RE: Another job's QTEMP

Richard,

I think BRMS does something like this - there's a special program to run at
the console which sits and waits for a trigger from a job on the job
scheduler, then kicks in restricted mode and runs the BRMS version of Save
option 21.  Based on that, I'd say your idea is viable.

Dave Shaw
Spartan International, Inc.
Spartanburg, SC

-----Original Message-----
From: Richard Jackson [mailto:richardjackson@richardjackson.net]

I just remembered.  Why won't this technique work if the target job is the
system console - DSP01?  I think that it will.  If that be true, then it
should be possible to automate a full system backup by sending a message to
the QGPL/QDSP01 message queue at the appropriate time.  The message would be
something like "call saveall" where program saveall is a program that does
everything that you want.  The console workstation job will run the program
as whoever is signed on - the program could adopt more authority.  In order
for this to work, the console has to be left signed on - obvious security
problem.

This is only interesting because people keep asking how to do this.

Richard Jackson
mailto:richardjackson@richardjackson.net
http://www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]On Behalf Of Richard Jackson
Sent: Monday, September 25, 2000 9:16 PM
To: MIDRANGE-L@midrange.com
Subject: RE: Another job's QTEMP


Okay.  I have looked at all the other replies to this note.  You guys have
all forgotten how to make a wheel with a stone axe.

Following is an easy way.  There are probably others that I haven't thought
of lately.  This technique requires the target job to agree to be probed.
There are other ways where this is not a requirement - see Peek/400.

When the target job starts, execute commands inside the target job.  first,
create a message queue in qgpl named q+job number.  Also in the target job,
assign a break message handler to the message queue.  The program to call
should look like this:

pgm (&mark)

dcl &mark *char 4
dcl &msg  *char 255

rcvmsg &mark &msg

call qcmdexec (&msg 255)

endpgm

If you try to compile this and it doesn't work, I won't be the least bit
surprised.  The last time I wrote this particular program was about 15 years
ago and the above is from memory.  If it turns out to work, it will be a
miracle on the same scale as the parting of the Red Sea.

Nevertheless, in order to get the DSPFD from the other job, send a break
message to qgpl/q+jobname.  The message should contain "dspfd qtemp/filename
... *print".  The spool file shows up in the target job.

Richard Jackson
mailto:richardjackson@richardjackson.net
http://www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-midrange-l@MIDRANGE.COM
[mailto:owner-midrange-l@MIDRANGE.COM]On Behalf Of Graves, Chuck
Sent: Monday, September 25, 2000 2:50 PM
To: 'MIDRANGE-L@midrange.com'
Subject: Another job's QTEMP


I think there's a way...I just don't know it...
How can I look at another jobs QTEMP...specifically to do a DSPFD of a file
in that job's QTEMP library
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---