MVSFORUMS.com

[LaluMon]

Hello.

My COBOL program needs to take in a VBM file as input and write the output as FBM format. (Earlier the requirement was to write the output also in VBM format, and for which I had no problems in coding COBOL). For FBM format, I tried the normal SELECT statement coding and in FD section also. But my output FBM is not proper.

1) Is there anything special for coding SELECT and FD for FBM formats
2) Is there anything to be taken care while writing a FBM record from a VBM record (Basically I am copying the input VBM format to output FBM format on matching certain conditions).

Hope my question is not confusing.
Thanks.

[slade]

Hi,

Your 1st ques is easy. The answer is "no".

The 2nd, on the otherhand....

I'll assume you know NOTHING about the subject, so don't be offended, OK?

VBM means that the recs can be variable in length, they are blocked, and each rec has a printer control char as the 1st DATA byte of each rec. In addition each variable rec has a 4 byte field that tells the system how many data bytes are in each rec. Similarly each variable block has a 4byte field that tells the system the # of bytes in the block (the sum of all data, rec descriptors and the block descriptor).

When you read a record into your COBOL pgm only the DATA is presented to your pgm into the 01 level you provided. You don't account for the non-data portion of the rec in your pgm. However, you must account for the data and the non-data portions of the variable block in the LRECL and BLKSIZE of your JCL. If the variable I/P file is Cataloged, then that's not even a concern.

BTW, you should define the files in your JCL as VB and FB. Don't use the "M". The reason is you want your pgm to "see" the print cntl char and treat it a data. I'm not sure what will happen if you used the "M", but I know it's safer and simpler without it. Just make sure you account for it in both rec descriptions. When you run the pgm that will actually print the FB file, you'll want to define it as FBM.

I guess you're just going to assume the max variable length for the len of your FBM O/P and pad the recs w/spaces. If you're going to do that, be sure to init the I/P rec w/spaces before each read. Then just READ VBM-FILE; WRITE FBM-REC FROM VBM-REC until I/P EOF.

Re. your problem defining an FBM file, you'll have to be more specific than "not proper".

HTH, Jack.

[LaluMon]

Thanks slade! Yes, I am new to VBM and FBM types..

But I for VBM output, I coded vbm in the jcl and it worked perfectly fine.
Only for FBM, I needed the coding syntax. Sorry if it is stupid question..But in your note, you mentioned to 'init the input rec wth spaces before read VBM..' I am confused ...are you saying that I move the input rec to a working storage max length variable so that it gets padded with spaces ....and then read the VBM file....If this is not what you meant, could you please elaborate as to what could be 'init the input rec'?

Thanks!

[slade]

Hi Mon,

When you read variable I/P recs into the FD rec description, the next rec you read may be shorter than its previous counterpart. When this happens part of the previous rec will be appended to the end of the shorter current rec when you move it to the O/P rec. To avoid that you'd want to clear the I/P FD rec before the next read.

When you think you've got the thing working, dump some I/P and O/P recs to make sure you've got the cntl chars right. Remember that they are hex chars, like X'03', etc. so they won't show as printable chars.


The FBM DD stmt should look something like this:

[slade]

Oops, the DISP should read:

DISP=(,CATLG,DELETE),

I forgot the "," before CATLG

[slade]

Oops2, when you read the variable I/P recs use READ VBM-FILE INTO
WS-VBM-REC. I say this because reading into the FD rec and then initing it, may destroy some of the data you haven't access yet. To be on the safe side read the VBM data into a Working Storage rec and init that.

[slade]

Where are you, LaluMon? Did you find an answer on your own? Did you not like the answers you got? Don't just "disappear". I hate when that happens.

What's the story?

Jack.

[LaluMon]

Slade,

I haven't had a chance to comeback and make changes to my program and test your solution. Really Apologize for not responding earlier. I just got stuck with other issues, since I am a lonely foot soldier battling out here. I will get some breathing space after June 23 and I plan to comeback and test your solution. Didnot mean to be rude or to disappear without responding. I didnot forget this either. I will surely revert with my results.

Regards!

[chandhroo]

Jack,
Could you please explain me why do we need to give one byte extra in LRECL over application program record length for FB. I know that for report generation we will be giving LRECL=133 and 01 level for record length in the program is 132.

Thanks
Chandru

[kolusu]

Chandroo,
The extra byte is due to compiler option ADV.This is the default compiler option set by IBM.With ADV in effect, the compiler adds 1 byte to the record length to account for the printer control character. ADV has meaning only if you use WRITE . . . ADVANCING in your source code. Some shops change it to NOADV.you can use NOADV if you have already adjusted your record length to include 1 byte for the printer control character.

Hope this helps...

cheers

kolusu

[slade]

Hi Chandru,

Sorry I couldn't reply in a timely manner. I was away from the net for the day. But I see you were in good hands.

Regards, Jack.

[chandhroo]

Kolusu and Jack,
So, we need to add one extra byte for printer character only when we code WRITE statement with ADVANCING option.

Thanks
Chandru

[kolusu]

chandroo,

As I said earlier, some shops have ADV as the default compiler option , so in that case , even without write...advancing , the compiler adds an extra byte to the record length to account for the printer control character. so in this case if you allocate only 132 bytes as per your file definition in the program , your program will abend with the message:

A file attribute mismatch was detected. File REPORT in program MYPGM had a record length of 133 and the file specified in the ASSIGN clause had a record length of 132.

Check the sysout of your program compile and see what options are used.If your site has defualted to ADV option , you can override it using the following statement as the first line in your program (before ID division)

CBL NOADV

Hope this helps...

cheers

kolusu

[slade]

Hi Chandru,

To summerize:

When using the ADVANCING phrase the compiler generates code to move the appropriate ANSI char into the 1st byte of the print rec. If ADV is specified the compiler prepends (to coin a phrase) 1 byte to the print rec you defined in the pgm (you can't reference it explicitly in your pgm.) So, if you defined 132 bytes, the compiler adds 1 the result is 133. That must be defined in the JCL.

If you don't use the ADVANCING phrase, DON'T use ADV (use NOADV), then provide for the cntl char as the 1st char in your definition of the print line in your pgm and MOVE the appropriate cntl char value to the 1st position of your print rec before WRITEing it. In this case the JCL LRECL equals the length you specified for the COBOL print rec.

I think I got it all, except for machine chars, but that's another topic.

Regards, Jack.

[chandhroo]

Kolusu and Jack,
Thanks a million for your response. I understood the concept behind ADVANCING.

Regards
Chandru