Determining Whether a User Is Already Signed On, Take Two
June 21, 2002 Timothy Prickett Morgan
Hey, Ted:
I am writing in reference to the first question and answer that was published in the May 31 “Odds and Ends” column. A reader asked the following: “Is it possible for an initial program to determine if the user who is running it is already signed on with another session?”
The technique that you described for setting an object lock is common, and it was probably adequate for the situation portrayed in the original question. However, the object-lock technique doesn’t tell you anything except ‘This object is/is not locked right now.’ Conceivably, locks can be established by users other than the one being tested. Backups might be running against the user’s library. Locks can come from many sources. This behavior could possibly even be used to bypass some level of application security.
When a more-robust solution is required, you could use the List Job (QUSLJOB) API, as illustrated in the following CL program, which I call CHKACTUSR. Pass to it the user profile name in the first parameter, and it will return the number of active jobs for that user in the second parameter:
ChkActUsr: pgm ( + &pChkUsr + &pNbrLstE + ) dcl &pChkUsr *char 10 /* Number of list entries: Listed jobs... */ dcl &pNbrLstE *dec (7) /*-----------------------------------------------------*/ dcl &usrspc *char 10 VALUE( '#$CHKUSRAC' ) dcl &usrspclib *char 10 VALUE( 'QTEMP ' ) dcl &qusrspc *char 20 dcl &us_hdr *char 150 /* Space header */ /* The qualified search job name... */ dcl &SchJob *char 26 monmsg cpf0000 exec(goto error_rtn) /*-----------------------------------------------------*/ chgvar &qusrsp ( &usrspc *cat &usrspclib ) /* Create usrspc to hold active job data from this usrprf */ call QUSCRTUS ( + &qusrspc + 'TMPLST ' + x'00001000' + X'00' + '*ALL ' + 'Temp list usr jobs ' + '*YES ' + x'0000000000000000' + ) /* */ /* Populate usrspc with appropriate job list data... */ /* */ chgvar &SchJob ( + '*ALL ' *cat + &pChkUsr *cat + '*ALL ' + ) call QUSLJOB ( + &qusrspc + 'JOBL0100' + &SchJob + '*ACTIVE ' + x'0000000000000000' + 'I' + x'00000000' + x'00000000' + ) /* Retrieve the header data... */ call QUSRTVUS ( + &qusrspc + x'00000001' + x'00000096' + &us_hdr + ) chgvar &pNbrLstE %bin( &us_hdr 133 4 ) /*------------------------------------------------------*/ Clean_up: dltusrspc &usrspclib/&usrspc return /*------------------------------------------------------*/ /* */ /* Unexpected error */ /* */ Error_rtn: chgvar &pNbrLstE -1 monmsg (cpf0000 mch0000) return endpgm
— Tom Liotta, The Powertech Group, Inc.
Sponsored By CENTERFIELD TECHNOLOGY |
Take the guesswork out of iSeries DASD Management with disk/HUNTER Why wait until your system slows down or stops because a run-away query eats up your disk space? Many application and database problems can lead to disk spikes, including:
Once installed and configured, disk/HUNTER runs continuously in the background on your AS/400 iSeries, and “wakes up” at intervals that you specify. Every time disk/HUNTER wakes up, it will measure the amount of free space remaining within specified ASPs or all ASPs. When the amount of free space decreases by a user-specified percentage or by a user-specified amount (in megabytes or gigabytes), disk/HUNTER will go to work, generating messages and reports pointing to the origination of the spike. The combination of detection and diagnostic capabilities within disk/HUNTER provides a powerful element of control to iSeries shops that experience high levels of activity and that also need to be proactive in managing storage. To really see how disk/HUNTER can be both an insurance policy and a time-saver in your shop, click here to download a demo or order a no-charge 30-day support-assisted trial evaluation. |