MI solution to display another jobs LDA?
Qile
our business uses the LDA heavily to set up attributes for our many warehouse
users scattered across the country. Sometimes as part of troubleshooting a
problem we need to take a look at the contents of a users LDA. Suffice to say
it is not easy. What normally ends up happening is that we change their
profile to LMTCPB(*NO), temporarily change the users password, sign on as them
and then get to a command line to dump the lda, sign off and reverse the
process.
Now it seems that it should be so simple to look at another jobs LDA, but yet
it isn't (as far as I know). I have heard rumors of MI programs that will do
this.
If so does anyone have some sample code I could get? or at least some
guidelines as to how to do it. It would really make our tech support staff
happy (myself included).
thanks in advance!!!
-Paul Jackson
Tech Support Programmer
Costco Wholesale
Issaquah, WA
(425) 313-8594 Fax: (425) 313-6800
Qile@AOL(nospamthankyoumaam).com
Charles R. Pence
> <<SNIP>>
> Now it seems that it should be so simple to look at another jobs LDA, but yet
> it isn't (as far as I know). I have heard rumors of MI programs that will do
> this.
> If so does anyone have some sample code I could get? or at least some
> guidelines as to how to do it. It would really make our tech support staff
> happy (myself included).
The easiest way IMO is to STRSRVJOB on the job whose *LDA you need to
review. Then issue the command: DMPSYSOBJ *PCS. Next issue the
command:
DSPSPLF QPSRVDMP SPLNBR(*LAST), search on *LDA in the splf;
on the left of spool data is an offset -- record it. Finally issue:
DMPSYSOBJ *PCS OFFSET(recorded_offset) followed by the command:
DSPSPLF QPSRVDMP SPLNBR(*LAST) and review *LDA starting at x/60 I
think.
FWiW the offset into the *PCS AFaIK is always OFFSET(230) <ie. I have
never seen otherwise>; so you may be able to create a command having a
CLP rqs:
DMPSYSOBJ *PCS OFFSET(230)
DSPSPLF QPSRVDMP SPLNBR(*LAST)
DLTSPLF QPSRVDMP SPLNBR(*LAST)
Regards, Chuck
-- Comments provided "as is" with no warranties of any kind whatsoever.
Douglas Handy
> What normally ends up happening is that we change their
>profile to LMTCPB(*NO), temporarily change the users password, sign on as them
>and then get to a command line to dump the lda, sign off and reverse the
>process.
Say what? When you sign on, the *LDA will be blanks. How do you then
dump the *LDA as it existed when the user called the help desk?
>Now it seems that it should be so simple to look at another jobs LDA, but yet
>it isn't (as far as I know). I have heard rumors of MI programs that will do
>this.
Why don't you just create a command to let the user display or print
the LDA? Here is a sample, which is a modified version of the
DSPDTAARA command, but only allows access to the *LDA. You can change
the defaults for Output() and Outfmt() to suit your needs, such as
having it automatically print.
This would have to be run by the user, but if you use the CRTCMD parms
given below they can run it even with limited capabilites unless they
have menus without a command line. If that is the case you could set
up an attention key program or change the message text for the sysreq
menu options to replace an option with DSPLDA.
/* CRTCMD CMD(DSPLDA) PGM(QSYS/QWCCDSVC) ALWLMTUSR(*YES) + */
/* HLPPNLGRP(QHWCCMD) HLPID(DSPDTAARA) */
CMD PROMPT('Display Local Data Area')
PARM KWD(DTAARA) TYPE(*CHAR) LEN(20) +
CONSTANT(*LDA) DTAARA(*YES)
PARM KWD(OUTPUT) TYPE(*CHAR) LEN(1) RSTD(*YES) +
DFT(*) SPCVAL((*) (*PRINT L)) EXPR(*YES) +
PROMPT('Output')
PARM KWD(OUTFMT) TYPE(*CHAR) LEN(1) RSTD(*YES) +
DFT(*CHAR) SPCVAL((*CHAR C) (*HEX H)) +
EXPR(*YES) PROMPT('Output format')
PARM KWD(SYSTEM) TYPE(*CHAR) LEN(1) CONSTANT(L)
If you want printouts to go to a specific outq or be placed on hold,
you will need to create your own CPP with something like:
PGM PARM(&dtaara &output &outfmt &system)
DCL &dtaara 20
DCL &output 20
DCL &output 20
DCL &system 1
OVRPRTF QSYSPRT HOLD(*YES) OUTQ(HELPDESK) USRDTA(LDA)
CALL QSYS/QWCCDSVC ('*LDA' &output &outfmt 'L')
DLTOVR QSYSPRT
ENDPGM
Then name that CPP in the CRTCMD instead of QSYS/QWCCDSVC. The extra
declares for &dtaara and &system could be removed if you change the
command source to remove the constant parameters.
There are other ways to get at this, but why bother?
Doug
Douglas Handy
> PGM PARM(&dtaara &output &outfmt &system)
> DCL &dtaara 20
> DCL &output 20
> DCL &output 20
> DCL &system 1
> OVRPRTF QSYSPRT HOLD(*YES) OUTQ(HELPDESK) USRDTA(LDA)
> CALL QSYS/QWCCDSVC ('*LDA' &output &outfmt 'L')
> DLTOVR QSYSPRT
> ENDPGM
The declares should have been:
DCL &dtaara 20
DCL &output 1
DCL &outfmt 1
DCL &system 1
Cut and paste while typing strikes again!
Njal Fisketjon (Njål Fisketjøn)
>Hello,
>our business uses the LDA heavily to set up attributes for our many warehouse
>users scattered across the country. Sometimes as part of troubleshooting a
>problem we need to take a look at the contents of a users LDA. Suffice to say
>it is not easy. What normally ends up happening is that we change their
>profile to LMTCPB(*NO), temporarily change the users password, sign on as them
>and then get to a command line to dump the lda, sign off and reverse the
>process.
>
>Now it seems that it should be so simple to look at another jobs LDA, but yet
>it isn't (as far as I know). I have heard rumors of MI programs that will do
>this.
>If so does anyone have some sample code I could get? or at least some
>guidelines as to how to do it. It would really make our tech support staff
>happy (myself included).
>
>thanks in advance!!!
>
If you really want to (and are not running under security level 40 or higher), you can use the
following procedure in a MI program:
Find the job in the WCBT
In the jobs PCS there's a system pointer to the LDA at offset x'230'
Inside the QLDA space (type x'19CE') the data starts at offset x'60'.
A simpler approch may be to
Set up a break message handling program for the job (if you play dirty you can do this in MI 'on the
fly')
Send commands to the job in question (via the break message handling program) to print the LDA
Njål Fisketjøn
e-mail: nfis...@hesgrp.com
http://www.robin.no/~nfisketj
Raul
you can do it in MI, but if you are running security level 40 (or you simply don't
have the time to reinvent the wheel), you can acquire a product to do that. If you
allow me to do so (advertisement follows!), I'd dare to encourage you to download
our Tango/04's VISUAL Support tool from http://www.tango04.com (you can use it for
free for 30 days).
It can be very useful in many tech-support situations, as you can change (not only
see) the LDA, and change the job library list, capture the screen up to the last
keystroke, execute any command, chat with the end user, and even browse the source
code that is being executed, seeing variable values and application structure on
the fly.
Forget me for this. However, if you have the time and decide to write your own
utility in MI anyway, the solution posted by Njål works (good one, Njål!), but he
is right in saying that is a lot of work and it will not work if you use security
levels higher than 30. I suggest you get the MI manuals (you have to pay for them,
and they are not in the IBM web site), the S/38 microfiches (not an easy task),
and a good MI source-level debugger.
Hope this helps.
Raul Cristian Aguirre
from Barcelona, Spain
Qile wrote:
> Hello,
> our business uses the LDA heavily to set up attributes for our many warehouse
> users scattered across the country. Sometimes as part of troubleshooting a
> problem we need to take a look at the contents of a users LDA. Suffice to say
> it is not easy. What normally ends up happening is that we change their
> profile to LMTCPB(*NO), temporarily change the users password, sign on as them
> and then get to a command line to dump the lda, sign off and reverse the
> process.
>
> Now it seems that it should be so simple to look at another jobs LDA, but yet
> it isn't (as far as I know). I have heard rumors of MI programs that will do
> this.
> If so does anyone have some sample code I could get? or at least some
> guidelines as to how to do it. It would really make our tech support staff
> happy (myself included).
>
> thanks in advance!!!
>
Ken Rokos
command to another job, access another job's QTEMP. Sounds a lot like
the Tango product described in another message. Don't remember the
cost. Bytware, 530-273-4595, 11471 Sutton Way, Ste. 204, PO Box 1112,
Grass Valley, CA, 95945.
Ken