[Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 668
  • Last Modified:

Can you look at the *LDA of another User?

Does anyone know of a way to see the Local Data Area of a job that's running for another user?
0
Bryav
Asked:
Bryav
  • 3
  • 2
1 Solution
 
tliottaCommented:
Bryav:

If you haven't upgraded to V5R4 (and haven't applied the relevant PTFs that are available back to V5R2), and you have *SERVICE authority, it's fairly easy with STRSRVJOB and an exit program specified on the TRCJOB command.

You start servicing the job, execute TRCJOB and name your exit program, and your exit program runs when any trace event occurs.

Create a message queue and send messages to it. Have your exit program receive the messages and do whatever the messages tell it to do. If the messages are in place when you run TRCJOB, your exit program will run immediately because the TRCJOB command is the first trace event. You can then immediately turn the trace off and end servicing the job.

IBM removed this capability at V5R4. Sigh.

Tom
0
 
BryavAuthor Commented:
Thanks Tom.  I almost got all of that too...right up to the message part, then you lost me.

Can you elaborate a bit more on the "Have our exit program recieve the messages...." part.  I'm not following you there.

Also, are you saying that the TRCJOB message or trace dump will show me what's in the LDA of the job I serviced?  I've almost got it, but I'm not quite there.

Thanks again...

Bryant
0
 
tliottaCommented:
Bryant:

The exit program parameter of the TRCJOB command gives the ability to execute a program inside another job -- if the job is being serviced through something such as STRSRVJOB.

You can write a program that will do RTVDTAARA *LDA and send the retrieved value somewhere else. Or you can write a general purpose program that can receive messages and act differently for different messages.

If you create a message queue in QGPL, for example, the program could look in there to see what orders you gave. You could create a temporary message queue that was named something like QGPL/DBG123456. You might choose the digits [123456] because those might be the ones that are from the Job Number of the job being serviced. Your program could retrieve the job number when it ran and figure out what message queue it should receive messages from. (Use the RCVMSG command to receive them. Or use the message API, but that takes a little more effort.)

So, you can write a program that does a particular thing like looks at *LDA and reports back to you. But the program would only be useful for that one thing and you couldn't use it the next day to do something different like listing files in the job's QTEMP.

Or, you can write a slightly more complex program that is able to get direction from you while it runs. A message queue is a fairly easy way to communicate with a program. You can send messages to the queue with the SNDMSG command and the program can easily get the messages. This program could be useful for a different task tomorrow when you need it for whatever comes up.

The message might be a string that the program could pass to QCMDEXC as a parm -- dynamic commands. Or the message might some basic codes that you choose yourself. The program does a RCVMSG, handles the message, then goes back and does RCVMSG again until all messages are gone.

Tom
0
 
BryavAuthor Commented:
I see where you were going with that now.  That's a really interesting idea for a utility.  I hadn't considered doing something like that, but now that you bring it up, that would be very useful for solving strange problems that occur when LDAs get messed up and when other things happen that you need to look at various details of another users job.

Thanks for your help Tom.

Bryant
0
 
tliottaCommented:
It is purely temporary as I said at the top, so don't rely too much on it. V5R4 takes it away for good.

Before V5R4, a long term solution might be to create a basic routing program that activates message handling for jobs.

The routing program would create a message queue (probably named according to the job, but must be named so that other jobs can determine which message queue to use). Then it would associate a break-message handler program. Finally, it would transfer control to QCMD to begin normal processing.

This routing program could be associated with batch and/or interactive subsystems as you choose. By enabling break-handling right up front for all jobs that pass through the subsystem, each job has a simple event handler active. You trigger the "event" by sending a message to the message queue being monitored by that job.

Break-message handlers are among the very easiest ways to get external events to be recognized and responded to. But you'll need some time to put such a solution in place. The service-job technique can buy some time.

Tom
0

Featured Post

Get quick recovery of individual SharePoint items

Free tool – Veeam Explorer for Microsoft SharePoint, enables fast, easy restores of SharePoint sites, documents, libraries and lists — all with no agents to manage and no additional licenses to buy.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now