I was actually avoiding putting a MONMSG on STRDBG in case it errored due to some reason other than debug already being active. Can you think of any other reasons why STRDBG would fail? Should I not be concerned with that?
-Kurt
-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, March 05, 2013 3:51 PM
To: wdsci-l@xxxxxxxxxxxx
Subject: Re: [WDSCI-L] RDP Debug when STRDBG active
On 05 Mar 2013 12:06, Anderson, Kurt wrote:
That makes sense and is what I was expecting. But if it's <ed: the
RDP debugger is> running STRDBG immediately after the STRSRVJOB, why
wouldn't the CHGDBG in the CL complete successfully? Maybe because
it's in the 'wrong' job? Meaning if you remotely (from another job)
debug a job, the CHGDBG that occurs actually isn't aware of the
'remote' debugging that is occurring.
Correct. The job that is being debugged is either explicitly or implicitly the /serviced/ job. When STRDBG is issued successfully in a job, then implicitly the job is self-servicing, and debug is active in that job; the job is both the servicing-job and the serviced-job. A CHGDBG issued in that self-serviced job functions without error, acting against the debug environment started previously in the same job.
However when CHGJOB is issued within a job that is serviced from another job, the CHGDBG fails because debug has not been started in a self-serviced job; i.e. an externally serviced job is not allowed to perform any debug activity on itself. This means that STRDBG also fails, but instead of due to mode-checking by the command analyzer, due to the debugger detecting that the job is being serviced by another job.
If that's the case, which now starts to make sense, I wonder is there
a way for the CL to know it's being remotely debugged so I can check
that?
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.
--
Regards, Chuck
--
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
