Considerations for Files in Shared File System Directories
OS/MVS data can be stored in a Shared File System directory and
manipulated through OS simulation. Here are some special considerations
to make note of when updating OS/MVS data that resides on shared file
directories:
- As long as no read/write sharing is taking place (for example, one user reads a file while another user writes to it), the version of all data sets is guaranteed to remain constant to the OS application. Only those changes made by the application itself will be seen. This guarantee does not exist for a read/write sharing environment.
- All shared file directories that are used for output by an OS application must be accessed as R/W.
- Unpredictable results may occur if the default SFS work unit is changed during the execution of a program that uses OS simulation. Also, if a file used by an OS simulation application is already open (through FSOPEN, EXECIO, or a previous OS OPEN) at entry to that application and the default work unit on which the file was opened is different from that used during the application, unpredictable results may occur if the application closes and then reopens the file.
- If an application opens a data set whose FILEDEF specifies a file mode of * for output, OS simulation will search all R/W file modes for the file. If it finds the file on any of those file modes, it will use the first occurrence of the file. Otherwise, OS simulation will create a new file with mode A1 when the application does the first write to the file.
- Each time a CLOSE is issued for a DASD DCB without the TYPE=T parameter, the file represented by that DCB will have FINIS issued for it.
- When you execute programs with OS macros that write to SFS files, you should ensure that there is an ample supply of unused blocks in the file space to which you are writing. Otherwise, your program could abnormally end when your program tries to close the file. You might also consider limiting write access to the file space so that other users do not consume the blocks you require for your application.
- If your application uses OS/MVS queued sequential access method (QSAM) to update SFS files, be sure to erase all data from the buffers (for example, close the files) before issuing a commit. This may be required because of QSAM buffering. For example, if a program uses OS/MVS QSAM with blocked records for an SFS output file, some of the most recently written output records may not be committed if the program issues a commit without first closing the QSAM file. These records will subsequently be committed when the program closes the file and either commits the work unit or allows end-of-command processing to commit the work unit. Using only FS macros to write to SFS files avoids this situation.
- An OS Simulation WRITE/PUT to a file in an SFS server will generally receive a disk full error when the SFS file space limit is exceeded. However, an OS Simulation WRITE/PUT to a file in an SFS server running at release levels prior to Release 2.1 will detect a disk full condition when the file space threshold is exceeded.