Craddock, Chris wrote:
So I'm comfortable with having the JPA as an area in my
address space for holding dynamically called reenterable
programs.
It is for ALL dynamically loaded modules that are NOT found in LPA.
Good. Makes sense.
It's the last sentence that I find less than
enlightening: suppose I dynamically load a non-reenterable
module? Where is that loaded? It can't be the JPA by the
above definition. I seem to recall a term like "Load List
Area" or "Link List Area" but I cannot find these anymore.
Reentrancy has (ALMOST) nothing to do with it. See below. The job pack
is a job-step level resource and it contains CDEs which are basically
just pointers to the programs in memory. Program modules are loaded into
job step storage because they may be accessed by multiple tasks, but
since multiple tasks may load different modules the system also keeps
track of the loads at the task level so it can "undo" them at
end-of-task. That task-level list is called the load list and it
contains LLEs, which point to CDEs.
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).
Every task in my address space may access these modules,
and managing that is influenced by reenterancy and
resuability.
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?).
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
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?
The "link list" is not a list of loaded programs at all, but rather it's
the list of libraries that the system will search by default (after
jobpack, steplib and LPA) for any load that does not refer to a specific
library DCB.
That was my understanding; but somewhere once upon a time
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.
A load that is satisfied from anywhere BUT the LPA will go into the
jobpack unless you're authorized and ask for it to be loaded into common
and even in that case there will be a job pack (CDE) and task-level
(LLE) so the thing can be removed at the right time. The only time
that's not true is for a directed load where the (authorized) caller
GETMAINs the storage and passes the address to the LOAD macro.
And that's beyond the scope of this partiuclar course,
so I don't want to get into that aspect of things here.
Finally, I gather the load list contains a list of all
programs dynamically loaded, whether they are reenterable
or not. But I am finding old notes that says the load list
is only for non-reenterable programs, but no pointer to
the docs for that.
Its simply misleading because the doc-writer didn't understand. The LPA
can only contain reentrant modules because they happen to be shared
between all address spaces, i.e. the LPA is part of the common area.
When a task issues a load and the module is found in LPA, the address of
that common area copy is returned and no I/O or relocation processing is
done.
Any module that is NOT found in the LPA will be loaded into the JPA for
the job step task, regardless of which subtask actually issues the load
and it doesn't matter in the slightest whether those modules are
reentrant or not.
CC
Thanks. Helped a lot; just a couple of questions remain
(see above).
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
