Oppolzer - Informatik / Blog


Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie

ASSEMBLER-L - Writable Static Area in ASSEMBLER

Subject:

Re: WSA reference

From:

Bernd Oppolzer <bernd.oppolzer@T-ONLINE.DE>

Reply-To:

IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU>

Date:

2010.06.06 13:25:41


AFAIK, with C++ you have no choice. RENT is required due to language definition.
Only ANSI C allows you to use natural reentrancy.

(RENT, DLL, LONGNAME is required for C++, AFAIK).

Use NORENT with PL/1 !!

Kind regards

Bernd



S.S. schrieb:
> On Sun, Jun 6, 2010 at 1:25 AM, Bernd Oppolzer
> <bernd.oppolzer@t-online.de> wrote:
>
>> There was a comment from Mr J.G. on IBM Main, too,
>> but I prefer to post here, although it is more a PL/1 topic.
>> Maybe we should discuss it further on the PL/1 list.
>>
> <snip>
>
>> If, in this case, you specify the RENT compile option, the following
>> happens:
>>
>> all STATIC variables are placed in the WSA. The WSA is dynamically
>> allocated on the enclave level (during start of the enclave). If the STATIC
>> variable have INIT values, the INITs have to be done by dynamic
>> initializations
>> at run time. That is, you have three drawbacks:
>>
>> - additional space for the init patterns in the load module (the space
>> in the
>> WSA is the same as the space in the STATIC CSECT in the other case)
>>
>> - larger load module due to initialization logic
>>
>> - CPU consumption due to initialization, although only on enclave start
>>
>> Think of large static arrays with INIT. This may be costly.
>>
>> And it does NO GOOD AT ALL.
>>
>> That is why I vote against the RENT compiler option.
>>
>
> We ran into this issue at shop also and there is an additional reason
> that naturally reentrant is preferred over constructed reentrancy for
> C/C++.  No PL/1.
>
> Our application (batch) has dozens of TCBs which perform specialized
> tasks.  Data is passed between the TCBs on queues.  When each TCB is
> attached, the parm points to a control block in the root TCB.
> Anchored off of this control block are various vector tables which
> contain program addresses and other various bits of data.  The
> programs are loaded (and the addresses put in the vector table) by the
> initialization TCB.  The programs can then be used by any of the other
> TCB as required.
>
> Each TCB creates its own CEEPIPI enclave.
>
> If the application did not use natural reentrant programs, we would
> have to load the programs under each TCB instead of just the
> initialization TCB.  This would have significant increased application
> complexity.
>
> <snip>
>
>
>> Kind regards
>>
>> Bernd
>>
>>
>>
>>
>
>

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie