date:20071212

Apparently, the default is not VERIFY 1 80,
but VERIFY 1 min(lrecl.1,lscreen.2) to say it in Rexx speak.

2007/12/13, Schuh, Richard <[EMAIL PROTECTED]>:
> Problem found by Mark Llewellyn. There was a "userid RDRLIST A0". Its
> properties were being used by XEDIT to set the verify range BECAUSE
> THERE IS NO SET VERIFY COMMAND being executed by RDRLIST or PROFRLST.
> Sigh! How can something like this live to be such a ripe old age without
> ever having been caught. I just tried FILELIST and it, happily, does not
> suffer from the same disease.
>
> Regards,
> Richard Schuh
>
>
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
> Behalf Of Alan Altmark
> Sent: Wednesday, December 12, 2007 2:27 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: RDRLIST Weirdness
>
> On Wednesday, 12/12/2007 at 04:55 EST, Bob Bates
> <[EMAIL PROTECTED]> wrote:
> > I looked and don't see anything that is obviously part of RDRLIST.
> Lots
> of
> > others though.
>
> PROFRLST XEDIT is the thing RDRLIST EXEC invokes.  There is no X$RLST$X
> XEDIT.
>
> The default VERIFY setting is OFF 1 80, which applies to filetype
> "RDRLIST".  Something is setting it.
>
> IPL CMS PARM NOSPROF INSTSEG NO
> ACC (NOPROF
> RELEASE A
> RDRLIST
>
>
> Alan Altmark
> z/VM Development
> IBM Endicott
>


-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: VMRM Cooperative Memory Management - working?

2007-12-12 Thread Bill Bitner

Fred Schmidt <[EMAIL PROTECTED]> writes:
>However, I would like to persist with CMM. My original question still
>stands... how can I verify that it is actually working?
>

>From the z/VM perspective you should see resident pages and total pages for
virtual machines being managed drop when the system comes under constraint.
For Performance Toolkit, this would be seen in UPAGE report (FCX113). The
process of Linux freeing backing memory is done via Diagnose x'10'. You can
see the diagnose 10 counts in PRIVOP report (FCX104). Some other items of
interest may be users in page wait, see USTAT (FCX114). Other performance
products will have similar reports.
>From the Linux perspective, you can check the size of the pool of pages
put out of play via the commands:
cat /proc/sys/vm/cmm_pages
cat /proc/sys/vm/cmm_timed_pages

Out of the box, VMRM is configured to use the first pool.

Regards,
Bill

Re: Performance ? How much page area to allocate?

2007-12-12 Thread Rob van der Heij

On Dec 12, 2007 5:38 PM, Rob van der Heij <[EMAIL PROTECTED]> wrote:

If nobody else does, I should read my posts ;-)

> Clearly my choice would be to give it to CP as paging device...  and let Linux
> (not) swap into VDISK.

My attempt to put too much in half a sentence may confuse the reader.
What I meant to say is that you give Linux VDISK for high-performance
swap device as well as the "just-in-case" swap device that will not
get used in normal situations. Obviously you need to monitor the usage
of that "just-in-case" device and act when for some reason it does get
used.

Rob
-- 
Rob van der Heij
Velocity Software, Inc
http://velocitysoftware.com/

Re: RDRLIST Weirdness

Problem found by Mark Llewellyn. There was a "userid RDRLIST A0". Its
properties were being used by XEDIT to set the verify range BECAUSE
THERE IS NO SET VERIFY COMMAND being executed by RDRLIST or PROFRLST.
Sigh! How can something like this live to be such a ripe old age without
ever having been caught. I just tried FILELIST and it, happily, does not
suffer from the same disease.

Regards, 
Richard Schuh 

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Alan Altmark
Sent: Wednesday, December 12, 2007 2:27 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

On Wednesday, 12/12/2007 at 04:55 EST, Bob Bates 
<[EMAIL PROTECTED]> wrote:
> I looked and don't see anything that is obviously part of RDRLIST.
Lots 
of 
> others though.

PROFRLST XEDIT is the thing RDRLIST EXEC invokes.  There is no X$RLST$X 
XEDIT.

The default VERIFY setting is OFF 1 80, which applies to filetype 
"RDRLIST".  Something is setting it.

IPL CMS PARM NOSPROF INSTSEG NO
ACC (NOPROF
RELEASE A
RDRLIST

Alan Altmark
z/VM Development
IBM Endicott

Re: RDRLIST Weirdness

On Wednesday, 12/12/2007 at 04:55 EST, Bob Bates 
<[EMAIL PROTECTED]> wrote:
> I looked and don't see anything that is obviously part of RDRLIST. Lots 
of 
> others though.

PROFRLST XEDIT is the thing RDRLIST EXEC invokes.  There is no X$RLST$X 
XEDIT.

The default VERIFY setting is OFF 1 80, which applies to filetype 
"RDRLIST".  Something is setting it.

IPL CMS PARM NOSPROF INSTSEG NO
ACC (NOPROF
RELEASE A
RDRLIST

Alan Altmark
z/VM Development
IBM Endicott

Re: DFSMSRM Errors in RMSMASTR

2007-12-12 Thread Dave Keeton

>The APARs which allow RMS to issue a query device without attaching
>the device are VM64062 and VM64206 for RMS, and VM64157 for CP.

>However, none of this service in my belief will help solve the
>I/O errors you are receiving.  If you associate a device with a
>particular scratch pool, and there are volumes in this pool, the
>I/O error seems strange.  You should ask the CE about this.  Of course
>they will point to the software.  So if you obtain a trsource trace of
>the I/O error we can tell you exactly what I/O is failing and what the
>error is.


Thanks for the APAR info, Les! 

Having never done a trace before, I'm not sure how to proceed. Should I
use the TRACE command? You mention 'trsource', which I see on the z/VM
Downloads page, but I'm not sure if that's what I need or not.

Please advise,
Dave

Re: RDRLIST Weirdness

Get PROFRLST SXEDIT, insert a TRACE ?i and file as PROFRLST XEDIT A,
Start RDRLIST, and issuse
  'PIPE STACK | CONS | BUFFER |STACK'
to see what will be executed when PROFRLST ends
Also issue
   'REFRESH';'CP SLEEP 5 SEC'
to have a look at what is already in the userid RDRLIST file

2007/12/12, Schuh, Richard <[EMAIL PROTECTED]>:
> Yes, no x$* that is part of RDRLIST. There is a file for PEEK and FILELIST 
> and lots of others. DRAWLOGO even has one. I tried looking for %$* * *.
>
> Regards,
> Richard Schuh
>
>
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of 
> Bob Bates
> Sent: Wednesday, December 12, 2007 1:54 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: RDRLIST Weirdness
>
> I looked and don't see anything that is obviously part of RDRLIST. Lots of 
> others though.
>
>
> Bob Bates
> Enterprise Hosting Services - Enterprise Virtualization - z/VM and z/Linux
>
> w. (972) 753-5967
> c. (214) 907-5071
>
> "This message may contain confidential and/or privileged information.  If you 
> are not the addressee or authorized to receive this for the addressee, you 
> must not use, copy, disclose, or take any action based on this message or any 
> information herein.  If you have received this message in error, please 
> advise the sender immediately by reply e-mail and delete this message.  Thank 
> you for your cooperation."
>
>
>
> -Original Message-
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of 
> Kris Buelens
> Sent: Wednesday, December 12, 2007 3:48 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: RDRLIST Weirdness
>
> So, I may be wrong, or RDRLIST is an exception, or the name is almost right:
>
> FILELIST and friends are composed of a few execs
> - FILELIST EXEC basically issues XEDIT userid FILELIST (PROFILE PROFFSLT
> - But, FILELIST queued 'MACRO X$FLST$X', before starting XEDIT.  So when the
>   PROFLST XEDIT macro exits, X$FLST$X runs.
> - X$FLST$X is the one that issues the required LISTFILE command to populate
>   the FILELIST
> - EXECUTE XEDIT is the macro that executes commands entered in FILELIST.
>
> I am almost 100% sure I did not made typos in the names above.  Now, RDRLIST, 
> DIRLIST MACLIST, etc all use the same basics.
> So search again for files X$*$X XEDIT S you should find the base of RDRLIST 
> too.
>
> 2007/12/12, Schuh, Richard <[EMAIL PROTECTED]>:
> >
> >
> >
> >
> > That is interesting. I find no such file anywhere in my search order.
> > Neither can I find it with EXECMAP (banana. Yet RDRLIST works fine for me.
> >
> >
> >
> >
> > Regards,
> >  Richard Schuh
> >
> >
> >
> >  
> >
> >
> > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
> > On Behalf Of Kris Buelens
> >  Sent: Wednesday, December 12, 2007 1:21 PM
> >  To: IBMVM@LISTSERV.UARK.EDU
> >  Subject: Re: RDRLIST Weirdness
> >
> >
> >
> > You must also search for X$RLST$X XEDIT macro, it is the heart of
> > RDRLIST
> >
> >
> > 2007/12/12, Schuh, Richard <[EMAIL PROTECTED]>:
> >
> >
> >
> > It is the initial RDRLIST display, as below, from which you may PEEK,
> > RECEIVE or otherwise manipulate the listed files. 1-80 is still its
> > proper verify setting.
> >
> >
> >
> > RSCHUH   RDRLIST  A0  V 164  Trunc=164 Size=6 Line=1 Col=1 Alt=0
> >
> >
> > Cmd Filename Filetype Class User  at Node Hold  RecordsDate
> > Time
> >
> > (none)   (none)   CON T RSCHUH   RSVM3NONE  172 2007-12-07
> > 16:54:53
> >
> > (none)   (none)   CON T RSCHUH   RSVM3NONE  351 2007-12-07
> > 16:55:58
> >
> > (none)   (none)   CON T SSCHRIMP RSVM3NONE  132 2007-12-12
> > 18:03:48
> >
> > (none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
> > 18:45:17
> >
> > (none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
> > 18:46:21
> >
> > (none)   (none)   CON T RSCHUH   RSVM3NONE  749 2007-12-12
> > 18:57:05
> >
> >
> >
> >
> >
> >
> >
> > Regards,
> >  Richard Schuh
> >
> >
> >
> >  
> >
> >
> > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
> > On Behalf Of Huegel, Thomas
> >  Sent: Wednesday, December 12, 2007 1:03 PM
> >
> >
> >
> >  To: IBMVM@LISTSERV.UARK.EDU
> >  Subject: Re: RDRLIST Weirdness
> >
> >
> >
> >
> >
> > What is the filetype? A filetype of LISTING would default to 1-132
> > where a filetype of PUNCH would be 1-80 .. there are several defaults
> > dependant on filetype.
> >
> >
> > -Original Message-
> >  From: The IBM z/VM Operating System
> > [mailto:[EMAIL PROTECTED]
> > Behalf Of Schuh, Richard
> >  Sent: Wednesday, December 12, 2007 2:36 PM
> >  To: IBMVM@LISTSERV.UARK.EDU
> >  Subject: Re: RDRLIST Weirdness
> >
> > The size of the screen is irrelevant; the verify columns should be
> > 1-80 on any size screen. RDRLIST and FILELIST both keep an exact copy
> > of bytes 1-80 in bytes 81-160 for use when (a) determining what has
> > been asltered when a

Re: RDRLIST Weirdness

Level 22 service 0701

 

Regards, 
Richard Schuh 

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of 
Huegel, Thomas
Sent: Wednesday, December 12, 2007 2:01 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

 

what is your CMS level? Q CMSLEVEL 

-Original Message- 
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
Behalf Of Schuh, Richard 
Sent: Wednesday, December 12, 2007 3:59 PM 
To: IBMVM@LISTSERV.UARK.EDU 
Subject: Re: RDRLIST Weirdness 

 

Yes, no x$* that is part of RDRLIST. There is a file for PEEK and FILELIST and 
lots of others. DRAWLOGO even has one. I tried looking for %$* * *.

Regards, 
Richard Schuh 

 

-Original Message- 
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bob 
Bates 
Sent: Wednesday, December 12, 2007 1:54 PM 
To: IBMVM@LISTSERV.UARK.EDU 
Subject: Re: RDRLIST Weirdness 

I looked and don't see anything that is obviously part of RDRLIST. Lots of 
others though. 

 

Bob Bates 
Enterprise Hosting Services - Enterprise Virtualization - z/VM and z/Linux 

w. (972) 753-5967 
c. (214) 907-5071 

"This message may contain confidential and/or privileged information.  If you 
are not the addressee or authorized to receive this for the addressee, you must 
not use, copy, disclose, or take any action based on this message or any 
information herein.  If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message.  Thank you for 
your cooperation."

 

-Original Message- 
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris 
Buelens 
Sent: Wednesday, December 12, 2007 3:48 PM 
To: IBMVM@LISTSERV.UARK.EDU 
Subject: Re: RDRLIST Weirdness 

So, I may be wrong, or RDRLIST is an exception, or the name is almost right: 

FILELIST and friends are composed of a few execs 
- FILELIST EXEC basically issues XEDIT userid FILELIST (PROFILE PROFFSLT 
- But, FILELIST queued 'MACRO X$FLST$X', before starting XEDIT.  So when the 
  PROFLST XEDIT macro exits, X$FLST$X runs. 
- X$FLST$X is the one that issues the required LISTFILE command to populate 
  the FILELIST 
- EXECUTE XEDIT is the macro that executes commands entered in FILELIST. 

I am almost 100% sure I did not made typos in the names above.  Now, RDRLIST, 
DIRLIST MACLIST, etc all use the same basics.

So search again for files X$*$X XEDIT S you should find the base of RDRLIST 
too. 

2007/12/12, Schuh, Richard <[EMAIL PROTECTED]>: 
> 
> 
> 
> 
> That is interesting. I find no such file anywhere in my search order. 
> Neither can I find it with EXECMAP (banana. Yet RDRLIST works fine for me. 
> 
> 
> 
> 
> Regards, 
>  Richard Schuh 
> 
> 
> 
>   
> 
> 
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Kris Buelens 
>  Sent: Wednesday, December 12, 2007 1:21 PM 
>  To: IBMVM@LISTSERV.UARK.EDU 
>  Subject: Re: RDRLIST Weirdness 
> 
> 
> 
> You must also search for X$RLST$X XEDIT macro, it is the heart of 
> RDRLIST 
> 
> 
> 2007/12/12, Schuh, Richard <[EMAIL PROTECTED]>: 
> 
> 
> 
> It is the initial RDRLIST display, as below, from which you may PEEK, 
> RECEIVE or otherwise manipulate the listed files. 1-80 is still its 
> proper verify setting. 
> 
> 
> 
> RSCHUH   RDRLIST  A0  V 164  Trunc=164 Size=6 Line=1 Col=1 Alt=0 
> 
> 
> Cmd Filename Filetype Class User  at Node Hold  RecordsDate 
> Time 
> 
> (none)   (none)   CON T RSCHUH   RSVM3NONE  172 2007-12-07 
> 16:54:53 
> 
> (none)   (none)   CON T RSCHUH   RSVM3NONE  351 2007-12-07 
> 16:55:58 
> 
> (none)   (none)   CON T SSCHRIMP RSVM3NONE  132 2007-12-12 
> 18:03:48 
> 
> (none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12 
> 18:45:17 
> 
> (none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12 
> 18:46:21 
> 
> (none)   (none)   CON T RSCHUH   RSVM3NONE  749 2007-12-12 
> 18:57:05 
> 
> 
> 
> 
> 
> 
> 
> Regards, 
>  Richard Schuh 
> 
> 
> 
>   
> 
> 
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Huegel, Thomas 
>  Sent: Wednesday, December 12, 2007 1:03 PM 
> 
> 
> 
>  To: IBMVM@LISTSERV.UARK.EDU 
>  Subject: Re: RDRLIST Weirdness 
> 
> 
> 
> 
> 
> What is the filetype? A filetype of LISTING would default to 1-132 
> where a filetype of PUNCH would be 1-80 .. there are several defaults 
> dependant on filetype. 
> 
> 
> -Original Message- 
>  From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED] 
> Behalf Of Schuh, Richard 
>  Sent: Wednesday, December 12, 2007 2:36 PM 
>  To: IBMVM@LISTSERV.UARK.EDU 
>  Subject: Re: RDRLIST Weirdness 
> 
> The size of the screen is irrelevant; the verify columns should be 
> 1-80 on any size screen. RDRLIST and FILELIST both keep an exact copy 
> of bytes 1-80 in bytes 81-160 for use when (a)

Re: Dirmaint and RACF - a disconnect

THANK YOU.

Downloading now.

Lionel B. Dyck, Consultant/Specialist 

Enterprise Platform Services, Mainframe Engineering 
KP-IT Enterprise Engineering 
925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED] 
AIM: lbdyck | Yahoo IM: lbdyck 
Kaiser Service Credo: "Our cause is health. Our passion is service. We're 
here to make lives better." 

I never guess. It is a capital mistake to theorize before one has data. 
Insensibly one begins to twist facts to suit theories, instead of theories 
to suit facts. 
- Sir Arthur Conan Doyle 

NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, 
you are prohibited from sharing, copying, or otherwise using or disclosing 
its contents. If you have received this e-mail in error, please notify the 
sender immediately by reply e-mail and permanently delete this e-mail and 
any attachments without reading, forwarding or saving them. Thank you. 

From:
Alan Altmark <[EMAIL PROTECTED]>
To:
IBMVM@LISTSERV.UARK.EDU
Date:
12/12/2007 01:33 PM
Subject:
Re: Dirmaint and RACF - a disconnect

On Wednesday, 12/12/2007 at 03:48 EST, "Lionel B. Dyck" 
<[EMAIL PROTECTED]> wrote:
> disclaimer - I do have this reported to IBM 
> 
> I have a challenge with Dirmaint and RACF 
> 
> Doing a "DIRM ADD userid" results in the account being created but an 
MDISK or 
> AMDISK statements in the "userid direct" are not fully processed. By 
that I 
> mean that the directory knows about the disks but when I log on to the 
new 
> account none of the disks are their in either a Q DISK or Q DASD. The 
consensus 
> here is that DIRM is not issuing the appropriate RACF Permit to allow 
the 
> account access to its own mini-disks. 
> 
> Has anyone else seen this and/or have any insight? 

Look at APAR VM64275.  It fixes the PERMIT issued by DIRMAINT.

Alan Altmark
z/VM Development
IBM Endicott

<>

Re: RDRLIST Weirdness

what is your CMS level? Q CMSLEVEL

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Schuh, Richard
Sent: Wednesday, December 12, 2007 3:59 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness


Yes, no x$* that is part of RDRLIST. There is a file for PEEK and FILELIST
and lots of others. DRAWLOGO even has one. I tried looking for %$* * *.

Regards, 
Richard Schuh 


-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Bob Bates
Sent: Wednesday, December 12, 2007 1:54 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

I looked and don't see anything that is obviously part of RDRLIST. Lots of
others though. 


Bob Bates
Enterprise Hosting Services - Enterprise Virtualization - z/VM and z/Linux 

w. (972) 753-5967
c. (214) 907-5071

"This message may contain confidential and/or privileged information.  If
you are not the addressee or authorized to receive this for the addressee,
you must not use, copy, disclose, or take any action based on this message
or any information herein.  If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this
message.  Thank you for your cooperation."



-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Kris Buelens
Sent: Wednesday, December 12, 2007 3:48 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

So, I may be wrong, or RDRLIST is an exception, or the name is almost right:

FILELIST and friends are composed of a few execs
- FILELIST EXEC basically issues XEDIT userid FILELIST (PROFILE PROFFSLT
- But, FILELIST queued 'MACRO X$FLST$X', before starting XEDIT.  So when the
  PROFLST XEDIT macro exits, X$FLST$X runs.
- X$FLST$X is the one that issues the required LISTFILE command to populate
  the FILELIST
- EXECUTE XEDIT is the macro that executes commands entered in FILELIST.

I am almost 100% sure I did not made typos in the names above.  Now,
RDRLIST, DIRLIST MACLIST, etc all use the same basics.
So search again for files X$*$X XEDIT S you should find the base of RDRLIST
too.

2007/12/12, Schuh, Richard <[EMAIL PROTECTED]>:
>
>
>
>
> That is interesting. I find no such file anywhere in my search order.
> Neither can I find it with EXECMAP (banana. Yet RDRLIST works fine for me.
>
>
>
>
> Regards,
>  Richard Schuh
>
>
>
>  
>
>
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Kris Buelens
>  Sent: Wednesday, December 12, 2007 1:21 PM
>  To: IBMVM@LISTSERV.UARK.EDU
>  Subject: Re: RDRLIST Weirdness
>
>
>
> You must also search for X$RLST$X XEDIT macro, it is the heart of 
> RDRLIST
>
>
> 2007/12/12, Schuh, Richard <[EMAIL PROTECTED]>:
>
>
>
> It is the initial RDRLIST display, as below, from which you may PEEK, 
> RECEIVE or otherwise manipulate the listed files. 1-80 is still its 
> proper verify setting.
>
>
>
> RSCHUH   RDRLIST  A0  V 164  Trunc=164 Size=6 Line=1 Col=1 Alt=0
>
>
> Cmd Filename Filetype Class User  at Node Hold  RecordsDate
> Time
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  172 2007-12-07
> 16:54:53
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  351 2007-12-07
> 16:55:58
>
> (none)   (none)   CON T SSCHRIMP RSVM3NONE  132 2007-12-12
> 18:03:48
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
> 18:45:17
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
> 18:46:21
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  749 2007-12-12
> 18:57:05
>
>
>
>
>
>
>
> Regards,
>  Richard Schuh
>
>
>
>  
>
>
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Huegel, Thomas
>  Sent: Wednesday, December 12, 2007 1:03 PM
>
>
>
>  To: IBMVM@LISTSERV.UARK.EDU
>  Subject: Re: RDRLIST Weirdness
>
>
>
>
>
> What is the filetype? A filetype of LISTING would default to 1-132 
> where a filetype of PUNCH would be 1-80 .. there are several defaults 
> dependant on filetype.
>
>
> -Original Message-
>  From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED]
> Behalf Of Schuh, Richard
>  Sent: Wednesday, December 12, 2007 2:36 PM
>  To: IBMVM@LISTSERV.UARK.EDU
>  Subject: Re: RDRLIST Weirdness
>
> The size of the screen is irrelevant; the verify columns should be 
> 1-80 on any size screen. RDRLIST and FILELIST both keep an exact copy 
> of bytes 1-80 in bytes 81-160 for use when (a) determining what has 
> been asltered when a profix command is entered, and (b) refreshing the 
> screen or line. When I enter rdrlist from my id , using a model 5, the
verify columns are 1-80.
> Using the same emulator session, but the affected user's id, verify is 
> 1-128. And that is true even after  NOSPROF and NOPROF.
>
>
>
> I have verified that in all aspects, the invocations of the EXEC and 
> XEDIT macro are the same

Re: RDRLIST Weirdness

Yes, no x$* that is part of RDRLIST. There is a file for PEEK and FILELIST and 
lots of others. DRAWLOGO even has one. I tried looking for %$* * *.

Regards, 
Richard Schuh 


-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bob 
Bates
Sent: Wednesday, December 12, 2007 1:54 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

I looked and don't see anything that is obviously part of RDRLIST. Lots of 
others though. 


Bob Bates
Enterprise Hosting Services - Enterprise Virtualization - z/VM and z/Linux 

w. (972) 753-5967
c. (214) 907-5071

"This message may contain confidential and/or privileged information.  If you 
are not the addressee or authorized to receive this for the addressee, you must 
not use, copy, disclose, or take any action based on this message or any 
information herein.  If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message.  Thank you for 
your cooperation."



-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris 
Buelens
Sent: Wednesday, December 12, 2007 3:48 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

So, I may be wrong, or RDRLIST is an exception, or the name is almost right:

FILELIST and friends are composed of a few execs
- FILELIST EXEC basically issues XEDIT userid FILELIST (PROFILE PROFFSLT
- But, FILELIST queued 'MACRO X$FLST$X', before starting XEDIT.  So when the
  PROFLST XEDIT macro exits, X$FLST$X runs.
- X$FLST$X is the one that issues the required LISTFILE command to populate
  the FILELIST
- EXECUTE XEDIT is the macro that executes commands entered in FILELIST.

I am almost 100% sure I did not made typos in the names above.  Now, RDRLIST, 
DIRLIST MACLIST, etc all use the same basics.
So search again for files X$*$X XEDIT S you should find the base of RDRLIST too.

2007/12/12, Schuh, Richard <[EMAIL PROTECTED]>:
>
>
>
>
> That is interesting. I find no such file anywhere in my search order.
> Neither can I find it with EXECMAP (banana. Yet RDRLIST works fine for me.
>
>
>
>
> Regards,
>  Richard Schuh
>
>
>
>  
>
>
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Kris Buelens
>  Sent: Wednesday, December 12, 2007 1:21 PM
>  To: IBMVM@LISTSERV.UARK.EDU
>  Subject: Re: RDRLIST Weirdness
>
>
>
> You must also search for X$RLST$X XEDIT macro, it is the heart of 
> RDRLIST
>
>
> 2007/12/12, Schuh, Richard <[EMAIL PROTECTED]>:
>
>
>
> It is the initial RDRLIST display, as below, from which you may PEEK, 
> RECEIVE or otherwise manipulate the listed files. 1-80 is still its 
> proper verify setting.
>
>
>
> RSCHUH   RDRLIST  A0  V 164  Trunc=164 Size=6 Line=1 Col=1 Alt=0
>
>
> Cmd Filename Filetype Class User  at Node Hold  RecordsDate
> Time
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  172 2007-12-07
> 16:54:53
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  351 2007-12-07
> 16:55:58
>
> (none)   (none)   CON T SSCHRIMP RSVM3NONE  132 2007-12-12
> 18:03:48
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
> 18:45:17
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
> 18:46:21
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  749 2007-12-12
> 18:57:05
>
>
>
>
>
>
>
> Regards,
>  Richard Schuh
>
>
>
>  
>
>
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Huegel, Thomas
>  Sent: Wednesday, December 12, 2007 1:03 PM
>
>
>
>  To: IBMVM@LISTSERV.UARK.EDU
>  Subject: Re: RDRLIST Weirdness
>
>
>
>
>
> What is the filetype? A filetype of LISTING would default to 1-132 
> where a filetype of PUNCH would be 1-80 .. there are several defaults 
> dependant on filetype.
>
>
> -Original Message-
>  From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED]
> Behalf Of Schuh, Richard
>  Sent: Wednesday, December 12, 2007 2:36 PM
>  To: IBMVM@LISTSERV.UARK.EDU
>  Subject: Re: RDRLIST Weirdness
>
> The size of the screen is irrelevant; the verify columns should be 
> 1-80 on any size screen. RDRLIST and FILELIST both keep an exact copy 
> of bytes 1-80 in bytes 81-160 for use when (a) determining what has 
> been asltered when a profix command is entered, and (b) refreshing the 
> screen or line. When I enter rdrlist from my id , using a model 5, the verify 
> columns are 1-80.
> Using the same emulator session, but the affected user's id, verify is 
> 1-128. And that is true even after  NOSPROF and NOPROF.
>
>
>
> I have verified that in all aspects, the invocations of the EXEC and 
> XEDIT macro are the same for both his id and mine. I have a Global 
> Rexx Exit running that captures the command, parameters and options 
> used to invoke any rexx program.
>
>
>
>
> Regards,
>  Richard Schuh
>
>
>
>  
>
>
> From: Th

Re: RDRLIST Weirdness

I looked and don't see anything that is obviously part of RDRLIST. Lots of 
others though. 


Bob Bates
Enterprise Hosting Services - Enterprise Virtualization - z/VM and z/Linux 

w. (972) 753-5967
c. (214) 907-5071

"This message may contain confidential and/or privileged information.  If you 
are not the addressee or authorized to receive this for the addressee, you must 
not use, copy, disclose, or take any action based on this message or any 
information herein.  If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message.  Thank you for 
your cooperation."



-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris 
Buelens
Sent: Wednesday, December 12, 2007 3:48 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

So, I may be wrong, or RDRLIST is an exception, or the name is almost right:

FILELIST and friends are composed of a few execs
- FILELIST EXEC basically issues XEDIT userid FILELIST (PROFILE PROFFSLT
- But, FILELIST queued 'MACRO X$FLST$X', before starting XEDIT.  So when the
  PROFLST XEDIT macro exits, X$FLST$X runs.
- X$FLST$X is the one that issues the required LISTFILE command to populate
  the FILELIST
- EXECUTE XEDIT is the macro that executes commands entered in FILELIST.

I am almost 100% sure I did not made typos in the names above.  Now, RDRLIST, 
DIRLIST MACLIST, etc all use the same basics.
So search again for files X$*$X XEDIT S you should find the base of RDRLIST too.

2007/12/12, Schuh, Richard <[EMAIL PROTECTED]>:
>
>
>
>
> That is interesting. I find no such file anywhere in my search order.
> Neither can I find it with EXECMAP (banana. Yet RDRLIST works fine for me.
>
>
>
>
> Regards,
>  Richard Schuh
>
>
>
>  
>
>
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Kris Buelens
>  Sent: Wednesday, December 12, 2007 1:21 PM
>  To: IBMVM@LISTSERV.UARK.EDU
>  Subject: Re: RDRLIST Weirdness
>
>
>
> You must also search for X$RLST$X XEDIT macro, it is the heart of 
> RDRLIST
>
>
> 2007/12/12, Schuh, Richard <[EMAIL PROTECTED]>:
>
>
>
> It is the initial RDRLIST display, as below, from which you may PEEK, 
> RECEIVE or otherwise manipulate the listed files. 1-80 is still its 
> proper verify setting.
>
>
>
> RSCHUH   RDRLIST  A0  V 164  Trunc=164 Size=6 Line=1 Col=1 Alt=0
>
>
> Cmd Filename Filetype Class User  at Node Hold  RecordsDate
> Time
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  172 2007-12-07
> 16:54:53
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  351 2007-12-07
> 16:55:58
>
> (none)   (none)   CON T SSCHRIMP RSVM3NONE  132 2007-12-12
> 18:03:48
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
> 18:45:17
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
> 18:46:21
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  749 2007-12-12
> 18:57:05
>
>
>
>
>
>
>
> Regards,
>  Richard Schuh
>
>
>
>  
>
>
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Huegel, Thomas
>  Sent: Wednesday, December 12, 2007 1:03 PM
>
>
>
>  To: IBMVM@LISTSERV.UARK.EDU
>  Subject: Re: RDRLIST Weirdness
>
>
>
>
>
> What is the filetype? A filetype of LISTING would default to 1-132 
> where a filetype of PUNCH would be 1-80 .. there are several defaults 
> dependant on filetype.
>
>
> -Original Message-
>  From: The IBM z/VM Operating System 
> [mailto:[EMAIL PROTECTED]
> Behalf Of Schuh, Richard
>  Sent: Wednesday, December 12, 2007 2:36 PM
>  To: IBMVM@LISTSERV.UARK.EDU
>  Subject: Re: RDRLIST Weirdness
>
> The size of the screen is irrelevant; the verify columns should be 
> 1-80 on any size screen. RDRLIST and FILELIST both keep an exact copy 
> of bytes 1-80 in bytes 81-160 for use when (a) determining what has 
> been asltered when a profix command is entered, and (b) refreshing the 
> screen or line. When I enter rdrlist from my id , using a model 5, the verify 
> columns are 1-80.
> Using the same emulator session, but the affected user's id, verify is 
> 1-128. And that is true even after  NOSPROF and NOPROF.
>
>
>
> I have verified that in all aspects, the invocations of the EXEC and 
> XEDIT macro are the same for both his id and mine. I have a Global 
> Rexx Exit running that captures the command, parameters and options 
> used to invoke any rexx program.
>
>
>
>
> Regards,
>  Richard Schuh
>
>
>
>  
>
>
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] 
> On Behalf Of Bob Bates
>  Sent: Wednesday, December 12, 2007 11:34 AM
>  To: IBMVM@LISTSERV.UARK.EDU
>  Subject: Re: RDRLIST Weirdness
>
>
>
> Try logging on with your id and see if it is the same results. Check 
> the MODEL number of the device his session is emulating. Could be it 
> thinks it has a larger screen?
>
>
>
>
> Bob Bat

Re: Dirmaint and RACF - a disconnect

Issue CP Q DASD V1U001
And, also look what "LINK uid 191 191 M" responds.

2007/12/12, Lionel B. Dyck <[EMAIL PROTECTED]>:
>
>
> ok - tried it and the disk is not found.
>
> I am unable to do an attach for it.
>
> I receive this when I logon to the guest immediately after cms starts:
>
> DMSACP113S A(191) not attached or invalid device address
>
> Here is the directory entry (from a dirm review)
>
> MDISK 0191 3390 5420 10 V1U001 MR ALL  
>
> This is the statement that was in the directory file used for the DIRM
> ADD:
>
> AMDISK 0191 3390 5420 10 V1U001 MR PWS ALL SOME FEW
>
> thx
>
> --
> *Lionel B. Dyck, Consultant/Specialist *
> Enterprise Platform Services, Mainframe Engineering
> KP-IT Enterprise Engineering
> 925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED]<[EMAIL PROTECTED]>
> AIM: lbdyck *|* Yahoo IM: lbdyck *
> Kaiser Service Credo: "Our cause is health. Our passion is service. We're
> here to make lives better." *
> *
> I never guess. It is a capital mistake to theorize before one has data.
> Insensibly one begins to twist facts to suit theories, instead of theories
> to suit facts.
> - Sir Arthur Conan Doyle *
> *
> NOTICE TO RECIPIENT: *If you are not the intended recipient of this
> e-mail, you are prohibited from sharing, copying, or otherwise using or
> disclosing its contents. If you have received this e-mail in error, please
> notify the sender immediately by reply e-mail and permanently delete this
> e-mail and any attachments without reading, forwarding or saving them. Thank
> you.
>
>
>  From: Kris Buelens <[EMAIL PROTECTED]> To: IBMVM@LISTSERV.UARK.EDU
> Date: 12/12/2007 01:25 PM
> Subject: Re: Dirmaint and RACF - a disconnect
>
> --
>
>
>
> Rob gave the correct syntax: Q MDISK USER xx DIRECTORY
> But, indeed, if the volume on which the minidisk is located is not
> attached to SYSTEM, Q MDISK tells it is not found.
>
> So, my guess is you need to issue ATTACH  SYSTEM, where  is
> the address of the volume.
>
> 2007/12/12, Lionel B. Dyck <[EMAIL PROTECTED]>:
> >
> > The disks go online immediately.
> >
> > I was unable to do the Q MDISK as I could not find the correct syntax.
> >
> > Neither a Q DISK and Q DASD show the disk.
> >
> > A RACF RL VMMDISK does
> >
> >
> >  
> Lionel B. Dyck, Consultant/Specialist
> >  Enterprise Platform Services, Mainframe Engineering
> >  KP-IT Enterprise Engineering
> >  925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED]
> >  AIM: lbdyck | Yahoo IM: lbdyck
> >  Kaiser Service Credo: "Our cause is health. Our passion is service.
> We're here to make lives better."
> >
> >  I never guess. It is a capital mistake to theorize before one has data.
> Insensibly one begins to twist facts to suit theories, instead of theories
> to suit facts.
> >  - Sir Arthur Conan Doyle
> >
> >  NOTICE TO RECIPIENT: If you are not the intended recipient of this
> e-mail, you are prohibited from sharing, copying, or otherwise using or
> disclosing its contents. If you have received this e-mail in error, please
> notify the sender immediately by reply e-mail and permanently delete this
> e-mail and any attachments without reading, forwarding or saving them. Thank
> you.
> >
> >
> >
> >  From: Rob van der Heij <[EMAIL PROTECTED]>
> >  To: IBMVM@LISTSERV.UARK.EDU
> >  Date: 12/12/2007 01:04 PM
> >  Subject: Re: Dirmaint and RACF - a disconnect
> >  
>
> >
> >
> >
> > On Dec 12, 2007 9:47 PM, Lionel B. Dyck <[EMAIL PROTECTED]> wrote:
> >
> >  > Has anyone else seen this and/or have any insight?
> >
> >  Have you configured DIRMAINT to bring directory changes online
> >  immediately? I believe default is to postpone it to some inconvenient
> >  time. RACF defaults are such that the user does not need permission
> >  from the ESM to link to his own disks.
> >  Use Q MDISK USER ...  DIR  to see whether the disk is in the object
> >  (online) directory.
> >
> >  Rob
> >  --
> >  Rob van der Heij
> >  Velocity Software, Inc
> >  http://velocitysoftware.com/
> >
> >
> >
> >
>
>
>
> --
> Kris Buelens,
> IBM Belgium, VM customer support
>
>


-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: RDRLIST Weirdness

So, I may be wrong, or RDRLIST is an exception, or the name is almost right:

FILELIST and friends are composed of a few execs
- FILELIST EXEC basically issues XEDIT userid FILELIST (PROFILE PROFFSLT
- But, FILELIST queued 'MACRO X$FLST$X', before starting XEDIT.  So when the
  PROFLST XEDIT macro exits, X$FLST$X runs.
- X$FLST$X is the one that issues the required LISTFILE command to populate
  the FILELIST
- EXECUTE XEDIT is the macro that executes commands entered in FILELIST.

I am almost 100% sure I did not made typos in the names above.  Now,
RDRLIST, DIRLIST MACLIST, etc all use the same basics.
So search again for files X$*$X XEDIT S you should find the base of RDRLIST too.

2007/12/12, Schuh, Richard <[EMAIL PROTECTED]>:
>
>
>
>
> That is interesting. I find no such file anywhere in my search order.
> Neither can I find it with EXECMAP (banana. Yet RDRLIST works fine for me.
>
>
>
>
> Regards,
>  Richard Schuh
>
>
>
>  
>
>
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
> Behalf Of Kris Buelens
>  Sent: Wednesday, December 12, 2007 1:21 PM
>  To: IBMVM@LISTSERV.UARK.EDU
>  Subject: Re: RDRLIST Weirdness
>
>
>
> You must also search for X$RLST$X XEDIT macro, it is the heart of RDRLIST
>
>
> 2007/12/12, Schuh, Richard <[EMAIL PROTECTED]>:
>
>
>
> It is the initial RDRLIST display, as below, from which you may PEEK,
> RECEIVE or otherwise manipulate the listed files. 1-80 is still its proper
> verify setting.
>
>
>
> RSCHUH   RDRLIST  A0  V 164  Trunc=164 Size=6 Line=1 Col=1 Alt=0
>
>
> Cmd Filename Filetype Class User  at Node Hold  RecordsDate
> Time
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  172 2007-12-07
> 16:54:53
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  351 2007-12-07
> 16:55:58
>
> (none)   (none)   CON T SSCHRIMP RSVM3NONE  132 2007-12-12
> 18:03:48
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
> 18:45:17
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
> 18:46:21
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  749 2007-12-12
> 18:57:05
>
>
>
>
>
>
>
> Regards,
>  Richard Schuh
>
>
>
>  
>
>
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
> Behalf Of Huegel, Thomas
>  Sent: Wednesday, December 12, 2007 1:03 PM
>
>
>
>  To: IBMVM@LISTSERV.UARK.EDU
>  Subject: Re: RDRLIST Weirdness
>
>
>
>
>
> What is the filetype? A filetype of LISTING would default to 1-132 where a
> filetype of PUNCH would be 1-80 .. there are several defaults dependant on
> filetype.
>
>
> -Original Message-
>  From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
> Behalf Of Schuh, Richard
>  Sent: Wednesday, December 12, 2007 2:36 PM
>  To: IBMVM@LISTSERV.UARK.EDU
>  Subject: Re: RDRLIST Weirdness
>
> The size of the screen is irrelevant; the verify columns should be 1-80 on
> any size screen. RDRLIST and FILELIST both keep an exact copy of bytes 1-80
> in bytes 81-160 for use when (a) determining what has been asltered when a
> profix command is entered, and (b) refreshing the screen or line. When I
> enter rdrlist from my id , using a model 5, the verify columns are 1-80.
> Using the same emulator session, but the affected user's id, verify is
> 1-128. And that is true even after  NOSPROF and NOPROF.
>
>
>
> I have verified that in all aspects, the invocations of the EXEC and XEDIT
> macro are the same for both his id and mine. I have a Global Rexx Exit
> running that captures the command, parameters and options used to invoke any
> rexx program.
>
>
>
>
> Regards,
>  Richard Schuh
>
>
>
>  
>
>
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
> Behalf Of Bob Bates
>  Sent: Wednesday, December 12, 2007 11:34 AM
>  To: IBMVM@LISTSERV.UARK.EDU
>  Subject: Re: RDRLIST Weirdness
>
>
>
> Try logging on with your id and see if it is the same results. Check the
> MODEL number of the device his session is emulating. Could be it thinks it
> has a larger screen?
>
>
>
>
> Bob Bates
>  Enterprise Hosting Services - Enterprise Virtualization - z/VM and z/Linux
>
>  w. (972) 753-5967
>  c. (214) 907-5071
>
> "This message may contain confidential and/or privileged information.  If
> you are not the addressee or authorized to receive this for the addressee,
> you must not use, copy, disclose, or take any action based on this message
> or any information herein.  If you have received this message in error,
> please advise the sender immediately by reply e-mail and delete this
> message.  Thank you for your cooperation."
>
>
>
>
>
>
>
>  
>
>
> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
> Behalf Of Schuh, Richard
>  Sent: Wednesday, December 12, 2007 1:24 PM
>  To: IBMVM@LISTSERV.UARK.EDU
>  Subject: RDRLIST Weirdness
>
> We have one user who started exhibiting strange symptoms today. When he
>

Re: VM session question

On Wednesday, 12/12/2007 at 03:51 EST, "Gentry, Stephen" 
<[EMAIL PROTECTED]> wrote:
> We have an auditor who wants to know if VM (or VM:Secure if you have it)
> has an idle time out feature.  For example, if a user hasn't done
> anything in their VM session for x amount of time, they get forced off.
> VM has a DISCONNECT_TIMEOUT parameter as part of the FEATURES statement
> in the SYSTEM CONFIG file. But I think this is for a user who is in DSC
> mode. The user is then forced off after the defined time has expired.
> Does anyone know if there is such a feature?

There is nothing in CP that will do that.  There are inactivity timers in, 
for example, FTP and Telnet.  For telnet sessions, look at the INACTIVE 
timer in InternalClientParms.  This will, IIRC, trip the 
Disconnect_Timeout wire.

Unfortunately there's no way to set the INACTIVE timer on a per-user 
basis.

Your performance monitor, as Marcy notes, is the best place to make that 
kind of decision anyway, since it has the best knowledge of whether the 
user is actually doing work (burning CPU) rather than depending on console 
traffic.

Alan Altmark
z/VM Development
IBM Endicott

Re: Dirmaint and RACF - a disconnect

ok - tried it and the disk is not found.

I am unable to do an attach for it.

I receive this when I logon to the guest immediately after cms starts:

DMSACP113S A(191) not attached or invalid device address 

Here is the directory entry (from a dirm review)

MDISK 0191 3390 5420 10 V1U001 MR ALL   

This is the statement that was in the directory file used for the DIRM 
ADD:

AMDISK 0191 3390 5420 10 V1U001 MR PWS ALL SOME FEW 

thx

Lionel B. Dyck, Consultant/Specialist 
Enterprise Platform Services, Mainframe Engineering 
KP-IT Enterprise Engineering 
925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED] 
AIM: lbdyck | Yahoo IM: lbdyck 
Kaiser Service Credo: "Our cause is health. Our passion is service. We're 
here to make lives better." 

I never guess. It is a capital mistake to theorize before one has data. 
Insensibly one begins to twist facts to suit theories, instead of theories 
to suit facts. 
- Sir Arthur Conan Doyle 

NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, 
you are prohibited from sharing, copying, or otherwise using or disclosing 
its contents. If you have received this e-mail in error, please notify the 
sender immediately by reply e-mail and permanently delete this e-mail and 
any attachments without reading, forwarding or saving them. Thank you. 

From:
Kris Buelens <[EMAIL PROTECTED]>
To:
IBMVM@LISTSERV.UARK.EDU
Date:
12/12/2007 01:25 PM
Subject:
Re: Dirmaint and RACF - a disconnect

Rob gave the correct syntax: Q MDISK USER xx DIRECTORY
But, indeed, if the volume on which the minidisk is located is not
attached to SYSTEM, Q MDISK tells it is not found.

So, my guess is you need to issue ATTACH  SYSTEM, where  is
the address of the volume.

2007/12/12, Lionel B. Dyck <[EMAIL PROTECTED]>:
>
> The disks go online immediately.
>
> I was unable to do the Q MDISK as I could not find the correct syntax.
>
> Neither a Q DISK and Q DASD show the disk.
>
> A RACF RL VMMDISK does
>
>
>  
Lionel B. Dyck, Consultant/Specialist
>  Enterprise Platform Services, Mainframe Engineering
>  KP-IT Enterprise Engineering
>  925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED]
>  AIM: lbdyck | Yahoo IM: lbdyck
>  Kaiser Service Credo: "Our cause is health. Our passion is service. 
We're here to make lives better."
>
>  I never guess. It is a capital mistake to theorize before one has data. 
Insensibly one begins to twist facts to suit theories, instead of theories 
to suit facts.
>  - Sir Arthur Conan Doyle
>
>  NOTICE TO RECIPIENT: If you are not the intended recipient of this 
e-mail, you are prohibited from sharing, copying, or otherwise using or 
disclosing its contents. If you have received this e-mail in error, please 
notify the sender immediately by reply e-mail and permanently delete this 
e-mail and any attachments without reading, forwarding or saving them. 
Thank you.
>
>
>
>  From: Rob van der Heij <[EMAIL PROTECTED]>
>  To: IBMVM@LISTSERV.UARK.EDU
>  Date: 12/12/2007 01:04 PM
>  Subject: Re: Dirmaint and RACF - a disconnect
>  

>
>
>
> On Dec 12, 2007 9:47 PM, Lionel B. Dyck <[EMAIL PROTECTED]> wrote:
>
>  > Has anyone else seen this and/or have any insight?
>
>  Have you configured DIRMAINT to bring directory changes online
>  immediately? I believe default is to postpone it to some inconvenient
>  time. RACF defaults are such that the user does not need permission
>  from the ESM to link to his own disks.
>  Use Q MDISK USER ...  DIR  to see whether the disk is in the object
>  (online) directory.
>
>  Rob
>  --
>  Rob van der Heij
>  Velocity Software, Inc
>  http://velocitysoftware.com/
>
>
>
>

-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: RDRLIST Weirdness

That is interesting. I find no such file anywhere in my search order.
Neither can I find it with EXECMAP (banana. Yet RDRLIST works fine for
me.

 

Regards, 
Richard Schuh 

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Kris Buelens
Sent: Wednesday, December 12, 2007 1:21 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

 

You must also search for X$RLST$X XEDIT macro, it is the heart of
RDRLIST

2007/12/12, Schuh, Richard <[EMAIL PROTECTED]>:

It is the initial RDRLIST display, as below, from which you may PEEK,
RECEIVE or otherwise manipulate the listed files. 1-80 is still its
proper verify setting.

 

RSCHUH   RDRLIST  A0  V 164  Trunc=164 Size=6 Line=1 Col=1 Alt=0


Cmd Filename Filetype Class User  at Node Hold  RecordsDate
Time 

(none)   (none)   CON T RSCHUH   RSVM3NONE  172 2007-12-07
16:54:53   

(none)   (none)   CON T RSCHUH   RSVM3NONE  351 2007-12-07
16:55:58   

(none)   (none)   CON T SSCHRIMP RSVM3NONE  132 2007-12-12
18:03:48   

(none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
18:45:17   

(none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
18:46:21   

(none)   (none)   CON T RSCHUH   RSVM3NONE  749 2007-12-12
18:57:05   

 


 

Regards, 
Richard Schuh 

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Huegel, Thomas
Sent: Wednesday, December 12, 2007 1:03 PM


To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

 

What is the filetype? A filetype of LISTING would default to 1-132 where
a filetype of PUNCH would be 1-80 .. there are several defaults
dependant on filetype.

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] Behalf Of Schuh, Richard
Sent: Wednesday, December 12, 2007 2:36 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

The size of the screen is irrelevant; the verify columns should
be 1-80 on any size screen. RDRLIST and FILELIST both keep an exact copy
of bytes 1-80 in bytes 81-160 for use when (a) determining what has been
asltered when a profix command is entered, and (b) refreshing the screen
or line. When I enter rdrlist from my id , using a model 5, the verify
columns are 1-80. Using the same emulator session, but the affected
user's id, verify is 1-128. And that is true even after  NOSPROF and
NOPROF. 

 

I have verified that in all aspects, the invocations of the EXEC
and XEDIT macro are the same for both his id and mine. I have a Global
Rexx Exit running that captures the command, parameters and options used
to invoke any rexx program.  

 

Regards, 
Richard Schuh 

 





From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Bates
Sent: Wednesday, December 12, 2007 11:34 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

 

Try logging on with your id and see if it is the same results.
Check the MODEL number of the device his session is emulating. Could be
it thinks it has a larger screen?

 

Bob Bates 
Enterprise Hosting Services - Enterprise Virtualization - z/VM
and z/Linux
 

w. (972) 753-5967 
c. (214) 907-5071 

"This message may contain confidential and/or privileged
information.  If you are not the addressee or authorized to receive this
for the addressee, you must not use, copy, disclose, or take any action
based on this message or any information herein.  If you have received
this message in error, please advise the sender immediately by reply
e-mail and delete this message.  Thank you for your cooperation."

 

 

 





From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard
Sent: Wednesday, December 12, 2007 1:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: RDRLIST Weirdness

We have one user who started exhibiting strange symptoms today.
When he enters the RDRLIST command,  VERIFY is set for 1-132, not 1-80.

*   He is using the PROFRLST from the S-disk, verified by
me. He has not monkeyed with the DEFAULTS for anything - everything is
vanilla.

*   He has set no user synonyms, also verified.

*   He has no RDRLIST EXEC, XEDIT or MODULE other than what
is on the S-disk, also verified 

*   I have done:

o   IPL CMS PARM NOSPROF

o   ACC 191 A (NOPROF

And I get the same result.

*   I have traced both RDRLIST EXEC and PROFRLST XEDIT and
have failed to find (perhaps

Re: Dirmaint and RACF - a disconnect

On Wednesday, 12/12/2007 at 03:48 EST, "Lionel B. Dyck" 
<[EMAIL PROTECTED]> wrote:
> disclaimer - I do have this reported to IBM 
> 
> I have a challenge with Dirmaint and RACF 
> 
> Doing a "DIRM ADD userid" results in the account being created but an 
MDISK or 
> AMDISK statements in the "userid direct" are not fully processed. By 
that I 
> mean that the directory knows about the disks but when I log on to the 
new 
> account none of the disks are their in either a Q DISK or Q DASD. The 
consensus 
> here is that DIRM is not issuing the appropriate RACF Permit to allow 
the 
> account access to its own mini-disks. 
> 
> Has anyone else seen this and/or have any insight? 

Look at APAR VM64275.  It fixes the PERMIT issued by DIRMAINT.

Alan Altmark
z/VM Development
IBM Endicott

Re: Dirmaint and RACF - a disconnect

Rob gave the correct syntax: Q MDISK USER xx DIRECTORY
But, indeed, if the volume on which the minidisk is located is not
attached to SYSTEM, Q MDISK tells it is not found.

So, my guess is you need to issue ATTACH  SYSTEM, where  is
the address of the volume.

2007/12/12, Lionel B. Dyck <[EMAIL PROTECTED]>:
>
> The disks go online immediately.
>
> I was unable to do the Q MDISK as I could not find the correct syntax.
>
> Neither a Q DISK and Q DASD show the disk.
>
> A RACF RL VMMDISK does
>
>
>  
Lionel B. Dyck, Consultant/Specialist
>  Enterprise Platform Services, Mainframe Engineering
>  KP-IT Enterprise Engineering
>  925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED]
>  AIM: lbdyck | Yahoo IM: lbdyck
>  Kaiser Service Credo: "Our cause is health. Our passion is service. We're 
> here to make lives better."
>
>  I never guess. It is a capital mistake to theorize before one has data. 
> Insensibly one begins to twist facts to suit theories, instead of theories to 
> suit facts.
>  - Sir Arthur Conan Doyle
>
>  NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, 
> you are prohibited from sharing, copying, or otherwise using or disclosing 
> its contents. If you have received this e-mail in error, please notify the 
> sender immediately by reply e-mail and permanently delete this e-mail and any 
> attachments without reading, forwarding or saving them. Thank you.
>
>
>
>  From: Rob van der Heij <[EMAIL PROTECTED]>
>  To: IBMVM@LISTSERV.UARK.EDU
>  Date: 12/12/2007 01:04 PM
>  Subject: Re: Dirmaint and RACF - a disconnect
>  

>
>
>
> On Dec 12, 2007 9:47 PM, Lionel B. Dyck <[EMAIL PROTECTED]> wrote:
>
>  > Has anyone else seen this and/or have any insight?
>
>  Have you configured DIRMAINT to bring directory changes online
>  immediately? I believe default is to postpone it to some inconvenient
>  time. RACF defaults are such that the user does not need permission
>  from the ESM to link to his own disks.
>  Use Q MDISK USER ...  DIR  to see whether the disk is in the object
>  (online) directory.
>
>  Rob
>  --
>  Rob van der Heij
>  Velocity Software, Inc
>  http://velocitysoftware.com/
>
>
>
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: RDRLIST Weirdness

Yeah, same thing I saw when I looked. Thought "Wow, mine's V 164?" Then
realized variable lrecl 164. Q VER shows OFF 1 80. Haven't found
anything to change it yet.
 

Bob Bates 
Enterprise Hosting Services - Enterprise Virtualization - z/VM and
z/Linux
 

w. (972) 753-5967 
c. (214) 907-5071 

"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein.  If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message.  Thank you for your cooperation."


 

  _  

From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: Wednesday, December 12, 2007 3:09 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness



It is the initial RDRLIST display, as below, from which you may PEEK,
RECEIVE or otherwise manipulate the listed files. 1-80 is still its
proper verify setting.

 

RSCHUH   RDRLIST  A0  V 164  Trunc=164 Size=6 Line=1 Col=1 Alt=0


Cmd Filename Filetype Class User  at Node Hold  RecordsDate
Time 

(none)   (none)   CON T RSCHUH   RSVM3NONE  172 2007-12-07
16:54:53   

(none)   (none)   CON T RSCHUH   RSVM3NONE  351 2007-12-07
16:55:58   

(none)   (none)   CON T SSCHRIMP RSVM3NONE  132 2007-12-12
18:03:48   

(none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
18:45:17   

(none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
18:46:21   

(none)   (none)   CON T RSCHUH   RSVM3NONE  749 2007-12-12
18:57:05   

 


 

Regards, 
Richard Schuh 

 

  _  

From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Huegel, Thomas
Sent: Wednesday, December 12, 2007 1:03 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

 

What is the filetype? A filetype of LISTING would default to 1-132 where
a filetype of PUNCH would be 1-80 .. there are several defaults
dependant on filetype.

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] Behalf Of Schuh, Richard
Sent: Wednesday, December 12, 2007 2:36 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

The size of the screen is irrelevant; the verify columns should
be 1-80 on any size screen. RDRLIST and FILELIST both keep an exact copy
of bytes 1-80 in bytes 81-160 for use when (a) determining what has been
asltered when a profix command is entered, and (b) refreshing the screen
or line. When I enter rdrlist from my id , using a model 5, the verify
columns are 1-80. Using the same emulator session, but the affected
user's id, verify is 1-128. And that is true even after  NOSPROF and
NOPROF. 

 

I have verified that in all aspects, the invocations of the EXEC
and XEDIT macro are the same for both his id and mine. I have a Global
Rexx Exit running that captures the command, parameters and options used
to invoke any rexx program.  

 

Regards, 
Richard Schuh 

 


  _  


From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Bates
Sent: Wednesday, December 12, 2007 11:34 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

 

Try logging on with your id and see if it is the same results.
Check the MODEL number of the device his session is emulating. Could be
it thinks it has a larger screen?

 

Bob Bates 
Enterprise Hosting Services - Enterprise Virtualization - z/VM
and z/Linux
 

w. (972) 753-5967 
c. (214) 907-5071 

"This message may contain confidential and/or privileged
information.  If you are not the addressee or authorized to receive this
for the addressee, you must not use, copy, disclose, or take any action
based on this message or any information herein.  If you have received
this message in error, please advise the sender immediately by reply
e-mail and delete this message.  Thank you for your cooperation."

 

 

 


  _  


From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard
Sent: Wednesday, December 12, 2007 1:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: RDRLIST Weirdness

We have one user who started exhibiting strange symptoms today.
When he enters the RDRLIST command,  VERIFY is set for 1-132, not 1-80.

*   He is using the PROFRLST from the S-disk, verified by
me. He has not monkeyed with the DEFAULTS for anything - everything is
vanilla.

Re: RDRLIST Weirdness

You must also search for X$RLST$X XEDIT macro, it is the heart of RDRLIST

2007/12/12, Schuh, Richard <[EMAIL PROTECTED]>:
>
>  It is the initial RDRLIST display, as below, from which you may PEEK,
> RECEIVE or otherwise manipulate the listed files. 1-80 is still its proper
> verify setting.
>
>
>
> RSCHUH   RDRLIST  A0  V 164  Trunc=164 Size=6 Line=1 Col=1
> Alt=0
>
> Cmd Filename Filetype Class User  at Node Hold  RecordsDate
> Time
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  172 2007-12-07
> 16:54:53
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  351 2007-12-07
> 16:55:58
>
> (none)   (none)   CON T SSCHRIMP RSVM3NONE  132 2007-12-12
> 18:03:48
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
> 18:45:17
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
> 18:46:21
>
> (none)   (none)   CON T RSCHUH   RSVM3NONE  749 2007-12-12
> 18:57:05
>
>
>
>
>
>
> Regards,
> Richard Schuh
>
>
>  --
>
> *From:* The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] *On
> Behalf Of *Huegel, Thomas
> *Sent:* Wednesday, December 12, 2007 1:03 PM
> *To:* IBMVM@LISTSERV.UARK.EDU
> *Subject:* Re: RDRLIST Weirdness
>
>
>
> What is the filetype? A filetype of LISTING would default to 1-132 where a
> filetype of PUNCH would be 1-80 .. there are several defaults dependant on
> filetype.
>
> -Original Message-
> *From:* The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
> Behalf Of *Schuh, Richard
> *Sent:* Wednesday, December 12, 2007 2:36 PM
> *To:* IBMVM@LISTSERV.UARK.EDU
> *Subject:* Re: RDRLIST Weirdness
>
> The size of the screen is irrelevant; the verify columns should be 1-80 on
> any size screen. RDRLIST and FILELIST both keep an exact copy of bytes 1-80
> in bytes 81-160 for use when (a) determining what has been asltered when a
> profix command is entered, and (b) refreshing the screen or line. When I
> enter rdrlist from my id , using a model 5, the verify columns are 1-80.
> Using the same emulator session, but the affected user's id, verify is
> 1-128. And that is true even after  NOSPROF and NOPROF.
>
>
>
> I have verified that in all aspects, the invocations of the EXEC and XEDIT
> macro are the same for both his id and mine. I have a Global Rexx Exit
> running that captures the command, parameters and options used to invoke any
> rexx program.
>
>
>
> Regards,
> Richard Schuh
>
>
>  --
>
> *From:* The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] *On
> Behalf Of *Bob Bates
> *Sent:* Wednesday, December 12, 2007 11:34 AM
> *To:* IBMVM@LISTSERV.UARK.EDU
> *Subject:* Re: RDRLIST Weirdness
>
>
>
> Try logging on with your id and see if it is the same results. Check the
> MODEL number of the device his session is emulating. Could be it thinks it
> has a larger screen?
>
>
>
> Bob Bates
> Enterprise Hosting Services - Enterprise Virtualization - z/VM and 
> z/Linux
>
> w. (972) 753-5967
> c. (214) 907-5071
>
> *"This message may contain confidential and/or privileged information.  If
> you are not the addressee or authorized to receive this for the addressee,
> you must not use, copy, disclose, or take any action based on this message
> or any information herein.  If you have received this message in error,
> please advise the sender immediately by reply e-mail and delete this
> message.  Thank you for your cooperation."*
>
>
>
>
>
>
>  --
>
> *From:* The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] *On
> Behalf Of *Schuh, Richard
> *Sent:* Wednesday, December 12, 2007 1:24 PM
> *To:* IBMVM@LISTSERV.UARK.EDU
> *Subject:* RDRLIST Weirdness
>
> We have one user who started exhibiting strange symptoms today. When he
> enters the RDRLIST command,  VERIFY is set for 1-132, not 1-80.
>
> §   He is using the PROFRLST from the S-disk, verified by me. He has
> not monkeyed with the DEFAULTS for anything - everything is vanilla.
>
> §   He has set no user synonyms, also verified.
>
> §   He has no RDRLIST EXEC, XEDIT or MODULE other than what is on the
> S-disk, also verified
>
> §   I have done:
>
> o   IPL CMS PARM NOSPROF
>
> o   ACC 191 A (NOPROF
>
> And I get the same result.
>
> §   I have traced both RDRLIST EXEC and PROFRLST XEDIT and have failed
> to find (perhaps recognize) a smoking gun.
>
> What gives? Where does RDRLIST set the verify columns? I have found no
> such command in either the traces or the source.
>
> Regards,
> Richard Schuh
>
>


-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: DIRMAINT authentication

On Tuesday, 12/11/2007 at 08:45 EST, David Boyes <[EMAIL PROTECTED]> 
wrote:

> This was where I was going a few months ago with the idea of integrating
> RACF into the base VM.

> Even given the general awfulness of RACF, at that
> point IBM would have a basic level of function to depend on, and you
> could always turn it off and/or replace it since there are fairly clean
> interface divisions. The other security/authorization vendors could
> easily implement a RACF compatibility layer, if they haven't done so
> already (assuming they actually start marketing their VM products
> again...).

The interface for authentication, authorization, and audit between a guest 
and an ESM is fully defined by RACROUTE.  The CP-ESM interface ("ACI") was 
updated in z/VM 5.3 to include a RACROUTE REQUEST=AUTH-style of call so 
that we could begin to standardize CP requests based on resource class and 
resource name.  In that way we can implement new requests without having 
to change the ACI.

> In any case, yes, it's long past time to get a consistent and common
> security and authorization paradigm going on VM. A REXX-callable CSL
> routine to ask would be goodness too.

The paradigm exists.  The problem is that nothing is using it and I have 
been derelict in my duty to crack the whip.  :-(  Git along, li'l 
dogies

Alan Altmark
z/VM Development
IBM Endicott

Re: DIRMAINT authentication

On Tuesday, 12/11/2007 at 04:05 EST, Jim Bohnsack <[EMAIL PROTECTED]> 
wrote:

> B) There "should" be no additional charge.  Not having to maintain
> separate authorization paradigms in each product just about has be less
> expensive for the vendor.  Certainly there would be an initial startup
> cost, but that should be able to be amortized in a short time and then
> it's all gravy :-)

I would expect a free ESM to simply perform the same authorization check 
that the individual products/features currently have, but have those 
authorizations in a single place.  The more granular checks I proposed 
would be something a real ESM would handle.  Further, there would be no 
connection to CP.

You could, of course, write your own ESM to replace the free one, but make 
sure that having a "roll your own" security manager is an acceptable 
policy in your shop. 

There is no way for IBM to give away a high-functioning ESM.  That would 
undermine the market for ESMs, upsetting both IBM and CA.

Alan Altmark
z/VM Development
IBM Endicott

Re: VM session question

The Disconnect_Timeout applies in two cases, (1) a disconnected user
posts a CP or VM read, and (2) an uncorrectable I/O error occurs on the
logon terminal. 

A user that is disconnected and idle does not get forced by system
unless it posts a read. You still need a monitor for disconnected users.
Like Marcy says, the performance monitor software usually has provision
for this. 

If you have TPF guests, they are never idle, even when they aren't doing
anything useful. They still take timer pops and check to see if there is
anything to do. 

Regards, 
Richard Schuh 


-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Marcy Cortes
Sent: Wednesday, December 12, 2007 12:54 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VM session question

Your performance monitor usually has this feature. 


Marcy Cortes 
 
"This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."


-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Gentry, Stephen
Sent: Wednesday, December 12, 2007 12:35 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] VM session question

We have an auditor who wants to know if VM (or VM:Secure if you have it)
has an idle time out feature.  For example, if a user hasn't done
anything in their VM session for x amount of time, they get forced off.
VM has a DISCONNECT_TIMEOUT parameter as part of the FEATURES statement
in the SYSTEM CONFIG file. But I think this is for a user who is in DSC
mode. The user is then forced off after the defined time has expired.
Does anyone know if there is such a feature?
Thanks,
Steve G.

Re: Dirmaint and RACF - a disconnect

The disks go online immediately.

I was unable to do the Q MDISK as I could not find the correct syntax. 

Neither a Q DISK and Q DASD show the disk.

A RACF RL VMMDISK does

Lionel B. Dyck, Consultant/Specialist 
Enterprise Platform Services, Mainframe Engineering 
KP-IT Enterprise Engineering 
925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED] 
AIM: lbdyck | Yahoo IM: lbdyck 
Kaiser Service Credo: "Our cause is health. Our passion is service. We're 
here to make lives better." 

I never guess. It is a capital mistake to theorize before one has data. 
Insensibly one begins to twist facts to suit theories, instead of theories 
to suit facts. 
- Sir Arthur Conan Doyle 

NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, 
you are prohibited from sharing, copying, or otherwise using or disclosing 
its contents. If you have received this e-mail in error, please notify the 
sender immediately by reply e-mail and permanently delete this e-mail and 
any attachments without reading, forwarding or saving them. Thank you. 



From:
Rob van der Heij <[EMAIL PROTECTED]>
To:
IBMVM@LISTSERV.UARK.EDU
Date:
12/12/2007 01:04 PM
Subject:
Re: Dirmaint and RACF - a disconnect



On Dec 12, 2007 9:47 PM, Lionel B. Dyck <[EMAIL PROTECTED]> wrote:

> Has anyone else seen this and/or have any insight?

Have you configured DIRMAINT to bring directory changes online
immediately? I believe default is to postpone it to some inconvenient
time. RACF defaults are such that the user does not need permission
from the ESM to link to his own disks.
Use Q MDISK USER ...  DIR  to see whether the disk is in the object
(online) directory.

Rob
-- 
Rob van der Heij
Velocity Software, Inc
http://velocitysoftware.com/

Re: DFSMSRM Errors in RMSMASTR

2007-12-12 Thread Jim Bohnsack

My MVS counterpart, 20+ years ago, would ask me to run with a piece of 
equipment on VM if it was suspect on MVS because, at that time MVS error 
recovery was so much better than VM's that it was harder to tell if 
there was a hardware error on something connected to MVS.  It would just 
recover, but VM would let you know, sometimes with a CP abend.

Jim

Huegel, Thomas wrote:

This is a multi-part message in MIME format.

--_=_NextPart_001_01C83CF7.6333BE72
Content-Type: text/plain;charset="utf-8"
X-EC0D2A8E-5CB7-4969-9C36-46D859D137BE-PartID: 
C2F4CFB4-5DC5-4C0B-BD01-766418D2226B

Those errors sound like something I once had. The errors were inconsistant
and somewhat random. I spent weeks writing error recovery routines for my
program and was pretty much at my witts end. Then I switched the cable to a
different card and PRESTO the errors went to the z/OS LPAR.. Maybe not your
problem, but if you have a spare cable and can try switching them it may be
worth the effort.  

  

--
Jim Bohnsack
Cornell University
(607) 255-1760
[EMAIL PROTECTED]

Re: RDRLIST Weirdness

It is the initial RDRLIST display, as below, from which you may PEEK,
RECEIVE or otherwise manipulate the listed files. 1-80 is still its
proper verify setting.

 

RSCHUH   RDRLIST  A0  V 164  Trunc=164 Size=6 Line=1 Col=1 Alt=0


Cmd Filename Filetype Class User  at Node Hold  RecordsDate
Time 

(none)   (none)   CON T RSCHUH   RSVM3NONE  172 2007-12-07
16:54:53   

(none)   (none)   CON T RSCHUH   RSVM3NONE  351 2007-12-07
16:55:58   

(none)   (none)   CON T SSCHRIMP RSVM3NONE  132 2007-12-12
18:03:48   

(none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
18:45:17   

(none)   (none)   CON T RSCHUH   RSVM3NONE  135 2007-12-12
18:46:21   

(none)   (none)   CON T RSCHUH   RSVM3NONE  749 2007-12-12
18:57:05   

 


 

Regards, 
Richard Schuh 

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Huegel, Thomas
Sent: Wednesday, December 12, 2007 1:03 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

 

What is the filetype? A filetype of LISTING would default to 1-132 where
a filetype of PUNCH would be 1-80 .. there are several defaults
dependant on filetype.

-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] Behalf Of Schuh, Richard
Sent: Wednesday, December 12, 2007 2:36 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

The size of the screen is irrelevant; the verify columns should
be 1-80 on any size screen. RDRLIST and FILELIST both keep an exact copy
of bytes 1-80 in bytes 81-160 for use when (a) determining what has been
asltered when a profix command is entered, and (b) refreshing the screen
or line. When I enter rdrlist from my id , using a model 5, the verify
columns are 1-80. Using the same emulator session, but the affected
user's id, verify is 1-128. And that is true even after  NOSPROF and
NOPROF. 

 

I have verified that in all aspects, the invocations of the EXEC
and XEDIT macro are the same for both his id and mine. I have a Global
Rexx Exit running that captures the command, parameters and options used
to invoke any rexx program.  

 

Regards, 
Richard Schuh 

 





From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Bates
Sent: Wednesday, December 12, 2007 11:34 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

 

Try logging on with your id and see if it is the same results.
Check the MODEL number of the device his session is emulating. Could be
it thinks it has a larger screen?

 

Bob Bates 
Enterprise Hosting Services - Enterprise Virtualization - z/VM
and z/Linux
 

w. (972) 753-5967 
c. (214) 907-5071 

"This message may contain confidential and/or privileged
information.  If you are not the addressee or authorized to receive this
for the addressee, you must not use, copy, disclose, or take any action
based on this message or any information herein.  If you have received
this message in error, please advise the sender immediately by reply
e-mail and delete this message.  Thank you for your cooperation."

 

 

 





From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard
Sent: Wednesday, December 12, 2007 1:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: RDRLIST Weirdness

We have one user who started exhibiting strange symptoms today.
When he enters the RDRLIST command,  VERIFY is set for 1-132, not 1-80.

*   He is using the PROFRLST from the S-disk, verified by
me. He has not monkeyed with the DEFAULTS for anything - everything is
vanilla.

*   He has set no user synonyms, also verified.

*   He has no RDRLIST EXEC, XEDIT or MODULE other than what
is on the S-disk, also verified 

*   I have done:

o   IPL CMS PARM NOSPROF

o   ACC 191 A (NOPROF

And I get the same result.

*   I have traced both RDRLIST EXEC and PROFRLST XEDIT and
have failed to find (perhaps recognize) a smoking gun. 

What gives? Where does RDRLIST set the verify columns? I have
found no such command in either the traces or the source.

Regards,
Richard Schuh

Re: RDRLIST Weirdness

What is the filetype? A filetype of LISTING would default to 1-132 where a
filetype of PUNCH would be 1-80 .. there are several defaults dependant on
filetype.

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Schuh, Richard
Sent: Wednesday, December 12, 2007 2:36 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

The size of the screen is irrelevant; the verify columns should be 1-80 on
any size screen. RDRLIST and FILELIST both keep an exact copy of bytes 1-80
in bytes 81-160 for use when (a) determining what has been asltered when a
profix command is entered, and (b) refreshing the screen or line. When I
enter rdrlist from my id , using a model 5, the verify columns are 1-80.
Using the same emulator session, but the affected user's id, verify is
1-128. And that is true even after  NOSPROF and NOPROF. 

I have verified that in all aspects, the invocations of the EXEC and XEDIT
macro are the same for both his id and mine. I have a Global Rexx Exit
running that captures the command, parameters and options used to invoke any
rexx program.  

Regards, 
Richard Schuh 

  _  

From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Bob Bates
Sent: Wednesday, December 12, 2007 11:34 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

Try logging on with your id and see if it is the same results. Check the
MODEL number of the device his session is emulating. Could be it thinks it
has a larger screen?

Bob Bates 
Enterprise Hosting Services -
 Enterprise Virtualization - z/VM and z/Linux

w. (972) 753-5967 
c. (214) 907-5071 

"This message may contain confidential and/or privileged information.  If
you are not the addressee or authorized to receive this for the addressee,
you must not use, copy, disclose, or take any action based on this message
or any information herein.  If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this
message.  Thank you for your cooperation."

  _  

From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: Wednesday, December 12, 2007 1:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: RDRLIST Weirdness

We have one user who started exhibiting strange symptoms today. When he
enters the RDRLIST command,  VERIFY is set for 1-132, not 1-80.

*   He is using the PROFRLST from the S-disk, verified by me. He has not
monkeyed with the DEFAULTS for anything - everything is vanilla.

*   He has set no user synonyms, also verified.

*   He has no RDRLIST EXEC, XEDIT or MODULE other than what is on the
S-disk, also verified 

*   I have done:

o   IPL CMS PARM NOSPROF

o   ACC 191 A (NOPROF

And I get the same result.

*   I have traced both RDRLIST EXEC and PROFRLST XEDIT and have failed
to find (perhaps recognize) a smoking gun. 

What gives? Where does RDRLIST set the verify columns? I have found no such
command in either the traces or the source.

Regards,
Richard Schuh

{SPAM?} RE: RDRLIST Weirdness

Well that was the first thing that occurred to me. Next I think I'd try
releasing his a-disk (and any other disks he might have modified EXECs
or XEDITs on) and define a temporary disk as A . Run rdrlist. Maybe
there is something else lurking with a funky name.  I would also keep
trying with NOPROF. 
 

Bob Bates 
Enterprise Hosting Services - Enterprise Virtualization - z/VM and
z/Linux
 

w. (972) 753-5967 
c. (214) 907-5071 

"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein.  If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message.  Thank you for your cooperation."


 

  _  

From: The IBM z/VM Operating System [mailto:IBMV  [EMAIL PROTECTED]
On Behalf Of Schuh, Richard
Sent: Wednesday, December 12, 2007 2:36 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness



The size of the screen is irrelevant; the verify columns should be 1-80
on any size screen. RDRLIST and FILELIST both keep an exact copy of
bytes 1-80 in bytes 81-160 for use when (a) determining what has been
asltered when a profix command is entered, and (b) refreshing the screen
or line. When I enter rdrlist from my id , using a model 5, the verify
columns are 1-80. Using the same emulator session, but the affected
user's id, verify is 1-128. And that is true even after  NOSPROF and
NOPROF. 

 

I have verified that in all aspects, the invocations of the EXEC and
XEDIT macro are the same for both his id and mine. I have a Global Rexx
Exit running that captures the command, parameters and options used to
invoke any rexx program.  

 

Regards, 
Richard Schuh 

 

  _  

From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Bob Bates
Sent: Wednesday, December 12, 2007 11:34 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

 

Try logging on with your id and see if it is the same results. Check the
MODEL number of the device his session is emulating. Could be it thinks
it has a larger screen?

 

Bob Bates 
Enterprise Hosting Services - Enterprise Virtualization - z/VM and
z/Linux
 

w. (972) 753-5967 
c. (214) 907-5071 

"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein.  If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message.  Thank you for your cooperation."

 

 

 

  _  

From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: Wednesday, December 12, 2007 1:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: RDRLIST Weirdness

We have one user who started exhibiting strange symptoms today. When he
enters the RDRLIST command,  VERIFY is set for 1-132, not 1-80.

*   He is using the PROFRLST from the S-disk, verified by me. He has
not monkeyed with the DEFAULTS for anything - everything is vanilla.

*   He has set no user synonyms, also verified.

*   He has no RDRLIST EXEC, XEDIT or MODULE other than what is on
the S-disk, also verified 

*   I have done:

o   IPL CMS PARM NOSPROF

o   ACC 191 A (NOPROF

And I get the same result.

*   I have traced both RDRLIST EXEC and PROFRLST XEDIT and have
failed to find (perhaps recognize) a smoking gun. 

What gives? Where does RDRLIST set the verify columns? I have found no
such command in either the traces or the source.

Regards,
Richard Schuh

Re: VM session question

2007-12-12 Thread Marcy Cortes

Your performance monitor usually has this feature. 


Marcy Cortes 
 
"This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."


-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Gentry, Stephen
Sent: Wednesday, December 12, 2007 12:35 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] VM session question

We have an auditor who wants to know if VM (or VM:Secure if you have it)
has an idle time out feature.  For example, if a user hasn't done
anything in their VM session for x amount of time, they get forced off.
VM has a DISCONNECT_TIMEOUT parameter as part of the FEATURES statement
in the SYSTEM CONFIG file. But I think this is for a user who is in DSC
mode. The user is then forced off after the defined time has expired.
Does anyone know if there is such a feature?
Thanks,
Steve G.

Re: Dirmaint and RACF - a disconnect

2007-12-12 Thread Rob van der Heij

On Dec 12, 2007 9:47 PM, Lionel B. Dyck <[EMAIL PROTECTED]> wrote:

> Has anyone else seen this and/or have any insight?

Have you configured DIRMAINT to bring directory changes online
immediately? I believe default is to postpone it to some inconvenient
time. RACF defaults are such that the user does not need permission
from the ESM to link to his own disks.
Use Q MDISK USER ...  DIR  to see whether the disk is in the object
(online) directory.

Rob
-- 
Rob van der Heij
Velocity Software, Inc
http://velocitysoftware.com/

VM session question

2007-12-12 Thread Gentry, Stephen

We have an auditor who wants to know if VM (or VM:Secure if you have it)
has an idle time out feature.  For example, if a user hasn't done
anything in their VM session for x amount of time, they get forced off.
VM has a DISCONNECT_TIMEOUT parameter as part of the FEATURES statement
in the SYSTEM CONFIG file. But I think this is for a user who is in DSC
mode. The user is then forced off after the defined time has expired.
Does anyone know if there is such a feature?
Thanks,
Steve G.

Dirmaint and RACF - a disconnect

disclaimer - I do have this reported to IBM

I have a challenge with Dirmaint and RACF

Doing a "DIRM ADD userid" results in the account being created but an 
MDISK or AMDISK statements in the "userid direct" are not fully processed. 
By that I mean that the directory knows about the disks but when I log on 
to the new account none of the disks are their in either a Q DISK or Q 
DASD. The consensus here is that DIRM is not issuing the appropriate RACF 
Permit to allow the account access to its own mini-disks.

Has anyone else seen this and/or have any insight?

Thank you

Lionel B. Dyck, Consultant/Specialist 
Enterprise Platform Services, Mainframe Engineering 
KP-IT Enterprise Engineering 
925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED] 
AIM: lbdyck | Yahoo IM: lbdyck 
Kaiser Service Credo: "Our cause is health. Our passion is service. We're 
here to make lives better." 

I never guess. It is a capital mistake to theorize before one has data. 
Insensibly one begins to twist facts to suit theories, instead of theories 
to suit facts. 
- Sir Arthur Conan Doyle 

NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, 
you are prohibited from sharing, copying, or otherwise using or disclosing 
its contents. If you have received this e-mail in error, please notify the 
sender immediately by reply e-mail and permanently delete this e-mail and 
any attachments without reading, forwarding or saving them. Thank you.

Re: RDRLIST Weirdness

The size of the screen is irrelevant; the verify columns should be 1-80
on any size screen. RDRLIST and FILELIST both keep an exact copy of
bytes 1-80 in bytes 81-160 for use when (a) determining what has been
asltered when a profix command is entered, and (b) refreshing the screen
or line. When I enter rdrlist from my id , using a model 5, the verify
columns are 1-80. Using the same emulator session, but the affected
user's id, verify is 1-128. And that is true even after  NOSPROF and
NOPROF. 

 

I have verified that in all aspects, the invocations of the EXEC and
XEDIT macro are the same for both his id and mine. I have a Global Rexx
Exit running that captures the command, parameters and options used to
invoke any rexx program.  

 

Regards, 
Richard Schuh 

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Bob Bates
Sent: Wednesday, December 12, 2007 11:34 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RDRLIST Weirdness

 

Try logging on with your id and see if it is the same results. Check the
MODEL number of the device his session is emulating. Could be it thinks
it has a larger screen?

 

Bob Bates 
Enterprise Hosting Services - Enterprise Virtualization - z/VM and
z/Linux
 

w. (972) 753-5967 
c. (214) 907-5071 

"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein.  If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message.  Thank you for your cooperation."

 

 

 



From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: Wednesday, December 12, 2007 1:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: RDRLIST Weirdness

We have one user who started exhibiting strange symptoms today. When he
enters the RDRLIST command,  VERIFY is set for 1-132, not 1-80.

*   He is using the PROFRLST from the S-disk, verified by me. He has
not monkeyed with the DEFAULTS for anything - everything is vanilla.

*   He has set no user synonyms, also verified.

*   He has no RDRLIST EXEC, XEDIT or MODULE other than what is on
the S-disk, also verified 

*   I have done:

o   IPL CMS PARM NOSPROF

o   ACC 191 A (NOPROF

And I get the same result.

*   I have traced both RDRLIST EXEC and PROFRLST XEDIT and have
failed to find (perhaps recognize) a smoking gun. 

What gives? Where does RDRLIST set the verify columns? I have found no
such command in either the traces or the source.

Regards,
Richard Schuh

Re: DFSMSRM Errors in RMSMASTR

Those errors sound like something I once had. The errors were inconsistant
and somewhat random. I spent weeks writing error recovery routines for my
program and was pretty much at my witts end. Then I switched the cable to a
different card and PRESTO the errors went to the z/OS LPAR.. Maybe not your
problem, but if you have a spare cable and can try switching them it may be
worth the effort.  

-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
Behalf Of Dave Keeton
Sent: Wednesday, December 12, 2007 10:17 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DFSMSRM Errors in RMSMASTR


Les,

That would be scratch0 I believe. I've been trying some stuff this
morning after reading your note. I disassociated the drive from the scratch
pool and when I re-started the RMSMASTR machine, there were no sense errors.
I was able to manually mount a tape which was volspecific. After
re-associating the drive to the scratch0 pool, I once again got the errors
on initialization of RMSMASTR.

Which APAR(s) should I be applying to bring DFSMS/VM current?

Thanks,
Dave

-Original Message-
From: Les Geer (607-429-3580) < [EMAIL PROTECTED]
 >
Reply-To: The IBM z/VM Operating System < IBMVM@LISTSERV.UARK.EDU
 >
To: IBMVM@LISTSERV.UARK.EDU  
Subject: Re: DFSMSRM Errors in RMSMASTR
Date: Tue, 11 Dec 2007 21:36:05 -0500


What was the category the device was assigned to in the previous

query?





Best Regards,

Les Geer

IBM z/VM and Linux Development





>I have 4 tapes assigned to the category scratch0 and 2 assigned to

>volspecific:

>

>FSMBCJ2182I SCRATCH0 VM

>3592   300GB

>FSMBCJ2182I SCRATCH0 VM0001

>3592   300GB

>FSMBCJ2182I SCRATCH0 VM0002

>3592   300GB

>FSMBCJ2182I SCRATCH0 VM0003

>3592   300GB

>FSMBCJ2182I VOLSPECIFIC VM0004

>3592   300GB

>FSMBCJ2182I VOLSPECIFIC VM0005

>3592   300GB

>

>

>
Dave Keeton
Systems Programmer
Enterprise Systems
Oregon State Data Center
(503) 373-0832
email: [EMAIL PROTECTED]

Re: RDRLIST Weirdness

Try logging on with your id and see if it is the same results. Check the
MODEL number of the device his session is emulating. Could be it thinks
it has a larger screen?
 

Bob Bates 
Enterprise Hosting Services - Enterprise Virtualization - z/VM and
z/Linux
 

w. (972) 753-5967 
c. (214) 907-5071 

"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein.  If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message.  Thank you for your cooperation."


 

  _  

From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: Wednesday, December 12, 2007 1:24 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: RDRLIST Weirdness



We have one user who started exhibiting strange symptoms today. When he
enters the RDRLIST command,  VERIFY is set for 1-132, not 1-80.

*   He is using the PROFRLST from the S-disk, verified by me. He has
not monkeyed with the DEFAULTS for anything - everything is vanilla.

*   He has set no user synonyms, also verified.

*   He has no RDRLIST EXEC, XEDIT or MODULE other than what is on
the S-disk, also verified 

*   I have done:

o   IPL CMS PARM NOSPROF

o   ACC 191 A (NOPROF

And I get the same result.

*   I have traced both RDRLIST EXEC and PROFRLST XEDIT and have
failed to find (perhaps recognize) a smoking gun. 



What gives? Where does RDRLIST set the verify columns? I have found no
such command in either the traces or the source.

Regards,
Richard Schuh

RDRLIST Weirdness

We have one user who started exhibiting strange symptoms today. When he
enters the RDRLIST command,  VERIFY is set for 1-132, not 1-80.

*   He is using the PROFRLST from the S-disk, verified by me. He has
not monkeyed with the DEFAULTS for anything - everything is vanilla.
*   He has set no user synonyms, also verified.
*   He has no RDRLIST EXEC, XEDIT or MODULE other than what is on
the S-disk, also verified 
*   I have done:
o   IPL CMS PARM NOSPROF
o   ACC 191 A (NOPROF
And I get the same result.
*   I have traced both RDRLIST EXEC and PROFRLST XEDIT and have
failed to find (perhaps recognize) a smoking gun. 

What gives? Where does RDRLIST set the verify columns? I have found no
such command in either the traces or the source.

Regards, 
Richard Schuh

Re: VMRM Cooperative Memory Management - working?

2007-12-12 Thread barton

There is a ton (metric or otherwise) of information in the monitor validating effects of
CMM. But if you don't have ESALPS, I'm clueless about what you would look at. On ESALPS,
there's user perspective, there's page space perspective, there's page rates, there's page
movement above/below the lines.
Could I recommend taking a class in z/VM and Linux performance? as well as a performance
monitor?

"http://velocitysoftware.com/workshop.html";

Brian Nielsen wrote:

On Wed, 12 Dec 2007 09:58:04 +0930, Fred Schmidt <[EMAIL PROTECTED]>

wrote:

However, I would like to persist with CMM. My original question still
stands... how can I verify that it is actually working?

Well, there are 2 answers to this.

First, the Linux guest has issued at least one ESSA instruction as
evidenced by Q MEMASSIST reporting "ACTIVE". The sole purpose of ESSA is

to implement CMMA. Since the virtual machine didn't get an operation
exception on the ESSA, it was either handled by the hardware assist or

simulated by CP. Personally, I'm reasonably sure that either did what it

was supposed to do with the ESSA, but Your Milage May Vary. I don't know

if there are any stats in CP or Linux on pages freed via CMMA.

Second, you could compare performance stats with it turned off and turned

on. With it on you would expect CP to do less paging and Linux to use

more CPU. See the IBM white paper "z/VM Large Memory – Linux on System
z"
for more detailed info:

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101151

Brian Nielsen

Re: DFSMSRM Errors in RMSMASTR

2007-12-12 Thread Les Geer (607-429-3580)

>That would be scratch0 I believe. I've been trying some stuff this
>morning after reading your note. I disassociated the drive from the
>scratch pool and when I re-started the RMSMASTR machine, there were no
>sense errors. I was able to manually mount a tape which was volspecific.
>After re-associating the drive to the scratch0 pool, I once again got
>the errors on initialization of RMSMASTR.
>
>Which APAR(s) should I be applying to bring DFSMS/VM current?
>

The APARs which allow RMS to issue a query device without attaching
the device are VM64062 and VM64206 for RMS, and VM64157 for CP.

However, none of this service in my belief will help solve the
I/O errors you are receiving.  If you associate a device with a
particular scratch pool, and there are volumes in this pool, the
I/O error seems strange.  You should ask the CE about this.  Of course
they will point to the software.  So if you obtain a trsource trace of
the I/O error we can tell you exactly what I/O is failing and what the
error is.

Best Regards,
Les Geer
IBM z/VM and Linux Development

Re: VMRM Cooperative Memory Management - working?

2007-12-12 Thread Brian Nielsen

On Wed, 12 Dec 2007 09:58:04 +0930, Fred Schmidt <[EMAIL PROTECTED]>

wrote:

>However, I would like to persist with CMM. My original question still
>stands... how can I verify that it is actually working?

Well, there are 2 answers to this.

First, the Linux guest has issued at least one ESSA instruction as 
evidenced by Q MEMASSIST reporting "ACTIVE".  The sole purpose of ESSA is

to implement CMMA.  Since the virtual machine didn't get an operation 
exception on the ESSA, it was either handled by the hardware assist or 

simulated by CP.  Personally, I'm reasonably sure that either did what it

was supposed to do with the ESSA, but Your Milage May Vary.  I don't know

if there are any stats in CP or Linux on pages freed via CMMA.

Second, you could compare performance stats with it turned off and turned

on.  With it on you would expect CP to do less paging and Linux to use 

more CPU.  See the IBM white paper "z/VM Large Memory  Linux on System
 z" 
for more detailed info:
  http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101151

Brian Nielsen

Greg Rehn is out of the office.

2007-12-12 Thread Greg Rehn


I will be out of the office starting  12/12/2007 and will not return until
12/13/2007.

I plan on checking email. For backup, please contact Gene Ganiere at
414-223-6092. Thx

Re: Performance ? How much page area to allocate?

2007-12-12 Thread Rob van der Heij

On Dec 12, 2007 4:18 PM, Huegel, Thomas <[EMAIL PROTECTED]> wrote:

> When I do this calculation I come up with a requirement of 10 3390 mod3 for
> my page space.
> I only have 2 3390 mod3's for page and I don't seem to be having any
> problems.

When you run out of paging space, CP will abend typically faster than
you can say Oops.

The calculation does the worst case scenario when every user wants
what you allowed him to have. Linux is that worst case. CMS users take
what they need, Linux takes what you let it have. And I trust you also
added the VDISKs to your calculation...

If you only have 6 GB of paging space, it does not take that many
users doing something unusual before you fill it up. Because Linux
roughly uses the entire virtual machine size in a LRU fashion, at the
moment it does not fit entirely in real memory, it will end up
entirely on paging DASD. And not just that one Linux machine, but all
of them because CP will take pages away from all of them.

Even if you have not configured your paging DASD optimal, you can
probably stand 1000 pg/s. That means that you fill the remaining 50%
of your paging space in less than 10 minutes. Even if you have
monitoring active on that, you still need to be pretty quick to beat
that.

Obviously, when you already have 25 GB of page space used at less than
50%, you would have a lot more time before bad things happen.

Trust me, you would not be the first to abend because you run out of
paging space. You know your workload and users best to estimate the
chances that this may happen, and you know whether the investment in
paging space is as insurance is justified.

Rob

PS I hear that some folks recommend to give each Linux server one of
more real disks for swap that do not get used. Combined with the myth
that swap space should be twice the virtual machine size, they end up
with an unused disk of twice the virtual machine size. Clearly my
choice would be to give it to CP as paging device...  and let Linux
(not) swap into VDISK.
-- 
Rob van der Heij
Velocity Software, Inc
http://velocitysoftware.com/

Re: DFSMSRM Errors in RMSMASTR

2007-12-12 Thread Dave Keeton

Les,

That would be scratch0 I believe. I've been trying some stuff this
morning after reading your note. I disassociated the drive from the
scratch pool and when I re-started the RMSMASTR machine, there were no
sense errors. I was able to manually mount a tape which was volspecific.
After re-associating the drive to the scratch0 pool, I once again got
the errors on initialization of RMSMASTR.

Which APAR(s) should I be applying to bring DFSMS/VM current?

Thanks,
Dave

-Original Message-
From: Les Geer (607-429-3580) <[EMAIL PROTECTED]>
Reply-To: The IBM z/VM Operating System 
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DFSMSRM Errors in RMSMASTR
Date: Tue, 11 Dec 2007 21:36:05 -0500


What was the category the device was assigned to in the previous
query?


Best Regards,
Les Geer
IBM z/VM and Linux Development


>I have 4 tapes assigned to the category scratch0 and 2 assigned to
>volspecific:
>
>FSMBCJ2182I SCRATCH0 VM
>3592   300GB
>FSMBCJ2182I SCRATCH0 VM0001
>3592   300GB
>FSMBCJ2182I SCRATCH0 VM0002
>3592   300GB
>FSMBCJ2182I SCRATCH0 VM0003
>3592   300GB
>FSMBCJ2182I VOLSPECIFIC VM0004
>3592   300GB
>FSMBCJ2182I VOLSPECIFIC VM0005
>3592   300GB
>
>
>

Dave Keeton
Systems Programmer
Enterprise Systems
Oregon State Data Center
(503) 373-0832
email: [EMAIL PROTECTED]

Re: Performance ? How much page area to allocate?

2007-12-12 Thread Marty Zimelis

James is probably correct.  CMS is aware enough of its environment to ask CP
how much storage it has, thus never has to touch each of its pages (as some
operating systems do).  It's also better behaved (for a virtual storage
environment) in releasing pages it isn't using.

For a CMS-intensive environment, the first factor in the calculation is
probably better "sum of the working sets of the logged on users," a slightly
more difficult value to obtain than the sum of defined storage sizes.

You could also work it backwards.  If your DASD page space is under 50% full
at peak (the usual target value), you could reduce the amount of space
defined until you get close to that.  However, be sure to allow for workload
growth; don't trim too close to the 50% full mark.
 
Marty
 
Martin Zimelis 
Principal 
maz/Consultancy 






From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
On Behalf Of Huegel, Thomas
Sent: Wednesday, December 12, 2007 10:19 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Performance ? How much page area to allocate?



IBM publishes a formula for calculating how much page space to
allocate. 
The formula is something like this: (Total amount of logged on user
storage - amount of REAL memory) x 2 = the amount of storage to map to DASD.

When I do this calculation I come up with a requirement of 10 3390
mod3 for my page space. 
I only have 2 3390 mod3's for page and I don't seem to be having any
problems. 

The question is 'am I missing something'? 

My page rate is < 2/sec. 
The only thing I ever see is occasionally LINUX will slow down for a
second or two. 

Any thoughts or comments would be appreciated. 

Thanks

Re: Performance ? How much page area to allocate?

2007-12-12 Thread Stracka, James (GTI)

That is a rough calculation and seems to be more appropriate for z/Linux
only environments.  In a CMS heavy environment it can be much less
because of DCSS usage and over allocation of Virtual Storage.
 
On our CMS heavy system, the calculation is:
 
qvirstor
Total Virtual Storage = 41735M ~ 40.7G
Needs 13 3390-3 TOTAL PAGE DASD
 
We have 10G Storage and 2G Expanded and have no paging:
 
q store
STORAGE = 10G
 
q xstore map
START   SIZE  STATUS %-IN-USE  %-UNUSABLE
   0M  2048M  CP(RETAINED)   0%0%
Ready; T=0.01/0.01 10:24:51
 
q alloc page
EXTENT EXTENT  TOTAL  PAGES   HIGH%
VOLID  RDEV  STARTEND  PAGES IN USE   PAGE USED
--  -- -- -- -- -- 
VMPAG1 AE97  1   3338 600840  0  0   0%
VMPAG2 AF07  1   3338 600840  0  0   0%
VMPAG3 AF18  1   3338 600840  0  0   0%
VMPAG4 AF2B  1   3338 600840  0  0   0%
VMPAG5 AF8E  1   3338 600840  0  0   0%
  -- --
SUMMARY2934K  0  0%
USABLE 2934K  0  0%
 
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Huegel, Thomas
Sent: Wednesday, December 12, 2007 10:19 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Performance ? How much page area to allocate?



IBM publishes a formula for calculating how much page space to
allocate. 
The formula is something like this: (Total amount of logged on
user storage - amount of REAL memory) x 2 = the amount of storage to map
to DASD.

When I do this calculation I come up with a requirement of 10
3390 mod3 for my page space. 
I only have 2 3390 mod3's for page and I don't seem to be having
any problems. 

The question is 'am I missing something'? 

My page rate is < 2/sec. 
The only thing I ever see is occasionally LINUX will slow down
for a second or two. 

Any thoughts or comments would be appreciated. 

Thanks


This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically indicated, 
this message is not an offer to sell or a solicitation of any investment 
products or other financial product or service, an official confirmation of any 
transaction, or an official statement of Merrill Lynch. Subject to applicable 
law, Merrill Lynch may monitor, review and retain e-communications (EC) 
traveling through its networks/systems. The laws of the country of each 
sender/recipient may impact the handling of EC, and EC may be archived, 
supervised and produced in countries other than the country in which you are 
located. This message cannot be guaranteed to be secure or error-free. This 
message is subject to terms available at the following link: 
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you 
consent to the foregoing.

Performance ? How much page area to allocate?