On Thu, 10 Jan 2013 22:13:51 -0600, Ed Gould wrote:
>
>That is contrary to what I have experienced.
>
What options? Certainly if you specify RDW. Otherwise, give
an example, with hex dump.
Of course, if you transfer z/OS to Z/OS with TYPE ASII, the
RDWs are not transmitted, but reconstructed at the receiving
end.
On Thu, 10 Jan 2013 20:28:26 -0500, Steven St.Jean wrote:
>Gil,
>
>> The ugly truth:
>
>> >>> STRU R
>> 504 Unimplemented STRU type.
>
>Depending on what the OP wants to do with the file on the Windows system, it
>may not matter that it does not support STRU R. The important thing is that
>z/OS does. If the primary goal is what we used to call "invertibility" --
>getting the file back exactly as it started out -- STRU R with binary should
>work. You just have to make sure you tell it to the z/OS side on both
>transfers.
>
It would seem so, but as I reported earlier in this thread, it doesn't work.
Empty records are corrupted; I don't get "the file back exactly as it started
out". I suspect this is purely a z/OS flaw, and it might occur even
transferring directly z/OS to z/OS with STRU R.
BTW, I understand how this process works with Windows client and z/OS
server. Can it be done likewise with z/OS client and Windows server
(which seemed to be the OP's requirement)? IOW, is there a LOCSTRU
or LOCSITE STRU R type command to allow the Windows server to
operate in BINARY mode and the z/OS client in RECORD?
An immodest proposal: Does anyone want to write the requirement for:
SITE AMATERSE and LOCSITE AMATERSE, and/or
SITE TSOXMIT and LOCSITE TSOXMIT?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
