Sir Rob, I had a look at your promising "conditional-output-of-cms-command.
Did you ever use it in practice? Because: most CMS commands do not produce
error messages when started in "command" mode. To get the reliability of
"command" (no execs called by accident) and the advantage of having error
messages being produced. For example:
address command 'CMDCALL STATE some file'
if rc<>0 then exit rc
I found this technique very suited to handle SFS commands, their RC is very
often not unique for various errors. So for example:
'PIPE COMMAND CMDCALL QUERY LIMITS FOR xyz SFSabc:',
'|VAR EMSG', /* pass error or header to REXX */
'|DROP', /* Drop header or error msg */
'|....'
if rc<>0 then call errExit rc,'Something is wrong:',emsg
And, for you subroutine:
'PIPE (end ? name OHCMS.EXEC:8)',
'? var cmd',
'| insert /CMDCALL /', /* make the command produce error messages */
'| c: not command ',
'| strnfind ,0, ',
'| d: dam ',
'? c: ',
'| buffer ',
'| d:',
'| cons'
2011/6/30 Rob van der Heij <[email protected]>
> On Thu, Jun 30, 2011 at 3:33 PM, Paul Gilmartin <[email protected]>
> wrote:
>
> > I suppose this is useful in the case where want the side effects
> > of the preceding command, but not its output. Nowadays, given the
> > prevalance of PIPE, GETFMADR ought to have a (NOSTACK) option.
>
> I believe it helps to show unexpected output rather than ignore it
> because you did not expect any. It's very frustrating to see a tool
> exit with RC=28 and maybe even report "File not found" where the
> original messages would have told me *which* file was missing. It's
> not always that simple, so I did this one a while ago:
> http://rvdheij.wordpress.com/2008/12/19/conditional-output-of-cms-commands/
>
> The advantages of a generic interface are obvious. If we were to
> design the CMS again now that we have CMS Pipelines, nobody would care
> about STACK, FIFO, LIFO, and STEM options for various commands.
>
> | Sir Rob the Plumber
>
--
Kris Buelens,
IBM Belgium, VM customer support
