Home > Archive > Cobol > September 2006 > Cobol LE and IDMS R16
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Cobol LE and IDMS R16
|
|
| mja@interbolsa.pt 2006-09-08, 7:55 am |
| Hi
I have 1 program with NORENT option and this program is called by batch
and online(ADS).
The progam is define REENTRANT in IDMS.
Should i need compile/link the program with RENT option?
The program call subrotines in assembler and i have some problems, the
terminal defined in IDMS stay active but don't respond. We need
deactivate and then activate it, then the system work well.
I don't find where is the problem.
Any idea?
Tks
| |
|
| mja@interbolsa.pt wrote:
> Hi
> I have 1 program with NORENT option and this program is called by batch
> and online(ADS).
>
> The progam is define REENTRANT in IDMS.
>
> Should i need compile/link the program with RENT option?
>
> The program call subrotines in assembler and i have some problems, the
> terminal defined in IDMS stay active but don't respond. We need
> deactivate and then activate it, then the system work well.
>
> I don't find where is the problem.
>
> Any idea?
> Tks
>
First, I do not know anything about IDMS or ASD. But, from a practical
standpoint, I would be more interested in how you defined the program to
the Linker/Binder. If the program is linked as RENT and/or IDMS treats
it as RENT as a result of what you told it, you have an exposure as follows:
* Program is loaded.
* Values changed in Working Storage.
* Program terminates.
* Because of the RENT definition, the program remains in storage
even though there is not a current user [i.e., The Use Count
will be zero.]
* A subsequent call to Program will see the changed values in W-S
instead of the initial values the program expects.
An alternative problem:
* The program is interrupted by some event.
* Another task tries to enter the RENT program because it is
actually expected to be reentrant.
* This subsequent task will not only get the changed W-S, but
will likely change other values to not match what the first
program believes to be there. Now, TWO programs get bad
results.
Lesson: Don't lie to the compiler and/or the Linker/Binder and/or to
IDMS. NOTHING good can come from this.
Re: Terminal issues
I have no idea...
Good luck!
Carl
|
|
|
|
|