Re: PRIROUTER question
On Fri, Jun 27, 2008 at 7:06 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think, we shouldn't waste time in discussing Shimon's font settings. I have put his picture through the clipboard into my editor and the picture was in fixed font. This was an effort of about 5 seconds. Indeed, that discussion is getting certainly non-proportional. :-) Since you already have a static route into the LPAR B, traffic for Y should go there. When the CTC to TCPIP in VM B comes up, TCPIP should register the IP address for Y in the OAT and make the OSA happy. Does the HMC show the entry for Y in the OAT? There were some issues there long ago, how old is your hardware and software? Maybe also good to understand why you can't go to VSWITCH, since that does address all the routing pain we had before. -Rob
Re: Tape Unit Documentation
If you have 3480's installed yet, you should be able to go to the computer room and find the CE's rack of maintenance manuals. You should be able to find what you want there. Jim Rob van der Heij wrote: On Thu, Jun 26, 2008 at 10:49 PM, Schuh, Richard [EMAIL PROTECTED] wrote: I was able to dig the CCWs out of HCPTTP, so reference cards are not needed. It would stll be nice if I could find the manual online. Close... My Hardware Collection CD of 1996 has the 3490E Hardware Reference. It lists with the CCWs where 3490E differs from 3480. The book GA32-0219-02 is 244 kB (but the Java ILR is 60 MB download). Rob -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: SHARE Group APLS Project REXX Requirements
So I take this to mean that SHARE will no longer accept requirements against REXX on z/OS since it appears that it will no longer be enhanced? I find that very interesting (surprising)... was there an announcement to that affect? Alan Ackerman wrote: This message was posted by Alan Ackerman on behalf of Kenneth Tomiak, SHARE Rexx Project Manager. -- IBM REXX on z/OS is in 'maintenance mode'. All IBM REXX requirements are rejected for that reason. Unless something changes, there is no reason to keep submitting, discussing, and voting on REXX requirements. We are trying to find who supports IBM REXX on z/VM to see if it is also in maintenance mode. etc, etc... -- 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
Moving User Maint's minidisks.
Hello all, I have to move user maint's minidisk to a new volume. Problem is that there isn't either a first level or second level system here I could use to do this and a good number of other logged on users who can't be shut down have links to maint's minidisks to say the least is the 19E 19D. Management says no shutting down VM and no IPL. Any suggestions would be appreciated. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: Moving User Maint's minidisks.
Hi, Howard. Try the following: 1) create another VM user id with the proper privileges. Call it, say, MAINTX. 2) create the new MAINT mindisks on the new volume,using your favorite directory manager tools. 3) logo off of MAINT 4) from MAINTX, link to both the old MAINT's minidisks, and the new minidisks on the new volume. 5) do a DDR from each old minidisk to the new one. 6) update all of the other user directory entries to point to the new MAINT minidisk locations, and bring the directory online. It will not matter that other users have links to MAINT's old minidisks, as these links should be r/o only. As users log off and back on again, they will pick up the new location for MAINT's minidisks. When the last user using the old minidisk location logs off, you can then reclaim that DASD space for other uses. No shutdown and no IPL required. Good luck. Howard Rifkind wrote: Hello all, I have to move user maint's minidisk to a new volume. Problem is that there isn't either a first level or second level system here I could use to do this and a good number of other logged on users who can't be shut down have links to maint's minidisks to say the least is the 19E 19D. Management says no shutting down VM and no IPL. Any suggestions would be appreciated. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: Moving User Maint's minidisks.
Thanks all...great suggestions. Dave Jones [EMAIL PROTECTED] 6/27/2008 9:52 AM Hi, Howard. Try the following: 1) create another VM user id with the proper privileges. Call it, say, MAINTX. 2) create the new MAINT mindisks on the new volume,using your favorite directory manager tools. 3) logo off of MAINT 4) from MAINTX, link to both the old MAINT's minidisks, and the new minidisks on the new volume. 5) do a DDR from each old minidisk to the new one. 6) update all of the other user directory entries to point to the new MAINT minidisk locations, and bring the directory online. It will not matter that other users have links to MAINT's old minidisks, as these links should be r/o only. As users log off and back on again, they will pick up the new location for MAINT's minidisks. When the last user using the old minidisk location logs off, you can then reclaim that DASD space for other uses. No shutdown and no IPL required. Good luck. Howard Rifkind wrote: Hello all, I have to move user maint's minidisk to a new volume. Problem is that there isn't either a first level or second level system here I could use to do this and a good number of other logged on users who can't be shut down have links to maint's minidisks to say the least is the 19E 19D. Management says no shutting down VM and no IPL. Any suggestions would be appreciated. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: Moving User Maint's minidisks.
One addition question: Doesn't all of this (19E 19D) have some effect on the saved segments for CMS? Dave Jones [EMAIL PROTECTED] 6/27/2008 9:52 AM Hi, Howard. Try the following: 1) create another VM user id with the proper privileges. Call it, say, MAINTX. 2) create the new MAINT mindisks on the new volume,using your favorite directory manager tools. 3) logo off of MAINT 4) from MAINTX, link to both the old MAINT's minidisks, and the new minidisks on the new volume. 5) do a DDR from each old minidisk to the new one. 6) update all of the other user directory entries to point to the new MAINT minidisk locations, and bring the directory online. It will not matter that other users have links to MAINT's old minidisks, as these links should be r/o only. As users log off and back on again, they will pick up the new location for MAINT's minidisks. When the last user using the old minidisk location logs off, you can then reclaim that DASD space for other uses. No shutdown and no IPL required. Good luck. Howard Rifkind wrote: Hello all, I have to move user maint's minidisk to a new volume. Problem is that there isn't either a first level or second level system here I could use to do this and a good number of other logged on users who can't be shut down have links to maint's minidisks to say the least is the 19E 19D. Management says no shutting down VM and no IPL. Any suggestions would be appreciated. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: Moving User Maint's minidisks.
Hi, Howard. No, there is no effect on the CMS saved segments...they are only effected if you change the their contents, not just their location. Howard Rifkind wrote: One addition question: Doesn't all of this (19E 19D) have some effect on the saved segments for CMS? Dave Jones [EMAIL PROTECTED] 6/27/2008 9:52 AM Hi, Howard. Try the following: 1) create another VM user id with the proper privileges. Call it, say, MAINTX. 2) create the new MAINT mindisks on the new volume,using your favorite directory manager tools. 3) logo off of MAINT 4) from MAINTX, link to both the old MAINT's minidisks, and the new minidisks on the new volume. 5) do a DDR from each old minidisk to the new one. 6) update all of the other user directory entries to point to the new MAINT minidisk locations, and bring the directory online. It will not matter that other users have links to MAINT's old minidisks, as these links should be r/o only. As users log off and back on again, they will pick up the new location for MAINT's minidisks. When the last user using the old minidisk location logs off, you can then reclaim that DASD space for other uses. No shutdown and no IPL required. Good luck. Howard Rifkind wrote: Hello all, I have to move user maint's minidisk to a new volume. Problem is that there isn't either a first level or second level system here I could use to do this and a good number of other logged on users who can't be shut down have links to maint's minidisks to say the least is the 19E 19D. Management says no shutting down VM and no IPL. Any suggestions would be appreciated. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: Moving User Maint's minidisks.
Why an extra user? Just use MAINT, and change the addresses. I'd use the password fields to tell which is which, for example MDISK A190 3390 nnn mmm oldvol RR OLD190 TOREMOVE mmdd MDISK 0190 3390 kkk mmm newvo RR ALL And, if you have an ESM, the passwords on the MDISK records don't count anymore, so you can then also store some information on the 190 MDISK record. 2008/6/27 Dave Jones [EMAIL PROTECTED]: Hi, Howard. No, there is no effect on the CMS saved segments...they are only effected if you change the their contents, not just their location. Howard Rifkind wrote: One addition question: Doesn't all of this (19E 19D) have some effect on the saved segments for CMS? Dave Jones [EMAIL PROTECTED] 6/27/2008 9:52 AM Hi, Howard. Try the following: 1) create another VM user id with the proper privileges. Call it, say, MAINTX. 2) create the new MAINT mindisks on the new volume,using your favorite directory manager tools. 3) logo off of MAINT 4) from MAINTX, link to both the old MAINT's minidisks, and the new minidisks on the new volume. 5) do a DDR from each old minidisk to the new one. 6) update all of the other user directory entries to point to the new MAINT minidisk locations, and bring the directory online. It will not matter that other users have links to MAINT's old minidisks, as these links should be r/o only. As users log off and back on again, they will pick up the new location for MAINT's minidisks. When the last user using the old minidisk location logs off, you can then reclaim that DASD space for other uses. No shutdown and no IPL required. Good luck. Howard Rifkind wrote: Hello all, I have to move user maint's minidisk to a new volume. Problem is that there isn't either a first level or second level system here I could use to do this and a good number of other logged on users who can't be shut down have links to maint's minidisks to say the least is the 19E 19D. Management says no shutting down VM and no IPL. Any suggestions would be appreciated. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com -- Kris Buelens, IBM Belgium, VM customer support
Re: Tape Unit Documentation
Four problems with the idea: 1. Our only real tapes are 3490s. 2. It would be a two day round trip by air to get to the data center. 3. I would have to pay the bill for my travel and call it a vacation. 4. When I got there, I would not be allowed to enter the machine room. Nothing major, though. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack Sent: Friday, June 27, 2008 5:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Tape Unit Documentation If you have 3480's installed yet, you should be able to go to the computer room and find the CE's rack of maintenance manuals. You should be able to find what you want there. Jim
IBM Ops/Mgr for z/VM and LISTSG package
Kris - or anyone. Are there any plans to enhance the LISTSG package member URLIST to support the new VIEWSPL feature in IBM's Operations Manager for z/VM 1.3 ? Thanks Lionel B. Dyck, Consultant/Specialist Enterprise Platform Services, Mainframe Engineering KP-IT Enterprise Engineering 925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED] AIM: lbdyck | Yahoo IM: lbdyck Kaiser Service Credo: Our cause is health. Our passion is service. We?re here to make lives better.? ?Never attribute to malice what can be caused by miscommunication.? NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you. image/gif
Re: Moving User Maint's minidisks.
I do remember you can get messages about shared Y- stat for the Y disk. Same goes for S-stat if you were to copy the 190 disk. The saved segments have to agree with the minidisks. Use DDR to copy the old disk to the new disk. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: Friday, June 27, 2008 10:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Moving User Maint's minidisks. One addition question: Doesn't all of this (19E 19D) have some effect on the saved segments for CMS? Dave Jones [EMAIL PROTECTED] 6/27/2008 9:52 AM Hi, Howard. Try the following: 1) create another VM user id with the proper privileges. Call it, say, MAINTX. 2) create the new MAINT mindisks on the new volume,using your favorite directory manager tools. 3) logo off of MAINT 4) from MAINTX, link to both the old MAINT's minidisks, and the new minidisks on the new volume. 5) do a DDR from each old minidisk to the new one. 6) update all of the other user directory entries to point to the new MAINT minidisk locations, and bring the directory online. It will not matter that other users have links to MAINT's old minidisks, as these links should be r/o only. As users log off and back on again, they will pick up the new location for MAINT's minidisks. When the last user using the old minidisk location logs off, you can then reclaim that DASD space for other uses. No shutdown and no IPL required. Good luck. Howard Rifkind wrote: Hello all, I have to move user maint's minidisk to a new volume. Problem is that there isn't either a first level or second level system here I could use to do this and a good number of other logged on users who can't be shut down have links to maint's minidisks to say the least is the 19E 19D. Management says no shutting down VM and no IPL. Any suggestions would be appreciated. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. *
Re: Moving User Maint's minidisks.
Do the renames (MAINT--MAINTOLD and MAINTX--MAINT) in the source directory and update the object directory. That will put both into effect at the same time. With no problems with new users log on. If they logon before the DIRECTXA command they get the old disks and if the logon after the command is issued they get the new disks. The only problem is that there are service machines that are not normally ever logged off. (Like TCPIP, VTAM, OPERATOR, SFS servers, etc.) If any of those use one of the disks you moved then they would need to be restarted. Restarting some of these could cause an outage. Shimon Lebowitz wrote: I would not do step 6 - updating all your users to MAINTX would be a nightmare. What you need is a 30 second window for problems, while you rename MAINT to MAINTOLD and MAINTX to MAINT. Then all new links will get the new versions. I don't remember the setting that prevents any new users from logging on (SET MAXUSERS 0?) but try it before the change so that no one will get messed up, and remember to fix it immediately afterwards. Shimon -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Moving User Maint's minidisks.
I also would not create another id. Just create new MAINT mdisks, do DDR copies and then flip flop the mdisks in MAINT's directory and DIRM REPLACE. We use DIRMAINT. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Friday, June 27, 2008 11:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Moving User Maint's minidisks. Why an extra user? Just use MAINT, and change the addresses. I'd use the password fields to tell which is which, for example MDISK A190 3390 nnn mmm oldvol RR OLD190 TOREMOVE mmdd MDISK 0190 3390 kkk mmm newvo RR ALL And, if you have an ESM, the passwords on the MDISK records don't count anymore, so you can then also store some information on the 190 MDISK record. 2008/6/27 Dave Jones [EMAIL PROTECTED]: Hi, Howard. No, there is no effect on the CMS saved segments...they are only effected if you change the their contents, not just their location. Howard Rifkind wrote: One addition question: Doesn't all of this (19E 19D) have some effect on the saved segments for CMS? Dave Jones [EMAIL PROTECTED] 6/27/2008 9:52 AM Hi, Howard. Try the following: 1) create another VM user id with the proper privileges. Call it, say, MAINTX. 2) create the new MAINT mindisks on the new volume,using your favorite directory manager tools. 3) logo off of MAINT 4) from MAINTX, link to both the old MAINT's minidisks, and the new minidisks on the new volume. 5) do a DDR from each old minidisk to the new one. 6) update all of the other user directory entries to point to the new MAINT minidisk locations, and bring the directory online. It will not matter that other users have links to MAINT's old minidisks, as these links should be r/o only. As users log off and back on again, they will pick up the new location for MAINT's minidisks. When the last user using the old minidisk location logs off, you can then reclaim that DASD space for other uses. No shutdown and no IPL required. Good luck. Howard Rifkind wrote: Hello all, I have to move user maint's minidisk to a new volume. Problem is that there isn't either a first level or second level system here I could use to do this and a good number of other logged on users who can't be shut down have links to maint's minidisks to say the least is the 19E 19D. Management says no shutting down VM and no IPL. Any suggestions would be appreciated. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com -- Kris Buelens, IBM Belgium, VM customer support * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. *
Re: SHARE Group APLS Project REXX Requirements
It must be too easy to use for it to be allowed to thrive on that other platform :-( Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Ackerman Sent: Thursday, June 26, 2008 6:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject: SHARE Group APLS Project REXX Requirements This message was posted by Alan Ackerman on behalf of Kenneth Tomiak, SHARE Rexx Project Manager. -- IBM REXX on z/OS is in 'maintenance mode'. All IBM REXX requirements are = rejected for that reason. Unless something changes, there is no reason to= keep submitting, discussing, and voting on REXX requirements. We are trying to find who supports IBM REXX on z/VM to see if it is also in maintenance mode. Sorry about IBM REXX on z/OS being moth-balled as far as any new development goes. If any of you would like to present at a SHARE Conference on a Rexx topic= , please get in touch with me. We have many z/OS experienced speakers, but = I do not have any z/VM experienced speakers and topics. It is the Rexx Project, so while Rexx on any platform is a potential session, SHARE is a= n IBM Mainframe user group, so preference is given to z/OS and z/VM. Find me at http://www.share.org/Volunteers/ProgramsandProjects/LanguagesP rogram/Rexx= Pr oject/tabid/233/Default.aspx (Watch for a URL broken across 2 lines!) Alan Ackerman= Alan (dot) Ackerman (at) Bank of America (dot) com
Re: Moving User Maint's minidisks.
For example, I created a new 193 ... new address 1193 accessed it as E and did a format of the new 1193 mini accessed as F. I then did a copy from 193 to 1193. No issue here. Now is it save to swap the 1193 to 193 although several user have access to the 193. In the directory I'm going to comment out the original 193 and give the 1193 mini the 193 address. (your comments please) Several people have mentioned DDR for the copy. What is the advantage there ... if any. Thanks Smith, Ann (ISD, IT) [EMAIL PROTECTED] 6/27/2008 11:34 AM I also would not create another id. Just create new MAINT mdisks, do DDR copies and then flip flop the mdisks in MAINT's directory and DIRM REPLACE. We use DIRMAINT. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Friday, June 27, 2008 11:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Moving User Maint's minidisks. Why an extra user? Just use MAINT, and change the addresses. I'd use the password fields to tell which is which, for example MDISK A190 3390 nnn mmm oldvol RR OLD190 TOREMOVE mmdd MDISK 0190 3390 kkk mmm newvo RR ALL And, if you have an ESM, the passwords on the MDISK records don't count anymore, so you can then also store some information on the 190 MDISK record. 2008/6/27 Dave Jones [EMAIL PROTECTED]: Hi, Howard. No, there is no effect on the CMS saved segments...they are only effected if you change the their contents, not just their location. Howard Rifkind wrote: One addition question: Doesn't all of this (19E 19D) have some effect on the saved segments for CMS? Dave Jones [EMAIL PROTECTED] 6/27/2008 9:52 AM Hi, Howard. Try the following: 1) create another VM user id with the proper privileges. Call it, say, MAINTX. 2) create the new MAINT mindisks on the new volume,using your favorite directory manager tools. 3) logo off of MAINT 4) from MAINTX, link to both the old MAINT's minidisks, and the new minidisks on the new volume. 5) do a DDR from each old minidisk to the new one. 6) update all of the other user directory entries to point to the new MAINT minidisk locations, and bring the directory online. It will not matter that other users have links to MAINT's old minidisks, as these links should be r/o only. As users log off and back on again, they will pick up the new location for MAINT's minidisks. When the last user using the old minidisk location logs off, you can then reclaim that DASD space for other uses. No shutdown and no IPL required. Good luck. Howard Rifkind wrote: Hello all, I have to move user maint's minidisk to a new volume. Problem is that there isn't either a first level or second level system here I could use to do this and a good number of other logged on users who can't be shut down have links to maint's minidisks to say the least is the 19E 19D. Management says no shutting down VM and no IPL. Any suggestions would be appreciated. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com -- Kris Buelens, IBM Belgium, VM customer support * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. * _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: Moving User Maint's minidisks.
If you are moving MAINT 190 you must use DDR to copy all of it. If you move MAINT 19E and you use DDR then you don't have to save CMS after it is moved. With any other disk you can save the FORMAT step and the ACCESS. Your plan would work if you are careful. If you just comment out the original MDISK, DIRMAP will show that as free space. No problem, unless you or someone else decides to use that free space. :( Anyone that is still linked to the old space will get errors. Howard Rifkind wrote: For example, I created a new 193 ... new address 1193 accessed it as E and did a format of the new 1193 mini accessed as F. I then did a copy from 193 to 1193. No issue here. Now is it save to swap the 1193 to 193 although several user have access to the 193. In the directory I'm going to comment out the original 193 and give the 1193 mini the 193 address. (your comments please) Several people have mentioned DDR for the copy. What is the advantage there ... if any. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Moving User Maint's minidisks.
Thanks Stephen, that's what I thought and you confirmed the issue with those people already linked to disks in question. Stephen Frazier [EMAIL PROTECTED] 6/27/2008 11:58 AM If you are moving MAINT 190 you must use DDR to copy all of it. If you move MAINT 19E and you use DDR then you don't have to save CMS after it is moved. With any other disk you can save the FORMAT step and the ACCESS. Your plan would work if you are careful. If you just comment out the original MDISK, DIRMAP will show that as free space. No problem, unless you or someone else decides to use that free space. :( Anyone that is still linked to the old space will get errors. Howard Rifkind wrote: For example, I created a new 193 ... new address 1193 accessed it as E and did a format of the new 1193 mini accessed as F. I then did a copy from 193 to 1193. No issue here. Now is it save to swap the 1193 to 193 although several user have access to the 193. In the directory I'm going to comment out the original 193 and give the 1193 mini the 193 address. (your comments please) Several people have mentioned DDR for the copy. What is the advantage there ... if any. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: Moving User Maint's minidisks.
On: Fri, Jun 27, 2008 at 11:43:21AM -0400,Howard Rifkind Wrote: } Now is it save to swap the 1193 to 193 although several user have access to the 193. In the directory I'm going to comment out the original 193 and give the 1193 mini the 193 address. (your comments please) Don't just delete the old 193, make it 2193 and leave it in the directory. That way the space is flagged as in use and won't be reallocated accidentally. And you can always do a: CP LINK MAINT 2913 2193 RR CP Q LINKS 2193 CP DET 2193 in an exec to see who still has the old disk. At some point you are going to have a partial outage to do the final cleanup. When only the never logged off SVMs are left, you will have to restart them at some point. You could try doing something like: CP SEND CP svm DETACH 190 CP SEND CP svm LINK * 190 190 RR for each svm for each disk, but since CMS in the svm will detect that the disk is detached and release it you would also have to send it a CMS command to reaccess it. Not really recommended as too much potential for disruption. Just a thought. -- Rich Greenberg N Ft Myers, FL, USA richgr atsign panix.com + 1 239 543 1353 Eastern time. N6LRT I speak for myself my dogs only.VM'er since CP-67 Canines:Val, Red, Shasta Casey (RIP), Red Zero, Siberians Owner:Chinook-L Retired at the beach Asst Owner:Sibernet-L
Re: Moving User Maint's minidisks.
Actually, if your ESM is VM:Secure you don't have to worry about any of this. He'll happily let you move R/O minidisks AND automatically reclaim the old extent after ALL links to it have been severed. As long as you aren't changing the size of the disk, I believe he'll copy it track by track (just like DDR) so the NSS's shouldn't have a problem either. -MC -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens And, if you have an ESM, the passwords on the MDISK records don't count anymore, so you can then also store some information on the 190 MDISK record.
Re: IBM Ops/Mgr for z/VM and LISTSG package
If you give me details, I will. - what is the command to use - which parameters - can it display OPEN files? - is there a standard server userid I could QUERY to prepare its use ( I do that for VMSPOOL: if VMSPOOL is logged on, I set other PF-keys) 2008/6/27 Lionel B. Dyck [EMAIL PROTECTED]: Kris - or anyone. Are there any plans to enhance the LISTSG package member URLIST to support the new VIEWSPL feature in IBM's Operations Manager for z/VM 1.3 ? Thanks Lionel B. Dyck, Consultant/Specialist Enterprise Platform Services, Mainframe Engineering KP-IT Enterprise Engineering 925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED] AIM: lbdyck | Yahoo IM: lbdyck Kaiser Service Credo: Our cause is health. Our passion is service. We're here to make lives better. Never attribute to malice what can be caused by miscommunication. NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you. -- Kris Buelens, IBM Belgium, VM customer support
Re: Moving User Maint's minidisks.
If you use Dirmaint: use the CLEAN option for a DMDDISK or CMDISK (delete/change minidisk): the DATAMOVE tries to get an exclusive link. Only when that succeeds, the minidisk is cleared after which it becomes free for re-use. Without CLEAN, the problem is not only that current users of old minidisk are not protected at all, but you may get extra trouble: Suppose an old minidisk started at cyl 100, and cyl 90-99 were free. After a DMISK, a new 20 cylinder minidisk is created from cyl 90 through 109. Now if one tries to link the new minidisk in write, CP will refuse if the old minidisk is linked R/W. If you link R/O and issue Q LINKS to see who's prohibiting your R/W request, CP tells no links. Because for Q LINKS CP checks who's having minidisks with the same start cylinder (no I don't have an exec to find this out, even though I think I once had). 2008/6/27 Michael Coffin [EMAIL PROTECTED]: Actually, if your ESM is VM:Secure you don't have to worry about any of this. He'll happily let you move R/O minidisks AND automatically reclaim the old extent after ALL links to it have been severed. As long as you aren't changing the size of the disk, I believe he'll copy it track by track (just like DDR) so the NSS's shouldn't have a problem either. -MC -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens And, if you have an ESM, the passwords on the MDISK records don't count anymore, so you can then also store some information on the 190 MDISK record. -- Kris Buelens, IBM Belgium, VM customer support
Re: SHARE Group APLS Project REXX Requirements
On Fri, 27 Jun 2008 07:29:13 -0500, Rich Smrcina [EMAIL PROTECTED] wro te: So I take this to mean that SHARE will no longer accept requirements against REXX on z/OS since it appears that it will no longer be enhanced? I find that very interesting (surprising)... was there an announcement to that affect? Alan Ackerman wrote: This message was posted by Alan Ackerman on behalf of Kenneth Tomiak, SHARE Rexx Project Manager. -- Kenneth Tomiak sent essentially the same email to everyone who was regist ered for REXX requirements at SHARE. He is the SHARE Rexx Project Manager so that const itutes an announcement. I got his permission to post it here. (The only change was to the 'how to contact me' part. He didn't want bots harvesting his email address and sending him spam.) IBM has rejected the last N REXX requirements. I think he decided to sto p beating his head against a brick wall. (Or IBM told him to.) I asked him if the same thing applied to REXX on VM. He said he would res earch that. I'm guessing there is only one REXX at IBM, but I could be wrong. If we wanted to write requirements we could ask for ANSI REXX compliance. But I don't think there is a big chance that IBM would say yes -- unless we could find a business case for making z/VM more attractive to Linux. I've been using Regina REXX on my Mac and I like it. Alan Ackerman Alan (dot) Ackerman (at) Bank of America (dot) com
