Chuck,
I'm definitely curious, so if you don't mind posting the code I'd love to see it.
And I appreciate your feedback.
Thanks,
Kurt
-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, March 05, 2013 10:16 PM
To: wdsci-l@xxxxxxxxxxxx
Subject: Re: [WDSCI-L] 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.
--
This is the Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries (WDSCI-L) mailing list To post a message email: WDSCI-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/wdsci-l.
midrange.com
