Dirmaint Mdisk Allocation
Hello all, I have a 3390-3 allocated as all Perm (PERM 0 3338 3339). Dirmaint will not let me allocate past cylinder 1170? I have another 3390-3 also allocated as all Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas? Thanks, Mary Zervos VM Systems Programmer Binghamton University
Re: Dirmaint Mdisk Allocation
Does your EXTENT CONTROL file have them configured as 3390-3? Does DIRMAINT think there is something else on the volume? Mary Zervos wrote: Hello all, I have a 3390-3 allocated as all Perm (PERM 0 3338 3339). Dirmaint will not let me allocate past cylinder 1170? I have another 3390-3 also allocated as all Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas? Thanks, Mary Zervos VM Systems Programmer Binghamton University -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: Dirmaint Mdisk Allocation
Yes, the Extent control file has them as 3390-3. A Dirm Usedext shows all the users mdisks. A Dirm Freext comes up empty. Rich Smrcina wrote: Does your EXTENT CONTROL file have them configured as 3390-3? Does DIRMAINT think there is something else on the volume? Mary Zervos wrote: Hello all, I have a 3390-3 allocated as all Perm (PERM 0 3338 3339). Dirmaint will not let me allocate past cylinder 1170? I have another 3390-3 also allocated as all Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas? Thanks, Mary Zervos VM Systems Programmer Binghamton University
Re: Dirmaint Mdisk Allocation
Does EXTENT CONTROL have a subset of the volumes configured? The third and fourth tokens on each line is the starting and ending cylinders of the area that DIRMAINT is allowed to allocate. Are you having problems with any other 3390-3 volumes? Mary Zervos wrote: Yes, the Extent control file has them as 3390-3. A Dirm Usedext shows all the users mdisks. A Dirm Freext comes up empty. Rich Smrcina wrote: Does your EXTENT CONTROL file have them configured as 3390-3? Does DIRMAINT think there is something else on the volume? Mary Zervos wrote: Hello all, I have a 3390-3 allocated as all Perm (PERM 0 3338 3339). Dirmaint will not let me allocate past cylinder 1170? I have another 3390-3 also allocated as all Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas? Thanks, Mary Zervos VM Systems Programmer Binghamton University -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: Dirmaint Mdisk Allocation
It's sounding like the disks already have minidisks on them so you can't allocate past those values?Can you show entries from EXTENT CONTROL (for these volumes - and also the 3390-3 definition at the bottom (check for dupe 3390-3 defs!)) -- and also from USEDEXT ? Scott Rohling On Tue, Aug 19, 2008 at 8:27 AM, Rich Smrcina [EMAIL PROTECTED] wrote: Does EXTENT CONTROL have a subset of the volumes configured? The third and fourth tokens on each line is the starting and ending cylinders of the area that DIRMAINT is allowed to allocate. Are you having problems with any other 3390-3 volumes? Mary Zervos wrote: Yes, the Extent control file has them as 3390-3. A Dirm Usedext shows all the users mdisks. A Dirm Freext comes up empty. Rich Smrcina wrote: Does your EXTENT CONTROL file have them configured as 3390-3? Does DIRMAINT think there is something else on the volume? Mary Zervos wrote: Hello all, I have a 3390-3 allocated as all Perm (PERM 0 3338 3339). Dirmaint will not let me allocate past cylinder 1170? I have another 3390-3 also allocated as all Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas? Thanks, Mary Zervos VM Systems Programmer Binghamton University -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: Dirmaint Mdisk Allocation
This is a new z/VM 5.3 system I'm working on. Very few userids with mdisks have been allocated so far. I've only added the following to the Extent Control file.and the Defaults Datadvh file is set right. :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments 530USR530USR 001 3338 3390-03 *DASDType Max-Size 3390-01 1113 3390-02 2226 3390-03 3339 I just formatted, allocated another 3390-3 pack as all perm, added it to the REGIONS in Extent Control, attached it to the system, added it to $ALLOC$, issued Dirm Freext which shows VOLUME DEVTYPE -- FREE EXTENTS --- 530TDK 3390 START= 1 AVAIL= 1112 It definitely doesn't see it as a 3390-3? Rich Smrcina wrote: Does EXTENT CONTROL have a subset of the volumes configured? The third and fourth tokens on each line is the starting and ending cylinders of the area that DIRMAINT is allowed to allocate. Are you having problems with any other 3390-3 volumes? Mary Zervos wrote: Yes, the Extent control file has them as 3390-3. A Dirm Usedext shows all the users mdisks. A Dirm Freext comes up empty. Rich Smrcina wrote: Does your EXTENT CONTROL file have them configured as 3390-3? Does DIRMAINT think there is something else on the volume? Mary Zervos wrote: Hello all, I have a 3390-3 allocated as all Perm (PERM 0 3338 3339). Dirmaint will not let me allocate past cylinder 1170? I have another 3390-3 also allocated as all Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas? Thanks, Mary Zervos VM Systems Programmer Binghamton University
Re: Dirmaint Mdisk Allocation
When you added it to EXTENT CONTROL, did you send the file back to DIRMAINT and tell it to reload the EXTENT CONTROL file (DIRM RLDEXTN)? Mary Zervos wrote: This is a new z/VM 5.3 system I'm working on. Very few userids with mdisks have been allocated so far. I've only added the following to the Extent Control file.and the Defaults Datadvh file is set right. :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments 530USR530USR 001 3338 3390-03 *DASDType Max-Size 3390-01 1113 3390-02 2226 3390-03 3339 I just formatted, allocated another 3390-3 pack as all perm, added it to the REGIONS in Extent Control, attached it to the system, added it to $ALLOC$, issued Dirm Freext which shows VOLUME DEVTYPE -- FREE EXTENTS --- 530TDK 3390 START= 1 AVAIL= 1112 It definitely doesn't see it as a 3390-3? Rich Smrcina wrote: Does EXTENT CONTROL have a subset of the volumes configured? The third and fourth tokens on each line is the starting and ending cylinders of the area that DIRMAINT is allowed to allocate. Are you having problems with any other 3390-3 volumes? Mary Zervos wrote: Yes, the Extent control file has them as 3390-3. A Dirm Usedext shows all the users mdisks. A Dirm Freext comes up empty. Rich Smrcina wrote: Does your EXTENT CONTROL file have them configured as 3390-3? Does DIRMAINT think there is something else on the volume? Mary Zervos wrote: Hello all, I have a 3390-3 allocated as all Perm (PERM 0 3338 3339). Dirmaint will not let me allocate past cylinder 1170? I have another 3390-3 also allocated as all Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas? Thanks, Mary Zervos VM Systems Programmer Binghamton University -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: DIRMAINT Mdisk Allocation
Make sure you do *not* have an EXTENT CONTROL file on your A disk, DIRMAINT will use that one first. Thank you, Scott R Wandschneider Senior Systems Programmer Infocrossing Office 402.963.8905 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rich Smrcina Sent: Tuesday, August 19, 2008 10:01 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Dirmaint Mdisk Allocation When you added it to EXTENT CONTROL, did you send the file back to DIRMAINT and tell it to reload the EXTENT CONTROL file (DIRM RLDEXTN)? Mary Zervos wrote: This is a new z/VM 5.3 system I'm working on. Very few userids with mdisks have been allocated so far. I've only added the following to the Extent Control file.and the Defaults Datadvh file is set right. :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments 530USR530USR 001 3338 3390-03 *DASDType Max-Size 3390-01 1113 3390-02 2226 3390-03 3339 I just formatted, allocated another 3390-3 pack as all perm, added it to the REGIONS in Extent Control, attached it to the system, added it to $ALLOC$, issued Dirm Freext which shows VOLUME DEVTYPE -- FREE EXTENTS --- 530TDK 3390 START= 1 AVAIL= 1112 It definitely doesn't see it as a 3390-3? Rich Smrcina wrote: Does EXTENT CONTROL have a subset of the volumes configured? The third and fourth tokens on each line is the starting and ending cylinders of the area that DIRMAINT is allowed to allocate. Are you having problems with any other 3390-3 volumes? Mary Zervos wrote: Yes, the Extent control file has them as 3390-3. A Dirm Usedext shows all the users mdisks. A Dirm Freext comes up empty. Rich Smrcina wrote: Does your EXTENT CONTROL file have them configured as 3390-3? Does DIRMAINT think there is something else on the volume? Mary Zervos wrote: Hello all, I have a 3390-3 allocated as all Perm (PERM 0 3338 3339). Dirmaint will not let me allocate past cylinder 1170? I have another 3390-3 also allocated as all Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas? Thanks, Mary Zervos VM Systems Programmer Binghamton University -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: DIRMAINT Mdisk Allocation
Maint's 191 A disk is where I purposely place the Extent Control file to tailor and to send back to Dirmaint, followed by a Dirm Rldextn. Wandschneider, Scott wrote: Make sure you do *not* have an EXTENT CONTROL file on your A disk, DIRMAINT will use that one first. Thank you, Scott R Wandschneider Senior Systems Programmer Infocrossing Office 402.963.8905 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rich Smrcina Sent: Tuesday, August 19, 2008 10:01 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Dirmaint Mdisk Allocation When you added it to EXTENT CONTROL, did you send the file back to DIRMAINT and tell it to reload the EXTENT CONTROL file (DIRM RLDEXTN)? Mary Zervos wrote: This is a new z/VM 5.3 system I'm working on. Very few userids with mdisks have been allocated so far. I've only added the following to the Extent Control file.and the Defaults Datadvh file is set right. :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments 530USR530USR 001 3338 3390-03 *DASDType Max-Size 3390-01 1113 3390-02 2226 3390-03 3339 I just formatted, allocated another 3390-3 pack as all perm, added it to the REGIONS in Extent Control, attached it to the system, added it to $ALLOC$, issued Dirm Freext which shows VOLUME DEVTYPE -- FREE EXTENTS --- 530TDK 3390 START= 1 AVAIL= 1112 It definitely doesn't see it as a 3390-3? Rich Smrcina wrote: Does EXTENT CONTROL have a subset of the volumes configured? The third and fourth tokens on each line is the starting and ending cylinders of the area that DIRMAINT is allowed to allocate. Are you having problems with any other 3390-3 volumes? Mary Zervos wrote: Yes, the Extent control file has them as 3390-3. A Dirm Usedext shows all the users mdisks. A Dirm Freext comes up empty. Rich Smrcina wrote: Does your EXTENT CONTROL file have them configured as 3390-3? Does DIRMAINT think there is something else on the volume? Mary Zervos wrote: Hello all, I have a 3390-3 allocated as all Perm (PERM 0 3338 3339). Dirmaint will not let me allocate past cylinder 1170? I have another 3390-3 also allocated as all Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas? Thanks, Mary Zervos VM Systems Programmer Binghamton University -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: DIRMAINT Mdisk Allocation
Assuming the vol 530TDK has meaning. The rest of the volume has been allocated as t-disk area. Tom Duerbusch THD Consulting Law of Dinner Table Attendance Cats must attend all meals when anything good is served. Scott Rohling [EMAIL PROTECTED] 8/19/2008 10:18 AM This isn't true.. DIRMAINT uses the copy on it's disks - not yours.. Scott Rohling On Tue, Aug 19, 2008 at 9:06 AM, Wandschneider, Scott [EMAIL PROTECTED] wrote: Make sure you do *not* have an EXTENT CONTROL file on your A disk, DIRMAINT will use that one first. Thank you, Scott R Wandschneider Senior Systems Programmer Infocrossing Office 402.963.8905
Re: Dirmaint Mdisk Allocation
Your EXTENT CONTROL entries came out garbled when I look at them.. I see 3390-01 in there - which is the size it seems to be using. What do your DEFAULTS show for 3390-3 or 3390-03 or whichever you are using in REGIONS? It's sounding very much like it thinks these are 3390-01 -- so either it's being specified that way in REGIONS - or you have an entry for 3390-03 that points to 1113 size in DEFAULTS.. On Tue, Aug 19, 2008 at 9:15 AM, Mary Zervos [EMAIL PROTECTED] wrote: Yes I did. Rich Smrcina wrote: When you added it to EXTENT CONTROL, did you send the file back to DIRMAINT and tell it to reload the EXTENT CONTROL file (DIRM RLDEXTN)? Mary Zervos wrote: This is a new z/VM 5.3 system I'm working on. Very few userids with mdisks have been allocated so far. I've only added the following to the Extent Control file.and the Defaults Datadvh file is set right. :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments 530USR530USR 001 3338 3390-03 *DASDType Max-Size 3390-01 1113 3390-02 2226 3390-03 3339 I just formatted, allocated another 3390-3 pack as all perm, added it to the REGIONS in Extent Control, attached it to the system, added it to $ALLOC$, issued Dirm Freext which shows VOLUME DEVTYPE -- FREE EXTENTS --- 530TDK 3390 START= 1 AVAIL= 1112 It definitely doesn't see it as a 3390-3? Rich Smrcina wrote: Does EXTENT CONTROL have a subset of the volumes configured? The third and fourth tokens on each line is the starting and ending cylinders of the area that DIRMAINT is allowed to allocate. Are you having problems with any other 3390-3 volumes? Mary Zervos wrote: Yes, the Extent control file has them as 3390-3. A Dirm Usedext shows all the users mdisks. A Dirm Freext comes up empty. Rich Smrcina wrote: Does your EXTENT CONTROL file have them configured as 3390-3? Does DIRMAINT think there is something else on the volume? Mary Zervos wrote: Hello all, I have a 3390-3 allocated as all Perm (PERM 0 3338 3339). Dirmaint will not let me allocate past cylinder 1170? I have another 3390-3 also allocated as all Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas? Thanks, Mary Zervos VM Systems Programmer Binghamton University
Re: Dirmaint Mdisk Allocation
Could someone please send me their Z/VM 5.3 Extent Control file to peek at? Thanks. Scott Rohling wrote: Your EXTENT CONTROL entries came out garbled when I look at them.. I see 3390-01 in there - which is the size it seems to be using. What do your DEFAULTS show for 3390-3 or 3390-03 or whichever you are using in REGIONS? It's sounding very much like it thinks these are 3390-01 -- so either it's being specified that way in REGIONS - or you have an entry for 3390-03 that points to 1113 size in DEFAULTS.. On Tue, Aug 19, 2008 at 9:15 AM, Mary Zervos [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Yes I did. Rich Smrcina wrote: When you added it to EXTENT CONTROL, did you send the file back to DIRMAINT and tell it to reload the EXTENT CONTROL file (DIRM RLDEXTN)? Mary Zervos wrote: This is a new z/VM 5.3 system I'm working on. Very few userids with mdisks have been allocated so far. I've only added the following to the Extent Control file.and the Defaults Datadvh file is set right. :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments 530USR530USR 001 3338 3390-03 *DASDType Max-Size 3390-01 1113 3390-02 2226 3390-03 3339 I just formatted, allocated another 3390-3 pack as all perm, added it to the REGIONS in Extent Control, attached it to the system, added it to $ALLOC$, issued Dirm Freext which shows VOLUME DEVTYPE -- FREE EXTENTS --- 530TDK 3390 START= 1 AVAIL= 1112 It definitely doesn't see it as a 3390-3? Rich Smrcina wrote: Does EXTENT CONTROL have a subset of the volumes configured? The third and fourth tokens on each line is the starting and ending cylinders of the area that DIRMAINT is allowed to allocate. Are you having problems with any other 3390-3 volumes? Mary Zervos wrote: Yes, the Extent control file has them as 3390-3. A Dirm Usedext shows all the users mdisks. A Dirm Freext comes up empty. Rich Smrcina wrote: Does your EXTENT CONTROL file have them configured as 3390-3? Does DIRMAINT think there is something else on the volume? Mary Zervos wrote: Hello all, I have a 3390-3 allocated as all Perm (PERM 0 3338 3339). Dirmaint will not let me allocate past cylinder 1170? I have another 3390-3 also allocated as all Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas? Thanks, Mary Zervos VM Systems Programmer Binghamton University
Re: Dirmaint Mdisk Allocation
sent our extent control and defaults datadvh to ya.. Scott Rohling On Tue, Aug 19, 2008 at 9:31 AM, Mary Zervos [EMAIL PROTECTED] wrote: Could someone please send me their Z/VM 5.3 Extent Control file to peek at? Thanks. Scott Rohling wrote: Your EXTENT CONTROL entries came out garbled when I look at them.. I see 3390-01 in there - which is the size it seems to be using. What do your DEFAULTS show for 3390-3 or 3390-03 or whichever you are using in REGIONS? It's sounding very much like it thinks these are 3390-01 -- so either it's being specified that way in REGIONS - or you have an entry for 3390-03 that points to 1113 size in DEFAULTS.. On Tue, Aug 19, 2008 at 9:15 AM, Mary Zervos [EMAIL PROTECTED]mailto: [EMAIL PROTECTED] wrote: Yes I did. Rich Smrcina wrote: When you added it to EXTENT CONTROL, did you send the file back to DIRMAINT and tell it to reload the EXTENT CONTROL file (DIRM RLDEXTN)? Mary Zervos wrote: This is a new z/VM 5.3 system I'm working on. Very few userids with mdisks have been allocated so far. I've only added the following to the Extent Control file.and the Defaults Datadvh file is set right. :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments 530USR530USR 001 3338 3390-03 *DASDType Max-Size 3390-01 1113 3390-02 2226 3390-03 3339 I just formatted, allocated another 3390-3 pack as all perm, added it to the REGIONS in Extent Control, attached it to the system, added it to $ALLOC$, issued Dirm Freext which shows VOLUME DEVTYPE -- FREE EXTENTS --- 530TDK 3390 START= 1 AVAIL= 1112 It definitely doesn't see it as a 3390-3? Rich Smrcina wrote: Does EXTENT CONTROL have a subset of the volumes configured? The third and fourth tokens on each line is the starting and ending cylinders of the area that DIRMAINT is allowed to allocate. Are you having problems with any other 3390-3 volumes? Mary Zervos wrote: Yes, the Extent control file has them as 3390-3. A Dirm Usedext shows all the users mdisks. A Dirm Freext comes up empty. Rich Smrcina wrote: Does your EXTENT CONTROL file have them configured as 3390-3? Does DIRMAINT think there is something else on the volume? Mary Zervos wrote: Hello all, I have a 3390-3 allocated as all Perm (PERM 0 3338 3339). Dirmaint will not let me allocate past cylinder 1170? I have another 3390-3 also allocated as all Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas? Thanks, Mary Zervos VM Systems Programmer Binghamton University
Re: Dirmaint Mdisk Allocation
Thanks Scott. I'm heading out the door for the day and I'll talk to you tomorrow. Mary Scott Rohling wrote: sent our extent control and defaults datadvh to ya.. Scott Rohling On Tue, Aug 19, 2008 at 9:31 AM, Mary Zervos [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Could someone please send me their Z/VM 5.3 Extent Control file to peek at? Thanks. Scott Rohling wrote: Your EXTENT CONTROL entries came out garbled when I look at them.. I see 3390-01 in there - which is the size it seems to be using. What do your DEFAULTS show for 3390-3 or 3390-03 or whichever you are using in REGIONS? It's sounding very much like it thinks these are 3390-01 -- so either it's being specified that way in REGIONS - or you have an entry for 3390-03 that points to 1113 size in DEFAULTS.. On Tue, Aug 19, 2008 at 9:15 AM, Mary Zervos [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Yes I did. Rich Smrcina wrote: When you added it to EXTENT CONTROL, did you send the file back to DIRMAINT and tell it to reload the EXTENT CONTROL file (DIRM RLDEXTN)? Mary Zervos wrote: This is a new z/VM 5.3 system I'm working on. Very few userids with mdisks have been allocated so far. I've only added the following to the Extent Control file.and the Defaults Datadvh file is set right. :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments 530USR530USR 001 3338 3390-03 *DASDType Max-Size 3390-01 1113 3390-02 2226 3390-03 3339 I just formatted, allocated another 3390-3 pack as all perm, added it to the REGIONS in Extent Control, attached it to the system, added it to $ALLOC$, issued Dirm Freext which shows VOLUME DEVTYPE -- FREE EXTENTS --- 530TDK 3390 START= 1 AVAIL= 1112 It definitely doesn't see it as a 3390-3? Rich Smrcina wrote: Does EXTENT CONTROL have a subset of the volumes configured? The third and fourth tokens on each line is the starting and ending cylinders of the area that DIRMAINT is allowed to allocate. Are you having problems with any other 3390-3 volumes? Mary Zervos wrote: Yes, the Extent control file has them as 3390-3. A Dirm Usedext shows all the users mdisks. A Dirm Freext comes up empty. Rich Smrcina wrote: Does your EXTENT CONTROL file have them configured as 3390-3? Does DIRMAINT think there is something else on the volume? Mary Zervos wrote: Hello all, I have a 3390-3 allocated as all Perm (PERM 0 3338 3339). Dirmaint will not let me allocate past cylinder 1170? I have another 3390-3 also allocated as all Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas? Thanks, Mary Zervos VM Systems Programmer Binghamton University
Re: Dirmaint Mdisk Allocation
Dirmaint doesn't look at all at the real disk, so how you have allocated it does not influence where Dirmaint will place minidisks. One exception: for CPOWEND volumes, DIRMAINT finds out where PAGE, SPOOL (and DRCT TDISK?) is and flags those cylinders as in use. I guess DIRMAINT uses some form of the CP Q ALLOC command to find this. EXTENT CONTROL and DEFAULTS DATADVH are indeed the keys in this issue. 2008/8/19 Mary Zervos [EMAIL PROTECTED] Thanks Scott. I'm heading out the door for the day and I'll talk to you tomorrow. Mary Scott Rohling wrote: sent our extent control and defaults datadvh to ya.. Scott Rohling On Tue, Aug 19, 2008 at 9:31 AM, Mary Zervos [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Could someone please send me their Z/VM 5.3 Extent Control file to peek at? Thanks. Scott Rohling wrote: Your EXTENT CONTROL entries came out garbled when I look at them.. I see 3390-01 in there - which is the size it seems to be using. What do your DEFAULTS show for 3390-3 or 3390-03 or whichever you are using in REGIONS? It's sounding very much like it thinks these are 3390-01 -- so either it's being specified that way in REGIONS - or you have an entry for 3390-03 that points to 1113 size in DEFAULTS.. On Tue, Aug 19, 2008 at 9:15 AM, Mary Zervos [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Yes I did. Rich Smrcina wrote: When you added it to EXTENT CONTROL, did you send the file back to DIRMAINT and tell it to reload the EXTENT CONTROL file (DIRM RLDEXTN)? Mary Zervos wrote: This is a new z/VM 5.3 system I'm working on. Very few userids with mdisks have been allocated so far. I've only added the following to the Extent Control file.and the Defaults Datadvh file is set right. :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments 530USR530USR 001 3338 3390-03 *DASDType Max-Size 3390-01 1113 3390-02 2226 3390-03 3339 I just formatted, allocated another 3390-3 pack as all perm, added it to the REGIONS in Extent Control, attached it to the system, added it to $ALLOC$, issued Dirm Freext which shows VOLUME DEVTYPE -- FREE EXTENTS --- 530TDK 3390 START= 1 AVAIL= 1112 It definitely doesn't see it as a 3390-3? Rich Smrcina wrote: Does EXTENT CONTROL have a subset of the volumes configured? The third and fourth tokens on each line is the starting and ending cylinders of the area that DIRMAINT is allowed to allocate. Are you having problems with any other 3390-3 volumes? Mary Zervos wrote: Yes, the Extent control file has them as 3390-3. A Dirm Usedext shows all the users mdisks. A Dirm Freext comes up empty. Rich Smrcina wrote: Does your EXTENT CONTROL file have them configured as 3390-3? Does DIRMAINT think there is something else on the volume? Mary Zervos wrote: Hello all, I have a 3390-3 allocated as all Perm (PERM 0 3338 3339). Dirmaint will not let me allocate past cylinder 1170? I have another 3390-3 also allocated as all Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas? Thanks, Mary Zervos VM Systems Programmer Binghamton University -- Kris Buelens, IBM Belgium, VM customer support
DDR'ing 3390 DASD To Remote Location
A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George
Re: Dirmaint Mdisk Allocation
I remember years ago a similar problem where my extent control didn't adhere to columns restriction in the REGIONS section. I never found a word on this in the doc but the support told me add 'spaces' between each column. That resolved my problem. Alain Benveniste Le 19/08/08 18:01, « Mary Zervos » [EMAIL PROTECTED] a écrit : Thanks Scott. I'm heading out the door for the day and I'll talk to you tomorrow. Mary Scott Rohling wrote: sent our extent control and defaults datadvh to ya.. Scott Rohling On Tue, Aug 19, 2008 at 9:31 AM, Mary Zervos [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Could someone please send me their Z/VM 5.3 Extent Control file to peek at? Thanks. Scott Rohling wrote: Your EXTENT CONTROL entries came out garbled when I look at them.. I see 3390-01 in there - which is the size it seems to be using. What do your DEFAULTS show for 3390-3 or 3390-03 or whichever you are using in REGIONS? It's sounding very much like it thinks these are 3390-01 -- so either it's being specified that way in REGIONS - or you have an entry for 3390-03 that points to 1113 size in DEFAULTS.. On Tue, Aug 19, 2008 at 9:15 AM, Mary Zervos [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Yes I did. Rich Smrcina wrote: When you added it to EXTENT CONTROL, did you send the file back to DIRMAINT and tell it to reload the EXTENT CONTROL file (DIRM RLDEXTN)? Mary Zervos wrote: This is a new z/VM 5.3 system I'm working on. Very few userids with mdisks have been allocated so far. I've only added the following to the Extent Control file.and the Defaults Datadvh file is set right. :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments 530USR530USR 001 3338 3390-03 *DASDType Max-Size 3390-01 1113 3390-02 2226 3390-03 3339 I just formatted, allocated another 3390-3 pack as all perm, added it to the REGIONS in Extent Control, attached it to the system, added it to $ALLOC$, issued Dirm Freext which shows VOLUME DEVTYPE -- FREE EXTENTS --- 530TDK 3390 START= 1 AVAIL= 1112 It definitely doesn't see it as a 3390-3? Rich Smrcina wrote: Does EXTENT CONTROL have a subset of the volumes configured? The third and fourth tokens on each line is the starting and ending cylinders of the area that DIRMAINT is allowed to allocate. Are you having problems with any other 3390-3 volumes? Mary Zervos wrote: Yes, the Extent control file has them as 3390-3. A Dirm Usedext shows all the users mdisks. A Dirm Freext comes up empty. Rich Smrcina wrote: Does your EXTENT CONTROL file have them configured as 3390-3? Does DIRMAINT think there is something else on the volume? Mary Zervos wrote: Hello all, I have a 3390-3 allocated as all Perm (PERM 0 3338 3339). Dirmaint will not let me allocate past cylinder 1170? I have another 3390-3 also allocated as all Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas? Thanks, Mary Zervos VM Systems Programmer Binghamton University
Re: DDR'ing 3390 DASD To Remote Location
Waw, that sounds great. 2008/8/19 Jiri Stehlik [EMAIL PROTECTED]: A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George -- Kris Buelens, IBM Belgium, VM customer support
Re: DDR'ing 3390 DASD To Remote Location
A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC 'Bout darn time. First of all, THANK YOU. That's been needed for AGES. Have you talked to the product owner? There is an open requirement against DDR that you could be a hero by helping them close it. The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Cool. Notice that this project is still a work in progress, therefore feedback is welcomed! Q: does this version also include the CMSDDR mods? So, when do you start on SPXTAPE? 8-) -- db
Re: DDR'ing 3390 DASD To Remote Location
Fantastic! That was me asking about that, I ended up using PIPE TRACKREAD, creating an intermediate file, and VMFTP'ing that (but it's VERY time consuming). I'll take a look at your mods ASAP and give you feedback (do you want it here or privately, if the latter is your email in the package?). Thanks George, can't wait to try it out! :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jiri Stehlik Sent: Tuesday, August 19, 2008 1:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DDR'ing 3390 DASD To Remote Location A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George
Re: DDR'ing 3390 DASD To Remote Location
Hi Dave, Have you talked to the product owner? There is an open requirement against DDR that you could be a hero by helping them close it. Yep, George has been working on this project with that exact requirement in mind. Considering the recent discussions here on this very topic, we thought we'd try to get some feedback on it now instead of waiting to get it into the release stream. If the feedback is positive, it'll certainly join the actual product in a future deliverable. Q: does this version also include the CMSDDR mods? No, this is an otherwise unmodified DDR module. For the purposes of this download, we wanted to limit the changes within a single deliverable. Regards, Eric Eric Farman z/VM I/O Development IBM Endicott, NY (607)429-4958 (tie 620)
Re: DDR'ing 3390 DASD To Remote Location
Yep, George has been working on this project with that exact requirement in mind. Fantastic. That's exactly what I wanted to hear. Q: does this version also include the CMSDDR mods? No, this is an otherwise unmodified DDR module. Yeah, about 3 seconds after hitting send I realized that with PIPE support CMSDDR becomes as simple as DDR FOO BAR A | OUTFILE DDR B, so I didn't need CMSDDR any longer anyway. Cool. Thanks for making it happen. Beer's on us next time I'm in Endicott. -- db
Re: DDR'ing 3390 DASD To Remote Location
On Tuesday, 08/19/2008 at 01:49 EDT, David Boyes [EMAIL PROTECTED] wrote: Have you talked to the product owner? There is an open requirement against DDR that you could be a hero by helping them close it. LOL. George left one small thing off of his signature: z/VM I/O Development IBM Endicott Alan Altmark z/VM Development IBM Endicott
Re: DDR'ing 3390 DASD To Remote Location
Details details details.! Thanks Alan Altmark wrote: On Tuesday, 08/19/2008 at 01:49 EDT, David Boyes [EMAIL PROTECTED] wrote: Have you talked to the product owner? There is an open requirement against DDR that you could be a hero by helping them close it. LOL. George left one small thing off of his signature: z/VM I/O Development IBM Endicott Alan Altmark z/VM Development IBM Endicott -- 'in media stat virtus' Virtue's in the middle
Re: DDR'ing 3390 DASD To Remote Location
On Tue, 19 Aug 2008 13:21:40 -0400 Jiri Stehlik said: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. I have the latest CMS PIPLINES but it doesn't include FTPGET and FTPPUT. I can't find them on the IBM Download site either. Where can I get them? /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock --
Re: DDR'ing 3390 DASD To Remote Location
On Aug 19, 2008, at 1:39 PM, Fran Hensler wrote: On Tue, 19 Aug 2008 13:21:40 -0400 Jiri Stehlik said: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. I have the latest CMS PIPLINES but it doesn't include FTPGET and FTPPUT. I can't find them on the IBM Download site either. Where can I get them? Run INSTPIPE MODULE from MAINT 2CC. Adam
Re: DDR'ing 3390 DASD To Remote Location
LOL. George left one small thing off of his signature: z/VM I/O Development IBM Endicott Alan Altmark z/VM Development IBM Endicott Well, far be it from me that I suggest that VM Development begin to talk to themselves. You lot 're odd enough to begin with...8-) -- db
Re: DDR'ing 3390 DASD To Remote Location
Hello, I compiled the FTPPUT and FTPGET pipe stages into the DRPC Module. So once you execute it, three pipe-stages (FTPPUT, FTPGET and DDR) will get registered. -George (on Alan's insistance): z/VM I/O Development IBM Endicott The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 08/19/2008 02:39:55 PM: On Tue, 19 Aug 2008 13:21:40 -0400 Jiri Stehlik said: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. I have the latest CMS PIPLINES but it doesn't include FTPGET and FTPPUT. I can't find them on the IBM Download site either. Where can I get them? /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock --
Re: DDR'ing 3390 DASD To Remote Location
On Aug 19, 2008, at 1:48 PM, David Boyes wrote: Well, far be it from me that I suggest that VM Development begin to talk to themselves. You lot 're odd enough to begin with...8-) As Zork so eloquently put it, Talking to yourself is said to be a sign of impending mental collapse. Adam
Re: DDR'ing 3390 DASD To Remote Location
As Zork so eloquently put it, Talking to yourself is said to be a sign of impending mental collapse. You see, I was never worried about it when I talked to myself. I only started to wonder when I started ANSWERING myself. That's when even the wife and kids leave the room and stay out of my way! (as they probably should!!) Ed Zell Illinois Mutual Life (309) 636-0107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: DDR'ing 3390 DASD To Remote Location
On Aug 19, 2008, at 1:39 PM, Fran Hensler wrote: I have the latest CMS PIPLINES but it doesn't include FTPGET and FTPPUT. I can't find them on the IBM Download site either. Where can I get them? On Tue, 19 Aug 2008 13:48:20 -0500 Adam Thornton said: Run INSTPIPE MODULE from MAINT 2CC. I'm stuck on z/VM 3.1 because I am on a FLEX-ES box. I found INST* files on MAINT 2C2 but not FTPGET or FTPPUT. I have the latest Princeton Runtime Distribution but there is no FTPGET or FTPPUT stages. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 45 years mailto:[EMAIL PROTECTED] http://zvm.sru.edu/~fjh +1.724.738.2153 Yes, Virginia, there is a Slippery Rock --
Re: DDR'ing 3390 DASD To Remote Location
As Zork so eloquently put it, Talking to yourself is said to be a sign of impending mental collapse. I prefer to think of this as discussing the problem with the person who understands it the best. That's my story and I'm sticking with it. Nora Graves
Re: DDR'ing 3390 DASD To Remote Location
On Aug 19, 2008, at 2:29 PM, Fran Hensler wrote: On Aug 19, 2008, at 1:39 PM, Fran Hensler wrote: I have the latest CMS PIPLINES but it doesn't include FTPGET and FTPPUT. I can't find them on the IBM Download site either. Where can I get them? On Tue, 19 Aug 2008 13:48:20 -0500 Adam Thornton said: Run INSTPIPE MODULE from MAINT 2CC. I'm stuck on z/VM 3.1 because I am on a FLEX-ES box. I found INST* files on MAINT 2C2 but not FTPGET or FTPPUT. I have the latest Princeton Runtime Distribution but there is no FTPGET or FTPPUT stages. Fortunately, then, they are in the DDR stage that George just added. The stages appeared in 5.1 to support the DVD install of z/VM. I would not expect earlier releases to have them on MAINT 2CC. Adam
Re: DDR'ing 3390 DASD To Remote Location
Now if we could get the TERSE/DETERSE stages added, we might get these du mps down to a better size for transferring cross-country. /Tom Kern /301-903-2211 On Tue, 19 Aug 2008 14:49:38 -0400, Jiri Stehlik [EMAIL PROTECTED] wro te: Hello, I compiled the FTPPUT and FTPGET pipe stages into the DRPC Module. So o nce you execute it, three pipe-stages (FTPPUT, FTPGET and DDR) will get registered. -George (on Alan's insistance): z/VM I/O Development IBM Endicott
Re: DDR'ing 3390 DASD To Remote Location
Use VMARC. It will get them down and the support folks know how to handle them in that format. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Tuesday, August 19, 2008 1:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Now if we could get the TERSE/DETERSE stages added, we might get these du= mps down to a better size for transferring cross-country. /Tom Kern /301-903-2211 On Tue, 19 Aug 2008 14:49:38 -0400, Jiri Stehlik [EMAIL PROTECTED] wro= te: Hello, I compiled the FTPPUT and FTPGET pipe stages into the DRPC Module. So o= nce you execute it, three pipe-stages (FTPPUT, FTPGET and DDR) will get registered. -George (on Alan's insistance): z/VM I/O Development IBM Endicott
Re: DDR'ing 3390 DASD To Remote Location
Does VMARC work as a pipe stage? Writing 3390-m9s as cms files and then reading then, compressing them and writing them as cms files is too much I/O for the process. A pipe stage to properly compress the piped input is necessary for efficiency. The PACK stage can be used but it doesn't buy y ou as much as other well-known compression algorithms. Being able to use the LZCOMPACT option on the DDR OUTPUT control statement might make the outpu t small enough to then use PACK simply to maintain record boundaries nicely and possibly to keep the data in a buffer size that is good for an encryption stage. /Tom Kern /301-903-2211 On Tue, 19 Aug 2008 13:22:27 -0700, Schuh, Richard [EMAIL PROTECTED] wrot e: Use VMARC. It will get them down and the support folks know how to handle them in that format. Regards, Richard Schuh
Re: DDR'ing 3390 DASD To Remote Location
No. it doesn't. Keep plugging for a way. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Tuesday, August 19, 2008 1:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Does VMARC work as a pipe stage? Writing 3390-m9s as cms files and then reading then, compressing them and writing them as cms files is too much = I/O for the process. A pipe stage to properly compress the piped input is necessary for efficiency. The PACK stage can be used but it doesn't buy y= ou as much as other well-known compression algorithms. Being able to use the= LZCOMPACT option on the DDR OUTPUT control statement might make the outpu= t small enough to then use PACK simply to maintain record boundaries nicely= and possibly to keep the data in a buffer size that is good for an encryption stage. /Tom Kern /301-903-2211 On Tue, 19 Aug 2008 13:22:27 -0700, Schuh, Richard [EMAIL PROTECTED] wrot= e: Use VMARC. It will get them down and the support folks know how to handle them in that format. Regards, Richard Schuh
SECUSER
I have a service machine the runs with MSG set to IUCV. If I enter the command SET SECUSER svcid *, messages are displayed on my console rather than being sent to the IUCV handler. The messages do not get displayed on the console if I log on to the id; why should they be reflected to the SECUSER console and not the IUCV handler? Is the behavior documented anywhere? I did not see it under either SET SECUSER or SET MSG IUCV. Looking at SCIF doesn't seem too productive, either. Regards, Richard Schuh
First time z/VM installer
I am new to z/VM and am sure to have a lot of questions. My first is about documentation. I did not receive a copy of the z/VM Guide for Automated Installation and Service with my 5.3 SDO. Should I have gotten this? It sure appears from the program directories for the SDO and for z/VM that I should have. I also learned at SHARE that there is a one-sheet reference for installation and I did not get that either. Myabe this is how SDOs are delivered but since it is all new to me I thought I should sak. Thanks! Susan
Re: SECUSER
On Tuesday, 08/19/2008 at 05:22 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: I have a service machine the runs with MSG set to IUCV. If I enter the command SET SECUSER svcid *, messages are displayed on my console rather than being sent to the IUCV handler. The messages do not get displayed on the console if I log on to the id; why should they be reflected to the SECUSER console and not the IUCV handler? Is the behavior documented anywhere? I did not see it under either SET SECUSER or SET MSG IUCV. Looking at SCIF doesn't seem too productive, either. Ah, one of the Great Schisms. See the 3rd from the last paragraph in the description of *MSG in the CP Programming Services book: If a virtual machine has both a valid path to *MSG and a functioning secondary user, incoming messages (except for SMSGs, which are not console messages) are directed to the secondary user instead of the IUCV *MSG path to the primary user. You can't use SCIF to monitor the behavior of a user connected to *MSG. I don't recall if SET OBSERVER has the same effect or not. And in case you're confused, VM/SP and VM/XA handled this differently. VM/SP handled this the Right and Proper Way. VM/XA did it the Horrible and Evil Way. I still hold a grudge. Alan Altmark z/VM Development IBM Endicott
Re: SECUSER
Richard, It is working as it has for a long time.. The *MSG system Service description in the Programming Services manual describes just what you are seeing. See Chapter 17 of CP Programming Services If a virtual machine has both a valid path to *MSG and a functioning secondary user, incoming messages (except for SMSGs, which are not console messages) are directed to the secondary user instead of the IUCV *MSG path to the primary user. Regards, Dan Griffith The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 08/19/2008 05:21:51 PM: SECUSER Schuh, Richard to: IBMVM 08/19/2008 05:22 PM Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Please respond to The IBM z/VM Operating System I have a service machine the runs with MSG set to IUCV. If I enter the command SET SECUSER svcid *, messages are displayed on my console rather than being sent to the IUCV handler. The messages do not get displayed on the console if I log on to the id; why should they be reflected to the SECUSER console and not the IUCV handler? Is the behavior documented anywhere? I did not see it under either SET SECUSER or SET MSG IUCV. Looking at SCIF doesn't seem too productive, either. Regards, Richard Schuh
IPGATE requirement
Has anyone ever submitted a requirement that this function (needed to share SFS across IP) be added to the product and formally supported? Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
Re: IPGATE requirement
On Tuesday, 08/19/2008 at 06:04 EDT, Marcy Cortes [EMAIL PROTECTED] wrote: Has anyone ever submitted a requirement that this function (needed to share SFS across IP) be added to the product and formally supported? There is an open requirement for this function. Alan Altmark z/VM Development IBM Endicott
Re: IPGATE requirement
Cool. Was it accepted? Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Tuesday, August 19, 2008 3:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] IPGATE requirement On Tuesday, 08/19/2008 at 06:04 EDT, Marcy Cortes [EMAIL PROTECTED] wrote: Has anyone ever submitted a requirement that this function (needed to share SFS across IP) be added to the product and formally supported? There is an open requirement for this function. Alan Altmark z/VM Development IBM Endicott
Re: First time z/VM installer
Hi, Susan. I don't know if the documents you mention should have been shipped or not, but in any case, IBM makes all of the VM doc available online, in both PDF and Book format. For all of the general z/VM publications, go here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/hcsh2a90 To snag a copy of the z/VM Guide for Automated Installation and Service, and the one sheet reference, go here: http://www.vm.ibm.com/pubs/index.html Good luck, and welcome to z/VM! Susan Barron wrote: I am new to z/VM and am sure to have a lot of questions. My first is about documentation. I did not receive a copy of the z/VM Guide for Automated Installation and Service with my 5.3 SDO. Should I have gotten this? It sure appears from the program directories for the SDO and for z/VM that I should have. I also learned at SHARE that there is a one-sheet reference for installation and I did not get that either. Myabe this is how SDOs are delivered but since it is all new to me I thought I should sak. Thanks! Susan -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: First time z/VM installer
Hi Susan. Welcome. Yes you should have received the documentation. Look for the z/VM SDO program directory which describes the install in more detail. Don't forget to request the buckets as documented. http://www.vm.ibm.com/sdo/sdozvm53.html Hans -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Susan Barron Sent: August 19, 2008 5:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: First time z/VM installer I am new to z/VM and am sure to have a lot of questions. My first is about documentation. I did not receive a copy of the z/VM = Guide for Automated Installation and Service with my 5.3 SDO. Should I = have gotten this? It sure appears from the program directories for the = SDO and for z/VM that I should have. I also learned at SHARE that there is a one-sheet reference for installation and I did not get that either. Myabe this is how SDOs are delivered but since it is all new to me I thought I should sak. Thanks! Susan
Re: DDR'ing 3390 DASD To Remote Location
Thanks George. Works really well. Ran backup of VMSRES (mod3) in 8 minutes using LZ and pack (600MB) to my desktop and the restore of a mdisk from the backup worked just fine. Thanks very much. Hans -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jiri Stehlik Sent: August 19, 2008 1:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: DDR'ing 3390 DASD To Remote Location A while ago there was a thread here about the ability to DDR DASD to remote location. Well there is an answer! I modified DDR so it can communicate with CMS PIPES (DDR can now be a pipe stage). The modules can be downloaded from here: http://www.vm.ibm.com/download/packages/descript.cgi?DRPC The FTPPUT and FTPGET PIPE stages were also included and documented at the above address. Notice that this project is still a work in progress, therefore feedback is welcomed! -George
Re: SECUSER
Thanks Alan. I have found a way to use SMSG, so I have circumvented a design feature. So it is documented. That does not alter the fact that the treatment of the MSG traffic seems to be somewhat inconsistent. If the id has a logon console, the messages are sent to the *MSG trap, regardless of whether there is a SECUSER. If the id is disconnected, the messages are trapped if there is no SECUSER or there is one that does not happen to be logged on, but are sent to the SECUSER if there is one who is logged on. To me, this violates the Principle of Least Astonishment. Is there some good reason why it works like this? It would be more consistent if the things that are set to be trapped by IUCV or SMSG were treated the same in all cases. After all, if it is OK for the machine to process the messages in most cases, why is it not OK in this one instance? I understand, and now share, your grudge. This is one of those things that may be BAD, but has been around for so long that it probably can't be fixed without upsetting a lot of users. (For the uninitiated, BAD is an acronym for Broken As Designed.) Has there been a replacement assigned to take over the Ombudsman role since Lyn Hadley held the post. Speaking of Lyn, has anyone heard from him recently? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Tuesday, August 19, 2008 2:59 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SECUSER On Tuesday, 08/19/2008 at 05:22 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: I have a service machine the runs with MSG set to IUCV. If I enter the command SET SECUSER svcid *, messages are displayed on my console rather than being sent to the IUCV handler. The messages do not get displayed on the console if I log on to the id; why should they be reflected to the SECUSER console and not the IUCV handler? Is the behavior documented anywhere? I did not see it under either SET SECUSER or SET MSG IUCV. Looking at SCIF doesn't seem too productive, either. Ah, one of the Great Schisms. See the 3rd from the last paragraph in the description of *MSG in the CP Programming Services book: If a virtual machine has both a valid path to *MSG and a functioning secondary user, incoming messages (except for SMSGs, which are not console messages) are directed to the secondary user instead of the IUCV *MSG path to the primary user. You can't use SCIF to monitor the behavior of a user connected to *MSG. I don't recall if SET OBSERVER has the same effect or not. And in case you're confused, VM/SP and VM/XA handled this differently. VM/SP handled this the Right and Proper Way. VM/XA did it the Horrible and Evil Way. I still hold a grudge. Alan Altmark z/VM Development IBM Endicott
Re: SECUSER
On Tuesday, 08/19/2008 at 07:25 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: Is there some good reason why it works like this? It would be more consistent if the things that are set to be trapped by IUCV or SMSG were treated the same in all cases. After all, if it is OK for the machine to process the messages in most cases, why is it not OK in this one instance? I understand, and now share, your grudge. I could understand the CONSOLE-based SCIF as having this bizzare-o behavior, I suppose, but SET SECUSER/OBSERVER probably would have been well-served to include an option for the watcher to decide whether you get a) SET SECUSER userid * PITA the message instead of it going to *MSG b) SET SECUSER userid * SNIFFER an annotated message AND it goes to *MSG c) SET SECUSER userid * only messages not trapped by *MSG (as the Gods intended) For those times when you want different things. This is one of those things that may be BAD, but has been around for so long that it probably can't be fixed without upsetting a lot of users. (For the uninitiated, BAD is an acronym for Broken As Designed.) I remember many heated arguments during VM/ESA 1.0 development. I also remember losing. (I had just started by stint in System Test.) Everyone KNOWS that the Prime Directive should apply to SCIF. Watching a server should not change its behavior. It makes debugging REXECD a pain. grump See Grudge. Has there been a replacement assigned to take over the Ombudsman role since Lyn Hadley held the post. I like to think that those of us who hang out here do a pretty good job, even if no one has the formal title. :-) Alan Altmark z/VM Development IBM Endicott
Re: SECUSER
On Tue, Aug 19, 2008 at 11:58 PM, Alan Altmark [EMAIL PROTECTED] wrote: Ah, one of the Great Schisms. See the 3rd from the last paragraph in the description of *MSG in the CP Programming Services book: What troubles me is that the folks in IBM who push the new automated operator product seem to have missed this part of their education. Apparently the documentation suggests that you can simply set secuser all over the place to manage virtual machines. And as we know this breaks the ability for the victim to process *MSG. Rob -- Rob van der Heij Velocity Software http://velocitysoftware.com/
Re: IPGATE requirement
On Tuesday, 08/19/2008 at 06:12 EDT, Marcy Cortes [EMAIL PROTECTED] wrote: Cool. Was it accepted? I see three requirements out there. One (general case of APPC-over-IP) is a Suggestion and the other two (Performance Toolkit) are Recognized. Alan Altmark z/VM Development IBM Endicott
Re: SECUSER
The SET OBSERVER command is working the right way, i.e. it won't take MSGs away from the *MSG IUCV handler. I tested this the first day I had a VM system with SET OBSERVER. I use it since then to debug SVMs that connect to *MSG(ALL). Can one use SET OBSERVER then without *any* side effect? No: an OBSERVED user cannot have a SECUSER at the same time. 2008/8/19 Alan Altmark [EMAIL PROTECTED]: On Tuesday, 08/19/2008 at 05:22 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: I have a service machine the runs with MSG set to IUCV. If I enter the command SET SECUSER svcid *, messages are displayed on my console rather than being sent to the IUCV handler. The messages do not get displayed on the console if I log on to the id; why should they be reflected to the SECUSER console and not the IUCV handler? Is the behavior documented anywhere? I did not see it under either SET SECUSER or SET MSG IUCV. Looking at SCIF doesn't seem too productive, either. Ah, one of the Great Schisms. See the 3rd from the last paragraph in the description of *MSG in the CP Programming Services book: If a virtual machine has both a valid path to *MSG and a functioning secondary user, incoming messages (except for SMSGs, which are not console messages) are directed to the secondary user instead of the IUCV *MSG path to the primary user. You can't use SCIF to monitor the behavior of a user connected to *MSG. I don't recall if SET OBSERVER has the same effect or not. And in case you're confused, VM/SP and VM/XA handled this differently. VM/SP handled this the Right and Proper Way. VM/XA did it the Horrible and Evil Way. I still hold a grudge. Alan Altmark z/VM Development IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support
Re: SECUSER
On Wednesday, 08/20/2008 at 12:50 EDT, Rob van der Heij [EMAIL PROTECTED] wrote: On Tue, Aug 19, 2008 at 11:58 PM, Alan Altmark [EMAIL PROTECTED] wrote: Ah, one of the Great Schisms. See the 3rd from the last paragraph in the description of *MSG in the CP Programming Services book: What troubles me is that the folks in IBM who push the new automated operator product seem to have missed this part of their education. Apparently the documentation suggests that you can simply set secuser all over the place to manage virtual machines. And as we know this breaks the ability for the victim to process *MSG. I'll have to let someone who has factual knowledge of the product answer that question. Alan Altmark z/VM Development IBM Endicott
Re: First time z/VM installer
Susan, I deliver the z/VM Installation - From Cardboard Box to IPL session at SHARE, and point out the difference between the 2-sided tri-fold Summary and the much more detailed Guide (the full manual). The session also includes the URLs for the these any other IBM z/VM installation documents. Yes, unless something has changed very recently in the z/VM 5.3 delivery, you should have received both documents (the tri-fold Summary both for Tape and DVD installations; and the full manual Guide). Check the printed IBM inventory sheets that came with the order to see if they were back-ordered (which would be rather surprising). That checking the order suggestion is also in the same SHARE session. See the session handout at: http://ew.share.org/proceedingmod/abstract.cfm?abstract_id=18663 And for those who cannot see the SHARE proceedings, that session and many others should soon be out on: http://linuxvm.org/Present/index.html Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Susan Barron [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 08/19/2008 04:57 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject First time z/VM installer I am new to z/VM and am sure to have a lot of questions. My first is about documentation. I did not receive a copy of the z/VM Guide for Automated Installation and Service with my 5.3 SDO. Should I have gotten this? It sure appears from the program directories for the SDO and for z/VM that I should have. I also learned at SHARE that there is a one-sheet reference for installation and I did not get that either. Myabe this is how SDOs are delivered but since it is all new to me I thought I should sak. Thanks! Susan 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.
