Discussion:
PAV use in zVSE
(too old to reply)
Victor, C. T. Hsiao
2016-08-13 08:23:40 UTC
Permalink
Hello:
I recently installed a zVSE V5.2 using IBm DS8884 which supports PAV. All the setup is O.K. I have 3 alias addresses for my DOSRES and SYSWK1. After turning on the SMF, I noticed that the IO count for one alias is much larger than the IO count for the base address, and the other two alias has near-zero IO count.
I read from document that "z/VSE does load levelling for parallel I/O’s by selecting a “free” device among the available base and alias devices." But it looks like that z/VSE tends to select the alias instead of the base. Another possible reason is that the device(base or alias) selection was made during task startup, not for every I/O.
I also read from the same document that "Subsystem Monitoring Facility (SMF) is enabled to collect base device information only". Therefore maybe this is the third possible explanation.
Is there anyone have the same experience?
m***@gmail.com
2016-08-23 20:55:45 UTC
Permalink
If you look at the PAV White Paper, the SIR SMF,VSE,777 command output shows the same thing as you see in terms of the number of I/Os to the base vs the aliases.

I think the bit about "collecting base device information only" may be related to having one set of I/O timings (QUEUED etc.) and not one set for the base and one per alias, but I could be wrong.

Mike
Ken and Mary Meyer
2016-08-24 13:55:47 UTC
Permalink
Unless IBM has resolved issues with out of order operations with PAV,
I would not recommend using it in production if you have any products
(BIM/CSI or CA former GOAL products, for example) or other third
party vendors that use special means to protect file/member integrity
within and between individual z/VSE and z/VM instances without using
the lock mechanisms available for those operating systems.

Ken

snip..
Mick Poil
2016-08-24 15:54:47 UTC
Permalink
Ken,

That sounds rather worrying. What kind of fallout can there be? I don't
remember anything like this being mentioned before.

Mike
Ken and Mary Meyer
2016-08-24 16:03:45 UTC
Permalink
The fallout is CCW chains not being consecutive when they have to be to
function properly. I mentioned this to VM people at multiple WAVV
conferences, as well as reporting it as an issue. There is a way to keep
them treated as a single "operation", but it was not working properly. My
research is property of CSI and CA now, so I do not have access to it.
If you want more "proprietary" information, email me privately.

Ken


snip..
Avihu Gershoni
2016-08-25 04:14:54 UTC
Permalink
I read with interest the posts about PAV because I am considering using it at my next storage replacement.
I read the white paper and the section in the Administration manual, but did not find a clear answer to the question:
Should PAV-alias devices be considered in counting the total number of devices defined by the IODEV parameter?

The manual does specify that you must define only base addresses in the IPL and can use only 1023 devices out of the 1024 defined by IODEV in a system with PAV because PAV activation requires to have one 'spare' I/O device eligible, but is the spare I/O device the only address "lost" by using PAV?

Avihu Gershoni
Mainframe System Department Manager
Hilan Limited
8 Meitav Street
Tel Aviv
Israel
Mick Poil
2016-08-25 07:49:57 UTC
Permalink
Avihu,

No PAV here and we run under VM and none of my customers use it, so I can't
say. Why not go the the z/VSE home page an "Contact IBM"?

Mike
Avihu Gershoni
2016-08-29 13:08:17 UTC
Permalink
Hello Mick,

I used your advice and this is the answer I got from Natalie Speiser from IBM Systems & Technology Group, Systems Software Development:

" The actual number of devices is calculated during IPL through the corresponding ADD statements. Since you only add the PAV base devices, PAV alias devices are not considered.
In z/VSE we allocate one dummy device for PAV initialization - no matter how many base devices have been added. So if you define 1024 devices, you can actually use only 1023."

Avihu


<http://www.hilan.co.il/>
Ernie J. Carney
2016-08-29 16:46:45 UTC
Permalink
1023 devices would be more than enough if z/VSE was allowed to use the huge DASD devices that z/VM and z/OS are allowed. z/VSE currently has a max disk size of 65520 Cylinders. z/OS and z/VM max is closer to 256,000 cylinders. I placed an RFE on IBM's web Site last year and have heard nothing.


E J Carney
CTO
DOB Systems, LLC

From: Avihu Gershoni [mailto:***@hilan.co.il]
Sent: Monday, August 29, 2016 8:08 AM
To: Vse-L (vse-***@Lehigh.EDU)
Subject: Re: PAV use in zVSE

Hello Mick,

I used your advice and this is the answer I got from Natalie Speiser from IBM Systems & Technology Group, Systems Software Development:

" The actual number of devices is calculated during IPL through the corresponding ADD statements. Since you only add the PAV base devices, PAV alias devices are not considered.
In z/VSE we allocate one dummy device for PAV initialization - no matter how many base devices have been added. So if you define 1024 devices, you can actually use only 1023."

Avihu
Kevin Corkery
2016-08-30 13:34:25 UTC
Permalink
Sounds like a use for an FOR in your CICS environment.

From: VSE-L [mailto:vse-l-bounces+kcorkery=***@lists.lehigh.edu] On Behalf Of Avihu Gershoni
Sent: Monday, August 29, 2016 11:55 PM
To: Vse-L (vse-***@Lehigh.EDU)
Cc: Ernie J. Carney
Subject: RE: PAV use in zVSE

Ernie,

I could live with the 1024 devices limitation defined by IODEV if all my disk devices were defined as 3390-54 for the foreseeable future, but the real limitation is not this but the 255 logical units per partition. This limitation can prevents opening a VSAM file in CICS if it needs new logical units beyond the maximum of 255.

Avihu


From: Ernie J. Carney [mailto:***@dobsystems.com]
Sent: Monday, August 29, 2016 7:47 PM
To: Avihu Gershoni; Vse-L (vse-***@Lehigh.EDU<mailto:vse-***@Lehigh.EDU>)
Subject: RE: PAV use in zVSE

1023 devices would be more than enough if z/VSE was allowed to use the huge DASD devices that z/VM and z/OS are allowed. z/VSE currently has a max disk size of 65520 Cylinders. z/OS and z/VM max is closer to 256,000 cylinders. I placed an RFE on IBM's web Site last year and have heard nothing.


E J Carney
CTO
DOB Systems, LLC

From: Avihu Gershoni [mailto:***@hilan.co.il]
Sent: Monday, August 29, 2016 8:08 AM
To: Vse-L (vse-***@Lehigh.EDU<mailto:vse-***@Lehigh.EDU>)
Subject: Re: PAV use in zVSE

Hello Mick,

I used your advice and this is the answer I got from Natalie Speiser from IBM Systems & Technology Group, Systems Software Development:

" The actual number of devices is calculated during IPL through the corresponding ADD statements. Since you only add the PAV base devices, PAV alias devices are not considered.
In z/VSE we allocate one dummy device for PAV initialization - no matter how many base devices have been added. So if you define 1024 devices, you can actually use only 1023."

Avihu
Avihu Gershoni
2016-08-31 03:31:16 UTC
Permalink
Hi Kevin,

FOR is certainly an option, but if my memory serves me right Function Shipping incurs 100% CPU increase. So I prefer to move to 3390-27 or 3390-54 instead.

Avihu

<http://www.hilan.co.il/>
Mick Poil
2016-08-31 09:49:26 UTC
Permalink
Function shipping is expensive compared to local VSAM I/O. Even with
MROLRM=YES, you use one MRO 2-way communication for every VSAM request.
With MROLRM=NO you have that plus a CSMI task to create and tear down for
every request.

In the LVC I gave in July 2014 I wrote down the results of a I/O load test
driver comparing Local vs Function Shipping VSAM requests, although what I
saw would have been exaggerated. MRO uses a lot of expensive SVCs, which
doesn't help if you use more than one cpu.

Mike
Lou Winston
2016-09-04 12:44:18 UTC
Permalink
If function shipping is so expensive, what about the VSAM redirector and all that stuff? How expensive is that?


L.W.


________________________________
From: VSE-L <vse-l-bounces+lewinston=***@lists.lehigh.edu> on behalf of Mick Poil <***@gmail.com>
Sent: Wednesday, August 31, 2016 5:49 AM
To: VSE Discussion List
Subject: Re: PAV use in zVSE

Function shipping is expensive compared to local VSAM I/O. Even with MROLRM=YES, you use one MRO 2-way communication for every VSAM request. With MROLRM=NO you have that plus a CSMI task to create and tear down for every request.

In the LVC I gave in July 2014 I wrote down the results of a I/O load test driver comparing Local vs Function Shipping VSAM requests, although what I saw would have been exaggerated. MRO uses a lot of expensive SVCs, which doesn't help if you use more than one cpu.

Mike
Mick Poil
2016-09-05 06:06:41 UTC
Permalink
No idea.
Loading...