ADRDSSU and Linux volumes
Setting up DFSMS ADRDSSU utility under z/OS to backup and restore our z/VM and Linux volumes for Disaster Recovery. The samples I found have the required 'tracks' key word, what is confusing is the number in the tracks key word is the cylinder count. All the sample jcl I found are set up the same way, why is the cylinder used in the tracks keyword? Is this correct? Thanks Matt DUMP INDDNAME(IN1) - OUTDDNAME(OUTVOL1) TOL(IOER) OPTIMIZE(4) - ADMIN CPVOLUME TRACKS(0,0,10016,14) DUMP INDDNAME(IN2) - OUTDDNAME(OUTVOL2) TOL(IOER) OPTIMIZE(4) - ADMIN CPVOLUME TRACKS(0,0,10016,14) /* Thanks, Matt -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: ADRDSSU and Linux volumes
On Tuesday, 06/30/2015 at 08:58 EDT, Dazzo, Matt mda...@pch.com wrote: Setting up DFSMS ADRDSSU utility under z/OS to backup and restore our z/VM and Linux volumes for Disaster Recovery. The samples I found have the required 'tracks' key word, what is confusing is the number in the tracks key word is the cylinder count. All the sample jcl I found are set up the same way, why is the cylinder used in the tracks keyword? Is this correct? Thanks Matt DUMP INDDNAME(IN1) - OUTDDNAME(OUTVOL1) TOL(IOER) OPTIMIZE(4) - ADMIN CPVOLUME TRACKS(0,0,10016,14) DUMP INDDNAME(IN2) - OUTDDNAME(OUTVOL2) TOL(IOER) OPTIMIZE(4) - ADMIN CPVOLUME TRACKS(0,0,10016,14) A quick look at the syntax for ADRDSSU shows that TRACKS is required if you specify CPVOLUME. And the syntax for TRACKS shows that the specification is TRACKS(c1, h1, c2, h2). So it *is* correct (for a 3390-3). But further reading reveals that if you specify X'FFF' or 268435455 for c2, it will use the physical size of the dasd. I would be remiss if I didn't point out that the reason given in the book for requiring TRACKS is bogus, to wit: CPVOLUME specifies that the input volume is a VM-format volume and that the OS-compatible VTOC must begin on track zero, record five. You must specify the track range to be copied with the TRACKS keyword, as the OS-compatible VTOCs do not describe the extents of any data on the volume. The reason ADRDSSU requires TRACKS with CPVOLUME is because uh u I speculate the requirement to specify TRACKS is a relic of the days before we had self-describing DASD, and the MVS sysprogs of the world never bothered to nag DSFSMSdss to update ADRDSSU. Well, anyway, it would be a modest change to ADRDSSU to default TRACKS(0,0,268435455,14) if CPVOLUME is specified. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Disable DVHBIU3203W
Any way to disable this function. On a PROFILE DIRMAINT update that all our Linux guests have access to, it is taking a long time to complete. DVHBIU3203W Unable to notify ASYNCHRONOUS_UPDATE_NOTIFICATION_EXIT DVHBIU3203W recipient of directory update. Recipient is unreachable. Chris Will Systems Software (313) 549-9729 Cell cw...@bcbsm.com The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Disable DVHBIU3203W
Gotcha.. this sounds very much like this? http://www-01.ibm.com/support/docview.wss?uid=isg1VM65564 Are you running z/VM 6.3 ? And does this occur for guests which are not IPLed? Scott Rohling On Tue, Jun 30, 2015 at 8:10 AM, Will, Chris cw...@bcbsm.com wrote: We have a profile included in every Linux guest's DIRMAINT entry called LNXDFLT. When I make a change to LNXDFLT using DIRMAINT I assume this message is issued for every Linux guest that has this profile included. Problem is it takes 20 to 30 minutes to make an update for maybe 30 guests on this z/VM instance. Chris Will Systems Software (313) 549-9729 Cell cw...@bcbsm.com -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Scott Rohling Sent: Tuesday, June 30, 2015 11:00 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Disable DVHBIU3203W Could you give more information about what is being done? I'm not sure what you mean by a PROFILE DIRMAINT update... or why Linux guests would be doing anything at all with DIRMAINT... Scott Rohling On Tue, Jun 30, 2015 at 7:32 AM, Will, Chris cw...@bcbsm.com wrote: Any way to disable this function. On a PROFILE DIRMAINT update that all our Linux guests have access to, it is taking a long time to complete. DVHBIU3203W Unable to notify ASYNCHRONOUS_UPDATE_NOTIFICATION_EXIT DVHBIU3203W recipient of directory update. Recipient is unreachable. Chris Will Systems Software (313) 549-9729 Cell cw...@bcbsm.com The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Disable DVHBIU3203W
Could you give more information about what is being done? I'm not sure what you mean by a PROFILE DIRMAINT update... or why Linux guests would be doing anything at all with DIRMAINT... Scott Rohling On Tue, Jun 30, 2015 at 7:32 AM, Will, Chris cw...@bcbsm.com wrote: Any way to disable this function. On a PROFILE DIRMAINT update that all our Linux guests have access to, it is taking a long time to complete. DVHBIU3203W Unable to notify ASYNCHRONOUS_UPDATE_NOTIFICATION_EXIT DVHBIU3203W recipient of directory update. Recipient is unreachable. Chris Will Systems Software (313) 549-9729 Cell cw...@bcbsm.com The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Disable DVHBIU3203W
On Tuesday, 06/30/2015 at 10:33 EDT, Will, Chris cw...@bcbsm.com wrote: Any way to disable this function. On a PROFILE DIRMAINT update that all our Linux guests have access to, it is taking a long time to complete. DVHBIU3203W Unable to notify ASYNCHRONOUS_UPDATE_NOTIFICATION_EXIT DVHBIU3203W recipient of directory update. Recipient is unreachable. In the description of DVH3203W is the procedure to get rid of the message. But I think you need to resolve the real problem. Did you bring up SMAPI and then shut all or part of it back down again abnormally? DIRM FOR ALL SUBSCRIBE QUERY * * * Should show you what virtual machine(s) or network clients registered to receive updates. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Disable DVHBIU3203W
We have a profile included in every Linux guest's DIRMAINT entry called LNXDFLT. When I make a change to LNXDFLT using DIRMAINT I assume this message is issued for every Linux guest that has this profile included. Problem is it takes 20 to 30 minutes to make an update for maybe 30 guests on this z/VM instance. Chris Will Systems Software (313) 549-9729 Cell cw...@bcbsm.com -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Scott Rohling Sent: Tuesday, June 30, 2015 11:00 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Disable DVHBIU3203W Could you give more information about what is being done? I'm not sure what you mean by a PROFILE DIRMAINT update... or why Linux guests would be doing anything at all with DIRMAINT... Scott Rohling On Tue, Jun 30, 2015 at 7:32 AM, Will, Chris cw...@bcbsm.com wrote: Any way to disable this function. On a PROFILE DIRMAINT update that all our Linux guests have access to, it is taking a long time to complete. DVHBIU3203W Unable to notify ASYNCHRONOUS_UPDATE_NOTIFICATION_EXIT DVHBIU3203W recipient of directory update. Recipient is unreachable. Chris Will Systems Software (313) 549-9729 Cell cw...@bcbsm.com The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
A call to chair sessions at SHARE in Orlando
Hello All, Yes it is that time of year again the SHARE conference is in Orlando this year and we have a lot of every interesting session. We are looking for a few or lots of good people to help out and chair session. Below is the list of open sessions which we need someone to help out by chairing them. If you see one or more that you like please e - mail me at brian.ja...@ca.commailto:brian.ja...@ca.com the session number, session name, date and time. Session ID Session Title DayDate and Time People 17478 Introduction to Virtualization Mon 2015-08-10, 10:00:00 Romney White (Speaker) 17464 Linux for Beginners Hands-on Lab, Part 1 of 3 Mon 2015-08-10, 10:00:00 Neale Ferguson (Speaker) 17842 The Apathy Virus Mon 2015-08-10, 10:00:00 Christopher O'Malley (Speaker) 17465 Linux for Beginners Hands-on Lab, Part 2 of 3 Mon 2015-08-10, 11:15:00 Neale Ferguson (Speaker) 17516 z/VM Platform Update Mon 2015-08-10, 11:15:00 Bill Bitner (Speaker) 17466 Linux for Beginners Hands-on Lab, Part 3 of 3 Mon 2015-08-10, 12:30:00 Neale Ferguson (Speaker) 17274 CMS Shared File System Usage and Administration Mon 2015-08-10, 13:45:00 Dan Martin (Speaker) 17487 Hadoop and Data Integration with z Systems Mon 2015-08-10, 13:45:00 Cameron Seay (Speaker), Mike Combs (Speaker) 17357 z/VM Shared File System (SFS) Backup Methodology Mon 2015-08-10, 15:15:00 Gerard P. Howells (Speaker) 17479 SHARE Live!: The Mainframe: The Latest Disruptive Technology in Cloud Mon 2015-08-10, 15:15:00 Frank DeGilio, Distinguished, Engineer (Speaker) 17716 Running Docker applications on Linux on the Mainframe Mon 2015-08-10, 15:15:00 Robert (Jay) J. Brenneman (Speaker) 17471 z/VM For Beginners Hands-on Lab. Part 1 of 2 Mon 2015-08-10, 16:30:00 Richard Lewis (Speaker) 17510 Backing Up and Restoring z/VM and Linux Guests Mon 2015-08-10, 16:30:00 Tracy Dean (Speaker) 17484 What's New with SUSE Linux Enterprise Server for z Systems Mon 2015-08-10, 16:30:00 Ihno Krumreich (Speaker) 17480 z/VM for Beginners Hands-on Lab, Part 2 of 2 Mon 2015-08-10, 18:00:00 Richard Lewis (Speaker) 17472 Introduction to REXX Workshop (Part 1 of 2) (BYOC) Tue2015-08-11, 10:00:00 John Franciscovich (Speaker) 17473 Introduction to REXX Workshop (Part 2 of 2) (BYOC) Tue2015-08-11, 11:15:00 John Franciscovich (Speaker) 17481 A Gentle Introduction to z/VM System Installation for the Inexperienced Tue2015-08-11, 11:15:00 Dan Martin (Speaker) 17515 What's New in the z/VM 6.3 Hypervisor Tue2015-08-11, 13:45:00 John Franciscovich (Speaker) 17468 z/VM Installation or Migration or Upgrade Hands-on Lab, Part 1 of 3 Tue2015-08-11, 13:45:00 Richard Lewis (Speaker) 17772 Effectively Running IBM Cognos BI On Linux On z Systems In a z/VM Environment Tue2015-08-11, 13:45:00 Mario Held (Speaker) 17512 Ideas for Automating a z/VM System Using CA VM:Operator Tue2015-08-11, 13:45:00 Brian Jagos (Speaker) 17671 Mobile Security and Integration with the Mainframe Roundtable Tue2015-08-11, 15:15:00 Erich Amrehn (Speaker), Wilhelm Mild (Speaker) 17469 z/VM Installation or Migration or Upgrade Hands-on Lab, Part 2 of 3 Tue2015-08-11, 15:15:00 Richard Lewis (Speaker) 17508 Advanced z/VM Systems Management with IBM Wave for z/VM Tue2015-08-11, 15:15:00 Eduardo C. Oliveira, Tiger, Team, Lead (Speaker) 17470 z/VM Installation or Migration or Upgrade Hands-on Lab, Part 3 of 3 Tue2015-08-11, 16:30:00 Richard Lewis (Speaker) 17474
HYPERPAV problem RHEL6.5
I must be doing something wrong but I sure don't see it. Has anyone seen this behavior? Thanks Tom Devices dedicated in z/VM directory. DEDICATE B600 B600 DEDICATE B640 B640 DEDICATE B641 B641 DEDICATE B642 B642 DEDICATE B643 B643 From a class B user CP Q PAV Device B600 is a base HyperParallel Access Volume device in Pool 0 Device B640 is an alias HyperParallel Access Volume device in Pool 0 Device B641 is an alias HyperParallel Access Volume device in Pool 0 Device B642 is an alias HyperParallel Access Volume device in Pool 0 Device B643 is an alias HyperParallel Access Volume device in Pool 0 From the z/LINUX virtual machine CP Q V PAV HYPERPAV BASE B600 ON B600 0ZB600 POOL 0 HYPERPAV ALIAS B640 ON B640 POOL 0 HYPERPAV ALIAS B641 ON B641 POOL 0 HYPERPAV ALIAS B642 ON B642 POOL 0 HYPERPAV ALIAS B643 ON B643 POOL 0 Set them online to LINUX chccwdev -e b600,b640-b643 Setting device 0.0.b600 online dasd-eckd 0.0.b600: New DASD 3390/0E (CU 3990/01) with 262668 cylinders, 15 heads, 224 sectors dasd-eckd 0.0.b600: DASD with 4 KB/block, 189120960 KB total size, 48 KB/track, linux disk layout dasdb:(nonl) dasdb1 Done Setting device 0.0.b640 online dasd-eckd 0.0.b640: New DASD 3390/0A (CU 3990/01) with 0 cylinders, 0 heads, 0 sectors Done Setting device 0.0.b641 online dasd-eckd 0.0.b641: New DASD 3390/0A (CU 3990/01) with 0 cylinders, 0 heads, 0 sectors Done Setting device 0.0.b642 online dasd-eckd 0.0.b642: New DASD 3390/0A (CU 3990/01) with 0 cylinders, 0 heads, 0 sectors Done Setting device 0.0.b643 online dasd-eckd 0.0.b643: New DASD 3390/0A (CU 3990/01) with 0 cylinders, 0 heads, 0 sectors Done [root@tom128 ~]# As seen by LINUX OS. lsdasd Bus-ID Status Name Device Type BlkSz Size Blocks == 0.0.b640 active ??? : ECKD 0 0.0.b641 active ??? : ECKD 0 0.0.b642 active ??? : ECKD 0 0.0.b643 active ??? : ECKD 0 0.0.0100 active dasda 94:0ECKD 4096 7042MB 1802880 0.0.b600 n/f dasdb 94:4 ECKD [root@tom128 ~]# WHY DOESN'T LINUX SEE THE ALIAS VOLUMES? -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Disable DVHBIU3203W
I looked in the SUBSCRIB DATADVH and found an invalid entry (temp IP we use for building a z/VM system). SUBSCRIB DATADVH Z1 V 80 Trunc=80 Size=2 Line=0 Col=1 Alt=0 0 * * * Top of File * * * 1 INCLUDE ALL TCP 10.100.1.74 5 ASCII DATA 30440this entry 2 INCLUDE ALL TCP 10.100.1.91 5 ASCII DATA 86826 3 * * * End of File * * * It may be timing out on this for all the guests with the profile entry (about 30 or so). Chris Will -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Scott Rohling Sent: Tuesday, June 30, 2015 11:18 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Disable DVHBIU3203W Gotcha.. this sounds very much like this? http://www-01.ibm.com/support/docview.wss?uid=isg1VM65564 Are you running z/VM 6.3 ? And does this occur for guests which are not IPLed? Scott Rohling On Tue, Jun 30, 2015 at 8:10 AM, Will, Chris cw...@bcbsm.com wrote: We have a profile included in every Linux guest's DIRMAINT entry called LNXDFLT. When I make a change to LNXDFLT using DIRMAINT I assume this message is issued for every Linux guest that has this profile included. Problem is it takes 20 to 30 minutes to make an update for maybe 30 guests on this z/VM instance. Chris Will Systems Software (313) 549-9729 Cell cw...@bcbsm.com -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Scott Rohling Sent: Tuesday, June 30, 2015 11:00 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Disable DVHBIU3203W Could you give more information about what is being done? I'm not sure what you mean by a PROFILE DIRMAINT update... or why Linux guests would be doing anything at all with DIRMAINT... Scott Rohling On Tue, Jun 30, 2015 at 7:32 AM, Will, Chris cw...@bcbsm.com wrote: Any way to disable this function. On a PROFILE DIRMAINT update that all our Linux guests have access to, it is taking a long time to complete. DVHBIU3203W Unable to notify ASYNCHRONOUS_UPDATE_NOTIFICATION_EXIT DVHBIU3203W recipient of directory update. Recipient is unreachable. Chris Will Systems Software (313) 549-9729 Cell cw...@bcbsm.com The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ The information contained in this communication is highly
Re: Disable DVHBIU3203W
On Tuesday, 06/30/2015 at 01:20 EDT, Will, Chris cw...@bcbsm.com wrote: There have been no issues with SMAPI. Here are the results of the command. DIRM FOR ALL SUBSCRIBE QUERY * * * DVHXMT1191I Your SUBSCRIBE request has been sent for processing to DVHXMT1191I DIRMAINT at XSYS. Ready; T=0.01/0.01 13:12:43 DVHREQ2288I Your SUBSCRIBE request for ALL at * has been accepted. DVHSUB3712I Action TargetId Prot Destination1Dest-2 Chars DVHSUB3712I Subscriber Data DVHSUB3712I --- --- -- DVHSUB3712I DVHSUB3716W No matching subscription was found to query or delete. DVHREQ2289E Your SUBSCRIBE request for ALL at * has failed; with RC = DVHREQ2289E 3716. Then I would open a PMR, as I'm not sure how DIRMAINT would process a non-existent subscription. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: HYPERPAV problem RHEL6.5
On 6/30/2015 at 12:43 PM, Tom Huegel tehue...@gmail.com wrote: I must be doing something wrong but I sure don't see it. Has anyone seen this behavior? Does anything change after you dasdfmt the base volume? If not, then I would assume it's a bug in Linux. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Disable DVHBIU3203W
There have been no issues with SMAPI. Here are the results of the command. DIRM FOR ALL SUBSCRIBE QUERY * * * DVHXMT1191I Your SUBSCRIBE request has been sent for processing to DVHXMT1191I DIRMAINT at XSYS. Ready; T=0.01/0.01 13:12:43 DVHREQ2288I Your SUBSCRIBE request for ALL at * has been accepted. DVHSUB3712I Action TargetId Prot Destination1Dest-2 Chars DVHSUB3712I Subscriber Data DVHSUB3712I --- --- -- DVHSUB3712I DVHSUB3716W No matching subscription was found to query or delete. DVHREQ2289E Your SUBSCRIBE request for ALL at * has failed; with RC = DVHREQ2289E 3716. Chris Will -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan Altmark Sent: Tuesday, June 30, 2015 11:59 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: Disable DVHBIU3203W On Tuesday, 06/30/2015 at 10:33 EDT, Will, Chris cw...@bcbsm.com wrote: Any way to disable this function. On a PROFILE DIRMAINT update that all our Linux guests have access to, it is taking a long time to complete. DVHBIU3203W Unable to notify ASYNCHRONOUS_UPDATE_NOTIFICATION_EXIT DVHBIU3203W recipient of directory update. Recipient is unreachable. In the description of DVH3203W is the procedure to get rid of the message. But I think you need to resolve the real problem. Did you bring up SMAPI and then shut all or part of it back down again abnormally? DIRM FOR ALL SUBSCRIBE QUERY * * * Should show you what virtual machine(s) or network clients registered to receive updates. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: What might happen if our sles11 sp3 systems are not at the level to handle the leap second.
On 6/30/2015 at 04:02 PM, Ron Foster ron.fos...@baldor.abb.com wrote: Everyone, When our SLES11 SP3 maintenance package was put together, it was put together at the 3.0.101-0.40-default kernel instead of the kernel level that was current. According to to tid 7016150 this is vulnerable to bug 915335. Any ideas on what we might be letting ourselves in for? It could range from nothing at all to critical applications falling over. I think the last time things weren't patched right, some processes jumped to 100% CPU busy until they were restarted. The TIDs should also provide workarounds to avoid the problem if you're not at the right version of the software. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: What might happen if our sles11 sp3 systems are not at the level to handle the leap second.
On 6/30/2015 at 04:11 PM, Michael Weiner mwei...@infinite-blue.com wrote: Speaking to that, what about just having a website being hosted ? What about that? I don't know what you're asking. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: HYPERPAV problem RHEL6.5
I have done this 2 ways. For RH, I also update /etc/dasd.conf COMMAND DEF HYPERPAVALIAS 7EE0 FOR BASE 800 MDISK 800 3390 32760 LX7E10 MR READ WRITE MULT COMMAND DEF HYPERPAVALIAS 7EE0 FOR BASE 800 MDISK 800 3390 DEVNO 7E38 MR READ WRITE MULT Joe Joseph Vitale Technology Services Group Mainframe Operating Systems Pershing Plaza 95 Christopher Columbus Drive Floor 14 Jersey City, N.J. 07302 Work 201-395-1509 Cell917-903-0102 -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Tom Huegel Sent: Tuesday, June 30, 2015 12:44 PM To: LINUX-390@VM.MARIST.EDU Subject: HYPERPAV problem RHEL6.5 I must be doing something wrong but I sure don't see it. Has anyone seen this behavior? Thanks Tom Devices dedicated in z/VM directory. DEDICATE B600 B600 DEDICATE B640 B640 DEDICATE B641 B641 DEDICATE B642 B642 DEDICATE B643 B643 From a class B user CP Q PAV Device B600 is a base HyperParallel Access Volume device in Pool 0 Device B640 is an alias HyperParallel Access Volume device in Pool 0 Device B641 is an alias HyperParallel Access Volume device in Pool 0 Device B642 is an alias HyperParallel Access Volume device in Pool 0 Device B643 is an alias HyperParallel Access Volume device in Pool 0 From the z/LINUX virtual machine CP Q V PAV HYPERPAV BASE B600 ON B600 0ZB600 POOL 0 HYPERPAV ALIAS B640 ON B640 POOL 0 HYPERPAV ALIAS B641 ON B641 POOL 0 HYPERPAV ALIAS B642 ON B642 POOL 0 HYPERPAV ALIAS B643 ON B643 POOL 0 Set them online to LINUX chccwdev -e b600,b640-b643 Setting device 0.0.b600 online dasd-eckd 0.0.b600: New DASD 3390/0E (CU 3990/01) with 262668 cylinders, 15 heads, 224 sectors dasd-eckd 0.0.b600: DASD with 4 KB/block, 189120960 KB total size, 48 KB/track, linux disk layout dasdb:(nonl) dasdb1 Done Setting device 0.0.b640 online dasd-eckd 0.0.b640: New DASD 3390/0A (CU 3990/01) with 0 cylinders, 0 heads, 0 sectors Done Setting device 0.0.b641 online dasd-eckd 0.0.b641: New DASD 3390/0A (CU 3990/01) with 0 cylinders, 0 heads, 0 sectors Done Setting device 0.0.b642 online dasd-eckd 0.0.b642: New DASD 3390/0A (CU 3990/01) with 0 cylinders, 0 heads, 0 sectors Done Setting device 0.0.b643 online dasd-eckd 0.0.b643: New DASD 3390/0A (CU 3990/01) with 0 cylinders, 0 heads, 0 sectors Done [root@tom128 ~]# As seen by LINUX OS. lsdasd Bus-ID Status Name Device Type BlkSz Size Blocks == 0.0.b640 active ??? : ECKD 0 0.0.b641 active ??? : ECKD 0 0.0.b642 active ??? : ECKD 0 0.0.b643 active ??? : ECKD 0 0.0.0100 active dasda 94:0ECKD 4096 7042MB 1802880 0.0.b600 n/f dasdb 94:4 ECKD [root@tom128 ~]# WHY DOESN'T LINUX SEE THE ALIAS VOLUMES? -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. If you are not the intended recipient please return the e-mail to the sender and delete it from your computer. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses. Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures relating to European legal entities.
Re: HYPERPAV problem RHEL6.5
Thanks for the responses. My problem was with the sequence of events. I was doing dasdfmt of the base after attaching the devices (base and aliases). Then I thought just chccwdev -d and then chccwdev -e would be enough. What I needed to do was after dasdfmt to attach (detach first if necessary) the aliases. Then I see what I expected. lsdasd Bus-ID Status Name Device Type BlkSz Size Blocks == 0.0.b640 alias ECKD 0.0.b641 alias ECKD 0.0.b642 alias ECKD 0.0.b643 alias ECKD 0.0.0100 active dasda 94:0ECKD 4096 7042MB 1802880 0.0.b600 active dasdb 94:4ECKD 4096 184688MB 47280240 [root@tom128 ~]# dasd-eckd 0.0.b600: SIM - SRC: 62600280 On Tue, Jun 30, 2015 at 9:51 AM, Vitale, Joseph joseph.vit...@bnymellon.com wrote: I have done this 2 ways. For RH, I also update /etc/dasd.conf COMMAND DEF HYPERPAVALIAS 7EE0 FOR BASE 800 MDISK 800 3390 32760 LX7E10 MR READ WRITE MULT COMMAND DEF HYPERPAVALIAS 7EE0 FOR BASE 800 MDISK 800 3390 DEVNO 7E38 MR READ WRITE MULT Joe Joseph Vitale Technology Services Group Mainframe Operating Systems Pershing Plaza 95 Christopher Columbus Drive Floor 14 Jersey City, N.J. 07302 Work 201-395-1509 Cell917-903-0102 -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Tom Huegel Sent: Tuesday, June 30, 2015 12:44 PM To: LINUX-390@VM.MARIST.EDU Subject: HYPERPAV problem RHEL6.5 I must be doing something wrong but I sure don't see it. Has anyone seen this behavior? Thanks Tom Devices dedicated in z/VM directory. DEDICATE B600 B600 DEDICATE B640 B640 DEDICATE B641 B641 DEDICATE B642 B642 DEDICATE B643 B643 From a class B user CP Q PAV Device B600 is a base HyperParallel Access Volume device in Pool 0 Device B640 is an alias HyperParallel Access Volume device in Pool 0 Device B641 is an alias HyperParallel Access Volume device in Pool 0 Device B642 is an alias HyperParallel Access Volume device in Pool 0 Device B643 is an alias HyperParallel Access Volume device in Pool 0 From the z/LINUX virtual machine CP Q V PAV HYPERPAV BASE B600 ON B600 0ZB600 POOL 0 HYPERPAV ALIAS B640 ON B640 POOL 0 HYPERPAV ALIAS B641 ON B641 POOL 0 HYPERPAV ALIAS B642 ON B642 POOL 0 HYPERPAV ALIAS B643 ON B643 POOL 0 Set them online to LINUX chccwdev -e b600,b640-b643 Setting device 0.0.b600 online dasd-eckd 0.0.b600: New DASD 3390/0E (CU 3990/01) with 262668 cylinders, 15 heads, 224 sectors dasd-eckd 0.0.b600: DASD with 4 KB/block, 189120960 KB total size, 48 KB/track, linux disk layout dasdb:(nonl) dasdb1 Done Setting device 0.0.b640 online dasd-eckd 0.0.b640: New DASD 3390/0A (CU 3990/01) with 0 cylinders, 0 heads, 0 sectors Done Setting device 0.0.b641 online dasd-eckd 0.0.b641: New DASD 3390/0A (CU 3990/01) with 0 cylinders, 0 heads, 0 sectors Done Setting device 0.0.b642 online dasd-eckd 0.0.b642: New DASD 3390/0A (CU 3990/01) with 0 cylinders, 0 heads, 0 sectors Done Setting device 0.0.b643 online dasd-eckd 0.0.b643: New DASD 3390/0A (CU 3990/01) with 0 cylinders, 0 heads, 0 sectors Done [root@tom128 ~]# As seen by LINUX OS. lsdasd Bus-ID Status Name Device Type BlkSz Size Blocks == 0.0.b640 active ??? : ECKD 0 0.0.b641 active ??? : ECKD 0 0.0.b642 active ??? : ECKD 0 0.0.b643 active ??? : ECKD 0 0.0.0100 active dasda 94:0ECKD 4096 7042MB 1802880 0.0.b600 n/f dasdb 94:4 ECKD [root@tom128 ~]# WHY DOESN'T LINUX SEE THE ALIAS VOLUMES? -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. If you are not the intended recipient please return the e-mail to the sender and delete it from your computer. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses. Please refer to http://disclaimer.bnymellon.com/eu.htm for certain disclosures relating to European legal entities.
What might happen if our sles11 sp3 systems are not at the level to handle the leap second.
Everyone, When our SLES11 SP3 maintenance package was put together, it was put together at the 3.0.101-0.40-default kernel instead of the kernel level that was current. According to to tid 7016150 this is vulnerable to bug 915335. Any ideas on what we might be letting ourselves in for? Ron Ron Foster Baldor Electric Company 5711 R S Boreham Jr Street Fort Smith, AR 72901 Phone:479-648-5865 Fax:479-646-5440 Email: ron.fos...@baldor.abb.commailto:ron.fos...@baldor.abb.com IM Address:ron.fos...@baldor.abb.com www.baldor.comhttp://www.baldor.com/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: What might happen if our sles11 sp3 systems are not at the level to handle the leap second.
Speaking to that, what about just having a website being hosted ? On Jun 30, 2015 4:09 PM, Mark Post mp...@suse.com wrote: On 6/30/2015 at 04:02 PM, Ron Foster ron.fos...@baldor.abb.com wrote: Everyone, When our SLES11 SP3 maintenance package was put together, it was put together at the 3.0.101-0.40-default kernel instead of the kernel level that was current. According to to tid 7016150 this is vulnerable to bug 915335. Any ideas on what we might be letting ourselves in for? It could range from nothing at all to critical applications falling over. I think the last time things weren't patched right, some processes jumped to 100% CPU busy until they were restarted. The TIDs should also provide workarounds to avoid the problem if you're not at the right version of the software. Mark Post -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
