| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 406.1 | | MORRIS::SMCAFEE | Steve McAfee | Wed Mar 25 1987 22:14 | 18 |
|
Other folks in this conference have mentioned that KERMIT is slower
than XMODEM however it seems more reliable (at least to me).
Try downloading to RAM: rather than disk. This speeds things up
considerably. (Watch your available memory though.)
As long as arc16.bin downloaded ok, it should work as follows:
From the cli simply "CD" to the directory containing ARC16.BIN and
then type "ARC16.BIN". It should throw up a full page containing
instructions on how to use the command. BTW you can rename the
program to anything you like the .BIN is purely a mnemonic to show
that the file is executable rather than ARC/SHAR or whatever.
regards,
steve mcafee
|
| 406.2 | | AMULET::HALVERSON | | Thu Mar 26 1987 07:52 | 8 |
| Thanks Steve I will give that a try tonight..
steve
|
| 406.3 | | AUTHOR::MACDONALD | WA1OMM Listening 224.64 | Thu Mar 26 1987 09:08 | 26 |
| To extract files from the archive do the following:
1. Use the CD command to set the current directory. ARC sends extracted
files to the current directory.
2. Make sure that the ARC'ed file you are working on has the extension
.ARC
3. The command line goes like this
ARC E filename
Here's an example:
Let's say your ARC utility is named ARC16.BIN and is located an
DF1:. Let's assume you wish to deARC UEDIT1.ARC that is located on
DF0:. And finally, let's assume you wish the deARC'ed files to end
up in a directory on DF0: called UEDIT. To accomplish all this do
the following:
1. Create the directory EDIT ---> MAKEDIR DF0:UEDIT
2. Set the current directory to DF0:UEDIT ---> CD DF0:UEDIT
3. Run the ARC utility ---> DF1:ARC16.BIN E DF0:UEDIT1
That's all there is to it! There is a document file in the ARC23.arc
archive that goes into more detail.
|
| 406.4 | STILL HAVING TROUBLE | AMULET::HALVERSON | GARFIELD | Thu Mar 26 1987 20:47 | 8 |
| I AM STILL HAVING TROUBELE WITH ARC16.BIN.
WHEN I TRY TO RUN IT I GET AN ERROR MESSAGE...UNABLE TO LOAD
ARC16.BIN FILE IS NOT AN OBJECT MODULE...
WHATS NEXT?
STEVE
|
| 406.5 | Use IMAGE/FIX modes | MLOKAI::SANFORD | | Thu Mar 26 1987 20:57 | 4 |
| Make sure you are using IMAGE mode in VT100 and SET FILE FIX when
using KERMIT-32.
-drew
|
| 406.6 | FIXOBJ | AUTHOR::MACDONALD | WA1OMM Listening 224.64 | Fri Mar 27 1987 10:12 | 4 |
| Other possibility is there might be some junk on it. Try running
it through FIXOBJ to remove the junk.
Paul
|
| 406.7 | STILL NO LUCK | AMULET::HALVERSON | GARFIELD | Fri Mar 27 1987 19:13 | 16 |
| I am still having some difficulty. I re-transfered the arc16.bin
file. When I try to run it now I get the message insufficient free
store. What am I doing wrong? I send the file to ram disk and
after it is through the disk is full. Would it be possible for
me to send someone an empty disk and have the arc23 executable files
copied onto it. I would be forever thankfull.
On a different note ....can someone describe the steps in down loading
a file from compuserve and which protocol shoud be used?
thanks steve
|
| 406.8 | | MORRIS::SMCAFEE | Steve McAfee | Sun Mar 29 1987 12:32 | 20 |
| steve,
I don't know if this is your problem or not, but one of the bugs
with arc16 was that it couldn't dearc a file that was in ram:.
I should have mentioned this when I told you to download to ram:,
sorry. After you download arc16 to ram:, copy it to a disk along
with the file you want to dearc. Kill VT100 if the file you are
dearcing is large (and anything else you may have running.).
If this still doesn't work, then something must be wrong with your
executable. Unfortunately, some areas have phone lines which are
noticeably poor. Your best bet would be to find a local store which
carries PD disks. I'm sure that at least one of the Fred Fish disks
has this on it. You can refer to other notes for listings of these
disks. {I believe I saw a somewhat complete listing of the disks in Dave
Wecker's area (thanks dave!)}.
regards,
steve mcafee
|
| 406.9 | | AMULET::HALVERSON | GARFIELD | Mon Mar 30 1987 08:28 | 10 |
| I HAVE THE FULL LISTING OF FISH DISKS AND I DO NOT SEE ANY ARCXX
ON ANY OF THEM. I WILL TRY AGAIN TONIGHT TO DEARC A FILE WITH NOTHING
ELSE RUNNING IN THE BACKGROUND.
COPYING TO RAM AND USING 2400 BAUD REALLY DID SPEED THINGS UP IN
XFERING FILES....
STEVE
|
| 406.10 | STILL TRYING | AMULET::HALVERSON | GARFIELD | Tue Mar 31 1987 12:17 | 8 |
| WELL I TRIED TO RUN ARC16 AGAIN WITHOUT ANYTHING RUNNING IN THE
BACKGROUND AND IT STILL SAID INSUFFICIENT FREE STORE...I HAVE ASKED
SOMEONE TO COPY THE EXECUTABLES FOR ME TO SEE IF THAT WORKS FOR
ME.
STEVE
|
| 406.11 | Is there a lot of stuff on the disk? | DDMAIL::ANDREWS | Just living a life of illusion | Tue Mar 31 1987 18:18 | 11 |
| This insufficient free store message sounds familiar to me.
I was trying to edit a file, and recieved this message too. What
I did was remove some files off of the disk I was using to another
disk, and try again. BINGO, I could edit the file.
My suggestion: Check to see how full the disk is, and remove some
stuff to somewhere else.
Rob
|
| 406.12 | Increase your stack? | NOVA::RAVAN | | Wed Apr 01 1987 13:02 | 7 |
| Maybe ARC is using the stack for some buffers or something
like that? You might try issuing a large STACK command
before running ARC. Just a suggestion. I've never had
this problem with my ARC16, but I've also never tried to
deARC a large file.
-jim
|
| 406.13 | WHAT IS STACK? | AMULET::HALVERSON | GARFIELD | Wed Apr 01 1987 13:23 | 4 |
| COULD YOU EXPLAIN A LITTLE FURTHER ABOUT THE STACK COMMAND YOU
MENTION...
THANKS.
|
| 406.14 | The STACK command | NOVA::RAVAN | | Wed Apr 01 1987 21:03 | 16 |
| The CLI command STACK gives the size to make the stack for all programs
that run from that particular CLI until another STACK command is
issued. So, let's say that you want to run program X, and you know
that program X uses a lot of stack space, because of the recursive
algorithms that it uses (for example). So you decide to give it a 100K
stack. To do so you would simply enter:
STACK 102400
X
When the CLI starts up X, it will allocate a 100K stack for it to
use.
Clearer?
-jim
|
| 406.15 | | AMULET::HALVERSON | GARFIELD | Thu Apr 02 1987 08:30 | 5 |
| THANK FOR THE INFO...I DID TRY DOING THAT LAST NIGHT, BUT I STILL
GOT THE INSUFFICIENT FREE SPACE MESSAGE...WHAT NEXT?
STEVE
|
| 406.16 | | EVER11::EKLOF | We're everywhere. | Fri Apr 03 1987 13:17 | 9 |
|
Just a thought. I haven't been able to get arc running, either, though
from the error messages I got, I think my problem is I don't have enough
memory (only 256K for now). Is there anyone out there who has gotten it to
run on a 256K Amiga? More memory is my first priority, anyway, but if I can
get it to run now, that would be even better.
Mark
|
| 406.17 | ARC16 prblm from a Mac | RSTS32::HUNT | Wherever you go, there you are! | Fri Apr 10 1987 10:09 | 20 |
| I am having trouble getting ARC16.BIN running too. I get the 'Not
an object file' error, and DID set Kermit-32 to FILE TYPE BINARY.
Should I also set FILE FIX?? I sent the file to my MAC (in image
mode), since it has an 80-meg HD. Then, using DIGITAL LINK on both
sides, tried to XMODEM it from the MAC to AMIGA at 57.6k baud.
The xfer went ok (only took 45 seconds!), but, hence the error
listed above occurred.
Does anyone know about Digital link? It was/is a product that comes
with a MAC and Amiga disk and cable, versions of the same pgm run
on BOTH machines, doing the xfer in XMODEM protocol. There is also
an option on the Amiga side called 'Amiga Binary' that can be set
instead of Xmodem. Does anyone know the correct protocol for this?
I really bought Digital Link, but since moving from CA to NH, can't
find the manual.
Phil Hunt
|
| 406.18 | Use kermit if you've got it! | SQM::JMSYNGE | James M Synge, VMS Performance Anal. | Sun Apr 12 1987 12:06 | 13 |
| Re: .17
The error was introduced in the transfer from the Mac to the Amiga.
XMODEM doesn't transfer files correctly. It includes extra garbage
at the end because it seems to describe file lengths in terms of
'blocks' instead of bytes. Thus there is normally some extra
garbage at the end.
I always recommend Kermit because I've never had a problem transferring
afile with Kermit, as long as I set the File Type correctly at the
beginning.
James
|
| 406.19 | Amiga xfer fixed | RSTS32::HUNT | Wherever you go, there you are! | Mon Apr 13 1987 10:42 | 16 |
| Hello,
Well, I got the xfer to work. I use kermit to xfer from VAX
to the Mac, where I store the files on my Mac Hard disk. Then I
use Digital Link on the MAC and AMIGA to xfer the files using MACBINARY
and AMIGABINARY xfer protocols. Digital Link has AMIGABINARY defined,
and it is really just Macbinary format. Anyway, after this xfer,
which by the way, is MUCH faster than KERMIT, at 56kbaud, the output
files are just fine and runnable.
Who needs a HD for Amiga! I am just going to store my files
on the Mac HD! I can xfer 100k file in about 45 seconds, almost
as fast as the Amiga floppy! :*))
Phil Hunt
|
| 406.20 | XFER ok, but WHY? | RSTS32::HUNT | Wherever you go, there you are! | Mon Apr 13 1987 10:45 | 8 |
| Oh, BTWE, I forgot to mention, services like GEnie REQUIRE the user
to download Amiga files using XMODEM. It also seems to work fine
as long as (on a Mac), you turn off automatic detection of MacBinary
files. In that mode, it sends 128 byte block files, so I don't
know WHY it works, but it does.
Phil Hunt
|