Craddock, Chris wrote:
Hmmm. So all dynamically loaded programs not in the LPA
are loaded into my address space; then the JPA is just
a collection of CDEs? I know CDEs point to XTLSTs and
that CDEs contain the _use count_, which is incremented
every time a program is invoked using a system service
(and decremented on return).
Yes. The XTLST refers to the actual block of storage that contains the
fully relocated program in memory. These days (I believe) there can be
either one or two XTLST entries for a single CDE and the latter case
only exists for split rmode modules. In days of old with scatter loads
there were as many as necessary but I don't know whether that's even
supported any more. Given z/OS history they probably still work, but
I've never seen one in the wild.
Cool. I new about two XTLST entries for split modules,
but never thought about the implications of scatter load
these days. Interesting question if it stills work and
if scatter load does use multiple XTLSTs.
Every task in my address space may access these modules,
and managing that is influenced by reenterancy and
resuability.
Yep. For reentrant modules they can all bang away at the same time.
Non-reentrant modules are somewhat more complicated in that the system
attempts to prevent a second or subsequent task from "using" the module
until the original requestor has released it. In practice those
limitations are trivially defeated, which is one of the many reasons I
maintain that non-reentrant modules are just a bad idea and ought to be
avoided, especially by privileged code.
By the way, when I say "privileged" it means anything running in ANY of
the following states; APF authorized (regardless of whether actually in
a system state or not) and/or running in supervisor state and/or running
in a system PSW key, or (and this one is funky), having a PKM allowing
it to switch to a system key. An SVC and any PC is potentially
privileged because (depending on how defined) it can run in a system
state (sup state and/or system key) even when the caller is as
unprivileged as dirt. The code inside that SVC or PC is considered
privileged. The code outside is not, unless it satisfied the same
criteria anyway.
The first time a task dynamically requests a module, the
module is either located as already in the LPA or JPA,
or it is loaded into my address space and a CDE and XTLST
are built. Then an LLE is built and set with a
_responsibility count_ of one; this is incremented
each time that task issues a LOAD and decremented for
each DELETE; (there is actually a _system responsibility
count_ as well); if I have multiple tasks, they would each
have their own LLEs but would share the same set of CDEs
(true?).
Yes. The system responsibility count is there to prevent unauthorized
programs from deleting programs loaded by privileged callers - a
slightly convoluted thought. Most application code starts in an
unauthorized condition and remains that way. All of the stuff you read
in the books is geared around that usage.
However, even unauthorized tasks can call privileged functions (SVC's
and PC routines) and once you're inside that privileged world all of the
rules look a little different. The dichotomy between "system" and
"non-system" deals with these cases.
If the caller of LOAD is in a privileged state, then the load must be
satisfied from an APF authorized library, or its moral equivalent (any
LPA module, or a linklist module if LNKAUTH=YES in parmlib.) In these
cases, the system responsibility count is incremented. If an
unprivileged task loads the same module, the other count goes up and the
count is decremented on DELETE, but no matter how many times the
unprivileged caller issues DELETE, the module won't actually be deleted
until the system count goes to zero and that count is only decremented
for privileged deletes.
Oh by the way, contents supervision is pretty complicated because it
deals with a whole range of circumstances you won't read about in any
external doc. Peter Relson looks after it and others mess with it at
their peril.
Here's an another area of confusion. Both you and the
docs say that LLEs point to CDEs. But I have a dump
I created for testing and I see this (short version
and slightly reformatted):
LLE
007FDE48 CHN...... 007FDE58 CDPT..... 00CB06C8
COUNT.... 0001 SYSCT.... 0001
007FDE58 CHN...... 007FDE68 CDPT..... 00CB0330
COUNT.... 0001 SYSCT.... 0001
007FDE68 CHN...... 00000000 CDPT..... 00CAE170
COUNT.... 0001 SYSCT.... 0001
CDE
007FD000 NAME..... ONION ENTPT.... 00007728 CHAIN.... 00000000
RRBP..... 007FF088 XLMJP.... 007FDE78
USE...... 0001 SP....... FB
USED. JOB PACK AREA.
CDE EXTENSION EXISTS.
XTLST
007FDE78 LNTH..... 00000010 NRFAC.... 00000001
SEGLN.... 800008D8 SEGAD....
00007728
Keep in mind that NOT ALL loads will result in a CDE or LLE and that no
matter what you do, some number of modules will be loaded (by the
system) prior to your application ever seeing a PSW. Note the SYSCT
above.
Yeah, I decided the LLEs above were created by some
of the system tasks, and the CDEs they point to are
not in my purview to see.
I understand the XTLST fields, and the CDE (although the
whole CDE extension is kind of interesting, since it says
there is an OMVS pathname for this module and that the
NAME field contains a value that can be hashed to find the
CDE extension which contains the path; interesting because
there is no use of z/OS UNIX or paths in this job, and
also because the CDE extension and the hashing algorithms
are not documented (OCO)).
Anyway, why are there three LLEs (since there is only a
job step task here) and none of the CDPT values point to
the one and only CDE we have in the address space?
See above.
I was sure I had read something about a LLA which stood
for the Link List Area or Load List Area; guess that's my
memory fading away.
LLA is Linklist Look-Aside. It is an in-memory cache of frequently used
modules and it is used to avoid some of the I/O and initialization
processing for such requests (another thing Peter looks after)
CC
Yes, I know about Linklist Look Aside, but the LLA
I saw was in a different context.
Thanks Chris. Most of this was familiar but some
of the nuances I've never had to work with (since I
try to focus on working with applications instead of
systems).
Kind regards,
-Steve Comstock
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
