RE: swap QTEMPs

[Leif Svalgaard <l.svalgaard@xxxxxxxxxxxxx>]

> Would it be possible to do this then.
> 
> Have a program that when run swaps QTEMP to a library for
> that job, then releases the previous QTEMP pointer back to the
> system.
        [Leif Svalgaard]  I don't think we can "release it back to the
system",
        but it is really not necessary to do so. I don't quite understand
your
        scenario below, but here is what I do:
        1) log on (as you do) as another user.
        2) assign a permanent library as QTEMP (no swapping actually) for
        the job under test
        3) let the test proceed
        4) after the test reinstate the old QTEMP.
        5) end the job under test



> I'm thinking of this.  If I want to test a job, I would sign on as
> a user and call an initial program that would swap the QTEMP
> for a special library I can set up, and then totally release the
> real QTEMP pointer back to the system.  Then this program
> would give me a command line.
> 
> Right after the command line, it would sign off.
> 
> Would this be a possible way to achieve this without the difficulty
> of QTEMP pointers floating around in la-la land?
> 
> Regards,
> 
> Jim Langston
> 
> bvining@VNET.IBM.COM wrote:
> 
> > >
> > >While I find the technique intriguing and even useful, it's not to be
> > >taken lightly. It's too bad the pointer is not refreshed upon each use
> > >of the job structure. That would obviate this problem.
> > >
> >
> > I would like to emphasize the "That would obviate THIS problem".  Just
> > to point out a few other considerations (for those who may not be as
> > familiar with MI and what is and what isn't documented/supported):
> >
> > 1.  QTEMP libraries are a distinct object type/subtype from regular
> > libraries.  This would suggest that the system does "something"
> > different in how QTEMP and non-QTEMP libraries are processed though
> > what that "something" is delves into the area of undocumented
> > implementation detail.
> >
> > 2.  QTEMP often contains objects that are not observable from end-user
> > interfaces, but can be seen via unblocked MI instructions such as
> MATCTX.
> > Simply swapping the QTEMP address with a permanent library pointer may
> > leave the job in a questionable state as you may now have effectively
> > "deleted" (or more accurately, made inaccessible) system objects that
> > system/job processes may have a dependency on.  Again, what may happen
> > delves into the area of undocumented implementation detail.
> >
> > 3.  Other operational considerations also exist, but the above are two
> > potential problem areas that can be verified with published interfaces
> > (display the QTEMP system pointer and look at its type; MATCTX).
> >
> > 4.  From a non-system operation point of view, doing things like
> swapping
> > the QTEMP system pointer in the PCO to address another library will
> > put the user outside of normal IBM support.  Users can do this if they
> > so desire; just like users can delete QCMD if they so desire...; but be
> > aware that you will be on your own until you put everything back (and
> > that may require a system reload or a RCLSTG).
> >
> > Again the above points are really targeted for those users who may
> > be following these discussions, but are not necessarily aware of some
> > of the implications inherent in some of these sample
> programs/approaches.
> > Others following these discussions are probably used to the idea of
> > periodically trashing their system with MI...
> >
> > Bruce
> >
> > +---
> > | This is the MI Programmers Mailing List!
> > | To submit a new message, send your mail to MI400@midrange.com.
> > | To subscribe to this list send email to MI400-SUB@midrange.com.
> > | To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> dr2@cssas400.com
> > +---
> 
> +---
> | This is the MI Programmers Mailing List!
> | To submit a new message, send your mail to MI400@midrange.com.
> | To subscribe to this list send email to MI400-SUB@midrange.com.
> | To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> dr2@cssas400.com
> +---
+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---