Version 4 to Version 5
In changing a z/VM system from Version 4 to Version 5: 1) is there any problem with the V5 system using the existing spool files of V4? 2) Can SFS servers that were running V4 simply be started up with the SFS servers of V5 on the same mdisks? I tried one SFS server and it failed to come up until I ran a FILESERV BACKUP. Was this some local problem, or did I do something wrong? Of course I did not use live data - I DDR'd all of the mdisks of the server to copies, and tried to run the new server on them. Thanks, Shimon -- Shimon Lebowitzmailto:shim...@iname.com VM System Programmer . Israel Police National HQ. Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308
Re: Deeper and deeper into the REXX rabbit hole - Signal on ERROR messages
You got me... almost exactly one year ago I updated all my EXECs to become 'RTNSTATE DMSINXED' if Rc0 then do; 'SUBCOM XEDIT' ; Xedit=(rc=0); end else do; call csl 'DMSINXED RETC REAS T'; Xedit=(reas=0 t=0) ; end But, this SIGNAL SAMPEXEC didn't have filetype EXEC (nor XEDIT, nor REXX), hence I missed it. 2009/3/16 Alan Altmark alan_altm...@us.ibm.com On Saturday, 03/14/2009 at 08:25 EDT, Kris Buelens kris.buel...@gmail.com wrote: /***/ ERREXIT: /* exit with retcode errormsg */ /***/ address '' 'SUBCOM XEDIT' xedit=(rc=0) if xedit then address xedit 'COMMAND SET MSGM ON' do i=2 to 'ARG'() if xedit then address xedit 'COMMAND EMSG' 'ARG'(i) else say 'ARG'(i) end Hmmm... I thought we had stamped out this programming idiom several years ago when we introduced DMSCALLR. Most people expect the above snippet to diplay the error in XEDIT if you're in XEDIT when the error occurs. All it really tells you is that XEDIT is active *somewhere* in the command sequence. To see for yourself, go into XEDIT, the into CMS subset mode, then issue a failing exec with the above code. You won't see the messages until you RETURN to XEDIT. Here's the Official Way to find out if your exec is running in XEDIT. That is to say, such that you will immediately see the output if you use COMMAND EMSG. InXEDIT: /* EXEC runtime environments */ execenv = CMS EXEC CMSMIXED DMSRTPRC EAGTPRC VRX$EXEC PRX$EXEC /* Run the caller chain. Skip level 0 and 1 because they */ /* are always RXCSL and EXEC. */ do level = 2 by 1 until csl_rc 0 Call CSL DMSCALLR csl_rc callee level callee = strip( left(callee, 8) ) If csl_rc = 0 wordpos(callee, execenv)= 0 then do if callee = XEDIT then return 1 else return 0 end end return 0 I asked Chuckie if he cared to comment, and he opened one eye and stared at me. (Creepy, I have to tell you - turns out he was asleep!) Upon wakening, later, he provided this Unofficial Solution based on the undocumented DMSINXED found in various product execs. InXEDIT: call CSL DMSINXED csl_rc csl_reason in_xedit if csl_rc = 0 in_xedit = 0 then return 1 return 0 Alan Altmark z/VM Development IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support
Re: Version 4 to Version 5
I went from V4 to V5 without any special treatment for spool nor SFS. I work like this since about VM/ESA R2.2. That is, I re-use the spool space of my old VM in the new release. For SFS, I simply started them with the new CMS level (most of the time, when I do that I have an eye on the SFS starting up). More detailed: in my installations - switching CP means copying a new CP module on CF1 and IPL - switching CMS means using another MDISK as MAINT 190 No mass DDR copies of mdisks involved. 2009/3/16 Shimon Lebowitz shim...@iname.com: In changing a z/VM system from Version 4 to Version 5: 1) is there any problem with the V5 system using the existing spool files of V4? 2) Can SFS servers that were running V4 simply be started up with the SFS servers of V5 on the same mdisks? I tried one SFS server and it failed to come up until I ran a FILESERV BACKUP. Was this some local problem, or did I do something wrong? Of course I did not use live data - I DDR'd all of the mdisks of the server to copies, and tried to run the new server on them. Thanks, Shimon -- Shimon Lebowitzmailto:shim...@iname.com VM System Programmer . Israel Police National HQ. Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308 -- Kris Buelens, IBM Belgium, VM customer support
Re: Deeper and deeper into the REXX rabbit hole - Signal on ERROR messages
On Mon, Mar 16, 2009 at 8:41 AM, Kris Buelens kris.buel...@gmail.com wrote: You got me... almost exactly one year ago I updated all my EXECs to become 'RTNSTATE DMSINXED' if Rc0 then do; 'SUBCOM XEDIT' ; Xedit=(rc=0); end else do; call csl 'DMSINXED RETC REAS T'; Xedit=(reas=0 t=0) ; end But, this SIGNAL SAMPEXEC didn't have filetype EXEC (nor XEDIT, nor REXX), hence I missed it. So we can conclude that you have not written any new REXX code since a year or don't use your own standards ;-) I really hate the approach to show CMS error messages as XEDIT MSG (even when the EXEC was invoked directly from the command line). I've often stared at the line mode output in HOLDING to see why it did not behave correct, only to get the VMLINK message after you get back in FILELIST. Weird enough the CP errors don't follow that path. For XEDIT macros its different since they are meant to do things with your editor. But for EXEC it is often less helpful. Rob
Greg Rehn is out of the office.
I will be out of the office starting 03/16/2009 and will not return until 03/24/2009. For technical issues that can't wait, please contact my backup, Dennis Hermann, at (309) 266-1222 or Cell: (309) 678-0814
Re: Deeper and deeper into the REXX rabbit hole - Signal on ERROR messages
Most of my execs do indeed not send their messages to XEDIT (I've got got less than 10 EXECs that do), for exactly the reasons you mention. My former IBM colleague who also worked years for my famous ex-customer, he though had a SUBCOM XEDIT test in his standard REXX skeleton, much to my regrets... 2009/3/16 Rob van der Heij rvdh...@gmail.com: On Mon, Mar 16, 2009 at 8:41 AM, Kris Buelens kris.buel...@gmail.com wrote: You got me... almost exactly one year ago I updated all my EXECs to become 'RTNSTATE DMSINXED' if Rc0 then do; 'SUBCOM XEDIT' ; Xedit=(rc=0); end else do; call csl 'DMSINXED RETC REAS T'; Xedit=(reas=0 t=0) ; end But, this SIGNAL SAMPEXEC didn't have filetype EXEC (nor XEDIT, nor REXX), hence I missed it. So we can conclude that you have not written any new REXX code since a year or don't use your own standards ;-) I really hate the approach to show CMS error messages as XEDIT MSG (even when the EXEC was invoked directly from the command line). I've often stared at the line mode output in HOLDING to see why it did not behave correct, only to get the VMLINK message after you get back in FILELIST. Weird enough the CP errors don't follow that path. For XEDIT macros its different since they are meant to do things with your editor. But for EXEC it is often less helpful. Rob -- Kris Buelens, IBM Belgium, VM customer support
Re: Version 4 to Version 5
Shimon, Was your SFS server up and running when you DDR'd it? If so, it's likely some data changed while your DDR was running causing you to end up with a dirty copy of the FilePool. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 steven.im...@ca.com -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Monday, March 16, 2009 02:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Version 4 to Version 5 In changing a z/VM system from Version 4 to Version 5: 1) is there any problem with the V5 system using the existing spool files of V4? 2) Can SFS servers that were running V4 simply be started up with the SFS servers of V5 on the same mdisks? I tried one SFS server and it failed to come up until I ran a FILESERV BACKUP. Was this some local problem, or did I do something wrong? Of course I did not use live data - I DDR'd all of the mdisks of the server to copies, and tried to run the new server on them. Thanks, Shimon -- Shimon Lebowitzmailto:shim...@iname.com VM System Programmer . Israel Police National HQ. Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308
Re: Deeper and deeper into the REXX rabbit hole - Signal on ERROR messages
Alan Altmark wrote:
Hmmm... I thought we had stamped out this programming idiom several years
ago when we introduced DMSCALLR. Most people expect the above snippet to
diplay the error in XEDIT if you're in XEDIT when the error occurs. All
it really tells you is that XEDIT is active *somewhere* in the command
sequence.
To see for yourself, go into XEDIT, the into CMS subset mode, then issue a
failing exec with the above code. You won't see the messages until you
RETURN to XEDIT.
snip
InXEDIT:
call CSL DMSINXED csl_rc csl_reason in_xedit
if csl_rc = 0 in_xedit = 0 then return 1
return 0
Verrry interesting. I've always used the SUBCOM XEDIT + (not)CMSFLAG('SUBSET')
version, which has never (to my knowledge) failed me. But knowing there's a
supported (if undocumented and therefore changeable yadda yadda) version is
great!
...phsiii
Re: Deeper and deeper into the REXX rabbit hole - Signal on ERROR messages
Being a major fan of INTERPRET, I've had to deal with many similar
situations - it's a question of the number of the number of indirection
levels. I've added a line to your error routine below to display what yo
u
are looking for.
/* */
SIGNAL ON ERROR
cmd='CP THIS WILL FAIL'
/* There may be a leading comment on this line */ cmd /* There may
be a trailing comment on this line, too */
say cmd', rc='rc
EXIT
/* */
Error:
say '+++ ERROR: error rtn entered in:' xfn xft xfm', rc='rc
say '+++ from line:' sigl', which reads:'
say '+++'sourceline(sigl)
cmdline=strip(sourceline(sigl),'B')
say '+++ which translates to:' value('CMDLINE')
INTERPRET 'say +++ which translates to:' cmdline
EXIT
Brian Nielsen
On Fri, 13 Mar 2009 18:00:38 -0500, Mike Walter mike.wal...@hewitt.com
wrote:
Over the years I've enhanced our sample boilerplate DOCREXX EXEC which
most application developers use to start new REXX execs.
The subroutines for SIGNAL ON SYNTAX, SIGNAL ON NOVALUE, and SIGNAL ON
ERROR have presented interesting challenges over those years. What has
been developed seems to do a pretty good job except in the case of
providing truly useful command failure information for a sequence such a
s:
---snip---
SIGNAL ON ERROR
cmd='CP THIS WILL FAIL'
/* There may be a leading comment on this line */ cmd /* There may
be a trailing comment on this line, too */
say cmd', rc='rc
---snip---
When the sample error subroutine executes, it easily displays some usefu
l
information:
---snip---
Error:
say '+++ ERROR: error rtn entered in:' xfn xft xfm', rc='rc
say '+++ from line:' sigl', which reads:'
say '+++'sourceline(sigl)
cmdline=strip(sourceline(sigl),'B')
say '+++ which translates to:' value('CMDLINE')
---snip---
But in the above example, the: '+++ which translates to:' value('CMDLINE
')
would only display : +++ which translates to: cmd
well, that's not so very useful. One would hope to see: +++ which
translates to: CP THIS WILL FAIL
I've tried various permutations of: say '+++ which translates to:'
value('CMDLINE')
but that introduces complications when the line is not a variable {ok, I
f
symbol(value('CMDLINE'))-'VAR' then ... }
and that introduce even more complications when the line contains commen
ts
as in the aforementioned:
/* There may be a leading comment on this line */ cmd /* There may
be a trailing comment on this line, too */
Granted, that's a fairly perverted line of code, but not unseen.
So... does anyone have some pretty rock-solid examples of Error, Syntax,
and Novalue subroutines that they'd be willing to share?
Too bad that the rexx manuals don't provide some nice, proven,
tried-and-tested samples what everyone could use as a starting point.
TIA
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
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-mail
s
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: Defining SCSI disk to z/VM
Fred, At our site we have our HCD under zOS. We define the fcp devices in zO S as FCP. We use 3390 DASD for linux root and fcp disks for linux data only . I donot define anything special in SYSTEM CONFIG, other than insuring tha t the devices are online at IPL : Online_at_IPL 6000-6FFF For each guest that will use fcp disk, I code a DEDICATE statement and to help the linux administrators I use a standard address for all fcp disks : DEDICATE 2107 600F The lun and wwpn assignments are all made within linux, so I donot have to be concerned about EDEV or MDISK statements. Bob
FW: ASSEMBLER-LIST Digest - 14 Mar 2009 to 15 Mar 2009 (#2009-72)
More on asynch exits -Original Message- From: IBM Mainframe Assembler List [mailto:assembler-l...@listserv.uga.edu] On Behalf Of Automatic digest processor Sent: Monday, March 16, 2009 12:04 AM To: Recipients of ASSEMBLER-LIST digests Subject: ASSEMBLER-LIST Digest - 14 Mar 2009 to 15 Mar 2009 (#2009-72) There are 6 messages totalling 247 lines in this issue. Topics of the day: 1. Asynchronous Exits:- How do they work? (5) 2. Asynchronous Exits:- How do they work? a followup question -- Date:Sun, 15 Mar 2009 14:08:20 +0100 From:Abe Kornelis a...@bixoft.nl Subject: Re: Asynchronous Exits:- How do they work? Ludmil, Tom, all, A small addition to Tom's original explanation: IRBs are slightly different. When some function of the operating system or some code you have written wants to interrupt the current TCB RB, it creates an IRB (Interruption Request Block), and then calls the operating system to queue the IRB to the RB chain. **-- Be aware that the interrupt may be processed on one processor while your TCB is executing on another one, That's why the TCB and RB chain must be locked while adding to the queue. I think it is the local lock that serves this purpose - but do double-check me on that one as I'm doing this from memory. If the TCB is currently not running, then the IRB gets control immediately **-- or rather, the next time the dispatcher elects the TCB for execution (the process represented by the IRB), and when the IRB completes, the TCB is left in the same state as before. **-- That is, after the IRB process completes, it returns to the OS which will issue an SVC 3 to pop the IRB. The RB chain is then back to its original state and the next dispatch of the TCB will resume the executing RB where it last ended. If the TCB was currently running, the IRB is not actually dispatched until the TCB is interrupted for some other reason. **-- Exactly. The IRB is appended to the RB chain, but the RB executing on behalf of the TCB will carry on, until it is interrupted itself. Then, as soon as the dispatcher next selects the TCB for execution on an processor, it will find the new IRB on top of the RB chain, so the IRB gets executed. When it ends, you get SVC 3 to pop the RB and again the dispatcher will schedule the top RB - which might well be the RB running when the IRB was first created. Other IRBs might have gotten in between, though. Anyway, by the time your application RB regains control, it will be in the usual way - and your app will never be able to tell whether, where, or when it might have been interrupted. The exceptional case is when the application RB issues SVC 3 before the IRB has been scheduled. I do not know what happens in this case. Could be SVC 3 logic will issue an abend. Or it might process the IRB before popping the RB that issued SVC 3. It would be hard to imagine SVC 3 would quietly pop any RB that is not on the top of the RB chain and quietly discard any unfinished RBs on the chain... Cheers, Abe Kornelis. = -- Date:Sun, 15 Mar 2009 09:45:12 -0400 From:Jaya Relim jayare...@hotmail.com Subject: Re: Asynchronous Exits:- How do they work? a followup question Then as per your note, the state information is stored on the RB. When ETXR gains control the TCB ID is in Reg1. Fine, I can use Reg1 to detach the daughter. Then say before I do a BR 14, I need to use a few regs, can I assume that their contents will be restored by system soon after the BR 14, without me actually saving the Regs and restoring them. Yes, but you do need to restore R14 (which should end up pointing to an SVC3) or you could simply invoke SVC3 instead of BR14. On Sat, 14 Mar 2009 19:19:11 -0400, Ludmila Koganer ludmilakoga...@yahoo.com wrote: Tom, Thank You so Much for having taken time to clarify. I think I have a follow up question. Say I have a ETXR on the main task. This gets control at some time after the daughter ends. ETXR gets control through a IRB. I follow upto this point clearly and also the description about RBs in general. Then as per your note, the state information is stored on the RB. When ETXR gains control the TCB ID is in Reg1. Fine, I can use Reg1 to detach the daughter. Then say before I do a BR 14, I need to use a few regs, can I assume that their contents will be restored by system soon after the BR 14, without me actually saving the Regs and restoring them. As a followup, will this work if the main task was executing a interruptible instruction like a MVCL which had Reg1 as one of its operands. If it is true that the system will always restore the current state prior to the execution of IRB, then ETXR is the best practice to code, isnt it? unless ofcourse the program really requires wait and post with ecb. Thanks again for your time as well as others who replied. I
Re: I want to know how command line on z/vm.
When you log on to the z/VM system you are presented with a command line. Do you have a z/VM session with the z9 system? If so, log on with your user id and password. นักรบ SPARTANS Talubthaisong wrote: Dear. Sir I has Operate IBM System z9 Enterprise Class and include z/vm. I want to know how command line on z/vm. Can You help me. Thank. */somkid T.lub/* -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: Merging DirMaint?
Thank you, David. It was enlightening to discover what 'gerrymander' means. ;-) I appreciate the help. Regards, Dave -Original Message- From: David Kreuter dkreu...@vm-resources.com Reply-to: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Merging DirMaint? Date: Thu, 12 Mar 2009 16:14:01 -0400 Hi Dave: for the directories on each system what I would do: 1. DIRM USER WITHPASS 2. RECEIVE the spool file as nodename WITHPASS - so you have a good copy of each systems directoy 3. Record by hand the volser where each directory is getting loaded onto 4. for each system run a DIRM SCAN USER and figure out which users you want to merge, mdisks, etc. 5. copy the file you want to gerrymander and place your diretory entries in there. Very carefully. 6. on the system you want to place the new directory: 6a. from maint: link dirmaint 1df 1df mr 6b: from MAINT: ac 1df l 6c: From MAINT: ERASE USER DIRECT L 6d. copy from maint your gerrymandered directory: COPY GMANDER DIRECT A USER INPUT L2 it is important to copy it onto dirmaint 1df as fn= user ft= input 7. rel l(det 8.hope for the best! David Kreuter From: The IBM z/VM Operating System on behalf of Dave Keeton Sent: Thu 3/12/2009 12:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Merging DirMaint? I have a question regarding DirMaint and how to migrate/merge from one release to another. Here's the scenario: I have z/VM 5.2 running in production with DirMaint. I have 20+ instances of SLES9 10 and everything is running great. I also have z/VM 5.4 running in a test LPAR which also has DirMaint, 2 instances of SLES10, as well as several CA products. I want to bring 5.4 into production. I'm trying to determine how to merge all the directory entries for my production systems into the test directory prior to IPL'ing z/VM 5.4 as production. My first concern is the EXTENT CONTROL. Each instance of DirMaint has its own DASD pool, separate from the other. I am concern about things getting mucked up by consolidating the pools. What's the most effective way to do this? When z/VM 5.4 is up and running correctly, the plan is to rebuild the test LPAR with the latest release of z/VM so we can stay on top of the releases. Thanks in advance, Dave
Re: Merging DirMaint?
I have a follow-up question about the EXTENT CONTROL file In my ignorance, I used the same REGIONS naming convention in both production and test. Here's an example: This is the test system: :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments LNX901 LNX9G6 1END3390-09 This is production: :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments LNX901 LNX9F1 1END3390-09 It looks like to me I've shot myself in the foot by using the same convention for the RegionId. Any suggestions on how to clean this up? Thanks, Dave -Original Message- From: David Kreuter dkreu...@vm-resources.com Reply-to: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Merging DirMaint? Date: Thu, 12 Mar 2009 16:14:01 -0400 Hi Dave: for the directories on each system what I would do: 1. DIRM USER WITHPASS 2. RECEIVE the spool file as nodename WITHPASS - so you have a good copy of each systems directoy 3. Record by hand the volser where each directory is getting loaded onto 4. for each system run a DIRM SCAN USER and figure out which users you want to merge, mdisks, etc. 5. copy the file you want to gerrymander and place your diretory entries in there. Very carefully. 6. on the system you want to place the new directory: 6a. from maint: link dirmaint 1df 1df mr 6b: from MAINT: ac 1df l 6c: From MAINT: ERASE USER DIRECT L 6d. copy from maint your gerrymandered directory: COPY GMANDER DIRECT A USER INPUT L2 it is important to copy it onto dirmaint 1df as fn= user ft= input 7. rel l(det 8.hope for the best! David Kreuter From: The IBM z/VM Operating System on behalf of Dave Keeton Sent: Thu 3/12/2009 12:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Merging DirMaint? I have a question regarding DirMaint and how to migrate/merge from one release to another. Here's the scenario: I have z/VM 5.2 running in production with DirMaint. I have 20+ instances of SLES9 10 and everything is running great. I also have z/VM 5.4 running in a test LPAR which also has DirMaint, 2 instances of SLES10, as well as several CA products. I want to bring 5.4 into production. I'm trying to determine how to merge all the directory entries for my production systems into the test directory prior to IPL'ing z/VM 5.4 as production. My first concern is the EXTENT CONTROL. Each instance of DirMaint has its own DASD pool, separate from the other. I am concern about things getting mucked up by consolidating the pools. What's the most effective way to do this? When z/VM 5.4 is up and running correctly, the plan is to rebuild the test LPAR with the latest release of z/VM so we can stay on top of the releases. Thanks in advance, Dave
Re: Merging DirMaint?
Any reason you're not just using the volser as the regionid ? Scott On Mon, Mar 16, 2009 at 10:01 AM, Dave Keeton dave.kee...@state.or.uswrote: I have a follow-up question about the EXTENT CONTROL file In my ignorance, I used the same REGIONS naming convention in both production and test. Here's an example: This is the test system: :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments LNX901 LNX9G6 1END3390-09 This is production: :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments LNX901 LNX9F1 1END3390-09 It looks like to me I've shot myself in the foot by using the same convention for the RegionId. Any suggestions on how to clean this up? Thanks, Dave -Original Message- From: David Kreuter dkreu...@vm-resources.com Reply-to: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Merging DirMaint? Date: Thu, 12 Mar 2009 16:14:01 -0400 Hi Dave: for the directories on each system what I would do: 1. DIRM USER WITHPASS 2. RECEIVE the spool file as nodename WITHPASS - so you have a good copy of each systems directoy 3. Record by hand the volser where each directory is getting loaded onto 4. for each system run a DIRM SCAN USER and figure out which users you want to merge, mdisks, etc. 5. copy the file you want to gerrymander and place your diretory entries in there. Very carefully. 6. on the system you want to place the new directory: 6a. from maint: link dirmaint 1df 1df mr 6b: from MAINT: ac 1df l 6c: From MAINT: ERASE USER DIRECT L 6d. copy from maint your gerrymandered directory: COPY GMANDER DIRECT A USER INPUT L2 it is important to copy it onto dirmaint 1df as fn= user ft= input 7. rel l(det 8.hope for the best! David Kreuter From: The IBM z/VM Operating System on behalf of Dave Keeton Sent: Thu 3/12/2009 12:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Merging DirMaint? I have a question regarding DirMaint and how to migrate/merge from one release to another. Here's the scenario: I have z/VM 5.2 running in production with DirMaint. I have 20+ instances of SLES9 10 and everything is running great. I also have z/VM 5.4 running in a test LPAR which also has DirMaint, 2 instances of SLES10, as well as several CA products. I want to bring 5.4 into production. I'm trying to determine how to merge all the directory entries for my production systems into the test directory prior to IPL'ing z/VM 5.4 as production. My first concern is the EXTENT CONTROL. Each instance of DirMaint has its own DASD pool, separate from the other. I am concern about things getting mucked up by consolidating the pools. What's the most effective way to do this? When z/VM 5.4 is up and running correctly, the plan is to rebuild the test LPAR with the latest release of z/VM so we can stay on top of the releases. Thanks in advance, Dave
Re: Merging DirMaint?
Oh, I was trying to be clever. I thought if I numbered them sequentially I'd be able to keep track of the number of packs I was using. Clearly a failure on my part. -Original Message- From: Scott Rohling scott.rohl...@gmail.com Reply-to: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Merging DirMaint? Date: Mon, 16 Mar 2009 10:09:53 -0600 Any reason you're not just using the volser as the regionid ? Scott On Mon, Mar 16, 2009 at 10:01 AM, Dave Keeton dave.kee...@state.or.us wrote: I have a follow-up question about the EXTENT CONTROL file In my ignorance, I used the same REGIONS naming convention in both production and test. Here's an example: This is the test system: :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments LNX901 LNX9G6 1END3390-09 This is production: :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments LNX901 LNX9F1 1END3390-09 It looks like to me I've shot myself in the foot by using the same convention for the RegionId. Any suggestions on how to clean this up? Thanks, Dave -Original Message- From: David Kreuter dkreu...@vm-resources.com Reply-to: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Merging DirMaint? Date: Thu, 12 Mar 2009 16:14:01 -0400 Hi Dave: for the directories on each system what I would do: 1. DIRM USER WITHPASS 2. RECEIVE the spool file as nodename WITHPASS - so you have a good copy of each systems directoy 3. Record by hand the volser where each directory is getting loaded onto 4. for each system run a DIRM SCAN USER and figure out which users you want to merge, mdisks, etc. 5. copy the file you want to gerrymander and place your diretory entries in there. Very carefully. 6. on the system you want to place the new directory: 6a. from maint: link dirmaint 1df 1df mr 6b: from MAINT: ac 1df l 6c: From MAINT: ERASE USER DIRECT L 6d. copy from maint your gerrymandered directory: COPY GMANDER DIRECT A USER INPUT L2 it is important to copy it onto dirmaint 1df as fn= user ft= input 7. rel l(det 8.hope for the best! David Kreuter From: The IBM z/VM Operating System on behalf of Dave Keeton Sent: Thu 3/12/2009 12:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Merging DirMaint? I have a question regarding DirMaint and how to migrate/merge from one release to another. Here's the scenario: I have z/VM 5.2 running in production with DirMaint. I have 20+ instances of SLES9 10 and everything is running great. I also have z/VM 5.4 running in a test LPAR which also has DirMaint, 2 instances of SLES10, as well as several CA products. I want to bring 5.4 into production. I'm trying to determine how to merge all the directory entries for my production systems into the test directory prior to IPL'ing z/VM 5.4 as production. My first concern is the EXTENT CONTROL. Each instance of DirMaint has its own DASD pool, separate from the other. I am concern about things getting mucked up by consolidating the pools. What's the most effective way to do this? When z/VM 5.4 is up and running correctly, the plan is to rebuild the test LPAR with the latest release of z/VM so we can stay on top of the releases. Thanks in advance, Dave
Re: Merging DirMaint?
Dave, I don't think that merging the two versions of USER DIRECT (which was the answer you got) will have any affect on the EXTENT CONTROL file. What you have on the testbed now will not change unless you get the two EXTENT CONTROL files and merge entries from each. So if you want your new production to retain the definitions for production, you would put the production EXTENT CONTROL file onto your testbed and throw away the testbed one - or hide it somewhere for the testbed you plan to rebuild. If your testbed is going away (which I think you said was happening), why would you need to retain the testbed version of the region definitions? On Mon, Mar 16, 2009 at 10:01 AM, Dave Keeton dave.kee...@state.or.us wrote: I have a follow-up question about the EXTENT CONTROL file In my ignorance, I used the same REGIONS naming convention in both production and test. Here's an example: This is the test system: :REGIONS. *RegionId VolSer RegStart RegEnd Dev-Type Comments LNX901 LNX9G6 1 END 3390-09 This is production: :REGIONS. *RegionId VolSer RegStart RegEnd Dev-Type Comments LNX901 LNX9F1 1 END 3390-09 It looks like to me I've shot myself in the foot by using the same convention for the RegionId. Any suggestions on how to clean this up? Thanks, Dave I'm trying to determine how to merge all the directory entries for my production systems into the test directory prior to IPL'ing z/VM 5.4 as production. My first concern is the EXTENT CONTROL. Each instance of DirMaint has its own DASD pool, separate from the other. I am concern about things getting mucked up by consolidating the pools. What's the most effective way to do this? When z/VM 5.4 is up and running correctly, the plan is to rebuild the test LPAR with the latest release of z/VM so we can stay on top of the releases. Thanks in advance, Dave
Re: Merging DirMaint?
Ron, You're right, test is going away. It will eventually become the next release of z/VM at some point later down the road... I just had a 'duh' moment after reading your reply. The scope of the problem is not nearly as big as I thought. In test there are only a couple of Linux guests, as well as the CA products. The bulk of the production guests will, as you said, come over with the existing EXTENT CONTROL file. My only remaining question then would be is it possible to redefine the EXTENT CONTROL file and change the RegionId definitions to using the VolSer instead? -Original Message- From: Ron Schmiedge ron.schmie...@gmail.com Reply-to: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Merging DirMaint? Date: Mon, 16 Mar 2009 10:17:59 -0600 Dave, I don't think that merging the two versions of USER DIRECT (which was the answer you got) will have any affect on the EXTENT CONTROL file. What you have on the testbed now will not change unless you get the two EXTENT CONTROL files and merge entries from each. So if you want your new production to retain the definitions for production, you would put the production EXTENT CONTROL file onto your testbed and throw away the testbed one - or hide it somewhere for the testbed you plan to rebuild. If your testbed is going away (which I think you said was happening), why would you need to retain the testbed version of the region definitions? On Mon, Mar 16, 2009 at 10:01 AM, Dave Keeton dave.kee...@state.or.us wrote: I have a follow-up question about the EXTENT CONTROL file In my ignorance, I used the same REGIONS naming convention in both production and test. Here's an example: This is the test system: :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments LNX901 LNX9G6 1END3390-09 This is production: :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments LNX901 LNX9F1 1END3390-09 It looks like to me I've shot myself in the foot by using the same convention for the RegionId. Any suggestions on how to clean this up? Thanks, Dave I'm trying to determine how to merge all the directory entries for my production systems into the test directory prior to IPL'ing z/VM 5.4 as production. My first concern is the EXTENT CONTROL. Each instance of DirMaint has its own DASD pool, separate from the other. I am concern about things getting mucked up by consolidating the pools. What's the most effective way to do this? When z/VM 5.4 is up and running correctly, the plan is to rebuild the test LPAR with the latest release of z/VM so we can stay on top of the releases. Thanks in advance, Dave
I want to know how command line on z/vm.
Dear. Sir I has Operate IBM System z9 Enterprise Class and include z/vm. I want to know how command line on z/vm. Can You help me. Thank. somkid T.lub แชตออนไลน์ทันใจกับเพื่อนและครอบครัวของคุณ! Windows Live Messenger _ ตัวตนที่แท้จริงข้างในต่างหากที่สำคัญ นักกีฬาคนไหนที่ซ่อนอยู่ในตัวคุณ http://yourinnerathlete.windowslive.com?locale=th-thocid=TXT_TAGLM_WLYIA_whichathlete_th
Re: Merging DirMaint?
Sure -- just do a DIRM RLDE when you're done so DIRMAINT knows the new region names... Scott On Mon, Mar 16, 2009 at 10:31 AM, Dave Keeton dave.kee...@state.or.uswrote: Ron, You're right, test is going away. It will eventually become the next release of z/VM at some point later down the road... I just had a 'duh' moment after reading your reply. The scope of the problem is not nearly as big as I thought. In test there are only a couple of Linux guests, as well as the CA products. The bulk of the production guests will, as you said, come over with the existing EXTENT CONTROL file. My only remaining question then would be is it possible to redefine the EXTENT CONTROL file and change the RegionId definitions to using the VolSer instead? -Original Message- From: Ron Schmiedge ron.schmie...@gmail.com Reply-to: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Merging DirMaint? Date: Mon, 16 Mar 2009 10:17:59 -0600 Dave, I don't think that merging the two versions of USER DIRECT (which was the answer you got) will have any affect on the EXTENT CONTROL file. What you have on the testbed now will not change unless you get the two EXTENT CONTROL files and merge entries from each. So if you want your new production to retain the definitions for production, you would put the production EXTENT CONTROL file onto your testbed and throw away the testbed one - or hide it somewhere for the testbed you plan to rebuild. If your testbed is going away (which I think you said was happening), why would you need to retain the testbed version of the region definitions? On Mon, Mar 16, 2009 at 10:01 AM, Dave Keeton dave.kee...@state.or.us wrote: I have a follow-up question about the EXTENT CONTROL file In my ignorance, I used the same REGIONS naming convention in both production and test. Here's an example: This is the test system: :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments LNX901 LNX9G6 1END3390-09 This is production: :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments LNX901 LNX9F1 1END3390-09 It looks like to me I've shot myself in the foot by using the same convention for the RegionId. Any suggestions on how to clean this up? Thanks, Dave I'm trying to determine how to merge all the directory entries for my production systems into the test directory prior to IPL'ing z/VM 5.4 as production. My first concern is the EXTENT CONTROL. Each instance of DirMaint has its own DASD pool, separate from the other. I am concern about things getting mucked up by consolidating the pools. What's the most effective way to do this? When z/VM 5.4 is up and running correctly, the plan is to rebuild the test LPAR with the latest release of z/VM so we can stay on top of the releases. Thanks in advance, Dave
Re: Version 4 to Version 5
You got me! So... I can assume that if I start up after an orderly shutdown, the V5 servers will work right away, with the V4 data, right? Original message Date: Mon, 16 Mar 2009 07:07:33 -0400 From: Imler, Steven J steven.im...@ca.com Subject: Re: Version 4 to Version 5 To: IBMVM@LISTSERV.UARK.EDU Shimon, Was your SFS server up and running when you DDR'd it? If so, it's likely some data changed while your DDR was running causing you to end up with a dirty copy of the FilePool. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 steven.im...@ca.com -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Monday, March 16, 2009 02:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Version 4 to Version 5 In changing a z/VM system from Version 4 to Version 5: 1) is there any problem with the V5 system using the existing spool files of V4? 2) Can SFS servers that were running V4 simply be started up with the SFS servers of V5 on the same mdisks? I tried one SFS server and it failed to come up until I ran a FILESERV BACKUP. Was this some local problem, or did I do something wrong? Of course I did not use live data - I DDR'd all of the mdisks of the server to copies, and tried to run the new server on them. Thanks, Shimon -- * *** Shimon Lebowitzmailto:shim...@iname.com VM System Programmer . Israel Police National HQ. Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308 * ***
Re: Version 4 to Version 5
Yes, no problem with SFS, and surely not these day where not too many new things happen to SFS. Even in the past, when SFS detected it used a newer level, it automatically updated its catalog with new fields, no user intervention required. 2009/3/16 Shimon Lebowitz shim...@iname.com: You got me! So... I can assume that if I start up after an orderly shutdown, the V5 servers will work right away, with the V4 data, right? Original message Date: Mon, 16 Mar 2009 07:07:33 -0400 From: Imler, Steven J steven.im...@ca.com Subject: Re: Version 4 to Version 5 To: IBMVM@LISTSERV.UARK.EDU Shimon, Was your SFS server up and running when you DDR'd it? If so, it's likely some data changed while your DDR was running causing you to end up with a dirty copy of the FilePool. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 steven.im...@ca.com -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Monday, March 16, 2009 02:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Version 4 to Version 5 In changing a z/VM system from Version 4 to Version 5: 1) is there any problem with the V5 system using the existing spool files of V4? 2) Can SFS servers that were running V4 simply be started up with the SFS servers of V5 on the same mdisks? I tried one SFS server and it failed to come up until I ran a FILESERV BACKUP. Was this some local problem, or did I do something wrong? Of course I did not use live data - I DDR'd all of the mdisks of the server to copies, and tried to run the new server on them. Thanks, Shimon -- * *** Shimon Lebowitzmailto:shim...@iname.com VM System Programmer . Israel Police National HQ. Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308 * *** -- Kris Buelens, IBM Belgium, VM customer support
Re: Version 4 to Version 5
Correct. AFAIK there are no issues with bringing a SFS server down under z/VM 4.n, then bringing it back up on a level of z/VM 5.n ... and then going back if for some reason you had to. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 steven.im...@ca.com -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Monday, March 16, 2009 03:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Version 4 to Version 5 You got me! So... I can assume that if I start up after an orderly shutdown, the V5 servers will work right away, with the V4 data, right? Original message Date: Mon, 16 Mar 2009 07:07:33 -0400 From: Imler, Steven J steven.im...@ca.com Subject: Re: Version 4 to Version 5 To: IBMVM@LISTSERV.UARK.EDU Shimon, Was your SFS server up and running when you DDR'd it? If so, it's likely some data changed while your DDR was running causing you to end up with a dirty copy of the FilePool. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 steven.im...@ca.com -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Monday, March 16, 2009 02:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Version 4 to Version 5 In changing a z/VM system from Version 4 to Version 5: 1) is there any problem with the V5 system using the existing spool files of V4? 2) Can SFS servers that were running V4 simply be started up with the SFS servers of V5 on the same mdisks? I tried one SFS server and it failed to come up until I ran a FILESERV BACKUP. Was this some local problem, or did I do something wrong? Of course I did not use live data - I DDR'd all of the mdisks of the server to copies, and tried to run the new server on them. Thanks, Shimon -- * *** Shimon Lebowitzmailto:shim...@iname.com VM System Programmer . Israel Police National HQ. Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308 * ***
SEGGEN failure
I am trying to rebuild CMSINST, following the directions in 3.17.1 Rebuild the Saved Segments of the 5.3.0 service guide. I 190 CL parm nosprof instseg no AC ( NOPROF AC 5E6 B AC 51D D vmfbld ppf segbld esasegs segblist instseg type (serviced VMFBLD2760I VMFBLD processing started VMFBLD1851I Reading build lists VMFBLD2182I Identifying new build requirements VMFBLD2182I No new build requirements identified VMFBLD1851I (1 of 1) VMFBDSEG processing SEGBLIST EXC0 D, target is BUILD 51D (D) VMFBDS2115I Validating segment INSTSEG VMFBDS2002I A DEFSEG command will be issued for 1 segment(s). VMFBDS2219I Processing object INSTSEG.SEGMENT DMSDCS358E Skeleton segment INSTSEG has already been reserved DMSGEN1279E Error(s) occurred during SEGGEN processing. VMFBDS1965E The command, SEGGEN INSTSEG PSEG A SYSTEM SEGID D2 ( TYPE, failed with return code 32 VMFBLD1851E (1 of 1) VMFBDSEG completed with return code 100. Some objects were not built VMFBLD2180I There are 1 build requirements remaining VMFBLD2760I VMFBLD processing completed unsuccessfully Ready(8); T=3.73/3.98 21:13:33 The reason I added the type option, was the advice in the manual for catching errors, and in fact, that line about already reserved was what showed up. So I ran through the steps again, and added Q SEGMENT * after the two ACCesses, before running vmfbld. The result was: q segment * DMSDCT357I No segment spaces exist Ready(00028); T=0.01/0.01 21:16:19 vmfbld ppf segbld esasegs segblist instseg type (serviced VMFBLD2760I VMFBLD processing started VMFBLD1851I Reading build lists VMFBLD2182I Identifying new build requirements VMFBLD2182I No new build requirements identified VMFBLD1851I (1 of 1) VMFBDSEG processing SEGBLIST EXC0 D, target is BUILD 51D (D) VMFBDS2115I Validating segment INSTSEG VMFBDS2002I A DEFSEG command will be issued for 1 segment(s). VMFBDS2219I Processing object INSTSEG.SEGMENT DMSDCS358E Skeleton segment INSTSEG has already been reserved DMSGEN1279E Error(s) occurred during SEGGEN processing. VMFBDS1965E The command, SEGGEN INSTSEG PSEG A SYSTEM SEGID D2 ( TYPE, failed with return code 32 VMFBLD1851E (1 of 1) VMFBDSEG completed with return code 100. Some objects were not built VMFBLD2180I There are 1 build requirements remaining VMFBLD2760I VMFBLD processing completed unsuccessfully Ready(8); T=3.67/3.90 21:16:49 So, why does it say already reserved if it isn't? Help, anybody? Thanks very much!! Shimon
Re: Version 4 to Version 5
Thank you very much, JR. Any such info about the spool files? At least in one direction? (I have no problem keeping a backup). Original message Date: Mon, 16 Mar 2009 15:17:13 -0400 From: Imler, Steven J steven.im...@ca.com Subject: Re: Version 4 to Version 5 To: IBMVM@LISTSERV.UARK.EDU Correct. AFAIK there are no issues with bringing a SFS server down under z/VM 4.n, then bringing it back up on a level of z/VM 5.n ... and then going back if for some reason you had to. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 steven.im...@ca.com -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Monday, March 16, 2009 03:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Version 4 to Version 5 You got me! So... I can assume that if I start up after an orderly shutdown, the V5 servers will work right away, with the V4 data, right? Original message Date: Mon, 16 Mar 2009 07:07:33 -0400 From: Imler, Steven J steven.im...@ca.com Subject: Re: Version 4 to Version 5 To: IBMVM@LISTSERV.UARK.EDU Shimon, Was your SFS server up and running when you DDR'd it? If so, it's likely some data changed while your DDR was running causing you to end up with a dirty copy of the FilePool. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 steven.im...@ca.com -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Monday, March 16, 2009 02:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Version 4 to Version 5 In changing a z/VM system from Version 4 to Version 5: 1) is there any problem with the V5 system using the existing spool files of V4? 2) Can SFS servers that were running V4 simply be started up with the SFS servers of V5 on the same mdisks? I tried one SFS server and it failed to come up until I ran a FILESERV BACKUP. Was this some local problem, or did I do something wrong? Of course I did not use live data - I DDR'd all of the mdisks of the server to copies, and tried to run the new server on them. Thanks, Shimon -- * *** Shimon Lebowitzmailto:shim...@iname.com VM System Programmer . Israel Police National HQ. Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308 * ***
Re: Version 4 to Version 5
Shimon Lebowitz wrote: Thank you very much, JR. Any such info about the spool files? At least in one direction? (I have no problem keeping a backup). SPXTAPE ? --Ivan
Re: Merging DirMaint?
Thanks, Scott! -Original Message- From: Scott Rohling scott.rohl...@gmail.com Reply-to: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Merging DirMaint? Date: Mon, 16 Mar 2009 11:49:04 -0600 Sure -- just do a DIRM RLDE when you're done so DIRMAINT knows the new region names... Scott On Mon, Mar 16, 2009 at 10:31 AM, Dave Keeton dave.kee...@state.or.us wrote: Ron, You're right, test is going away. It will eventually become the next release of z/VM at some point later down the road... I just had a 'duh' moment after reading your reply. The scope of the problem is not nearly as big as I thought. In test there are only a couple of Linux guests, as well as the CA products. The bulk of the production guests will, as you said, come over with the existing EXTENT CONTROL file. My only remaining question then would be is it possible to redefine the EXTENT CONTROL file and change the RegionId definitions to using the VolSer instead? -Original Message- From: Ron Schmiedge ron.schmie...@gmail.com Reply-to: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Merging DirMaint? Date: Mon, 16 Mar 2009 10:17:59 -0600 Dave, I don't think that merging the two versions of USER DIRECT (which was the answer you got) will have any affect on the EXTENT CONTROL file. What you have on the testbed now will not change unless you get the two EXTENT CONTROL files and merge entries from each. So if you want your new production to retain the definitions for production, you would put the production EXTENT CONTROL file onto your testbed and throw away the testbed one - or hide it somewhere for the testbed you plan to rebuild. If your testbed is going away (which I think you said was happening), why would you need to retain the testbed version of the region definitions? On Mon, Mar 16, 2009 at 10:01 AM, Dave Keeton dave.kee...@state.or.us wrote: I have a follow-up question about the EXTENT CONTROL file In my ignorance, I used the same REGIONS naming convention in both production and test. Here's an example: This is the test system: :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments LNX901 LNX9G6 1END3390-09 This is production: :REGIONS. *RegionId VolSerRegStart RegEnd Dev-Type Comments LNX901 LNX9F1 1END3390-09 It looks like to me I've shot myself in the foot by using the same convention for the RegionId. Any suggestions on how to clean this up? Thanks, Dave I'm trying to determine how to merge all the directory entries for my production systems into the test directory prior to IPL'ing z/VM 5.4 as production. My first concern is the EXTENT CONTROL. Each instance of DirMaint has its own DASD pool, separate from the other. I am concern about things getting mucked up by consolidating the pools. What's the most effective way to do this? When z/VM 5.4 is up and running correctly, the plan is to rebuild the test LPAR with the latest release of z/VM so we can stay on top of the releases. Thanks in advance, Dave
Re: Version 4 to Version 5
Actually, I don't believe there were any changes to the format/structure of spool files between z/VM 4.n and z/VM 5.n ... only to the way CP handles manipulating them. One notable change is the introduction of DCSSGs with z/VM 5.4 ... but you obviously won't have any of those (yet) anyway. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 steven.im...@ca.com -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Monday, March 16, 2009 03:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Version 4 to Version 5 Thank you very much, JR. Any such info about the spool files? At least in one direction? (I have no problem keeping a backup). Original message Date: Mon, 16 Mar 2009 15:17:13 -0400 From: Imler, Steven J steven.im...@ca.com Subject: Re: Version 4 to Version 5 To: IBMVM@LISTSERV.UARK.EDU Correct. AFAIK there are no issues with bringing a SFS server down under z/VM 4.n, then bringing it back up on a level of z/VM 5.n ... and then going back if for some reason you had to. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 steven.im...@ca.com -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Monday, March 16, 2009 03:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Version 4 to Version 5 You got me! So... I can assume that if I start up after an orderly shutdown, the V5 servers will work right away, with the V4 data, right? Original message Date: Mon, 16 Mar 2009 07:07:33 -0400 From: Imler, Steven J steven.im...@ca.com Subject: Re: Version 4 to Version 5 To: IBMVM@LISTSERV.UARK.EDU Shimon, Was your SFS server up and running when you DDR'd it? If so, it's likely some data changed while your DDR was running causing you to end up with a dirty copy of the FilePool. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 steven.im...@ca.com -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Monday, March 16, 2009 02:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Version 4 to Version 5 In changing a z/VM system from Version 4 to Version 5: 1) is there any problem with the V5 system using the existing spool files of V4? 2) Can SFS servers that were running V4 simply be started up with the SFS servers of V5 on the same mdisks? I tried one SFS server and it failed to come up until I ran a FILESERV BACKUP. Was this some local problem, or did I do something wrong? Of course I did not use live data - I DDR'd all of the mdisks of the server to copies, and tried to run the new server on them. Thanks, Shimon -- * *** Shimon Lebowitzmailto:shim...@iname.com VM System Programmer . Israel Police National HQ. Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308 * ***
Re: Version 4 to Version 5
Shimon Lebowitz wrote: Thank you very much, JR. Any such info about the spool files? At least in one direction? (I have no problem keeping a backup). SPXTAPE ? If you are using the same spool volumes and they are defined in the same CP_OWNED slots, and you are using the same checkpoint and warmstart areas, then you should be able to shut down your old system and IPL the new one with a warm start and have all of your spool files restored. Of course, it's always a good idea to back them up before shutting down just in case. John Franciscovich z/VM Development
Re: SEGGEN failure
Shimon, problem 1 do a Q NSS and you will find an instesg that has been defined/reserved you will need to delete that one before you try it again problem 2 what ever you changed in your instseg has made it too large to load in the instseg space you are defining/reserving. you will need to enlarge the defseg for instseg but I do not remember off hand how to do it. I am sure you can do it from the VMF segment panel screens good luck Bill Munson Sr. z/VM Systems Programmer Brown Brothers Harriman CO. 525 Washington Blvd. Jersey City, NJ 07310 201-418-7588 President MVMUA http://www2.marist.edu/~mvmua/ Shimon Lebowitz shimon...@gmail.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/16/2009 03:20 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject SEGGEN failure I am trying to rebuild CMSINST, following the directions in 3.17.1 Rebuild the Saved Segments of the 5.3.0 service guide. I 190 CL parm nosprof instseg no AC ( NOPROF AC 5E6 B AC 51D D vmfbld ppf segbld esasegs segblist instseg type (serviced VMFBLD2760I VMFBLD processing started VMFBLD1851I Reading build lists VMFBLD2182I Identifying new build requirements VMFBLD2182I No new build requirements identified VMFBLD1851I (1 of 1) VMFBDSEG processing SEGBLIST EXC0 D, target is BUILD 51D (D) VMFBDS2115I Validating segment INSTSEG VMFBDS2002I A DEFSEG command will be issued for 1 segment(s). VMFBDS2219I Processing object INSTSEG.SEGMENT DMSDCS358E Skeleton segment INSTSEG has already been reserved DMSGEN1279E Error(s) occurred during SEGGEN processing. VMFBDS1965E The command, SEGGEN INSTSEG PSEG A SYSTEM SEGID D2 ( TYPE, failed with return code 32 VMFBLD1851E (1 of 1) VMFBDSEG completed with return code 100. Some objects were not built VMFBLD2180I There are 1 build requirements remaining VMFBLD2760I VMFBLD processing completed unsuccessfully Ready(8); T=3.73/3.98 21:13:33 The reason I added the type option, was the advice in the manual for catching errors, and in fact, that line about already reserved was what showed up. So I ran through the steps again, and added Q SEGMENT * after the two ACCesses, before running vmfbld. The result was: q segment * DMSDCT357I No segment spaces exist Ready(00028); T=0.01/0.01 21:16:19 vmfbld ppf segbld esasegs segblist instseg type (serviced VMFBLD2760I VMFBLD processing started VMFBLD1851I Reading build lists VMFBLD2182I Identifying new build requirements VMFBLD2182I No new build requirements identified VMFBLD1851I (1 of 1) VMFBDSEG processing SEGBLIST EXC0 D, target is BUILD 51D (D) VMFBDS2115I Validating segment INSTSEG VMFBDS2002I A DEFSEG command will be issued for 1 segment(s). VMFBDS2219I Processing object INSTSEG.SEGMENT DMSDCS358E Skeleton segment INSTSEG has already been reserved DMSGEN1279E Error(s) occurred during SEGGEN processing. VMFBDS1965E The command, SEGGEN INSTSEG PSEG A SYSTEM SEGID D2 ( TYPE, failed with return code 32 VMFBLD1851E (1 of 1) VMFBDSEG completed with return code 100. Some objects were not built VMFBLD2180I There are 1 build requirements remaining VMFBLD2760I VMFBLD processing completed unsuccessfully Ready(8); T=3.67/3.90 21:16:49 So, why does it say already reserved if it isn't? Help, anybody? Thanks very much!! Shimon *** IMPORTANT NOTE* The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman Co., its subsidiaries and affiliates (BBH). There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus.
Re: SEGGEN failure
Shimon, Look in appendix E of the Service Guide. munson 201-418-7588 Shimon Lebowitz shimon...@gmail.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/16/2009 03:20 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject SEGGEN failure I am trying to rebuild CMSINST, following the directions in 3.17.1 Rebuild the Saved Segments of the 5.3.0 service guide. I 190 CL parm nosprof instseg no AC ( NOPROF AC 5E6 B AC 51D D vmfbld ppf segbld esasegs segblist instseg type (serviced VMFBLD2760I VMFBLD processing started VMFBLD1851I Reading build lists VMFBLD2182I Identifying new build requirements VMFBLD2182I No new build requirements identified VMFBLD1851I (1 of 1) VMFBDSEG processing SEGBLIST EXC0 D, target is BUILD 51D (D) VMFBDS2115I Validating segment INSTSEG VMFBDS2002I A DEFSEG command will be issued for 1 segment(s). VMFBDS2219I Processing object INSTSEG.SEGMENT DMSDCS358E Skeleton segment INSTSEG has already been reserved DMSGEN1279E Error(s) occurred during SEGGEN processing. VMFBDS1965E The command, SEGGEN INSTSEG PSEG A SYSTEM SEGID D2 ( TYPE, failed with return code 32 VMFBLD1851E (1 of 1) VMFBDSEG completed with return code 100. Some objects were not built VMFBLD2180I There are 1 build requirements remaining VMFBLD2760I VMFBLD processing completed unsuccessfully Ready(8); T=3.73/3.98 21:13:33 The reason I added the type option, was the advice in the manual for catching errors, and in fact, that line about already reserved was what showed up. So I ran through the steps again, and added Q SEGMENT * after the two ACCesses, before running vmfbld. The result was: q segment * DMSDCT357I No segment spaces exist Ready(00028); T=0.01/0.01 21:16:19 vmfbld ppf segbld esasegs segblist instseg type (serviced VMFBLD2760I VMFBLD processing started VMFBLD1851I Reading build lists VMFBLD2182I Identifying new build requirements VMFBLD2182I No new build requirements identified VMFBLD1851I (1 of 1) VMFBDSEG processing SEGBLIST EXC0 D, target is BUILD 51D (D) VMFBDS2115I Validating segment INSTSEG VMFBDS2002I A DEFSEG command will be issued for 1 segment(s). VMFBDS2219I Processing object INSTSEG.SEGMENT DMSDCS358E Skeleton segment INSTSEG has already been reserved DMSGEN1279E Error(s) occurred during SEGGEN processing. VMFBDS1965E The command, SEGGEN INSTSEG PSEG A SYSTEM SEGID D2 ( TYPE, failed with return code 32 VMFBLD1851E (1 of 1) VMFBDSEG completed with return code 100. Some objects were not built VMFBLD2180I There are 1 build requirements remaining VMFBLD2760I VMFBLD processing completed unsuccessfully Ready(8); T=3.67/3.90 21:16:49 So, why does it say already reserved if it isn't? Help, anybody? Thanks very much!! Shimon *** IMPORTANT NOTE* The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman Co., its subsidiaries and affiliates (BBH). There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus.
Re: Version 4 to Version 5
John Franciscovich wrote: If you are using the same spool volumes and they are defined in the same CP_OWNED slots, and you are using the same checkpoint and warmstart areas, then you should be able to shut down your old system and IPL the new one with a warm start and have all of your spool files restored. Of course, it's always a good idea to back them up before shutting down just in case. Backups ? Blah ! backups are for the weak ! real sysprogs now by heart the exact contents of all their CP Owned volumes and can reconstruct them from memory using a 3880 MD device to reconstruct the 3380 volumes from scratch.. Now, more seriously.. Performing a DDR on a live system (or at least its CP owned vols) and IPLing on a restore of those is going to ask for a CKPT or FORCE start.. and those spool files that were opened during the DDR process may contain a bit of funny data ! So maybe SPXTAPE followed by a restore, a cold start and a SPXTAPE LOAD would be a slightly better idea ! (Since I believe the problem wasn't the actual migration - but a rollback option). Then again, even for a migration.. keeping a SPXTAPE reel may always be helpful.. just in case something goes awry.. (Sorry.. I'm from the SP and XA days when thing would sometimes indeed go awry !). --Ivan
Re: Merging DirMaint?
Dave, The Program Directory for DIRMAINT should have a section called Tailor the DIRMAINT Server Machines (I am still z/VM 5.3, you'll have to check the 5.4 version).There's a figure containing a list of supplied sample files. If you've tailored any of them, you'll want to bring them forward from 5.3 to 5.4 (I have changed 4 of them on my system, one is EXTENT CONTROL). A couple pages further is a short list of files for which no samples are provided. I have changed 2 of them. Those two lists, along with the directory itself, should be the ones to worry about. On Mon, Mar 16, 2009 at 10:31 AM, Dave Keeton dave.kee...@state.or.us wrote: Ron, You're right, test is going away. It will eventually become the next release of z/VM at some point later down the road... I just had a 'duh' moment after reading your reply. The scope of the problem is not nearly as big as I thought. In test there are only a couple of Linux guests, as well as the CA products. The bulk of the production guests will, as you said, come over with the existing EXTENT CONTROL file. My only remaining question then would be is it possible to redefine the EXTENT CONTROL file and change the RegionId definitions to using the VolSer instead?
New CMS based SSLSERV problem... DTCSSL300E
I'll start by saying that I have already found, read and preformed all tasks on http://www.vm.ibm.com/related/tcpip/tcsslini.html to no avail. I'm trying to setup the new CMS based SSLSERV for z/VM 540 RSU 0802, but I keep getting the exact error mentioned in the link above. DTCRUN1011I Server started at 16:02:41 on 16 Mar 2009 (Monday) DTCRUN1011I Running server command: VMSSL DTCRUN1011I Parameters in use: DTCRUN1011I MAXSESSIONS 20 KEYFILE /etc/gskadm/Database.kdb DTCSSL2423I Using server module: SSLSERV MODULE E2 - 2/26/09 16:28:52 DTCSSL002I SSLSERV main() - PROGMAP: NameEntry Origin BytesAttributes SSLSERV 0FD632880FD6328800041D73Amode 31 Reloc DTCSSL002I DEBUG settings: Debug: 0 DTCSSL002I main() started... DTCSSL015I Server initialization in progress (z/VM level 540 - PK65850) DTCSSL100I This software incorporates the RSA algorithm DTCSSL132I Server ID: SSLSERV DMSLIO201W The following names are undefined: EDCUCSNM DMSLIO201W The following names are undefined: EDCUCSNM DTCSSL300E gsk_open_database_using_stash_file() failed; rc: 0x3353009 reason: File or keyring not found DTCSSL127E Server shutdown has commenced DTCSSL128E Server shutdown is complete DTCRUN1015I Server ended with RC=1 at 16:02:42 on 16 Mar 2009 (Monday) DTCRUN1019I Server will not be logged off because you are connected If I issue 'openvm list /etc/gskadm (own' on GSKADMIN account I get the following openvm listfile /etc/gskadm (own Directory = '/etc/gskadm' User IDGroup Name Permissions Type Path name component gskadmin securityrw- r-- --- F'Database.kdb' gskadmin securityrw- --- --- F'Database.rdb' gskadmin securityrw- r-- --- F'Database.sth' The SSLSERV directory statement also has POSIXINFO UID 7 GNAME security So, what else can I try??? Mark Wiggins University of Connecticut 860-486-2792
Re: Version 4 to Version 5
Well, for going forward, it works without any issues. My z/VM 5.2 SFS VMSERVU server was initially created on VM/SP 5 and has been thru many upgrades since. (But no down grades). If you have a tape backup of any pool, use Ditto to browse the first block. It will say what version/release of VM did the initial creation/format of that pool. Tom Duerbusch THD Consulting Imler, Steven J steven.im...@ca.com 3/16/2009 2:17 PM Correct. AFAIK there are no issues with bringing a SFS server down under z/VM 4.n, then bringing it back up on a level of z/VM 5.n ... and then going back if for some reason you had to. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 steven.im...@ca.com -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Monday, March 16, 2009 03:05 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Version 4 to Version 5 You got me! So... I can assume that if I start up after an orderly shutdown, the V5 servers will work right away, with the V4 data, right? Original message Date: Mon, 16 Mar 2009 07:07:33 -0400 From: Imler, Steven J steven.im...@ca.com Subject: Re: Version 4 to Version 5 To: IBMVM@LISTSERV.UARK.EDU Shimon, Was your SFS server up and running when you DDR'd it? If so, it's likely some data changed while your DDR was running causing you to end up with a dirty copy of the FilePool. JR (Steven) Imler CA Senior Sustaining Engineer Tel: +1 703 708 3479 steven.im...@ca.com -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Monday, March 16, 2009 02:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Version 4 to Version 5 In changing a z/VM system from Version 4 to Version 5: 1) is there any problem with the V5 system using the existing spool files of V4? 2) Can SFS servers that were running V4 simply be started up with the SFS servers of V5 on the same mdisks? I tried one SFS server and it failed to come up until I ran a FILESERV BACKUP. Was this some local problem, or did I do something wrong? Of course I did not use live data - I DDR'd all of the mdisks of the server to copies, and tried to run the new server on them. Thanks, Shimon -- * *** Shimon Lebowitzmailto:shim...@iname.com VM System Programmer . Israel Police National HQ. Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308 * ***
Re: Version 4 to Version 5
SFS in VM/SP R5??? Normal mortals could not lay their hand on SFS until VM/SP R6. 2009/3/16 Tom Duerbusch duerbus...@stlouiscity.com Well, for going forward, it works without any issues. My z/VM 5.2 SFS VMSERVU server was initially created on VM/SP 5 and has been thru many upgrades since. (But no down grades). If you have a tape backup of any pool, use Ditto to browse the first block. It will say what version/release of VM did the initial creation/format of that pool. Tom Duerbusch THD Consulting -- Kris Buelens, IBM Belgium, VM customer support
Re: New CMS based SSLSERV problem... DTCSSL300E
Mark, What did you put in SYSTEM DTCPARMS or node DTCPARMS for your SSL server? If you want to change anything for :nick.ssl in IBM DTCPARMS, you have to copy the whole section for that nickname to your local file. For example, I wanted to add a session limit and exempt low-strength encryption algorithms. The first thing I tried was just putting the following in node DTCPARMS: :nick.ssl :type.class :name.SSL daemon :command.VMSSL :diskwarn.YES :parms.MAXSESSIONS 30 EXEMPT LOW This was similar to my z/VM 5.3.0 file. I then got a message about Admin_ID_list not being found, so I added that. When I tried again, I got the same message you got. I guessed that I needed to copy the entire :nick.ssl section from IBM DTCPARMS to my local file, and change the parts I wanted to change. That worked. I currently have: :nick.ssl :type.class :name.SSL daemon :command.VMSSL :runtime.C :diskwarn.YES :Admin_ID_list.TCPMAINT GSKADMIN SYSPROG1 SYSPROG2 :memory.256M :mixedcaseparms.YES :mount. /../VMBFS:VMSYS:ROOT/ / , /../VMBFS:VMSYS:SSLSERV/ /tmp , /../VMBFS:VMSYS:GSKSSLDB/ /etc/gskadm :parms.KEYFile /etc/gskadm/Database.kdb MAXSESSIONS 30 EXEMPT LOW Your error message is because SSLSERV is not seeing a :mount. tag, so it doesn't know where to find /etc/gskadm/Database.kdb. Dennis O'Brien 39,516 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wiggins, Mark Sent: Monday, March 16, 2009 13:38 To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] New CMS based SSLSERV problem... DTCSSL300E I'll start by saying that I have already found, read and preformed all tasks on http://www.vm.ibm.com/related/tcpip/tcsslini.html to no avail. I'm trying to setup the new CMS based SSLSERV for z/VM 540 RSU 0802, but I keep getting the exact error mentioned in the link above. DTCRUN1011I Server started at 16:02:41 on 16 Mar 2009 (Monday) DTCRUN1011I Running server command: VMSSL DTCRUN1011I Parameters in use: DTCRUN1011I MAXSESSIONS 20 KEYFILE /etc/gskadm/Database.kdb DTCSSL2423I Using server module: SSLSERV MODULE E2 - 2/26/09 16:28:52 DTCSSL002I SSLSERV main() - PROGMAP: NameEntry Origin BytesAttributes SSLSERV 0FD632880FD6328800041D73Amode 31 Reloc DTCSSL002I DEBUG settings: Debug: 0 DTCSSL002I main() started... DTCSSL015I Server initialization in progress (z/VM level 540 - PK65850) DTCSSL100I This software incorporates the RSA algorithm DTCSSL132I Server ID: SSLSERV DMSLIO201W The following names are undefined: EDCUCSNM DMSLIO201W The following names are undefined: EDCUCSNM DTCSSL300E gsk_open_database_using_stash_file() failed; rc: 0x3353009 reason: File or keyring not found DTCSSL127E Server shutdown has commenced DTCSSL128E Server shutdown is complete DTCRUN1015I Server ended with RC=1 at 16:02:42 on 16 Mar 2009 (Monday) DTCRUN1019I Server will not be logged off because you are connected If I issue 'openvm list /etc/gskadm (own' on GSKADMIN account I get the following openvm listfile /etc/gskadm (own Directory = '/etc/gskadm' User IDGroup Name Permissions Type Path name component gskadmin securityrw- r-- --- F'Database.kdb' gskadmin securityrw- --- --- F'Database.rdb' gskadmin securityrw- r-- --- F'Database.sth' The SSLSERV directory statement also has POSIXINFO UID 7 GNAME security So, what else can I try??? Mark Wiggins University of Connecticut 860-486-2792
Re: New CMS based SSLSERV problem... DTCSSL300E
Hi Mark, I suspect the errors you've encountered stem from somehow referencing a pre-540 SSL 'class' entry -- one that lacks the :runtime.C , :mount. and other tags that define values needed for the 540 SSL server. Please chec k your SYSTEM DTCPARMS file (or any others you've customized) for a stale/rogue pre-540 SSL class entry that looks like this one: :nick.ssl :type.class :name.SSL daemon :command.VMSSL :diskwarn.YES Also, ensure that a pre-540 level IBM DTCPARMS file is not present in the CMS search order of the (540) SSL server, and that thePK65850- level IBM DTCPARMS file *is* available. The class definition from this file is: :nick.ssl :type.class :name.SSL daemon :command.VMSSL :runtime.C :diskwarn.YES :Admin_ID_list.TCPMAINT GSKADMIN :memory.256M :mixedcaseparms.YES :mount. /../VMBFS:VMSYS:ROOT/ / , /../VMBFS:VMSYS:SSLSERV/ /tmp , /../VMBFS:VMSYS:GSKSSLDB/ /etc/gskadm :parms.KEYFile /etc/gskadm/Database.kdb (Note: The 540 GA-level of this file lacks the 'SSLSERV' file space ID fo r the '/tmp' mount; commentary in the updated file explains why this needs to be included.) One other customer ran across the errors you cited for this same reason, but I've just not had a chance to update the page you had checked to add this 'gotcha'... Regards, Mark Cibula (z/VM TCP/IP Support)
Re: Version 4 to Version 5
Ye...you're right. I keep forgetting that on VM/SP 5 we were on FSF and converted to SFS on VM/SP 6. I believe that FSF was File Sharing Facility. Interesting, but compared to SFS, it was garbage. G Tom Duerbusch THD Consulting Kris Buelens kris.buel...@gmail.com 3/16/2009 4:14 PM SFS in VM/SP R5??? Normal mortals could not lay their hand on SFS until VM/SP R6. 2009/3/16 Tom Duerbusch duerbus...@stlouiscity.com Well, for going forward, it works without any issues. My z/VM 5.2 SFS VMSERVU server was initially created on VM/SP 5 and has been thru many upgrades since. (But no down grades). If you have a tape backup of any pool, use Ditto to browse the first block. It will say what version/release of VM did the initial creation/format of that pool. Tom Duerbusch THD Consulting -- Kris Buelens, IBM Belgium, VM customer support
Re: New CMS based SSLSERV problem... DTCSSL300E
Dennis (and Mark W) -- Apologies for the somewhat duplicate posting - ran into a browser timeout whilst putting my posting together.. I would like to suggest how one ca n implement DTCPARMS server customizations (building on Dennis' post) to better isolate them, and to lessen the impact of changes to the IBM DTCPA RMS file itself. * Use this 'override' entry in the SYSTEM DTCPARMS file: * (Because the 'parms' value is overridden, the :parm. tag/value from IBM * DTCPARMS needs to first be duplicated and then modified within this * (SYSTEM DTCPARMS) file so as not to lose the Keyfile information. :nick.SSLSERV:type.server :class.ssl :Admin_ID_list.TCPMAINT GSKADMIN SYSPROG1 SYSPROG2 :parms.KEYFile /etc/gskadm/Database.kdb MAXSESSIONS 30 EXEMPT LOW With the above ':type.server' entry in place, a ':nick.ssl :type.class' entry should no longer be necessary within SYSTEM DTCPARMS. The 'class' entry in the IBM DTCPARMS will provide the remainder of the needed tags/v alues. Granted, with the significant change to the ssl 'class' with 540, having done something similar to the above for a 530 SSL 'server' entry, one mig ht still have encountered some problems, since the old/new tags had little i n common... The type of change I suggest above is meant simply to illustrate how to k eep customizations separate from the (IBM) supplied defaults. (And, we do encourage this same type of thing on our own test systems so fewer server s go 'bump' as things are changed). -- Regards, Mark Cibula
Austin SHARE Presentations on linuxvm.org
I've received a few people's presentations so far, so I'll put them up on the web site for starters. Hopefully we'll get more people contributing in the near future. Session Presenter Title 9060Bill Reeder IBM Transformation: Major IT Consolidation Initiative 9111Romney WhiteUsing New CP Features in z/VM 5.4 9113John Franciscovich z/VM's Control Program (CP): Useful Things to Know 9127Mark Post/Martha McConaghy z/VM for MVS Systems Programmers, Part 1 9128Mark Post/Martha McConaghy z/VM for MVS Systems Programmers, Part 2 9133John Franciscovich Configuring, Customizing and Modifying Your VM System Without an IPL 9150Jim Elliott CSE for High Availability and System Management 9156Rich SmrcinaConfiguring LDAP on z/VM and Linux 9202Jim Elliott Linux on System z - A Strategic View 9224/9225 Mark Post Linux System Management for the Mainframe System Programmer 9230Mark Post Saving Real Storage with Execute in Place on Linux for System z 9233Mark Post Linux Installation Planning 9242Neale Ferguson Linux for Beginners Hands-On Lab 9250Neale Ferguson Basic Linux Scripting Hands-On Lab 9272David Kreuter Taming Your Storage Hungry Linuxen Using CMM(A) 9274Ed MacKenty The Linux IPL Procedure 9275Gerard C. Shockley How Boston University Uses Oracle on Linux to Exploit its IBM System z with Open Systems and Open Standards 9277Brad Hinson Fedora for System z: The Open Source Build Process Explained 9284Phil Smith How To Turn a Penguin Into a Dog ...or... Things To Do That Will Avoid Linux on z Success 9287Mark Post Installing the Novell SLES 10 Starter System without a Net(work) 9293Shawn Wells What's new with Red Hat Enterprise Linux 5 9294Ed MacKenty Automating Resource Management for Linux on z/VM: Lessons Learned http://linuxvm.org/Present/#share112 Mark Post
