Intermittently printing data to a mainframe COBOL report

[atlcarroll]

I am having a problem printing to an extract where a field does not always print. I can not reproduce the problem when using a small sampling of data for the input file such as 200 records. But the production job inputs up to 3 million records. Sometimes it prints a field properly, sometimes not. I should mention that this is a COBOL/DB2 program. It prints correctly in Expeditor, the debugging tool that we use. When using displays, the field is populated just before the write, then it doesn't show up on the report. It seems to sporadically drop one field. I used region=0m on the EXEC proc to no avail.

 

[Glenn9999]

How do you have your print file and records defined (in JCL as well as your COBOL)? Where is this "intermittently printing field in the record"? How are you populating and writing these print records (i.e. MOVE to PRINT-BUUFER & WRITE, VERSUS WRITE FROM MEMORY LOCATION)?

 

[slade]

You may also want to look for a "runaway" indes/subscrpt that may be overlaying parts of memory w/spaces or unprintables/

Regards, Jack.

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

 

[Glenn9999]

Another thought I had in reading this: Perhaps your small sample doesn't have the kind of record data in it that is causing your problem? If you can get a sample of the print run, try to isolate the records you are attempting to print and then locate a record or two in the 3 million and then isolate those and use them in your 200 record test set.

It's amazing how mangled the data can get if you don't even realize it can be done. I've had a couple of 3am callouts on my programs for that exact reason.

 

[WMK]

Another thought that I had was that you are not (correctly( initializing some field to spaces (before printing).

I know that I have seen intermitent (sp?) problems when "binary zeroes" or some other "garbage from a previous record" remains in a field before printing. Sometimes it works (logic fills full field) and sometimes garbage remains - leading to "odd" print results.

This specific case does NOT sound like this is likely - but if all other suggestions fail, you might want to check this out.

Bill Klein