SWAPGEN EXEC
Hi I am trying to download the SWAPGEN EXEC from the Sine Nomine website and cannot get it in a format we can use. I do not understand why it is in Mailable format. Can anyone please tell me how to do it or, if possible send me the code Tia Dave
Re: Second Physical Screen for Performance Monitor
Both the 'FC AUTOREFR ON' and the 'FCONAPPC' command can be either included in the FCONX $PROFILE, or you can append the commands to the PerfKit invocation as follows: 'perfkit fc autorefr on;fconappc;' . Eginhard - Original Message - From: Howard Rifkind To: IBMVM@LISTSERV.UARK.EDU Sent: Tuesday, June 17, 2008 9:39 PM Subject: Re: Second Physical Screen for Performance Monitor Eginhard, Thanks for the information below...works as advertised. One further questions, is there any way that the 'FC AUTOREFR ON' command and the 'FCONAPPC' can be automated? We would like to have this automatically done to avoid operator intervention. Thanks. Eginhard Jaeger [EMAIL PROTECTED] 6/17/2008 6:06 AM Sure, the Performance Toolkit uses local APPC/VM connections to allow performance data retrieval from any number of other virtual machines on the same system. I believe the original setup for PERFSVM will automatically activate the APPC/VM data retrieval interface, and it uses the APPC/VM resource ID 'FCXRES00' that the FCONAPPC command expects to connect to by default. If you already use the Web interface then APPC/VM connections are certainly activated, too. But before trying to use the interface you'll have to authorize any additional users for data retrieval by including them in the 'FCONRMT AUTHORIZ' file (see 'Performance Toolkit Guide' pages 12/13). You then just need an additional CMS machine to - log on to the second screen - start PerfKit there *without* performance data collection (give it a dummy FCONX $PROFILE, or make sure the 'FC MONCOLL ON' statement is commented out) - then start a performance data retrieval session with the command 'FCONAPPC' If the intention is to let a specific performance screen be permanently displayed and also automatically refreshed then enter also the command 'FC AUTOREFR ON' in the client machine *before* activating the data retrieval session with the 'FCONAPPC' command. Eginhard Jaeger - Original Message - From: Howard Rifkind To: IBMVM@LISTSERV.UARK.EDU Sent: Monday, June 16, 2008 9:39 PM Subject: Second Physical Screen for Performance Monitor Off the top of the lists hat would anyone know if you can connect a second physical monitor for z/VM. I would like to have one in the computer room and one in the Systems Programmers area. I know you can have a web interface to the monitor but that isn't way the manager wants. 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. _ 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: Bogus CPU utilization numbers from Linux Red Hat 4.6
Please. ESAMON has been correcting the Linux numbers since the problem was discovered in 2001. Thomas Kern wrote: I think that the discussion was that tools like PERFTK, ESAMON, CP IND USER show accurate numbers for what the whole virtual machine is using, and the the numbers from tools INSIDE a linux virtual machine such as TOP, SAR vary depending upon the level of the kernel, the distribution and the workload of the rest of the system. /Tom Kern Martin, Terry R. (CMS/CTR) (CTR) wrote: Hi I saw something in one of the postings that stated that the CPU utilization numbers that were reported in the z/VM Performance Toolkit on behalf of a Red Hat 4.6 z/Linux guest were not correct. Is it only the PTK that does not report the correct numbers or is it any monitor? Do we know if the numbers reported are bogus on the high side or low side? I am running z/VM 5.3 and the Linux Kernel is at 2.6.9-67. Thanks Terry
Re: SWAPGEN EXEC
It's in MAILABLE format because it's actually a package of several files. Download the MAILABLE file to your VM system. RENAME the file to SWPG0803 EXEC and run it to extract the 11 encoded files. Use and enjoy.
Re: Bogus CPU utilization numbers from Linux Red Hat 4.6
Sorry Barton. I wasn't sure of a good wording and figured you would step in to provide the correct state of affairs. /Tom Kern On Wed, 18 Jun 2008 07:19:39 -0800, Barton Robinson [EMAIL PROTECTED] wrote: Please. ESAMON has been correcting the Linux numbers since the problem was discovered in 2001. Thomas Kern wrote: I think that the discussion was that tools like PERFTK, ESAMON, CP IND USER show accurate numbers for what the whole virtual machine is using , and the the numbers from tools INSIDE a linux virtual machine such as TOP, SAR vary depending upon the level of the kernel, the distribution and the workload of the rest of the system. /Tom Kern Martin, Terry R. (CMS/CTR) (CTR) wrote: Hi I saw something in one of the postings that stated that the CPU utilization numbers that were reported in the z/VM Performance Toolki t on behalf of a Red Hat 4.6 z/Linux guest were not correct. Is it onl y the PTK that does not report the correct numbers or is it any monitor ? Do we know if the numbers reported are bogus on the high side or low side? I am running z/VM 5.3 and the Linux Kernel is at 2.6.9-67. Thanks Terry =
Re: DDR'ing 3390 DASD To Remote Location
3 months was chosen back in the early '80s. This is local government. Revenue in: Sales tax: Comes in automatically. Audits may be done at a later time. Federal distribution of income tax to local gov'ts: Comes in based on latest population figures. Earnings tax: Comes in automatically. May be audits at a later date. Real Estate taxes: We do have to bill. But can be same as last year. Revenue out: Payroll: Pay same as last time. Accounting: Pay the biggies manually. We have 3 months before most businesses will take action. Hence, 3 months. But we also produce election notices. Can't miss those on a Federal election. But I don't know what would happen in mist of a disaster. But I'm pretty sure I have it down to a month, assuming I survive. G Most plans are for the big earth quake. It would take out City Hall and the region. No problems with recovery then. There will be few left alive. Tom Duerbusch THD Consulting Michael Coffin [EMAIL PROTECTED] 6/18/2008 9:04 AM Hi Tom, Holy Cow! A 3 MONTH recovery window?!?!? I don't think I've ever come across such a generous recovery window, most companies would be out of business in 3 months without access to their mission-critical systems. :) On another note, has anyone ever come across an FTP stage for the CMS PIPE command? Someone on the LINUX-390 listserv suggested there might have been one once upon a time.. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch Sent: Tuesday, June 17, 2008 3:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location It depends on your recovery window. In the shop where we don't have disaster recovery tests, the window is officially 3 months, but I have it down to 1 month. In the shop where we do disaster recovery tests, the window is 3 days. IMHO, the closer you get to a hot site (already spinning a copy of your files), the more you need the monkey boy. In the days recovery window, good instructions are needed. In the month recovery window, we can get a system programmer consultant (to replace me, a consultant), that can get the system up. But all that depends on your recovery time frame, what you have in place (contacts, contracts, locations, etc), and what the shop is willing to pay for. We are pretty much in sync in the other aspects. I'm planning on a VM recovery system, on a single 3590 tape, with the script to restore the system, on floppy. That includes a small VSE system (no VM tape management, but VSE does have Dynam, and all the rest of the 390 backups are done within VSE), to restore each of the other VSE systems from tape (currently 3590, soon to be TS1120). Then, we (may) need to do application level restores from the most current backup available. But that can be done via the scheduling software. Yep, DDR is nice in that it restores the cylinders that are on that tape without caring if the cylinders before or after are done. Just mount the tapes, have rexx scan the TLBL, attach the disk drive and restore that set of cylinders. Eventually, all cylinders that got backed up, will be restored. I had a similar concept back in the late 80's/early '90s. Thanks for the info Tom Duerbusch THD Consulting Law of Cat Acceleration A cat will accelerate at a constant rate, until he gets good and ready to stop. Michael Coffin [EMAIL PROTECTED] 6/17/2008 12:28 PM Hi Tom, You really should plan towards monkey boy as being the only resource capable of performing the recovery. I classify disasters in three classes: 1. Minor: This would be like a prolonged regional power failure, but all facilities, systems and equipment are still present. 2. Major: This would be something involving the total loss of the computer facility and perhaps even some staff, but at least some people with expertise and knowledge of the business and systems are available to participate in the recovery. For example, a fire at the computer facility. 3. Total: All facilities and staff are impacted and unavailable, nobody has expertise and knowledge of the business and systems - this is the monkey boy scenario. An example might be a natural disaster (hurricane, tornado, earthquake, etc.) or act of terrorism. The recovery system is prestaged on tape, it's a small footprint z/VM system with EVERYTHING needed to perform the recovery (it senses available ARM libraries, networks, DASD, etc. etc.). Restoring the recovery system to disk and IPL'ing is the one part of the process that is not menu driven, but it's well documented and really only involves a few steps: 1. Mount recovery tape. 2. IPL DDR on the head of the recovery tape. 3. Restore the recovery system to disk. 4. IPL the recovery system from disk and startup the menu-based recovery system. The 4 steps above are the most technical part of the process, the monkey boy simply needs to execute commands and provide responses
Re: DDR'ing 3390 DASD To Remote Location
We could BEG IBM to add native VTAPE to z/VM .. even 'lowly VSE' supports VTAPEs. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Michael Coffin Sent: Tuesday, June 17, 2008 1:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi Aria, It's weird, sometimes it takes as little as 15 minutes to DDR2CMS a 3390-3 spindle, but most times it takes 45-50 minutes. But all spindles are not created equal, so you might have one that has very little actual data on it (even if it is fully allocated for minidisks, those minidisks might be substantially empty), and one that is full to the gills. Likewise, some data compacts better than others (for example one spindle contains a bunch of 'zip' files sent to us by PC users, those files are already well compressed and further compaction isn't likely). Again, if I can't (quickly) find a means to read the disk and write to a TCPIP stream directly (with a collector on the remote end, of course), I'll probably replace DDR2CMS with PIPEDDR to create the intermediate files before transmitting them. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Aria Bamdad Sent: Tuesday, June 17, 2008 1:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Tue, 17 Jun 2008 13:00:37 -0400 Michael Coffin said: Hi Aria, We are on an IBM 2066-0B1 with ESCON channels to an IBM 9393, running with a full system load. It would probably only take about 10 minutes on a big z9 (or z10) box, lightly loaded with FICON channels. :) I wish!!! I am on a 2066-0B1 with ESCON channels also. The DASD is an EMC 8430 with lots of cache however. Aria.
SFS REVOKE AUTH question
I am trying to REVOKE AUTH for an SFS user. The directory, let's call it VMSYS:MAINT.PUBLIC has had a GRANT AUTH PUBLIC done to it earlier. I have a specific user I do not want to access this directory. When I issue the REVOKE AUTH, (specifically: revoke auth vmsys:maint.public from steveg) I get DMSJAU1138E File sharing conflict with a return code of 70. The user is not logged on when I issue the command. Is the PUBLIC authority causing this problem? Thanks, Steve
Re: RMSMASTR FSMKIN1100E Error from communication function 24, return
Les, I removed RMSMASTR from the ICHCONN facility in RACF, use the DFSMS authorization file and added IUCV ANY to the 2nd level profiles needing access to VTS tapes via RMSMASTR. 2nd level guests (authorized) connect to the VTS with no issues now. Thanks ! -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Les Geer (607-429-3580) Sent: Thursday, June 12, 2008 1:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: RMSMASTR FSMKIN1100E Error from communication function 24, return Has anyone run into the following running a DFSMSRM command from a second level z/vm? and what corrected it? FSMKIN1100E Error from communication function 24, return code = 15 Situation: First level z/VM 5.2.0 runs VM:Tape and RMSMASTR connected to a VTS. 2nd level z/VM 5.2.0 just RMSMASTR connected to same VTS. No problems with first level. 2nd level (VMTEST) in cms mode can run commands okay. RMSMASTR appears to initialize (attach then detach tape drive without errors) in 2nd level. Is there some sort of virtual ctc needed between the 1st and 2nd level? This is an IUCV error, the 15 indicates an authorization failure. Do you have IUCV ALLOW in the RMSMASTR directory on the second level system? RMSMASTR second level and first level are not aware of each other nor do they communicate with each other. In addition, the RMSMASTR directory should probably have: IUCV *IDENT RESANY BLOBAL REVOKE Best Regards, Les Geer IBM z/VM and Linux Development Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. ==
Re: SFS REVOKE AUTH question
Unfortunately for you, granting authority to PUBLIC grants it to everyone who has an id on the system. If the filepool is listed as a Global Resource, the authority carries over to other systems connected to your system via APPC. Yes, PUBLIC is the problem. Your ESM may provide an out. I do not know the abilities of VM:Secure and RACF in this area. SafeSFS may be another way to control access the way you are hoping for. Whenever I enroll a new user in our SFS, I tell them to not grant authority to PUBLIC for any files or subdirectories that they would not want posted on the web or printed in the Enquirer. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Gentry, Stephen Sent: Wednesday, June 18, 2008 8:23 AM To: IBMVM@LISTSERV.UARK.EDU Subject: SFS REVOKE AUTH question I am trying to REVOKE AUTH for an SFS user. The directory, let's call it VMSYS:MAINT.PUBLIC has had a GRANT AUTH PUBLIC done to it earlier. I have a specific user I do not want to access this directory. When I issue the REVOKE AUTH, (specifically: revoke auth vmsys:maint.public from steveg) I get DMSJAU1138E File sharing conflict with a return code of 70. The user is not logged on when I issue the command. Is the PUBLIC authority causing this problem? Thanks, Steve
Re: DDR'ing 3390 DASD To Remote Location
VTAPE is a Virtual Software Systems, Inc. (VSSI) commercial product and already runs on VM. It wouldn't help in this case, because all VTAPE does is redirect TAPE I/O to a local file, you'd still have to take that really big file and FTP it. Now if VTAPE could redirect TAPE I/O to a remote location somehow (i.e. open a TCPIP socket pointed to a Linux server running a little VTAPE client to accept the data and write it to a file) THAT would be sweet (and I'd bet you there is a market for such a product Hint hint). :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, June 18, 2008 11:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location We could BEG IBM to add native VTAPE to z/VM .. even 'lowly VSE' supports VTAPEs. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Michael Coffin Sent: Tuesday, June 17, 2008 1:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi Aria, It's weird, sometimes it takes as little as 15 minutes to DDR2CMS a 3390-3 spindle, but most times it takes 45-50 minutes. But all spindles are not created equal, so you might have one that has very little actual data on it (even if it is fully allocated for minidisks, those minidisks might be substantially empty), and one that is full to the gills. Likewise, some data compacts better than others (for example one spindle contains a bunch of 'zip' files sent to us by PC users, those files are already well compressed and further compaction isn't likely). Again, if I can't (quickly) find a means to read the disk and write to a TCPIP stream directly (with a collector on the remote end, of course), I'll probably replace DDR2CMS with PIPEDDR to create the intermediate files before transmitting them. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Aria Bamdad Sent: Tuesday, June 17, 2008 1:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Tue, 17 Jun 2008 13:00:37 -0400 Michael Coffin said: Hi Aria, We are on an IBM 2066-0B1 with ESCON channels to an IBM 9393, running with a full system load. It would probably only take about 10 minutes on a big z9 (or z10) box, lightly loaded with FICON channels. :) I wish!!! I am on a 2066-0B1 with ESCON channels also. The DASD is an EMC 8430 with lots of cache however. Aria.
Re: Second Physical Screen for Performance Monitor
Thanks Eginhard, that did the trick. Eginhard Jaeger [EMAIL PROTECTED] 6/18/2008 6:36 AM Both the 'FC AUTOREFR ON' and the 'FCONAPPC' command can be either included in the FCONX $PROFILE, or you can append the commands to the PerfKit invocation as follows: 'perfkit fc autorefr on;fconappc;' . Eginhard - Original Message - From: Howard Rifkind ( mailto:[EMAIL PROTECTED] ) To: IBMVM@LISTSERV.UARK.EDU Sent: Tuesday, June 17, 2008 9:39 PM Subject: Re: Second Physical Screen for Performance Monitor Eginhard, Thanks for the information below...works as advertised. One further questions, is there any way that the 'FC AUTOREFR ON' command and the 'FCONAPPC' can be automated? We would like to have this automatically done to avoid operator intervention. Thanks. Eginhard Jaeger [EMAIL PROTECTED] 6/17/2008 6:06 AM Sure, the Performance Toolkit uses local APPC/VM connections to allow performance data retrieval from any number of other virtual machines on the same system. I believe the original setup for PERFSVM will automatically activate the APPC/VM data retrieval interface, and it uses the APPC/VM resource ID 'FCXRES00' that the FCONAPPC command expects to connect to by default. If you already use the Web interface then APPC/VM connections are certainly activated, too. But before trying to use the interface you'll have to authorize any additional users for data retrieval by including them in the 'FCONRMT AUTHORIZ' file (see 'Performance Toolkit Guide' pages 12/13). You then just need an additional CMS machine to - log on to the second screen - start PerfKit there *without* performance data collection (give it a dummy FCONX $PROFILE, or make sure the 'FC MONCOLL ON' statement is commented out) - then start a performance data retrieval session with the command 'FCONAPPC' If the intention is to let a specific performance screen be permanently displayed and also automatically refreshed then enter also the command 'FC AUTOREFR ON' in the client machine *before* activating the data retrieval session with the 'FCONAPPC' command. Eginhard Jaeger - Original Message - From: Howard Rifkind ( mailto:[EMAIL PROTECTED] ) To: IBMVM@LISTSERV.UARK.EDU Sent: Monday, June 16, 2008 9:39 PM Subject: Second Physical Screen for Performance Monitor Off the top of the lists hat would anyone know if you can connect a second physical monitor for z/VM. I would like to have one in the computer room and one in the Systems Programmers area. I know you can have a web interface to the monitor but that isn't way the manager wants. 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. _ 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. _ 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: DDR'ing 3390 DASD To Remote Location
I think the reference was to a VTS unit. Is emulated tapes are called VTAPEs, I believe. Either Rick did not trademark VTAPE or he gave IBM permission to use it. (Or he is going to file suit as a result of this note :-) ). Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Michael Coffin Sent: Wednesday, June 18, 2008 8:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location VTAPE is a Virtual Software Systems, Inc. (VSSI) commercial product and already runs on VM. It wouldn't help in this case, because all VTAPE does is redirect TAPE I/O to a local file, you'd still have to take that really big file and FTP it. Now if VTAPE could redirect TAPE I/O to a remote location somehow (i.e. open a TCPIP socket pointed to a Linux server running a little VTAPE client to accept the data and write it to a file) THAT would be sweet (and I'd bet you there is a market for such a product Hint hint). :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, June 18, 2008 11:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location We could BEG IBM to add native VTAPE to z/VM .. even 'lowly VSE' supports VTAPEs. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Michael Coffin Sent: Tuesday, June 17, 2008 1:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi Aria, It's weird, sometimes it takes as little as 15 minutes to DDR2CMS a 3390-3 spindle, but most times it takes 45-50 minutes. But all spindles are not created equal, so you might have one that has very little actual data on it (even if it is fully allocated for minidisks, those minidisks might be substantially empty), and one that is full to the gills. Likewise, some data compacts better than others (for example one spindle contains a bunch of 'zip' files sent to us by PC users, those files are already well compressed and further compaction isn't likely). Again, if I can't (quickly) find a means to read the disk and write to a TCPIP stream directly (with a collector on the remote end, of course), I'll probably replace DDR2CMS with PIPEDDR to create the intermediate files before transmitting them. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Aria Bamdad Sent: Tuesday, June 17, 2008 1:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Tue, 17 Jun 2008 13:00:37 -0400 Michael Coffin said: Hi Aria, We are on an IBM 2066-0B1 with ESCON channels to an IBM 9393, running with a full system load. It would probably only take about 10 minutes on a big z9 (or z10) box, lightly loaded with FICON channels. :) I wish!!! I am on a 2066-0B1 with ESCON channels also. The DASD is an EMC 8430 with lots of cache however. Aria.
Re: DDR'ing 3390 DASD To Remote Location
On Jun 18, 2008, at 9:04 AM, Michael Coffin wrote: Hi Tom, Holy Cow! A 3 MONTH recovery window?!?!? I don't think I've ever come across such a generous recovery window, most companies would be out of business in 3 months without access to their mission-critical systems. :) On another note, has anyone ever come across an FTP stage for the CMS PIPE command? Someone on the LINUX-390 listserv suggested there might have been one once upon a time.. Well, in the z/VM installation from, uh, version 5.1 forwards, I think, there's the Install From DVD option, which uses an undocumented pipe stage to transfer track images and reassemble them. If you look at the INSTDVD exec you can see how it works. It's undocumented, but it's been stable for a while, so it probably isn't going anywhere, but at your own risk, etc. Adam
Re: DDR'ing 3390 DASD To Remote Location
VSE has VTAPE now. CA has CDTAPE that works with z/VM now. Copyright Computer Associates International, Inc. 2003 CDTAPE simulates the CMS TAPE and VMFPLC2 commands allowing you to run various software installation procedures like AIM or CIS using tape image files instead of real tape volumes. Tape image files can reside in CMS or on your TCP/IP connected workstation. You indicate which location CDTAPE is to use by means of the CDTAPE START command. I would think that IBM could to it right now too. Ed Martin 330-588-4723 ext 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Michael Coffin Sent: Wednesday, June 18, 2008 11:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location VTAPE is a Virtual Software Systems, Inc. (VSSI) commercial product and already runs on VM. It wouldn't help in this case, because all VTAPE does is redirect TAPE I/O to a local file, you'd still have to take that really big file and FTP it. Now if VTAPE could redirect TAPE I/O to a remote location somehow (i.e. open a TCPIP socket pointed to a Linux server running a little VTAPE client to accept the data and write it to a file) THAT would be sweet (and I'd bet you there is a market for such a product Hint hint). :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, June 18, 2008 11:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location We could BEG IBM to add native VTAPE to z/VM .. even 'lowly VSE' supports VTAPEs. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Michael Coffin Sent: Tuesday, June 17, 2008 1:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi Aria, It's weird, sometimes it takes as little as 15 minutes to DDR2CMS a 3390-3 spindle, but most times it takes 45-50 minutes. But all spindles are not created equal, so you might have one that has very little actual data on it (even if it is fully allocated for minidisks, those minidisks might be substantially empty), and one that is full to the gills. Likewise, some data compacts better than others (for example one spindle contains a bunch of 'zip' files sent to us by PC users, those files are already well compressed and further compaction isn't likely). Again, if I can't (quickly) find a means to read the disk and write to a TCPIP stream directly (with a collector on the remote end, of course), I'll probably replace DDR2CMS with PIPEDDR to create the intermediate files before transmitting them. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Aria Bamdad Sent: Tuesday, June 17, 2008 1:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Tue, 17 Jun 2008 13:00:37 -0400 Michael Coffin said: Hi Aria, We are on an IBM 2066-0B1 with ESCON channels to an IBM 9393, running with a full system load. It would probably only take about 10 minutes on a big z9 (or z10) box, lightly loaded with FICON channels. :) I wish!!! I am on a 2066-0B1 with ESCON channels also. The DASD is an EMC 8430 with lots of cache however. Aria.
Re: DDR'ing 3390 DASD To Remote Location
That is excatally what it can do in VSE.. Point the output to an IP address where the client is running (there is LINUX, WINDOZE, UNIX, etc. versions) and run your VSE job to either read or write the tape input/output to the remote VTAPE server.. So simple and I can't believe IBM developed it. But why not in z/VM? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Michael Coffin Sent: Wednesday, June 18, 2008 10:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location VTAPE is a Virtual Software Systems, Inc. (VSSI) commercial product and already runs on VM. It wouldn't help in this case, because all VTAPE does is redirect TAPE I/O to a local file, you'd still have to take that really big file and FTP it. Now if VTAPE could redirect TAPE I/O to a remote location somehow (i.e. open a TCPIP socket pointed to a Linux server running a little VTAPE client to accept the data and write it to a file) THAT would be sweet (and I'd bet you there is a market for such a product Hint hint). :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Wednesday, June 18, 2008 11:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location We could BEG IBM to add native VTAPE to z/VM .. even 'lowly VSE' supports VTAPEs. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Michael Coffin Sent: Tuesday, June 17, 2008 1:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Hi Aria, It's weird, sometimes it takes as little as 15 minutes to DDR2CMS a 3390-3 spindle, but most times it takes 45-50 minutes. But all spindles are not created equal, so you might have one that has very little actual data on it (even if it is fully allocated for minidisks, those minidisks might be substantially empty), and one that is full to the gills. Likewise, some data compacts better than others (for example one spindle contains a bunch of 'zip' files sent to us by PC users, those files are already well compressed and further compaction isn't likely). Again, if I can't (quickly) find a means to read the disk and write to a TCPIP stream directly (with a collector on the remote end, of course), I'll probably replace DDR2CMS with PIPEDDR to create the intermediate files before transmitting them. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Aria Bamdad Sent: Tuesday, June 17, 2008 1:44 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Tue, 17 Jun 2008 13:00:37 -0400 Michael Coffin said: Hi Aria, We are on an IBM 2066-0B1 with ESCON channels to an IBM 9393, running with a full system load. It would probably only take about 10 minutes on a big z9 (or z10) box, lightly loaded with FICON channels. :) I wish!!! I am on a 2066-0B1 with ESCON channels also. The DASD is an EMC 8430 with lots of cache however. Aria.
Dirmaint Start Up Problem.
When I log on to the Dirmaint user id and the system executes profiles and what not, I'm getting the following error. It seems that the 192 disk (with is a link to 5vmdir30's 492 disk) is being detached by something in the system. When I issue the 'DVHBEGIN' command the system is telling me that the DVHUPDIR module can't be found. That's because this module exists on the 192 disk which should be linked but is becoming detached. This is sort of a new installation. I'm doing my testing second level and I did DDR's on tape from the first level system then back to the second level system. I DDR'ed the following users minidisks: 5VMDIR30 DIRMAINT DATAMOVE DATASAT The DDR's didn't have any errors and I believe I did copy over all the minidisks involved. The DIRMAINT system came packaged on first level. The directory entries for these users are the same in both the first and second level system and contain all the same link statements. Any ideas how to resolve this issue 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: Bogus CPU utilization numbers from Linux Red Hat 4.6
Oh, and the fixed numbers from later releases are bogus as well... As it turns out, Linux folks from discrete world don't really care for CPU utilization, they only ask for that so they do their math to determine the amount of *unused* capacity (100-busy). Clearly in this world you cannot do this with just a single number, so the answer on their question does not help them. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: DDR'ing 3390 DASD To Remote Location
Ed, Something I have done in the past is to use DoctorD in VSE which has a feature to create standalone DDR'ish backups of VM volumes.. That way they are labeled and in the EPIC catalog too. It worked fine in DR tests, back when we used real tapes. Tom -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Ed Zell Sent: Wednesday, June 18, 2008 11:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location That is excatally what it can do in VSE.. Point the output to an IP address where the client is running (there is LINUX, WINDOZE, UNIX, etc. versions) and run your VSE job to either read or write the tape input/output to the remote VTAPE server.. So simple and I can't believe IBM developed it. But why not in z/VM? I have used the VSE VTAPE over TCPIP and with VSAM. In our case, VSAM performs MUCH better. It was explained to me that our FLEX box doesn't have the same throughput over the network that a shiny new Z box with OSA would have. It would be great to have VTAPE in VM natively. Of course, I am spoiled as we have had FAKETAPE with FLEX since 2001. We still do CMS backups to FAKETAPE using VMFPLC2. Then we run a VSE job to copy the non-labeled FAKETAPE to a cataloged tape that VSE DYNAM knows about. That way we can have our CMS backups in the same catalog as our VSE stuff. Ed Zell Illinois Mutual Life (309) 636-0107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: Dirmaint Start Up Problem.
Any ideas how to resolve this issue would be appreciated. Well, for starters: pasting the messages you see on DIRMAINT when you logon and the PROFILE EXEC runs would be a good place to start. As I tell some end users: No message, no problem. Be happy!. being detached by something in the system. Without the messages, it's hard to say what and why it might be detached. But the LINK not being authorized might be a good place to start looking. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Howard Rifkind [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 06/18/2008 11:10 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Dirmaint Start Up Problem. When I log on to the Dirmaint user id and the system executes profiles and what not, I'm getting the following error. It seems that the 192 disk (with is a link to 5vmdir30's 492 disk) is being detached by something in the system. When I issue the 'DVHBEGIN' command the system is telling me that the DVHUPDIR module can't be found. That's because this module exists on the 192 disk which should be linked but is becoming detached. This is sort of a new installation. I'm doing my testing second level and I did DDR's on tape from the first level system then back to the second level system. I DDR'ed the following users minidisks: 5VMDIR30 DIRMAINT DATAMOVE DATASAT The DDR's didn't have any errors and I believe I did copy over all the minidisks involved. The DIRMAINT system came packaged on first level. The directory entries for these users are the same in both the first and second level system and contain all the same link statements. Any ideas how to resolve this issue 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. 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: DDR'ing 3390 DASD To Remote Location
3 months was chosen back in the early '80s. This is local government. As Mel Brooks would say: It's good to be the king!
Re: DDR'ing 3390 DASD To Remote Location
Yes, Adam is quite correct, the new install procedures for z/VM (at least for the past couple of releases) does employ an undocumented FTP PIPE stage. I don't know if the put command is implemented, but the get command is there. Since the FTP stage is a bit of IBM programming, I can't send it out to external sites; you'll have to license z/vM to get a copy. I have requested, informally, the IBM Endicott document this stage, but so far, no luck. DJ Original Message: - From: Adam Thornton [EMAIL PROTECTED] Date: Wed, 18 Jun 2008 10:00:08 -0500 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Jun 18, 2008, at 9:04 AM, Michael Coffin wrote: Hi Tom, Holy Cow! A 3 MONTH recovery window?!?!? I don't think I've ever come across such a generous recovery window, most companies would be out of business in 3 months without access to their mission-critical systems. :) On another note, has anyone ever come across an FTP stage for the CMS PIPE command? Someone on the LINUX-390 listserv suggested there might have been one once upon a time.. Well, in the z/VM installation from, uh, version 5.1 forwards, I think, there's the Install From DVD option, which uses an undocumented pipe stage to transfer track images and reassemble them. If you look at the INSTDVD exec you can see how it works. It's undocumented, but it's been stable for a while, so it probably isn't going anywhere, but at your own risk, etc. Adam myhosting.com - Premium Microsoft® Windows® and Linux web and application hosting - http://link.myhosting.com/myhosting
FCXLON679E Unable to authenticate user uuuuu from 10.54.11.28:04192
Hi, Does anyone know if the requirement for the web login screen for the Performance Toolkit to improve handling of users with expired passwords has been raised? If you have a user who has been defined to RACF but the password has expired they cannot login through the web interface to Performance Toolkit. They get FCXLON679E Unable to authenticate user u from 10.54.11.28:04192 This does not tell you your password is expired or give the opportunity to enter a new password. I was able to have them login through VM/CMS and once they changed the password it worked fine. It would have been nice to at least get a better message. Ideally they could have changed the expired password through the web interface. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message.
Re: DDR'ing 3390 DASD To Remote Location
Hi Michael, we use as DR a VTL from BusTech, the MAS. So, we have FICON attached a MAS, and we write our tapes in normal open systems disks. Then, the reseller here in Germany, mainstorconcept, installed also a replication module over IP and now we have all the virtual tapes in a second DR location. In relative short time we have all our DDR's in the another location. And also encrypted. For us is also interesting, that the tapes are stored in linux in AWSTAPE format. We replace our old DR solution from CMSDDR FTP with this hardware. best regards, N. _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066
Re: SFS REVOKE AUTH question
Thanks for the reply. VM:Secure has a revoke command. If I understand the doc correctly, it takes the command and issues it to VM, almost verbatim. I do get the same error message when I issue the vmsecure revoke. Looks like it's time for Plan B (whatever that is). Steve -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, June 18, 2008 11:53 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS REVOKE AUTH question Unfortunately for you, granting authority to PUBLIC grants it to everyone who has an id on the system. If the filepool is listed as a Global Resource, the authority carries over to other systems connected to your system via APPC. Yes, PUBLIC is the problem. Your ESM may provide an out. I do not know the abilities of VM:Secure and RACF in this area. SafeSFS may be another way to control access the way you are hoping for. Whenever I enroll a new user in our SFS, I tell them to not grant authority to PUBLIC for any files or subdirectories that they would not want posted on the web or printed in the Enquirer. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Gentry, Stephen Sent: Wednesday, June 18, 2008 8:23 AM To: IBMVM@LISTSERV.UARK.EDU Subject: SFS REVOKE AUTH question I am trying to REVOKE AUTH for an SFS user. The directory, let's call it VMSYS:MAINT.PUBLIC has had a GRANT AUTH PUBLIC done to it earlier. I have a specific user I do not want to access this directory. When I issue the REVOKE AUTH, (specifically: revoke auth vmsys:maint.public from steveg) I get DMSJAU1138E File sharing conflict with a return code of 70. The user is not logged on when I issue the command. Is the PUBLIC authority causing this problem? Thanks, Steve
Re: DDR'ing 3390 DASD To Remote Location
Well ain't this a kick in the pants! Yes indeed, BOTH the FTPPUT and FTPGET stages are defined (on z/VM 5.3). ::START_CUSTOMER_GRIPE:: It's so hard to get IBM to enhance ANYTHING in CMS these days, here they've gone and invested precious development dollars in a PIPE stage that would be a HUGE help to existing VM/CMS customers, and they don't bother to document it and, when asked to, they STILL don't?!?!? I've been spending countless hours trying to reinvent a wheel which IBM has already invented, and which we are already licensed to use - EXTREMELY ANNOYING! Come on IBM, can you please document this lovely PIPE stage THAT YOU'VE ALREADY DEVELOPED so that we can exploit it?!?! It's not like we're asking you to develop something from scratch, just spend an hour documenting WHAT YOU'VE ALREADY DEVELOPED!!! ::END_CUSTOMER_GRIPE:: So, if I can decipher the parms for the FTP stages all I really need to do now is: PIPE TRACKREAD | TRACKSQUISH | FTPPUT (FTP_parms to be deciphered) There may be some other intermediate stages (BLOCK 1024, etc.) that need to go in as well, I'll take a look at how Bruce Hayden already addressed this in PIPEDDR and just change the output stage to FTPPUT (assuming I can either decipher the correct parms, or if some kind soul from IBM could forward a tiny little README on this officially or otherwise I'd be in your debt!). The nice thing is I can also integrate FTPGET into the recovery process which will speed things up nicely as well. Thanks Adam and David for steering me in the right direction. FWIW, there is an example of PIPE FTPGET in INSTLBMD EXEC - so that might provide a clue as to what parms are required and/or supported. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, June 18, 2008 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Yes, Adam is quite correct, the new install procedures for z/VM (at least for the past couple of releases) does employ an undocumented FTP PIPE stage. I don't know if the put command is implemented, but the get command is there. Since the FTP stage is a bit of IBM programming, I can't send it out to external sites; you'll have to license z/vM to get a copy. I have requested, informally, the IBM Endicott document this stage, but so far, no luck. DJ Original Message: - From: Adam Thornton [EMAIL PROTECTED] Date: Wed, 18 Jun 2008 10:00:08 -0500 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location On Jun 18, 2008, at 9:04 AM, Michael Coffin wrote: Hi Tom, Holy Cow! A 3 MONTH recovery window?!?!? I don't think I've ever come across such a generous recovery window, most companies would be out of business in 3 months without access to their mission-critical systems. :) On another note, has anyone ever come across an FTP stage for the CMS PIPE command? Someone on the LINUX-390 listserv suggested there might have been one once upon a time.. Well, in the z/VM installation from, uh, version 5.1 forwards, I think, there's the Install From DVD option, which uses an undocumented pipe stage to transfer track images and reassemble them. If you look at the INSTDVD exec you can see how it works. It's undocumented, but it's been stable for a while, so it probably isn't going anywhere, but at your own risk, etc. Adam myhosting.com - Premium MicrosoftR WindowsR and Linux web and application hosting - http://link.myhosting.com/myhosting
Re: DDR'ing 3390 DASD To Remote Location
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Michael Coffin Sent: Wednesday, June 18, 2008 11:49 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Well ain't this a kick in the pants! Yes indeed, BOTH the FTPPUT and FTPGET stages are defined (on z/VM 5.3). ::START_CUSTOMER_GRIPE:: It's so hard to get IBM to enhance ANYTHING in CMS these days, here they've gone and invested precious development dollars in a PIPE stage that would be a HUGE help to existing VM/CMS customers, and they don't bother to document it and, when asked to, they STILL don't?!?!? I've been spending countless hours trying to reinvent a wheel which IBM has already invented, and which we are already licensed to use - EXTREMELY ANNOYING! Come on IBM, can you please document this lovely PIPE stage THAT YOU'VE ALREADY DEVELOPED so that we can exploit it?!?! It's not like we're asking you to develop something from scratch, just spend an hour documenting WHAT YOU'VE ALREADY DEVELOPED!!! ::END_CUSTOMER_GRIPE:: If this is like some things in z/OS, the response from IBM development will be along the lines of: It is not documented because we don't want anyone else to use it. We don't want others to use it because if they do, then we must support it. And if we support it, then we cannot make arbitrary changes to it to implement what we want, should __our__ needs change. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: DDR'ing 3390 DASD To Remote Location
Do I smell a WAVV requirement? There may also be a formalized request/requirement mechanism on the z/VM web site (there is on the z/VSE web site). Michael Coffin wrote: Well ain't this a kick in the pants! Yes indeed, BOTH the FTPPUT and FTPGET stages are defined (on z/VM 5.3). ::START_CUSTOMER_GRIPE:: It's so hard to get IBM to enhance ANYTHING in CMS these days, here they've gone and invested precious development dollars in a PIPE stage that would be a HUGE help to existing VM/CMS customers, and they don't bother to document it and, when asked to, they STILL don't?!?!? I've been spending countless hours trying to reinvent a wheel which IBM has already invented, and which we are already licensed to use - EXTREMELY ANNOYING! Come on IBM, can you please document this lovely PIPE stage THAT YOU'VE ALREADY DEVELOPED so that we can exploit it?!?! It's not like we're asking you to develop something from scratch, just spend an hour documenting WHAT YOU'VE ALREADY DEVELOPED!!! ::END_CUSTOMER_GRIPE:: So, if I can decipher the parms for the FTP stages all I really need to do now is: PIPE TRACKREAD | TRACKSQUISH | FTPPUT (FTP_parms to be deciphered) There may be some other intermediate stages (BLOCK 1024, etc.) that need to go in as well, I'll take a look at how Bruce Hayden already addressed this in PIPEDDR and just change the output stage to FTPPUT (assuming I can either decipher the correct parms, or if some kind soul from IBM could forward a tiny little README on this officially or otherwise I'd be in your debt!). The nice thing is I can also integrate FTPGET into the recovery process which will speed things up nicely as well. Thanks Adam and David for steering me in the right direction. FWIW, there is an example of PIPE FTPGET in INSTLBMD EXEC - so that might provide a clue as to what parms are required and/or supported. -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, June 18, 2008 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Yes, Adam is quite correct, the new install procedures for z/VM (at least for the past couple of releases) does employ an undocumented FTP PIPE stage. I don't know if the put command is implemented, but the get command is there. Since the FTP stage is a bit of IBM programming, I can't send it out to external sites; you'll have to license z/vM to get a copy. I have requested, informally, the IBM Endicott document this stage, but so far, no luck. DJ -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: Beginning programing question: scripting actions with dirmaint
Dirmaint has a programming interface for synchronous communication. See Appendix D of the Directory Maintenance Facility Commands Reference manual for more information on it. It uses WAKEUP under the covers to wait for the response from the DIRMAINT service machine. On Tue, Jun 17, 2008 at 4:16 PM, Patrick Spinler [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi: Although I've done a bit of maintenance on our company's VM systems, I'm a raw, brand spanking new VM script writer, so forgive me if I'm missing the obvious. I'm sure I'll have many d'oh! moments. I'd like to write some code to fetch dirmaint's disk allocation maps (dirmaint dirmap and possibly dirmaint send extent control) and perform some analysis on it. Specifically asking questions like how much free dasd we have in various volume groups, how fragmented our dasd allocation is, and the like. My question is how may I, in a rexx exec, know when the results of a dirmaint command like dirmap are complete, if it failed, when any result is available in my reader, and what reader file# to receive? Thanks, and apologies for the beginner question. - -- Pat -- Bruce Hayden Linux on System z Advanced Technical Support IBM, Endicott, NY
Re: DDR'ing 3390 DASD To Remote Location
Something I have done in the past is to use DoctorD in VSE which has a feature to create standalone DDR'ish backups of VM volumes.. That way they are labeled and in the EPIC catalog too. It worked fine in DR tests, back when we used real tapes. Tom, We also have Doctor D on VSE, and I vaguely recall reading about that feature. Sounds like a good project for a rainy day! Thanks for pointing that out. Ed Zell Illinois Mutual Life (309) 636-0107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: Beginning programing question: scripting actions with dirmaint
Pat--You should also look at the CMS DIRMAP program. I usually use it with the USER BACKUP file that DIRMAINT puts on it's 1DB disk so it's what the system looked last night or whenever you have it generated. If I want an up-to-the-minute file, I do a DIRM USER BACKUP and then run DIRMAP. I think it will provide you with the information you want without having to figure out how to cope with the asynchronous output from the DIRMAINT DIRMAP command. Jim Bruce Hayden wrote: Dirmaint has a programming interface for synchronous communication. See Appendix D of the Directory Maintenance Facility Commands Reference manual for more information on it. It uses WAKEUP under the covers to wait for the response from the DIRMAINT service machine. On Tue, Jun 17, 2008 at 4:16 PM, Patrick Spinler [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi: Although I've done a bit of maintenance on our company's VM systems, I'm a raw, brand spanking new VM script writer, so forgive me if I'm missing the obvious. I'm sure I'll have many d'oh! moments. I'd like to write some code to fetch dirmaint's disk allocation maps (dirmaint dirmap and possibly dirmaint send extent control) and perform some analysis on it. Specifically asking questions like how much free dasd we have in various volume groups, how fragmented our dasd allocation is, and the like. My question is how may I, in a rexx exec, know when the results of a dirmaint command like dirmap are complete, if it failed, when any result is available in my reader, and what reader file# to receive? Thanks, and apologies for the beginner question. - -- Pat -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: SFS REVOKE AUTH question
From what I have heard, I have no direct experience with it, all VM:Secure does is act as a file pool administrator using the built-in SFS commands; it does not add any functionality. Your experience tends to support that. There may be other commands, but if there are, I am not familiar with them. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Gentry, Stephen Sent: Wednesday, June 18, 2008 9:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS REVOKE AUTH question Thanks for the reply. VM:Secure has a revoke command. If I understand the doc correctly, it takes the command and issues it to VM, almost verbatim. I do get the same error message when I issue the vmsecure revoke. Looks like it's time for Plan B (whatever that is). Steve -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, June 18, 2008 11:53 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS REVOKE AUTH question Unfortunately for you, granting authority to PUBLIC grants it to everyone who has an id on the system. If the filepool is listed as a Global Resource, the authority carries over to other systems connected to your system via APPC. Yes, PUBLIC is the problem. Your ESM may provide an out. I do not know the abilities of VM:Secure and RACF in this area. SafeSFS may be another way to control access the way you are hoping for. Whenever I enroll a new user in our SFS, I tell them to not grant authority to PUBLIC for any files or subdirectories that they would not want posted on the web or printed in the Enquirer. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Gentry, Stephen Sent: Wednesday, June 18, 2008 8:23 AM To: IBMVM@LISTSERV.UARK.EDU Subject: SFS REVOKE AUTH question I am trying to REVOKE AUTH for an SFS user. The directory, let's call it VMSYS:MAINT.PUBLIC has had a GRANT AUTH PUBLIC done to it earlier. I have a specific user I do not want to access this directory. When I issue the REVOKE AUTH, (specifically: revoke auth vmsys:maint.public from steveg) I get DMSJAU1138E File sharing conflict with a return code of 70. The user is not logged on when I issue the command. Is the PUBLIC authority causing this problem? Thanks, Steve
Re: Beginning programing question: scripting actions with dirmaint
On: Wed, Jun 18, 2008 at 02:06:30PM -0400,Jim Bohnsack Wrote:
} Pat--You should also look at the CMS DIRMAP program. I usually use it
} with the USER BACKUP file that DIRMAINT puts on it's 1DB disk so it's
} what the system looked last night or whenever you have it generated. If
} I want an up-to-the-minute file, I do a DIRM USER BACKUP and then run
} DIRMAP. I think it will provide you with the information you want
} without having to figure out how to cope with the asynchronous output
} from the DIRMAINT DIRMAP command.
Good idea except that DIRMAP has one design flaw. It does not show gaps
if they are at the end of the volume, and that is oftem where the most
interesting gaps lie. My fix is to run the DIRMAP, and post process
it with an xedit macro called GAPMAP which follows. I also have an exec
DMAP and another macro which together with GAPMAP do the whole mapping job.
QUERY DASD DETAILS is used to find the actual number of cyls. I am reluctant
to post DMAP because its fairly large and contains some bits which are
specific to my last job. I will send it off list on request along with
FIXMAP (the other macro).
/*
GAPMAP
This macro will fix up the o/p of DISKMAP by:
1) Checking the end cyl of the last line for each volume
against the actual size of the volume and adding in a
GAP if needed.
2) Adding in the VOLSER on each GAP line.
*/
false = (1=0)
true = (1=1)
Trace O
/*
If MSGMODE is on, turn it off (and restore later) to
suppress the 'Target not found at the end.
*/
'EXTRACT /MSGMODE/LINE/'
start_line = line.1
'SET MSGMODE OFF'
'SET WRAP OFF'
'SET CASE MIXED RESPECT'
/*
Phase 1:
For each volume, add a gap at the end if needed.
*/
'TOP'
vsn = ''
do forever
'FIND VOLUME' /* Next volume. */
if rc ^= 0
then leave
'NFIND __' /* Get */
'EXTRACT /CURLINE/'/* the */
vsn = translate(left(curline.3,6)) /*volser.*/
parse value diagrc(8,'QUERY DASD' vsn, 80) with cp_rc . . cuu err '15'x
if cp_rc ^= 0 | err = 'was not found.' /* Error? */
then iterate/* Yes, ignore this vol. */
parse value diagrc(8,'QUERY DASD DETAILS' cuu) with cp_rc . ,
'CYLS =' ncyl '15'x
if cp_rc ^= 0 /* Error?*/
then iterate/* Yes, ignore this vol. */
ncyl = strip(ncyl, 'L')/* Drop leading blanks. */
'FIND ___'
/* Locate next blank.*/
if rc ^= 0 /* Error?*/
then iterate/* Yes, ignore this vol. */
'-1' /* Up one. */
'EXTRACT /CURLINE/'/* Get last non-blank line. */
ecyl = word(substr(curline.3,9),5) /* Ending cyl of last MDISK.*/
if ecyl = ncyl-1 /* Does it end on last cylinder? */
then iterate/* Its OK, try next volume. */
scyl = right(ecyl + 1,8)
ecyl = right(ncyl - 1,8)
qcyl = right(ncyl - scyl,8)
'INPUT' copies(' ',33) scyl ecyl qcyl ' GAP'
end
/*
Phase 2:
Scan the file, picking up each volser as I come to it,
and overlaying it (lower cased) on each GAP line.
*/
':1' /* Start 1 down to avoid the timestamp. */
vsn = ''
do forever
'+1'
if rc ^= 0
then leave
'EXTRACT /CURLINE/'
temp = left(curline.3,6)
select
when curline.3 = ''
then iterate
when temp = ''
then nop
when temp = '--'
then iterate
when temp = 'VOLUME'
then do
'EXTRACT /LINE/'
'NFIND __'
'EXTRACT /CURLINE/'
vsn = left(curline.3,6)
vsn = translate(vsn,'abcdefghijklmnopqrstuvwxyz', ,
'ABCDEFGHIJKLMNOPQRSTUVWXYZ')
':'line.1
iterate
end
otherwise
nop
end
if word(curline.3,words(curline.3)) = 'GAP'
then do
if vsn = old_vsn
then do
'EXTRACT /LINE/'
'FINDUP' vsn
'OVERLAY *'
':'line.1
'OVERLAY' vsn'*'
end
else do
'OVERLAY' vsn
old_vsn = vsn
end
end
end
/*
All done with GAPMAP processing.
If I have been called from an exec, push a FILE.
If I am interactive, just restore the MSGMODE, and exit.
Make a guess at this by checking if the TERMINAL is in
TYPEWRITER or DISPLAY mode.
This works because an exec would (normally) call XEDIT
with the NOSCREEN option.
*/
'EXTRACT
Who Has the Longest Running VM System?
We have a VM 2.3 system that was last IPL'ed on August 17, 2003. Anybody have one that was last IPL'ed before then? q cplevel VM/ESA Version 2 Release 3.0, service level 0101 Generated at 03/11/02 17:44:14 EDT IPL at 08/17/03 04:40:50 EDT Ready; T=0.01/0.01 14:59:18 Thank you, Scott R Wandschneider Senior Systems Programmer Infocrossing, a WIPRO Company 11707 Miracle Hills Dr. Omaha, NE 68154 Office 402.963.8905
Re: Beginning programing question: scripting actions with dirmaint
Good idea except that DIRMAP has one design flaw. It does not show gaps if they are at the end of the volume, and that is oftem where the most Or you could allocate a dummy at the end of each volume (one cylinder in user $THE$END or so). It also helps to make DISKMAP alert you when you miscounted the last disk and extended it onto the gravel. We only have DISKMAP available to us and that's what we do to. Just put a 1 cyl disk at the end and it makes it much easier to see all your gaps. Ed Zell Illinois Mutual Life (309) 636-0107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
Re: Who Has the Longest Running VM System?
We couldn't have survived on the largest system built in 2003. There have been just a couple of cpu upgrades since then, not to mention outages for other hardware upgrades or moves. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Wandschneider, Scott Sent: Wednesday, June 18, 2008 12:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Who Has the Longest Running VM System? We have a VM 2.3 system that was last IPL'ed on August 17, 2003. Anybody have one that was last IPL'ed before then? q cplevel VM/ESA Version 2 Release 3.0, service level 0101 Generated at 03/11/02 17:44:14 EDT IPL at 08/17/03 04:40:50 EDT Ready; T=0.01/0.01 14:59:18 Thank you, Scott R Wandschneider Senior Systems Programmer Infocrossing, a WIPRO Company 11707 Miracle Hills Dr. Omaha, NE 68154 Office 402.963.8905
Re: FCXLON679E Unable to authenticate user uuuuu from 10.54.11.28:04192
Yes I recently worked with a customer regarding this same issue. What it comes down to the Perfkit WEB Interface is not designed for this and we are a basic user interface. My response in the PMR was: -We do not provide the support for applications to change user passwords and there ar eno plans to add this support. -To change a password that does not have an associated z/VM user ID you must get a SYSADMIN to change it for you (or the shop must have set up some self-help automation to handle it). -However, it looks like in R530 you can do what you are after!!!..check this out: Starting in z/VM 530 we have abillity to set a NOEXPIRED password: RAC ALTUSER PERF2 PASSWORD(xx) NOEXPIRED thus when you initially set your password it will not be expired. and then he can also set RAC password user( PERF2 ) nointerval so the password will not expire in the future. We are however looking into the Perfkit and return code handling from our calls to DMSPASS...so we could possibly change some messages and such in the future, but I do not see us handling password changes/etc for th e aformentioned reasons. I hope this helps clarify the concern. Best Regards, Roger Lunsford Perfkit/CP Level2
Re: Beginning programing question: scripting actions with dirmaint
That's what I do to make DISKMAP work properly. Rob van der Heij wrote: On Wed, Jun 18, 2008 at 8:36 PM, Rich Greenberg [EMAIL PROTECTED] wrote: Good idea except that DIRMAP has one design flaw. It does not show gaps if they are at the end of the volume, and that is oftem where the most Or you could allocate a dummy at the end of each volume (one cylinder in user $THE$END or so). It also helps to make DISKMAP alert you when you miscounted the last disk and extended it onto the gravel. Rob -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: Beginning programing question: scripting actions with dirmaint
Actually, if you create a minidisk that overlays the whole pack, DIRMAP will ignore it for overlays but show any gap at the end. Something like this: USER $DASD$ NOLOG MDISK 1C3A 3390 3339 LABEL1 On Wed, Jun 18, 2008 at 2:36 PM, Rich Greenberg [EMAIL PROTECTED] wrote: On: Wed, Jun 18, 2008 at 02:06:30PM -0400,Jim Bohnsack Wrote: Good idea except that DIRMAP has one design flaw. It does not show gaps if they are at the end of the volume, and that is oftem where the most interesting gaps lie. snip -- Bruce Hayden Linux on System z Advanced Technical Support IBM, Endicott, NY
Re: FCXLON679E Unable to authenticate user uuuuu from 10.54.11.28:04192
I would not expect the Perfkit WEB interface to provide for changing passwords, but it must provide sufficient information for failures so tha t the user knows who to turn to for assistance. Please provide as much erro r description as possible. /Tom Kern On Wed, 18 Jun 2008 14:15:52 -0500, Roger Lunsford [EMAIL PROTECTED] wrote: Yes I recently worked with a customer regarding this same issue. What i t comes down to the Perfkit WEB Interface is not designed for this and we are a basic user interface. My response in the PMR was: -We do not provide the support for applications to change user passwords and there ar eno plans to add this support. -To change a password that does not have an associated z/VM user ID you must get a SYSADMIN to change it for you (or the shop must have set up some self-help automation to handle it). -However, it looks like in R530 you can do what you are after!!!..check this out: Starting in z/VM 530 we have abillity to set a NOEXPIRED password: RAC ALTUSER PERF2 PASSWORD(xx) NOEXPIRED thus when you initially set your password it will not be expired. and then he can also set RAC password user( PERF2 ) nointerval so the password will not expire in the future. We are however looking into the Perfkit and return code handling from our calls to DMSPASS...so we could possibly change some messages and suc h in the future, but I do not see us handling password changes/etc for t he aformentioned reasons. I hope this helps clarify the concern. Best Regards, Roger Lunsford Perfkit/CP Level2 = ===
Re: FCXLON679E Unable to authenticate user uuuuu from 10.54.11.28:04192
Thank you Tom (and Sam) for the correspondance. This is appreciated and I will ensure your concerns are noted in our internal work stage for this issue. And we are in complete agreement, which is the reason we opened u p the internal work stage for this.we can do a better job in this area! We all want things to work smoothly and as detailed as possible...keep up the good work/input/etc! Best Regards, Roger Lunsford Perfkit CP Level2 support
Re: Dirmaint Start Up Problem.
Howard, Again, I preface this reply by reminding you that we don't run DIRMAINT here. But I do run SERVICE and PUT2PROD for it. I'm wondering if the DASD 0192 DETACHED, and DASD 021F DETACHED might be red herrings. I don't know why they are detached (the rexx code has been compiled, making that more difficult to examine), but checking the DIRMAINT 191 disk here, it contains about 258 files, including the DVHUPDIR MODULE reported below as missing (rc=28). Could you check the DIRMAINT 191 disk to see if it has more than just a PROFILE EXEC? What about the source disk from which you DDRed the DIRMAINT 191 disk, what does it have (we don't need a complete list). Something looks out of whack. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Howard Rifkind [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 06/18/2008 01:39 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Dirmaint Start Up Problem. Mike Directory entries and list below... Thanks. Directory Entries: 01264 USER 5VMDIR30 16M 64M EG 01265 ACCOUNT 1 SYSPROG 01266 IPL CMS 01267 MACHINE ESA 01268 CONSOLE 009 3215 T 01269 SPOOL 00C 2540 READER * 01270 SPOOL 00D 2540 PUNCH A 01271 SPOOL 00E 1403 A 01272 LINK MAINT 190 190 RR * CMS system disk 01273 LINK MAINT 19D 19D RR * help disk 01274 LINK MAINT 19E 19E RR * Product code disk 01275 LINK MAINT 51D 51D MR * VMSES/E software inventory disk 01276 LINK MAINT 5E5 5E5 RR * VMSES/E code 01277 LINK DIRMAINT 1DF 1DF MR * DIRMAINT server disk 01278 MDISK 2C4 3390 3337 001 530W01 MR 01279 MDISK 191 3390 0229 009 530W02 MR 01280 MDISK 2A2 3390 0238 004 530W02 MR 01281 MDISK 2A6 3390 0242 004 530W02 MR 01282 MDISK 2B2 3390 0246 013 530W02 MR 01283 MDISK 2C2 3390 0259 002 530W02 MR 01284 MDISK 2D2 3390 0261 050 530W02 MR 01285 MDISK 29D 3390 0311 009 530W02 MR 01286 MDISK 29E 3390 1795 001 VPWK02 MR READ 01287 MDISK 2B1 3390 0321 010 530W02 MR 01288 MDISK 502 3390 0331 009 530W02 MR 01289 MDISK 491 3390 0340 015 530W02 MR 01290 MDISK 492 3390 0355 015 530W02 MR 01291 MDISK 41F 3390 0370 008 530W02 MR ALL 01292 MDISK 11F 3390 0378 008 530W02 MR ALL 01293 * 01294 USER DIRMAINT NOLOG 32M 64M BDG 01295 IPL CMS PARM AUTOCR 01296 MACHINE ESA 01297 ACCOUNT SYSTEM SYSPROG 01298 D8ONECMD FAIL LOCK 01299 OPTION CONCEAL DIAG88 D84NOPAS IGNMAXU 01300 IUCV ANY PRIORITY MSGLIMIT 100 01301 CONSOLE 009 3215 T 01302 SPOOL 00C 2540 READER A 01303 SPOOL 00D 2540 PUNCH A 01304 SPOOL 00E 1403 A 01305 LINK 5VMDIR30 491 191 MR 01306 LINK 5VMDIR30 492 192 MR 01307 LINK 5VMDIR30 11F 11F MR 01308 LINK 5VMDIR30 41F 21F MR 01309 LINK MAINT 190 190 RR * CMS system disk 01310 LINK MAINT 19D 19D RR * help disk 01311 LINK MAINT 19E 19E RR * Product code disk 01312 LINK MAINT 123 123 MW 01313 MDISK 1AA 3390 0458 009 530W02 MR 01314 MDISK 1FA 3390 0467 009 530W02 MR 01315 MDISK 1DE 3390 0476 020 530W02 MR 01316 MDISK 2AA 3390 0496 009 530W02 MR 01317 MDISK 155 3390 0505 009 530W02 MR 01318 MDISK 1DF 3390 0514 009 530W02 MR 01319 MDISK 1DB 3390 0523 009 530W02 MR 01320 MDISK 2DF 3390 0532 009 530W02 MR 01321 MDISK 2DB 3390 0541 009 530W02 MR Screen Print of startup: LOGON DIRMAINT HCPLNM107E MAINT 019D not linked; not in CP directory z/VM Version 5 Release 3.0, Service Level 0703 (64-bit), built on IBM Virtualization Technology There is no logmsg data FILES: 0014 RDR, 0016 PRT, NO PUN LOGON AT 14:32:26 EDT WEDNESDAY 06/18/08 DMSACC724I 19E replaces Y (19E) DMSACP723I Y (19E) R/O z/VM V5.3.02008-01-10 14:57 DMSWSP100W Shared Y-STAT not available PRODUCT: IBM Directory Maintenance Facility for z/VM (DirMaint) 5741-A05 (C) Copyright IBM Corporation 1979, 2007. Function Level 530 Service Level . DMSACC724I 155 replaces A (191) DMSACC723I X (01DE) R/W - OS DVHPRO2008I ROLE = DIRMAINT DVHPRO2010I TESTING USE OF MSGNOH ... DASD 0192 DETACHED DASD 021F DETACHED DVHPRO2002A Manual start is required for DIRMAINT. Enter DVHBEGIN DVHPRO2002A when ready to start. DIRMAINT VMTESTEB - 2008/06/18; T=0.03/0.04 14:32:44 dvhbegin DVHRLC2102E File not found: DVHUPDIR MODULE; RC= DVHRLC2102E 28. File not found: DVHUPDIR MODULE; DVHRLC2102E RC= 28. DVHBEG2119T Error in CMS command; RC= 2102 DVHBEG2119T from: EXEC DVHRLDC DVHBEG2119T at line 37. DIRMAINT VMTESTEB - 2008/06/18(02119); T=0.08/0.10 14:32:48 *** Query Time TIME IS 14:32:48 EDT WEDNESDAY 06/18/08 CONNECT= 00:00:22 VIRTCPU= 000:00.11 TOTCPU= 000:00.14 *** Identify DIRMAINT AT VMTESTEB VIA *06/18/08 14:32:48 EDT
Re: Dirmaint Start Up Problem.
Howard, I little more on your 2nd level DIRMAINT test... I found the uncompiled rexx source for the DVFPROF EXEC in the 5VMDIR30 disk 02B1. At line 626, it contains comments, followed by code to do it: /*!* /*! Release and detach non-required disks. * /*! (A disk is not required if it is linked R/O* /*! and has not been accessed yet.)* /*!* It appears that something is preventing DIRMAINT from getting its R/W link to the 192 and 21F disks, and then DVHPROF detaches them. That's an area of interests, but does not explain why DIRMAINT does not find the DVHUPDIR MODULE on its 191 disk. Answering that should get you closer. Are you sure that the source system from which you are DDRing these disks had a successful PUT2PROD DIRM? 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-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: Dirmaint Start Up Problem.
Thanks Mike. I'll check into all that you mention here. Mike Walter [EMAIL PROTECTED] 6/18/2008 5:20 PM Howard, I little more on your 2nd level DIRMAINT test... I found the uncompiled rexx source for the DVFPROF EXEC in the 5VMDIR30 disk 02B1. At line 626, it contains comments, followed by code to do it: /*!* /*! Release and detach non-required disks. * /*! (A disk is not required if it is linked R/O* /*! and has not been accessed yet.)* /*!* It appears that something is preventing DIRMAINT from getting its R/W link to the 192 and 21F disks, and then DVHPROF detaches them. That's an area of interests, but does not explain why DIRMAINT does not find the DVHUPDIR MODULE on its 191 disk. Answering that should get you closer. Are you sure that the source system from which you are DDRing these disks had a successful PUT2PROD DIRM? 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-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. _ 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: DDR'ing 3390 DASD To Remote Location
At my last client we did all the VM backups using FCOPY in VSE since we did not have a tape management system in VM but we did in VSE. Very easy technically to do but hard for a VM bigot like me to do. You use what you have where you have it. The DR procedures would IPL VSE standalone programs and then use FCOPY to restore the VM system. No DDR just standalone FCOPY. Hans -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ed Zell Sent: June 18, 2008 1:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DDR'ing 3390 DASD To Remote Location Something I have done in the past is to use DoctorD in VSE which has a feature to create standalone DDR'ish backups of VM volumes.. That way they are labeled and in the EPIC catalog too. It worked fine in DR tests, back when we used real tapes. Tom, We also have Doctor D on VSE, and I vaguely recall reading about that feature. Sounds like a good project for a rainy day! Thanks for pointing that out. Ed Zell Illinois Mutual Life (309) 636-0107 . CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, notify the sender and delete this e-mail from your system.
