Re: More, Re: Weird server-crashing-on-takeoff issue on customer system, involving QTMMCUTL -- H E L P !

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

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:
<<SNIP>>

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

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.