Re: VM/ESA 2.4 under z/VM 5.x
Hi Dan: Although you will have a great boost in performance power be careful about the performance expectations of your 3rd level VSE guests. Each time the VSE guest is dispatched you will be running a SIE under SIE (virtual machines are always dispatched in processing mode known as emulation mode - the instruction that places a CPU in emulation mode is Start Interpretive Execution). In long gone releases and hardware left by the curb this killed performance. Strides have been made in this area but a 3rd level production dispatch - better measure it carefully. I have not done this on z boxes - so it may be tolerable. Best of luck and let us on the list know how it goes. What type of CPU usage do you have today? David Kreuter Dan Andrada wrote: Thanks for the input everyone! We're looking at getting off our 9221 box running VM/ESA 2.4 and VSE/ESA 2.6.3. We have merely two VSE guest machines and just a handful of programmers that use CMS for developemnt purposes. No Linux, no productio n VM guest machines other than the VSE guests. In our shop, VM is merely a hyper-visor for our VSE guests. However, our programming staff does not want to lose the various EXEC's they use in CMS and XEDIT. We have a proposal to move to a z/890 processor to run z/VM and z/VSE to stay in support. To ease our migration, I would like to bring up VM/ESA 2.4 as a second-level guest along with one or both of the VSE guests unde r that, and progress from there. Even at the entry level configuration of a z/890, its processing capacity is easily twice that of our current 9221 utilization, so I don't think I need to be too concerned about processing overhead. I've asked IBM about this and I've not been given a definitive answer. Th e latest FAQ that IBM has provided on their z/VM site states that z/VM will run VSE/ESA and VM/ESA as guests. The Tell-All for me would be to find out if anyone has attempted or done this kind of migration. So with that said, if anyone has any further information or experience in doing a migration of this type, I would be very grateful for your input. Thanks again!
Re: NICDEF Question- a little courious is all
Title: RE: NICDEF Question- a little courious is all VSWITCHes are always protected, even with a NICDEF directory card. David -Original Message- From: VM/ESA and z/VM Discussions on behalf of Huegel, Thomas Sent: Tue 3/7/2006 11:59 AM To: VMESA-L@LISTSERV.UARK.EDU Subject: NICDEF Question- a little courious is all I used a NICDEF directory statement very similiar to the example below from the CP Planning and Admin guide. The VSWITCH is defined in the SYSTEM CONFIG file I do not have a MODIFY VSWITCH GRANT statement for this user. When the user logs on I get an error saying he is not authorized to couple to the VSWITCH. I know it is easy enough to fix that with the SET VSWITCH command, but I was under the impression that this was not necessary if the NICDEF was used in the directory (even without a MODIFY VSWITCH GRANT), as opposed to a DEFINE VSWITCH command. Did I miss something or are the old brain cells in need of a PTF or two? Define a simulated QDIO adapter using I/O devices 0500-0507 (eight devices) which will be coupled to the SYSTEM-owned INEWS LAN during LOGON processing: NICDEF 500 TYPE QDIO DEV 8 LAN SYSTEM INEWS __ ella for Spam Control has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com
Re: Vswitch problem on z/VM 5.2.0?
had a similar problem on 5.2. See if ptf UM31613 APAR VM63895 are on your system. It corrected our problem. David -Original Message- From: VM/ESA and z/VM Discussions on behalf of Brian Nielsen Sent: Mon 3/6/2006 3:17 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: Vswitch problem on z/VM 5.2.0? This weekend I upgraded from z/VM 4.4.0 to 5.2.0 and ran into an unexpected problem with connectivity through vswitches to the external = network. I'm trying to figure out if the problem is in my vswitch definitions or if it's a reportable issue. At the moment it appears that private IP address ranges (eg 192.168.xxx.xxx, 10.xxx.xxx.xxx, 172.16.64.xxx) which worked fine through= a vswitch in 4.4.0 do not work at all through a vswitch on 5.2.0. Private IP addresses in the same subnet, on the same VLAN, on the same = vswitch couldn't ping each other or their external gateway. The public I= P addresses on the same vswitch had no trouble pinging their external gateway. Private IP addresses with direct OSA conections had no problems= either. I was able to confirm it was a vswitch related problem through testing = with my z/VM TCPIP stack. Normally it has a dedicated OSA connection and= a private IP address of 172.16.64.3 on VLAN 7. On zVM 5.2 I was able to = PING its external gateway at 172.16.64.1. When I changed the TCPIP stack= s network connection from a dedicated OSA to a virtual NIC on the vswitch = the ping failed. My vswitch was defined in z/VM 4.4.0 with: DEFINE VSWITCH SWITCH02 RDEV 0500 F804 PORTNAME PT0500 PTF804 and in 5.2.0 with: DEFINE VSWITCH SWITCH02 RDEV 0500 F804 VLAN 7 PORTNAME PT0500 PTF804= For testing the TCPIP NIC on the vswitch it was authorized with: SET VSWITCH SWITCH02 GRANT TCPIPVLAN 7 In both cases, PROFILE TCPIP includes: LINK ETH0 QDIOETHERNET [EMAIL PROTECTED] VLAN 7 Changing TCPIP's GRANT to include PORTTYPE TRUNK, and verifying the chang= e with Q VSWITCH ALL DETAILS, had no effect. On the exact same switch, SWITCH02, other Linux guests on VLAN 2 with public IP addresses (eg 164.165.57.xxx) had no trouble communicating with= the network outside the z/890. They are authorized to the vswitch with: SET VSWITCH SWITCH02 GRANT userid VLAN 2 The problem also manifested itself on the other vswitch carrying traffic = on private IP addresses for other VLANs (3 and 4). Is there something I've overlooked in the changes to vswitches from 4.4.0= to 5.2.0? Or is this a reportable problem? Brian Nielsen P.S. The problem has been temporariliy circumvented by connecting the userids with priviate IP address on VLAN 7 to a guest LAN and using the = zVM TCPIP stack to route their traffic to the OSA. (Yuck, but it works.)=
Re: ZVM 5.2, Z890, and I/O
without any other workload analysis: 6g central 2g xstore. on a z/9 we have not experienced or noticed 2g i/o issues. David -Original Message- From: VM/ESA and z/VM Discussions on behalf of Hughes, Jim - OIT Sent: Mon 3/6/2006 4:23 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: ZVM 5.2, Z890, and I/O Is there a problem with ZVM 5.2 and a Z890 when doing I/O over the 2 gig line? We are probably getting a Z890 with 8 gig of main storage. Any suggestions for carving up the main storage(xstore, cache, etc.) ___ Jim Hughes 603-271-5586 Impossible is just an opinion.
Re: Another xstore question
You could try 6G central 2G Xstore. David Huegel, Thomas wrote: OK I agree that some XSTORE is desirable even with z/VM 5.2 and a z890 but how much? I have 8G of storage and was thinking about 128m for XSTORE .. does anyone have a guess or a rule of thumb as to how much XSTORE to allocate. Thanks Tom * ella for Spam Control * has removed *2571* VSE-List messages and set aside *1461* VM-List for me You can use it too - and it's FREE! www.ellaforspam.com http://www.ellaforspam.com No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.1/273 - Release Date: 02/03/2006
Re: How to PING through a secondary TCPIP stack?
If you want to make this known permanently you can use a combination of SYSTEM NETID, TCPIP DATA, and SET CPUID commands. TCPIP DATA: TCPIP: TCPIPUSERID TCPIP TCPIP1: TCPIPUSERID TCPIP1 TCPIP2: TCPIPUSERID TCPIP2 TCPIP3: TCPIPUSERID TCPIP3 SYSTEM NETID: : 22 TCPIP TCPIP 11 TCPIP1 TCPIP1 : From TCPMAINT: q cpuid CPUID = FF2220948000 Ready; T=0.01/0.01 11:46:03 netstat home VM TCP/IP Netstat Level 520 IPv4 Home address entries: Address Subnet Mask Link --- --- -- 172.27.96.174 255.255.255.0OSASERV IPv6 Home address entries: None ping 172.27.96.174 Ping level 520: Pinging host 172.27.96.174. Enter 'HX' followed by 'BEGIN' to interrupt. PING: Ping #1 response took 0.029 seconds. Successes so far 1. netstat home tcp tcpip1 VM TCP/IP Netstat Level 520 IPv4 Home address entries: Address Subnet Mask Link --- --- -- 192.168.150.1 255.255.255.0HIPER IPv6 Home address entries: None set cpuid 11 ping 192.168.150.1 Ping Level 520: Pinging host 192.168.150.1. Enter 'HX' followed by 'BEGIN' to interrupt. PING: Ping #1 response took 0.060 seconds. Successes so far 1. David Brian Nielsen wrote: I have brought up a second TCPIP stack (in userid TCPIPDR) to test a routing setup for DR. NETSTAT has the TCP option to send the command to the TCPIP stack of my choice, but I don't see a similar option for PING o r TRACERTE. The test network is isolated from the production network. How do I send the PING to my test network via the second TCPIP stack? Brian Nielsen
Re: vmfinfo ---
try VMFSETUP ZVM CPSFS David Little, Chris wrote: Yes, maint. yes, 4.4 And you answered my question. We are at RSU 0501. Thank you. Instead of begging for answers, I was trying to answer them myself while learning about the system. I executed Jim's recommendation for vmfsetup zvm cp and received the following. Which answers some questions and raises the following vmfsetup zvm cp VMFSET2760I VMFSETUP processing started for ZVM CP DMSACP113S E(2C4) not attached or invalid device address VMFSET1905E The access of 2C4 failed with a return code of 100. DMSACP113S F(2C2) not attached or invalid device address VMFSET1905E The access of 2C2 failed with a return code of 100. DMSACP113S G(2A6) not attached or invalid device address VMFSET1905E The access of 2A6 failed with a return code of 100. DMSACP113S H(2A4) not attached or invalid device address VMFSET1905E The access of 2A4 failed with a return code of 100. DMSACP113S I(2A2) not attached or invalid device address VMFSET1905E The access of 2A2 failed with a return code of 100. DMSACP113S J(2D2) not attached or invalid device address VMFSET1905E The access of 2D2 failed with a return code of 100. DMSACP113S O(194) not attached or invalid device address VMFSET1905E The access of 194 failed with a return code of 100. VMFSET2760I VMFSETUP processing completed unsuccessfully Ready(00012); T=0.06/0.07 15:02:31 -Original Message- From: Mike Walter [mailto:[EMAIL PROTECTED] Sent: Friday, February 24, 2006 2:58 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: vmfinfo --- Chris, Are you executing VMFINFO from MAINT? From the missing file identifier, it appears that you are running z/VM 4.4.0 - it that actually true (when something isn't going right, always include basic questions)? That APAR VM63405 resulted in z/VM 440 PTF: UM31122, which was included on RSU 0403. What RSU level are you running. Alternatively, you could look in the CPLOAD MAP for VM36405 , it hit: MODULES/MACROS: CHPIDHCPCCS HCPCSCBK HCPHCD HCPIOX HCPMES HCPMESA HCPMESB HCPMESE HCPOCO HCPOM1 HCPPOCO HCPQPS HCPRPHCPSYSCM HCPYCAD HCPYCPD HCPZSI Nut you really should determine why VMFINFO is not getting the results you expect. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. Little, Chris [EMAIL PROTECTED] Sent by: VM/ESA and z/VM Discussions VMESA-L@LISTSERV.UARK.EDU 02/24/2006 02:47 PM Please respond to VM/ESA and z/VM Discussions VMESA-L@LISTSERV.UARK.EDU To VMESA-L@LISTSERV.UARK.EDU cc Subject Re: vmfinfo --- great . . . . : VMFINFO Main Panel Select one of the following. Then press enter. PPF fileid .. ZVM PPF D Component name .. CP Setup ... YES Product ID .: 4VMVMB40 System .. VM Options: S - select Option Query Product description Product status Product requisites Product dependencies PTFs/APARs Serviceable parts/usable forms Miscellaneous VMFINF2239I Setup did not complete successfully. Query results may be invalid Command === -Original Message- From: Jim Vincent [mailto:[EMAIL PROTECTED] Sent: Friday, February 24, 2006 2:38 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: vmfinfo --- The default for VMFINFO is to NOT set up the disk accesses for the component. Try this: VMFINFO ZVM CP (SETUP and then try your lookup again. If that too fails, then you have a key VMSES file M.I.A. - I presume you have backups? ;-) ___ James Vincent Systems Engineering Consultant Nationwide Services Co., Technology Infrastructure Engineering Mainframe, z/VM and z/Linux Support One Nationwide Plaza 3-25-02 Columbus OH 43215-2220 U.S.A Voice: (614) 249-5547Fax: (614) 677-7681 mailto:[EMAIL PROTECTED] VM/ESA and z/VM Discussions VMESA-L@LISTSERV.UARK.EDU wrote on 02/24/2006 03:33:52 PM: VMESA-L@LISTSERV.UARK.EDU For the most part I'm a linux, not VM geek, so I'm still trying to find my way around. I want to see the status of an APAR so I'm using VMFINFO, but I get the error : VMFINF2233I Table 4VMVMB40 SRVREQT not found. Query cancelled Any ideas? PTF/APAR Queries Enter a PTF or APAR number and type an option code. Then press Enter. PPF fileid .. ZVM PPF D Component name .. CP Setup ... NO Product ID .: 4VMVMB40 System .. VM PTF number .. APAR number . VM63405 Options: S - select Option Query Status of PTF Requisites/supersedes of PTF Dependencies/superseding of
Sad news
It with deep sadness that I am letting listers know that Roger Clarke died suddenly this week. Roger was a long time member of the Canada VM Users Group, and participated in the Midwest VM Regional Users Group. Roger assisted me at VM RESOURCES LTD. many times over the years. He amiably and with talent served our clients. For those in the Toronto area funeral and visitation information can be obtained from the Neweduk Funeral Home, 1981 Dundas Street West, Mississauga. 905 828 8000. Google will point you at a few WEB pages for Neweduk. Roger was 52 years old. He will be missed. David Kreuter
Re: storage given to ZOS guests
Duane: It depends (sic) on what your expectations are concerning storage residency. Prior to z/VM 5.2 you can use preferred guest storage (V=R or V=F) whereby all the storage of 1 or more z/os guests can be permanently assigned in memory. At this point it a counting calculation game for your z/OS guests. CP will happily page non-preferred guest memory of any virtual machine. In z/VM 5.2 preferred guest storage is not available. You can LOCK the pages of your z/OS guest; you'll have to know which pages to lock! You can try and lock all. Locking all pages of machines guarantees those pages are always in memory. Page locking does not have the same benefits of preferred storage. Preferred guest support (of which storage is part of) provides extensive I/O benefits as well. Or you can let CP happily page memory for all machines including your z/OS machines then decide on your course of actions based on response time or lack thereof. Over time LRU pages will be moved out of main memory including those for the z/OS guests. David -Original Message- From: VM/ESA and z/VM Discussions on behalf of Duane Weaver Sent: Mon 2/6/2006 3:49 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: storage given to ZOS guests I have a VM system that is going to host 2-3 ZOS guest systems running at the same time. The z/VM system is running the default service machines, including TCPIP and FTPSERVE. The VM system itself has a total of 3152m of storage. How does one determine how much storage can be given to one or more zOS guests? Duane Ohio State U.
Re: Need to move 510SPL and 510PAG from mod 3 to mod 9
in the sad event that you come up CLEAN and your SPXTAPE backup isn't good, you can build CMS and SES/E maintained segments with zero or minor struggle using a combo similar to: (from MAINT): (MAINT should IPL 190 - if not do it manually -) vmfsetup zvm cms sampnss cms i 190 cl parm savesys cms vmfbld ppf segbld esasegs segblist ( all I just did this (again) on a 2nd level test system that I IPL'ed CLEAN NOAUTO. David - From: VM/ESA and z/VM Discussions on behalf of Wolfe, Gordon W Sent: Thu 1/19/2006 3:49 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: Need to move 510SPL and 510PAG from mod 3 to mod 9 The SPXTAPE utility will save your NSS and DCSS files to tape. YOu can restore them after the upgrade. Good. Fast. Cheap. Pick any two. - David Gerrold, A Matter for Men Gordon Wolfe, Ph.D. (425)865-5940 VM Technical Services, The Boeing Company -- From: Rob van der Heij Reply To: VM/ESA and z/VM Discussions Sent: Thursday, January 19, 2006 12:37 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: Need to move 510SPL and 510PAG from mod 3 to mod 9 On 1/19/06, Anne Crabtree [EMAIL PROTECTED] wrote: What if I don't care about whats on spool? Can I just take VM down, relabel new packs(mod 9) as 510SPL and 510PAG and then IPL? (relabelling old ones first) You *do* care because your NSS files are there too... but I fail to see why you could not format the pack and then in stand-alone ddr the old spool pack to the first third of the new pack and allocate the remainder as spool again, provided you stick it back in the same position in the cpown list. -- Rob van der Heij rvdheij @ gmail.com Velocity Software, Inc
Re: TCPIP stacks
I've had the same discussions with networking groups at different clients. One thing for sure: networking procedures and plans remain opaque to me. Anway after months of discussion one client's network group has agreed to go with a vswitch solution. They are massively happy with it. Redundancy is provided through trunked real switches attaching to two different osa features. The tcpip vswitch machines have multiple sets of devices. Works brilliantly! Next big play I have in store is to go vlan big time. The current network architecture is just stepping up to vlan. Vlan would save the client a whole bunch of OSA devices. Probably take 'bout a year. Keep at it as it all we can do! David PS. also like to do some in board firewalling - may have an IFL ready just for fw'ing! But that's another story Michael Coffin wrote: Hi David, Yes, that's correct (i.e. no VIPA). All of the TCPIP subsystems are on the same network, no VSWITCH, VIPA or automatic-failover between them. I wanted to use VIPA, but let's just say the people that own the network at this site weren't getting it. They had a LOT of trouble understanding how our Linux/390 guests could have no real NICs with MACs, cables, proxy-arping, and the like - or the fact that we had multiple TCPIP servers all running on the same physical piece of hardware. I was lucky to get reserved IP addresses for my TCPIP's and Linux/390's - had to create some MAC addresses for the Linux/390 guests just so they'd have something to put on their request form. :) I spent months trying to get the network resources I needed to deploy VIPA - but finally gave up. Maybe one of these days I'll revisit it - but it was mighty painful the first time around. :) PS: We use a BusTech NetShuttle with 3 GigE paths, 2 100mbps paths (primarily for backup and development only) all over one ESCON connection to our MP3000. One GigE is dedicated to a TCPIP server used strictly for Linux/390 traffic, the other 2 GigE's are dedicated to the primary TCPIP server for interactive CMS use (along with supported services like printing, spooling, file transfer/FTP, etc., etc.). Michael Coffin, President MC Consulting Company, Inc. PMB 123 289 Park Street Stoughton, Massachusetts 02072 Voice: (781) 344-9837FAX: (781) 344-7683 [EMAIL PROTECTED] www.mccci.com We employ aggressive SPAM filters. If you cannot reply or send email to mccci.com go to www.mccci.com/spamblockremove.php -Original Message- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Wednesday, January 04, 2006 10:43 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: TCPIP stacks Hi Mike: By backup, you mean the stacks all connect on the same networks but are not providing hot backup through VIPA or VSWITCH solutions, right? So that TCPIPA et al doesn't route to TCPIPB et al? David -Original Message- From: VM/ESA and z/VM Discussions on behalf of Michael Coffin Sent: Wed 1/4/2006 1:26 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: TCPIP stacks FWIW - I use an entirely separate second TCPIP Subsystem, complete with it's own TCPIP server. So I've got TCPIP (my primary TCPIP subsystem with it's stack), TCIPIPA and TCPIPB - all running completely independent of one another, all with their own hardware, IP addressing and service virtual machines (i.e. TCPIPA has ROUTEDA, NAMEDA; TCPIPB has ROUTEDB, NAMEDB, etc. etc.). Not only can I bounce the target TCPIP virtual machine without it impacting other TCPIP subsystems, but if one fails entirely - I have the others as backup. This is particularly helpful when, for example, you need to bounce your primary TCPIP virtual machine and are at a remote location - just connect using TCPIPA or TCPIPB so that your TN3270 session won't disappear when the primary TCPIP virtual machine is taken down. Not a lot of work IMHO. :) Michael Coffin, President MC Consulting Company, Inc. PMB 123 289 Park Street Stoughton, Massachusetts 02072 Voice: (781) 344-9837FAX: (781) 344-7683 [EMAIL PROTECTED] www.mccci.com We employ aggressive SPAM filters. If you cannot reply or send email to mccci.com go to www.mccci.com/spamblockremove.php -Original Message- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Wednesday, January 04, 2006 1:08 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: TCPIP stacks I use a second stack on both sides of a z890 for TELNET and some specialized services across a HiperSocket. It took about 30 minutes to make the necessary updates to the appropriate DTCPARMS and to create the directory entries. Creating the full suite of application servers to go with a second stack would be much more work and I would not want to do it without a great deal of justification. /Tom Kern /301-903-2211
Re: TCPIP stacks
Hi Mike: By backup, you mean the stacks all connect on the same networks but are not providing hot backup through VIPA or VSWITCH solutions, right? So that TCPIPA et al doesn't route to TCPIPB et al? David -Original Message- From: VM/ESA and z/VM Discussions on behalf of Michael Coffin Sent: Wed 1/4/2006 1:26 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: TCPIP stacks FWIW - I use an entirely separate second TCPIP Subsystem, complete with it's own TCPIP server. So I've got TCPIP (my primary TCPIP subsystem with it's stack), TCIPIPA and TCPIPB - all running completely independent of one another, all with their own hardware, IP addressing and service virtual machines (i.e. TCPIPA has ROUTEDA, NAMEDA; TCPIPB has ROUTEDB, NAMEDB, etc. etc.). Not only can I bounce the target TCPIP virtual machine without it impacting other TCPIP subsystems, but if one fails entirely - I have the others as backup. This is particularly helpful when, for example, you need to bounce your primary TCPIP virtual machine and are at a remote location - just connect using TCPIPA or TCPIPB so that your TN3270 session won't disappear when the primary TCPIP virtual machine is taken down. Not a lot of work IMHO. :) Michael Coffin, President MC Consulting Company, Inc. PMB 123 289 Park Street Stoughton, Massachusetts 02072 Voice: (781) 344-9837FAX: (781) 344-7683 [EMAIL PROTECTED] www.mccci.com We employ aggressive SPAM filters. If you cannot reply or send email to mccci.com go to www.mccci.com/spamblockremove.php -Original Message- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Wednesday, January 04, 2006 1:08 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: TCPIP stacks I use a second stack on both sides of a z890 for TELNET and some specialized services across a HiperSocket. It took about 30 minutes to make the necessary updates to the appropriate DTCPARMS and to create the directory entries. Creating the full suite of application servers to go with a second stack would be much more work and I would not want to do it without a great deal of justification. /Tom Kern /301-903-2211
Re: REXX Syntax
Very interesting. I believe that EXTRACT is using the dot as a delimiter. I can't get it to fail. David Schuh, Richard wrote: I was browsing an XEDIT macro written in REXX and noticed a statement that looked like this: 'EXTRACT some values to extract'/* A COMMENT */ . The period appears to be an accident caused by its being to the right of the display when the statement was edited. For some reason, the period following the comment is not flagged as a syntax error. The EXTRACT works as an error free statement. If I compile the macro, the compiler also passes the statement without error. Replacing the period with a question mark or any other special character that I have tried does cause an error. Is this working properly? Is there something in the specification that makes the period a legitimate part of the syntax?
Re: REXX Syntax
REXX is as happy as EXTRACT. Here's a QD GG XEDIT: /**/ trace c 'EXTRACT' ? 'EXTRACT ' /* comment */ . 'EXTRACT ' /* comment */ ? 'EXTRACT /FTYPE/' /* comment */ . 'EXTRACT /FTYPE/' /* comment */ ? 'EXTRACT ' ?FTYPE? 'EXTRACT ' .FTYPE. When GG is invoked from XEDIT session: 3 *-* 'EXTRACT' ? EXTRACT ? 4 *-* 'EXTRACT ' /* comment */ . EXTRACT . 5 *-* 'EXTRACT ' /* comment */ ? EXTRACT ? 6 *-* 'EXTRACT /FTYPE/' /* comment */ . EXTRACT /FTYPE/ . +++ RC(5) +++ 7 *-* 'EXTRACT /FTYPE/' /* comment */ ? EXTRACT /FTYPE/ ? +++ RC(5) +++ 8 *-* 'EXTRACT ' ?FTYPE? EXTRACT ?FTYPE? 9 *-* 'EXTRACT ' .FTYPE. EXTRACT .FTYPE. Schuh, Richard wrote: EXTRACT should never see the light of day unless this is correct REXX syntax. So far I have found nothing to suggest that it is correct syntax, but I may be missing something. Try substituting some other character for the period and the syntax check does fail. It is the REXX that is in question, not the EXTRACT. -Original Message- From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On Behalf Of Brian Nielsen Sent: Tuesday, November 22, 2005 9:23 AM To: VMESA-L@LISTSERV.UARK.EDU Subject:Re: REXX Syntax On Tue, 22 Nov 2005 09:01:42 -0800, Schuh, Richard [EMAIL PROTECTED] wrote: I was browsing an XEDIT macro written in REXX and noticed a statement that looked like this: 'EXTRACT some values to extract'/* A COMMENT */ . The period appears to be an accident caused by its being to the right of the display when the statement was edited. For some reason, the period following the comment is not flagged as a syntax error. The EXTRACT works as an error free statement. If I compile the macro, the compiler also passes the statement without error. Replacing the period with a question mark or any other special character that I have tried does cause an error. Is this working properly? Is there something in the specification that makes the period a legitimate part of the syntax? When you do this EXTRACT is actually getting a RC=5 to flag the incorrect argument. Arguments before the incorrect argument are processed, those after it are not. EXTRACT.1 will be set to the invalid string. See usage note 2 for the EXTRACT command. Brian Nielsen
Re: Compare TXTLIB
Title: RE: Compare TXTLIB CMAP was/is a great tool. It trapped SVC 202/204 as Mike has said. I don't think it trapped entries from the loader table. You can setup CP TRACEs to trap branches into loader table address. Elaborate setup and dim the lights on your box - but you will see what is getting called. Another approach which reveals wonderful data is to do establish branch tracing using virtual per. Again it can dim the lights but you can match up loader entries with branches. Not for the faint of heart and only useful in 1 or few virtual machines. Beware of performance degradation. David -Original Message- From: VM/ESA and z/VM Discussions on behalf of Michael Coffin Sent: Thu 11/17/2005 1:26 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: Compare TXTLIB CMAP has the ability to intercept ANY SVC202, very powerful, very cool! I hope they are still marketing it, I'm actually looking for that capability right now. Michael Coffin, President MC Consulting Company, Inc. PMB 123 289 Park Street Stoughton, Massachusetts 02072 Voice: (781) 344-9837 FAX: (781) 344-7683 [EMAIL PROTECTED] www.mccci.com We employ aggressive SPAM filters. If you cannot reply or send email to mccci.com go to www.mccci.com/spamblockremove.php -Original Message- From: VM/ESA and z/VM Discussions [mailto:VMESA-L@LISTSERV.UARK.EDU] On Behalf Of David Boyes Sent: Thursday, November 17, 2005 12:22 PM To: VMESA-L@LISTSERV.UARK.EDU Subject: Re: Compare TXTLIB Unless I misunderstand the thought behind I think CMAP (a commercial product) used to do this sort of thing, but VM/ESA is no longer supported by most ISVs, so I doubt it is still available. CMAP/XA is indeed still available. It's now marketed (barely) and supported by Macro4 - it's not easy to find on their web site, look at: http://www.macro4.com/support/productlevels/vm-esa/cmap.html Yeah, it's still out there. The question is whether MACRO4 still supports it on VM/ESA. The other open question is whether there is a budget for commercial products (sounds like there isn't). But even so, I don't *think* it addresses the questions asked here. Basically we use it to tell who is executing which monitored commands. But it may do more than we ask of it. It *used* to have a way of tracking the use of the LOAD and GENMOD commands, and which modules were included during the search, but my memory of those days is getting blurry.
Re: Display userid on Ready message
I'm happily using the A3 solution for the write of the new message repository all over the place. One gotcha is you need a writable A disk! So any servers with r/o 191s will not benefit from this solution. David -Original Message- From: VM/ESA and z/VM Discussions on behalf of Bob Forward Sent: Thu 11/3/2005 10:38 AM To: VMESA-L@LISTSERV.UARK.EDU Subject: Display userid on Ready message Is there a command or EXEC that will allow you to modify the CMS ready message to include other things on it, like the userid or the current date? For example, now the message displays Ready; T=1.58/1.67 09:17:05 -- can I tailor it to display userid Ready; T=1.58/1.67 current date 09:17:05?
Re: DASD map tool?
I agree that a 1 cylinder scan is quite useful. I've used it myself. There are times though where a successful CMS access could be misleading. Any disk that was recomped such as the 190 will return incorrect results. It is also possible that a minidisk that has been deleted will still show up with its cylidner 1 intact potentially pointing at garbage. Just be aware of this and a DISCOVER tool is still quite effective. David Bill Stephens wrote: I'm assuming, from your question, that you do not have a directory that maps your volume. I've developed a tool for use during disaster recovery exercises called DISCOVER. If you do not have a directory map of your volume, you can run DISCOVER to at least learn where your minidisks are. Then, by using the output from ICKDSF, which will show you the system areas of the pack, you can get a pretty good idea of what's where, without a directory. If you want, I'll send you the tool. In principle, all it does is use CP DEFINE MDISK to define a 1 cylinder MDISK at progressively higher cylinder numbers, trying to CMS ACCESS that minidisk. If it works, the results from QUERY MDISK will tell how big CMS thinks the minidisk is supposed to be, and DISCOVER then appends this information to a map file, the information being the CMS volser, the starting cylinder, and the size of the minidisk. DISCOVER also has the option to redefine the minidisk at its correct size so it can be used. Handy if you need to discover where MAINT 190 or the parm disks are ... It is interesting how often I've had to use this tool after it was built - in one case someone had to recover data from backups of a defunct VM system, and although you could restore the tapes (they were DDR), there was no directory that said where the minidisks were. Were it not for DISCOVER, I couldn't have helped them. Regards, Bill Stephens Sr. Technology Analyst, High Availability SunGard Availability Services 10th floor 401 North Broad Street Philadelphia, PA 19108 Phone: (215) 351-1099 Fax: (215) 451-2045 [EMAIL PROTECTED]
Re: DASD map tool?
IEBIBALL only works in z/OS. We use VMFIBALL. David Bill Stephens wrote: Dave Kreuter wrote I agree that a 1 cylinder scan is quite useful. I've used it myself. There are times though where a successful CMS access could be misleading. Any disk that was recomped such as the 190 will return incorrect results. It is also possible that a minidisk that has been deleted will still show up with its cylidner 1 intact potentially pointing at garbage. Just be aware of this and a DISCOVER tool is still quite effective.. This is quite correct. Usually, there will be a gap evident in the map file following the 190 disk, which +may+ give you a clue as to the correct size of the 190 mdisk (e.g., if in the directory, the 190 minidisk is immediately followed by another minidisk, then the ACCESS reported size plus the gap size is the true size). But that's only if there is no actual gap between 190 and the next minidisk in the directory. Another issue that DISCOVER can't detect is when disks get overlaid. Consider: 1)user A has a minidisk allocated at cylinder 100 for 10 cylinders 2)user B has a minidisk allocated at cylinder 105 for 4 cylinders (never mind how or why) In this case, DISCOVER will report that there is a minidisk at cylinder 100 for 10 cylinders, and another minidisk at cylinder 105 for 4 cylinders. That's why the best use of DISCOVER is in conjunction with IEBIBALL. Regards, Bill Stephens Sr. Technology Analyst, High Availability SunGard Availability Services 10th floor 401 North Broad Street Philadelphia, PA 19108 Phone: (215) 351-1099 Fax: (215) 451-2045 [EMAIL PROTECTED]
Re: DASD map tool?
Without DIRMAINT from MAINT with access to the soruce directory: DISKMAP fn of source directory file With DIRMAINT: From MAINT: DIRM DIRMAP David Clark, Carl wrote: VM enthusiasts: Thanks for all the answers about saving CMS for the 2nd Level system. Now a different issue has arisen. How may I determine exactly which minidisks are on a particular real DASD volume? q 5629 DASD 5629 CP OWNED 510RES 109 Ready; T=0.01/0.01 15:30:31 I understand that many minidisks are defined to this volume, is there a tool that will map all the mdisks for a particular volume? Your help is appreciated, Carl Clark BCBST Please see the following link for the BlueCross BlueShield of Tennessee E-mail disclaimer: http://www.bcbst.com/email_disclaimer.shtm No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.361 / Virus Database: 267.12.5/150 - Release Date: 27/10/2005
Re: Monitoring VSwitch
Tom: You need a minimum of one VM TCPIP controller machine. The controller machine manages the vswitch for availability. The real devices are attached to the controller at vswitch creation or recovery to an available controller. The controller does not have DEVICE/LINK statements, it does not run it as IP adapter. If you want a VM TCPIP stack to use the vswitch as an IP adaptor you need to give it a NICDEF and couple it over to the vswitch guest lan (sorry Alan for calling it a vswitch guest lan). So you would then have two VM TCPIP stacks, one as a controller, and the other as a user of the vswitch. Bytes in/out come from a NETSTAT DEVLINK pointing at the name of tcpip controller: netstat devlink tcp tcpiplz VM TCP/IP Netstat Level 510 Device VSWITCHDEV Type: VSWITCH-IUCV Status: Connected Queue size: 0 CPU: 0 IUCVid: *VSWITCH Priority: B Link VSWITCHLINK Type: IUCV Net number: 1 BytesIn: 790 BytesOut: 924 or from asking the tcpip stack using an adapter on the guest lan: netstat devlink tcp tcpiply VM TCP/IP Netstat Level 510 Device [EMAIL PROTECTED]Type: OSDStatus: Ready Queue size: 0 CPU: 0 Address: 0800Port name: UNASSIGNED IPv4 Router Type: NonRouter Arp Query Support: Yes Link OSASERV Type: QDIOETHERNET Net number: 0 BytesIn: 427469 BytesOut: 0 Forwarding: Enabled MTU: 1500IPv6: Disabled Broadcast Capability: Yes Multicast Capability: Yes Group Members - --- 224.0.0.1 1 David Tom Duerbusch wrote: I have vswitch running over on the IFL lpar. Still only testing. Great...neat... I connected to it via VM's TCP/IP stack. I've connected to it via 64 bit SLES9. Seems to all work. But now that traffic isn't being routed via the VM TCP/IP stack, the information that I was getting from NETSTAT, just isn't there anymore. I use to be able to see what was connected to me. I use to be able to see the byte count of data that was sent (netstat dev). Just kind of wondering how I can tell when it is being used and what kind of and amount of activity that is on it. Thanks Tom Duerbusch THD Consulting
