Re: PTF cover letter test

On 11-Dec-2015 07:48 -0600, rob wrote:

On 11-Dec-2015 06:22 -0600, rob wrote:

I can do SNDSRVRQS and all that, but now none of my partitions can:

SNDPTFORD PTFID((SF98720))
Object QESE203207 type *DTAQ created in library QGPL.
Sending PTF order 1534524566.
Object QESE203207 in QGPL type *DTAQ deleted.
CPF8C24 - Error occurred while processing request.

From program: QESRSPTF <<SNIPped; add: msgCPF8C24 F/QESRSPTF>>

Not really the issue, but I tried this:
[http://www.ibm.com/support/docview.wss?uid=nas3f4d1150fc7b2391386257e490057fd3b]
"SI56820 - OSP-OTHER-MSGCPF8C32 ..."

Anyone else running into this or do I need to check to see what evil
things my network guy has been up to?

<<SNIP>> Now I have to figure out why SNDSRVRQS and all that works
but not SNDPTFORD. If I talk to the network guy first thing he's
going to ask me is "what ports".
Guess I could open a ticket with IBM...

IMO, the latter.

If for no other reason than the implication by the message "Recovery" text that there should be "previously listed error messages" diagnosing the problem origin, but [as inferred from what was shown in the OP] there were none. Even if the origin of the failure of the Send PTF Order (SNDPTFORD) request was "unable to initiate comm" or "could not contact the server after success initiating comm", irrespective anything the /network guy/ did, where is the prior messaging diagnosing that condition of the network communications being the issue origin, rather than possibly the actual origin being some negative feedback from the _successfully contacted server_?

That [lack of] messaging is doing a _disservice_ to IBM Service [and the user]:

If the feature terminated for something other than an exception, for which likely there would be prior messages, e.g. perhaps the origin for terminating the request instead were a return code or otherwise negative feedback from a comm conversation with the server, then the Send PTF Order (SNDPTFORD) feature could have logged a prior message that recorded whatever was that effective return code. There is no requirement that such diagnostic messaging must be understood by the user, because additional recovery text hints that the /correction/ to the prior errors may not be possible. A conspicuous benefit of logging such a message, would be that the logged feedback would have been recorded in the joblog, as information that the "service representative" can review; if\when the user deems the necessary next-action will be the [yet additional] recovery text suggesting that "If the problem continues, contact your service representative." And another benefit would be that if the logged reason code could be searched along with the message identifier as a symptom, then that would be an easy way to find assistance [on the web] without needing to actually contact a service representative; having only the quite-generic symptom of msg CPF8C24 F/QESRSPTF, /generically/ issued for any prior "error [that] occurred while processing", approaches being far too nebulous to be worthwhile in a search for a /similar/ problem.