Error : DMSITS135S Maximum SVC depth 200 has been exceeded
Hi, We are running VMSERVE, the application server/scheduler on a z/VM CP/CMS system. Recently, it started giving this error every time we make a progr am run through VMSERVE. I am not very experienced in z/VM so any help is appreciated! System : z/VM Version 5 Release 2.0, Service Level 0801 (64-bit) WWVM ESA CMS 15 012 VMSERVE starts fine but as soon as it runs a program, VMSERVE crashes and ends with this error, DMSITS135S Maximum SVC depth 200 has been exceeded. DMSITS135S Maximum SVC depth 200 has been exceeded. It probably means : The CMS system does not allow the nesting level of SV Cs to exceed ''. But not sure what can be done to fix this. Regards, Amar
Re: SFS problem
Mike, Yes, I checked out the message. The thing is, the job runs nightly, and only fails intermittently. There is no reason to believe that the authority to access the directory is changing during that time period; there are only 2 people who regularly grant permissions to that user's directory. Neither of us has made a change. Nora Graves nora.e.gra...@irs.gov Main IRS, Room 6531 (202) 622-6735 Fax (202) 622-3123 SE:W:CAR:MP:D:KS:BRSI -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Mike Walter Sent: Thursday, April 14, 2011 4:13 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS problem Nora, Did you issue: HELP DMSOPN1258E The response from the msg indicates an SFS authorization problem.: ---snip--- (c) Copyright IBM Corporation 1990, 2008 DMS1258E You are not authorized|Not authorized|Not permitted to write (to) file fn ft fm|pathname Explanation: You attempted to write to a file for which you do not have write authority, or you attempted to create a new file in a directory for which you do not have write authority. System Action: RC=12 or 28. Execution of the command is terminated. User Response: Ensure that you specified the correct file. If so, contact the owner to gain proper authorization to the file or directory. If the file specified is an alias, you may enter the QUERY ALIAS command to determine the owner of the base file. For a BFS file, enter the OPENVM LISTFILE command with the OWNER option for the file. This will tell you the owning user ID and group name for the file you wish to use. Refer to the z/VM: OpenExtensions Command Reference or enter HELP OPENVM for more information on the OPENVM commands. ---snip--- z/VM has a terrific HELP facility (including most messages), it's worth investing a bit of time to familiarize yourself with it. Were you using the VMLINK command in every case with the (FORCERW option? Regardless, check the syntax for your SFS authorizations. And if all those bazillion intricate SFS authorizations become overwhelming, consider checking out SafeSFS from safesfs.com. We're vary satisfied customers, it makes authorizations much MUCH simpler, saves huge amounts of effort and back time. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. Graves Nora E nora.e.gra...@irs.gov Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 04/14/2011 02:45 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject SFS problem We are having an intermittent problem with SFS and I'm hoping someone may have some ideas of what to pursue next. We have several batch jobs that run under VMBATCH overnight. Sometimes they are not able to create a file in a directory, even though most times it is successful. The only differences in the executions are the file names; for many of these the File Type is the date. In the job I am most familiar with, these are the specifics. The job runs Monday-Saturday. This year, it has failed on January 4, January 12, February 9, March 18, March 25, and April 13. It has run successfully the other days. Other than the QUERY statements below, it has not changed. The job runs in a work machine, WORK7. The job is submitted by the User ID of the database owner. The SFS directories are owned by a 3rd user. Failures occur in many of the subdirectories, not just one subdirectory owned by this user. This user is the owner of most of the directories containing the data files we create in batch, so I don't think it's significant that it's the ID that has the problem. However, as far as I know, it is the only ID that does have the problem. This job uses VMLINK to acquire a write link to SFS directory. This always looks to be successful--no error is given. (Other jobs use GETFMADDR and ACCESS to acquire the write link to the directory. This always appears successful as well). Once the file is ready to be copied from the Work Machine's 191 disk to the SFS directory, the intermittent error appears. The vast majority of the time, the write is successful. However, sometimes, the job gets this error message: DMSOPN1258E You are not authorized to write to file XX 20110413 Z1 The file is not large--last night's file was only 12 blocks. At the suggestion of our systems programmer, I've put in a lot of query statements. I've issued QUERY LIMITS for the job submitter; it's only used 84% of the allocation, with several thousand blocks available. The SFS directory owner has only used 76% of its allocation, with several thousand more blocks still available. The filepool is not full. I've issued QUERY FILEPOOL CONFLICT. There is no conflict. I've issued QUERY ACCESSED. The directory shows that is accessed R/W. When the write is unsuccessful, the program then
Re: SFS problem
Alan, The submitter does have NEWRITE permissions. And nothing in that job erases the file. The job runs only once per day, and the File Type is the date, such as 20110419. However, I didn't know that authority to write the file disappeared with the file if NEWRITE wasn't granted, so I learned something! Nora Graves nora.e.gra...@irs.gov Main IRS, Room 6531 (202) 622-6735 Fax (202) 622-3123 SE:W:CAR:MP:D:KS:BRSI -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Thursday, April 14, 2011 4:52 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS problem On Thursday, 04/14/2011 at 03:47 EDT, Graves Nora E nora.e.gra...@irs.gov wrote: DMSOPN1258E You are not authorized to write to file XX 20110413 Z1 : I've issued QUERY ACCESSED. The directory shows that is accessed R/W. When the write is unsuccessful, the program then loops through 5 tries of releasing the access, reacquiring the access, and attempting to write the file again. This has never been successful. I've issued both a COPYFILE and a PIPE to try to write the file; these do not work once there has been a failure. We've looked at the operator consoles to see if we can find any jobs running at the same time. We haven't found any that are accessing that directory structure. There aren't any dumps to look at--it looks perfectly successful other than the fact that it won't write the file. Does anyone have any suggestions of something to try next? As you can see, it's an authorization error. Does the worker/submittor have NEWRITE authority to the directory? If not, and some part of the job ERASEs the file from the directory and then tries to recreate it, it will fail, as the authority to the file is deleted if the file itself is deleted. In a FILECONTROL directory, R/W access to the directory does not imply R/W access to all the files in it! Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: SFS problem
Kris, The submitter is ABC, the directory owner is XYZ. The submitter has WRITE/NEWRITE authority to the directory and files. Nora Graves nora.e.gra...@irs.gov Main IRS, Room 6531 (202) 622-6735 Fax (202) 622-3123 SE:W:CAR:MP:D:KS:BRSI From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Kris Buelens Sent: Thursday, April 14, 2011 4:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS problem Note: if you use VMBATCH, the worker machine connects to SFS with the authority of the job submitter. You say This user is the owner of most of the directories You mean: the submitter is userid ABC, the dirids are all named fpoolid:ABC.something? 2011/4/14 Graves Nora E nora.e.gra...@irs.gov We are having an intermittent problem with SFS and I'm hoping someone may have some ideas of what to pursue next. We have several batch jobs that run under VMBATCH overnight. Sometimes they are not able to create a file in a directory, even though most times it is successful. The only differences in the executions are the file names; for many of these the File Type is the date. In the job I am most familiar with, these are the specifics. The job runs Monday-Saturday. This year, it has failed on January 4, January 12, February 9, March 18, March 25, and April 13. It has run successfully the other days. Other than the QUERY statements below, it has not changed. The job runs in a work machine, WORK7. The job is submitted by the User ID of the database owner. The SFS directories are owned by a 3rd user. Failures occur in many of the subdirectories, not just one subdirectory owned by this user. This user is the owner of most of the directories containing the data files we create in batch, so I don't think it's significant that it's the ID that has the problem. However, as far as I know, it is the only ID that does have the problem. This job uses VMLINK to acquire a write link to SFS directory. This always looks to be successful--no error is given. (Other jobs use GETFMADDR and ACCESS to acquire the write link to the directory. This always appears successful as well). Once the file is ready to be copied from the Work Machine's 191 disk to the SFS directory, the intermittent error appears. The vast majority of the time, the write is successful. However, sometimes, the job gets this error message: DMSOPN1258E You are not authorized to write to file XX 20110413 Z1 The file is not large--last night's file was only 12 blocks. At the suggestion of our systems programmer, I've put in a lot of query statements. I've issued QUERY LIMITS for the job submitter; it's only used 84% of the allocation, with several thousand blocks available. The SFS directory owner has only used 76% of its allocation, with several thousand more blocks still available. The filepool is not full. I've issued QUERY FILEPOOL CONFLICT. There is no conflict. I've issued QUERY ACCESSED. The directory shows that is accessed R/W. When the write is unsuccessful, the program then loops through 5 tries of releasing the access, reacquiring the access, and attempting to write the file again. This has never been successful. I've issued both a COPYFILE and a PIPE to try to write the file; these do not work once there has been a failure. We've looked at the operator consoles to see if we can find any jobs running at the same time. We haven't found any that are accessing that directory structure. There aren't any dumps to look at--it looks perfectly successful other than the fact that it won't write the file. Does anyone have any suggestions of something to try next? Nora Graves nora.e.gra...@irs.gov -- Kris Buelens, IBM Belgium, VM customer support
Re: SFS problem
Jim, I didn't think to look there, I will. Our regular backups are VMBACKUP, which is scheduled to run 90 minutes after this job runs. This job runs only 2 minutes maximum, so I know that isn't the problem. But the SFS console may have some good indications. I'll see what I can find there. Thanks, Nora Graves nora.e.gra...@irs.gov Main IRS, Room 6531 (202) 622-6735 Fax (202) 622-3123 SE:W:CAR:MP:D:KS:BRSI -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Hughes, Jim Sent: Thursday, April 14, 2011 5:23 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS problem Nora, Have you looked at the SFS service machine's console log for any odd messages? Could the SFS server being doing some sort of control backup? Jim Hughes Consulting Systems Programmer Mainframe Technical Support Group Department of Information Technology State of New Hampshire 27 Hazen Drive Concord, NH 03301 603-271-5586Fax 603.271.1516 Statement of Confidentiality: The contents of this message are confidential. Any unauthorized disclosure, reproduction, use or dissemination (either whole or in part) is prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete the message from your system.
Re: SFS problem
Jim, There are basically no messages at all in the console for the SFS service machine. One of the failures was on April 13. This is the console for that day--no editing at all of the contents. HCPMID6001I TIME IS 00:00:00 EDT WEDNESDAY 04/13/11 00:00:00 HCPMID6001I TIME IS 00:00:00 EDT THURSDAY 04/14/11 00:00:00 Nora Graves nora.e.gra...@irs.gov Main IRS, Room 6531 (202) 622-6735 Fax (202) 622-3123 SE:W:CAR:MP:D:KS:BRSI -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Hughes, Jim Sent: Thursday, April 14, 2011 5:23 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS problem Nora, Have you looked at the SFS service machine's console log for any odd messages? Could the SFS server being doing some sort of control backup? Jim Hughes Consulting Systems Programmer Mainframe Technical Support Group Department of Information Technology State of New Hampshire 27 Hazen Drive Concord, NH 03301 603-271-5586Fax 603.271.1516 Statement of Confidentiality: The contents of this message are confidential. Any unauthorized disclosure, reproduction, use or dissemination (either whole or in part) is prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete the message from your system.
Re: Error : DMSITS135S Maximum SVC depth 200 has been exceeded
Amar, we just had this happen on a totally different program. What was happening was the user had created an EXEC on there A disk that was identical to the name on another disk. When they run their EXEC, it basically kept calling itself causing recursion and exceeding available SVC's So, look for duplicate file names. Steve -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Amar Moh Sent: Tuesday, April 19, 2011 7:09 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Error : DMSITS135S Maximum SVC depth 200 has been exceeded Hi, We are running VMSERVE, the application server/scheduler on a z/VM CP/CMS system. Recently, it started giving this error every time we make a progr am run through VMSERVE. I am not very experienced in z/VM so any help is appreciated! System : z/VM Version 5 Release 2.0, Service Level 0801 (64-bit) WWVM ESA CMS 15 012 VMSERVE starts fine but as soon as it runs a program, VMSERVE crashes and ends with this error, DMSITS135S Maximum SVC depth 200 has been exceeded. DMSITS135S Maximum SVC depth 200 has been exceeded. It probably means : The CMS system does not allow the nesting level of SV Cs to exceed ''. But not sure what can be done to fix this. Regards, Amar
Re: Error : DMSITS135S Maximum SVC depth 200 has been exceeded
Look at it's log file and console spool file to see what it was doing when the error occurred. The message is typical for an exec that executes something that executes the exec, as Stephen pointed out. If you've configured VMSERVE properly it is fairly unusual for it to suddenly change it's behavior unless a disk it is linked to has introduced something new. Of course this also assumes that all the EXECs that you've given it to use follow the Good Rexx Coding Practices rules. Les Amar Moh wrote: Hi, We are running VMSERVE, the application server/scheduler on a z/VM CP/CMS system. Recently, it started giving this error every time we make a progr am run through VMSERVE. I am not very experienced in z/VM so any help is appreciated! System : z/VM Version 5 Release 2.0, Service Level 0801 (64-bit) WWVM ESA CMS 15 012 VMSERVE starts fine but as soon as it runs a program, VMSERVE crashes and ends with this error, DMSITS135S Maximum SVC depth 200 has been exceeded. DMSITS135S Maximum SVC depth 200 has been exceeded. It probably means : The CMS system does not allow the nesting level of SV Cs to exceed ''. But not sure what can be done to fix this. Regards, Amar
Re: SFS problem
Nora, Batch jobs normally run with the privileges of the owner of the job, using the SECUSER facility in z/VM. With SFS, this can lead to unexpected results when a prior batch job leaves the worker with a connection to the filepool under a different user's id. If the job ordering/selection of batch workers is somewhat random, you could see the outcome that you're experiencing (sometimes it works, sometimes it fails). For example: If WORK7 first runs a job for JOHN and JOHN utilizes the same filepool, WORK7 could be left with a connection to the filepool that appears to be from the user JOHN. If your failing job runs next, it would likely end up accessing the filepool as JOHN, not as the actual owner, which could cause the failure. If on another night, WORK7 is recycled before your failing job runs, then it would establish a connection to the file pool with the owner's ID (say OWNER) and then would run with the access rights of OWNER, and you'd see success. If this is your problem, there are many ways to solve it. The easiest would be to ensure that worker machines are recycled (logoff/xautolog or IPL CMS) prior to the job running. I wonder if there are VMBATCH options (system or job) that provide the ability to do a more advanced clean up of a worker prior to a job run. John -- John Hall Safe Software, Inc. 727-608-8799 johnh...@safesoftware.com On Thu, Apr 14, 2011 at 3:45 PM, Graves Nora E nora.e.gra...@irs.govwrote: We are having an intermittent problem with SFS and I'm hoping someone may have some ideas of what to pursue next. We have several batch jobs that run under VMBATCH overnight. Sometimes they are not able to create a file in a directory, even though most times it is successful. The only differences in the executions are the file names; for many of these the File Type is the date. In the job I am most familiar with, these are the specifics. The job runs Monday-Saturday. This year, it has failed on January 4, January 12, February 9, March 18, March 25, and April 13. It has run successfully the other days. Other than the QUERY statements below, it has not changed. The job runs in a work machine, WORK7. The job is submitted by the User ID of the database owner. The SFS directories are owned by a 3rd user. Failures occur in many of the subdirectories, not just one subdirectory owned by this user. This user is the owner of most of the directories containing the data files we create in batch, so I don't think it's significant that it's the ID that has the problem. However, as far as I know, it is the only ID that does have the problem. This job uses VMLINK to acquire a write link to SFS directory. This always looks to be successful--no error is given. (Other jobs use GETFMADDR and ACCESS to acquire the write link to the directory. This always appears successful as well). Once the file is ready to be copied from the Work Machine's 191 disk to the SFS directory, the intermittent error appears. The vast majority of the time, the write is successful. However, sometimes, the job gets this error message: DMSOPN1258E You are not authorized to write to file XX 20110413 Z1 The file is not large--last night's file was only 12 blocks. At the suggestion of our systems programmer, I've put in a lot of query statements. I've issued QUERY LIMITS for the job submitter; it's only used 84% of the allocation, with several thousand blocks available. The SFS directory owner has only used 76% of its allocation, with several thousand more blocks still available. The filepool is not full. I've issued QUERY FILEPOOL CONFLICT. There is no conflict. I've issued QUERY ACCESSED. The directory shows that is accessed R/W. When the write is unsuccessful, the program then loops through 5 tries of releasing the access, reacquiring the access, and attempting to write the file again. This has never been successful. I've issued both a COPYFILE and a PIPE to try to write the file; these do not work once there has been a failure. We've looked at the operator consoles to see if we can find any jobs running at the same time. We haven't found any that are accessing that directory structure. There aren't any dumps to look at--it looks perfectly successful other than the fact that it won't write the file. Does anyone have any suggestions of something to try next? Nora Graves nora.e.gra...@irs.gov
Re: Error : DMSITS135S Maximum SVC depth 200 has been exceeded
Amar, Could you logon to the service machine running VMSERVE, stop VMSERVE, and then run the command that was running when you experienced the failure? If it still fails the same way, you will evidence that VMSERVE is not causing the problem, and can look elsewhere. An alternative if you don't want to stop VMSERVE: from another ID, link to all the disks that VMSERVE has accessed and run the same failing command. If the same failure occurs, you can diagnose, correct, and test the solution with affecting VMSERVE, then move the fix into production. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. Amar Moh amar_...@yahoo.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 04/19/2011 06:09 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Error : DMSITS135S Maximum SVC depth 200 has been exceeded Hi, We are running VMSERVE, the application server/scheduler on a z/VM CP/CMS system. Recently, it started giving this error every time we make a program run through VMSERVE. I am not very experienced in z/VM so any help is appreciated! System : z/VM Version 5 Release 2.0, Service Level 0801 (64-bit) WWVM ESA CMS 15 012 VMSERVE starts fine but as soon as it runs a program, VMSERVE crashes and ends with this error, DMSITS135S Maximum SVC depth 200 has been exceeded. DMSITS135S Maximum SVC depth 200 has been exceeded. It probably means : The CMS system does not allow the nesting level of SVCs to exceed ''. But not sure what can be done to fix this. Regards, Amar 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: SFS problem
Isn't that DIAG 88, instead of SECUSER? Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of John Hall Sent: Tuesday, April 19, 2011 6:41 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS problem Nora, Batch jobs normally run with the privileges of the owner of the job, using the SECUSER facility in z/VM. With SFS, this can lead to unexpected results when a prior batch job leaves the worker with a connection to the filepool under a different user's id. If the job ordering/selection of batch workers is somewhat random, you could see the outcome that you're experiencing (sometimes it works, sometimes it fails).
Re: SFS problem
Just to exhaust the possibilities in this line, we have had occasions when a job would fail for another reason, then be re-submitted by another userid without the required authority. On Tue, Apr 19, 2011 at 7:47 AM, Graves Nora E nora.e.gra...@irs.govwrote: Kris, The submitter is ABC, the directory owner is XYZ. The submitter has WRITE/NEWRITE authority to the directory and files. Nora Graves nora.e.gra...@irs.gov Main IRS, Room 6531 (202) 622-6735 Fax (202) 622-3123 SE:W:CAR:MP:D:KS:BRSI -- *From:* The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] *On Behalf Of *Kris Buelens *Sent:* Thursday, April 14, 2011 4:58 PM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* Re: SFS problem Note: if you use VMBATCH, the worker machine connects to SFS with the authority of the job submitter. You say This user is the owner of most of the directories You mean: the submitter is userid ABC, the dirids are all named fpoolid:ABC.something? 2011/4/14 Graves Nora E nora.e.gra...@irs.gov We are having an intermittent problem with SFS and I'm hoping someone may have some ideas of what to pursue next. We have several batch jobs that run under VMBATCH overnight. Sometimes they are not able to create a file in a directory, even though most times it is successful. The only differences in the executions are the file names; for many of these the File Type is the date. In the job I am most familiar with, these are the specifics. The job runs Monday-Saturday. This year, it has failed on January 4, January 12, February 9, March 18, March 25, and April 13. It has run successfully the other days. Other than the QUERY statements below, it has not changed. The job runs in a work machine, WORK7. The job is submitted by the User ID of the database owner. The SFS directories are owned by a 3rd user. Failures occur in many of the subdirectories, not just one subdirectory owned by this user. This user is the owner of most of the directories containing the data files we create in batch, so I don't think it's significant that it's the ID that has the problem. However, as far as I know, it is the only ID that does have the problem. This job uses VMLINK to acquire a write link to SFS directory. This always looks to be successful--no error is given. (Other jobs use GETFMADDR and ACCESS to acquire the write link to the directory. This always appears successful as well). Once the file is ready to be copied from the Work Machine's 191 disk to the SFS directory, the intermittent error appears. The vast majority of the time, the write is successful. However, sometimes, the job gets this error message: DMSOPN1258E You are not authorized to write to file XX 20110413 Z1 The file is not large--last night's file was only 12 blocks. At the suggestion of our systems programmer, I've put in a lot of query statements. I've issued QUERY LIMITS for the job submitter; it's only used 84% of the allocation, with several thousand blocks available. The SFS directory owner has only used 76% of its allocation, with several thousand more blocks still available. The filepool is not full. I've issued QUERY FILEPOOL CONFLICT. There is no conflict. I've issued QUERY ACCESSED. The directory shows that is accessed R/W. When the write is unsuccessful, the program then loops through 5 tries of releasing the access, reacquiring the access, and attempting to write the file again. This has never been successful. I've issued both a COPYFILE and a PIPE to try to write the file; these do not work once there has been a failure. We've looked at the operator consoles to see if we can find any jobs running at the same time. We haven't found any that are accessing that directory structure. There aren't any dumps to look at--it looks perfectly successful other than the fact that it won't write the file. Does anyone have any suggestions of something to try next? Nora Graves nora.e.gra...@irs.gov -- Kris Buelens, IBM Belgium, VM customer support
sclp_config: cpu capability changed.
Hello all , I have noticed kernel message Apr 19 12:35:07 hostname kernel: sclp_config: cpu capability changed on all of our Linux guest on multiple LPARs. Does this indicate a hardware issue with the IFL processor? I have asked our hardware support to check for any error on the machine. Thank you, Ashwin Bhemidhi
Re: sclp_config: cpu capability changed.
It could very well mean a hardware issue. We received this message when the refrigeration unit in our z10 failed. The microcode scales back the processor speed. For our healthy z10: adczlnxsahqa1:/ # cat /sys/devices/system/cpu/cpu0/capability 1760 From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Bhemidhi, Ashwin Sent: Tuesday, April 19, 2011 2:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject: sclp_config: cpu capability changed. Hello all , I have noticed kernel message Apr 19 12:35:07 hostname kernel: sclp_config: cpu capability changed on all of our Linux guest on multiple LPARs. Does this indicate a hardware issue with the IFL processor? I have asked our hardware support to check for any error on the machine. Thank you, Ashwin Bhemidhi
Re: sclp_config: cpu capability changed.
Well, our hardware support said that IBM was replacing some other failed component (not IFL) around the time I noticed those errors. The cpu capability on our z10 match what you reported on your z10. cat /sys/devices/system/cpu/cpu0/capability 1760 I have asked hardware team to check to see if there are any other errors. Hopefully the error was due the hardware maintenance. Thank you for the information on your z10. Regards, Ashwin From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Quay, Jonathan (IHG) Sent: Tuesday, April 19, 2011 2:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: sclp_config: cpu capability changed. It could very well mean a hardware issue. We received this message when the refrigeration unit in our z10 failed. The microcode scales back the processor speed. For our healthy z10: adczlnxsahqa1:/ # cat /sys/devices/system/cpu/cpu0/capability 1760 From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Bhemidhi, Ashwin Sent: Tuesday, April 19, 2011 2:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject: sclp_config: cpu capability changed. Hello all , I have noticed kernel message Apr 19 12:35:07 hostname kernel: sclp_config: cpu capability changed on all of our Linux guest on multiple LPARs. Does this indicate a hardware issue with the IFL processor? I have asked our hardware support to check for any error on the machine. Thank you, Ashwin Bhemidhi
Re: sclp_config: cpu capability changed.
What model of CEC? If it's a z10 or a z196, it might be some of the power-saving features kicking in. That message can also occur if capacity-on-demand has modified the system capability (although it's usually rare to see it on a IFL). From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Bhemidhi, Ashwin Sent: Tuesday, April 19, 2011 2:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject: sclp_config: cpu capability changed. Hello all , I have noticed kernel message Apr 19 12:35:07 hostname kernel: sclp_config: cpu capability changed on all of our Linux guest on multiple LPARs. Does this indicate a hardware issue with the IFL processor? I have asked our hardware support to check for any error on the machine. Thank you, Ashwin Bhemidhi
Re: sclp_config: cpu capability changed.
It is a 2097-503 z10. Regards, Ashwin From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of David Boyes Sent: Tuesday, April 19, 2011 2:33 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: sclp_config: cpu capability changed. What model of CEC? If it's a z10 or a z196, it might be some of the power-saving features kicking in. That message can also occur if capacity-on-demand has modified the system capability (although it's usually rare to see it on a IFL). From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Bhemidhi, Ashwin Sent: Tuesday, April 19, 2011 2:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject: sclp_config: cpu capability changed. Hello all , I have noticed kernel message Apr 19 12:35:07 hostname kernel: sclp_config: cpu capability changed on all of our Linux guest on multiple LPARs. Does this indicate a hardware issue with the IFL processor? I have asked our hardware support to check for any error on the machine. Thank you, Ashwin Bhemidhi
Minidisk Cache
The Planning and Administration Guide for z/VM 6.1 mentions dasd that is not eligible for minidisk cache. Is the 3390 mod 54 minidisk cache eligible? Thanks in advance. Brent Litster Brent Litster Zions Management Services Company 2185 South 3270 West West Valley City 84119 (801) 844-5545 blits...@zionsbank.com[cid:image002.gif@01CBFE98.4C241BB0] === THIS ELECTRONIC MESSAGE, INCLUDING ANY ACCOMPANYING DOCUMENTS, IS CONFIDENTIAL and may contain information that is privileged and exempt from disclosure under applicable law. If you are neither the intended recipient nor responsible for delivering the message to the intended recipient, please note that any dissemination, distribution, copying or the taking of any action in reliance upon the message is strictly prohibited. If you have received this communication in error, please notify the sender immediately. Thank you.
VMLINK behavior
I executed this exec : /**/ VMLINK 5VMDIR40 0491 VMLINK 5VMDIR40 0492 VMLINK 5VMDIR40 011F VMLINK 5VMDIR40 041F VMLINK DIRMAINT 01AA VMLINK DIRMAINT 01FA VMLINK DIRMAINT 02AA VMLINK DIRMAINT 0155 VMLINK DIRMAINT 01DF DMSACC048E Invalid filemode S Ready(02024); T=0.01/0.01 16:05:35 I received DMSACC048E Invalid filemode S for the VMLINK DIRMAINT 01DF q disk LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BL K TOTAL MNT191 191 A R/W 175 3390 4096 121 1459-05 30041 31500 MNT190 190 S R/O 100 3390 4096 704 15293-85 2707 18000 DIR155 127 T R/O 9 3390 4096 10 23-01 1597 1620 DIR1AA 126 U R/O 9 3390 40966 13-01 1607 1620 DRM41F 125 V R/O 8 3390 4096 50642-45798 1440 DIR11F 124 W R/O15 3390 4096 49629-23 2071 2700 DRM492 121 X R/O15 3390 4096 269 1490-55 1210 2700 MNT19E 19E Y/S R/O 250 3390 4096 1779 38956-87 6044 45000 DRM491 120 Z R/O15 3390 4096 259 1410-52 1290 2700 Ready; T=0.01/0.01 16:05:41 I used the version of vmlink created in september 2010 Alain Benveniste
Re: VMLINK behavior
Does VMLINK with the NONAMES option cause the same behavior? VMLINK user disk (NON I'm not sure about in this case, but NAMES files can sometimes create problems when using VMLINK - so I tend to use NONames Scott Rohling On Tue, Apr 19, 2011 at 2:08 PM, Alain Benveniste a.benveni...@free.frwrote: I executed this exec : /**/ VMLINK 5VMDIR40 0491 VMLINK 5VMDIR40 0492 VMLINK 5VMDIR40 011F VMLINK 5VMDIR40 041F VMLINK DIRMAINT 01AA VMLINK DIRMAINT 01FA VMLINK DIRMAINT 02AA VMLINK DIRMAINT 0155 VMLINK DIRMAINT 01DF DMSACC048E Invalid filemode S Ready(02024); T=0.01/0.01 16:05:35 I received DMSACC048E Invalid filemode S for the VMLINK DIRMAINT 01DF q disk LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL MNT191 191 A R/W 175 3390 4096 121 1459-05 30041 31500 MNT190 190 S R/O 100 3390 4096 704 15293-85 2707 18000 DIR155 127 T R/O 9 3390 4096 10 23-01 1597 1620 DIR1AA 126 U R/O 9 3390 40966 13-01 1607 1620 DRM41F 125 V R/O 8 3390 4096 50642-45798 1440 DIR11F 124 W R/O15 3390 4096 49629-23 2071 2700 DRM492 121 X R/O15 3390 4096 269 1490-55 1210 2700 MNT19E 19E Y/S R/O 250 3390 4096 1779 38956-87 6044 45000 DRM491 120 Z R/O15 3390 4096 259 1410-52 1290 2700 Ready; T=0.01/0.01 16:05:41 I used the version of vmlink created in september 2010 Alain Benveniste
Re: EXTERNAL: VMLINK behavior
Alain, This looks like the problem described in APAR VM64870. Is VM64870 installed? -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alain Benveniste Sent: Tuesday, April 19, 2011 2:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: EXTERNAL: VMLINK behavior I executed this exec : /**/ VMLINK 5VMDIR40 0491 VMLINK 5VMDIR40 0492 VMLINK 5VMDIR40 011F VMLINK 5VMDIR40 041F VMLINK DIRMAINT 01AA VMLINK DIRMAINT 01FA VMLINK DIRMAINT 02AA VMLINK DIRMAINT 0155 VMLINK DIRMAINT 01DF DMSACC048E Invalid filemode S Ready(02024); T=0.01/0.01 16:05:35 I received DMSACC048E Invalid filemode S for the VMLINK DIRMAINT 01DF q disk LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BL K TOTAL MNT191 191 A R/W 175 3390 4096 121 1459-05 30041 31500 MNT190 190 S R/O 100 3390 4096 704 15293-85 2707 18000 DIR155 127 T R/O 9 3390 4096 10 23-01 1597 1620 DIR1AA 126 U R/O 9 3390 40966 13-01 1607 1620 DRM41F 125 V R/O 8 3390 4096 50642-45798 1440 DIR11F 124 W R/O15 3390 4096 49629-23 2071 2700 DRM492 121 X R/O15 3390 4096 269 1490-55 1210 2700 MNT19E 19E Y/S R/O 250 3390 4096 1779 38956-87 6044 45000 DRM491 120 Z R/O15 3390 4096 259 1410-52 1290 2700 Ready; T=0.01/0.01 16:05:41 I used the version of vmlink created in september 2010 Alain Benveniste
Re: VMLINK behavior
Scott I will test this tomorrow... And back to tell you... Le 19/04/11 22:16, « Scott Rohling » scott.rohl...@gmail.com a écrit : Does VMLINK with the NONAMES option cause the same behavior? VMLINK user disk (NON I'm not sure about in this case, but NAMES files can sometimes create problems when using VMLINK - so I tend to use NONames Scott Rohling On Tue, Apr 19, 2011 at 2:08 PM, Alain Benveniste a.benveni...@free.fr wrote: I executed this exec : /**/ VMLINK 5VMDIR40 0491 VMLINK 5VMDIR40 0492 VMLINK 5VMDIR40 011F VMLINK 5VMDIR40 041F VMLINK DIRMAINT 01AA VMLINK DIRMAINT 01FA VMLINK DIRMAINT 02AA VMLINK DIRMAINT 0155 VMLINK DIRMAINT 01DF DMSACC048E Invalid filemode S Ready(02024); T=0.01/0.01 16:05:35 I received DMSACC048E Invalid filemode S for the VMLINK DIRMAINT 01DF q disk LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL MNT191 191 A R/W 175 3390 4096 121 1459-05 30041 31500 MNT190 190 S R/O 100 3390 4096 704 15293-85 2707 18000 DIR155 127 T R/O 9 3390 4096 10 23-01 1597 1620 DIR1AA 126 U R/O 9 3390 4096 6 13-01 1607 1620 DRM41F 125 V R/O 8 3390 4096 50 642-45 798 1440 DIR11F 124 W R/O 15 3390 4096 49 629-23 2071 2700 DRM492 121 X R/O 15 3390 4096 269 1490-55 1210 2700 MNT19E 19E Y/S R/O 250 3390 4096 1779 38956-87 6044 45000 DRM491 120 Z R/O 15 3390 4096 259 1410-52 1290 2700 Ready; T=0.01/0.01 16:05:41 I used the version of vmlink created in september 2010 Alain Benveniste
Re: RACFVM Resizing mdisk 200 and more...
I replayed all the process. Just before the racfconv, a verify with racut 200 validated the database integrity. After racfconv, the database is damaged ... Alain Benveniste
Re: EXTERNAL: VMLINK behavior
Robert, I can't confirm this right now, but if this ptf was in the last RSU from April 2011 for vm540, so... Yes it is applied... Alain Le 19/04/11 22:27, « Hodge, Robert L » robert.l.ho...@lmco.com a écrit : VM64870
Re: VMLINK behavior
VMLINK shouldn't try to access a disk at filemode S, since the access command doesn't allow you to access anything at filemode S. You may have found a bug. What level and service level of z/VM are you running? Maybe you need APAR VM64870 VMLINK INCORRECTLY DETACHES THE SYSTEM DISK? The description doesn't sound correct, but the text talks about special handling for the S disk. On Tue, Apr 19, 2011 at 4:08 PM, Alain Benveniste a.benveni...@free.fr wrote: I executed this exec : /**/ VMLINK 5VMDIR40 0491 VMLINK 5VMDIR40 0492 VMLINK 5VMDIR40 011F VMLINK 5VMDIR40 041F VMLINK DIRMAINT 01AA VMLINK DIRMAINT 01FA VMLINK DIRMAINT 02AA VMLINK DIRMAINT 0155 VMLINK DIRMAINT 01DF DMSACC048E Invalid filemode S Ready(02024); T=0.01/0.01 16:05:35 I received DMSACC048E Invalid filemode S for the VMLINK DIRMAINT 01DF q disk LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL MNT191 191 A R/W 175 3390 4096 121 1459-05 30041 31500 MNT190 190 S R/O 100 3390 4096 704 15293-85 2707 18000 DIR155 127 T R/O 9 3390 4096 10 23-01 1597 1620 DIR1AA 126 U R/O 9 3390 4096 6 13-01 1607 1620 DRM41F 125 V R/O 8 3390 4096 50 642-45 798 1440 DIR11F 124 W R/O 15 3390 4096 49 629-23 2071 2700 DRM492 121 X R/O 15 3390 4096 269 1490-55 1210 2700 MNT19E 19E Y/S R/O 250 3390 4096 1779 38956-87 6044 45000 DRM491 120 Z R/O 15 3390 4096 259 1410-52 1290 2700 Ready; T=0.01/0.01 16:05:41 I used the version of vmlink created in september 2010 Alain Benveniste -- Bruce Hayden z/VM and Linux on System z ATS IBM, Endicott, NY
Re: RACFVM Resizing mdisk 200 and more...
I'd say a call to the support center is in order... RACFCONV should not damage your database. On Tue, Apr 19, 2011 at 4:32 PM, Alain Benveniste a.benveni...@free.fr wrote: I replayed all the process. Just before the racfconv, a verify with racut200 validated the database integrity. After racfconv, the database is damaged... Alain Benveniste -- Bruce Hayden z/VM and Linux on System z ATS IBM, Endicott, NY
Backout PTF(s) applied
Hello Listers, What is the best way/practice to backout a ptf or ptfs that has been applied and PUT2PROD? I am about to apply some service (2 ptfs) to CP and can't seem to find what is best way to restore my environment prior to applying the ptfs. I would prefer not to restore dasd. It would be preferrable if there is an exec that can revert the affected elements. I have heard of VMFREM? And also heard of not using PUT2PROD but rather swap 490 and 190. Any assistance or documentation on how to backout a couple of ptfs would be appreciated. Kind Regards, Steve
Re: EXTERNAL: VMLINK behavior
VM64870 is not on a RSU. -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alain Benvéniste Sent: Tuesday, April 19, 2011 2:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: EXTERNAL: VMLINK behavior Robert, I can't confirm this right now, but if this ptf was in the last RSU from April 2011 for vm540, so... Yes it is applied... Alain Le 19/04/11 22:27, « Hodge, Robert L » robert.l.ho...@lmco.com a écrit : VM64870
Re: VMLINK behavior
Bruce, I'm near sure I have reconducted the last vmlink provided - this ptf included - by the IBM support from my VM530 to my VM540 RSU 1003... now I am with the rsu 1101 applied. Alain Le 19/04/11 22:40, « Bruce Hayden » bjhay...@gmail.com a écrit : VMLINK shouldn't try to access a disk at filemode S, since the access command doesn't allow you to access anything at filemode S. You may have found a bug. What level and service level of z/VM are you running? Maybe you need APAR VM64870 VMLINK INCORRECTLY DETACHES THE SYSTEM DISK? The description doesn't sound correct, but the text talks about special handling for the S disk. On Tue, Apr 19, 2011 at 4:08 PM, Alain Benveniste a.benveni...@free.fr wrote: I executed this exec : /**/ VMLINK 5VMDIR40 0491 VMLINK 5VMDIR40 0492 VMLINK 5VMDIR40 011F VMLINK 5VMDIR40 041F VMLINK DIRMAINT 01AA VMLINK DIRMAINT 01FA VMLINK DIRMAINT 02AA VMLINK DIRMAINT 0155 VMLINK DIRMAINT 01DF DMSACC048E Invalid filemode S Ready(02024); T=0.01/0.01 16:05:35 I received DMSACC048E Invalid filemode S for the VMLINK DIRMAINT 01DF q disk LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL MNT191 191 A R/W 175 3390 4096 121 1459-05 30041 31500 MNT190 190 S R/O 100 3390 4096 704 15293-85 2707 18000 DIR155 127 T R/O 9 3390 4096 10 23-01 1597 1620 DIR1AA 126 U R/O 9 3390 4096 6 13-01 1607 1620 DRM41F 125 V R/O 8 3390 4096 50 642-45 798 1440 DIR11F 124 W R/O 15 3390 4096 49 629-23 2071 2700 DRM492 121 X R/O 15 3390 4096 269 1490-55 1210 2700 MNT19E 19E Y/S R/O 250 3390 4096 1779 38956-87 6044 45000 DRM491 120 Z R/O 15 3390 4096 259 1410-52 1290 2700 Ready; T=0.01/0.01 16:05:41 I used the version of vmlink created in september 2010 Alain Benveniste
Re: VMLINK behavior
Bruce This ptf was for the case where the 190 was detached by vmlink... In my case i still have it... Alain Le 19/04/11 22:40, « Bruce Hayden » bjhay...@gmail.com a écrit : VMLINK shouldn't try to access a disk at filemode S, since the access command doesn't allow you to access anything at filemode S. You may have found a bug. What level and service level of z/VM are you running? Maybe you need APAR VM64870 VMLINK INCORRECTLY DETACHES THE SYSTEM DISK? The description doesn't sound correct, but the text talks about special handling for the S disk. On Tue, Apr 19, 2011 at 4:08 PM, Alain Benveniste a.benveni...@free.fr wrote: I executed this exec : /**/ VMLINK 5VMDIR40 0491 VMLINK 5VMDIR40 0492 VMLINK 5VMDIR40 011F VMLINK 5VMDIR40 041F VMLINK DIRMAINT 01AA VMLINK DIRMAINT 01FA VMLINK DIRMAINT 02AA VMLINK DIRMAINT 0155 VMLINK DIRMAINT 01DF DMSACC048E Invalid filemode S Ready(02024); T=0.01/0.01 16:05:35 I received DMSACC048E Invalid filemode S for the VMLINK DIRMAINT 01DF q disk LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL MNT191 191 A R/W 175 3390 4096 121 1459-05 30041 31500 MNT190 190 S R/O 100 3390 4096 704 15293-85 2707 18000 DIR155 127 T R/O 9 3390 4096 10 23-01 1597 1620 DIR1AA 126 U R/O 9 3390 4096 6 13-01 1607 1620 DRM41F 125 V R/O 8 3390 4096 50 642-45 798 1440 DIR11F 124 W R/O 15 3390 4096 49 629-23 2071 2700 DRM492 121 X R/O 15 3390 4096 269 1490-55 1210 2700 MNT19E 19E Y/S R/O 250 3390 4096 1779 38956-87 6044 45000 DRM491 120 Z R/O 15 3390 4096 259 1410-52 1290 2700 Ready; T=0.01/0.01 16:05:41 I used the version of vmlink created in september 2010 Alain Benveniste
Re: VMLINK behavior
Hi Alain, Please XEDIT the VMLINK SEXEC S that you have and change: minidisklist = '' to minidisklist = 'S' and then file it on your A-disk as VMLINK EXEC. Then repeat the failing scenario. This might patch the problem for you. This is not an official fix from IBM. I am just trying to help get you past this problem. I agree with Bruce that this might be a bug and will need to go through the normal problem reporting process. pdb (Doug Breneman) z/VM System Test IBM Endicott, NY From: Alain Benvéniste a.benveni...@free.fr To: IBMVM@LISTSERV.UARK.EDU Date: 04/19/2011 04:50 PM Subject:Re: VMLINK behavior Sent by:The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU Bruce This ptf was for the case where the 190 was detached by vmlink... In my case i still have it... Alain Le 19/04/11 22:40, « Bruce Hayden » bjhay...@gmail.com a écrit : VMLINK shouldn't try to access a disk at filemode S, since the access command doesn't allow you to access anything at filemode S. You may have found a bug. What level and service level of z/VM are you running? Maybe you need APAR VM64870 VMLINK INCORRECTLY DETACHES THE SYSTEM DISK? The description doesn't sound correct, but the text talks about special handling for the S disk. On Tue, Apr 19, 2011 at 4:08 PM, Alain Benveniste a.benveni...@free.fr wrote: I executed this exec : /**/ VMLINK 5VMDIR40 0491 VMLINK 5VMDIR40 0492 VMLINK 5VMDIR40 011F VMLINK 5VMDIR40 041F VMLINK DIRMAINT 01AA VMLINK DIRMAINT 01FA VMLINK DIRMAINT 02AA VMLINK DIRMAINT 0155 VMLINK DIRMAINT 01DF DMSACC048E Invalid filemode S Ready(02024); T=0.01/0.01 16:05:35 I received DMSACC048E Invalid filemode S for the VMLINK DIRMAINT 01DF q disk LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BLK TOTAL MNT191 191 A R/W 175 3390 4096 121 1459-05 30041 31500 MNT190 190 S R/O 100 3390 4096 704 15293-85 2707 18000 DIR155 127 T R/O 9 3390 4096 10 23-01 1597 1620 DIR1AA 126 U R/O 9 3390 4096 6 13-01 1607 1620 DRM41F 125 V R/O 8 3390 4096 50 642-45 798 1440 DIR11F 124 W R/O 15 3390 4096 49 629-23 2071 2700 DRM492 121 X R/O 15 3390 4096 269 1490-55 1210 2700 MNT19E 19E Y/S R/O 250 3390 4096 1779 38956-87 6044 45000 DRM491 120 Z R/O 15 3390 4096 259 1410-52 1290 2700 Ready; T=0.01/0.01 16:05:41 I used the version of vmlink created in september 2010 Alain Benveniste
Re: Backout PTF(s) applied
Thanks, Bill. However, I don't think my question(s) were answered in that RED alert unless it describes to me how best to backout ptfs applied. And from reviewing the alert, I was not able to find that answer. And no, I do not have the PTF applied that the RED alert indicated. Thanks for your response. I will see if others here have feedback or experiences here prior to contacting IBM. Kind Regards, Steve Steve S. Perez zSeries Technical Services -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Bill Munson Sent: Tuesday, April 19, 2011 3:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Backout PTF(s) applied Steve. There is a PTF closed yesterday to fix the RED Alert ptf sent out this morning. Call IBM. Munson - Original Message - From: Steve Perez [sspe...@corelogic.com] Sent: 04/19/2011 03:43 PM EST To: IBMVM@LISTSERV.UARK.EDU Subject: Backout PTF(s) applied Hello Listers, What is the best way/practice to backout a ptf or ptfs that has been applied and PUT2PROD? I am about to apply some service (2 ptfs) to CP and can't seem to find = what is best way to restore my environment prior to applying the ptfs. I= would prefer not to restore dasd. It would be preferrable if there is an= exec that can revert the affected elements. I have heard of VMFREM? And also heard of not using PUT2PROD but rather = swap 490 and 190. Any assistance or documentation on how to backout a couple of ptfs would = be appreciated. Kind Regards, Steve *** IMPORTANT NOTE*-- The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman Co., its subsidiaries and affiliates (BBH). There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus. ** This message may contain confidential or proprietary information intended only for the use of the addressee(s) named above or may contain information that is legally privileged. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message and any copies immediately thereafter. Thank you. ** CLLD
Re: Backout PTF(s) applied
However, I don't think my question(s) were answered in that RED alert unless it describes to me how best to backout ptfs applied. Call the support center is the best answer. Those folks actually understand SES well enough to tell you how to do it without screwing things up. If you don't know what all the options to VMFREM actually do, you stand an excellent chance of making your system unserviceable. That's why the support center gets the big bucks. They live for this stuff. -- db PS - yes, I would like some more koolaid, Mr. Leary.
Re: Backout PTF(s) applied
Steve, CP does not use the 0190 and 0490 disks... those are the CMS system residence volumes. When you apply service to CP that goes in the CP nucleus (i.e. into the CPLOAD MODULE on the MAINT CF1 disk), then you only need to be sure that you have a backup copy of the CPLOAD MODULE on the CF1 disk. Before building service (perhaps with the SERVICE command), I manually link the MAINT CF1 disk R/W, and COPYFILE CPLOAD MODULE fm -1CPLOAD MODULE fm (OLDDATE REPLACE. IBM's PUT2PROD makes backups, too - but I prefer to have something that I know, and where I know it is every time. If the maintenance causes problems, you just: SHUTDOWN REIPL MODULE -1CPLOAD (FYI, the filetype MUST be MODULE!) More detail: I actually keep several older copies of the CPLOAD MODULE, each time manually bumping their filename higher, as in -1CPLOAD, -2CPLOAD, -3CPLOAD, etc. in a manual version of a z/OS GDG dataset name. And I keep the a @CPLOAD MODULE which is the CPLOAD MODULE that was on the disk when we first brought up that z/VM version. Once the -1CPLOAD MODULE has been IPLed you can choose what you want to do about backing out the errant CP maintenance. That's why you pay IBM the SS fee, let it be their problem (keeping jobs in the U.S. - maybe!). Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. Steve Perez sspe...@corelogic.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 04/19/2011 03:43 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Backout PTF(s) applied Hello Listers, What is the best way/practice to backout a ptf or ptfs that has been applied and PUT2PROD? I am about to apply some service (2 ptfs) to CP and can't seem to find what is best way to restore my environment prior to applying the ptfs. I would prefer not to restore dasd. It would be preferrable if there is an exec that can revert the affected elements. I have heard of VMFREM? And also heard of not using PUT2PROD but rather swap 490 and 190. Any assistance or documentation on how to backout a couple of ptfs would be appreciated. Kind Regards, Steve 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: sclp_config: cpu capability changed.
Which begs the question: If you're responsible for monitoring and resolving such events, why didn't you know about the schedule for the hardware maintenance? Les David Boyes wrote: Based on your later message about simultaneous hardware maintenance happening around the same time as the capability change happened, that's more likely to be the cause (and would explain why you saw it on IFLs - that's one of the few things that would affect both CPs and IFLs similarly). If they finished the maintenance, it's probably back to normal now (although you should have seen another capability change message when the maintenance was finished and everything was back to full speed ahead). From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Bhemidhi, Ashwin Sent: Tuesday, April 19, 2011 3:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: sclp_config: cpu capability changed. It is a 2097-503 z10. Regards, Ashwin
Re: VMLINK behavior
It probably doesn't make a whole lot of difference here, but VMLINK is an EXEC and you aren't following the Good Practices for ordinary Rexx execs: 1-Always code Address Command 2-Specify EXEC or CP as appropriate 3-You got this one right: Quote and uppercase commands to the underlying system It's also wise to either check the RC or use Signal On Error. It may seem meaningless to follow the rules for such a trivial piece of code, but the ONE Y2K problem we had on our project was because we missed a piece of code that didn't, leaving us exposed to synonym resolution and a disk that the user had linked and accessed! Had to borrow the user's id at 2am to find that one :-( Les Alain Benveniste wrote: I executed this exec : /**/ VMLINK 5VMDIR40 0491 VMLINK 5VMDIR40 0492 VMLINK 5VMDIR40 011F VMLINK 5VMDIR40 041F VMLINK DIRMAINT 01AA VMLINK DIRMAINT 01FA VMLINK DIRMAINT 02AA VMLINK DIRMAINT 0155 VMLINK DIRMAINT 01DF DMSACC048E Invalid filemode S Ready(02024); T=0.01/0.01 16:05:35 I received DMSACC048E Invalid filemode S for the VMLINK DIRMAINT 01DF q disk LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT BL K TOTAL MNT191 191 A R/W 175 3390 4096 121 1459-05 30041 31500 MNT190 190 S R/O 100 3390 4096 704 15293-85 2707 18000 DIR155 127 T R/O 9 3390 4096 10 23-01 1597 1620 DIR1AA 126 U R/O 9 3390 40966 13-01 1607 1620 DRM41F 125 V R/O 8 3390 4096 50642-45798 1440 DIR11F 124 W R/O15 3390 4096 49629-23 2071 2700 DRM492 121 X R/O15 3390 4096 269 1490-55 1210 2700 MNT19E 19E Y/S R/O 250 3390 4096 1779 38956-87 6044 45000 DRM491 120 Z R/O15 3390 4096 259 1410-52 1290 2700 Ready; T=0.01/0.01 16:05:41 I used the version of vmlink created in september 2010 Alain Benveniste
