× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: swap QTEMPs
  • From: Gary Guthrie <GaryGuthrie@xxxxxxxx>
  • Date: Thu, 09 Dec 1999 12:17:08 -0600

Here's a good one regarding swapping pointers to QTEMP libraries. I
mentioned this to IBM so they may have done something about it, I
haven't checked.

Presume JOB1 and JOB2. Store JOB2's pointer to QTEMP in JOB1s PCO. Now
instead of swapping back, end the job. No problem right? Maybe NOT!!!

Another job starting up grabs the job structure that JOB1 used (for
performance reasons it hangs around as an eligible structure rather than
requiring the penalty of re-creation). This new job now has a pointer to
JOB2's QTEMP. Of course JOB2 may or not still be active or some other
new job might now have the QTEMP that JOB2 had... This could be really,
really, troublesome!!! Mix up a few QTEMP pointers and you could have
multiple jobs pointing to a single QTEMP. While this could be useful for
some things, it could be devastating in those cases where it was neither
intended nor detected!

Or how about storing a pointer to a permanent context (library) as a
pointer to QTEMP. I've done that before, too. That can be interesting.
It's handy for testing things done with another job's QTEMP objects. For
instance, you might have a job that's creating things in QTEMP and
things aren't going as expected. Create a permanent context, stuff it's
address in the PCO as if it's QTEMP, and let the job continue. Now from
another job you can perform all the normal OS/400 commands against the
job's QTEMP, because it's a permanent context with a normal library name
you can use in the commands.

Gary Guthrie
Technical Editor, NEWS/400 Magazine at http://www.news400.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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.