How does a JCL link the PRTOUTA, ...etc... to a Cobol program?

Question

I am working on a program that writes information to a output file and also to PRTOUTA, PRTOUTB, PRTOUTC with a PRTRTENO program. You have to move variables to a PRINT-AREA and so forth.

I am sure that it has to do with PRTRTENO but I am not completely certain

Cobol:

 PRINT-B.                              
    DISPLAY 'PRINT-B SECTION'         
    MOVE 'B' TO RPT.                  
    CALL 'PRTRTENO' USING PRINT-AREA. 
 PRINT-B-X. EXIT.                      

Cobol Call:

 MOVE TEST-LINE TO PRINT-AREA. PERFORM PRINT-B.   

More Cobol:

PAGE-TOPA.                           
    MOVE 'P' TO CTL.                 
PRINT-A.                             
    MOVE 'A' TO RPT.    <-- Is it here that determines the JCL printout.             
    CALL 'PRTRTENO' USING PRINT-AREA.
    IF CTL = '*'                     
       PERFORM HEAD-A THRU HEAD-A-X  
    END-IF.                          
HEAD-A.                              
  ...etc... //code here
HEAD-A-X.

JCL:

//OUTPUT1   DD  DSN=Test-File-Name-Goes-Here,DISP=(,CATLG),         
//          DCB=TS20.FB0080.MODEL,MGMTCLAS=TDML1   --EMAIL     
//PRTOUTA   DD  SYSOUT=1,DCB=TS20.FBM0133.MODEL    --EOS       
//PRTOUTB   DD  SYSOUT=1,DCB=TS20.FBM0133.MODEL    --LABELS    
//PRTOUTC   DD  SYSOUT=1,DCB=TS20.FBM0133.MODEL    --NO EMAIL  

Answer 1

Files are made known to your COBOL program through the FILE-CONTROL paragraph in the ENVIRONMENT DIVISION of a program. The FILE-CONTROL paragraph looks something like:

 FILE-CONTROL.
     SELECT PRT-FILE       <-- Name in FD SECTION
     ASSIGN TO PRTOUTA     <-- JCL DD Name
     ...

Then in the DATA DIVISION you use an FD to associate a record buffer to the SELECTed file from FILE-CONTROL. When you READ/WRITE to the associated buffer a record is transferred from your program to the named file. FD's will begin with:

 FD PRT-FILE  <-- same as SELECT from FILE-CONTROL
 ...

Beyond that things can get a little complicated because your program is not writing to these files directly, but through a called program ('PRTRTENO'). The above file definitions may appear in your program or in the called program. In either event they are probably declared as EXTERNAL making them available anywhere in your run-unit.

I'm betting that you will find them as EXTERNAL in the called program. So to answer your question, you need to look for the FILE-CONTROL paragraph and FD in your program. If they do not relate to the JCL DD Names, then look in the called program - they must be there.

Answer 2

I would not expect you to have SELECT/ASSIGN/FD for the DDNAMES in your program. One reason for having the sub-program is to avoid 1,000 report programs with 1,000 identical (or near-identical) SELECT/ASSIGN/FD, and all the IO and checking, and page-sizes etc which goes with it.

They will be in the CALLed program, or a program it CALLs in turn. Along the way, the DDNAMES are most likely being allocated "dynamically", or at least a program enquires for the presence of a DDNAME in the JCL and will only use the DDNAME if present (obviously difficult to know without access to the code).

I'd think it likely that the actual IO is done in Assembler sub-routines. It is possible to do it in COBOL, but it will depend on the age of the original program.

You have a locally-written program, PRTRTENO. This program is CALLed by your program. PRTRTENO supports, either directly or through CALLing other programs, different types of "report" output with different characteristics.

Report-producing programs tend to have a lot of duplicated code (dealing with headings, new pages, for standard listing reports, labels, letters, etc) which can over-complicate (through size of source), contain subtle differences, require changes to many programs to provide general maintenance, etc.

By using a sub-program, like PRTRTENO, some of these issues can be addressed. Standard company-wide headings, footings and end-of-reports, output-routing information, special stationery (and non-stationery, like your e-mail) etc can be centralised in one program, providing numerous benefits.

Where the sub-program can deal with multiple outputs at the same time, a parameter is required to indicate which print lines belong to which logical report. This is the A, B, C setting in your output, and the sub-program (or something it uses) will map your output, using this, to the DDNAMEs in the JCL.

If you ask colleagues, you should be able to look at the source for PRTRTENO and see what it gets up to, and how it does it. It, or its components, will be quite a large program, and your program otherwise would have to contain code similar to PRTRTENO to do the print output.

Some sites do it that way, some not. At other sites you'll have all the OPEN/WRITE/CLOSE, counting lines, getting the headings in the correct place, etc, coded in each program.