Remove trailing blanks from all records from a flat file.

Sunita.Raman · New User Joined: 03 Mar 2011 Posts: 3 Location: USA

Hello.

I am using a file in OUTPUT mode in my COBOL program.

The File Control for this file looks like
SELECT MAIL01-FILE ASSIGN TO MAIL01
ORGANIZATION IS SEQUENTIAL
ACCESS MODE IS SEQUENTIAL.

And the FD section is been defined as
FD MAIL01-FILE
LABEL RECORDS ARE STANDARD
RECORDING MODE IS V
RECORD IS VARYING IN SIZE.
01 MAIL01-REC PIC X(76).

The JCL is referring the file as
//MAIL01 DD DSN=H2503PS.G.COIEDI.RECVX12.MAIL01&GDG1,
// DISP=(NEW,CATLG,CATLG),
// SPACE=(TRK,(95,95),RLSE),
// MGMTCLAS=D100M,
// DCB=(RECFM=V,LRECL=80,BLKSIZE=0)

As the program is executed, and I open the file in edit mode, I get the message as -
"Truncation warning. The data you are editing is variable length data with at least one record that ends with a blank. Saving the data will result in
removal of any trailing blanks from all records. You can issue the PRESERVE ON command if you don't want the blanks removed.
"
I am sending this file further for processing to a unix server. When in edit mode in this file, if I save and come out of the file(which removes the trailing blanks), my further processing in unix goes good. If I use PRESERVE ON on this file, my further processing on UNIX gets rejected as the file has lot of unnecessary spaces.

I am thinking that this could be something related to the way the file has been defined. Any suggestions as to how this can be rectified ?

Thanks for your help.

dick scherrer · Posted: Fri Mar 04, 2011 12:16 am

Hello and welcome to the forum,

Look at and change the code that creates this variable length file making sure that the records written have no trailing spaces. . . Then there should be no need to edit the file before downloading.

superk · Posted: Fri Mar 04, 2011 12:18 am

I'm not a COBOL expert, but doesn't the PIC X(76) mean that all of the records are 76-characters in length.

Robert Sample · Posted: Fri Mar 04, 2011 12:22 am

If you have only the one 01 level under the FD (MAIL01-REC), then every record your COBOL program writes out will be 76 bytes long, with trailing spaces if needed.

You can either add more 01 levels with the different length records, or work with OCCURS DEPENDING ON in the 01 under the FD (and use the RECORD VARYING DEPENDING ON variable to set the actual length before writing records)

Merely telling COBOL that a file has variable length records will not, by itself, make the record lengths vary -- you must write the varying length records yourself as part of the process.

dick scherrer · Posted: Fri Mar 04, 2011 12:23 am

Hi Kevin,

Yup, the data portion will be 76 with an unneeded 4-bytes on the front for the RDW.

I should have also posted that the file description will create truly variable length records if the MAIL01-REC contains an Occurs Depending On that determines the number of bytes befor the trailing blanks.

Bill O'Boyle · Posted: Fri Mar 04, 2011 12:28 am

This is a variable-length file and needs to handled as such -

www.ibmmainframes.com/viewtopic.php?p=250794&highlight=#250794

In the above link, field "WS-DR-LEN" must be defined as an unsigned WS field, preferably as PIC 9(08) COMP.

Before you issue a "WRITE", populate this WS field with the desired length.

On a "READ", it will automatically be set to the actual length of the variable-length record just read.

Bill

don.leahy · Posted: Fri Mar 04, 2011 12:50 am

A really easy way to handle this situation, albeit by adding a step, is to create the file as FB in your Cobol program and then use DFSORT to convert it to VB. SORT will take care of dropping the trailing spaces, if that's what you want it to do.

dick scherrer · Posted: Fri Mar 04, 2011 3:56 am

Unless the file has a few hundred million records

superk · Posted: Fri Mar 04, 2011 6:04 am

Another thing I hate about Unix. You'd think that, if really mattered about trailing blanks, it would automatically drop them, like Windows does.

dick scherrer · Posted: Fri Mar 04, 2011 10:11 am

Hello,

I suspect there is more to this than has been posted. . .

Which error(s) are raised on the Unix system? Which Unix is being used?

I recall moving lots of "stuff" from a mainframe to both HP-UX and AIX that had some number of trailing blanks with no problems. Things like program source, control lib info, etc. What i don't remember 15 years later is if we had the ftp eliminate the spaces or let them pass. . .

One of the things that DID cause problems was data that was "below spaces" in ascii (values below x'20') because these are where control characters live. If anyone downloaded packed or computational data or if the data contained "bit switches" strange things could happen.

It may help if you post the ftp control statements used and show which defaults are set on your system. The informatoinal output from 2 ftp runs might also help.

Sunita.Raman · New User Joined: 03 Mar 2011 Posts: 3 Location: USA

Hello.

I made the necessary changes to the COBOL program. First changed the FD section to include the DEPENDING ON Clause. Took care of the length parameter while writing to the output file.

The output file now contained actual variable length record. Now when I open the file in EDIT mode, I no longer get any messages on trailing blanks. Meaning, there is not need for me to even glance at the file before FTP'ing it to mainframe.

File when sent to UNIX was processed successfully.

As far as FTP from mainframe is concerned, I am sending my file in binary format, and there is a process on UNIX which first converts it fromEBCDIC to ASCII. Its after ASCII conversion that the file is then fed into the ultimate process.

I truly appreciate each and every response that I got against the question I posted. Thank you all much for your responses.

Thank you,
Sunita.

Sunita.Raman · New User Joined: 03 Mar 2011 Posts: 3 Location: USA

Rectifying typos to avoid confusion.

"The output file now contained actual variable length record. Now when I open the file in EDIT mode, I no longer get any messages on trailing blanks. Meaning, there is not need for me to even glance at the file before FTP'ing it to unix."

Thanks once again for your inputs that helped me get thru this.

dick scherrer · Posted: Fri Mar 04, 2011 10:27 pm

Good to hear it is working - thank you for letting us know

d