home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Unsorted BBS Collection
/
thegreatunsorted.tar
/
thegreatunsorted
/
texts
/
txtfiles_misc
/
simtel20.1
< prev
next >
Wrap
Text File
|
1993-10-09
|
15KB
|
328 lines
Subj: #2(3) File: "PDGET HELP"
Date: 93-10-09 03:22:21 EDT
From: LISTSERV@VM1.NODAK.EDU
To: Monk OTY
Mail Split By AOL Gateway
------- cut here --------
ASIS -- suitable for hosts that can receive binary data. The
file is sent exactly as it is stored on the server:
binary images of the file data. ASIS may be used
only with format NETDATA.
UUENCODE -- suitable for hosts that cannot receive binary data.
The file is sent uuencoded.
OLDUUE -- suitable for hosts that cannot receive binary data.
The file is sent uuencoded using a variant in which
an extra character is appended to the end of each
line to protect it from trailing blank truncation.
(This method is obsolete and should be avoided.)
XXENCODE -- suitable for hosts that cannot receive binary data.
The file is sent xxencoded.
TRANSLATE -- suitable for any host, but only when the file actually
represents readable text. The file is translated to
EBCDIC. (If you are on an ASCII machine, then your
system should automatically translate to ASCII when
the file arrives.) TRANSLATE applied to a binary file
is treated as if UUENCODE were specified.
If no encoding is specified, then ASIS is assumed for NETDATA, and
UUENCODE for the others. If a requested file is too large to send
through BITNET in the requested format, then the server forces it to be
uuencoded MAIL. (Only the BITSEND format avoids this format
conversion.)
--------Note--------Note--------Note--------Note--------Note-----------
In the actual archives at SIMTEL20 there are a few files stored in
the top-level directory. (For example, PD:<MSDOS>FILES.IDX is a file
listing the names of all the files in the subdirectories of the MSDOS
archive.) The design of the BITNET server does not permit access to any
of these files. However, since the files at the top-level directory
generally contain directory information, the need for them is superseded
by the /PDDIR command.
--------Note--------Note--------Note--------Note--------Note-----------
------------------------------------------------------------------------
Getting Started
------------------------------------------------------------------------
WARNING:
The specific file names and "paths" used below MAY change over time.
This is expecially likely for ones like:
PD:<MSDOS.STARTER>ARCE40G.COM
PD:<MSDOS.STARTER>ARCE40G.DOC
PD:<MSDOS.ZIP>DEZIP20.COM
where the "40G" and "20" may be a version or release name.
If you can't find the file indicated try /pddir commands such as
/pddir pd:<msdos.*>arc*.* 99999 or
/pddir pd:<msdos.*>dezip*.* 99999
to try to find the correct name and location.
Before all else, something you absolutely must have available is
a method for getting files from your host system to you micro computer.
It would be preferable if this method included support for transferring
binary files as well as normal text files. If you do not already have
a way to communicate with your host and transfer files, consider getting
the appropriate Kermit implementations available from the KERMSRV file
server at CUVMA.
Once that minor detail has been addressed, then you should consider
what additional utility programs you will need or that will be helpful.
Most files are in an archive format, so you will need a de-archive
utility or two. You may also need a uudecode program, depending on your
ability to receive binary files on your host and your ability to
download binary files to you micro computer.
This last point requires some explanation. The server stores all
files from SIMTEL20 as-is in 128 byte sector image blocks. They are
bit-for-bit identical to how they should appear on your micro computer.
The server makes no attempt to interpret the files; it simply sends them
on demand out through BITNET. BITNET, though, is fundamentally an
EBCDIC network, and your micro computer is fundamentally an ASCII
machine. This gives rise to two places along the path from server to
micro where the file data might be misinterpreted or corrupted.
If your host system is ASCII-based (as are most non-IBM systems)
it will translate incoming BITNET files from EBCDIC to ASCII. If your
host is EBCDIC-based, your communications software will translate files
you download from EBCDIC to ASCII. But the files from the server do not
contain EBCDIC data. You must either find a way to disable the
translations or encode the data in such a way that the original file
can be recovered.
There are suggestions given later for specific host machines to
disable the translations. For now assume data encoding is required.
You can ask the server to send files in encoded from. If you request
encoding, the file is encoded using either of two techniques, uuencoding
or xxencoding. Encoded data is preserved through most of the
EBCDIC/ASCII translations the file might encounter. So, all you need
is a program for you micro computer that decodes an encoded file.
--------Note--------Note--------Note--------Note--------Note-----------
Uuencoding is by far the more popular method for encoding binary
data files. However, there are some few mail gateways (most notorously
the JANET gateway) through which the encoding does not survive. There
also are a multitude of uuencode/uudecode implementations which are not
fully 100% compatible with each other. If an XXdecode implementation
exists for your environment, then that is the method you should favor.
To help diagnose character translation problems we have stored a
file called ASCII CHARS on the LISTSERV@NDSUVM1.BITNET (or on the
Internet listserv@vm1.nodak.edu). Send the server at that address the
command GET ASCII CHARS and download the file to the location where
you do the uu/xxdecoding. By visually inspecting the result you may be
able to see where the problem is and compensate for it.
For large files the LISTSERV/trickle server will break up the
encoded output into several files. You must RECOMBINE these files
properly before trying to decode them! It may be easiest to do this
on the system which firsts receives the mail, before you download
the files to the system where you will decode them. Be sure they are
recombined in the correct order! A script for unix users is included
below in the section "Unix Users".
--------Note--------Note--------Note--------Note--------Note-----------
There are several decoders available from SIMTEL20. The only
problem is how do you get the program to your micro computer. Catch-22.
Well, you can ask the server to send ASCII text files in translated
form. If you request translation, a file is first translated to EBCDIC
before it is sent. This is not recommended as a standard option since
there may be some loss of information, but for getting started it may
be essential.
If you need a program for MSDOS to decode uuencoded files, send the
following commands to the server:
/PDGET PD:<MSDOS.STARTER>UUDECODE.xxx TRANSLATE
/PDGET PD:<MSDOS.STARTER>UUENCDEC.DOC TRANSLATE
Replace "xxx" with either BAS, C, or PAS depending on which source
language you would prefer (BASIC, C, or Pascal, respectively).
If you need a program for CP/M to decode uuencoded files, send the
following command to the server:
/PDGET PD:<CPM.STARTER-KIT>UUDECODE.HEX TRANSLATE
The file contains the CP/M hex data for the program. Download it. Use
the CP/M commands LOAD and SAVE to create an executable program. You
should end up with UUDECODE.COM, the desired program.
Next, you should consider requesting which ever of the following
files you feel appropriate for your micro computer system:
For PC-DOS and MSDOS machines:
PD:<MSDOS.STARTER>ARCE40G.COM Un-archive utility.
PD:<MSDOS.STARTER>ARCE40G.DOC ..and the documentation.
PD:<MSDOS.ZIP>DEZIP20.COM ZIP archive extract
PD:<MSDOS.STARTER>UUDECODE.COM Compiled uudecode utility
PD:<MSDOS.STARTER>UUDECODE.DOC ...and the documentation.
For CP/M machines:
PD:<CPM.STARTER-KIT>DELBR12.COM Un-library utility.
PD:<CPM.STARTER-KIT>UNARC.COM-Z80 Un-archive utility, Z-80 only.
PD:<CPM.STARTER-KIT>UNARCA.COM-8080 Un-archive utility.
PD:<CPM.STARTER-KIT>UNARC.DOC ..and the documentation.
PD:<CPM.STARTER-KIT>UNCR-Z80.COM Un-crunch utility, Z-80 only.
PD:<CPM.STARTER-KIT>UNCR8080.COM Un-crunch utility.
PD:<CPM.STARTER-KIT>UNCR8080.DOC ..and the documentation.
PD:<CPM.STARTER-KIT>USQ120.COM Un-squeeze utility.
PD:<CPM.STARTER-KIT>USQ120.DOC ..and the documentation.
There are many other useful utilities in these and other archive
directories. Remember, though, if you need the server to UUENCODE the
files you request, you should explicitly ask for it. Also, some of the
programs listed above may be replaced by newer versions. (For example,
ARCE40C.COM replaced the earlier ARCE31C.COM.) If you have trouble with
the server claiming "file not found", use the /PDDIR command to list the
the appropriate directory.
You may find two other files useful. PD:<MSDOS.FILEDOCS>SIMIBM.ZIP
and PD:<CPM.FILEDOCS>SIMCPM.ARK contain one-line descriptions for many
of the other files in their respective archives. Not all files are
described, but it does contain enough valuable information to help you
find other software.
IBM System Users.
If your host is an IBM system running either VM or MVS, you can avoid
the need for uuencoding. Files received from BITNET will not be
translated, since the IBM is an EBCDIC machine. Most down-load methods
support binary transfer, so you can defeat the translation that would
otherwise take place there. For example, with CMS Kermit the command
SET FILE BINARY is all the is required before initiating a download.
If you are using a 3270 emulator and IND$FILE for file transfers, by
default no translation takes place.
VAX/VMS Users.
If your host is a DEC VAX system running VMS, with Jnet as your network
software, you can avoid the need for uuencoding. You can tell the Jnet
software to bypass the usual EBCDIC/ASCII translation, but there are a
few additional steps needed before downloading a file.
* Receive the file with the Jnet command RECEIVE/BINARY. The
BINARY modifier suppresses the normal EBCDIC/ASCII translation.
For the sake of discussion, assume that the file is now named
SOFTWARE.FIL. This file, as received, is almost correct; but
there may be an error in how VMS interprets the records.
* Generate an FDL file for SOFTWARE.FIL using the command
ANALYZE/RMS/FDL SOFTWARE.FIL
* Edit the FDL file with the command
EDIT/FDL SOFTWARE
Examine the CARRIAGE_CONTROL setting. Change it to NONE. Exit
from the editor.
* Use the edited FDL to correct carriage control interpretation
errors in the original SOFTWARE.FIL.
CONVERT/FDL=SOFTWARE.FDL SOFTWARE.FIL FIXED_SOFTWARE.FIL
* Download the FIXED_SOFTWARE.FIL as a binary file using any
reliable means. (For VAX Kermit, use the SET FILE TYPE BINARY
command before starting the download.)
Unix Users.
If you save the uuencoded parts in the proper order under unix
and then use the following script, which I call "lcombine" you should
be able to receive the files intact.
#! /bin/sh
cat $* | sed '/--- End /,/--- Part/d' | uudecode
This assumes the parts were saved using file names that sort
alphabetically into the proper order. Example:
simibm.uue01
simibm.uue02
simibm.uue03
lcombine simibm.uue*
The result will be simibm.zip and it should be readable. The script
eliminates the need to strip the headers from each uuencoded part.
There is another solution for those who may not be able to use the
lcombine script. A program called uucat ignores headers and trailers,
passing just the uuencoded part. It's available from SIMTEL20
directory PD:<MISC.UNIX> as UUCAT.C and UUCAT.MSG. It works just
like the Unix cat command on uuencoded files (NOT xxencoded):
uucat simibm.uue* | uudecode
(Contributed by Keith Petersen)
------------------------------------------------------------------------
Common Problems
------------------------------------------------------------------------
Q. I downloaded this program to my micro, but when I run it, my machine
hangs (or I get the message "Out of Memory" or ...).
A. Either the file became corrupted in transit (perhaps one of those
nasty EBCDIC/ASCII translations), or the file was uuencoded and you
have not decoded it.
Q. I downloaded an archive to my micro, but the de-archive utility
would not process it. I get messages like "File not an archive" or
"Cannot extract member".
A. Same comments as above.
Q. I really, really need to get these special files that I absolutely
must have, but the server limits how much I can request per day. Is
there any way I can get around these limits for this one special case
A. No.
Q. I am trying to get a file from the (top-level of the) MSDOS
directory. /PDDIR won't list it, /PDGET claims it can't find it,
but I know it is there.
A. It may well be there at SIMTEL20. However, the BITNET server is not
capable of handling any request for a file from the top-level of an
archive. Generally, though, the files stored at the top level list
the contents of the archive. The /PDDIR command can be used to get
a directory listing.
Q. I have been requesting this same file repeatedly. Each time the
server tells me my request has been "queued for processing," then a
------- cut here --------
----------------------- Headers ------------------------
From <@VM1.NODAK.EDU:LISTSERV@VM1.NODAK.EDU> Sat Oct 9 03:21:16 1993
Received: from VM1.NoDak.EDU by jlev.hp.aol.net with SMTP
(1.37.109.4/16.2) id AA02558; Sat, 9 Oct 93 03:21:16 -0400
Return-Path: <@VM1.NODAK.EDU:LISTSERV@VM1.NODAK.EDU>
Received: from VM1.NODAK.EDU by VM1.NoDak.EDU (IBM VM SMTP V2R2)
with BSMTP id 1210; Sat, 09 Oct 93 02:20:32 CDT
Received: from VM1.NODAK.EDU (NJE origin LISTSERV@NDSUVM1) by VM1.NODAK.EDU (LMail V1.1d/1.7f) with BSMTP id 4642; Sat, 9 Oct 1993 02:20:30 -0500
Date: Sat, 9 Oct 1993 02:20:29 -0500
From: BITNET list server at NDSUVM1 (1.7f) <LISTSERV@VM1.NODAK.EDU>
To: monkoty@AOL.COM
Subject: #2(3) File: "PDGET HELP"
AOL-Member: monkoty