If your back-level version of WebSphere Application Server is using the unrestricted jurisdiction policy files, you must perform the following special step to migrate these files to your new version of WebSphere Application Server. If you are not using the unrestricted jurisdiction policy files, you do not need to take the following step.
Before migrating, copy the modified local_policy.jar file to a temporary location.
The z/OS Migration Management Tool has created jobs based on the information that you provided. These instructions tell you how to modify the operating system and run the jobs to migrate WebSphere Application Server for z/OS. When you upload the migration definition to the target system, a text version of these instructions will be written to:
${zTargetHLQ}.CNTL(BBOMDINS)
${zTargetHLQ}.CNTL
${zTargetHLQ}.DATA
Before proceeding to execute any jobs, ensure the above datasets have been defined with the correct characteristics.
The ${zTargetHLQ}.CNTL datasets should be defined with the following characterists: PRIMARY=15 SECONDARY=15 TRACKS LRECL=80 BLKSIZE=8000 DIRECTORY=30 RECFM=FB
Also ensure that the ${zTargetHLQ}.DATA datasets have been defined with the following characteristics: PRIMARY=5 SECONDARY=5 TRACKS LRECL=255 BLKSIZE=0 DIRECTORY=30 RECFM=VB
The z/OS Migration Management Tool for WebSphere Application Server for z/OS does not attempt to update configuration data for your base operating system or existing subsystems. You must take the following manual steps before running the WebSphere Application Server for z/OS migration jobs. Because you are migrating an existing system, some of these steps might have already been taken in your previous installation.
${zConfigHfsName}
mounted at:
${zmbToConfigRoot}
in read and write mode.
For example:
MOUNT FILESYSTEM('${zConfigHfsName}')
MOUNTPOINT('${zmbToConfigRoot}')
TYPE(${zFilesystemType})
MODE(RDWR)
If you are configuring in a sysplex environment, you might want to add the NOAUTOMOVE parameter as follows:
MOUNT FILESYSTEM('${zConfigHfsName}')
MOUNTPOINT('${zmbToConfigRoot}')
TYPE(${zFilesystemType})
MODE(RDWR) SYSNAME(<system_name>) NOAUTOMOVE
The NOAUTOMOVE parameter in this example prevents the configuration file system from being mounted on a different z/OS system in a shared file system configuration, which could cause performance problems. Replace <system_name> with the applicable system name for your installation.
Alternatively, once the customization jobs are uploaded to the target z/OS system, you may append the contents of the following paritioned data set member to the SCHEDxx member:
${zTargetHLQ}.CNTL(BBOSCHED)
Note: When you are finished updating SCHEDxx, issue the command
SET SCH=xx to activate SCHEDxx and load a new program properties
table. This action does not need to be performed if the target z/OS system is
at z/OS 1.9 or above, as the BPXBATA2 entry that the BBOSCHED member contains
already exists in the IBM-supplied PPT table at those z/OS levels.
Language Environment SCEERUN
SCEERUN2
System SSL SIEALNKE (z/OS 1.6 and above)
64-bit Support Code SCLBDLL2
Placing these data sets in the link list or link pack area improves performance and insulates your WebSphere Application Server for z/OS configuration from changes in data set names (for example, when migrating to z/OS 1.6).
If the Language Environment or System SSL load module libraries are not in your system link list or link pack area, take the following steps before starting any WebSphere Application Server for z/OS servers:
If you use RACF for your security system, use the following instructions. If you use another SAF-compliant security system, contact the security system vendor for appropriate information.
Check your MVS system log or use the TSO RLIST STARTED command to determine the user ID and group under which your previous daemon runs. (The previous default daemon user ID and group are WSDMNCR1 and WSCFG1.) Then issue the following RACF command to create a corresponding STARTED profile for the Version 8.0 daemon cataloged procedure:
RDEFINE STARTED ${zmbDaemonProcName}.*
STDATA(USER(user) GROUP(group) TRACE(YES))
SETROPTS RACLIST(STARTED) GENERIC(STARTED) REFRESH
Check your MVS system log or use the TSO RLIST STARTED command to determine the user ID and group under which your previous deployment manager controller runs. (The previous default deployment manager controller user ID and group are ASCR1 and WSCFG1.) Then, issue the following RACF command to create a corresponding STARTED profile for the Version 8.0 deployment manager controller cataloged procedure:
RDEFINE STARTED ${zmbControllerProcName}.*
STDATA(USER(user) GROUP(group) TRACE(YES))
SETROPTS RACLIST(STARTED) GENERIC(STARTED) REFRESH
Because the STARTED profile for the deployment manager servant is based only on the job name, no additional STARTED profile should be needed for the deployment manager servant, which has the same job name before and after migration.
If you use RACF for your security system, use the following instructions. If you use another SAF-compliant security system, contact the security system vendor for appropriate information.
If the cell is being migrated from Version 6.0.x or previous and it uses SAF authorization, create the following SAF profile and grant READ access to the deployment manager control region user ID.
BBO.TRUSTEDAPPS.<cell_shortname>.**
Use the following RACF commands to accomplish this.
RDEFINE FACILITY
BBO.TRUSTEDAPPS.<cell_shortname>.**
UACC(NONE)
PERMIT BBO.TRUSTEDAPPS.<cell_shortname>.**
CLASS(FACILITY) ID(<config_group>) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
The new SAF profile must be created before servers are started at Version 8.0.
If the cell being migrated uses SAF authorization for EJB roles, create EJBROLE profiles for the deployer and adminsecuritymanager roles (which were added in Version 6.1). Use the following RACF commands to create the profiles:
RDEFINE EJBROLE (optionalSAFProfilePrefix.)deployer
UACC(NONE)
RDEFINE EJBROLE (optionalSAFProfilePrefix.)adminsecuritymanager
UACC(NONE)
SETROPTS RACLIST(EJBROLE) REFRESH
The adminsecuritymanager role must be granted to any administrator who needs to update WebSphere Application Server console users and groups (for example, in preparation for an LDAP or custom user registry with non-SAF authorization). The administrator user ID created during configuration should usually be granted this role:
PERMIT (optionalSAFProfilePrefix.)adminsecuritymanager
CLASS(EJBROLE) ID(WSADMIN) ACCESS(READ)
SETROPTS RACLIST(EJBROLE) REFRESH
If the cell being migrated uses SAF authorization for EJB roles, you might need to create an EJBROLE profile for the auditor role that was added in Version 7.0. Use the following RACF commands to create the profile:
RDEFINE EJBROLE (optionalSAFProfilePrefix.)auditor
UACC(NONE)
SETROPTS RACLIST(EJBROLE) REFRESH
The auditor role should be granted to users who need to view and modify the configuration settings for the security auditing subsystem. The administrator user ID created during configuration should usually be granted this role:
PERMIT (optionalSAFProfilePrefix.)auditor
CLASS(EJBROLE) ID(WSADMIN) ACCESS(READ)
SETROPTS RACLIST(EJBROLE) REFRESH
The z/OS Migration Management Tool built a number of batch jobs with the variables that you supplied. You must run the jobs in the order listed below using user IDs with the appropriate authority.
Note: Whenever "file system update authority" is indicated, the user ID used to run the configuration job must have either uid = 0 or the following UNIXPRIV class profile privileges:
CONTROL access to SUPERUSER.FILESYS UPDATE access to SUPERUSER.FILESYS.MOUNT READ access to SUPERUSER.FILESYS.CHOWN READ access to SUPERUSER.FILESYS.CHANGEPERMS READ access to SUPERUSER.FILESYS.PFSCTL
If the UNIXPRIV profile CHOWN.UNRESTRICTED is defined, then the SUPERUSER.FILESYS.CHOWN is not required. For information about the UNIXPRIV class, see the z/OS Unix System Services Planning book.
Before you begin, complete the section above that is titled "Performing manual configuration updates."
Follow the steps in the section below, which lists in order the jobs that you must submit and the commands that you must enter. Special handling notes are included in the section. All jobs are members of ${zTargetHLQ}.CNTL.
Attention: After submitting each job, carefully check the output. Errors might exist even when all return codes are zero.
Unless otherwise indicated, these jobs must be submitted by a user ID that has authority to alter file permissions, change file ownership, and change group membership of all files. Please read the instructions for each job carefully before submitting it.
This job is not required if you already have a suitable mount point. If you are required to manually create the directory structure, this job performs the following tasks:
${zmbToConfigRoot}
${zConfigHfsName}
Either disable the automount rule for the configuration mount point while running this job, or perform the following steps manually:
chmod 775 ${zmbToConfigRoot}
mkdir -p -m 775 /WebSphere/V8R5
chown <user>:<group> <mount_point>
| Status of task | Date |
|---|---|
This job is not required if you already have a suitable mount point. If you are required to manually create the following directory structure, this job performs the following tasks:
${zmbToConfigRoot}
${zConfigHfsName}
Either disable the automount rule for the configuration mount point while running this job, or perform the following steps manually:
chmod 775 ${zmbToConfigRoot}
mkdir -p -m 775 /WebSphere/V8R5
chown <user>:<group> <mount_point>
| Status of task | Date |
|---|---|
${zmbProclibName}
It is recommended that you use the same user ID and group memberships that you you used in your previous version.
This job copies the tailored start procedures, parameters, and EXECs to the runtime libraries.
| Status of task | Date |
|---|---|
The steps for migrating a profile include:
The user ID that submits the job(s) must have file system update authority.
Submit the job, and verify that the return code is 0. If using the multi-job option verify the return code is 0 before submitting the next job.
This job performs the main migration procedure. Based on the information that you provided when you created your migration definition and your previous configuration, your previous server will be migrated to Version 8.0.
Note: If you selected to deploy the applications by script, you can use the following generated script to deploy your applications to the new environment. The script also contains further instructions about deploying applications.
${zmbTempDirectory}/${zmbTimestamp}/dmgr_backup/install_all_apps.jy
| Status of task | Date |
|---|---|
If the SCEERUN, SCEERUN2, and System SSL load module libraries are not in the system link list or link pack area, add them to the STEPLIB DD concatenation in each of the following cataloged procedures in ${zmbProclibName}:
${zmbControllerProcName}
${zmbServantProcName}
${zmbDaemonProcName}
and also add the full data set names, separated by colons (:), to the STEPLIB variable in the shell script:
${zmbToConfigRoot}/
${zmbToWASHomeDir}/
profiles/default/bin/setupCmdLine.sh
When modifying the setupCmdLine.sh script, do not remove lines or comment them out, as this might cause problems with automated updates to the script.
Add only those data sets that are not in the link list or link pack area.
| Status of task | Date |
|---|---|
The daemon is required to run at the Version 8.0 level of code for all the servers that it manages on the same LPAR. It will be at the Version 8.0 level when the deployment manager is started.
Copy unrestricted jurisdiction policy files
If you saved a copy of local_policy.jar in the beginning of the migration process take the following steps:
1)After migration completes successfully, mount the new product hfs read/write.
2)Copy the modified local_policy.jar from the temporary location to the following directory on the new WebSphere Application Server installation: WAS_HOME/java/lib/security
3)Mount the new product HFS as read/only
| Status of task | Date |
|---|---|
You must start the deployment manager before you start any application servers or node agents.
Use the existing commands that you currently use to start your previous server, but replace the STARTED procedure name with the value that you entered when you created your migration definition:
${zmbControllerProcName}
This command starts the deployment manager. Wait until the server has finished initializing before proceeding.
The following message appears on the console and in the job log of BBODMGR:
BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBODMGR
| Status of task | Date |
|---|---|
Migration has now been completed.