×
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.