1 / 39

External Linkage

COBOL External Linkage. A COBOL program can call (transfer control to) an external subroutine; i.e., one that has been separately compiled or assembled.Called program may be written in COBOL, ASM, PL/1.Use a particular protocol similar to the procedure you learned in ASM.. COBOL External Linkage.

nadine
Télécharger la présentation

External Linkage

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. External Linkage

    2. COBOL External Linkage A COBOL program can call (transfer control to) an external subroutine; i.e., one that has been separately compiled or assembled. Called program may be written in COBOL, ASM, PL/1. Use a particular protocol similar to the procedure you learned in ASM.

    3. COBOL External Linkage Reasons for keeping programs separate: A number of different programs in a shop may need the same routine. Why code it over and over? Write it once, let all use it. Some languages perform certain functions more appropriately (efficiently) than others. In COBOL, all data values are global. Can lead to inadvertent access and changing of variables. Thus, use external routines and only pass the values that the routine has business with.

    4. Calling Program Callers WORKING-STORAGE SECTION: Input FDs, or linkage section, define those data items that are to be shared Items in linkage section would be received things, but then passed on to another program.

    5. Calling Program WORKING-STORAGE. 01 SOMESTUFF. 02 STUFF1 PIC X. Storage allocated for shared items in 02 STUFF2 PIC X(5). the callers program, not in called 02 STUFF3 PIC 99. program. 8 bytes of data plus a 5 77 NUMBER PIC 9(5) digit number to be passed.

    6. Calling Program Note that the passed parms must be 01 or 77 level items. SOMESTUFF and NUMBER refer to the 2 parms being passed. Note position, order! It is the addresses of SOMESTUFF and NUMBER that are passed. COBOL automatically sets hi-order bit of last parm to 1, enabling the passing of variable length parm lists.

    7. Calling Program Callers PROCEDURE DIVISION: PROCEDURE DIVISION. . . . CALL SUBRTN USING SOMESTUFF . . . NUMBER. STOP RUN.

    8. Calling Program CALL [literal identifier] [USING identifier list] [ON OVERFLOW imperative statement] SUBRTN, enclosed in single quotes, is the pgm-id or csect name of the program to be called. ON OVERFLOW gets control if the called pgm cannot be loaded dynamically during execution. Thus, only used for dynamic calls.

    9. Called Program PROGRAM-ID. SUBRTN. DATA DIVISION. FDs. If subrtn does its own I/O W-S. For subrtns local necessary variables.

    10. Called Program And now a new section in the Data Division, the LINKAGE SECTION. It describes the parms being passed to it. Description is like a DSECT. No storage for these data items is actually reserved here.

    11. Called Program LINKAGE SECTION. 77 NUMBER PIC9(5). May use same names or different ones. 01 MORESTUFF. 02 MORE1 PIC X(6). 8 bytes worth of data. 02 MORE2 PIC XX.

    12. Called Program PIC clauses may differ (cf. going from 99 to XX with MORE2), but the byte length must be the same. Note that MORE1 refers to both SOMESTUFF1 and 2. Thats OK. MORE1 could be defined as PIC X OCCURS 6 TIMES.

    13. Called Program PIC clauses here depend on the processing needs of this program. Order of parm definition here does not matter. Note how I put NUMBER first.

    14. Called Program Name the data items available to both programs on the PROCEDURE DIVISION statement: PROCEDURE DIVISION USING MORESTUFF NUMBER. Here the parms are positional; i.e., must be in same order as calling statement. Putting it together in the PROCEDURE DIV...

    15. Called Program PROCEDURE DIVISION USING MORESTUFF NUMBER. . . . do things with morestuff and number. References to shared items here use the names defined in its linkage section, but these references are actually references to the data items described in callers pgmjust like using a DSECT. . . . GOBACK. Returns control to caller.

    16. Called Program Alternative entry points can be defined using the ENTRY statement. ENTRY ALTPOINT USING ----- -----.

    17. Miscellaneous Notes OK: A calls B; B calls C; C calls D. Not OK: A calls B; B calls C; C calls A. A calls B. B can now: Transfer control back to A using GOBACK or EXIT PROGRAM. Call another pgm using CALL--- USING End the run unit with STOP RUN.

    18. Static Calls Main program and sub programs are link edited together as part of the same load module. Thus, the subroutines are already in memory when theyre called. Subsequent calls to a previously called sub program find that sub program in its last used state.

    19. Static Calls Thus, alteration of any local storage must be re-initialized. May use more storage than dynamic calls (be cause you cannot Cancel a program), but calls are executed more quickly.

    20. Dynamic Calls Sub programs are not link edited with the main program, but are link edited into their own load modules. They get loaded into memory when theyre called.

    21. Dynamic Calls 1st call finds a fresh copy, and Subsequent calls find the last used copy. Unless the main pgm issues a CANCEL pgm-id. This rids memory of the sub program. The next call to it will then bring in a fresh copy.

    22. Dynamic Calls Used, eg.,. if a program may call anywhere from 5 to 50 sub programs depending on processing needs. Why bring in all 50 if today pgm only needs to call 5? Instead, bring in only whats needed.

    23. Dynamic Calls Specify DYNAM,RESIDENT as compiler parms. Then you can use either CALL literal or CALL identifier. When DYNAM is in effect, call literal and call identifier are dynamic. When NODYNAM is in effect, call literal is static. Call identifier is always dynamic even if NODYNAM is in effect.

    24. Receiving Parms from the Exec Card Main program can be considered a called sub program from perspective of O.S. Main can therefore receive parms passed from the EXEC card that invokes the program. Must therefore have a linkage section as follows...

    25. Receiving Parms from the Exec Card //STEP3 EXEC PGM=MAINPGM,PARM=THIS,THAT enclosing quotes not passed, comma is passed. LINKAGE SECTION. 01 PARMS-IN. 02 LENGTH-IN PIC S9(4) COMP SYNC. 2-byte length field has number of characters in parm string. 02 1ST-PARM PICX(4). 02 FILLER PIC X. For the comma. 02 2ND-PARM PIC X(4)

    26. Receiving Parms from the Exec Card The programmer must therefore know the format of the parms being passed in so can code the linkage template correctly. Or, check length field... If only 4 bytes, only 1st parm passed in. or

    27. Receiving Parms from the Exec Card 01 PARMS-IN. 02 LENGTH-IN PIC 9(4) COMP SYNC. 02 FIELD PIC X(100) 100 being max length Then pick up the length and parse the field.

    28. COBOL Calling Assembler If do ASM expansion on source code, will show COBOL building a parm list of addresses in memory and pointing R1 to it. When ASM sub program is given control, do standard linkage and retrieval of parms (just as if another ASM CSECT had called it).

    29. COBOL Calling Assembler COBOL even sets hi-order bit of last parm address to zero so can use variable length parm lists and detect last one. DC A(PARM1) DC A(PARM2) DC X80,AL3(LASTPARM) Get in a loop picking off parms, doing a TM on first bit for a zero.

    30. Separate Compilation of COBOL/ASM Programs Putting it all together...

    31. //S1 EXEC COMPILER //SYSIN DD * main COBOL pgm //SYSLIN DD DSN=&&OBJMOD,DISP=(NEW,PASS) //S2 EXEC COMPILER/ASSEMBLER //SYSIN DD * asm or COBOL subprogram //SYSLIN DD DSN=&&OBJMOD,DISP=(MOD,PASS) //S3 EXEC COMPILER/ASSEMBLER //SYSIN DD * asm or COBOL subprogram /SYSLIN DD DSN=&&OBJMOD,DISP=(MOD,PASS) //S4 EXEC LINK EDITOR,PARM=MAP/02-22-97,C //SYSLIN DD DSN=&&OBJMOD,DISP=(OLD,DELETE) //SYSLMOD DD DSN=---------- //S5 EXEC PGM=X

    32. Separate Compilation of COBOL/ASM Programs If using the Loader: EXEC PGM=LOADER,PARM=MAP/GOPARMS or EXEC PGM=LOADER,PARM=(EP=PGMID,MAP/GOPARMS) Alternately.. //SYSLIN DD DSN=&&OBJ1,DISP=(NEW,PASS) //SYSLIN DD DSN=&&OBJ2,DISP=(NEW,PASS) //SYSLIN DD DSN=&&OBJ3,DISP=(NEW,PASS)

    33. Separate Compilation of COBOL/ASM Programs Then, SYSLIN to Link Editor: //SYSLIN DD DSN=&&OBJ1,DISP=(OLD,DELETE) DD DSN=&&OBJ2,DISP=(OLD,DELETE) DD DSN=&&OBJ3,DISP=(OLD,DELETE) DD * ENTRY PGM-ID1 /*

    34. Static Call Putting it all together...

    35. Main routine. Subroutine. WORKING-STORAGE SECTION. PROG-ID SUBRTN. 01 FLAG PIC X. . . . 01 RECORDA. DATA DIVISION. 02 SALARY PIC S9(5)V99. LINKAGE SECTION. 02 RATE PIC S9V99. 01 PAYREC. 02 HRS PIC S99V99. 02 HR-RATE PIC S9V99. . . . 02 PAY PICS9(5)V99. PROCEDURE DIVISION. 02 HOURS PIC S99V99. . . . 77 CODE PIC 9. CALL SUBRTN PROC. DIV. USING PAYREC. USING RECORDA. . . . . . . GOBACK. CALL PAYMASTER ENTRY PAYMASTER USING FLAG RECORDA. USING CODE PAYREC. . . . . . . STOP RUN. GOBACK.

    36. Static Call On 2nd call to Subrtn, the subroutine is in its last used state. I.e., any local variables changed during 1st call have values they had after 1st GOBACK.

    37. Dynamic Call Putting it all together...

    38. WORKING-STORAGE SECTION 77 IDENTIF PIC X(8). 01 FLAG PIC X. 01 RECORDA. As before. . . . PROC. DIV . . . MOVE SUBRTN TO IDENTIF. CALL IDENTIF USING RECORDA. Same subroutine as before. . . . CANCEL IDENTIF. . . . MOVE PAYMASTER TO IDENTIF. CALL IDENTIF USING FLAG RECORDA. Same as before. . . . STOP RUN.

    39. Dynamic Call The CANCEL statement removes SUBRTN from memory. Second call to alternate entry point causes a fresh copy of the load module to be brought in.

More Related