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.gov>wrote: > 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 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 >> >> > > > > -- > Kris Buelens, > IBM Belgium, VM customer support >
