Re: Moving On

[Schuh, Richard]

In just a few minutes, I will be checking out of the Visa hotel (or perhaps 
asylum - they put up with me for 13+ years). I want to thank everyone who sent 
their congratulations and well wishes, and to reiterate my thanks to the 
everyone on who has helped me over the years (going back to the pre-Mitre 
Scheduler and the VM SHARE Tape days ). I may not rejoin the list until I have 
moved, am settled in, and have started enjoying my 7 day weekends. I am looking 
forward to reestablishing my connection with the group.


Regards,
Richard Schuh

Re: SFS Catalog Storage Pool

[Schuh, Richard]

I am not just anyone. :-)

I have fought my battles. Let someone who has skin in the game take up the 
banner.


Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark
> Sent: Thursday, July 07, 2011 10:19 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: SFS Catalog Storage Pool
> 
> On Thursday, 07/07/2011 at 12:35 EDT, "Schuh, Richard" 
> 
> wrote:
> > Something ought to be done about the instructions regarding 
> MAXUSERS.  
> > A
> few 
> > years ago, I had a small system that only had 64 users in 
> the directory. 
>  
> > It had performance problems (a complete freeze of any user 
> that tried 
> > to
>  use 
> > SFS) with MU of 100, 200, or 300. Upping it to 1000 fixed 
> the  problem.
> >  
> > And no, Alan or Mike, I will not open an incident or call 
> the Support
> Center 
> > (Unless I call to say goodbye) :-)
> 
> Anyone can send e-mail to mhvr...@us.ibm.com and comment on the pubs.
> 
> Alan Altmark
> 
> Senior Managing z/VM and Linux Consultant IBM System Lab 
> Services and Training ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
> 

Re: SFS Catalog Storage Pool

[Schuh, Richard]

Something ought to be done about the instructions regarding MAXUSERS. A few 
years ago, I had a small system that only had 64 users in the directory. It had 
performance problems (a complete freeze of any user that tried to use SFS) with 
MU of 100, 200, or 300. Upping it to 1000 fixed the problem.

And no, Alan or Mike, I will not open an incident or call the Support Center 
(Unless I call to say goodbye) :-)


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Kris Buelens
Sent: Thursday, July 07, 2011 2:52 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: SFS Catalog Storage Pool

The physical space for the catalog is large enough, but SFS also has a notion 
of "logical space".  SFS is derived from SQL/DS, remember DBEXTENTs and 
DBSPACEs).
You need to run FILESERV REGENERATE and increase MAXUSERS and/or MAXDISKS, 
chapter 11 in the SFS admin manual.

2011/7/7 clifford jackson 
mailto:cliffordjackson...@msn.com>>
I have a large SFS and monitoring my Catalog Space Information, I observed that 
my Percent used index blocks was at 97% I performed a control bata backup and 
done a FILESERV REORG. This in turn gave me 94% percent used index blocks. My 
Catalog storage pool 1 has the following specifications:

MDISK   STORAGE GROUP   PERCENT Utilized
304 1   100%
310 1 20%
312 1 20%


What do I need to do to get the percent used index blocks down and keep it to 
something manageable ..



CliffJackson
Senior Systems Programmer



--
Kris Buelens,
IBM Belgium, VM customer support

Re: IBM Sterling Connect:Direct for z/VM Announcement - End of Service - 12/31/2012

[Schuh, Richard]

Yeah, then there was that other nut-case who predicted EoW for May 21 of this 
year. He didn't admit that he had made a mistake until well after that day. 
However, the Mayan calendar may be a better model.



Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Roger Hawkinson
> Sent: Wednesday, July 06, 2011 12:50 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: IBM Sterling Connect:Direct for z/VM 
> Announcement - End of Service - 12/31/2012
> 
> It won't matter, Marcy.
> EoW (End of World) set to end on Dec. 21, 2012.
> CR reviewed/approved for that event.
> 
> Roger
> 
> Operating Systems Engineer, z/VM and Linux on IBM System z 
> Enterprise Hosting Services, Mainframe/Midrange Services
> 
> Wells Fargo Bank | 1220 Concord Ave | Concord, CA MAC 
> A0314-029 Tel 925-686-7317 | Cell 415-238-1358
> 
> hawki...@wellsfargo.com
> 
> 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:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Marcy Cortes
> Sent: Wednesday, July 06, 2011 12:38 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: IBM Sterling Connect:Direct for z/VM Announcement
> 
> Don't know if you all saw this.
> I was hoping that when IBM bought them, they might enhance 
> the VM product.  Instead, they killed it.  Sigh.
> 
> 
> 
> --
> 
> 
> The purpose of this email is to advise you of a change in 
> status of IBM Sterling Connect:Direct for z/VM.  This 
> information is date sensitive.  If you are not currently 
> responsible for these products within your organization, 
> please immediately forward this email to the responsible 
> individual(s). As the e-business and information technology 
> landscapes are changing, Sterling Commerce must adapt its 
> offerings to match current requirements.  We are therefore 
> announcing the phased withdrawal of some of our current 
> products and services.
> 
> Details:
> -The decision to end service of IBM Sterling 
> Connect:Direct for z/VM was made as a result of the product's 
> dependence on  the IBM VSE/VSAM module for z/VM which is no 
> longer supported by IBM.
> -End of Service - 12/31/2012 - The product will no 
> longer be supported by IBM
> 
> You will have two choices:
> -Migrate to another IBM Sterling Connect:Direct 
> platform by the End of Service date.
> -Continue using IBM Sterling Connect:Direct for z/VM 
> beyond the end of service date without continued IBM/Sterling Support.
> 
> More information is available on the Sterling Commerce 
> Customer Center site linked here: Connect Products End of 
> Life Migration/Entitlement Page (Please note, you need a 
> username and password to enter the site)
> 
>  Your IBM sales representative can help provide you with 
> additional information on IBM/Sterling offerings.
> 
> Regards,
> Rob Hall
> IBM Sterling MFT Product Management
> ster...@us.ibm.com
> 

Re: SHUTTRAP

[Schuh, Richard]

BTW, CP seems to accept any virtual system reset or disabled wait as a signal 
to remove a userid from the list of users in the SHUTDOWN Pending list. That is 
as I expected. 

I presume that cancellation is also accepted. :-) 

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark
> Sent: Monday, July 04, 2011 8:18 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: SHUTTRAP
> 
> On Monday, 07/04/2011 at 09:12 EDT, David Boyes 
> 
> wrote:
> > SA22-7832-08, pg. 11-16, in the section on Warnings. 
> There's about two 
> > sentences referring to power failure. The rest is in the SHUTTRAP 
> > source
> code.
> > 
> > I said it was tiny. 8-).
> 
> Indeed, and vague, too.  :-)  According to SHUTTRAP source, 
> the LPAR deactivation event ("Quiesce") is reflected via an 
> unsolicited Service Signal external interrupt with event 
> 0x1D, not a Warning machine check. So it's definitely in the 
> "not published" camp.
> 
> Alan Altmark
> 
> Senior Managing z/VM and Linux Consultant IBM System Lab 
> Services and Training ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
> 

Re: SHUTTRAP

[Schuh, Richard]

Close, but I am not willing to grant you a cigar. If all, or even most, have 
the same Signalled by id, then either a "signal shutdown all" was done or a 
program did multiple "signal shutdown user userid" commands in rapid sequence.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Raymond Noal
> Sent: Tuesday, June 28, 2011 3:38 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: SHUTTRAP
> 
> Richard,
> 
> You can use the CP command - 'Q SIGNALS' to make your 
> determinations, as in - 
> 
> q signals  
> Signalled  Timeout  
> UseridSignalSignal Status   By Remaining
> LN192209  SHUTDOWN  Enabled -  -
> VMSERVR   SHUTDOWN  Enabled -  -
> VMSERVU   SHUTDOWN  Enabled -  -
> VMSERVS   SHUTDOWN  Enabled -  -
> 
> Happy parsing!!
> 
> Raymond E. Noal
> 
>EMC²
> where information lives
> 
> Phone: (508) 249-4076
> Ext:  44076
> 
> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Schuh, Richard
> Sent: Tuesday, June 28, 2011 6:22 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: SHUTTRAP
> 
> Given the lack of direction, I suppose that you can do almost 
> anything, so long as you are consistent. There is no right or 
> wrong, so logging off will work so long as the watchdog 
> machine does not bring logged off users back on. Is there any 
> way for a user to determine if it is being targeted alone, by 
> a "signal shutdown user userid" or is included in a "signal 
> shutdown all"? I suspect not, but I can see where that might 
> be useful at times. Also, CP does notice when a user who has 
> requested the shutdown signal logs off and cancels the 
> request, does it not? It must because a virtual machine can 
> log off at any time, regardless of the shutdown signal, and 
> CP has to handle it correctly. Does CP disallow new logons 
> when it receives  "signal shutdown all" command?
> 
> Regards,
> Richard Schuh 
> 
>  
> 
> > -Original Message-
> > From: The IBM z/VM Operating System
> > [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark
> > Sent: Tuesday, June 28, 2011 1:56 PM
> > To: IBMVM@LISTSERV.UARK.EDU
> > Subject: Re: SHUTTRAP
> > 
> > On Tuesday, 06/28/2011 at 03:10 EDT, "Schuh, Richard" 
> > 
> > wrote:
> > > No only is it not obvious, so far I have been unable to 
> find it in 
> > > the documentation. You can specify a wait state code on the
> > SHUTDOWN
> > > command
> > and
> > > it can be anything between 1 and . I cannot find where
> > the default
> > is FFF. 
> > > Is that a true system default or is it a code you have 
> adopted for 
> > > your
> > use?
> > 
> > You will not find any published information on the mechanism.
> > 
> > I *observe* that if you SIGNAL SHUTDOWN to a 2nd level VM, it will 
> > load wait state FFF and the SIGNAL SHUTDOWN command gives a 
> > "successful termination" message.
> > 
> > Draw your own conclusions.
> > 
> > Alan Altmark
> > 
> > Senior Managing z/VM and Linux Consultant IBM System Lab 
> Services and 
> > Training ibm.com/systems/services/labservices
> > office: 607.429.3323
> > mobile; 607.321.7556
> > alan_altm...@us.ibm.com
> > IBM Endicott
> > 
> 

Re: SHUTTRAP

[Schuh, Richard]

Given the lack of direction, I suppose that you can do almost anything, so long 
as you are consistent. There is no right or wrong, so logging off will work so 
long as the watchdog machine does not bring logged off users back on. Is there 
any way for a user to determine if it is being targeted alone, by a "signal 
shutdown user userid" or is included in a "signal shutdown all"? I suspect not, 
but I can see where that might be useful at times. Also, CP does notice when a 
user who has requested the shutdown signal logs off and cancels the request, 
does it not? It must because a virtual machine can log off at any time, 
regardless of the shutdown signal, and CP has to handle it correctly. Does CP 
disallow new logons when it receives  "signal shutdown all" command?

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark
> Sent: Tuesday, June 28, 2011 1:56 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: SHUTTRAP
> 
> On Tuesday, 06/28/2011 at 03:10 EDT, "Schuh, Richard" 
> 
> wrote:
> > No only is it not obvious, so far I have been unable to find it in  
> > the documentation. You can specify a wait state code on the 
> SHUTDOWN 
> > command
> and 
> > it can be anything between 1 and . I cannot find where 
> the default
> is FFF. 
> > Is that a true system default or is it a code you have adopted for 
> > your
> use?
> 
> You will not find any published information on the mechanism.
> 
> I *observe* that if you SIGNAL SHUTDOWN to a 2nd level VM, it 
> will load wait state FFF and the SIGNAL SHUTDOWN command 
> gives a "successful termination" message.
> 
> Draw your own conclusions.
> 
> Alan Altmark
> 
> Senior Managing z/VM and Linux Consultant IBM System Lab 
> Services and Training ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
> 

Re: SHUTTRAP

[Schuh, Richard]

I do not find any mention of "shutdown" in the copy of "z/Architecture 
Principals of Operation" that I just searched. Like I said, the documentation 
is difficult to find.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Kris Buelens
Sent: Tuesday, June 28, 2011 1:05 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: SHUTTRAP

That code is what CP will load when its shutdown is complete.  So, not related 
to signal shutdown's wait code.  I don't remember where I found the code to 
load, my guess is in the z Series Principles of Operations (the shutdown signal 
is not a z/VM invention, but a z HW feature that z/VM also virtualizes).

2011/6/28 Schuh, Richard mailto:rsc...@visa.com>>
No only is it not obvious, so far I have been unable to find it in the 
documentation. You can specify a wait state code on the SHUTDOWN command and it 
can be anything between 1 and . I cannot find where the default is FFF. Is 
that a true system default or is it a code you have adopted for your use?


Regards,
Richard Schuh






From: The IBM z/VM Operating System 
[mailto:IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of 
Tom Huegel
Sent: Tuesday, June 28, 2011 11:53 AM

To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>
Subject: Re: SHUTTRAP

Thanks Kris, that is not obvious, but it makes sense..

On Tue, Jun 28, 2011 at 11:07 AM, Kris Buelens 
mailto:kris.buel...@gmail.com>> wrote:
My RxKernel has ShutTrap support.  RxServer uses WAKEUP (EXT to catch the 
interrupt.  No abends then.

And, to complete handling a shutdown signal, one is supposed to load an FFF 
wait state, not to LOGOFF.  My first attempt was to end with a LOGOFF.  But 
then our automation saw the server go logoff and started it again.  So now I 
end with the official method:
   'CP STORE PSW 000A 8FFF'




2011/6/28 Raymond Noal mailto:raymond.n...@emc.com>>
Hello Richard,

I believe the reason for your error message in using SHUTTRAP is that SHUTTRAP 
can only issue CMS commands and not CP commands. Is the message associated with 
your SHUTTRAP issuing a CP command? I had the same problem when my message was 
a CP command. As a test for SHUTTAP I issued the CMS command 'Q DISK' and it 
worked with no error message.

Hope this helps.

Raymond E. Noal

   EMC²
where information lives

Phone: (508) 249-4076
Ext:  44076

From: The IBM z/VM Operating System 
[mailto:IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of 
Schuh, Richard
Sent: Tuesday, June 28, 2011 11:59 AM
To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>
Subject: SHUTTRAP

I just retrieved SHUTTRAP from the download page and tried it. In my first 
simpleminded try, the results were mixed. The signal shutdown did indeed 
trigger the command included with the shuttrap command. Then I got this:

SHUTTRAP: Shutdown in 900 seconds
DMSITP143T Addressing exception occurred at 81056162 in system routine WAITRD; 
re-IPL CMS
15:07:56  * MSG FROM RSCHUH1 : DMSDIE3550I All APPC/VM and IUCV paths have been 
severed.
HCPGIR450W CP entered; disabled wait PSW 000A 80F3F752

There is nothing in the documentation that would lead me to believe that this 
is normal; however, the documentation consists solely of the HELP file and is 
pretty sparse in this area. I tried reassembling the module with the same 
results.

z/VM 6.1 Service Level 1002
CMS 25, Service Level 002


Regards,
Richard Schuh






--
Kris Buelens,
IBM Belgium, VM customer support




--
Kris Buelens,
IBM Belgium, VM customer support

Re: SHUTTRAP

[Schuh, Richard]

No only is it not obvious, so far I have been unable to find it in the 
documentation. You can specify a wait state code on the SHUTDOWN command and it 
can be anything between 1 and . I cannot find where the default is FFF. Is 
that a true system default or is it a code you have adopted for your use?


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Tom Huegel
Sent: Tuesday, June 28, 2011 11:53 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: SHUTTRAP

Thanks Kris, that is not obvious, but it makes sense..

On Tue, Jun 28, 2011 at 11:07 AM, Kris Buelens 
mailto:kris.buel...@gmail.com>> wrote:
My RxKernel has ShutTrap support.  RxServer uses WAKEUP (EXT to catch the 
interrupt.  No abends then.

And, to complete handling a shutdown signal, one is supposed to load an FFF 
wait state, not to LOGOFF.  My first attempt was to end with a LOGOFF.  But 
then our automation saw the server go logoff and started it again.  So now I 
end with the official method:
   'CP STORE PSW 000A 8FFF'




2011/6/28 Raymond Noal mailto:raymond.n...@emc.com>>
Hello Richard,

I believe the reason for your error message in using SHUTTRAP is that SHUTTRAP 
can only issue CMS commands and not CP commands. Is the message associated with 
your SHUTTRAP issuing a CP command? I had the same problem when my message was 
a CP command. As a test for SHUTTAP I issued the CMS command 'Q DISK' and it 
worked with no error message.

Hope this helps.

Raymond E. Noal

   EMC²
where information lives

Phone: (508) 249-4076
Ext:  44076

From: The IBM z/VM Operating System 
[mailto:IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of 
Schuh, Richard
Sent: Tuesday, June 28, 2011 11:59 AM
To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>
Subject: SHUTTRAP

I just retrieved SHUTTRAP from the download page and tried it. In my first 
simpleminded try, the results were mixed. The signal shutdown did indeed 
trigger the command included with the shuttrap command. Then I got this:

SHUTTRAP: Shutdown in 900 seconds
DMSITP143T Addressing exception occurred at 81056162 in system routine WAITRD; 
re-IPL CMS
15:07:56  * MSG FROM RSCHUH1 : DMSDIE3550I All APPC/VM and IUCV paths have been 
severed.
HCPGIR450W CP entered; disabled wait PSW 000A 80F3F752

There is nothing in the documentation that would lead me to believe that this 
is normal; however, the documentation consists solely of the HELP file and is 
pretty sparse in this area. I tried reassembling the module with the same 
results.

z/VM 6.1 Service Level 1002
CMS 25, Service Level 002


Regards,
Richard Schuh






--
Kris Buelens,
IBM Belgium, VM customer support

SHUTTRAP

[Schuh, Richard]

I just retrieved SHUTTRAP from the download page and tried it. In my first 
simpleminded try, the results were mixed. The signal shutdown did indeed 
trigger the command included with the shuttrap command. Then I got this:

SHUTTRAP: Shutdown in 900 seconds
DMSITP143T Addressing exception occurred at 81056162 in system routine WAITRD; 
re-IPL CMS
 15:07:56  * MSG FROM RSCHUH1 : DMSDIE3550I All APPC/VM and IUCV paths have 
been severed.
HCPGIR450W CP entered; disabled wait PSW 000A 80F3F752

There is nothing in the documentation that would lead me to believe that this 
is normal; however, the documentation consists solely of the HELP file and is 
pretty sparse in this area. I tried reassembling the module with the same 
results.

z/VM 6.1 Service Level 1002
CMS 25, Service Level 002



Regards,
Richard Schuh

Re: RMSMASTR and shutdowns

[Schuh, Richard]

Is there something in RMSMASTR that requires a R/W 191? There does not appear 
to be on our system. The most recently written file on the disk is dated 12 Nov 
2010.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark
> Sent: Friday, June 24, 2011 2:24 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: RMSMASTR and shutdowns
> 
> On Friday, 06/24/2011 at 04:31 EDT, Marcy Cortes 
>  wrote:
> > Bleah.. and Yuck.
> > 
> > NO NO NO.
> > 
> > What's the point of putting 1 file in a SFS if you can't share it
> anyway???
> > Put it on a minidisk.  1 cyl is fine.
> > And maybe when I have SSI , I can actually share it.
> > 
> > It's 7 4k blocks of config data.  Maybe IBM was trying to 
> save me the
> other 96% 
> > of a cylinder by putting it in SFS?  The rest of the component is on
> minidisk...
> 
> But you CAN update it while RMSMASTER is up, can you not?  I 
> am guessing 
> that there was a requirement to be able to update the config 
> file without 
> bringing the server down.
> 
> Alan Altmark
> 
> Senior Managing z/VM and Linux Consultant
> IBM System Lab Services and Training 
> ibm.com/systems/services/labservices 
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
> 

Re: Moving on

[Schuh, Richard]

We have 6 LPARs running z/VM 6.1.0 and only one of them does TPF hosting. While 
TPF hosting is the biggest expenditure of resources in that LPAR, it also has 
other critical applications. We never have gotten all the way down to just TPF 
hosting. If you count the several Linux guests that support TPF as TPF hosting, 
there are still a few critical applications that are running on VM. Of those 6 
LPARs, 4 are devoted to m/f Linux. There are also an unknown number of POCs for 
Linux either in process or in planning.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Bob Heerdink
> Sent: Thursday, June 23, 2011 11:42 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Moving on
> 
> Richard,
> 
> Thank for all your help over the last 30 years that I've had 
> the pleasure=
>  
> to work with VM.  
> 
> Was VM role at VISA down to just TPF guesting?   Seems like 
> you had some =
> 
> applications that WERE running under VM inhte old days.
> 
> Good bye and good luck,
> Bob Heerdink
> (now with IBM)
> 

Re: Moving on

[Schuh, Richard]

I made it official today. July 8 will be my last day of gainful employment. 
I'll try not to be too tough on you between now and then :-)


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of John Franciscovich
Sent: Thursday, June 23, 2011 11:22 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Moving on

Richard,

Congratulations!  Thanks for sharing so many of your  experiences with all of 
us, as well as keeping us honest with your (sometimes tough) questions :-)
Now it's time to enjoy yourself after many years of hard work.

John Franciscovich
z/VM Development

Re: Moving on

[Schuh, Richard]

Thanks for the kind words. I know that I got at least as much, undoubtedly way, 
way more, from the group than I contributed. My main regret is that I never had 
an employer who could be convinced that active participation in projects and 
committees would be beneficial. 

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Peter E. Carrier
> Sent: Thursday, June 23, 2011 8:44 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Moving on
> 
> Thanks for being a part of the community for so long, 
> Richard.  I have =
> 
> great memories of the good old days at VMSHARE, etc.  You 
> were always a =
> 
> great role model for us newbies.
> 
> Peter
> 

Re: Moving on

[Schuh, Richard]

Thanks Marty. I had come to the conclusion that Parkinson was right by 
observing one of my oldest and best friends. He has been much busier since 
retirement than he was before, and has enjoyed it much more.

I think it was still Piedmont Airlines, some time in the 1984-1987 period. We 
were still using the SHARE Tape, I think. USAir bought us in late 1987 or early 
1988

Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Martin Zimelis
Sent: Wednesday, June 22, 2011 2:05 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Moving on

Richard,
   I'd like to add my best wishes to those of your myriad friends on this list. 
 I seem to recall first running into you at a SHARE meeting when you worked for 
USAir (or was it one of its components?) in North Carolina.  It's been a long 
and interesting road since then.

   I have one observation on retirement for you.  Parkinson's Law is true.  
Work *does* expand to fill the time allotted to it.  :-)

   Best of luck.  It's been a real pleasure.

   Marty

On Wed, Jun 22, 2011 at 12:51 PM, Schuh, Richard 
mailto:rsc...@visa.com>> wrote:
After 48 years in the industry, involved with VM for the last 38 of them, I 
will be retiring early next month. I don't think it is possible to find a 
better group of people than the VM List. The professionalism, the willingness, 
even eagerness, to help others is outstanding. You have made my job easier. I 
wish you all the best. It has been nice, sometimes even fun, to know and work 
with such an exemplary group of people.

Regards,
Richard Schuh

Re: Moving on

[Schuh, Richard]

Which two (that was a plural) were useful? :-)


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Michael MacIsaac
Sent: Wednesday, June 22, 2011 10:56 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Moving on


Richard,

Good luck! Enjoy your retirement.  Thanks for all your useful appends to this 
list.

"Mike MacIsaac"(845) 433-7061

Re: Moving on

[Schuh, Richard]

Free time will be new to me, as well.

Thanks for the offer. I may well be taking you up on it sometime down the road.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of David Boyes
Sent: Wednesday, June 22, 2011 10:40 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Moving on

Drat. Now I'll have to go swap my investments somewhere else that has people I 
can trust working for them.
Wish someone had leaked the info early; you deserve a retirement book.

Best wishes - you've always been a great test of an idea at scale. Hope you 
have something fun and interesting planned to do with this strange thing I've 
heard called "free time". I've heard it can be quite addictive; wouldn't know 
from personal experience.

If you need a 3270 fix, let me know. We'll find you a VM session to keep your 
hand in.


n  Db

n

From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Schuh, Richard
Sent: Wednesday, June 22, 2011 12:51 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Moving on

After 48 years in the industry, involved with VM for the last 38 of them, I 
will be retiring early next month. I don't think it is possible to find a 
better group of people than the VM List. The professionalism, the willingness, 
even eagerness, to help others is outstanding. You have made my job easier. I 
wish you all the best. It has been nice, sometimes even fun, to know and work 
with such an exemplary group of people.

Regards,
Richard Schuh

Re: Moving on

[Schuh, Richard]

I echo those sentiments back to you.

You never did tell me your wife's reaction to your losing that scarf, but IIRC, 
the next time I saw you, your jaws were wired together.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Mike Walter
Sent: Wednesday, June 22, 2011 10:39 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Moving on

Richard,

It has been a privilege to call you a colleague and a friend for lo these many 
years.  I'll always remember that extended walk we took one evening in San 
Francisco, trying to find the scarf I lost on the walk back to the Hilton from 
Ghirardelli Square.

Enjoy your retirement, and keep us in mind just as we'll fondly remember you.


Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.



From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Schuh, Richard
Sent: Wednesday, June 22, 2011 11:51 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Moving on

After 48 years in the industry, involved with VM for the last 38 of them, I 
will be retiring early next month. I don't think it is possible to find a 
better group of people than the VM List. The professionalism, the willingness, 
even eagerness, to help others is outstanding. You have made my job easier. I 
wish you all the best. It has been nice, sometimes even fun, to know and work 
with such an exemplary group of people.

Regards,
Richard Schuh

Re: Moving on

[Schuh, Richard]

I will try staying on the list. There are two guys here who have been trying. 
They have so far been unsuccessful.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Scott Rohling
Sent: Wednesday, June 22, 2011 10:05 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Moving on

Rich - thanks for all the great input and assistance!  Best of luck enjoying 
your freedom...

And - you can always stay on the list with your personal email if you start to 
miss us :-)

Best regards -   Scott Rohling

On Wed, Jun 22, 2011 at 10:51 AM, Schuh, Richard 
mailto:rsc...@visa.com>> wrote:
After 48 years in the industry, involved with VM for the last 38 of them, I 
will be retiring early next month. I don't think it is possible to find a 
better group of people than the VM List. The professionalism, the willingness, 
even eagerness, to help others is outstanding. You have made my job easier. I 
wish you all the best. It has been nice, sometimes even fun, to know and work 
with such an exemplary group of people.

Regards,
Richard Schuh

Re: Moving on

[Schuh, Richard]

If I have helped more than I have muddied the waters, it was done gladly.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Bill Munson
Sent: Wednesday, June 22, 2011 10:01 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Moving on

Rich,

I am not sure if we ever met ( CRS ) but I have learned a lot from your posts 
on the VM list serv.

Thank you very much and good luck

Bill Munson
Sr. z/VM Systems Programmer
Brown Brothers Harriman & CO.
525 Washington Blvd.
Jersey City, NJ 07310
201-418-7588

VM Workshop
http://www.VMWorkshop.org/<http://www.vmworkshop.org/>
President - MVMUA
http://www2.marist.edu/~mvmua/
LVM Program Officer - SHARE
http://www.linkedin.com/in/BillMunson




From:    "Schuh, Richard" 
To:IBMVM@LISTSERV.UARK.EDU
Date:06/22/2011 12:51 PM
Subject:Moving on
Sent by:The IBM z/VM Operating System 




After 48 years in the industry, involved with VM for the last 38 of them, I 
will be retiring early next month. I don't think it is possible to find a 
better group of people than the VM List. The professionalism, the willingness, 
even eagerness, to help others is outstanding. You have made my job easier. I 
wish you all the best. It has been nice, sometimes even fun, to know and work 
with such an exemplary group of people.

Regards,
Richard Schuh



*** IMPORTANT NOTE*-- The 
opinions expressed in this message and/or any attachments are those of the 
author and not necessarily those of Brown Brothers Harriman & Co., its 
subsidiaries and affiliates ("BBH"). There is no guarantee that this message is 
either private or confidential, and it may have been altered by unauthorized 
sources without your or our knowledge. Nothing in the message is capable or 
intended to create any legally binding obligations on either party and it is 
not intended to provide legal advice. BBH accepts no responsibility for loss or 
damage from its use, including damage from virus. 

Moving on

[Schuh, Richard]

After 48 years in the industry, involved with VM for the last 38 of them, I 
will be retiring early next month. I don't think it is possible to find a 
better group of people than the VM List. The professionalism, the willingness, 
even eagerness, to help others is outstanding. You have made my job easier. I 
wish you all the best. It has been nice, sometimes even fun, to know and work 
with such an exemplary group of people.


Regards,
Richard Schuh

Re: Problems at DR test

[Schuh, Richard]

Have you submitted requirements? :-)

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark
> Sent: Wednesday, June 22, 2011 3:25 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Problems at DR test
> 
> Kris, I wasn't disputing the current state of affairs, but 
> was expressing my opinion on how it *should* work.
> 
> Regards,
> 
> Alan Altmark
> IBM Lab Services
> 
> -
> Sent from my BlackBerry Handheld.
> 

7720 Support

[Schuh, Richard]

Is the 7720 configured without tapes supported for normal CMS use in 6/1? 
Currently, we have VM:Tape and a TMC shared with MVS.


Regards,
Richard Schuh

Re: REXXCPS EXEC

[Schuh, Richard]

Running a compiled REXXCPS, I get these results:

 Run 1. Performance: 6587190 REXX clauses per second 
 Run 2. Performance: 7755269 REXX clauses per second
 Run 3. Performance: 7560471 REXX clauses per second  

This is on a lightly loaded z10 (Real CPU ID  = 000s20978000). The numbers 
appear to vary directly with the CPU Busy values. The LPAR shares its 5 CPs 
with  two other lightly loaded LPARs that are capped, with very low ceilings. 
If I run the uncompiled version, the result is approximately 25% of the 
compiled version's. I haven't had a chance to try it in one of the IFL LPARs. 
It is tough finding a time when they are not extremely busy.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Bruce Hayden
> Sent: Friday, June 10, 2011 7:13 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: REXXCPS EXEC
> 
> I ran it on a 2817-742 (i.e. a z196):
> rexxcps
> - REXXCPS 2.1 -- Measuring REXX clauses/second -  
> REXX version is: REXX370 4.02 01 Dec 1998
>System is: CMS
>Averaging: 100 measures of 100 iterations Calibration 
> (empty DO): 0.1351 secs (average of 100) Spooling trace 
> NOTERM Spooling now back on TERM
> 
> Total (full DO): 0.03813453 secs (average of 100 measures of 
> 100 iterations) Time for one iteration (1000 clauses) was: 
> 0.0003813453 seconds
> 
>  Performance: 2622295 REXX clauses per second
> 
> Ready; T=3.76/3.76 10:06:06
> 
> But - you're probably more interested in the numbers after 
> compiling the exec.  (I noticed in the table that it also has 
> the results after the exec is compiled.)
> 
> rexxcpsc
> - REXXCPS 2.1 -- Measuring REXX clauses/second -  
> REXX version is: REXXC370 4.02 23 Dec 1999
>System is: CMS
>Averaging: 100 measures of 100 iterations Calibration 
> (empty DO): 0.0467 secs (average of 100) Spooling trace 
> NOTERM Spooling now back on TERM
> 
> Total (full DO): 0.00707880 secs (average of 100 measures of 
> 100 iterations) Time for one iteration (1000 clauses) was: 
> 0.70788 seconds
> 
>  Performance: 14126688 REXX clauses per second
> 
> Ready; T=0.69/0.69 10:06:10
> 
> On Fri, Jun 10, 2011 at 6:18 AM, Les Koehler 
>  wrote:
> > I'm curious... Has anyone with real mainframe hardware (no 
> emulation) 
> > recently run REXXCPS that MFC wrote way back when?
> >
> > See:
> >
> > http://speleotrove.com/misc/rexxcpslist.html
> >
> > for his collection of data.
> >
> > If you've never seen REXXCPS, there's a link to it at the 
> top of the page.
> > Just remove the hash-bang usr/bin to run it on a VM userid.
> >
> > Les
> >
> 
> 
> 
> --
> Bruce Hayden
> z/VM and Linux on System z ATS
> IBM, Endicott, NY
> 

Re: z/VM page space

[Schuh, Richard]

A good decision, probably not a difficult one, by Mr. Holder and friends. 
Untangling that can of worms should not be a high priority use of development 
$$.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark
> Sent: Tuesday, June 14, 2011 10:45 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: z/VM page space
> 
> On Tuesday, 06/14/2011 at 01:30 EDT, David Boyes 
> 
> wrote:
>  
> > I think that's why you'd have to force CP to dirty the page rather 
> > than doing it inside a virtual machine, especially with 
> CP's own pages 
> > potentially written at startup. Probably only doable from inside CP 
> > itself, or at minimum, via manipulate of real storage rather than
> virtual
> > storage. There Be Dragons.
> > 
> > Another project for my Copious Spare Time. Not.
> 
> And now you know why DRAIN MIGRATE doesn't exist.  :-)   As 
> Bill Holder, 
> z/VM Memory Master, alludes, there are no data structures in 
> CP that index the contents of paging volumes.  You would have 
> to traverse every users' 
> memory management data structures to find references to page 
> slots on the drained volume.  In short, "Eeeww."
> 
> Alan Altmark
> 
> z/VM and Linux on System z Consultant
> IBM System Lab Services and Training
> ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
> 

Re: z/VM page space

[Schuh, Richard]

An absolute prereq, not just a safety one. If it is not already draining, then 
there would be nothing to prevent new pages from being written on the device. 
It will still be somewhat tricky because the page may already be in storage, in 
use by a virtual machine. Also,  it may be part of a DCSS, in which case, only 
your private copy (resulting from your changing the page) will be paged out by 
your activity; others will still be referencing the original page. 

Regards, 
Richard Schuh 

 

 
> 
> This might not be as hard as I thought. If the volume is 
> already drained for new traffic (probably a safety prereq for 
> this to happen), then determining pages on those volumes and 
> forcing page-in/page-out is probably safer than previously 
> thought. CP can maintain the appropriate interlocks if we 
> force CP to fault the page in, touch the page in a way that 
> forces CP to consider the page as dirty, and then allow the 
> normal page-out logic to determine the new location. It would 
> cause a fairly large burst in paging activity while running, 
> but that's probably not an big issue for the few times this 
> would get activated.
> 
> Scratch, scratch, scratch... There's an itch in here somewhere.
> 
> -- db
> 

Re: REXXDATE MODULE

[Schuh, Richard]

The start is the same.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Mike Walter
Sent: Monday, June 06, 2011 10:42 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: REXXDATE MODULE


As did Russ, I also have the REXXDATE MODULE, ASSEMBLE, and MEMO files.  When 
XEDITing, the MODULE gives no clue as to the author, etc.
The file dates are all: 1/22/88
The files are loaded from the 1987 VM Workshop Tools tape at Brigham Young 
University.

On the off chance that Russ has a different REXXDATE, here's the top of the 
ASSEMBLE source:

* * * Top of File * * *
*   Rexxdate was written by Alex Kodat at the Johns Hopkins University,
*   School of Hygiene and Public Health. Use it in good health
*   and modify it at your own peril.
*
*   REXXDATE is fully relocatable.
*
*
*   PROGRAM TO CONVERT A CHARACTER FORMAT DATE TO AN INTEGER (NUMBER
*   OF DAYS SINCE START OF GREGORIAN CALENDAR) THIS PROGRAM IS
*   MEANT TO BE CALLED AS A REXX FUNCTION.
*
REXXDATE START

Let me know if you need the three files

Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.




Russ Burtnett 

Sent by: "The IBM z/VM Operating System" 

06/06/2011 12:18 PM
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: REXXDATE MODULE





Richard,

I found a copy of the source and the memo file in one of my old archives.  I
suspect it was from a tools tape.

I'll send it to you offline.

... Russ Burtnett

P.S. No "packrat" comments please.





The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. E-mails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by e-mail.

Re: REXXDATE MODULE

[Schuh, Richard]

Russ, 

Thanks. Do you also have TOD EXEC? It appears that it is what has been calling 
REXXDATE. I would like to bring them into the 21st century. :-)

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Russ Burtnett
> Sent: Monday, June 06, 2011 10:18 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: REXXDATE MODULE
> 
> Richard,
> 
> I found a copy of the source and the memo file in one of my 
> old archives.=
>   I
> suspect it was from a tools tape.
> 
> I'll send it to you offline.
> 
> ... Russ Burtnett
> 
> P.S. No "packrat" comments please.
> 

Re: REXXDATE MODULE

[Schuh, Richard]

I fully agree with the retirement of these programs. If DATE() doesn't fill the 
bill, something else may.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Scott Rohling
Sent: Monday, June 06, 2011 10:10 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: REXXDATE MODULE

I do recall this function and even used it (trying to find archives) back in 
the pre-Y2K conversions.  The internal DATE() function in REXX seems to provide 
most of what is needed, though.  You can translate date formats .. and I 
usually do date calculations using DATE('B).  I'm pretty sure REXXDATE did date 
calculations/conversion - but I need to dig up my old code.  If I can find out 
more I will post, but would consider converting to DATE() and some REXX code to 
avoid reliance on the module (which I doubt is supported).

Scott Rohling

On Mon, Jun 6, 2011 at 10:39 AM, Schuh, Richard 
mailto:rsc...@visa.com>> wrote:
We have a legacy (pejorative intended) program named REXXDATE MODULE for which 
we have no source. It is dated 8/3/1994, which predates my arrival at Visa. 
Does anyone know if this is something that was made generally available to the 
VM community and, if so, is the source available? I has suddenly started 
blowing up, repeatable, for one application. I really don't want to 
dis-assemble it for debugging purposes.

Regards,
Richard Schuh

REXXDATE MODULE

[Schuh, Richard]

We have a legacy (pejorative intended) program named REXXDATE MODULE for which 
we have no source. It is dated 8/3/1994, which predates my arrival at Visa. 
Does anyone know if this is something that was made generally available to the 
VM community and, if so, is the source available? I has suddenly started 
blowing up, repeatable, for one application. I really don't want to 
dis-assemble it for debugging purposes.


Regards,
Richard Schuh

Re: service all status ptf

[Schuh, Richard]

I empathize with you on this one, Mike. Whenever I am asked a question that is 
answered in the HELP files, my usual answer is the HELP command to enter.  

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Mike Walter
> Sent: Thursday, May 26, 2011 2:05 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: service all status ptf
> 
> Entirely true, Kris.
> 
> But with our dearth of CMS users (no more than 25 at any 
> point in time), I just deleted the HELP saved segment and 
> stopped saving it.  There's not much in FST memory savings 
> for so few users of the HELP disk, and so few that ever even 
> enter the HELP command.  I do track monthly use of the HELP 
> command, and 98% if its use is us two VM sysprogs.  We can 
> suffer the incredible delay to read the MAINT 19D FST into 
> our memory.  (tongue firmly in cheek)
> 
> Mike
> 
> 
> 
> "Kris Buelens"  
> 
> Sent by: "The IBM z/VM Operating System" 
> 05/26/2011 03:13 PM
> Please respond to
> "The IBM z/VM Operating System" 
> 
> 
> 
> To
> IBMVM@LISTSERV.UARK.EDU
> cc
> 
> Subject
> Re: service all status ptf
> 
> 
> 
> 
> 
> 
> Also the 19D disk has a shared segment for the FSTs.  But, 
> unlike fro 190 and 19E, there is no message telling you the 
> saved segment is no longer used as the FST's have been updated.
> So, beside changing MAINT's directory to get 19D linked in 
> RR, I had something like this in my and MAINT's PROFILE EXEC:
> 'SEGMENT RESERVE HELP'
> if rc<>0 then say 'Could not check status of HELP saved segment'
> else do
>'ACCESS 19D Z (SAVEONLY'
>if rc<>0 then say 'You should rebuild the HELP segment'
> end
> 
> 2011/5/26 Mike Walter  Steve,
> 
> When you: ipl 190 parm savesys cms
> the active CMS FSTs (File Status Table) for the 190 and 19E 
> disks are saved (for the 190 disk) as the S-STAT, and (for 
> the 19E disk) as the Y-STAT.
> The FST contains a pointers to the location of every file on 
> that minidisk (if you're from z/OS, think a minidisk's FST as 
> a VTOC).  When you SAVECMS, the FST is saved into the S-STAT 
> and Y-STAT, which are included in the CMS "Named Saved System" (NSS).
> 
> Subsequently, any user executing IPL CMS benefits by having 
> access to the SHARED saved FSTs for the 190 disk (S-STAT) and 
> 19E (Y-STATS) files without having to load those FSTs into 
> their virtual machine's memory. The overall z/VM system 
> benefits by all users sharing the same memory containing 
> those two FSTs (instead of every user having their own copy); 
> that savings used to be more important in days of yore when a 
> typical VM system had hundreds or thousands of CMS users (and 
> lower system physical max memory sizes).
> 
> Key point (finally!):
> If the FST on the 190 or 19E disk is altered in any way, it 
> will no longer match the one saved by SAVESYS.  Hence the 
> messages you received are issued when "CMS" is IPLed.  So... 
> what alters the FST?  Well... anything that writes to the 
> disk.  When you have a disk LINKED R/W, and ACCESS it, its 
> FST is loaded into your VM's memory.  When the CMS command 'RELEASE'
> is issued against that minidisk, the FST is re-written to 
> disk (even if no files were changed; the last-accessed date 
> is updated on the disk regardless).  Care to bet on whether 
> one or more of the VMSES/E commands ACCESSes and RELEASEs the 
> 190 and/or 19E disks (even if not as filemode S
> or Y) in the process of executing your command?:-)   The mdisk FST
> update cannot happen when the disk is accessed R/O.
> 
> 
> So.. before you re-save CMS again:
> - Change MAINT's directory entry for 190 and 19E to "RR" 
> links  (changing the directory has no effect on MAINT current 
> LINK modes until MAINT is logged off/logged on again).
> - From MAINT, issue 'CP LINK * 190 190 RR' and 'CP LINK * 19E 19E RR'
> (thus eliminating the need to logoff/logon)
> - repeat your process to re-save CMS.
> 
> Mike Walter
> Aon Corporation
> The opinions expressed herein are mine alone, not my employer's.
> 
> 
> 
> Steve Harman 
> 
> Sent by: "The IBM z/VM Operating System" 
> 05/26/2011 01:26 PM
> Please respond to
> "The IBM z/VM Operating System" 
> 
> 
> 
> To
> IBMVM@LISTSERV.UARK.EDU
> cc
> 
> Subject
> Re: service all status ptf
> 
> 
> 
> 
> 
> 
> That helped, thanks.
> 
> I still have the problem if the PTF I query is not found.  I 
> only lose the
> 
> Y-Stat (19E).  If the PTF is found, there is no problem.
> 
> service all status UM33290VMFSRV2760I SERVICE processing 
> started VMFSRV1226I CP (5VMCPR40%CP) PTF UM33290
> status:
> VMFSRV1226IRECEIVED  05/26/11
> 11:55:07
> VMFSRV1226IAPPLIED   05/26/11
> 11:55:09
> VMFSRV1226IBUILT 05/26/11
> 11:55:57
> VMFSRV1226IPUT2PROD  05/26/11
> 11:58:04
> VMFSRV2760I SERVICE processing completed successfully Ready; 
> T=0.81/0.86
> 13:16:24
> q disk
> LABEL  VDEV M  STAT   CYL TYPE BLKSZ   FILES  BLKS USED-(%) 
> BLKS LEFT  BLK
> 
> TOTAL

Re: Sort IP addresses

[Schuh, Richard]

Or, if you are sorting in a pipe, create a separate sort key and retain the 
original unmolested addresses.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark
> Sent: Tuesday, May 24, 2011 8:49 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Sort IP addresses
> 
> On Tuesday, 05/24/2011 at 11:30 EDT, Dave Jones 
> 
> wrote:
> > num1 = right(num1,3,'0')
> > num2 = right(num2,3,'0')
> > num3 = right(num3,3,'0')
> > num4 = right(num4,3,'0')
> > padded_IP_addr.i = num1 || '.' || num2 || '.' || num3 || '.' || num4
> 
> That's ok for an intermediate result for sorting, but dogma 
> requires that include "i" in there so that you can relate it 
> back to the original list. 
> A dotted-quad element with leading zeros is traditionally 
> interpreted as octal.
> 
> Alan Altmark
> 
> z/VM and Linux on System z Consultant
> IBM System Lab Services and Training
> ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
> 

Re: Sort IP addresses

[Schuh, Richard]

Here is something I wrote years ago to verify the format of an IP address. It 
was written to  verify a single IP address per call. You might be able to use 
it as a starting point.

'PIPE (end \ name VeriftIPA)',   
'\ var ipa', 
   '| v: verify /.0123456789/',  
   '| deblock linend .', 
   '| pad 1 0',  
   '| p: pick w1 <<= /255/', 
   '| c: count lines',   
   '| join * /./',   
   '| var ipaddr'
'\ v:',  
   '| stem badchar.',
'\ c:',  
   '| var segs', 
'\ p:',  
   '| stem badsegs.' 

Instead of the "pad 1 0" stage you could "pad 3 left 0" to make all octets 3 
bytes long. 

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Jim Bohnsack
> Sent: Tuesday, May 24, 2011 7:40 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Sort IP addresses
> 
> Does anyone have an xedit macro, or some other means, to sort 
> a column of ip addresses that will accommodate the varying 
> number of digits between the dots.  I looked on the IBM 
> download website, but don't see anything.
> 
> Jim Bohnsack
> 
> --
> James Bohnsack
> (972) 596-6377 home/office
> (972) 342-5823 cell
> 

Re: DASD HA & R0 ?

[Schuh, Richard]

I don't think that there is any doubt about it being writable, There was a CCW 
for it. Writing record 0 was all that was needed to clear a track when you 
initialized a track (not a security write). There was also Write Home Address 
which marked the start of a track. It was needed for new disks. The vendor did 
not initialize them way back then.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Michael Harding
Sent: Friday, May 20, 2011 12:39 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DASD HA & R0 ?


If you're going back that far, ISTR that R0, if writeable at all, was used on 
an otherwise bad track to point to its alternate.

--
Mike Harding
z/VM System Support

mhard...@us.ibm.com
mike.b.hard...@kp.org
mikehard...@mindless.com
(925) 926-3179 (w)
(925) 323-2070 (c)
IM: VMBearDad (AIM), mbhcpcvt (Y!)


The IBM z/VM Operating System  wrote on 05/20/2011 
11:56:14 AM:

> From: "Schuh, Richard" 
> To: IBMVM@LISTSERV.UARK.EDU
> Date: 05/20/2011 11:56 AM
> Subject: Re: DASD HA & R0 ?
> Sent by: The IBM z/VM Operating System 
>
> Must have been a thing from OS/360, then, probably from a time
> before there was Sense id and RDC. Writing the capacity of the track
> in R0 might have been helpful in those days. The fact that the Write
> R0 CCW erases the entire track insures that the part about updating
> it is incorrect.
>
> Regards,
> Richard Schuh
>

Re: DASD HA & R0 ?

[Schuh, Richard]

Must have been a thing from OS/360, then, probably from a time before there was 
Sense id and RDC. Writing the capacity of the track in R0 might have been 
helpful in those days. The fact that the Write R0 CCW erases the entire track 
insures that the part about updating it is incorrect.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark
> Sent: Friday, May 20, 2011 10:45 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: DASD HA & R0 ?
> 
> On Friday, 05/20/2011 at 11:55 EDT, "Schuh, Richard" 
> wrote:
> > I think I remember R0 being referred to as the Track 
> Capacity record. 
> > It
> was 
> > not a constant, but held the remaining capacity after the last
> formatting write.
> 
> It is possible that some OSes write things to R0, but CMS and 
> CP don't. 
> CMS FORMAT and DSF write R0 and HA with zeros.  Use DDR 
> "PRINT 0 0 0" to 
> see them.  Each time you WRITE R0, you erase the track.
> 
> Track capacity is determined by using formulae described in 
> the book with 
> data from the READ DEVICE CHARACTERISTICS command.
> 
> Alan Altmark
> 
> z/VM and Linux on System z Consultant
> IBM System Lab Services and Training 
> ibm.com/systems/services/labservices 
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
> 

Re: DASD HA & R0 ?

[Schuh, Richard]

I think I remember R0 being referred to as the Track Capacity record. It was 
not a constant, but held the remaining capacity after the last formatting write.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark
> Sent: Friday, May 20, 2011 7:04 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: DASD HA & R0 ?
> 
> On Friday, 05/20/2011 at 09:00 EDT, Tom Huegel 
>  wrote:
> > Can anyone point me to a doc that has the format of ECKD 
> Home Address
> (HA) and 
> > Record 0 (R0) records?
> 
> It's odd that the most recent programming reference for ECKD 
> DASD (IBM ESS S/390 Command Reference, SC26-7298) does not 
> describe the format of the HA except to say that it is 5 bytes.
> 
> Dragging out an old 3880 book, READ HOME ADDRESS transfers 
> "the flag, cylinder, and head bytes of the home address 
> area."  I'm assuming that's 
> of the form FCCHH.   I only see a description of flag byte 
> bits 6-7='10': 
> Next track defective.
> 
> In that same 3880 book, READ SPECIAL HOME ADDRESS transfers 
> "the skip control bytes, segment number, physical address 
> bytes, flag, and identifier bytes (CCHH) of the home address 
> area" with no further description.
> 
> I'm guessing that detailed HA content is part of the 
> proprietary disk architecture, but you'd have to raise a 
> problem to your storage vendor to find out.
> 
> R0 doesn't have any special format except that it is 8 bytes 
> with KL=0.
> 
> The most r
> Alan Altmark
> 
> z/VM and Linux on System z Consultant
> IBM System Lab Services and Training
> ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
> 

Re: zvm directions

[Schuh, Richard]

Too bad it will not work for geographically dispersed LPARS :-(

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark
> Sent: Wednesday, May 18, 2011 11:28 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: zvm directions
> 
> On Wednesday, 05/18/2011 at 12:07 EDT, Marcy Cortes 
>  wrote:
> 
> > I don't see LGR as a load balancing solution at all.  We 
> will continue
> to use 
> > our F5 load balancers as well as the WAS IHS plugin for 
> that effort.  
> > I
> see it 
> > more for a planned outage move for things you want to move 
> away for a
> while 
> > without the reboot.
> 
> An excellent assessment, Marcy.  :-)  LGR was not designed to 
> replace any application-level workload balancing solutions 
> (F5).  Those balancing solutions provide the needed HA in 
> case you lose a VM LPAR unexpectedly.
> 
> LGR will let you take back control of your VM LPARs.  No 
> longer will you need to get 15 application owners to agree on 
> a time for you to take down and service the VM system.  Their 
> servers keep running and the application monitor dashboard 
> shows green.
> 
> Oh, and I suppose there is an additional benefit in that if 
> someone says,
> "*I* can relocate a server to a different rack in case it 
> starts to overheat!" you can stick out your tongue and then 
> say "*I* can relocate a server when I want to.  My machine 
> doesn't overheat."  :-)
> 
> Alan Altmark
> 
> z/VM and Linux on System z Consultant
> IBM System Lab Services and Training
> ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
> 

Re: Nothing today?

[Schuh, Richard]

None from me.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Frank M. Ramaekers
Sent: Tuesday, May 17, 2011 1:10 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Nothing today?

No posts today?


 Frank M. Ramaekers Jr.





[cid:image001.gif@01CC14A4.79CE3150]


Systems Programmer


MCP, MCP+I, MCSE & RHCE




American Income Life Insurance Co.


Phone: (254)761-6649




1200 Wooded Acres Dr.


Fax: (254)741-5777




Waco, Texas  76701







_ This message contains 
information which is privileged and confidential and is solely for the use of 
the intended recipient. If you are not the intended recipient, be aware that 
any review, disclosure, copying, distribution, or use of the contents of this 
message is strictly prohibited. If you have received this in error, please 
destroy it immediately and notify us at privacy...@ailife.com.

Re: Pipe, sort and coherence...

[Schuh, Richard]

Would you not want all of the passwords to survive in that instance?


Regards,
Richard Schuh






(for crucial minidisks I let the ALL read password survive, just for the case 
I'd be forced to IPL without RACF)

Re: 3590 assign problem

[Schuh, Richard]

You can specify NOASSIGN on the ATTACH command. If it still fails after that, 
it may be that it is shared with z/OS and has not been properly taken offline 
there. It must be made OFFLINE to JES and, if present, MIM.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Neale Ferguson
> Sent: Thursday, April 28, 2011 10:07 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: 3590 assign problem
> 
> X-posted - IBMVM & LINUX-390
> 
> When we attach a tape drive (3590) to a Linux guest, the tape 
> driver attempts to execute an assign operation on the device 
> which is getting an
> error:
> 
> TRACE TYPE IO, CPU   TIME 12:08:25.022913
> TRACEID = VMTAPE, TRACESET = TAPE, IODATA = 100 USER = 
> SLES10S2, I/O OLD PSW = 07041000 8000  001352BE 
> DEVICE = 0585, SCSW = 00C04017 7FFDC448 0E00  ** I/O 
> ERROR ** ESW = 0080
> I/O PRIORITIES: CHANNEL =   0, CURRENT = 100, ORIGINAL = 100
> OUT-PRIORITIZED COUNT = 0
> -> CCW(1) = B74B 7FFC6FA4, CCW ADDRESS = 7FFDC438
> DATA =   00 *...*
> -> CCW(2) = 0304 7FF8A058, CCW ADDRESS = 7FFDC440 ** IDA **
> 
> The subsequent sense reveals:
> -> CCW(1) = 04200020 7FFEF810, CCW ADDRESS = 7FFEF7F0
> DATA = 804800C0 20122041 0003FF00   
> **  0010 2004 1011  
> **
> 
> On the linux side syslog shows:
> 
> kernel: TAPE_STD: 0.0.0181: assign failed - device might be busy
> 
> A search reveals a great candidate APAR for HCPTSS: VM63414, 
> however, this was a problem back in 2005 for z/VM 4.4 and 
> we're on 5.4 RSU 0901. Before, I go any further is this a 
> problem anyone else has seen? If not, I'll go through normal 
> channels (actually I'll probably do it in parallel).
> 
> Neale
> 

Re: 391 391 RR?RE: password_on_cmds feature statement in CONFIG

[Schuh, Richard]

I hope that they do not have the MAINT 191 R/W. I would hate to log on to MAINT 
and not get my own 191 R/W because some Linux guest already had it in write 
mode.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Rob van der Heij
> Sent: Friday, April 22, 2011 3:14 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: 391 391 RR?RE: password_on_cmds feature 
> statement in CONFIG
> 
> On Fri, Apr 22, 2011 at 11:24 PM, Schuh, Richard 
>  wrote:
> > Might I ask a dumb question?
> >
> > If it is in the PROFILE EXEC, why not put it in the 
> directory entry? 
> > If it is there and is detached, it can be reacquired by the 
> command, 
> > "CP LINK *
> > 391 391 RR" without having to enter a password. And without ever 
> > having to know that it is a disk defined in the MAINT entry.
> 
> You're correct. I tried to avoid changes to the PROFILE EXEC 
> because I fear it will be on each of the servers and they may 
> have the 191 R/W (but we already discussed options to make 
> the guest detach that disk).
> 
> One reason you find this kind of things in programs is when 
> the userid or mini disk address is determined by some 
> programmed logic. Mini disk passwords are a pain in that 
> situation and don't really provide any security because the 
> link is issued in the user virtual machine. One of my peers 
> was very proud of his program that scrambled the password in 
> the code (so you could not see it when you browse the 
> module). He was pretty shocked when I did a trace on the DIAG 
> 08 to see the password... :-)
> 
> Rob
> 

391 391 RR?RE: password_on_cmds feature statement in CONFIG

[Schuh, Richard]

Might I ask a dumb question?

If it is in the PROFILE EXEC, why not put it in the directory entry? If it is 
there and is detached, it can be reacquired by the command, "CP LINK * 391 391 
RR" without having to enter a password. And without ever having to know that it 
is a disk defined in the MAINT entry.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Scott Rohling
Sent: Friday, April 22, 2011 1:12 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: password_on_cmds feature statement in CONFIG

Rob --  Right you are!I just checked this on a system that has 
password_on_cmds NO  for LINK..  (and RACF installed controlling links)

If I enter the LINK with a password:

link maint 191 391 rr read
HCPLNM118E MAINT 0191 not linked; command format not valid
Ready(00118); T=0.01/0.01 16:07:36

Note that if I leave the password off - it works fine -- (and btw - my user is 
authorized to LINK to MAINT 191 in RACF)

So Terry -- you will need to remove the password from the LINK statement in the 
PROFILE EXECs before setting password_on_cmds to NO!   Now that you know it 
works without the password -- that should be safe.

Good catch, Rob ...

Scott Rohling

On Fri, Apr 22, 2011 at 1:59 PM, Rob van der Heij 
mailto:rvdh...@gmail.com>> wrote:
On Fri, Apr 22, 2011 at 9:24 PM, Scott Rohling 
mailto:scott.rohl...@gmail.com>> wrote:

> Hi Terry -  If RACF is installed and controlling links  - then the password
> on the link statement is likely being ignored and is there from pre-RACF
> days..

The password is ignored now because access control is done by RACF.
But my recollection is that when he changes CP to not allow
password_on_cmds the LINK statement with a password would be rejected
despite the fact that RACF does not use the password. If so, then the
change in the configuration file might break things that work now...

I believe this was what justified a local mod for one of our systems.
We could not go through the code to check for statements with inline
password, but did not want to allow people to type their password on
logon in plain text either.

Rob

Re: password_on_cmds feature statement in CONFIG

[Schuh, Richard]

Shouldn't that be "ADDRESS COMMAND 'CP LINK...'"? 

Regards, 
Richard Schuh 

 

> 
> In a fully secured VM system (i.e. with an ESM), the only 
> command that requires a password is LOGON.  All other actions 
> (LINK, XAUTOLOG) are (should be) managed by the ESM without a 
> dependency on passwords.
> 
> Without an ESM, passwords are avoided for LINK and AUTOLOG by 
> putting the LINK and AUTOLOG statements in the appropriate 
> directory entry.  If you simply MUST make a disk vulnerable 
> to improper access by storing its password on some other disk 
> (i.e. in an exec), then use ADDRESS COMMAND "LINK..." as that 
> will override the no-password-on-LINK directive.
> 
> Alan Altmark
> 
> z/VM and Linux on System z Consultant
> IBM System Lab Services and Training
> ibm.com/systems/services/labservices
> office: 607.429.3323
> mobile; 607.321.7556
> alan_altm...@us.ibm.com
> IBM Endicott
> 

Re: Tapeless segment tranfser between LPARs?

[Schuh, Richard]

But that only works for DCSSs, not NSSs. 

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Rob van der Heij
> Sent: Thursday, April 21, 2011 7:59 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Tapeless segment tranfser between LPARs?
> 
> On Thu, Apr 21, 2011 at 4:53 PM, Daniel Bewley 
>  wrote:
> 
> > Is there another freely available utility out there for moving 
> > segments from spool to minidisk and back again?  Or is there some 
> > combination of CP commands to retrieve and load non-CP/CMS 
> data into a segment?
> 
> There's DCSSBKUP and DCSSRSAV on the MAINT 193 disk...
> 
> Rob
> 

Re: SFS problem

[Schuh, Richard]

Actually, SECUSER still exists and is something quite different. SECUSER 
defines a secondary user for receiving console messages and entering commands 
and responses. The entries are done as though they came from, not on behalf of, 
the user.

Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of John Hall
Sent: Wednesday, April 20, 2011 7:04 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: SFS problem

If I recall correctly, DIAG D4 is the one that manipulates the secondary ID, 
aka "Alternate ID".  (SECUSER is an old term).  Diag 88 provides the ability to 
link minidisks and perform userid/password validations (if the issuer has 
appropriate authority).

An interesting usage note for this is that DIAG D4 does not change the userid 
associated with any existing (already active) SFS connections.  This is because 
it is a CP function and manipulates the VMDBK.  Once set, future connections 
(via APPC/VM Connect) will utilize the Alternate ID. ... This is why severing 
all connections prior to setting the AltID will "fix" this type of problem, 
because CMS will (re) connect and use the AltID.

If this is Nora's problem, an easy work around would be wrap the job with an 
exec that uses DMSGETWU and DMSPUSWU to set a new default work unit that 
contains the appropriate user, then run the job from the exec, then finally 
reset with DMSPOPWU. (If I'm remembering all of this correctly)

John

--
John Hall
Safe Software, Inc.
727-608-8799
johnh...@safesoftware.com<mailto:johnh...@safesoftware.com>



On Tue, Apr 19, 2011 at 11:48 AM, Schuh, Richard 
mailto:rsc...@visa.com>> wrote:
Isn't that DIAG 88, instead of SECUSER?


Regards,
Richard Schuh






From: The IBM z/VM Operating System 
[mailto:IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of 
John Hall
Sent: Tuesday, April 19, 2011 6:41 AM

To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>
Subject: Re: SFS problem

Nora,
Batch jobs normally run with the privileges of the "owner" of the job, using 
the SECUSER facility in z/VM.  With SFS, this can lead to unexpected results 
when a prior batch job leaves the worker with a connection to the filepool 
under a different user's id.  If the job ordering/selection of batch workers is 
somewhat random, you could see the outcome that you're experiencing (sometimes 
it works, sometimes it fails).

Re: SFS problem

[Schuh, Richard]

Isn't that DIAG 88, instead of SECUSER?


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of John Hall
Sent: Tuesday, April 19, 2011 6:41 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: SFS problem

Nora,
Batch jobs normally run with the privileges of the "owner" of the job, using 
the SECUSER facility in z/VM.  With SFS, this can lead to unexpected results 
when a prior batch job leaves the worker with a connection to the filepool 
under a different user's id.  If the job ordering/selection of batch workers is 
somewhat random, you could see the outcome that you're experiencing (sometimes 
it works, sometimes it fails).

Re: Sevice level

[Schuh, Richard]

That would be nice. It ought to also have a way to answer Marcy's question, 
"Has PTF xxx been applied to the system (or, perhaps, to a specified module)?" 
without having to wade through a list of the universe of PTFs. As long as we 
are dreaming, it would be nice to have a defined interface so that we could 
interrogate cooperative ISV modifications to CP (VSSI, CA, et. al.) via the 
same command. 

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of David Boyes
> Sent: Sunday, April 10, 2011 3:28 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Sevice level
> 
> What I would like:
> 
> 1) a flag for the output of Q CPLEVEL that indicates that 
> additional service beyond the displayed level has been 
> applied. Something like 8801++.
> 
> Applying the next RSU would reset the flag until the next PTF 
> outside the RSU is applied.
> 
> 2) a new option to SERVICE that does the VMFSIM magic to list 
> all PTFS applied to a component. Example: 
> 
> SERVICE LIST CP
> 
> Resulting in something like:
> 
> RSU 8801
> PTF c
> PTF yyygyygyy
> Etc
> 
> I think that would help non-SES wizards to understand without 
> breaking  the older method.
> 
> 
> 
> 
> On Apr 9, 2011, at 20:06, "Alan Altmark" 
>  wrote:
> 
> > Following up on Nick Harris' expectation to see a change to QUERY 
> > CPLEVEL after applying COR service to CP, I'd like to open a 
> > discussion on how folks perceive service levels.  That is, is there 
> > some way that you feel IBM should express the concept of 
> 'service level'?
> > 
> > For the sake of discussion, let us assert that:
> > - We are talking about the running entity, not the copy of 
> the entity 
> > on the build disk.
> > - Unless there are specific pre-reqs or co-reqs, PTFs can 
> be applied 
> > in any order or combination.
> > - Each component (CP, CMS, DIRMAINT, RACF, SES, etc.) has its own 
> > service stream
> > 
> > Regards,
> >  Alan
> > 
> > z/VM and Linux on System z Consultant
> > IBM System Lab Services and Training
> > ibm.com/systems/services/labservices
> > office: 607.429.3323
> > alan_altm...@us.ibm.com
> 

Re: Something wrong with my USERID

[Schuh, Richard]

Since the error message is from CP, the #cp is probably redundant.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Neale Ferguson
Sent: Wednesday, April 06, 2011 9:23 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Something wrong with my USERID

#CP TERM MODE VM


On 4/6/11 12:20 PM, "Martin, Terry R. (CMS/CTR) (CTR)" 
 wrote:

Hi

I have something set wrong for my userid on this one LPAR and for the life 
can't see it.

When I issue a basic command such as Q DISK I get the following:

12:14:28 q disk
12:14:28 HCPCQV003E Invalid option - DISK

Re: z/VM & z/OS sharing same DASD

[Schuh, Richard]

Having been in the same situation, my advice is that it is better to be safe 
than sorry. We had one individual who, on more than one occasion, formatted MVS 
volumes for use by TPF test systems. Needles to say, the MVS folks were not 
happy. I took the power away from him on two fronts when I was given 
responsibility for VM - 1. I took Class B away from him, and 2. I put all MVS 
disks that were not intentionally shared in the Not_Accepted list. 

The DASD Storage Management  group, who controlled the world when it came to 
DASD surface acreage,  thought it was a good idea to interleave the devices, 
giving VM the even numbers and MVS the odd. The MVS folks were trying to time 
the remote (2000 miles) replication of their DASD during what turned out to be 
a heavy period for VM. Our pleas to segregate the VM and MVS DASD finally 
struck home. They were not expecting VM to interfere with them. The outcome was 
not pretty - there were timeouts, and even failures, of the replication process 
due to the load that VM was putting on the channels. 

For me, the best practices are 1. Segregate the dasd, 2. Only have the disks 
that are intended for use by VM online, and 3. only give the power to ATTACH 
and DETACH to responsible parties who have a need for doing so. 

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Karl Huf
> Sent: Tuesday, April 05, 2011 3:44 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: z/VM & z/OS sharing same DASD
> 
> I could have sworn I had seen something about this in a 
> presentation regarding "best practices" for configuring z/OS 
> & z/VM LPAR's that share the same DASD subsystems but now 
> that I need it, no joy.
> 
> We have 2 (z10) CEC's, each with z/VM and z/OS LPAR's 
> attached via FICON Directors to a pair of DS8700's.  As 
> currently configured all of the DASD is defined on common 
> LCU's and all of the DASD is online to all systems. 
> This makes me nervous but perhaps my fears are unfounded?  My 
> gut tells me that a better configuration would be having the 
> VM DASD segregated onto dedicated LCU's and the rest of the 
> MVS DASD on their own LCU's - and that the respective devices 
> not be online to the "foreign" OS's.  Due to other recent 
> discoveries we have some DASD reconfiguration work ahead of 
> us anyway and, if it's worthwhile, I'd like to pile on with 
> getting the VM DASD to be isolated as part of that work - but 
> at the moment I can't quantify to those that would do the work why.
> 
> Are there good reasons or am I making mountains where there 
> are no molehills?  TIA.
> 
> 
> __
> _
> Karl S Huf | Senior Vice President | World Wide Technology 
> 840 S Canal, Chicago, IL, 60607 | phone (312)630-6287 | k...@ntrs.com 
> Please visit northerntrust.com 
> CONFIDENTIALITY NOTICE: This communication is confidential, may be 
> privileged and is meant only for the intended recipient. If 
> you are not 
> the intended recipient, please notify the sender ASAP and delete this 
> message from your system.
> 
> IRS CIRCULAR 230 NOTICE: To the extent that this message or 
> any attachment 
> concerns tax matters, it is not intended to be used and 
> cannot be used by 
> a taxpayer for the purpose of avoiding penalties that may be 
> imposed by 
> law. For more information about this notice, see 
> http://www.northerntrust.com/circular230
> 
> P Please consider the environment before printing this e-mail.
> 

Re: SFS management question

[Schuh, Richard]

Are you running the CRR server? I seem to remember that, even though you do not 
need it for its stated purpose, it is needed for performance reasons.

Another p[possibility is that the log m-disks might be filling up. The control 
data backup is initiated at 80% full, a non-configurable but arbitrary size. 
If, while that backup is running, it reaches 95%, all activity is suspended 
until it is below a given percentage.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Kris Buelens
Sent: Thursday, March 31, 2011 3:16 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: SFS management question

I some release it became less "required" to run SFS reorganisations.  You can 
run a FILEPOOL REORG, that will only reorganise storage pool 1, that is, the 
SFS DB2-like catalog.  There is no tool to reorganise the other storage groups 
(apart from a backup & restore).

2011/3/31 Tony Thigpen mailto:t...@vse2pdf.com>>
It's been a long time since I managed a production SFS system so I need
a little refresher.

On our development system, I ran out of space on my SFS pool, but was
able to reduce the usage down to just 45% by deleting a bunch of stuff
we no longer needed. Now the SFS seems 'slow'. Do I need to run a job to
'compress' the SFS or re-org the directory?

--

Tony Thigpen



--
Kris Buelens,
IBM Belgium, VM customer support

Re: DDR Question

[Schuh, Richard]

Really important. You could measure the size of the IBGs and the space before 
tape marks in half inch and inch increments. And you could use tape developer 
to see the actual bits on the tape.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Tom Huegel
Sent: Wednesday, March 30, 2011 9:32 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR Question

I don't believe I ever worked with 200 bpi tapes, but I did work were we had 8 
tape drives 6 were 800 bpi and 2 were 1600 bpi with the optional high speed 
rewind. I guess maybe byte counts were more important back then..

On Wed, Mar 30, 2011 at 10:45 PM, Schuh, Richard 
mailto:rsc...@visa.com>> wrote:
Round tape reels! Now, that is old. Since I remember them too, we are both 
showing our age. Do you remember when the 200 bpi density?


Regards,
Richard Schuh






From: The IBM z/VM Operating System 
[mailto:IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of 
Tom Huegel
Sent: Wednesday, March 30, 2011 8:37 PM

To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>
Subject: Re: DDR Question

Slight brain fart, I didn't even think of hardware compression duh! I guess the 
only real way to to do it is just experimentation.
I still seem to remember a program from long ago, and it may have been a VSE 
program, that would tell you how many bytes would go to the tape, in fact I 
think it told you how many feet of tape (2400/3400) would be used..

Thanks guys.

On Wed, Mar 30, 2011 at 5:14 PM, Tom Duerbusch 
mailto:duerbus...@stlouiscity.com>> wrote:
If you are doing software compression, then, perhaps use the Pipe DDR stage and 
route it to the "count" stage.
But knowing how much compression the hardware will donot obvious to me.

However, once you do have a compressed tape, DITTO TMP will tell you how much 
tape the compressed dataset took on the media.

Tom Duerbusch
THD Consulting

>>> Rich Greenberg mailto:ric...@panix.com>> 3/30/2011 4:55 
>>> PM >>>
On: Wed, Mar 30, 2011 at 11:37:00AM -0700,Tom Huegel Wrote:

} That doesn't show the compressed byte count is (would be). The goal here is
} to be able to predict how many tapes I will need to do backups.

If you are doing hardware compression in the tape drive, I don't think
there is any way for DDR to know the compressed byte count.  Software
compression, yes it would.

I suspect that  the easiest way to determine the tape counts will be
experimentally.

--
Rich Greenberg  Sarasota, FL, USA richgr atsign panix.com<http://panix.com>  + 
1 941 378 2097
Eastern time.  N6LRT  I speak for myself & my dogs only.VM'er since CP-67
Canines: Val, Red, Shasta, Zero & Casey (At the bridge)Owner:Chinook-L
Canines: Red & Cinnar (Siberians)  Retired at the beach  Asst Owner:Sibernet-L

Re: DDR Question

[Schuh, Richard]

Round tape reels! Now, that is old. Since I remember them too, we are both 
showing our age. Do you remember when the 200 bpi density?


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Tom Huegel
Sent: Wednesday, March 30, 2011 8:37 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR Question

Slight brain fart, I didn't even think of hardware compression duh! I guess the 
only real way to to do it is just experimentation.
I still seem to remember a program from long ago, and it may have been a VSE 
program, that would tell you how many bytes would go to the tape, in fact I 
think it told you how many feet of tape (2400/3400) would be used..

Thanks guys.

On Wed, Mar 30, 2011 at 5:14 PM, Tom Duerbusch 
mailto:duerbus...@stlouiscity.com>> wrote:
If you are doing software compression, then, perhaps use the Pipe DDR stage and 
route it to the "count" stage.
But knowing how much compression the hardware will donot obvious to me.

However, once you do have a compressed tape, DITTO TMP will tell you how much 
tape the compressed dataset took on the media.

Tom Duerbusch
THD Consulting

>>> Rich Greenberg mailto:ric...@panix.com>> 3/30/2011 4:55 
>>> PM >>>
On: Wed, Mar 30, 2011 at 11:37:00AM -0700,Tom Huegel Wrote:

} That doesn't show the compressed byte count is (would be). The goal here is
} to be able to predict how many tapes I will need to do backups.

If you are doing hardware compression in the tape drive, I don't think
there is any way for DDR to know the compressed byte count.  Software
compression, yes it would.

I suspect that  the easiest way to determine the tape counts will be
experimentally.

--
Rich Greenberg  Sarasota, FL, USA richgr atsign panix.com  + 
1 941 378 2097
Eastern time.  N6LRT  I speak for myself & my dogs only.VM'er since CP-67
Canines: Val, Red, Shasta, Zero & Casey (At the bridge)Owner:Chinook-L
Canines: Red & Cinnar (Siberians)  Retired at the beach  Asst Owner:Sibernet-L

Re: DDR Question

[Schuh, Richard]

Is there anything on the download site that will give you what you want? There 
are a few DDR-related tools there.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Tom Huegel
Sent: Wednesday, March 30, 2011 11:37 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR Question

That doesn't show the compressed byte count is (would be). The goal here is to 
be able to predict how many tapes I will need to do backups.

On Wed, Mar 30, 2011 at 11:30 AM, Schuh, Richard 
mailto:rsc...@visa.com>> wrote:
There is a COUNT option on the PRINT or TYPE command that will display only the 
COUNT fields, but that doesn't appear to be what you want.


Regards,
Richard Schuh






From: The IBM z/VM Operating System 
[mailto:IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of 
Tom Huegel
Sent: Wednesday, March 30, 2011 11:16 AM
To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>
Subject: DDR Question

Hello all,

 I seem to remember from long ago a program, or option of DDR ( I sure can't 
find it now) that would do DDR DUMP and not actually produce an output tape but 
just print a byte count of what would have been dumped...

Does anyone know what I am talking about?

Tom

Re: DDR Question

[Schuh, Richard]

There is a COUNT option on the PRINT or TYPE command that will display only the 
COUNT fields, but that doesn't appear to be what you want.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Tom Huegel
Sent: Wednesday, March 30, 2011 11:16 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: DDR Question

Hello all,

 I seem to remember from long ago a program, or option of DDR ( I sure can't 
find it now) that would do DDR DUMP and not actually produce an output tape but 
just print a byte count of what would have been dumped...

Does anyone know what I am talking about?

Tom

Re: SFPURGER problem

[Schuh, Richard]

It probably ought to close console files only lest it mess up some application. 
Even then, it should probably restrict the machines whose consoles it closes to 
a list of known servers for the same reason.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Kris Buelens
Sent: Wednesday, March 23, 2011 1:55 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: SFPURGER problem

Spool files get as timestamp the time they are opened, not when they are 
closed.  My SFPURGER had an exception for OPERATNS: never delete anything.  
Stronger: when one of my 20 VM systems had a NOHOLD dump in its reader, I got 
an email sent to my reader.

This is a good reason to implement some automation that closes spool files 
around midnight for example.  With the example below: if you don't close 
CONSOLE files and VM runs longer than 60 days, right after the first IPL, all 
consoles look "old" and get purged.  I've got such an EXEC for those who want 
it.

2011/3/23 Frank M. Ramaekers 
mailto:framaek...@ailife.com>>
I just had a major problem with this program.   Last night we took a CP hit and 
a CPDUMP was created.  I found out this morning that SFPURGER had deleted it, 
although:

***
* Ignore any spool files found in the NSS queue (privilege class E)
QUEUE NSS ACTION IGNORE

* Keep spool files owned by maintenance user IDs
USERID MAINT* ACTION IGNORE

* Purge dump files after 4 weeks.  Ignore the rest
TYPE DMP DAYS 29  ACTION PURGE

* If user hold +15 day otherwise delete after 30 days
QUEUE RDRDAYS 60  HOLD USER   ACTION PURGE
QUEUE RDR HOLD USER   ACTION IGNORE
QUEUE RDRDAYS 30  ACTION PURGE
QUEUE RDR ACTION IGNORE
Yet,

****  *
**SFPURGER Run File   *
** Created by z/VM  5741-A0523 Mar 2011   00:01:33*
** VMUTIL at MKMFVM   *
****  *

Reason code 1 QUEUE NSS ACTION IGNORE.
Reason code 2 USERID MAINT* ACTION IGNORE.
Reason code 3 TYPE DMP DAYS 29 ACTION PURGE.
Reason code 4 QUEUE RDR DAYS 60 HOLD USER ACTION PURGE.
  :
  :
SFP100I   PURGE OPERATNS  RDR   0001  Reason003   IOV100
  HCPDUMP
SFP100I   PURGE OPERATNS  RDR   0002  Reason003   CPDUMP
  CPDUMP
  :
  :

QUERY from last night:

q rdr operatns all
ORIGINID FILE CLASS RECORDS  CPY HOLD DATE  TIME NAME  TYPE DIST
SYSTEM   0002 D SYS 00098846 001 NONE 03/22 21:29:48 CPDUMPCPDUMP   IOV100
SYSTEM   0005 D SYS 0190 001 NONE 03/22 21:29:48 IOV100HCPDUMP
SYSTEM   0004 D SYS 0189 001 NONE 03/22 20:45:29 IOV100HCPDUMP
SYSTEM   0003 D SYS 0216 001 NONE 03/22 20:45:29 IOV100HCPDUMP
SYSTEM   0001 D SYS 0190 001 NONE 03/22 20:45:29 IOV100HCPDUMP



 Frank M. Ramaekers Jr.






Systems Programmer


MCP, MCP+I, MCSE & RHCE




American Income Life Insurance Co.


Phone: (254)761-6649




1200 Wooded Acres Dr.


Fax: (254)741-5777




Waco, Texas  76701







_ This message contains 
information which is privileged and confidential and is solely for the use of 
the intended recipient. If you are not the intended recipient, be aware that 
any review, disclosure, copying, distribution, or use of the contents of this 
message is strictly prohibited. If you have received this in error, please 
destroy it immediately and notify us at 
privacy...@ailife.com.



--
Kris Buelens,
IBM Belgium, VM customer support

Re: SFS question

[Schuh, Richard]

Yes.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Gentry, Stephen
Sent: Thursday, March 10, 2011 1:33 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: SFS question

I'm getting the following error on a DMSCLOSE:
51010 - No space for data left in catalog space.
I am writing a group of files, 733 of them, to an SFS pool
Does the error message mean that I don't have enough room in storage group 1?
TIA
Steve

Re: Sending files to JES

[Schuh, Richard]

Also, Active means that the link has been started but the sign-on process has 
not been completed. The status must be Connect before a file can be 
transferred. Either JES has not started the link or there is a problem in the 
definition on either or both ends.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Neale Ferguson
Sent: Tuesday, March 08, 2011 9:44 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Sending files to JES

Alternatively, the TCPNJE add-on-extra to RSCS will allow submission through 
NJE.

Neale


On 3/8/11 12:34 PM, "David Boyes"  wrote:

SPOOL PUN TO RSCS
TAG DEV PUN zos SYSTEM
PUNCH fn ft fm ( NOH

Explanation:

SP PUN TO RSCS sets the destination of the PUNCH command on the VM side. RSCS 
knows to look at the tag data of the incoming files to decide what to do with 
them. TAG DEV PUN zos SYSTEM sets the tag data destination fields to node zos 
(replace with the NJE name of your zos system) SYSTEM, which is normally the 
JES input processor (SYSTEM is a magic word for NJE). PUNCH fn ft fm (NOH takes 
your virtual card deck stored in fn ft fm (must be RECFM F, LRECL 80) and 
punches it to RSCS without any special headers (the NOHeader parm). CP tags the 
virtual card deck with the information from the TAG command, and it ends up in 
RSCS' virtual reader. RSCS looks at the tag data, slurps up the file and sends 
it to zOS.

All this is covered in the RSCS Users' Guide, albeit somewhat opaquely. Feel 
free to ask if you have more questions.

Re: CMS SFS Question

[Schuh, Richard]

I don't believe that I said DELETE USER RICHARD. I certainly did not intend to 
imply that, nor did I intend for someone to infer it. I should have stated it 
better.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Les Koehler
> Sent: Tuesday, March 01, 2011 2:07 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: CMS SFS Question
> 
> That's NOT the scenario you gave in your original note! You 
> wrote about deleting Richard when you wrote:
> 
> It is possible for one user to grant access to other users  
> >>>> who are not enrolled. DELETE USER does not clean up 
> these  >>>> permissions.
> 
> I don't see *any* indication that would trigger a DELETE USER 
> Les (using your scenario, which was reversed from mine, 
> further confusing the issue).
> 
> Les
> 
> Schuh, Richard wrote:
> > It is permissions granted to users who are not enrolled 
> that is the issue. Here is the scenario:
> > 
> > User Richard is enrolled
> > User Les is not enrolled
> > Richard grants Les some SFS authorities.
> > DELETE USER LES is issued without enrolling LES (or no 
> DELETE USER is 
> > issued for LES) The authorities granted to LES by RICHARD 
> are left hanging and will be applied to any newly created LES 
> regardless of the identity of the owner.
> > 
> > If LES is enrolled before the DELETE USER, those 
> authorities granted to LES by others are removed. By doing 
> the ENROLL for 0 blocks for any userid that is to be deleted, 
> no ghost authorities are given to new users. The userids are 
> unconditionally enrolled. If the user has already been 
> enrolled and owns a file space, the enroll will fail. Because 
> all I care about is that the user be enrolled, I ignore that failure. 
> > 
> > 
> > Regards,
> > Richard Schuh
> > 
> >  
> > 
> >> -Original Message-
> >> From: The IBM z/VM Operating System
> >> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Les Koehler
> >> Sent: Tuesday, March 01, 2011 1:24 PM
> >> To: IBMVM@LISTSERV.UARK.EDU
> >> Subject: Re: CMS SFS Question
> >>
> >> I guess there's something implied there that I don't get. 
> >> Scenario, from your note:
> >>
> >> Your task is to delete LES, who is enrolled, from the SFS 
> system LES 
> >> has granted rights to RICHARD but RICHARD is not enrolled
> >>
> >> How does enrolling LES for 0 blocks do anything about the granted 
> >> rights that RICHARD has?
> >>
> >> Les
> >>
> >> Schuh, Richard wrote:
> >>> I simply enroll any user to be deleted for 0 blocks. The
> >> alternative is to scan the sfs directories and files 
> looking for such 
> >> users. It is much easier to attempt the enroll. If it fails, it is 
> >> because the user is already enrolled.
> >>> Regards,
> >>> Richard Schuh
> >>>
> >>>  
> >>>
> >>>> -Original Message-
> >>>> From: The IBM z/VM Operating System 
> >>>> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Les Koehler
> >>>> Sent: Tuesday, March 01, 2011 12:22 PM
> >>>> To: IBMVM@LISTSERV.UARK.EDU
> >>>> Subject: Re: CMS SFS Question
> >>>>
> >>>> I'm curious: How do you find the user who is not enrolled, but 
> >>>> granted rights to the target user to be deleted?
> >>>>
> >>>> Les
> >>>>
> >>>> Schuh, Richard wrote:
> >>>>> The Pipe is the easiest. 
> >>>>>
> >>>>> PIPE < user list | spec /delete user/ 1 w1 nw | cms | >
> >> delete log a
> >>>>> Note, however, that if you have an SFS that has a lot of
> >>>> files and permissions, each DELETE USER can take a long
> >> time, so you
> >>>> do not want to do this on an id that you might need soon 
> after you 
> >>>> enter the PIPE command. In our shop, an individual 
> DELETE USER can 
> >>>> take upwards of 10 minutes.
> >>>>> Cleaning up SFS when a userid is deleted is important from
> >>>> a security standpoint. If the same id should be given to a
> >> different
> >>>> person, it would automatically inherit permissions from 
> the prior 
> >>>> owner. You should be doing a DELETE USER every time that a
> >> userid is
> >&

Re: CMS SFS Question

[Schuh, Richard]

It is permissions granted to users who are not enrolled that is the issue. Here 
is the scenario:

User Richard is enrolled
User Les is not enrolled
Richard grants Les some SFS authorities.
DELETE USER LES is issued without enrolling LES (or no DELETE USER is issued 
for LES)
The authorities granted to LES by RICHARD are left hanging and will be applied 
to any newly created LES regardless of the identity of the owner. 

If LES is enrolled before the DELETE USER, those authorities granted to LES by 
others are removed. By doing the ENROLL for 0 blocks for any userid that is to 
be deleted, no ghost authorities are given to new users. The userids are 
unconditionally enrolled. If the user has already been enrolled and owns a file 
space, the enroll will fail. Because all I care about is that the user be 
enrolled, I ignore that failure. 


Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Les Koehler
> Sent: Tuesday, March 01, 2011 1:24 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: CMS SFS Question
> 
> I guess there's something implied there that I don't get. 
> Scenario, from your note:
> 
> Your task is to delete LES, who is enrolled, from the SFS 
> system LES has granted rights to RICHARD but RICHARD is not enrolled
> 
> How does enrolling LES for 0 blocks do anything about the 
> granted rights that RICHARD has?
> 
> Les
> 
> Schuh, Richard wrote:
> > I simply enroll any user to be deleted for 0 blocks. The 
> alternative is to scan the sfs directories and files looking 
> for such users. It is much easier to attempt the enroll. If 
> it fails, it is because the user is already enrolled.
> > 
> > Regards,
> > Richard Schuh
> > 
> >  
> > 
> >> -Original Message-
> >> From: The IBM z/VM Operating System
> >> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Les Koehler
> >> Sent: Tuesday, March 01, 2011 12:22 PM
> >> To: IBMVM@LISTSERV.UARK.EDU
> >> Subject: Re: CMS SFS Question
> >>
> >> I'm curious: How do you find the user who is not enrolled, but 
> >> granted rights to the target user to be deleted?
> >>
> >> Les
> >>
> >> Schuh, Richard wrote:
> >>> The Pipe is the easiest. 
> >>>
> >>> PIPE < user list | spec /delete user/ 1 w1 nw | cms | > 
> delete log a
> >>>
> >>> Note, however, that if you have an SFS that has a lot of
> >> files and permissions, each DELETE USER can take a long 
> time, so you 
> >> do not want to do this on an id that you might need soon after you 
> >> enter the PIPE command. In our shop, an individual DELETE USER can 
> >> take upwards of 10 minutes.
> >>> Cleaning up SFS when a userid is deleted is important from
> >> a security standpoint. If the same id should be given to a 
> different 
> >> person, it would automatically inherit permissions from the prior 
> >> owner. You should be doing a DELETE USER every time that a 
> userid is 
> >> deleted from the directory.
> >>> It is possible for one user to grant access to other users
> >> who are not enrolled. DELETE USER does not clean up these 
> >> permissions. To get rid of them, you have to first enroll 
> the user in 
> >> the pool even if it is for 0 blocks. To solve this in our 
> automated 
> >> process, each user to be deleted is enrolled for 0 blocks, 
> ignoring 
> >> the return code. We don't care if the user is already 
> enrolled, the 
> >> attempt does no harm. After the enroll, the deletion will 
> clean out 
> >> all permissions granted to or by the user being deleted.
> >>>
> >>> Regards,
> >>> Richard Schuh
> >>>
> >>>  
> >>>
> >>>> -Original Message-
> >>>> From: The IBM z/VM Operating System 
> >>>> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Rick Troth
> >>>> Sent: Tuesday, March 01, 2011 10:54 AM
> >>>> To: IBMVM@LISTSERV.UARK.EDU
> >>>> Subject: Re: CMS SFS Question
> >>>>
> >>>> Nahh ... even easier ... Pipes.
> >>>> I'm thinking two pipes.  One to gather the Q ENROLL 
> output then a 
> >>>> second to actually perform the deletes.  In between shove that Q 
> >>>> ENROLL output into a file, manually edit for confirmation,
> >> then feed
> >>>> the selected content into DELETE USER.
> >>>>
> >>>>

Re: CMS SFS Question

[Schuh, Richard]

I simply enroll any user to be deleted for 0 blocks. The alternative is to scan 
the sfs directories and files looking for such users. It is much easier to 
attempt the enroll. If it fails, it is because the user is already enrolled.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Les Koehler
> Sent: Tuesday, March 01, 2011 12:22 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: CMS SFS Question
> 
> I'm curious: How do you find the user who is not enrolled, 
> but granted rights to the target user to be deleted?
> 
> Les
> 
> Schuh, Richard wrote:
> > The Pipe is the easiest. 
> > 
> > PIPE < user list | spec /delete user/ 1 w1 nw | cms | > delete log a
> > 
> > Note, however, that if you have an SFS that has a lot of 
> files and permissions, each DELETE USER can take a long time, 
> so you do not want to do this on an id that you might need 
> soon after you enter the PIPE command. In our shop, an 
> individual DELETE USER can take upwards of 10 minutes. 
> > 
> > Cleaning up SFS when a userid is deleted is important from 
> a security standpoint. If the same id should be given to a 
> different person, it would automatically inherit permissions 
> from the prior owner. You should be doing a DELETE USER every 
> time that a userid is deleted from the directory. 
> > 
> > It is possible for one user to grant access to other users 
> who are not enrolled. DELETE USER does not clean up these 
> permissions. To get rid of them, you have to first enroll the 
> user in the pool even if it is for 0 blocks. To solve this in 
> our automated process, each user to be deleted is enrolled 
> for 0 blocks, ignoring the return code. We don't care if the 
> user is already enrolled, the attempt does no harm. After the 
> enroll, the deletion will clean out all permissions granted 
> to or by the user being deleted.
> > 
> > 
> > Regards,
> > Richard Schuh
> > 
> >  
> > 
> >> -Original Message-
> >> From: The IBM z/VM Operating System
> >> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Rick Troth
> >> Sent: Tuesday, March 01, 2011 10:54 AM
> >> To: IBMVM@LISTSERV.UARK.EDU
> >> Subject: Re: CMS SFS Question
> >>
> >> Nahh ... even easier ... Pipes.
> >> I'm thinking two pipes.  One to gather the Q ENROLL output then a 
> >> second to actually perform the deletes.  In between shove that Q 
> >> ENROLL output into a file, manually edit for confirmation, 
> then feed 
> >> the selected content into DELETE USER.
> >>
> >> -- R;
> >> Rick Troth
> >> Velocity Software
> >> http://www.velocitysoftware.com/
> >>
> >>
> >>
> >> On Tue, 1 Mar 2011, Rich Smrcina wrote:
> >>
> >>> REXX?
> >>>
> >>> On 03/01/2011 12:35 PM, Wandschneider, Scott wrote:
> >>>> Is there a way to delete multiple users at once or create
> >> a "batch" job to delete multiple users that are enrolled in SFS?
> >>>> Thank you,
> >>>> Scott R Wandschneider
> >>>> Systems Programmer 3|| Infocrossing, a Wipro Company || 11707 
> >>>> Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 ||
> >>>> Ë:847.849.7223  ||  : 
> >> scott.wandschnei...@infocrossing.com **Think
> >>>> Green  - Please print responsibly**
> >>>>
> >>>>
> >>>>
> >>>> Confidentiality Note: This e-mail, including any
> >> attachment to it, may contain material that is confidential, 
> >> proprietary, privileged and/or "Protected Health 
> Information," within 
> >> the meaning of the regulations under the Health Insurance 
> >> Portability&  Accountability Act as amended.
> >>  If it is not clear that you are the intended recipient, you are 
> >> hereby notified that you have received this transmittal in 
> error, and 
> >> any review, dissemination, distribution or copying of this e-mail, 
> >> including any attachment to it, is strictly prohibited. If 
> you have 
> >> received this e-mail in error, please immediately return it to the 
> >> sender and delete it from your system. Thank you.
> >>>
> >>> --
> >>> Rich Smrcina
> >>> Velocity Software, Inc.
> >>> http://www.velocitysoftware.com
> >>>
> >>> Catch the WAVV! http://www.wavv.org
> >>> WAVV 2011 - April 15-19, 2011 Colorado Springs, CO
> >>>
> >>>
> 

Re: CMS SFS Question

[Schuh, Richard]

The Pipe is the easiest. 

PIPE < user list | spec /delete user/ 1 w1 nw | cms | > delete log a

Note, however, that if you have an SFS that has a lot of files and permissions, 
each DELETE USER can take a long time, so you do not want to do this on an id 
that you might need soon after you enter the PIPE command. In our shop, an 
individual DELETE USER can take upwards of 10 minutes. 

Cleaning up SFS when a userid is deleted is important from a security 
standpoint. If the same id should be given to a different person, it would 
automatically inherit permissions from the prior owner. You should be doing a 
DELETE USER every time that a userid is deleted from the directory. 

It is possible for one user to grant access to other users who are not 
enrolled. DELETE USER does not clean up these permissions. To get rid of them, 
you have to first enroll the user in the pool even if it is for 0 blocks. To 
solve this in our automated process, each user to be deleted is enrolled for 0 
blocks, ignoring the return code. We don't care if the user is already 
enrolled, the attempt does no harm. After the enroll, the deletion will clean 
out all permissions granted to or by the user being deleted.


Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Rick Troth
> Sent: Tuesday, March 01, 2011 10:54 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: CMS SFS Question
> 
> Nahh ... even easier ... Pipes.
> I'm thinking two pipes.  One to gather the Q ENROLL output 
> then a second to actually perform the deletes.  In between 
> shove that Q ENROLL output into a file, manually edit for 
> confirmation, then feed the selected content into DELETE USER.
> 
> -- R;
> Rick Troth
> Velocity Software
> http://www.velocitysoftware.com/
> 
> 
> 
> On Tue, 1 Mar 2011, Rich Smrcina wrote:
> 
> > REXX?
> > 
> > On 03/01/2011 12:35 PM, Wandschneider, Scott wrote:
> > > Is there a way to delete multiple users at once or create 
> a "batch" job to delete multiple users that are enrolled in SFS?
> > >
> > > Thank you,
> > > Scott R Wandschneider
> > > Systems Programmer 3|| Infocrossing, a Wipro Company || 11707 
> > > Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || 
> > > Ë:847.849.7223  ||  : 
> scott.wandschnei...@infocrossing.com **Think 
> > > Green  - Please print responsibly**
> > >
> > >
> > >
> > > Confidentiality Note: This e-mail, including any 
> attachment to it, may contain material that is confidential, 
> proprietary, privileged and/or "Protected Health 
> Information," within the meaning of the regulations under the 
> Health Insurance Portability&  Accountability Act as amended. 
>  If it is not clear that you are the intended recipient, you 
> are hereby notified that you have received this transmittal 
> in error, and any review, dissemination, distribution or 
> copying of this e-mail, including any attachment to it, is 
> strictly prohibited. If you have received this e-mail in 
> error, please immediately return it to the sender and delete 
> it from your system. Thank you.
> > 
> > 
> > --
> > Rich Smrcina
> > Velocity Software, Inc.
> > http://www.velocitysoftware.com
> > 
> > Catch the WAVV! http://www.wavv.org
> > WAVV 2011 - April 15-19, 2011 Colorado Springs, CO
> > 
> > 
> 

Re: XEDIT to display Euro

[Schuh, Richard]

CRS? I don't remember what that stands for.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Les Koehler
> Sent: Wednesday, February 23, 2011 6:32 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: XEDIT to display Euro
> 
> Thanks for the explanation! Guess I'm suffering from CRS.
> 
> Les
> 

Re: DEVICES stmt in SYSTEM CONFIG

[Schuh, Richard]

You specify the filename of the desired CONFIG file in a provided space.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Perez, Steve S
Sent: Thursday, February 17, 2011 12:14 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DEVICES stmt in SYSTEM CONFIG

What is the command to override that OFFLINE_AT_IPL statement in the SALIPL 
screen ?  Or can we ?



Thanks,

Steve




From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Frank M. Ramaekers
Sent: Thursday, February 17, 2011 2:10 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DEVICES stmt in SYSTEM CONFIG

You can actually mix them:

Devices ,
  Online_at_IPL   -,
  Offline_at_IPL  000C-000E,
  Offline_at_IPL  0170-0179,
  Offline_at_IPL  0500-053F,
  :
  :



Frank M. Ramaekers Jr.






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Perez, Steve S
Sent: Thursday, February 17, 2011 2:05 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DEVICES stmt in SYSTEM CONFIG

Unfortunately we are not at the point where we can issue the VARY online 
command.  The system (Test DR z/VM environment) cannot continue because the 
OFFLINE_AT_IPL statement contains the address of the PAGE volumes.  So we are 
thinking that having the PAGE volume addresses included in the OFFLINE_AT_IPL 
list is keeping the PAGE volumes from coming online and therefore preventing 
the system from initializing.

My other option would be to shutdown the DR z/VM environment and update the 
SYSTEM CONFIG without those ranges and create a new CPLOAD module to see if 
that is what is actually causing the z/VM system from fully initializing.


Thanks,
Steve



From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Scott Rohling
Sent: Thursday, February 17, 2011 1:48 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DEVICES stmt in SYSTEM CONFIG
CP VARY ON address  ??

Scott Rohling
On Thu, Feb 17, 2011 at 12:45 PM, Steve Perez 
mailto:sspe...@corelogic.com>> wrote:
Hello Listers,

If I have DEVICE addresses in the SYSTEM CONFIG file to be OFFLINE_AT_IPL,
is there to dynamically have those devices varied online or override at
IPL of a zVM 5.4 ?



Thanks,
Steve.

**
This message may contain confidential or proprietary information intended only 
for the use of the
addressee(s) named above or may contain information that is legally privileged. 
If you are
not the intended addressee, or the person responsible for delivering it to the 
intended addressee,
you are hereby notified that reading, disseminating, distributing or copying 
this message is strictly
prohibited. If you have received this message by mistake, please immediately 
notify us by
replying to the message and delete the original message and any copies 
immediately thereafter.

Thank you.
**
CLLD
_ This message contains 
information which is privileged and confidential and is solely for the use of 
the intended recipient. If you are not the intended recipient, be aware that 
any review, disclosure, copying, distribution, or use of the contents of this 
message is strictly prohibited. If you have received this in error, please 
destroy it immediately and notify us at privacy...@ailife.com.

Re: DEVICES stmt in SYSTEM CONFIG

[Schuh, Richard]

You could also have a second config file that includes the devices in the 
online_at_ipl list. When you ipl, put a console address in the LOADPARMS area 
(or as the LOADPARM parameter if you are ipling 2nd level) and specify the 
alternate config file name in the SALIPL screen. If the devices are currently 
offline because of duplicate volsers, you could make the older devices offline 
in the alternate file.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Quay, Jonathan (IHG)
> Sent: Thursday, February 17, 2011 11:49 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: DEVICES stmt in SYSTEM CONFIG
> 
> If you don't want to change your SYSTEM CONFIG file to 
> specify those devices as ONLINE_AT_IPL, you could vary the 
> devices online in your
> AUTOLOG1 profile exec.
> 
> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Steve Perez
> Sent: Thursday, February 17, 2011 2:45 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: DEVICES stmt in SYSTEM CONFIG
> 
> Hello Listers,
> 
> If I have DEVICE addresses in the SYSTEM CONFIG file to be 
> OFFLINE_AT_IPL= , is there to dynamically have those devices 
> varied online or override at =
> 
> IPL of a zVM 5.4 ? 
> 
> 
> 
> Thanks,
> Steve.
> 

Re: Watson

[Schuh, Richard]

That would require predicting which voice to use.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Tom Huegel
Sent: Tuesday, February 15, 2011 2:33 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Watson

My wife thinks Watson should have a womens voice for the correct answers and a 
mans voice for incorrect answers..



On Tue, Feb 15, 2011 at 2:27 PM, Alan Altmark 
mailto:alan_altm...@us.ibm.com>> wrote:
On Tuesday, 02/15/2011 at 05:04 EST, Tom Huegel 
mailto:tehue...@gmail.com>>
wrote:
> I was just watching Jeopardy with Watson, IBM's 'thinking' computer.
> Quite amazing even though his occasional misses are comical. There may
be a PTF
> available to fix that.
> I wonder what the business justification was for building it.

ibm.com/watson

I find most fascinating the development of the Watson's understanding of
the concepts of "important" and "context" through computer learning.  The
point being to develop new information systems that can sift through data
and find patterns that can brought to bear on real-world problems.

The PTF you mention is available, but I don't think it was used in the
game.  Watson does not hear the other contestants' answers.  In the
trials, his performance rose in a category when he was given the others'
answers, wrong or right.  (You'll recall that he repeated the incorrect
answer "1920s".)

At least Watson hasn't learned to blush when he's wrong (though his sun
rays turn orange).  Yet.

Alan Altmark

z/VM and Linux on System z Consultant
IBM System Lab Services and Training
ibm.com/systems/services/labservices
office: 607.429.3323
alan_altm...@us.ibm.com
IBM Endicott

Re: Watson

[Schuh, Richard]

In the form of a file that is sent at the time the buzzers are unlocked.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Dave Jones
> Sent: Tuesday, February 15, 2011 2:26 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Watson
> 
> Does Watson use voice recognition? I was under the impression 
> that the questions are made available to him (it?, them?) in 
> a computer readable format.
> 
> On 02/15/2011 04:14 PM, McBride, Catherine wrote:
> > I would imagine just the advancement in voice recognition 
> would have 
> > some business value. Plus the legal mandates to digitize medical 
> > records maybe. Whatever it is, Watson is awesome
> > 
> > *From*: The IBM z/VM Operating System 
> > *To*: IBMVM@LISTSERV.UARK.EDU 
> > *Sent*: Tue Feb 15 16:04:10 2011
> > *Subject*: Watson
> > 
> > I was just watching Jeopardy with Watson, IBM's 'thinking' computer.
> > Quite amazing even though his occasional misses are 
> comical. There may 
> > be a PTF available to fix that.
> > I wonder what the business justification was for building it.  
> 
> --
> Dave Jones
> V/Soft Software
> www.vsoft-software.com
> Houston, TX
> 281.578.7544
> 

Re: z/VM 6.2 release date?

[Schuh, Richard]

Aha, Chuckie lives. We haven't heard from him for quite awhile.

Regards, 
Richard Schuh 

 

> 
> Folks who attend John Franciscovich's presentation on SSI/LGR 
> at SHARE can try to make him reveal what he knows.  Just 
> surround him and poke him with sharp sticks.  See if he'll 
> squeal.  ;-)
> 
> Alan Altmark
> 
> z/VM and Linux on System z Consultant
> IBM System Lab Services and Training
> ibm.com/systems/services/labservices
> office: 607.429.3323
> alan_altm...@us.ibm.com
> IBM Endicott
> 

Re: Closing console (and other o/p UR devices) at midnight or other times.

[Schuh, Richard]

Those of us who already have ways to do it would need to convert :-(

Actually, having a built-in way to do it would relieve us of the kludges that 
we have had to construct and would be one less item that new employees would 
have to learn or relearn. It is something that has been missing since the 
advent of service machines and, to go farther back, the OPERATOR userid.

Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Mike Walter
Sent: Friday, February 11, 2011 11:45 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Closing console (and other o/p UR devices) at midnight or other times.


Almost every z/VM customer is forced to devise a method to close service 
virtual machine consoles at midnight, or at some time of day.  z/VM old-timers 
have done this for ages, but new z/VM customers don't often have the skills 
necessary to implement automated closures - or even recognize the advantages of 
doing so.

Before submitting this to IBM as an enhancement request (probably through the 
auspices of SHARE), it seemed prudent to run it past others for wider 
consideration.

I see three possibilities:
1) Enhance the directory entry statement "SPOOL" to add "EOF AT hh:mm:ss", or 
"CLOSE AT hh:mm:ss"
2) Enhance the CP command "SPOOL" to enhance "EOF" adding "AT hh:mm:ss", or 
enhance "CLOSE" adding "AT hh:mm:ss"
3) For the sake of consistency, both enhancements 1 and 2.

If only #2 were implemented, the new SPOOL command could be entered in the 
directory entry of such servers via the 'COMMAND' statement, providing the same 
facility with lower CP coding and documentation requirements.  New products 
could be distributed with sample directory entries containing the "AT hh:mm:ss" 
included, perhaps as a comment.

Thoughts?

Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.



The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. E-mails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by e-mail.

Re: Who is accessing DASD

[Schuh, Richard]

Q SYSTEM 6F8


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Frank M. Ramaekers
Sent: Thursday, February 10, 2011 12:03 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Who is accessing DASD

Isn't there a command that will tell me who (what) are the following 104?

Q 6F8
DASD 06F8 CP OWNED  540RES   104


 Frank M. Ramaekers Jr.





[cid:image001.gif@01CBC914.8F52FAA0]


Systems Programmer


MCP, MCP+I, MCSE & RHCE




American Income Life Insurance Co.


Phone: (254)761-6649




1200 Wooded Acres Dr.


Fax: (254)741-5777




Waco, Texas  76701







_ This message contains 
information which is privileged and confidential and is solely for the use of 
the intended recipient. If you are not the intended recipient, be aware that 
any review, disclosure, copying, distribution, or use of the contents of this 
message is strictly prohibited. If you have received this in error, please 
destroy it immediately and notify us at privacy...@ailife.com.

Recall: A little pipe question.

[Schuh, Richard]

Schuh, Richard would like to recall the message, "A little pipe question.".

Re: A little pipe question.

[Schuh, Richard]

Tom,

Here is a pipe that I have extracted from an EXEC that we have been using for 
several years that does the type of thing you appear to be attempting. Let me 
know if you have any questions.

Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Tom Huegel
Sent: Tuesday, February 08, 2011 6:39 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: A little pipe question.

Thanks David, I thought that was the flow, but I didn't get it to work..  Maybe 
I was just tired. Between shoveling snow and watching the Super Bowl I'm ready 
for a vacation.

On Tue, Feb 8, 2011 at 5:53 AM, Dave Jones 
mailto:d...@vsoft-software.com>> wrote:
Tom, if the "xcmd" stage has a secondary output stream defined,
Pipelines will write the return code from the cp/cms command there.

Does that help?

DJ

On 02/07/2011 02:09 PM, Tom Huegel wrote:
> I am trying to replace a WAKEUP (IUCVMSG routine with a PIPE STARMSG.
> I have the following snippet that seems to work fine except for capturing
> the return code from the cp/cms command (XCMD).
>
> Is there a simple fix to this? - Thanks
>
> /*
> */
>
> trace
> o
> cp set msg
> iucv
> arg
> xcmd
> 'pipe (endchar
> ?)',
>   '| starmsg
> ',
>
> xcmd,
>   '| specs 9-16 1 17-* strip nw x15
> nw',
>   '| stem linecount.',   /* save results
> */
>   '?',   /* start of second pipeline
> */
>   'literal +01', /* Delay time
> */
>   '| delay', /* Delay
> */
>   '| pipestop'   /* Stop
> */
> say
> rc
>
> cp set msg
> on
> 'pipe stem linecount. |
> console'
> exit
>

--
Dave Jones
V/Soft Software
www.vsoft-software.com
Houston, TX
281.578.7544

/**/
'PIPE (end \)',
'\ f: faninany',
   '| take 1',
   '| pipestop',
'\ starmsg *msg cp smsg' rscsid pfx sys cmd,
   '| b: beat 5 /Timeout/',
   '| eof: nlocate anyc  /garbage/',
   '| f2: faninany',
   '| not chop 16',
   '| stem' stem '1',
   '| take 1',
   '| spec /smsg rscs' pfx sys 'garbage/ 1',
   '| cp',
'\ b:',
   '| take 1',
   '| f:',
'\ eof:',
   '| take 1',
   '| f:',
'\ immcmd q',
   '| take 1',
   '| f:'


Re: z10 capacity number?

[Schuh, Richard]

3 quarts?

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Martha McConaghy
> Sent: Monday, January 31, 2011 10:46 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: z10 capacity number?
> 
> We just moved our remaining LPAR over to a new z10.  Now, 
> some of our z/OS people are updating their licenses on their 
> products to reflect the new serial number, etc.  However, 
> they are being asked for the new mainframe's "capacity 
> number".  I've never heard of that before.  They are being 
> told to run:
> 
> d m=cpu
> 
> from z/OS to get the number.  However, since all of our z/OS 
> systems are guests, I have no idea if the info being returned 
> is accurate.  Is there an equivelent in z/VM?  I found the 
> "query capability" command but am not sure if it is the same thing.
> 
> Martha
> 

Re: Forced logoff by SYSTEM?

[Schuh, Richard]

Are you sure about that? Any posted read that is not responded to will get a 
disconnected machine forced regardless of whether it is VM or CP read. The 
forced disconnect is in response to terminal errors during I/O and is relevant 
to this discussion only if a read is posted while disconnected. It is all as 
documented, I do believe., and is not a bug. The reason for it is fairly 
obvious. If there is no secuser for the machine, someone has to log on to 
respond to the read. If nobody logs on, then the read triggers the logoff force 
timer.  This is nothing new to XA.

If, whenever you logon, a CP Read is posted, it is because you do not have SET 
RUN ON. That CP Read bears no relationship to the logoff timer. That goes back 
to the earliest releases of VM and probably beyond to CP40 and CP67. I only got 
into VM at the VM370 Release 1 level as a user, Release 2 as a sysprog., so I 
cannot speak to the earlier systems.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf 
Of Kris Buelens
Sent: Tuesday, January 25, 2011 12:34 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Forced logoff by SYSTEM?

Logically the Virtual Machine would be in VM READ.
But in the VM/XA branch of VM -on which z/VM is based- any VM READ of a 
disconnected user without secondary user gets translated in a CP READ.  I find 
this a bug, VM/SP and VM/HPO did it right.  Without setting a secondary user on 
it, one cannot even use CP SEND to respond to the VM READ, because it is no 
longer there.  Even CP SEND CP xxx BEGIN can't help: the VM READ will be 
reposted, but it gets again translated into a CP READ.
Then, why not using SET SECUSER followed by SEND BEGIN?  There are cases where 
one doesn't want a secondary user: namely for servers intercepting messages 
(WAKEUP, PROP, PIPE *STARMSG, ...)

2011/1/25 Shimon Lebowitz mailto:shim...@iname.com>>
The OP (that's me) has mentioned opening a PMR
over the fact that PERFSVM did in fact abend.
I thought that after creating a VMDUMP, the virtual
machine would be in a CP READ, but I guess I misunderstood.

Shimon

On Tue, Jan 25, 2011 at 4:37 AM, Stephen Powell 
mailto:zlinux...@wowway.com>> wrote:


What probably happened to the OP is this: (1) The virtual machine was
autologged, (2) It ran a program, (3) the program abended, causing CMS
to issue the "CMS" prompt, instead of the usual "Ready;" prompt,
Then it issued a VM READ.  At this point, CMS is waiting for the user
to issue the DEBUG command to obtain virtual machine status at the time
of the ABEND.  Any other command will cause ABEND cleanup processing
to occur.  But that is a moot point, really.  The point is that the
virtual machine is in a VM READ state at this point in time.  And after
being in a VM READ state for 15 minutes, CP forces it off.





--
Kris Buelens,
IBM Belgium, VM customer support

Re: IO configuration question?

[Schuh, Richard]

If they are NOTACCEPTED, as Gregg Reed suggests, they are covered both when 
they are added dynamically and when VM is subsequently  ipled. You can use 
commands to add them to your configuration as needed. Just remember to take 
them out of the NOTACCEPTED list so that they will be part of your system after 
an ipl.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Shimon Lebowitz
Sent: Tuesday, January 11, 2011 8:21 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: IO configuration question?

I think you also might want to check your New_Devices setting in the SYSTEM 
CONFIG.
If it is enabled, new devices will be brought online when the system sees them 
appear.


On Tue, Jan 11, 2011 at 5:32 PM, Macioce, Larry 
mailto:larry.maci...@com.state.oh.us>> wrote:
I would ask the z/OS guy what his IOCDS shows in the way of dasd i/o devices 
and put those in the offline at ipl list.
Then as you need them bring them online
Mace

From: The IBM z/VM Operating System 
[mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of 
Tom Huegel
Sent: Tuesday, January 11, 2011 10:16 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: IO configuration question?

Greetings,

I have a guestion regaurding z/VM I/O configuration. After I IPL my z/VM I have 
about a dozen devices (DASD) defined (Q DASD FREE), which is what I expect. But 
at some time during the life of the IPL the z/OS admin loads a new IOCDS (I 
think that is what is going on) I suddenly have several hundred devices online.
The question: Is there a way I can prevent this from happening? I still want 
the ability to vary some of those devices online as needed.

Thanks
Tom



 The 
information transmitted is intended solely for the individual or entity to 
which it is addressed and may contain confidential and/or privileged material. 
Any review, retransmission, dissemination or other use of or taking action in 
reliance upon this information by persons or entities other than the intended 
recipient is prohibited. If you have received this email in error please 
contact the sender and delete the material from any computer. 

Re: How can get the Week day ?

[Schuh, Richard]

It is right with the DATE(B) function - 01/01/1001.

All the technicalities aside, forget about the word "Century" and view the 
letter "C" as an abstraction for the described function. Then, everything is 
consistent, even if technically incorrect.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of George Henke/NYLIC
Sent: Tuesday, January 04, 2011 1:14 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How can get the Week day ?

tyvm, Chip, for the explanation.  So this century really began in Jan 1, 2001, 
not 2000.  Interesting.

Certainly glad it was the "C" programmers, not the BAL programmers, that went 
wrong.

A good BAL programmer knows that everything is relative "0", not "1".



Chip Davis 
Sent by: The IBM z/VM Operating System 

01/03/2011 09:25 PM
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: How can get the Week day ?





Technically, the first year of each century is cc01, not cc00.

Due to an appalling lack of consistency, the C programmers in the
first decade ("0") of the first century ("0") declared the first year
to be "1".  :-)

-Chip-

On 1/3/11 16:03 George Henke/NYLIC said:
> Not quite sure what is the difference between the number of days since
> the beginning of the century and the number of days since the most
> recent year ending in '00' unless going back or ahead more than a
> century or 2.
>
> But I suppose there is a difference or it would have been moot.
>
> *Chip Davis *
> Be careful with Date('C').  It doesn't really give you the number of
> days in the current century (as it was originally documented).  It
> returns the number of days since the beginning of the most recent year
> ending in '00', e.g. '2000'.
>
> On 1/3/11 14:25 George Henke/NYLIC said:
>  > REXX also has a nifty function called Century Day that simplifies things
>  > by working in century days, days since the beginning of the century,
>  > rather than days since the beginning of the year.

Re: VTAM logmodes

[Schuh, Richard]

Good is a relative term when discussing VTAM :-)

Regards, 
Richard Schuh 

 

> It wouldn't 
> be the first time that VM accidentally got Good Stuff that 
> MVS didn't. 
> 

Re: Configuration Puzzler

[Schuh, Richard]

That was the problem. When the conversion to use SFS was done, it was only half 
done. One machine, the one that owned the minidisk, was converted, the other 
was not.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Scott Rohling
Sent: Thursday, December 30, 2010 4:21 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Configuration Puzzler

???  I thought there was linking, etc involved...  as in minidisks.   Well - 
glad you figured it out...  it was a puzzler as stated :-)

Scott Rohling

On Thu, Dec 30, 2010 at 1:01 PM, Schuh, Richard 
mailto:rsc...@visa.com>> wrote:
Mystery solved. There was an incomplete conversion to SFS. Converting the B 
machine to actually look like A solved the problem.

Regards,
Richard Schuh






From: The IBM z/VM Operating System 
[mailto:IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of 
Kris Buelens
Sent: Thursday, December 30, 2010 3:29 AM

To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>
Subject: Re: Configuration Puzzler

RELEASE in not implicit with LOGOFF: when you enter LOGOFF, CMS passes this to 
CP, without lokking.  So, CMS doesn't perform a RELEASE.
But, somehow you give a good idea, even though I don't think it applies here.  
When you update a file, CMS doesn't commit the changes until all files on the 
updated minidisk are closed.  CMS will close all files when returning to CMS 
Ready, something an ever running server will not do. (that's why good written 
execs always close the files they opened.  Mostly no problem if using PIPE, 
requires action if using EXECIO).
But, as mentioned, it should not apply here: Richard saw the new version of the 
file after a new LINK.  But, Richard, if you XAUTOLOGged B after the update, 
the logon process implies a LINK...  So that LINK or the explicit LINK should 
have behaved the same.

Compare Q MDISK 191 LOCATION perhaps?

2010/12/30 mailto:gclo...@br.ibm.com>>
Richard,
One possibility:
I remember that a FST is maintained in memory, until command "RELEASE" 
completes. RELEASE is implicit into LOGOFF. Because this, MultiWrite must be 
avoided  in CMS.
If A Xautolog B, is possible that the altered FST was not saved yet.
When A change something, try "CMS RELEASE A", before "CP XAUTOLOG B"...
Only a idea...
_
Clovis


From:   "Schuh, Richard" mailto:rsc...@visa.com>>
To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>
Date:   29/12/2010 22:52
Subject:Re: Configuration Puzzler
Sent by:The IBM z/VM Operating System 
mailto:IBMVM@LISTSERV.UARK.EDU>>





Mike,
1.If it had not been fully logged off, then the XAUTOLOG commands 
probably would have failed, would they not? It was logged off many times, both 
were logged off many times.When A was logged off, it would XAUTOLOG B, 
otherwise I would do the honors. Q USER B, preceded by Q USER A when 
appropriate, prior to entering the XAUTOLOG command showed that the user was 
not logged on.
2.Q LINKS 191 was used to verify that the disk was the correct one. A 
had it as its 191 R/W disk, B had it as its 191 R/O disk.The the manual link 
command used was LINK * 191 191 RR. If that got a different disk, then there 
was an error in the processing of the LINK command - the directory entry is 
LINK A 191 191 RR. When the profile was updated, both A and B were logged off 
and the update was done from another id, mine.
We still do not have an answer. It has all of the appearances of being a cache 
problem of some kind. MDC should have kept things straight since these were two 
guests of the same CP. DASD cache should also have given both users the same 
answer. It appears as though A was being given data from a cache, and the cache 
was being bypassed by B. That would be understandable if the guests were in 
different LPARS or on different CECs and MDC were in use; however, they were in 
the same LPAR, hosted by the same CP, using the same I/O hardware and program 
interfaces. If not a cache problem, then the ACCESS command could have been 
giving 9ncorrect results, i.e. using the active ADT for A and the inactive for 
B.

I am planning to take both users logoff/xautolog cycles to see if this is a 
recurring problem.

Regards,
Richard Schuh




From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Michael Harding
Sent: Wednesday, December 29, 2010 3:36 PM
To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>
Subject: Re: Configuration Puzzler

The fact that you had to logon to B, and detach/relink the disk tells me that 
either (1) B never really logged off, or more likely (2) B wasn't linking the 
disk you thought it was, but when you did 

Re: Configuration Puzzler

[Schuh, Richard]

Mystery solved. There was an incomplete conversion to SFS. Converting the B 
machine to actually look like A solved the problem.

Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Kris Buelens
Sent: Thursday, December 30, 2010 3:29 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Configuration Puzzler

RELEASE in not implicit with LOGOFF: when you enter LOGOFF, CMS passes this to 
CP, without lokking.  So, CMS doesn't perform a RELEASE.
But, somehow you give a good idea, even though I don't think it applies here.  
When you update a file, CMS doesn't commit the changes until all files on the 
updated minidisk are closed.  CMS will close all files when returning to CMS 
Ready, something an ever running server will not do. (that's why good written 
execs always close the files they opened.  Mostly no problem if using PIPE, 
requires action if using EXECIO).
But, as mentioned, it should not apply here: Richard saw the new version of the 
file after a new LINK.  But, Richard, if you XAUTOLOGged B after the update, 
the logon process implies a LINK...  So that LINK or the explicit LINK should 
have behaved the same.

Compare Q MDISK 191 LOCATION perhaps?

2010/12/30 mailto:gclo...@br.ibm.com>>
Richard,
One possibility:
I remember that a FST is maintained in memory, until command "RELEASE" 
completes. RELEASE is implicit into LOGOFF. Because this, MultiWrite must be 
avoided  in CMS.
If A Xautolog B, is possible that the altered FST was not saved yet.
When A change something, try "CMS RELEASE A", before "CP XAUTOLOG B"...
Only a idea...
_________
Clovis


From:   "Schuh, Richard" mailto:rsc...@visa.com>>
To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>
Date:   29/12/2010 22:52
Subject:Re: Configuration Puzzler
Sent by:The IBM z/VM Operating System 
mailto:IBMVM@LISTSERV.UARK.EDU>>





Mike,
1.If it had not been fully logged off, then the XAUTOLOG commands 
probably would have failed, would they not? It was logged off many times, both 
were logged off many times.When A was logged off, it would XAUTOLOG B, 
otherwise I would do the honors. Q USER B, preceded by Q USER A when 
appropriate, prior to entering the XAUTOLOG command showed that the user was 
not logged on.
2.Q LINKS 191 was used to verify that the disk was the correct one. A 
had it as its 191 R/W disk, B had it as its 191 R/O disk.The the manual link 
command used was LINK * 191 191 RR. If that got a different disk, then there 
was an error in the processing of the LINK command - the directory entry is 
LINK A 191 191 RR. When the profile was updated, both A and B were logged off 
and the update was done from another id, mine.
We still do not have an answer. It has all of the appearances of being a cache 
problem of some kind. MDC should have kept things straight since these were two 
guests of the same CP. DASD cache should also have given both users the same 
answer. It appears as though A was being given data from a cache, and the cache 
was being bypassed by B. That would be understandable if the guests were in 
different LPARS or on different CECs and MDC were in use; however, they were in 
the same LPAR, hosted by the same CP, using the same I/O hardware and program 
interfaces. If not a cache problem, then the ACCESS command could have been 
giving 9ncorrect results, i.e. using the active ADT for A and the inactive for 
B.

I am planning to take both users logoff/xautolog cycles to see if this is a 
recurring problem.

Regards,
Richard Schuh




From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Michael Harding
Sent: Wednesday, December 29, 2010 3:36 PM
To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>
Subject: Re: Configuration Puzzler

The fact that you had to logon to B, and detach/relink the disk tells me that 
either (1) B never really logged off, or more likely (2) B wasn't linking the 
disk you thought it was, but when you did it manually you got the disk you 
thought it should have (the one A updated).
--
Mike Harding
z/VM System Support

mhard...@us.ibm.com<mailto:mhard...@us.ibm.com>
mike.b.hard...@kp.org<mailto:mike.b.hard...@kp.org>
mikehard...@mindless.com<mailto:mikehard...@mindless.com>
(925) 926-3179 (w)
(925) 323-2070 (c)
IM: VMBearDad (AIM), mbhcpcvt (Y!)


The IBM z/VM Operating System 
mailto:IBMVM@LISTSERV.UARK.EDU>> wrote on 12/29/2010 
03:17:53 PM:

> From: "Schuh, Richard" mailto:rsc...@visa.com>>
> To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>
> Date: 12/29/2010 03:18 PM
> Subject: Re: Configuration Puzzler
> Sent by: The IBM z/VM Operating System 
> mailto:IBMVM@LISTSERV

Re: Accounting Records

[Schuh, Richard]

For the formats, try the ACOBK in CP Data Areas and Control Blocks. We do not 
use them for accounting purposes, but they are saved for ad hoc reports. We do 
a daily ACNT ALL just before midnight. The files are saved as ACCOUNT mmdd.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Scott Rohling
Sent: Thursday, December 30, 2010 10:18 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Accounting Records

I believe the record layout is in CP Planning and Administration?   Here's some 
code you point at an accounting file and produces a report showing CPU 
minutes/hours for each user (looks like although I collect the account code - 
I'm not displaying it):

/**/
Trace o
Address COMMAND
Arg file
Parse VAR file file '(' outfile
Parse Source envnm callnm snm styp smod synnm cmdnm
user. = ''
users. = ''
usernum = 0
grand = 0
'PIPE COMMAND LISTFILE' file '| STEM FILES.'
Do i = 1 to files.0
  'PIPE FILE' files.i '| LOCATE 79.2 /01/ | SPECS 1.40 1 | STEM REC.'
  Say files.i
  Do j = 1 to rec.0
Parse VAR rec.j 1 usr 9 act 17 . 33 tsecs 37 .
usr = strip(usr)
tsecs = 'C2D'(tsecs)
If user.usr = '' Then Do
  user.usr = 0
  usernum = usernum + 1
  users.usernum = usr
  user.usr.code = act
End
user.usr = user.usr + tsecs
grand = grand + tsecs
  End
End
Say usernum 'users found'
If outfile = '' Then outfile = 'CPUCNT OUTPUT A'
'ERASE' outfile
total = 0
Do i = 1 to usernum
   usr = strip(users.i)
  act = user.usr.code
/* Data is milliseconds - so get seconds */
  amount = user.usr/1000
  pct = format(100*(user.usr/grand),5,2)
/* Divide by 60 for minutes */
  hours = amount/60
  total = total + amount
  out = left(usr,8) format(amount,10,2) format(hours,10,2) pct'%'
  Say out
  'PIPE VAR OUT | >>' outfile
End
Say 'Total:' total
'FINIS' outfile
Call @Exit 0

/**/
/* Exit  -  Exit  Routine  (Normal  and  Error)   */
/**/
@Exit:
Parse Arg erc text
If text ¬= ''
  Then Say text
Exit erc




On Thu, Dec 30, 2010 at 11:07 AM, Billy Bingham 
mailto:billy.bingham...@suddenlink.net>> wrote:
Does anyone have a short tutorial or know of a book on collecting and 
processing the accounting records generated by VM? This would include the 
record layouts.


Thanks,

Billy

Re: Configuration Puzzler

[Schuh, Richard]

It is exactly the same disk. One is defined as an MDISK; the other, a link to 
that MDISK. I guess that makes it a total overlap.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Alain Benveniste
> Sent: Thursday, December 30, 2010 1:48 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Configuration Puzzler
> 
> Richard
> 
> Did you check if you didn't have a mdisk overlap for those users ?
> 
> Alain 
> 
> Envoyé de mon iPhone
> 
> Le 30 déc. 2010 à 01:55, "Schuh, Richard"  a écrit :
> 
> > No. A's directory entry for the disk is an MDISK statement 
> the has a mode of MR. Q LINKS 191 from B showed only 2 links, 
> those from A and B. 
> > 
> > Regards,
> > Richard Schuh
> > 
> > 
> > 
> >> -Original Message-
> >> From: The IBM z/VM Operating System
> >> [mailto:ib...@listserv.uark.edu] On Behalf Of Rich Greenberg
> >> Sent: Wednesday, December 29, 2010 4:03 PM
> >> To: IBMVM@LISTSERV.UARK.EDU
> >> Subject: Re: Configuration Puzzler
> >> 
> >> On: Wed, Dec 29, 2010 at 02:11:58PM -0800,Schuh, Richard Wrote:
> >> 
> >> } We have two service machines, I will call them A and B for this 
> >> discussion. These machines share a 191 disk. When A is 
> xautologged, 
> >> it initializes itself and then xautologs B. I logged both machines 
> >> off and added two new ACCESS commands to the PROFILE EXEC. I then 
> >> logged A on and checked its configuration. It reflected 
> the changes 
> >> from the PROFILE. It AUTOLOGGed B. B came up using the old 
> profile. I 
> >> stopped the server code on B and checked the configuration. It was 
> >> indeed the old profile that was used. A q links 191 showed 
> that A had 
> >> it as its 191 in R/W mode, while B had it as 191 R/O. A 
> list profile 
> >> exec * found only one such file, on the A disk, , and on B 
> it was the 
> >> old configuration. I then logged both off and xautologged 
> A. Again, B 
> >> came up with the old configuration. I tried the 
> logoff/logon sequence 
> >> several times, all with the same result. I finally 
> detached the 191 
> >> disk from B and relinked it. This time, the new profile exec was 
> >> there, like it should have been all along.
> >> 
> >> Just a WAG, but might a 3rd userid (perhaps the one who changed the
> >> profile) have had the disk accessed and the FSTs were cached?
> >> 
> >> --
> >> Rich Greenberg  Sarasota, FL, USA richgr atsign panix.com  +
> >> 1 941 378 2097
> >> Eastern time.  N6LRT  I speak for myself & my dogs only.
> >> VM'er since CP-67
> >> Canines: Val, Red, Shasta, Zero & Casey (At the bridge)   
> >> Owner:Chinook-L
> >> Canines: Red & Cinnar (Siberians)  Retired at the beach  Asst 
> >> Owner:Sibernet-L
> >> 
> 

Re: Configuration Puzzler

[Schuh, Richard]

No. A's directory entry for the disk is an MDISK statement the has a mode of 
MR. Q LINKS 191 from B showed only 2 links, those from A and B. 

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Rich Greenberg
> Sent: Wednesday, December 29, 2010 4:03 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Configuration Puzzler
> 
> On: Wed, Dec 29, 2010 at 02:11:58PM -0800,Schuh, Richard Wrote:
> 
> } We have two service machines, I will call them A and B for 
> this discussion. These machines share a 191 disk. When A is 
> xautologged, it initializes itself and then xautologs B. I 
> logged both machines off and added two new ACCESS commands to 
> the PROFILE EXEC. I then logged A on and checked its 
> configuration. It reflected the changes from the PROFILE. It 
> AUTOLOGGed B. B came up using the old profile. I stopped the 
> server code on B and checked the configuration. It was indeed 
> the old profile that was used. A q links 191 showed that A 
> had it as its 191 in R/W mode, while B had it as 191 R/O. A 
> list profile exec * found only one such file, on the A disk, 
> , and on B it was the old configuration. I then logged both 
> off and xautologged A. Again, B came up with the old 
> configuration. I tried the logoff/logon sequence several 
> times, all with the same result. I finally detached the 191 
> disk from B and relinked it. This time, the new profile exec 
> was there, like it should have been all along.
> 
> Just a WAG, but might a 3rd userid (perhaps the one who changed the
> profile) have had the disk accessed and the FSTs were cached?
> 
> --
> Rich Greenberg  Sarasota, FL, USA richgr atsign panix.com  + 
> 1 941 378 2097
> Eastern time.  N6LRT  I speak for myself & my dogs only.
> VM'er since CP-67
> Canines: Val, Red, Shasta, Zero & Casey (At the bridge)   
>  Owner:Chinook-L
> Canines: Red & Cinnar (Siberians)  Retired at the beach  Asst 
> Owner:Sibernet-L
> 

Re: Configuration Puzzler

[Schuh, Richard]

Mike,

 1.
If it had not been fully logged off, then the XAUTOLOG commands probably would 
have failed, would they not? It was logged off many times, both were logged off 
many times.When A was logged off, it would XAUTOLOG B, otherwise I would do the 
honors. Q USER B, preceded by Q USER A when appropriate, prior to entering the 
XAUTOLOG command showed that the user was not logged on.
 2.
Q LINKS 191 was used to verify that the disk was the correct one. A had it as 
its 191 R/W disk, B had it as its 191 R/O disk.The the manual link command used 
was LINK * 191 191 RR. If that got a different disk, then there was an error in 
the processing of the LINK command - the directory entry is LINK A 191 191 RR. 
When the profile was updated, both A and B were logged off and the update was 
done from another id, mine.

We still do not have an answer. It has all of the appearances of being a cache 
problem of some kind. MDC should have kept things straight since these were two 
guests of the same CP. DASD cache should also have given both users the same 
answer. It appears as though A was being given data from a cache, and the cache 
was being bypassed by B. That would be understandable if the guests were in 
different LPARS or on different CECs and MDC were in use; however, they were in 
the same LPAR, hosted by the same CP, using the same I/O hardware and program 
interfaces. If not a cache problem, then the ACCESS command could have been 
giving 9ncorrect results, i.e. using the active ADT for A and the inactive for 
B.

I am planning to take both users logoff/xautolog cycles to see if this is a 
recurring problem.

Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Michael Harding
Sent: Wednesday, December 29, 2010 3:36 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Configuration Puzzler


The fact that you had to logon to B, and detach/relink the disk tells me that 
either (1) B never really logged off, or more likely (2) B wasn't linking the 
disk you thought it was, but when you did it manually you got the disk you 
thought it should have (the one A updated).
--
Mike Harding
z/VM System Support

mhard...@us.ibm.com
mike.b.hard...@kp.org
mikehard...@mindless.com
(925) 926-3179 (w)
(925) 323-2070 (c)
IM: VMBearDad (AIM), mbhcpcvt (Y!)


The IBM z/VM Operating System  wrote on 12/29/2010 
03:17:53 PM:

> From: "Schuh, Richard" 
> To: IBMVM@LISTSERV.UARK.EDU
> Date: 12/29/2010 03:18 PM
> Subject: Re: Configuration Puzzler
> Sent by: The IBM z/VM Operating System 
>
> As stated, one has it R/W the other R/O. Someone has to log on to
> the machine that has it R/W to update it, there is nothing in the
> machine, itself, that writes anything. I am aware of MDC, and it is
> not in play, here. Both are on the same VM system. The update was
> done while both were logged off. The file was only updated once. The
> trials, including several logoff/logon sequences, spanned a couple
> of hours on a system that is lightly loaded.
>
> Regards,
> Richard Schuh
>
>
>
> From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]
> On Behalf Of Kris Buelens
> Sent: Wednesday, December 29, 2010 2:09 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Configuration Puzzler

> Your machines don't share it in MW mode?  If yes, anything is possible
> They are on the same z/VM system? If not, the MDC cache on the
> system that didn't update the disk can be backlevel.

> 2010/12/29 Schuh, Richard 
> We have two service machines, I will call them A and B for this
> discussion. These machines share a 191 disk. When A is xautologged,
> it initializes itself and then xautologs B. I logged both machines
> off and added two new ACCESS commands to the PROFILE EXEC. I then
> logged A on and checked its configuration. It reflected the changes
> from the PROFILE. It AUTOLOGGed B. B came up using the old profile.
> I stopped the server code on B and checked the configuration. It was
> indeed the old profile that was used. A q links 191 showed that A
> had it as its 191 in R/W mode, while B had it as 191 R/O. A list
> profile exec * found only one such file, on the A disk, , and on B
> it was the old configuration. I then logged both off and xautologged
> A. Again, B came up with the old configuration. I tried the logoff/
> logon sequence several times, all with the same result. I finally
> detached the 191 disk from B and relinked it. This time, the new
> profile exec was there, like it should have been all along.
>
> How is this even possible? Are we going to be plagued by this every
> time we xautolog A? Clearly the pointers were all correct when the
> first machine logged on. Given that, I would certainly expect that
> they would be correct when the second machine linked to the same
> disk and accessed it.
>
>
> Regards,
> Richard Schuh
>
>
>
>
>
>
> --
> Kris Buelens,
> IBM Belgium, VM customer support

Re: Configuration Puzzler

[Schuh, Richard]

As stated, one has it R/W the other R/O. Someone has to log on to the machine 
that has it R/W to update it, there is nothing in the machine, itself, that 
writes anything. I am aware of MDC, and it is not in play, here. Both are on 
the same VM system. The update was done while both were logged off. The file 
was only updated once. The trials, including several logoff/logon sequences, 
spanned a couple of hours on a system that is lightly loaded.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Kris Buelens
Sent: Wednesday, December 29, 2010 2:09 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Configuration Puzzler

Your machines don't share it in MW mode?  If yes, anything is possible
They are on the same z/VM system? If not, the MDC cache on the system that 
didn't update the disk can be backlevel.

2010/12/29 Schuh, Richard mailto:rsc...@visa.com>>
We have two service machines, I will call them A and B for this discussion. 
These machines share a 191 disk. When A is xautologged, it initializes itself 
and then xautologs B. I logged both machines off and added two new ACCESS 
commands to the PROFILE EXEC. I then logged A on and checked its configuration. 
It reflected the changes from the PROFILE. It AUTOLOGGed B. B came up using the 
old profile. I stopped the server code on B and checked the configuration. It 
was indeed the old profile that was used. A q links 191 showed that A had it as 
its 191 in R/W mode, while B had it as 191 R/O. A list profile exec * found 
only one such file, on the A disk, , and on B it was the old configuration. I 
then logged both off and xautologged A. Again, B came up with the old 
configuration. I tried the logoff/logon sequence several times, all with the 
same result. I finally detached the 191 disk from B and relinked it. This time, 
the new profile exec was there, like it should have been all along.

How is this even possible? Are we going to be plagued by this every time we 
xautolog A? Clearly the pointers were all correct when the first machine logged 
on. Given that, I would certainly expect that they would be correct when the 
second machine linked to the same disk and accessed it.


Regards,
Richard Schuh






--
Kris Buelens,
IBM Belgium, VM customer support

Re: Configuration Puzzler

[Schuh, Richard]

LOGOFF/LOGON certainly does that.


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Scott Rohling
Sent: Wednesday, December 29, 2010 2:07 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Configuration Puzzler

You have to reaccess RO disks to see changes.  Doesn't sound like you did.

Scott Rohling

Sent from my iPhone

On Dec 29, 2010, at 1:42 PM, "Schuh, Richard" 
mailto:rsc...@visa.com>> wrote:

We have two service machines, I will call them A and B for this discussion. 
These machines share a 191 disk. When A is xautologged, it initializes itself 
and then xautologs B. I logged both machines off and added two new ACCESS 
commands to the PROFILE EXEC. I then logged A on and checked its configuration. 
It reflected the changes from the PROFILE. It AUTOLOGGed B. B came up using the 
old profile. I stopped the server code on B and checked the configuration. It 
was indeed the old profile that was used. A q links 191 showed that A had it as 
its 191 in R/W mode, while B had it as 191 R/O. A list profile exec * found 
only one such file, on the A disk, , and on B it was the old configuration. I 
then logged both off and xautologged A. Again, B came up with the old 
configuration. I tried the logoff/logon sequence several times, all with the 
same result. I finally detached the 191 disk from B and relinked it. This time, 
the new profile exec was there, like it should have been all along.

How is this even possible? Are we going to be plagued by this every time we 
xautolog A? Clearly the pointers were all correct when the first machine logged 
on. Given that, I would certainly expect that they would be correct when the 
second machine linked to the same disk and accessed it.


Regards,
Richard Schuh

Configuration Puzzler

[Schuh, Richard]

We have two service machines, I will call them A and B for this discussion. 
These machines share a 191 disk. When A is xautologged, it initializes itself 
and then xautologs B. I logged both machines off and added two new ACCESS 
commands to the PROFILE EXEC. I then logged A on and checked its configuration. 
It reflected the changes from the PROFILE. It AUTOLOGGed B. B came up using the 
old profile. I stopped the server code on B and checked the configuration. It 
was indeed the old profile that was used. A q links 191 showed that A had it as 
its 191 in R/W mode, while B had it as 191 R/O. A list profile exec * found 
only one such file, on the A disk, , and on B it was the old configuration. I 
then logged both off and xautologged A. Again, B came up with the old 
configuration. I tried the logoff/logon sequence several times, all with the 
same result. I finally detached the 191 disk from B and relinked it. This time, 
the new profile exec was there, like it should have been all along.

How is this even possible? Are we going to be plagued by this every time we 
xautolog A? Clearly the pointers were all correct when the first machine logged 
on. Given that, I would certainly expect that they would be correct when the 
second machine linked to the same disk and accessed it.



Regards,
Richard Schuh

Re: Duplicate VOLSERs at IPL

[Schuh, Richard]

Which begs the question, what are the criteria for determining the level of a 
message?  

I would think that something that could cause potentially serious system 
problems, like getting an incorrect CP OWNED volume, would warrant an E. On the 
other hand, if the duplicated volser is for a volume having only user 
minidisks, a W might be appropriate as this can be straightened out after the 
ipl. Even that W is open for debate. If it is something that needs to be fixed 
before letting the users on the system, an E might be the correct level for the 
volumes that are merely attached to the system. 

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter
> Sent: Monday, December 27, 2010 8:18 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Duplicate VOLSERs at IPL
> 
> Just closing the loop on this thread... I did open a Sev 3 
> (should have =
> 
> been Sev 4) PMR for this issue on November 20, 2010, pasting 
> pretty much =
> 
> the same text as posted earler to justify the W-level 
> ("Warning") message=
>  
> type on this mesesage.  The PMR response was received today, 
> December 27,=
>  
> 2010.
> 
> The response was:
> "The developer has decided not to change the message type for 
> this messag= e."
> 

Re: ISFC connection between LPARs

[Schuh, Richard]

For me, SFS is enough. In a former life, I did write a complex APPC application 
that involved code and data in VM, MVS and TPF. That was enough to make me 
swear off of APPC unless it is absolutely the right tool for the job. If that 
happens, I will delegate.

I have looked at IPGATE. There are two problems with it:

 1.
We have restrictions on what we can download and install. The search argument 
is "vendor support"-freeware
 2.
The documentation is pretty sparse. I do not have the time to do a lot of 
experimenting.

Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Kris Buelens
Sent: Tuesday, December 21, 2010 12:10 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: ISFC connection between LPARs

What do you really need?  Sharing some SFS servers can be done using IPGATE, no 
CTC then.

2010/12/21 Schuh, Richard mailto:rsc...@visa.com>>
A long time ago, Alan (or was it Chuckie? I sometimes can't tell them apart.) 
thought that ISFC over IP was a neat idea when I suggested it. Maybe a 
requirement is in order.

Regards,
Richard Schuh



> -Original Message-
> From: The IBM z/VM Operating System
> [mailto:IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of 
> Martha McConaghy
> Sent: Tuesday, December 21, 2010 11:32 AM
> To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>
> Subject: ISFC connection between LPARs
>
> Its been a long while since I had to create an ISFC
> connection. We are finally getting a z10 and I need to create
> a link between the two main LPARs.  I don't have ESCON
> adapters in this box and I'd really hate to use up a couple
> of FICON just for a CTC connection between the 2 LPARs.
>
> Is there any other way to do this on a z10?
>
> Martha
>



--
Kris Buelens,
IBM Belgium, VM customer support

Re: ISFC connection between LPARs

[Schuh, Richard]

A long time ago, Alan (or was it Chuckie? I sometimes can't tell them apart.) 
thought that ISFC over IP was a neat idea when I suggested it. Maybe a 
requirement is in order.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Martha McConaghy
> Sent: Tuesday, December 21, 2010 11:32 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: ISFC connection between LPARs
> 
> Its been a long while since I had to create an ISFC 
> connection. We are finally getting a z10 and I need to create 
> a link between the two main LPARs.  I don't have ESCON 
> adapters in this box and I'd really hate to use up a couple 
> of FICON just for a CTC connection between the 2 LPARs.
> 
> Is there any other way to do this on a z10?
> 
> Martha
> 

Re: Mandatory ESMs?

[Schuh, Richard]

Did anyone build a legitimate business case for CP-40 before it was built?

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark
> Sent: Thursday, December 16, 2010 3:37 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Mandatory ESMs?
> 
> Au contraire.  It was necessary for "MVS" development.
> 

Re: Vswitch Grant as a CMD in User's Directory?

[Schuh, Richard]

They spoil the patdowns by requiring that the genders of the patter and pattee 
be the same :-)


Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Tom Huegel
Sent: Thursday, December 09, 2010 9:01 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Vswitch Grant as a CMD in User's Directory?

Does it really matter? SOX is just another way congress has come up with to 
destroy the American economy, and in fact the American way of life. Besides all 
of our passwords are probably available on Wikileaks anyway.
Don't you just love the airport scanners and patdowns?


On Thu, Dec 9, 2010 at 8:40 AM, Schuh, Richard 
mailto:rsc...@visa.com>> wrote:
Not necessarily, there is LOGONBY. They need only know their own passwords.

Should anyone have full authority including all the passwords? If so, who?

Regards,
Richard Schuh



> -Original Message-
> From: The IBM z/VM Operating System
> [mailto:IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>] On Behalf Of 
> Alan Altmark
> Sent: Wednesday, December 08, 2010 8:32 PM
> To: IBMVM@LISTSERV.UARK.EDU<mailto:IBMVM@LISTSERV.UARK.EDU>
> Subject: Re: Vswitch Grant as a CMD in User's Directory?
>
> On Wednesday, 12/08/2010 at 03:11 EST, RPN01
> mailto:nix.rob...@mayo.edu>> wrote:
> > But, should you have to have an external security manager
> for a system
> where
> > the majority of users are disconnected guest operating systems?
>
> Yes.
>
> > Most of
> > today's z/VM systems have a bare minimum of real human users. CP is
> > the security manager for us, and it's sufficient to control the wild
> ramblings
> > of, oh, say, the four people who need access.
>
> Those four people know all the passwords.  There is no
> accountability and no plausible deniability.  You have de
> facto password sharing, something I have yet to see
> countenanced by any IT organization.

Re: Vswitch Grant as a CMD in User's Directory?

[Schuh, Richard]

Not necessarily, there is LOGONBY. They need only know their own passwords.

Should anyone have full authority including all the passwords? If so, who?

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark
> Sent: Wednesday, December 08, 2010 8:32 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: Vswitch Grant as a CMD in User's Directory?
> 
> On Wednesday, 12/08/2010 at 03:11 EST, RPN01 
>  wrote:
> > But, should you have to have an external security manager 
> for a system
> where
> > the majority of users are disconnected guest operating systems?
> 
> Yes.
> 
> > Most of
> > today's z/VM systems have a bare minimum of real human users. CP is 
> > the security manager for us, and it's sufficient to control the wild
> ramblings
> > of, oh, say, the four people who need access.
> 
> Those four people know all the passwords.  There is no 
> accountability and no plausible deniability.  You have de 
> facto password sharing, something I have yet to see 
> countenanced by any IT organization.

Re: FTP within REXX EXEC

[Schuh, Richard]

Try Fran Hensler's site http://zvm.sru.edu/~DOWNLOAD/



Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Perez, Steve S
> Sent: Wednesday, December 08, 2010 2:37 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: FTP within REXX EXEC
> 
> I cannot find VMFTP on the IBM VM download page.
> 
> http://www.vm.ibm.com/download/packages/
> 
>  
> 
> Thanks,
> Steve
> 
> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Hughes, Jim
> Sent: Wednesday, December 08, 2010 4:09 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: FTP within REXX EXEC
> 
> Get a copy of VMFTP from the IBM VM downloads page.  You will 
> not regret it.
> 
> It allows you to write rexx ftp scripts and you can check 
> return codes as well as look at the results of each ftp 
> command in case you need to determine what to do next.
> 
> 
> Jim Hughes
> 603-271-5586
> "It is fun to do the impossible."
> 
> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Steve Perez
> Sent: Wednesday, December 08, 2010 5:05 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: FTP within REXX EXEC
> 
> Hello Listers,
> 
> I have written an REXX exec to file transfer monitor data 
> files from our =
> 
> z/VM Lpar to our z/OS Lpar using FTP.  The following is an 
> excerpt from =
> 
> that code:
> 
> push 'quit' =
>  =
>   
> push put TEST.FILE.A 'my.zos.dsn' 
> ... other ftp commands here ...  =
> 
> 'FTP' ftpaddress
> 
> My question is.  What can I do to retrieve the return code if 
> this fails =
> 
> or is successful?  Or any other ideas or suggestions I can 
> use to determine if the file successfully transferred?
> 
> Thanks in advance for any and all replies.
> 
> Steve.
> **
> 
> This message may contain confidential or proprietary 
> information intended only for the use of the
> addressee(s) named above or may contain information that is 
> legally privileged. If you are not the intended addressee, or 
> the person responsible for delivering it to the intended 
> addressee, you are hereby notified that reading, 
> disseminating, distributing or copying this message is 
> strictly prohibited. If you have received this message by 
> mistake, please immediately notify us by replying to the 
> message and delete the original message and any copies 
> immediately thereafter. 
> 
> Thank you. 
> **
> 
> CLLD
> 

Re: z/VM 6.1, SSLSERV Question

[Schuh, Richard]

Does anyone have a sample SSL/TLS client assembler program that uses the VMCF 
interface? And would you be willing to share it/ If so, it isn't a lost cause.

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark
> Sent: Wednesday, December 01, 2010 2:11 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: z/VM 6.1, SSLSERV Question
> 
> On Wednesday, 12/01/2010 at 11:43 EST, "Schuh, Richard" 
> 
> wrote:
> > Thanks for the reply, Alan. So it is not possible using 
> RXSOCKET. Is 
> > it possible from a CMS client running a home-grown assembler or 
> > Pipelines
> program, 
> > or is it a lost cause?
> 
> A lost cause, I would say.
> 
> Implicit/Static TLS/SSL is available for any TCP/IP *server* 
> without regard to the interface being used.  I.e. an IUCV, C, 
> RxSocket or Pipeline server can be protected by the SECURE 
> parameter on the PORT statement. 
> However, there is no such support for clients.  If a 
> connection to a SECURE port (static) comes from an app on the 
> same stack AND the SecureLocal parm is specified, the stack 
> will treat it as it would an inbound external connection and 
> route the connection through the SSL server on behalf of the 
> *server* side only.
> 
> For clients, only dynamic/negotiated TLS/SSL support is 
> available, and that is only via the VMCF/Pascal API.
> 
> Btw, I don't see very much pressure being placed on z/VM to 
> provide client-side TLS support for homegrown RxSocket or 
> Pipeline apps.  I see slightly more pressure for VM to 
> provide user certificate-based single- and two-factor 
> authentication for TN3270E (and, inevitably, ftp and smtp).
> 
> Alan Altmark
> 
> z/VM and Linux on System z Consultant
> IBM System Lab Services and Training
> ibm.com/systems/services/labservices
> office: 607.429.3323
> alan_altm...@us.ibm.com
> IBM Endicott
> 

Re: DEV vs. DASD

[Schuh, Richard]

The table modifications that HDS needed were indeed included in z/VM 6.1. I do 
not know about other vendors. I do know that when our TPF systems were on EMC a 
few years ago, there were code modifications that we needed in addition to the 
table changes. I don't know if those updates are still needed. And, of course, 
SHARKs (if they are still known by that name) have always been covered. (There. 
I got all 3 of the vendors in.)


Regards, 
Richard Schuh IKA Richard Shuh

(IKA - Incorrectly Known As) :-)

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark
> Sent: Wednesday, December 01, 2010 2:58 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: DEV vs. DASD
> 
> On Wednesday, 12/01/2010 at 05:23 EST, "Wandschneider, Scott" 
>  wrote:
> > The mystery is solved thank you!  The devices that have a 
> device type 
> > of
> DEV 
> > are in fact RDEV?ed as unsupported devices in the SYSTEM 
> CONFIG file.  
> Now the 
> > next question for me is why? 
> 
> Typically because they aren't IBM devices and something on 
> z/OS is using disk functions (CCWs) that the disk vendor 
> hasn't shared with IBM. 
> Defining them as UNSUPPORTED is the only way to get CP to let 
> the alien CCWs through the gate, with the proviso that such 
> dasd cannot be attached to SYSTEM (so no sharing and no MDC). 
>  Making it "unsupported" is a big hint that you accept the risk.
> 
> That said, as Richard Shuh posted recently, z/VM 6.1 adds 
> some, if not all, of these vendor-specific CCWs to the 
> "supported" list.  (From that I infer the vendor(s) finally 
> disclosed to IBM sufficient information about the CCWs so 
> that their risk to the system could be judged.)  People with 
> z/VM 6.1 may want to revisit their dasd definitions.
> 
> Alan Altmark
> 
> z/VM and Linux on System z Consultant
> IBM System Lab Services and Training
> ibm.com/systems/services/labservices
> office: 607.429.3323
> alan_altm...@us.ibm.com
> IBM Endicott
> 

Re: z/VM 6.1, SSLSERV Question

[Schuh, Richard]

Thanks for the reply, Alan. So it is not possible using RXSOCKET. Is it 
possible from a CMS client running a home-grown assembler or Pipelines program, 
or is it a lost cause?

Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark
> Sent: Wednesday, December 01, 2010 6:53 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: z/VM 6.1, SSLSERV Question
> 
> On Tuesday, 11/30/2010 at 06:39 EST, "Schuh, Richard" 
> 
> wrote:
> 
> > We have a person who is trying to get a secure end-to-end 
> transaction
> between a 
> > CMS client and a TPF host.  RXSOCKET is being used by the 
> CMS client. 
> The port 
> > specified is 51105, which has been designated as a secure 
> port. He has
> traced 
> > the SSLSERV and sees no traffic going through it; however, the
> connection to 
> > TPF is made and it is not secure. The ASSORTEDPARMS are coded as:
> >  
> > ASSORTEDPARMS
> >   SECURELOCAL
> >   PROXYARP
> >   IGNOREREDIRECT
> >   FREELOWPORTS
> > ENDASSORTEDPARMS
> >  
> > What is the magic that will allow this to be done. 
> 
> None.  The description of SecureLocal is somewhat deficient.  
> It applies only to loopback connections and only to sockets 
> managed by the Pascal/VMCF socket interface.  The 
> RxSocket/C/IUCV socket interface does not have support for SSL.
> 
> Under normal circumstances, loopback connections for static 
> SSL connections would be superfluous since the traffic never 
> leaves the stack 
> and the secured apps can't tell the difference.   
> "SecureLocal" overrides 
> that decision in case you have a stack that you want to use 
> for testing the management and use of SSL.
> 
> Alan Altmark
> 
> z/VM and Linux on System z Consultant
> IBM System Lab Services and Training
> ibm.com/systems/services/labservices
> office: 607.429.3323
> alan_altm...@us.ibm.com
> IBM Endicott
> 

z/VM 6.1, SSLSERV Question

[Schuh, Richard]

We have a person who is trying to get a secure end-to-end transaction between a 
CMS client and a TPF host.  RXSOCKET is being used by the CMS client. The port 
specified is 51105, which has been designated as a secure port. He has traced 
the SSLSERV and sees no traffic going through it; however, the connection to 
TPF is made and it is not secure. The ASSORTEDPARMS are coded as:

ASSORTEDPARMS
  SECURELOCAL
  PROXYARP
  IGNOREREDIRECT
  FREELOWPORTS
ENDASSORTEDPARMS

What is the magic that will allow this to be done.



Regards,
Richard Schuh

Re: Backups on Magentic Tapes

[Schuh, Richard]

What are you using for the backup? If it is DDR, you would have to construct a 
command file that looks something like:

PROMPTS OFF
SYSPRINT CONS
OUTPUT   vaddr 3590 other parms (LEAVE
INPUT vaddr 3390 volser
DUMP ALL

Repeat the INPUT and DUMP commands for each volume to dump.

If the above file is named DUMP CMDS, for example, you would need to


 *
Attach or link the disks to be dumped
 *
Attach a tape drive and mount the output tape
 *
Enter the command DDR  DUMP CMDS.
 *
Rewind and unload the tape.




Regards,
Richard Schuh






From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Mario Izaguirre
Sent: Thursday, November 25, 2010 6:10 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Backups on Magentic Tapes

Hi all:

I want to make a magnetic tape backup of all my z/VM residents, but the tape is 
3590 and I would type put all the DUMP of the volumes in the same magnetic 
tape, someone has some example of how to create multiple tapes within oneself.

Thanks in advance.




Best Regards,


Mario Izaguirre
Mainframe System Programmer
Barcelona, Spain

Re: The old VM/ESA CMS GUI - Does it still live?

[Schuh, Richard]

And then you have someone like me who finds typing to be burdensome due to a 
physical condition. If I had a GUI to manage the operating system, I would 
welcome it. One point I was making is that saying or implying that because 
someone prefers a GUI, they do not know what they are doing is a generality 
that has exceptions and is offensive. One can know how to do something using 
primitives and simply choose an easier method. It happens all of the time. It 
is why we have tools like Rexx and CMS Pipelines, for instance. I am familiar 
with machine instructions, but I do not write programs using them. The closest 
I have ever come to it (post IBM 601 days) is using Assembler. Does that make 
me stupid or a bad person? Does that imply that I don't know what I am doing? I 
think not.

As for your example of the DNS admins, they should know their limits as well as 
their abilities. Rule number 1 applies - if you do not know what a command 
does, do not enter it; if you do not know what clicking on an icon does, do not 
click it. If you do not know how to do something, read the manual or help files 
or ask someone who does know. If you go beyond your limits, be prepared to pay 
the price. The same can be said of every user from end user to admin (including 
DNS admin); from system operator to systems programmer. I would rather have 
someone ask very basic questions than do something they shouldn't, something 
that causes harm to themselves or others, for lack of asking. 
 
 
Regards, 
Richard Schuh 

 

> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of William D Carroll
> Sent: Wednesday, November 24, 2010 10:32 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: The old VM/ESA CMS GUI - Does it still live?
> 
> I think we can safely assume that since this discussion was 
> about VM CMS that we're talking operating systems and 
> interfaces to those OS's not applications as is your wife's 
> case GUI's have their place,  I personally do not believe 
> that place is in an OS to manage it or it's subsystems where 
> understanding what happens is very important.
> 
> I know DNS admins who can't manage their servers without GUI's.
> That to me is ridiculous and are admins who need to 
> understand more about what they manage.  Are they more 
> productive maybe,  are they dangerous, I leave that to you 
> Think of this,  what happens to those admins if their gui 
> breaks and all they have is command line.
> 
> 
> William 'Doug' Carroll
> 
> 
> -Original Message-
> From: The IBM z/VM Operating System 
> [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard
> Sent: Wednesday, November 24, 2010 12:54 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: The old VM/ESA CMS GUI - Does it still live?
> 
> That is an assumption or opinion, not necessarily a fact. For 
> example, my wife may not know the operating system line mode 
> commands, but she certainly knows the accounting systems that 
> she uses via a GUI interface. In fact, the GUI represents an 
> increase in productivity. 
> 
> I would suggest that if you do not know what you are doing, 
> then you should not use either interface; if you do know, you 
> should use whatever interface you choose. Rule Number 1 (Know 
> what you are doing) applies. 
> 
> Regards,
> Richard Schuh 
> 
>  
> 
> > 
> > You still type in your 3270 emulator, you still have to know 
> > what you're doing.   GUI's hide that from you
> > 
> > Doug
> > 
> This communication is for informational purposes only. It is 
> not intended as an offer or solicitation for the purchase or 
> sale of any financial instrument or as an official 
> confirmation of any transaction. All market prices, data and 
> other information are not warranted as to completeness or 
> accuracy and are subject to change without notice. Any 
> comments or statements made herein do not necessarily reflect 
> those of JPMorgan Chase & Co., its subsidiaries and affiliates.
> 
> This transmission may contain information that is privileged, 
> confidential, legally privileged, and/or exempt from 
> disclosure under applicable law. If you are not the intended 
> recipient, you are hereby notified that any disclosure, 
> copying, distribution, or use of the information contained 
> herein (including any reliance
> thereon) is STRICTLY PROHIBITED. Although this transmission 
> and any attachments are believed to be free of any virus or 
> other defect that might affect any computer system into which 
> it is received and opened, it is the responsibility of the 
> recipient to ensure that it is virus free and no 
> responsibility is accept

Re: The old VM/ESA CMS GUI - Does it still live?

[Schuh, Richard]

That is an assumption or opinion, not necessarily a fact. For example, my wife 
may not know the operating system line mode commands, but she certainly knows 
the accounting systems that she uses via a GUI interface. In fact, the GUI 
represents an increase in productivity. 

I would suggest that if you do not know what you are doing, then you should not 
use either interface; if you do know, you should use whatever interface you 
choose. Rule Number 1 (Know what you are doing) applies. 

Regards, 
Richard Schuh 

 

> 
> You still type in your 3270 emulator, you still have to know 
> what you're doing.   GUI's hide that from you
> 
> Doug
> 

Re: The old VM/ESA CMS GUI - Does it still live?

[Schuh, Richard]

Regards, 
Richard Schuh 

 

> Advanced sysprogs may or may not appreciate this, but novices 
> will certainly benefit from such advances in these user interfaces.


As can those who are keyboard challenged, regardless of their experience level.