Re: Where does SEU store Work In Progress

ð
Hello David,

You wrote:
>There is a "hidden" part of a job called the *PCS (Process Control Space).
>The OS puts job specific system objects into this space in various
>"contexts", one of which is QTEMP context (this is explained somewhat in the
>CL reference under the DMPSYSOBJ command (thx Tim)).  Its unclear to me what
>the differences, if any, there are between the library QTEMP and the context
>QTEMP, but the context QTEMP could be a lot more permanent than the library.

The PCS is not so much hidden as simply an internal object rather than an 
external one.  
Contexts are simply the MI term for a library.  The different terminology 
arises from 
different groups doing different parts of the development.  If you read the 
Functional 
Concepts Manual (assuming you can get a copy) you will see that it is written 
from the 
point of view of the MI developers and is aimed at those who would create an 
operating 
system to run on top of the MI.

There are two types of context:  A library context which is created via the 
CRTCTX MI 
instruction which is more commonly invoked by the CRTLIB CL command; and the 
Machine 
Context which is implicity created by the machine and used for addressing 
permanent 
objects like contexts, communications descriptions, user profiles, and other 
objects which 
the user cannot place in particular context.

The word context is used because it qualifies the reference to any specific 
object.  A 
context contains addressability by name, type, and subtype to other system 
objects.  Not 
all objects need to be in a context but if they are not then the only way to 
find them 
(resolve them) is by knowing the address.  Temporary objects generally do not 
have a 
context.  The addresses of temporary objects are usually active for the 
duration of a 
program or job.  If longer term addressability is required then the object's 
address can 
be stored in another permanent object (which would have an associated context).

Contexts can be permanent or temporary and an attribute in the context creation 
template 
controls this.  Temporary contexts (and indeed any object not in a context) can 
only be 
addressed by the system pointer returned when the context (or object) was 
created.  
Permanent contexts can be addressed in the same way but more usually by 
resolving the 
symbolic address (name, type, and subtype) to a virtual address in a system 
pointer 
returned by the RSLVSP MI instruction.  

QTEMP used to be a temporary context but it has been a permanent context for 
quite a while 
(I think since VRM230 and possibly earlier).  It was changed due to problems 
with damaged 
objects when the temporary context was implicitly destroyed.  Now QTEMP and the 
objects it 
contains are explicitly destoyed as part of job termination -- usually when the 
job ends 
but sometimes as part of the cleanup performed during an abnormal IPL.

Regardless, QTEMP does not persist beyond an IPL and generally not beyond a 
job's 
existence so information stored there cannot be retrieved after a job ends.

Now to the PCS.  The PCS does not contain "various contexts" but rather is a 
structure 
fundamental to a jobs existence that holds variables containing various state 
information 
about the job.  It is used as a machine work area and it allows jobs to be 
addressed and 
managed.  It is created by the CRTPCS MI instruction and is passed to the 
INITPR MI 
instruction when a job is started (or more correctly a process is initialised). 
 The 
variables in the PCS may be scalar or pointer data and the pointers may 
reference contexts 
or other objects.  The most obvious contexts referenced are the job's QTEMP 
library and 
the libraries referenced in the Name Resolution List (more commonly known as 
the library 
list).  There is much more stored away in the PCS.

Various job spaces and tables are created during IPL and as required during 
normal system 
operations.  The QTOTJOB and QADLTOTJ system values control the creation of 
Work Control 
Block Table Entries, the QACTJOB and QADLACTJ system vðlues control the 
creation of PCS 
objects.  PCS objects are reused as jobs terminate.

Boy, am I in a good mood!

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           «»
«» Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au      «»
«»                                                                «»
«» Windoze should not be open at Warp speed.                      «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
//--- forwarded letter -------------------------------------------------------
> X-Mailer: Microsoft Outlook Express 5.00.2615.200
> Date: Sat, 15 Apr 2000 16:46:48 -0700
> From: "David Keck" <dkeck@idt.net>
> To: MIDRANGE-L@midrange.com
> Reply-To: MIDRANGE-L@midrange.com
> Subject: Where does SEU store Work In Progress

> 
> There is a "hidden" part of a job called the *PCS (Process Control Space).
> The OS puts job specific system objects into this space in various
> "contexts", one of which is QTEMP context (this is explained somewhat in the
> CL reference under the DMPSYSOBJ command (thx Tim)).  Its unclear to me what
> the differences, if any, there are between the library QTEMP and the context
> QTEMP, but the context QTEMP could be a lot more permanent than the library.
> Also, in reviewing some of the  MI commands,  I found one called ENSOBJ,
> which protects an MI object against volatile storage loss.  Sounds similar
> to a configuring a file with force write ratio 1:1.  Something along these
> lines is needed as the 400 may not have time for things such as MOVOBJ when
> it's goin' down hard.

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---