Thats a good list. Here are some more ideas from our shop:
I'd first want to make sure that VM:Secure works. Trying to log on is a
good test. New functions will already have been tested second level.
Then I'd want to make sure that we can IPL z/OS and z/Linux guests.
Then the rest of the VM:Manager suite.
Our current management asks us to test ALL our program products, using th
e
IVP or whatever other test we can come up with for each one. That
exercises CMS. I don't thing that's really necessary, as CMS hasn't
changed in a long time and problems with program products are now
extremely rare.
We also have to test our CP exits and the two mods VMSI VPARS and VTAPE.
We test those all second level before we ever get into production, though
.
We have a couple of times been bitten by something that worked differentl
y
at first level than second level.
In general, I think you should concentrate on whatever is most important
to your shop - your bread and butter. So an IBM IVP would probably be of
limited use.
In our shop, most of the important things, like z/OS guests on some
systems, and VM:Sched jobs on others, get run automatically when we bring
the systems up, so all we really have to do is watch for a few hours on
Sunday. (We IPL very early on Sunday.)
We have had a number of problems with DB2 Private Data Spaces in z/VM
5.2.0 and 5.3.0, so that also we test at second level, then again first
level. (We still have 5.2.0 running on one last system, due to a problem
in this area that we discovered second level. It took us 2 months to
reproduce it.)
I guess the general principle is that if you have had a problem in some
area in the recent past, its important to put that on your test list.
Alan Ackerman
Alan (dot) Ackerman (at) Bank of America (dot) com
On Fri, 15 Feb 2008 12:49:56 -0500, Doug Breneman <[EMAIL PROTECTED]>
wrote:
>
>Hi All,
>Many years ago there was an Installation Verification Procedure for VM.
>This was mostly directed toward CMS tasks. We found that this was not
very
>useful and removed it from our product documentation. We have a list of
>some items that we use as an IVP when we get a new release of VM. This
is
>not an official IBM IVP. This include things like:
>
>CP IPL (MP) - stop if you cannot do this :-)
>CMS IPL (190 and Segment) - needed to do many other things. 190 is need
ed
>if the segment fails
>GCS IPL - needed for RSCS and other applications
>RSCS Initializes - needed for sending/receiving files
>PVM Initializes - remote system access
>SFS Initializes - file storage
>TCP/IP Initializes
> Able to logon to the system via telnet - remote system access
> Able to FTP to and from VM - needed for sending/receiving files
> NETSTAT command functions - needed for our environment
>Run test workloads to reach 50-70% CPU load for 4 hours. - load that is
>reasonable for us to ensure some stability. The test workloads vary.
>Linux and z/OS each IPL second level. - needed for our environment
> Workloads must run on both of these guest operating systems.
>
>These are some of the things that we do to initially verify the installe
d
>VM. If all of these work, then we have a good chance that we can contin
ue
>to use the new release. The items that are important to you might vary
>from this list. I hope this list might act as one example.
>
>Doug Breneman z/VM Development IBM Endicott, NY
>
>
>
>
> Adam Thornton
> <[EMAIL PROTECTED]
> mine.net>
To
> Sent by: The IBM IBMVM@LISTSERV.UARK.EDU
> z/VM Operating
cc
> System
> <[EMAIL PROTECTED] Subje
ct
> ARK.EDU> Re: Installation Verification
> Procedures
>
> 02/15/2008 10:22
> AM
>
>
> Please respond to
> The IBM z/VM
> Operating System
> <[EMAIL PROTECTED]
> ARK.EDU>
>
>
>
>
>
>
>On Feb 15, 2008, at 9:07 AM, Alan Altmark wrote:
>> Program products have IVPs because .... I don't know. The great thing
>> about computers, unlike people, is that they reliably do the same
>> thing
>> every time.
>
>Here speaks a man who works in Endicott, not in Redmond.
>
>Adam
>
