Failed call to QCMDEXC

[TedHolt]

I'd be curious to hear of anyone's experiences calling QCMDEXC from COBOL programs. I'm working on a program and QCMDEXC has just ended abnormally. I've never found a way that I like to trap a failed call. (That is, I am not thrilled with condition handlers.) I'm debating writing a CL program to do the call and pass back a status parameter. Just wondered what others are doing.

[Terry Wincheste]

Re: Failed call to QCMDEXC

If I am doing something very *simple* like an OVRPRTF then I'll use QCMDEXC, otherwise, calling a small CL program provides way more flexibility IMO. This is especially true with the newer CL enhancements over the last few years. I agree with you on Condition Handlers...hate them with a passion and have never used them except in rare circumstances.

[TedHolt]

Re: Failed call to QCMDEXC

That makes a lot of sense, Terry. Do you have a utility program that you use over and over, or do you write new CL programs as required?

In this case, the call is starting commitment control. I think I'll put a CL program over it to start commitment control, call the COBOL program, and end commitment control.

Thanks for the response, Terry.

Ted

[tomliotta]

Re: Failed call to QCMDEXC

What is "ended abnormally" for QCMDEXC? Was the command malformed? Did the command fail? Or did QCMDEXC itself fail(!)?

[TedHolt]

Re: Failed call to QCMDEXC

The command in the first parm was STRCMTCTL and commitment control was already active. I should have been a little more specific, Tom. Good of you to ask.

[tomliotta]

Re: Failed call to QCMDEXC

It just soaked in that this is COBOL.

Does the CALL ... ON EXCEPTION ... form fit here? A PROGRAM STATUS structure should provide useful error info.

(I've preferred QCAPCMD for quite a few years, though it's hard to give up QCMDEXC for simple things.)

[Terry Wincheste]

Re: Failed call to QCMDEXC

Ted, we wrap most all of our RPG/CBLLE programs in CL programs regardless if they're batch or interactive. For batch processes, this is a no-brainer. For interactive screens, it allows us to do some up-front things like checking for Display Session anomalies (e.g. Client Access not set to default to 27x132), retrieval of the LPAR name in case we wish to redirect print output, etc.

Your commitment control idea seems the smart thing to do...plus you can handle return messages in the CL long before your high-level language program gets called.

[tomliotta]

Re: Failed call to QCMDEXC

I generally prefer executing CL commands in a CL *MODULE wrapper. First, of course, is that it becomes compiled rather than interpreted at run-time. But then, CL has built-in features for detecting and handling CL-related conditions.

I've never quite caught on to the idea of trying to duplicate in RPG the features that CL already supplies. It always feels like I'm reinventing the wheel by coding my own CL processor when a very good one already exists in the job. I do use the various command APIs, but rarely in final production code and only in the simplest forms that never change. STRCMTCTL might fit for command simplicity except I'd probably want to code potentially sophisticated responses to errors, and a CL *MODULE could be better for that part.

[TedHolt]

Re: Failed call to QCMDEXC

I ended up writing an RPG program to run QCMDEXC, trap the error, and return the message ID to the caller. If message ID is blank, the caller knows QCMDEXC ran successfully. The caller can look at the value in the message ID parm and decide to ignore the error or take some action. So far so good.

RPG program CMDEXC:

ctl-opt  actgrp(*caller) option(*srcstmt) main(CmdExc);

/copy prototypes,CmdExc

/copy qrpglesrc,qualpsds

dcl-proc  CmdExc;

dcl-pi  CmdExc;
           inCommand               char(4096)       const;
           inCommandLength         packed(15:5)     const;
           ouMessageID             char(7);
end-pi;

/copy qrpglesrc,qcmdexc

monitor;
   clear ouMessageID;
   QCmdExc (inCommand: inCommandLength);
on-error;
   ouMessageID = psds.ExceptionID;
endmon;
return;

end-proc;

If anybody wants the copybooks, let me know. I'm sure you can figure them out.

Example call from COBOL:

01  CL-command               pic x(64).
01  CL-Command-length        pic s9(10)v9(5) packed-decimal.
01  Message-ID               pic x(7).

*** Turn on commitment control if it's not already active
     move 'StrCmtCtl LckLvl(*chg) CmtScope(*job)'
              to CL-Command
     move length of CL-Command to CL-Command-length
     call 'CMDEXC' using CL-Command, CL-Command-length, Message-ID

*** CPF8351 means that commitment control is already active
     if Message-ID not = spaces
     and Message-ID not = 'CPF8351'
	    ************ handle the error ****************