Page 2 of 2

Re: Dynamically calling LE-conforming assembler

PostPosted: Fri Sep 09, 2016 11:35 pm
by 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?

Re: Dynamically calling LE-conforming assembler

PostPosted: Sat Sep 10, 2016 11:51 am
by 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?

Re: Dynamically calling LE-conforming assembler

PostPosted: Mon Sep 12, 2016 11:48 am
by Wildt
BillyBoyo wrote: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.

Re: Dynamically calling LE-conforming assembler

PostPosted: Mon Sep 12, 2016 8:50 pm
by 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.

Re: Dynamically calling LE-conforming assembler

PostPosted: Wed Sep 14, 2016 11:57 am
by Wildt
BillyBoyo wrote: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)

Re: Dynamically calling LE-conforming assembler

PostPosted: Wed Sep 14, 2016 9:40 pm
by 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...?

Re: Dynamically calling LE-conforming assembler

PostPosted: Thu Sep 15, 2016 4:15 pm
by 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.

Re: Dynamically calling LE-conforming assembler

PostPosted: Thu Sep 15, 2016 4:37 pm
by 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.

Re: Dynamically calling LE-conforming assembler

PostPosted: Thu Sep 15, 2016 8:15 pm
by 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.