I have set logging off for all my VSE guests, I would have to check
the user backup to confirm that is what is on the *DVHOPT line. Never
needed to know where it was stored as long as it worked.

Ron

On 8/23/07, Horlick, Michael <[EMAIL PROTECTED]> wrote:
> Hi Ron,
>
> Thanks for the info. I was curious what exactly changes when you change the 
> user options. I realized that the user's directory entry changes when you 
> issue the USEROPTN command. The last record changes to something like:
>
> *DVHOPT LNK0 LOG2 RCM0 SMS0 NPW1 LNGAMENG PWC20030317 CRC"ยค
>
> I guess "LOG2 RCM0" means logging and received messages are OFF.
>
> Is that what you have for all your VSE guests?
>
> Thanks again,
>
> Mike
>
> -----Original Message-----
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of 
> Ron Schmiedge
> Sent: August 23, 2007 2:07 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Spool file from DIRMAINT
>
> Mike,
>
> If you want to know why some options have OFF signified with a 2 and
> for others with a 0, I can't help there.  :-(
> Perhaps IBM could explain themselves. I was happy just to find out how
> to to turn it off and stop bugging my VSE guests with all those
> AUTONAME jobs whenever I changed their directories.
>
> Ron
>
> On 8/23/07, Horlick, Michael <[EMAIL PROTECTED]> wrote:
> > Hi Ron,
> >
> > Thanks for the info. I have been playing around with the 'DIRM USEROPTN'
> > command and it is a bit confusing. If I select both LOGGING OFF and
> > RCVMSGS OFF I get :
> >
> > DVHMNU1404E The LOGGING_OFF, RCVMSGS_INFO_OFF fields are conflicting
> > DVHMNU1404E parameters.
> > DVHMNU1406E You selected or filled in too many items; specify 1 item(s).
> >
> > However, I can turn them off individually. But when I go a QUERY , I get
> > :
> >
> > DVHUOP3293I Links:0 Logging:2 RcvMsgs:0 Smsg:0 NeedPass:1 Lang:AMENG
> >
> > Shouldn't that "Logging:2" be "Logging:0" ? I'll try some more
> > combinations
> >
> > Mike
> >
> >
> > -----Original Message-----
> > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
> > Behalf Of Ron Schmiedge
> > Sent: August 23, 2007 1:19 PM
> > To: IBMVM@LISTSERV.UARK.EDU
> > Subject: Re: Spool file from DIRMAINT
> >
> > Hi Mike,
> >
> > I think the answer you are looking for is the DIRMAINT USEROPTN setting.
> >
> > If you turn off both RCVMSGS and LOGGING for a userid, then whenever
> > you change his directory both the messages from DIRMAINT that you see
> > when you are logged on go away (thats the RCMSGS option) and the log
> > file containing the messages is not sent (the LOGGING option). The
> > LOGGING option is automatically turned on if you turn off RCVMSGS, so
> > that the user gets sent the messages he missed in his reader for later
> > viewing. So you probably need to turn off RCVMSGS first then LOGGING.
> >
> > This a change in the default from DIRMAINT R1.5, one that bit us when
> > we went to z/VM 4.4.0. (And found out about from IBM when we opened an
> > ETR).
> >
> > Ron
> >
> > > >>
> > > >> For the longest time we have been getting a spool file sent from
> > > >> DIRMAINT sent to a user who has its directory entry changed (DIRM
> > > >> FOR userid REPLACE).
> > > >>
> > > >>
> > > >>
> > > >> For example :
> > > >>
> > > >>
> > > >>
> > > >> q rdr XXXXXX
> > > >all
> > > >>
> > > >> ORIGINID FILE CLASS RECORDS  CPY HOLD DATE       TIME     NAME
> > > >TYPE
> > > >>
> > > >> DIRMAINT 1813 A PUN 00000006 001 NONE 2006-07-15 00:02:08  XXXXXXX
> > > >DEVVM
> > > >>
> > > >> <mike>
> > > >Ready;
> > > >>
> > > >>
> > > >
> > > >
> > > >>
> > > >> This file once read in by CMS looks like:
> > > >>
> > > >>
> > > >>
> > > >> 2006/07/14 14:51:35 DVHBIU3427I Changes made to directory entry
> > > >> xxxxxxx by DUMMY at DEVVM
> > > >>
> > > >> 2006/07/14 14:51:35 DVHBIU3427I have been placed
> > > >> online.
> > > >>
> > > >>
> > > >>
> > > >> This presents a problem for a VSE guest or any service machine that
> > > >> may process files from its reader.
> > > >>
> > > >>
> > > >>
> > > >> Is there any way to prevent this file from being sent?
> > > >>
> >
>

Reply via email to