Re: PTF 5770TC1-SI54738 and QSECOFR *USE

Check out this thread...
http://archive.midrange.com/midrange-l/201407/msg00845.html

You said you'd have SI53118 staged to apply, did you do so? Is it applied?


On Wed, Oct 1, 2014 at 12:45 PM, Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
wrote:

All,

Yesterday morning about 7:20 we had a power outage that lasted 20-25
minutes. The UPS power handling program shut the System i 520 (V7R1) in

an

orderly fashion. I had about 30 PTFs set to apply during an IPL, so they
did.

Later in the day I found that emails were not being sent from the IBM

i. I

checked the joblog of the forwarding job of ESEND to see what was
happening. I found this error over and over:

CPF22E9 Escape 40 09/30/14 09:21:57.774322

QSYPHDL

QSYS *STMT QTMMSNDM QTCP *STMT
From module . . . . . . . . :
QSYPHDL
From procedure . . . . . . :
validateUser__FPCcT1CcCiCUiiP18SYCB_UserProfil
e_TP14SYCB_GrpList_TPc
Statement . . . . . . . . . : 178
To module . . . . . . . . . :
QTMMSNDA
To procedure . . . . . . . :
QtmmSendMail
Statement . . . . . . . . . : 61
Message . . . . : *USE authority

to

user profile QSECOFR required.
Cause . . . . . : When a password

of

*NOPWD is specified, then *USE
authority to profile QSECOFR is
required. Recovery . . . : Have the
security officer issue the request
for this user profile or have the
security officer give you *USE
authority to user profile QSECOFR.

I looked through all the PTFs that were applied and 5770-TC1 SF54738 is

the

only one that has anything to do with email. The cover letter contains:

DESCRIPTION OF PROBLEM FIXED FOR APAR SE60092 :
-----------------------------------------------
When using the SNDSMTPEMM command a MIME file is created in
/tmp. The APIs then send this MIME file. When it is created it
is created with an owner of either QMSF or QTCP, but then a swap
is done to the user that issued the command and this causes an
AF entry.

ESEND predates the SNDSMTPEMM command but I'm guessing it uses the same

API

somewhere along the line. To get around the problem I granted PUBLIC

*USE

access to QSECOFR, for now.

Does this seem to you that this PTF is the culprit? The description of
problem fixed does not seem an exact fit to me, it seems more the

opposite

in that I wasn't getting authority failures before, but now I am.

I assume that PUBLIC *USE access to QSECOFR is not a good idea? Is it

PMR

time?




--
Jeff Crosby
VP Information Systems
UniPro FoodService/Dilgard
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
www.dilgardfoods.com

The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.
--
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.

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