What happens if you add a copybook to linkage section instead of adding it to a working-storage section in a sub-program?

Question

What happens if you add a copybook to linkage section instead of adding it to a working-storage section in a sub-program?

Nananne

Answer 1

This is a common practice. Having a copybook that can be used in the Working-Storage or Local-Storage Section of a calling program and the Linkage Section of the program being called ensures the parameters on the CALL match.

As noted in another answer, no storage is allocated for a copybook in the Linkage Section. This is no different than any other variables described there. If you want addressability to variables defined in the Linkage Section, you must include them in the USING phrase of your Procedure Division, which allows the calling parameters to be matched with variables described in the Linkage Section -or- you must dynamically allocate storage of sufficient size to accommodate these variables and use SET ADDRESS OF linkage-section-item TO pointer-to-allocated-storage. Probably the most portable method to allocate storage in COBOL is the ALLOCATE statement if your compiler supports it. With IBM Enterprise COBOL storage can be allocated via the Language Environment callable service CEEGTST, Micro Focus has CBL_ALLOC_MEM, some compilers and environments support directly callin C functions so you could use malloc() there.

COBOL (and C, et. al.) compilers do not enforce type-safety for passed parameters. At run time the Linkage Section variables in the called program are mapped to the addresses of the variables on the CALL statement in the calling program.

As noted in a comment by @SimonSobisch, there has been some work done in the COBOL standard to enforce type-safety on CALLs via prototypes. Not all COBOL compilers support this.

If you have a copybook in which calling parameters for a subroutine are defines, and use the same copybook in the Working-Storage section of the calling program and the Linkage Section of the program it calls, then changes to the definition of the parameters need only be done in one place (the copybook), and hopefully your source code management system will force recompilation of both the caller and the called program, ensuring there is no parameter mismatch.

Moline

"COBOL compilers do not enforce type-safety for passed parameters." COBOL 2002 has program-prototypes that do exactly this, doesn't it? And it specifies checks that (if the compiler supports it) will be done at run-time to verify the parameters match by type and size (and by actually being passed). I suggest to update your good answer that gives the main point of WS/LS->PROCEDURE DIVISION USING, along with ways to allocate storage (No idea of GETMAIN but a CALL to C$MALLOC, CBL_..., and the standard ALLOCATE statement should work). – Pronto

Answer 2

The storage will not be allocated when running the program. You will need to gain addressability to it, either by having a program call the sub-program with the copybook as one of the parameters AND specifying the copybook in the PROCEDURE DIVISION USING...

Alternatively you can use a GETMAIN command (like EXEC CICS GETMAIN, if you are in CICS) to allocate some storage, and then set the address of the copybook to the resulting pointer.

If you try to assign values to the copybook without doing either, you will get abends, probably S0C4 (Protection Exception).

Kermie