If you are saying you don't know how to call a subprogram dynamically in COBOL, you can either (1) verify the DYNAM and NODLL options are specified in your COBOL compile, or (2) use CALL <variable-name> where variable-name contains the name of the subprogram. If you are asking how to achieve something else, you'll need to explain more about what you're wanting to do.I want this too if I call it dynamically (also from batch COBOL) , but I don't know how to achieve that.
- if you're talking about the assembler data areas, that's not "working storage" as the term is commonly used; if you're talking about the COBOL WORKING-STORAGE, then it will be the same when the subprogram returns as when the subprogram is invoked (unless, of course, you changed it in the subprogram).persistent "working storage"
Static called subprograms are linked into the calling program and hence the "routine" in the quote would be the calling program; with dynamically called subprograms the "routine" in the quote will be the subprogram since it is independent of the calling program. Hence, you will see different behavior between static and dynamic calls and unless you find another facility in the LE macros to provide storage across calls, you can either (1) provide the subprogram memory from the calling program, or (2) give up your idea of having persistent memory and work within the limitations you have.Automatic data: Automatic data is allocated with the same value on entry and
reentry into a routine if it has been initialized to that value in the semantics of
the language used, for example, data declared using the PL/I INIT() option.
Values of the data at exit from the routine are not retained for the next entry
into the routine. The scope of automatic data is a routine invocation within an
I think you would run into the issue still. A COBOL run unit is one or more object programs that are executed together. With dynamic calls, your assembler subprogram and the COBOL routine it calls would be a run unit (as long as they were linked together) and COBOL initializes WORKING-STORAGE when the run unit is invoked. You might be able to use external storage (look at CEEGTST) to achieve what you want.Do you think dynamically calling a COBOL program from the assembler program to store the data in it's working storage would work? (I dread the performance overhead though)