LeasePak Upgrade and Conversion

Upgrading from LeasePak 7.4 through 7.6 to the latest version

For users upgrading from LeasePak version 7.4 through 7.6 to LeasePak version 7.7a.

If you are upgrading from a version prior to 7.4, contact your NetSol representative for instructions appropriate to your starting version.

LeasePak versions 7.4 through 7.6 run on RHEL7 (minimum 7.7) and Oracle Database 19c or Sybase 16.0 SP04. LeasePak version 7.7 runs on RHEL8 (minimum 8.10) and Oracle Database 19c or Sybase 16.0 SP04 PL04.

If you are upgrading from version 7.6, skip section A below.

A. Upgrade from LeasePak version 7.4 or 7.5 to LeasePak 7.6:

In order to upgrade to LeasePak version 7.7a, you must first temporarily upgrade to 7.6.

1. Follow the instructions in the Upgrade and Conversion section of the 7.6 SAG to install the LeasePak 7.6 server software on your current RHEL7 application server, upgrade your environments to LeasePak 7.6, and convert your databases to LeasePak 7.6. Skip most of the Post Conversion Procedures listed in the Upgrade and Conversion section of the 7.6 SAG. However, do perform these three Post Conversion Procedures:
   • Re-create and re-install .netsol_proxy file
   • Re-create and re-install mpcipher.dat file
   • Re-encrypt Electronic Payment Service Account column

   Do not perform the Post Conversion Procedures in the Upgrade and Conversion section of the 7.6 SAG, except for the three procedures listed above.

2. Snapshot your LeasePak 7.6 databases by running the db_snapshot script.

B. Upgrade from LeasePak 7.6 to LeasePak 7.7:

For more information on scripts used in the following steps, refer to the LeasePak Server section of the 7.7 SAG.

1. If you have not already done so, run End of Period on the RHEL7 application server for all portfolios in all of the environments that you are upgrading. You may have already run End of Period when upgrading from 7.4 or 7.5 to 7.6. After End of Period is finished, do not make changes to the databases. It is recommended to limit user access to the application server and DBMS server once End of Period is complete.
2. If you have not already done so, stop all batch and print queues on the RHEL7 application server.
3. If you have not already done so, snapshot your LeasePak 7.6 databases by running the db_snapshot script on the RHEL7 application server.
4. Install LeasePak 7.7 on the new RHEL8 application server.
5. Create a new LeasePak 7.7 environment by running the setup_new_env script on the RHEL8 application server.
6. Create a new LeasePak 7.7 database by running the db_create script on the RHEL8 application server.
7. Copy the 7.6 snapshot dataset from the RHEL7 application server to the RHEL8 application server.
8. Load the LeasePak 7.6 dataset into the LeasePak 7.7 environment by running the db_restore script on the RHEL8 application server.

   A 7.6 dataset can be loaded into a 7.7 environment because LeasePak 7.6 databases have the same structure (table and column definitions) as LeasePak 7.7 databases.

9. Run the database conversion script to convert the 7.6 database (which has been loaded into the 7.7 environment) to 7.7. This is required because, even though there were no structural database changes between 7.6 and 7.7, there may have been data changes. For instructions on running the database conversion script, refer to Database Conversion.
10. Post-conversion task: U0460 Master General Ledger Reconciliation

    U0460 Master General Ledger Reconciliation users: If you run the U0460 Master General Ledger Reconciliation report, you must perform the following additional steps after you complete the upgrade and start the print and batch queues in order to incorporate the newly added general ledger accounts:

    1. Delete the pX_gl_hist*.scr file(s) (located in $udata), where X denotes the portfolio number.
    2. Run the LeasePak utility 232 Master G/L Reconciliation report. This will regenerate the scratch file(s), which will now include the new general ledger accounts.
11. Post-conversion task: U0212 Portfolio
    1. Go through each update screen in each of the following areas: Assessment, Calculation, End of Period, Field, Miscellaneous, Modules, New Lease, Payoff, Predefined Cycles, and PAP/ACH Control File. The UDF/UDT can be skipped unless there are changes that need to be made after conversion.
    2. Update the EOP module list. Failure to go through the EOP Module list after any conversion could cause EOP modules to be missed.
    3. For each update screen, unless there are changes, press and take the values that have already been set up.
12. Post-conversion task: U0712 Custom General
    1. Run U0712 Miscellaneous Customizations, going through each update screen. Unless you have changes, press and take the values that have already been set up.

Database Conversion

For each LeasePak database you wish to convert to 7.7a, log on to the 7.7a application server as the $NSTDBA user of the new version and run the conversion script corresponding to your DBMS (Oracle or Sybase).

** NOTE ** Ensure that your $NSTDBA user account is pointing to the 7.7a version (i.e. the new version) by running the whatami command prior to running the upgrade_env command. If the whatami output shows that the $NSTDBA user account is not pointing to the 7.7a version, you will need to copy in the correct startup files so that it is pointing to the 7.7a version before running the conversion script.

Database conversion instructions for Oracle DBMS

Run the ora_conversion script with the following command:

$top/env/environment/conv/ora_conversion environment from-version step-number

where environment is the name of the new 7.7 environment, from-version is the LeasePak "from version" specified in v##x format (not in ##.x format), and step-number is the starting step number. Specify the from-version as "v76a". To run the entire conversion, the starting step number should be specified as 1.

** NOTE ** Make sure that you enter the correct from-version, which is "v76a".

The from-version parameter to the ora_conversion script should be specified in v##x format. For example, if you are converting from 7.6a, specify the from-version as v76a, not as 7.6a.

The script will prompt for the DBO (database owner) password. Enter the password when prompted. The DBO is the Oracle user whose name is the same as the name of the database.

The conversion is divided into sections called "steps". The steps are run sequentially. After a step completes successfully, the next step is run. If a step fails, all subsequent steps automatically fail without running. The first step that failed is referred to as the "restart step".

In the event of a step failure:

1. Resolve the issue which caused the failure.
   
   
2. Contact your Netsol representative and request a script named custom_ora_conv_getcode. This script is a modified version of the standard ora_conv_getcode script from which has been removed any SQL in the "restart step" that had already executed before the failure occurred. A custom_ora_conv_getcode script is needed before each restart (except as noted below) in order to prevent conversion code in the restart step from running twice and corrupting the database due to double execution.
   
   Note: While a custom_ora_conv_getcode script is usually required before performing a restart of ora_conversion, there are two circumstances in which it is not required. One is if the statement that failed is the very first statement in the step that failed. The other is if the statements which have already been executed in the step that failed can be re-executed without corrupting the database or causing the conversion to fail again. In those two circumstances, you can ignore the instructions below and simply run the ora_conversion script again, but this time specifying step-number as the "restart step number".
   
   
3. Create a temporary directory in the HOME directory of the $NSTDBA user and put the custom_ora_conv_getcode file in that directory. Make sure that the owner of the custom_ora_conv_getcode file is the $NSTDBA user, the group owner is 'users', and the file permissions are 'r-xr-----'.
   
   
4. Set environment variable CUSTOM_GETCODE_DIR equal to the path of the directory created above. This setting instructs ora_conversion to use the custom_ora_conv_getcode script in the specified directory, rather than the ora_conv_getcode script in the build directory.
   
   
5. Run the ora_conversion script again, but this time specify step-number as the "restart step number". The restart step number is usually the first step that failed in the prior run. Make sure that environment variable CUSTOM_GETCODE_DIR is defined properly before running ora_conversion.
   
   
6. If another step failure occurs, repeat (1) through (5) above.
   
   
7. After the conversion completes successfully, delete the custom_ora_conv_getcode script, delete the temporary directory that was created in the HOME directory of the $NSTDBA user, and unset the CUSTOM_GETCODE_DIR environment variable. The variable can be unset either explicitly with the unset unix command, or by logging out from the application server.

The ora_conversion script displays informational and error messages on the screen and also writes them to the conversion log file in the LeasePak log directory. The name of the conversion log file is environment_YYYYMMDDHHMI_conv.log. Even if the screen messages say that the conversion completed successfully, you should still check the conversion log file for error messages.

Database conversion instructions for Sybase DBMS

Run the syb_conversion script with the following command:

$top/env/environment/conv/syb_conversion environment from-version

where environment is the name of the new 7.7 environment and from-version is the LeasePak "from version" specified in v##x format (not in ##.x format). Specify the from-version as "v76a".

** NOTE ** Make sure that you enter the correct from-version, which is "v76a".

The from-version argument to the syb_conversion script should be specified in v##x format. For example, if you are converting from 7.6a, specify the from-version as v76a, not as 7.6a.

The script will prompt for the DBO (database owner) password. Enter the password when prompted. The DBO is the Sybase user whose name is the same as the name of the database.

The syb_conversion script displays informational and error messages on the screen and also writes them to the conversion log file in the LeasePak log directory. A single log file is shared by all Sybase conversions. You can search for your database name in the log file to find the section pertaining to your conversion. It will usually be the last conversion in the log file.

If there were no errors during the course of the conversion, the following message is displayed on the screen and written to the log file:
"syb_conversion script has completed successfully."

If any errors occurred during the conversion, contact your Netsol representative. Do not restart the conversion until the errors have been resolved and, if necessary, a modified SQL script has been created which will skip over the sections of the conversion that have already completed. A modified SQL script is needed before restarting in order to prevent conversion code from running twice and corrupting the database due to double execution.