Browse Prior Art Database

Assembler Macro Implementation

IP.com Disclosure Number: IPCOM000112356D
Original Publication Date: 1994-May-01
Included in the Prior Art Database: 2005-Mar-27

Publishing Venue

IBM

Related People

West, W: AUTHOR

Abstract

The solution described in this article grew out of a need to be able to implement an Assembler Language macro which required many subparameters to support a new diagnostic software program. The conventional method of implementation provided by an Assembler Language compiler Macro Facility was found to have the disadvantages of being:

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 13% of the total text.

Assembler Macro Implementation

      The solution described in this article grew out of a need to be
able to implement an Assembler Language macro which required many
subparameters to support a new diagnostic software program.  The
conventional method of implementation provided by an Assembler
Language compiler Macro Facility was found to have the disadvantages
of being:

o   more expensive in implementation effort than necessary

o   more expensive and "unfriendly" in application for the user than
    necessary
and instead the present method of implementation as described below
was chosen which expands the Macro Facility parameter handling
capability.

      The task was to implement an Assembler Language macro interface
which described the characteristics of a  computer program to be
analyzed by the new diagnostic software.  It was desirable that this
macro be a "one step", easy-to-use tool for a system analyst to be
able to describe the state, both static and dynamic, of the computer
program under investigation, at the location of a given trace point.
Also the macro needed to be usable in a customer environment (in
customer programs compiled to execute as VSE/POWER user exit
routines) and therefore should not impact existing customer programs.
The states chosen at the beginning were:

o   static states (indicators at the physical code location of the
    trace point)

    Module Name     name of module where trace point located (e.g.,
                    "IPW$$LR")

    Trace Point ID  a unique numerical identifier of the trace point
                    within the module named (e.g., "001")

    Text            short text to describe the situation functionally
                    (e.g., "READING INPUT")

    Functional Group the "functional group" to which the code
                    location belonged (e.g., "CARD READER SUPPORT" or
                    "TAPE READER SUPPORT") (*)

    (Miscellaneous:) Various other characteristics:
                    Entry Point     the ENTRY point from a caller
                    Return Point    the RETURN point to a caller
                    External Call   an EXTERNAL component call
                    External Return an EXTERNAL component return
                                    point

o   dynamic states (indicators at the time of the trace point
    execution)

    Data Areas      the contents of various "data areas" of main
                     storage, (e.g., an input data area or a task
                     control block) (*)

    Resources       the names of "resources" being used by the
                     program at the trace point (e.g., the input
   ...