New COBOL version truncating 1st column of report output

[davidncarter]

Migrating from "COBOL for MVS & VM" to "Enterprise COBOL for z/OS V3" Nothing changed in program, just recompiled.
Column 1 of report is truncated on output, how do I restore it?
Output report file defined:
SELECT FLR-VOTES-UPDT-RPT-FILE ASSIGN TO UT-S-UPDATE.
**************
FD FLR-VOTES-UPDT-RPT-FILE
**************
RECORD CONTAINS 133 CHARACTERS
RECORDING MODE F
RECORD IS FLR-VOTES-UPDT-REPORT.

FLR-VOTES-UPDT-REPORT.
FILLER PIC X(1).
FLR-VOTES-UPDT-PRINT-LINE PIC X(132).

Compiled with "NOADV" option, lines written to report with "AFTER" clause.

Output defined in JCL:
23 XXUPDATE DD SYSOUT=&OUT,DCB=BLKSIZE=134
IEFC653I SUBSTITUTION JCL - SYSOUT=*,DCB=BLKSIZE=134

Output from UPDATE dd using load module compiled with MVS & VM COBOL:
FILE> CONTROLM.PSIQ27CU.JOB02902
DATE: 12/10/2009 I N Q U I R
TIME: 16:02 COMMITTEE ACTIO
MEASURE ID ACTN DATE COMM. HRNG SEQ.
---------- --------- ----- ---- ----

Output from UPDATE dd using load module compiled with Enterprise COBOL:
FILE> CONTROLM.TSIQ27CU.JOB05223
ATE: 12/02/2009 I N Q U I R
IME: 21:47 COMMITTEE ACTION
MEASURE ID ACTN DATE COMM. HRNG SEQ.
---------- --------- ----- ---- ----

 

[papadba]

Why was NOADV chosen?

If the code uses ADVANCING, you want ADV i believe. . .

 

[webrabbit]

If you use ADVANCING, you must reserve the first byte for the control character. BEFORE ADVANCING forces DCB=FM, AFTER ADVANCING forces DCB=FA. If you use both, I don't know which prevails.

 

[papadba]

In either case (before/after), the first byte is needed for "printer control". . .

From the Enterprise COBOL Manuals:

ADV has meaning only if you use WRITE . . . ADVANCING in your source code. With ADV in effect, the compiler adds 1 byte to the record length to account for the printer control character. . .
.
Use NOADV if you already adjusted record length to include 1 byte for the printer control character.

Usage note: If you use the ADV compiler option, the compiler adds 1 byte to the record length in order to allow for the control character. If in your record definition you already reserve the first byte for the control character, you should use the NOADV option.

 

[webrabbit]

The NOADV option says you have reserved the first byte for the control character. As you have not, you want the compiler to add the byte, which requires the ADV option, as papadba suggests, or reserve the byte yourself.

 

[coboldeke]

You have reserved the first byte for carriage control. That's what the FILLER of 1 byte is for. If the code moves the filled out report line to the 01 entry (FLR-VOTES-UPDT-REPORT), then the first byte is in the FILLER and is used as a carriage control character.

You should move the filled out report line to the elementary field FLR-VOTES-UPDT-PRINT-LINE.

 

[davidncarter]

As noted, I have set aside the first byte for carriage control, and I move the output line to FLR-VOTES-UPDT-PRINT-LINE before "WRITING" FLR-VOTES-UPDT-REPORT. This is unchanged since the switch in compilers. The bottom line, it appears to me that something has changed between COBOL FOR MVS/VM and Enterprise COBOL, that is causing the first char to be lopped off. Any pointers to a source that lists the differences between the two compilers would be gratefully appreciated. And, if I'm being dense here, and missing something, please point it out. THANKS!

 

[coboldeke]

As far as I remember, when we converted to Enterprise COBOL, we did not have any changes for writing report lines. The code worked fine when recompiled. I'm guessing there has to be something unorthodox happening in the code when you try to get the line printed. In other words, a logic error.

 

[3gm]

As suggested, you should confirm the ADV/NOADV option is consistent between the compilers. IIRC, your system programmer can set defaults for the installation and they may very well be different from previous defaults. Confirm the options on the compile listing match between the old and new versions.

Regards,

Glenn

 

[MarcLodge]

David,
A couple of questions:
Have you changed the JCL at all?
Have you moved operating systems? (your Cobol version has gone from MVS for VM to OS3)

I think that your program is fine, but your JCL should specify DCB=(RECFM=FBA,LRECL=134,BLKSIZE=27872).

Marc

 

[papadba]

You might try changing:
//UPDATE DD SYSOUT=&OUT,DCB=BLKSIZE=134
to:
//UPDATE DD SYSOUT=* (or &OUT - shouldn't matter for a test)

None of the sysout= statements on the systems i currently support specify any dcb info at all . . . fwiw.

 

[TysonLPrice]

It's been about ten years since I've been on the mainframe so be gentle

Didn't the RECFM have to be FBA in the JCL?

 

[slade]

Hi David,

I've been viewing this thread on & off since the beginning. Unfortunately I have no answers for you, but I have a few ques if you haven't yet left the building;

1) I noticed your "before" run shows the 3rd line truncated. Typo?

2) Are you viewing the problem SYSOUT using the SDSF "S" line cmd?

3) Are you using cut & paste to display the code (both JCL & pgm)?

4) Could you also display the WRITE stmt?

Thanx and

Regards, Jack.

"A problem well stated is a problem half solved" -- Charles F. Kettering

 

[MarcLodge]

All,
I don't think it's worth replying to this thread any further as the poster appears to have not logged in since 14th December. The answer to this is, as stated in a number of posts above, is that his JCL is wrong. He needed to have FBA coded.

Marc

 

[davidncarter]

Thank you all for your input - I appreciate your efforts. I haven't logged in for a while, due to many fires that have needed to be exinguished in our shop, which took precedence over the issue I originally posted. I will post a reply once I've tried your solutions.

Thanks!
David