MVS variable length records ftp'ed to Unix

[noggin]

I've got a MVS mainframe file that has been FTPed to our Solaris system. The records are variable and contain packed decimal and binary data so I've got to do any EBCDIC/ASCII conversion field by field, also I can't rely on the end of record being marked by line feed in the usual Unix fashion. Each record is preceded by a 4-byte record length field (RDW in mainframe terminology). I'm using Fujitsu COBOL and have coded -
01 in-record.
02 in-rdw pic 9(4) comp.
02 filler pic xx.
02 in-data pic x occurs nnn to nnn depending on in-rdw.
The record length (in binary) seems to be in first 2 bytes of the prefix field. Field in-rdw contains the length of in-data PLUS 4. So the system reads in the first record OK plus the first 4 bytes of the second record, hence all subsequent records are garbage. Anybody else had this problem? [sig][/sig]

 

[ChristopherD]

noggin -

Yes, I have had a similar problem. First, transfering packed data does not work. We convert everything to PIC 9 before the transfer. It seems that ftp thinks one of the packed characters is a crlf character. Secondly, we have had no luck with transfering variable length records. There really isn't a UNIX equivalent. We have two job streams (COBOL) that run half on the mainframe and half on UNIX - all of our files are fixed length with no packed data.

Sorry for the bad news, if you post this question in the general UNIX forum you might get a better response. [sig]<p>Christopher Devenny<br><a href=mailto:c_devenny@yahoo.com>c_devenny@yahoo.com</a><br><a href= > </a><br> [/sig]

 

[Thane]

Don't use the Ocurs Depending on. Instead code a Pic X area large enough for th elargest record, then code:

Record Length Varying Depending on in-rdw. That will fix you right up. [sig][/sig]

 

[oldtimer]

On the mainframe the RDW is hidden, the system routines return the correct record although you still have to decode it using a record type etc. To transfer character data (ie. 'flat' or 'visible', typical PC/UNIX) FTP will obviously work, for packed and binary data (ie. typical mainframe) it WON'T, you need a proprietary solution like Connect Direct (both the sending AND receiving systems need the sofware ie. CD for MVS & CD for Unix, expensive!). When your Unix program reads the transferred file you get the whole record. So say the RDW (bytes 1-2 actually contain the count, ignore 3-4) contains 228, this is the length of the data (224) PLUS the rdw itself (4), if you coded -
01 REC
02 RDW PIC X(4)
02 REDEFINES RDW
03 LRECL PIC 9(4)BINARY
03 FILLER PIC XX
02 DATA PIC X OCCURS 0 TO 999 DEPENDING ON LRECL
then you would actually read 232 bytes ie. 4 bytes into the next record - PROBLEM!!!. One (only?) solution is to use C byte-stream routines, these come with Microfocus (Merant?) COBOL and Fujitsu COBOL, possibly other vendors. Routines you need to CALL are CBL_OPEN_FILE, CBL_READ_FILE, CBL_CLOSE_FILE (lots of others too). Procedure is -
1. call CBL_OPEN_FILE, set read function to 'filesize'
3. call CBL_READ_FILE to get file size in bytes
3. set read function to 'i/o', set offset to 0,
4. call CBL_READ_FILE to read next 4 bytes, get lrecl
5. add 4 to offset and call CBL_READ_FILE read next (lrecl) bytes ie. the data
6. process data
7. add lrecl to offset and repeat from 4.
8. End-of-file is when the offset reaches the file size, then call CBL_CLOSE_FILE.
Sounds fiddly but actually works well. Hope this helps.
Alternatively knock up a routine in C yourself, not too difficult.

 

[bmunicorn]

HI - had this problem years ago, when we were transfering data from the mainframe to a Unix box. We now run Merant(MicroFocus) cobol on an AIX RS/6000. When we did it, there was no automated tool, so we had to write a program on the mainframe side to unpack the packed decimal, however we were able to leave the variable length records alone and that worked fine. The company SYNCSORT now has a bunch of utility programs they have created to automate the transfer process better. I would also recommend using their sorting package on the UNIX box. It sped up the sorts by 3X. Good luck on your conversion. [sig][/sig]