Re: SFS problem
If I recall correctly, DIAG D4 is the one that manipulates the secondary ID, aka Alternate ID. (SECUSER is an old term). Diag 88 provides the ability to link minidisks and perform userid/password validations (if the issuer has appropriate authority). An interesting usage note for this is that DIAG D4 does not change the userid associated with any existing (already active) SFS connections. This is because it is a CP function and manipulates the VMDBK. Once set, future connections (via APPC/VM Connect) will utilize the Alternate ID. ... This is why severing all connections prior to setting the AltID will fix this type of problem, because CMS will (re) connect and use the AltID. If this is Nora's problem, an easy work around would be wrap the job with an exec that uses DMSGETWU and DMSPUSWU to set a new default work unit that contains the appropriate user, then run the job from the exec, then finally reset with DMSPOPWU. (If I'm remembering all of this correctly) John -- John Hall Safe Software, Inc. 727-608-8799 johnh...@safesoftware.com On Tue, Apr 19, 2011 at 11:48 AM, Schuh, Richard rsc...@visa.com wrote: 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
I do not believe that this is the problem. I was giving you information on the failing job that I am most familiar with. Other jobs that fail are submitted to VMBatch by the ID that also owns the SFS directories. FYI, VMBatch is the IBM VM Batch Facility Version 2.2, I was not aware until recently that there are other products also known as VMBatch. If this has caused confusion, I apologize. 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 John Hall Sent: Wednesday, April 20, 2011 10:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS problem If I recall correctly, DIAG D4 is the one that manipulates the secondary ID, aka Alternate ID. (SECUSER is an old term). Diag 88 provides the ability to link minidisks and perform userid/password validations (if the issuer has appropriate authority). An interesting usage note for this is that DIAG D4 does not change the userid associated with any existing (already active) SFS connections. This is because it is a CP function and manipulates the VMDBK. Once set, future connections (via APPC/VM Connect) will utilize the Alternate ID. ... This is why severing all connections prior to setting the AltID will fix this type of problem, because CMS will (re) connect and use the AltID. If this is Nora's problem, an easy work around would be wrap the job with an exec that uses DMSGETWU and DMSPUSWU to set a new default work unit that contains the appropriate user, then run the job from the exec, then finally reset with DMSPOPWU. (If I'm remembering all of this correctly) John -- John Hall Safe Software, Inc. 727-608-8799 johnh...@safesoftware.com On Tue, Apr 19, 2011 at 11:48 AM, Schuh, Richard rsc...@visa.com wrote: 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
Interesting problem Nora. Nothing recorded in the SFS log either. Please post your POOLDEF statements and your DMSPARMS for the filepool having the problems. Also, what is the virtual storage size defined for the sfs server? Regards, 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. From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Graves Nora E Sent: Wednesday, April 20, 2011 10:17 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS problem I do not believe that this is the problem. I was giving you information on the failing job that I am most familiar with. Other jobs that fail are submitted to VMBatch by the ID that also owns the SFS directories. FYI, VMBatch is the IBM VM Batch Facility Version 2.2, I was not aware until recently that there are other products also known as VMBatch. If this has caused confusion, I apologize. 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 John Hall Sent: Wednesday, April 20, 2011 10:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS problem If I recall correctly, DIAG D4 is the one that manipulates the secondary ID, aka Alternate ID. (SECUSER is an old term). Diag 88 provides the ability to link minidisks and perform userid/password validations (if the issuer has appropriate authority). An interesting usage note for this is that DIAG D4 does not change the userid associated with any existing (already active) SFS connections. This is because it is a CP function and manipulates the VMDBK. Once set, future connections (via APPC/VM Connect) will utilize the Alternate ID. ... This is why severing all connections prior to setting the AltID will fix this type of problem, because CMS will (re) connect and use the AltID. If this is Nora's problem, an easy work around would be wrap the job with an exec that uses DMSGETWU and DMSPUSWU to set a new default work unit that contains the appropriate user, then run the job from the exec, then finally reset with DMSPOPWU. (If I'm remembering all of this correctly) John -- John Hall Safe Software, Inc. 727-608-8799 johnh...@safesoftware.com On Tue, Apr 19, 2011 at 11:48 AM, Schuh, Richard rsc...@visa.com wrote: 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
Nora, Is there ever a case where the command (EXEC, or whatever) fails when it is NOT run in a VMBATCH worker? If they never fail outside of VMBATCH workers, John probably has a good handle on the diagnosis. You may have to read a little bit more in the VMBATCH documentation about how VMBATCH workers get initialized, end, and especially: how the post-job cleanup process works. It might be as simple as changing the program to release the SFS directory before ending (and perhaps examining the connection and looping until it has been cleared). BTW, the other common VMBATCH product is from CA, called VM:Batch. Many moons ago there were other publically available freeware VMBATCH solutions, too -- IIRC, from colleges. 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/20/2011 09:17 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: SFS problem I do not believe that this is the problem. I was giving you information on the failing job that I am most familiar with. Other jobs that fail are submitted to VMBatch by the ID that also owns the SFS directories. FYI, VMBatch is the IBM VM Batch Facility Version 2.2, I was not aware until recently that there are other products also known as VMBatch. If this has caused confusion, I apologize. 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 John Hall Sent: Wednesday, April 20, 2011 10:04 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS problem If I recall correctly, DIAG D4 is the one that manipulates the secondary ID, aka Alternate ID. (SECUSER is an old term). Diag 88 provides the ability to link minidisks and perform userid/password validations (if the issuer has appropriate authority). An interesting usage note for this is that DIAG D4 does not change the userid associated with any existing (already active) SFS connections. This is because it is a CP function and manipulates the VMDBK. Once set, future connections (via APPC/VM Connect) will utilize the Alternate ID. ... This is why severing all connections prior to setting the AltID will fix this type of problem, because CMS will (re) connect and use the AltID. If this is Nora's problem, an easy work around would be wrap the job with an exec that uses DMSGETWU and DMSPUSWU to set a new default work unit that contains the appropriate user, then run the job from the exec, then finally reset with DMSPOPWU. (If I'm remembering all of this correctly) John -- John Hall Safe Software, Inc. 727-608-8799 johnh...@safesoftware.com On Tue, Apr 19, 2011 at 11:48 AM, Schuh, Richard rsc...@visa.com wrote: 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). 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
Thank you, yes, that is correct... Apologies for mixing my terms. I should have been saying Alternate ID. John On Wed, Apr 20, 2011 at 12:33 PM, Schuh, Richard rsc...@visa.com wrote: Actually, SECUSER still exists and is something quite different. SECUSER defines a secondary user for receiving console messages and entering commands and responses. The entries are done as though they came from, not on behalf of, the user. Regards, Richard Schuh -- *From:* The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] *On Behalf Of *John Hall *Sent:* Wednesday, April 20, 2011 7:04 AM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* Re: SFS problem If I recall correctly, DIAG D4 is the one that manipulates the secondary ID, aka Alternate ID. (SECUSER is an old term). Diag 88 provides the ability to link minidisks and perform userid/password validations (if the issuer has appropriate authority). An interesting usage note for this is that DIAG D4 does not change the userid associated with any existing (already active) SFS connections. This is because it is a CP function and manipulates the VMDBK. Once set, future connections (via APPC/VM Connect) will utilize the Alternate ID. ... This is why severing all connections prior to setting the AltID will fix this type of problem, because CMS will (re) connect and use the AltID. If this is Nora's problem, an easy work around would be wrap the job with an exec that uses DMSGETWU and DMSPUSWU to set a new default work unit that contains the appropriate user, then run the job from the exec, then finally reset with DMSPOPWU. (If I'm remembering all of this correctly) John -- John Hall Safe Software, Inc. 727-608-8799 johnh...@safesoftware.com On Tue, Apr 19, 2011 at 11:48 AM, Schuh, Richard rsc...@visa.com wrote: 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
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
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: 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: 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
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 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: SFS problem
Would issuing a QUERY AUTHORITY at the time of the error give anything useful, I wonder. Maybe try for both the directory and the file? Peter -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Graves Nora E Sent: April 14, 2011 15:46 To: IBMVM@LISTSERV.UARK.EDU 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 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 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner.
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 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 The information
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
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
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.
