Re: REXX that verify what MINIDISK is a file

[Les Koehler]

Sergio,
As Scott suggests, compiling is the first step to protect yourself from getting 
calls about tools that are not *your* tools.


The second step, assuming you can't get the tool installed in a shared segment 
(or whatever they call it these days), is to check that it is executing from an 
EXECLOAD from the correct disk. If not, then EXECLOAD it with the PUSH option, 
re-invoke it and then EXECDROP it.


Your tracking mechanism should use the same technique.

You might want to consider allowing a specified userid run it from disk for 
testing purposes.


Another advantage to doing this is that you avoid the problem of users running 
back-level code that was copied to some other disk earlier in the search order. 
Back in the days when I worked at IGS in Tampa, this was one of the biggest 
problems we constantly faced. Someone would create a 'collection' of tools from
several disks in order to avoid using up all the mode letters. Then they'd have 
everyone else in their department link&access the 'department' disk. Of course 
they never checked to see if the *original* disk had been updated with a later 
version!


A good tracking facility helps in this area as well. You can just look at the 
tracking data and tell the complainer "You're not running the current version of 
MY tool!"


Just be real careful about what you protect this way. For instance, the Rexx 
compiler execs are 'sample' code and can be greatly enhanced by the user to do 
such things as add an automatic Copyright statement from a lookup file, as well 
as a 'footprint' that identifies the source code disk, date/time of the source, etc.


Les

Scott Rohling wrote:

Yes - exactly what I did to test my code snippet.

You'll never be able to stop people from copying files to their A disk - and
making modifications - including removing any checks you make for an X disk,
etc.   Users can do an EXECDROP or EXECLOAD on their own - there's not many
good ways to stop a determined user from shooting themselves in the foot if
they want to.

Sergio - maybe the best answer to solve the root problem is to compile the
REXX code?People could still have old copies of CATAA .. but at least if
it's compiled, they can't make changes to the current code.

Scott Rohling

On Thu, Oct 14, 2010 at 3:45 PM, Michael Coffin wrote:


 Just checking the filemode of the program will not guarantee that that it
is running from MAINT 31A.If I:



ACCESS 191 X



Then execute CATAA with Parse Source in it, the Parse Source will show it
is running from the mdisk accessed as X – but it’s my 191, not the MAINT
31A.



Look into CP QUERY MDISK to verify that the disk accessed as X is MAINT
31A.



-Mike



*From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On
Behalf Of *Sergio Lima
*Sent:* Thursday, October 14, 2010 5:17 PM

*To:* IBMVM@LISTSERV.UARK.EDU
*Subject:* Re: REXX that verify what MINIDISK is a file



Hello Mike,

Thanks very much from your good explanation.

We need that the user execute our EXEC from a public dasd (Maint 31a),
because, We try track who executed this, the date, the time, and another
thinks, like Filename, Filetype, Filemode.
This EXEC do a Compilation of programs here, and now, the people here, want
have a little control about what was compiled, and others thinks.

Thanks again, and Best Regards,

Sergio

 --

Date: Thu, 14 Oct 2010 15:03:36 -0500
From: mike.wal...@hewitt.com
Subject: Re: REXX that verify what MINIDISK is a file
To: IBMVM@LISTSERV.UARK.EDU


It is pretty unusual to force an EXEC to execute from a specific disk.
 About 98% of the time I do that is when running a common 'PROFCMS EXEC' in
everybody's "PROFILE EXEC" - the "PROFCMS EXEC" complains when it is not
executing from the Y-disk (or the our HAINST alternative to IBM's CMSINST
NSS).  Also, a common "PROFILE XEDIT" complains of the same results (after
it does some preliminary setup, it attempts to execute the user's  "userid
XEDIT" macro).

But if you really need to execute an exec from a specific disk, from my 20
July 2009 post here:
Check out Kent Fiala's "DIREXEC" on the IBM VM Download page:
http://www.vm.ibm.com/download/packages/descript.cgi?DIREXEC

That DIREXEC VMARC package should do exactly what you wish, and explains
that the included FMEXEC is syntactically easier to use for minidisk
files.

But before you do that, please help us understand why you would want to do
so.  There may be much better solutions yo meet your need.

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

  *"Sergio Lima" *

Sent by: "The IBM z/VM Operating System"  10/14/2010
02:19 PM

Please respond to
"The IBM z/VM Operating System" 



   To

IBMVM@LISTSERV.UARK.EDU

cc

Subject

REXX that verify what MINIDISK is a file






Hello List,

We are changing a REXX here for that this EXEC execute only if reside on X
acessed minidisk.
So, try with STATE command without succesfull  and now try  with LISTF

Re: REXX that verify what MINIDISK is a file

[Les Koehler]

I learned:

'CONWAIT'
'DESBUF'

but maybe that isn't necessary any more.

Les

Hughes, Jim wrote:

You need to issue a DESBUF command before the EXIT 99 statement.

 


The LISTFILE command is putting the EXECNAME is the program/console
stack and being read after your problem exits.  CMS reads it and starts
executing it again and again,

 




Jim Hughes

603-271-5586

"It is fun to do the impossible."



From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Sergio Lima
Sent: Thursday, October 14, 2010 5:25 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: REXX that verify what MINIDISK is a file

 


Scott,
 
Sorry about disturb, but still don't run, look please :
 
The code :
 
 trace r   
 'LISTFILE  cataa exec * (DATE STACK LIFO' 
   
 Parse Source . . x1 x2 x3 .   
 If left(x3,1) <> 'X' Then Do  
   Say 'You are not executing from the X disk!'
   Exit 99 
 End   
 
The result :
 
 3 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
 5 *-* Parse Source . . x1 x2 x3 . 
   >.>   "CMS" 
   >.>   "COMMAND" 
   >>>   "VX"  
   >>>   "EXEC"
   >>>   "A1"  
   >.>   "VX CMS"  
 6 *-* If left(x3,1) <> 'X'
   >>>   "1"   
   *-*  Then   
   *-*  Do 
 7 *-*   Say 'You are not executing from the X disk!'  
   >>> "You are not executing from the X disk!"
You are not executing from the X disk! 
 8 *-*   Exit 99   
   >>> "99"
 8 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* Parse Source . . x1 x2 x3 . 
   >.>   "CMS" 
   >.>   "COMMAND" 
   >>>   "CATAA"   
   >>>   "EXEC"
   >>>   "A2"  
   >.>   "CATAA CMS"   
11 *-* If left(x3,1) <> 'X'
   >>>   "1"   
   *-*  Then   
   
HOL
   *-*  Do  
12 *-*   Say 'You are not executing from the X disk!'   
   >>> "You are not executing from the X disk!" 
You are not executing from the X disk!  
13 *-*   Exit 99
   >>> "99" 
 8 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO"  
10 *-* Parse Source . . x1 x2 x3 .  
   >.>   "CMS"  
   >.>   "COMMAND"  
   >>>   "CATAA"
   >>>   "EXEC" 
   >>>   "A2"   
   >.>   "CATAA CMS"
11 *-* If left(x3,1) <> 'X' 
   >>>   "1"
   *-*  Then
   *-*  Do  
12 *-*   Say 'You are not executing from the X disk!'   
   >>> "You are not executing from the X disk!" 
You are not executing from the X disk!  
13 *-*   Exit 99
   >>> "99" 
 8 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO"  
10 *-* Parse Source . . x1 x2 x3 .  
   >.>   "CMS"  
   >.>   "COMMAND"  
   >>>   

CAVMEN Meeting on Thursday, October 28, 2010

[Chicago Area VM (and Linux) Enthusiasts]

The fourth quarter meeting of the Chicago Area VM (and Linux) 
Enthusiasts will be held on Thursday, October 28, 2010.


We are scheduled to meet in room M2 off the cafeteria, it is right 
next to room M3 where we frequently meet.


NOTE:  We have a very full agenda for this meeting, and we will be 
starting promptly at 9:00AM.



--

Meeting Location:

This quarter's meeting will be held at the Hewitt Associates 'East 
Campus' located at 100 Half Day Road, in Lincolnshire, IL. We will 
meet in Conference Room 100-M2, in Building 100, just off the cafeteria.


If you have not attended a meeting at this location before, or you 
are not familiar with the area, 
Click here for 
additional information on directions, maps, lodging and dining.



--

Attendance:

We would like to request a count of expected attendees by the Monday 
before the meeting, so that we may plan appropriately for arranging 
the facilities, and for refreshments and lunch, should one of the 
vendors wish to provide them. If you are planning to attend, PLEASE 
send an E-Mail by that date to 
cav...@comcast.net with a subject line of 
"Meeting Attendance".


This is meant to be a facilities planning aid and should not be 
interpreted as a registration requirement. If you suddenly become 
available at the last minute, please feel free to attend even if you 
have not responded.


Thank you in advance for your cooperation in this matter.


--

Meeting Agenda:

9:00 AM z/VM Platform Update

This session will provide you with the latest & greatest information 
about z/VM. We will discuss the recently announced updates to z/VM 
V5.4 and z/VM 6.1, including support for the IBM zEnterprise System, 
as well as the Statements of Direction for Single-System Image and 
Live Guest Relocation.


The speaker will be John Franciscovich of the IBM Corporation.

10:05 AMCoffee Break

10:15 AMz/VM Single System Image and Guest Mobility Preview

IBM has issued a Statement of Direction describing its intent to 
permit multiple z/VM Systems to collaborate in a Single System Image 
cluster, and to allow a running guest to be moved from one member of 
a cluster to another with Live Guest Relocation. This presentation 
provides a preview of these enhancements.


The speaker will be John Franciscovich of the IBM Corporation.

11:30 PMLunch Break

12:30 PMAdministration and Vendor Announcements

12:45 PMLinux on z Update

The speaker will present a brief update of recent developments in the 
Linux under z/VM area.


The speaker will be Paul Augustyniak of the IBM Corporation.

1:00 PM CSL-WAVE - Linux / z/VM Virtual Server Management

CSL-WAVE, is very unique in the sense that it provides complete 
freedom to our users to operate z/VM-based virtual server farms while 
eliminating the need for the Linux sys-admins to develop a z/VM skill 
set. CSL-WAVE abstracts the z/VM resources and knowhow via its 
intuitive GUI and architecture to the point that CSL-WAVE users do 
not need to resort to the z/VM system programming dept for help for 
any of their day-to-day infrastructure management nor for even more 
advanced activities such as storage or network management. All within 
the scope and permissions that are dictated by the site-level 
CSL-WAVE administration function (Usually the z/VM system programmer).


The product handles all aspects of the virtual server farm: Virtual 
server management, provisioning, storage managed at the server and 
z/VM instance level, Network (GLANs and VSwitches), even script 
management across the virtual server farm.


The speaker will be Sharon Chen, Founder and CEO of CSL-International.

2:15 PM Coffee Break

2:30 PM What's new from IBM for automating operations on z/VM 
and Linux on System z


As the Linux on System z environment continues to grow, the need for 
software and solutions to manage this environment also grows. IBM 
continues to enhance a set of software solutions to assist customers 
with automated operations, system management, and storage management. 
This session will focus on automated operations and what's new in 
Operations Manager for z/VM V1.4, announced and available in 
September 2010. Live demos will be included.


The speaker will be Tracy Dean of the IBM Corporation.

3:30 PM Coffee Break and Prize Drawing

3:45 PM What's new from IBM for tape management on z/VM

As the Linux on System z environment continues to grow, the need for 
software and solutions to manage this environment also grows. IBM 
continues to enhance a set of software solutions to assist customers 
with automated operations, system management, and storage management. 
This session will focus on tape management and what's new in Tape 
Manager for z/VM V1.3, announced and available in September 2010.


The speaker will be Tracy Dean of the IBM Corporation.

4:45

Re: Applied RSU but CPLEVEL is unchanged

[George Henke/NYLIC]

tyvm everyone, 

The IPL shows the old Service Level but the current date/time stamp.

19:09:15 z/VM  V5 R4.0  SERVICE LEVEL 0802 (64-BIT) 
19:09:16 SYSTEM NUCLEUS CREATED ON 2010-10-14 AT 12:05:41, LOADED 
FROM 54XRES

It is the same whether I IPL from CF1 or CF2, but CF3 shows the 2 year old 
version.

I did run Service and P2P twice once for the RSU and once again for the 
COR for the 3 z196 compatibility APARs.

I did IPL between the 2 Service sessions.

SERVICE ALL STATUS shows these APARs were applied, built, and put2prod.

service all status vm64798   
VMFSRV2760I SERVICE processing started 
VMFSRV1226I CP (5VMCPR40%CP) APAR VM64798 (PTF UM33151) status: 
VMFSRV1226IRECEIVED  10/14/10 12:02:44 
VMFSRV1226IAPPLIED   10/14/10 12:03:24  
VMFSRV1226IBUILT 10/14/10 12:06:15 
VMFSRV1226IPUT2PROD  10/14/10 12:23:28 
VMFSRV2760I SERVICE processing completed successfully 
 
service all status vm64879   
VMFSRV2760I SERVICE processing started 
VMFSRV1226I CP (5VMCPR40%CP) APAR VM64879 (PTF UM33171) status: 
VMFSRV1226IRECEIVED  10/14/10 12:02:44 
VMFSRV1226IAPPLIED   10/14/10 12:03:24   
VMFSRV1226IBUILT 10/14/10 12:06:15 
VMFSRV1226IPUT2PROD  10/14/10 12:23:28 
VMFSRV2760I SERVICE processing completed successfully
 
service all status vm64881
VMFSRV2760I SERVICE processing started 
VMFSRV1226I CP (5VMCPR40%CP) APAR VM64881 (PTF UM33183) status: 
VMFSRV1226IRECEIVED  10/14/10 12:02:44 
VMFSRV1226IAPPLIED   10/14/10 12:03:24 
VMFSRV1226IBUILT 10/14/10 12:06:15 
VMFSRV1226IPUT2PROD  10/14/10 12:23:28 
VMFSRV2760I SERVICE processing completed successfully 
 

But that is no assurance that I am running with them, unless the 0802 is 
just "cosmetic".  But I doubt it.

I will need to examine $VMF... $MSGLOG more carefully, as MIke Walter 
suggests, to see what has happened.

PTFs did get applied and I do see the correct SES envelop FNs in $MSGLOG, 
so I know I did not just rerun with the old SERVLINK.





George Henke/NYLIC
10/14/2010 06:36 PM

To
The IBM z/VM Operating System 
cc

Subject
Re: Applied RSU but CPLEVEL is unchanged





My HCPCPE AUXVM file shows 0802

My SHOPZ order has Stacked 5407 and PTF UM97540.

I saw PTFs go on, but I can't explain the AUXVM contents.




Mike Walter  
Sent by: The IBM z/VM Operating System 
10/14/2010 03:37 PM
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Applied RSU but CPLEVEL is unchanged







George, 

RSU0802 is from "5402RSU Stacked Product RSU -  December  12, 2008". 

Does CP Query CPLOAD show the sysres from which you expected to IPL? 
(Again, a good reason to not use the save volser on different real device 
addresses, aka UCB's).  If not, don't blame the service, it would be time 
to figure out what went wrong in your maintenance process between your 
production and new DDR'ed 2nd level systems. 

Can you provide the exact APAR or PTF number that you actually ordered? 

To find the most current z/VM PTF, always search for APAR UM97vr0 (where 
v=version, and r=release). 
For example for z/VM 5.4 you'd check out UM97540, and for z/VM 6.1 it 
would be UM97610. 

The RSU display by Q CPLEVEL is updated with each RSU into HPCCPE.  You 
might want to enter: 
VMFSETUP ZVM CP 
then 
FILELIST HCPCPE * * 
See what's in the HCPCPR AUXVM file.  If it shows the PTF for RSU1002, 
then it's time to find out where the CPLOAD MODULE was written. 
For clues, browse the " $VMFP2P  $MSGLOG  A1" file.  The most recent 
udpates are at the top, going back through history downward through the 
file. 
Ours shows: 
-- 
ST:HCPZAC6730I CPRELEASE request for disk A completed. 

ST:VMFP2P2204I Linking MAINT CF1 as 1FFF with the link mode M 
ST:DMSACP723I X (CF2) R/O 
ST:VMFP2P1231I Copying files from the Secondary Parm disk to the Primary   

ST:Parm disk   

ST:HCPZAC6732I CPACCESS request for MAINT's 0CF1 in mode A completed. 
-- 

That implies that the VMFBLD wrote to CPLOAD MODULE to the CF2 disk, and 
that the PUT2PROD copied the files from the CF2 to the CF1.   
Too bad the messages don't include the names of the files copied (or just 
say "Copying ALL files..."), and information from QUERY MDISK CF1 LOCATION 
and CF2, like: 
TargetID Tdev OwnerID  Odev Dtype Vol-ID Rdev   StartLoc   Size 
MAINT0CF1 MAINT0CF1 3390  VMR54I 6A40   2521120 
TargetID Tdev OwnerID  Odev Dtype Vol-ID Rdev   StartLoc   Size 
MAINT0CF2 MAINT0CF2 3390  VMR54I 6A40   2641120 
you would immediately know from and to where PUT2PROD did it's behind the 
scenes work at that date and time. 

Let us know how it works out. 

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


"George Henke/NYLIC"  

Sent by: "The IBM z/VM Operating System"  
10/14/2010 01:56 PM 

Please respond to
"The I

Re: REXX that verify what MINIDISK is a file

[Scott Rohling]

Yes - exactly what I did to test my code snippet.

You'll never be able to stop people from copying files to their A disk - and
making modifications - including removing any checks you make for an X disk,
etc.   Users can do an EXECDROP or EXECLOAD on their own - there's not many
good ways to stop a determined user from shooting themselves in the foot if
they want to.

Sergio - maybe the best answer to solve the root problem is to compile the
REXX code?People could still have old copies of CATAA .. but at least if
it's compiled, they can't make changes to the current code.

Scott Rohling

On Thu, Oct 14, 2010 at 3:45 PM, Michael Coffin wrote:

>  Just checking the filemode of the program will not guarantee that that it
> is running from MAINT 31A.If I:
>
>
>
> ACCESS 191 X
>
>
>
> Then execute CATAA with Parse Source in it, the Parse Source will show it
> is running from the mdisk accessed as X – but it’s my 191, not the MAINT
> 31A.
>
>
>
> Look into CP QUERY MDISK to verify that the disk accessed as X is MAINT
> 31A.
>
>
>
> -Mike
>
>
>
> *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On
> Behalf Of *Sergio Lima
> *Sent:* Thursday, October 14, 2010 5:17 PM
>
> *To:* IBMVM@LISTSERV.UARK.EDU
> *Subject:* Re: REXX that verify what MINIDISK is a file
>
>
>
> Hello Mike,
>
> Thanks very much from your good explanation.
>
> We need that the user execute our EXEC from a public dasd (Maint 31a),
> because, We try track who executed this, the date, the time, and another
> thinks, like Filename, Filetype, Filemode.
> This EXEC do a Compilation of programs here, and now, the people here, want
> have a little control about what was compiled, and others thinks.
>
> Thanks again, and Best Regards,
>
> Sergio
>
>  --
>
> Date: Thu, 14 Oct 2010 15:03:36 -0500
> From: mike.wal...@hewitt.com
> Subject: Re: REXX that verify what MINIDISK is a file
> To: IBMVM@LISTSERV.UARK.EDU
>
>
> It is pretty unusual to force an EXEC to execute from a specific disk.
>  About 98% of the time I do that is when running a common 'PROFCMS EXEC' in
> everybody's "PROFILE EXEC" - the "PROFCMS EXEC" complains when it is not
> executing from the Y-disk (or the our HAINST alternative to IBM's CMSINST
> NSS).  Also, a common "PROFILE XEDIT" complains of the same results (after
> it does some preliminary setup, it attempts to execute the user's  "userid
> XEDIT" macro).
>
> But if you really need to execute an exec from a specific disk, from my 20
> July 2009 post here:
> Check out Kent Fiala's "DIREXEC" on the IBM VM Download page:
> http://www.vm.ibm.com/download/packages/descript.cgi?DIREXEC
>
> That DIREXEC VMARC package should do exactly what you wish, and explains
> that the included FMEXEC is syntactically easier to use for minidisk
> files.
>
> But before you do that, please help us understand why you would want to do
> so.  There may be much better solutions yo meet your need.
>
> Mike Walter
> Aon Hewitt
> The opinions expressed herein are mine alone, not my employer's.
>
>   *"Sergio Lima" *
>
> Sent by: "The IBM z/VM Operating System"  10/14/2010
> 02:19 PM
>
> Please respond to
> "The IBM z/VM Operating System" 
>
>
>
>To
>
> IBMVM@LISTSERV.UARK.EDU
>
> cc
>
> Subject
>
> REXX that verify what MINIDISK is a file
>
>
>
>
>
>
> Hello List,
>
> We are changing a REXX here for that this EXEC execute only if reside on X
> acessed minidisk.
> So, try with STATE command without succesfull  and now try  with LISTFILE
> command.
> If execute like this :
>
> 9 *-* 'LISTFILE  cataa exec x (DATE STACK LIFO'
>   >>>   "LISTFILE  cataa exec x (DATE STACK LIFO"
>10 *-* if rc = 0
>   >>>   "1"
>   *-*  then
>   *-*  do
>11 *-*   pull x1 x2 x3 .
>   >>> "CATAA"
>   >>> "EXEC"
>   >>> "X2"
>   >.> "V 83506  4 10/14/10 15:03:32"
>12 *-*   say x1
>   >>> "CATAA"
> CATAA
>13 *-*   say x2
>   >>> "EXEC"
> EXEC
>14 *-*   say x3
>   >>> "X2"
> X2
>15 *-*   exit
>
> But, when try execute with filemode *, lookslike the program go to a
> LOOPING :
>
> 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
>10 *-* if rc = 0
>   >>>   "1"
>   *-*  then
>   *-*  do
>11 *-*   pull x1 x2 x3 .
>   >>> "CATAA"
>   >>> "EXEC"
>   >>> "X2"
>   >.> "V 83506  4 10/14/10 15:03:32"
>12 *-*   say x1
>   >>> "CATAA"
> CATAA
>13 *-*   say x2
>   >>> "EXEC"
> EXEC
>14 *-*   say x3
>   >>> "X2"
> X2
>15 *-*   exit
> 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
>10 *-* if rc = 0
>   >>>   "1"
>   *-*  then
>   *-*  do
>11 *-*   pull x1 x2 x3 .
>   >>> "CATAA"
>   >>> "EXEC"
>
> The command in the line show this :
>
> listfile cataa 

Oct.20 Webcast - Intro to SCSI over FCP for Linux on System z - 9:00 AM EDT or 2:00 PM EDT

[Pamela Christina in rainy Endicott NY]

Cross-posted to IBMVM, LINUX390, and IBMMAIN for
the Linux on the mainframe enthusiasts out there.

The next LVC / IBM Linux WebCast is scheduled for Wed. Oct. 20

Register to listen
http://www.vm.ibm.com/education/lvc/

   Date:Wednesday October 20, 2010

   Times:   Choice of two live calls: 9:00AM or 2:00PM EDT
(A replay is planned to be available a few days after the live call.)

   Title:   Introduction to SCSI over FCP for Linux on System z

 Speaker:   Christof Schmitt, IBM Boeblingen Programming Laboratory

Duration:  75 minutes

Abstract:   SCSI over FCP is an open, standard-based alternative and
supplement to existing ESCON or FICON I/O connections.
This session will provide an introduction to the storage
attachment via the SCSI over FCP protocol. It includes setup
considerations,related features in Linux on System z and
troubleshooting basics.

Registration info and Details are in the PDF invitation:
  http://www.vm.ibm.com/education/lvc/lvc1020l.pdf
or just visit this web page.
http://www.vm.ibm.com/education/lvc/


Please direct any questions to Julie Liesenfelt at jul...@us.ibm.com.


Regards, Pam C

Re: Applied RSU but CPLEVEL is unchanged

[George Henke/NYLIC]

My HCPCPE AUXVM file shows 0802

My SHOPZ order has Stacked 5407 and PTF UM97540.

I saw PTFs go on, but I can't explain the AUXVM contents.




Mike Walter  
Sent by: The IBM z/VM Operating System 
10/14/2010 03:37 PM
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Applied RSU but CPLEVEL is unchanged







George, 

RSU0802 is from "5402RSU Stacked Product RSU -  December  12, 2008". 

Does CP Query CPLOAD show the sysres from which you expected to IPL? 
(Again, a good reason to not use the save volser on different real device 
addresses, aka UCB's).  If not, don't blame the service, it would be time 
to figure out what went wrong in your maintenance process between your 
production and new DDR'ed 2nd level systems. 

Can you provide the exact APAR or PTF number that you actually ordered? 

To find the most current z/VM PTF, always search for APAR UM97vr0 (where 
v=version, and r=release). 
For example for z/VM 5.4 you'd check out UM97540, and for z/VM 6.1 it 
would be UM97610. 

The RSU display by Q CPLEVEL is updated with each RSU into HPCCPE.  You 
might want to enter: 
VMFSETUP ZVM CP 
then 
FILELIST HCPCPE * * 
See what's in the HCPCPR AUXVM file.  If it shows the PTF for RSU1002, 
then it's time to find out where the CPLOAD MODULE was written. 
For clues, browse the " $VMFP2P  $MSGLOG  A1" file.  The most recent 
udpates are at the top, going back through history downward through the 
file. 
Ours shows: 
-- 
ST:HCPZAC6730I CPRELEASE request for disk A completed. 

ST:VMFP2P2204I Linking MAINT CF1 as 1FFF with the link mode M 
ST:DMSACP723I X (CF2) R/O 
ST:VMFP2P1231I Copying files from the Secondary Parm disk to the Primary   

ST:Parm disk   

ST:HCPZAC6732I CPACCESS request for MAINT's 0CF1 in mode A completed. 
-- 

That implies that the VMFBLD wrote to CPLOAD MODULE to the CF2 disk, and 
that the PUT2PROD copied the files from the CF2 to the CF1.   
Too bad the messages don't include the names of the files copied (or just 
say "Copying ALL files..."), and information from QUERY MDISK CF1 LOCATION 
and CF2, like: 
TargetID Tdev OwnerID  Odev Dtype Vol-ID Rdev   StartLoc   Size 
MAINT0CF1 MAINT0CF1 3390  VMR54I 6A40   2521120 
TargetID Tdev OwnerID  Odev Dtype Vol-ID Rdev   StartLoc   Size 
MAINT0CF2 MAINT0CF2 3390  VMR54I 6A40   2641120 
you would immediately know from and to where PUT2PROD did it's behind the 
scenes work at that date and time. 

Let us know how it works out. 

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


"George Henke/NYLIC"  

Sent by: "The IBM z/VM Operating System"  
10/14/2010 01:56 PM 

Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU 
cc

Subject
Applied RSU but CPLEVEL is unchanged









I ordered RSU 1002 from SHOPZ,IBMVM@LISTSERV.UARK.EDU or so I thought. 

SHOPZ called it RSU5407 when it gave me the download. 

Applied 35 PTFs, others were already on, PUT2PROD, and IPLed. 

But CPLEVEL still shows 0802: 

q cplevel 
z/VM Version 5 Release 4.0, service level 0802 (64-bit)   
Generated at 10/14/10 12:05:41 EDT 
IPL at 10/14/10 14:40:34 EDT 

Any ideas? 

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: REXX that verify what MINIDISK is a file

[Mike Walter]

Sergio,

If you are saying that you ONLY want this exec to execute from the
MAINT 31A disk accessed as the X-disk, then get rid of the LISTFILE
code.  There's no reason for it, at least no reason from what you've
shared so far.  CMS will always execute the EXEC in the standard
CMS Search Order.  For more detail, see the "CMS User's Guide", 
for "CMS Command Search Order"; page 172 of the manual SC24-6079-00).

Just start the exec with something like (using some of our standard
"new rexx code" template) pasted below.  Admittedly, it may be a
bit "over engineered", but I get the feeling that you may be a bit
new to z/VM, and rexx coding.  This template and some of the examples
can be considered a bit of hand-learned experience share by your
new z/VM friends.

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

/* Prolog; See Epilog for additional information 
 * Exec Name - CATAAEXEC*
 * Support   - Sergio   *
 * Status- Version 1, Release 1.0   *
 /

   address 'COMMAND'
   parse source xos xct xfn xft xfm xcmd xenvir .
   parse upper arg parms 1 operands '(' options ')' parmrest

   hi='1DE8'x   /* 3270 Hilite Char */
   lo='1D60'x   /* 3270 Default Char*/
/* Signal ON Syntax */
/* Signal ON NoValue */
/* Signal ON ERROR */
   If parms='?' then Signal Explain

   parse var xfm L1xfm 2 .   /* Faster than left(xfm,1) */

   If L1xfm<>'X' then/* Easy test first, quick exit */ 
  Call WrongDisk

  'PIPE (NAME GetOwner)' , /* More extensive test for MAINT 31A */
 '| COMMAND QUERY DISK' xfm ,
 '| DROP 1' , /* Drop title */
 '| SPECS /QUERY MDISK/ 1' ,   /* Building command: QUERY MDISK */
 'WORD 2 NEXTWORD' ,   /*   append: vdev*/
 '| CP' ,  /* Execute: CP QUERY MDISK vdev  */
 '| DROP 1' , /* Drop title */
 '| SPECS WORD 3.2 1' ,/* Keep: OwnerID vdev*/
 '| VAR ownerinfo'

   parse var ownerinfo ownerid ownervdev .
   If ownerid<>'MAINT' & ownervdev<>'031A' then
  Call WrongDisk

   ... insert all your processing here ...

Call Exit rc


//
/*   Sub-Routines below this point  */
//

Exit:
   parse arg exitrc todo
   If todo='?' then say 'For more help, enter:' xfn '?'
   If verify(exitrc,'-0123456789')>0 then Exit 99
Exit exitrc


WrongDisk:
  say xfn xfm 'is not executing from the disk X-031A location.'
  say 'Execution was aborted before processing began.'
  say 'Please ERASE or RENAME your "'xfn xft xfm'" file' ,
  'before trying again.'
  Call Exit 99
Return  /* "Return" not really needed, but brackets the sub-rtn */



Explain:
  'PIPE (NAME Explain)' ,
 '| <' xfn xft xfm ,
 '| INSIDE /ExplainBegin:/ /ExplainEnd:/' ,
 '| PREFACE STRLITERAL /'xfn xft xfm 'help.../' ,
 '| CONSOLE'
   Call Exit 0
/*
ExplainBegin:

===> Place command description and syntax here, between
===> lines beginning with "ExplainBegin:" and "ExplainEnd:"
===> A sample "railroad-style" syntax is shown below.

+-default operands--+
>>-Cmdname--+---+--+---+-
+-optional operands-+  +-(-| Options |-+---+
   +-)-+

|-Options-|


ExplainEnd:
*/

/* Epilog ***
 * Function  -  *
 * Component of  -  *
 * Command format-  *
 * Called by -  *
 * Dependencies  - CATAA EXEC X (not on any other disk, only 'X')   *
 * Program Lang. - CMS REXX *
 * Return Codes  - 0, Successful completion *
 * 4, Help requested or no operands entered.*
 * 8, Command operands not entered properly, failed.*
 *12, Unexpected condition found, failed.   *
 *20, Internal logic error in command, failed.  *
 *99, Running from disk other than X.   *
 * Date Written  - mmdd *
 * Author- First M. Last*
 * Author- First M. Last*
 * Changed | By  | Description of Change*
 * +-+

Re: REXX that verify what MINIDISK is a file

[Michael Coffin]

Just checking the filemode of the program will not guarantee that that it is
running from MAINT 31A.If I:

 

ACCESS 191 X

 

Then execute CATAA with Parse Source in it, the Parse Source will show it is
running from the mdisk accessed as X - but it's my 191, not the MAINT 31A.

 

Look into CP QUERY MDISK to verify that the disk accessed as X is MAINT 31A.

 

-Mike

 

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Sergio Lima
Sent: Thursday, October 14, 2010 5:17 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: REXX that verify what MINIDISK is a file

 

Hello Mike,
 
Thanks very much from your good explanation.
 
We need that the user execute our EXEC from a public dasd (Maint 31a),
because, We try track who executed this, the date, the time, and another
thinks, like Filename, Filetype, Filemode.
This EXEC do a Compilation of programs here, and now, the people here, want
have a little control about what was compiled, and others thinks.
 
Thanks again, and Best Regards,
 
Sergio
 

  _  

Date: Thu, 14 Oct 2010 15:03:36 -0500
From: mike.wal...@hewitt.com
Subject: Re: REXX that verify what MINIDISK is a file
To: IBMVM@LISTSERV.UARK.EDU


It is pretty unusual to force an EXEC to execute from a specific disk.
About 98% of the time I do that is when running a common 'PROFCMS EXEC' in
everybody's "PROFILE EXEC" - the "PROFCMS EXEC" complains when it is not
executing from the Y-disk (or the our HAINST alternative to IBM's CMSINST
NSS).  Also, a common "PROFILE XEDIT" complains of the same results (after
it does some preliminary setup, it attempts to execute the user's  "userid
XEDIT" macro). 

But if you really need to execute an exec from a specific disk, from my 20
July 2009 post here: 
Check out Kent Fiala's "DIREXEC" on the IBM VM Download page:
 
http://www.vm.ibm.com/download/packages/descript.cgi?DIREXEC

That DIREXEC VMARC package should do exactly what you wish, and explains 
that the included FMEXEC is syntactically easier to use for minidisk 
files.

But before you do that, please help us understand why you would want to do
so.  There may be much better solutions yo meet your need. 

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




"Sergio Lima"  

Sent by: "The IBM z/VM Operating System" 
10/14/2010 02:19 PM 


Please respond to
"The IBM z/VM Operating System" 






To

IBMVM@LISTSERV.UARK.EDU 


cc



Subject

REXX that verify what MINIDISK is a file

 






Hello List,

We are changing a REXX here for that this EXEC execute only if reside on X
acessed minidisk.
So, try with STATE command without succesfull  and now try  with LISTFILE
command.
If execute like this :

9 *-* 'LISTFILE  cataa exec x (DATE STACK LIFO'   
  >>>   "LISTFILE  cataa exec x (DATE STACK LIFO" 
   10 *-* if rc = 0   
  >>>   "1"   
  *-*  then   
  *-*  do 
   11 *-*   pull x1 x2 x3 .   
  >>> "CATAA" 
  >>> "EXEC"  
  >>> "X2"
  >.> "V 83506  4 10/14/10 15:03:32"  
   12 *-*   say x1
  >>> "CATAA" 
CATAA  
   13 *-*   say x2
  >>> "EXEC"  
EXEC   
   14 *-*   say x3
  >>> "X2"
X2 
   15 *-*   exit  

But, when try execute with filemode *, lookslike the program go to a LOOPING
:

9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
  >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
   10 *-* if rc = 0   
  >>>   "1"   
  *-*  then   
  *-*  do 
   11 *-*   pull x1 x2 x3 .   
  >>> "CATAA" 
  >>> "EXEC" 

Re: REXX that verify what MINIDISK is a file

[Scott Rohling]

Ah - good catch!   The EXEC is exiting, but the stacked output from LISTFILE
causes it to execute again..

So:

'MAKEBUF'
buf = rc
'LISTFILE  cataa exec * (DATE STACK LIFO'

 Parse Source . . x1 x2 x3 .
 If left(x3,1) <> 'X' Then Do
   Say 'You are not executing from the X disk!'
   'DROPBUF' buf
   Exit 99
 End

A little different then doing a DESBUF - but friendlier and the same
effect...

I'm not real sure why your are doing the LISTFILE anymore though...   The
Parse Source is all you need to know the EXEC didn't execute from the X
disk.

Scott Rohling

On Thu, Oct 14, 2010 at 3:33 PM, Hughes, Jim  wrote:

>  You need to issue a DESBUF command before the EXIT 99 statement.
>
>
>
> The LISTFILE command is putting the EXECNAME is the program/console stack
> and being read after your problem exits.  CMS reads it and starts executing
> it again and again,
>
>
>
> 
>
> Jim Hughes
>
> 603-271-5586
>
> "It is fun to do the impossible."
>   --
>
> *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On
> Behalf Of *Sergio Lima
> *Sent:* Thursday, October 14, 2010 5:25 PM
>
> *To:* IBMVM@LISTSERV.UARK.EDU
> *Subject:* Re: REXX that verify what MINIDISK is a file
>
>
>
> Scott,
>
> Sorry about disturb, but still don't run, look please :
>
> The code :
>
>  trace r
>  'LISTFILE  cataa exec * (DATE STACK LIFO'
>
>  Parse Source . . x1 x2 x3 .
>  If left(x3,1) <> 'X' Then Do
>Say 'You are not executing from the X disk!'
>Exit 99
>  End
>
> The result :
>
>  3 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
>  5 *-* Parse Source . . x1 x2 x3 .
>>.>   "CMS"
>>.>   "COMMAND"
>>>>   "VX"
>>>>   "EXEC"
>>>>   "A1"
>>.>   "VX CMS"
>  6 *-* If left(x3,1) <> 'X'
>>>>   "1"
>*-*  Then
>*-*  Do
>  7 *-*   Say 'You are not executing from the X disk!'
>>>> "You are not executing from the X disk!"
> You are not executing from the X disk!
>  8 *-*   Exit 99
>>>> "99"
>  8 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
> 10 *-* Parse Source . . x1 x2 x3 .
>>.>   "CMS"
>>.>   "COMMAND"
>>>>   "CATAA"
>>>>   "EXEC"
>>>>   "A2"
>>.>   "CATAA CMS"
> 11 *-* If left(x3,1) <> 'X'
>>>>   "1"
>*-*  Then
>
> HOL
>*-*  Do
> 12 *-*   Say 'You are not executing from the X disk!'
>>>> "You are not executing from the X disk!"
> You are not executing from the X disk!
> 13 *-*   Exit 99
>>>> "99"
>  8 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
> 10 *-* Parse Source . . x1 x2 x3 .
>>.>   "CMS"
>>.>   "COMMAND"
>>>>   "CATAA"
>>>>   "EXEC"
>>>>   "A2"
>>.>   "CATAA CMS"
> 11 *-* If left(x3,1) <> 'X'
>>>>   "1"
>*-*  Then
>*-*  Do
> 12 *-*   Say 'You are not executing from the X disk!'
>>>> "You are not executing from the X disk!"
> You are not executing from the X disk!
> 13 *-*   Exit 99
>>>> "99"
>  8 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
> 10 *-* Parse Source . . x1 x2 x3 .
>>.>   "CMS"
>>.>   "COMMAND"
>>>>   "CATAA"
>
>
>
> Loop again,
>
> Thanks,
>
> Sergio
>
>  --
>
> Date: Thu, 14 Oct 2010 14:48:09 -0600
> From: scott.rohl...@gmail.com
> Subject: Re: REXX that verify what MINIDISK is a file
> To: IBMVM@LISTSERV.UARK.EDU
>
> Yes - I corrected this in another post - you only want the first character
> of the filemode - or it will never be just X:
>
> Parse Source . . x1 x2 x3 .
> If left(x3,1) <> 'X' Then Do
>   Say 'You are not executing from the X disk!'
>   Exit 99
> End
>
> Note the 2nd line now has left(x3,1) to only look at the first character.
> This is because the filemode is actually X1 or X2, etc.
>
> Scott Rohling
>
> On Thu, Oct 14, 2010 at 2:22 PM, Sergio Lima 
> wrote:
>
> Hello,
>
> Thanks from your help.
>
> This code :
>
> trace r
>
> 'LISTFILE  cataa exec * (DATE STACK LIFO'
>
>
> Parse Source . . x1 x2 x3 .
> If x3 <> 'X' Then Do
>   Say 'You are not executing from the X disk!'
>   Exit 99
> End
>
>
>
> Also do a loop, look please :
>
>
>  8 *-* 'LISTFILE  cataa exec *
> (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
>
> 10 *-* Parse Source . . x1 x2 x3 .
>>.>   "CMS"
>>.>   "COMMAND"
>>>>   "CATAA"
>>>>   "EXEC"
>>>>   "A2"
>>.>   "CATAA CMS"
> 11 *-* If x3 <> 'X'
>>>>   "1"
>*-*  Then
>*-*  Do
> 12 *-*

Re: REXX that verify what MINIDISK is a file

[Scott Rohling]

When the 'Exit 99' is executed - the EXEC will be terminated --

So if this is looping - you must be calling it again from another EXEC.
There is no possible way for the code you listed to loop.

Scott Rohling

On Thu, Oct 14, 2010 at 3:25 PM, Sergio Lima wrote:

>  Scott,
>
> Sorry about disturb, but still don't run, look please :
>
> The code :
>
>
>  trace r
>  'LISTFILE  cataa exec * (DATE STACK LIFO'
>
>  Parse Source . . x1 x2 x3 .
>  If left(x3,1) <> 'X' Then Do
>Say 'You are not executing from the X disk!'
>Exit 99
>  End
>
> The result :
>
>
>  3 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
>  5 *-* Parse Source . . x1 x2 x3 .
>>.>   "CMS"
>>.>   "COMMAND"
>>>>   "VX"
>>>>   "EXEC"
>>>>   "A1"
>>.>   "VX CMS"
>  6 *-* If left(x3,1) <> 'X'
>>>>   "1"
>*-*  Then
>*-*  Do
>  7 *-*   Say 'You are not executing from the X disk!'
>>>> "You are not executing from the X disk!"
> You are not executing from the X disk!
>  8 *-*   Exit 99
>>>> "99"
>  8 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
> 10 *-* Parse Source . . x1 x2 x3 .
>>.>   "CMS"
>>.>   "COMMAND"
>>>>   "CATAA"
>>>>   "EXEC"
>>>>   "A2"
>>.>   "CATAA CMS"
> 11 *-* If left(x3,1) <> 'X'
>>>>   "1"
>*-*  Then
>
> HOL
>
>*-*  Do
> 12 *-*   Say 'You are not executing from the X disk!'
>>>> "You are not executing from the X disk!"
> You are not executing from the X disk!
> 13 *-*   Exit 99
>>>> "99"
>  8 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
> 10 *-* Parse Source . . x1 x2 x3 .
>>.>   "CMS"
>>.>   "COMMAND"
>>>>   "CATAA"
>>>>   "EXEC"
>>>>   "A2"
>>.>   "CATAA CMS"
> 11 *-* If left(x3,1) <> 'X'
>>>>   "1"
>*-*  Then
>*-*  Do
> 12 *-*   Say 'You are not executing from the X disk!'
>>>> "You are not executing from the X disk!"
> You are not executing from the X disk!
> 13 *-*   Exit 99
>>>> "99"
>  8 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
> 10 *-* Parse Source . . x1 x2 x3 .
>>.>   "CMS"
>>.>   "COMMAND"
>>>>   "CATAA"
>
>
>
> Loop again,
>
> Thanks,
>
> Sergio
>
> --
> Date: Thu, 14 Oct 2010 14:48:09 -0600
>
> From: scott.rohl...@gmail.com
> Subject: Re: REXX that verify what MINIDISK is a file
> To: IBMVM@LISTSERV.UARK.EDU
>
> Yes - I corrected this in another post - you only want the first character
> of the filemode - or it will never be just X:
>
> Parse Source . . x1 x2 x3 .
> If left(x3,1) <> 'X' Then Do
>   Say 'You are not executing from the X disk!'
>   Exit 99
> End
>
> Note the 2nd line now has left(x3,1) to only look at the first character.
> This is because the filemode is actually X1 or X2, etc.
>
> Scott Rohling
>
> On Thu, Oct 14, 2010 at 2:22 PM, Sergio Lima wrote:
>
> Hello,
>
> Thanks from your help.
>
> This code :
>
> trace r
> 'LISTFILE  cataa exec * (DATE STACK LIFO'
>
> Parse Source . . x1 x2 x3 .
> If x3 <> 'X' Then Do
>   Say 'You are not executing from the X disk!'
>   Exit 99
> End
>
>
> Also do a loop, look please :
>
>  8 *-* 'LISTFILE  cataa exec *
> (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
> 10 *-* Parse Source . . x1 x2 x3 .
>>.>   "CMS"
>>.>   "COMMAND"
>>>>   "CATAA"
>>>>   "EXEC"
>>>>   "A2"
>>.>   "CATAA CMS"
> 11 *-* If x3 <> 'X'
>>>>   "1"
>*-*  Then
>*-*  Do
> 12 *-*   Say 'You are not executing from the X disk!'
>
>>>> "You are not executing from the X disk!"
> You are not executing from the X disk!
> 13 *-*   Exit 99
>>>> "99"
>  8 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
> 10 *-* Parse Source . . x1 x2 x3 .
>>.>   "CMS"
>>.>   "COMMAND"
>>>>   "CATAA"
>>>>   "EXEC"
>>>>   "A2"
>>.>   "CATAA CMS"
> 11 *-* If x3 <> 'X'
>>>>   "1"
>*-*  Then
>
>
> Any mistake here ?
>
> Sergio
>
>
>
>
> --
> Date: Thu, 14 Oct 2010 13:34:28 -0600
> From: scott.rohl...@gmail.com
> Subject: Re: REXX that verify what MINIDISK is a file
>
> To: IBMVM@LISTSERV.UARK.EDU
>
>  Parse Source . . x1 x2 x3 .
> If x3 <> 'X' Then Do
>   Say 'You are not executing from the X disk!'
>   Exit 99
> End
>
> Scott Rohling
>
>
> On Thu, Oct 14, 2010 at 1:19 PM, Sergio Lima wrote:
>
> Hello 

Re: REXX that verify what MINIDISK is a file

[Sergio Lima]

Hello Jim,
 
Tested, run very well,
 
Thanks very much, and Best Regards,
 
Sergio
 


Date: Thu, 14 Oct 2010 16:05:42 -0400
From: jim.hug...@doit.nh.gov
Subject: Re: REXX that verify what MINIDISK is a file
To: IBMVM@LISTSERV.UARK.EDU










 A better method would be to verify the EXEC is on the X disk.  Once verified, 
EXECLOAD this exec and then run it. Before exiting, EXECDROP it.
 
Sample using TEXTME EXEC C as the exec in question.  I have one on my A disk 
and another different exec named TESTME EXEC on my C disk.  Here is the one on 
my A disk.
 
/*  */
 
"State TESTME EXEC C"
if rc <> 0 Then exit rc
 
"EXECLOAD TESTME EXEC C  TESTME EXEC"
 
"EXEC TESTME "
 
"EXECDROP TESTME EXEC"
 
return rc
 
 


Jim Hughes
603-271-5586
"It is fun to do the impossible."




From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Sergio Lima
Sent: Thursday, October 14, 2010 3:19 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: REXX that verify what MINIDISK is a file
 
Hello List,
 
We are changing a REXX here for that this EXEC execute only if reside on X 
acessed minidisk.
So, try with STATE command without succesfull  and now try  with LISTFILE 
command.
If execute like this :
 
 9 *-* 'LISTFILE  cataa exec x (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec x (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   >>> "X2"
   >.> "V 83506  4 10/14/10 15:03:32"  
12 *-*   say x1
   >>> "CATAA" 
CATAA  
13 *-*   say x2
   >>> "EXEC"  
EXEC   
14 *-*   say x3
   >>> "X2"
X2 
15 *-*   exit  
 
But, when try execute with filemode *, lookslike the program go to a LOOPING :
 
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   >>> "X2"
   >.> "V 83506  4 10/14/10 15:03:32"  
12 *-*   say x1
   >>> "CATAA" 
CATAA  
13 *-*   say x2
   >>> "EXEC"  
EXEC   
14 *-*   say x3
   >>> "X2"
X2 
15 *-*   exit  
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
 

Re: REXX that verify what MINIDISK is a file

[Sergio Lima]

Hello Mike,
 
Thanks very much from your good explanation.
 
We need that the user execute our EXEC from a public dasd (Maint 31a), because, 
We try track who executed this, the date, the time, and another thinks, like 
Filename, Filetype, Filemode.
This EXEC do a Compilation of programs here, and now, the people here, want 
have a little control about what was compiled, and others thinks.
 
Thanks again, and Best Regards,
 
Sergio
 


Date: Thu, 14 Oct 2010 15:03:36 -0500
From: mike.wal...@hewitt.com
Subject: Re: REXX that verify what MINIDISK is a file
To: IBMVM@LISTSERV.UARK.EDU


It is pretty unusual to force an EXEC to execute from a specific disk.  About 
98% of the time I do that is when running a common 'PROFCMS EXEC' in 
everybody's "PROFILE EXEC" - the "PROFCMS EXEC" complains when it is not 
executing from the Y-disk (or the our HAINST alternative to IBM's CMSINST NSS). 
 Also, a common "PROFILE XEDIT" complains of the same results (after it does 
some preliminary setup, it attempts to execute the user's  "userid XEDIT" 
macro). 

But if you really need to execute an exec from a specific disk, from my 20 July 
2009 post here: 
Check out Kent Fiala's "DIREXEC" on the IBM VM Download page:
http://www.vm.ibm.com/download/packages/descript.cgi?DIREXEC

That DIREXEC VMARC package should do exactly what you wish, and explains 
that the included FMEXEC is syntactically easier to use for minidisk 
files.

But before you do that, please help us understand why you would want to do so.  
There may be much better solutions yo meet your need. 

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






"Sergio Lima"  

Sent by: "The IBM z/VM Operating System"  
10/14/2010 02:19 PM 




Please respond to
"The IBM z/VM Operating System" 







To
IBMVM@LISTSERV.UARK.EDU 


cc



Subject
REXX that verify what MINIDISK is a file









Hello List,

We are changing a REXX here for that this EXEC execute only if reside on X 
acessed minidisk.
So, try with STATE command without succesfull  and now try  with LISTFILE 
command.
If execute like this :

9 *-* 'LISTFILE  cataa exec x (DATE STACK LIFO'   
  >>>   "LISTFILE  cataa exec x (DATE STACK LIFO" 
   10 *-* if rc = 0   
  >>>   "1"   
  *-*  then   
  *-*  do 
   11 *-*   pull x1 x2 x3 .   
  >>> "CATAA" 
  >>> "EXEC"  
  >>> "X2"
  >.> "V 83506  4 10/14/10 15:03:32"  
   12 *-*   say x1
  >>> "CATAA" 
CATAA  
   13 *-*   say x2
  >>> "EXEC"  
EXEC   
   14 *-*   say x3
  >>> "X2"
X2 
   15 *-*   exit  

But, when try execute with filemode *, lookslike the program go to a LOOPING :

9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
  >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
   10 *-* if rc = 0   
  >>>   "1"   
  *-*  then   
  *-*  do 
   11 *-*   pull x1 x2 x3 .   
  >>> "CATAA" 
  >>> "EXEC"  
  >>> "X2"
  >.> "V 83506  4 10/14/10 15:03:32"  
   12 *-*   say x1
  >>> "CATAA" 
CATAA  
   13 *-*   say x2
  >>> "EXEC"  
EXEC   
   14 *-*   say x3
  >>> "X2" 

Re: EREP dump readout for MCIC

[David Boyes]

On 10/14/10 4:52 PM, "Carlos Bodra - Pessoal"  wrote:

>  We are running z/vm 4.40 over MP3000 (soon z10 BC), but until there, I need
> to discover what means External Damage in MCIC code.

External damage means that the processor microcode LIC file loaded during
system startup is corrupted in some way and that the internal checking of
the parts of that file failed, but since it was able to correct the problem
and keep running, it appears to be only a partial failure. I've also seen
this problem caused by a faulty control store memory chip in the CPC.

Either case, what you need to do is call your field CE RIGHT NOW before the
disk and/or control store hardware completely fails and have him/her get a
backup of the customer data and configuration data, then run the CE CPC
diagnostics on the CPC cards.

You're looking at an immanent hardware failure that will be hard (or at
least VERY time-consuming) to fix if you don't get a good backup ASAP.

=- db

EREP dump readout for MCIC

[Carlos Bodra - Pessoal]

 Hi listners.

I was checking erep output to try to discover more about MCIC (Machine 
Check Interruption Code) and found following register,
but I checked 02 Erep manuals, (User´s Guide Manual and Reference 
Manual), but can´t found any description how to readout these

little dump.

We are running z/vm 4.40 over MP3000 (soon z10 BC), but until there, I 
need to discover what means External Damage in MCIC code.


If I remember in the past, we had some manuals called "Logic Manuals", 
but I can´t located it for Erep.
If anyone can tell me where I can found documentation about these dump, 
I will say Thank You!




MODEL-7060  SERIAL NO-  071002
--- RECORD ENTRY SOURCE - MCH
 VM/ESAV4 R0
   DAY YEAR   HH MM SS.TH
DATE-  285  10 TIME-  03 52 06 78

PROGRAM IDENTITY-   @
JOB IDENTITY-
OLD MACHINE CHECK PSW - 03 3C 00 00 80 21 09 14

   HEX DUMP OF RECORD
   HEADER107018000010285F03520678
170710027060027C

 033C80210914

   0030  04000F3D40030004

   0050  

   0070  

   0090  
4040404040404040
   00B0  40404040404040404040404040404040
40404040404040404000000F
   00D0  0009D3800304
00D65B862C205000
   00F0  20001000002107F08000
800014B1EE40004DB07F
   0110  5B9D30805B9D3040
C8005B662124
   0130  5BA2E7615B860101
1F00
   0150  

   0170  

   0190  

   01B0  

   01D0  

   01F0  

   0210  

   0230  

   0250  

   0270  0037
00010400004000C07FFE74B4
   0290  716508C0C6B73AF49CF658C004000F3D
40038000C6B725338021091404000F3D
   02B0  40038000C6B72559802108E404000F3D
40038100C6B72E838019244204000F3D
   02D0  40038000C6B731CA8021091404000F3D
40038000C6B73AF480210914

   02F0  
RECORD TYPE - 10
--

Carlos Bodra
IBM zSeries Certified Specialist
Sao Paulo - Brazil

Re: REXX that verify what MINIDISK is a file

[Scott Rohling]

Yes - I corrected this in another post - you only want the first character
of the filemode - or it will never be just X:

Parse Source . . x1 x2 x3 .
If left(x3,1) <> 'X' Then Do
  Say 'You are not executing from the X disk!'
  Exit 99
End

Note the 2nd line now has left(x3,1) to only look at the first character.
This is because the filemode is actually X1 or X2, etc.

Scott Rohling

On Thu, Oct 14, 2010 at 2:22 PM, Sergio Lima wrote:

>  Hello,
>
> Thanks from your help.
>
> This code :
>
> trace r
> 'LISTFILE  cataa exec * (DATE STACK LIFO'
>
> Parse Source . . x1 x2 x3 .
> If x3 <> 'X' Then Do
>   Say 'You are not executing from the X disk!'
>   Exit 99
> End
>
>
> Also do a loop, look please :
>
>  8 *-* 'LISTFILE  cataa exec *
> (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
> 10 *-* Parse Source . . x1 x2 x3 .
>>.>   "CMS"
>>.>   "COMMAND"
>>>>   "CATAA"
>>>>   "EXEC"
>>>>   "A2"
>>.>   "CATAA CMS"
> 11 *-* If x3 <> 'X'
>>>>   "1"
>*-*  Then
>*-*  Do
> 12 *-*   Say 'You are not executing from the X disk!'
>
>>>> "You are not executing from the X disk!"
> You are not executing from the X disk!
> 13 *-*   Exit 99
>>>> "99"
>  8 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
> 10 *-* Parse Source . . x1 x2 x3 .
>>.>   "CMS"
>>.>   "COMMAND"
>>>>   "CATAA"
>>>>   "EXEC"
>>>>   "A2"
>>.>   "CATAA CMS"
> 11 *-* If x3 <> 'X'
>>>>   "1"
>*-*  Then
>
>
> Any mistake here ?
>
> Sergio
>
>
>
>
> --
> Date: Thu, 14 Oct 2010 13:34:28 -0600
> From: scott.rohl...@gmail.com
> Subject: Re: REXX that verify what MINIDISK is a file
>
> To: IBMVM@LISTSERV.UARK.EDU
>
> Parse Source . . x1 x2 x3 .
> If x3 <> 'X' Then Do
>   Say 'You are not executing from the X disk!'
>   Exit 99
> End
>
> Scott Rohling
>
>
> On Thu, Oct 14, 2010 at 1:19 PM, Sergio Lima wrote:
>
> Hello List,
>
> We are changing a REXX here for that this EXEC execute only if reside on X
> acessed minidisk.
> So, try with STATE command without succesfull  and now try  with LISTFILE
> command.
> If execute like this :
>
>  9 *-* 'LISTFILE  cataa exec x (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec x (DATE STACK LIFO"
> 10 *-* if rc = 0
>>>>   "1"
>*-*  then
>*-*  do
> 11 *-*   pull x1 x2 x3 .
>>>> "CATAA"
>>>> "EXEC"
>>>> "X2"
>>.> "V 83506  4 10/14/10 15:03:32"
> 12 *-*   say x1
>>>> "CATAA"
> CATAA
> 13 *-*   say x2
>>>> "EXEC"
> EXEC
> 14 *-*   say x3
>>>> "X2"
> X2
> 15 *-*   exit
>
> But, when try execute with filemode *, lookslike the program go to a
> LOOPING :
>
>  9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
> 10 *-* if rc = 0
>>>>   "1"
>*-*  then
>*-*  do
> 11 *-*   pull x1 x2 x3 .
>>>> "CATAA"
>>>> "EXEC"
>>>> "X2"
>>.> "V 83506  4 10/14/10 15:03:32"
> 12 *-*   say x1
>>>> "CATAA"
> CATAA
> 13 *-*   say x2
>>>> "EXEC"
> EXEC
> 14 *-*   say x3
>>>> "X2"
> X2
> 15 *-*   exit
>  9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
> 10 *-* if rc = 0
>>>>   "1"
>*-*  then
>*-*  do
> 11 *-*   pull x1 x2 x3 .
>>>> "CATAA"
>>>> "EXEC"
>
> The command in the line show this :
>
> listfile cataa exec *
> CATAAEXEC A2
> CATAAEXEC X2
> Ready; T=0.01/0.01 16:17:00
>
> Someone can help, how can verify if this EXEC is not running from X disk ?
>
> Thanks very much,
>
> Sergio Lima Costa
> Sao Paulo - Brazil
>
>
>

Re: REXX that verify what MINIDISK is a file

[Sergio Lima]

Hello,
 
Excellent idea, we consider this as well,

Thanks
 
Sergio

 


Date: Thu, 14 Oct 2010 15:34:19 -0400
From: brene...@us.ibm.com
Subject: Re: REXX that verify what MINIDISK is a file
To: IBMVM@LISTSERV.UARK.EDU


You might consider using MAKEBUF and DROPBUF around your code. You are stacking 
two lines of output when the file is on the A and the X disk. You pull one of 
them and leave the other on the stack. Since the second line is CATA EXEC X2, 
it will execute the CATA EXEC again, which will stack two lines, etc. Yes you 
have an infinite loop.

If you want to execute the EXEC only from the X disk regardless of its possible 
existence on another filemode, you can EXECLOAD the copy from the X disk and 
then execute it since execs in storage get priority over execs on disk. 
EXECLOAD allows you to specify the filemode. EXECLOAD fn ft fm. You can even 
EXECLOAD the exec as a different name. HELP EXECLOAD can help you if you choose 
to use it. 
pdb (Doug Breneman)
z/VM System Test IBM Endicott, NY

Sergio Lima ---10/14/2010 03:20:45 PM---Hello List,

From: Sergio Lima 
To: IBMVM@LISTSERV.UARK.EDU
Date: 10/14/2010 03:20 PM
Subject: REXX that verify what MINIDISK is a file
Sent by: The IBM z/VM Operating System 





Hello List,

We are changing a REXX here for that this EXEC execute only if reside on X 
acessed minidisk.
So, try with STATE command without succesfull and now try with LISTFILE command.
If execute like this :

9 *-* 'LISTFILE cataa exec x (DATE STACK LIFO' 
>>> "LISTFILE cataa exec x (DATE STACK LIFO" 
10 *-* if rc = 0 
>>> "1" 
*-* then 
*-* do 
11 *-* pull x1 x2 x3 . 
>>> "CATAA" 
>>> "EXEC" 
>>> "X2" 
>.> "V 83 506 4 10/14/10 15:03:32" 
12 *-* say x1 
>>> "CATAA" 
CATAA 
13 *-* say x2 
>>> "EXEC" 
EXEC 
14 *-* say x3 
>>> "X2" 
X2 
15 *-* exit 

But, when try execute with filemode *, lookslike the program go to a LOOPING :

9 *-* 'LISTFILE cataa exec * (DATE STACK LIFO' 
>>> "LISTFILE cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0 
>>> "1" 
*-* then 
*-* do 
11 *-* pull x1 x2 x3 . 
>>> "CATAA" 
>>> "EXEC" 
>>> "X2" 
>.> "V 83 506 4 10/14/10 15:03:32" 
12 *-* say x1 
>>> "CATAA" 
CATAA 
13 *-* say x2 
>>> "EXEC" 
EXEC 
14 *-* say x3 
>>> "X2" 
X2 
15 *-* exit 
9 *-* 'LISTFILE cataa exec * (DATE STACK LIFO' 
>>> "LISTFILE cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0 
>>> "1" 
*-* then 
*-* do 
11 *-* pull x1 x2 x3 . 
>>> "CATAA" 
>>> "EXEC" 

The command in the line show this :

listfile cataa exec * 
CATAA EXEC A2 
CATAA EXEC X2 
Ready; T=0.01/0.01 16:17:00 

Someone can help, how can verify if this EXEC is not running from X disk ?

Thanks very much,

Sergio Lima Costa
Sao Paulo - Brazil
  

Re: REXX that verify what MINIDISK is a file

[Sergio Lima]

Hello,
 
Thanks from your help.
 
This code :
 
trace r
'LISTFILE  cataa exec * (DATE STACK LIFO'  
   
Parse Source . . x1 x2 x3 .
If x3 <> 'X' Then Do   
  Say 'You are not executing from the X disk!' 
  Exit 99  
End
 
Also do a loop, look please :
 
 8 *-* 'LISTFILE  cataa exec * 
(DATE STACK LIFO' 
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO"   
10 *-* Parse Source . . x1 x2 x3 .   
   >.>   "CMS"   
   >.>   "COMMAND"   
   >>>   "CATAA" 
   >>>   "EXEC"  
   >>>   "A2"
   >.>   "CATAA CMS" 
11 *-* If x3 <> 'X'  
   >>>   "1" 
   *-*  Then 
   *-*  Do   
12 *-*   Say 'You are not executing from the X disk!'
   >>> "You are not executing from the X disk!"  
You are not executing from the X disk!   
13 *-*   Exit 99 
   >>> "99"  
 8 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO' 
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO"   
10 *-* Parse Source . . x1 x2 x3 .   
   >.>   "CMS"   
   >.>   "COMMAND"   
   >>>   "CATAA" 
   >>>   "EXEC"  
   >>>   "A2"
   >.>   "CATAA CMS" 
11 *-* If x3 <> 'X'  
   >>>   "1" 
   *-*  Then 
 
 
Any mistake here ?
 
Sergio
 
 

 


Date: Thu, 14 Oct 2010 13:34:28 -0600
From: scott.rohl...@gmail.com
Subject: Re: REXX that verify what MINIDISK is a file
To: IBMVM@LISTSERV.UARK.EDU

Parse Source . . x1 x2 x3 .
If x3 <> 'X' Then Do
  Say 'You are not executing from the X disk!'
  Exit 99
End

Scott Rohling



On Thu, Oct 14, 2010 at 1:19 PM, Sergio Lima  wrote:


Hello List,
 
We are changing a REXX here for that this EXEC execute only if reside on X 
acessed minidisk.
So, try with STATE command without succesfull  and now try  with LISTFILE 
command.
If execute like this :
 
 9 *-* 'LISTFILE  cataa exec x (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec x (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   >>> "X2"
   >.> "V 83506  4 10/14/10 15:03:32"  
12 *-*   say x1
   >>> "CATAA" 
CATAA  
13 *-*   say x2
   >>> "EXEC"  
EXEC   
14 *-*   say x3
   >>> "X2"
X2 
15 *-*   exit  
 
But, when try execute with filemode *, lookslike the program go to a LOOPING :
 
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA"  

Re: REXX that verify what MINIDISK is a file

[Hughes, Jim]

 A better method would be to verify the EXEC is on the X disk.  Once
verified, EXECLOAD this exec and then run it. Before exiting, EXECDROP
it.

 

Sample using TEXTME EXEC C as the exec in question.  I have one on my A
disk and another different exec named TESTME EXEC on my C disk.  Here is
the one on my A disk.

 

/*  */

 

"State TESTME EXEC C"

if rc <> 0 Then exit rc

 

"EXECLOAD TESTME EXEC C  TESTME EXEC"

 

"EXEC TESTME "

 

"EXECDROP TESTME EXEC"

 

return rc

 

 



Jim Hughes

603-271-5586

"It is fun to do the impossible."



From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Sergio Lima
Sent: Thursday, October 14, 2010 3:19 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: REXX that verify what MINIDISK is a file

 

Hello List,
 
We are changing a REXX here for that this EXEC execute only if reside on
X acessed minidisk.
So, try with STATE command without succesfull  and now try  with
LISTFILE command.
If execute like this :
 
 9 *-* 'LISTFILE  cataa exec x (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec x (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   >>> "X2"
   >.> "V 83506  4 10/14/10 15:03:32"  
12 *-*   say x1
   >>> "CATAA" 
CATAA  
13 *-*   say x2
   >>> "EXEC"  
EXEC   
14 *-*   say x3
   >>> "X2"
X2 
15 *-*   exit  
 
But, when try execute with filemode *, lookslike the program go to a
LOOPING :
 
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   >>> "X2"
   >.> "V 83506  4 10/14/10 15:03:32"  
12 *-*   say x1
   >>> "CATAA" 
CATAA  
13 *-*   say x2
   >>> "EXEC"  
EXEC   
14 *-*   say x3
   >>> "X2"
X2 
15 *-*   exit  
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   
The command in the line show this :
 
listfile cataa exec *
CATAAEXEC A2 
CATAAEXEC X2 
Ready; T=

Re: REXX that verify what MINIDISK is a file

[Frank M. Ramaekers]

Problem with that is the file mode contains the numeric designation:

 

/* */

  Parse source RexxResrc 

Say RexxResrc

 

 

CMS COMMAND REXXTEST EXEC A1 rexxtest CMS   

 

Frank M. Ramaekers Jr.

 

 



From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Scott Rohling
Sent: Thursday, October 14, 2010 2:34 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: REXX that verify what MINIDISK is a file

 

Parse Source . . x1 x2 x3 .
If x3 <> 'X' Then Do
  Say 'You are not executing from the X disk!'
  Exit 99
End

Scott Rohling



On Thu, Oct 14, 2010 at 1:19 PM, Sergio Lima 
wrote:

Hello List,
 
We are changing a REXX here for that this EXEC execute only if reside on
X acessed minidisk.
So, try with STATE command without succesfull  and now try  with
LISTFILE command.
If execute like this :
 
 9 *-* 'LISTFILE  cataa exec x (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec x (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   >>> "X2"
   >.> "V 83506  4 10/14/10 15:03:32"  
12 *-*   say x1
   >>> "CATAA" 
CATAA  
13 *-*   say x2
   >>> "EXEC"  
EXEC   
14 *-*   say x3
   >>> "X2"
X2 
15 *-*   exit  
 
But, when try execute with filemode *, lookslike the program go to a
LOOPING :
 
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   >>> "X2"
   >.> "V 83506  4 10/14/10 15:03:32"  
12 *-*   say x1
   >>> "CATAA" 
CATAA  
13 *-*   say x2
   >>> "EXEC"  
EXEC   
14 *-*   say x3
   >>> "X2"
X2 
15 *-*   exit  
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   
The command in the line show this :
 
listfile cataa exec *
CATAAEXEC A2 
CATAAEXEC X2 
Ready; T=0.01/0.01 16:17:00  
 
Someone can help, how can verify if this EXEC is not running from X disk
?
 
Thanks very much,
 
Sergio Lima Costa
Sao 

Re: REXX that verify what MINIDISK is a file

[Mike Walter]

It is pretty unusual to force an EXEC to execute from a specific disk. 
About 98% of the time I do that is when running a common 'PROFCMS EXEC' in 
everybody's "PROFILE EXEC" - the "PROFCMS EXEC" complains when it is not 
executing from the Y-disk (or the our HAINST alternative to IBM's CMSINST 
NSS).  Also, a common "PROFILE XEDIT" complains of the same results (after 
it does some preliminary setup, it attempts to execute the user's  "userid 
XEDIT" macro).

But if you really need to execute an exec from a specific disk, from my 20 
July 2009 post here:
Check out Kent Fiala's "DIREXEC" on the IBM VM Download page:
http://www.vm.ibm.com/download/packages/descript.cgi?DIREXEC

That DIREXEC VMARC package should do exactly what you wish, and explains 
that the included FMEXEC is syntactically easier to use for minidisk 
files.

But before you do that, please help us understand why you would want to do 
so.  There may be much better solutions yo meet your need.

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



"Sergio Lima"  

Sent by: "The IBM z/VM Operating System" 
10/14/2010 02:19 PM
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
REXX that verify what MINIDISK is a file






Hello List,
 
We are changing a REXX here for that this EXEC execute only if reside on X 
acessed minidisk.
So, try with STATE command without succesfull  and now try  with LISTFILE 
command.
If execute like this :
 
 9 *-* 'LISTFILE  cataa exec x (DATE STACK LIFO' 
   >>>   "LISTFILE  cataa exec x (DATE STACK LIFO" 
10 *-* if rc = 0 
   >>>   "1" 
   *-*  then 
   *-*  do 
11 *-*   pull x1 x2 x3 . 
   >>> "CATAA" 
   >>> "EXEC" 
   >>> "X2" 
   >.> "V 83506  4 10/14/10 15:03:32" 
12 *-*   say x1 
   >>> "CATAA" 
CATAA 
13 *-*   say x2 
   >>> "EXEC" 
EXEC 
14 *-*   say x3 
   >>> "X2" 
X2 
15 *-*   exit  
 
But, when try execute with filemode *, lookslike the program go to a 
LOOPING :
 
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO' 
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0 
   >>>   "1" 
   *-*  then 
   *-*  do 
11 *-*   pull x1 x2 x3 . 
   >>> "CATAA" 
   >>> "EXEC" 
   >>> "X2" 
   >.> "V 83506  4 10/14/10 15:03:32" 
12 *-*   say x1 
   >>> "CATAA" 
CATAA 
13 *-*   say x2 
   >>> "EXEC" 
EXEC 
14 *-*   say x3 
   >>> "X2" 
X2 
15 *-*   exit 
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO' 
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0 
   >>>   "1" 
   *-*  then 
   *-*  do 
11 *-*   pull x1 x2 x3 . 
   >>> "CATAA" 
   >>> "EXEC" 
 
The command in the line show this :
 
listfile cataa exec * 
CATAAEXEC A2 
CATAAEXEC X2 
Ready; T=0.01/0.01 16:17:00  
 
Someone can help, how can verify if this EXEC is not running from X disk ?
 
Thanks very much,
 
Sergio Lima Costa
Sao Paulo - Brazil



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: REXX that verify what MINIDISK is a file

[Scott Rohling]

Oops --  need to only look at the first letter of the filemode:

Parse Source . . x1 x2 x3 .
If left(x3,1) <> 'X' Then Do
  Say 'You are not executing from the X disk!'
  Exit 99
End


Scott Rohling

On Thu, Oct 14, 2010 at 1:34 PM, Scott Rohling wrote:

> Parse Source . . x1 x2 x3 .
> If x3 <> 'X' Then Do
>   Say 'You are not executing from the X disk!'
>   Exit 99
> End
>
> Scott Rohling
>
>
>
> On Thu, Oct 14, 2010 at 1:19 PM, Sergio Lima wrote:
>
>>  Hello List,
>>
>> We are changing a REXX here for that this EXEC execute only if reside on X
>> acessed minidisk.
>> So, try with STATE command without succesfull  and now try  with LISTFILE
>> command.
>> If execute like this :
>>
>>  9 *-* 'LISTFILE  cataa exec x (DATE STACK LIFO'
>>>>>   "LISTFILE  cataa exec x (DATE STACK LIFO"
>> 10 *-* if rc = 0
>>>>>   "1"
>>*-*  then
>>*-*  do
>> 11 *-*   pull x1 x2 x3 .
>>>>> "CATAA"
>>>>> "EXEC"
>>>>> "X2"
>>>.> "V 83506  4 10/14/10 15:03:32"
>> 12 *-*   say x1
>>>>> "CATAA"
>> CATAA
>> 13 *-*   say x2
>>>>> "EXEC"
>> EXEC
>> 14 *-*   say x3
>>>>> "X2"
>> X2
>> 15 *-*   exit
>>
>> But, when try execute with filemode *, lookslike the program go to a
>> LOOPING :
>>
>>  9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
>> 10 *-* if rc = 0
>>>>>   "1"
>>*-*  then
>>*-*  do
>> 11 *-*   pull x1 x2 x3 .
>>>>> "CATAA"
>>>>> "EXEC"
>>>>> "X2"
>>>.> "V 83506  4 10/14/10 15:03:32"
>> 12 *-*   say x1
>>>>> "CATAA"
>> CATAA
>> 13 *-*   say x2
>>>>> "EXEC"
>> EXEC
>> 14 *-*   say x3
>>>>> "X2"
>> X2
>> 15 *-*   exit
>>  9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
>> 10 *-* if rc = 0
>>>>>   "1"
>>*-*  then
>>*-*  do
>> 11 *-*   pull x1 x2 x3 .
>>>>> "CATAA"
>>>>> "EXEC"
>>
>> The command in the line show this :
>>
>> listfile cataa exec *
>> CATAAEXEC A2
>> CATAAEXEC X2
>> Ready; T=0.01/0.01 16:17:00
>>
>> Someone can help, how can verify if this EXEC is not running from X disk ?
>>
>> Thanks very much,
>>
>> Sergio Lima Costa
>> Sao Paulo - Brazil
>>
>
>

Re: Migrating Maintenance to Level 1 Minimum

[Mike Walter]

Page volumes never have to be copied.  Once the have been properly 
CPFMTXA'd (or ICKDSF for those who prefer the pain), they are good 
forever.  Each IPL starts out using them fresh, nothing is leftover.  Just 
be sure that each system has sufficient page volumes for its own workload.
When we're done with an installation, we don't have anything leftover on 
the 54xWnn volumes.  Are you sure that you do?

> I do not believe I can simply IPL with the new CPLOAD, because I have 
the SDFs in the SPOOL which I believe SES rebuilt when I applied the 
maintenance. 

Don't assume.  On each system enter: 
pipe cp q nss iso | sort w6.2 d | cons 
Check the results (displayed sorted by most recent dates at the top).  If 
they are the same, there is no reason to mess with SPOOL volumes.

Tell your manager that you believe that your productivity would really 
benefit from attending the next SHARE conference!

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




"George Henke/NYLIC"  

Sent by: "The IBM z/VM Operating System" 
10/14/2010 02:12 PM
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Migrating Maintenance to Level 1 Minimum







I need to move maintenance from Level 2 to Level 1: 

Level 1 is 540RES, 540W01, 540W02, 540SPL, 540SP2, 540PAG, 540PG2 
Level 2 is 54XRES, 54XW01, 54XW02 54XSPL, 54XSP2, 54XPAG, 54XPG2 

What is the least disruptive way to do this when: 
there is no tape, 
no additional volumes are available, and 
I need a fallback.

I do not believe I can simply IPL with the new CPLOAD, because I have the 
SDFs in the SPOOL which I believe SES rebuilt when I applied the 
maintenance. 

I could DDR the SPOOLs but then I would step on the Level 1 SDFs. 

I suppose I could just point to the Level 2 RES, 54XRES and IPL at Level 1 
instead of 540RES. 

Would there be any changes needed if I did? 



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: Applied RSU but CPLEVEL is unchanged

[Mike Walter]

George,

RSU0802 is from "5402RSU Stacked Product RSU -  December  12, 2008".

Does CP Query CPLOAD show the sysres from which you expected to IPL? 
(Again, a good reason to not use the save volser on different real device 
addresses, aka UCB's).  If not, don't blame the service, it would be time 
to figure out what went wrong in your maintenance process between your 
production and new DDR'ed 2nd level systems.

Can you provide the exact APAR or PTF number that you actually ordered?

To find the most current z/VM PTF, always search for APAR UM97vr0 (where 
v=version, and r=release).
For example for z/VM 5.4 you'd check out UM97540, and for z/VM 6.1 it 
would be UM97610.

The RSU display by Q CPLEVEL is updated with each RSU into HPCCPE.  You 
might want to enter:
VMFSETUP ZVM CP
then
FILELIST HCPCPE * *
See what's in the HCPCPR AUXVM file.  If it shows the PTF for RSU1002, 
then it's time to find out where the CPLOAD MODULE was written.
For clues, browse the " $VMFP2P  $MSGLOG  A1" file.  The most recent 
udpates are at the top, going back through history downward through the 
file.
Ours shows:
--
ST:HCPZAC6730I CPRELEASE request for disk A completed. 
ST:VMFP2P2204I Linking MAINT CF1 as 1FFF with the link mode M 
ST:DMSACP723I X (CF2) R/O 
ST:VMFP2P1231I Copying files from the Secondary Parm disk to the Primary 
ST:Parm disk 
ST:HCPZAC6732I CPACCESS request for MAINT's 0CF1 in mode A completed. 
--

That implies that the VMFBLD wrote to CPLOAD MODULE to the CF2 disk, and 
that the PUT2PROD copied the files from the CF2 to the CF1. 
Too bad the messages don't include the names of the files copied (or just 
say "Copying ALL files..."), and information from QUERY MDISK CF1 LOCATION 
and CF2, like:
TargetID Tdev OwnerID  Odev Dtype Vol-ID Rdev   StartLoc   Size 
MAINT0CF1 MAINT0CF1 3390  VMR54I 6A40   2521120 
TargetID Tdev OwnerID  Odev Dtype Vol-ID Rdev   StartLoc   Size
MAINT0CF2 MAINT0CF2 3390  VMR54I 6A40   2641120 
you would immediately know from and to where PUT2PROD did it's behind the 
scenes work at that date and time.

Let us know how it works out.

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



"George Henke/NYLIC"  

Sent by: "The IBM z/VM Operating System" 
10/14/2010 01:56 PM
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Applied RSU but CPLEVEL is unchanged







I ordered RSU 1002 from SHOPZ,IBMVM@LISTSERV.UARK.EDU or so I thought. 

SHOPZ called it RSU5407 when it gave me the download. 

Applied 35 PTFs, others were already on, PUT2PROD, and IPLed.   

But CPLEVEL still shows 0802: 

q cplevel 
z/VM Version 5 Release 4.0, service level 0802 (64-bit)   
Generated at 10/14/10 12:05:41 EDT 
IPL at 10/14/10 14:40:34 EDT 

Any ideas? 



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: Migrating Maintenance to Level 1 Minimum

[Quay, Jonathan (IHG)]

I think you've conflated PTF maintenance with version or release
maintenance.  VM has "test" minidisks built in to it to test and promote
new PTF levels.  Release or version maintenance is done by creating new
system volumes and then migrating your user directory, etc, to the new
system volumes when you're satisfied with your testing.  Since you've
already built new volumes, I would go with migrating the rest of my
system to the new volumes.

 



From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of George Henke/NYLIC
Sent: Thursday, October 14, 2010 3:13 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Migrating Maintenance to Level 1 Minimum

 


I need to move maintenance from Level 2 to Level 1: 

Level 1 is 540RES, 540W01, 540W02, 540SPL, 540SP2, 540PAG, 540PG2 
Level 2 is 54XRES, 54XW01, 54XW02 54XSPL, 54XSP2, 54XPAG, 54XPG2 

What is the least disruptive way to do this when: 

*   there is no tape, 
*   no additional volumes are available, and 
*   I need a fallback.


I do not believe I can simply IPL with the new CPLOAD, because I have
the SDFs in the SPOOL which I believe SES rebuilt when I applied the
maintenance. 

I could DDR the SPOOLs but then I would step on the Level 1 SDFs. 

I suppose I could just point to the Level 2 RES, 54XRES and IPL at Level
1 instead of 540RES. 

Would there be any changes needed if I did? 

Re: Migrating Maintenance to Level 1 Minimum

[Marcy Cortes]

I find it easiest just to do the service and put2prod on the production systems.
Others have ways of moving all the parts around... but it could be a big 
inconvenience if you had to put an emergency PTF on quickly.

We run service ahead of time and right before the IPL, run the put2prod.
We compare the logs left on maint's 191 by the service command to make sure the 
same things happen there as they did on the 2nd level test.


Marcy 


From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of George Henke/NYLIC
Sent: Thursday, October 14, 2010 12:13 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] Migrating Maintenance to Level 1 Minimum


I need to move maintenance from Level 2 to Level 1: 

Level 1 is 540RES, 540W01, 540W02, 540SPL, 540SP2, 540PAG, 540PG2 
Level 2 is 54XRES, 54XW01, 54XW02 54XSPL, 54XSP2, 54XPAG, 54XPG2 

What is the least disruptive way to do this when: 
* there is no tape, 
* no additional volumes are available, and 
* I need a fallback.

I do not believe I can simply IPL with the new CPLOAD, because I have the SDFs 
in the SPOOL which I believe SES rebuilt when I applied the maintenance. 

I could DDR the SPOOLs but then I would step on the Level 1 SDFs. 

I suppose I could just point to the Level 2 RES, 54XRES and IPL at Level 1 
instead of 540RES. 

Would there be any changes needed if I did? 

Re: REXX that verify what MINIDISK is a file

[Doug Breneman]

You might consider using MAKEBUF and DROPBUF around your code. You are
stacking two lines of output when the file is on the A and the X disk. You
pull one of them and leave the other on the stack. Since the second line is
CATA EXEC X2, it will execute the CATA EXEC again, which will stack two
lines, etc. Yes you have an infinite loop.

If you want to execute the EXEC only from the X disk regardless of its
possible existence on another filemode, you can EXECLOAD the copy from the
X disk and then execute it since execs in storage get priority over execs
on disk. EXECLOAD allows you to specify the filemode. EXECLOAD fn ft fm.
You can even EXECLOAD the exec as a different name. HELP EXECLOAD can help
you if you choose to use it.
pdb (Doug Breneman)
z/VM System Test   IBM   Endicott, NY



From:   Sergio Lima 
To: IBMVM@LISTSERV.UARK.EDU
Date:   10/14/2010 03:20 PM
Subject:REXX that verify what MINIDISK is a file
Sent by:The IBM z/VM Operating System 



Hello List,

We are changing a REXX here for that this EXEC execute only if reside on X
acessed minidisk.
So, try with STATE command without succesfull  and now try  with LISTFILE
command.
If execute like this :

 9 *-* 'LISTFILE  cataa exec x (DATE STACK LIFO'
   >>>   "LISTFILE  cataa exec x (DATE STACK LIFO"
10 *-* if rc = 0
   >>>   "1"
   *-*  then
   *-*  do
11 *-*   pull x1 x2 x3 .
   >>> "CATAA"
   >>> "EXEC"
   >>> "X2"
   >.> "V 83506  4 10/14/10 15:03:32"
12 *-*   say x1
   >>> "CATAA"
CATAA
13 *-*   say x2
   >>> "EXEC"
EXEC
14 *-*   say x3
   >>> "X2"
X2
15 *-*   exit

But, when try execute with filemode *, lookslike the program go to a
LOOPING :

 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
10 *-* if rc = 0
   >>>   "1"
   *-*  then
   *-*  do
11 *-*   pull x1 x2 x3 .
   >>> "CATAA"
   >>> "EXEC"
   >>> "X2"
   >.> "V 83506  4 10/14/10 15:03:32"
12 *-*   say x1
   >>> "CATAA"
CATAA
13 *-*   say x2
   >>> "EXEC"
EXEC
14 *-*   say x3
   >>> "X2"
X2
15 *-*   exit
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
10 *-* if rc = 0
   >>>   "1"
   *-*  then
   *-*  do
11 *-*   pull x1 x2 x3 .
   >>> "CATAA"
   >>> "EXEC"

The command in the line show this :

listfile cataa exec *
CATAAEXEC A2
CATAAEXEC X2
Ready; T=0.01/0.01 16:17:00

Someone can help, how can verify if this EXEC is not running from X disk ?

Thanks very much,

Sergio Lima Costa
Sao Paulo - Brazil

Re: REXX that verify what MINIDISK is a file

[Scott Rohling]

Parse Source . . x1 x2 x3 .
If x3 <> 'X' Then Do
  Say 'You are not executing from the X disk!'
  Exit 99
End

Scott Rohling


On Thu, Oct 14, 2010 at 1:19 PM, Sergio Lima wrote:

>  Hello List,
>
> We are changing a REXX here for that this EXEC execute only if reside on X
> acessed minidisk.
> So, try with STATE command without succesfull  and now try  with LISTFILE
> command.
> If execute like this :
>
>  9 *-* 'LISTFILE  cataa exec x (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec x (DATE STACK LIFO"
> 10 *-* if rc = 0
>>>>   "1"
>*-*  then
>*-*  do
> 11 *-*   pull x1 x2 x3 .
>>>> "CATAA"
>>>> "EXEC"
>>>> "X2"
>>.> "V 83506  4 10/14/10 15:03:32"
> 12 *-*   say x1
>>>> "CATAA"
> CATAA
> 13 *-*   say x2
>>>> "EXEC"
> EXEC
> 14 *-*   say x3
>>>> "X2"
> X2
> 15 *-*   exit
>
> But, when try execute with filemode *, lookslike the program go to a
> LOOPING :
>
>  9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
> 10 *-* if rc = 0
>>>>   "1"
>*-*  then
>*-*  do
> 11 *-*   pull x1 x2 x3 .
>>>> "CATAA"
>>>> "EXEC"
>>>> "X2"
>>.> "V 83506  4 10/14/10 15:03:32"
> 12 *-*   say x1
>>>> "CATAA"
> CATAA
> 13 *-*   say x2
>>>> "EXEC"
> EXEC
> 14 *-*   say x3
>>>> "X2"
> X2
> 15 *-*   exit
>  9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'
>>>>   "LISTFILE  cataa exec * (DATE STACK LIFO"
> 10 *-* if rc = 0
>>>>   "1"
>*-*  then
>*-*  do
> 11 *-*   pull x1 x2 x3 .
>>>> "CATAA"
>>>> "EXEC"
>
> The command in the line show this :
>
> listfile cataa exec *
> CATAAEXEC A2
> CATAAEXEC X2
> Ready; T=0.01/0.01 16:17:00
>
> Someone can help, how can verify if this EXEC is not running from X disk ?
>
> Thanks very much,
>
> Sergio Lima Costa
> Sao Paulo - Brazil
>

Re: Migrating Maintenance to Level 1 Minimum

[Scott Rohling]

If these are the only volumes on the system - then just IPLing 54XRES should
be fine...   But I assume you have other volumes and guests using them on
Level 1.   These would need to be merged into the 2nd level directory and
put online before you IPL 54XRES.

There are also likely disks on Level 1 you likely want to keep the 1st level
version of, rather than the 2nd level.   Examples are DISKACNT 191 and
MONWRITE 191...

Also - you don't have a way to access your old Level 1 spool if you IPL
54XRES -- so you would want to ensure it is as clean as possible - all
console files received and stored some place, etc

Scott Rohling.

On Thu, Oct 14, 2010 at 1:12 PM, George Henke/NYLIC <
george_he...@newyorklife.com> wrote:

>
> I need to move maintenance from Level 2 to Level 1:
>
> Level 1 is 540RES, 540W01, 540W02, 540SPL, 540SP2, 540PAG, 540PG2
> Level 2 is 54XRES, 54XW01, 54XW02 54XSPL, 54XSP2, 54XPAG, 54XPG2
>
> What is the least disruptive way to do this when:
>
>- there is no tape,
>- no additional volumes are available, and
>- I need a fallback.
>
>
> I do not believe I can simply IPL with the new CPLOAD, because I have the
> SDFs in the SPOOL which I believe SES rebuilt when I applied the
> maintenance.
>
> I could DDR the SPOOLs but then I would step on the Level 1 SDFs.
>
> I suppose I could just point to the Level 2 RES, 54XRES and IPL at Level 1
> instead of 540RES.
>
> Would there be any changes needed if I did?
>

Re: REXX that verify what MINIDISK is a file

[Michael Coffin]

Sure.  You have at least two CATAA EXEC files in your search.  The LISTFILE
on line 9 returns at least two stacked items which start CATAA ...  

 

You PULL the first off of the stack on Line 11, and then EXIT on line 15.
EVERYTHING else that was on the stack now gets dumped out to CMS.  

 

What happens when you type CATAA on the CMS command line and press ENTER?
Correct - it executes your exec.  :)

 

There are much better ways to get data in/out of a REXX program than the
very ancient old STACK.  May I suggest using a PIPE:

 

'PIPE COMMAND LISTFILE CATAA EXEC X (DATE | STEM RESULT.'

 

If Result.0=0 Then Say Result.1  /*This will yield "File not found" or
something to that effect.

Else Do I=1 To Result.0  /*Loop through each result and do something..*/

   Say 'Result.'I'='Result.I

End

 

Exit Rc /*Exit on LISTFILE's RC*/

 

Or you could use brute force and put a 'DESBUF' between line 14 and 15 (but
that will destroy ALL buffers, if you MUST use the stack look into the
equally ancient MAKEBUF/DROPBUF commands).

 

-Mike

 

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Sergio Lima
Sent: Thursday, October 14, 2010 3:19 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: REXX that verify what MINIDISK is a file

 

Hello List,
 
We are changing a REXX here for that this EXEC execute only if reside on X
acessed minidisk.
So, try with STATE command without succesfull  and now try  with LISTFILE
command.
If execute like this :
 
 9 *-* 'LISTFILE  cataa exec x (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec x (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   >>> "X2"
   >.> "V 83506  4 10/14/10 15:03:32"  
12 *-*   say x1
   >>> "CATAA" 
CATAA  
13 *-*   say x2
   >>> "EXEC"  
EXEC   
14 *-*   say x3
   >>> "X2"
X2 
15 *-*   exit  
 
But, when try execute with filemode *, lookslike the program go to a LOOPING
:
 
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   >>> "X2"
   >.> "V 83506  4 10/14/10 15:03:32"  
12 *-*   say x1
   >>> "CATAA" 
CATAA  
13 *-*   say x2
   >>> "EXEC"  
EXEC   
14 *-*   say x3
   >>> "X2"
X2 
15 *-*   exit  
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do

Re: REXX that verify what MINIDISK is a file

[Hughes, Jim]

Put a PARSE SOURCE statement at the beginning of the EXEC and see if it
was loaded from the X disk.

 



Jim Hughes

603-271-5586

"It is fun to do the impossible."



From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Sergio Lima
Sent: Thursday, October 14, 2010 3:19 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: REXX that verify what MINIDISK is a file

 

Hello List,
 
We are changing a REXX here for that this EXEC execute only if reside on
X acessed minidisk.
So, try with STATE command without succesfull  and now try  with
LISTFILE command.
If execute like this :
 
 9 *-* 'LISTFILE  cataa exec x (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec x (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   >>> "X2"
   >.> "V 83506  4 10/14/10 15:03:32"  
12 *-*   say x1
   >>> "CATAA" 
CATAA  
13 *-*   say x2
   >>> "EXEC"  
EXEC   
14 *-*   say x3
   >>> "X2"
X2 
15 *-*   exit  
 
But, when try execute with filemode *, lookslike the program go to a
LOOPING :
 
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   >>> "X2"
   >.> "V 83506  4 10/14/10 15:03:32"  
12 *-*   say x1
   >>> "CATAA" 
CATAA  
13 *-*   say x2
   >>> "EXEC"  
EXEC   
14 *-*   say x3
   >>> "X2"
X2 
15 *-*   exit  
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   
The command in the line show this :
 
listfile cataa exec *
CATAAEXEC A2 
CATAAEXEC X2 
Ready; T=0.01/0.01 16:17:00  
 
Someone can help, how can verify if this EXEC is not running from X disk
?
 
Thanks very much,
 
Sergio Lima Costa
Sao Paulo - Brazil

REXX that verify what MINIDISK is a file

[Sergio Lima]

Hello List,
 
We are changing a REXX here for that this EXEC execute only if reside on X 
acessed minidisk.
So, try with STATE command without succesfull  and now try  with LISTFILE 
command.
If execute like this :
 
 9 *-* 'LISTFILE  cataa exec x (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec x (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   >>> "X2"
   >.> "V 83506  4 10/14/10 15:03:32"  
12 *-*   say x1
   >>> "CATAA" 
CATAA  
13 *-*   say x2
   >>> "EXEC"  
EXEC   
14 *-*   say x3
   >>> "X2"
X2 
15 *-*   exit  
 
But, when try execute with filemode *, lookslike the program go to a LOOPING :
 
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   >>> "X2"
   >.> "V 83506  4 10/14/10 15:03:32"  
12 *-*   say x1
   >>> "CATAA" 
CATAA  
13 *-*   say x2
   >>> "EXEC"  
EXEC   
14 *-*   say x3
   >>> "X2"
X2 
15 *-*   exit  
 9 *-* 'LISTFILE  cataa exec * (DATE STACK LIFO'   
   >>>   "LISTFILE  cataa exec * (DATE STACK LIFO" 
10 *-* if rc = 0   
   >>>   "1"   
   *-*  then   
   *-*  do 
11 *-*   pull x1 x2 x3 .   
   >>> "CATAA" 
   >>> "EXEC"  
   
The command in the line show this :
 
listfile cataa exec *
CATAAEXEC A2 
CATAAEXEC X2 
Ready; T=0.01/0.01 16:17:00  
 
Someone can help, how can verify if this EXEC is not running from X disk ?
 
Thanks very much,
 
Sergio Lima Costa
Sao Paulo - Brazil

Migrating Maintenance to Level 1 Minimum

[George Henke/NYLIC]

I need to move maintenance from Level 2 to Level 1:

Level 1 is 540RES, 540W01, 540W02, 540SPL, 540SP2, 540PAG, 540PG2 
Level 2 is 54XRES, 54XW01, 54XW02 54XSPL, 54XSP2, 54XPAG, 54XPG2

What is the least disruptive way to do this when:

there is no tape,
no additional volumes are available, and
I need a fallback.

I do not believe I can simply IPL with the new CPLOAD, because I have the 
SDFs in the SPOOL which I believe SES rebuilt when I applied the 
maintenance.

I could DDR the SPOOLs but then I would step on the Level 1 SDFs.

I suppose I could just point to the Level 2 RES, 54XRES and IPL at Level 1 
instead of 540RES.

Would there be any changes needed if I did?

Applied RSU but CPLEVEL is unchanged

[George Henke/NYLIC]

I ordered RSU 1002 from SHOPZ,IBMVM@LISTSERV.UARK.EDU or so I thought.

SHOPZ called it RSU5407 when it gave me the download.

Applied 35 PTFs, others were already on, PUT2PROD, and IPLed. 

But CPLEVEL still shows 0802:

q cplevel 
z/VM Version 5 Release 4.0, service level 0802 (64-bit) 
Generated at 10/14/10 12:05:41 EDT 
IPL at 10/14/10 14:40:34 EDT

Any ideas? 

Re: z10 and z/VM 6.1

[Mike Walter]

> There's usually a description of installing the "new" system 2nd level 
in CP
> Planning and Admin. That's normally what I think of as the "upgrade" 
path.

Could you perhaps have mean the z/VM Migration Guide (e.g. "z/VM Migration 
Guide Version 5 Release 4.0"  GC24-6103-07)?

Those migration guides contain upgrade changes going many releases back 
(for -07 all the way back to VM/ESA 2.2!). 

The chapters are (not to be missed):
Chapter 1. Introduction to Migration
Chapter 2. System Changes
Chapter 3. Changes to External Interfaces
Chapter 4. Migration Tasks
Appendix A. CMS Pipelines Message Cross-Reference [V2.3]
Appendix B. Sample Utilities for Converting to Configuration Files

At every version or release boundary, I'm always surprised  at how 
well IBM documents what has changed.
Migration (mostly of the directly) is difficult and tedious enough, 
without this manual it would be a lot worse.

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








"David Boyes"  

Sent by: "The IBM z/VM Operating System" 
10/14/2010 12:26 PM
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: z10 and z/VM 6.1






On 10/14/10 1:13 PM, "Marcy Cortes"  wrote:

> Tested what upgrade path?   There's an upgrade path?!

There's usually a description of installing the "new" system 2nd level in 
CP
Planning and Admin. That's normally what I think of as the "upgrade" path.

Also, other places in IBM tend to have codified the n-2 support level, and
I'd suspect that the VM guys are also getting pressure to do that too. 
Mere
speculation, but...

> We're on George's page.  There's nothing compelling in 6.1 for us.  And 
we
> have a lot of new function in 5.4 available by SPE which is way easier 
to do.

I still have a good number of CMS users, so testing SPEs tends to be 
harder
for me in that I have to duplicate the entire scenario. I often find that
these days that the bugs are so subtle, it's easier to do the next release
and just leave 5.4 alone unless it's something that really breaks CP so 
that
you can't IPL. But YMMV.





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: z10 and z/VM 6.1

[Marcy Cortes]

Well, if you had a new install on z10+ and not an upgrade, it would certainly 
be the thing to do.
For those of use with 10+ systems, it's not worth a jump.
There wasn't even an ESP run for 6.1 since there was so little function that 
didn't go into 5.4.  Some customers did get the new function SPEs early though 
and tested them extensively.

Marcy 

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of George Henke/NYLIC
Sent: Thursday, October 14, 2010 10:45 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] z10 and z/VM 6.1


>We've tried it and 6.1 will run as a guest of 5.4 on a z10. 

But will 6.1 run on a z9 or less?  No, I've tried it. 

So for a "seamless" migration to new hardware, maybe it is not so bad to change 
one thing at a time and keep 5.4. 

True, there is less risk going from 6.1 to 6.2, than 5.4 to 6.2, but "tomorrow 
never comes", what happens today determines what happens tomorrow. 

The way IBM has configured things for 6.1: 
• shorter expiration date than 5.4, 
• not much new functionality, 
• no hardware "downward compatibility" below z10,

6.1 is, for all intents and purposes, a "dead release". 

Hope "Chuckie" isn't listening. 


  

Scott Rohling  
Sent by: The IBM z/VM Operating System  
10/14/2010 01:27 PM 
Please respond to
The IBM z/VM Operating System 

To
IBMVM@LISTSERV.UARK.EDU 
cc

Subject
Re: z10 and z/VM 6.1







We've tried it and 6.1 will run as a guest of 5.4 on a z10..

If you're swinging all your DASD over to the z10 - you could just bring up z/VM 
5.4 -- build your 2nd level 6.1 guest - merge and migrate and bring up 6.1 1st 
level...

Scott rohling

On Thu, Oct 14, 2010 at 11:21 AM, Bruce Hayden  wrote: 
I haven't tried it, but 6.1 should run as a guest of 5.4 on a z10 (or later.)  
z/VM does not "hide" or "downgrade" the architecture of the machine from the 
guest (as much as possible), so the machine features needed by 6.1 should still 
be available to a guest of 5.4 on a z10. 


On Thu, Oct 14, 2010 at 11:17 AM, Frank M. Ramaekers  
wrote: 
We are installing a z10 this weekend with z/VM 5.4.  My question is what are my 
migration options for migration to z/VM 6.1?   I don’t suppose that 6.1 can run 
under 5.4, since 6.1 requires a z10+ and 5.4 does not?  (If so, problem 
solved.  Otherwise it looks I’ll be limited to 1.  LPAR the z/VM 6.1 or  2. Run 
the production 5.4 under 6.1) 
  
 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. 



-- 
Bruce Hayden
z/VM and Linux on System z ATS
IBM, Endicott, NY 

Re: z10 and z/VM 6.1

[George Henke/NYLIC]

>We've tried it and 6.1 will run as a guest of 5.4 on a z10.

But will 6.1 run on a z9 or less?  No, I've tried it.

So for a "seamless" migration to new hardware, maybe it is not so bad to 
change one thing at a time and keep 5.4.

True, there is less risk going from 6.1 to 6.2, than 5.4 to 6.2, but 
"tomorrow never comes", what happens today determines what happens 
tomorrow.

The way IBM has configured things for 6.1:

shorter expiration date than 5.4,
not much new functionality,
no hardware "downward compatibility" below z10,

6.1 is, for all intents and purposes, a "dead release".

Hope "Chuckie" isn't listening.


 



Scott Rohling  
Sent by: The IBM z/VM Operating System 
10/14/2010 01:27 PM
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: z10 and z/VM 6.1






We've tried it and 6.1 will run as a guest of 5.4 on a z10..

If you're swinging all your DASD over to the z10 - you could just bring up 
z/VM 5.4 -- build your 2nd level 6.1 guest - merge and migrate and bring 
up 6.1 1st level...

Scott rohling

On Thu, Oct 14, 2010 at 11:21 AM, Bruce Hayden  wrote:
I haven't tried it, but 6.1 should run as a guest of 5.4 on a z10 (or 
later.)  z/VM does not "hide" or "downgrade" the architecture of the 
machine from the guest (as much as possible), so the machine features 
needed by 6.1 should still be available to a guest of 5.4 on a z10.


On Thu, Oct 14, 2010 at 11:17 AM, Frank M. Ramaekers <
framaek...@ailife.com> wrote:
We are installing a z10 this weekend with z/VM 5.4.  My question is what 
are my migration options for migration to z/VM 6.1?   I don’t suppose that 
6.1 can run under 5.4, since 6.1 requires a z10+ and 5.4 does not?  (If 
so, problem solved.  Otherwise it looks I’ll be limited to 1.  LPAR the 
z/VM 6.1 or  2. Run the production 5.4 under 6.1)
 

 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. 



-- 
Bruce Hayden
z/VM and Linux on System z ATS
IBM, Endicott, NY

Re: z10 and z/VM 6.1

[Scott Rohling]

We've tried it and 6.1 will run as a guest of 5.4 on a z10..

If you're swinging all your DASD over to the z10 - you could just bring up
z/VM 5.4 -- build your 2nd level 6.1 guest - merge and migrate and bring up
6.1 1st level...

Scott rohling

On Thu, Oct 14, 2010 at 11:21 AM, Bruce Hayden  wrote:

> I haven't tried it, but 6.1 should run as a guest of 5.4 on a z10 (or
> later.)  z/VM does not "hide" or "downgrade" the architecture of the machine
> from the guest (as much as possible), so the machine features needed by 6.1
> should still be available to a guest of 5.4 on a z10.
>
>
> On Thu, Oct 14, 2010 at 11:17 AM, Frank M. Ramaekers <
> framaek...@ailife.com> wrote:
>
>>  We are installing a z10 this weekend with z/VM 5.4.  My question is what
>> are my migration options for migration to z/VM 6.1?   I don’t suppose that
>> 6.1 can run under 5.4, since 6.1 requires a z10+ and 5.4 does not?  (If so,
>> problem solved.  Otherwise it looks I’ll be limited to 1.  LPAR the z/VM 6.1
>> or  2. Run the production 5.4 under 6.1)
>>
>>
>>
>>  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.
>>
>
>
>
> --
> Bruce Hayden
> z/VM and Linux on System z ATS
> IBM, Endicott, NY
>

Re: z10 and z/VM 6.1

[David Boyes]

On 10/14/10 1:13 PM, "Marcy Cortes"  wrote:

> Tested what upgrade path?   There's an upgrade path?!

There's usually a description of installing the "new" system 2nd level in CP
Planning and Admin. That's normally what I think of as the "upgrade" path.

Also, other places in IBM tend to have codified the n-2 support level, and
I'd suspect that the VM guys are also getting pressure to do that too. Mere
speculation, but...

> We're on George's page.  There's nothing compelling in 6.1 for us.  And we
> have a lot of new function in 5.4 available by SPE which is way easier to do.

I still have a good number of CMS users, so testing SPEs tends to be harder
for me in that I have to duplicate the entire scenario. I often find that
these days that the bugs are so subtle, it's easier to do the next release
and just leave 5.4 alone unless it's something that really breaks CP so that
you can't IPL. But YMMV.

Re: z10 and z/VM 6.1

[Bruce Hayden]

I haven't tried it, but 6.1 should run as a guest of 5.4 on a z10 (or
later.)  z/VM does not "hide" or "downgrade" the architecture of the machine
from the guest (as much as possible), so the machine features needed by 6.1
should still be available to a guest of 5.4 on a z10.

On Thu, Oct 14, 2010 at 11:17 AM, Frank M. Ramaekers
wrote:

>  We are installing a z10 this weekend with z/VM 5.4.  My question is what
> are my migration options for migration to z/VM 6.1?   I don’t suppose that
> 6.1 can run under 5.4, since 6.1 requires a z10+ and 5.4 does not?  (If so,
> problem solved.  Otherwise it looks I’ll be limited to 1.  LPAR the z/VM 6.1
> or  2. Run the production 5.4 under 6.1)
>
>
>
>  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.
>



-- 
Bruce Hayden
z/VM and Linux on System z ATS
IBM, Endicott, NY

Re: z10 and z/VM 6.1

[Marcy Cortes]

Tested what upgrade path?   There's an upgrade path?!
Or maybe you are talking about running the 5.4 CMS under 6.1 CP or something 
like that? 

We're on George's page.  There's nothing compelling in 6.1 for us.  And we have 
a lot of new function in 5.4 available by SPE which is way easier to do.

Holding out for 6.2 or whatever his number ends up being,
Marcy 

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of David Boyes
Sent: Thursday, October 14, 2010 10:00 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] z10 and z/VM 6.1

On 10/14/10 12:15 PM, "George Henke/NYLIC" 
wrote:


> 5.4 has a longer TTL than 6.1.
> 6.1 does not have that much more functionality.
> Why would anyone go to a higher release that has a shorter expiration and not
> much more functionality?

One extenuating reason is that IBM is more likely to have tested the upgrade
path for release N from release N-1 than release N-2. This is somewhat of a
special case (5.4 being the last release before a major architecture
level-set), but the changes to 6.2 made public so far are going to be
doozies, and you don't need another annoying thing to worry about while
you're learning that stuff.

I think this is one case where I'd put up a 6.1 floor system and run the 5.4
production system in a guest. If you have Linux guests, they're pretty self
contained, it's going to be fairly easy to move them to 1st level quickly,
and your CMS users (if you have any) can do testing with both environments
easily. Also, 6.2 isn't that far off, so you could stay current and move
from 5.4 to 6.2 also in a guest, staying supported all the time. 

Re: z10 and z/VM 6.1

[David Boyes]

On 10/14/10 12:15 PM, "George Henke/NYLIC" 
wrote:


> 5.4 has a longer TTL than 6.1.
> 6.1 does not have that much more functionality.
> Why would anyone go to a higher release that has a shorter expiration and not
> much more functionality?

One extenuating reason is that IBM is more likely to have tested the upgrade
path for release N from release N-1 than release N-2. This is somewhat of a
special case (5.4 being the last release before a major architecture
level-set), but the changes to 6.2 made public so far are going to be
doozies, and you don't need another annoying thing to worry about while
you're learning that stuff.

I think this is one case where I'd put up a 6.1 floor system and run the 5.4
production system in a guest. If you have Linux guests, they're pretty self
contained, it's going to be fairly easy to move them to 1st level quickly,
and your CMS users (if you have any) can do testing with both environments
easily. Also, 6.2 isn't that far off, so you could stay current and move
from 5.4 to 6.2 also in a guest, staying supported all the time. 

Re: WAVV201003 update.

[Marcy Cortes]

Thanks David and IBM ;)

Marcy 
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of David Boyes
Sent: Thursday, October 14, 2010 6:35 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] FW: WAVV201003 update.

 
> RMS fails to init if multiple libs defined and not online
> 
> The following comment has been added by Karen Thompson :
> Marketing Field Requirement -- RMS fails to init if multiple libs defined
> and not online
> The status is :Acknowledged
> Comment Added  :  This customer request will be addressed as a problem
> rather than as a new requirement.

Looks like you get your wish, Marcy. Thanks, IBM.

-- db

Re: Information

[Mr. PC]

Check the IBM Principles of Operation. There's a chapter devoted to machine
check handling.

 

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Carlos Bodra - Pessoal
Sent: Thursday, October 14, 2010 10:18 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Information

 

How can I readout these Machine Check occurring in a MP3000 running zVm 4.40

07:13:06 HCPMCI9101I MACHINE CHECK ON CPU .  MCIC = 04000F3D 400B  
07:13:06 System operation continues.   

07:53:45 HCPMCI9101I MACHINE CHECK ON CPU .  MCIC = 04000F3D 400B

07:53:45 System operation continues.

07:53:45 Reporting will be suspended temporarily because machine checks are
occurring too frequently.

There are no problem reported and CE says that machine is ok.
How can I interpret MCIC code showed?



-- 



Carlos Bodra   
IBM zSeries Certified Specialist  
Sao Paulo - Brazil

Re: z10 and z/VM 6.1

[George Henke/NYLIC]

Also, Frank, it should be noted, 6.1 will not run on a z9.  You get a wait 
state code.  It is not "downward compatible", but 5.4 is both "downward" 
and "upward compatible".

It would be nice to bring up the software before the hardware comes in the 
door, just to shake things down.

It is also not wise to change both software and hardware at the same time.

Just one more reason to stick with 5.4.

Everything I know about this I learned here.

You don't need 6.1

Just put  VM64798 VM64879 VM64881 on 5.4 and you can run on z10.

5.4 has a longer TTL than 6.1.

6.1 does not have that much more functionality.

Why would anyone go to a higher release that has a shorter expiration and 
not much more functionality?

It's suboptimal.

Put on the APARs for z10 and wait for 6.2





"Frank M. Ramaekers"  
Sent by: The IBM z/VM Operating System 
10/14/2010 11:17 AM
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
z10 and z/VM 6.1






We are installing a z10 this weekend with z/VM 5.4.  My question is what 
are my migration options for migration to z/VM 6.1?   I don’t suppose that 
6.1 can run under 5.4, since 6.1 requires a z10+ and 5.4 does not?  (If 
so, problem solved.  Otherwise it looks I’ll be limited to 1.  LPAR the 
z/VM 6.1 or  2. Run the production 5.4 under 6.1)
 

 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. 

Re: z10 and z/VM 6.1

[George Henke/NYLIC]

You don't need 6.1

Just put  VM64798 VM64879 VM64881 on 5.4 and you can run on z10.

5.4 has a longer TTL than 6.1.

6.1 does not have that much more functionality.

Why would anyone go to a higher release that has a shorter expiration and 
not much more functionality?

It's suboptimal.

Put on the APARs for z10 and wait for 6.2





"Frank M. Ramaekers"  
Sent by: The IBM z/VM Operating System 
10/14/2010 11:17 AM
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
z10 and z/VM 6.1






We are installing a z10 this weekend with z/VM 5.4.  My question is what 
are my migration options for migration to z/VM 6.1?   I don’t suppose that 
6.1 can run under 5.4, since 6.1 requires a z10+ and 5.4 does not?  (If 
so, problem solved.  Otherwise it looks I’ll be limited to 1.  LPAR the 
z/VM 6.1 or  2. Run the production 5.4 under 6.1)
 

 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. 

z10 and z/VM 6.1

[Frank M. Ramaekers]

We are installing a z10 this weekend with z/VM 5.4.  My question is what
are my migration options for migration to z/VM 6.1?   I don't suppose
that 6.1 can run under 5.4, since 6.1 requires a z10+ and 5.4 does not?
(If so, problem solved.  Otherwise it looks I'll be limited to 1.  LPAR
the z/VM 6.1 or  2. Run the production 5.4 under 6.1)

 

 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.

Information

[Carlos Bodra - Pessoal]

 How can I readout these Machine Check occurring in a MP3000 running 
zVm 4.40


07:13:06 HCPMCI9101I MACHINE CHECK ON CPU .  MCIC = 04000F3D 400B
07:13:06 System operation continues.

07:53:45 HCPMCI9101I MACHINE CHECK ON CPU .  MCIC = 04000F3D 400B
07:53:45 System operation continues.
07:53:45 Reporting will be suspended temporarily because machine checks 
are occurring too frequently.


There are no problem reported and CE says that machine is ok.
How can I interpret MCIC code showed?

--

Carlos Bodra
IBM zSeries Certified Specialist
Sao Paulo - Brazil

FW: WAVV201002, WAVV201008

[David Boyes]

 
> User Group Number - WAVV201002
> Document Status - Suggestion
> Title - Allowing CP to present different logos for users on different IP
> net
> IBM will use this request as input to planning but no commitment is made or
> implied. This request will not be updated.
> 
> User Group Number - WAVV201008
> Document Status - Recognized
> Title - Provide DSE option for user disks
> IBM agrees with the request and a solution appears to be a desirable
> objective. A solution however may not presently appear feasible or
> implementable. No IBM commitment is made or implied as to the eventual
> delivery of an acceptable solution.

Busy, busy, busy...

-- db

FW: WAVV201003 update.

[David Boyes]

 
> RMS fails to init if multiple libs defined and not online
> 
> The following comment has been added by Karen Thompson :
> Marketing Field Requirement -- RMS fails to init if multiple libs defined
> and not online
> The status is :Acknowledged
> Comment Added  :  This customer request will be addressed as a problem
> rather than as a new requirement.

Looks like you get your wish, Marcy. Thanks, IBM.

-- db