Dynamically calling LE-conforming assembler

[Wildt]

Well, I said that the LE conforming assembler would DYNAMICALLY call the COBOL sub-program. Then they wouldn't be a LE "routine" would it?

And if I get storage in my assembler program with CEEGTST, where would I put the pointer to the area before I exit, so I can retrieve it upon re-entry?

[BillyBoyo]

Just found this, and I see it is on IBM-MAIN as well.

If you dynamically CALL a COBOL program, that COBOL program's WORKING-STORAGE is not going anywhere until the termination of the run-unit/enclave.

However, how about making a LOADable table, so that you can get the storage you need by name?

[Wildt]

Just found this, and I see it is on IBM-MAIN as well.

If you dynamically CALL a COBOL program, that COBOL program's WORKING-STORAGE is not going anywhere until the termination of the run-unit/enclave.

However, how about making a LOADable table, so that you can get the storage you need by name?

Thanks for the reply - I'll look into LOADable tables - I don't know anything about it.

[BillyBoyo]

I'm assuming your sub-program is itself persistent.

You create your storage as an Assembler "program". Then use the LOAD macro to get it into memory, using its name.

If your sub-program is not persistent, LOAD the table from a program which is, and you will still be able to access it via the name in yours.

[Wildt]

I'm assuming your sub-program is itself persistent.

You create your storage as an Assembler "program". Then use the LOAD macro to get it into memory, using its name.

If your sub-program is not persistent, LOAD the table from a program which is, and you will still be able to access it via the name in yours.

Right. In CICS would the LOADed program get purged when the transaction is finished? (I don't get a chance to issue a DELETE)

[BillyBoyo]

I'm fairly sure it would, but I'm not a CICS specialist.

Can you outline how it is that you want this to work? Is it for CICS, or both CICS and batch? How do you want the persistence to work, such that it does as much as you want and not too much?

The idea of the LOAD is being a slightly faster way than using a dynamically-CALLed COBOL program. If you have multiple transactions with simultaneous use, you does that mess you up? For CICS you could steal a few bytes of commarea for an address, but if you want the same code in batch...?

[Wildt]

As I mentioned earlier, I'm simply trying to emulate existing behaviour. The intent was, as far as I can tell, to emulate the way COBOL dynamic calls work under LE, mainly to avoid having to get/free storage and perform trivial "first time" house keeping on every call.

I haven't studied all the cases/programs in depth but I've more or less come to the conclusion that making them LE-conforming (using CEEENTRY auto storage) and linking them into the COBOL programs is "good enough".

Thanks for your replies - much appreciated.

[Wildt]

For some reason the "EDIT" button has disappeared, so I'll just briefly add to the above:

The programs are used in both CICS and batch.

[Robert Sample]

Generally, forums (fora) will limit the time to edit a response to 10 or 15 minutes. If you attempt to edit your response after so many minutes, you won't be able to.

EXEC CICS LOAD has a HOLD option. If this option is specified, the program remains in memory until a RELEASE is done or the region comes down. Without the HOLD option, the program is purged when the transaction is complete. If the program is defined as RELOAD=YES, RELEASE will not work and a FREEMAIN must be done to remove the program -- it will not be purged with the transaction ends.