General Page
WebSphere Application Server V7.0 for IBM i provides the foundation for serving dynamic content via servlets and JavaServer Pages (JSPs).
websphere 70,was 70,websphere 7.0,was 7.0,websphere application server v7.0,websphere 70 on ibm i,was 70 on ibm i,websphere 7.0 on ibm i,was 7.0 on ibm i
websphere 70,was 70,websphere 7.0,was 7.0,websphere application server v7.0,websphere 70 on ibm i,was 70 on ibm i,websphere 7.0 on ibm i,was 7.0 on ibm i
Fix pack installation instructions
Terms:
Throughout these instructions, you must replace the following:
-
UPDI_LOCATION: The location where the V7.0 Update Installer is installed. The default location is
/QIBM/ProdData/WebSphere/UpdateInstaller/V7/UPDI.
Note: If your system also has WebSphere Application Server V6.1 installed you may find that the location is/QIBM/ProdData/WebSphere/UpdateInstaller/V61/UPDI.In this case the Update Installer code in the/QIBM/ProdData/WebSphere/UpdateInstaller/V61directory is upgraded to the V7 Update Installer. You can verify this by viewing/QIBM/ProdData/WebSphere/UpdateInstaller/V61/UPDI/version.txt -
PRODUCT_LOCATION: The location of the V7.0 product you are updating. Default locations are:
-
Express: /QIBM/ProdData/WebSphere/AppServer/V7/Express -
Base: /QIBM/ProdData/WebSphere/AppServer/V7/Base -
ND: /QIBM/ProdData/WebSphere/AppServer/V7/ND -
NDDMZ: /QIBM/ProdData/WebSphere/AppServer/V7/NDDMZ -
AppClient: /QIBM/ProdData/WebSphere/AppClient/V7/client -
WebServer Plugins: /QIBM/ProdData/WebSphere/Plugins/V7/webserver
Tip: Invoke the querywasinstalls Qshell script located in directory /QIBM/WAS/bin from a Qshell session to list the WebSphere Application Server products installed on your system. -
-
MAINTENANCE_PACKAGE: The name of the file containing the fix pack. This will be one of the following,
where x is the fix pack number, for example, 1:
- Express, Base, ND: 7.0.0-WS-WAS-i5osPPC-FP000000x.pak
- NDDMZ: 7.0.0-WS-NDDMZ-i5osPPC-FP000000x.pak
- AppClient: 7.0.0-WS-AppClient-i5osPPC-FP000000x.pak
- WebServer Plugins: 7.0.0-WS-PLG-i5osPPC-FP000000x.pak
Installing a fix pack:
- Stop all Java processes that use the WebSphere Application Server product you are updating. These processes include all application server processes, the nodeagent process, the deployment manager process, and any WebSphere Application Server client applications.
- Start the host servers if they are not currently active:
STRHOSTSVR *ALL - System requirements/recommendations:
- The userid used to run the update must have *ALLOBJ authority.
- Your HTTP server(s) will have to be ended and restarted at the end of this procedure.
- Ensure that as little activity as possible is occurring on the system. Do not put the system in restricted state or the fix pack install will fail.
- Ensure that the storage pool in which the job runs has sufficient dedicated memory. A minimum of 512MB of dedicated memory is required, however, 1GB is recommended. More memory improves the performance of the update installer significantly. See step 4 to determine in which storage pool the job will run.
- Ensure that no other workloads are competing for this dedicated memory. This can be accomplished by submitting the job to a subsystem associated with a storage pool containing this dedicated memory.
- Over time, as multiple versions of fix packs have been installed, there will be multiple .pak source files stored in the source directory, UPDI_LOCATION/maintenance. When the update function is performed, the most recently stored .pak file will be used in the update. If you wish to override this behavior, you can indicate a specific fix pack source file. See option 2 below.
- Install the fix pack using one of the options below.
Option 1: installFixpack700x script
Use this option when you have obtained the fix pack by applying the WebSphere Group PTF.
When the WebSphere Group PTF is applied, the Update Installer is installed or updated, and install/uninstallFixPack700x scripts are created in the bin directory of each WebSphere V7.0 product on the system. Maintenance packages that are too large to be contained in a single PTF are split into two or more PTFs and restored to the Update Installer’s maintenance directory by the installFixPack700x script.
If the install/uninstallFixPack700x scripts do not exist, use Option 2 below.
- From QShell, invoke: PRODUCT_LOCATION/bin/installFixPack700x where x is the fix pack number, for
example,
Example:
/QIBM/ProdData/WebSphere/AppServer/V7/Express/bin/installFixPack7001 - By default the installFixPack700x script submits the job to install the fix pack to the QSYSNOMAX
job queue which is associated with the QSYSWRK subsystem and storage pool. You can use the –jobq,
-jobqlib, and -job parameters to specify a different job queue, job queue library, and job name.
This allows you to have the job run in a different subsystem associated with a different storage
pool if necessary.
Example: installFixPack700x -jobqlib MYLIB -jobq MYJOBQ –job MYJOBNAME
Option 2: Submit the update script to batch manually.
Use this option when you have obtained the fix pack image from the WebSphere Application Server support download site or from some location other than by applying the group PTF.
This is a single command, typed as a continuous line of text. This will install the fix pack, running the update script as a batch job in the QSYSWRK subsystem. To submit the batch job to a different subsystem, modify the JOBQ parameter to specify the job queue you want to use.
-
SBMJOB CMD(STRQSH CMD
('UPDI_LOCATION/update -W product.location=
PRODUCT_LOCATION -W maintenance.package=
UPDI_LOCATION /maintenance/MAINTENANCE_PACKAGE')) JOB(UPDATEWAS) ALWMLTTHD(*YES) JOBQ(QSYS/QSYSNOMAX)
Notes:- Installation of the fix pack may take over an hour depending on your IBM i system. If memory available to the update process is limited, the update can take much longer, potentially several hours.
- From QShell, invoke: PRODUCT_LOCATION/bin/installFixPack700x where x is the fix pack number, for
example,
- The installation is complete when the job ends. Check the updatelog.txt file located under this directory:
PRODUCT_LOCATION/logs/update/7.0.0-WS-WAS-i5osPPC-FP000000x.install for successful completion, where
x is the fix pack number, for example, 1.
The last line of the file indicates if the install was successful (INSTCONFSUCCESS), partially successful (INSTCONFPARTIALSUCCESS) or failed (INSTCONFFAIL). - End and restart the HTTP Admin instance if it was active during the update. Use the following commands
at the command prompt:
- ENDTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)
- STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)
Uninstalling a fix pack:
- Stop all Java processes that use the WebSphere Application Server product you are updating. These processes include all application server processes, the nodeagent process, the deployment manager process, and any WebSphere Application Server client applications.
- Start the host servers if they are not active:
STRHOSTSVR *ALL - System requirements/recommendations:
a. The userid used to run the update must have *ALLOBJ authority.
b. Your HTTP server(s) will have to be ended and restarted at the end of this procedure.
c. Ensure that as little activity as possible is occurring on the system. Do not put the system in restricted state or the fix pack install will fail.
d. Ensure that the storage pool in which the job runs has sufficient dedicated memory. A minimum of 512MB of dedicated memory is required, however, 1GB is recommended. More memory improves the performance of the update installer significantly.
e. Ensure that no other workloads are competing for this dedicated memory. This can be accomplished by submitting the job to a subsystem associated with a storage pool containing this dedicated memory.
- Uninstall the fix pack using one of the options below.
Option 1: Submit the update script to batch using the uninstallFixPack700x script.
Use this option to uninstall the fix pack after installing the fix pack delivered by the WebSphere Application Server group PTF.
When the WebSphere Group PTF is applied, an uninstallFixPack700x script is created in the bin directory of each WebSphere V7.0 product on the system. If the uninstallFixPack700x script does not exist, use Option 2 below.
- From QShell, invoke: PRODUCT_LOCATION/bin/uninstallFixPack700x where x is the fix pack number, for
example, 1.
Example: /QIBM/ProdData/WebSphere/AppServer/V7/Express/bin/uninstallFixPack7001 - By default the uninstallFixPack700x script submits the job to install the fix pack to the QSYSNOMAX
job queue which is associated with the QSYSWRK subsystem and storage pool 2. You can use the –jobqlib,
-jobq, -job parameters to specify a different job queue, job queue library, and job name.
Example: uninstallFixPack700x -jobqlib MYLIB -jobq MYJOBQ –job MYJOBNAME
Option 2: Submit the update script to batch manually.
Use this option when you have obtained the fix pack image from the WebSphere Application Server support download site or from some location other than by applying the group PTF.
- This is a single command, typed as a continuous line of text. This will uninstall the fix pack, running
the update script as a batch job in the QSYSWRK subsystem. To submit the batch job to a different
subsystem, modify the JOBQ parameter to specify the job queue you want to use.
-
SBMJOB CMD(STRQSH CMD('UPDI_LOCATION/update -W update.type=uninstall -W product.location=PRODUCT_LOCATION -W backup.package=MAINTENANCE_PACKAGE')) JOB(UPDATEWAS) ALWMLTTHD(*YES) JOBQ(QSYS/QSYSNOMAX)
Notes:- Uninstall of the fix pack may take over an hour depending on your IBM i system.
- If more than one V7.0 product is installed on your system (i.e. Express, Base, or ND), you must use option 1 or 2 above to uninstall the fix pack for each of the products. You must not run multiple uninstalls of the fix pack at the same time.
- From QShell, invoke: PRODUCT_LOCATION/bin/uninstallFixPack700x where x is the fix pack number, for
example, 1.
- The uninstall is complete when the job ends. Check the updatelog.txt file located under this directory:
PRODUCT_LOCATION/logs/update/7.0.0-WS-WAS-i5osPPC-FP000000x.uninstall where x is the fix pack number, for example, 1.
The last line of the file indicates if the uninstall was successful (INSTCONFSUCCESS), partially successful (INSTCONFPARTIALSUCCESS) or failed (INSTCONFFAIL). - End and restart the HTTP Admin instance if it was active during the uninstall. Use the following:
- ENDTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)
- STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)
[{"Product":{"code":"HW1A1","label":"IBM Power Systems"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"--","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"Version Independent","Edition":"","Line of Business":{"code":"LOB57","label":"Power"}}]
Was this topic helpful?
Document Information
Modified date:
03 May 2021
UID
isg3T1027646