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:
<<SNIP>> Now I have to figure out why SNDSRVRQS and all that works
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:
"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?
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
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.