Re: swap QTEMPs -- MI400

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.

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