I've had similar issues before. There are really two choices you can make. The first is to open a PMR and do traces and such. Since it's a very intermittent failure, this can be difficult. The other is to make the user doing the writes a filepool administrator and get on with life. Mgmt chose the latter.
-----Original Message----- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Graves Nora E Sent: Tuesday, April 19, 2011 7:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: 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 XXXXXX 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 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.
