Performance considerations
When you specify edit, File-AID loads the data set/member (or selected subset of the data set/member) into virtual storage where the data is updated during edit operations.
If sufficient storage is unavailable, the edit session is terminated with an error display that gives the number of records that were successfully read before storage was exhausted. It may be possible to successfully edit the data set by specifying selection criteria information on the Edit - Data set Specification screen which brings a subset of the entire file into virtual storage.
Limitations for editing data sets
The following table describes edit limitations by data set type.
Edit Option Limitations for Data sets
Data set type | Selection Criteria | Description |
|---|---|---|
Ordinary Sequential (Standard Edit) | NO | No limitations. |
Sequential (Standard Edit) | YES | The workfile allocation (set on System-Parameters) must be large enough to create a workfile equal in size to the data being edited. The M (Move) line command and SORT primary command are not valid. |
Sequential (64-bit Memory Mode) | NO | |
Hardware-Compressed Sequential (Standard Edit) | YES | The workfile allocation (set on System-Parameters) must be large enough to create a workfile equal in size to the data being edited. The M (Move) line command and SORT primary command are not valid. |
Hardware-Compressed Sequential (64-bit Memory Mode) | NO | |
Partitioned | N/A | Each member is treated as a sequential data set. |
Keyed | NO | Keyed records can be duplicated. However, a data set may not be saved while there are duplicate keys or key sequence errors. All record keys are initially protected. A key cannot be altered by a CHANGE command, data shifting, or overtyping unless the record key is unprotected with an unprotect (U) line command. |
Keyed (Standard Edit) | YES | Records can be inserted or deleted. Initially, all keys are protected, and all keys are protected after a successful SAVE. Keys on newly created records are unprotected, but they can be protected with the P (protect) line command. Only keys on newly created records can be unprotected (U line command). A key cannot be altered unless unprotected. When a SAVE is issued, File-AID checks for duplicate keys or sequential errors. If errors are found, each is flagged and the SAVE is rejected. |
Keyed (64-bit Memory Mode) | NO | Records can be inserted or deleted. See Editing VSAM Files in 64-bit Memory Mode, Edit in 64-bit Memory Mode — Primary Command Availability, and 64-bit Memory Mode Edit Line Commands. |
Indexed Sequential | N/A | Same limitations as keyed data sets. If the data set was allocated with code L, deleted records are logically deleted by placing a hexadecimal byte of 'FF’ in the first data position. If the data set was not allocated with option code L, the records cannot be deleted. |
VSAM ESDS | NO | Non-reusable data sets have the same limitations as described in the next table entry (VSAM ESDS with Selection Criteria = Yes). Otherwise, no limitations. |
VSAM ESDS | YES | A VSAM ESDS is edited as a sequential file. Records cannot be inserted, deleted, or sorted. Allows changes only to existing records. 64-bit Memory Mode is not supported. |
VSAM KSDS | NO | Non-reusable data sets have the same limitations as described in the table entry for Keyed data sets with Selection Criteria = Yes; reusable data sets have the same limitations as described in the table entry for Keyed data sets with Selection Criteria = No. |
VSAM KSDS | NO | See Editing VSAM Files in 64-bit Memory Mode. Non-reusable data sets have the same limitations as described in the table entry for Keyed data sets with Selection Criteria = Yes; reusable data sets have the same limitations as described in the table entry for Keyed data sets with Selection Criteria = No. |
VSAM KSDS | YES | Same limitations as keyed data sets. |
VSAM RRDS | Edit supported for fixed VSAM RRDS; not supported for variable VSAM RRDS. | |
BDAM | Edit supported for fixed BDAM; not supported for variable BDAM. |
Update-In-Place Restrictions
File-AID employs an update-in-place edit method for data sets that cannot be opened for load. As a result, some line and primary commands are restricted.
The update-in-place is employed for the following data set types:
- Non-reusable VSAM data sets (ESDS and RRDS) or DISP=SHR (with or without selection criteria)
- Reusable VSAM ESDS or KSDS with selection criteria (DISP=OLD)
- BDAM and RECFM=U (load module) PDS member
- Backwards processing
- Multi-volume file when you specify a volume serial number.
This causes File-AID to restrict the use of the following line and primary commands:
- I (Insert), D (Delete), C (Copy), M (Move), and R (Repeat) line commands
- COPY, DELETE, SORT, REPEAT, INSERT, PRESERVE OFF, and PROTECT OFF primary commands.
In addition, the following update-in-place restrictions apply for the following data set types:
- Non-reusable VSAM KSDS or DISP=SHR (restricts only U (Unprotect))
- Sequential with selection criteria (restricts only M (Move) and SORT).
Editing with DISP=SHR: a Warning
Whenever you edit a sequential data set or ESDS, whether with Standard Edit or 64-bit Memory Mode, the entire data set is copied into a work area at the beginning of the edit session. This work area can be either in memory or in a work file on disk. At the end of the edit session, when the data set is saved, the entire data set is replaced by a copy of the contents of your work area. (If you use 64-bit Memory Mode edit, or an update-in-place edit, only a portion of the data is saved in any one save operation.)
We recommend that you specify DISP as OLD whenever possible when updating any file. If you cannot avoid the need to specify a DISPosition of SHR (share), you should ensure that only one user or process is able to update the file, with others limited to READ ONLY access.
Whenever you specify a DISPosition of SHR (share) when editing, it is possible for some other process, such as a batch job or an online system, to update the same data set that you are editing, and to do it during your edit session. Any changes made by such a process will be overwritten when the entire data set from your work area is written back to the original data set. If the two updates take place simultaneously, results are unpredictable, so that your data set may end up containing either version of the data or containing an interleaved version with some changes from each of the processes.
Some processes, such as editing a data set or link-editing a load module, issue ENQ reserves to lock out other similar processes from simultaneous updates. So, for example, one ISPF or File-AID/MVS Edit session would lock out another such Edit session, even with DISP=SHR. However, this type of lockout does not protect against simultaneous updates by unrelated processes such as batch utility programs. So an IEBGENER job, for example, could easily overwrite your sequential data set at the same time as you edit it, if both specify DISP=SHR.
If your situation dictates that you need to edit a file while it is allocated to some started task, batch job, online system (such as CICS), another LPAR not connected by GRS, or any other process, if you cannot deallocate the file temporarily from that other use, be sure that another user is only accessing the file in READ ONLY mode, and that any updates that might have been done earlier have been physically written to the file on disk (for example, some systems let you do this by closing and then reopening the file). If you are going to allow the other process to update the file after you complete your edit session, you will first need to refresh its buffers again with your updated data, for example by closing and reopening the file a second time for a system or process where that option works.
This warning applies anytime two separate unlike processes, involving File-AID/MVS or not, update the same sequential file or ESDS concurrently using DISP=SHR.
In many cases other kinds of data sets have the same exposure; for example, a PDS member is often processed the same as if it were an ordinary sequential file.
Storage Management
File-AID attempts to read the entire data set or member into your user region when NO Selection Criteria is specified. For edit, if there is not sufficient storage to hold all records in 31-bit Memory Mode, File-AID switches to 64-bit Memory Mode, unless the file type is not supported in 64-bit Memory Mode. When 64-bit Memory Mode is not supported, File-AID displays an error message for INSUFFICIENT MEMORY.
If this should occur, use the HELP command (PF1) to find the number of records that File-AID read before memory was exhausted. Then, logon with a larger region size, or use selection criteria to select a portion of the data set that will fit in available memory.
If modifications to the data set require more memory and File-AID cannot obtain sufficient memory to hold the changes, File-AID stops processing and displays the Edit screen with an insufficient memory error. Any modifications made since the last SAVE are lost.
When Selection Criteria is used, Edit is restricted to 31-bit Memory Mode and reads only a portion of the data into memory. On a sequential data set, File-AID makes a copy of the edit data set in a work file. This practice allows File-AID to make insertions and deletions.
However, the use of the work file does not reduce the storage requirements; sufficient memory must be available to hold all of your selected records. If the work file is not large enough to hold a copy of the edit data set, a B37 abend is detected. If this happens, use the File-AID System Parameters screen option (0.1) to increase the size of the work file.