Is the command owned by QSECOFR?
Is the command secured by an authorization list and *PUBLIC is excluded from using it?
Is the CPP owned by QSECOFR?
Does the CPP have the owner parameter set to *OWNER?
Does the CPP adopt authority (use adopted authority parameter = *YES)?
Do other programs called by the CPP adopt authority?
Gary Monnier
IT Software Engineer CSM, CSPO
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Darryl Freinkel
Sent: Monday, July 25, 2016 1:46 PM
To: Midrange Systems Technical Discussion
Subject: Need to create a program that uses QSECOFR as adopted authority
We have a need to grant the help desk the authority to reset and/or change user's passwords. We have written code to prompt the profile name and then after doing some validation (not QSECOFR...) the program resets the user ID.
The CL program is owned by QSECOFR.
A help desk user, say PETER1, has access to the program via a menu option.
He runs the program and it aborts with a CPF2217 - not authorized to the user profile.
What are we missing here?
I have not done this for many years and my understanding was that if the program was owned by QSECOFR or a profile of *SECOFR class, the program should execute as if the program was being run by QSECOFR.
So why is it aborting?
What am I missing?
TIA
--
Darryl Freinkel
--
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,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
As an Amazon Associate we earn from qualifying purchases.