IBM Mainframe Forum

Problem (short):

Need to convert x'25' to x'15' in batch on an HFS (linux) file

Problem & what I've tried:

We have an xml file that is in the HFS / linux partition. The xml file was created with only linefeed's (LF). When I use OEDIT or OBROWSE, I can see LF is a hex 25. The problem is that every record has been put into onto one line. This doesn't work well in a batch cobol program. I need to do a global change of x'25' to x'15' to appease cobol. From linux, I've tried SED & TR commands. They all worked great on every character in the file EXCEPT the x'25'. I've tried executing IKJEFT01 and calling EDIT on the HFS file, but EDIT doesn't support HFS. I tried executing IKJEFT01 and calling OEDIT on the HFS file, but OEDIT utilized ISPF and will not work in batch. I was able to get FileManger via ISPF panels to do the global changes, but I cannot seem to get the batch FILEMGR to work. It responds with FMNBA317 Invalid input data set for function DSU(unsupported DSORG). The file is a variable length file (generated from another unix machine). The command I used in File Manager (ISPF) that worked was C ALL X'25' X'15'

I've tried DSEB & DSU in file manager batch & get the same FMNBA317 error message of unsupported DSORG

Anyone have any ideas of how to change the x'25' to x'15' in JCL? I'm open to any solution really. I just figured that if file manager can do it via ispf screens it should be able to do it via batch.

in OBROWSE, this is what my test file in hex looks like (for simplicity, erased all but two letters and the x'25'):



TIA!

Are you sure that your solution fixes the problem? How have you defined the file in your Cobol program? Lots of people are transferring files in that direction without having to do this change.

I assume the file itself is all "display" fields? No COMPutational fields in Cobol terms?

A way to make the change is with your Sort product, check in you documentation for the availability of FINDREP (find and replace). You can do X'26' for the IN and X'15' for the OUT.

Yes, it's all display fields. It's an XML file that has only LF's in it. When we FTP'd the file down from their site, it only shows one record -- a very LONG record.

I did find a work around. I used the "extattr -FLF filename.xml" in unix system services. Now when I copy the file from USS to MVS, the LF's are interpreted correctly. Just thought it was weird on how it was acting.

OK. Also have a good look at documentation on FTP. Give it a good google as well, I think I've seen similar topics out there.

Personally, I think you should address the issue with FTP since FTP can translate line termination characters from LF to CR/LF to record delimiters on a mainframe, but you could try File Manager batch:although I have not tested this since I don't have any files with the characteristics you described.

I saw that there was a MBSENDEOL and SBSENDEOL command, but I think that only works on PUT commands. I'm issuing GET commands. If you know of a way, I'd rather perform through a locsite command or some other FTP conversion.

As for using File Manager, Here's my results..

DSC (I had to modify the pathopts so that the system would create the file for me)



Results:



DSU (my attempt)



Results

If you're doing a GET, then should be acceptable. SITE is for the remote host, LOCSITE for the local host.

Robert,

The way the manual was worded, it led me to believe that it only worked on PUTting a file. Regardless of what I thought, I still tried it. I used the following commands when FTP'ing into the vendor's FTP server. Didn't change it. But on a positive note, I did get the TR command to work while researching the SBSENDEOL command. This describes my problem to a "T". The guy posting's terminology is wrong, but this is what I'm getting as well.

http://www.mail-archive.com/ibm-main@bama.ua.edu/msg78550.html

Have you tried transferring as binary and using ICONV in Unix System Services?