zVSE 3.1 Performance

[s***@maccnet.com]

We recently upgraded from VSE/ESA 2.6.2 to z/VSE 3.1, when we moved
from a 9672 RA6 processor to a new z890 (2086-A04). We went from 88
MIPS to 150 MIPS. We run 4 VSE guests under zVM 5.2. We went from 2G
of memory to 8G. We utilize only one engine.

Our shop runs 95% batch, 24X7, with very little daily CICS data entry.
Our expectations were, that with the additional memory and increased
speed of the box, our VSE batch jobs would run more quickly.
Unfortunately, that's not what we're seeing. In fact, our schedulers,
developers and end-users have not seen a notable difference in the
amount of machine time that jobs require to complete.

This is obviously disturbing, since the whole reason we installed the
new z was to improve our throughput and allow for expected business
growth.

Hopefully, the issues we're experiencing with performance are related
to under-utilized memory and/or a poorly tuned system. Perhaps too
much of our "old" system crept forward into our new. Perhaps it's a
caching issue and we need to research products to assist with that.
(We used to use Cache Magic from SDI, but it won't run on zVM V5).
Perhaps our jobs are I/O bound and we need to determine that. The
problem is, we don't really know where to start.....

I would greatly appreciate any and all suggestions you may have.

Thank you.

[Eric Schadow]

Do you have a system monitor?

Is caching turned on for the DASD.?

Do you have MDC turned on?

CP Q MDC.


You are probably I/0 bound.

VSAM or Database?

eric











At 11:02 AM 7/7/2006, you wrote:
>We recently upgraded from VSE/ESA 2.6.2 to z/VSE 3.1, when we moved
>from a 9672 RA6 processor to a new z890 (2086-A04). We went from 88
>MIPS to 150 MIPS. We run 4 VSE guests under zVM 5.2. We went from 2G
>of memory to 8G. We utilize only one engine.
>
>Our shop runs 95% batch, 24X7, with very little daily CICS data entry.
>Our expectations were, that with the additional memory and increased
>speed of the box, our VSE batch jobs would run more quickly.
>Unfortunately, that's not what we're seeing. In fact, our schedulers,
>developers and end-users have not seen a notable difference in the
>amount of machine time that jobs require to complete.
>
>This is obviously disturbing, since the whole reason we installed the
>new z was to improve our throughput and allow for expected business
>growth.
>
>Hopefully, the issues we're experiencing with performance are related
>to under-utilized memory and/or a poorly tuned system. Perhaps too
>much of our "old" system crept forward into our new. Perhaps it's a
>caching issue and we need to research products to assist with that.
>(We used to use Cache Magic from SDI, but it won't run on zVM V5).
>Perhaps our jobs are I/O bound and we need to determine that. The
>problem is, we don't really know where to start.....
>
>I would greatly appreciate any and all suggestions you may have.
>
>Thank you.

Eric Schadow
Mainframe Technical Support
www.davisvision.com



------------------------------------------------------------------------
The information contained in this communication is intended
only for the use of the recipient(s) named above. It may
contain information that is privileged or confidential, and
may be protected by State and/or Federal Regulations. If
the reader of this message is not the intended recipient,
you are hereby notified that any dissemination,
distribution, or copying of this communication, or any of
its contents, is strictly prohibited. If you have received
this communication in error, please return it to the sender
immediately and delete the original message and any copy
of it from your computer system. If you have any questions
concerning this message, please contact the sender.
------------------------------------------------------------------------

[s***@maccnet.com]

We do have a system monitor. It's EXPLORE/VM from CA. There are some
bugs with it right now that we're working with them to fix.

Caching is turned on for the dasd. It's EMC dasd (5430s).

Mini disk caching is NOT turned on (Minidisk cache OFF for system)

We use SD and VSAM. No database.

Thanks....

Eric Schadow wrote:
> Do you have a system monitor?
>
> Is caching turned on for the DASD.?
>
> Do you have MDC turned on?
>
> CP Q MDC.
>
>
> You are probably I/0 bound.
>
> VSAM or Database?
>
> eric

[Mike Moore]

What kind of DASD are you running and how is it attached to the box? Are
your batch jobs heavy I/O users?

Mike Moore
IT Manager
Alabama Judicial Datacenter
300 Dexter Ave
Montgomery, AL 36104
334-954-5025

[s***@maccnet.com]

We are running EMC 5430 escon attached DASD. Batch jobs are HEAVY I/O
users.

Thanks.

Mike Moore wrote:
> What kind of DASD are you running and how is it attached to the box? Are
> your batch jobs heavy I/O users?
>
> Mike Moore
> IT Manager
> Alabama Judicial Datacenter
> 300 Dexter Ave
> Montgomery, AL 36104
> 334-954-5025

[Hughes, Jim - OIT]

What does your i/o subsystem look like?

We moved from a Multiprise 2003 and its internal dasd to a Z890 with
DS8100 dasd.

Our batch cycle elapsed time dropped by about 60%.

Just recently acquired a workload from a 9672 with ramac dasd and moved
it to the Z890. The 9672 dasd were cabled to the z890. There was a
reduction in cpu cycles though the elapsed time reduction was very
minor. We expect when the ramac dasd is migrated to the DS8100, elapsed
times will drop too.

All 9 of the vse systems are at VM/ESA 2.6.

ZVM 5.2 controls everything.

_______________________
Jim Hughes
603-271-5586
"Impossible is just an opinion."
"Your career is what you're paid for, your calling is what you're made
for."
"We cannot solve our problems with the same thinking we used when we
created them. Albert Einstein "

[s***@maccnet.com]

We are running with EMC 5430, escon-attached dasd. We have four VSE
systems.
Thanks.

Hughes, Jim - OIT wrote:
> What does your i/o subsystem look like?
>
> We moved from a Multiprise 2003 and its internal dasd to a Z890 with
> DS8100 dasd.
>
> Our batch cycle elapsed time dropped by about 60%.
>
> Just recently acquired a workload from a 9672 with ramac dasd and moved
> it to the Z890. The 9672 dasd were cabled to the z890. There was a
> reduction in cpu cycles though the elapsed time reduction was very
> minor. We expect when the ramac dasd is migrated to the DS8100, elapsed
> times will drop too.
>
> All 9 of the vse systems are at VM/ESA 2.6.
>
> ZVM 5.2 controls everything.
>
> _______________________
> Jim Hughes
> 603-271-5586
> "Impossible is just an opinion."
> "Your career is what you're paid for, your calling is what you're made
> for."
> "We cannot solve our problems with the same thinking we used when we
> created them. Albert Einstein "

[m***@mainline.com]

So much to cover here.

What was your CPU usage before the upgrade? If you weren't in a CPU wait
before, more CPU isn't helping.

Adding memory doesn't help like in Windows or Linux where both of those
OSes will immediately put it to use. You have to tell VSE/VM how to use
the new memory. VM will use it somewhat on it's own, but VSE really has to
be told how to use it.

I/O rates. Most batch jobs wait on I/O more than CPU. Look closely at
your I/O subsystem.



Mark D Pace
Senior Systems Engineer
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317
Office: 850.219.5184
Fax: [phone]
http://www.mainline.com

[s***@maccnet.com]

CPU usage before the upgrade was very high, averaging 95% most days.
It is now much lower, around 50 - 60%. We were definitely CPU bound
before, but aren't now.
Thanks.

***@mainline.com wrote:
> So much to cover here.
>
> What was your CPU usage before the upgrade? If you weren't in a CPU wait
> before, more CPU isn't helping.
>
> Adding memory doesn't help like in Windows or Linux where both of those
> OSes will immediately put it to use. You have to tell VSE/VM how to use
> the new memory. VM will use it somewhat on it's own, but VSE really has to
> be told how to use it.
>
> I/O rates. Most batch jobs wait on I/O more than CPU. Look closely at
> your I/O subsystem.
>
>
>
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
> 1700 Summit Lake Drive
> Tallahassee, FL. 32317
> Office: 850.219.5184
> Fax: [phone]
> http://www.mainline.com

[Ken Meyer]

Believe it or not, being CPU bound can help performance, if you are
determining performance based on one or a few high priority processes.
If a system is CPU bound, less consecutive requests will be processed,
so more of the I/O system will be dedicated to the high priority processes,
unless you have some type of balancing for I/O requests.

Now that you have more CPU power available, more consecutive requests for
I/O and other functions are being processed, which can slow down your higher
priority processing. This can make your system to appear slower than you
expect it to be after a major processor upgrade.

In addition, how the Z architecture works can make programs that have been
working well for years to appear to be slower because of the way it uses
storage and instruction cache area. Methods of handling instructions versus
data storage may need to be changed for many programs in order to take advantage
of the way Z architecture functions.

Ken Meyer
CSI


***@maccnet.com wrote:
> CPU usage before the upgrade was very high, averaging 95% most days.
> It is now much lower, around 50 - 60%. We were definitely CPU bound
> before, but aren't now.
> Thanks.

snip..

[Martin]

Sherry,

say that again:

>> We used to use Cache Magic from SDI, but it won't run on zVM V5 <<

You must have seen the change or did you change so much on the same moment?

Your I/O bound system did benefit greatly from that Cache-product. Now
either you invest into the various knobs in VM V5 or into another (or
the same) product.

--
Martin
--
XML2PDF - the way to get all features of PDF into your documents
on mainframe or PC systems; more at http://www.pi-sysprog.de

[Frank M. Ramaekers]

As everyone else asked, what is your DASD I/O subsystem. When we moved
from an H30 to a z800 we didn't get the same performance because of the
internal DASD H30 was significantly quicker than the Shark on ESCON. We
got better performance when we changed out the ESCON for FICON. We have
since went to a DS6000 and are seeing even better performance (again on
FICON).

Frank M. Ramaekers Jr.
Systems Programmer; MCP, MCP+I, MCSE & RHCE
American Income Life Insurance Company
Phone: [phone] Fax: [phone]

-----Original Message-----
From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU] On Behalf
Of ***@maccnet.com
Sent: Friday, July 07, 2006 10:03 AM
To: VSE Discussion List
Subject: zVSE 3.1 Performance

We recently upgraded from VSE/ESA 2.6.2 to z/VSE 3.1, when we moved
from a 9672 RA6 processor to a new z890 (2086-A04). We went from 88
MIPS to 150 MIPS. We run 4 VSE guests under zVM 5.2. We went from 2G
of memory to 8G. We utilize only one engine.

Our shop runs 95% batch, 24X7, with very little daily CICS data entry.
Our expectations were, that with the additional memory and increased
speed of the box, our VSE batch jobs would run more quickly.
Unfortunately, that's not what we're seeing. In fact, our schedulers,
developers and end-users have not seen a notable difference in the
amount of machine time that jobs require to complete.

This is obviously disturbing, since the whole reason we installed the
new z was to improve our throughput and allow for expected business
growth.

Hopefully, the issues we're experiencing with performance are related
to under-utilized memory and/or a poorly tuned system. Perhaps too
much of our "old" system crept forward into our new. Perhaps it's a
caching issue and we need to research products to assist with that.
(We used to use Cache Magic from SDI, but it won't run on zVM V5).
Perhaps our jobs are I/O bound and we need to determine that. The
problem is, we don't really know where to start.....

I would greatly appreciate any and all suggestions you may have.

Thank you.


----------------------------------------
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 ***@ailife.com.

[Ken Meyer]

Are you taking advantage of the extra memory by creating virtual
disks for VSE and/or VM for work files and other temporary data?
If you are heavy on I/O, this should help. How are you VSE systems
defined? You should make the VSE machines large and use the extra
real. What activity takes place on the VM system besides VSE virtual
machines? Do you share much data between the VSE systems? If so,
do you have a VM virtual disk for the VSE lock file?

Ken Meyer
CSI


***@maccnet.com wrote:
> We recently upgraded from VSE/ESA 2.6.2 to z/VSE 3.1, when we moved
> from a 9672 RA6 processor to a new z890 (2086-A04). We went from 88
> MIPS to 150 MIPS. We run 4 VSE guests under zVM 5.2. We went from 2G
> of memory to 8G. We utilize only one engine.

snip..

[s***@maccnet.com]

We use VM (CMS) for application development. All data is shared
between VSE systems. We're looking for information on placing the VSE
lock file on a VM virtual disk.

Thanks for your suggestions.


Ken Meyer wrote:
> Are you taking advantage of the extra memory by creating virtual
> disks for VSE and/or VM for work files and other temporary data?
> If you are heavy on I/O, this should help. How are you VSE systems
> defined? You should make the VSE machines large and use the extra
> real. What activity takes place on the VM system besides VSE virtual
> machines? Do you share much data between the VSE systems? If so,
> do you have a VM virtual disk for the VSE lock file?
>
> Ken Meyer
> CSI
>
>
> ***@maccnet.com wrote:
> > We recently upgraded from VSE/ESA 2.6.2 to z/VSE 3.1, when we moved
> > from a 9672 RA6 processor to a new z890 (2086-A04). We went from 88
> > MIPS to 150 MIPS. We run 4 VSE guests under zVM 5.2. We went from 2G
> > of memory to 8G. We utilize only one engine.
>
> snip..

[Ed Zell]

> We use VM (CMS) for application development. All data
> is shared between VSE systems. We're looking for information
> on placing the VSE lock file on a VM virtual disk.
>
> Thanks for your suggestions.


Here is what we do.


1) Create a new user in the directory called VSESETUP. It has
a virtual disk at address 999

USER VSESETUP xxxxxxxx 16M 16M G
OPTION CPUID C100D8
........
MDISK 999 FB-512 V-DISK 0800 MWV ALL ALL ALL


2) Set up an ASI proc for this machine that formats the lock file:

CATALOG $VSESET.PROC REPLACE=YES
009,$$A$SUPX,VIO=512K,VPOOL=64K,LOG,NOPDS
ADD 009,3277
ADD 00C,2540R
ADD 00D,2540P
ADD 00E,1403
ADD 220,ECKD,SHR
ADD 240,ECKD,SHR
ADD 999,FBA,SHR
DLF UNIT=999,BLK=2,NBLK=768,TYPE=F,NCPU=9
SET ZONE=WEST/00/00
DEF SYSCAT=DOSRES
DEF SYSREC=SYSWK1
SYS JA=YES
SYS BUFSIZE=1500
SYS NPARTS=12
SYS SEC=NO
SYS SPSIZE=0K
SYS BUFLD=YES
DLA VOLID=DOSRES,NAME=VSESETUP,CYL=377,NCYL=2,DSF=N
SVA SDL=300,GETVIS=(128K,512K),PSIZE=(128K,512K)
/+
CATALOG $0VSESET.PROC DATA=YES REPLACE=YES
STDOPT ACANCEL=NO,DECK=NO,DUMP=PART,SYSDMP=YES,SXREF=YES
*
*
*
* VSESETUP HAS COMPLETED FORMATTING THE FOLLOWING VDISKS
*
* 999 = VSE LOCK FILE
*
* VSESETUP IS NOW GOING TO SLEEP
*
* DO N O T LOGOFF FROM THIS MACHINE, TYPE * CP DISC
*
STOP
/&
/+


3) XAUTOLOG this machine at VM startup in AUTOLOG1 and have it format
the lock file using DSF in the PROFILE EXEC for VSESETUP


QUEUE 'CONSOLE'
QUEUE 'CONSOLE'
QUEUE 'INIT UNIT(999) NVFY NOMAP VOLID(VSELOK) FBAVTOC(END)'
QUEUE 'U'
QUEUE 'END'
ICKDSF



4) Change all other VSE's to use a lock file at 999 and you are all set

'CP LINK VSESETUP 999 999 MW' in the PROFILE EXEC

ADD 999,FBA,SHR VSELOK - VM VDISK FOR LOCK FILE
....
DLF UNIT=999



If this doesn't make sense or you want more specifics, just
give me a call.


Ed Zell
Illinois Mutual Life Insurance
[phone] x-107





.


CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.

[Max Singley]

I would check my DASD and tune it or even better, upgrade it if
feasible.

have fun,
Max E. Singley
Technical Services Project Leader
Alex Lee, Inc.
Email: ***@alexlee.com Tel: [phone]



-----Original Message-----
From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU] On Behalf
Of ***@maccnet.com
Sent: Friday, July 07, 2006 11:03 AM
To: VSE Discussion List
Subject: zVSE 3.1 Performance

We recently upgraded from VSE/ESA 2.6.2 to z/VSE 3.1, when we moved from
a 9672 RA6 processor to a new z890 (2086-A04). We went from 88 MIPS to
150 MIPS. We run 4 VSE guests under zVM 5.2. We went from 2G of memory
to 8G. We utilize only one engine.

Our shop runs 95% batch, 24X7, with very little daily CICS data entry.
Our expectations were, that with the additional memory and increased
speed of the box, our VSE batch jobs would run more quickly.
Unfortunately, that's not what we're seeing. In fact, our schedulers,
developers and end-users have not seen a notable difference in the
amount of machine time that jobs require to complete.

This is obviously disturbing, since the whole reason we installed the
new z was to improve our throughput and allow for expected business
growth.

Hopefully, the issues we're experiencing with performance are related to
under-utilized memory and/or a poorly tuned system. Perhaps too much of
our "old" system crept forward into our new. Perhaps it's a caching
issue and we need to research products to assist with that.
(We used to use Cache Magic from SDI, but it won't run on zVM V5).
Perhaps our jobs are I/O bound and we need to determine that. The
problem is, we don't really know where to start.....

I would greatly appreciate any and all suggestions you may have.

Thank you.

[Eric Schadow]

SIR SMF can used for DASD response analysis.

Issue SIR SMF,ON

wait a few minutes

Issue SIR SMF,VSE

and

SIR SMF,OFF



Make sure you have PTF DY46387/APAR UD52861 of the SIR command may loop


eric



Eric Schadow
Mainframe Technical Support
www.davisvision.com



------------------------------------------------------------------------
The information contained in this communication is intended
only for the use of the recipient(s) named above. It may
contain information that is privileged or confidential, and
may be protected by State and/or Federal Regulations. If
the reader of this message is not the intended recipient,
you are hereby notified that any dissemination,
distribution, or copying of this communication, or any of
its contents, is strictly prohibited. If you have received
this communication in error, please return it to the sender
immediately and delete the original message and any copy
of it from your computer system. If you have any questions
concerning this message, please contact the sender.
------------------------------------------------------------------------

[Mike Moore]

How much ESCON are you running to the DASD---how many paths? Any chance
you could move to FICON? We picked up our FICON cards on the used market
and they have made a huge difference. Based on your answer below about
your CPU utilization going down, I would say you
should look at your DASD configuration next.
Just for the heck of it, get a trial of OPTI-CACHE from BSI and see what
it will do for you. We have run it for years and it is a lot of bang for
the buck.

Mike Moore
IT Manager
Alabama Judicial Datacenter
300 Dexter Ave
Montgomery, AL 36104
334-954-5025

[s***@fastmail.fm]

This example uses no VSE guest; just a plain CMS userid with a VDISK at
400. Directory entry is followed by its profile exec. The VSEs have MW
links.

USER VSExxxxx xxxxxxxx 2M 2M ABEG 01
XAUTOLOG AUTOLOG1 MAINT OPERATOR
ACCOUNT 100 DOSSYS
MACH XA
OPTION ACCT
IPL CMS PARM AUTOCR
CONSOLE 009 3215
SPOOL 00C 2540 READER *
SPOOL 00D 2540 PUNCH A
SPOOL 00E 3211 E FCB 1GLT
LINK MAINT 190 190 RR
LINK MAINT 19D 19D RR
LINK MAINT 19E 19E RR
MDISK 191 3390 1900 0005 430W02 MW ALL READ WRITE
MDISK 400 FB-512 V-DISK 1560 MWV ALL READ WRITE

PROFILE EXEC

/* EXEC TO INITIALIZE THE VSE LOCK FILE (0400).
THE VSE LABEL AREAS ARE ON VSE VIRTUAL DISKS. */
'CP SET RUN ON'
'SET AUTOREAD OFF'
'CP SP CONS * START'
'MSGNOH OPERATOR VSE/ESA V2.1.3 SYSTEM LOCK FILE BEING INITIALIZED'
Push 'END'
Push 'U'
PUSH 'INIT UNIT(400),NOVFY,NOMAP,VOLID(LOCKFL),FBAVTOC(END)'
Push 'CONSOLE'
Push 'CONSOLE'
'ICKDSF'

'MSGNOH OPERATOR THE VSE/ESA SYSTEMS MAY NOW BE XAUTOLOGED.'
EXIT

--

Suleiman Shahin

--
http://www.fastmail.fm - mmm... Fastmail...

[Ed Zell]

This is much simpler than my approach.

Doesn't one of the VSE's need the full lock file command?

DLF UNIT=999,BLK=2,NBLK=768,TYPE=F,NCPU=9

instead of just DLF UNIT=999

If so, do you always make sure that VSE comes up first? Or
am I missing something here?

Thanks.

Ed Zell
[phone] x-107
***@illinoismutual.com




-----Original Message-----
From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU] On Behalf
Of ***@fastmail.fm
Sent: Thursday, July 13, 2006 11:37 AM
To: VSE Discussion List
Subject: RE: zVSE 3.1 Performance

This example uses no VSE guest; just a plain CMS userid with a VDISK at
400. Directory entry is followed by its profile exec. The VSEs have MW
links.

USER VSExxxxx xxxxxxxx 2M 2M ABEG 01
XAUTOLOG AUTOLOG1 MAINT OPERATOR
ACCOUNT 100 DOSSYS
MACH XA
OPTION ACCT
IPL CMS PARM AUTOCR
CONSOLE 009 3215
SPOOL 00C 2540 READER *
SPOOL 00D 2540 PUNCH A
SPOOL 00E 3211 E FCB 1GLT
LINK MAINT 190 190 RR
LINK MAINT 19D 19D RR
LINK MAINT 19E 19E RR
MDISK 191 3390 1900 0005 430W02 MW ALL READ WRITE
MDISK 400 FB-512 V-DISK 1560 MWV ALL READ WRITE

PROFILE EXEC

/* EXEC TO INITIALIZE THE VSE LOCK FILE (0400).
THE VSE LABEL AREAS ARE ON VSE VIRTUAL DISKS. */
'CP SET RUN ON'
'SET AUTOREAD OFF'
'CP SP CONS * START'
'MSGNOH OPERATOR VSE/ESA V2.1.3 SYSTEM LOCK FILE BEING INITIALIZED'
Push 'END'
Push 'U'
PUSH 'INIT UNIT(400),NOVFY,NOMAP,VOLID(LOCKFL),FBAVTOC(END)'
Push 'CONSOLE'
Push 'CONSOLE'
'ICKDSF'

'MSGNOH OPERATOR THE VSE/ESA SYSTEMS MAY NOW BE XAUTOLOGED.'
EXIT

--

Suleiman Shahin

--
http://www.fastmail.fm - mmm... Fastmail...

.


CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.

[Bill Dodge]

Ed,

If you do

DLF UNIT=999,BLK=2,NBLK=768,TYPE=N,NCPU=9

and the lock file hasn't been formatted it will override the N and format so I set all of my VSE systems to TYPE=N and whoever comes up first does the format (twice a year when the clocks change).

Bill Dodge
email: ***@vm-vse4metrodc.com
Phone: [phone]

"If you don't know where you are going, any road will take you there." Lewis Carroll
"If you don't know where you are, a map won't help" Unknown

[Ed Zell]

I've been working with VM/VSE for a long time but didn't
realize that is how things worked. I guess we have been
set up this way for so long I didn't realize there are
easier ways to do it.

I just love it when I learn something new like this !!

Thanks for all the responses and Long live VSE-L :)

Ed Zell
[phone] x-107
***@illinoismutual.com



-----Original Message-----
From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU] On Behalf
Of Bill Dodge
Sent: Thursday, July 13, 2006 1:07 PM
To: VSE Discussion List
Subject: RE: zVSE 3.1 Performance


Ed,

If you do

DLF UNIT=999,BLK=2,NBLK=768,TYPE=N,NCPU=9

and the lock file hasn't been formatted it will override the N and
format so I set all of my VSE systems to TYPE=N and whoever comes up
first does the format (twice a year when the clocks change).

Bill Dodge
.


CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.

[Kevin Corkery]

Ed ...

I think that the lock file format and creation is dynamic, i.e. it will be
formatted only once when needed subsequent IPLs would not format the file.
So, if you're formatting the lock file be sure to bring up only one VSE,
then the others can be IPLed. I don't think it really matters witch VSE
formats it. The default, TYPE=N causes this behavior. To force lock file
creation you should specify TYPE=F. When TYPE=N is in effect, if the lock
file is not formatted it will be formatted by the machine being brought up.
Make sure that all IPL procedure reference the same volume and extents for
the lock file.

Kevin P Corkery
Independent Consultant
Voorhees, New Jersey

-----Original Message-----
From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU] On Behalf Of Ed
Zell
Sent: Thursday, July 13, 2006 1:51 PM
To: VSE Discussion List
Subject: RE: zVSE 3.1 Performance


This is much simpler than my approach.

Doesn't one of the VSE's need the full lock file command?

DLF UNIT=999,BLK=2,NBLK=768,TYPE=F,NCPU=9

instead of just DLF UNIT=999

If so, do you always make sure that VSE comes up first? Or
am I missing something here?

Thanks.

Ed Zell
[phone] x-107
***@illinoismutual.com




-----Original Message-----
From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU] On Behalf Of
***@fastmail.fm
Sent: Thursday, July 13, 2006 11:37 AM
To: VSE Discussion List
Subject: RE: zVSE 3.1 Performance

This example uses no VSE guest; just a plain CMS userid with a VDISK at 400.
Directory entry is followed by its profile exec. The VSEs have MW links.

USER VSExxxxx xxxxxxxx 2M 2M ABEG 01
XAUTOLOG AUTOLOG1 MAINT OPERATOR
ACCOUNT 100 DOSSYS
MACH XA
OPTION ACCT
IPL CMS PARM AUTOCR
CONSOLE 009 3215
SPOOL 00C 2540 READER *
SPOOL 00D 2540 PUNCH A
SPOOL 00E 3211 E FCB 1GLT
LINK MAINT 190 190 RR
LINK MAINT 19D 19D RR
LINK MAINT 19E 19E RR
MDISK 191 3390 1900 0005 430W02 MW ALL READ WRITE
MDISK 400 FB-512 V-DISK 1560 MWV ALL READ WRITE

PROFILE EXEC

/* EXEC TO INITIALIZE THE VSE LOCK FILE (0400).
THE VSE LABEL AREAS ARE ON VSE VIRTUAL DISKS. */
'CP SET RUN ON'
'SET AUTOREAD OFF'
'CP SP CONS * START'
'MSGNOH OPERATOR VSE/ESA V2.1.3 SYSTEM LOCK FILE BEING INITIALIZED' Push
'END' Push 'U' PUSH 'INIT UNIT(400),NOVFY,NOMAP,VOLID(LOCKFL),FBAVTOC(END)'
Push 'CONSOLE'
Push 'CONSOLE'
'ICKDSF'

'MSGNOH OPERATOR THE VSE/ESA SYSTEMS MAY NOW BE XAUTOLOGED.' EXIT

--

Suleiman Shahin

--
http://www.fastmail.fm - mmm... Fastmail...

.


CONFIDENTIAL NOTICE: This communication, including any attachments, is
intended only for the use of the individual or entity to which it is
addressed and contains information which may be confidential. If you are
not the intended recipient, any distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify the sender immediately, delete the
communication and destroy all copies. Thank you for your compliance.

[s***@fastmail.fm]

In this case, the CMS userid is xautlogged first and formats the file,
The VSEs are Xaulogged after it.

Thu, 13 Jul 2006 12:51:25 -0500, "Ed Zell"
<***@illinoismutual.com> said:
> This is much simpler than my approach.
>
> Doesn't one of the VSE's need the full lock file command?
>
> DLF UNIT=999,BLK=2,NBLK=768,TYPE=F,NCPU=9
>
> instead of just DLF UNIT=999
>
> If so, do you always make sure that VSE comes up first? Or
> am I missing something here?
>
> Thanks.
>
> Ed Zell
> [phone] x-107
> ***@illinoismutual.com
>
>
>
>
> -----Original Message-----
> From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU] On Behalf
> Of ***@fastmail.fm
> Sent: Thursday, July 13, 2006 11:37 AM
> To: VSE Discussion List
> Subject: RE: zVSE 3.1 Performance
>
> This example uses no VSE guest; just a plain CMS userid with a VDISK at
> 400. Directory entry is followed by its profile exec. The VSEs have MW
> links.
>
> USER VSExxxxx xxxxxxxx 2M 2M ABEG 01
> XAUTOLOG AUTOLOG1 MAINT OPERATOR
> ACCOUNT 100 DOSSYS
> MACH XA
> OPTION ACCT
> IPL CMS PARM AUTOCR
> CONSOLE 009 3215
> SPOOL 00C 2540 READER *
> SPOOL 00D 2540 PUNCH A
> SPOOL 00E 3211 E FCB 1GLT
> LINK MAINT 190 190 RR
> LINK MAINT 19D 19D RR
> LINK MAINT 19E 19E RR
> MDISK 191 3390 1900 0005 430W02 MW ALL READ WRITE
> MDISK 400 FB-512 V-DISK 1560 MWV ALL READ WRITE
>
> PROFILE EXEC
>
> /* EXEC TO INITIALIZE THE VSE LOCK FILE (0400).
> THE VSE LABEL AREAS ARE ON VSE VIRTUAL DISKS. */
> 'CP SET RUN ON'
> 'SET AUTOREAD OFF'
> 'CP SP CONS * START'
> 'MSGNOH OPERATOR VSE/ESA V2.1.3 SYSTEM LOCK FILE BEING INITIALIZED'
> Push 'END'
> Push 'U'
> PUSH 'INIT UNIT(400),NOVFY,NOMAP,VOLID(LOCKFL),FBAVTOC(END)'
> Push 'CONSOLE'
> Push 'CONSOLE'
> 'ICKDSF'
>
> 'MSGNOH OPERATOR THE VSE/ESA SYSTEMS MAY NOW BE XAUTOLOGED.'
> EXIT
>
> --
>
> Suleiman Shahin
>
> --
> http://www.fastmail.fm - mmm... Fastmail...
>
> .
>
>
> CONFIDENTIAL NOTICE: This communication, including any attachments, is
> intended only for the use of the individual or entity to which it is
> addressed and contains information which may be confidential. If you are
> not the intended recipient, any distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, notify the sender immediately, delete the
> communication and destroy all copies. Thank you for your compliance.
--

Suleiman Shahin

--
http://www.fastmail.fm - Faster than the air-speed velocity of an
unladen european swallow

[s***@fastmail.fm]

I correct my previous statement. The CMS userid only inits the file. The
first VSE that logs after it does the formatting as others have
indicated.

(Sorry! Been such a long time that I touched on that issue!)

Suleiman Shahin

On Thu, 13 Jul 2006 12:51:25 -0500, "Ed Zell"
<***@illinoismutual.com> said:
> This is much simpler than my approach.
>
> Doesn't one of the VSE's need the full lock file command?
>
> DLF UNIT=999,BLK=2,NBLK=768,TYPE=F,NCPU=9
--

Suleiman Shahin

--
http://www.fastmail.fm - Accessible with your email software
or over the web

[Wakser, David]

Ed:

The lock file disk needs to be formatted before ANY of the VSEs come
up. That way, order doesn't matter. All VSEs have a MW link to the minidisk.
It really doesn't matter who "owns" it!

Many years ago, when I used a lock file, I had the "owner" of the
lock file xautologged when VM was IPLed (AUTOLOG1 did it). From that point
on, any or all of the VSE machines could we IPLed.

David Wakser

-----Original Message-----
From: Ed Zell [mailto:***@illinoismutual.com]
Sent: Thursday, July 13, 2006 1:51 PM
To: VSE Discussion List
Subject: RE: zVSE 3.1 Performance

This is much simpler than my approach.

Doesn't one of the VSE's need the full lock file command?

DLF UNIT=999,BLK=2,NBLK=768,TYPE=F,NCPU=9

instead of just DLF UNIT=999

If so, do you always make sure that VSE comes up first? Or am I missing
something here?

Thanks.

Ed Zell
[phone] x-107
***@illinoismutual.com




-----Original Message-----
From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU] On Behalf Of
***@fastmail.fm
Sent: Thursday, July 13, 2006 11:37 AM
To: VSE Discussion List
Subject: RE: zVSE 3.1 Performance

This example uses no VSE guest; just a plain CMS userid with a VDISK at 400.
Directory entry is followed by its profile exec. The VSEs have MW links.

USER VSExxxxx xxxxxxxx 2M 2M ABEG 01
XAUTOLOG AUTOLOG1 MAINT OPERATOR
ACCOUNT 100 DOSSYS
MACH XA
OPTION ACCT
IPL CMS PARM AUTOCR
CONSOLE 009 3215
SPOOL 00C 2540 READER *
SPOOL 00D 2540 PUNCH A
SPOOL 00E 3211 E FCB 1GLT
LINK MAINT 190 190 RR
LINK MAINT 19D 19D RR
LINK MAINT 19E 19E RR
MDISK 191 3390 1900 0005 430W02 MW ALL READ WRITE
MDISK 400 FB-512 V-DISK 1560 MWV ALL READ WRITE

PROFILE EXEC

/* EXEC TO INITIALIZE THE VSE LOCK FILE (0400).
THE VSE LABEL AREAS ARE ON VSE VIRTUAL DISKS. */
'CP SET RUN ON'
'SET AUTOREAD OFF'
'CP SP CONS * START'
'MSGNOH OPERATOR VSE/ESA V2.1.3 SYSTEM LOCK FILE BEING INITIALIZED'
Push 'END'
Push 'U'
PUSH 'INIT UNIT(400),NOVFY,NOMAP,VOLID(LOCKFL),FBAVTOC(END)'
Push 'CONSOLE'
Push 'CONSOLE'
'ICKDSF'

'MSGNOH OPERATOR THE VSE/ESA SYSTEMS MAY NOW BE XAUTOLOGED.'
EXIT

--

Suleiman Shahin

--
http://www.fastmail.fm - mmm... Fastmail...

.


CONFIDENTIAL NOTICE: This communication, including any attachments, is
intended only for the use of the individual or entity to which it is
addressed and contains information which may be confidential. If you are
not the intended recipient, any distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify the sender immediately, delete the
communication and destroy all copies. Thank you for your compliance.
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 of 1996. 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.

[Tom Duerbusch]

Actually, it does make a difference who formats it.

If you are runing different releases of VSE.....

Every once in a while, the lock file is expanded to allow for more
images. You normally would want the newer releases to do the lock file
formatting. Failure to do this, means that you will be restricted to
the number of images that the VSE release that did the formatting, had.

Been there, done that..
Got bit by a dasd converesion where I used an older VSE system to
create the lock file. When I cut over to production, after the 8th
machine, we failed on lock file processing....ooops.

Took an hour to figure that one out.

Tom Duerbusch
THD Consulting

>>> ***@infocrossing.com 7/13/2006 1:05 PM >>>
Ed:

The lock file disk needs to be formatted before ANY of the VSEs
come
up. That way, order doesn't matter. All VSEs have a MW link to the
minidisk.
It really doesn't matter who "owns" it!

Many years ago, when I used a lock file, I had the "owner" of
the
lock file xautologged when VM was IPLed (AUTOLOG1 did it). From that
point
on, any or all of the VSE machines could we IPLed.

David Wakser