JUNGER@CWRU.BITNET (05/07/88)
A few days ago I posted several pleas for help because, though
I could get files from the SIMTEL20 archives from the listservers on
bitnet known as LISTSERV@RPICICGE and TRICKLE@TREARN, the files came
through utterly scrambled, whether they were supposed to be in ASCII
or BINARY format.
The response was wonderful and the problem is now solved.
This message is to thank all those who helped, to give a history of
my problem--which is not, as it turns out, unique--and to describe
the solution to the problem that I arrived at only because of the
help of my new friends out there on the nets.
The rest of this message will probably only be of interest
to those of you who communicate on bitnet through VAX nodes and
to those few heroic souls who maintain the servers that supply
the rest of us with all that useful software for our PC's.
A good bit of my initial problem was the result of my own
extreme stupidity. When the VAX informed me that I had received
one of the files that I had requested from one of the software
servers, I invoked RECEIVE in its interactive mode and gave it
the command
COPY *
without indicating any parameters. In partial justification for
my stupidity, the initial files that I had requested were text files,
and I assumed, correctly, that they were maintained on SIMTEL20 in
ASCII format. Unfortunately one of the default switches (at least
on the CWRU VAX) for RECEIVE (and RECEIVE COPY) is /TRANSLATE.
And that meant that before copying the file into my directory,
RECEIVE translated the file into EBCDIC (or else it assumed the file
was in EBCDIC and "translated" it into ASCII, I don't know which).
At that point I asked the net for help.
One of the first responses that I got was from Dave Goodwin
(Goodwin@SMCVAX.BITNET), a.k.a. Dr. D0S, who wrote:
|Peter, have you tried asking for files in UUENCODED format? I am on a VAX
|also, and that's what we must do. I use the command form:
|
| SEND Listserv@RPICICGE /pdget pd:<dir>filename.ext ( UUENCODE
|
|This of course assumes you have a UUDECODER at your site. We didn't, but I
|simply got the source out of RPICICGE and compiled one. I have to say though
|that I've not had the problem you describe with plain text files!
|
|I'm relatively new at this myself, but feel free to ask for more details and
|I'll do what I can!
That is a solution that I have not pursued. I did not have
a copy of the UUDECODER. I mentioned this on the net and soon was
swamped with copies of source code, in both C and Pascal, of both
the encoder and decoders. I do not know whom to thank for all of these
goodies, though I know some came from Dave. In any case, thanks to all.
The UUENCODing approach suggests something about the nature
of the problem--or, at least, of a problem. As I sort of guessed,
SIMTEL20 is a DEC20 and, as I sort of remembered, DEC20's have 36 bit
words and (for the most part) 7 bit bytes. I don't quite know what
UUENCODing involves, but--from a quick glance at the source code--the
encoder/decoder packs/unpacks (or vice versa) two bytes into three.
I would be interested to find out exactly what those programs do.
It would be an interesting exercise to write an 8086 assembly language
version as a thank-you present for all who have helped me.
I have not yet compiled the decoder, so I don't know if
encoding and decoding is one solution to my problem. Instead another
solution was suggested by John S. Fisher (FISHER@RPICICGE), who is
the wizard of PCSERV-L and the software server on RPICICGE. His
message also referred to UUDECODing programs and, before I leave
that subject, I should also mention that Turgut Kalfaoglu
(BILTUR@TREARN), whom we have to thank for the RED server on
TRICKLE@TREARN, has been most helpful; Turgut sent me the following
message related to encoding:
|Try the new encoding options of the TRICKLE@TREARN.
|Use:
| /PDGET <dirnam.dirnam>fn.ft (EBC80
| (EBC32
| (UU
|
|The first two convert the file to EBCDIC, and the last one encodes it with
|UUE... Please let me know how it goes.
| -turgut
Here is the message from John Fisher which revealed to me
my stupidity about binary files and suggested the solution to a
more serious problem:
|Assuming your VAX is running Jnet, it is possible to receive files without
|incurring the EBCDIC/ASCII translation that is clobbering you files. I am
|not all that familiar with the product, but the syntax is something like
|RECEIVE/BINARY. There is still one thing you must do after that to convert
|the file to some final correct form. Perhaps someone more VAX-wise will
|comment.
|
|At any rate, the uudecode programs available that may be useful are as
|follows:
|
| PD:<MSDOS.STARTER>UUDECODE.BAS --BASIC source.
| PD:<MSDOS.STARTER>UUDECODE.PAS --Pascal source.
| PD:<MSDOS.STARTER>UUDECODE.C --C source.
| PD:<MISC.VAXVMS>UUDECODE.VMS --FORTRAN(?) source for your VAX.
|
|The one appropriate for you should be requested with the TRANSLATE option.
At this point, somewhat embarrassed, I requested some files
from the listservers and RECEIVEd them with the /BINARY (== /NOTRANSLATE)
switch. I could then read the text files that I received.
Unfortunately, when I kermited them down to my PC (first giving
the SET FILE TYPE BINARY command), PKXARC informed me that each of the
files that were members of the ARC file had a CRC sum error. This
was a big improvement, since at least PKXARC recognized that the files
were archived, something that it could not do with the earlier files
imported without the /BINARY switch.
At this point Helen Ng (NG@CWRU), of the Jennings Computer Center
here at CWRU, sent me a program called VMSSWEEP.EXE (which is available
from the listserver at RPICICGE). (I owe Helen a lot of thanks, as I would
never have been able to solve the problem without her assistance.)
This program runs on a VAX under VMS and dismembers ARC files.
It nearly solved my problem. The only difficulties were that one of
the member files in the ARC file still produced a CRC sum error and that
I wanted to download ARC files to my PC, rather than their unsquashed
contents.
In the meantime though I had received three additional messages
that spelled out the ultimate solution:
John L. Neufeld (NEUFELD@UNCG) wrote:
|On our VAX running JNET, the method I have used to get files from RPICICGE is
|as follows:
|
|1) Receive the file with RECEIVE/BINARY. This suppresses the EBCDIC to ASCII
|conversion which JNET normally performs on files received from BITNET. The
|RECEIVE command can also be used to undo the damage which may have occurred if
|a file has been received without /BINARY. Use HELP RECEIVE to find the stuff
|about converting already RECEIVE'd files from ASCII to EBCDIC.
|
|2) This is not sufficient! For some reason, VMS is liable to regard the file
|have an implicit carriage return as a line delimiter. This must be changed,
|and the process has several steps.
|
|3) Assume the received file's name is RPICICGE.ARC. The first step would be to
|produce an FDL file for RPICICGE.ARC. This is done with the following command:
|
|$ANALYZE/RMS/FDL RPICICGE.ARC
|
|The result will be a new file, RPICICGE.FDL. This is an ascii file which can
|be easily examined. Under RECORD examine CARRIAGE_CONTROL. If the entry says
|"carriage_return", then it must be changed.
|
|4) VMS has a special editor for changing FDL files. Invoke it with the
|following command:
|
|$EDIT/FDL RPICICGE
[I think this should be $EDIT/FDL RPICICGE.ARC]
|
|The editor uses a menu interface to allow you to change every entry to another
|acceptable value. Use the editor to change "carriage_control" to "none". Exit
|the editor.
|
|5) The corrected FDL file is finally used to create a new file using the
|CONVERT utility:
|
|$CONVERT/FDL=RPICICGE.FDL RPICICGE.ARC USABLE_RPICICGE.ARC
|
|6) The new file, USABLE_RPICICGE.ARC can now be downloaded via Kermit (Don't
|forget SET FILE TYPE BINARY to VAX Kermit).
John L. Neufeld (NEUFELD@UNCG.BITNET) wrote:
|Here is a message which, I think, has the information you want:
|
|******************************************************************************
|
|Date: Tue, 16 Feb 88 11:39 PDT
|From: <RAUSEO%UCLACH.BITNET@CUNYVM.CUNY.EDU>
|Subject: Receiving NETDATA binary files on BITNET VMS hosts running JNet
| I have successfully picked up files from the CCUC server and from
|LISTSERV@RPICICGE without using a decoder on my PC. If your VAX
|installation is using JNet 3.0 or later for its BITNET software, then I
|believe that you can do the same.
| The procedure I use is this:
|1) When I request a file from CCUC or from RPICICGE I set no flags but get
|the file in the default format set by the server.
|2) If when you run the receive utility the class of the file is listed as
|"PUN N" then when you "RECEIVE" or "COPY" the file you must specify the
|/BINARY option.
|3) Once the file exists on your VAX directory, you may still not be out of
|the woods. Your VAX may set the file to have an implicit CR_LF
|combination at the end of each record as a default. It does not actually
|exist as such, but the VAX will add these characters when you kermit it to
|your PC. You must use the CONVERT utility on the VAX to convert the
|carriage control of the file from CR_LF to None. (You create a *.FDL file
|using the Edit/FDL utility and then Convert the file you obtained from the
|network using that *.FDL file. This may all sound like a lot of work, but
|it is reasonably well documented for the VAX, and you only need to create
|this FDL file once. Your local systems people should be able to help
|you.)
|4) Bingo! Once you kermit this converted file to your PC, the file should
|un-archive successfully.
|Hope this helps.
|Steve Rauseo (RAUSEO@UCLACH.bitnet)
and D'haese Gratien (DHAESE@BANUIA51) wrote:
|The solution to your problem is rather easy, and you don't need any
|special program from SIMTEL20 because VAX is able to solve the
|problem.
|
|First: receive> copy/notranslate *.*
| receive> exit
| Files are now saved under your main directory.
|
|Second: Create a CONRPIC.COM file like this one:
|
|$ convert/fdl=[-]RPIC.FDL 'p1 'p1
|$ purge
|
|Thirdly: also create the RPIC.FDL file,
|
|IDENT "25-APR-1988 15:42:13 VAX-11 FDL Editor"
|
|RECORD
| CARRIAGE_CONTROL none
| FORMAT undefined
|
|Last thing to do is, e.g. CONRPIC file
|and your file is ready to be transfered to a PC, the file can be read
|or unarced, etc...
|
|Greetings from ANTWERP and happy RPICcing......
Now, even with all this help, I still had to ask Helen Ng to
explain to me how to go about actually entering the commands to do
the necessary conversion.
Still I received several messages from others who believed that
they were suffering from the same problem that I was. One was working
on an IBM node, so his problem must have been different, but the rest
may actually profit from my hard earned experience. So here (only
slightly edited) is an actual log of the way I now get a file from
Simtel20 to my PC (only the first command is simulated) [By the
way, though I RECEIVE files from RPICICGE and TREARN in different
PUN formats, this solution appears to work equally well on files from
both those sources]:
$ send trickle@trearn /pdget <msdos.txtutl>filters.arc
[then do something else until notified that the file has been received]
$ receive
Files received for JUNGER
Source file Class Node User Date Time Records
FILTERS.ARC;4 PUN A TREARN TRICKLE 4-May-1988 20:27 256
FILTERS.ARC;3 PUN N RPICICGE TRICKLE 4-May-1988 14:28 256
GGREP.ARC;2 PUN A TREARN TRICKLE 4-May-1988 18:19 249
RECEIVE> copy filters.arc;4 /binary
%RECEIVE-S-COPIED, copied NETDATA file
from: FILTERS.ARC;4
to: ARJCC:[JUNGER]FILTERS.ARC;1
RECEIVE> exit
$ dir *.arc
Directory ARJCC:[JUNGER]
FILTERS.ARC;1
Total of 1 files.
$ analyze/rms/fdl filters.arc
$ type filters.fdl
IDENT " 6-MAY-1988 15:32:25 VAX/VMS ANALYZE/RMS_FILE Utility"
SYSTEM
SOURCE VAX/VMS
FILE
ALLOCATION 42
BEST_TRY_CONTIGUOUS no
CLUSTER_SIZE 3
CONTIGUOUS no
EXTENSION 0
GLOBAL_BUFFER_COUNT 0
NAME "ARJCC:[JUNGER]FILTERS.ARC;1"
ORGANIZATION sequential
OWNER [600,113]
PROTECTION (system:RWED, owner:RWED, group:RWE, world:)
RECORD
BLOCK_SPAN yes
CARRIAGE_CONTROL carriage_return
FORMAT variable
SIZE 0
$ edit/fdl filters.fdl
Parsing Definition File
Definition Parse Complete
VAX-11 FDL Editor
Add to insert one or more lines into the FDL definition
Delete to remove one or more lines from the FDL definition
Exit to leave the FDL Editor after creating the FDL file
Help to obtain information about the FDL Editor
Invoke to initiate a script of related questions
Modify to change existing line(s) in the FDL definition
Quit to abort the FDL Editor with no FDL file creation
Set to specify FDL Editor characteristics
View to display the current FDL Definition
Main Editor Function (Keyword)[Help] : modify
Current Primary Attributes
SYSTEM
FILE
RECORD
Enter Desired Primary (Keyword)[FILE] : record
Current RECORD Secondary Attributes
RECORD
BLOCK_SPAN yes
CARRIAGE_CONTROL carriage_return
FORMAT variable
SIZE 0
Enter RECORD Attribute (Keyword)[-] : carriage_control
RECORD
CARRIAGE_CONTROL carriage_return
(Carriage_return FORTRAN None Print)
Enter value for this Secondary (Keyword)[-] : none
Resulting Primary Section
RECORD
BLOCK_SPAN yes
CARRIAGE_CONTROL none
FORMAT variable
SIZE 0
Press RETURN to continue (^Z for Main Menu) Exit
VAX-11 FDL Editor
Add to insert one or more lines into the FDL definition
Delete to remove one or more lines from the FDL definition
Exit to leave the FDL Editor after creating the FDL file
Help to obtain information about the FDL Editor
Invoke to initiate a script of related questions
Modify to change existing line(s) in the FDL definition
Quit to abort the FDL Editor with no FDL file creation
Set to specify FDL Editor characteristics
View to display the current FDL Definition
Main Editor Function (Keyword)[Help] : exit
ARJCC:[JUNGER]FILTERS.FDL;2 22 lines
$ dir filters.fdl
Directory ARJCC:[JUNGER]
FILTERS.FDL;2 FILTERS.FDL;1
Total of 2 files.
$ del filters.fdl;1
$ type filters.fdl
IDENT " 6-MAY-1988 15:34:00 VAX-11 FDL Editor"
SYSTEM
SOURCE VAX/VMS
FILE
ALLOCATION 42
BEST_TRY_CONTIGUOUS no
CLUSTER_SIZE 3
CONTIGUOUS no
EXTENSION 0
GLOBAL_BUFFER_COUNT 0
NAME "ARJCC:[JUNGER]FILTERS.ARC;1"
ORGANIZATION sequential
OWNER [GUEST,JUNGER]
PROTECTION (system:RWED, owner:RWED, group:RWE, world:)
RECORD
BLOCK_SPAN yes
CARRIAGE_CONTROL none
FORMAT variable
SIZE 0
$ convert/fdl=filters.fdl filters.arc filterx.arc
$ dir filterx.arc
Directory ARJCC:[JUNGER]
FILTERX.ARC;1
Total of 1 file.
$ kermit
VMS Kermit-32 version 3.3.111
Default terminal for transfers is: _LTA452:
Kermit-32>set file type binary
Kermit-32>show file
File type BINARY
File naming Normal form
Incomplete file disposition Discard
Kermit-32>send filterx.arc
Kermit-32>exit
[I know that has a lot of extra steps, but it is a log of the first time
I got it all together.]
Again, my thanks to you all.
Peter JUNGER@CWRU