7. PARAMETERS › 7.3 Unit-Level Parameters › 7.3.2 IMS Application Unit Definition

7.3.2 IMS Application Unit Definition

In CA MICS, data about IMS activity is stored by application
unit identification in the following files:

     IMS Application Unit Activity   -   (IMSIAU)
     (transactions scheduled via standard IMS scheduling)

     IMS Application Unit Activity   -   (IMS_IA)
     (transactions scheduled via Fastpath EMH but Non-BMC
     MAINVIEW for IMS Online)

     IMS User Application Count File -   (IMSIAC)

The IMS application unit identifier is twelve bytes long and
is named "IMSAPU".  It is part of the key in the three
above-mentioned files.  Any information may be stored in this
field by the application unit IMSAURT derivation exit, from
the partial or full contents of any field in the IMS monitor
data input to CA MICS (such as Transaction ID, Terminal ID,
or PSBNAME).

The methods used for classification of IMS workload vary from
installation to installation and may be based on one of the
following approaches:

  o  Classification by transaction identification

     Normally this approach utilizes a table lookup of IMS
     transaction ID to group the work.  For example,
     transactions 'ABCD' and 'WXYZ' are always heavy resource
     drains, while other transactions are quick inquiry
     transactions.

  o  Classification by service area requested

     This approach classifies work based on the service area
     exercised.  For example, a bank may divide transactions
     into the application categories of demand deposits, time
     deposits, administrative services, and system support
     activity.  This method typically identifies the
     application unit by a prefix of the IMS transaction ID
     (such as demand deposit transaction IDs all begin with
     the letter 'R').

  o  Classification by user

     This approach classifies transaction data according to
     the user who requested the service.  This method can use
     various ways to extract the identity of the requestor
     from the IMS terminal or line identifiers.

For example, you might define your application structure as
having two parts, such as Project and Transaction Identifier,
respectively.  You might assign the first two bytes of the
twelve byte IMSAPU field as Project Identification, and the
next four bytes as the first four bytes of the IMS
Transaction ID (the remaining bytes would be blank).

In this example, the actual values of the field might be:

              111
     123456789012   Project          Transaction
     ------------   ---------------  ------------------------
    'DDRBAL      '  Demand Deposits  Account Balance Inquiry
    'TDINQN      '  Time Deposits    Name and Address Inquiry

CA MICS does not support a means of changing the
characteristics of the IMSAPU data element (by making it
longer or shorter, for example).


Usage Notes:

1.  There may be certain groups of transactions that are of
    more interest when considered as a group than when
    considered by individual transaction ID.  Examples of
    such transactions are:

    o  Transactions associated with purchased application
       packages, such as IBM Field Developed Programs.

    o  Trivial applications, especially those frequently
       used, such as simple menu processors.

    The grouping together of such transaction data in this
    routine greatly decreases the amount of storage needed to
    represent Application Unit data in the CA MICS database.

2.  Any data element that could be useful in later reporting
    from the Application Unit file MUST be coded into the
    application unit identifier if the data element is not
    contained in the rest of the record.  An example is the
    data element TRANTYPE.  It may be useful in some sites to
    be able to group application unit data by Short, Medium,
    Long, or Conversational transaction type.  However,
    TRANTYPE is not normally part of the record in this file.
    It is therefore in your interest to consider saving
    TRANTYPE somewhere in the application unit ID.

    These concepts apply to both the IMSIAU and IMS_IA files.
    The IMS_IA file is a CA MICS "parallel" file to the
    IMSIAU file and uses the same named elements and sequence
    fields.  The IMSIAU file contains observations related to
    transactions utilizing normal IMS scheduling while the
    IMS_IA file contains observations for transactions
    utilizing Fastpath EMH scheduling.