On 04-Aug-2014 12:52 -0500, James H. H. Lampert wrote:
It appears that HelpSystems and Gumbo have seen something like this,
and they both have bulletins out that the SI51172 PTF is broken, and
causes their products to break.
And several places can be found documents stating effectively the
same as Gumbo says: "REMOVE the PTF by running RMVPTF LICPGM(5770TC1)
SELECT(SI51172)." But after that [or just instead], apparently a
supersede is [as documented by CoolSpools] is SI52478 per: "superceded
by PTF SI52478. <www-912.ibm.com/a_dir/as4ptf.nsf/ALLPTFS/SI52478>"
I've never seen anything like this one. It seems to happen for all
ordinary users, but not for certain privleged ones, and just started
Immediately upon launch of the child-server job handling the
connection in our client-server CRM application, the child-server
program for that connection crashes with a CPD0193 on QTMMCUTL.
CPD0193 Diag <<SNIP>> QCACALL QSYS 0355 QCMD QSYS 01C8
Message: Not authorized to service program QTMMCUTL in QTCP.
The symptom is: msgCPD0193 F/QCACALL for service program (SRVPGM)
QTMMCUTL in QTCP
We don't directly reference QTMMCUTL, and it's not listed in the
service programs page of a DSPPGM on the child-server program:
The second level text of the error message is quite clear, the origin
is a CL command invocation rather than a coded procedure invocation;
i.e. the CPD0193 "message is sent for one of the following situations:
-- A command was executed and the command processing program or validity
checking program is bound to a service program that you are not
authorized to. -- A call was made to a program bound to a service
program that you are not authorized to. The call could be from the
command line or during program execution."
I looked at QTMMSNDM, on both our box and the customer box, and both
of them do list QTMMCUTL, but both run under owner authority, both
are owned by QTCP, and both QTMMCUTLs are owned by QTCP, and show the
While authority plays a role, the visible authority to the object(s)
named may not be the source of the issue. The system stores authority
in the system pointer to the object, and that authority can be gained
elsewhere; think /adopted authority/.
I don't know what to make of this. HELP!
Probably best to apply the supersede. Reviewing SI51172 shows
[contrary to above supersede info] that the current supersede is SI53118
for APAR SE58912; that APAR correctly includes the message in symptom
string keyword form [abstract: TCPIP-SMTP-MSGCPD0193 MCH1001 ...], there
is no mention [too typical] of the service program name :-( or names
that might be expected to appear. In such situations one would expect
the PSP to be updated, and that APAR SE58912 would be marked HIPer with
its PTF as supersede to prevent the defect [defective PTF] condition.