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



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.