Emails randomly delete first 1 1/2 pages of report

[J9CMOD]

I have gone through all the manuals, and tried many things, and can't find a solution.
We are on CMOD 9.5, using ODF for distribution. 
When we want to email a report we send it to the JES output queue (with location PRINT and DEST JES2MAIL).
When the output is sent to our customer, the 1st 1 1/2 pages of the document are missing from the output.  (We never had this problem with the previous product we used that also sent the output to JES2MAIL.)
The CMOD monitor shows the correct number of pages for the report, and when I use the monitor to re-distribute it always works correctly.
This appears to only happen during our nightly cycle, when a large number of reports are being distributed.  I have not seen it happen in our mid-day cycle, which is much smaller in regards to emails, and it doesn't happen in our development system, which is set up the same as our Prod system.
Any help would be greatly appreciated.  I need to find a solution before we roll out the rest of our reports.  Currently, with a portion of our reports rolled out for distribution, I have to manually re-distribute several reports every day.
Thanks!

[Ed_Arnold]

The only thing I can guess that might somehow be in play is if you have the output limit parm set, but I realize that's doubtful

Output Limit

    Unlimited
        If you select Unlimited, then the system level maximums will be used.
    Maximum Lines
        Specify a maximum number of lines to output. The maximum number of lines can be up to 16777215.

Sounds like a PMR is in order.

Do you use the "-v" parm on your ODF started task?  It's very helpful when sending in the started task log to support, let's them know exactly what parms are in use.

XXARSODF   EXEC PGM=ARSRMAIN,REGION=0M,
XX   PARM=('-h ARCH950 -u odadmin -p foo -S -v')

Ed

[J9CMOD]

Thanks.  We do have a limit on the output, and the strange part is that is appears to be "all there" when I look at the monitor (correct number of pages), and if I re-distribute it from the monitor, they get the entire report.

[Ed_Arnold]

CMOD 9.5 has had quite a few PTFs come out recently, some for defects, some for rolling out new function.

The newest PTF as of this writing is UI40019.

What's the newest CMOD PTF you have on your system?


//STEP010 EXEC PGM=GIMSMP                 
//SMPCSI   DD DISP=OLD,DSN=YOUR.CMOD.CSI
//SMP.SMPCNTL  DD DATA                     
  SET BOUNDARY(TZONE).                     
   LIST SYSMODS FORFMID(H272950).         
/*                                         

Ed

[J9CMOD]

Thanks Ed.  I went through a lot of output, and the exit program and found that the exit program wasn't clearing out working storage.  So, if the banner page for the one with the missing pages was not a full page (66 lines in our case), and the previous distribution before the one in error had commands at the end of it's banners, they were being carried over to the banner pages of the next distribution.
This is being looked at by some people at IBM.  In the meantime, I just changed all my banner pages to have enough blank lines to take up a full page.

[scottnys]

J9CMOD , Sorry to hear your woos, I truly feel for you.

Ed, This sounds like something that should be fixed in the APAR the developers are working on for NYS.  I'm sure we would be hit by this same Uninitialized Working Storage issue as well.  Can't just test 1 single call - Multiple calls is the real world.   

Scott.

[Ed_Arnold]

J9CMOD , Sorry to hear your woos, I truly feel for you.

Ed, This sounds like something that should be fixed in the APAR the developers are working on for NYS.  I'm sure we would be hit by this same Uninitialized Working Storage issue as well.  Can't just test 1 single call - Multiple calls is the real world.   

Scott.

Exit issue.

Ed