On Wed, 9 Jan 2008 15:36:28 -0600, Thomas Kern wrote:

>A good philosophy is to use some program common to both sending and
>receiving systems that will compress and possibly encrypt the data,
>retaining the file's original record formatting as part of the new data
>file. Transfer that new data file and decrypt/expand it at the receiving
>site. XMIT can be used to simply reblock the data to retain record
>formatting, TERSE/DETERSE can be used to compress and reblock. PKZIP can
>also be used. If you have a mainframe based data encryption product, it
>might have its own compress&encrypt utility, if you can convince the
>receiving system to use the same product.
>
In the OP's situation, both endpoints are z/OS, so the middleman needn't
understand the format; it should be just bits to him.

Now that TERSE is becoming a base z/OS facility, it should be made an
option of FTP to save a separate job step:

    LOCSITE TERSE

>On Wed, 9 Jan 2008 15:24:32 -0600, Bruce Baxter
> wrote:
>>use of FTP introduces in this process.  The central issue as I see it is that 
>>the
>>mainframes at either end of the pipeline are both EBCDIC and record oriented,
>>and the servers and ftp processes that lie between them to facilitate these
>>transfers do not have any inherent concept of record oriented files like the
>>mainframe.

I did "HELP LOCSITE" with z/OS FTP client.  It tells me:

    RDw             RDW from VB/VBS files is retained as data.
    NORDw           RDW from VB/VBS files is discarded as not data.

Sigh.  Too literally true.  What I observed was that on PUT the RDWs
were transmitted as if they were data.  On GET, they were treated as
data, not as RDWs.  Didn't any coder or design reviewer or whatever
have the guts to say to the specifier, "The way you describe this is
probably not what the customer needs."?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to