Skip Headers
JD Edwards EnterpriseOne Applications Upgrade Guide
Applications Release 9.1 and Tools Release 9.1.x for UNIX with DB2 UDB

E23321-16
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

2 Before You Begin the Upgrade

You should complete the tasks in this chapter before you begin the actual upgrade process.

This chapter discusses:

2.1 Preparing to Upgrade to Release 9.1 from Prior Releases

The Upgrade order should be:

  1. Install the Deployment Server, which includes JD Edwards EnterpriseOne Tools Release 9.1.

  2. Install the Platform Pack, which includes JD Edwards EnterpriseOne Applications Release 9.1.

  3. Using Server Manager, install the latest update (service pack) to the JD Edwards EnterpriseOne Tools Release that is required to support JD Edwards EnterpriseOne Applications Release 9.1.

    For example, if you are upgrading from JD Edwards EnterpriseOne 8.10 to JD Edwards EnterpriseOne Release 9.1, you should install the most current service pack or update for Tools Release 9.1 (where service packs and updates are cumulative and includes the base release).

  4. Install the latest planner update.

    For example, if you are upgrading from JD Edwards EnterpriseOne 8.9 to JD Edwards EnterpriseOne Release 9.1, you should install the most recent Release 9.1 planner update.

  5. Run the Installation Planner.

  6. Run the Installation Workbench.

  7. Build packages.

  8. Run post upgrade manual table conversions.

  9. Apply all ESUs from the update center to get fix current.

  10. Use Visual compare to retrofit custom objects.

By following this procedure, you are assured of saving time and avoiding extra work associated with retrofitting and retesting custom code in the future.

Before you begin the upgrade, you must prepare your current development, production, and prototype environments and back up your Deployment Server, Enterprise Servers, and databases.

You must complete these preparatory tasks before the upgrade team arrives.

Caution:

It is important to turn off Table Auditing, if you are using it, before beginning the upgrade process. Failure to do so may cause the audited tables to be in inconsistent states, requiring the tables to be recovered. For more information on turning off the Table Audit function, refer to the Auditing Administration Guide including 21 CFR Part 11. Table Auditing may be turned on again after the upgrade has been completed.

2.2 Preparing the Prototype Environment

To make sure you retain all modifications from your prototype environment:

  1. Make sure the network services JD Edwards EnterpriseOne network services are running on the Enterprise Server.

    Note:

    The service names will be prefixed with JDE for releases prior to 8.9 and after 8.11, while the prefixed will be PSFT for releases 8.9, 8.10, and 8.11.
  2. From the System Administration Tools menu (GH9011), select Batch Versions.

  3. Transfer PD versions to prototype so the two environments are the same.

  4. Run R9830512.

  5. Select ZJDE0001 and click Copy.

  6. Create a new version name and a new version title.

    Leave security set at 0.

  7. To select the new version on the version prompting form, check the Data Selection box.

  8. Select the advanced options to bring up the Advanced version prompting form and select to Override Location.

  9. Click Submit.

  10. When prompted for the override location, select LOCAL.

  11. Modify the data selection logic like this:

    where BC Version History (F983051) is not equal to "XJDE0000-XJDE9999", 
    and BC Version History (F983051) is not equal to "XJDEAAAA - XJDEZZZZ"
    
  12. When prompted to enter processing options, ensure that they are set at 1, A, 1, and 1, as shown on this screen:

    Surrounding text describes overview_proc_options.gif.
  13. Click OK on printer selection.

  14. Click OK.

  15. Build a prototype package. This package can be used later to verify that your custom versions were upgraded properly.

  16. Deploy the prototype package to workstations. Run the release you are upgrading from, for example, B7333.

See Also

Transferring Objects and Package Build in the JD Edwards EnterpriseOne Tools Package Management Guide for more specific instructions about building and deploying packages.

2.3 Preparing the Development Environment

If you do not have a development environment, you can skip this procedure.

Caution:

For your initial upgrade, do not select the DV910 environment as the target of the upgrade if you are upgrading a copy of your production data. The Development (DVxxx) environment defaults to loading demo data during the upgrade, so loading using the upgrade installer would result in a mixture of your data and the JD Edwards EnterpriseOne demo data in some of your tables.

To make sure you retain all modifications from the previous development environment:

  1. Make sure that all work in progress is checked into the development pathcode.

    Caution:

    From a development workstation, use Object Management Workbench, or your own query or report, to verify that objects are not checked out. Also, verify that no objects are checked out to individual workstations. Any modifications that are checked out will not be carried forward to the new release.
  2. Build the development package in preparation for deployment to one or more workstations.

  3. Deploy the development package to one or more workstations.

    These workstations are used later to help verify that all custom modifications were carried forward to the new release.

    Caution:

    You cannot make any modifications to the environment you are upgrading (except changes to custom business functions written in C language), and still carry them forward to the next release.

See Also

Transferring Objects and Package Build in the JD Edwards EnterpriseOne Tools Package Management Guide for more specific instructions about building and developing packages.

2.4 Preparing the DB2 UDB Database for Table Conversions

The upgrade process requires specific database preparation to account for the various CPU-bound and data size requirements. It is important to note that during execution of the Table Conversion Workbench your tablespaces must be of sufficient size to accommodate two copies of tables being converted. To account for this tablespace requirement, you should identify the four largest tables which you plan to convert, determine their current size, and multiple that by two.

For example, the following table shows a hypothetical environment where the largest tables are F0911, F42199, F42119, and F41021.

Largest Tables Existing Size (see Note) Existing Size Doubled
F0911 120 MB 240 MB
F42199 80 MB 160 MB
F42119 90 MB 180 MB
F41021 56 MB 112 MB
Total Amount of Space Required to Run Tables Conversions 692 MB

Note:

This includes the size of the table and all unique indexes on that table.

That is, if N is the number of concurrent jobs in the TC Workbench, then the tablespaces should be as large as the N largest tables combined, including all indexes.

For the SQL Server database, you will also need to increase the size of your transaction log by the same amount to account for log entries which are created for each table insert.

For DB2 UDB databases, perform these tasks:

2.4.1 Increasing the LOCKLIST Size

Complete this procedure to increase the LOCKLIST size of your DB2 UDB database.

  1. Sign on to the Enterprise Server as the instance owner.

  2. Enter the following commands (substituting your database_name):

    DB2 get db cfg for database_name
    

    Write down the size of the LOCKLIST so you can reset it to this value after you finish this procedure.

  3. Execute these commands to set the LOCKLIST to the required value of 4000:

    DB2 update db cfg for database_name using LOCKLIST 4000
    Db2stop
    Db2start
    

Note:

Once the upgrade has completed, you can reduce the LOCKLIST to its previous size which you noted in Step 2 above.

2.4.2 Increasing the DBHEAP Size

Complete this procedure to increase the DBHEAP size of your DB2 UDB database.

  1. Sign on to the Enterprise Server as the instance owner.

  2. Enter the following commands (substituting your database_name):

    DB2 get db cfg for database_name
    

    Write down the size of the DBHEAP so you can reset it to this value after you finish this procedure.

  3. Execute these commands to set the DBHEAP to the required value of 6000:

    DB2 update db cfg for database_name using DBHEAP 6000
    Db2stop force
    Db2start
    

Note:

Once the upgrade has completed, you can reduce the DBHEAP to its previous size which you noted in Step 2 above.

2.4.3 Increasing Tablespace Size

Complete this procedure to increase the tablespace size of your DB2 UDB database.

  1. In the DB2 UDB Control Center, look at the size of the business data 32K tablespace for the environment your are upgrading, for example PRODDTAT32K for PROD.

  2. Look at the number of blocks used in that tablespace and convert to MB by dividing by 32. (For our shipped demo data, the number of blocks used is 352 and this corresponds to 11MB.)

  3. Increase the size of the CTLI tablespace (for example, PRODCTLI) by at least that amount to accommodate the intermediate table F00165T used during F00165 conversion. This can be done by adding an additional container through the Control Center (all containers for one tablespace must be the same size), or by signing onto the Enterprise Server as the instance owner, connecting to the environment database, and extending the tablespace container size as follows (substituting your database_name):

    DB2 connect to database_name
    DB2 alter tablespace PRODCTLI EXTEND (ALL 11M)
    

    Substitute the database name for the environment you are upgrading, the correct tablespace name and the correct number of MB. If you have made extensive use of Media Objects, you will have used more space in the xDTAT32K tablespace.

  4. Increase the size of the DTAT4K tablespace by the same amount. This is to accommodate the converted F00165 table.

    Additionally, you should increase the size of the xxxDTAT4K and DTAI tablespaces to accommodate an extra copy of your largest tables.

    If upgrading the DEV environment, make sure you have enough spare space in the OW_DEV tablespaces to accommodate the demo data, which is much larger than it was in previous releases. Look at the script ow_dev_tbsp.unxow_dev_tbsp.nt and increase the tablespaces accordingly.

2.4.4 Ensuring Proper Rights are Assigned to the Enterprise Server Account for DB2 UDB

When running the Enterprise Platform Pack install, you must make sure that the DB2 UDB database account signed on to the Enterprise Server has these special rights:

  • Act as part of the operating system

  • Create token object

  • Adjust memory quotas

  • Replace a process level token

Note:

These rights are not automatically given when you add the account to the Administrator group. The account created by your DB2 UDB install on your Windows server has these rights. By default, that account is named db2admin.

2.5 Checking Modification and Merge Flags

This task ensures that your modifications are carried forward to the new release. Before you upgrade, perform the steps to review or set the modification flags on the Object Librarian records for all modified objects.

Caution:

Do not run the Specification merges until you check the flags for all pathcodes containing modified objects.

To check modification and merge flags:

  1. Logon to the workstation or to the deployment environment on the Deployment Server.

  2. On the menu (GH9611), select Specification Merge Selection.

    Surrounding text describes iseries_spec_merge.gif.
  3. On the Specification Merge Selection form, complete these fields:

    • Location

      Enter the name of the Deployment Server that is the check-in location for this pathcode.

    • Path Code

      Enter the name of the associated pathcode (prototype or development).

  4. On the QBE line, enter C in the Mod Flag field to list the changed objects, and then click Find.

  5. Set the MrgOpt field to 1 for all objects except those you do not want to merge; use Enable to carry changed objects and use Disable to not carry changed objects.

  6. When you finish reviewing or modifying the records, click Close.

    Caution:

    To verify the accuracy of included modifications, additional queries are strongly recommended to avoid missing any modified objects. For example, verify that the system code of the objects is 55 to 59.

2.6 Refreshing and Verifying Data

Before running Installation Workbench, you have the option to refresh the business data for the environment being upgraded with a current set of Production data. Having a recent copy of the data makes testing table conversions and the new release more effective. For example, when you upgrade the development environment, refresh Business Data - TEST; and when you upgrade the PY environment, refresh Business Data - CRP.

The source can be any data set you choose, but you should use a current copy of your production data. When table conversions run during Installation Workbench, this data is converted to the new Release 9.1 formats, as required. By using a copy of your production data, you ensure a successful upgrade of your live production data later.

This section discusses:

2.6.1 Refreshing the Business Data

To copy your business data, you must add a version of R98403 that is similar to XJDE0021 from a B73.3.x or B9 workstation, and then run it in proof mode to make sure the data selection and processing options are set correctly.

To refresh the business data:

  1. From the System Administration Tools menu (GH9011), select Batch Versions.

  2. In the Batch Application field, enter R98403.

  3. Click Find.

  4. Run your version (the one that is similar to XJDE0021).

  5. On the Processing Options Environment tab, verify the processing options.

  6. Click OK.

  7. After running the batch application in proof mode, run in update mode to recreate the existing tables.

    Because User-Defined Code (UDC) and menu merges are customer-based, copy them from the production environment to the PY environment. If upgrading the development environment, consider refreshing the development environment control tables from production environment to test the software.

    Before running Installation Workbench to upgrade the prototype or development environment, copy the current production environment control tables (Control Tables - Production) to the Control Tables - Test or Control Tables - CRP data source, depending on the environment to upgrade. This makes sure that your master control tables are used when the upgrade merges run during Installation Workbench.

2.6.2 Refreshing the Control Tables

To refresh the control tables:

  1. From the previous release's planner environment, you must map tables for the environment being upgraded as shown in the list below. For example, for DV733x, map these tables to the Control Tables - Test data source.

    F0004
    F0004D
    F0005
    F0005D
    F0082
    F00821
    F0083
    F0084
    F9100
    F9101
    F9102
    F9105
    F9105D
    F9106
    F9106D
    F9050
    F9010
    F9020
    F9021
    F9022
    F9023
    F9025
    F9030
    F98840
    F91011
    F91012
    F91013
    F91014
    F98810D
    F98811
    F98830
    F98845
    F98800
    F98800D
    F98800T
    F98810
  2. From the System Administration Tools menu (GH9011), select Batch Versions.

  3. In the Batch Application field, enter R98403.

  4. Click Find.

  5. Run version XJDE0022 locally.

  6. On the Processing Options Environment tab, verify the processing options are set to 1, 1, A, and 1.

  7. Click OK.

  8. Deactivate the mappings you defined for the tables listed in Step 1.

  9. Reactivate the original mappings.

    You must verify that your master control tables for release level B73.3.x or B9 include all custom changes you want to carry forward to Release 9.1. Verify them for each environment you want to upgrade.

2.6.3 Verifying Custom Changes in Master Control Tables

To verify custom changes in master control tables:

  1. Verify that the previous release's master control tables for the data dictionary reside in a relational database accessed by the Data Dictionary data source:

    • F9200

    • F9202

    • F9203

    • F9207

    • F9210

    • F9211

    • F9212

    • GT92002 (F00165)

  2. Verify that the previous release's master control tables for menus reside in a relational database accessed by the Control Tables - Production data source (for production), Control Tables - CRP (for PY environments), or Control Tables - Test (for the development environment):

    • F9100

    • F9101

    • F9102

    • F9105D

    • F9106D

  3. Verify that the B73.3.x or B9 master control tables for user defined codes reside in a relational database accessed by the Control Tables - Production data source (for production), Control Tables - CRP (for PY environments), or Control Tables - Test (for the development environment).

2.6.4 Backing Up the Servers and Databases

This section discusses:

2.6.4.1 Backing up the Deployment Server

The Deployment Server must be completely backed up, because some JD Edwards EnterpriseOne objects exist in directories other than normal JD Edwards EnterpriseOne structures.

2.6.4.2 Backing Up the Enterprise Server

Prior to beginning the upgrade, you should back up the complete directory structure for the JD Edwards EnterpriseOne base installation.

To back up your IBM i-based Enterprise Server:

  1. Save all data libraries that contain JD Edwards EnterpriseOne tables using the SAVLIB command.

  2. Save all JD Edwards EnterpriseOne system libraries using the SAVLIB command.

  3. Save the specifications for all pathcodes using the SAV command.

2.6.4.3 Backing Up the Oracle Databases

To back up your Oracle databases:

  1. Fully export all instances (one at a time).

  2. Perform a cold back up of the complete Oracle database.

2.6.5 Working with Purge Tables

These tables have changed format from Release 9.1:

  • F3111S

  • F3112S

  • F31122S

The upgrade process will drop and recreate these tables. These are Purge tables, and the upgrade process does not preserve the data in purge tables.

2.6.6 Working with Accounts Payable Processing

If you are upgrading, you must use the Work with Payment Groups application (P04571) to reset or finish (write and update) all accounts payable processing. The Financials department or financials consultant can assist you with this task.

Note:

Failure to accomplish this task causes data corruption in accounts payable processing files. To verify that no unfinished accounts payable processing records exist, tables F04571 and F04572 should both be empty.

2.7 Verifying Software and Hardware Requirements

Certain minimum hardware and software requirements must be met to run Release 9.1 on various operating systems and servers. Verify that the Deployment Server, Enterprise Servers, and workstations meet the hardware and software requirements.

Because the software and hardware requirements change rapidly as manufacturers constantly update their products, requirements are not provided in this documentation. Refer to Section 1.3.1, "Accessing Minimum Technical Requirements (Certifications)".

Note:

Make sure that you have taken and installed the latest Planner Update ESU from the Oracle JD Edwards Update Center. Failing to do so may prevent proper installation of the software.

Additionally, a new compiler requirement is added for Release 9.1. Before you run the Deployment Server or Platform Pack installer, you should install a Microsoft Visual C++ compiler on any machine on which the installer will be run. The MTRs list supported C++ compilers on Microsoft Windows-based machines. Refer to Section 1.3.1, "Accessing Minimum Technical Requirements (Certifications)"

2.8 Verifying the Disk Space Requirements

The amount of disk space you need for Release 9.1 software on the Deployment Server and Enterprise Server depends on many variables according to platform and database. For the Deployment Server, all disk space must be available on one drive except if you use the Remote Share option. With the Remote Share option, there must be enough room on one remote share for all the path codes. For Enterprise Server installation, multiple foundations during the install are not supported. There must be enough space on one disk drive for all logic components.

During the install you cannot choose to have Printqueue and build areas installed onto another location. Additionally you must have sufficient disk space on either the Enterprise Server or a separate Database Server for the scripts and dump files and the database components. If you are manually running the database scripts, can edit the scripts to put the actual database components (that the scripts create) onto other drives.

After you have completed an installation, you can manually relocate some components of the Enterprise Server on different drives, such as printqueue location, build areas, package location, and BI-Publisher storage. Additionally, when using multiple foundations it is possible to use different drives for each set of JD Edwards EnterpriseOne pathcodes. However, it is important to note that for purposes of the initial installation, having the correct amount of space available, but not on a single drive, is not adequate. Up-to-date disk space requirements are listed in the Release 9.1 Minimum Technical Requirements. Refer to Section 1.3.1, "Accessing Minimum Technical Requirements (Certifications)".

Note:

While the disk space tables accurately represent the disk space requirements, the actual requirements for an installation will be greater due to the requirement for temporary space.

2.9 Cleaning Up Disk Space on the Servers

Make sure you have enough disk space before starting the upgrade. You may delete some directories from previous releases to increase space on your system.

Note:

Parallel Release Considerations

If you want to maintain the recommended parallel environments, and if you have sufficient disk space, you should keep your complete prior release directory structure intact, such as B733.x and B9. To run parallel, you must keep at least the CLIENT, PLANNER and DATA, PLANNER and SPEC, pathcode, and SYSTEM directory structures.

Path Code Considerations

If you use the JD733x pathcode, or any packages associated with it, do not delete the JD733x directory structure. However, if the directory is only a copy of the JD Edwards EnterpriseOne pristine objects for a previous release, you can delete it.

See Also

Section 2.7, "Verifying Software and Hardware Requirements"

Section 2.8, "Verifying the Disk Space Requirements"

2.10 Applying Microsoft Product Updates

You should apply all the critical updates for Microsoft on your Deployment Server including Visual C++.

Tip:

If you already have the required components installed, you can install Microsoft .NET without prompting for the prerequisite installation image by entering this command line:

x:\setup\setup.exe \NO_BSLN_CHECK

where x: is the drive on which the .NET setup program resides.