Re: Please tell me I did something stupid
On Wed, Mar 18, 2009 at 6:36 AM, Alan Altmark alan_altm...@us.ibm.com wrote: I appreciate the sentiments. We are not particularly happy about getting rid of them, but their time had come. In order to keep it to one page, the page was going to have to grow to a non-standard piece of paper because the font was too small, both from an IBM printing standards perspective and based on complaints from sysprogs. Non-standard = more costly to produce. Alan, If these arguments really had any influence on the decision, then I think you're really far off... What we are happy about is the amount of text on that summary, not the physical and logistical issues when it is printed. Let alone the idea that we would need IBM to print it. I expect most VM sysprogs will have someone in the family who heard about this new thing called Internet and could download the PDF. And if printing will result in 3-4 pages, fine. How many of us have bothered to print in double-sided? Oh, and printing these days is electronic. There is hardly the issue of the IBM Printing Department needing to keep a supply of genuine fonts in lead and sufficient pairs of pliers to place those... Even if you would have a hand-written document it could be reproduced. I think the summary describes 3 different routes: tape, 1st level DVD and 2nd level DVD. It would have been more clear to order the content in row major so that you use just on of the 3 sections in it. What troubled me with it was that it missed vital steps in the process, and did not even refer to a section in the book that would have to be checked there. The other part that kept me busy was one step that was deliberately omitted since it happened by magic; would have been nice to explain that you don't have to pick up the RSU when it is merged in before. Bad idea to throw them away. But I would be happy with a summary chapter in the book that has the scenario for those who are not completely new to z/VM installation. Rob
Persistant Flashcopy
I have been playing with Persistant Flashcopy that was introduced to z/VM with APAR VM64449. Great fun! I have established flashcopy relationships between two packs A1 and B1 and have specified that I want to keep label of target volume so I don't get duplicate volumes. FLASHCOPY ESTABLIST SOURCE AAA TARGET BBB LABEL B1 CHGRECORD This is fine. When I do RESYNC to update change from SOURCE to TARGET , it overwrites label of TARGET volume. This is not what I need. Any suggestions as to what I am doing wrong ? Crispin Hugo Systems Programmer Macro 4 This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 plc internal virus protection system.
Re: Please tell me I did something stupid
It sounds like this may come under the heading of beating a dead horse, but that has never stopped VM Sysprogs before, so I've used the Quick Guides for 5 or 6 zVM installs so far and I don't think I've ever used an IBM printed hard copy of them yet. I've always printed a copy from the .PDF files. It would be fine with me if IBM did not even supply a hard copy version. That takes care of any expense issue with non-standard sized paper. (I frequently print other materials on legal sized paper and have no problem with doing so. I suspect other users feel the same way.) Of course, the paper and font size issues could be eliminated by breaking the DVD guide into two versions: 1st level DVD and 2nd level DVD. (The tape install is already in a separate quick guide). Each of these could easily fit on a standard sheet using a larger font. Yes, this would create another, new, document and it could be argued that this would increase the cost... but As mentioned before, don't print any of them. Make them available electronically (only). That also makes it possible to update them much easier if the need arises. If you want to make sure that users are aware of the Quick Guides, put a one-sheet notice in with the other shipped materials providing the URLs for the downloadable guides. Mike C. M. (Mike) Hammock Sr. Technical Advisor IBM System Z Solutions Mainline Information Systems (404) 643-3258 mike.hamm...@mainline.com Alan Altmark alan_altm...@us. ibm.com To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System ib...@listserv.u Subject ARK.EDU Re: Please tell me I did something stupid 03/18/2009 01:37 AM Please respond to The IBM z/VM Operating System ib...@listserv.u ARK.EDU On Tuesday, 03/17/2009 at 09:45 EDT, Mike Hammock mike.hamm...@mainline.com wrote: I also vote for keeping the Quick Guides... I think they are the best thing since sliced bread! The only suggestion I would make would be to 'simplify'; them by completely separating the 1st level and 2nd level install instructions,. I find that skipping around the other parts causes more problems than anything else. I appreciate the sentiments. We are not particularly happy about getting rid of them, but their time had come. In order to keep it to one page, the page was going to have to grow to a non-standard piece of paper because the font was too small, both from an IBM printing standards perspective and based on complaints from sysprogs. Non-standard = more costly to produce. We will instead supply some sort of abbreviated installation/service procedure as part of the book. It won't skip steps, but neither will it have the voluminous explanations of the primary text. Alan Altmark z/VM Development IBM Endicott This e-mail and files transmitted with it are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you are not one of the named recipient(s) or otherwise have reason to believe that you received this message in error, please immediately notify sender by e-mail, and destroy the original message. Thank You.
Re: Please tell me I did something stupid
I agree.when I was working, I used the quick guides, knowing full well that there was a more detailed install doc available.just in case. --- On Wed, 3/18/09, Mike Hammock mike.hamm...@mainline.com wrote: From: Mike Hammock mike.hamm...@mainline.com Subject: Re: Please tell me I did something stupid To: IBMVM@LISTSERV.UARK.EDU Date: Wednesday, March 18, 2009, 8:04 AM It sounds like this may come under the heading of beating a dead horse, but that has never stopped VM Sysprogs before, so I've used the Quick Guides for 5 or 6 zVM installs so far and I don't think I've ever used an IBM printed hard copy of them yet. I've always printed a copy from the .PDF files. It would be fine with me if IBM did not even supply a hard copy version. That takes care of any expense issue with non-standard sized paper. (I frequently print other materials on legal sized paper and have no problem with doing so. I suspect other users feel the same way.) Of course, the paper and font size issues could be eliminated by breaking the DVD guide into two versions: 1st level DVD and 2nd level DVD. (The tape install is already in a separate quick guide). Each of these could easily fit on a standard sheet using a larger font. Yes, this would create another, new, document and it could be argued that this would increase the cost... but As mentioned before, don't print any of them. Make them available electronically (only). That also makes it possible to update them much easier if the need arises. If you want to make sure that users are aware of the Quick Guides, put a one-sheet notice in with the other shipped materials providing the URLs for the downloadable guides. Mike C. M. (Mike) Hammock Sr. Technical Advisor IBM System Z Solutions Mainline Information Systems (404) 643-3258 mike.hamm...@mainline.com Alan Altmark alan_altm...@us. ibm.com To Sent by: The IBM ib...@listserv.uark.edu z/VM Operating cc System ib...@listserv.u Subject ARK.EDU Re: Please tell me I did something stupid 03/18/2009 01:37 AM Please respond to The IBM z/VM Operating System ib...@listserv.u ARK.EDU On Tuesday, 03/17/2009 at 09:45 EDT, Mike Hammock mike.hamm...@mainline.com wrote: I also vote for keeping the Quick Guides... I think they are the best thing since sliced bread! The only suggestion I would make would be to 'simplify'; them by completely separating the 1st level and 2nd level install instructions,. I find that skipping around the other parts causes more problems than anything else. I appreciate the sentiments. We are not particularly happy about getting rid of them, but their time had come. In order to keep it to one page, the page was going to have to grow to a non-standard piece of paper because the font was too small, both from an IBM printing standards perspective and based on complaints from sysprogs. Non-standard = more costly to produce. We will instead supply some sort of abbreviated installation/service procedure as part of the book. It won't skip steps, but neither will it have the voluminous explanations of the primary text. Alan Altmark z/VM Development IBM Endicott This e-mail and files transmitted with it are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not the intended recipient, or the employee or agent responsible to deliver it to the
Re: Setup XLINK
Software AG - Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany, - Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/ Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), David Broadbent, Mark Edwards, Dr. Peter Kurpick, Ivo Totev, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/ Chairman of the Supervisory Board: Frank F. Beelitz - http://www.softwareag.com -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: Tuesday, March 17, 2009 12:33 PM To: ibmvm@listserv.uark.edu Subject: Re: Setup XLINK XLINK makes it possible to protect multiple minidisks on a shared pack. XLINK checks cylinder ranges. You can test this - on VMA, use LINK userid vdev 1 M - on VMB try LINK userid vdev 1 M and this should fail, CP should tell userid vdev not linked, R/W by VMA Note that there are no commands to dynamically the XLINK definitions as those found in SYSTEM CONFIG, and IPL is required. You don't need to define the volumes as shared, but BEWARE: - The problem is MDC: when MDC is active for a volume, CP may find request data in storage and may no go to the disk fo satisfy an I/O. Hence is an update took place in VMA a request from VMB may read backlevel data - Turn MDC OFF for the shared volumes and you are safe (the default for disks definedd as SHARED) - or, if you know 100% sure that only one system is writing to it - leave MDC ON for the volumes on the writing system - turn MDC OFF for the volumes on all reading systems (my former customer has been working like this for years) 2009/3/17 Berry van Sleeuwen berry.vansleeu...@xs4all.nl: Hello Listers, I am looking into XLINK. The main goal is to be able to determine if a minidiskextent on DASD is already in R/W use on a different VM. This way we could provide for an easy switch for linux guests from one VM to another. We do not setup the full CSE here. SPOOL and DIRMAINT are just for their own VM image. Now I have found that I need: - XLINK_SYSTEM_INCLUDE for every VM system. - XLINK_VOLUME_INCLUDE for every DASD volume. - XLINK FORMAT the DASD to enable the volume for XLINK usage. Do I need more? For instance, it could be that there are multiple minidisks on one volume and that the linuxguests in question are spread across the 4 VM images. Should the DASD be set to SHARED for this? As I understand it linux doesn't require the disks to be SHARED but I'd like to be sure. Are there any other issues I should prepare for? TIA, Berry. -- Kris Buelens, IBM Belgium, VM customer support
VSWITCH not working with VLANs
Hi I have been called back to VM to help with a problem VLANs and VSWITCH we have a z/VM 5.4 system with a VSWITCH through which VM and a some Linux systems talk The OSA card is connected to a Cisco 2950 On the 2950 the link is defined as an accessport for VLAN 13 On the VSWITCH all users are defined with VLAN 13 and the VSWITCH is also defined with VLAN 13 everything works Now they want to let one of the Linux systems talk on VLAN 305 Our first step was to change the Cisco link to a trunk allowing vlan 13 and 305 Nothing was changed on the VM side Now NO communication goes through output from q VSWITCH ACC is VSWITCH SYSTEM VSW1 Type: VSWITCH Connected: 2Maxconn: INFINITE PERSISTENT RESTRICTEDNONROUTER Accounting: OFF VLAN Aware Default VLAN: 0013Default Porttype: Access GVRP: Enabled Native VLAN: 0013VLAN Counters: OFF MAC address: 02-00-01-00-00-01 State: Ready IPTimeout: 5 QueueStorage: 8 Authorized userids: BCXZLN01 Porttype: Access VLAN: 0013 BCXZLN02 Porttype: Access VLAN: 0013 BCXZLN03 Porttype: Access VLAN: 0013 BCXZLN04 Porttype: Access VLAN: 0013 BCXZLN05 Porttype: Access VLAN: 0013 BCXZRH01 Porttype: Access VLAN: 0013 SYSTEM Porttype: Access VLAN: 0013 TCPIPPorttype: Access VLAN: 0013 RDEV: FA00.P00 VDEV: FA00 Controller: VSWCTL Why can we not work? Can someone help thank you Jan de Wet Deployment (Business Connexion), Services Building, Midrand, South Africa Cell: +27 (0)82 902 1996 Office: +27 (0)11 990 1695 Fax:+27 (0)86 572 5720 e-mail: jan.de...@bcx.co.za Jesus Christ is my Lord
Quick Guides (was: Please tell me I did something stupid)
On Wed, Mar 18, 2009 at 6:36 AM, Alan Altmark alan_altm...@us.ibm.com wrote: I appreciate the sentiments. We are not particularly happy about getting rid of them, but their time had come. In order to keep it to one page, the page was going to have to grow to a non-standard piece of paper because the font was too small, both from an IBM printing standards perspective and based on complaints from sysprogs. Non-standard = more costly to produce. I would like to add my voice to the many asking for the quick guides to be retained. I have installed the last 3 levels of z/VM using the quick guides. After installing z/VM 5.3 from tape (our 'traditional' method) I then did it again from DVD for the first time. z/VM 5.4 I did only using DVD (twice - once for ESP once for GA). The most difficult bit is deciding which of the options is right for you and I do agree that there was a bit of intuition needed - but I completed the first DVD install within half a day of first seeing the guide, (so it can't have been that bad). I think we are in danger of somewhat missing the point of the quick guide. I never considered it to be full and comprehensive instructions for someone who has never done an install before. The manual does that job very well. It is more of a quick aide memoir for those who need prompts and checklists. After all, pilots know how to fly but they still use checklists to ensure they don't forget something - that doesn't mean we would expect someone to learn to fly from the checklist. Colin Allinson Amadeus Data Processing GmbH
Re: Please tell me I did something stupid
For my two cents I have never used the quick guide. I read through it, but always open the book. Just a comfort factor I guess. I do agree though that seperating 1st and 2nd level instructions is a much better approach that skipping sections. Maybe a flowchart approach might be a good idea. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]on Behalf Of william JANULIN Sent: Wednesday, March 18, 2009 8:06 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Please tell me I did something stupid I agree.when I was working, I used the quick guides, knowing full well that there was a more detailed install doc available.just in case. --- On Wed, 3/18/09, Mike Hammock mike.hamm...@mainline.com wrote: From: Mike Hammock mike.hamm...@mainline.com Subject: Re: Please tell me I did something stupid To: IBMVM@LISTSERV.UARK.EDU Date: Wednesday, March 18, 2009, 8:04 AM It sounds like this may come under the heading of beating a dead horse, but that has never stopped VM Sysprogs before, so I've used the Quick Guides for 5 or 6 zVM installs so far and I don't think I've ever used an IBM printed hard copy of them yet. I've always printed a copy from the .PDF files. It would be fine with me if IBM did not even supply a hard copy version. That takes care of any expense issue with non-standard sized paper. (I frequently print other materials on legal sized paper and have no problem with doing so. I suspect other users feel the same way.) Of course, the paper and font size issues could be eliminated by breaking the DVD guide into two versions: 1st level DVD and 2nd level DVD. (The tape install is already in a separate quick guide). Each of these could easily fit on a standard sheet using a larger font. Yes, this would create another, new, document and it could be argued that this would increase the cost... but As mentioned before, don't print any of them. Make them available electronically (only). That also makes it possible to update them much easier if the need arises. If you want to make sure that users are aware of the Quick Guides, put a one-sheet notice in with the other shipped materials providing the URLs for the downloadable guides. Mike C. M. (Mike) Hammock Sr. Technical Advisor IBM System Z Solutions Mainline Information Systems (404) 643-3258 mike.hamm...@mainline.com Alan Altmark alan_altm...@us. ibm.com To Sent by: The IBM ib...@listserv.uark.edu z/VM Operating cc System ib...@listserv.u Subject ARK.EDU Re: Please tell me I did something stupid 03/18/2009 01:37 AM Please respond to The IBM z/VM Operating System ib...@listserv.u ARK.EDU On Tuesday, 03/17/2009 at 09:45 EDT, Mike Hammock mike.hamm...@mainline.com wrote: I also vote for keeping the Quick Guides... I think they are the best thing since sliced bread! The only suggestion I would make would be to 'simplify'; them by completely separating the 1st level and 2nd level install instructions,. I find that skipping around the other parts causes more problems than anything else. I appreciate the sentiments. We are not particularly happy about getting rid of them, but their time had come. In order to keep it to one page, the page was going to have to grow to a non-standard piece of paper because the font was too small, both from an IBM printing standards perspective and based on complaints from sysprogs. Non-standard =
Re: New CMS based SSLSERV problem... DTCSSL300E
This is slightly off-topic but if anyone has the 5.4 SSLSERV running with the Rumba or WRQ Reflection 3270 emulator, please contact me offline. Thanks. Ray Mrohs U.S. Department of Justice 202-307-6896 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wiggins, Mark Sent: Tuesday, March 17, 2009 9:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: New CMS based SSLSERV problem... DTCSSL300E Thank you to both Dennis and Mark. I had the mount commands in my DTCPARMS, they just weren't syntactically correct. Everything appears to be fine now... Mark Wiggins
Re: Persistant Flashcopy
Hi Crispin, This is fine. When I do RESYNC to update change from SOURCE to TARGET , it overwrites label of TARGET volume. This is not what I need. Any suggestions as to what I am doing wrong ? You're not doing anything wrong, but RESYNC may indeed not be doing what you want. If that's the case, send us feedback through the official channels. The LABEL operand on the FLASHCOPY command is provided by z/VM as a matter of convenience, and is likely most useful for non-persistent (or at least non-incremental) relationships. But, it is not subject to the same persistence as the FlashCopy relationship itself, which is managed by the DASD subsystem. As a result, the RESYNC command you're doing is noting that the labels on AAA and BBB are different and thus should also be resynchronized. Regards, Eric Eric Farman z/VM I/O Development IBM Endicott, NY
DMS5DF3366W SEVER FROM *IDENT
As a result of a careless mistake (starting an ISLINK between systems running SFS servers by the same name), the servers got this message: DMS5DF3366W SEVER FROM *IDENT FOR RESOURCE YPOOL. REASON CODE 0 After correcting the problem (deactivating the link), is there any way short of IPL CMS to reconnect the SFS server to the *Ident service, and allow access to the filepool? Thanks, Shimon
Re: Please tell me I did something stupid
I'm clearly swimming upstream, but I've never used the quick guides, and probably never will. Anything that is a summary of something else carrie s the risk of not being complete. Brian Nielsen On Wed, 18 Mar 2009 01:36:17 -0400, Alan Altmark alan_altm...@us.ibm.com wrote: On Tuesday, 03/17/2009 at 09:45 EDT, Mike Hammock mike.hamm...@mainline.com wrote: I also vote for keeping the Quick Guides... I think they are the bes t thing since sliced bread! The only suggestion I would make would be to 'simplify'; them by completely separating the 1st level and 2nd level install instructions,. I find that skipping around the other parts causes more problems than anything else. I appreciate the sentiments. We are not particularly happy about gettin g rid of them, but their time had come. In order to keep it to one page , the page was going to have to grow to a non-standard piece of paper because the font was too small, both from an IBM printing standards perspective and based on complaints from sysprogs. Non-standard = mor e costly to produce. We will instead supply some sort of abbreviated installation/service procedure as part of the book. It won't skip steps, but neither will it have the voluminous explanations of the primary text. Alan Altmark z/VM Development IBM Endicott =
Re: Version 4 to Version 5
Hi, Simon. I think that spool files dumped to tape from z/VM V4 SPXTAPE should be restorable by z/VM V5 SPXTAPE. How else could sites move their V4 spool files to V5 when they do an upgrade? But I would do a little test first, if I could, just to make sure. Have a good one. Shimon Lebowitz wrote: Ivan Warren i...@vmfacility.fr asked: SPXTAPE ? And of course the answer is 'yes', but... In fact I have decided NOT to ipl on the same spool volumes and same CP OWNED list, but to use SPXTAPE to move (copy) the spool to new volumes. However, at least I can assume (I hope) that there is no problem with V5 loading files dumped by V4 SPXTAPE. Right? :-) Thanks to everyone else who helped too! Shimon (also from SP3 days, but I can't compare to REAL old-timers here...) -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: Version 4 to Version 5
Ivan Warren i...@vmfacility.fr asked: SPXTAPE ? And of course the answer is 'yes', but... In fact I have decided NOT to ipl on the same spool volumes and same CP OWNED list, but to use SPXTAPE to move (copy) the spool to new volumes. However, at least I can assume (I hope) that there is no problem with V5 loading files dumped by V4 SPXTAPE. Right? :-) Thanks to everyone else who helped too! Shimon (also from SP3 days, but I can't compare to REAL old-timers here...)
Re: Please tell me I did something stupid
On Mar 18, 2009, at 3:10 AM, Rob van der Heij wrote: Bad idea to throw them away. But I would be happy with a summary chapter in the book that has the scenario for those who are not completely new to z/VM installation. It strikes me that, given that we have several versions' worth of excellent models, there's nothing really stopping, um, one of *us* from doing a set of one page versions, one for tape, for first level DVD, and for second level DVD. Of course, getting those KNOWN to people who don't already know about the mailing list becomes the trick. Adam
Re: New CMS based SSLSERV problem... DTCSSL300E
On Wednesday, 03/18/2009 at 09:49 EDT, Mrohs, Ray ray.mr...@usdoj.gov wrote: This is slightly off-topic but if anyone has the 5.4 SSLSERV running with the Rumba or WRQ Reflection 3270 emulator, please contact me offline. Thanks. Neither Rumba nor Reflection work correctly. We are working with Attachmate to fix Reflection. Rumba has not responded to our attempts to contact them. IBM Host on Demand doesn't work, either, at the moment. The common problem we are seeing is that the clients are bringing down the session when the server requests a client certificate they don't posesss. The RFC specifies that the client should send an empty certificate list and that it is up to the server, not the client, to decide whether the lack of a client certificate is grounds for a divorce. Work with your client vendor. If they want someone in IBM to talk to, send them to me. Alan Altmark z/VM Development IBM Endicott
Re: DMS5DF3366W SEVER FROM *IDENT
On Wednesday, 03/18/2009 at 09:51 EDT, Shimon Lebowitz shimon...@gmail.com wrote: As a result of a careless mistake (starting an ISLINK between systems running SFS servers by the same name), the servers got this message: DMS5DF3366W SEVER FROM *IDENT FOR RESOURCE YPOOL. REASON CODE 0 After correcting the problem (deactivating the link), is there any way short of IPL CMS to reconnect the SFS server to the *Ident service, and allow access to the filepool? No. The filepool has to be restarted. Alan Altmark z/VM Development IBM Endicott
Re: Please tell me I did something stupid
On Wednesday, 03/18/2009 at 10:48 EDT, Adam Thornton athorn...@sinenomine.net wrote: It strikes me that, given that we have several versions' worth of excellent models, there's nothing really stopping, um, one of *us* from doing a set of one page versions, one for tape, for first level DVD, and for second level DVD. Of course, getting those KNOWN to people who don't already know about the mailing list becomes the trick. I, for one, would prefer that the community NOT do that as it creates an expectation that installing release 'n+1' is the same as release 'n'. I think that at such a sensitive point in the deployment process that they should be using Official Information that comes with the installation/service deliverable. But if the community does choose to build such a set of documents, please clearly point out that the information is not provided or warranted by IBM and that installation/service problems encounted need to be reported to the author, not IBM. (I don't want PMRs that begin I attend a small mid-western university. While using the One-Page Install Guide from the Internet and I encountered a problem...) Checklists and other preparatory advice, based on real-world experience, are ponies of a different color. They would definitely be a value-add, providing *guidance* (opinion) where IBM can usually only provide a *procedure*. Alan Altmark z/VM Development IBM Endicott
Re: Version 4 to Version 5
How else? Perhaps by providing a compatibility PTF that allows the new SPXTAPE to DUMP the old system's files. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dave Jones Sent: Wednesday, March 18, 2009 7:28 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Version 4 to Version 5 Hi, Simon. I think that spool files dumped to tape from z/VM V4 SPXTAPE should be restorable by z/VM V5 SPXTAPE. How else could sites move their V4 spool files to V5 when they do an upgrade? But I would do a little test first, if I could, just to make sure. Have a good one. Shimon Lebowitz wrote:
Re: Please tell me I did something stupid
On Mar 18, 2009, at 10:13 AM, Alan Altmark wrote: Checklists and other preparatory advice, based on real-world experience, are ponies of a different color. They would definitely be a value- add, providing *guidance* (opinion) where IBM can usually only provide a *procedure*. Hey, man, *you're* the one threatening to take away my pony. I don't care if the Quick And Dirty Guide is four or five pages, or whether there's a paper version at all. MY use case for the thing is to open it in one window, have my 3270 emulator in another window, and look at the guide when it's time to do the next step. Adam
Re: Version 4 to Version 5
However, at least I can assume (I hope) that there is no problem with V5 loading files dumped by V4 SPXTAPE. Right? :-) Right. No PTFs required, as someone else suggested. In the unlikely event that you do encounter a problem with this, please contact the Support Center. John Franciscovich z/VM Development
OT: IBM said to be in talks to buy Sun Microsystems
Bloomberg News is reporting that IBM is holding talks with Sun Microsystem to buy them out: http://www.chron.com/disp/story.mpl/headline/biz/6318756.html -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: DMS5DF3366W SEVER FROM *IDENT
OK, Thank you Alan. Now, I am trying to see how to *prevent* the problem. I tried starting up a LOCAL server with IUCV *IDENT RESANY LOCAL but it refuses to initialize. When I left in RESANY GLOBAL the two systems still seem to interact, even if I have LOCAL in the DMSPARMS file. The other system got: HCPACR2733E IDENTIFY REQUEST FROM NODE othernode FOR RESOURCE YPOOL IS A DUPLICATE -- RESOURCE REJECTED. So, LOCAL in the parms file does NOT seem to prevent network-wide announcement of the pool. One of the servers (the 'production' one) *must* be defined as REMOTE/GLOBAL. Is there ANY way to run a local service with the same name and tell VM that I *only* want to access the local one? Hmmm... I guess I could try the same trick I use with VMSYS. Call the local pool YPOOL2 and set up a comdir to send requests for YPOOL to YPOOL2. Is that the only solution? I really didn't want to have to change setup files too much, which is why I was hoping the directory change would do it. Thanks, and sorry for rambling... :-) Shimon Original message Date: Wed, 18 Mar 2009 10:54:58 -0400 From: Alan Altmark alan_altm...@us.ibm.com Subject: Re: DMS5DF3366W SEVER FROM *IDENT To: IBMVM@LISTSERV.UARK.EDU On Wednesday, 03/18/2009 at 09:51 EDT, Shimon Lebowitz shimon...@gmail.com wrote: As a result of a careless mistake (starting an ISLINK between systems running SFS servers by the same name), the servers got this message: DMS5DF3366W SEVER FROM *IDENT FOR RESOURCE YPOOL. REASON CODE 0 After correcting the problem (deactivating the link), is there any way short of IPL CMS to reconnect the SFS server to the *Ident service, and allow access to the filepool? No. The filepool has to be restarted. Alan Altmark z/VM Development IBM Endicott
Re: Quick Guides (was: Please tell me I did something stupid)
I appreciate the sentiments. We are not particularly happy about getting rid of them, but their time had come. In order to keep it to one page, the page was going to have to grow to a non-standard piece of paper because the font was too small, both from an IBM printing standards perspective and based on complaints from sysprogs. Non-standard = more costly to produce. I've only used the double-sided Installation Summary sheets as a quick pointer into how far I am though the complete installation task (i.e. a quarter way done, or half way, etc.). That's helpful when trying to decide whether to go home and resume in the morning, or stay a little longer to get it all wrapped up. Preferring to better understand everything that goes on so that if something breaks it's more clear what broke, I use the full Guide for Automated Installation and Service. It serves a bit as education, and includes *everything*. Obviously, it's important to check the PSP buckets for any doc changes, too. Since the full Guide has EVERY step, it permits me to write the current date and time in the margin as I execute each command. Knowing that interruptions are frequent, and often it may take days or weeks to get back to completing the installation (less so nowadays with the speedy installs), the date/time in the margin provide clear doc to let me resume right where I left off. *More importantly*, the date/time in the margin let me look back later to match up console logs of the installation activities. Even wonder some time later when something is not working properly, if maybe you might have skipped a step? (Hmmm... wasn't an accidentally skipped step what triggered this thread!?). Seeing the date/time in the margin provides pretty (although not 100%) empirical proof that the step was executed, and enough information to let you match up a console log showing the execution (and perhaps an error message that you missed while fielding a phone call while it ran). But I understand and empathize with those who regularly perform many separate z/VM installations, using the Summaries as the installation preflight checklist (what a GREAT analogy Colin provided!). Being experience pilots they already know the installation details, and just want to prevent a crash caused by missing one of those critical preflight checklist item. Even so, if they are doing the installation for a customer, those date/timestamps in the margin of the Guide and the matching console logs, might provide their customer with the evidence that permits them with reasons to extend their support contract. Just my humble opinion... 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: Please tell me I did something stupid
Brian Nielsen wrote: I'm clearly swimming upstream, but I've never used the quick guides, and probably never will. Anything that is a summary of something else carries the risk of not being complete. Brian Nielsen I never used the quick guide either. Brian pretty much summed up the reasons. -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: Version 4 to Version 5
Hi Simon, We did exactly what you describe when we moved from z/VM 4.4 to z/VM 5.2 - backed up the spool with SPXTAPE on the 4.4 system, brought up the z/VM 5.2 system with new spool volumes, and restored the 4.4 SPXTAPE under 5.2. No problems. On Wed, Mar 18, 2009 at 8:28 AM, Dave Jones d...@vsoft-software.com wrote: Hi, Simon. I think that spool files dumped to tape from z/VM V4 SPXTAPE should be restorable by z/VM V5 SPXTAPE. How else could sites move their V4 spool files to V5 when they do an upgrade? But I would do a little test first, if I could, just to make sure. Have a good one. Shimon Lebowitz wrote: Ivan Warren i...@vmfacility.fr asked: SPXTAPE ? And of course the answer is 'yes', but... In fact I have decided NOT to ipl on the same spool volumes and same CP OWNED list, but to use SPXTAPE to move (copy) the spool to new volumes. However, at least I can assume (I hope) that there is no problem with V5 loading files dumped by V4 SPXTAPE. Right? :-) Thanks to everyone else who helped too! Shimon (also from SP3 days, but I can't compare to REAL old-timers here...) -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: DMS5DF3366W SEVER FROM *IDENT
On Wednesday, 03/18/2009 at 12:08 EDT, Shimon Lebowitz shimon...@gmail.com wrote: Now, I am trying to see how to *prevent* the problem. I tried starting up a LOCAL server with IUCV *IDENT RESANY LOCAL but it refuses to initialize. When I left in RESANY GLOBAL the two systems still seem to interact, even if I have LOCAL in the DMSPARMS file. The other system got: HCPACR2733E IDENTIFY REQUEST FROM NODE othernode FOR RESOURCE YPOOL IS A DUPLICATE -- RESOURCE REJECTED. So, LOCAL in the parms file does NOT seem to prevent network-wide announcement of the pool. Correct. Only VMSYSxxx filepools are local from CP's perspective. All others create global APPC/VM resources. The LOCAL parameter in DMSPARMS causes the SFS server (not CP) to reject connections from remote users. One of the servers (the 'production' one) *must* be defined as REMOTE/GLOBAL. Is there ANY way to run a local service with the same name and tell VM that I *only* want to access the local one? No. COMDIR is the only way to redirect the connection. If you want to prevent resource revocation, use IUCV *IDENT resname rather than RESANY. Alan Altmark z/VM Development IBM Endicott
Re: Quick Guides
On Wednesday, 03/18/2009 at 09:39 EDT, Colin Allinson cgallin...@amadeus.com wrote: I think we are in danger of somewhat missing the point of the quick guide. I never considered it to be full and comprehensive instructions for someone who has never done an install before. The manual does that job very well. It is more of a quick aide memoir for those who need prompts and checklists. After all, pilots know how to fly but they still use checklists to ensure they don't forget something - that doesn't mean we would expect someone to learn to fly from the checklist. The decision to get rid of the one-page Quick Guides as they exist today was a business decision. Technically we could continue produce them, of course, but non-optional changes to form and content have to be made. The resulting document would have both diminished value and increased cost. We chose instead to spend those dollars to provide a better Installation/Service guide that can meet the needs of both the experienced VMer and the newbie. As it happens, it's also an exercise that lets us study the human factors of installation/service so that we can learn where the soft spots are and decide if they need more attention, whether that's in words or by updates to the tools. Alan Altmark z/VM Development IBM Endicott
Re: Quick Guides
The newbie can be a tough one. When I was with Amdahl, we always sought out newbies and had them try to do it by the book. It is interesting to see the different ways that peoples minds work, the different ways that they interpret the same prose. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Wednesday, March 18, 2009 1:16 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Quick Guides We chose instead to spend those dollars to provide a better Installation/Service guide that can meet the needs of both the experienced VMer and the newbie. As it happens, it's also an exercise that lets us study the human factors of installation/service so that we can learn where the soft spots are and decide if they need more attention, whether that's in words or by updates to the tools. Alan Altmark z/VM Development IBM Endicott
XEDIT Macro
Is there any way to access the prefix area of a line from an XEDIT Macro? I see nothing in the EXTRACT command. Am I missing something there? Is there some other way to access it? Regards, Richard Schuh
Re: XEDIT Macro
Title: XEDIT Macro Schuh, Richard wrote: Is there any way to access the prefix area of a line from an XEDIT Macro? I see nothing in the EXTRACT command. Am I missing something there? Is there some other way to access it? Regards, Richard Schuh That begs a question: What do you want to do with the prefix area that you can't do with an Xedit command? -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: DMS5DF3366W SEVER FROM *IDENT
Do I understand you correctly that if I use IUCV *IDENT resname the resname should be the filepoolid? And if I do that for any *local* pool, and then the fact that there is a global pool of the same name will not cause any problem? What about in the other direction? Is the REMOTE sfs server affected when a LOCAL server is known in the group? I seem to remember that earlier today, when BOTH systems got the HCPACR2733E msg, only the pool defined as LOCAL crashed (after meeting the REMOTE pool), but the one defined as REMOTE kept on working as usual (even though it also got that msg). Is that correct? Thank you for your help! Shimon When I left in RESANY GLOBAL the two systems still seem to interact, even if I have LOCAL in the DMSPARMS file. The other system got: HCPACR2733E IDENTIFY REQUEST FROM NODE othernode FOR RESOURCE YPOOL IS A DUPLICATE -- RESOURCE REJECTED. So, LOCAL in the parms file does NOT seem to prevent network-wide announcement of the pool. Correct. Only VMSYSxxx filepools are local from CP's perspective. All others create global APPC/VM resources. The LOCAL parameter in DMSPARMS causes the SFS server (not CP) to reject connections from remote users. One of the servers (the 'production' one) *must* be defined as REMOTE/GLOBAL. Is there ANY way to run a local service with the same name and tell VM that I *only* want to access the local one? No. COMDIR is the only way to redirect the connection. If you want to prevent resource revocation, use IUCV *IDENT resname rather than RESANY.
Re: XEDIT Macro
If you are talking about writing your own prefix commands, the following is an example: PREFIXCD XEDIT Y2 /* CCD - COPY BLOCK OF LINES TO AN EXTERNAL CMS FILE */ /* THEY CAN THEN BE BROUGHT IN TO THE SAME OR */ /* OTHER XEDIT FILES AT A LATER TIME */ /* */ /* TOM DUERBUSCH - THD CONSULTING */ /* 6/18/93*/ /* */ ARG PREFIX OPERAND PLINE OP REST PARSE SOURCE . . . . . NAME . PRF=NAME||SPACE(OP REST) 'COMMAND PRESERVE' 'COMMAND SET STAY ON' 'SET CMSTYPE HT' 'COMMAND ERASE STACK XEDIT A' 'SET CMSTYPE RT' SELECT WHEN LENGTH(NAME) = 2 THEN /* NO BLOCK GROUP */ DO 'COMMAND EXTRACT /LINE/' ':'PLINE 'PUT 1 STACK XEDIT A' END WHEN LENGTH(NAME) = 3 THEN /* BLOCK GROUP */ DO /* LOOK FOR THIS PREFIX COMMAND PRIOR TO THIS ONE */ DO FSD = 0 TO PLINE UNTIL RC ¬= 2 'COMMAND EXTRACT /PENDING BLOCK' NAME ':'FSD ':'PLINE '/' END SELECT WHEN PENDING.0 ¬= 0 THEN /* WE HAVE ENDED THE PREFIX BLOCK * DO 'COMMAND :'PENDING.1 'COMMAND SET PENDING OFF' RANGE = PLINE - PENDING.1 SELECT WHEN RANGE 0 THEN RANGE = RANGE +1 WHEN RANGE 0 THEN RANGE = RANGE -1 OTHERWISE NOP END 'COMMAND LOCATE :'PENDING.1 'PUT ' RANGE ' STACK XEDIT A' END OTHERWISE /* THIS IS A START OF A PREFIX BLOCK */ DO 'COMMAND :'PLINE 'COMMAND SET PENDING BLOCK' LEFT(PRF,5) END END OTHERWISE NOP END 'COMMAND RESTORE' RETURN and then add to the profile xedit: /* FOLLOWING ARE THD CREATED PREFIX COMMANDS */ SET 'PREFIX SYNONYM CD PREFIXCD' SET 'PREFIX SYNONYM CCD PREFIXCD' SET 'PREFIX SYNONYM MD PREFIXMD' SET 'PREFIX SYNONYM MMD PREFIXMD' SET 'PREFIX SYNONYM G PREFIXG' Tom Duerbusch THD Consulting Schuh, Richard rsc...@visa.com 3/18/2009 3:45 PM Is there any way to access the prefix area of a line from an XEDIT Macro? I see nothing in the EXTRACT command. Am I missing something there? Is there some other way to access it? Regards, Richard Schuh
Re: XEDIT Macro
On Wed, 18 Mar 2009 13:45:05 -0700, Schuh, Richard rsc...@visa.com wrot e: Is there any way to access the prefix area of a line from an XEDIT Macro? I see nothing in the EXTRACT command. Am I missing something there? Is there some other way to access it? If you are looking to see what commands are in the prefix areas, perhaps you will find this useful: 'EXTRACT /PENDING */' There are various sub-options to PENDING that may or may not be useful to you depending on the particulars of what you want. Brian Nielsen
Re: XEDIT Macro
On Wed, 18 Mar 2009 13:45:05 -0700, Schuh, Richard rsc...@visa.com wrot e: Is there any way to access the prefix area of a line from an XEDIT Macro? I see nothing in the EXTRACT command. Am I missing something there? Is there some other way to access it? Here is a more complete example which shows all commands in the prefix areas: /* */ line=0 DO UNTIL PENDING.0=0 'EXTRACT /PENDING * :'line+1'/' DO i=0 TO pending.0 say format(i,3) pending.i END line=pending.1 END Brian Nielsen
Re: XEDIT Macro
Does it really matter to you? When a specific PFK is pressed, I want to process according to the values in the prefix areas of all lines in the file. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Rich Smrcina Sent: Wednesday, March 18, 2009 1:48 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XEDIT Macro Schuh, Richard wrote: Is there any way to access the prefix area of a line from an XEDIT Macro? I see nothing in the EXTRACT command. Am I missing something there? Is there some other way to access it? Regards, Richard Schuh That begs a question: What do you want to do with the prefix area that you can't do with an Xedit command? -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: XEDIT Macro
By default, the values in the prefix areas are the line numbers, no? Or, if you'd ask the user to type various strings in the prefix, then EXTRACT PENDING is the way to go 2009/3/18 Schuh, Richard rsc...@visa.com: Does it really matter to you? When a specific PFK is pressed, I want to process according to the values in the prefix areas of all lines in the file. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Rich Smrcina Sent: Wednesday, March 18, 2009 1:48 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XEDIT Macro Schuh, Richard wrote: Is there any way to access the prefix area of a line from an XEDIT Macro? I see nothing in the EXTRACT command. Am I missing something there? Is there some other way to access it? Regards, Richard Schuh That begs a question: What do you want to do with the prefix area that you can't do with an Xedit command? -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009 -- Kris Buelens, IBM Belgium, VM customer support
Re: Anne Altman...
Alyce, She's registered on LinkedIn. You could try contacting her through there. Best regards, Mark Date: Wed, 18 Mar 2009 15:19:23 -0700 From: 00...@vm1.cc.nps.navy.mil Subject: Anne Altman... To: IBMVM@LISTSERV.UARK.EDU Hello, I would like to get in touch with Anne K. Altman, General Manager, System Z IBM Systems and Techology Group. Can someone please send me her contact information? Thank you, Alyce Austin Naval Postgraduate School _ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme
Re: Anne Altman...
Rather that post her personal contact info in eternity on this list, try going to: http://www.ibm.com/contact/employees/us/ You can look up any IBM employee worldwide. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Alyce Austin 00...@vm1.cc.nps.navy.mil Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/18/2009 05:19 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Anne Altman... Hello, I would like to get in touch with Anne K. Altman, General Manager, System Z IBM Systems and Techology Group. Can someone please send me her contact information? Thank you, Alyce Austin Naval Postgraduate School 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: Anne Altman...
That was easy... Thanks, Alyce -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter Sent: Wednesday, March 18, 2009 3:29 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Anne Altman... Rather that post her personal contact info in eternity on this list, try going to: http://www.ibm.com/contact/employees/us/ You can look up any IBM employee worldwide. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Alyce Austin 00...@vm1.cc.nps.navy.mil Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/18/2009 05:19 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Anne Altman... Hello, I would like to get in touch with Anne K. Altman, General Manager, System Z IBM Systems and Techology Group. Can someone please send me her contact information? Thank you, Alyce Austin Naval Postgraduate School 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: XEDIT Macro
Do not assume that normal defaults are in effect. I am an abnormal sort. This is not a normal XEDIT session. Items are being displayed in XEDIT and the viewer specifies the disposition of individual items by entries in the prefix area which has been set to NULLS by the profile. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: Wednesday, March 18, 2009 3:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XEDIT Macro By default, the values in the prefix areas are the line numbers, no? Or, if you'd ask the user to type various strings in the prefix, then EXTRACT PENDING is the way to go 2009/3/18 Schuh, Richard rsc...@visa.com: Does it really matter to you? When a specific PFK is pressed, I want to process according to the values in the prefix areas of all lines in the file. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Rich Smrcina Sent: Wednesday, March 18, 2009 1:48 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XEDIT Macro Schuh, Richard wrote: Is there any way to access the prefix area of a line from an XEDIT Macro? I see nothing in the EXTRACT command. Am I missing something there? Is there some other way to access it? Regards, Richard Schuh That begs a question: What do you want to do with the prefix area that you can't do with an Xedit command? -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009 -- Kris Buelens, IBM Belgium, VM customer support
Re: SCSIDISC SAMPEXEC on z/VM 5.4.0
That does seem odd.. I would think it would be supplied named as EXEC in that case.. I agree it implies a 'sample' when named SAMPEXEC .. which is only useful when the 'sample' is human readable so you can see what a good sample looks like ;-) Inconsistent to say the least, but I'm not aware of the reasons (if any) behind not releasing the source. Maybe Chuckie knows.. ? Scott On Wed, Mar 18, 2009 at 5:04 PM, Raymond Noal raymond.n...@hds.com wrote: Dear List Members: Just to save you some time and grief, I’m passing this along. We have just started using FCP devices for our Linux (SuSE Red Hat) virtual machines running under our z/VM 5.4.0 system. In order to verify our hardware configuration and our switch configurations, I was able to use the SCSIDISC SAMPEXEC program found on MAINT’s 2CC mini disk. To my surprise, the SCSIDISC SAMPEXEC is not REXX source code, but instead it is compiled REXX. I requested a copy of the REXX source for SCSIDISC, but IBM will not release the source code. A dark day in VM-land, for sure. As I said, just an FYI. ***HITACHI* *** **DATA SYSTEMS* *Raymond E. Noal* *Senior Technical Engineer* *Office: (408) 970 - 7978*
Re: XEDIT Macro
On Thu, Mar 19, 2009 at 12:10 AM, Schuh, Richard rsc...@visa.com wrote: Do not assume that normal defaults are in effect. I am an abnormal sort. This is not a normal XEDIT session. Items are being displayed in XEDIT and the viewer specifies the disposition of individual items by entries in the prefix area which has been set to NULLS by the profile. And you don't control the entire navigation with an XEDIT macro using the READ subcommand? If you can do that, you get the entries back tagged with a PRF Rob
Re: SCSIDISC SAMPEXEC on z/VM 5.4.0
Hi Scott, Yes, I agree. This goes against years of IBM tradition and history of IBM employees sharing sample code with the user community to highlight a new function/feature of an operating system or application. I look at Kris Buelens (and others) who have graciously shared code they developed for the use and benefit of all concerned. We all own them a debt of gratitude. As to Chuckie - while although he does dance to a different drummer, he is still a staunch IBM employee. So, if the mandate is not to distribute the source code I sincerely doubt he will go against company policy. HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Wednesday, March 18, 2009 4:15 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SCSIDISC SAMPEXEC on z/VM 5.4.0 That does seem odd.. I would think it would be supplied named as EXEC in that case.. I agree it implies a 'sample' when named SAMPEXEC .. which is only useful when the 'sample' is human readable so you can see what a good sample looks like ;-) Inconsistent to say the least, but I'm not aware of the reasons (if any) behind not releasing the source. Maybe Chuckie knows.. ? Scott On Wed, Mar 18, 2009 at 5:04 PM, Raymond Noal raymond.n...@hds.com wrote: Dear List Members: Just to save you some time and grief, I'm passing this along. We have just started using FCP devices for our Linux (SuSE Red Hat) virtual machines running under our z/VM 5.4.0 system. In order to verify our hardware configuration and our switch configurations, I was able to use the SCSIDISC SAMPEXEC program found on MAINT's 2CC mini disk. To my surprise, the SCSIDISC SAMPEXEC is not REXX source code, but instead it is compiled REXX. I requested a copy of the REXX source for SCSIDISC, but IBM will not release the source code. A dark day in VM-land, for sure. As I said, just an FYI. HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978
Anne Altman...
Hello, I would like to get in touch with Anne K. Altman, General Manager, System Z IBM Systems and Techology Group. Can someone please send me her contact information? Thank you, Alyce Austin Naval Postgraduate School
Re: SCSIDISC SAMPEXEC on z/VM 5.4.0
Well - I'm a staunch IBM employee myself, though I try to remain neutral in this forum. My influence is limited, so not a great loss ;-) I think even Chuckie will agree that providing a SAMPEXEC without the source is a misnomer and a packaging issue at the least.. I'm still hoping this was simply a mistake and the source can actually be provided. I'm not sure what avenue you took to request the source - but maybe it's simply a misunderstanding. If not - then at least provide a rational reason why we shouldn't understand how this utility works (or even legalese if rational thought has been excluded). I'm with ya, Raymond ;-) Scott On Wed, Mar 18, 2009 at 5:32 PM, Raymond Noal raymond.n...@hds.com wrote: Hi Scott, Yes, I agree. This goes against years of IBM tradition and history of IBM employees sharing sample code with the user community to highlight a new function/feature of an operating system or application. I look at Kris Buelens (and others) who have graciously shared code they developed for the use and benefit of all concerned. We all own them a debt of gratitude. As to Chuckie – while although he does dance to a different drummer, he is still a staunch IBM employee. So, if the mandate is not to distribute the source code I sincerely doubt he will go against company policy. *HITACHI* * **DATA SYSTEMS* *Raymond E. Noal* *Senior Technical Engineer* *Office: (408) 970 - 7978* -- *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On Behalf Of *Scott Rohling *Sent:* Wednesday, March 18, 2009 4:15 PM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* Re: SCSIDISC SAMPEXEC on z/VM 5.4.0 That does seem odd.. I would think it would be supplied named as EXEC in that case.. I agree it implies a 'sample' when named SAMPEXEC .. which is only useful when the 'sample' is human readable so you can see what a good sample looks like ;-) Inconsistent to say the least, but I'm not aware of the reasons (if any) behind not releasing the source. Maybe Chuckie knows.. ? Scott On Wed, Mar 18, 2009 at 5:04 PM, Raymond Noal raymond.n...@hds.com wrote: Dear List Members: Just to save you some time and grief, I’m passing this along. We have just started using FCP devices for our Linux (SuSE Red Hat) virtual machines running under our z/VM 5.4.0 system. In order to verify our hardware configuration and our switch configurations, I was able to use the SCSIDISC SAMPEXEC program found on MAINT’s 2CC mini disk. To my surprise, the SCSIDISC SAMPEXEC is not REXX source code, but instead it is compiled REXX. I requested a copy of the REXX source for SCSIDISC, but IBM will not release the source code. A dark day in VM-land, for sure. As I said, just an FYI. *HITACHI* * **DATA SYSTEMS* *Raymond E. Noal* *Senior Technical Engineer* *Office: (408) 970 - 7978*
Re: SCSIDISC SAMPEXEC on z/VM 5.4.0
Scott, The response I received from IBM was the result of my opening an ETR on the subject. To protect the innocent, I did not mention the name of the IBM employee who works in the z/VM I/O Development group - if that's of any use. Welcome aboard !! HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Wednesday, March 18, 2009 5:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SCSIDISC SAMPEXEC on z/VM 5.4.0 Well - I'm a staunch IBM employee myself, though I try to remain neutral in this forum. My influence is limited, so not a great loss ;-) I think even Chuckie will agree that providing a SAMPEXEC without the source is a misnomer and a packaging issue at the least.. I'm still hoping this was simply a mistake and the source can actually be provided. I'm not sure what avenue you took to request the source - but maybe it's simply a misunderstanding. If not - then at least provide a rational reason why we shouldn't understand how this utility works (or even legalese if rational thought has been excluded). I'm with ya, Raymond ;-) Scott On Wed, Mar 18, 2009 at 5:32 PM, Raymond Noal raymond.n...@hds.com wrote: Hi Scott, Yes, I agree. This goes against years of IBM tradition and history of IBM employees sharing sample code with the user community to highlight a new function/feature of an operating system or application. I look at Kris Buelens (and others) who have graciously shared code they developed for the use and benefit of all concerned. We all own them a debt of gratitude. As to Chuckie - while although he does dance to a different drummer, he is still a staunch IBM employee. So, if the mandate is not to distribute the source code I sincerely doubt he will go against company policy. HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Wednesday, March 18, 2009 4:15 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SCSIDISC SAMPEXEC on z/VM 5.4.0 That does seem odd.. I would think it would be supplied named as EXEC in that case.. I agree it implies a 'sample' when named SAMPEXEC .. which is only useful when the 'sample' is human readable so you can see what a good sample looks like ;-) Inconsistent to say the least, but I'm not aware of the reasons (if any) behind not releasing the source. Maybe Chuckie knows.. ? Scott On Wed, Mar 18, 2009 at 5:04 PM, Raymond Noal raymond.n...@hds.com wrote: Dear List Members: Just to save you some time and grief, I'm passing this along. We have just started using FCP devices for our Linux (SuSE Red Hat) virtual machines running under our z/VM 5.4.0 system. In order to verify our hardware configuration and our switch configurations, I was able to use the SCSIDISC SAMPEXEC program found on MAINT's 2CC mini disk. To my surprise, the SCSIDISC SAMPEXEC is not REXX source code, but instead it is compiled REXX. I requested a copy of the REXX source for SCSIDISC, but IBM will not release the source code. A dark day in VM-land, for sure. As I said, just an FYI. HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978
Re: XEDIT Macro
On Thu, Mar 19, 2009 at 12:48 AM, Schuh, Richard rsc...@visa.com wrote: No. I have not figured out how to use READ to do what I want. So far, I have succeeded only in getting the command line stacked; none of the file lines, changed or not. So how is it done? When you issue the READ you get control back when the user hits an AID key. At that point there's one line stacked for each change on the screen. You can decide whether XEDIT should update the file being edited or not. When you have processed the stacked lines, you issue another READ until you have seen the signal to terminate (eg PFK 3). Try something like this to see what happens: /* */ 'READ ALL NUMBER TAG' address command 'PIPE stack | cons' Rob Warning: READ used to be a NOP when there is a line stacked when it is invoked. I don't see it mentioned anymore in the notes, so it may have been fixed. It was a very popular cause for such applications to get into a loop.
Re: SCSIDISC SAMPEXEC on z/VM 5.4.0
My apologies to the z/VM I/O Development Group. I was wrong. The signature of the responder to my ETR said - CP Support. HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978 From: Raymond Noal Sent: Wednesday, March 18, 2009 5:22 PM To: 'The IBM z/VM Operating System' Subject: RE: SCSIDISC SAMPEXEC on z/VM 5.4.0 Scott, The response I received from IBM was the result of my opening an ETR on the subject. To protect the innocent, I did not mention the name of the IBM employee who works in the z/VM I/O Development group - if that's of any use. Welcome aboard !! HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Wednesday, March 18, 2009 5:17 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SCSIDISC SAMPEXEC on z/VM 5.4.0 Well - I'm a staunch IBM employee myself, though I try to remain neutral in this forum. My influence is limited, so not a great loss ;-) I think even Chuckie will agree that providing a SAMPEXEC without the source is a misnomer and a packaging issue at the least.. I'm still hoping this was simply a mistake and the source can actually be provided. I'm not sure what avenue you took to request the source - but maybe it's simply a misunderstanding. If not - then at least provide a rational reason why we shouldn't understand how this utility works (or even legalese if rational thought has been excluded). I'm with ya, Raymond ;-) Scott On Wed, Mar 18, 2009 at 5:32 PM, Raymond Noal raymond.n...@hds.com wrote: Hi Scott, Yes, I agree. This goes against years of IBM tradition and history of IBM employees sharing sample code with the user community to highlight a new function/feature of an operating system or application. I look at Kris Buelens (and others) who have graciously shared code they developed for the use and benefit of all concerned. We all own them a debt of gratitude. As to Chuckie - while although he does dance to a different drummer, he is still a staunch IBM employee. So, if the mandate is not to distribute the source code I sincerely doubt he will go against company policy. HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Scott Rohling Sent: Wednesday, March 18, 2009 4:15 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SCSIDISC SAMPEXEC on z/VM 5.4.0 That does seem odd.. I would think it would be supplied named as EXEC in that case.. I agree it implies a 'sample' when named SAMPEXEC .. which is only useful when the 'sample' is human readable so you can see what a good sample looks like ;-) Inconsistent to say the least, but I'm not aware of the reasons (if any) behind not releasing the source. Maybe Chuckie knows.. ? Scott On Wed, Mar 18, 2009 at 5:04 PM, Raymond Noal raymond.n...@hds.com wrote: Dear List Members: Just to save you some time and grief, I'm passing this along. We have just started using FCP devices for our Linux (SuSE Red Hat) virtual machines running under our z/VM 5.4.0 system. In order to verify our hardware configuration and our switch configurations, I was able to use the SCSIDISC SAMPEXEC program found on MAINT's 2CC mini disk. To my surprise, the SCSIDISC SAMPEXEC is not REXX source code, but instead it is compiled REXX. I requested a copy of the REXX source for SCSIDISC, but IBM will not release the source code. A dark day in VM-land, for sure. As I said, just an FYI. HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978
Re: SCSIDISC SAMPEXEC on z/VM 5.4.0
On Thu, Mar 19, 2009 at 1:22 AM, Raymond Noal raymond.n...@hds.com wrote: The response I received from IBM was the result of my opening an ETR on the subject. To protect the innocent, I did not mention the name of the IBM employee who works in the z/VM I/O Development group – if that’s of any use. To give them the benefit of the doubt, it might be that person was maybe confused about the reason for not sharing the source code with you. In some cases the source is owned by another organization (inside our outside IBM) who do not wish to disclose it. Or it may be written in a language that IBM does not expect you to read or write (although this one smells like compiled REXX code). Or maybe the person could not find it and did not read enough History of VM to understand how sensitive we are in this aspect. ;-) If you're willing to read another language, IIRC there's something similar with the s390-tools in Linux and that prolly ships with source. -Rob
