You may decide to restart the SMSPDSE1 address space to try to
correct system problems due to a problem in PDSE processing. Before
doing so, however, you should be aware this action could result in
failures of currently running jobs and TSO sessions that are accessing
PDSEs. In addition, you should note the following restrictions and
limitations:
- The SMSPDSE1 address space restart might not work correctly if
more than one SMSPDSE1 address space restart is attempted concurrently
because of the xQUIESCE time interval that is initiated by the restarting
SMSPDSE1. If a SMSPDSE1 restart is performed on more than one system
at the same time, then these restarting systems will not get the benefit
of the other systems' xQUIESCE time duration interval.
- If the SMSPDSE1 address space terminates as a result of a hard
failure or because of the FORCE command, then the results of a PDSE
address space restart are unpredictable. Some undesirable effects
that could result from a FORCE command are:
- If a member is deleted while SMSPDSE1 is down, then a reconnection
to that member will fail.
- If a user on another system opens for update when the restartable
connection had a data set open for read/write, the restart connection
will fail.
- If the user address space fails to reconnect after the SMSPDSE1
address space restarts, then the user address space should be forced
off of the system.
- The restart of the SMSPDSE1 address space could result either
in a loss of some SMF I/O counts or in duplicate counts.
- If you used the VARY SMS,PDSE1,MONITOR command to change the PDSE
MONITOR values and the SMSPDSE1 address space is restarted, then the
values provided either by system defaults or by the MONITOR values
specified in the IGDSMSxx member of SYS1.PARMLIB will be
used to restart the PDSE1 MONITOR.
- If callers that do not use the standard PDSE interface are connected,
then PDSE will not know that the connection is active (and not behaving
as expected). At this time there are no known callers of PDSE that
fit this criteria.