For example, suppose the new level 1 release of a server supports all the old level 0 functionality. When it starts, it indicates that it supports server levels 0 to 1. The clients running in the sysplex might not yet have been upgraded to understand server level 1, so they continue to request server level 0 for their requests. Since the new level 1 server supports server level 0 functionality as well, the new level 1 server can process those requests. If there was both a level 0 and a level 1 server instance running, either one is suitable for such requests.

If the new level 1 server is not compatible with the level 0 server protocols or function, it indicates that it supports only server level 1. Suppose older versions of the clients are running in the sysplex. They are unaware of server level 1 and thus do not know that server level 1 is incompatible with their request. However, being down level, they are still specifying server level 0 for their requests. Because the new level 1 server does not support server level 0 requests, it is not considered to be a suitable server for these requests. Any such level 0 requests need to be processed by a server that supports level 0 requests.

This usage might allow, for example, two different product releases to coexist at the same time. The server level ensures that the requests from old clients are processed by old servers, and new requests are processed by new servers even if both releases used the same server names.

You might also use the server name to ensure that requests are processed by a suitable server. If a new release changes the server names, the new server only receives requests from clients that have been upgraded to target requests to servers using the new names. There is no need to change the supported server levels in this scenario, or alternatively, you can reset them to 0.