Installation Instructions for Hot Fix G49017

AIX


Hot fix G49017 addresses issues in SAS Fraud Management 3.2_M2 on AIX.

This hot fix download consists of the following components:

G49017 - SAS Fraud Management 3.2_M2
meh_hotfix_3.2.2.9 - MEH updates (1)
rpthist_db2_hotfix_3.2.2.3 - RH updates for DB2 (1)
rpthist_db2_hotfix_3.2.2.6 - RH updates for DB2 (2)
rpthist_db2_hotfix_3.2.2.7 - RH updates for DB2 (3)
rpthist_db2_hotfix_3.2.2.9 - RH updates for DB2 (4)
rpthist_db2_hotfix_3.2.2.16 - RH updates for DB2 (5)
rpthist_teradata_hotfix_3.2.2.3 - RH updates for teradata (1)
rpthist_teradata_hotfix_3.2.2.6 - RH updates for teradata (2)
rpthist_teradata_hotfix_3.2.2.7 - RH updates for teradata (3)
rpthist_teradata_hotfix_3.2.2.9 - RH updates for teradata (4)
sor_hotfix_3.2.2.3 - SOR updates (1)
sor_hotfix_3.2.2.5 - SOR updates (2)
sor_hotfix_3.2.2.6 - SOR updates (3)
sor_hotfix_3.2.2.7 - SOR updates (4)
sor_hotfix_3.2.2.9 - SOR updates (5)
sor_hotfix_3.2.2.10 - SOR updates (6)
sor_hotfix_3.2.2.12 - SOR updates (7)
sor_hotfix_3.2.2.16 - SOR updates (8)
sor_hotfix_3.2.2.17 - SOR updates (9)


The G49017 component is a "container" hot fix that contains the following "member" hot fixes which will update the software components as indicated. See the Container Hot Fixes section in the Maintenance Install Tool (MIT) Usage Guide for more information about container hot fixes.

G51009 for SAS Fraud Management Alert Generation Server 3.2_M2
H04004 for SAS Fraud Management Common Macros 3.2_M2
G50013 for SAS Fraud Management Mid-Tier 3.2_M2 ***
G70005 for SAS Fraud Management Multi Entity History DB Maintenance Macros 3.2_M2
H05008 for SAS Fraud Management Reporting History DB Maintenance Macros 3.2_M2
H06006 for SAS Fraud Management Reporting History ETL Server Macros 3.2_M2
G52008 for SAS Fraud Management Scoring Engine 3.2_M2
G73006 for SAS Fraud Management System of Record DB Maintenance Macros 3.2_M2
G63013 for SAS Fraud Management Transaction Extensions 3.2_M2
I30001 for SAS Fraud Management Operational Reports 3.2_M2

*** member hot fixes that have been updated since the previously released hot fix (G49016)


Before applying this hot fix, follow the instructions in SAS Note 35968 to generate a SAS Deployment Registry report, then verify that the appropriate product releases are installed on your system. The software components and release numbers should match the list of software components updated by the individual hot fix installers.


IMPORTANT NOTES

  1. Files delivered in this hot fix will be backed up during the installation process. However, it is good general practice to back up your system before applying updates to software.

  2. You must have Administrator Privileges on your CLIENT or SERVER machine.

  3. All currently active SAS sessions, daemons, spawners and servers must be terminated before applying this hot fix.

  4. This hot fix should be installed using the same userid who performed the initial software installation.


INSTALLATION

  1. The G49017r6.tar download is a compressed tar file. Download this file to the user's root directory. Uncompress the tar file with this command:
    $> cd ~
    $> tar -xf G49017r6.tar

    This will extract these components to the user's G49017 subdirectory:
    G49017r6.bin
    meh_hotfix_3.2.2.9.tar
    rpthist_db2_hotfix_3.2.2.3.tar
    rpthist_db2_hotfix_3.2.2.6.tar
    rpthist_db2_hotfix_3.2.2.7.tar
    rpthist_db2_hotfix_3.2.2.9.tar
    rpthist_db2_hotfix_3.2.2.16.tar
    rpthist_teradata_hotfix_3.2.2.3.tar
    rpthist_teradata_hotfix_3.2.2.6.tar
    rpthist_teradata_hotfix_3.2.2.7.tar
    rpthist_teradata_hotfix_3.2.2.9.tar
    sor_hotfix_3.2.2.3.tar
    sor_hotfix_3.2.2.5.tar
    sor_hotfix_3.2.2.6.tar
    sor_hotfix_3.2.2.7.tar
    sor_hotfix_3.2.2.9.tar
    sor_hotfix_3.2.2.10.tar
    sor_hotfix_3.2.2.12.tar
    sor_hotfix_3.2.2.16.tar
    sor_hotfix_3.2.2.17.tar

  2. Copy G49017r6.bin to each machine where SAS Fraud Management 3.2_M2 is installed.

  3. Copy meh_hotfix_3.2.2.9.tar to each machine.

  4. Copy rpthist_db2_hotfix_3.2.2.3.tar , rpthist_db2_hotfix_3.2.2.6.tar , rpthist_db2_hotfix_3.2.2.7.tar , rpthist_db2_hotfix_3.2.2.9.tar , and rpthist_db2_hotfix_3.2.2.16.tar to each machine.

  5. Copy rpthist_teradata_hotfix_3.2.2.3.tar , rpthist_teradata_hotfix_3.2.2.6.tar , rpthist_teradata_hotfix_3.2.2.7.tar , and rpthist_teradata_hotfix_3.2.2.9.tar to each machine.

  6. Copy sor_hotfix_3.2.2.3.tar, sor_hotfix_3.2.2.5.tar , sor_hotfix_3.2.2.6.tar , sor_hotfix_3.2.2.7.tar , sor_hotfix_3.2.2.9.tar , sor_hotfix_3.2.2.10.tar , sor_hotfix_3.2.2.12.tar , sor_hotfix_3.2.2.16.tar and sor_hotfix_3.2.2.17.tar to each machine.

  7. Install G49017r6.bin:

    1. Verify that the installation binary has execute permission. If it does not, use the chmod command to make it executable.
      $> chmod 755 G49017r6.bin

    2. Set your $DISPLAY environment variable
      export DISPLAY=<your_node_name>:0

    3. Execute G49017r6.bin
      <path_to_downloaded_file>/G49017r6.bin
      For example:
      ./G49017r6.bin
      This will initiate the installation wizard, which will guide you through the hot fix installation process. During the installation you will be prompted for the SASHOME location to be updated. You should provide the path to the top level SAS directory where the deploymntreg directory exists.

      See the Maintenance Install Tool (MIT) Usage Guide for more details on the installation of hot fixes.

      The contents of G49017r6.bin are listed in the hot fix manifest.


  8. Follow the installation instructions for each appropriate RH and SOR component.
    MEH updates (1):Installation Instructions for MEH updates

    RH_db2 updates (1):Installation Instructions for RH_DB2 updates

    RH_db2 updates (2):Installation Instructions for RH_DB2 updates

    RH_db2 updates (3):Installation Instructions for RH_DB2 updates

    RH_db2 updates (4):Installation Instructions for RH_DB2 updates

    RH_db2 updates (5):Installation Instructions for RH_DB2 updates

    RH_teradata updates (1):Installation Instructions for RH_teradata updates

    RH_teradata updates (2):Installation Instructions for RH_teradata updates

    RH_teradata updates (3):Installation Instructions for RH_teradata updates

    RH_teradata updates (4):Installation Instructions for RH_teradata updates

    SOR updates (1):Installation Instructions for SOR updates

    SOR updates (2):Installation Instructions for SOR updates

    SOR updates (3):Installation Instructions for SOR updates

    SOR updates (4):Installation Instructions for SOR updates

    SOR updates (5):Installation Instructions for SOR updates

    SOR updates (6):Installation Instructions for SOR updates

    SOR updates (7):Installation Instructions for SOR updates

    SOR updates (8):Installation Instructions for SOR updates

    SOR updates (9):Installation Instructions for SOR updates


This completes the installation of G49017. You must perform any "Post-Installation Instructions" documented below to successfully complete the deployment of this hot fix.


POST-INSTALLATION INSTRUCTIONS

  1. Set the test_area_path_webapp and test_area_path properties.

    A new property, test_area_path_webapp, has been created as part of this hot fix. This property is closely related to the property test_area_path. Both properties can be found on the SAS Fraud Management web application under the Preferences tab. From the Preferences tab, select System Properties -> Rule Testing.

    The value for both of these properties needs to be set to a logical location that is shared between the server running WebSphere and the server hosting the SAS IOM Server. If the properties are not set correctly, rule testing may fail.

    It is suggested that the TestArea directory should be in the same location as the Estimates directory as defined in the properties estimate_results_dir_sasiom and estimate_results_dir_webapp found in the Preferences Tab under System Properties->Estimation.



  2. If you use a Teradata Reporting History database, follow the steps below to update your implementation.

    You must be logged in to host machine as the configuration user for your implementation.

    1. cd $SASHOME/SASFoundation/9.2/misc/fsmrh/data

    2. Copy the teradata_codes4translate.csv to the RH implementation directory:
      cp teradata_codes4translate.csv $SASWHSE_IMPLEMENT_HOME/dbmaint/data/sas

    3. cd $SASWHSE_IMPLEMENT_HOME/dbmaint/data/sas

    4. Set permissions on the file:
      chmod 755 teradata_codes4translate.csv



  3. If you use the Java OSE, follow the steps below to update your implementation of the BPI script.

    You must be logged in to the J-OSE host machine as the configuration user.

    1. cd $SASOSE_IMPLEMENT_HOME/ose/Server1/bin

    2. Rename "bpi_server.sh" (otherwise it will be overwritten in step 4):
      mv bpi_server.sh bpi_server.sh.R32M2

    3. cd $SASHOME/SASFoundation/9.2/misc/fsmmeh/scripts

    4. Copy the new bpi_server.sh.orig to the OSE implementation directory:
      cp bpi_server.sh.orig $SASOSE_IMPLEMENT_HOME/ose/<Server#>/bin

    5. cd $SASOSE_IMPLEMENT_HOME/ose/<Server#>/bin

    6. Set permissions on the file:
      chmod 755 bpi_server.sh.orig

    7. Rename the file to remove the .orig extension:
      mv bpi_server.sh.orig bpi_server.sh

    8. Edit bpi_server.sh:

      1. Change "@ose.server.name@" to the appropriate OSE server for your implementation.
        For example: Server1

      2. Replace MACHINE_TYPE value "@os.localhost.machine.type@" with the appropriate machine type for your implementation.
        Valid values: aix, lax

      3. Replace these tokens at the beginning of the script with the corresponding values from the implementation's version of the bpi_server.sh:
        JAVA_HOME
        SASVJR_HOME
        FRAUDOSEINSTALLDIR



  4. If you use the Java OSE, follow the steps below to update your implementation of the JOSE server script.

    You must be logged in to the J-OSE host machine as the configuration user.

    1. cd $SASOSE_IMPLEMENT_HOME/ose/Server1/bin

    2. Rename "ose_server.sh" (otherwise it will be overwritten in step 4):
      mv ose_server.sh ose_server.sh.R32M2

    3. cd $SASHOME/SASFoundation/9.2/misc/fsmmeh/scripts

    4. Copy the new ose_server.sh.orig to the OSE implementation directory:
      cp ose_server.sh.orig $SASOSE_IMPLEMENT_HOME/ose/<Server#>/bin

    5. cd $SASOSE_IMPLEMENT_HOME/ose/<Server#>/bin

    6. Set permissions on the file:
      chmod 755 ose_server.sh.orig

    7. Rename the file to remove the .orig extension:
      mv ose_server.sh.orig ose_server.sh

    8. Edit ose_server.sh:

      1. Replace FRAUDOSESERVER "@ose.server.name@" with the appropriate OSE server for your implementation.
        For example: Server1

      2. Replace MACHINE_TYPE value "@os.localhost.machine.type@" with the appropriate machine type for your implementation.
        Valid values: r64, lax

      3. Replace these tokens at the beginning of the script with the corresponding values from the implementation version of the ose_server.sh:
        JAVA_HOME
        SASVJR_HOME
        FRAUDOSEINSTALLDIR
        MQ_HOME
        DB_HOME



  5. Follow the installation instructions to import Information Maps: Importing Information Maps



  6. Correct any records in the FRH_QUEUE_DIM table that have more than one instance of CHANGE_CURRENT_IND='1' for a queue_id.

    After installing hotfix G49017, the script fix_queue_current_recs.sh can be used to correct any records in the FRH_QUEUE_DIM table that have more than one instance of CHANGE_CURRENT_IND='1' for a queue_id.

    1. Be sure that the permissions on this script file are set to 750. The file is installed in folder $SASHOME/SASFoundation/9.2/misc/fsmrh/scripts.

    2. Using an implementation's ETL RH BCH userid, execute the fix_queue_current_recs.sh and examine the SAS log created in the $SASWHSE_IMPLEMENT_HOME/dbmaint/logs folder. This script should only need to be executed once to correct the existing data. Updates to job's 4018 code will address the cause for multiple "current" records in the FRH_QUEUE_DIM table.



  7. Rename files in the etl/data folder if job 4000 aborted while loading the data.

    After installing hotfix G49017, the script change_failed_rff_name.sh can be used to rename new_rff_<timestamp>.sas7bdat files in the etl/data folder which job 4000 has renamed to failed_rff_<timestamp>.sas7bdat when it aborted trying to load the data. If the cause of the failure has been addressed and one wants to run job 4000 again using the failed_rff... file, it must be renamed using this script.

    1. Be sure that the permissions on this script file are set to 750. The file is installed in folder $SASHOME/SASFoundation/9.2/misc/fsmrh/scripts.

    2. Using an implementation's ETL RH BCH userid, execute the change_failed_rff_name.sh script and examine the SAS log created in the $SASWHSE_IMPLEMENT_HOME/etl/logs folder.

    3. The script can be run for a specific file or all files with the failed prefix.

      For the file failed_rff_1654774118.sas7bdat, one would use:
      change_failed_rff_name.sh -s "FILE=failed_rff_1654774118.sas7bdat"

      For all failed files, one would simply use:
      change_failed_rff_name.sh



  8. Performance improvements

    Clients can achieve some transaction processing performance improvements by setting the following 2 new property values to 'true':

    ags_disable_insert_vxx
    ags_disable_merchant_dim_update

    This can be done from the console tab under the Configure Properties -> Alert Engine entry in the left hand navigation tree.

    The ags_disable_insert_vxx property will disable the storage of user variable values when a transaction is stored in the SOR and RH. This means that if rules are firing in an unexpected manner, the user variable report cannot be used as a diagnostic tool to examine the values of these variables on past transactions because this data will not have been saved in the SOR or RH.

    The ags_disable_merchant_dim_update will disable the storage and update of data in the RH about each merchant involved in a transaction. Setting this option to true should have no effect on the basic operation of the system as the merchant dim table (FRH_MERCHANT_DIM) is an auxiliary table created to support client reports should they choose to write them.



  9. Setup for Common Point of Purchase Implementation

    Create the following directories:

    Copy $SAS_ROOT/misc/fsmrh/data/cpp_ccca_jobparms.xml to $SASWHSE_IMPLEMENT_HOME/cpp/etc

    Copy $SAS_ROOT/misc/fsmrh/source/cpp_autoexec.sas to $SASWHSE_IMPLEMENT_HOME/cpp/src/sas

    Copy $SAS_ROOT/misc/fsmrh/source/cpp_obfuscate.sas to $SASWHSE_IMPLEMENT_HOME/cpp/src/obf



  10. Update the web application deployed to your application server:

    1. Re-build Web Applications

      In order for this step to execute correctly, the Metadata Server must be running.

      1. Set the DISPLAY environment variable, for example
        $ export DISPLAY=<displayname>:0

      2. Invoke the SAS Deployment Manager 9.2

        From the SASDeploymentManager directory execute config.sh, for example

        $ cd <SASHOME>/SASDeploymentManager/9.2
        $ ./config.sh

      3. Select a language in the Choose Language box

      4. Select Rebuild Web Applications

      5. Select Configuration Directory or Enter the Configuration Directory and Level that needs to be updated

      6. Specify Connection Information, including the sasadm User ID and Password

      7. Select SAS Fraud Management Mid-Tier as the Web Application to Rebuild

      8. Verify the information on the Summary screen and select Start

      9. Select Finish when the deployment is complete

      This process will update the Fraud Management ear in <CONFIGDIR>/Lev1/Web/Staging. A backup of the original ear file will be placed in the Backup directory.


    2. Re-deploy Web Applications

      Re-deploy the web applications based on the instructions in SAS Web Application Administration Guide, Chapter 8, for the web application server you are using.



  11. If performing an upgrade from SAS Fraud Management 3.2 _M1 to SAS Fraud Management 3.2_M2:

    The dml.sql in sor_hotfix_3.2.2.3.tar (sasfmcp\database\db2\sor\patches\patch_3.2.2.3\dml.sql) must be executed after running the SOR table release updates (SOR job 100). Running the sql is needed for preserving the existing key_field_id values in the FCM_ALERT_TYPE table for the alert types present in the 3.2_M1 release. The SOR tables update job sets the key_field_id values as used in a new installation. For an upgrade, the indicated sql must be executed after job 100 is executed. Failing to run the dml.sql will invalidate the execution of rules running in the upgraded environment.


This completes the installation of hot fix G49017 on AIX.

Copyright 2015 SAS Institute Inc. All Rights Reserved.