×
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.
Peter Dow wrote:
From your further explanation, it would appear that the CPYF
tried to send the CPC2957 completion message, but failed to do
so because by that time the device was already not
communicating.
<<SNIP>>
For lack of both spooled joblog and spooled stack, both which
would include timestamps and thus correlation betwixt, I had to make
some assumptions about the times when the messages in the joblog
actually transpired and what the programs were processing.
For example I had inferred the timing from the description [from
a question actually] of the scenario; i.e. by asking "why did it
pause at the CPC2957 completion message?" I had concluded that the
message CPC2957 was visible in the active joblog when a DSPJOBLOG
was issued before the reconnect.
So although I concentrated first on the completion, I tried to
allude that it may have been instead, a status message, that caused
the device failure to have been detected. From the timestamps, it
could have been more obvious. From the given stack and that the
reconnect produced the CPF5104 to the program writing to the
QDDSPMSG, I had expected that it was status messaging which caused
the device failure to be detected. Since status messaging is
/recoverable/, I was hesitant to suggest that origin any more
confidently, even with what was seemingly obvious support from the
stack.
However I have since noticed that I *mistook* the file QDDSPMSG
as an indication of the UIM message line. Obvious to me *now*, that
by its naming, that *FILE object is the DSPF implementing the DSPMSG
feature. I should have known something was amiss in my recollection
of the status messaging, having seen QWTPECTL which confused me;
i.e. it seemed out of place, but I simply ignored it. Ughh :-( Now
I recall that program name as implementing the break\notify message
event. The program QMHDLVMS "deliver message" and more importantly
the program QMHDSMSS is "display message" *not* a "send status
message" on which I had incorrectly based some comments.
I will review the given again, with that correction, and comment
further in a separate reply.
Regards, Chuck
midrange.com
