swap QTEMPs

[bvining@xxxxxxxxxxxx]

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