Re: MAINTENANCE
Hi Anne, Unless you discover a bug in CP (HIGHLY unlikely) then nothing that you d o in a Class G virtual machine can impact the first-level system (other tha n maybe in terms of excessive resource consumption if your system is ahem, inappropriately tuned grin). Maybe it's the, do it all again on first level that's worrying you ... Well, I tend not to, do it all again because I only keep the maintenance materials on second-level - what I do for first-level is to identify the RESULTS of the maintenance and then copy just those parts that a running system requires, up to first level. I do this, by hand and set things up on first-level in a very manual and (relatively) labour-intensive way. If I don't use any automatic procedures then it's much harder to be, surprised because the quantum value of each step is sufficiently small for me to be usually be able to fully grasp its impact before I tak e it - if I manually enter ten commands rather than run an EXEC containing those ten commands then I have time to think between each micro-step and confirm to myself that I'm still comfortable with what I'm about to do. The downside is that you have to dig around a bit and discover what is truly, The tip of the iceberg that is actually NEEDED to run the system / subsystems and learn how to migrate those essentials to first- level. You have to develop skills with some of the elemental commands (such as, say, DEFNSS), but the payback is that you end up with a far greater awareness of the detail of what's going on in your system which then spins off into better problem diagnosis and analysis skills and better ways of ensuring that maintenance is non-disruptive. If that seems like, all too much and you DO want to simply, do it all again then I suggest investing effort in replicating as complete a model as you can of your first-level environment in your second-level system. Then, when you, do it second-level you can look for and learning how to deal with any unexpected side-effects that might arise (such as TCPIP suddenly going off the air). The other thing of course, which I'm SURE I don't really need to tell you , is to take copious notes - document exactly what you did and what happene d as a result - including all those things that you thought at first happened but then it turned out that they didn't, plus all those things that you didn't notice had happened and only discovered afterwards. Hmm - I'm preaching again - does any of that help or am I off-target? (If yes, please rephrase the question and I - plus many others, I'm sure g - will take another shot at it.) Regards Jeff Gribbin
Re: MAINTENANCE
We too placed SHUTDOWN in a class of its own: S, and only VMOPER has it. If I really want to do a shutdown, I can: SET PRIVCLASS * +S. We also have a SHUTDOWN EXEC that shows a selection panel, brings down DB2 servers gracefully, ... The code also includes SET PRIVCLASS * +S, so the class change is almost transparent. My second-level test system is active all the time, it is even the home of all sysprogs; home means that we code our execs etc there. All SW is installed and maintained there, promotion to production systems is by SENDFILE, remote SFS, or even DDR (after doing a DEFINE MDISK to get access to the minidisk of the test system). The advantage is that any installed maintenance is a bit tested by everyone. For automated operation backups, this test system is like any other VM we've got; we keep the backup even longer. We work like this since day 1 (VM/SP R6 days). Disadvantage: I have to ask the collegues if I can re-IPL it. 2007/8/23, Ivica Brodaric [EMAIL PROTECTED]: We have SHUTDOWN command in a privilege class of its own and only one ops userid has that class. That user has a SHUTDOWN EXEC on its A disk. Not to prevent the shutdown but to actually do it. It first checks that it's being run from that particular user and then asks a are-you-shure-type question. That pretty much eliminates the possibility of an accidental shutdown of the first level. I mean, you can still add that shutdown-only privilege class to your user and and then have an oops! moment, but then it's not an _accident_. It's not a death wish either. It's an intention to kill. -- Kris Buelens, IBM Belgium, VM customer support
Re: MAINTENANCE
Before I had the tools to fully automate SW installations on remote systems, I had a pseudo manual method: CMDSRUN. Basically I place the commands to run in a file, CMDSRUN (a 230 lines exec) reads that file and issues these commands one by one. By default, the exec pauses before and after each command, during the pause you can enter any other CP/CMS command, tell to skip the command, or exit. A log is maintained. Advantages: you don't forget required commands, you make less typing errors. I can send it to any requester. 2007/8/23, Jeff Gribbin, EDS [EMAIL PROTECTED]: Hi Anne, Unless you discover a bug in CP (HIGHLY unlikely) then nothing that you d o in a Class G virtual machine can impact the first-level system (other tha n maybe in terms of excessive resource consumption if your system is ahem, inappropriately tuned grin). Maybe it's the, do it all again on first level that's worrying you ... Well, I tend not to, do it all again because I only keep the maintenance materials on second-level - what I do for first-level is to identify the RESULTS of the maintenance and then copy just those parts that a running system requires, up to first level. I do this, by hand and set things up on first-level in a very manual and (relatively) labour-intensive way. If I don't use any automatic procedures then it's much harder to be, surprised because the quantum value of each step is sufficiently small for me to be usually be able to fully grasp its impact before I tak e it - if I manually enter ten commands rather than run an EXEC containing those ten commands then I have time to think between each micro-step and confirm to myself that I'm still comfortable with what I'm about to do. The downside is that you have to dig around a bit and discover what is truly, The tip of the iceberg that is actually NEEDED to run the system / subsystems and learn how to migrate those essentials to first- level. You have to develop skills with some of the elemental commands (such as, say, DEFNSS), but the payback is that you end up with a far greater awareness of the detail of what's going on in your system which then spins off into better problem diagnosis and analysis skills and better ways of ensuring that maintenance is non-disruptive. If that seems like, all too much and you DO want to simply, do it all again then I suggest investing effort in replicating as complete a model as you can of your first-level environment in your second-level system. Then, when you, do it second-level you can look for and learning how to deal with any unexpected side-effects that might arise (such as TCPIP suddenly going off the air). The other thing of course, which I'm SURE I don't really need to tell you , is to take copious notes - document exactly what you did and what happene d as a result - including all those things that you thought at first happened but then it turned out that they didn't, plus all those things that you didn't notice had happened and only discovered afterwards. Hmm - I'm preaching again - does any of that help or am I off-target? (If yes, please rephrase the question and I - plus many others, I'm sure g - will take another shot at it.) Regards Jeff Gribbin -- Kris Buelens, IBM Belgium, VM customer support
Ted Kotlowski is out of the office.
I will be out of the office starting 08/23/2007 and will not return until 08/27/2007. I will respond to your message when I return. If your request requires immediate attention, Please contact the MVS Technical Support Hotline at 1-866-866-4488 x12000 ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. **
Scott A Heiser is out of the office. Alternate contact info provided.
I will be out of the office starting 08/23/2007 and will not return until 09/03/2007. I am on vacation riding the hurricanes in Mexico from Thursday the 23rd returning on the September 2nd. I will respond to your message when I return. If you need immediate assistance please contact Jeff Beck ( [EMAIL PROTECTED] ) who will be more than happy to help out in my absence. Please invite Jeff to any meetings that you feel I should attend. Thank you and happy surfing. Scott
Re: REXXVSAM - Multiple Files
My fix for multiple file access in REXXVSAM broke single file access. I have fixed that problem and thoroughly tested both single and multiple file access. For those who do not know: REXXVSAM allows access of both CMS and VSE VSAM files from CMS REXX. The updated package is on my download site at: http://zvm.sru.edu/~download /Fran Hensler at Slippery Rock University of Pennsylvania USA for 44 years [EMAIL PROTECTED] +1.724.738.2153 Yes, Virginia, there is a Slippery Rock On Fri, 13 Jul 2007 07:34:58 EDT Fran Hensler said: I've found the problem in REXXVSAM.
Re: MAINTENANCE
ALL of our 2nd level systems a strictly class G. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Wednesday, August 22, 2007 4:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: MAINTENANCE USER VMTEST xx 64M 64MABG Eek! 1st level class A privs for a test id? That'll last as long as it takes for you to type CP SHUTDOWN to the wrong level of CP...8-) BG or BCEG should be more than sufficient, and there are very good arguments to make test ids like this class G only and do anything privileged (ATTACH, DETACH, etc) from another id or DEDICATEs in the CP directory entry. -- db This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: MAINTENANCE
On our test system, we move SHUTDOWN to class S (or whatever). Then SET PRIVCLAS * +S is required to kill the first-level system. I've thought, too, about giving ESMs control over SHUTDOWN. Sounds like a very good idea to implement generically for the next release of VM. Having SHUTDOWN bunched in with all the other class A commands has always been a loaded automatic without a safety. In fact, does OPERATOR really need anything but C and G for normal operations? B would be convenient, but thinking about this as a more general lockdown and cleanup, it might be worth tightening things up a bit now that we're not really doing apps on CMS any more.
Re: MAINTENANCE
On Thursday, 08/23/2007 at 09:28 EDT, David Boyes [EMAIL PROTECTED] wrote: In fact, does OPERATOR really need anything but C and G for normal operations? B would be convenient, but thinking about this as a more general lockdown and cleanup, it might be worth tightening things up a bit now that we're not really doing apps on CMS any more. I would say that human operators (not sysprogs) will tend to want - VARY / ATTACH / DETACH - FORCE / XAUTOLOG - SET / QUERY / INDICATE - START / DRAIN - WNG / MSG - HALT - ENABLE / DISABLE - SIGNAL - SNAPDUMP - SHUTDOWN The other class A commands are really for sysprogs. (Do you really want the operator to issue ASSOCIATE EXIT, CPXLOAD, or MODIFY COMMAND?) DEFINE MDISK is controversial. I'd place it under ESM control, but I still need a provision for in case of emergency break glass. I guess I'm paranoid that it will get into the wrong hands, but that it will be prevented from being placed in the *right* hands! YOU HAVE REQUESTED DEFINE MDISK ACCESS. CONFIRMATION BY ANOTHER ADMINISTRATOR IS [NOT] REQUIRED. PRESS F5 TO CONFIRM. BY DOING SO YOU SWEAR (OR AFFIRM) THAT A STATE OF EMERGENCY EXISTS AND THAT DEITY-LIKE POWER IS NECESSARY TO CORRECT THE SITUATION. ALL COMMANDS FROM THIS POINT ON SHALL BE RECORDED FOR SUBSEQUENT AUDITING BY DATA SECURITY DRAGONS. THIS WARNING WILL NOT APPEAR AGAIN DURING THIS SESSION. ... WELCOME AND THANK YOU FOR CHOOSING DEFINE MDISK TODAY. PLEASE DRIVE CAREFULLY. Alan Altmark z/VM Development IBM Endicott
How to insert zvse4 installation tapes without barcode label on 3953/3584 library
*** cross posted to VM and VSE list *** Hi listers, one of my customers has a 3584 library with 3592 drives. He has ordered the zVSE 4 on 3592 tapes and got cartridges without barcode label. Now he has a problem to insert the cartridges into the library because of the following fact which I have read in the TS3500 redbook. Unlabeled cartridges and cartridges with unreadable external VOLSER labels are not supported by the 3953 Tape System. Even though the TS3500 Tape Library supports unlabeled or unreadable external labels for Open Systems hosts, this does not apply to System z attachment. As he has no other tape system he asked me now how to get the cartridges into the library. Has anybody of you solved such a situation before? Is it perhaps possible to mount the tape manually on the drive? Any hints are welcome, thanks in advance. -- kind regards Franz Josef Pohlen
Re: MAINTENANCE
I update SYSTEM CONFIG to make SHUTDOWN a class S command, and add class S to OPERATOR's directory (as others do). As an additional safety measure, I also disable the command: MODIFY Cmd SHUTDOWN PRIVclass S DISABLE Cmd SHUTDOWN The operator's procedure for shutting down the system includes issuing ENABLE CMD SHUTDOWN prior to the SHUTDOWN command. Call me paranoid. Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com “The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt” - Bertrand Russell
Re: How to insert zvse4 installation tapes without barcode label on 3953/3584 library
I don't know about those 2 devices, but, the 3494 has 2 different methods for that. Your devices may have something similar. Insert unlabeled tape. Standalone drive mounting from the input station. -- Mark Pace Mainline Information Systems
Re: MAINTENANCE
Schuh, Richard [EMAIL PROTECTED] wrote: Add to that that we have some pretty heavy vendor modifications to the CP, we simply cannot use the SERVICE/PUT2PROD approach well - yes no. I assume that Richard is talking about the same vendor products that we use. Our procedure is to build the IBM system (2nd level - vanilla) using all the standard tools. We then do a vendor build, which involves an override disk and results in a modified CP module using the vendor procedures. This pulls in all the SES applied updates applied. If we have new IBM service we apply that using SERVICE PUT2PROD (without the override disk) and then do the vendor build again. Any other mods, (local or from any other source), are applied as SES mods on the localmod disk so they just get included automatically. Richard is right that we cannot use SERVICE PUT2PROD for the updates from this vendor (but they have a pretty slick process anyway) and the final build but that does not stop us using them for all other (particularly IBM) updates. Now Richard is going to tell me that he was thinking of something completely different and I am barking at the wrong tree! With best regards / mit den besten Grüßen, Colin G Allinson Technical Manager VM Amadeus Data Processing GmbH T +49 (0) 8122-43 49 75 F +49 (0) 8122-43 32 60 [EMAIL PROTECTED] http://www.amadeus.com IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees . It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws . If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system . Amadeus Data Processing GmbH Geschäftsführer: Eberhard Haag Sitz der Gesellschaft: Erding HR München 48 199 Berghamer Strasse 6 85435 Erding Germany
Re: How to insert zvse4 installation tapes without barcode label on 3953/3584 library
we knew this option on the 3494. Before we had also this library. You can insert an unlabeled cartridge into the 3584 library but the 9353 library manager will reject it. It has no longer the options you mentioned from the 3494. kind regards Franz Josef Pohlen Mark Pace schrieb: I don't know about those 2 devices, but, the 3494 has 2 different methods for that. Your devices may have something similar. Insert unlabeled tape. Standalone drive mounting from the input station. -- Mark Pace Mainline Information Systems
Re: How to insert zvse4 installation tapes without barcode label on 3953/3584 library
It may also be known as a foreign tape or alien tape mounting option. If not, that's a big oversight. Tapes come from (and go to) the outside all the time in some shops. [EMAIL PROTECTED] wrote: we knew this option on the 3494. Before we had also this library. You can insert an unlabeled cartridge into the 3584 library but the 9353 library manager will reject it. It has no longer the options you mentioned from the 3494. kind regards Franz Josef Pohlen Mark Pace schrieb: I don't know about those 2 devices, but, the 3494 has 2 different methods for that. Your devices may have something similar. Insert unlabeled tape. Standalone drive mounting from the input station. -- Mark Pace Mainline Information Systems -- 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 2008 - Chattanooga - April 18-22, 2008
Re: Spool file from DIRMAINT
Hello Kris, Sorry to bug you. For awhile I gave up on this problem but I think I woul d like to resume it again. I wanted to know if this is a known issue. I was reluctant to create the DIRMAINT NAMES file since we have several service machines that process their reader files and I thought maybe there was a global way of preventing this to happen instead of me having to add all t he machine names to the NAMES file. Since it seems that most people do not get this reader file there has to be some reason why we are getting it. Thanks, Mike Horlick [EMAIL PROTECTED] On Sat, 22 Jul 2006 23:25:34 +0200, Kris Buelens [EMAIL PROTECTED] wrote: Any easy bypass: make a DIRMAINT NAMES file in which you code :nick.VSExyz :userid.RUBBISH issue DIRM FILE DIRMAINT NAMES and DIRMAINT will send the file to user RUBBISH Kris, IBM Belgium, VM customer support Greetings, For the longest time we have been getting a spool file sent from DIRMAINT sent to a user who has its directory entry changed (DIRM FOR userid REPLACE). For example : q rdr XX all ORIGINID FILE CLASS RECORDS CPY HOLD DATE TIME NAME TYPE DIRMAINT 1813 A PUN 0006 001 NONE 2006-07-15 00:02:08 XXX DEVVM mike Ready; This file once read in by CMS looks like: 2006/07/14 14:51:35 DVHBIU3427I Changes made to directory entry xxx by DUMMY at DEVVM 2006/07/14 14:51:35 DVHBIU3427I have been placed online. This presents a problem for a VSE guest or any service machine that may process files from its reader. Is there any way to prevent this file from being sent? Thanks, Mike =
Ops privs (was Re: MAINTENANCE)
David Boyes wrote: On our test system, we move SHUTDOWN to class S (or whatever). Then Sounds like a very good idea to implement generically for the next release of VM. Having SHUTDOWN bunched in with all the other class A commands has always been a loaded automatic without a safety. In fact, does OPERATOR really need anything but C and G for normal operations? B would be convenient, but thinking about this as a more general lockdown and cleanup, it might be worth tightening things up a bit now that we're not really doing apps on CMS any more. Actually we never gave our ops class-C ... only sysprogs got that. AFAIK, we never ran into a situation where they needed it. We gave them class E, as we had some tools that might need to display real memory, but never C (look, but don't touch). They also got class-B, though, since they did some manual device management (usually tape drives -- occasionally DASD). And we also had a class override defined for Shutdown. Only ops got that, not sysprogs.
Re: How to insert zvse4 installation tapes without barcode label on 3953/3584 library
I am not familiar with this tape system. My first thought would be to put a barcode external label on the tape long enough to deal with the tape, then remove it. Just my .02 for whatever it's worth! Loren Charnley, Jr. IT Systems Engineer Family Dollar Stores, Inc. (704) 847-6961 Ext. 3327 (704) 814-3327 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, August 23, 2007 10:47 AM To: IBMVM@LISTSERV.UARK.EDU Subject: How to insert zvse4 installation tapes without barcode label on 3953/3584 library *** cross posted to VM and VSE list *** Hi listers, one of my customers has a 3584 library with 3592 drives. He has ordered the zVSE 4 on 3592 tapes and got cartridges without barcode label. Now he has a problem to insert the cartridges into the library because of the following fact which I have read in the TS3500 redbook. Unlabeled cartridges and cartridges with unreadable external VOLSER labels are not supported by the 3953 Tape System. Even though the TS3500 Tape Library supports unlabeled or unreadable external labels for Open Systems hosts, this does not apply to System z attachment. As he has no other tape system he asked me now how to get the cartridges into the library. Has anybody of you solved such a situation before? Is it perhaps possible to mount the tape manually on the drive? Any hints are welcome, thanks in advance. -- kind regards Franz Josef Pohlen - NOTE: This e-mail message contains PRIVILEGED and CONFIDENTIAL information and is intended only for the use of the specific individual or individuals to which it is addressed. If you are not an intended recipient of this e-mail, you are hereby notified that any unauthorized use, dissemination or copying of this e-mail or the information contained herein or attached hereto is strictly prohibited. If you receive this e-mail in error, notify the person named above by reply e-mail and please delete it. Thank you.
Re: Ops privs (was Re: MAINTENANCE)
Actually we never gave our ops class-C ... only sysprogs got that. The only reason for C would be to enable SET PRIV, which would let us take away all the other privs in the default setup.
Re: MAINTENANCE
It's really a bad, stomach-wrenching feeling when you hit ENTER on your second level system and realize you shut down the first level system instead :-( Been There, Done That.. I do all the attaches and everything else I need to do, then issue a PRIVCLASS command to remove all classes except G on the second level system's userid. Then... everything is (hopefully) safe. Jim Bohnsack [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 08/22/2007 09:55 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: MAINTENANCE Over the course of 30 years of VM systems programming, I and every VM sysprog with whom I have worked, have shut down a production system once. There is probably a SHUTDOWN EXEC on almost every VM system in the world. One thing that I don't understand is why in the world, the SHUTDOWN command is ever used in anything except CP. If I remember correctly it is also in RSCS and PVM and I suspect other IBM programs. It isn't all that difficult to shutdown a remote system with either of them. I've done it. Jim Adam Thornton wrote: On Aug 22, 2007, at 3:55 PM, Alan Altmark wrote: Eeek! x 2 A non-adminstrator virtual machine with anything other than class G (or less)?!? Someone PLEASE bring me my pills!! The installation guide recommends B actually And even on my class A administrator machine, I have the following SHUTDOWN EXEC on my A-Disk: /* */ say Bad idea, dude. Adam -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: Spool file from DIRMAINT
No, I don't know directly how to make they are not created. They no longer bother me as I tailored SFPURGER (running in VMUTIL) to purge them directly. But indeed, if you have servers -like VSE- that react to reader files, they will still see the Dirmaint file... Maybe a simple bypass: store a SENDFILE EXEC on DIRMAINT's A-disk. That SENDFILE EXEC could check the parameters to see if it is such an email-type thing, or if it is something like a DIRM SEND, DIRM REVV or DIRM GET. Your exec could EXECLOAD the SENDFILE EXEC S as e.g. SFILE EXEC, and your own little SENDFILE EXEC would issue 'EXEC SFILE' arg(1) if it want the file being sent. Maybe even better: don't store a SENDFILE EXEC on DIRMAINT's disk, but a MYSEND EXEC; the PROFILE EXEC of DIRMAINT should then EXECLOAD MYSEND EXEC as SENDFILE EXEC. This way only DIRMAINT will find your MYSEND as SENDFILE, and not someone linking to DIRMAINT's disks. 2007/8/23, Michael Horlick [EMAIL PROTECTED]: Hello Kris, Sorry to bug you. For awhile I gave up on this problem but I think I woul d like to resume it again. I wanted to know if this is a known issue. I was reluctant to create the DIRMAINT NAMES file since we have several service machines that process their reader files and I thought maybe there was a global way of preventing this to happen instead of me having to add all t he machine names to the NAMES file. Since it seems that most people do not get this reader file there has to be some reason why we are getting it. Thanks, Mike Horlick [EMAIL PROTECTED] On Sat, 22 Jul 2006 23:25:34 +0200, Kris Buelens [EMAIL PROTECTED] wrote: Any easy bypass: make a DIRMAINT NAMES file in which you code :nick.VSExyz :userid.RUBBISH issue DIRM FILE DIRMAINT NAMES and DIRMAINT will send the file to user RUBBISH Kris, IBM Belgium, VM customer support Greetings, For the longest time we have been getting a spool file sent from DIRMAINT sent to a user who has its directory entry changed (DIRM FOR userid REPLACE). For example : q rdr XX all ORIGINID FILE CLASS RECORDS CPY HOLD DATE TIME NAME TYPE DIRMAINT 1813 A PUN 0006 001 NONE 2006-07-15 00:02:08 XXX DEVVM mike Ready; This file once read in by CMS looks like: 2006/07/14 14:51:35 DVHBIU3427I Changes made to directory entry xxx by DUMMY at DEVVM 2006/07/14 14:51:35 DVHBIU3427I have been placed online. This presents a problem for a VSE guest or any service machine that may process files from its reader. Is there any way to prevent this file from being sent? Thanks, Mike = -- Kris Buelens, IBM Belgium, VM customer support
Re: MAINTENANCE
On Thursday, 08/23/2007 at 11:00 EDT, Colin Allinson [EMAIL PROTECTED] wrote: Our procedure is to build the IBM system (2nd level - vanilla) using all the standard tools. We then do a vendor build, which involves an override disk and results in a modified CP module using the vendor procedures. This pulls in all the SES applied updates applied. That's pretty cool since it requires an analysis of the PTF source update to see if it conflicts with the vendor mods. Physical conflicts (update overlap) are easy. Logical conflicts are harder, depending on the specific mod. If CP is *extended* with new functionality that get loaded dynamically via CPXLOAD and ASSOCIATE commands, then there may be just a recompile and rebuild. If we have new IBM service we apply that using SERVICE PUT2PROD (without the override disk) and then do the vendor build again. Any other mods, (local or from any other source), are applied as SES mods on the localmod disk so they just get included automatically. Richard is right that we cannot use SERVICE PUT2PROD for the updates from this vendor (but they have a pretty slick process anyway) and the final build but that does not stop us using them for all other (particularly IBM) updates. OK. I just don't want anyone to mistakenly equate local mods with can't use SERVICE or PUT2PROD. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs (was Re: MAINTENANCE)
On Thursday, 08/23/2007 at 12:31 EDT, David Boyes [EMAIL PROTECTED] wrote: Actually we never gave our ops class-C ... only sysprogs got that. The only reason for C would be to enable SET PRIV, which would let us take away all the other privs in the default setup. You don't need class C to manage your own privileges. Also, the new COMMAND statement in the directory makes it easy to do things that were previously a PITA. E.g. you no longer need to give a user class A just so they can SET SHARE when they logon. In the case of SET PRIV: USER ALAN BDEFG : COMMAND SET PRIVCLASS * =G IPL 123 Alan Altmark z/VM Development IBM Endicott
TRACK
OK, what am I doing wrong here: Went to : http://vm.marist.edu/track/code.html Click on trackv52.vmarc and downloaded to my pc Did ftp from pc to vm (maint) Issued vmarc command and I get this: vmarc unpk trackv52 vmarc a = = z AUTO HELPTRAC Z1. Bytes in=8192, bytes out=3807 (46%). Invalid header for compacted file. Ready(8); T=0.01/0.01 13:02:06 Possibly wrong vmarc module?
Re: TRACK
Did you run it through FBLOCK? -- R; Anne D. Crabtree [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 08/23/2007 01:04 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU From Anne D. Crabtree [EMAIL PROTECTED] To IBMVM@LISTSERV.UARK.EDU cc Subject TRACK OK, what am I doing wrong here: Went to : http://vm.marist.edu/track/code.html Click on trackv52.vmarc and downloaded to my pc Did ftp from pc to vm (maint) Issued vmarc command and I get this: vmarc unpk trackv52 vmarc a = = z AUTO HELPTRAC Z1. Bytes in=8192, bytes out=3807 (46%). Invalid header for compacted file. Ready(8); T=0.01/0.01 13:02:06 Possibly wrong vmarc module?
TRACK
NEVERMIND Forgot to do the pipe!!! doh
Re: Spool file from DIRMAINT
Hi Mike, I think the answer you are looking for is the DIRMAINT USEROPTN setting. If you turn off both RCVMSGS and LOGGING for a userid, then whenever you change his directory both the messages from DIRMAINT that you see when you are logged on go away (thats the RCMSGS option) and the log file containing the messages is not sent (the LOGGING option). The LOGGING option is automatically turned on if you turn off RCVMSGS, so that the user gets sent the messages he missed in his reader for later viewing. So you probably need to turn off RCVMSGS first then LOGGING. This a change in the default from DIRMAINT R1.5, one that bit us when we went to z/VM 4.4.0. (And found out about from IBM when we opened an ETR). Ron For the longest time we have been getting a spool file sent from DIRMAINT sent to a user who has its directory entry changed (DIRM FOR userid REPLACE). For example : q rdr XX all ORIGINID FILE CLASS RECORDS CPY HOLD DATE TIME NAME TYPE DIRMAINT 1813 A PUN 0006 001 NONE 2006-07-15 00:02:08 XXX DEVVM mike Ready; This file once read in by CMS looks like: 2006/07/14 14:51:35 DVHBIU3427I Changes made to directory entry xxx by DUMMY at DEVVM 2006/07/14 14:51:35 DVHBIU3427I have been placed online. This presents a problem for a VSE guest or any service machine that may process files from its reader. Is there any way to prevent this file from being sent?
Re: MAINTENANCE
Even HALT seems to be going the way of the Dodo bird. I can't remember the last time it was used effectively here. We tend to not have much tape and no printer (we let MVS do what it is good at :-}) activity. The only START/DRAIN activity our operators need is SMSG RSCS ... . There is something to be said for not having UR equipment on your system. I would not want to put the starting and draining of disks in the operator's hands, so I would separate the UR and DASD forms in a slightly different manner, I would put DASD in a sysprog class, other than B, that is separate from the operator commands. Unless things have changed, the MAINT machine is A-G out of the box. That and the default passwords are the first things I change on a system. That reminds me of a story. When I left Amdahl to go to work for Piedmont Airlines in 1984, I changed the password of the IBMCE userid to AMDAHL on our first VM system. There was one IBM SE assigned to the account who absolutely refused to log on because of the password. All of the other IBM folks thought it was funny, so they would not change it for him. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, August 23, 2007 7:14 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: MAINTENANCE On Thursday, 08/23/2007 at 09:28 EDT, David Boyes [EMAIL PROTECTED] wrote: In fact, does OPERATOR really need anything but C and G for normal operations? B would be convenient, but thinking about this as a more general lockdown and cleanup, it might be worth tightening things up a bit now that we're not really doing apps on CMS any more. I would say that human operators (not sysprogs) will tend to want - VARY / ATTACH / DETACH - FORCE / XAUTOLOG - SET / QUERY / INDICATE - START / DRAIN - WNG / MSG - HALT - ENABLE / DISABLE - SIGNAL - SNAPDUMP - SHUTDOWN The other class A commands are really for sysprogs. (Do you really want the operator to issue ASSOCIATE EXIT, CPXLOAD, or MODIFY COMMAND?) DEFINE MDISK is controversial. I'd place it under ESM control, but I still need a provision for in case of emergency break glass. I guess I'm paranoid that it will get into the wrong hands, but that it will be prevented from being placed in the *right* hands! YOU HAVE REQUESTED DEFINE MDISK ACCESS. CONFIRMATION BY ANOTHER ADMINISTRATOR IS [NOT] REQUIRED. PRESS F5 TO CONFIRM. BY DOING SO YOU SWEAR (OR AFFIRM) THAT A STATE OF EMERGENCY EXISTS AND THAT DEITY-LIKE POWER IS NECESSARY TO CORRECT THE SITUATION. ALL COMMANDS FROM THIS POINT ON SHALL BE RECORDED FOR SUBSEQUENT AUDITING BY DATA SECURITY DRAGONS. THIS WARNING WILL NOT APPEAR AGAIN DURING THIS SESSION. ... WELCOME AND THANK YOU FOR CHOOSING DEFINE MDISK TODAY. PLEASE DRIVE CAREFULLY. Alan Altmark z/VM Development IBM Endicott
Re: MAINTENANCE
Why would I lie about it? VSSI does have some slick installation and maintenance tools. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Colin Allinson Sent: Thursday, August 23, 2007 8:00 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: MAINTENANCE Schuh, Richard [EMAIL PROTECTED] wrote: Add to that that we have some pretty heavy vendor modifications to the CP, we simply cannot use the SERVICE/PUT2PROD approach well - yes no. I assume that Richard is talking about the same vendor products that we use. Our procedure is to build the IBM system (2nd level - vanilla) using all the standard tools. We then do a vendor build, which involves an override disk and results in a modified CP module using the vendor procedures. This pulls in all the SES applied updates applied. If we have new IBM service we apply that using SERVICE PUT2PROD (without the override disk) and then do the vendor build again. Any other mods, (local or from any other source), are applied as SES mods on the localmod disk so they just get included automatically. Richard is right that we cannot use SERVICE PUT2PROD for the updates from this vendor (but they have a pretty slick process anyway) and the final build but that does not stop us using them for all other (particularly IBM) updates. Now Richard is going to tell me that he was thinking of something completely different and I am barking at the wrong tree! With best regards / mit den besten Grüßen, Colin G Allinson Technical Manager VM Amadeus Data Processing GmbH T +49 (0) 8122-43 49 75 F +49 (0) 8122-43 32 60 [EMAIL PROTECTED] http://www.amadeus.com IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees . It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws . If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system . Amadeus Data Processing GmbH Geschäftsführer: Eberhard Haag Sitz der Gesellschaft: Erding HR München 48 199 Berghamer Strasse 6 85435 Erding Germany
Re: Spool file from DIRMAINT
Mike, If you want to know why some options have OFF signified with a 2 and for others with a 0, I can't help there. :-( Perhaps IBM could explain themselves. I was happy just to find out how to to turn it off and stop bugging my VSE guests with all those AUTONAME jobs whenever I changed their directories. Ron On 8/23/07, Horlick, Michael [EMAIL PROTECTED] wrote: Hi Ron, Thanks for the info. I have been playing around with the 'DIRM USEROPTN' command and it is a bit confusing. If I select both LOGGING OFF and RCVMSGS OFF I get : DVHMNU1404E The LOGGING_OFF, RCVMSGS_INFO_OFF fields are conflicting DVHMNU1404E parameters. DVHMNU1406E You selected or filled in too many items; specify 1 item(s). However, I can turn them off individually. But when I go a QUERY , I get : DVHUOP3293I Links:0 Logging:2 RcvMsgs:0 Smsg:0 NeedPass:1 Lang:AMENG Shouldn't that Logging:2 be Logging:0 ? I'll try some more combinations Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ron Schmiedge Sent: August 23, 2007 1:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Spool file from DIRMAINT Hi Mike, I think the answer you are looking for is the DIRMAINT USEROPTN setting. If you turn off both RCVMSGS and LOGGING for a userid, then whenever you change his directory both the messages from DIRMAINT that you see when you are logged on go away (thats the RCMSGS option) and the log file containing the messages is not sent (the LOGGING option). The LOGGING option is automatically turned on if you turn off RCVMSGS, so that the user gets sent the messages he missed in his reader for later viewing. So you probably need to turn off RCVMSGS first then LOGGING. This a change in the default from DIRMAINT R1.5, one that bit us when we went to z/VM 4.4.0. (And found out about from IBM when we opened an ETR). Ron For the longest time we have been getting a spool file sent from DIRMAINT sent to a user who has its directory entry changed (DIRM FOR userid REPLACE). For example : q rdr XX all ORIGINID FILE CLASS RECORDS CPY HOLD DATE TIME NAME TYPE DIRMAINT 1813 A PUN 0006 001 NONE 2006-07-15 00:02:08 XXX DEVVM mike Ready; This file once read in by CMS looks like: 2006/07/14 14:51:35 DVHBIU3427I Changes made to directory entry xxx by DUMMY at DEVVM 2006/07/14 14:51:35 DVHBIU3427I have been placed online. This presents a problem for a VSE guest or any service machine that may process files from its reader. Is there any way to prevent this file from being sent?
Re: Spool file from DIRMAINT
Hi Ron, Thanks for the info. I was curious what exactly changes when you change the user options. I realized that the user's directory entry changes when you issue the USEROPTN command. The last record changes to something like: *DVHOPT LNK0 LOG2 RCM0 SMS0 NPW1 LNGAMENG PWC20030317 CRC¤ I guess LOG2 RCM0 means logging and received messages are OFF. Is that what you have for all your VSE guests? Thanks again, Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ron Schmiedge Sent: August 23, 2007 2:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Spool file from DIRMAINT Mike, If you want to know why some options have OFF signified with a 2 and for others with a 0, I can't help there. :-( Perhaps IBM could explain themselves. I was happy just to find out how to to turn it off and stop bugging my VSE guests with all those AUTONAME jobs whenever I changed their directories. Ron On 8/23/07, Horlick, Michael [EMAIL PROTECTED] wrote: Hi Ron, Thanks for the info. I have been playing around with the 'DIRM USEROPTN' command and it is a bit confusing. If I select both LOGGING OFF and RCVMSGS OFF I get : DVHMNU1404E The LOGGING_OFF, RCVMSGS_INFO_OFF fields are conflicting DVHMNU1404E parameters. DVHMNU1406E You selected or filled in too many items; specify 1 item(s). However, I can turn them off individually. But when I go a QUERY , I get : DVHUOP3293I Links:0 Logging:2 RcvMsgs:0 Smsg:0 NeedPass:1 Lang:AMENG Shouldn't that Logging:2 be Logging:0 ? I'll try some more combinations Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ron Schmiedge Sent: August 23, 2007 1:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Spool file from DIRMAINT Hi Mike, I think the answer you are looking for is the DIRMAINT USEROPTN setting. If you turn off both RCVMSGS and LOGGING for a userid, then whenever you change his directory both the messages from DIRMAINT that you see when you are logged on go away (thats the RCMSGS option) and the log file containing the messages is not sent (the LOGGING option). The LOGGING option is automatically turned on if you turn off RCVMSGS, so that the user gets sent the messages he missed in his reader for later viewing. So you probably need to turn off RCVMSGS first then LOGGING. This a change in the default from DIRMAINT R1.5, one that bit us when we went to z/VM 4.4.0. (And found out about from IBM when we opened an ETR). Ron For the longest time we have been getting a spool file sent from DIRMAINT sent to a user who has its directory entry changed (DIRM FOR userid REPLACE). For example : q rdr XX all ORIGINID FILE CLASS RECORDS CPY HOLD DATE TIME NAME TYPE DIRMAINT 1813 A PUN 0006 001 NONE 2006-07-15 00:02:08 XXX DEVVM mike Ready; This file once read in by CMS looks like: 2006/07/14 14:51:35 DVHBIU3427I Changes made to directory entry xxx by DUMMY at DEVVM 2006/07/14 14:51:35 DVHBIU3427I have been placed online. This presents a problem for a VSE guest or any service machine that may process files from its reader. Is there any way to prevent this file from being sent?
Re: Spool file from DIRMAINT
I have set logging off for all my VSE guests, I would have to check the user backup to confirm that is what is on the *DVHOPT line. Never needed to know where it was stored as long as it worked. Ron On 8/23/07, Horlick, Michael [EMAIL PROTECTED] wrote: Hi Ron, Thanks for the info. I was curious what exactly changes when you change the user options. I realized that the user's directory entry changes when you issue the USEROPTN command. The last record changes to something like: *DVHOPT LNK0 LOG2 RCM0 SMS0 NPW1 LNGAMENG PWC20030317 CRC¤ I guess LOG2 RCM0 means logging and received messages are OFF. Is that what you have for all your VSE guests? Thanks again, Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ron Schmiedge Sent: August 23, 2007 2:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Spool file from DIRMAINT Mike, If you want to know why some options have OFF signified with a 2 and for others with a 0, I can't help there. :-( Perhaps IBM could explain themselves. I was happy just to find out how to to turn it off and stop bugging my VSE guests with all those AUTONAME jobs whenever I changed their directories. Ron On 8/23/07, Horlick, Michael [EMAIL PROTECTED] wrote: Hi Ron, Thanks for the info. I have been playing around with the 'DIRM USEROPTN' command and it is a bit confusing. If I select both LOGGING OFF and RCVMSGS OFF I get : DVHMNU1404E The LOGGING_OFF, RCVMSGS_INFO_OFF fields are conflicting DVHMNU1404E parameters. DVHMNU1406E You selected or filled in too many items; specify 1 item(s). However, I can turn them off individually. But when I go a QUERY , I get : DVHUOP3293I Links:0 Logging:2 RcvMsgs:0 Smsg:0 NeedPass:1 Lang:AMENG Shouldn't that Logging:2 be Logging:0 ? I'll try some more combinations Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ron Schmiedge Sent: August 23, 2007 1:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Spool file from DIRMAINT Hi Mike, I think the answer you are looking for is the DIRMAINT USEROPTN setting. If you turn off both RCVMSGS and LOGGING for a userid, then whenever you change his directory both the messages from DIRMAINT that you see when you are logged on go away (thats the RCMSGS option) and the log file containing the messages is not sent (the LOGGING option). The LOGGING option is automatically turned on if you turn off RCVMSGS, so that the user gets sent the messages he missed in his reader for later viewing. So you probably need to turn off RCVMSGS first then LOGGING. This a change in the default from DIRMAINT R1.5, one that bit us when we went to z/VM 4.4.0. (And found out about from IBM when we opened an ETR). Ron For the longest time we have been getting a spool file sent from DIRMAINT sent to a user who has its directory entry changed (DIRM FOR userid REPLACE). For example : q rdr XX all ORIGINID FILE CLASS RECORDS CPY HOLD DATE TIME NAME TYPE DIRMAINT 1813 A PUN 0006 001 NONE 2006-07-15 00:02:08 XXX DEVVM mike Ready; This file once read in by CMS looks like: 2006/07/14 14:51:35 DVHBIU3427I Changes made to directory entry xxx by DUMMY at DEVVM 2006/07/14 14:51:35 DVHBIU3427I have been placed online. This presents a problem for a VSE guest or any service machine that may process files from its reader. Is there any way to prevent this file from being sent?
Re: How to insert zvse4 installation tapes without barcode label on 3953/3584 library
If you know the format of the barcode, perhaps you can print an acceptable one on a gummed label and stick it on the cart. -- Rich Greenberg N Ft Myers, FL, USA richgr atsign panix.com + 1 239 543 1353 Eastern time. N6LRT I speak for myself my dogs only.VM'er since CP-67 Canines:Val, Red, Shasta Casey (RIP), Red Zero, Siberians Owner:Chinook-L Retired at the beach Asst Owner:Sibernet-L
Re: Spool file from DIRMAINT
Yep, LOG2 and RCM0 on them all. On 8/23/07, Ron Schmiedge [EMAIL PROTECTED] wrote: I have set logging off for all my VSE guests, I would have to check the user backup to confirm that is what is on the *DVHOPT line. Never needed to know where it was stored as long as it worked. Ron On 8/23/07, Horlick, Michael [EMAIL PROTECTED] wrote: Hi Ron, Thanks for the info. I was curious what exactly changes when you change the user options. I realized that the user's directory entry changes when you issue the USEROPTN command. The last record changes to something like: *DVHOPT LNK0 LOG2 RCM0 SMS0 NPW1 LNGAMENG PWC20030317 CRC¤ I guess LOG2 RCM0 means logging and received messages are OFF. Is that what you have for all your VSE guests? Thanks again, Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ron Schmiedge Sent: August 23, 2007 2:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Spool file from DIRMAINT Mike, If you want to know why some options have OFF signified with a 2 and for others with a 0, I can't help there. :-( Perhaps IBM could explain themselves. I was happy just to find out how to to turn it off and stop bugging my VSE guests with all those AUTONAME jobs whenever I changed their directories. Ron On 8/23/07, Horlick, Michael [EMAIL PROTECTED] wrote: Hi Ron, Thanks for the info. I have been playing around with the 'DIRM USEROPTN' command and it is a bit confusing. If I select both LOGGING OFF and RCVMSGS OFF I get : DVHMNU1404E The LOGGING_OFF, RCVMSGS_INFO_OFF fields are conflicting DVHMNU1404E parameters. DVHMNU1406E You selected or filled in too many items; specify 1 item(s). However, I can turn them off individually. But when I go a QUERY , I get : DVHUOP3293I Links:0 Logging:2 RcvMsgs:0 Smsg:0 NeedPass:1 Lang:AMENG Shouldn't that Logging:2 be Logging:0 ? I'll try some more combinations Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ron Schmiedge Sent: August 23, 2007 1:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Spool file from DIRMAINT Hi Mike, I think the answer you are looking for is the DIRMAINT USEROPTN setting. If you turn off both RCVMSGS and LOGGING for a userid, then whenever you change his directory both the messages from DIRMAINT that you see when you are logged on go away (thats the RCMSGS option) and the log file containing the messages is not sent (the LOGGING option). The LOGGING option is automatically turned on if you turn off RCVMSGS, so that the user gets sent the messages he missed in his reader for later viewing. So you probably need to turn off RCVMSGS first then LOGGING. This a change in the default from DIRMAINT R1.5, one that bit us when we went to z/VM 4.4.0. (And found out about from IBM when we opened an ETR). Ron For the longest time we have been getting a spool file sent from DIRMAINT sent to a user who has its directory entry changed (DIRM FOR userid REPLACE). For example : q rdr XX all ORIGINID FILE CLASS RECORDS CPY HOLD DATE TIME NAME TYPE DIRMAINT 1813 A PUN 0006 001 NONE 2006-07-15 00:02:08 XXX DEVVM mike Ready; This file once read in by CMS looks like: 2006/07/14 14:51:35 DVHBIU3427I Changes made to directory entry xxx by DUMMY at DEVVM 2006/07/14 14:51:35 DVHBIU3427I have been placed online. This presents a problem for a VSE guest or any service machine that may process files from its reader. Is there any way to prevent this file from being sent?
VMARC AND 64-EN/DE-CODE
Dear list: Newbie here with what seems to be a catch-22. I've downloaded the VMARCMOD.TXT file and the 64-ENCODE/DECODE.REXX files from the various download sites. In order to use 64DECODE I need to have VMARC available. In order to process the 64DECODE.REXX file, I need to have VMARC available. How do you break this chicken-and-the-egg problem? Is there some place else I can download these files ready for use? TIA HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978
Re: VMARC AND 64-EN/DE-CODE
You can get a working VMARC MODULE from www.vm.ibm.com/download/vmarc.module. You need to run it through the pipe shown on that page, and then you can unpack the real thing using it. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Raymond Noal Sent: Thursday, August 23, 2007 5:29 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VMARC AND 64-EN/DE-CODE Dear list: Newbie here with what seems to be a catch-22. I've downloaded the VMARCMOD.TXT file and the 64-ENCODE/DECODE.REXX files from the various download sites. In order to use 64DECODE I need to have VMARC available. In order to process the 64DECODE.REXX file, I need to have VMARC available. How do you break this chicken-and-the-egg problem? Is there some place else I can download these files ready for use? TIA HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978
Re: Ops privs (was Re: MAINTENANCE)
On Thursday, 08/23/2007 at 01:06 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: You do if you are adding a priv that is not in your directory entry. Most of us live in fear of the class A privileges, so we do not include it in our entries. Without either C or A, you cannot add A (or C, for that matter). If you have class C, then you have all classes at your disposal, regardless of what's in the directory. If, however, you define your userid with the maximum privs and then *take away* privs you do not normally require (see prior post), then you do not need class C. When you decide you need class A, just SET PRIV * +A. When done, SET PRIV * -A. The concept of least privilege should be applied. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs (was Re: MAINTENANCE)
True enough; however, I fear trusting anyone enough to include class A in their directory privileges. We have very few Class C users. While on the subject of privilege classes, why does TCPIP hqve class A? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, August 23, 2007 3:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs (was Re: MAINTENANCE) On Thursday, 08/23/2007 at 01:06 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: You do if you are adding a priv that is not in your directory entry. Most of us live in fear of the class A privileges, so we do not include it in our entries. Without either C or A, you cannot add A (or C, for that matter). If you have class C, then you have all classes at your disposal, regardless of what's in the directory. If, however, you define your userid with the maximum privs and then *take away* privs you do not normally require (see prior post), then you do not need class C. When you decide you need class A, just SET PRIV * +A. When done, SET PRIV * -A. The concept of least privilege should be applied. Alan Altmark z/VM Development IBM Endicott
Re: Article for z/Journal
In May, I said: I'm doing an article for Bob Thomas' z/Journal http://www.zjournal.com/ about next-generation mainframers, industry and educational outreach initiatives for students and young professionals, opportunities and obstacles for people exploring this career area, etc. www.ibm.com/university/systemz is interesting if you've not seen it. A long-time and common topic on these lists (and I've cross-posted this note to several) is the graying of mainframers and how there is or will be a shortage of people to use/support/enhance big iron. I'm interested in what you're seeing -- in industry, schools, user groups, etc. -- regarding new generations of mainframers. --- The article is the cover story in the August/September z/Journal issue -- cover shown on http://www.zjournal.com/ and PDF file http://www.zjournal.com/index.cfm?section=articleaid=823# linked from http://www.zjournal.com/index.cfm?section=articleaid=823. I appreciate the many people who responded with comments, observations, and personal stories. The article is much too short to include more than a small sampling of what I received. The synopsis given, This article describes how IBM, SHARE, and others are trying to overcome an aging mainframe workforce and introduce a new generation to the benefits of mainframe computing, is accurate. Note what the article is NOT about: outsourcing, offshoring, age discrimination, unemployment, etc. Those weren't what z/Journal wanted covered, though they're important topics and may be the subjects of future pieces. Again, thanks for the many responses received. -- Gabriel Goldberg, Computers and Publishing, Inc. (703) 204-0433 3401 Silver Maple Place, Falls Church, VA 22042[EMAIL PROTECTED]
OSA question
Can z/VM and a guest operating system (z/OS) share the same OSA addresses ? z/VM uses 100,101 and 102. Can z/OS use 100,101 and 103 ? Or does z/OS need to use 103, 104 and 105 ? ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **
Re: MAINTENANCE
Why give your second level system A, C, D, E, or F in the first place? Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, August 23, 2007 5:49 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: MAINTENANCE It's really a bad, stomach-wrenching feeling when you hit ENTER on your second level system and realize you shut down the first level system instead :-( Been There, Done That.. I do all the attaches and everything else I need to do, then issue a PRIVCLASS command to remove all classes except G on the second level system's userid. Then... everything is (hopefully) safe. Jim Bohnsack [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 08/22/2007 09:55 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: MAINTENANCE Over the course of 30 years of VM systems programming, I and every VM sysprog with whom I have worked, have shut down a production system once. There is probably a SHUTDOWN EXEC on almost every VM system in the world. One thing that I don't understand is why in the world, the SHUTDOWN command is ever used in anything except CP. If I remember correctly it is also in RSCS and PVM and I suspect other IBM programs. It isn't all that difficult to shutdown a remote system with either of them. I've done it. Jim Adam Thornton wrote: On Aug 22, 2007, at 3:55 PM, Alan Altmark wrote: Eeek! x 2 A non-adminstrator virtual machine with anything other than class G (or less)?!? Someone PLEASE bring me my pills!! The installation guide recommends B actually And even on my class A administrator machine, I have the following SHUTDOWN EXEC on my A-Disk: /* */ say Bad idea, dude. Adam -- Jim Bohnsack Cornell University (607) 255-1760 [EMAIL PROTECTED]
Re: Ops privs (was Re: MAINTENANCE)
I thought it was for Locking/Unlocking pages, but I'm not sure. Schuh, Richard wrote: True enough; however, I fear trusting anyone enough to include class A in their directory privileges. We have very few Class C users. While on the subject of privilege classes, why does TCPIP hqve class A? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, August 23, 2007 3:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs (was Re: MAINTENANCE) If you have class C, then you have all classes at your disposal, regardless of what's in the directory. If, however, you define your userid with the maximum privs and then *take away* privs you do not normally require (see prior post), then you do not need class C. When you decide you need class A, just SET PRIV * +A. When done, SET PRIV * -A. The concept of least privilege should be applied. Alan Altmark z/VM Development IBM Endicott
Re: OSA question
z/OS must use 103, 104, and 105. -- R; - Original Message - From: Daniel Allen [EMAIL PROTECTED] Sent: 08/23/2007 07:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: OSA question Can z/VM and a guest operating system (z/OS) share the same OSA addresses ? z/VM uses 100,101 and 102. Can z/OS use 100,101 and 103 ? Or does z/OS need to use 103, 104 and 105 ? ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **
Re: MAINTENANCE
Even HALT seems to be going the way of the Dodo bird. I can't remember the last time it was used effectively here. We tend to not have much tape and no printer (we let MVS do what it is good at :-}) activity. Ditto here (except for that nasty MVS thing). You guys have fixed all the cases where HALT used to work..8-) The only START/DRAIN activity our operators need is SMSG RSCS ... . There is something to be said for not having UR equipment on your system. I would not want to put the starting and draining of disks in the operator's hands, so I would separate the UR and DASD forms in a slightly different manner, I would put DASD in a sysprog class, other than B, that is separate from the operator commands. Then Alan said: I would say that human operators (not sysprogs) will tend to want - VARY / ATTACH / DETACH - FORCE / XAUTOLOG - SET / QUERY / INDICATE - START / DRAIN - WNG / MSG - HALT - ENABLE / DISABLE - SIGNAL - SNAPDUMP - SHUTDOWN So, if we go with O is for Operator, we can probably come up with something, although the systems without ESMs are going to be problematical. YOU HAVE REQUESTED DEFINE MDISK ACCESS. CONFIRMATION BY ANOTHER ADMINISTRATOR IS [NOT] REQUIRED. PRESS F5 TO CONFIRM. BY DOING SO YOU SWEAR (OR AFFIRM) THAT A STATE OF EMERGENCY EXISTS AND THAT DEITY-LIKE POWER IS NECESSARY TO CORRECT THE SITUATION. ALL COMMANDS FROM THIS POINT ON SHALL BE RECORDED FOR SUBSEQUENT AUDITING BY DATA SECURITY DRAGONS. THIS WARNING WILL NOT APPEAR AGAIN DURING THIS SESSION. ... WELCOME AND THANK YOU FOR CHOOSING DEFINE MDISK TODAY. PLEASE DRIVE CAREFULLY. Or my all-time favorite from a real Thinking Machines CM/2: CM/2 OS 3.51-2. 32,768 cores enabled. CAUTION: Running unpartitioned: Safeties are off. Hazard perimeter is on. CM2-1 *That* machine was cool. Bizarre, but cool.
