Upgrading from LeasePak 7.4 or 7.5 to the latest version

LeasePak Upgrade and Conversion

Upgrading from LeasePak 7.4 or 7.5 to the latest version

1. LeasePak 7.6a Server Installation

Install the LeasePak 7.6a server software by following the instructions in LeasePak Server Preparation and Installation.

2. Preparing LeasePak Server for Upgrade

Perform the following preparations on your old version of LeasePak before upgrading to the new version.

a. User Processes

Notify users in advance that LeasePak will be unavailable during the upgrade. At the scheduled start time, stop any remaining LeasePak server processes. The following command will identify LeasePak server processes, including End of Period and LeasePak Utilities processes:

ps -ef | grep lpa

Also use the appropriate procedures to stop any LeasePak-related processes on the DBMS server.

b. End of Period

Run End of Period for all portfolios in all of the environments that you are upgrading. After End of Period is finished, do not make changes to the databases. You may also want to limit user access to the application server and DBMS server once End of Period is complete.

c. Batch and Print Queues

Log on to the application server as root or with a privileged account and STOP all batch and print queues for the prior release. For example:

[root@leasepak init.d]# /etc/init.d/nst_prod75
usage: ./nst_qm_prod7.6a {start|stop|status|restart}

[root@leasepak init.d]# /etc/init.d/nst_prod75 stop

d. System Backups

Perform backups of your systems as needed.

3. LeasePak Environment and Database Upgrade

a. Database Snapshot (optional)

For each LeasePak database you wish to convert to 7.6a, optionally snapshot the database as a precaution. To snapshot a database, log on to the application server as the $NSTDBA user of the old version and run db_snapshot

** NOTE ** Ensure that your $NSTDBA user account is pointing to the old version by running the whatami command prior to running the db_snapshot command. If the whatami output shows that the $NSTDBA user account is not pointing to the old version, you will need to copy in the correct startup files so that it is pointing to the old version before running db_snapshot.

b. Environment Upgrade

For each LeasePak environment you wish to upgrade to 7.6a, log on to the 7.6a application server as the $NSTADMIN user of the new version and run upgrade_env.

** NOTE ** Ensure that your $NSTADMIN user account is pointing to the 7.6a 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 $NSTADMIN user account is not pointing to the 7.6a version, you will need to copy in the correct startup files so that it is pointing to the 7.6a version before running upgrade_env.

upgrade_env [new-setup-env-flags] path-to-old-environment-to-upgrade [build-descriptor]

where new-setup-env-flags are the optional flags and build-descriptor is the LeasePak build ID or alias as described in the LeasePak Environments and Databases section of LeasePak Server Configuration and Maintenance. The original setup_new_env arguments, including the flags, may be available in the variable $MSIENV_SETUP_ARGS, depending on the LeasePak version in which the environment was originally created. Note that setup_new_env flags must be provided to match the previous setup_new_env, if known. If the flags contain *t* (for TEST environment), then the LeasePak build ID or alias is also required.

c. Database Conversion

For each LeasePak database you wish to convert to 7.6a, log on to the 7.6a 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.6a 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.6a version, you will need to copy in the correct startup files so that it is pointing to the 7.6a 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 upgraded environment whose database you are converting, from-version is the LeasePak database's "from version" specified in v##x format (not in ##.x format), and step-number is the starting step number. To run the entire conversion, the starting step number should be specified as 1.

** NOTE ** Make sure that you enter the correct from-version.

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

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:

Resolve the issue which caused the failure.
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".
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-----'.
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.
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.
If another step failure occurs, repeat (1) through (5) above.
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 environment whose database you are converting, and from-version is the LeasePak database's "from version" specified in v##x format (not in ##.x format)

** NOTE ** Make sure that you enter the correct from-version.

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

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

4. Post-conversion Procedures

a. LeasePak 7.6a Re-create and re-install .netsol_proxy file

If you own the LeasePak Shared User module, after the database conversion you must perform the following in order to re-create and re-install the .netsol_proxy file. The file requires re-creation because the encryption it uses is changing from Triple DES to AES.

Log on to the application server as a user who can run LeasePak.
Run lease /util 110 in dedicated mode to create a hidden file named .netsol_proxy in the current working directory. This file contains the Proxy DBMS user's username and password encrypted with AES.
Move the .netsol_proxy file from the current working directory to the Proxy Unix user's HOME directory, overwriting the prior version of the file.
Assign ownership of the file to the Proxy Unix user, and make the group of the file the same as the Proxy Unix user's primary group.
Set the file's Unix access permissions to 600 (which is rw access for the owner, and no access of any kind for the group and world).

For an overview of the Shared User module, refer to the Shared User section of the LeasePak documentation.

b. LeasePak 7.6a Re-create and re-install mpcipher.dat file

If you own the LeasePak mPower module, after the database conversion you must perform the following in order to re-create and re-install the mpcipher.dat file. The file requires re-creation because the encryption it uses is changing from Triple DES to AES.

Log on to the application server as a user who can run LeasePak.
Run lease /util 101 to create a file named mpcipher.dat in the current working directory. This file contains the mPower username and password encrypted with AES.
Move the mpcipher.dat file to the appropriate directory on the mPower web server. Refer to the mPower documentation for more information.

c. Re-encrypt Electronic Payment Service Account column

If you own the Electronic Payments module and your rse table contains one or more rows, after the database conversion you must perform the following in order to change the encryption used by column rse.encr_sec_s from Triple DES to AES:

Log on to the application server as a user who can run LeasePak.
Run lease /util 150. This util option will change the encrypted data in column rse.encr_sec_s from Triple DES to AES.

d. LeasePak 7.6a Batch and Print Queues

Log on to the application server as root or with a privileged account and START all batch and print queues for the current release. For example:

[root@leasepak init.d]# /etc/init.d/nst_prod76
usage: ./nst_qm_dev7.6a {start|stop|status|restart}

[root@leasepak init.d]# /etc/init.d/nst_prod76 start

e. 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:

Delete the pX_gl_hist*.scr file(s) (located in $udata), where X denotes the portfolio number.
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.

f. LeasePak 7.6a Client Upgrade

Follow the procedures in the Upgrade and Conversion section of the LeasePak client documentation to upgrade the LeasePak client software.

g. In U0212 Portfolio:

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.
Update the EOP module list. Failure to go through the EOP Module list after any conversion could cause EOP modules to be missed.
For each update screen, unless there are changes, press and take the values that have already been set up.

h. In U0712 Custom General:

Run U0712 Miscellaneous Customizations, going through each update screen. Unless there are changes, press and take the values that have already been set up.