For COBOL, try these elements. Change your CL to work like this:

   ovrprtf     PRINT1  share( *YES ) opnscope( *ACTGRPDFN )

   call        PRINT1O  '*OPEN     '

   call        PRINT1A
   call        PRINT1B
   call        PRINT1C

   call        PRINT1O  '*CLOSE    '

   dltovr      PRINT1

I used different names for the series of COBOL programs to illustrate that the programs you call are all similar and use the same printer file. I added a new program to call before and after the usual sequence.

Here’s the new COBOL program:

       PROCESS APOST NOPRTCORR
       Identification Division.
       Program-ID.     PRINT1O.
       Environment Division.

       Configuration Section.
       Source-computer.    IBM-AS400.
       Object-computer.    IBM-AS400.

       Input-output Section.
       File-control.
           select  PRINT1      assign to   formatfile-PRINT1
                               organization sequential.

       Data Division.
       File Section.
       FD  PRINT1
           label records are omitted.
       01  FD-PRINT1-REC.
           copy dds-all-formats of PRINT1.

       Working-storage Section.

       Linkage Section.

       01  lk-Ctl                          pic x(10).

       Procedure Division using
                               lk-Ctl .
       0-MAIN Section.

       0-MAIN-LINE.

      * Open the files...
           evaluate lk-Ctl
               when '*OPEN'
                   open    output  PRINT1

               when '*CLOSE'
                   close   PRINT1

           end-evaluate.

      * Close down the program...
           goback.

In this example, the printer file is named PRINT1. For your job, the name would be LRS460O. The only purpose of this extra program is to add a hook into the opening and closing of the file. COBOL does things differently from RPG, so this helps connect the CL to the opening and closing of the file.

By opening the file and leaving it open, the subsequent programs can become connected to it. They can all use the same open data path rather than creating individual ones. The final close can happen after the other programs are done with it.

Then the override can be deleted.

Note that some adjustments might need to handle activation group details and possibly others.

Tom

SELECT LRS460O ASSIGN TO FORMATFILE-LRS460O-SI
               ORGANIZATION IS SEQUENTIAL.
...
FD  LRS460O.
 01 LRS460O-REC.
    COPY DDS-ALL-FORMATS-O OF LRS460O.
...
OPEN OUTPUT LRS460O.
...
MOVE CORRESPONDING REC-REPORT-BUFFER TO LRS460O1-O.
WRITE LRS460O-REC FORMAT IS "LRS460O1"
INDICATORS ARE INDICATOREN.
ACCEPT REC-PRT-FEEDBACK FROM IO-FEEDBACK FOR LRS460O.
... and some more (similar) writes
CLOSE LRS460O.

Also, be aware that each of those programs may have OVRPRTF or DLTOVR commands inside of them.

Does the job end up with six spooled files named LRS460O? Or is it a number other than six? (And I see that the last character in the name is the letter “O” and not the digit “0″.)

Tom

OVRPRTF    FILE(LRS460O) OUTQ(PDF)  +
                      OVRSCOPE(*JOB) +
                      SHARE(*YES) +
                      OPNSCOPE(*JOB)

next are some checks again (RTVDTAARA etc, but no DLTOVR nor a OVRPRTF)
then:

CALL       PGM(LRS465B) PARM(&PLPARM)
CALL       PGM(LRS466B) PARM(&PLPARM)
CALL       PGM(LRS461B) PARM(&PLPARM)
CALL       PGM(LRS462B) PARM(&PLPARM)
CALL       PGM(LRS463B) PARM(&PLPARM)
CALL       PGM(LRS464B) PARM(&PLPARM)

There is no DLTOVR for the printe rfile after that.

Although that can work, it’s not required. You can have multiple programs creating separate reports that result in a single spooled file. There is no need to call a single program to get it done.

But we need to see the controlling code (i.e., the CL that wraps around it all) to know possible reasons why it’s not working in this case.

Tom

In the CL, the code would look something like this:

ovrprtf     MyPrtF  +
              ovrscope( *JOB ) +
              share( *YES )          +
              opnscope( *JOB )
call  PgmA
call  PgmB
call  PgmC
dltovr      MyPrtF  lvl( *JOB )

If that’s not how your CL looks at that point, then show us what it looks like. For example, you can’t be using {SBMJOB CMD(call PgmA)} in place of just plain {call PgmA}. And if the printer file isn’t named MyPrtF in PgmA, PgmB and PgmC, then you have to use the actual printer file name instead of “MyPrtF”.

But if you can’t make the CL work, we need to see what it looks like.

Tom

This seems to be rather an awkward way to do this. Is there a reason that you can’t put the data from these three programs into a database file? Then you could either have a routine at the end of the third program print the data, or you could create a fourth program to do the printing.

It seems to me that this would lead to a cleaner and more maintainable job stream than what you are trying to do.