Our old method for sending a M/F ADABAS File up to our Linux box was to FTP the file down to a PC ensuring ‘Quote site rdw’ is present to ensure the integrity of the DB file (RDW) and then the box to collect it. We’ve now decided on a more secure method which is to copy the file to zFS and the Linux box to collect it from there.
This new method works perfectly well for non-DB files using ‘OCOPY’ to get the file onto zFS but for ADABAS files (Unload/Decompress/VB dataset) we lose the ‘RDW’ 4 byte field when we check the file on Linux after it’s been picked up. We’ve exhausted searching the internet for parameter values so was wondering whether anybody else has experienced this issue. We’re open to suggestions if there’s a better method to get an ADABAS file up to zFS with RDW enclosed. TIA
This just doesn’t make sense, OCOPY doesn’t know what’s an “ADABAS file” or “another file”.
Are the “other files” VB as well ?
The only thing that influences the target format is the OCOPY BINARY option.
For Adabas ADACMP decompressed data there is the option HEADER=YES to have the ADAH prefix before each record. ADACMP on Linux can read these records when specifying RECORD_STRUCTURE=HEADER or RDW_HEADER. If the RDW prefix is missing, the individual record size is taken from the ADAH prefix.
You were speaking of a more secure method: using SFTP would give more security and FTPing directly between mainframe and Linux.
For copying structured data from mainframe I use the getfilez script from the adapya-base Python package which supports SFTP and RDW option.
Resolved using ‘HEADER=YES’ on the decompress on the M/F to create ADAH bytes for each record. Used ‘record_structure=header’ for the compress on Linux. Thanks for the replies
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.