4. CUSTOMIZATION › 4.15 Defining and Submitting Utility Jobs › 4.15.3 Defining the Utility Job Processing Routine › 4.15.3.3 Accounting Table Maintenance Utility
4.15.3.3 Accounting Table Maintenance Utility
This Accounting Table utility is used to apply maintenance to
the following production accounting ISPF tables:
o Invoice categories table
o Credit categories table
o Charging elements table
o Journal files table
o Menu item table
The utility supports the following functions:
1) add - allows for the adding of new rows to the
specified table. If the row to be added
already exists in the table then the add
function can be requested to perform the add
with a rename option. This will result in the
row being added under a new name.
2) modify - allows for the verify and update of existing
rows in the specified table. The verification
consists of specification of a field in the row
to be updated and its corresponding value. If
the row does contain the specified field and if
the value is correct, then the verified value
is replaced with the corresponding value from
the master version of the specified table. If
the verification fails, a force option can be
specified which results in the update being
performed without the verification check.
The utility performs the above two functions based on a
control file. The control file is comprised of the following
statements:
o $TABLE - specifies the names of the tables to be updated.
Up to five tables can be specified. The statement
has the following format:
$TABLE table_name1 table_name2 ...
where,
table_name is the name of the table to be updated.
Valid table names are:
MAF$INVC - Invoice categories table
MAF$CRED - Credit categories table
MAF$ELEM - Charging elements table
MAF$JOUR - Journal files table
MAF$STP - Menu item table
o $ADDLN - specifies the table and the name of a row to be
added. The row to be added is specified by giving
the name and the value of the control variable for
the row. The statement has the following format:
$ADDLN table_name cntl_var value rename new_value
where,
table_name is the name of the table to be updated and
must have been specified on the preceding
$table statement.
cntl_var is the name of the control variable for the
row to be added.
value is the value of the control variable for the
row to be added.
rename indicates that the row is to be added with a
new value for the control variable if the
original row to be added already exists.
new_value is the value to be used for the control
variable in the event a rename is required.
o $MODLN - specifies the table and the name of a row to be
updated. The row to be updated is specified by
giving the name and the value of the control
variable for the row. The statement has the
following format:
$modln table_name cntl_var value ver_var ver_value force
where,
table_name is the name of the table to be updated and
must have been specified on the preceding
$table statement.
cntl_var is the name of the control variable for the
row to be updated.
value is the value of the control variable for the
row to be updated.
ver_var is the name of a variable in the specified
row to be used to verify the state of the row
prior to update.
ver_value is the value of the verify variable. the
value of the verify variable in the specified
row must match this value in order for the
update to be performed.
force indicates that the row is to be updated even
if the verification fails.
Within the scope of a $table statement no tables are
actually updated until all statements are processed.
Because a single $table statement can specify all accounting
tables, this utility provides a method for ensuring that no
table is updated unless all modifications are successful.
If there is an error, the job does not update any tables.
You must correct the error by choosing one of the following
options and rerun the ACTnnnnA job:
o Place an asterisk (*) in column 1 of the control
statement in the ACTnnnnA job that is causing the
conflict. Any statement that has an asterisk (*) in
column 1 is ignored.
If you choose this option, the item will not be added,
and you will not be able to use it.
o Using the CA MICS Workstation Facility Accounting and
Chargeback panels, rename or delete the item that is
causing the conflict.
It may be necessary to revise your rate table if you
are using user-defined computation codes in a rate
table. User-defined computation codes should be in the
8000-9999 range.
o Change the identifier (computation code, invoice, or
credit category) for the item being added in the
ACTnnnnA control statements.
For example, to change computation code 1870, add
RENAME nnnn to the end of the $ADDLN statement for
ELMCCODE 1870, where nnnn is the computation code that
you wish to use. User-added computation codes should
be in the 8000-9999 range. An example follows:
$ADDLN ELMCCODE 1870 RENAME nnnn
After you have resolved the conflicts and resubmitted the
ACTnnnnA job, examine the ISPLOG and MICSLOG for error
messages. Ensure that the job completes with a condition
code of zero.
