Re: RDP Debug when STRDBG active

On 05 Mar 2013 14:33, Anderson, Kurt wrote:

I was actually avoiding putting a MONMSG on STRDBG in case it
errored due to some reason other than debug already being active.

That is a concern. Because the escape error messages for STRDBG are not [documented as being] granular, there is more concern for using MONMSG than if there were a specific escape message issued for "job is being serviced by another job". That is because handling the errors is instead mostly dependent upon what is\are the preceding diagnostic message(s). Placing the STRDBG UPDPROD(*NO) request in its own CLP makes the processing easier, and keeps cleaner the CLP that otherwise would be wanting to issue the request to STRDBG UPDPROD(*NO).

Can you think of any other reasons why STRDBG would fail?

None that I am aware of; well, specifically for monitoring the CPF1999 error. But unfortunately for lack of documentation on what are the possible preceding diagnostics, one can only presume that the only diagnostic will be the CPF1937. Best to code additionally, and specifically, for the CPF1937 as the expected preceding diagnostic.

I know the command can fail for CPF1992, probably for CPF1993, and I suppose even for CPF1994 [as undocumented :-( *ESCAPE Messages], so even more reason than ever to avoid monitoring CPF0000 or even CPF1900 message ranges.

There is also the possibility for CPF0001, as for any command. But for STRDBG the error is more likely and most likely a failure is due to the preceding CPD0039 "Command &2 not valid in this mode." diagnostic because of the attribute setting of MODE(*PROD) on the command definition for STRDBG.

Should I not be concerned with that?

Probably not too much, if monitoring just for the CPF1999; and possibly even not too much of a concern if also monitoring for CPF0001 to ignore the possibility that the STRDBG has run already in the job.

However if interested, I have just finished coding a new\reincarnated version of DLWUPDPROD command and a CLP as CPP from what I remember of what I had written in the past... but I made the code just ignore both "debug not allowed; already in debug" and "debug not allowed; this job is being serviced by another job", and for anything other error to move the diagnostics and resend the exception to the caller. Let me know if you want a copy... and I can post a copy to code.midrange.com

Regards, Chuck

CRPence on Tuesday, March 05, 2013 3:51 PM wrote:

<<SNIP>> This means that STRDBG also fails <ed: when the job
issuing the STRDBG is being serviced by another job>, but instead
of due to mode-checking by the command analyzer [ed: per MODE() on
CRTCMD], due to the debugger detecting that the job is being
serviced by another job.

To learn that the job is being serviced is straightforward; using
the aforementioned ability of the STRDBG to detect and diagnose the
condition:

CPF1999 on STRDBG preceded by the diagnostic CPF1937 "STRDBG is not
allowed because job is being serviced." is how I checked this for
the /same/ means to prevent updating production files in my job; no
PGM() was specified for debug however. I actually had created a CL
command called Disallow Update Production DLWUPDPROD that did the
STRDBG, monitored for the failure, verified the expected diagnostic
for the monitored failure and then cleared the messages, or
effected the Start Debug with UPDPROD(*NO), and then returned, or
determined that the condition was not for the expected diagnostic
and sent the diagnostic as the escape to the invoker to know
something unexpected occurred.