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

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.

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].