On 29-Oct-2015 17:01 -0500, Barbara Morris wrote:
On 10/29/2015 1:03 PM, Mark S Waterbury wrote:
...
I have discovered that the *DFTACTGRP is also "cleaned up" when you
run the "Reroute Job" (RRTJOB) command to start a new routing step
within an interactive job. (RRTJOB seems to put the default
activation group back to a state very much as it appeared at the
start of the job.)
...
Hi Mark, very interesting! I don't think I have ever used RRTJOB. I
did a bit of experimenting, and it also causes heap storage allocated
in the DAG to be reclaimed. As well as reclaiming ordinary activation
groups. It also _seems_ to end the JVM, although my understanding is
that ending the JVM fully is complicated, so I wouldn't count on any
experiment I could do as being any kind of proof that it really gets
ended.
I think I'll stick with signing off and back on ...
My recollection is: The RRTJOB is effectively just Transfer Job
(TFRJOB) sans Job Queue (JOBQ); i.e. the latter ends the current routing
step by rerouting the job through a new Job Queue, whereas the former
ends the current routing step while [re]routing into the current
subsystem. Thus AIUI the reroute is somewhat of a shortcut to get the
new routing step started in the same subsystem, by bypassing [some of
the WM complexities for additionally] routing via a JobQ. And the
Transfer Batch Job (TFRBCHJOB) is almost the same as TFRJOB, but the
former allows the job to span a PwrDwn\IPL when the job was waiting on
the job queue just as would a batch job started with Submit Job (SBMJOB)
and also similar to the SBMJOB that the QTEMP library will be /new/,
whereas the latter would have the job canceled from the job queue during
an IPL despite any appearance of having been waiting on the job queue
when the Power Down System (PWRDWNSYS) was initiated.
What I recall that survives into a new routing step, spanning a
transition from ending one routing step to the start of another, is
basically just the job Status Attributes (*STSA) and Definitional
Attributes (*DFNA), [at least the user portion of] the Library List
(*LIBL), the spooled files (*SPLF), and the joblog [the job message
queue]. And most everything else is cleared [e.g. QTEMP for TFRBCHJOB],
ended [e.g. *CmtCtl] and\or de-allocated [e.g. locks, opens, overrides,
and activations]. And the rest of the job is established anew,
according to the WM routing per the specified Routing Data (RTGDTA)
[i.e. *RUNA]. The others that were cleared\deallocated are left to the
program(s) to re-allocate and\or populate as required to continue their
work in that new routing step.
I would expect that if the JVM /seems/ to end with the end of the
routing step, then the JVM probably was intended to have ended
completely. Suggesting that either the JVM can, or the JVM can not,
transition into a new routing-step. I expect probably, there really
should be no gray area. I expect that if there is a problem with either
starting a new JVM in the new routing step or continuing to use the
existing JVM in the new routing step, then there might very likely be a
defect in the design; i.e. probably as an overlooked aspect in the
design of the JVM, most likely because so little is known about
/routing-steps/, even by most of the [non-WM] OS developers. Again,
just a guess; perhaps worth someone [who is interested\impacted] to
pursue via a reader comment or a PMR.
midrange.com
