Description
The File Manager SET function is used to change various File Manager options that affect the processing of other File Manager functions. It can RESET the options, which sets them all to the current defaults as defined in the File Manager options table. And per the documentation, it is supposed to be able to LIST the processing options currently in effect, but that doesn’t actually work.
When SET is used in a File Manager batch job, it has local effect: it only affects the subsequent batch functions. SET can also be used in “keyword” mode (e.g. “FILEMGR $SET”), which sets the File Manger processing options in the ISPF profile for the current application, which may or many not be File Manager. Processing options are destructive and persistent: if SET is used this way in a File Manager application, they change that application’s settings and affect future File Manager functions, both via ISPF menus or other File Manager keyword functions. If used this way in a different application, they affect any future File Manager functions executed in that application.
Keyword mode is of particular interest, since for certain File Manager options, the SET command is the only way to execute other File Manager functions with the desired processing modes. For example, let’s say a developer wants to use a File Manager function in keyword mode from within an exec (address TSO “FILEMGR $function”) and wants the output to go a REXX stem variable. This is controlled by the PRINTOUT option, but that option can only be set by the SET function. If the developer just executes the File Manager function, the PRINTOUT option’s value would not be known; it could have been changed by some previous command. So, the developer would need to first do address TSO “FILEMGR $SET PRINTOUT=REXX”, but that would change this option in the application going forward. The same goes for any of the other processing options that affect function behavior. And, if the exec is executed in File Manager’s application (which in some cases it must be for proper functionality), using SET could change the user’s settings.
Therefore, this Idea is to add some additional keyword options to the SET function:
LIST: SET LIST would list the current values of all of the SET processing options:
SET with no other values would default to SET LIST, i.e. SET by itself would just list the options
SET with some other parm (e.g. SET HEADERPG=NO) would default to NOLIST
SET LIST with or without other parms would list the options in addition to other processing. For example, SET LIST,PAGESIZE=50 would set the pagesize to 50 and then list the options
EXPORT: SET EXPORT would save the current processing options in a form that is machine-readable, e.g. could be processed by an exec.
SAVE and RESTORE: As mentioned above, using SET as a keyword instruction is destructive and persistent; it changes whatever the current option in the profile is, even though the developer may just want to change it for the use by one function execution. SAVE and RESTORE would save the current settings, and RESTORE would restore them. (How they are saved and restored is up to IBM – perhaps there is just one command for SAVE/EXPORT, and RESTORE restored form the exported version.)
DELETE: There is a RESET option, but what it does is actually SET all the options to their current defaults. This “bakes” the options in; if the options table is later changed, the new defaults won’t be used. What SET DELETE would do (or some other keyword to this effect) is delete all of the processing options from the profile so that the next File Manager function starts from scratch.
Use Case
An example use case is when an exec uses a File Manager function and wants to use a particular processing option, but doesn’t want to have it permanently affect the profile. And perhaps this exec needs to operate regardless of the current ISPF application; either it is constrained to work with a particular application, or needs to always be in File Manager’s application, or needs to be application-agnostic – whatever they case, trying to use some application to workaround the “destructive & persistent” issue is not an option.
With the new SET subcommands, the exec could do:
address TSO
“FILEMGR $SET SAVE”
“FILEMGR $SET HEADERPG=NO,PRINTOUT=REXX”
“FILEMGR $some function…”
“FILEMGR $SET RESTORE”
Process result…
Note that this is similar in concept to the existing ISPF services that are used to preserve and restore dialog processing state.
Idea History
Case opened due to problems hit in SET processing
5/13/2021: RFE 150478 submitted
RFE 150478 was system-migrated to FMZOS-I-469
6/12/2025 : Idea FMZOS-I-469 closed due to age. At the time it was closed it had 4 votes.
6/18/2025: Resubmitted as this idea.
