× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.