> 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. > 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. > 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 ---------------------------------------------------------------------- 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
