Date:         Tue, 20 Jul 1999 21:24:32 +0100
Reply-To:     peter.crawford@DB.COM
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Peter Crawford <peter.crawford@DB.COM>
Subject:      Antwort: Re: os/390(mvs) reading a file after binary FTP from os/2
Content-type: text/plain; charset=us-ascii

Many thanks for confirming the issues.

Binary seems necessary because the data includes some fields stored in a form we
can read with s370fPDw.d, and also because the ftp program aborted the character
transfer with message "......invalid string...."
The source has varying record lengths. There are at least five different lengths
among the source data records.

I thought it should be the ftp program which would do any reformatting, but
there appears no way in the binary ftp process to regularize the records from
linefeed terminated at the source into the variable length record approach of
mvs !
(I suppose '0a'x must be allowed to arise among the data when that is defined as
binary!)

We have embarked on performing the reformatting ourselves at the receiving (mvs)
end, having no access to SAS on the server source end.

Previously using a pc-sas approach, with access to the data through the local
network, was extremely slow!

Thanks again!


Datum:         20.07.99 21:07
An:            Peter Crawford/Zentrale/DeuBaExt



Betreff:       Re: os/390(mvs) reading a file after binary FTP from os/2
Nachrichtentext:



Peter,
If the file _has_ to be sent in binary, you can use the SITE command to
pass the MVS allocation parms (lrecl, blksize, recfm).  However, if this
is varying-length binary data, then -uh- well, you may have to pre-process
it into a standard length, as MVS doesn't know about 0D or OD0A or 0A or
whatever (^Z on a Cyber as i recall) when it reads binary data. ( I
thought 0A was <LF> and particular to a mac).  You might use SAS for the
preprocessing.  --Joe