To extend your punch suggestion a bit, rather than saving the status of the
punch and using it to test the user, would it be more elegant to define a
"new" punch at another address, spool that one, then detach it?

Such as:

Cp define pun 01d
Cp spool 01d to foobar
HCPCSP053E FOOBAR not in CP directory
Cp detach 01d

This removes the need for saving and restoring the original punch's status,
and shortens the code path considerably. It's a virtual system, so let's
make use of as much of it as we can... :-)

-- 
   .~.    Robert P. Nix             Mayo Foundation
   /V\    RO-OE-5-55                200 First Street SW
  /( )\   507-284-0844              Rochester, MN 55905
  ^^-^^   ----- 
        "In theory, theory and practice are the same, but
         in practice, theory and practice are different."




On 10/25/07 10:24 AM, "Marty Zimelis" <[EMAIL PROTECTED]> wrote:

> Dave,
>    You're correct that Ken's "LINK userid" is more elegant than my proposed
> "SPOOL PUN userid".  However, I would urge you NOT to use the "QUERY
> userid"-based solutions.  That's relying on the fact that the userid doesn't
> match any existing parameter to the CP QUERY command.  If the userid you're
> testing matches a parameter of the command or if IBM should enhance the
> command adding a parameter that matches a userid you're testing, the test
> will produce "misleading results."
> 
> Marty
> 
>> -----Original Message-----
>> From: The IBM z/VM Operating System
>> [mailto:[EMAIL PROTECTED] On Behalf Of Dave Hansen
>> Sent: Thursday, October 25, 2007 11:05 AM
>> To: IBMVM@LISTSERV.UARK.EDU
>> Subject: Re: How can I find if a user is defined in the
>> directory (without looking!)?
>> 
>> Hello again,
>> 
>>    Thank you for all your suggestions.  I did like Kens
>> response with the diagrc in it.  I did some testing and for
>> simplicity I favor just checking
>> the return code on the CP Q userid.  I had forgotten about
>> our friend EXECIO that stacks the output and I liked the PIPE
>> that put the results in a
>> stem variable.
>> 
>> 
>>       Thanks again to all,  Dave Hansen
>> 

Reply via email to