1)We use AJS heavily, no IBMUSR on any of our LPARS.
However, if you set up multiple environment for AJS, (we have this on our R&D LPAR) then you must set up users and data libraries.
This is only done in Ops Nav.
This could be where the lock is coming from.
2) The other possibility is that someone create a service account called IBMUSER, and some automated processes may run under that user.
Do a WRKUSRJOB IBMUSR, see what results.
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, March 27, 2014 5:11 PM
Subject: Re: user IBMUSR - is this necessary?
On 27-Mar-2014 13:02 -0700, Stone, Joel wrote:
I wanted to disable this user profile for compliance and security.
However it seems tied somehow to Advanced Job Scheduler in that WRKJOB
shows a lock for job QIJSSCD.
Even if that non-IBM user has some relation to the AJS on that system, the change to disable the user with a request to CHGUSRPRF IBMUSR PASSWORD(*NONE) is unlikely to have any negative impact on typical batch processing; i.e. a job can still be started with that profile, but the user would be unable "signon" with credentials. Nor would CHGUSRPRF IBMUSR STATUS(*DISABLE) have any effect for typical batch processing, AFaIK.
Any idea why this user profile is locked here? And is this user
profile necessary to run AJS?
Is the full WRKJOB OUTPUT(*PRINT) available?
What is the "Current user" for the job? The job type? AFaIK there is no /method/ available to directly request a lock of a *USRPRF object; the lock on a profile appears normally, due to the Work Management for the job\work related to that profile. So for example, if a job switches to another user, that should effect a lock on the switched-to user just like the original current-user should have been locked to the job. I suppose even while holding a handle for the original profile [for which the job is named], the lock on the initial user might be dropped.?
<ed: Job Locks shows Job QIJSSCD with User QIJS holding a *SHRRD on
the IBMUSR *USRPRF object; and just one more lock on a *LIB>
Was the provided output from WRKJOB OPTION(*JOBLCK) truncated, without any indication; i.e. seems the job would likely have many more locks. For example, I would have expected to see a *SHRRD lock on the QIJS *USRPRF object.
Was the joblog reviewed for any errors; conditions that might imply an origin for a lock that was not properly released or implying a reason the profile might need to be allocated [though as I alluded, there is presumably no explicit locking support\method].
I would suggest looking at the details from DSPOBJD IBMUSR *USRPRF for both DETAIL(*SERVICE) and DETAIL(*FULL), most notably the "created by user" and the creation date and release level. That might point to a responsible party, for the existence of the profile. Output from DSPUSRPRF QIJS TYPE(*BASIC) may be worthwhile to review as well; I do not recall if [supplemental] group profiles are locked by the job.
IIRC that job starts from an autostart job entry in the QSYSWRK Subsystem Description, using the *JOBD QIJSSTRJD in QIJS; though perhaps that job was since changed to be a system-job. If still an AJE, then if the USER() for that Job Description had been changed to IBMUSR, I would expect that the job name would have been *N/IBMUSR/QIJSSCD instead of *N/QIJS/QIJSSCD. If the current user had been swapped from QIJS to IBMUSR, I am not sure where that would be done, but I would check the job routing or any exits that exist for the feature. Normally exits are documented with a warning that swapping the user is unsupported, but there is nothing that actually prevents the action.
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l