RE: Another jobs QTEMP

[Danny Oentung <DANNY@xxxxxxxxxxxxxxxx>]

you could use these 2 products or u could try the downloaded source code
from news400.
I haven't try it too ,just sent it after reading it hope can help u.

*************** Club Tech Programming Tips Newsletter *************** 
An AS400 Network Publication              http://www.as400network.com
Home of NEWS/400 Magazine
Issue 28                                           September 27, 2000

> Viewing Another Job's QTEMP

Featured Tip:

VIEWING ANOTHER JOB'S QTEMP
PeekPlus
Bytware, Inc.
http://www.bytware.com/
[See the upcoming November 2000 issue of NEWS/400 for an article about 
PeekPlus.]

JOB Talk utility, which is part of TAA Productivity Tools (the follow-
on product to QUSRTOOL)
Jim Sloan, Inc.
http://www.taatool.com/

The other method for viewing a user's QTEMP is to use a utility 
published in NEWS/400 in July 1994. Although the code is available 
online, the article text isn't. I decided to dust off the article, 
make some minor tweaks, and present it here.

The source files for the utility can be downloaded from
http://www.as400network.com/noderesources/code/clubtechcode/RunJobCmd.zip . 

Looking into Someone Else's QTEMP
By Ernie Malaga 

Reprinted from NEWS/400, July 1994
Copyright c 2000 Duke Communications International, Inc.
ALL RIGHTS RESERVED

QTEMP, the temporary library, is unlike other AS/400 libraries in that 
each job has its own QTEMP. This is great because you can create 
objects that are "local" to your job, meaning that no other jobs can 
see them and that you don't have to worry about duplicating the name 
of similar objects created in other jobs. In addition, QTEMP 
automatically vanishes when your job ends, eliminating the possibility 
of leftover objects that clutter your system and consume valuable disk 
space.

Along with these advantages, however, comes a major inconvenience: You 
can't access another job's QTEMP. Say, for example, that a shipping 
program created objects in QTEMP, as many in-house and purchased 
software products do. Let's then suppose the program blows up, and the 
shipping clerk calls you for help. You need to investigate the 
DEFAULTS data area in the clerk's QTEMP to find out what went wrong. 
However, running the DSPDTAARA (Display Data Area) command from your 
display station would display only the data areas in your copy of 
QTEMP - which would contain different data, if the same data areas 
existed at all. Instead, you must run DSPDTAARA at the clerk's display 
station in the shipping department. There must be an easier way.

An Easier Way
With MI, you could fool the AS/400 into believing that your QTEMP is 
the clerk's QTEMP. You could then run commands into the remote user's 
interactive job from the comfort of your own desk. MI solutions, 
however, are difficult and seldom work at security levels higher than 
30. Here, I present an easy-to-implement non-MI solution that will 
work at any security level. It consists of a single command: 
RUNJOBCMD.

To see how to use command RUNJOBCMD, let's revisit the shipping-clerk 
scenario. Let's say you're signed on to SYSDSP02 in the computer room, 
and the shipping clerk, Brad, is signed on to display station 
SHPDSP03. From Brad's description, you determine the problem must be 
in the DEFAULTS data area in his QTEMP. To look at the DEFAULTS data 
area in Brad's QTEMP from your display station, you run

RUNJOBCMD
  JOB(SHPDSP03)      +
  CMD(DSPDTAARA      +
      qtemp/Defaults +
      OUTPUT(*PRINT))

The RUNJOBCMD command tells the system to run the DSPDTAARA command as 
if it had been requested from SHPDSP03. The *PRINT option lets you 
look at the DSPDTAARA output by displaying the generated spooled file; 
without the OUTPUT(*PRINT) parameter, the output would simply go to 
Brad's display station.

When you press Enter, Brad's display station beeps and presents a 
panel that shows him the command you've requested and lets him approve 
or reject the request. If he presses Enter, your DSPDTAARA command 
will run on his job, displaying the DEFAULT data area in his QTEMP. If 
he presses F3 or F12, however, DSPDTAARA doesn't run. Either way, 
utility RUNJOBCMD sends you a break message that tells you which 
action Brad has taken.

How It Works
Central to utility RUNJOBCMD is a break-handling program that receives 
messages coming into the remote display station's message queue and, 
if they're request messages (*RQS), interprets them as commands and 
executes them via QCMDEXC. (For details about how break-handling 
programs work, see Chapter 8 of the CL Programming manual, SC41-5721, 
http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/QB3AUO03/CCONTENTS 
.)

For this break-handling program to work, the remote display station's 
message queue must be in *BREAK mode. To ensure this, it's a good idea 
to use a user profile initial program such as that shown below:

/* Sample User Profile Initial Program                            */
/*                                                                */
/* From "Looking Iinto Someone Else's QTEMP                       */
/* NEWS3X/400, July 1994                                          */
/*                                                                */
/* Copyright (c) 1994 Duke Communications Int'l.                  */
/* ALL RIGHTS RESERVED                                            */

PGM

   DCL  &dspstn  *CHAR  10

   /*                                                             +
    | Place the display station's message queue in *BREAK mode.   +
    | First, get the display station's name and then run CHGMSGQ. +
   */
   RTVJOBA JOB(   &dspstn   )
   CHGMSGQ MSGQ(  &dspstn   )                                     +
           DLVRY( *BREAK    )                                     +
           PGM(   jobcmdbhp )

ENDPGM

This program, executed when a user signs on, uses the CHGMSGQ (Change 
Message Queue) command to automatically place the display station's 
message queue in *BREAK mode, with JOBCMDBHP as the break-handling 
program. From this point on, RUNJOBCMD is ready whenever you need it.

Let's dig a little deeper into the utility's details. When you run 
command RUNJOBCMD, you enter the name of the remote display station 
and the command you want to execute. Because the CMD parameter is 
defined as a command string (*CMDSTR), you can prompt the command you 
want to run by typing RUNJOBCMD and pressing F4.

All that command processing program (CPP) RUNJOBCMDC does is send the 
command string as a *RQS message to the remote display station's 
message queue. Notice that RUNJOBCMDC does not use the standard SNDMSG 
(Send Message) command to send this message because SNDMSG cannot send 
*RQS messages. Instead, it uses the more complicated SNDPGMMSG (Send 
Program Message) command.

When the *RQS message arrives at the message queue, break-handling 
program JOBCMDBHP receives the message, extracting from the sender 
information parameter the names of the user profile who sent the 
message and of the display station from which it was sent. When 
JOBCMDBHP determines that the message is a *RQS message (which has a 
return type of '08' or '10'), it uses display file JOBCMDBHPD to 
present the Job Command Request panel, which lets the remote user 
approve or reject the requested command. To approve the request, the 
user presses Enter, and JOBCMDBHP executes the command. To reject the 
request, the user presses F3 or F12. JOBCMDBHP then reports the user's 
action back to the requester in the form of a break message.

Security Risks
Although convenient, this utility does pose some security risks. If 
you compile the break-handling program so that it adopts QSECOFR 
authority, anyone who has access to RUNJOBCMD (and who has a willing 
accomplice signed on at another display station) can run any command 
on the system. The same exposure exists if someone uses RUNJOBCMD to 
run commands from QSECOFR's interactive job; however, this can't be 
done unless QSECOFR (or someone at the station QSECOFR is signed on 
to) authorizes each command request by pressing Enter.

To minimize your security exposure, follow common-sense security 
rules. For example, don't compile the break-handling program while 
adopting QSECOFR's authority, and don't disclose QSECOFR's password. 
Also, make sure QSECOFR knows how RUNJOBCMD works and the possible 
security risks. In addition, you can use the AS/400's journaling 
feature to keep a permanent record of who's using RUNJOBCMD and how. 

Implementation Issues
Implementing utility RUNJOBCMD is easy. You need only create command 
RUNJOBCMD, CPP RUNJOBCMDC, break-handling program JOBCMDBHP, and 
display file JOBCMDBHPD. To install utility RUNJOBCMD, run the 
following commands in sequence:

CRTCMD
  CMD(MYLIB/RUNJOBCMD)   +
  PGM(MYLIB/RUNJOBCMDC)  +
  SRCFILE(MYLIB/QCMDSRC) +
  AUT(*EXCLUDE)

CRTCLPGM
  CMD(MYLIB/RUNJOBCMDC)  +
  SRCFILE(MYLIB/QCLSRC)  +
  AUT(*EXCLUDE)

CRTDSPF
  FILE(MYLIB/JOBCMDBHPD) +
  SRCFILE(MYLIB/QDDSSRC)

CRTCLPGM
  PGM(MYLIB/JOBCMDBHP)   +
  SRCFILE(MYLIB/QCLSRC)

Last, give *USE authority for command RUNJOBCMD and program RUNJOBCMDC 
to authorized users.

You cannot use RUNJOBCMD to run interactive commands, such as 
WRKOBJPDM (Work with Objects Using PDM). That's why, in our shipping-
clerk example, we had the DSPDTAARA command send its output to the 
printer, which lets the command run in batch mode. Otherwise, 
DSPDTAARA's output would go to the screen, making DSPDTAARA an 
interactive command. If you must run an interactive command, first use 
RUNJOBCMD to execute the CRTDUPOBJ (Create Duplicate Object) command 
to copy the necessary objects from the remote display station's QTEMP 
to any other library. You can then operate on the objects using 
standard commands.

The next time a user calls with a problem in QTEMP, run utility 
RUNJOBCMD instead of running up the stairs. Your legs and lungs will 
thank you.


Short Takes:

1. TESTING FOR AN ACTIVE PROCEDURE - PART 2
In the last issue, I ran an item from IBM's Knowledgebase that 
replicated the S/36 IF ACTIVE function, which tests whether another 
procedure is running.

Minutes after the e-mail newsletter was distributed, I received many 
e-mails telling me IBM's suggestion was flawed and offering several 
alternative solutions. IBM's solution can cause problems if the 
program - for which the active state is being tested - terminates 
abnormally, in which case the program will appear to other programs as 
still active.

I'll be posting the solutions sent to me on the Club Tech Web site 
next week and will provide the URL in the next newsletter. Thanks to 
all the readers who responded!


************************** ADVERTISING **************************:
SAVE BIG AT MANTA'S SUPER SERIES SALE!
Now is the time to order your personalized AS/400 training package 
from Manta.  Now through October 15, save 25% on all CBT series, 
combination packs, or the entire library.  Take advantage of Manta's 
newest CD containing major revisions to the system administration 
curriculum, as well as two new courses: Introduction to Java and 
Streamlining AS/400 Operations. Find out why so many people are 
turning to Manta for their AS/400 training needs! Visit 
http://www.as400network.com/store/cdrom/Manta.html for more 
information!

********** ABOUT CLUB TECH PROGRAMMING TIPS NEWSLETTER **********:

Club Tech Programming Tips Newsletter is published every other 
Wednesday. We publish Club Tech Systems Management Newsletter on 
alternate Wednesdays. Also from NEWS/400, NEWSWire/400 is published 
Tuesdays and Thursdays and covers the latest AS/400 industry news. 
NEWSWire/400 Product Extra is published Mondays and contains the 
latest new product announcements. All are *FREE OF CHARGE*!

FOR NEW SUBSCRIPTIONS, you can subscribe by joining the AS400 Network 
with a handy Web form at http://www.as400network.com/join/ .

TO UNSUBSCRIBE or CHANGE E-MAIL ADDRESSES, go to
http://www.as400network.com/info/profile/profilelogin.cfm . If you 
don't have Web access, you can also unsubscribe to this newsletter 
(without unsubscribing to NEWSWire/400) by replying to this message 
with UNSUBSCRIBE in the Subject line.

You are subscribed as: danny@multipolar.co.id

IF YOU HAVE a technical question, please submit it to 
clubtech@as400network.com or post it in the appropriate 
as400network.com forum. If you have a response to a tip in this 
newsletter, please e-mail clubtech@as400network.com .

IF YOU WANT TO SPONSOR a Club Tech Programming Tips Newsletter, please 
contact your AS400 Network sales manager. Click here for details: 
http://www.as400network.com/info/mediakit/Sales/Index.htm .
___________________________
Copyright 2000, NEWS/400
http://www.as400network.com
>>> "Prakash Harri" <PHarri@clover.co.za> 09/28 8:39  >>>
Does anyone know how to access anything in another job's qtemp ??

Regards
Prakash

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com 
+---
 
!
   !
 

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---