Systems running the FTP server that provide the FTCHKCMD. FTPOSTPR, or FTCHKJES exit routines can experience ABENDs or other unusual conditions. This is especially likely to occur after applying maintenance or upgrading the z/OS release level, but can also be from newly created or installed exit routines.
The most likely symptom is an S0C4 ABEND when attempting to access a control block created by the FTCHKCMD exit routine. But other unpredictable results are also possible.
The PTFs for APAR PM59618 (included in the base for z/OS 2.1) provide a fix to ensure that any changes made to the supplied scratch pad area before the USER and PASS commands are processed (before switching to the user's authority) would still be available in subsequent invocations of these exits. However, no control blocks created in the address space (private storage) by these exits will be carried across that authority switch, so any pointers to those areas that are stored in the scratch pad will be unusable.
Resolving the problem
Update the FTCHKCMD exit routine to do one of the following:
- Not create any such data areas until after the server has switched to the session's userid.
- Recognize when a userid switch will be performed and remove any pointers to private memory areas that are in the scratch pad.
Note: Neither of these actions will result in a loss of function that had been previously provided by these exits. Any data areas created before the userid switch have always deleted, the difference is that before the PTF (or upgrade) the scratch pad area was also deleted.
- Allocate the data areas in common storage, if you are certain that these exits will only be used on systems with the PTFs applied. But in doing this, you will also need to provide a mechanism to ensure that these areas are later released (even if the server address space ABENDs).
Note: Be sure to use a system key (0-7) for any such areas. If sensitive information is stored in these control blocks, a fetch protected subpool (such as 231) should also be used.