HP 3000 Manuals HP 3000 Manuals
The Program Analyst
The interpreter maintains extensive data structures that describe the
current program. That information can be valuable for developing and
maintaining programs. The Program Analyst is an environment that makes
this information available and provides tools for analyzing the
information. The Program Analyst can be used for design optimization,
memory usage analysis, program statistics information, and optimization
of subunit sizes.
ANALYST
The ANALYST command enters the Program Analyst environment. The
following conditions must be met to successfully run the Program Analyst:
* The terminal fully supports the terminal-specific features of HP
Business BASIC/XL.
* The interpreter is running in a session, rather than a batch job.
* There is at least one program line in the current program.
* The program is not running or paused.
* The program has no VERIFY errors.
* The destination for OUTPUT and SYSTEM OUTPUT is the display.
Syntax
ANALYST [screen_argument]
Parameters
screen_argument An argument that specifies which screen to enter. If no
screen is specified, the Main Menu/Browse screen is
displayed.
Table 2-10 lists each argument, and the screen that it displays.
Table 2-10. Analyst Command Arguments
--------------------------------------------------------------------------------------------
| | |
| Argument | Screen Selected |
| | |
--------------------------------------------------------------------------------------------
| | |
| S | Static Analysis. |
| | |
| O | Optimize. |
| | |
| D | Data Types. |
| | |
| C | Suggest COPTIONs. |
| | |
| G | Replace GOSUBs. |
| | |
| P | Optimize PACKFMTs. |
| | |
| E | Extract Subunit. |
| | |
--------------------------------------------------------------------------------------------
This section describes each screen. Each action that occurs in a
particular screen is explained. The following control actions work from
any screen:
* To exit the Program Analyst press f8.
* Pressing HALT while the Program Analyst is waiting for input
transfers control to the next height level screen.
* Pressing HALT while the Program Analyst is writing information to the
screen returns control to the Main Menu/Browse screen.
* Pressing HALT while in the Main Menu/Browse screen exits the Program
Analyst.
All files created by the Program Analyst have a set of comments giving
the file name, the date and time of creation, the name of the screen
being used, and the original name of the program as their first few
lines.
The user interface capabilities used in the Program Analyst are available
in HP Business BASIC/XL applications through the following statements and
functions:
ON KEY
ON HALT
CURSOR
RESPONSE
ACCEPT
TINPUT
NOTE The features of the Program Analyst can change from one release to
the next. Whenever you receive a new version of HP Business
BASIC/XL, check the NEWS category in the HELP facility for
information on changes and enhancements.
In some screens, the Program Analyst creates file whose names have the
form BBPAnn. After you have merged one of these files, purge it. If you
have many of these files in your group, the Program Analyst spends extra
time trying to find an unused name.
The Main Menu/Browse Screen. The purpose of this screen is to provide
general information about the current program.
The Main Menu/Browse Screen displays the following information about the
current program:
* The name of the program (the BSAVE file name).
* The time and date when the program was last saved.
* The overall subunit space and fixed data space requirements of the
program.
* The subunit space and fixed data space requirement of each subunit.
* The source code listing, shown in blocks of eight lines.
The cursor is on the first character of the current subunit name. Table
2-11 shows the actions that you can perform while in the Main Menu/Browse
screen.
Table 2-11. Main Menu/Browse Screen Actions
---------------------------------------------------------------------------------------------
| | |
| Action | Effect |
| | |
---------------------------------------------------------------------------------------------
| | |
| Softkeys | Pressing one of the labeled softkeys moves between adjacent subunits |
| | or to a different screen. |
| | |
---------------------------------------------------------------------------------------------
| | |
| Line number | Entering a line number moves to that line. If the line exists, it is |
| | the first line displayed, and the subunit containing it is the |
| | current subunit. |
| | |
---------------------------------------------------------------------------------------------
| | |
| Subunit Name | Entering a subunit name moves to that subunit. If the name entered |
| | matches a subunit in the program, that subunit is the current subunit |
| | and its first eight lines are displayed. |
| | |
---------------------------------------------------------------------------------------------
| | |
| RETURN | Pressing RETURN displays the next eight lines of the current subunit. |
| | This method can only be used in the current subunit, and cannot be |
| | used to move to the next subunit. |
| | |
---------------------------------------------------------------------------------------------
The Static Analysis Screen. The purpose of this screen is to provide
detailed statistics about the program and its system requirements.
The Static Analysis screen displays detailed information about each
subunit of a program. It contains three types of information. The
following lists describe the information that this screen provides.
Interpreter Resource Utilization: This section contains information
about resource utilization within the interpreter. Resources include
tables, data segments, and interpreter space. The fields and their
contents are:
Field Contents
Global Tables The amount of space (in words) taken to store the
interpreter's directory information for locating
and managing all of the programs subunits.
Included are tables holding the names of the
subunits.
Local Tables For the subunit being displayed, this value is the
amount of space for all tables that reside in the
subunit space area of the interpreter's data
stack.
New Run-time Tables When a program contains references to external
routines or intrinsics, the interpreter requires
additional space for parameter information at
run-time. This value is an estimate of that space
requirement.
Recoverable The interpreter's tables can sometimes become
cluttered with unnecessary information,
particularly when extensive editing has been done.
The tables can be cleaned by saving the program in
ASCII format (through the SAVE LIST command) and
then issuing a GET command. The value displayed
is an estimate of the number of words in the
subunit space that would be recovered by a SAVE
LIST and GET.
COMMON Space The spaced required by all variables declared in
COM statements.
Local Space Space for locally declared (or undeclared)
variables and parameters. This number is broken
down into Numeric Space and String Space fields.
Software Metrics This section provides statistics about the program.
Many techniques exist for measuring the size and complexity of software
and the amount of structure it contains. The Program Analyst can measure
these features quickly and accurately. The significance of the numbers
is left up to the programmer. The fact that the numbers are generated
should not be considered an endorsement of a particular technique, nor is
it the intent to pass judgement on the user's code. This section
contains the following information:
Field Contents
Source Lines The number of lines in the subunit. This is the
number of unique line numbers. Continuation lines
are not counted.
Comments The total number of comments including REM
statements, comment lines, and comments placed at
the end of other program lines.
NCSS Non-Comment Source Statements. The number of
program lines that do not consist entirely of a
comment or REM.
Code Volume An attempt to quantify the information content of
(Halstead) a group of source statements, in this case a
subunit or program. Code volume is a number
calculated from the number of unique identifiers
and operators and the number of occurrences of
these identifiers and operators.
Complexity (McCabe) This value is the number of decision points in the
subunit or program, plus one.
Structure Compliance Indicates the percentage of branches that are
(DeMarco) accomplished without explicit GOTO statements.
All of the structured statements are counted as
branches, including each value or range in a CASE
statement.
Statement Frequency The Statement Frequency section lists the 21 most
frequently used statements in the subunit. The statement names are
displayed with the frequency count.
The Optimize Screens. The Program Analyst contains four screens that are
specifically designed to help improve the efficiency of the current
program. The next four sections describe each of these screens.
The Data Types Screen. The purpose of this screen is to provide
information to minimize run-time conversions through more efficient
definitions of variable data types.
This screen displays information for the entire MAIN subunit. The name
of the subunit and the first and last line numbers are displayed at the
top of the screen. A predicted number of conversions is below the
subunit information is shown in a table. The lines with the most
conversions are indicated to the right of the table. The Program Analyst
predicts static conversion numbers. If a statement (such as a FOR
statement) is to be executed multiple times, the Program Analyst counts
the conversion only once. If the Program Analyst finds a control
variable that is a floating-point type, or a default REAL or DECIMAL type
and the Program Analyst can determine that the starting value, limit, and
step (if present) are all integers, the line number of the FOR loop is
reported. A FOR loop that meets those criteria is very inefficient
because the control variable has to be converted. In addition, the FOR
loop can produce incorrect results.
After the information about the MAIN subunit is display, the cursor is at
the beginning of the Line Range field at the top of the screen. To move
to a different part of the program, enter a line range or a single line
number, or press a softkey to move to the previous or next subunit. If
you select a single line, the line itself is listed at the bottom of the
screen. The data type of each numeric variable is displayed.
The Program Analyst cannot accurately detect conversions that occur
during a call to an external routine, an intrinsic, a subprogram, or a
function. Conversions may be generated if an actual parameter does not
match the declared parameter. Also, any conversions that take place to
determine which CASE to execute in a SELECT structure are not reported.
If your program uses GLOBAL OPTION DECIMAL and does not have OPTION
DECIMAL or OPTION REAL statements in each of the subunits, issue the
VERIFY command before entering the Program Analyst . This notifies all
the subunits that they will be executing in DECIMAL mode and ensures that
you get the most accurate information about conversions.
The Suggest COPTIONs Screen. The purpose of this screen is to predict
the benefit of each of the compiler options (COPTIONs) in terms of
generated code savings.
The Suggest COPTIONs screen estimates the number of words of compiled
code that would be eliminated through the use of each compiler option.
The information is displayed in four columns. The first column contains
the names of all the compiler options. If the subunit or program
currently being displayed has a compiler option in effect, the code
savings is displayed in the Current column. If the program or subunit is
not current taking advantage of that option, the potential savings is
displayed in the Potential column. The final column indicates whether
any features that would prevent the use of an option are being used. The
Program Analyst cannot estimate the actual size of a compiled subunit.
When you enter the Suggest COPTIONs screen, the cursor is positioned
under the first letter in the subunit or program name. You can type a
subunit name or line number or press a softkey to move to another subunit
or line.
The Replace GOSUBs Screen. The purpose of this screen is to replace
GOSUB statement with the subroutines the reference. This improves
performance in some situations.
If a program has GOSUBs that execute many thousands of times, the
overhead associated with them becomes noticeable. The Replace GOSUBs
screen can, with certain restrictions, be used to replace a GOSUB with
the body of the referenced subroutine. This is possible when there are
enough available line numbers after the GOSUB to insert the entire
subroutine before the next line, and the subroutine does not contain and
GOTO statements or any lines that are targets of branches.
The Replace GOSUBs screen prompts you for a line range to use to search
for eligible GOSUBs. It also asks for the maximum number of lines to be
inserted for each GOSUB. The Program Analyst then creates an ASCII file
containing a copy of the referenced subroutine. If you choose to replace
the GOSUB with the subroutine, the GOSUB statement is deleted and the
copy of the subroutine is inserted in its place. If the subroutine
contains consecutive assignment statements, the Program Analyst combines
them into fewer lines if possible.
The existence of this screen should not suggest that all GOSUBs should be
eliminated. Only those that are used very frequently should be
considered for replacement.
The Replace GOSUBs screen is useful in conjunction with the Extract
Subunit screen described later. Replace GOSUBs can help to resolve
subroutine references that might otherwise prevent a successful
extraction.
The Optimize PACKFMTs Screen. The purpose of this screen is to generate
SKIP clauses for PACKFMT statement to minimize packing and unpacking of
variables.
Often a subunit needs to access only a few items specified in a PACKFMT
statement. In a PACK or UNPACK statement, the entire record will be
transferred between the string buffer and the variable, even if the
PACKFMT statement has information for many more items than the subunit is
using.
To improve efficiency, the PACKFMT specification can contain one or more
SKIP clauses. A SKIP specifies that a certain number of bytes in the
string buffer are to be ignored during an UNPACK and skipped over during
a PACK.
The Optimize PACKFMTs screen determines which items can be skipped,
calculates the number of bytes to skip, and then modifies a PACKFMT
accordingly.
When you enter this screen, you are prompted for the line number of a
PACKFMT statement. You can enter a line number or use a softkey to list
the line numbers of all of the PACKFMT statements in your program. If
the correct line number of a PACKFMT is entered, each item in the PACKFMT
statement is examined. If the PACKFMT statement is used anywhere else in
the subunit, or if it is in common or is a parameter to the subunit, the
Program Analyst assumes that it is needed and cannot be skipped.
Otherwise, the Program Analyst determines the number of bytes in that
item and generates a SKIP. If adjacent items can be skipped, the Program
Analyst creates only one SKIP clause to cover those items. The items
that can be skipped are highlighted.
If skippable items are found, pressing RETURN will cause the Program
Analyst to create an ASCII file containing the following statements:
* The original PACKFMT line with the actual statement commented out
with a !.
* The new PACKFMT statement with a line number one greater than the
original.
When this file is merged (using the MERGE command) back into the program,
the original line serves as documentation of the complete record layout.
If you are referencing a PACKFMT statement by a line number instead of a
label, you need to modify the appropriate PACK or UNPACK statement.
When determining the number of bytes in a string variable, the Program
Analyst uses the maximum declared length (or 18 if the string is
undeclared). The Program Analyst assumes that strings are always padded
out to their maximum length before packing them. This is recommended
practice because the maximum length is always used during an UNPACK.
The Optimize PACKFMTs screen can also be used to optimize IN DATASET
statements. You can modify a IN DATASET statement so that it looks like
a PACKFMT statement, optimize the modified statement, merge the statement
into the program, and then modify it back to an IN DATASET statement.
The Extract Subunit Screen. The purpose of this screen is to assist in
dividing large subunits into smaller subunits.
Manually removing lines form one part of a program and using the lines to
create a new subunit can be tedious. There are many dependencies that
must be examined. The Program Analyst can be very useful for extracting
subunits. Using the information in the interpreter, the Program Analyst
can detect all of the following dependencies:
* Branches that will be broken if lines are removed.
* Variables that have been shared between the old and new subunits that
must become parameters or placed in common.
* Single-line functions definitions and OPTION, IMAGE, and PACKFMT
statements that will be needed in the new subunit.
On entry of a line range, the Program Analyst displays the effects of
removing this line range from its subunit. The Program Analyst examines
all GOTOs, GOSUBs, and structured statements to determine whether they
would be affected. It also determines whether variables (including
files) need to be passed as parameters to the proposed new subunit. Once
you have identified a line range that can be extracted without breaking
any branches or structures, the Program Analyst creates the new subunit
and the CALL to it.
NOTE The Program Analyst allows you to extract a subunit even if there
are broken branches. Manual editing may be required before the new
program can run.
Factors Affecting Extraction. The following factors that can affect
extraction cannot be fully analyzed:
* DATA, READ, and RESTORE statements.
* Report Writer usage.
* SORT USING statements.
* THREAD statements.
* RETURN statements.
* ON ERROR, ON KEY, ON HALT, etc.
The Program Analyst may produce warnings if these features are used in
the subunit being divided. However, the Program Analyst continues to
create the subunit. If will be up to you to make any necessary manual
changes.
When the Program Analyst creates a new subunit, it handles the following
requirements automatically:
* Creation of parameter lists.
* Copying of necessary common block declarations.
* Copying of necessary single-line function definitions.
* Copying of necessary IMAGE and PACKFMT statements.
* Moving declarations of variables that are only using in the new
subunit into that subunit.
* Copying of OPTION statements.
The Program Analyst does not alter your program. It produces two ASCII
files that you can GET and MERGE to create an altered program. If you
are planning to extract more than one subunit, you must do the GET and
MERGE for the first subunits before analyzing subsequent subunits.
Extracting a Subunit. The following is a list of the steps required to
extract a subunit:
1. Renumber the program to allow space between lines so the Program
Analyst can insert any necessary lines.
2. Get and examine a listing. The Program Analyst normally assumes
lines are to be extracted from the MAIN subunit. Also, the
Program Analyst cannot create a multi-line function this way.
Look at the listing to find logical subunit material.
3. Enter the Program Analyst and go to the Extract Subunit screen.
Enter the line range that you want to analyze. Use existing line
numbers.
4. When you enter a line range, the Program Analyst displays
information about branches, structured statement, variables, and
detectable problem conditions. Try different line ranges until
you find one that will not cause many broken branches.
5. Press the softkey labeled Extract. Use any legal HP Business
BASIC/XL identifier. The Program Analyst creates the two files
used to produce the altered program. The first file is the
original program with the extracted lines replaced by a CALL
statement, and the second is the new subunit.
6. Exit the Program Analyst.
7. GET the original program file (the one whose name begins with g)
and then MERGE the new subunit file (the one whose name begins
with m). Use a line number on the MERGE command that will add the
new subunit to the end of the program.
8. Renumber the program, and SAVE it. During the SAVE, the Program
Analyst will identify any remaining broken structures that will
need manual correction.