Tweet
Is there a way to get to another job's qtemp?
-
-
Another job's QTEMP
On Tuesday, January 26, 1999, 03:06 PM, Dale Monti wrote: Is there a way to get to another job's qtemp?
this question comes up from time to time; If you can display the job you can display the lib list for the job but that's about it........Bob Hamilton TEXAS BUSINESS SYSTEMS 736 Pinehurst Richardson, Texas 75080
-
Another job's QTEMP
Dale and Bob, Actually this is not true. I am a participant on the Midrange-L mailing list and this question comes up periodically. There are a couple of people on the list who have written interfaces into the system to "peek" at another job's QTemp. To subscribe to the list, go to target=_new href="http://www.midrange.com/"> href="http://www.midrange.com/">http://www.midrange.com/ . Bill On Tuesday, January 26, 1999, 03:06 PM, Dale Monti wrote: Is there a way to get to another job's qtemp?
Bob Hamilton wrote: this question comes up from time to time; If you can display the job you can display the lib list for the job but that's about it.. ......Bob Hamilton TEXAS BUSINESS SYSTEMS 736 Pinehurst Richardson, Texas 75080
Comment
-
Another job's QTEMP
STRSRVJOB on the job whose QTEMP you want to see, and then issue: DMPSYSOBJ *ALL QTEMP /* combined with OFFSET, you can dump specific objects in the other job's QTEMP */ There are other methodologies, some are dangerous while others are safe and robust. For a good answer, the specific needs must be stated; ie. why and from what does the need arise. Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.Comment
-
Another job's QTEMP
On Wednesday, January 27, 1999, 04:13 PM, Chuck Pence wrote: STRSRVJOB on the job whose QTEMP you want to see, and then issue: DMPSYSOBJ *ALL QTEMP /* combined with OFFSET, you can dump specific objects in the other job's QTEMP */ There are other methodologies, some are dangerous while others are safe and robust. For a good answer, the specific needs must be stated; ie. why and from what does the need arise. Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.
Every time this comes up, I seem to suspect some redesign is inorder.... IMHO, TI......Bob Hamilton TEXAS BUSINESS SYSTEMS 736 Pinehurst Richardson, Texas 75080
Comment
-
Another job's QTEMP
On Wednesday, January 27, 1999, 06:58 PM, Bob Hamilton wrote: Every time this comes up, I seem to suspect some redesign is in order.... IMHO, TI ...... Along the lines of removing the concept of QTEMP perhaps? If anybody wants to access another's QTEMP there are certainly ways... and as I said there are safe and effective ways; maybe not so effective as direct access, but at least "safe". I see no need for change in any direction other than removal... as I would hardly want to support QTEMP as a "supposed to be temporary to a specific job, yet we allow any authorized user to mess with it; thus having destroyed a well-defined pervasivedesign dependency". General access to QTEMP for operations other than within a user's own job except via "servicing" commands is a Pandora's box which I prefer to have remain closed; already too late as I've seen the effects of a poor design change idea Comment
-
Another job's QTEMP
I meant application redesign, not operating system....did you ever try to remove QTEMP from a job????
......Bob Hamilton TEXAS BUSINESS SYSTEMS 736 Pinehurst Richardson, Texas 75080
Comment
-
Another job's QTEMP
Didn't Ernie Malaga write an article a few years back on accessing another job's QTEMP? ChrisComment
-
Another job's QTEMP
On Thursday, January 28, 1999, 06:53 AM, Chris Ringer wrote: Didn't Ernie Malaga write an article a few years back on accessing another job's QTEMP?
I don't think so, but I could be wrong. I remember he submitted a request thru COMMON that IBM add a parameter to the SBMJOB that would allow a submitted job to use its own QTEMP or share the QTEMP of the caller. I thought that was a great idea, and still do.Comment
-
Another job's QTEMP
FYI. The reason I asked this question is that I am doing some Java work. I created an out file in QTEMP using the command call classes, then I wanted to query the out file, but the command call and the query run in 2 different jobs. Thank you all for your input DaleComment
-
Another job's QTEMP
Once in a while I do find the Qtemp situation annoying, when I am trying to retrieve a work file attribute and realize I can't while debugging or something like that. But, (And it's a big but) the benifits of having "working storage" for each job executing code on my system that is not accessible to any other job is a great benefit. I for one count on each jobs QTemp lib and utilize it in almost every job I execute. The idea that other jobs might access this temp storage area would defeat the purpose of it being a Temporary storage area. In the past I have created libs up front in a CL that are utilized by other jobs in the same stream, finally passing control back to the CL that deletes the "working lib". Now if ILE could be made to create a QTEMP lib that was accessible to any Proc called or submitted from it, that would be an enhancement. Just trying to keep up....Comment
-
Another job's QTEMP
I think the article was called "Peeking into someone elses QTEMP" or something like that. I don't know if it was an MC publication or News/400.
On Thursday, January 28, 1999, 03:25 PM, Ted Holt wrote: On Thursday, January 28, 1999, 06:53 AM, Chris Ringer wrote: Didn't Ernie Malaga write an article a few years back on accessing another job's QTEMP? I don't think so, but I could be wrong. I remember he submitted a request thru COMMON that IBM add a parameter to the SBMJOB that would allow a submitted job to use its own QTEMP or share the QTEMP of the caller. I thought that was a great idea, and still do.Comment
-
Another job's QTEMP
It's quite simple really... the QTEMP is designed quite clearly to not allow sharing of one job's QTEMP objects with another job. Any change to effect otherwise, would quite thoroughly compromise that design concept. If a shared QTEMP is desired, then the desire is for a shared repository -- so why not just create one.?.? If being able to access files between two jobs is required, then QTEMP should not be used except when the job will move the required objects to a permanent library when it is done using them. The key point being that with such access, which implies locking, to objects in another job's QTEMP conflicts with the ability for the owning job to function properly -- or even have an orderly termination, because it may not be able to access an object in its own QTEMP. Many other issues are actions which one might be compelled to effect, like modify a data record in a temporary file of the job to allow it to continuewhen there is an error. Tempting! But to vitiate the QTEMP concept, is it worth it? IMNSHO I do not think so. If you want that, then implement the programs/jobs with a back-door, to issue requests via events to that job; same as STRSRVJOB is effected. A simple routing program to allocate a message queue with a break program can effect this quite nicely; even requiring password validation or other verification to the requests -- and if compiled as a adopt for a super-user, can perform actions which might not otherwise be allowed . Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever. Comment
-
Another job's QTEMP
On Thursday, January 28, 1999, 03:25 PM, Ted Holt wrote: I don't think so, but I could be wrong. I remember he submitted a request thru COMMON that IBM add a parameter to the SBMJOB that would allow a submitted job to use its own QTEMP or share the QTEMP of the caller. I thought that was a great idea, and still do.
Geez. That's about the best idea I've heard since... well, a long time. One of my beefs has always been waiting for a submitted job. Usually I use a queue of some type (message or data), but since the submitter and submitted jobs are different, you have to externalize the queue, which means having a unique name, which usually involves the job number... You know the drill. With a shared QTEMP, the queue name could be ANYTHING, and I know I wouldn't have an issue of cross-posting. How MARVELOUS! My, my, my, would somebody please kick the IBM enhancement team someplace where they might notice? JoeComment
-
Another job's QTEMP
On Friday, January 29, 1999, 02:29 PM, Chuck Pence wrote: It's quite simple really... the QTEMP is designed quite clearly to not allow sharing of one job's QTEMP objects with another job. Any change to effect otherwise, would quite thoroughly compromise that design concept. If a shared QTEMP is desired, then the desire is for a shared repository -- so why not just create one.?.? If being able to access files between two jobs is required, then QTEMP should not be used except when the job will move the required objects to a permanent library when it is done using them. The key point being that with such access, which implies locking, to objects in another job's QTEMP conflicts with the ability for the owning job to function properly -- or even have an orderly termination, because it may not be able to access an object in its own QTEMP. Many other issues are actions which one might be compelled to effect, like modify a data record in a temporary file of the job to allow it to continuewhen there is an error. Tempting! But to vitiate the QTEMP concept, is it worth it? IMNSHO I do not think so. If you want that, then implement the programs/jobs with a back-door, to issue requests via events to that job; same as STRSRVJOB is effected. A simple routing program to allocate a message queue with a break program can effect this quite nicely; even requiring password validation or other verification to the requests -- and if compiled as a adopt for a super-user, can perform actions which might not otherwise be allowed . Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever. Thanks Chuck
Exactly what I said, just done better. Just trying to keep up....Comment
Comment