RE: accessing qtemp files from another job

["Richard Jackson" <richardjackson@xxxxxxxxxxxxxxxxxx>]

Given your statement that you are new to this, it seems like a pretty bad
idea to give you a nuclear bomb to kill mice.  Here are your choices:

1. Fix the programs so they don't look
2. Give someone enough authority to fix the jobs when they do loop.
3. Live with it.

If management doesn't want to give out authority, then they don't want it
fixed.  If they want it fixed then they give authority.  If you try to sneak
around the authority problem, you are risking your job for nothing.  This
isn't your problem, it is their problem.  Don't let them make you feel bad
about that.

By the way, there are technical solutions but this situation doesn't want a
technical solution.  A technical solution gives you the opportunity to cut
yourself with a very sharp knife or get yourself in trouble with the
authority czar.  This situation wants a business solution.

I'm sorry you have to live with this.  However, this is my opinion.

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

> |-----Original Message-----
> |From: owner-mi400@midrange.com [mailto:owner-mi400@midrange.com]On
> |Behalf Of Jodi Walker
> |Sent: Wednesday, September 27, 2000 12:48 PM
> |To: MI400@midrange.com
> |Subject: accessing qtemp files from another job
> |
> |
> |     I have checked the archives and found some items relating
> |to accessing
> |     another job's qtemp files.  The problem is that they are a
> |little over
> |     my head - I am completely new to this area.
> |
> |     The situation is this: for whatever reasons, misguided or
> |otherwise,
> |     we use QTEMP files heavily in batch processes.  Some of these batch
> |     jobs are started by ROBOT software.  Our security is setup so that
> |     programmers can not even see the job log of a ROBOT job.  There are
> |     times when there is no one around with *ALLOBJ authority and when a
> |     job starts to loop, we have no way to recover the data from QTEMP
> |     before ending the job.  Management is unlikely to come up with a
> |     solution to resolve the problem, especially if the solution
> |involves
> |     assigning *ALLOBJ authority to any programmer.
> |
> |     What I want to do, and I assume it is possible from what I
> |have read,
> |     is create an object that will allow us the specify the
> |qualified job
> |     and perhaps the file names in question, and either CRTDUPOBJ or
> |     display the file contents from QTEMP so that we can safely
> |end the job
> |     without losing the interim data - something that we can
> |call when we
> |     need it.  Can this be done without adopting *ALLOBJ authority?   We
> |     don't want to have to go back and modify every program that stores
> |     data in QTEMP files.
> |
> |     Could someone give me some direction on how I can do this
> |or point me
> |     to a primer so that I can understand more of what I am
> |reading in the
> |     archives about accessing another job's QTEMP files?
> |
> |     thanks much
> |     jw
> |+---
> || 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
+---