In some cases, e.g. when system errors occur, it may not be possible to unload the subsystems. This may be due to the following reasons:
The subsystem is in a LOCKED state, since the associated holder task can no longer be used, e.g. after a system dump.
The subsystem cannot be unloaded because some tasks are still connected. This typically occurs when FT cannot be exited (the tasks with the TSNs FTC* and the FT server tasks (job name FTSP) do not disappear) when connected tasks enter permanent wait states, or when tasks are “permanently pending” after system dumps due to insufficient disk space.
In such exceptional cases, the system administrator can resort to some special resources to unload the subsystems and thus save the BS2000 session. These resources are described in the DSSM manual. The following points discuss some of the aspects to be observed when unloading the FT subsystems.
There is always a certain risk involved in using any such resources. There is essentially no way of guaranteeing that all error states are fully described here. The ultimate responsibility always lies with the system administrator!
A subsystem in a LOCKED state can be removed from the system by using the command /UNLOCK-SUBSYSTEM. Note, however, that this does not call the subsystem-specific uninstallation routine and therefore has the following consequences for the FT subsystem:
No file locks held by FT are released, so all user files locked by FT will remain locked. These locks can be removed explicitly by the system administrator with REMOVE-FILE-ALLOCATION-LOCKS or will disappear implicitly at the next BS2000 startup.
A subsystem to which tasks are still connected can be unloaded with /STOP-SUBSYSTEM FORCE=YES if required, provided the attribute FORCED=ALLOWED is first assigned with the command /MOD-SUBSYSTEM-PARAMETERS. By default, FT subsystems do not have this attribute.
This approach causes any restarted tasks that are still connected to run onto a system dump. Such system dumps are of no use whatsoever for any diagnostic purposes and may hence be discarded. FT tasks which are still connected and which blocked in a waiting state will run within at most 10 minutes onto the system dump.
The subsystem should never be restarted as long as there are existing tasks which were still connected at the time of forcing the subsystems to unload!