Temporary Space

SFS file space and minidisk space are handled differently in CMS. For example, if you have a program that writes intermediate files on a user's minidisk, you have to be sure there is enough minidisk space to hold the file or obtain temporary minidisk space. In SFS, the file space allocated to each user is considered committed space. Because you can use space above your allocated space until you commit, your program can write files and close them, but not commit the files. You can then reopen the file and read the uncommitted updates, and continue processing.

If your application is written using SFS routines, and it is unable to commit a work unit because file space limits have been exceeded, the commit failure will not automatically cause activity on the work unit to be either committed or rolled back. Your application must either delete unneeded file blocks that are above the file space limit and attempt to commit the work again, or explicitly roll back the changes if there is not sufficient space to hold them.

If your application does not use CSL routines to update SFS files, an error will be returned for a write operation when the SFS file space limit is detected. In an environment where files are not shared, you should have enough space to close and commit all updated files. In an environment where there is sharing, updates on the work unit will be rolled back if the SFS file space limit is exceeded when the files are closed and changes are committed.

In either case, you could lose some of the changes you intended to be permanent if temporary changes and permanent changes are on the same logical unit of work. Keep in mind that this may happen even if the file is nonrecoverable.

Your installation may have established a storage policy and installed a file space usage exit that may prevent or limit overuse of uncommitted space. Contact your file pool administrator for details.