Kris,

I did say, "... or is it necessary to use a PIPE..." I have that type of
code in several places, too. Presumably, the incidence of errors will be
very low, and they are the only reason for imbedding the command in a
PIPE; a return code of 0 is a success. The overhead of using a Pipe so
that I can catch the one error in thousands of passes is not necessary.
It should be far cheaper to issue the command and then retry in a Pipe
only when the operation fails. 

That said, I would rather not have to use a Pipe for this at all, but
for that I need a way to correlate return code with error condition. 

Regards, 
Richard Schuh 

 

> -----Original Message-----
> From: The IBM z/VM Operating System 
> [mailto:[email protected]] On Behalf Of Kris Buelens
> Sent: Tuesday, March 31, 2009 12:36 AM
> To: [email protected]
> Subject: Re: VMTAPE MOUNT Command
> 
> Why not always imbed the MOUNT in a PIPE?  I've got lots of 
> code like this
>    'PIPE COMMAND CMDCALL someSFScmd',
>         '|VAR EMSG |DROP',   /* take emsg/remove header */
>         '|...analyze the response ....
> if rc<>0 then do
>    inform enduser 'Command xyz failed:' emsg
>    .....
> The CMDCALL is typical for CMS commands, it assures an 
> errormessage is generated, even when executing the command in 
> "address command" mode.
> 
> 2009/3/30 Schuh, Richard <[email protected]>:
> > Is there documentation, in one place, of the possible 
> non-zero return 
> > codes from a VMTAPE MOUNT command, or is it necessary to 
> use a PIPE to 
> > trap the return code and message? I have a service machine 
> that needs 
> > to mount tapes and perform functions for many users. It 
> would be nice 
> > for the server to be able to tell a user that a request 
> failed because 
> > an input tape could not be mounted, and be able to say why 
> the mount failed.
> >
> > The VM:Tape Messages and Codes manual appears to have the 
> information, 
> > however, the user messages are intermingled with the system and 
> > operator messages. Furthermore, the message numbers do not 
> match the return codes.
> > For example, if a MOUNT command is entered with an invalid virtual 
> > address, the message number is 44, but the return code is 24.
> >
> > The mount requests will succeed most of the time. I suppose that I 
> > could request the mount using a simple command and, if the 
> return code 
> > is non-zero, reissue it in a pipe to trap the response. 
> However, that 
> > seems a bit hokey.
> >
> >
> > Regards,
> > Richard Schuh
> >
> 
> 
> 
> --
> Kris Buelens,
> IBM Belgium, VM customer support
> 

Reply via email to