In CL, how can you determine if a known User Profile is signed on?

[Guest.Visitor]

Other than using APIs, you could try the following: For users signed on thru 5250 (though possibly disconnected): WRKUSRJOB USER(xxxxxxxxxx) STATUS(*ACTIVE) OUTPUT(*PRINT) JOBTYPE(*INTERACT) To see if they're logged on in any way, including server jobs serving them, use WRKOBJLCK OBJ(xxxxxxxxxx) OBJTYPE(*USRPRF) OUTPUT(*PRINT) The standard kludge for commands that don't have outfiles is to copy the splf to a pf, then read the pf and scan for their equivalent to "none found". For WRKUSRJOB, it's "No jobs to display". For WRKOBJLCK, it's "There are no locks for the specified object". These assume the program has sufficient authority to the commands and profiles to do this.

[Guest.Visitor]

Ken Rokos wrote: > To see if they're logged on in any way, including server jobs serving > them, use > > WRKOBJLCK OBJ(xxxxxxxxxx) OBJTYPE(*USRPRF) OUTPUT(*PRINT) I wonder if a better method would be to use the AlcObj command? Bill

[SoggySand]

Thanks Ken, While waiting for replies to my post, I continued to experiment and came up with something similar to your idea. My RPG program that needed to know who is "on" has an array of valid user profile names. It then calls the following CL program: DLTSPLF FILE(QPDSPAJB) /* Just in case */ DLTF FILE(QTEMP/USERSON) /* Just in case */ WRKACTJOB OUTPUT(*PRINT) SBS(QINTER) CRTPF FILE(QTEMP/USERSON) RCDLEN(132) CPYSPLF FILE(QPDSPAJB) TOFILE(QTEMP/USERSON) The RPG program then can use QTEMP/USERSON (the active session user ID is in columns 17-26) to lookup the array, and matches are active user sessions. It works fine, but if anyone has suggestions for improvements I welcome them.

[SoggySand]

I'll try the post again, with the code easier to read.

---

Code

[dacust]

ALCOBJ can't be used on a *USRPRF.

[BVining]

This approach does have a few exposures/considerations. Printed reports are not considered to be a formal programming interface by IBM and so the report layout may change with new releases and/or when installing different national languages as translations may cause movement of the columns. You also are assuming that the job user name is in fact the user of the job. This is not always true, especially in server environments. You may have jobs that have QUSER for instance in the job name but the current user is a different user profile. This can be seen by displaying a job and taking option 1 (Display job status attributes) and Current user profile. A "safer" approach would be to use the List Job (QUSLJOB) API. This API can return active jobs and provide both the job user name and the current user profile (with format JOBL0200 and key 305. It may not be as easy to use as the *print option of wrkactjob but would be more dependable.

[SoggySand]

Thanks.

[Guest.Visitor]

You may not be able to allocate a user profile, but you can try to allocate the user message queue. If you can allocate the message queue, the user IS NOT signed on. If you can not allocate the message queue, the user IS signed on. I don't usually like to use reverse logic, but in this case I don't know of an alternative. Hope that helps, --Bruce

---

Code