4.8 Managing the portal environment

< Day Day Up >

In this section we provide some information about areas that we found important for consideration when managing WebSphere Portal Server on z/OS. Some of these areas have already been covered in previous sections or other chapters, but they are collected together here for reference:

Portlet deployment is disruptive to the server as discussed in 6.1, "Portlet development" on page 182 and 4.7, "Managing Portlets in z/OS" on page 141.
Portlet deployment uses the Systems Management API (SMAPI) which can have unforeseen side-effects with administrators also using SMEUI to perform updates to the Application Server.

For example lets say one systems administrator is using SMEUI to modify either the same portal server region, or another J2EE application running in a different server region on the same application server. To do this they will have created a new conversation using SMEUI, made some configuration changes, validated and committed the conversation.

If at the same time this has been happening, another systems administrator deploys a portlet, and since the deployment process also uses SMAPI it is possible for the deployment process to create a new conversation after the creation of the conversation done by the administrator using SMEUI.

The unfortunate side-effect of this will be that the administrator using SMEUI will not be able to activate their conversation and configuration changes, because the conversation that the changes were modelled on have been replaced by the conversation used to deploy the portlet(s).
A deployed portlet is installed as a J2EE application (EAR file) running on the Portal Server. Therefore, environment variables for the J2EE server and modifications to the installed EAR files can be done from the SMEUI Administrative GUI (Figure 4-17 on page 144).

Figure 4-17: SMEUI Administrative functions for Portal J2EE applications

SMEUI can be used to define new environment variables to be used by new portlets that require additional classes/jars to be added to the J2EE container.

However, we do not recommend that administrators use the SMEUI to manage individual J2EE Portlet Applications, because this is normally managed via the deployment process. In the case of an error however, for example, updating a portlet using a different WAR file name, which, as described in 4.7.1, "Updating portlets" on page 142, is not supported, then the orphan or defunct EARs can be deleted using SMEUI. Figure 4-17 on page 144 shows SMEUI Administration with a list of installed J2EE Portlet applications and the J2EE server environment variables.
The Portal log needs to be managed.

As noted in 4.5, "Log Files" on page 136 the portal log is a series of time stamped files created in a directory in the HFS. These log files are not automatically deleted after a period of time, so administrative procedures need to be in place to manage their growth.
Portal configuration files are maintained in ASCII.

Many of the portal configuration files, for example, files located in <WPS_PATH>/libapp/config are in ASCII and are not viewable or editable from TSO ISH or USS. IBM provides a number of free z/OS tools for download, including an ASCII editor available at:

http://www-1.ibm.com/servers/eserver/zseries/zos/unix/bpxa1ty2.html
Need to manage file attributes, owner, group, permissions, if using USS.

Some operations in the portal require the creation and update of directories and files in the HFS. The directory file permissions, including owner and group need to be preserved across manual changes or some portal functions will not work correctly.
Administrative and Operations control of the Portal Server, for J2EE configuration and start/stop of the server region, can be controlled in the usual way for any WebSphere Application Server z/OS application by using the SMEUI tool from a workstation. Figure 4-18 shows an example of using SMEUI Operations to start the Portal server region on our system.

Figure 4-18: Using SMEUI Operations to start the Portal server

< Day Day Up >