Combining printer files from multiple programs in one spool file in a job.

810 pts.
Tags:
AS/400 Printer File
AS/400 printing
AS/400 Spool Files
iSeries printing
PRTF
We run one job with several checks at night. All these program use the same PRTF, but each results in a separate spool file. Is it possible to have the output from all these programs in one spool file? I.e. pgm1 has printed output and I want pgm2, pgm3, in the same job to add to it.

Software/Hardware used:
iSeris v5r4

Answer Wiki

Thanks. We'll let you know when a new response is added.

You may want to try this. Create a flat file for 133 or 199 (length of print file and 1 extra char for control char in pos 1). Run CPYSPLF with the control char of “*FCFC” to flat file using “*ADD” option for each report. After the last one is copied, use OVRPRTF for check print file with “*FCFC” and CPYF the flat file using same check print file.

Discuss This Question: 14  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • djac
    Just wondering if OVRPRTF FILE(file) SCHEDULE(*JOBEND) might have the desired result? Possibly with the DFRWRT(*YES) parameter?
    900 pointsBadges:
    report
  • TomLiotta
    If Pgm A calls Pgm B and then calls Pgm C, and Pgm B & C print through the same printer file, then review this command:
    ovrprtf     MyPrtF  +
                  ovrscope( *ACTGRPDFN ) +
                  share( *YES )          +
                  opnscope( *ACTGRPDFN )
    The OVRPRTF command can be run in Pgm A before it calls Pgm B. The override should stay in place until after Pgm C finishes. Then Pgm A can run this command:
    dltovr      MyPrtF  lvl( *ACTGRPDFN )
    I suspect that you will want to use *JOB in place of *ACTGRPDFN even though this should all be done within an activation group. If this is a single batch job, it doesn't matter much; but it might become a piece of a larger job someday. Tom
    125,585 pointsBadges:
    report
  • PGMBOB
    Good Tom, I've used SHARE(*yes) but with 2 programs, Worked great!
    1,040 pointsBadges:
    report
  • r.otto
    In the CL I call PgmA then PgmB then PgmC, etc. They all open and close the same printer file. I tried:
    ovrprtf     MyPrtF  +
                  ovrscope( *JOB ) +
                  share( *YES )          +
                  opnscope( *JOB )
    but that did not do the trick.
    810 pointsBadges:
    report
  • Teandy
    Make sure you do not have a DLTOVR command prior to programs B and C. Also make sure that there is no previous OVRPRTF with SECURE(*YES) prior to running program A. 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.
    5,860 pointsBadges:
    report
  • TomLiotta
    In the CL I call PgmA then PgmB then PgmC, etc.... 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
    125,585 pointsBadges:
    report
  • pdraebel
    The trick is to have the different programs call one program that stays open and does all the printer output.
    2,635 pointsBadges:
    report
  • pdraebel
    And do not close printer files ! That will cause different spools being created.
    2,635 pointsBadges:
    report
  • TomLiotta
    The trick is to have the different programs call one program that stays open and does all the printer output. 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
    125,585 pointsBadges:
    report
  • r.otto
    The job is submitted and it looks klike this: some checks
    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.
    810 pointsBadges:
    report
  • TomLiotta
    Assuming that LRS465B and the others are written in RPG, can you show us the F-specs for the LRS460O file in at least two of those programs? 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
    125,585 pointsBadges:
    report
  • r.otto
    They are all COBOL pgms and are exactly the same for the printer file part: Most lines printed are composed in the COBOL pgm and moved to a 132 character field in the PRTF.
    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.
    
    810 pointsBadges:
    report
  • TomLiotta
    They are all COBOL pgms... 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
    125,585 pointsBadges:
    report
  • r.otto
    [...] Combining printer files from multiple programs in one spool file in a job [...]
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following