When a user server address space had allocated a port and doesn't terminate properly or port ranges were invalidly defined, then it can happen that a port is not available to a newly started user server address space. If that port was the first in the range of the scheduler, this could mean that no user server could get started anymore. With port skip active (PORTCHECK="1" set in the scheduler configuration parameters), z/Server tests the availability of the port. If it is already in use by someone, the message:
+SLR0055E [001] Port [002] is not available.
+SLR0135S [001] Port [002] for z/Server scheduler [003] locked because port was not available.
In this context, "port is not available" means that TCPIP returned a response of "the port is in use and has the state LISTEN". There is an entry in the user administration control structures of z/Server for every port defined to the scheduler. The entry that was not available is now marked as LOCKED and will not be used any longer to allocate conversations with a client. This can be displayed by using the command:
F <holder>,display,dsp,format
IN the DD named DSPPRT of the holder task the following output can be found:
-------------------------------------- Userid JobName JobId SYS Port -------------------------------------- user jobname jobid system nnnnn
If a user server has stalled and not terminated and hence still has the port allocated, it needs to get terminated, probably via an operator force arm or force command. That will make the port available for reuse. The port is still in a "locked" state in the user administration part of z/Server, however. It needs to be unlocked manually using the command
F <scheduler>,TSO,UNLOCK,PORT=nnnnn
This cleans up the LOCKED state of the port entry, and the port can be used again by the scheduler.
If the port was not allocated to a stalled user server, then the system administrator needs to determine who has the port allocated (i.e. netstat command). There is probably some sort of definition error in the port ranges for this scheduler/holder that needs to get corrected. If ports were defined incorrectly to the scheduler/holder, the scheduler/holder will need to be restarted with the corrected definitions.
If you only unlock the port in the user administration without first making sure that it really is available to be allocated again, port skip will immediately issue messages SLR0055E and SLR0135S again and relock the port in the user administration control structures.