Why and when to perform this task
WebSphere Application Server V3.5 Standard Edition for z/OS and OS/390 maintains an Application Server class loader that is global to the JVM. The class loaders work differently in V5 or higher. Each application can have its own class loader, depending on the values chosen when the application and Web modules are installed.The Application Server class loader serves as the parent to all of the Web application class loaders. The default search mode used when locating a class to load is "Parent First". In Parent First mode, the servlet engine first attempts to locate the specified class in the parent class loader or load it from one of the libraries or directories supported by that class loader. In the case where a Web application is being loaded, the servlet engine will first search the application level class loader for the target class. If not found, the servlet engine will then proceed to locate the class in the Web application specific class loader or from one of the libraries or directories specified in the deployedwebapp.web_app_name classpath directive for that Web application.
The application server classpath is used to specify classes that are used by multiple Web applications such as utility functions. The Web application contains the artifacts that are to be referenced by a single Web application. Web Applications do not have access to artifacts that are packaged with another Web application.
In V3.5, any text based files (properties or resource bundles) that are loaded from an open directory by the Application Level class loader are required to be encoded in EBCDIC. This anomaly no longer exists in V5 or higher. All property files and resource bundles are required to be encoded as US ASCII with no exception.
The technique for specifying a class loader policy is more robust in V5 or higher. Migrating the class loader Module Visibility Mode describes how to specify these policies in V5 or higher.