Consumption of RAM causes problems with tcpip
Hello, I have 2 SUSE Linux 9 servers under z/VM 5.2 and when one of them starts to use all of its RAM (example: when copying huge files or work with java , portal), suddenly both of them stop responding by tcpip. I can see under z/VM, that servers still work, only can't do anything by tcpip. I found only one way to retrieve communication by tcpip, simply reipl linux under z/VM. Any ideas why it happens? Regards Sebastian
Re: Consumption of RAM causes problems with tcpip
On Thu, Jan 15, 2009 at 12:10 PM, Hebda Sebastian s.he...@kghm.pl wrote: Hello, I have 2 SUSE Linux 9 servers under z/VM 5.2 and when one of them starts to use all of its RAM (example: when copying huge files or work with java, portal), suddenly both of them stop responding by tcpip. I can see under z/VM, that servers still work, only can't do anything by tcpip. I found only one way to retrieve communication by tcpip, simply reipl linux under z/VM. You need a performance monitor to collect the data and understand what is preventing them to run. Without that data, I can only guess. It sounds like one or both have landed in the eligable list and don't get dispatched anymore. If you reduce the size of the virtual machines, things will run better. If you have not tuned your VM system, MDC may need to be limited to avoid taking too much storage (with SET MDC STOR 0M 256M for example). If you have sufficient paging space defined you can overcommit memory by SET SRM STORBUF Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Sharing the RACF database in CSE
Dear all, I am planning to setup RACF in a CSE environemnt. The CSE is on two different processors. I have read in the Program Directory that in this c ase the RACF database mustn't be on a CSE formatted volume since it uses real reserve/release CCWs. Therefore I can put it only on a real volume and dedicate it to RACFVM or make a fullpack minidisk out of it. Isn't that an overkill of dedicating two full 3390 addresses (5 GB) for 2 x 17 cylinder of data, the size of the database?? Could I put the Primary and the Backup at least on the same volume? What would you recommend? Thank you. Best regards, Florian
Re: Sharing the RACF database in CSE
On 1/15/09 11:11 AM, Florian Bilek florian.bi...@gmail.com wrote: I am planning to setup RACF in a CSE environemnt. The CSE is on two different processors. I have read in the Program Directory that in this c ase the RACF database mustn't be on a CSE formatted volume since it uses real reserve/release CCWs. Therefore I can put it only on a real volume and dedicate it to RACFVM or make a fullpack minidisk out of it. That's how I always understood it. I tried to APAR it years ago, and didn't get very far, so I gave up. The answer I received was that it would make major changes in how the RACF database management logic works on z/OS, so they didn't want to change it. Isn't that an overkill of dedicating two full 3390 addresses (5 GB) for 2 x 17 cylinder of data, the size of the database?? Yes. That's just the way RACF works, AFAIK. It's a waste, but c'est la vie. Could I put the Primary and the Backup at least on the same volume? Kind of defeats the point if the physical volume chokes for some reason. You should have the Backup on a different physical volume.
Sorting monitor data?
Can monitor data be sorted so that it can be fed into CP3KVMXT (CP3000 summarizer)? We collect monitor data using Brian Wade's LINMON package which allows us to collect it into smaller files. We then FTP these files over to z/OS for processing by MXG. Problem is CP3KVMXT doesn't like it when the files are in reverse order, so I'd like to sort them before feeding to CP3KVMXT. Any idea on how I'd go about doing that? Thanks, Leland
Re: Sharing the RACF database in CSE
On Thursday, 01/15/2009 at 11:11 EST, Florian Bilek florian.bi...@gmail.com wrote: I am planning to setup RACF in a CSE environemnt. The CSE is on two different processors. I have read in the Program Directory that in this case the RACF database mustn't be on a CSE formatted volume since it uses real reserve/release CCWs. Therefore I can put it only on a real volume and dedicate it to RACFVM or make a fullpack minidisk out of it. Isn't that an overkill of dedicating two full 3390 addresses (5 GB) for 2 x 17 cylinder of data, the size of the database?? Could I put the Primary and the Backup at least on the same volume? What would you recommend? Don't put the primary and backup on the same dasd. The whole point of the backup is to have a good database in case you get a h/w failure on the primary volume. If your storage controller allows it you can carve out smaller volumes (e.g. 200 cyls). While it might be wasteful, database integrity is more important than unused cylinders. Alan Altmark z/VM Development IBM Endicott
Re: Sharing the RACF database in CSE
Couldn't you define a very small 3390 volume for this purpose in the storage subsystem so that at least you're waste is less Lionel B. Dyck, Consultant/Specialist From: David Boyes dbo...@sinenomine.net To: IBMVM@LISTSERV.UARK.EDU Date: 01/15/2009 08:22 AM Subject: Re: Sharing the RACF database in CSE Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU On 1/15/09 11:11 AM, Florian Bilek florian.bi...@gmail.com wrote: I am planning to setup RACF in a CSE environemnt. The CSE is on two different processors. I have read in the Program Directory that in this c ase the RACF database mustn't be on a CSE formatted volume since it uses real reserve/release CCWs. Therefore I can put it only on a real volume and dedicate it to RACFVM or make a fullpack minidisk out of it. That's how I always understood it. I tried to APAR it years ago, and didn't get very far, so I gave up. The answer I received was that it would make major changes in how the RACF database management logic works on z/OS, so they didn't want to change it. Isn't that an overkill of dedicating two full 3390 addresses (5 GB) for 2 x 17 cylinder of data, the size of the database?? Yes. That's just the way RACF works, AFAIK. It's a waste, but c'est la vie. Could I put the Primary and the Backup at least on the same volume? Kind of defeats the point if the physical volume chokes for some reason. You should have the Backup on a different physical volume.
Re: Sharing the RACF database in CSE
On 1/15/09 11:25 AM, Lionel B. Dyck lionel.b.d...@kp.org wrote: Couldn't you define a very small 3390 volume for this purpose in the storage subsystem so that at least you're waste is less Yeah. Minidisks by any other name, but It¹s just annoying that RACF is so VM-hostile.
Re: Sorting monitor data?
Forewarning: I have no knowledge of LINMON package details. There may/must be better ways of doing this, but this may help. Isn't there a sufficient date/timestamp already on each generated record that could be used to sort them before CP3KVMXT processing? If not, would it be possible in your case to modify the LINMON package or the MSUX EXEC (exit) to write a prefix at the start of each record before it is written to disk. That prefix could be the mmddhhmmssnn where yymmddhhmmss is the time that this process prefix began, and the 'nnn's are a sequence number (easily generated with a PIPEs SPECS stage). When you are ready to run them into CP3KVMXT, first sort on that prefix, and stripping it before re-writing them all as one large file. But that seems to defeat the purpose of writing the file in smaller pieces, no? Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Leland Lucius lluc...@homerow.net Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 01/15/2009 10:23 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Sorting monitor data? Can monitor data be sorted so that it can be fed into CP3KVMXT (CP3000 summarizer)? We collect monitor data using Brian Wade's LINMON package which allows us to collect it into smaller files. We then FTP these files over to z/OS for processing by MXG. Problem is CP3KVMXT doesn't like it when the files are in reverse order, so I'd like to sort them before feeding to CP3KVMXT. Any idea on how I'd go about doing that? Thanks, Leland The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: Sharing the RACF database in CSE
I use the stubby volumes (less than a mod-3) at the end of the string for exactly this reason. You can DEDICATE the volumes as 200 and 300 in the directory, but then you can't get them attached anywhere else. I define them this way now: MDISK 0200 3390 DEVNO 461F MWV MDISK 0300 3390 DEVNO 641F MWV The magic is the combination of a DEVNO fullpack with the V - VM will do virtual reserve release that gets pushed to the real bit on the device - it works both within a single VM system and across CECs as far as I can tell. I'm sharing the DB across 6 CECs this way. -- Jay Brenneman
Re: Sharing the RACF database in CSE
Don't put the primary and backup on the same dasd. The whole point of the backup is to have a good database in case you get a h/w failure on the primary volume. Seems that with modern DASD, one never gets a volume failure anymore. You either lose nothing or you lose the whole darn subsystem or big chunk of it. Put it on a different box :) Or use PPRC to a different box if it really is that critical. If not, take regular, frequent backups to tape. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Don't put the primary and backup on the same dasd. The whole point of the backup is to have a good database in case you get a h/w failure on the primary volume. If your storage controller allows it you can carve out smaller volumes (e.g. 200 cyls). While it might be wasteful, database integrity is more important than unused cylinders. Alan Altmark z/VM Development IBM Endicott
Re: Sharing the RACF database in CSE
Dear all, Thanks a lot for this real quick answers. Have hoped to avoid a reconfiguration of the storage subsystem. Seems there would be some room for future enhancement of this issue ;-) Best regards, Florian
Re: Sharing the RACF database in CSE
I(ve got a CP mod that allows a Reserve/Release on non-fullpack volumes. Created for my customer at a time they had 3 or 4 softwares that each needed 2 R/R minidisks. Without the mod, we'd had to devote 8 full packs, each with a few cylinders in use. The mod is basically simply commenting out the check for fullpack minidisks, HCPGDS is the module name, 6 lines to comment (another 6 lines were required to avoid R/R being sent to next existing HW for VDISKs). This mod didn't require any change since I created it somewhere in the VM/ESA timeframe. But, it is left to the sysprog not to place more than 1 minidisk requiring R/R on a given pack. Because, the mod is so basic: a Release requested by a virt machine is let through to the HW, nothing exists to check if no other minidisk on that volume has an outstanding Reserve, what would require that the disk should still remain Reserved for this system on the HW level. Available on request, alongside a small asm program one can use to check that R/R is indeed passed to the HW. Obviously: use on your own risk. 2009/1/15 Florian Bilek florian.bi...@gmail.com: Dear all, Thanks a lot for this real quick answers. Have hoped to avoid a reconfiguration of the storage subsystem. Seems there would be some room for future enhancement of this issue ;-) Best regards, Florian -- Kris Buelens, IBM Belgium, VM customer support
Re: Sorting monitor data?
Mike Walter wrote: Forewarning: I have no knowledge of LINMON package details. There may/must be better ways of doing this, but this may help. Isn't there a sufficient date/timestamp already on each generated record that could be used to sort them before CP3KVMXT processing? Yepper, there's a date field and I've tried sorting by that, but CP3KVMXT specifically look for a record beginning with '87'x as the first record. Of course, I just had to comment out that check and give it a try, but it causes a specification exception. :-) If not, would it be possible in your case to modify the LINMON package or the MSUX EXEC (exit) to write a prefix at the start of each record before it is written to disk. That prefix could be the mmddhhmmssnn where yymmddhhmmss is the time that this process prefix began, and the 'nnn's are a sequence number (easily generated with a PIPEs SPECS stage). When you are ready to run them into CP3KVMXT, first sort on that prefix, and stripping it before re-writing them all as one large file. But that seems to defeat the purpose of writing the file in smaller pieces, no? Unfortunately, the files in question have already been created. I can fix the out-of-order issue for future collections, but I was hoping to be able to feed CP3KVMXT a particularly nasty day we had recently. Leland
Re: Sharing the RACF database in CSE
If your storage subsystem is a DS6000 or DS8000 series it allocates in extents which are a Mod3 in size. So you waste space for any volume that is not a multiple of a Mod3. On a Shark, you can define odd sizes without wasting space. Brian Nielsen On Thu, 15 Jan 2009 08:25:40 -0800, Lionel B. Dyck lionel.b.d...@kp.org wrote: Couldn't you define a very small 3390 volume for this purpose in the storage subsystem so that at least you're waste is less Lionel B. Dyck, Consultant/Specialist From: David Boyes dbo...@sinenomine.net To: IBMVM@LISTSERV.UARK.EDU Date: 01/15/2009 08:22 AM Subject: Re: Sharing the RACF database in CSE Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU On 1/15/09 11:11 AM, Florian Bilek florian.bi...@gmail.com wrote: I am planning to setup RACF in a CSE environemnt. The CSE is on two different processors. I have read in the Program Directory that in thi s c ase the RACF database mustn't be on a CSE formatted volume since it uses real reserve/release CCWs. Therefore I can put it only on a real volume and dedicate it to RACFVM or make a fullpack minidisk out of it. That's how I always understood it. I tried to APAR it years ago, and didn't get very far, so I gave up. The answer I received was that it would make major changes in how the RACF database management logic works on z/OS, s o they didn't want to change it. Isn't that an overkill of dedicating two full 3390 addresses (5 GB) fo r 2 x 17 cylinder of data, the size of the database?? Yes. That's just the way RACF works, AFAIK. It's a waste, but c'est la vie. Could I put the Primary and the Backup at least on the same volume? Kind of defeats the point if the physical volume chokes for some reason. You should have the Backup on a different physical volume.
Re: Sorting monitor data?
IIRC, that is a configuration record that is written when the monitor is initialized. It was required by MICS. ESAWRITE has the ability to start each raw data file with one of these records. If you don't have ESAWRITE, you can find a configuration record in any file, retain a copy of it and include it in the files processed by the program. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Leland Lucius Sent: Thursday, January 15, 2009 9:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sorting monitor data? Mike Walter wrote: Forewarning: I have no knowledge of LINMON package details. There may/must be better ways of doing this, but this may help. Isn't there a sufficient date/timestamp already on each generated record that could be used to sort them before CP3KVMXT processing? Yepper, there's a date field and I've tried sorting by that, but CP3KVMXT specifically look for a record beginning with '87'x as the first record. Of course, I just had to comment out that check and give it a try, but it causes a specification exception. :-) If not, would it be possible in your case to modify the LINMON package or the MSUX EXEC (exit) to write a prefix at the start of each record before it is written to disk. That prefix could be the mmddhhmmssnn where yymmddhhmmss is the time that this process prefix began, and the 'nnn's are a sequence number (easily generated with a PIPEs SPECS stage). When you are ready to run them into CP3KVMXT, first sort on that prefix, and stripping it before re-writing them all as one large file. But that seems to defeat the purpose of writing the file in smaller pieces, no? Unfortunately, the files in question have already been created. I can fix the out-of-order issue for future collections, but I was hoping to be able to feed CP3KVMXT a particularly nasty day we had recently. Leland
Re: Sharing the RACF database in CSE
I came across the following explanation from IBM when setting up out RACF. Looks like you could use mdisks if only VM shares the database, but you still have to waste the rest of the space on the volumes. .FO OFF .RH ON Item BDC28340 NOM (DATE/20031125) IBM INTERNAL USE ONLY .SP 2 .RH OFF TITLE: RACF database build ***SOURCE: UNITED STATES (ASKQQA) *** -OPM2008 -5799WZY00 -ETRPRO -P3S3-03/11/24-22:13 -XE ** For IBM Use Only * In RETAIN use CR CA to complete the call. * * The use of CC will not notify the originator of a response! * RESPOND ELECTRONICALLY. Route = 5799WZY00 . Abstract: RACF database build Welcome to zSeries Q A Technical Support - Electronic Q/A Service ~ This queue is for VM and related products: DFSMS/VM,DIRMAINT,GCS, ISPF/VM,PVM,RACF/VM,REXX/VM,RSCS,RTM/ESA etc. To help us accurately respond to your GENERAL-USAGE (How-To) QUESTION, please provide the Product Name, Version, Release and Maintenance Level of all software that may be related to this question. Include any other relevant info. that will help expedite a response, eg. hardware installed, error messages etc. Product Name Version/Release Maintenance Level * * You can add the text of your question after you press enter * * I am on z/VM V4R4 with RACF. I am attempting to build a racf database that will be shared with several (level 1) VM systems. The documentation in the RACF program directory (5739-A03) is a little confusing. It recommends using a full volume mini disk but then says do not place any mini disk on cylinder zero. Can you start at cylinder zero? Can you use another name in the racdsf command besides RACF and RACFBK if you start at cylinder zero? If I start at cylinder 1 will the z/VMs do the physical enqueuing to reserve the volume? If not how do I configure them to use that facility? =EVANS, PAUL G -5799WZY00 -L40D/QAVM -P3S -03/11/24-22:38 -CT =EVANS, PAUL G -568411202 -L40D/QAVM -P3S3-03/11/24-22:41 -CR S5 SERVICE GIVEN= 39 SG/39/ S7 SERVICE GIVEN= 39 SG/39/ Action taken: Hello Walter The Program directory is a bit misleading. I will check into this and have a further update for you in the morning. Many Thanks Paul Evans action plan; investigate sharing between VM systems. =EVANS, PAUL G -568411202 -L40D/QAVM -P3S3-03/11/25-16:23 -CR S7 SERVICE GIVEN= 39 SG/39/ Action taken: Hello Walter, That Program Directory is somewhat confusing so I will try to sort it out for you. When sharing a RACF database between VM systems, you have a bit more choice as to how to do it than you have if MVS is in the picture. If a MVS system will ever be sharing this database then that makes a big difference. MVS does not understand what a minidisk is and expects the real label in real cylinder zero to have a VTOC pointer and all the MVS stuff. Thus is MVS is going to share the RACF database, then you would want to use a Full Pack Minidisk for the database addresses. A Full Pack Mini actually starts at Cylinder Zero for the entire volume. The Minidisk statements in the directory would be something like: MDISK 200 3390 0 END RACF MWV MDISK 300 3390 0 END RACFBK MWV Please note that the MWV means Multi Write with Virtual Reserve/Release The volume also needs to have the SHARED option in the SYSTEM CONFIG to tell z/VM to use Real Reserve/Release. In the RACF p^rogram directory, it mentions that you can use different values than RACF and RACFBK by reassembling ICHRDSNT I believe. The RACF System Programmer's Guide has further information about that. If you are just sharing between VM systems and MVS will never be in the picture, then you can define the 200 and 300 as regular minidisks but the EXACT same definition must be made on ALL z/VM systems and again the MWV for the MDISK is needed and the SHARED option in the SYSTEM CONFIG is needed. Note that reserve/release affects the entire volume so it is not wise to place any other minidisks on that volume. Of course, the backup database should be on a different physical volume for availability purposes. Hope this helps clarify things. If you have further questions, please let us know. Many Thanks Paul Evans action plan: await further update from Walter ( or closure ) -OPM2008 -568411202 -ETRPRO -P3S3-03/11/25-17:42 -XC Reason For Closure: Thank you. Beautiful explaination. Include that in the Program Directory. =EVANS, PAUL G -568411202 -L40D/---P3S3-03/11/25-19:46 -AT Action taken: Hello Walter, Many thanks for your comments. I will pass this info along to the authors of the Program Directory for their consideration. In the meantime, I will archive this for our reference.
Re: Sorting monitor data?
Schuh, Richard wrote: IIRC, that is a configuration record that is written when the monitor is initialized. It was required by MICS. ESAWRITE has the ability to start each raw data file with one of these records. If you don't have ESAWRITE, you can find a configuration record in any file, retain a copy of it and include it in the files processed by the program. Just found that out. The MDATPEEK stage that CP3KVMXT uses requires that control record. So, now I have something to work on the rest of the day. :-) Leland
Re: Sharing the RACF database in CSE
This Retain text is still misleading: - an unmodfied CP will never let a Reserve go through the HW for non-fullpack mdisks So, the text about placing the minidisks at the exact same place for all sharing z/VM systems, is useless. - the mode MWV triggers only *Virtual* Reserve/Release. Unless you run two copies of RACF on a single VM system, no Virtual R/R is required. MWV could protect RACFVM and RACMAINT stepping on eachother, but I don't know if CP allows both of them to become active concurrently. 2009/1/15 Greg Dyrda gregory.l.dy...@us.hsbc.com: I came across the following explanation from IBM when setting up out RACF. Looks like you could use mdisks if only VM shares the database, but you still have to waste the rest of the space on the volumes. .FO OFF .RH ON Item BDC28340 NOM (DATE/20031125) IBM INTERNAL USE ONLY .SP 2 .RH OFF TITLE: RACF database build ***SOURCE: UNITED STATES (ASKQQA) *** -OPM2008 -5799WZY00 -ETRPRO -P3S3-03/11/24-22:13 -XE ** For IBM Use Only * In RETAIN use CR CA to complete the call. * * The use of CC will not notify the originator of a response! * RESPOND ELECTRONICALLY. Route = 5799WZY00 . Abstract: RACF database build Welcome to zSeries Q A Technical Support - Electronic Q/A Service ~ This queue is for VM and related products: DFSMS/VM,DIRMAINT,GCS, ISPF/VM,PVM,RACF/VM,REXX/VM,RSCS,RTM/ESA etc. To help us accurately respond to your GENERAL-USAGE (How-To) QUESTION, please provide the Product Name, Version, Release and Maintenance Level of all software that may be related to this question. Include any other relevant info. that will help expedite a response, eg. hardware installed, error messages etc. Product Name Version/Release Maintenance Level * * You can add the text of your question after you press enter * * I am on z/VM V4R4 with RACF. I am attempting to build a racf database that will be shared with several (level 1) VM systems. The documentation in the RACF program directory (5739-A03) is a little confusing. It recommends using a full volume mini disk but then says do not place any mini disk on cylinder zero. Can you start at cylinder zero? Can you use another name in the racdsf command besides RACF and RACFBK if you start at cylinder zero? If I start at cylinder 1 will the z/VMs do the physical enqueuing to reserve the volume? If not how do I configure them to use that facility? =EVANS, PAUL G -5799WZY00 -L40D/QAVM -P3S -03/11/24-22:38 -CT =EVANS, PAUL G -568411202 -L40D/QAVM -P3S3-03/11/24-22:41 -CR S5 SERVICE GIVEN= 39 SG/39/ S7 SERVICE GIVEN= 39 SG/39/ Action taken: Hello Walter The Program directory is a bit misleading. I will check into this and have a further update for you in the morning. Many Thanks Paul Evans action plan; investigate sharing between VM systems. =EVANS, PAUL G -568411202 -L40D/QAVM -P3S3-03/11/25-16:23 -CR S7 SERVICE GIVEN= 39 SG/39/ Action taken: Hello Walter, That Program Directory is somewhat confusing so I will try to sort it out for you. When sharing a RACF database between VM systems, you have a bit more choice as to how to do it than you have if MVS is in the picture. If a MVS system will ever be sharing this database then that makes a big difference. MVS does not understand what a minidisk is and expects the real label in real cylinder zero to have a VTOC pointer and all the MVS stuff. Thus is MVS is going to share the RACF database, then you would want to use a Full Pack Minidisk for the database addresses. A Full Pack Mini actually starts at Cylinder Zero for the entire volume. The Minidisk statements in the directory would be something like: MDISK 200 3390 0 END RACF MWV MDISK 300 3390 0 END RACFBK MWV Please note that the MWV means Multi Write with Virtual Reserve/Release The volume also needs to have the SHARED option in the SYSTEM CONFIG to tell z/VM to use Real Reserve/Release. In the RACF p^rogram directory, it mentions that you can use different values than RACF and RACFBK by reassembling ICHRDSNT I believe. The RACF System Programmer's Guide has further information about that. If you are just sharing between VM systems and MVS will never be in the picture, then you can define the 200 and 300 as regular minidisks but the EXACT same definition must be made on ALL z/VM systems and again the MWV for the MDISK is needed and the SHARED option in the SYSTEM CONFIG is needed. Note that reserve/release affects the entire volume so it is not wise to place any other minidisks on that volume. Of course, the backup database should be on a different physical
VM UnZip question
System is running z/VM Version 4 Release 3.0, service level 0301 (32-bit) , one of the app programmers asked this question ( his email is below) , I have never used it so I do not know, any help with this is appreciated. Hi Augie; I figured out how to get the 1.9 million records loaded. Now I have another question, do we have an mainframe unzip module???The data they want me to load is zipped on the PC and I need to open it up to convert it from ASCII to EBCDIC. I know we have the zip module because we use it. Jack Jack M Schwier
Re: VM UnZip question
The PKZIP company might still offer a pkzip for CMS; they had a download and free trial period too. http://www.pkware.com/ -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of August Carideo Sent: Thursday, January 15, 2009 1:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM UnZip question System is running z/VM Version 4 Release 3.0, service level 0301 (32- bit) , one of the app programmers asked this question ( his email is below) , I have never used it so I do not know, any help with this is appreciated. Hi Augie; I figured out how to get the 1.9 million records loaded. Now I have another question, do we have an mainframe unzip module???The data they want me to load is zipped on the PC and I need to open it up to convert it from ASCII to EBCDIC. I know we have the zip module because we use it. Jack Jack M Schwier This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.
Re: VM UnZip question
http://www.xlsoft.compkzip for VM -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of August Carideo Sent: Thursday, January 15, 2009 1:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM UnZip question System is running z/VM Version 4 Release 3.0, service level 0301 (32- bit) , one of the app programmers asked this question ( his email is below) , I have never used it so I do not know, any help with this is appreciated. Hi Augie; I figured out how to get the 1.9 million records loaded. Now I have another question, do we have an mainframe unzip module???The data they want me to load is zipped on the PC and I need to open it up to convert it from ASCII to EBCDIC. I know we have the zip module because we use it. Jack Jack M Schwier This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.
Re: Sharing the RACF database in CSE
- the mode MWV triggers only *Virtual* Reserve/Release. Unless you run two copies of RACF on a single VM system, no Virtual R/R is required. MWV could protect RACFVM and RACMAINT stepping on eachother, but I don't know if CP allows both of them to become active concurrently. My understanding is that MWV on a fullpack or devno minidisk that starts on cyl0 will let VM push the Virtual R/R through the hardware to the real R/R bit on the device. Is this still correct? I specifically chose this approach so that I could start building my new VM systems 2nd level on my production VM systems, and share the production RACF database with the 2nd level VM test/maintenance systems. I was trying to get away from a dedicated maintenance/test LPAR - which is what is required with DEDICATEed shared RACF database volumes. -- Jay Brenneman
Re: VM UnZip question
I'm not certain, but I think PKWARE dropped VM/CMS support last fall, so you might not be able to get new copies or keys. DB -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Romanowski, John (OFT) Sent: Thursday, January 15, 2009 13:49 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM UnZip question http://www.xlsoft.compkzip for VM -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of August Carideo Sent: Thursday, January 15, 2009 1:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM UnZip question System is running z/VM Version 4 Release 3.0, service level 0301 (32- bit) , one of the app programmers asked this question ( his email is below) , I have never used it so I do not know, any help with this is appreciated. Hi Augie; I figured out how to get the 1.9 million records loaded. Now I have another question, do we have an mainframe unzip module???The data they want me to load is zipped on the PC and I need to open it up to convert it from ASCII to EBCDIC. I know we have the zip module because we use it. Jack Jack M Schwier This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.
Re: Sharing the RACF database in CSE
On Thursday, 01/15/2009 at 12:13 EST, Marcy Cortes marcy.d.cor...@wellsfargo.com wrote: Seems that with modern DASD, one never gets a volume failure anymore. You either lose nothing or you lose the whole darn subsystem or big chunk of it. Put it on a different box :) Or use PPRC to a different box if it really is that critical. If not, take regular, frequent backups to tape. Yes, by h/w failure I don't really mean a rotating spindle. RAID technologies pretty much guarantee protection from a a single- or double-drive/media failure. (You actually have to use it, though!) The more likely failures are in the infrastructure or the associated wetware. If you have GDPS available to you, it can transparently protect the RACF database volume, obviating the requirement for a backup database. That said, I don't know that the RACF database setup utilities handle placing both databases on the same volume. Alan Altmark z/VM Development IBM Endicott
Re: Sharing the RACF database in CSE
On Thursday, 01/15/2009 at 01:02 EST, Greg Dyrda gregory.l.dy...@us.hsbc.com wrote: I came across the following explanation from IBM when setting up out RACF. Looks like you could use mdisks if only VM shares the database, but you still have to waste the rest of the space on the volumes. You MUST use full-pack mdisks (preferred) or dedicated volumes whenever you share with another z/OS or z/VM system that is running in a separate LPAR. If all users are on the same VM system (e.g. first level RACF/VM sharing with second-level z/OS), then small minidisks can be used. We have solutions on the drawing board, with the premise that shared dasd is not a viable long-term strategy for database synchronization. Alan Altmark z/VM Development IBM Endicott
Re: Sharing the RACF database in CSE
On Thursday, 01/15/2009 at 02:02 EST, Robert J Brenneman bren...@gmail.com wrote: My understanding is that MWV on a fullpack or devno minidisk that starts on cyl0 will let VM push the Virtual R/R through the hardware to the real R/R bit on the device. Is this still correct? It doesn't matter about start vs. end, per se. The definition must cover the entire volume, whether it's 0 END or 0 3338 (or whatever), DEVNO or not. If it's got 10K cyls on it and you define it a 0 3338 then it isn't a full-pack mini and the R/R will not be propagated. Don't forget that the the V on MWV only enables the use of R/R on the minidisk. The volume must also be defined as SHARED in SYSTEM CONFIG. Alan Altmark z/VM Development IBM Endicott
Re: VM UnZip question
Unless you are doing something fancy (passwords?) on the PC side, the fre e ARCUTIL might still be useful in UNZIPing a file on VM. Here is a link to the packages available for download from the Slippery Rock University. http://zvm.sru.edu/~DOWNLOAD/ /Tom Kern On Thu, 15 Jan 2009 13:38:10 -0500, August Carideo august.cari...@avon.c om wrote: System is running z/VM Version 4 Release 3.0, service level 0301 (32-bit ) , one of the app programmers asked this question ( his email is below) , I have never used it so I do not know, any help with this is appreciated . Hi Augie; I figured out how to get the 1.9 million records loaded. Now I have another question, do we have an mainframe unzip module???The dat a they want me to load is zipped on the PC and I need to open it up to convert it from ASCII to EBCDIC. I know we have the zip module becau se we use it. Jack Jack M Schwier =
Re: VM UnZip question
Burch, Aubrey D Mr CIV US DISA CDB24 wrote: I'm not certain, but I think PKWARE dropped VM/CMS support last fall, so you might not be able to get new copies or keys. Your Linux images have a perfectly functional unzip ... -- Jack J. Woehr# I run for public office from time to time. It's like http://www.well.com/~jax # working out at the gym, you sweat a lot, don't get http://www.softwoehr.com # anywhere, and you fall asleep easily afterwards.
Re: Sharing the RACF database in CSE
If you have GDPS available to you, No real reserve/release allowed with GDPS/PPRC Hyperswaps :) Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
Re: VM:Schedule utility
Graeme, Have you called CA to best use the support money your company is paying? ;-) If they don't have any better ideas, this should do: There are both full-screen (panel) VMSCHED commands and linemode commands to rename scheduled requests. Moving requests is more complicated. Again, CA may have better ideas, but this is what I'd do. No guarantees, YMMV. The VM:Schedule database is a flat file on VMSCHED's 1B0 disk: Filename Filetype VMSCHED IRBDB The format is documented in a CA manual (used to be in the Generalized Report Writer Guide). You may want to try copying that database to a different CMS-formatted minidisk on the new system and on the copy, delete all but a couple requests that you want to try on the new system. Bring up VMSCHED on the new system and see what happens. If it doesn't work, call CA. I think it will work. If it does work, then provided you can tolerate a VMSCHED outage on the first system, shut down VMSCHED there, copy the VMSCHED IRBDB file to a backup name (e.g. VMSCHED -1IRBDB) with OLDDATE as a backup in case things go poorly, then copy VMSCHED IRBDB to another disk where you can work (leaving VMSCHED down). On that other disk, XEDIT the VMSCHED IRBDB, place an 'X' in the XEDIT prefix area of each line you want to stay in the current system to exclude that line. When you are done, the only lines showing should be the requests to be moved to the new system. Enter the commands: TOP, then PUTD * NEWSYS IRBDB A [that puts all the displayed lines into NEWSYS IRBDB, deleting them from this file] then: FFILE OLDSYS IRBDB A [that saves all the remaining lines for the old system into the OLDSYS IRBDB file.] COPYFILE the new OLDSYS IRBDB A to the old system's VMSCHED 1B0 disk (with REPLACE, after all you should still have the VMSCHED -1IRBDB file there, right?). Then bring up that VMSCHED on the old system. Then copy the NEWSYS IRBDB file to the hew systems' VMSCHED 1B0 disk as VMSCHED IRBDB and bring up that VMSCHED. Not too painful. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Graeme Moss ib...@mossaustralia.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 01/15/2009 03:12 PM Please respond to Graeme Moss ib...@listserv.uark.e DU To IBMVM@LISTSERV.UARK.EDU cc Subject VM:Schedule utility G'day, does any-one have utilities that can a a) rename VM:Sched requests b) extract VM:Sched requests from system a and add them into system b tia Graeme The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: Schedule utility
Graeme, You can move around VM:Schedule database records to another system if you want. Just locate the record in the VMSCHED IRBDB and copy it to the VMSCHED IRBDB on the system you want it. You'll have to make sure the request owner (and thus, where it runs) exists on the new system. You should bring down VMSCHED when appending new requests to its database, then reinitialize it so it will pick up the new, appended requests. The only problem I can think of is if the 2 systems have different 'local' time. VM:Schedule requests are kept in the database in local time. You can probably still do the append to get the requests over there, you'd just have to check the run date/time and change that as appropriate. A query on the request before you move it can give you the information you need to verify things once the request is moved. To rename a scheduled request: Go to '1 SCHEDULE' screen Put the request name in you want to rename Hit PF5 for COPY function. It will clear the name out and put your new name in. Hit PF12 for SUBMIT Please note that you have to type in a command in order for VM:Schedule to bring up the request to be copied. Once the new copy looks as you want it, you can just cancel the old request. Check 1st run dates and different criteria on the renamed request to be sure that everything was carried over/copied correctly. I hope this helps. Yvonne -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Graeme Moss Sent: Thursday, January 15, 2009 4:12 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VM:Schedule utility G'day, does any-one have utilities that can a a) rename VM:Sched requests b) extract VM:Sched requests from system a and add them into system b tia Graeme
Re: Sorting monitor data?
On Thu, Jan 15, 2009 at 7:01 PM, Schuh, Richard rsc...@visa.com wrote: IIRC, that is a configuration record that is written when the monitor is initialized. It was required by MICS. ESAWRITE has the ability to start each raw data file with one of these records. If you don't have ESAWRITE, you can find a configuration record in any file, retain a copy of it and include it in the files processed by the program. Constructing you own raw monitor data out of snippets that you have kept is probably not a good idea. The configuration data provides the context for the subsequent sample data. That's the reason programs that process monitor data need the configuration records. Though borrowed data from somewhere else may bypass the check that such a program does, it's likely to affect the quality of your numbers. And since you mention ESAWRITE: apart from raw monitor data, MXG also reads the history data format that ESAWRITE produces. This is much smaller and probably makes the entire problem go away. It also saves the staging disk space both on VM and MVS, and uses less resources on MVS to process it. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Re: Sorting monitor data?
That was from years ago, before ESAWRITE wrote the configuration records for every hourly file. Both the hourly file and the configuration record in every one of them were for problems that we had at USAir, and originated out of the process that I implemented and shared with Barton. Since our configuration rarely changed, only once every IOCP/POR, copying the one record did no harm. In those days, MICS only accepted raw data from VM, and it ignored the configuration record after verifying its existence. Even if it did warp the data, that was no problem because the capacity planners never did use it; they simply ignored VM. The only systems they cared about were MVS and TPF. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Rob van der Heij Sent: Thursday, January 15, 2009 1:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sorting monitor data? On Thu, Jan 15, 2009 at 7:01 PM, Schuh, Richard rsc...@visa.com wrote: IIRC, that is a configuration record that is written when the monitor is initialized. It was required by MICS. ESAWRITE has the ability to start each raw data file with one of these records. If you don't have ESAWRITE, you can find a configuration record in any file, retain a copy of it and include it in the files processed by the program. Constructing you own raw monitor data out of snippets that you have kept is probably not a good idea. The configuration data provides the context for the subsequent sample data. That's the reason programs that process monitor data need the configuration records. Though borrowed data from somewhere else may bypass the check that such a program does, it's likely to affect the quality of your numbers. And since you mention ESAWRITE: apart from raw monitor data, MXG also reads the history data format that ESAWRITE produces. This is much smaller and probably makes the entire problem go away. It also saves the staging disk space both on VM and MVS, and uses less resources on MVS to process it. Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Re: VM UnZip question
You can still get an old version of Info-zip for CMS. I found one here: ftp://tug.ctan.org/tex-archive/tools/zip/info-zip/VMCMS/I haven't used this in several years/VM releases, but it used to work well enough. On Thu, Jan 15, 2009 at 2:52 PM, Jack Woehr j...@well.com wrote: Burch, Aubrey D Mr CIV US DISA CDB24 wrote: I'm not certain, but I think PKWARE dropped VM/CMS support last fall, so you might not be able to get new copies or keys. Your Linux images have a perfectly functional unzip ... -- Jack J. Woehr# I run for public office from time to time. It's like http://www.well.com/~jax # working out at the gym, you sweat a lot, don't get http://www.softwoehr.com # anywhere, and you fall asleep easily afterwards. -- Jeff Henry
