Re: Accessing objects in another job's QTEMP

The exit program is running in the other job.  Your job continues to run 
after the API call completes.

Bruce Vining




Don <dr2@xxxxxxxx> 
Sent by: mi400-bounces+bvining=us.ibm.com@xxxxxxxxxxxx
02/14/2006 02:00 PM
Please respond to
MI Programming on the AS400 / iSeries <mi400@xxxxxxxxxxxx>


To
MI Programming on the AS400 / iSeries <mi400@xxxxxxxxxxxx>
cc

Subject
Re: [MI400] Accessing objects in another job's QTEMP






Bruce,

out of curiosity, this exit pgm then runs in thier space and cycles or in 
mine?

Thanks

Don





At 01:43 PM 2/14/2006 -0600, you wrote:
>In V5R3 the Open List of Objects (QGYOLOBJ) API was enhanced to allow the
>list to be the QTEMP of another job.  This API can be found in the Object
>category of System APIs in the V5R3 Information Center.
>
>In V5R4 a new Call Job Interrupt Program (QWCJBITP) API is also 
available.
>  This API allows you to have a user exit program run in the initial 
thread
>of another job.  The program could, among other things, examine the
>contents of the other jobs QTEMP library and generate a report, write the
>results to a shared resource such as a file or user space, etc.  The API
>can be found in the Work Management category of system APIs in the V5R4
>Information Center.
>
>Bruce Vining
>
>
>
>
>dr2@xxxxxxxx
>Sent by: mi400-bounces@xxxxxxxxxxxx
>02/14/2006 10:32 AM
>Please respond to
>MI Programming on the AS400 / iSeries <mi400@xxxxxxxxxxxx>
>
>
>To
>mi400@xxxxxxxxxxxx
>cc
>
>Subject
>[MI400] Accessing objects in another job's QTEMP
>
>
>
>
>
>
>
>
>Greetings,
>
>I think we hit this topic back several releases ago and I'd like to see 
if
>there's anything enhanced in recent history.
>
>The current need is to be able to catalog name, type and size of objects
>in other job's QTEMP for disk and object use analysis.  I don't need to
>necesarily open or assign the objects a lock state, but I do need to be
>able to get thier attributes for systems analysis use.
>
>I'm not aware of an API that allows retrieval of this from a supported 
IBM
>side, and if it's not there, it probably should be.
>
>And since the list has been quiet for too long I thought I'd drop this 
out
>there to see if anyone's got a nice way to skin this cat...prefereably
>sans system state pgms...but I'm not excluding anything at this point.
>
>Thanks
>
>D.Rima
>
>
>_______________________________________________
>This is the MI Programming on the AS400 / iSeries (MI400) mailing list
>To post a message email: MI400@xxxxxxxxxxxx
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/mailman/listinfo/mi400
>or email: MI400-request@xxxxxxxxxxxx
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/mi400.
>
>
>_______________________________________________
>This is the MI Programming on the AS400 / iSeries (MI400) mailing list
>To post a message email: MI400@xxxxxxxxxxxx
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/mailman/listinfo/mi400
>or email: MI400-request@xxxxxxxxxxxx
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/mi400.
>


_______________________________________________
This is the MI Programming on the AS400 / iSeries (MI400) mailing list
To post a message email: MI400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/mi400
or email: MI400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mi400.