If QSTRUP is "owned" by QSECOFR or a profile with QSECOFR's authority, your
issues will go away. QPGMR and others will adopt the authority for the
duration of QSTRUP running.
Paul Nelson
Cell 708-670-6978
Office 409-267-4027
nelsonp@xxxxxxxxxxxxx
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Wednesday, July 06, 2016 1:44 PM
To: 'midrange-l@xxxxxxxxxxxx'
Subject: RE: 3rd party app failed to start on IPL, because QPGMR passwordwas
set to *NONE
Chuck,
Response from the 3rd party vendor.
The profile starting the software must have a password and be capable of
signing on - or the java will not start.
I do have SI60622 installed.
This issue only occurs during IPLs, which default to QPGMR running the
QSTRUP job.
I would really like to change QSTRUP to run as a different user, would solve
this and many other issues related to QPGMR having insufficient authority to
run a process.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
CRPence
Sent: Wednesday, July 06, 2016 1:40 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: 3rd party app failed to start on IPL, because QPGMR password
was set to *NONE
On 06-Jul-2016 10:07 -0500, Steinmetz, Paul wrote:
I IPL'd Production LPAR this past weekend for latest V7R1 cum,
TL16120, all latest groups, etc. That all went good, everything
working fine.
However, 3rd party app failed to start on IPL, because QPGMR password
was set to *NONE.
Is this valid?
Unsure what "this" is. But QPGMR certainly can have PASSWORD(*NONE)
established via Change User Profile (CHGUSRPRF), and a 3rd party app
certainly could be coded [explicitly or implicitly so as] to require that a
particular user profile must have a password.
I'm really getting tired of all the various issues with QPGMR, QSTRUP,
IPL etc.
Request data queue operation failed
com.ibm.as400.access.AS400SecurityException: Password is *NONE.:QPGMR
The 3rd party application appears to be using the Java ToolBox for an
access class, apparently per an attempt to use a DataQueue method. What are
the requirements and resolution to difficulties, would seem more
appropriately directed to the service provider being used for that 3rd party
app,; especially if the User Profile (USRPRF) QPGMR had been and is still
correctly established, as desired\intended, on that logical partition. They
should be able to identify if the issue is their own, as something with
their [mis]use of the ToolBox or OS, or something incorrect with how the
ToolBox or OS responds to or processes their requests.
Or, a web search may yield some APAR\PTF that might address a
[presumably] like-issue. For example, there is an apparent JT400 issue for
which that security exception may be issued also diagnosing the password of
*NONE, for which IBM i 7.1 is revealed as having the latest available PTF
R710 SI60622, a PTF that is not yet on a cumulative, having been provided
for the APAR SE58670 with an apparent implication of something being wrong
with some provided Java extensions.
[
http://m.ibm.com/http/www-912.ibm.com/n_dir/nas4apar.nsf/ALLAPARS/SE58670]
--
Regards, Chuck
--
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.
midrange.com
