This chapter provides reference information for Oracle Communications Billing and Revenue Management (BRM) rerating utilities.
Use the load_pin_config_ood_criteria utility to load out-of-order criteria into the /config/event_order_criteria object in the BRM database. You define out-of-order criteria in the pin_config_ood_criteria.xml file in BRM_Home/sys/data/config.
For more information, see "Defining Out-of-Order Criteria" and "Loading Out-of-Order Criteria".
Important:
To connect to the BRM database, the load_pin_config_ood_criteria utility needs a configuration (pin.conf) file in the directory from which you run the utility.Caution:
The load_pin_config_ood_criteria utility overwrites existing out-of-order criteria. If you are updating out-of-order criteria, you cannot load new out-of-order criteria only. You must load complete sets of out-of-order criteria each time you run the load_pin_config_ood_criteria utility.Displays online help about the command.
Creates a log file for debugging purposes. Use this parameter for debugging when the utility appears to have run with no errors but the data has not been loaded into the database.
Displays detailed information as the utility runs.
Checks the validity of the XML file but does not process any data.
The name and location of the file that defines out-of-order criteria. The default pin_config_ood_criteria.xml file is in BRM_Home/sys/data/config.
If you do not run the utility from the directory in which the file is located, you must include the complete path to the file. For example:
load_pin_config_ood_criteria BRM_Home/sys/data/config/pin_config_ood_criteria.xml
Tip:
If you copy the pin_config_ood_criteria.xml file to the directory from which you run the load_pin_config_ood_criteria utility, you do not have to specify the path or file name. By default, the name of the file is pin_config_ood_criteria.xml. You can change this name.The load_pin_config_ood_criteria utility notifies you when it successfully creates the /config/event_order_criteria object. Otherwise, look in the default.pinlog file for errors. This file is either in the directory from which the utility was started or in a directory specified in the utility configuration file.
To verify that out-of-order criteria was loaded, you can display the /config/event_order_criteria object by using the Object Browser application in Developer Center, or use the robj command with the testnap utility.
Important:
You must send a Reload semaphore to make new out-of-order criteria available in the Pipeline Manager. The Reload semaphore is used by the DAT_PortalConfig data module.Use this utility to load the following information into the BRM database:
Load extraction keys-to-event field mappings into the /config/rerate_flds object. You define extraction keys and map them to EDR fields by using XML. For more information, see "Defining Custom pin_rerate Parameters for Rerating".
Load balance-impact comparison fields into the /config/rerate_flds/compare_bi object. The balance impact fields in this object determine whether the balance impacts of rerating and previous rating are equivalent. For more information, see "Determining Whether Balance Impacts of Rerating and Previous Rating Are Equivalent".
Specifies the name of the XML file that contains either the extraction keys and field mappings or the balance-impact comparison fields.
Important:
The file you load cannot include both extraction-key mapping and balance-impact comparison fields. You must load the files for these configurations separately.Displays information about successful or failed processing as the utility runs.
Note:
This parameter is always used with other parameters and commands. It is not position dependent. For example, you can enter -verbose at the beginning or end of a command to initiate the verbose parameter. To redirect the output to a log file, use the following syntax with the verbose parameter. Replace filename.log with the name of the log file:load_pin_rerate_flds any_other_parameter –v > filename.log
Displays the syntax and parameters for this utility.
This utility notifies you when it successfully creates the /config/rerate_flds object.
If it cannot create the /config/rerate_flds, it logs an error in the log file (default.pinlog). It creates the log file either in the directory from which the utility was started or in the directory specified in the configuration file.
Use this utility to extract events from your database to be rerated by the BRM Pipeline Manager.
You define which events to extract by using the pin_event_extract.cfg file located in the BRM_Home/apps/pin_event_extract directory. For information, see "Specifying Which Events to Extract for Rerating".
For information about extracting events, see "Running the pin_event_extract Utility".
Note:
To connect to the BRM database, the pin_event_extract utility needs a configuration file in the directory from which you run the utility.Specifies the name and location of the configuration file that defines which events to extract. For information on how to create the file, look at the sample file (BRM_Home/apps/pin_event_extract/pin_event_extract.cfg).
By default, the utility looks in the current working directory. If your configuration file is located in a different directory, you must specify the entire path for the file. If the pin_event_extract.cfg file is located in the current working directory, you can ignore this parameter.
Extracts events based on the information provided in the roaming_input_file. The roaming_input_file is generated by the RAP Processing pipeline during Outcollect processing. It contains records that specify the extraction criteria for extracting TAP settlement records from the BRM database. For more information, see "Backing Out the Balance Impacts for the Rejected TAP Files and Records" in BRM Configuring Roaming in Pipeline Manager.
Extracts events assigned to a specific brand. You can use this option alone or with the -f option.
Flags the events for back-out-only rerating. Pipeline Manager backs out the balance impact and does not rerate the event.
Overrides the program lock.
-o TRUE resets the status table to the unused state.
-o FALSE sets the status table to the used state.
The Event Extraction Manager cannot run at the same time as Rated Event Loader or Rerated Event Loader. To prevent this, all three applications use a status table to determine if one of the other applications is running. If one of the applications terminates abnormally and leaves the status table in a locked state, the Event Extraction Manager cannot be started. In this case, use the -o TRUE option to reset the status table to an unused state.
Important:
Before using this option, ensure that the Rated Event Loader and Rerated Event Loader are stopped.Displays the syntax and parameters for this utility.
This utility is used by the OODHandler batch handler to process out-of-order events. It converts rerate-request files generated by the FCT_EventOrder module into flist format and then calls PCM_OP_ACT_USAGE to generate a notification event.
For more information, see "About Automatic Rerating of Out-of-Order Events".
Important:
You must run the utility from a directory that contains both the pin_rerate_job_info.xsd file and a pin.conf configuration file. By default, these files are located in the BRM_Home/apps/pin_ood_handler/process directory.Creates a log file for debugging purposes. Use this parameter for debugging when the utility appears to have run with no errors but the data has not been loaded into the database.
Displays detailed information as the utility runs.
Checks the validity of the XML file but does not process any data. When you run the file in test mode, it returns either that the XML file is valid or an error message that contains the invalid line number.
Specifies the name of the rerate request XML file that is generated by the FCT_EventOrder pipeline module.
Displays online help about the command.
Use this BRM utility after you change the rates for cycle forward and cycle forward arrears events in the current cycle. This utility triggers the creation of rerating requests that the pin_rerate utility uses to recalculate the charges for these events and adjust the balance impacts.
For information on rate changes in a cycle, see "About Calculating Charges When You Change the Rate" in BRM Configuring and Running Billing.
For information on the pin_rerate utility, see "pin_rerate".
The pin.conf file for this utility is in BRM_Home/apps/pin_rate_change.
Displays information about successful or failed processing as the utility runs.
Note:
This parameter is not position dependent. For example, you can enter -v at the beginning or end of a command to initiate the verbose parameter. To redirect the output to a log file, use the following syntax with the verbose parameter. Replace filename.log with the name of the log file:pin_rate_change any_other_parameter –v > filename.log
Creates a log file for debugging purposes. Use this parameter for debugging when the utility appears to have run with no errors, but the data has not been loaded into the database.
Displays the syntax and parameters for this utility.
The pin_rate_change utility notifies you when it successfully creates the rerating requests.
If the pin_rate_change utility does not notify you that it was successful, look in the utility log file (default.pinlog) to find any errors. The log file is either in the directory from which the utility was started, or in a directory specified in the configuration file.
Loads batches of prerated or rerated event records from Pipeline Manager into the BRM database.
There are two ways to use this utility. When you initially run pin_rel, use the command without any options and use the file name as the only command-line parameter. You use the override option when the utility has not successfully completed its process and needs to be rerun.
pin_rel records any errors in the pin_rel log file (BRM_Home/apps/pin_rel/rel.pinlog).
This option starts a new pin_rel process. Use this option to restart pin_rel when it has abnormally stopped or you have stopped it manually.
Important:
Use this option only when you know there are no other RE Loader processes running.RE Loader maintains a status of its operations. Because only one RE Loader process can load events into the same database at the same time, the status must indicate the loading process is complete before another process can start loading. If you manually stop pin_rel, its status may not reflect its true state. The -override parameter overrides the status and permits a new loading process to start, providing one is not already running.
The name of the event file to load, including its extension.
If pin_rel is successful, it returns PROCESSED SUCCESSFULLY in the RE Loader log file (BRM_Home/apps/pin_rel/rel.pinlog).
If an error occurs during loading, this utility aborts the loading process. An error is logged in the rel.pinlog file, SQL loader errors are logged in a ”bad” file (BRM_Home/apps/pin_rel/CDR_file_name.bad), and the records loaded in this session are deleted from the database.
If an error occurs during account updating, the error is logged in the rel.pinlog file. Loaded records are not deleted from the database.
Use this BRM utility to rerate events rated in real-time and events rated in batch by Pipeline Manager, and update account balances with the rerated results. For more information, see "Using the pin_rerate Utility".
If you rerate both real-time-rated and pipeline-batch-rated events concurrently, you run pin_rerate multiple times: once to create rerating jobs by selecting the accounts and events for rerating, and several times again to process the rerate jobs.
If you do not use Pipeline Manager for batch rating, you select the accounts and events and rerate them by using a single pin_rerate command.
Note:
pin_rerate is a multithreaded application.
In a multischema environment, you must run pin_rerate separately on each database schema.
To connect to the BRM database, the pin_rerate utility needs a configuration file in the directory from which you run the utility.
BRM_Home/bin
The pin.conf file for this utility is located in BRM_Home/apps/pin_rerate. Run pin_rerate from this directory.
pin_rerate [-t [ss/mm/hh/] MM/DD/YYYY] [-a account POID_id] [[-d | -g | -i | -m | -n | -p | -s] input_file] [-line subscription_id] [-field_name input_file] [-r] [-reason reason_code] [-b [c | e]] [-c] [-backout] [-e [-a | -s | -p | -n | -d]] [-h | help] [-purge [-t [ss/mm/hh/] MM/DD/YYYY]] [-l [d | s | sd | n]] -process jobs [-reason reason_code [,reason_code...]] -process queue -rerate [-reason reason_code [,reason_code...][-l [d | s | sd | n]] -process recycle [-db database_id]
The parameters specify which accounts and events to rerate and which rerating process to perform.
To select the accounts and events for rerating, see the following sections:
To assign a rerate reason code for rerating, see "Parameter for Assigning a Rerate Reason".
To specify rerating behavior, such as how to order the events, whether to update the database, and whether to generate reports, see "Parameters Affecting Rerating Behavior".
To purge rerate jobs, see "Parameter for Purging Rerate Jobs".
To process rerate jobs and rerate the selected accounts and events, see "Parameters for Processing Rerate Jobs".
Parameters for Selecting Accounts for Rerating
The following parameters are used to select accounts for rerating based on the described event criteria.
All account selection parameters are optional and mutually exclusive, except for the -t parameter, which is mandatory when selecting the accounts and events to rerate. If you specify only the time (-t) parameter, BRM selects all accounts for rerating in the period defined by the -t parameter.
For more information about selecting account for rerating, see "Specifying Accounts for Rerating".
Selects a single account for rerating based on the provided account POID.
When you specify an account POID, you can also use the -c option to rerate events without updating the database.
This parameter is optional.
Note:
You cannot use this parameter with the -d, -g, -i, -m, -p, -s, -line, or custom parameters.Selects accounts for rerating based on the deal. Accounts that have events associated with the products and discounts that belong to the deals specified in input_file are selected for rerating.
input_file format: A text file with one deal name specified on each line. The deal names are case sensitive.
This parameter is optional.
Important:
If a product is part of multiple deals, all accounts that purchase the product are selected for rerating even if they did not purchase the deal that was rerated.Note:
You cannot use this parameter with the -a, -g, -i, -m, -n, -p, -s, -line, or custom parameters.Selects accounts for rerating based on one of the following:
The account and bill unit objects
The account, bill unit, and balance group objects
Accounts that match any criteria listed in input_file are selected for rerating.
If items in input_file specify an account, bill unit, and balance group, only events specific to the balance group are selected.
If items in input_file specify an account and a bill unit only, pin_rerate searches for all the balance groups associated with the bill unit and then selects the events specific to those balance groups.
input_file format: A text file containing information for one or more accounts in flist format. Specify an account POID, /billinfo POID, and balance group POID in a results array for each account. For example:
0 PIN_FLD_RESULTS ARRAY [1]
1 PIN_FLD_ACCOUNT_OBJ POID [0] $DB_NO /account 12345 0
1 PIN_FLD_BILLINFO_OBJ POID [0] $DB_NO /billinfo 34567 0
1 PIN_FLD_BAL_GRP_OBJ POID [0] $DB_NO /balance_group 66765 0
0 PIN_FLD_RESULTS ARRAY [1]
1 PIN_FLD_ACCOUNT_OBJ POID [0] $DB_NO /account 12344 0
1 PIN_FLD_BILLINFO_OBJ POID [0] $DB_NO /billinfo 45654 0
1 PIN_FLD_BAL_GRP_OBJ POID [0] $DB_NO /balance_group NULL 0
...
where:
PIN_FLD_ACCOUNT_OBJ specifies the POID of the account object.
PIN_FLD_BILLINFO_OBJ specifies the POID of the bill unit object.
PIN_FLD_BAL_GRP_OBJ specifies the POID of the balance group object.
To rerate all events for all balance groups for a given account's bill unit, specify a value of NULL as the POID ID for the balance group object, as shown in the second results array in the above example.
This parameter is optional.
Note:
You cannot use this parameter with the -a, -d, -i, -m, -n, -p, -s, -e, -line, or custom parameters.Selects accounts for rerating based on the discount object. Accounts that own at least one instance of the discount objects specified in input_file are selected for rerating.
input_file format: A text file with one discount name specified on each line. Discount names are case sensitive.
This parameter is optional.
Note:
You cannot use this parameter with the -a, -d, -g, -m, -n, -p, -s, -line, or custom parameters.Selects a set of accounts for rerating based on the provided account POIDs.
input_file format: A text file containing the accounts to rerate in flist format. Specify each account in a results array. For example:
0 PIN_FLD_RESULTS ARRAY [1]
1 PIN_FLD_ACCOUNT_OBJ POID [0] $DB_NO /account 12345 0
0 PIN_FLD_RESULTS ARRAY [2]
1 PIN_FLD_ACCOUNT_OBJ POID [0] $DB_NO /account 12333 0
...
where PIN_FLD_ACCOUNT_OBJ is the POID of the account object.
Note:
You cannot use this parameter with the -a, -d, -g, -i, -n, -p, or -s -e, -line, or custom parameters.Selects accounts for rerating based on the event types. Accounts that have events of the types specified in input_file are selected for rerating.
input_file format: A text file with one event type specified on each line. Event types are case sensitive.
This parameter is optional.
Note:
You cannot use this parameter with the -a, -d, -g, -i, -m, -p, -s, -line, or custom parameters.
If you use this parameter with the -r parameter, all subclasses of the event type specified in the input file are also rerated. For more information, see "Specifying Events for Rerating".
When using a custom pin_rerate parameter, the -n parameter is mandatory if the custom parameter is based on an event field that is present only in an event subclass. In this case, the -n parameter input file can contain only one event type.
Selects accounts for rerating based on the product. Accounts that have events associated with the products specified in input_file are selected for rerating.
input_file format: A text file with one product name specified on each line. Product names are case sensitive.
This parameter is optional.
Note:
You cannot use this parameter with the -a, -d, -g, -i, -m, -n, -s, -line, or custom parameters.Selects accounts for rerating based on the service type. Accounts that have events associated with the service types specified in input_file are selected for rerating.
input_file format: A text file with one service type specified on each line. Service type names are case sensitive.
This parameter is optional.
Note:
You cannot use this parameter with the -a, -d, -g, -i, -m, -n, -p, -line, or custom parameters.Selects accounts for rerating based on the event start time. All accounts with events that occurred between the start time and the current date are selected for rerating.
Note:
The group of selected accounts can be further restricted by using criteria specified with the -a, -d, -g, -i, -m, -n, -p, -s, -line, or custom parameters.Selects accounts for rerating based on a subscription service.
subscription_id specifies the subscription service ID. The subscription service is identified by the PIN_FLD_ALIAS_LIST.PIN_FLD_NAME field, which can specify, for example, the caller ID such as a phone number or the MAC address.
This parameter is optional.
Note:
The group of selected accounts can be further restricted by using criteria specified with the -a, -d, -g, -i, -m, -n, -p, -s, or custom parameters.field_name is a custom pin_rerate parameter you have defined that maps to a specific event field.
input_file is a file that contains the values of the event field that are used to select the accounts for rerating.
Selects accounts based on the custom parameter. Accounts are selected for rerating that have events with the field identified by field_name whose field value is one of those specified in input_file.
For information about defining custom pin_rerate parameters, see "Defining Custom pin_rerate Parameters for Rerating".
Note:
You cannot use this parameter with the -a, -d, -g, -i, -m, -p, -s, or -line parameters.Important:
If the custom parameter maps to a field in an /event subclass, you must specify the subclass event type by including the -n parameter, and the -n parameter input file can include only one event type. If you specify more than one event type, an error is returned.Parameter for Specifying Events for Rerating
Use the following parameter to specify which events to rerate for the selected accounts.
For more information about selecting events for rerating, see "Specifying Events for Rerating".
Specifies whether to use selective rerating. This applies the account selection criteria parameters (-a, -d, -g, -i, -m, -n, -p, -s, -line or field_name) to the account's events as well and selects events for rerating based on the specified parameter. For example, using -r and -p input_file in the command line selects accounts based on the products specified in input_file, and then selects and rerates only the account's events associated with those products.
Important:
Do not use selective rerating if your rating scheme includes credit limits or resource-based tiers. These schemes require that all events related to an account are rerated to ensure accurate rerating.
Do not use selective rerating if deferred taxation is used for taxing events during rerating.
Use caution when specifying selective rerating. Account balances can be impacted by different types of events, and the order of the balance impacts is important to accurately apply discounts and consume resources. It is typically safer to rerate all of an account's events.
This parameter is optional and can be used with any other parameter. The value for this parameter can be specified as either 0 (disable) or 1 (enable).
Note:
If no value is specified for this parameter, the default behavior is to consider the value as 1.Parameter for Assigning a Rerate Reason
Use with other selection parameters to assign a rerate reason code to the jobs created for the selected accounts.
For more information about assigning rerate reason codes, see "Assigning Rerate Reasons to Rerate Jobs".
Reason code format: Any integer except 1 (1 is a reserved default value for pipeline-generated rerating requests).
If you create rerate jobs through BRM automatic rerating, rerate reasons are hard coded by the opcodes that handle those rerating scenarios. Be sure your rerate reasons are unique to process rerate jobs associated with them during separate rerating executions.
To process rerate jobs according to a rerate reason, see "Parameters for Processing Rerate Jobs".
Parameters Affecting Rerating Behavior
The following are additional, optional parameters that affect rerating behavior and the utility's output.
Specifies the order in which batch events are rated. The c option rerates events in the order that they were created in the BRM database. The e option rerates events based on the time when the event actually occurred. The default is e. For more information, see "Specifying the Event Sequence for Rerating".
Note:
Due to real time account balance impacts and credit limit monitoring, the order in which the batch events are processed may result in different rating results. For more information, see "About Rerating Pipeline and Real-Time Events Concurrently".This parameter is optional.
Specifies calculation of rerating only. Use this parameter to log the rerating result of an account into a report file without updating the database. This option can be used for only one account, so it works only when using the -a parameter.
This parameter is optional.
Specifies back-out-only rerating, which backs out the balance impacts of rating without rerating events.
For more information about back-out-only rerating, see "Using pin_rerate for Back-Out-Only Rerating".
This parameter is optional and can be used with any other parameter.
Note:
When choosing the events to back out, ensure that you do not select events that could imbalance your general ledger, such as events for which fees have already been paid and usage events that should be rerated. Typically, back-out-only rerating is performed only on usage events where rating should not have occurred.Returns an estimate of how many events might be affected by rerating based on which accounts are being rerated. Options:
-e -a: A single account
-e -s: Accounts with a specific service type
-e -p: Accounts with specific products
-e -n: Accounts with specific event types
-e -d: Accounts with specific deals
Note:
If you do not specify one of these options when using the -e parameter, the utility returns 0.The pin_rerate utility prints the output of this option on the screen or to the pin_rerate.pinlog file in $PIN_LOG/pin_rerate.
This parameter is optional.
Note:
You cannot use this parameter with the -m or -g parameters.Displays the syntax and parameters for this utility.
Specifies whether to generate a report. Options:
-ld: Specifies a detailed report (pin_rerate.detail).
-ls: Specifies a summary report (pin_rerate.summary).
-lsd: Specifies both detailed and summary reports. This is the default.
-ln: Specifies no report.
Note:
When Pipeline Manager is running, you can specify these report options at rerate time (when you use the -rerate parameter). You cannot specify them when you create the rerate jobs.For more information, see "Reports Generated by the pin_rerate Utility".
Parameters for Processing Rerate Jobs
You use different parameters to process rerate jobs depending on whether you rerate real-time-rated and pipeline-batch-rated events concurrently or, if you do not use Pipeline Manager for batch rating, rerate only real-time-rated events.
Processing Rerate Jobs When Rerating Real-Time and Pipeline Rated Events Concurrently
To process rerate jobs when rerating real-time and pipeline rated events concurrently, you run the following commands in the order shown.
pin_rerate -process jobs [-reason comma_separated_reason_codes] pin_rerate -process queue pin_rerate -rerate [-l [d | s | sd | n] ] pin_rerate -process queue pin_rerate -process recycle
Important:
You must run pin_rerate with all of the above parameters to complete the rerating process.These commands process rerate jobs that were created both manually, by running pin_rerate to select accounts for rerating (see "Parameters for Selecting Accounts for Rerating"), and automatically, by BRM automatic rerating features.
The parameters specify the following:
Searches for all rerate jobs with status equal to NEW, and notifies Pipeline Manager to lock the accounts in the rerate jobs. Then updates the status of the rerate jobs to WAITING_ACCOUNT_LOCK.
If you use the -reason parameter, performs the same actions but only for the rerate jobs associated with the specified reason codes, where:
specifies the codes you assigned as the rerate reason for the jobs you want to process. For more information, see "Assigning Rerate Reasons to Rerate Jobs".
Note:
If you do not specify a rerate reason code, all rerate jobs in the rerate queue are processed.For more information, see "Processing Rerate Jobs According to a Rerate Reason Code for Concurrent Rerating".
Processes acknowledgment events from Pipeline Manager and updates rerate job status as follows:
If acknowledging notification to suspend EDRs, it updates the status to ACCOUNT_LOCKED.
If acknowledging notification to resume processing EDRs, it updates the status to READY_TO_RECYCLE.
This parameter is used twice: before and after the -rerate parameter.
Rerates events for the accounts referenced in the rerate jobs, and updates the rerate job status to RERATED.
Specifies to generate a rerating report. Options are:
-ld: Generates a detailed report (pin_rerate.detail).
-ls: Generates a summary report (pin_rerate.summary).
-lsd: Generates both detailed and summary reports. This is the default.
-ln: Generates no report.
For more information, see "Reports Generated by the pin_rerate Utility".
Recycles the EDRs suspended during the rerating process, and updates the rerate job status to COMPLETE.
-db database_id: Specifies the ID of the database schema that contains the suspended EDRs in the format x.x.x.x (for example, 0.0.0.2). Use this only if the suspended EDRs are not stored in the current BRM schema.
Note:
If you do not specify the -db database_id parameter, the suspended EDRs are picked up from the current schema.For more information about processing rerate jobs for concurrent rerating, see "Processing Rerate Jobs for Concurrent Rerating".
Processing Rerate Jobs When You Do Not Use Pipeline Manager
If you do not use Pipeline Manager for batch rating, rerate jobs for real-time-rated events are processed as follows:
When you run pin_rerate with parameters that specify the accounts and events to rerate, pin_rerate creates the rerate jobs for those accounts are then immediately rerates their events.
Rerate jobs that already exist (such as those created by automatic rerating) are processed with the following parameter:
Rerates events for the accounts referenced in the rerate jobs, and updates the rerate job status to COMPLETE.
If you use the -reason parameter, performs the same actions but only for the rerate jobs associated with the specified reason codes.
comma_separated_reason_codes
Specifies the codes you assigned as the rerate reason for the jobs you want to process. For more information, see "Assigning Rerate Reasons to Rerate Jobs".
Note:
If you do not specify a rerate reason code, all rerate jobs in the rerate queue are processed.For more information, see "Processing Rerate Jobs per a Rerate Reason When Rerating Only Real-Time-Rated Events".
Parameter for Purging Rerate Jobs
Use the following parameter to purge rerate jobs.
Purges rerate jobs that have a rerate job status of COMPLETE or UNSUCCESSFUL.
[-t [ss/mm/hh/] MM/DD/YYYY]
Specifies to purge rerate jobs that have had their rerate job status set to COMPLETE or UNSUCCESSFUL before the time specified.
If no time is specified, all rerate jobs that have a rerate job status of COMPLETE or UNSUCCESSFUL are purged up to the current date.
If the pin_rerate utility does not notify you that it was successful, look in the utility log file (pin_rerate.pinlog) to find any errors. The log file is either in the directory from which the utility was started, or in a directory specified in the configuration file.
If rerating fails, the utility creates a report that includes the account numbers and start times for failed rerates. The report file name is pin_rerate.status_report, and is in the directory from where you ran the utility.