Advanced Macro Guide
Advanced Macro Guide
SC27-5450-03
IBM Host Access Transformation Services IBM
SC27-5450-03
Note:
Before using this information and the product it supports, read the information in Appendix B, “Notices,” on page 203.
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Contents v
Playing the macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Working with screens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Editing macro screen properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Adding macro screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Associating a macro screen with a screen capture . . . . . . . . . . . . . . . . . . . . . 116
Screen preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Default screen recognition criteria . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Cut, delete, copy, and paste screens . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Working with actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Adding and editing actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Hiding and showing actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Custom action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Evaluate (If) action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Extract action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Extract All action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Input action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Pause action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Perform action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Play macro action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Prompt action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Prompt All action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Set cursor position action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
| Trace action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Update macro variable action . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Working with next screen connections . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Adding a next screen connection from the palette . . . . . . . . . . . . . . . . . . . . . 131
Reordering and changing next screen connections . . . . . . . . . . . . . . . . . . . . . 132
Working with VME preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Contents vii
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
<nextscreens> element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
<numfields> element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
<numinputfields> element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
<oia> element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
<pause> element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
<perform> element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
<playmacro> element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
<prompt> element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
<recolimit> element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
<screen> element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
<sqlquery> element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
<string> element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
<trace> element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
<type> element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
<vars> element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
<varupdate> element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
XML samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Figures xi
xii IBM Host Access Transformation Services: Advanced Macro Guide
Tables
1. Definitions of terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Arithmetic operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3. Conditional operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4. Logical operators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Negative value for row . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Negative value for column . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Contents of macro screen Screen1 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8. Contents of macro screen Screen2 . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Logical operators for the uselogic attribute . . . . . . . . . . . . . . . . . . . . . . . 40
10. Types of descriptors, how many of each type allowed . . . . . . . . . . . . . . . . . . . 41
11. Example of variable names and values . . . . . . . . . . . . . . . . . . . . . . . . 74
12. How the macro runtime maps macro data types to Java data types . . . . . . . . . . . . . . . 94
13. HML variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
14. Method summary for $HMLFormatUtil$ . . . . . . . . . . . . . . . . . . . . . . . . 96
15. Method summary for $HMLPSUtil$ . . . . . . . . . . . . . . . . . . . . . . . . . 97
16. Formulas for calculating values related to presentation space . . . . . . . . . . . . . . . . . 99
17. Method summary for $HMLSessionUtil$ . . . . . . . . . . . . . . . . . . . . . . . 103
18. Method summary for $HMLSQLUtil$ . . . . . . . . . . . . . . . . . . . . . . . . 104
19. Example of two-dimensional array containing results . . . . . . . . . . . . . . . . . . . 105
20. Three types of <description> element descriptors . . . . . . . . . . . . . . . . . . . . 141
21. Valid settings for the descriptor Wait for OIA to Become Uninhibited . . . . . . . . . . . . . . 142
22. Default initial values for variables . . . . . . . . . . . . . . . . . . . . . . . . . 149
23. Communication states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
24. Keywords for the Input action . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
25. Bidirectional keywords for the Input action . . . . . . . . . . . . . . . . . . . . . . 201
Use these editors to make any of these changes to your HATS macros:
v Add actions, such as new prompts, mouse clicks, or conditional actions.
v Edit and enhance the macro's screen recognition behavior and user input.
v Add more intelligent behavior to the macro, such as choosing between alternate
paths through an application.
Note: Support for the Macro Editor and the Advanced Macro Editor is deprecated
in HATS V9.7. While support continues for now, IBM reserves the right to
remove these capabilities in a subsequent release of the product. This
support is replaced by the Visual Macro Editor.
The Host On-Demand macro scripts described in this document begin with a
<HAScript> tag and end with a </HAScript> tag. In HATS, each Host
On-Demand macro script is wrapped within the HATS <macro> begin tag and the
</macro> end tag. The <macro> tag contains 4 elements:
Samples
You can create a new macro by copying a macro script from this document. This
section assumes that you are copying an entire macro script, starting from the
beginning designator <HAScript> and ending with the </HAScript> ending
designator. To create a new macro in this way, perform the following steps:
1. In HATS Toolkit, select your HATS project and open the host terminal.
2. Record a simple macro to use as a holder for the script:
a. Click the Record Macro icon. The Record Macro wizard opens.
b. Click Finish to accept the default values. The Define Screen Recognition
Criteria wizard opens.
c. Click Finish to accept the default values. The title bar on the host terminal
window should display Recording....
You can edit the macro further using any of the HATS macro editors.
Note: Not all samples in this book are complete macro scripts. A complete macro
script starts and ends with the element <HAScript> and does not contain
ellipses (ellipses indicate missing information in the samples). Other samples
are macro code snippets and need to be pasted into the appropriate location
inside an existing, complete macro.
Macro script
A macro script is an XML script used to store a macro. You can view and edit the
XML text of a macro script by using the source view of the VME or the basic
Macro Editor.
Learning a little about the XML elements of the macro language will greatly
increase your understanding of important topics, including the following:
v How to use the macro editors
v How macro playback works
v How to build effective macros
This book refers not only to the input fields, buttons, and list boxes provided by
the macro editors, but also to the corresponding XML elements in which the same
information is stored.
XML elements
To understand macro scripts you do not need to learn a great deal about XML, just
the basics of the syntax. If your knowledge of XML syntax needs brushing up, you
can learn more about it in “XML syntax in the Host On-Demand macro language”
on page 167. However, almost all of what you need to know is covered in this
subsection.
XML macro element names are enclosed in angle brackets. Examples: <HAScript>
element, <screen> element.
In the begin tag, the attributes are specified by using the attribute name (such as
attribute1), followed by an equals sign (=), followed by an attribute value enclosed
in quotation marks (such as "value1"). Any number of attributes can occur within
the begin tag.
If the macro element does not contain other XML elements then it can be written
in the shorthand fashion shown in Figure 3:
In Figure 3, the element <SampleElement> is written with a left angle bracket (<)
followed by the name (SampleElement), followed by the attributes, followed by a
forward slash and a right angle bracket (/>). Thus the entire XML element is
written within a single pair of angle brackets.
Figure 4 displays a <HAScript> element that contains instances of the major types
of subelements: an <import> element (Import), a <vars> element (Variables), and
three <screen> elements (Screen1, Screen2, and Screen3).
All macro scripts are structured like this, except that most have more screens. If
there were 50 screens in the above macro, then Figure 4 would look much the
same, except that after Screen3 there would be additional screens: Screen4, Screen5,
and so on, up to Screen50. However, the order in which the screens are stored does
The <HAScript> element is the master element of a macro script. (HAScript stands
for Host Access Script.) It encloses the entire macro and also contains, in its begin
tag, attributes that contain information applicable to the entire macro, such as the
macro's name. For an example of an <HAScript> element, see Figure 1 on page 5.
The <import> element is used to import Java™ classes and is optional. Importing
Java classes is an advanced topic that is discussed in Chapter 9, “Variables and
imported Java classes,” on page 87.
The <vars> element is used to declare and initialize variables belonging to one of
the standard data types (boolean, integer, double, string, or field). Using standard
variables is an advanced topic that is discussed in Chapter 9, “Variables and
imported Java classes,” on page 87.
The <screen> element is used to define a macro screen. The <screen> element is
the most important element that occurs inside the <HAScript> element. As you can
see in Figure 4 on page 10, a macro script is composed mostly of <screen>
elements (such as Screen1, Screen2, and Screen3 in the figure). Also, most of the
other kinds of XML elements in a macro script occur somewhere inside a <screen>
element.
Application screen
An application screen is a meaningful arrangement of characters displayed on the
host terminal by a host application. An example of an application screen is the
OS/390® ISPF Primary Option Menu, which is displayed in Figure 5 on page 12.
PF7 PF8 PF9 PF10 PF711 PF12 Clear PA2 SysReq NextPad
Figure 5. A sample application screen, the OS/390 ISPF Primary Option Menu
In Figure 5 you can see that this application screen has menu selections displayed
in a row across the top (Menu, Utilities, Compilers, Options, and so on), a title
near the top (OS/390 Primary Option Menu), a list of options along the left side (0
through DAT), and an input field in which to type an option number or letter
(Option ===>). When the user provides input, for example by typing a 3 (for
Utilities) followed by the enter key, the ISPF application removes all these visible
items from the host terminal and displays a different application screen.
Macro screen
A macro screen is a set of instructions that tell the macro runtime how to manage a
visit to a particular application screen. A macro screen includes:
v A description of a particular application screen
v The actions to take when visiting this particular application screen
v A list of the macro screens that can validly occur after this particular macro
screen
Although the concept is not very intuitive at this point, there might be within the
same macro several macro screens that refer to the same application screen.
Because of the way macro screens are linked to one another, the macro runtime
might visit the same application screen several times during macro playback,
processing a different macro screen at each visit.
Also, one macro screen might refer to more than one application screen. When
several application screens are similar to each other, you might build a macro
screen that handles all of the similar application screens.
When you play back a recorded macro, the macro runtime processes one or more
macro screens for each application screen that it visits during the course of the
playback. Typically, a single macro screen runs for a given application screen.
However, it is possible for a macro to be edited in such a way that the actions of
the first macro screen do not cause the application screen to advance, and a second
macro screen then matches the same application screen.
Figure 6 shows a <screen> element (Screen1) that contains the three required
subelements: a <description> element (Description), an <actions> element
(Actions), and a <nextscreens> element (Valid Next Screens).
All <screen> elements are structured in this way, with these three subelements. (A
fourth and optional type of subelement, the <recolimit> element, is discussed later
in this book.)
The <screen> element is the master element of a macro screen. It contains all the
other elements that belong to that particular macro screen, and it also contains, in
its begin tag, attributes that contain information applicable to the macro screen as a
whole, such as the macro screen's name.
The <description> element contains descriptors that enable the macro runtime to
recognize that the <screen> element to which the <description> element belongs is
associated with a particular application screen. The descriptors and the
<description> element are described in Chapter 5, “Screen description,” on page 35.
The <nextscreens> element (Valid Next Screens in Figure 6 on page 13) contains a
list of the screen names of all the <screen> elements that might validly occur after
the current macro screen. The <nextscreens> element and the elements that it
encloses are described in Chapter 6, “Screen recognition,” on page 49.
The basic macro format enables you to enter literal values, including integers,
doubles, boolean (true or false), and strings.
In addition to the basic macro format functions, the advanced macro format offers
these added functions:
v Allows string concatenation using the plus symbol (+) string operator.
v Allows arithmetic expressions.
v Allows conditional expressions.
v Allows variables.
v Allows imported Java variable types and methods.
However, these rules affect only input fields located on editor tabs used to define
screens (with the exception of the name), screen actions, and variables and types.
For other input fields, always use the rules for the basic macro format.
You must manually change, one at a time, all of the representations of strings and
the two special characters back to the basic representations. You must also delete
any instances where advanced features have been used in the macro. If you do not
do so, you might encounter errors or unexpected results when you try to save or
run the script. Any remaining advanced macro format operator characters will be
treated as literal characters rather than as operators.
Boolean data
The boolean values true and false can be written with any combination of
uppercase and lower case letters (such as True, TRUE, FALSE, falsE, and so on).
Examples of fields that require a boolean value are the Entry screen, Exit screen,
and Transient screen fields for a macro screen definition. Enter true to set the
condition to true or false to set the condition to false.
However, string values are converted to boolean values within a boolean context
(see “Conversion to boolean” on page 21). Therefore with the advanced macro
format you could enter the string ’true’ within a boolean field because the macro
editor would convert the string ’true’ to the boolean value true.
Integers
Integers are written without commas or other delimiters. Examples:
10000
0
-140
Integer constants
The macro editor has a number of integer constants that are written using all
uppercase characters. These values are treated as integers, not strings. Examples:
v NOTINHIBITED
v FIELD_PLANE
v COLOR_PLANE
Doubles
Doubles are written without commas or other delimiters. Examples:
3.1416
4.557e5
-119.0431
Strings
A string is any sequence of characters and can include leading, trailing, or
intervening blank characters. Strings in some input fields must be represented
differently, depending on whether the macro has been set to use the basic macro
format or the advanced macro format. See “Representation of strings and
non-alphanumeric characters” on page 15.
Here are the same examples using the basic macro format representation:
apple
User4
Total number of users
This string has 3 leading blanks.
This string has 3 trailing blanks.
Notice that with the basic macro format, trailing blanks are still allowed but are
difficult to detect. If in doubt, see the representation of the string in the source
view.
Fields
See “Field variables” on page 91.
Do not use null to signify an empty string. To signify an empty string, use a pair of
single quotes ('') in the advanced macro format, or nothing at all in the basic macro
format. If you use the value null in a string context (for example, by assigning it to
a string variable), then the macro editor or the macro runtime will convert the
value null to the string ’null’.
You can use parentheses to indicate the order in which you want expressions to be
evaluated:
(4 * 2) + (16 / 8) - (1 * 2) evaluates to 8
but
4 * (( 2 + 16) / (8 - 1)) * 2 evaluates to 20.571
If you are entering && in an HTML or XML editor you might have to enter
&&
In a conditional expression the terms are evaluated left to right. The order of
precedence of the operators is the same order in which they are listed in the tables
above. You can use parentheses to indicate the order in which you want
expressions to be evaluated. Examples:
Expression: Evaluates to:
(4 > 3) true
!(4 > 3 ) false
(4 > 3) && (8 > 10) false
(4 > 3) || (8 > 10) true
Effect of context
If an item of data belongs to one standard data type (boolean, integer, double, or
string) but the context requires a different standard data type, then when the data
is evaluated (either when the macro editor saves the data or when the macro
runtime plays the macro) it is automatically converted to the standard data type
required by the context, if possible.
The following subsections discuss the conversions that can occur for each standard
data type.
Conversion to boolean
The string ’true’ (or ’TRUE’, ’True’, and so on) in a boolean context is converted
to boolean true. Any other string in a boolean context (including ’false’, ’1’,
’apple’, and any other) is converted to boolean false.
’true’ (in an input field that requires a boolean) converts to true
’apple’ (in an input field that requires a boolean) converts to false
Conversion to integer
A string in valid integer format and occurring in an integer context converts to
integer.
’4096’ converts to 4096
’-9’ converts to -9
Conversion to double
A string in valid double format occurring in a double context converts to double.
’148.3’ converts to 148.3
Conversion to string
A boolean, integer, or double in a string context converts to a string. (The boolean
values true and false are not strings. See “Boolean data” on page 17.) The
following values, when specified for an input field requiring a string value (such
as the String field of an Input action), will evaluate to the specified result.
’The result is ’ + true evaluates to ’The result is true’
FALSE (in an input field that requires a string) converts to ’false’
’The answer is ’ + 15 evaluates to ’The answer is 15’
22 (in an input field that requires a string) converts to ’22’
14,52 (in an input field that requires a string) evaluates to’14,52’
Conversion errors
If the context requires a conversion but the format of the data is not valid for the
conversion then the macro editor displays an error message. For example, typing
'123apple' into the Row field of an Input action will cause an error message to be
displayed and the previous value will be restored.
Equivalents
Any context that accepts an immediate value of a particular standard data type
also accepts any entity of the same data type.
For example, if an input field accepts a string value, such as ’Standard Dialog’, it
also accepts:
v An expression that evaluates to a string
Similarly, if an input field accepts a boolean value (true or false), it also accepts:
v An expression that evaluates to a boolean value
v A value that converts to a boolean value
v A boolean variable
v A call to an imported method that returns a boolean
Recognizing this flexibility in the macro facility will help you write more powerful
macros.
For example, if the host screen has 24 rows of text then a row coordinate of -1
indicates an actual row coordinate of 24 (calculated as: 24 + 1 - 1). Similarly if the
host screen has 80 columns of text then a column coordinate of -1 indicates an
actual column coordinate of 80 (calculated as 80 + 1 - 1).
The row calculation above ignores the OIA row. For example, if the host screen has
25 rows, it has only 24 rows of text.
The advantage of this convention is that if you want to specify a rectangle at the
bottom of the host terminal, then this calculation gives the right result whether the
host screen has 25, 43, or 50 rows. Similarly, if you want to specify a rectangle at
the right side of the host terminal, then this calculation gives the right result
whether the host screen has 80 columns or 132 columns.
Whether you use this convention or not, you should at least remember that a
rectangular area with coordinates of (1,1) and (-1,-1) means the entire text area of
the host terminal.
The scenario begins at the point at which the macro runtime has performed all the
actions in Screen1 and is ready to search for the next macro screen to be processed.
Screen1 is the macro screen that handles the OS/390 ISPF Primary Option Menu
(see Figure 7).
PF7 PF8 PF9 PF10 PF711 PF12 Clear PA2 SysReq NextPad
Screen2 is the macro screen that handles the Utility Selection Panel (see Figure 8).
Menu Help
Utility Selection Panel
Option ===>
1 Library Compress or print data set. Print index listing. Print,
rename, delete, browse, edit or view members
2 Data Set Allocate, rename, delete, catalog, uncatalog, or display
information of an entire data set
3 Move/Copy Move, or copy members or data sets
4 Dslist Print or display (to process) list of data set names.
Print or display VTOC information
5 Reset Reset statistics for members of ISPF library
6 Hardcopy Initiate hardcopy output
7 Transfer Download ISPF Client/Server or Transfer data set
8 Outlist Display, delete, or print held job output
9 Commands Create/change an application command table
11 Format Format definition for formatted data Edit/Browse
12 SuperC Compare data sets (Standard Dialog)
13 SuperCE Compare data sets Extended (Extended Dialog)
14 Search-For Search data sets for strings of data (Standard Dialog)
15 Search-ForE Search data sets fro strings of data Extended (Extended Dialog)
16 Tables ISPF Table Utility
17 Udlist Print or display (to process) z/OS UNIX directory list
MA* a 04/014
PF1 PF2 PF3 PF4 PF5 PF6 Enter PA1 Attn NewLine
PF7 PF8 PF9 PF10 PF11 PF12 Clear PA2 SysReq NextPad
Menu Help
Stage 1
As noted above, stage 1 has three steps and, therefore, requires a more detailed
explanation than stages 2 or 3. Each of these steps involves the list of valid next
screens.
The list of valid next screens is just a list that can hold macro screen names. The
macro runtime creates this list at the beginning of macro playback (before playing
back the first macro screen), and discards this list after macro playback is complete.
Initially the list is empty (except possibly for transient screens, which are described
in “How the macro runtime selects the names of candidate macro screens” on page
29).
During macro playback, each time the macro runtime needs to determine the next
macro screen to be processed, it performs the three steps 1(a), 1(b), and 1(c) using
the list of valid next screens.
In step 1(b), the macro runtime periodically checks each macro screen on the list to
determine whether it matches the application screen.
Timing is a factor in this step. Because of an action that the macro runtime has just
performed in the current macro screen (in Screen1, typing '3[enter]' as the last
action of the <actions> element), the host application is in the process of changing
the host terminal so that it displays the new application screen (the Utility
Selection Panel) instead of the old application screen (ISPF Primary Option Menu).
However, this change does not occur immediately or all at once. The change takes
some hundreds of milliseconds and might require several packets of data from the
host.
Therefore, during step 1(b), every time the OIA line or the host terminal's
presentation space is updated, the macro runtime again checks the macro screen
(or screens) named in the list of valid next screens to determine whether one of
them matches the application screen in its current state.
Eventually the host terminal is updated to the extent that the macro runtime is
able to match one of the macro screens on the list to the application screen.
In step 1(c), the macro runtime removes all the macro screen names from the list of
valid next screens (except transient screens if any).
In stage 2, the macro runtime makes the selected macro screen, the one that
matched the application screen in step 1(b), the new current macro screen.
Finally, in stage 3, the macro runtime performs the actions in the <actions> element
of Screen2.
The remainder of this chapter provides detailed information about the stages and
steps presented in the above overview.
Step 1(a): Adding macro screen names to the list of valid next
screens
In this step the macro runtime places the names of candidate macro screens on the
list of valid next screens.
This might seem at first to be counter-intuitive. After all, the ISPF Primary Option
Menu has about 30 different possible inputs (15 options, 6 menu selections, and 8
function keys). There should be 30 names of macro screens on the list, not just 1,
right?
The reason that the list of valid next screens usually has only one or a few names
on it is that the macro is executing a series of instructions that are aimed at
accomplishing some specific task. In Screen1, the instructions are aimed at getting
from the ISPF Primary Option Menu to the Utility Selection Panel. The necessary
actions have been performed to make this transition occur (’3[enter]’), and the
macro screen is now just waiting for the expected application screen to appear.
First macro screen: When macro playback begins, the list of valid next screens is
empty (except possibly for transient screens, see “Transient screens” on page 30).
To get candidates for the first macro screen to be processed, the macro runtime
searches the entire macro, finds each macro screen that is marked as an entry
screen, and adds the names of these macro screens to the list.
The entry screen setting (an attribute of the <screen> element) exists for exactly
this purpose, to mark macro screens that can occur as the first screen to be
processed.
When a macro is recorded, the Macro object by default marks just the first macro
screen to be recorded as an entry screen. After recording is complete, you can mark
(or unmark) any macro screen as an entry screen, and there can be multiple entry
screens.
Entry screens are described in more detail in “Entry screens” on page 49.
If no macro screen is marked as an entry screen, then the macro runtime uses all
the macro screens in the macro as candidates for the first macro screen to be
processed.
Subsequent macro screens: For subsequent macro screens (including the one
immediately after the first macro screen), the macro runtime finds the names of the
candidate macro screens listed in the <nextscreens> element of the current macro
screen.
All of the macro screen names listed in the element are added to the list of valid
next screens by the macro runtime.
During macro recording, when the Macro object begins to record a new macro
screen, it stores the name of that new macro screen (such as Screen2) in the
<nextscreens> element of the macro screen that it has just finished recording (such
as Screen1). Therefore each macro screen (except the last) of a recorded macro has
the name of one macro screen stored in its <nextscreens> element.
Subsequently you can add or delete the name of any macro screen in the macro to
or from the <nextscreens> element of any macro screen.
Transient screens: A transient screen is a screen that can occur at any point in the
macro, that occurs unpredictably, and that always needs to be cleared. An example
of a transient screen is an error screen that appears in response to invalid input.
The Macro object does not mark any macro screen as a transient screen during
macro recording. However, subsequently you can mark any macro screen as a
transient screen.
When macro playback begins, the macro runtime searches the macro, finds each
macro screen that is marked as a transient screen, and adds the name of each
transient macro screen to the list of valid next screens. These names remain on the
list for the duration of the macro playback.
For more information on transient screens see “Transient screens” on page 50.
This process is called screen recognition because the macro runtime recognizes one
of the macro screens on the list as corresponding to the application screen that is
currently displayed in the host terminal.
Overview of evaluation
The macro runtime evaluates the candidate macro screens in the order in which
their names appear in the list of valid next screens.
If the macro runtime finds that one of the candidates matches the application
screen, then the macro runtime immediately stops evaluating and goes on to the
next step of removing the candidate names from the list, step 1(c). The matching
screen becomes the next macro screen to be processed (stage 2).
However, if the macro runtime evaluates each macro screen named in the list
without finding a match, then the macro runtime stops evaluating, temporarily,
and does nothing further until the host terminal is updated.
This situation explains why the macro runtime temporarily stops working on
screen recognition until the screen is updated. If screen recognition has failed, the
reason might be that the new application screen is incomplete. Therefore the macro
runtime waits.
Each time that the OIA line is updated or the presentation space of the host
terminal is updated, the macro runtime again makes a pass through the list of
valid next screens, trying to find a match to the current application screen. If no
match occurs then the macro runtime waits again.
The macro runtime might go through several cycles of waiting and evaluation
before screen recognition succeeds.
Eventually, enough of the new application screen arrives so that the macro runtime
can match one of the macro screens named in the list to the new application
screen.
In the example scenario, the macro runtime finds the name Screen2 on the list of
valid next screens, retrieves Screen2, looks at its descriptors, and compares the
descriptors with the host terminal.
Each macro screen contains a <description> element that itself contains one or
more descriptors. A descriptor is a statement of fact about the host terminal
(application screen in its current state) that can be either true or false. In the
example scenario, Screen2 contains three descriptors:
v The input inhibited indicator is cleared (input is not inhibited).
v There are 80 fields in the host terminal.
v There are 3 input fields in the host terminal.
When there are several descriptors in a <description> element, as here, the method
that the macro runtime uses to evaluate the descriptors (as boolean true or false)
and to combine their results into a single result (true or false) depends on some
additional configuration information that is not described here. See “Evaluation of
descriptors” on page 37 for the configuration information.
In the example scenario, Screen2 is configured in the default manner, so that the
macro runtime evaluates each of the three descriptors in turn. If all three are true,
then the macro runtime concludes that the overall result is true, and that Screen2
matches the current application screen.
Recognition limit: You can set a recognition count that causes the macro runtime
to terminate the macro, or to jump to a specified macro screen, if the macro
runtime recognizes a macro screen, such as ScreenA, a number of times equal to
the count (see “Recognition limit” on page 53).
This is a simple step. The macro runtime removes the names of all the candidate
macro screens, whether recognized or not, from the list of valid next screens.
If the list contains the names of transient screens, those names remain on the list
(see “Transient screens” on page 50).
In the example scenario, the macro runtime makes Screen2 the new current macro
screen. The host terminal displays the new application screen, the Utility Selection
Panel (see Table 7 on page 26 and Table 8 on page 27).
Each macro screen typically contains an <actions> element that contains one or
more actions to be performed. An action is an instruction that causes some type of
activity, such as sending a sequence of keys to the host, displaying a prompt in a
popup window for the user, capturing a block of text from the screen, or some
other activity.
For more information on actions see Chapter 7, “Macro actions,” on page 55.
To avoid this type of problem, the macro runtime, by default, inserts a delay of 150
milliseconds after every Input action or Prompt action in every macro screen, and
a delay of 300 milliseconds after the last action of every macro screen (see “The
pausetime attribute” on page 81).
You should leave this feature enabled, although you can disable it if you want. You
can change the delays from 150 milliseconds and 300 milliseconds to other values.
If you want to change the duration of the delay for a particular macro screen, you
can do so (see “The pause attribute” on page 81).
Also, for any particular action, you can increase the delay by adding a Pause
action after the action (see “Pause action (<pause> element)” on page 66).
In the example scenario Screen2 is marked as an exit screen (see Table 8 on page
27).
The exit screen setting, an attribute of the <screen> element, exists for exactly this
purpose, to mark macro screens that terminate the macro.
When a macro is recorded, the Macro object, by default, marks the last recorded
macro screen as an exit screen. After recording is complete, you can mark (or
unmark) any macro screen as an exit screen, and there can be multiple exit screens.
Exit screens are described in more detail in “Exit screens” on page 50.
Definition of terms
Descriptor
An XML element that occurs in the <description> element of a macro
screen and that states an identifying characteristic of the application screen
to which the macro screen corresponds.
For example, a macro screen named ScreenB might contain a String
descriptor (<string> element) that states that row 3 of the application
screen contains the string ISPF Primary Option Menu. During macro
playback, when the macro runtime is determining which macro screen to
process next, and when ScreenB is a candidate, the macro runtime
compares the descriptor in ScreenB with the actual application screen. If
the descriptor matches the actual application screen (row 3 of the
application screen really does contain the string), then the macro runtime
selects ScreenB as the next macro screen to be processed.
Screen description
The process of adding descriptors to the <description> element of a macro
screen. You engage in screen description when you use a macro editor to
create or edit a descriptor for a macro screen (such as the String descriptor
in the previous example). Likewise, the Macro object creates one or more
descriptors for each new macro screen that it creates during macro
recording (see “Recorded descriptions” on page 36).
Screen recognition
The process that the macro runtime performs when it attempts to match a
candidate macro screen to the current application screen.
As detailed in Chapter 4, “How the macro runtime processes a macro
screen,” on page 25, when the macro runtime needs to determine the next
macro screen to be processed, the macro runtime places the names of
candidate macro screens (usually found in the <nextscreens> element of
the current macro screen) onto a list of valid next screens. Then, as the host
application updates the host terminal with the new application screen, the
macro runtime compares the descriptors of each macro screen on the list
with the new application screen. Eventually the application screen is
updated to the extent (for example, the string ISPF Primary Option Menu
appears in row 3) that the macro runtime can match one of the macro
For information about screen description using the VME, see “Screen Recognition
tab” on page 115, and using the AME, see “Description tab” on page 138.
Recorded descriptions
During macro recording in the HATS host terminal, one or more descriptors is
added to the new <description> element of each new macro screen that is created.
You must define the first macro screen of the macro being recorded. HATS
automatically adds the OIA descriptor to the description of the first screen.
For every other application screen of the macro after the first application screen,
you have the choice of defining the screen or allowing HATS to define it
automatically. When HATS defines a screen, it creates three descriptors:
v The OIA descriptor is set to NOTINHIBITED.
v The Cursor descriptor is set to the actual cursor position of the application
screen.
v The Number of Input Fields descriptor is set to the actual number of input fields
in the application screen (can be 0).
Therefore, when the recorded macro is played back (without having been revised
in any way), the macro runtime matches every macro screen after the first one to
its corresponding application screen based on whether the input inhibited indicator
is cleared, whether the cursor position matches the cursor position of the
application screen, and whether the number of input fields in the macro screen's
description matches the number of input fields in the application screen.
First, the OIA descriptor, cursor position, and number of input fields can be
applied to every possible application screen. That is, every application screen has
some number of input fields (perhaps the number is 0), a starting cursor position,
and an input inhibited indicator that is either set or cleared.
Second, the combination of the number of input fields and the cursor position
provides a pretty reliable description of an application screen, because application
screens typically contain many fields, but only a certain number of them are input
fields. The cursor position is always in the first input field.
Third, and perhaps most important, during screen recognition the macro runtime
compares the new application screen to a short list (usually a very short list) of
macro screens called valid next screens (see “Stages in processing a macro screen”
on page 27). Therefore a single macro screen need not be differentiated from every
other macro screen in the macro, only from the other screens in the list of valid
next screens. Frequently the list consists of a single macro screen.
Evaluation of descriptors
This section describes in detail how the macro runtime determines whether a
macro screen matches an application screen.
Keep the following in mind as you read through the following subsections:
v In most macro screens, the <description> element contains more than one
descriptor.
v The default in the macro editors is that all descriptors are required (the Optional
attribute of each descriptor is false) and that the default combining rule is used.
v The most common scenario that you will encounter is that all descriptors are
required. That is, if you have defined three descriptors, you want all three of
them to be true in order for the macro screen to be recognized. If you are facing
this scenario, then you should use the default settings.
v If you are faced with a scenario that is more complicated than the default
scenario, then you should use the uselogic method (see “The uselogic attribute”
on page 39.)
For example, if the descriptor is a String descriptor, then the macro runtime looks
in the application screen at the row and column that the descriptor specifies, and
compares the string at that location with the string that the descriptor specifies. If
the two strings match, then the macro runtime assigns a value of true to the String
descriptor. If the two strings do not match then the macro assigns a value of false
to the String descriptor.
Usually a macro screen contains more than one descriptor. However, if a macro
screen contains only one descriptor (and assuming that the descriptor does not
have the invertmatch attribute set to true) then if the single descriptor is true the
entire description is true, and the macro runtime recognizes the macro screen as a
match for the application screen. In contrast, if the single descriptor is false, then
the entire description is false, and the macro screen is not recognized.
Invertmatch attribute
Every descriptor has an invertmatch attribute.
By default this attribute is false, so that it has no effect on the evaluation of the
descriptor.
If this setting is true, then the macro runtime inverts the boolean result that it
obtains from evaluating the descriptor, changing true to false or false to true.
For example, if the macro runtime determines that a String descriptor is true (the
string in the descriptor matches the screen in the application window), but the
String descriptor has the invertmatch attribute set to true, then the macro runtime
changes the String descriptor's result from true to false.
If you want the description as a whole to be true only if all the descriptors are
true, then set the Optional attribute of all the descriptors in the description to false
(the default setting).
In contrast, if you want the description as a whole to be true if at least one of the
descriptors is true, then set the Optional attribute of all of the descriptors in the
description to true.
You should not use the default combining rule in any other scenario where you
have multiple descriptors in one macro screen, unless you understand the rule and
its implications thoroughly. For more information see “Default rule for combining
multiple descriptors in one macro screen” on page 199.
Also, you should not set the Optional attributes of multiple descriptors in one
macro screen differently (some true, some false) unless you understand the rule
and its implications thoroughly.
HATS adds a default uselogic attribute to the <description> tag when you record
the macro. It will be regenerated if you edit the macro in the host terminal or in
the macro editors. It will not be regenerated if you edit the macro in the source
view.
Note: If you use the uselogic attribute, then the macro runtime ignores the
invertmatch and Optional attributes in the individual descriptors.
The value of the uselogic attribute is a simplified logical expression whose terms
are 1-based indexes of the descriptors that follow. Figure 9 on page 40 shows an
example of a <description> element that contains a uselogic attribute (some of the
attributes of the <string> element are omitted for clarity):
In the example in Figure 9 the macro runtime will determine that the description
as a whole is true if one of the following occurs:
v The result of the first descriptor is true and the result of the second descriptor is
true (1 and 2)
v The result of the first descriptor is false and the result of the third descriptor is
true (!1 and 3)
Remember that if you use the uselogic attribute, then the macro runtime ignores
the invertmatch and the Optional attribute settings in the individual descriptors.
The descriptors
Each type of descriptor is stored as an individual XML element situated within the
<description> element of one macro screen.
Table 10 lists all the types of descriptors and shows the number of descriptors of
each type that are allowed to exist in one macro screen (more specifically, in one
<description> element belonging to one <screen> element):
Table 10. Types of descriptors, how many of each type allowed
Type of descriptor: Number of this type of descriptor allowed
per macro screen:
OIA 1 (required)
Number of Fields 0 or 1
Number of Input Fields 0 or 1
String descriptor 0 or more
Cursor descriptor 0 or 1
Attribute descriptor 0 or more
Condition descriptor 0 or more
| Custom descriptor 0 or more
However, if you have a scenario in which you want the macro runtime to ignore
the input inhibited condition, then set this descriptor to DONTCARE.
When the macro runtime counts the fields in the host terminal it counts all types
of 3270, or 5250, fields, including input fields.
If you do not want to use this descriptor then set the Number of Fields input field
to blank.
You can use an integer in the Number of Input Fields field, or any entity that
evaluates to an integer (such as a variable, an arithmetic expression, or a call to an
external Java method).
If you do not want to use this descriptor then set the Number of Input Fields field
to blank.
The macro runtime searches inside the entire rectangular area of text for the string
you specify. If the macro runtime finds the string inside the rectangular area of
text, then it evaluates the string descriptor as true. If not, then it evaluates the
string descriptor as false.
However, suppose that the application screen that you want to match to the macro
screen has the same string, ’Terminal and user parameters’, located within it, but
you cannot predict which row of the application screen will contain the string. In
this case you could specify the rectangular area (1,1), (-1,-1), indicating that the
macro runtime should search every row of the application screen for the
identifying string.
For the string value you can use a string or any entity that evaluates to a string
(such as a variable, an expression, or a call to an external Java method). The string
must be in the form required by the macro format that you have chosen, either
basic or advanced.
If the macro runtime finds the string within the rectangular block of text then the
macro runtime evaluates this descriptor as true. Otherwise the macro runtime
evaluates this descriptor as false.
In contrast, if the Wrap attribute is set to true then the macro runtime searches for
the string as follows:
1. Get all the lines of the rectangular area and concatenate them in order.
2. Determine whether the string occurs in the concatenated string.
If the string you are searching for can wrap from one line to the next of the host
terminal, then you should set the Wrap attribute to true. Do not confuse this
attribute with the Unwrap attribute of the Extract action, which is based on fields
rather than blocks of text (see “Unwrap attribute” on page 60).
In Figure 10, the first character of each row is a blank space. For example, in row
14, the first two characters are ’ 6’, that is, a blank space followed by the numeral
6. Suppose that you want to set up a String descriptor that checks for the following
rectangular block of text on this application screen:
Hardcopy
Transfer
Outlist
Commands
Reserved
The steps in setting up the String descriptor for this multi-row block are as follows:
1. Create a new String descriptor.
2. Set the row and column location of the upper left corner of the text rectangle
above to (14, 5) and the row and column location of the lower right corner to
(18, 12).
3. Set the string value. The string value is:
’HardcopyTransferOutlist CommandsReserved’
4. Set the Wrap attribute to true.
5. Leave all the other attributes set to the default.
Notice that in step 3 above the five rows are concatenated as a single string,
without any filler characters added (such as a newline or space at the end).
However, the string does contain a blank space after ’Outlist’ because that blank
space does fall within the boundaries of the rectangle.
For example, in ScreenA you might read a company name from the host terminal
into a string variable named $strTmp$, using an Extract action. Then in ScreenB
you could use $strTmp$ as the string to be searched for in a String descriptor.
You can do this when extracting multiple lines of text if you have the Wrap
attribute set to true.
If the two locations are the same then the macro runtime evaluates this descriptor
as true. Otherwise the macro runtime evaluates this descriptor as false.
During screen recognition the macro runtime compares the specified attribute (such
as 0x3) to the actual attribute at the row and column specified. If the attributes are
the same, then the macro runtime evaluates the descriptor as true. Otherwise the
macro runtime evaluates the descriptor as false.
This descriptor can be useful when you are trying to differentiate between two
application screens that are very similar except for their attributes.
During screen recognition the macro runtime evaluates the conditional expression
and obtains a boolean result.
If the conditional expression evaluates to true then the macro runtime evaluates
this descriptor as true. Otherwise the macro runtime evaluates this descriptor as
false.
The Condition descriptor increases the flexibility and power of screen recognition
by allowing the macro runtime to determine the next macro screen to be processed
based on the value of one or more variables or on the result of a call to a Java
method.
To create a Custom descriptor you must use the source view to add a
<customreco> element to the <description> element of the macro screen. For more
information on this element, see “<customreco> element” on page 177.
Note: If you are using custom screen recognition in the screen descriptors of a
HATS macro, and the macro is invoked through the <playmacro> action
from within a separate macro, the custom screen recognition logic does not
work.
HATS can only register as a listener for custom recognition events in the
first macro of a chain. HATS cannot register as a listener for any of the
subsequent macros in the chain.
To resolve this problem, use non-chained macros when using HATS custom
screen recognition.
The Variable update action in a <description> element performs the very same
type of operation that it performs in an <actions> element, which is to store a
specified value into a specified variable.
For information about creating a Variable update action see “Variable update action
(<varupdate> element)” on page 73.
As you might remember, the macro runtime can go through the screen recognition
process a number of times before matching a macro screen to an application screen
(see “Repeated screen evaluations” on page 31). Therefore, if a <description>
element contains one or more Variable update actions, then the macro runtime will
perform the Variable update actions each time that it evaluates the <description>
element.
For example, suppose that a macro is being played back, that the screen name
ScreenB is on the list of valid next screens, and that ScreenB contains a
<description> element like the one shown in Figure 11 on page 47:
Each time that the macro runtime tries to match ScreenB to the current application
screen:
1. The macro runtime sees the <varupdate> action and performs it, incrementing
the value of $intUpdate$ by 1.
2. The macro runtime evaluates the <oia> descriptor and the <attrib> descriptor
and arrives at a boolean result for the entire <description> element.
In Figure 1 on page 5, you can see these three attributes in the <screen> element
for Screen1: entryscreen, exitscreen, and transient.
For information about where these settings are made using the VME, see “General
tab” on page 114, and using the AME, see “Screens tab” on page 136.
Entry screens
Mark a screen as an entry screen if you want the macro screen to be considered as
one of the first macro screens to be processed when the macro is played back. You
might have only one macro screen that you mark as a entry screen, or you might
have several.
When the macro playback begins, the macro runtime searches through the macro
script and finds all the macro screens that are designated as entry screens. Then
the macro runtime adds the names of these entry macro screens to the runtime list
of valid next screens. Finally the macro runtime tries in the usual way to match
one of the screens on the list to the current host terminal.
When the macro runtime has matched one of the entry macro screens to the host
terminal, that macro screen becomes the first macro screen to be processed. Before
performing the actions in the first macro screen, the macro runtime removes the
names of the entry macro screens from the runtime list of valid next screens.
In this situation, you might want the user to be able to run the macro whether the
user was at application screen A, B, or C.
For example, you might have a host application that has a central application
screen with a set of menu selections, so that each time you make a menu selection
the application goes through several application screens of processing and then
returns to the original central application screen.
In this situation, suppose that macro ScreenA is the macro screen corresponding to
the central application screen. Both of the following would apply:
v ScreenA could be an entry screen, because the macro could start at the central
application screen
v ScreenA could also appear in the <nextscreens> element of other macro screens,
because after each task the application returns to the central application screen
Exit screens
Marking a macro screen as an exit screen causes the macro runtime to terminate
the macro after it has performed the actions for that macro screen. That is, after the
macro runtime performs the actions, and before going on to screen recognition, the
macro runtime looks to see if the current macro screen has the exit screen indicator
set to true. If so, then the macro runtime terminates the macro. (The macro runtime
ignores the <nextscreens> element of an exit screen.)
You can have any number of exit screens for a macro. Here are some examples of
situations in which there could be several exit screens.
v A macro might have one normal termination point and several abnormal
termination points, which could be reached if an error occurred.
v A macro might allow you to stop at a certain point in the processing, or to keep
going, so that there would be several normal termination points.
Transient screens
A transient macro screen is used to process an application screen that has the
following characteristics:
v The application screen occurs unpredictably during the flow of the application.
It might occur at several points or it might not occur at all.
v The only action that needs to occur for the application screen is that it needs to
be cleared.
An example of such an application screen is an error screen that the application
displays when the user enters invalid data. This error screen appears at
unpredictable times (whenever the user enters invalid data) and as a macro
developer the only action that you want to take for this error screen is to clear it
and to get the macro back on track.
When the macro runtime prepares to play back a macro, at the point where the
macro runtime adds the names of entry screens to the runtime list of valid next
screens, the macro runtime also adds the names of all macro screens marked as
transient screens (if any) to the end of the list.
Transient screens are considered for the entry screen without being marked as
entry screens. If a transient screen is selected as the entry screen, its actions
execute, and then the macro checks all of the entry screens and all of the transient
screens to decide which screen to match next.
Whenever the macro runtime performs screen recognition, it evaluates the macro
screens of all the names on the list in the usual way. If the macro runtime does not
find a match to the application screen among the candidate macro screens whose
names are on the list, then the macro runtime goes on down the list trying to
match one of the transient macro screens named on the list to the application
screen.
If the macro runtime matches one of the transient macro screens to the current
application screen, then the macro runtime does not remove any names from the
list. Instead, the macro runtime performs the actions in the transient macro screen
(which should clear the unexpected application screen) and then goes back to the
screen recognition process that it was pursuing when the unexpected application
screen occurred.
Screen recognition
After the macro runtime has performed all the actions in the <actions> element of
a macro screen, the macro runtime attempts to match one of the screens on the list
of valid next screens to the new application screen (see Chapter 4, “How the macro
runtime processes a macro screen,” on page 25).
When such a scenario occurs, the result is that the macro appears to hang while
the macro runtime continually and unsuccessfully attempts to find a match.
Notice that this message displays the name of the macro and the name of the
screen that was being processed when the timeout occurred. For example, if the
screen specified in this message is ScreenA, then the macro runtime had already
performed all the actions in ScreenA and was trying to match a macro screen in
the Valid Next Screens list for ScreenA to the application screen.
If the macro is playing in the host terminal, the following message is displayed:
When specified, the default timeout value is set to 60000 milliseconds (60 seconds).
If the timer expires before the macro runtime has completed screen recognition,
then the macro runtime displays the message in Figure 12 on page 52.
Recognition limit
The recognition limit allows you to take some sort of action if the macro runtime
processes a particular macro screen too many times. If the macro runtime does
process the same macro screen a large number of times (such as 100), then the
reason is probably that an error has occurred in the macro and that the macro is
stuck in an endless loop.
The recognition limit is not an attribute in the begin tag of the <screen> element,
but rather a separate element (the <recolimit> element) that optionally can occur
inside a <screen> element, on the same level as the <description>, <actions>, and
<nextscreens> elements.
| The <recolimit> element can be added using the Set Recognition Limit check box
| and the Screens Before Error input field both the VME and AME, see “Screens
| tab” on page 136.
When the recognition limit is reached, the macro runtime either terminates the
macro with an error message (this is the default action) or starts processing
another macro screen that you specify.
You should notice that the recognition limit applies to one particular screen and
that by default it is not specified. You can specify a recognition limit for any macro
screen, and you can specify the same or a different recognition limit value for each
macro screen in which you include it.
Suppose that a macro includes a macro screen named ScreenB and that ScreenB
contains a <recolimit> element with a recognition limit of 100. Each time the macro
runtime recognizes ScreenB (that is, each time the macro runtime selects ScreenB as
the next macro screen to be processed), the macro runtime performs the following
steps:
If you use the goto attribute, the macro runtime does not terminate the macro but
instead starts processing the macro screen specified in the attribute.
You can use the target macro screen for any purpose. Some possible uses are:
v For debugging
v To display an informative message to the user before terminating the macro
v To continue processing the macro
After the macro runtime has performed all the actions, it immediately goes on to
the next step of determining the next macro screen to be processed.
You are not required to create any actions for a macro screen. If there is no
<actions> element or if the <actions> element is empty, then the macro runtime
goes straight to the next section of macro screen processing, which is selecting the
next macro screen to be processed.
However, there are a few fields in which you cannot use variables (see “Using the
value that the variable holds” on page 91).
For information about specifying actions using the VME, see “Working with
actions” on page 119, and using the AME, see “Actions tab” on page 143.
The actions
This action can be specified using the Source tab in the VME, and using the
Actions tab in the AME, see “Comm wait action” on page 151.
However, if the two statuses do not match, then the macro runtime does no further
processing, but just waits for the communication status that is specified in the
Comm wait action to actually occur in the session.
You can specify in the Comm wait action a timeout value in milliseconds that
causes the macro runtime to end the Comm wait action when the timeout value
has expired. That is, the macro runtime terminates the action when the timeout
value has expired, even if the communication status that the macro runtime has
been looking for has not been reached.
After a Comm wait action, you probably want to use some other action, such as an
Extract action, to check some characteristic of the application screen that indicates
to you whether the session has actually reached the communication status that you
wanted, or whether the Comm wait action ended because of a timeout.
Examples
Figure 14 shows an example of specifying a communication state that will wait
until a Telnet session negotiation has begun or until 10 seconds have elapsed
without a Telnet negotiation session, whichever occurs first.
This action can be specified using the VME, see “Evaluate (If) action” on page 121,
and using the AME, see “Conditional action” on page 152.
Example
The following code fragment prompts the user for input. If the input string is the
string true, the code fragment writes the message You typed TRUE on the host
screen. If the input string is any other string, the code fragment writes the message
You typed FALSE. This example uses the following actions: Prompt action,
Condition action, and Input action.
You can copy this code fragment from this document into the system clipboard,
and then from the system clipboard into the source view. Because this code is a
fragment, you must copy it into a macro screen in an existing macro script. You
must also create a string variable named $strData$. To create the variable, add the
follow lines after the <HAScript> begin tag and before the first <screen> element:
<vars>
<create name="$strData$" type="string" value="" />
</vars>
<actions>
<prompt name="'Type true or false'" description="" row="0" col="0"
len="80" default="" clearfield="false" encrypted="false"
movecursor="true" xlatehostkeys="true" assigntovar="$strData$"
varupdateonly="true" />
<if condition="$strData$" >
<input value="’You typed TRUE’" row="0" col="0" movecursor="true" xlatehostkeys="true" encrypted="false"/>
</if>
<else>
<input value="’You typed FALSE’" row="0" col="0" movecursor="true" xlatehostkeys="true" encrypted="false"/>
</else>
</actions>
This action can be specified using the VME, see “Extract action” on page 122, and
using the AME, see “Extract action” on page 152.
As an example, suppose that the first 40 characters of rows 16, 17, and 18 of the
host terminal are as follows:
.8..Outlist.....Display, delete, or prin
.9..Commands....Create/change an applica
.10.Reserved....This option reserved for
In addition, suppose that the macro runtime is about to perform an Extract action
with the following settings:
v The continuous attribute is false.
v The row and column pairs are (16, 5) (the 'O' of Outlist) and (18, 12) (the 'd' of
'Reserved').
v The extraction name is 'Extract1'.
v The data plane is TEXT_PLANE.
v The string variable $strTmp$ is the variable in which the result string is to be
stored.
Because the continuous attribute is false, the macro runtime treats the row and
column pairs as marking a rectangular block of text, with the upper left corner at
row 16 and column 5 and the lower right corner at row 18 and column 12.
The macro runtime initializes the result string to an empty string. Then the macro
runtime reads the rectangular block of text one row at a time ('Outlist.',
'Commands', 'Reserved'), concatenating each row to the result string. Finally the
macro runtime stores the entire result string into the result variable $strTmp$. The
variable $strTmp$ now contains the following string:
’Outlist.CommandsReserved’
For example, suppose that rows 21 and 22 of the host terminal contain the
following text (each row is 80 characters):
........Enter / on the data set list command field for the command prompt pop-up
or ISPF line command............................................................
and suppose that the macro runtime is about to perform an Extract action with the
following settings:
v The continuous attribute is true.
v The row and column pairs are (21, 9) (the 'E' of 'Enter') and (22, 20) (the 'd' of
'command').
v The extraction name is 'Extract1'.
v The data plane is TEXT_PLANE.
v The string variable $strTmp$ is the variable in which the result string is to be
stored.
Because the continuous attribute is true, the macro runtime treats the row and
column pairs as marking the beginning and end of a sequence of text, with the
beginning position at (21, 9) and the ending at (22, 20).
The macro runtime initializes the result string to an empty string. Then the macro
runtime reads the sequence of text from beginning to end, wrapping around from
the last character of row 21 to the first character of row 22. Finally the macro
runtime stores the entire result string into the result variable $strTmp$. The
variable $strTmp$ now contains the following string of 92 characters (the following
text is hyphenated to fit on the page of this document, but actually represents one
string without a hyphen):
’Enter / on the data set list command field for the com-
mand prompt pop-up or ISPF line command’
Unwrap attribute
You can use this option with the continuous attribute set to either false or true.
When you set the unwrap attribute to true, the macro runtime uses not only the
row and column pairs in the Extract window but also the field boundaries in the
host terminal in determining the data to collect. The macro runtime returns an
array of strings (if you are using the toolkit) or a single string of concatenated
strings (if you are not using the toolkit).
Do not confuse the unwrap attribute with the wrap attribute of the String
descriptor, which is based on a rectangular block of text rather than fields (see
“How the macro runtime searches the rectangular area (Wrap attribute)” on page
43).
When unwrap is true and continuous is false: When the continuous attribute is
false, the row and column pairs represent the corners of a rectangular block of text.
When you set the unwrap attribute to true, the macro runtime reads each row of
the rectangular block of text and processes each field in the row as follows:
The intent of the unwrap attribute is to capture the entire contents of a field as one
string even if the field wraps from one line to the next.
For example, suppose that the host terminal is 80 characters wide and that rows 9,
10, 11, and 12 of the host terminal are as follows:
...............................................Compress or print data set.......
..............................................................Reset statistics..
..............................................................Catalog or display
information of an entire data set...............................................
Suppose also that the following text areas in the lines above are fields:
Reset statistics
Catalog or display information of an entire data set
The macro runtime concatenates the individual strings and stores them as a single
string into the variable that you specified in the Extract window. In this example
the macro runtime stores the string ’Reset statisticsCatalog or display
information of an entire data set’ into the variable.
When unwrap is true and continuous is true: When the continuous attribute is
true, the row and column pairs represent the beginning and ending locations of a
continuous sequence of text that wraps from line to line if necessary. When you
then set the unwrap attribute to true, the macro runtime processes the continuous
sequence of text as follows:
v If the field begins outside the sequence and continues into the sequence, then
the macro runtime ignores the field.
v If the field begins inside the sequence and ends inside the sequence, then the
macro runtime includes the field's contents in the result.
v If the field begins inside the sequence and ends outside the sequence, then the
macro runtime includes the contents of the entire field (including the part
outside the continuous sequence) in the result.
This action can be specified using the VME, see “Input action” on page 126, and
using the AME, see “Input action” on page 154.
If you specify a row or column location of 0, then the macro runtime will type the
key sequence beginning at the actual row and column location of the text cursor
on the host terminal when the Input action is performed. You should not specify a
row or column of 0 unless the context is one in which the location of the text
cursor does not matter or unless you can predict where the text cursor will be
located (for example, if a Mouse click action has just moved the text cursor to a
specific location, or if the application has positioned the text cursor as part of
displaying the application screen).
Input errors
During macro playback, the host terminal reacts to a key input error in the same
way as it would react if an actual user had typed the key.
For example, if an Input action sends a key that displays a character (such as a, b,
c, #, & and so on) to the session when the text cursor is not located in a 3270 or
5250 input field, then the session responds by inhibiting the key input and
displaying an error symbol in the Operator Information Area, just as it would with
a keystroke typed by an actual user.
For example, suppose that the input key sequence is ’[up][up]Hello world’ and
that the text cursor is at row 4, column 10. If the xlatehostkeys attribute is true,
then in performing this input sequence the macro runtime moves the text cursor
up two rows and then types Hello world beginning at row 2, column 10. In
contrast, if the xlatehostkeys attribute is false, then the macro runtime types
[up][up]Hello world beginning at row 4, column 10.
In contrast, if the value of the movecursor attribute is false, then the macro
runtime does not move the text cursor at all. The text cursor remains in the same
position as it occupied before the macro runtime performed the Input action.
Encrypted attribute
You can use the encrypted attribute to encrypt the input key sequence contained in
the value attribute (the String field). When you encrypt the contents of the value
attribute, Host On-Demand stores only the encrypted version of the input key
sequence into the macro script (in the <input> element) and does not retain the
plain text (unencrypted) version of the input key sequence.
For example, Figure 16 shows an <input> element with an unencrypted input key
sequence (’myPassword’):
In contrast, Figure 17 shows the same <input> element with the input key
sequence encrypted (I7xae6rSVlVFF6qzhWRfKw==). Notice that in this example the
encrypted attribute of the <input> element is set to true:
In the macro editor, an encrypted input key sequence is displayed with asterisks
(for example, the encrypted version of ’myPassword’ is displayed in the String field
as ************************ rather than as I7xae6rSVlVFF6qzhWRfKw==).
After you encrypt the input key sequence, Host On-Demand does not allow you or
anyone else to use the macro editor or the source view to decrypt it. Host
On-Demand does not decrypt an encrypted input key sequence of an Input action
until the macro runtime processes the Input action during macro playback. When
the macro runtime processes the Input action, the macro runtime decrypts the
encrypted input key sequence and types the unencrypted version into the session
window beginning at the specified row and column location.
For greater security, you can use a Prompt action instead of an Input action. With a
Prompt action, the input key sequence is not stored in the macro script, not even in
encrypted form. Instead, during macro playback, when the macro runtime
processes the Prompt action, the macro runtime pops up a window with an input
field and a message prompting the end user to type an input key sequence. When
the end user types the input key sequence and clicks OK, the macro runtime
removes the popup window and directs the input key sequence into the session
window at the specified row and column location.
Note: The default values for prompts are stored in macro files unencrypted. The
default values display in the clear when you edit prompts in the macro
editor. Therefore, while using a prompt to specify a password is an
appropriate thing to do, for security reasons you should not specify a
default value for the password.
Using an Input action does have this advantage, that the macro script runs
automatically during macro playback without the end user having to intervene.
However, if the confidential data changes (for example, if a password expires and
a new and different password is required) then the Input action must be updated
with the new input key sequence.
Automatic encryption during macro recording: During macro recording, for 3270
Display and 5250 Display sessions only, HATS automatically records a password
input sequence as an Input action with an encrypted input key sequence.
Using the Encrypt string (VME) or Password (AME) check box: If the input key
sequence was automatically encrypted during macro recording, when you look at
the Input action in the macro editor, the Encrypt string (VME), or Password
(AME), check box is selected, and the String field contains some number of
asterisks (such as ******) representing the encrypted input key sequence.
In contrast, if the input key sequence was not automatically encrypted during
macro recording (perhaps because the session was not a 3270 or 5250 display
session, or perhaps because the input field was not a non-display input field) then
the check box is cleared and the String field contains the unencrypted input key
sequence.
If the input key sequence was not automatically encrypted during macro recording,
you can encrypt it in the macro editor. Follow these steps to encrypt the input key
sequence. Before you start, clear the check box if it is not already cleared.
1. If the input key sequence that you want is not already present in the String
field, type the input key sequence into the String field.
v The input key sequence appears normally in the String field (for example,
’myPassWord’).
v If you are using the advanced macro format, remember to enclose the input
key sequence in single quotes (’myPassWord’).
2. Select the check box.
v The macro editor encrypts the input key sequence and displays it in the
String field using asterisks (***********************).
After the input key sequence is encrypted, you might decide that you do not want
it to be encrypted or that you want to revise it.
If the input key sequence is encrypted and you decide that you do not want it to
be encrypted, then follow these steps:
1. Clear the check box.
v The macro editor discards the encrypted string and clears the String field.
v If for some reason the String field is not cleared, then delete the characters in
it using the backspace key or the delete key.
2. Type the unencrypted input key sequence into the String field.
If the input key sequence is encrypted and you decide that you want to revise it,
follow these steps:
1. Clear the String field using the backspace key or the delete key.
v Delete the entire encrypted input key sequence, so that the field is empty.
2. Type the revised input key sequence into the String field.
v If you are using the advanced macro format, remember to enclose the input
key sequence in single quotes (’myPassWord’).
v As you type into the String field, the macro editor displays the characters
using asterisks (’myPassword’ is displayed as ************).
v When the input focus leaves the String field (that is, when you click some
other field) then the macro editor encrypts the input key sequence.
Do not try to revise an encrypted input key sequence by typing over or inserting
characters into the string of asterisks in the String field (*******)! If you do, then
you corrupt the encrypted input key sequence with your unencrypted revisions.
Then the macro editor, believing that you have typed in an unencrypted string,
re-encrypts the corrupted sequence. The result is that during macro playback,
when the macro runtime processes the Input action, the decrypted sequence is not
the input key sequence that you expected. (Also, if you are using the advanced
macro format and you do not enclose the corrupted input key sequence with single
quotes, the macro editor generates an error message).
Using the source view: The source view follows the same rules for encrypting an
input key sequence as the macro editor.
The source view always allows you to do either of the following actions:
v Type into the editable text area a new <input> element that encrypts the input
key sequence.
You can also, while using the source view, change the value of the encrypted
attribute (which activates or deactivates encryption) from true to false, or false to
true.
However, if you want to use the source view to modify the value of the value
attribute (which contains the encrypted or unencrypted input key sequence), and
the encrypted attribute is set to true, then completely delete the encrypted input
key sequence (so that it reads value=""), then type in the new input key sequence
that you want encrypted.
Do not try to revise an encrypted input key sequence by typing over or inserting
characters into an encrypted input key sequence in the value attribute! If you do,
then you corrupt the encrypted input key sequence with your unencrypted
revisions.
Encrypting a variable name: Although you can type a variable name (such as
$var1$) into the String field in the macro editor (or into the value part of the value
attribute in the source view) and encrypt the name of the variable (using the same
steps that you would use to encrypt a normal input key sequence) this normally is
not a useful thing to do. The reason is that when you encrypt a variable name only
the characters making up the variable name are encrypted. The contents of the
variable itself are not encrypted.
During macro playback, the macro runtime decrypts the encrypted text to get the
plain text (such as $var1$), sees that the plain text is a variable name, and then
evaluates the variable in the usual way.
This action can be specified using the VME, see “Set cursor position action” on
page 131, and using the AME, see “Mouse click action” on page 154.
More specifically, the macro runtime finds the <pause> element, reads the duration
value, and waits for the specified number of milliseconds. Then the macro runtime
goes on to perform the next item.
This action can be specified using the VME, see “Perform action” on page 127, and
using the AME, see “Perform action” on page 155.
You can invoke a method in many other contexts besides the Perform action.
However, the Perform action is useful in certain scenarios, for example, when you
want to invoke a method that does not return a value.
Some of the contexts, other than the Perform action, in which you can invoke a
method are as follows:
v You can invoke a method and assign the return value to a variable by using the
Update variable action. The variable that receives the return value can be either
a variable belonging to a standard type (boolean, integer, string, double) or a
variable belonging to an imported type (for example, a variable named
$objTmp$ that belongs to the imported type Object, based on the Java class
Object).
v You can invoke a method and use the return value as a parameter in a macro
action by specifying the method call in the field for the parameter. For example,
in the Row parameter of an Extract action you can use a method call that
returns an integer value. The macro runtime sees that the parameter is a method
call , invokes the method, and uses the integer return value as the value of the
Row parameter.
v You can invoke a method as part of any expression by using the method call as
a term in the expression. When the macro runtime evaluates the expression, it
sees that the term is a method call, invokes the method, and uses the value of
the method (for example, a string) as the value of the term.
v You can invoke a method and use the return value as the initial value of a
variable that you have just declared.
In general, outside the Perform action, you can invoke a method in any context in
which the value returned by the method is valid.
Examples
The Figure 18 on page 68 shows how to invoke a method using the Perform action.
Notice the following facts about these examples:
v In Example 1, the Perform action calls the update() method on the variable
$importedVar$. Notice that:
– The entire method call is enclosed in dollar signs ($).
– In the context of a method call, the variable name itself (importedVar) is not
enclosed in dollar signs ($).
– A variable passed as a parameter to a method must be enclosed in dollar
signs ($) as usual ($str$).
– A string passed as a parameter to a method must be enclosed in single quotes
as usual (’Application’).
v In Example 2, the Perform action calls a static method.
<actions>
<!-- Example 1 -->
<perform value="$importedVar.update( 5, ’Application’, $str$)$" />
This action can be specified using the VME, see “Play macro action” on page 127,
and using the AME, see “Playmacro action” on page 155.
When the macro runtime performs a PlayMacro action, it terminates the current
macro (the one in which the PlayMacro action occurs) and begins to process the
specified macro screen of the target macro. This process is called chaining. The
calling macro is said to "chain to" the target macro. There is no return to the calling
macro.
You must specify in the PlayMacro action the name of the target macro and,
optionally, the name of the macro screen in the target macro that you want the
macro runtime to process first.
You can have the macro runtime transfer all of the variables with their contents
from the calling macro to the target macro.
You can have as many Condition elements in the macro as you like, with each
Condition element containing one PlayMacro action in its true branch and one
PlayMacro action in its false branch.
Any time that you use macro variables with prompts in macros, you must specify
a value of promptall=true in the <HAScript> tag of the macro. This is the default
value for the attribute. Ensure that your calling macro, which contains all of the
prompts for the chain, is using a value of true for promptall.
Transferring variables
You can have the macro runtime transfer to the target macro all the variables that
belong to the calling macro, including the contents of those variables, by setting
the transferVars attribute to "Transfer" (the default is "No Transfer").
This transferring of variables and their contents allows you to use variables to pass
parameters from the calling macro to the target macro.
After the target macro gets control, it can read from and write to the transferred
variables in the same way that it reads from and writes to variables that it has
declared itself.
For example, if MacroA currently has two integer variables named StartRow and
StartCol, with values of 12 and 2, and then MacroA launches MacroB with a
PlayMacro action, then MacroB starts out having variables StartRow and StartCol
with values of 12 and 2.
Even if the transferred variable belongs to an imported type and contains a Java
object, the target macro can still refer to the transferred variable and call methods
on the Java object, or can write some other object into that transferred variable.
Requirements for transferring variables: The target macro must have selected the
advanced macro format (see “Basic and advanced macro format” on page 15).
When the target macro needs to import a type: In the target macro, if you want
to use a transferred variable that belongs to an imported type, then you do not
need to import that same type in the target macro. Examples of operations where
you do not need to import the type are as follows:
v Using the transferred variable as the value of an attribute
v Calling a method on the transferred variable
However, in the target macro, if you want to use the name of an imported type,
then you must import that type. Examples of operations where you must import
the type:
v Declaring a new variable of the imported type
v Creating a new instance of the imported type
v Calling a static method of the imported type
<actions>
<playmacro name="TargetMacro" startscreen="*DEFAULT*"
transferVars="Transfer" />
</actions>
This action can be specified using the VME, see “Prompt action” on page 128, and
using the AME, see “Prompt action” on page 155.
The Prompt action displays on top of the host terminal a prompt window that
contains a message, an input field, and three buttons (OK, Cancel, Help). After the
user types text into the input field and clicks OK, the Prompt action uses the input
in one or both of the following ways:
v The Prompt action types the input into an input field of the host terminal.
v The Prompt action interprets the input as a string and stores the input into a
variable.
A typical use of this action, but by no means the only use, is to permit the user to
provide a password. Many scenarios require that a macro log on to a host or start
an application that requires a password for access. Because a password is sensitive
data and also typically changes from time to time, you probably do not want to
code the password as an immediate value into the macro.
With the Prompt action, you can display a message that prompts the user for a
password and that lets the user type the password into the input field. After the
user clicks OK, the macro runtime types the input into the host terminal at the row
Note: The default values for prompts are stored in macro files unencrypted. The
default values display in the clear when you edit prompts in the macro
editors. Therefore, while using a prompt to specify a password is an
appropriate thing to do, for security reasons you should not specify a
default value for the password.
The promptall attribute in the <actions> element works similarly (see “<actions>
element” on page 172).
This action can be specified using the Source tab in the VME, and using the
Actions tab in the AME, see “SQLQuery action” on page 158.
You can use the SQLQuery action in any type of session that supports macros
(3270 Display, 5250 Display, or VT Display).
The database server to which you connect can be on a different host than the host
running your application session.
The SQLQuery action supports only SQL statements of type Select. It does not
support SQL statements of type Insert, Update, or Delete.
The SQLQuery action requires a database driver that is accessible to both the
HATS Toolkit environment and the specific HATS applications using the
SQLQuery action. The database driver is specific to the database being accessed;
obtain this driver from the database administrator.
For the SQL Wizard to function correctly within the HATS Toolkit, the database
driver file should be placed in the lib\ext directory of the Java Runtime
Environment (JRE) being used by the Rational® Software Delivery Platform (for
example, RAD_INSTALL_DIR\jre\lib\ext). You must restart the Rational Software
Delivery Platform (if it was active) after copying the database driver to the JRE
location.
The HATS application must also have access to the database driver file when it is
deployed. For HATS Web applications, the database driver file should be added to
the EAR level. After the file is added to the EAR level, each WAR in the HATS
application that uses the SQLQuery action must have its META-INF/
Chapter 7. Macro actions 71
MANIFEST.MF file updated to include the database driver file. To ensure that the
update to the MANIFEST.MF file is made correctly, edit it using the JAR
Dependency Editor. For HATS rich-client applications, the database driver file
should be added to the lib\ext directory of the JRE that is being used by the target
deployment environment (Eclipse rich client, Lotus Notes®, or Lotus® Expeditor
Client).
This action can be specified using the Source tab in the VME, and using the
Actions tab in the AME, see “Trace action” on page 163.
Example
The example in Figure 20 on page 73 shows how to send trace messages to the
HATS Toolkit console. This example uses the following action elements: Trace and
Variable update.
You can copy the text of this macro script from this document into the system
clipboard, and then from the system clipboard into the source view (see “Samples”
on page 7). After you save this script in the macro editor, you can edit it.
This script in Figure 20 causes the macro runtime to send the following data:
The value is +{$strData$ = Original value}
The value is +{$strData$ = Updated value}
In the trace output above, notice that instead of just displaying the value of
$strData$, the Debug action displays both the variable's name and its value inside
braces.
This action can be specified using the VME, see “Update macro variable action” on
page 131, and using the AME, see “Variable update action” on page 163.
You can also use the Variable update action in a <description> element (see
“Processing a Variable update action in a description” on page 46).
The value can be an arithmetic expression and can contain variables and calls to
imported methods. If the value is an expression, then during macro playback the
macro runtime evaluates the expression and stores the resulting value into the
specified variable.
With the Variable update action you type the left side of the equation (the variable)
into the variable name field in the macro editor and type the right side of the
equation (the value) into the value field. To create the equivalents of the Java
assignment statements above, you would use the values shown in Table 11:
Table 11. Example of variable names and values
In the variable name field: In the value field:
$boolVisitedThisScreen$ true
$intVisitCount$ $intVisitCount$+1
$dblLength$ 32.4
$strAddress$ '123 Hampton Court'
The value that you provide must belong to the correct data type for the context or
be convertible to that type (see “Automatic data type conversion” on page 20).
A field variable is a type of string variable. A field variable is defined in the <vars>
element of the macro script but does not take an initial value. The following
contains an example of a field variable.
<vars>
<create name=$intUpdate$" type="integer" value="3"/>
<create name="$strData$" type="string" value="’hello’"/>
<create name="$fieldVar$" type="field" />
</vars>
A field variable contains a string, just as a string variable does, and you can use a
field variable in any context in which a string variable is valid. However, a field
variable differs from a string variable in the way in which a string is stored into
the field variable. The string that a field variable contains is always a string that
the macro runtime has read from a 3270 or 5250 field in the current host terminal.
When you use the Variable update action to update a string variable, you specify
the following information:
v The name of the field variable, such as $fldTmp$.
v A location string, such as '5,11'. (A location string is a string containing two
integers separated by a comma that represent a row and column location on the
host terminal.)
You can then use the field variable in any context in which a string is valid. For
example, you can concatenate the field variable with another string, as in the
following:
’The field\’s contents are’+ $fldPrintOption$
As an example, suppose that the host terminal contains a 3270 or 5250 field with
the following characteristics:
v It begins at row 5, column 8
v It ends at row 5, column 32
v It contains the string ’Print VTOC information’
You set up a Variable update action with the following values:
v In the variable name field you type the name of a field variable that you have
just created, $fldData$.
v In the value field you type a location string, ’5,11’. Notice that you have to
specify only one row and column location, and that it can be any row and
column location that lies within the field.
When the macro runtime performs this Variable update action, the macro runtime
reads the entire contents of the field and stores the contents as a string into
$fldData$. The field variable $fldData$ now contains the string ’Print VTOC
information’.
Reading part of a field: When you are using a field variable in a Variable update
action, you can specify a location string that contains two locations. Use this
feature if you want to read only part of the contents of a field.
Type the first and second locations into the value field with a colon (:) between
them. For example, if the first location is 5,14 and the second location is 5,17, then
you would type ’5,14:5,17’.
As an example, suppose that the host terminal contains a 3270 or 5250 field with
the following characteristics:
v It begins at row 5, column 8
v It ends at row 5, column 32
v It contains the string ’Print VTOC information’
If the second location lies beyond the end of the field, the macro runtime reads the
string beginning at the first location and continuing until the end of the field. The
macro runtime then stores this string into the field variable.
There are several timing parameters that influence macro execution. Most timing
parameters control delays in various parts of the macro's execution. This allows the
macro to be resilient, robust, and successful in an environment where host
response time and certain other variables might be unpredictable. The most
common reason for adding delay in a macro is to allow the screen coming from
the host to complete its arrival before it is processed by the macro. This delay can
usually be reduced or totally avoided if enough additional description — for
example, looking for strings of characters on various parts of the screen — is
added to the screens that the delay addresses.
In a HATS macro, there are elements and there are attributes that modify elements
(attributes are also referred to as parameters). Elements are framed by opening and
closing angle bracket tags and attributes are normally included within an element's
tags, such as in this example of the screen element with a modifying pause
attribute:
<screen pause=15000>
The pause attribute (not to be confused with the <pause> element) overrides the
pausetime attribute. To be more precise, if a pause attribute is defined within an
element, it is used to override, for only that screen, the pausetime attribute defined
(explicitly or by default) in the <HAScript> element for the macro. This means that
when the pause attribute is defined for a screen, the pausetime attribute is ignored,
and the value of that screen's pause attribute is used in calculating any
pausetime-related delays that occur during that <screen> element's processing. The
pause and pausetime attributes are not affected by, and do not affect, the
processing of any <pause> elements.
The <pause> element is used to insert an explicit delay into the processing of a
screen's actions. One or more <pause> elements can be placed before, in between,
and after other actions defined in a screen's <actions> element. The pause and
pausetime attributes are not affected by, and do not affect, the processing of any
<pause> elements.
For macro screens defined as exit screens (the exitscreen attribute set to “true”), the
pausetime attribute (and any pause attribute defined for that exit screen) is
essentially ignored and there is no additional delay automatically executed after all
of the screen's actions are completed. This keeps the macro engine from adding
extra delays once it has navigated to the final screen of the macro.
For example, if pausetime="1000" and no pause attribute is defined for the screen,
as shown in Figure 21, the macro will sleep for 500 ms after the first action (a
prompt), 500 ms after 4th action and (if the current screen is not an exit screen)
1000 ms after all the actions are played, for a total of 2000 ms.
<actions>
<prompt...
<extract...
<extract...
<prompt...
<insert...
</actions>
In a macro, <pause> elements are executed inline wherever they are placed, and
are not overridden by the pausetime attribute or pause attribute settings, but might
be overridden by the ignorepauseforenhancedtn attribute of the <HAScript>
element if it is set to "true".
<actions>
<prompt...
<extract...
<extract...
<prompt...
<insert...
<pause value="150"/>
</actions>
Note that if this were an exit screen, the total sleep time would be 1650 ms. Also
note that the ignorepauseforenhancedtn attribute of the <HAScript> element, and
the ignorepauseoverrideforenhancedtn attribute of the <pause> element, if set, will
effect whether the explicit <pause> element in this example is executed or ignored.
There are two attributes that let you add a pause after actions during runtime:
v The pausetime attribute of the <HAScript> element.
v The pause attribute of the <Screen> element.
By default, the pausetime attribute is enabled and the timeout value is set to 300
milliseconds. Therefore by default the macro runtime:
v Waits 150 milliseconds after every Input action or Prompt action except the last
one in a macro screen.
v Waits 300 milliseconds after the last action in a macro screen.
Notice that the pausetime attribute affects every macro screen. Therefore this one
setting allows you avoid timing errors throughout the macro, without having to
change each macro screen that might have a problem.
If you specify this attribute for a macro screen, then the macro runtime uses the
specified number of milliseconds for the pause between actions for this particular
macro screen.
For example, if for ScreenA you set the pause attribute to 500 milliseconds, then
the macro runtime waits 250 milliseconds after each Input action and Prompt
action in ScreenA except the last one, and waits 500 milliseconds after the last
action in ScreenA.
When the macro runtime processes a macro screen with the pause attribute of the
<screen> element specified, it ignores the setting of the pausetime attribute of the
<HAScript> element, and uses only the value in the pause attribute.
Screen completion
In short, as a result of this timing problem the macro runtime has read rows 15
and 16 of the new application screen before the host could finish updating them.
However, this process does present problems for the macro runtime during screen
recognition. Recall that during screen recognition the macro runtime tries to match
the application screen to one of the valid next macro screens every time the screen
is updated and every time an OIA event occurs (see “Repeated screen evaluations”
on page 31). Therefore the macro runtime might find a match before the screen is
completely updated. For example, a String descriptor might state that recognition
occurs if row 3 of the application screen contains the characters "ISPF Primary
Option Menu". When the host has updated row 3 to contain these characters, then
the macro runtime determines that a match has occurred, regardless of whether the
host has finished updating the remainder of the application screen.
Add more descriptors: This approach works sometimes but can be awkward and
unreliable. You add enough descriptors to the description part of ScreenB so that
the macro runtime will not recognize the ScreenB until the critical portion of the
application screen has been updated.
Insert a delay after the input action: Inserting a delay is the best solution if the
session is an ordinary TN3270 session or if the session is a TN3270E session
without contention-resolution. That is, after the Input action (in ScreenA in our
example) that causes the host to send a new application screen, insert a pause of
several hundred milliseconds or longer. This delay allows enough time for the host
to update the application screen before the macro runtime starts processing the
actions in the next macro screen (ScreenB).
In this scenario there are several ways to insert a pause after the Input action:
v Increase the delay specified by the pausetime attribute of the <HAScript>
element.
v Increase the delay specified by the pause attribute of the <screen> element for
ScreenA. This method is a good one. You are increasing the pause time only for
ScreenA, so that only ScreenA is affected.
If your macro has to run both on ordinary TN3270 sessions and also on TN3270E
sessions with contention-resolution enabled, the XML macro language has several
attributes that can help you. See “Attributes that deal with screen completion.”
ignorepauseforenhancedtn=true/false
The ignorepauseforenhancedtn attribute of the <HAScript> element, when set to
true, causes the macro runtime to skip Pause actions (<pause> elements) during
macro playback if the session is running in a contention-resolution environment.
You can use this attribute if you developed a macro to run in a
non-contention-resolution environment (you inserted Pause actions) and you now
want the macro to also run in a contention-resolution environment without
unnecessary delays (you want the Pause actions to be ignored).
With this attribute set to true, the macro runtime processes Pause actions (waits the
specified number of milliseconds) in a non-contention-resolution environment but
ignores Pause actions in a contention-resolution environment.
ignorepauseoverrideforenhancedtn=true/false
The ignorepauseoverrideforenhancedtn attribute of the <pause> element, when set
to true in a particular <pause> element, causes the macro runtime to process that
<pause> element (wait for the specified number of milliseconds) even if the
ignorepauseforenhancedtn attribute is set to true in the <HAScript> element.
Set this attribute to true in a <pause> element if you want the <pause> element
always to be performed, not skipped, even in a contention-resolution environment
with the ignorepauseforenhancedtn attribute set to true in the <HAScript> element.
delayifnotenhancedtn=(milliseconds)
The delayifnotenhancedtn attribute of the <HAScript> element, when set to a
non-zero value, causes the macro runtime to automatically pause the specified
number of milliseconds whenever the macro runtime receives a notification that
the OIA (Operator Information Area) has changed.
With this attribute set to true, then when the macro is run in a
non-contention-resolution environment the macro runtime inserts a pause for the
specified number of milliseconds each time it receives a notification that the OIA
has changed. For example, if you specify a pause of 200 milliseconds then the
macro runtime waits for 200 milliseconds every time the OIA changes.
The cumulative effect of the macro runtime pausing briefly after each notification
of a change to the OIA is that the application screen is completed before the macro
runtime begins processing the actions of the new macro screen. The macro runtime
inserts these extra pauses only when it detects that the session is running in a
non-contention-resolution environment.
A limitation of this attribute is that the macro runtime adds these extra pauses
during every screen, not just during screens in which screen update is a problem.
However, the additional time spent waiting is small. And more importantly, this
attribute lets you quickly adapt the macro to a non-contention resolution
environment, without having to test individual screens and insert a pause action in
each screen with a screen update problem.
Global variables
Global variables are variables created in HATS Toolkit and used by HATS projects.
Global variables are stored outside of the macro script. They are maintained and
updated by HATS runtime. There are two types of global variables:
Local
A local global variable is one that is created within a HATS project, and is only
visible to the project.
Shared
A shared global variable is one that is visible to and can be used by all the
HATS Web applications in an .ear file, or by all HATS rich client applications
running in the same rich client environment.
Macro variables
Unlike global variables, macro variables are used and stored within macros in the
HATS .hma source file. The macro editors can be used to create macro variables. To
create macro variables using the VME, see “Variables and Types tab” on page 113,
and using the AME, see “Variables tab” on page 147. The macro variables are
created, stored, and used by the macro engine, and listed in the macro script.
In a HATS macro (.hma) file source using HATS prompts and extracts for global
variables, the prompts and extracts appear in the file before the macro script
syntax. The macro script, which contains the macro variables, is enclosed by the
begin <HAScript> and the end </HAScript> tags.
You can create a variable that belongs to any of the standard data types (string,
integer, double, boolean, and field).
You can also create a variable that belongs to an imported type representing a Java
class. You can then create an instance of the class and call a method on the
instance. This capability opens the door to the abundant variety of functionality
available through Java class libraries, including libraries in the Java Runtime
Environment (JRE) libraries, classes or libraries that you implement yourself, or
Java classes and libraries from other sources.
However, remember that all recorded macros are recorded in the basic macro
format. So, if you have recently recorded a macro and are beginning to develop it
further, then you might simply not have gotten around to switching to the
advanced macro format.
The macro editors address both these situations by popping up a window with the
following message when you start to define a variable in a macro that is still in the
basic macro format:
You are attempting to use an advanced macro feature. If you choose to continue,
your macro will automatically be converted to advanced macro format. Would you
like to continue?
Click Yes if you are building a macro in which you plan to use variables, or No if
you have a macro in the basic macro format that you do not want to convert.
Scope of variables
The scope of every variable is global with respect to the macro in which the
variable is created. That is, every variable in a macro is accessible from any macro
screen in the macro. All that an action or a descriptor in a macro screen has to do
to access the variable is just to use the variable name.
For example, suppose that you have a variable named $intPartsComplete$ that you
initialize to 0. You might use the variable in the following ways as the macro
proceeds:
1. ScreenC completes Part 1 of a task and increments $intPartsComplete$ using a
Variable update action.
2. ScreenG completes Part 2 of a task and increments $intPartsComplete$ using a
Variable update action.
3. ScreenM has a Conditional action that tests whether 1 or 2 parts have been
completed so far. Depending on the result, the macro expects either ScreenR or
ScreenS as the next macro screen to be processed.
4. ScreenS completes Part 3 of a task and increments $intPartsComplete$ using a
Variable update action.
In this example, actions in several different macro screens were able to read from
or write to the variable $intPartsComplete$.
Creating a variable
In the Source view, you create a variable using a <create> element. There is a
containing element called <vars> that contains all the variables in the macro script,
and there is a <create> element for each variable. Figure 24 on page 89 shows a
<vars>
<create name="$strAccountName$" type="string" value="" />
<create name="$intAmount$" type="integer" value="0" />
<create name="$dblDistance$" type="double" value="0.0" />
<create name="$boolSignedUp$" type="boolean" value="false" />
<create name="$fldFunction$" type="field" />
</vars>
In Figure 24, the <vars> element creates one variable from each of the standard
data types (string, integer, double, boolean, and field).
You must put all variable creations (<create> elements) inside the <vars> element.
The <vars> element itself must appear after the <import> element, if any (see the
next section), and before the first macro screen (<screen> element).
<import>
<type class="java.util.Hashtable" name="Hashtable" />
</import>
<vars>
<create name=$ht$ type="Hashtable" value="$new Hashtable(40)$" />
</vars>
In the figure above the <import> element contains one <type> element, which has
a class attribute (containing the fully qualified class name, java.util.Hashtable)
and a name attribute (containing the short name, Hashtable). The <vars> element
contains one <create> element, which as usual specifies a name ($ht$), a type
(Hashtable), and an initial value (which here is not null but rather is a call to a
constructor that returns an instance of the class, $new Hashtable(40)$).
If you are using the source view, you must put all imported types (<type>
elements) inside the <import> element. The <import> element itself must appear
inside the <HAScript> element (see “<HAScript> element” on page 180) and
before the <vars> element.
Deploying a Java library or class consists of placing the library file or class file
containing the class in a location where the macro runtime can find it during
macro playback. The following Java classes are automatically available for use and
do not need to be deployed by you:
v Classes in the Java API. The Java archive files are already present in the HATS
application and their locations are listed in the classpath that is specified when
the HATS application is launched.
v Classes in the Host On-Demand Macro Utility Libraries. The HML libraries are
stored with the HATS code (see “The Macro Utility Libraries (HML libraries)” on
page 95).
All other Java classes containing methods invoked by a macro script must be
deployed by you to a location where the macro runtime can find them. Depending
on the environment, you can deploy the Java classes as class files or as libraries
containing Java classes.
Field variables
A field variable is a type of string variable. It holds a string, just as a string
variable does, and you can use it in any context in which a string variable is valid.
However, a field variable differs from a string variable in the way in which a
string is stored into the field variable. The string that a field variable contains is
always a string that the macro runtime reads from a 3270 or 5250 field in the
current host terminal. To get the macro runtime to read this string from the 3270 or
5250 field, you have to create a Variable update action that specifies:
1. The name of the field variable (such as $fldFilename$).
2. A location string (a string containing a pair of integers separated by a comma,
such as ’5,11’).
When the macro runtime performs the Variable update action it takes the following
steps:
1. Looks in the host terminal at the row and column value specified by the
location string.
2. Finds the 3270 or 5250 field in which the row and column value is located.
3. Reads the entire contents of the field.
4. Stores the entire contents of the field as a string into the field variable.
For more information, see “Variable update action with a field variable” on page
74.
Using variables
The macro runtime assigns initial values to variables at the start of the macro
playback, before processing any macro screen. The sections that follow describe the
usage of those initial values for both standard and imported variable types.
In the source view, you cannot use a variable in the following contexts:
v The name of an attribute of any element
v The value of any attribute of an <HAScript> element
v The value of the name attribute of a <screen> element
v The value of the uselogic attribute of the <description> element
v The name of a macro screen in a <nextscreen> element
v The value of any attribute of a <playmacro> element
Writing a Java object into a variable of standard type: If you write a Java object
into a variable of standard type, then the macro runtime calls the toString() method
of the imported type and then attempts to assign the resulting string to the
variable.
Restrictions
You cannot assign the following types of data to a variable of imported type:
If your macro attempts to assign one of these invalid types of values to a variable
of imported type, then the Macro runtime generates a runtime error and halts the
macro.
Also, you can use the Perform action to call a method when you do not need the
return variable of the method or when the method has no return value (void) (see
“Perform action (<perform> element)” on page 67).
When the macro runtime searches in the Java class for a method to match the
method that you have called, the macro runtime maps macro data types (boolean,
integer, string, field, double, imported type) to Java data types as shown in
Table 12:
Table 12. How the macro runtime maps macro data types to Java data types
If the method parameter belongs to this Then the macro runtime looks for a Java
macro data type: method with a parameter of this Java data
type:
boolean boolean
integer int
string String
field String
double double
imported type underlying class of the imported type
The reason is that the macro runtime, during the initializing that goes on when
macro playback is started:
v Imports all the HML classes.
v Creates one variable for each HML class to contain an instance of the class.
v Creates one instance of each HML class and stores it in the appropriate variable.
The following table shows for each HML variable the variable name and the types
of methods in the underlying class.
Table 13. HML variables
HML variable: Description of methods:
$HMLFormatUtil$ Methods for formatting strings.
$HMLPSUtil$ Methods that access the presentation space of the session
window.
$HMLSessionUtil$ Methods that return session values.
$HMLSQLUtil$ Methods that return information about the results of the
most recent SQLQuery action.
$HMLFormatUtil.numberToString(1.44)$
$HMLPSUtil.getCursorPos()$
$HMLSessionUtil.getHost()$
$HMLFormatUtil$
The methods invoked with $HMLFormatUtil$ are formatting methods. Table 14
summarizes these methods:
Table 14. Method summary for $HMLFormatUtil$
METHOD SUMMARY: $HMLFormatUtil$
String
numberToString(Object obj)
Converts a number to a string formatted according to the currently
configured locale. The input parameter can be of type integer or of
type double.
int or
stringToNumber(String str)
double
Converts a numeric string in the local format (such as '1111.56',
'1,111.56', or '1111,56') to a number. The number returned is either
of type integer or of type double, depending on the input string.
Method details
numberToString():
public String numberToString(Object obj)
<input value="$HMLFormatUtil.numberToString(1111.44)$"
row="20" col="16" movecursor="true"
xlatehostkeys="true" encrypted="false" />
stringToNumber():
public int stringToNumber(String str)
public double stringToNumber(String str)
<value="'1111.33'" />
<extract name="’Extract’" planetype="TEXT_PLANE"
srow="1" scol="1"
erow="1" ecol="10" unwrap="false"
assigntovar="$value$" />
<if condition="$HMLFormatUtil.stringToNumber($value$)$ < 0 "
...
</if>
$HMLPSUtil$
The methods invoked with $HMLPSUtil$ affect the presentation space of the
session window or return information about the presentation space of the session
window. Table 15 summarizes these methods:
Table 15. Method summary for $HMLPSUtil$
METHOD SUMMARY: $HMLPSUtil$
int
convertPosToCol(int pos)
Returns the column number of the specified position in the
presentation space.
int
convertPosToRow(int Pos)
Returns the row number of the specified position in the
presentation space.
Presentation space
The presentation space is a data structure that contains an element for each row
and column position in the session window (but not including the last row of the
session window, which is used for the Operator Information Area). The size of the
presentation space depends on the size of the session window. For example, if the
session window has 24 rows and 80 columns, then the size of the presentation
space is 24 * 80 = 1920.
The position of the elements in the presentation space corresponds serially to the
row and column positions in the session window, reading from left to right, top to
bottom. For example, if the session window has 80 rows and 25 columns, then row
and column positions are as shown in Figure 29 on page 99:
Figure 29. Correspondence of row and column location in the presentation space
Host On-Demand uses the presentation space to store the characters that are to be
displayed in the session window. Each element in the presentation space is used to
store one character (and information about that character, such as intensity). For
example, if the string Message appears at row 1 and column 1 of the session
window, then rows and columns correspond to the positions shown in Figure 30:
Although you normally will not need to use them, Table 16 shows the formulas for
calculating various values. The meanings of the symbols used in these formulas are
as follows:
v row - A row location in the session window
v col - A column location in the session window
v pos - A position in the presentation space
v NUMROWS - The number of rows in the session window, not including the last row
used for the Operator Information Area (OIA)
v NUMCOLS - The number of columns in the session window
Table 16. Formulas for calculating values related to presentation space
Value: Formula for calculating:
Size of the PS NUMROWS * NUMCOLS
Example:
24 * 80 = 1920
Example:
(81 + 80 - 1) / 80 = 2
col pos - ((row - 1) * NUMCOLS)
Example:
1920 - ((24 - 1) * 80) = 80
pos ((row - 1) * NUMCOLS) + col
Example:
((24 - 1) * 80) + 1 = 1641
Method details
convertPosToCol():
public int convertPosToCol(int pos)
This method returns the column number associated with the specified position in
the presentation space.
convertPosToRow():
public int convertPosToRow(int pos)
This method returns the row number associated with the specified position in the
presentation space.
enableRoundTrip():
public void enableRoundTrip(boolean flag)
This method is for bidirectional languages only (Arabic and Hebrew). Assume that
A, B, and C are bidirectional characters. Normally, when a string contains a series of
bidirectional characters followed by a series of numerals (for example, ABC 123),
and the entire string is stored, the Host On-Demand client exchanges the positions
of the bidirectional characters and the numerals. For example, normally, if you read
the string ABC 123 from the presentation space and store the string into a variable,
and then subsequently write the value of the variable back into the presentation
space, the Host On-Demand client writes 123 ABC back into the presentation space.
getCursorCol():
public int getCursorCol()
This method returns the column location of the text cursor in the presentation
space.
<input value="$HMLSessionUtil.getHost()$"
row="$HMLPSUtil.getCursorRow()$"
col="$HMLPSUtil.getCursorCol()$+2"
movecursor="true" xlatehostkeys="true"
encrypted="false" />
getCursorPos():
public int getCursorPos()
This method returns the position of the text cursor in the presentation space.
getCursorRow():
public int getCursorRow()
This method returns the row location of the text cursor in the presentation space.
<input value="$HMLSessionUtil.getHost()$"
row="$HMLPSUtil.getCursorRow()$"
col="$HMLPSUtil.getCursorCol()$+2"
movecursor="true" xlatehostkeys="true"
encrypted="false" />
getSize():
public int getSize()
getSizeCols():
public int getSizeCols()
This method returns the number of columns in the presentation space. The
presentation space has the same number of columns as the session window. For
example, if the session window has 25 rows and 80 columns, then the number of
columns in the presentation space is 80.
getSizeRows():
public int getSizeRows()
This method returns the number of rows in the presentation space. The
presentation space has one row less than the session window (because the last line
of the session window, which contains the Operator Information Area, is not
included in the presentation space). For example, if the session window has 25
rows and 80 columns, then the number of rows in the presentation space is 24.
getString():
public String getString(int pos, int len)
This method returns the text string beginning at the specified position in the
presentation space and continuing for the specified number of characters.
searchString():
public int searchString(String str)
This method returns the position in the presentation space of the specified string.
This method returns 0 if the string is not found in the presentation space.
$HMLSessionUtil$
The methods invoked with $HMLSessionUtil$ return values associated with the
session. Table 17 summarizes these methods:
Table 17. Method summary for $HMLSessionUtil$
METHOD SUMMARY: $HMLSessionUtil$
String
getHost()
Returns the text string specified in the Destination Address field
of the session configuration.
String
getLabel()
Returns the string specified in the Session Name field of the
session configuration
String
getName()
Returns the session instance identifier assigned to the session by
the host.
Method details
getHost():
public String getHost()
This method returns the host name or the host address that you typed into the
Destination Address field of the Connection section of the session configuration
(such as myhost.myloc.mycompany.com or 9.27.63.45).
This method returns the session name that you typed into the Session Name field
of the Connection section of the session configuration (a name such as 3270
Display or 5250 Display).
getName():
public String getName()
This method returns the identifying name that the host assigns to the session (such
as A , B, or C). When you start a session, the host assigns a name to the session to
distinguish it from other instances of the same session that might be started.
$HMLSQLUtil$
The methods invoked on $HMLSQLUtil$ return information about the results of
the most recent SQLQuery action. Table 18 summarizes these methods:
Table 18. Method summary for $HMLSQLUtil$
METHOD SUMMARY: $HMLSQLUtil$
int
getColumnSize()
Returns the number of columns of data.
String
getDataByIndex()
Returns the entry located at the specified row index and column
index.
String
getDataByName()
Returns the entry located at the specified row index and column
name (field name).
int
getRowSize()
Returns the number of rows of data.
In the table above, the entry at Row 0, Column 0 contains an empty string. The
remainder of Row 0 contains the field names from the database (TOPICID,
EXMPLID, DESCRIPT). The remainder of Column 0 contains index numbers for
the rows (0, 1, 2, 3, 4). The actual data is contained in the remainder of the array.
All values are strings.
Method details
getColumnSize():
public int getColumnSize()
This method returns the actual number of columns of data in the array, including
the added Column 0. For example, for the array in Table 19 this method returns 4.
getDataByIndex():
public int getDataByIndex(int row, int column)
This method returns the entry at the specified row and column index. The
following list shows the values returned for the data shown in Table 19:
v getDataByIndex(0,0) returns an empty string.
v getDataByIndex(0,1) returns the string 'TOPICID'.
v getDataByIndex(0,2) returns the string 'EXMPLID'.
v getDataByIndex(1,1) returns the string '4'.
v getDataByIndex(2,2) returns the string '54'.
v getDataByIndex(3,3) returns the string 'Edit Products'.
getDataByName():
public int getDataByName(int row, String fieldName)
getRowSize():
public int getRowSize()
This method returns the actual number of rows of data in the array, including the
added Row 0. For example, for the array in Table 19 on page 105 this method
returns 6.
The Macro Editor can still be opened by right-clicking on the macro and selecting
Open With -> Macro Editor. The Advanced Macro Editor can still be opened from
the Macro Editor Overview page. Prompts and Extracts can also still be edited
from the Macro Editor.
Note: Support for the Macro Editor and the Advanced Macro Editor is deprecated
in HATS V9.7. While support continues for now, IBM reserves the right to
remove these capabilities in a subsequent release of the product. This
support is replaced by the Visual Macro Editor.
In the HATS perspective, use any of the following procedures to start the New
Macro wizard:
v From the menu bar, click File > New > Other > HATS > HATS Macro.
v From the menu bar, click HATS > New > Macro.
v From the tool bar, click the Create a HATS macro icon.
v From the HATS Projects view, right-click a project and select New HATS >
Macro.
Select
SignOn Marquee
MainMenu
Prompt for userName Screen
Input ‘go celdial[enter]’
Prompt for password
Next Screen Connection
Send [enter]
Actions
CelDialCommunications Input
CustomerDetail BadCustomerNumber
Extract number Extract errorMessage
Extract name
Extract address
Extract city
Extract country
3 more actions...
3 Sign On
System . . . . . :
Subsystem . . . :
ISERIESD
QINTER
Display . . . . . : QPADEV000S
User . . . . . . . . . . . . . . . . . . . . ____________
Password . . . . . . . . . . . . . . . . .
Program/procedure . . . . . . . . . . . . . ____________
Menu . . . . . . . . . . . . . . . . . . . . ____________
Current library. . . . . . . . . . . . . . . . ____________
4
Figure 49. Visual Macro Editor parts
Design tab
The design tab, or canvas, is the primary work area in the VME. It shows the
macro objects graphically (macro screens, actions, and next screen connections) and
allows you to make modifications to each object as well as change global macro
properties.
Input '1[enter]'
DisplayProgramMessages
Send [enter]
CustomerInquiry
Send [enter]
CustomerDetail BadCustomerNumber
For each object, different actions are enabled using the object's pop-up menu
(right-click on the object). All actions can be undone by selecting Undo from the
pop-up menu or from the Edit menu on the menu bar. All actions can be redone
by selecting Redo from the pop-up menu or from the Edit menu. Once the macro
is saved, changes cannot be undone. Once a change is made in the Source tab,
previous actions made in the Design tab cannot be undone. Changes made on the
Design tab are reflected in the Source tab and vice versa.
Macro menu
The following actions are enabled on the macro's pop-up menu (right-click on the
white macro canvas):
Save Saves the macro to a file, disabling the Undo and Redo actions.
Copy As image
Copies the entire image of the macro to the system clipboard. This is useful
for pasting the image of the macro into an email, or design document.
Paste Only enabled after a screen copy or cut.
Reset Layout
Resets the macro screens by attempting to minimize the number of crossed
next screen connection lines. Entry screens are positioned at the top. Exit
screens are positioned at the bottom. By default, the layout is reset when a
screen is added using the integrated terminal. The layout of a macro
created in a previous version of HATS is automatically set (using this same
algorithm) when the macro is opened the first time in the VME.
Screen menu
The following actions can be performed on a screen's pop-up menu (right-click a
macro screen object):
Cut Deletes and copies the macro screen. For more information, see “Cut,
delete, copy, and paste screens” on page 116.
Copy Copies the macro screen and allows pasting it into the same macro or
another macro. For more information, see “Cut, delete, copy, and paste
screens” on page 116.
Paste Only enabled after a screen copy or cut.
Delete Removes the macro screen from the macro. For more information, see
“Cut, delete, copy, and paste screens” on page 116.
Rename
Allows renaming the macro screen. Disabled if more than one screen is
selected.
Properties
Allows editing macro screen-level settings. Disabled if more than one
screen is selected.
Action menu
The following actions can be performed on a screen action's pop-up menu
(right-click a screen action):
Edit Allows editing the screen action. Only enabled if one action is selected. For
more information, see“Adding and editing actions” on page 119.
Remove
Removes the action from the macro screen.
Move Up
Moves the action up in the list of screen actions. Disabled for the first
action.
Move Down
Moves the action down in the list of screen actions. Disabled for the last
action.
Palette view
The Palette allows you to:
v Select an object using the Select tool.
v Select multiple objects on the canvas using the Marquee tool.
Palette
Select
Marquee
Screen
Next Screen Connection
Actions
Input
Prompt
Prompt All
Extract
Extract All
Set Cursor Position
Integrated terminal
The integrated terminal toolbar allows for the following actions:
Connect
Connect to the host.
Disconnect
Disconnect from the host.
Add Screen
See “Adding a screen from the integrated terminal” on page 115.
Play Macro
See “Playing the macro” on page 114.
Stop Macro
See “Playing the macro” on page 114.
Host keypad
Interact with the host using the host keypad pull-down.
Note: In the integrated terminal, when navigating the host application, the
F12 key is intercepted by IBM® Rational Software Delivery Platform
(Rational SDP), which then moves the focus to the design pane of
the VME. The F12 key is never sent to the host application. To work
around this issue, and for other host keys as needed, use the host
keypad pull-down from the toolbar.
User . . . . . . . . . . . . . . . . . . . . ____________
Password . . . . . . . . . . . . . . . . .
Program/procedure . . . . . . . . . . . . . ____________
Menu . . . . . . . . . . . . . . . . . . . . ____________
Current library. . . . . . . . . . . . . . . . ____________
MA* a 06/053
Source tab
The Source tab enables you to modify the macro XML source. It is required for
advanced editing, such as adding custom screen recognition criteria.
The VME uses the Host On-Demand <comment> tag to keep information like
location of the macro screen on the canvas and the associated screen capture.
The <comment> tag can also be used by developers to add a comment to a screen.
Another way to add a comment is to use the format : <!– this is a comment–>. To
avoid losing a developer's pre-existing comments, the VME converts text found in
the <comment> tag that it does not recognize, for example, that does not contain any
of the keywords like visualinfo, into a comment for the screen using the <!– –>
format.
If there are syntax errors in the macro, then error markers appear when the macro
is saved. Markers appear in the source and in the Problems view. Source errors
prevent the macro canvas from showing, and an error message is displayed
instead. If this occurs, switch to the Source tab and correct the errors.
By default, content assistance is enabled for all macros in the project. While editing
a macro on the Source tab, press Crtl+Space to invoke content assistance. You can
configure which macros in the project provide content assistance. For instructions,
see Macro Content Assistance.
The Properties panel includes a General tab and a Variables and Types tab.
General tab
The General tab allows you to view and modify the following macro properties:
Name Name of the macro (view only).
Description
Description of the macro. Optional.
Author
Author of the macro. Optional.
Creation date
Date and time when the macro was created. Optional.
Pause between actions
The amount of time (in milliseconds) the macro playback engine waits
between executing actions in a macro screen.
Timeout between screens
The amount of time (in milliseconds) the macro playback engine waits for
a next screen to appear.
Handle all prompts at start of macro
Specifies whether the user is prompted for all of the macro's prompts at
the start of the macro.
Connection
The name of the connection in the project to use. For HATS projects with a
single connection, the connection is typically named main. This setting is
important if the macro is used in an Integration Object (IO) because this
value is hardcoded in the generated IO when the IO is created and is used
at runtime to select which connection to use.
Automatically connect terminal when the macro is opened
Specifies whether to automatically connect the integrated terminal when
the macro is opened.
The Enable support for variables and arithmetic expressions check box is cleared
by default, can only be selected once, and is disabled afterwards. When the check
box is selected, the macro is converted into the advanced macro format. Because
this operation cannot be undone, a warning message is issued.
After the warning message is cleared by clicking Yes, the Variables and
User-Defined Types tables are enabled and you can Add, Edit, and Remove items
from the tables.
For more information, see Chapter 3, “Data types, operators, and expressions,” on
page 15 and Chapter 9, “Variables and imported Java classes,” on page 87.
The Screen Properties panel includes a General tab, a Screen Recognition Tab, and
an Actions Tab.
General tab
The General tab allows you to modify the following properties:
Name Name of the macro screen.
Screen capture
If a screen capture is associated with the macro screen, then a preview is
shown in the screen capture area. If no screen capture is associated with
the macro screen, then a message is displayed in the screen capture area.
You can use the Browse button to select a new screen capture and the
Clear button to remove the association to a screen capture. For more
information, see “Associating a macro screen with a screen capture” on
page 116.
Entry screen
Specifies a screen on which the macro can begin.
Exit Specifies a screen on which the macro can end.
Transient screen
Specifies an unpredictable screen that may appear at anytime.
| Set Recognition Limit
| Specifies the number of times that the macro runtime recognizes the macro
| screen. When the macro runtime recognizes the macro screen by the
| specified times, the macro runtime does not process the actions of this
| macro screen, but instead performs the specified action.
| By default the Set Recognition limit check box is cleared and the input
| field is disabled. If you select the check box, then the macro editor sets the
| default value of the Screens Before Error input field to 100. You can set
| the value to a larger or smaller quantity. For more information, see
| “Recognition limit” on page 53.
Actions tab
The Actions tab allows you to configure the actions to perform when the screen is
recognized.
You can Add, Edit, Remove, and change the order of the actions using the Up and
Down buttons. For more information, see “Adding and editing actions” on page
119.
When dragging from a project different than the one that contains the macro, you
are prompted to select whether to import the screen capture file into the target
project. If you click Yes, then the file is copied into the project's main Screen
Capture folder, not the macro specific folder, and associated with the new macro
screen on the canvas. If you click No, then the file is not imported, and no screen
capture is associated with the new macro screen on the canvas.
You can double-click on the new screen to fully configure it and use the Next
Screen Connection tool on the palette to wire it with the other screens in the
macro.
To add a screen, click Screen in the palette, then click on the canvas. This action
will start the Add Screen wizard as described in “Adding a screen from the
integrated terminal.” The wizard forces you to select a screen capture using the
Screen Capture panel described in “Associating a macro screen with a screen
capture” on page 116 before proceeding to allow you to configure the screen.
The Screen Capture panel is also displayed when the user adds a screen from the
Palette.
Screen preview
Hovering the mouse over a screen on the canvas shows a preview of the screen
capture associated with it, if any.
This feature is useful when many screens share the same recognition criteria. For
example, if all your screens have a five character name or code at the upper left
corner that uniquely identifies the screen, you can configure default recognition
criteria so that every new screen recorded or added to the macro uses string
recognition at that area of the screen. This saves time by not requiring you to
configure recognition criteria on every screen.
There is only one default recognition criteria saved for the whole project, and it
applies to all macros in the project.
The default recognition criteria is overridden by the last screen recognition criteria
defined with the Remember criteria for next time check box selected.
When a default recognition criteria is defined, it is applied every time the Add
Screen wizard is started and is also adjusted to the screen capture associated with
the new screen.
When one or more screens are selected and either Cut or Delete is executed, then
all of the selected screens and incoming and outgoing next screen connections are
removed from the macro canvas. This operation could force a reordering of the
next screen connections originating from screens not removed. In the example
below, the CelDialCommunications screen has next screen connections from the
DisplayProgramMessages screen and to the MainMenu screen. It is also the second
in order of next screen connections from the SignOn screen.
CelDialCommunications
Input’1[enter]’
MainMenu
Input ‘go celdial[enter]’
After cutting or deleting the CelDialCommunications screen, all of the next screen
connections from and to it are removed, and the MainMenu screen becomes the
second (instead of the third) in order of next screen connections from the SignOn
screen.
SignOn
Prompt for userName DisplayProgramMessages
Prompt for password Send [enter]
Send [enter]
MainMenu
Input 'go celdial[enter]'
When Paste is executed, after a Copy or a Cut, then the internal next screen
connections (next screen connections to other selected screens) are retained during
the operation. In the example below the SignOn, DisplayProgramMessages, and
MainMenu screens are selected to copy.
Delete Delete
Reset Layout
Properties Alt+Enter
After pasting the copied screens back onto the same macro canvas, notice that all
of the next screen connections among the three selected screens are also copied.
Only the next screen connection from the MainMenu screen to the
CelDialCommunications screen is not copied.
Send [enter]
CelDialCommunications
Input ‘1[enter]’
DisplayProgramMessages
Send [enter]
Copy of SignOn
Copy of MainMenu
Prompt for userName
Input ‘go celdial[enter]’
Prompt for password
Send [enter]
Copy of DisplayProgramMessages
Send [enter]
Some considerations must be made when pasting one or more screens from or to a
macro in advanced macro format.
v When pasting screens from a macro that is not in advanced macro format to a
macro in advanced format, then the screens being copied are converted to
advance format.
v When pasting screens from a macro that is in advanced macro format to a macro
that is not, a warning message is displayed, and you have the choice whether to
convert the target macro.
v Variables and user-defined types used by screens being pasted are not copied.
To add an action, click the action in the palette, then click on the macro screen to
add the action.
A panel, applicable to the selected action type, appears so you can edit the
properties of the action.
CustomerDetail
If a screen has more actions than are permitted to be displayed, see “Working with
VME preferences” on page 132, a line that reads nnn more actions is shown.
Actions
The following sections describe all the actions that can be added or edited using
the VME. For more information about macro actions and more details about each
action, see Chapter 7, “Macro actions,” on page 55.
Custom action
A Custom action allows you to invoke a Java program as a macro action and
optionally pass arguments to the program.
You can Add, Edit, Remove, move Up, or move Down, actions to perform for each
case.
For more information see “Conditional action (<if> element and <else> element)”
on page 57.
Extract action
The Extract action captures data from the host terminal and optionally stores the
data into a variable. This action is very useful and is the primary method that the
Macro object provides for reading application data (instead of using programming
APIs from the toolkit).
Name Specifies the name of the extract.
If an extract already exists with the same name, a warning message
displays to notify you that proceeding will override the settings for the
existing extract.
Use the Region section to specify the region of the host screen to extract.
Start row, Start column, End row, End Column
Specify the row and column coordinates of the area of the host screen to
extract. When you use the mouse to mark the area on the host screen,
these fields are filled for you.
Use the Extraction Format section to specify the format of the extracted data. Data
extracted from the text plane is returned by storing a single string or lists of strings
based on the extraction format chosen. Data extracted from the other (non-text)
planes is returned in the form of a character array based on the extraction format
chosen.
Extract this region as one string
When extracting from the text plane, specifies that the extracted text
should be saved as a single horizontal string of characters. This option is
supported for Integration Objects, macro handlers, global variables, and
macro variables.
When extracting from the other (non-text) planes, specifies that the
extracted data should be saved in a global variable as a single object in the
form of a 2-dimensional character array. This option is supported only for
global variables.
Extract this region as a list of strings
When extracting from the text plane, specifies that the extracted text
should be saved as a vertical list of strings. This option is supported for
macro handlers, global variables, and macro variables. For an Integration
Object, a list of strings is treated as one continuous string.
When extracting from the other (non-text) planes, specifies that the data
extracted as a 2-dimensional character array should be broken up into
individual 1-dimensional arrays, each one representing a single row that
was extracted, and each row stored in an index in the global variable. This
option is supported only for global variables.
Extract this region as a table
When extracting from the text plane, specifies that the extracted text
should be saved as a table of horizontal and vertical strings, with rows and
Note: When extracting from the other (non-text) planes, this option is
disabled because this non-text data is not intended to be displayed
directly to a user. Instead, it is meant for developers who need the
extra data to determine how to display or handle certain host
screens.
Click Define to define the table.
Table Extract Configuration
Use this page to format the columns of the table.
v Column name
Use this field to change the heading of the selected column.
v Expand column
Expanding a column moves characters between columns. When
you highlight a column, the Left button moves the last character
on each line of the column to the left of the highlighted column
to become the first character on each line in the highlighted
column. The Right button moves the first character from each
line of the column to the right of the highlighted column to
become the last character on each line in the highlighted column.
v Reduce column
Reducing a column moves characters between columns. When
you highlight a column, the Left button moves the first character
from each line of the highlighted column to become the last
character on each line in the column to the left of the
highlighted column. The Right button moves the last character
from each line of the highlighted column to become the first
character on each line in the column to the right of the
highlighted column.
v Merge
Use this button to merge two highlighted columns into a single
column. The characters in the highlighted columns are joined
into one column.
v Divide
Use this button to divide a highlighted column into two separate
columns. The characters in the highlighted column are divided
equally between the two new columns. If there are an uneven
number of characters, the left column will contain one more
character than the right column.
Note:
Note: When extracting from the other (non-text) planes, this option is disabled
because this non-text data is not intended to be displayed directly to a user.
Instead, it is meant for developers who need the extra data to determine
how to display or handle certain host screens.
Show handler
For HATS Web applications, you can select a .jsp file to display the
extracted information to the user. A default macro handler is shipped with
HATS, and it is named default.jsp. You can find this in the HATS Projects
view, expanding the project name, and expanding Web Content > Macro
Event Handlers. If you want to create your own handler, ensure that you
return control to the HATS runtime.
Note: Integration Objects do not use this option. Instead, the output page
will retrieve the extracted data from the Integration Object and
display them.
For HATS rich client projects, you can specify a custom macro handler, or
browse to select from the list of custom macro handlers defined in the rich
client project, to prompt the user for the necessary information, and
include a button for the user to submit the information. A default macro
handler is shipped with HATS, and it is named DefaultMacroHandler. You
can find this file in the HATS Projects view, expanding the project name,
and expanding Rich Content > Macro Event Handlers. If you want to
create your own handler, ensure that you return control to the HATS
runtime by calling the createButtonArea() and createButtons() methods in
the render() method of your custom macro handler. These methods are
called in the default implementation of the RcpMacroHandler.render()
method. For more information about RcpMacroHandler, see the HATS RCP
API Reference section in the HATS Knowledge Center at
http://www.ibm.com/support/knowledgecenter/SSXKAY_9.7.0?topic=/
com.ibm.hats.doc/doc/rcpjavadoc/index.html.
Save as global variable
You can enter a name for the global variable in the Name field or select an
existing variable using the drop-down menu. If you select an existing
global variable in the Name field, click Advanced and specify how to
handle the existing variable by selecting one of the following radio
buttons:
v Overwrite the existing value with this new value.
v Overwrite the existing value with this new value, starting at the specific
index.
v Append this new value to the end of the existing value.
v Insert this new value into the existing value, at the specific index.
You can also specify whether this variable is shared by selecting the
Shared check box.
If you select to save the extract data as a global variable, the Text option of
the Planes to extract setting is automatically selected.
For more information see “Extract action (<extract> element)” on page 58. For
considerations when using bidirectional language support, see Macro prompt and
extract bidirectional options in the HATS User's and Administrator's Guide.
You can easily exclude single fields, all empty protected fields, or all input fields,
and set names for the extracts.
If an extract already exists with the same name, a warning message displays to
notify you that proceeding will override the settings for the existing extract.
If you select the Save as global variable option, you can also select whether to
Synchronize extract names and global variables names. If you do, then the names
are kept in sync. Otherwise, you can edit the global variable name to make it
different than the name of the extract.
For information about the other VME settings for this action, see “Extract action”
on page 122. For more general information see “Extract action (<extract> element)”
on page 58.
Input action
The Input action simulates keyboard input from an actual user. The action sends a
sequence of keystrokes to the host terminal. The sequence can include keys that
display a character (such as a, b, c, #, &, and so on) and also action keys (such as
[enter] and others).
Insert at current cursor position
Select this box to have the macro runtime insert the input at the current
cursor position on the host terminal. Clear this box to set the cursor Row
and Column fields yourself. Enter the cursor row and column at which to
insert the input. If a screen capture is available, you can click on it to set
the cursor row and column. You can also enter into the Row and Column
fields a variable name in the form $var$.
String Enter into this field the string to send to the host terminal. You can enter
an AID key into this field. For example, pressing F12 on the keyboard will
insert [pf12]. Other AID keys can be inserted using the drop-down menu
next to the field. Since a [tab] will be inserted if the TAB key is pressed,
the mouse must be used to exit the field.
Translate host action keys
Select this box, which is the default value, to have the macro runtime
interpret an action key string (such as [enter]) as an action key rather than
as a literal string.
For more information see “Input action (<input> element)” on page 62.
Pause action
The Pause action waits for a specified number of milliseconds and then terminates.
More specifically, the macro runtime finds the <pause> element, reads the duration
value, and waits for the specified number of milliseconds. Then the macro runtime
goes on to perform the next item.
Specifies the number of milliseconds to wait. The default is 10000 milliseconds (10
seconds).
Perform action
The Perform action allows you to specify a Java method to run. This action can
only be added for macros in advanced macro format.
The action invokes a method belonging to a Java class that you have imported as a
user-defined type (see “Variables and Types tab” on page 113).
Java method
Specifies the method to run. You must enclose a method call in dollar signs
($), just as you would a variable (see “Syntax of a method call” on page
94). The macro runtime invokes the method. See also “How the macro
runtime searches for a called method” on page 94.
For more information see “Perform action (<perform> element)” on page 67.
For more information, see “PlayMacro action (<playmacro> element)” on page 68.
Prompt action
The Prompt action provides a powerful way to send immediate user keyboard
input into the 3270 or 5250 application or into a variable.
Name Specifies the name of the prompt. This name is displayed in the prompt to
the user, so you can use it to provide instructions related to the prompt
field.
If a prompt already exists with the same name, a warning message
displays to notify you that proceeding will override the settings for the
existing prompt.
Default value
Specifies a default value to use for the prompt field.
Password protect input
Select this box to encrypt prompt input provided by the user.
Note: Default values that you specify for prompts are stored in macro files
unencrypted. The default values display in the clear when you edit
prompts using the macro editors. Therefore, while using a prompt to
specify a password is an appropriate thing to do, for security
reasons you should not specify a default value for the password.
Save value to macro variable
Select this box to specify a macro variable in which to save the prompt
input. This option is only displayed if macro variables are enabled for the
macro. The Do not insert value into field option is only enabled if Save
value to macro variable is selected.
Variable
Select the variable in which to save the prompt input. The
drop-down menu is populated with all variables defined in the
macro.
Do not insert value into field
Select this box to have the macro runtime not display the prompt
input in the input field. This field is enabled only when the Save
value to macro variable box is selected.
Clear field before inserting value
Select this box to have the macro runtime clear the contents of the input
field before typing begins.
Insert at current cursor position
Select this box to have the macro runtime insert the prompt input at the
current cursor position on the host terminal. Clear this box to set the
cursor Row and Column fields yourself. Enter the cursor row and column
at which to insert the prompt input. If a screen capture is available, you
can click on it to set the cursor row and column. You can also enter into
the Row and Column fields a variable name in the form $var$.
The Handler section enables you to determine how the prompt is processed. You
can select one of the following radio buttons:
Show handler
For HATS Web projects, you can select a .jsp file to prompt the user for the
necessary information, and include a button for the user to submit the
information. A default macro handler, named default.jsp, is shipped with
HATS. You can find this file by clicking the HATS Projects view of the
Toolkit, expanding the project name, and expanding Web Content > Macro
Event Handlers. If you want to create your own handler, ensure that you
return control to the HATS runtime.
Note: Integration Objects ignore the selected .jsp handler. Instead, an input
page is created for the Integration Object, and a prompt for the
value is placed in that input page. The generated output page copies
the value supplied by the input page into the Integration Object
before the Integration Object is run.
For HATS rich client projects, you can specify a custom macro handler, or
browse to select from the list of custom macro handlers defined in the rich
client project, to prompt the user for the necessary information, and
include a button for the user to submit the information. A default macro
handler, named DefaultMacroHandler, is shipped with HATS. You can find
this file in the HATS Projects view, expanding the project name, and
expanding Rich Client Content > Macro Event Handlers. If you want to
create your own handler, ensure that you return control to the HATS
runtime by calling the createButtonArea() and createButtons() methods in
the render() method of your custom macro handler. These methods are
called in the default implementation of the RcpMacroHandler.render()
method. For more information about RcpMacroHandler, see the HATS RCP
API Reference section in the HATS Knowledge Center at
http://www.ibm.com/support/knowledgecenter/SSXKAY_9.7.0?topic=/
com.ibm.hats.doc/doc/rcpjavadoc/index.html.
Set prompt to string
If you know what value should be returned from a prompt, you can enter
that string in the String field.
Set prompt to global variable
If you want the value of the prompt to be provided by a global variable,
enter a name for the global variable in the Name field or select an existing
variable using the drop-down menu next to the Global variable field. If
you click the Advanced button, you can specify whether your variable is
shared or indexed. If it is an indexed variable, you also need to specify
whether to show all indexes or a single index. For more information about
global variables, see the chapter, Interacting with global variables, in the
HATS User's and Administrator's Guide.
Note:
Note: The Prompt type should be prefilled with the correct value.
For more information see “Prompt action (<prompt> element)” on page 70. For
considerations when using bidirectional language support, see Macro prompt and
extract bidirectional options in the HATS User's and Administrator's Guide.
You can easily exclude fields and set names for the prompts.
If a prompt already exists with the same name, a warning message displays to
notify you that proceeding will override the settings for the existing prompt.
If you select the Set prompt to global variable option, you can also select whether
to Synchronize prompt names and global variables names. If you do, then the
names are kept in sync. Otherwise, you can edit the global variable name to make
it different than the name of the prompt.
For information about the other VME settings for this action, see “Prompt action”
on page 128. For more general information see “Prompt action (<prompt>
element)” on page 70.
Specify the Row and Column location where you want the mouse click to occur.
The screen capture is displayed if it is available. If so, you can click on it to set the
Row and Column fields. You can also enter into the Row and Column fields a
variable name in the form $var$.
| Trace action
| The Trace action sends a trace message to a trace destination that you specify, such
| as the HATS Toolkit console or the WebSphere console. In addition, HATS adds
| macro traces to the HATS runtime trace.
| Trace specification
| Use the Trace Handler list box to specify the destination to which you want the
| trace message sent:
| v Select Host On-Demand trace facility to send the trace message to the Host
| On-Demand trace facility.
| v Select User trace event to send the trace message to a user trace handler.
| v Select Command line to send the message to the console.
| Use the Value input field to specify the string that you want to send to the trace
| destination.
| For more information, see “Trace action (<trace> element)” on page 72.
For more information see “Variable update action (<varupdate> element)” on page
73.
If other connections originating from the same source screen exist, the new
connection will have the highest order or priority. You can use the Reorder action
on the next screen connection pop-up menu to change the order.
To create a loop, that is a next screen connection with the same source and target,
click on the same screen twice. The loop is displayed as an arrow, if no other next
screen connection is defined for the screen, or as a circle showing the order, if more
next screen connections are defined for the screen.
The Reorder action works as an Up and Down. That is, if the connection with
order 2 is changed to order 3 (down 1), then the connection with order 3 goes to
order 2 (up 1).
The source or target of a next screen connection can be changed by dragging the
appropriate end of the connection to a new source or target screen.
The basic Macro Editor can be opened by right-clicking on the macro and selecting
Open With -> Macro Editor. The Advanced Macro Editor can then be opened from
the Macro Editor Overview page. Prompts and Extracts can also still be edited
from the Macro Editor.
If you open a macro with the Macro Editor, instead of with the VME, then the
Macro Editor becomes the default editor for that macro (only that macro).
Note: Support for the Macro Editor and the Advanced Macro Editor is deprecated
in HATS V9.7. While support continues for now, IBM reserves the right to
remove these capabilities in a subsequent release of the product. This
support is replaced by the Visual Macro Editor.
Macro tab
For the purpose of getting you acquainted with the AME, this section consists of a
very simple comparison between the Macro tab of the AME and the <HAScript>
element described in the previous section.
The AME has four tabs: Macro, Screens, Links, and Variables. The first tab, the
Macro tab, corresponds very closely to the <HAScript> element. In fact, the Macro
tab is the graphical user interface for some of the information that is stored in the
attributes of the begin tag of the <HAScript> element.
Therefore, as the <HAScript> element is the master element of a macro script and
contains in its attributes information that applies to the entire macro (such as the
macro description), similarly the Macro tab is the first tab of the AME and
provides access to some of the same global information.
Figure 61 on page 135 shows the AME with the Macro tab selected.
In Figure 61, the Macro tab has input fields for the macro description and other
information, along with several check boxes. Also notice the following:
The Macro Name field contains the name that you assign to the macro. This is the
same name that you will select when you want to edit the macro or run the macro.
Macro names are case-sensitive. For example, macro_1 is a different name than
Macro_1, MACRO_1, and so on.
The Use Variables and Arithmetic Expressions In Macro check box determines
whether the macro object uses the basic macro format or the advanced macro
format for this macro. In the figure above this check box is not selected, indicating
that the basic macro format will be used (see “Basic and advanced macro format”
on page 15).
Figure 62 on page 136 shows a sample <HAScript> element that contains the same
information as is shown on the Macro tab in Figure 61, as well as some additional
information. In the source view, a <HAScript> element is written on a single line;
here the element is written on multiple lines so that you can see the attributes.
...
</HAScript>
Screens tab
This section shows some of the ways in which the Screens tab of the AME is
related to the XML <screen> element described in the previous section. Figure 63
shows the AME with the Screens tab selected:
Notice that there are two Screen Name fields on the Screens tab:
v The Screen Name field at the top of the Screens tab is a list box that contains
the names of all the macro screens in the macro.
v The Screen Name field at the top of the General subtab is an input field in
which you can type the name that you want to assign to the currently selected
screen.
In the Screen Name list box at the top of the Screens tab, you click the name of
the macro screen that you want to work on (such as Screen1), and the AME
displays in the subtabs the information belonging to that macro screen. For
example, in Figure 63 on page 136 the list box displays the macro screen name
Screen1 and the subtabs display the information belonging to Screen1. If the user
selected another macro screen name in the list box, perhaps Screen10, then the
AME would display in the subtabs the information belonging to macro screen
Screen10.
In the Screen Name input field under the General tab, you type the name that you
want to assign to the currently selected macro screen. A screen name such as
Screenx, where x stands for some integer (for example, Screen1), is a default name
that the Macro object gives to the macro screen when it creates the macro screen.
You can retain this name, or you can replace it with a more descriptive name that
is easier to remember. (When all your macro screens have names such as Screen3,
Screen10, Screen24, and so on, it is difficult to remember which macro screen does
what.)
Notice that the subtabs General, Description, and Actions on the Screens tab
correspond to the main parts of the XML <screen> element described in the
previous section. Specifically:
v The General subtab presents the information stored in the attributes of a
<screen> element.
v The Description subtab presents the information stored in the <description>
subelement of a <screen> element.
v The Actions subtab presents the information stored in the <actions> subelement
of a <screen> element.
But what about the <nextscreens> subelement? For usability reasons, the
information belonging to the <nextscreens> element is presented in a higher-level
tab, the Links tab. You can see the Links tab immediately to the right of the
Screens tab in Figure 63 on page 136.
Figure 64 on page 138 shows the XML begin tag and end tag of a sample <screen>
element named Screen1:
In Figure 64, the ellipsis (...) is not part of the XML text, but indicates that the
required elements contained inside the <screen> element have been omitted for
simplicity. Notice that the attributes in the begin tag correspond to fields on the
General tab in Figure 63 on page 136. For example, the name attribute
(name="Screen1" ) corresponds to the Screen Name input field on the General tab,
and the entryscreen attribute (entryscreen="true") corresponds to the Entry Screen
list box on the General tab.
Figure 65 shows the XML text for the entire <screen> element including the
enclosed elements:
In Figure 65, notice that the <screen> element contains the required <description>,
<actions>, and <nextscreens> elements.
By default the Set Recognition limit check box is cleared and the input field is
disabled. If you select the check box, then the macro editor sets the default value
of the Screens Before Error input field to 100. You can set the value to a larger or
smaller quantity. For more information, see “Recognition limit” on page 53.
Description tab
The Description tab on the Screens tab of the AME gives you access to the
information stored inside the <description> element of a macro screen. Figure 66
on page 139 shows a sample Description tab:
Number of Fields
80
In Figure 66, the Screens tab of the AME is selected. The name of the currently
selected screen, Screen2, is displayed in the Screen Name field at the top of the
Screens tab. Below the Screen Name field are the General, Description, and
Actions subtabs. The Description tab is selected.
As you look at the Description tab in the figure above, you can see that it has an
upper area and a lower area.
The upper area contains controls that operate on a single descriptor element
considered as a whole. In particular, the Descriptor list box situated in the upper
left corner of the Description tab contains the name of the currently selected
descriptor. In the figure above, the currently selected descriptor is a Field Counts
and OIA descriptor at the top of the list. (Descriptors do not have names. Field
Counts and OIA is the type of the descriptor.)
The lower area of the Description tab displays the contents of the currently
selected descriptor. Because the currently selected descriptor is a Fields Counts and
OIA descriptor, the lower area of the Description tab presents the contents
appropriate to that type of descriptor. If you created and selected another type of
descriptor, such as a String descriptor, then the lower area would present the
contents appropriate to a String descriptor.
Looking more closely at the lower area of the Description tab in Figure 66, you can
see that the Field Counts and OIA descriptor contains three tests of identity:
v The screen contains 80 fields (the Number of Fields field is set to 80).
v The screen contains three input fields (the Number of Input Fields field is set to
3).
v The screen has the input inhibited indicator cleared (the Wait for OIA to
Become Uninhibited list box is set to true).
Chapter 11. Advanced Macro Editor 139
The macro runtime will apply these three tests of identity when it tries to match
this macro screen to an application screen.
Note: Although the AME presents the Fields Counts and OIA descriptor as a
single descriptor containing three tests, in fact the macro language defines
these three tests as three separate and independent descriptors. See “Field
Counts and OIA descriptor” on page 141.
The lower area of the Description tab in Figure 66 on page 139 also
displays, for each of these three tests in the Field Counts and OIA
descriptor, a field labeled Optional. You can ignore this field for now. The
Number of Fields and Number of Input Fields descriptors also have a field
labeled Inverse Descriptor. You can ignore this field for now as well. These
fields are described in the section “Default combining method” on page 38.
Creating a new descriptor: Looking again at the Descriptor list box in Figure 66
on page 139, notice that only the first entry is an actual descriptor. The remaining
selections, which are all enclosed in angle brackets and all begin with the word
new, are for creating new descriptors. Following is the list from Figure 66 on page
139:
Figure 67. Contents of the Descriptor list box with one actual descriptor
For example, if you clicked <new string descriptor>, the Macro object would create
a new String descriptor and place it at the start of the list. The lower area of the
Description tab would allow you to fill out the various fields that belong to a
String descriptor (such as a row and column location and a character string). The
Descriptor list box would then look like this:
Figure 68. Contents of the Descriptor list box with two actual descriptors
In Figure 68, the currently selected descriptor is now the String descriptor at the
top of the list (the 3,29 stands for row 3, column 29). The Field Counts and OIA
descriptor is now second on the list.
This should not cause you any trouble in practice, for the following reasons:
v Although the Field Counts and OIA descriptor itself is required, only one of the
three tests that it contains is required. Therefore the actual requirement is that
every <description> element must contain one and only one OIA descriptor.
v The AME enforces these rules and will not let you mistakenly include more than
one Field Counts and OIA descriptor in a Description tab. For example, the
Delete button does not have any effect when you try to delete the Field Counts
and OIA descriptor, and the Descriptor list box does not contain a <new> entry
for the Field Counts and OIA descriptor.
How three separate and independent descriptors are presented as one: The
AME presents the Field Counts and OIA descriptor as one descriptor (see Figure 66
on page 139). However, in fact each of the three parts of the Field Counts and OIA
descriptor on the Description tab corresponds to a separate and independent
descriptor in the underlying XML macro language. Specifically:
v The Number of Fields setting is stored as a <numfields> descriptor.
v The Number of Input Fields setting is stored as a <numinputfields> descriptor.
v The Wait for OIA to Become Uninhibited setting is stored as an <oia>
descriptor.
Table 20 lists these three types of descriptors and shows how many of each can
occur within a <description> element:
Table 20. Three types of <description> element descriptors
Type of descriptor: Number of this type of descriptor allowed
per macro screen (that is, per <description>
element):
<oia> 1 (required)
<numfields> 1 (optional)
<numinputfields> 1 (optional)
As Table 20 shows, only one of each type of these descriptors can occur in a
<description> element. The <oia> descriptor is required, but the <numfields>
descriptor and the <numinputfields> descriptor are optional. The macro editor
enforces these rules.
For example, look at a Field Counts and OIA descriptor first as it appears on the
Description tab of the AME and then in the source view. Figure 66 on page 139
shows a Field Counts and OIA descriptor on the Description tab. The settings of
the three parts of the Field Counts and OIA descriptor are set as follows:
Number of Fields: 80
Number of Input fields: 3
Wait for OIA to Become Uninhibited: true
But if you look at the corresponding <description> element in the source view, you
see the following:
The XML code fragment in Figure 69 shows that the <description> element
contains three separate and independent descriptors, each corresponding to one of
the three parts of the Field Counts and OIA descriptor.
Suppose that you change the Field Counts and OIA descriptor settings to be as
follows:
Number of Fields: (blank)
Number of Input fields: (blank)
Wait for OIA to Become Uninhibited: true
Setting the first two fields to blank tells the AME that these items are not to be
included in the script. If you look again at the corresponding <description>
element in the source view you now see:
<description>
<oia status="NOTINHIBITED" optional="false" invertmatch="false" />
</description>
The XML code fragment above shows that the <description> element now contains
only one descriptor, an <oia> descriptor corresponding to the Wait for OIA to
Become Uninhibited setting in the Field Counts and OIA descriptor.
Treatment during screen recognition: During screen recognition, when the macro
runtime evaluates individual descriptors and combines the boolean results, the
macro runtime treats the <oia> descriptor, the <numfields> descriptor (if it is
present), and the <numinputfields> descriptor (if it is present) each as a separate
and independent descriptor, one like any other descriptor.
The '*' string in a new String descriptor: When you create a new String
descriptor the AME places the string ’*’ into the String input field as an initial,
default value. Just erase this initial string and fill in the string that you want. The
asterisk (*) does not mean anything or have any function. The initial string could
say 'Default string value' and have the same effect.
Actions tab
The Actions tab on the Screens tab of the AME allows you to create and edit
actions. When you create an action in the Actions tab, the AME inserts the new
action into the <actions> element of the currently selected screen. Figure 70 on
page 144 shows a sample Actions tab:
Row Column
String
Password
In Figure 70, the Screens tab of the AME is selected. The name of the currently
selected screen, Screen1, is displayed in the Screen Name field at the top of the
Screens tab. Below the Screen Name field are the General, Description, and
Actions subtabs. The Actions tab is selected.
Like the Description tab, the Actions tab has an upper area and a lower area.
The upper area contains controls that operate on a single action element considered
as a whole. In particular, the Actions list box situated in the upper left corner of
the Actions tab contains the name of the currently selected action. In the figure
above, there is no currently selected action, because no action has been created yet.
The lower area of the Actions tab displays the contents of the currently selected
action, if any. If the currently selected action is an Input action, then the lower area
of the Actions tab presents the contents appropriate to that type of action. If the
user creates or selects another type of action, such as an Extract action, then the
lower area presents the contents appropriate to an Extract action.
Creating a new action: Looking again at the Actions list box in Figure 70, you
should notice that it does not yet contain any actions. The selections, which are all
enclosed in angle brackets and all begin with the word new, are for creating new
actions. As you can see in Figure 70, part of the Actions list box is not tall enough
to show the whole list at once. Following is the entire list:
Figure 71. Contents of the list of an Actions list box with no actions created
For example, if you click <new input action>, the Macro object creates a new
Input action and places it at the top of the list. The lower area of the Actions tab
allows you to fill out the various fields that belong to an Input action (such as the
input key sequence). The new Input item is in the selected area of the Actions list
box, and the list part of the list box then looks like this:
Input action1(0,0)
<new input action>
<new extract action>
<new prompt action>
<new pause action>
<new comm wait action>
<new trace action>
<new mouse click action>
<new variable update action>
<new play macro action>
<new perform action>
<new conditional action>
<new sql query action>
Figure 72. Contents of the list of an Actions list box with one actual action
When the macro runtime processes this macro screen, it performs the actions in the
same order in which they are listed in the Actions list box. To change the order of
the actual actions, click the Change Order button to the right of the Actions list
box.
Links tab
In the AME, the Links tab provides the user interface for storing the names of
candidate macro screens into the <nextscreens> element of a macro screen.
Figure 73 on page 146 shows a sample Links tab:
Timeout 0 milliseconds
Screen1 Screen2
In Figure 73, the Screen Name list box at the top of the tab contains a list of all the
macro screens in the entire macro. The currently selected macro screen is Screen1.
On the right, the Valid Next Screens list box contains a list of candidate macro
screens for Screen1. (Do not confuse this list box, which contains the names in the
<nextscreens> element of Screen1, with the list of valid next screens that the macro
runtime uses when a macro is played back). On the left, the Available Screens list
box contains a list of the names of all other macro screens.
Figure 73 shows only one screen in the Available Screens list because this figure is
from a macro with only two macro screens in it, Screen1 and Screen2. However,
imagine a macro of twenty screens, and suppose that you want to add macro
screens to the <nextscreens> list of a new macro screen, ScreenR. You would follow
these steps:
1. On the Links tab, expand the Screen Name list box and scroll down until you
find ScreenR.
2. Select ScreenR.
3. Because ScreenR is a new screen, there are no macro screen names listed in the
Valid Next Screens list on the right.
4. On the left, the Available Next Screens list box contains the names of all the
macro screens in the macro.
5. Select a screen that you want to add to the list for ScreenR. Suppose that you
select ScreenS.
6. After selecting ScreenS, click the right arrowhead button between the two list
boxes. ScreenS is added to the list box on the right, and removed from the list
box on the left.
7. In the same way, move the names of any other macro screens that you want to
the Valid Next Screens list box for ScreenR.
In the source view, you would see the names of the valid next macro screens,
ScreenS, ScreenG, ScreenY, stored inside ScreenR as shown in Figure 74:
Figure 74 shows the <screen> element for ScreenR, with the name attribute set to
"ScreenR". Inside are the three primary structural elements of a <screen> element:
the <description> element, the <actions> element, and the <nextscreens> element.
The contents of the <description> element and the <actions> element are not
shown but are indicated with ellipses (...). The <nextscreens> element contains
three <nextscreens> elements, and each <nextscreen> element contains the name of
one of the valid next screens: ScreenS, ScreenG, and ScreenY.
For more information about runtime processing see Chapter 4, “How the macro
runtime processes a macro screen,” on page 25.
Variables tab
Because a variable belongs to the entire macro, and not to any one screen, there is
a separate high-level tab for Variables. The Variables tab allows you to:
v Create a variable.
v Remove a variable.
v Import a Java class as a new variable type.
To create a variable belonging to a standard data type, use the Variables tab in the
AME. Figure 75 on page 148 shows a sample Variables tab:
Name $strUserName$
Initial Value
In Figure 75, the Variables tab of the AME is selected. The name of the currently
selected variable, $strUserName$, is displayed in the Variables list box. Three other
fields contain information that the macro runtime needs to create this variable: the
Name input field, the Type list box, and the Initial Value input field.
The Variables list box contains the names of all the variables that have been
created for this macro. It allows you to select a variable to edit or to remove, and it
also contains a <new variable> entry for creating new variables.
Notice that the entry of the currently selected variable is contained in parentheses
after another string:
Variable1($strUserName$)
The string Variable1 is a setting that shows how many variables you have created.
It is not saved in the macro script. The real name of the variable is $strUserName$,
and you should use this name alone throughout the macro wherever you use the
variable.
You have probably noticed that the variable name $strUserName$ is enclosed in
dollar signs ($). This is a requirement. You must enclose the variable name in
dollar signs ($) wherever you use it in the macro.
The Name input field displays the name of the currently selected variable,
$strUserName$. You can change the name of the variable by typing over the old
name. Mostly you should use this field only for assigning a name to a newly
created variable. Although you can come back later at any time and change the
name of this variable (for example to $strUserFirstName$), remember that you
might have already used the variable's old name elsewhere in the macro, in some
action or descriptor. If you change the name here in the Variables tab, then you
148 IBM Host Access Transformation Services: Advanced Macro Guide
must also go back to every place in the macro where you have you used the
variable and change the old variable name to the new variable name.
You can choose any variable name you like, although there are a few restrictions
on the characters you can choose (see “Variable names and type names” on page
90). You do not have to choose names that begin with an abbreviated form of the
data type (such as the str in the string variable $strUserName$), as this book does.
The Type list box lists the available types for variables and lets you select the type
that you want to use for a new variable. The standard types are string, integer,
double, boolean, and field. Also, whenever you import a Java class, such as
java.util.Hashtable, as an imported type, the Type list box picks up this
imported type and adds it to the list of available types, as shown in Figure 76:
string
integer
double
boolean
field
java.util.Hashtable
Figure 76. Contents of the Type list box after an imported type has been declared
You should use this list box for assigning a type to a newly created variable. You
can come back later and change the variable's type to another type, but, as with
variable names, remember that you might have already used the variable
throughout the macro in contexts that require the type that you initially selected. If
so, you must go to each of those places and make sure that the context in which
you are using the variable is appropriate for its new type.
The Initial Value input field allows you to specify an initial value for the variable.
The AME provides the following default values, depending on the type:
Table 22. Default initial values for variables
Type of variable: Default initial value:
string No string
integer 0
double 0.0
boolean false
field (No initial value)
(any imported type) null
To specify a new initial value just type over the default value.
The Import button and the Import popup window are discussed in “Creating an
imported type for a Java class” on page 150.
Note: If you create a string variable, you must enclose the initial value in single
quotes. Otherwise you will see a message stating that the initial value is an
invalid expression.
Now you should set the values that you want for the new variable. For example, if
you are creating an integer variable that is for counting screens and that should
have an initial value of 1, then you might set the initial values as follows:
1. In the Name input field, type the name $intScreenCount$.
2. In the Type list box, select the integer data type.
3. In the Initial Value field, type 1.
Besides the Variables tab, the AME provides access, in several convenient
locations, to a popup window for creating new variables. For example, in the
Variable update action, the Name list box contains not only all the names of
variables that you have already created but also a <New Variable> entry. Click this
entry to bring up the popup window for creating a new variable. Variables created
using this popup window are equivalent to variables created in the Variables tab.
For information about creating a variable in the Source view, see “Creating a
variable” on page 88.
Going back to the Import popup window, the Imported Types list box allows you
to create new types and to edit or delete the types that you have already created.
To create a new type, click the <new imported type> entry at the end of the list. To
edit a type, select the type in the Imported Types list box and modify the values in
the Class and Short Name input fields. To remove a type, select the type and click
Remove.
When you specify a short name, you can use any name, with certain restrictions
(see “Variable names and type names” on page 90).
For information about creating an imported type in the Source view, see “Creating
an imported type for a Java class” on page 89.
The stable states (that is, the ones that usually persist for more than a few seconds)
are:
If you select <Expression> in the Connection Status list box, then you must
specify an expression that resolves to one of the keywords that the macro runtime
expects to find in the value attribute of the <commwait> element (see
“<commwait> element” on page 174). For example, you might specify a variable
named $strCommState$) that resolves to CONNECTION_READY.
For more information, see “Comm wait action (<commwait> element)” on page 56.
Conditional action
Specifying the condition
Specify in the Condition field the conditional expression that you want the macro
runtime to evaluate. The conditional expression can contain logical operators and
conditional operators and can contain terms that include arithmetic expressions,
immediate values, variables, and calls to Java methods (see “Conditional and
logical operators and expressions” on page 19).
The Condition is True tab contains controls that are almost identical to the controls
for the Actions tab. Specifically:
v The Action list box on the Condition is True tab allows you to create and edit
actions in the same way that the Action list box on the Actions tab does.
v The Delete button and the Change Order button on the Condition is True tab
allow you to delete or reorder actions in the same way that the Delete button
and the Change Order button on the Actions tab do.
v The lower area of the Condition is True tab allows you to edit the values of the
currently selected action in the same way that lower area of the Actions tab
does.
Use these controls on the Condition is True tab to create and edit the actions that
you want the macro runtime to perform if the condition is true.
Like the Condition is True tab, the Condition is False tab contains controls that
are almost identical to the controls for the Actions tab. Use these controls on the
Condition is False tab to create and edit the actions that you want the macro
runtime to perform if the condition is false.
For more information see “Conditional action (<if> element and <else> element)”
on page 57.
Extract action
Capturing text
The most common use of the Extract action is to capture text that is being
displayed in the host terminal.
Note: If you extract a value and assign it to a global variable set by an extract, and
you plan to use the global variable value for a prompt, you should set the
promptall attribute to false. When the promptall attribute is set to true, the
extract action is not run before the prompts values are retrieved. Because of
this, the global variable used by the prompt does not contain a value.
Macros recorded in HATS default to promptall=true. For further
information regarding the promptall attribute, see “The promptall attributes”
on page 71.
Set the Continuous Extract option: If you want to capture a rectangular block of
text, then set the Continuous Extract option to false (this is the default value). For
more information, see “Capturing a rectangular area of the host terminal” on page
59.
In contrast, if you want to capture a continuous sequence of text that wraps from
line to line, then set the Continuous Extract option to true. For more information,
see “Capturing a sequence of text from the host terminal” on page 59.
Specify the area of the host terminal: To specify the area of the host screen that
you want to capture, type the row and column coordinates of the text area into the
Row and Column fields on the Extract action window.
The macro runtime interprets the values differently depending on whether the
Continuous Extract option is set to false or true (see “Set the Continuous Extract
option”).
Type the first set of row and column coordinates into the first pair of Row and
Column values (labeled Top Corner on the Extract action window) and type the
second set of coordinates into the second pair of Row and Column values (labeled
Bottom Corner). You can use the text cursor on the host screen as an aid to
determine the coordinates that you want.
In the Row (Bottom Corner) input field you can enter -1 to signify the last row of
the data area on the host screen. This feature is helpful if your users work with
host screens of different heights (such as 25, 43, 50) and you want to capture data
down to the last row. Similarly for the Column (Bottom Corner) input field you
can enter -1 to signify the last column of the data on the host screen (see
“Significance of a negative value for a row or column” on page 22).
Specify TEXT_PLANE as the data plane: In the Data Plane list box click
TEXT_PLANE. This is the default.
Specify the variable in which you want the text to be stored: Set the check box
labeled Assign Text Plane to a Variable and enter the name of the variable into
However, if you specify a variable of some other standard data type (boolean,
integer, double) then the macro runtime converts the string to the format of the
variable, if possible. For example, if the text on the screen is 1024 and the variable
is an integer variable then the macro runtime will convert the string 1024 to the
integer 1024 and store the value in the integer variable. If the format is not valid
for converting the string to the data type of the variable then the macro runtime
terminates the macro with a run time error. For more information about data
conversion see “Automatic data type conversion” on page 20.
Input action
Input string
The String field is an input field in which you specify the key sequence that you
want the action to perform.
To specify a key from the Actions Keys list box, scroll the list to the key you want
(such as [backspace]) and click Insert Action Key. The name of the key enclosed
by square brackets appears at the next input position in the String field. Notice
that the keys in the Action Keys list box are not listed alphabetically throughout.
You might have to keep scrolling down the list to find the key you want.
Another way to specify an action key is just to type the name itself into the input
field, surrounded by square brackets (for example, [backspace]).
The following copy/paste keys occur in the Action Keys list for a 3270 Display
Session:
[copy] [mark right]
[copyappend] [mark up]
[cut] [paste]
[mark down] [pastenext]
[mark left] [unmark]
These keys are not supported by HATS since HATS does not create a Display
Session (Host On-Demand Terminal).
For other keys see “Mnemonic keywords for the Input action” on page 199.
For more information, see “Input action (<input> element)” on page 62.
Pause action
The Pause action waits for a specified number of milliseconds and then terminates.
More specifically, the macro runtime finds the <pause> element, reads the duration
value, and waits for the specified number of milliseconds. Then the macro runtime
goes on to perform the next item.
Type the number of milliseconds in the Duration input field. The default is 10000
milliseconds (10 seconds).
Perform action
The Perform action invokes a method belonging to a Java class that you have
imported (see “Creating an imported type for a Java class” on page 150).
For more information see “Perform action (<perform> element)” on page 67.
Playmacro action
The PlayMacro action launches another macro.
Use the Start Screen Name list box to select the macro screen in the target macro
that you want the macro runtime to process first:
v If you want to start the target macro at its usual start screen, then select the
*DEFAULT* entry in the Start Screen Name list box, or provide an expression
that evaluates to the value *DEFAULT*.
v If you want to start the target macro at some other screen, then select the name
of that screen in the Start Screen Name list box.
For more information, see “PlayMacro action (<playmacro> element)” on page 68.
Prompt action
The Prompt action provides a powerful way to send immediate user keyboard
input into the 3270 or 5250 application or into a variable.
The macro runtime displays a prompt window with the following characteristics:
v The prompt window appears on top of the session window and is located in the
center of the system's desktop window.
v The title of the prompt window is the value of the Prompt Title field unless that
field is blank or there are multiple prompts in the macro and the macro is
configured to show all prompts at the start of the macro. In those two instances,
the title of the prompt window will be "Prompt".
v The message that you typed into the Prompt Name field is displayed in the
center of the prompt window, followed by an input field.
v A button row across the bottom of the prompt window contains three buttons:
– The OK button causes the macro runtime to process the contents of the input
field.
– The Cancel button halts the macro.
– The Help button displays help text explaining how to use the prompt
window.
Default Response: In the Default Response field, which is optional, you can type
the text of a default response that you want to appear in the input field of the
prompt window when the prompt window is displayed. If the user does not type
any keyboard input into the input field of the prompt window, but rather just
clicks OK to indicate that input is complete, then the macro runtime processes the
default response that is contained in the input field.
For example, if the user normally uses ApplicationA but sometimes uses
ApplicationB, you could type ApplicationA into the Default Response field. When
the macro runtime performs the Prompt action, the prompt window appears with
the text ApplicationA already displayed in the input field. The user either can click
OK (in which case the macro processes ApplicationA as the contents of the input
field) or else can type ApplicationB into the input field and then click OK (in
which case the macro processes ApplicationB as the contents of the input field).
Password Response: If you select true in the Password Response list box (the
default is false) then when the user types each key into the input field of the
prompt window, the macro runtime displays an asterisk (*) instead of the character
associated with the key.
For example, with the Password Response list box set to true (or resolving to true
at runtime) then if the user types 'Romeo' the macro runtime displays ***** in the
input field.
Require Response: If you select true in the Require Response list box (the default
is false) then:
v The macro runtime displays the text string (required) to the right of the input
field, to indicate to the end user that input is required for this input field.
v The macro runtime disables the OK button of the prompt window until the
input field of the prompt window contains text.
If the promptall attribute of the <HAScript> element (or of the <actions> element)
is set to true, and you have several prompt actions in the macro (or in the macro
screen) with Require Response set to true, then at the start of macro playback (or
at the start of the playback of the macro screen), when the macro runtime displays
all the prompt input fields in a single prompt window, the macro runtime does not
enable the OK button in the prompt window until all required input fields contain
text (see “The promptall attributes” on page 71 ).
Note: If a prompt value is based on a global variable set by an extract, and the
promptall attribute is set to true, the extract action is not run before the
prompts values are retrieved. Because of this, the global variable used by the
prompt does not contain a value. If you use global variables with extracts
and prompts, you should set the promptall attribute to false. Macros
recorded in HATS default to promptall=true.
Action keys and Translate Host Action Keys: Both you (in the Default Response
input field) and the user (in the input field of the Prompt window) can use action
keys (such as [enterreset], and so on) as you would in the String field of an Input
action (see “Input string” on page 154).
The Translate Host Action Keys list box and its effect are exactly like the Translate
Host Action Keys list box in the Input action (see “Translate host action keys
(xlatehostkeys attribute)” on page 62). If you set this list box to true, which is the
default value, then the macro runtime interprets an action key string (such as
[enter]) as an action key rather than as a literal string.
You can have the macro runtime clear the contents of the input field before typing
begins, by setting the Clear Host Field list box to true.
The Move Cursor to End of Input field has the same function and effects as the
button of the same name in the Input action (see “Move cursor to end of input
(movecursor attribute)” on page 62).
You can have the macro runtime not display the input sequence in the input field
by setting the Don't Write to Screen list box to true. This field is enabled only
when the Assign to a Variable check box is selected.
Create a new variable by clicking the <New Variable> entry in the list box. In the
popup window for specifying a new variable, you can specify the name of a
variable that the current macro inherits from another macro, or you can specify the
name of a new variable that you want to create in the current macro. If you want
to create a new variable in the current macro, select the Create variable in this
macro check box and select the type of the new variable.
The macro runtime stores the input sequence as a string, and consequently you
could specify a string variable as the variable to receive the input. However, if the
variable is of some other type than string, then the macro runtime tries to convert
the input to the data type of the target variable according to the usual rules (see
“Automatic data type conversion” on page 20).
SQLQuery action
The SQLQuery action is a very useful and powerful action that allows you to send
an SQL statement to a host database, retrieve any data resulting from the SQL
statement, and then write the data into a Host On-Demand macro variable.
The statement section occupies the upper area of the window and includes the
following fields: Database URL, Driver Identifier, Driver Class, User ID,
Password, and Statement. You can modify the information in this section in two
ways:
v By creating an SQL statement in the SQL Wizard.
v By typing the information into the fields.
You can also edit any of the fields at any time by typing into the field.
The result section occupies the lower area of the window and includes the
remaining field: Output Result To (the $HMLSQLUtil$ macro variable).
Database URL: In the Database URL field, type the database URL of the database
server that provides access to the database. The format of the database URL
depends on the type of Java Database Connectivity (JDBC) driver that you use to
access the database (for more information on drivers see “Driver Identifier and
Driver Class”).
The remote server can be located on a host other than the host to which the
application session is connected. For example, a SQLQuery action can specify an
IBM i host, even though the same SQLQuery action is part of a macro that is
running in a 3270 Display session connected to a System z® host.
Consult the documentation provided by the driver vendor for the proper format
for the database URL.
Driver Identifier and Driver Class: The JDBC driver that the SQLQuery action
uses to access the database is a Java client package used by the HATS application
to communicate with a server program on a remote host. This server program on
the remote host provides access to the database.
If you need a JDBC driver, contact the administrator of the remote database server
to obtain the driver.
In the Driver Identifier list box of the SQLQuery action window in the macro
editor, select Other.
When you select Other in the Driver Identifier list box, then you must type the
fully qualified class name of the driver into the Driver Class field. If you do not
know the fully qualified class name, contact the provider of the driver. When you
type in the name, remember that case is significant (for example, com is different
from COM).
HATS encrypts the key sequence that you type into the Password field. This
encryption works exactly like the encryption used when the Password check box is
selected in an Input action (see “Encrypted attribute” on page 63). Remember:
v When you type a password (such as mypass) into the Password field, the AME
displays the password using asterisks (******).
v When you move the input focus to another input field, the AME:
1. Generates an encrypted version of the password (such as q0eqOskTUBQ=).
2. Displays the encrypted version of the password in the Password field using
asterisks (************). (You can see the actual characters of the encrypted
version of the password in the AME.)
v The password is a string. Therefore, if you are using the advanced macro format,
remember to type the password enclosed in single quotes (for example,
’mypass’). The AME encrypts the entire string, including the single quotes.
v If you need to modify the password after the AME has encrypted it, be sure to
completely delete all the characters in the field before typing in the new password.
160 IBM Host Access Transformation Services: Advanced Macro Guide
Note: The default values for prompts are stored in macro files unencrypted. The
default values display in the clear when you edit prompts in the macro
editors. Therefore, while using a prompt to specify a password is an
appropriate thing to do, for security reasons you should not specify a
default value for the password.
Statement: Type or paste an SQL statement into the Statement field. If the
Statement field already contains an SQL statement, you can edit it (even if the SQL
statement was created using the SQL Wizard).
The AME does not check the format of the SQL statement for validity. If the format
is invalid, a run time error occurs when the macro runtime processes the
SQLQuery action.
You can spread the SQL statement over several lines or write it all on one line.
Figure 77 and Figure 78 show the same SQL statement written over several lines
and written as one line. Either way is correct.
SELECT
*
FROM
SQLTEST.EX01
WHERE
(
( SQLTEST.EX01.DESCRIPT is not null )
)
Remember that if you are using the advanced macro format you must enclose the
SQL statement in single quotes and follow the rules for special characters. Below,
Figure 79 and Figure 80 show the same SQL statement written for the basic macro
format and for the advanced macro format:
Figure 79. SQL statement written for the basic macro format
Figure 80. Same SQL statement written for the advanced macro format
You can use either upper case or lower case for reserved words (such as select)
and database names and fields (such as hodtest.ex01.descript), but you must use
exact case for matching strings (such as ’Edit Products’). Thus the two SQL
Storing the data into a macro variable ($HMLSQLUtil$): The default destination
for the data resulting from an SQLQuery action is the Host On-Demand macro
variable $HMLSQLUtil$. The Host On-Demand runtime always updates this
variable with the results of a successful SQLQuery action.
To store data into $HMLSQLUtil$, expand the Output Result To list box and click
$HMLSQLUtil$.
To use the data stored in $HMLSQLUtil$ in a subsequent macro action, you must
invoke methods from the Host On-Demand Macro Utility library (HML library)
associated with $HMLSQLUtil$. See “$HMLSQLUtil$” on page 104.
For more information, see “SQLQuery action (<sqlquery> element)” on page 71.
Trace action
The Trace action sends a trace message to a trace destination that you specify, such
as the HATS Toolkit console or the WebSphere console. In addition, HATS adds
macro traces to the HATS runtime trace.
Trace specification
Use the Trace Handler list box to specify the destination to which you want the
trace message sent:
v Select Host On-Demand trace facility to send the trace message to the Host
On-Demand trace facility.
v Select User trace event to send the trace message to a user trace handler.
v Select Command line to send the message to the console.
Use the Trace Text input field to specify the string that you want to send to the
trace destination.
For more information, see “Trace action (<trace> element)” on page 72.
For more information, see “Variable update action (<varupdate> element)” on page
73.
However, customarily the master element is spelled HAScript and the other
elements are spelled with all lower case.
v Each XML element has a begin tag and an end tag, as shown in the examples
below from the Host On-Demand macro language:
<HAScript> ... </HAScript>
<import> ... </import>
<vars> ... </vars>
<screen> ... </screen>
v Optionally you can combine the begin tag and end tag of an XML element into
one tag. This option is useful when the XML element includes attributes but not
other elements. For example,
<oia ... />
<numfields ... />
v An element can contain attributes of the form attribute_name="attribute_value".
For example:
<oia status="NOTINHIBITED" optional="false" invertmatch="false"/>
<numfields number="80" optional="false" invertmatch="false"/>
You can use a pair of empty double quote characters (that is, two double quote
characters with nothing in between) to specify that the attribute is not set to a
value.
<HAScript name="ispf_ex1" description="" timeout="60000" ... author="" ...>
...
</HAScript>
v An element can include other entire elements between its begin tag and end tag,
in much the same way that HTML does. In the following example, a
<description> element contains two elements: an <oia> element and a
<numfields> element.
You can cut and paste text between the source view and the system clipboard. This
is a very important feature because it allows you to transfer text between the
source view and other XML editors or text editors.
Figure 82. Hierarchy of elements in the Host On-Demand macro language supported in
HATS
Comment errors
The source view will display an error message in the following situations:
v Nested comments
v A comment that comments out part of an executable element
Also, you cannot use comment brackets <!-- --> outside the <HAScript> element.
If you do so then the source view will discard those comment brackets and the
surrounded text when you save the script.
Examples of comments
Following are some examples of the use of comment brackets <!-- --> to insert
comments:
<!--
A multi-line comment that comments on
the following <screen> element
-->
<screen name="Screen1" entryscreen="true" exitscreen="false" transient="false">
<vars>
<create name="$var1$" type="string" value="’original’" />
</vars>
.
.
<actions>
<trace type="SYSOUT" value="’Before update: ’+$var1$" />
<varupdate name="$var1$" value="’updated’" />
<trace type="SYSOUT" value="’After update: ’+$var1$" />
</actions>
The code shown in the figure above prints the following text to the console:
Notice that the <trace> action displays each variable in curly braces {} that contain
both the variable name and the contents of the variable.
XML requirements
In the macro language the value of every attribute must be enclosed in double
quotes. For example, in the following <mouseclick> element the values of the row
and col attributes are enclosed in double quotes:
<mouseclick row="4" col="51" />
Similarly, in the macro language, when you provide a string value for an attribute
that corresponds to one of these input fields that is affected by the advanced
format, you must enter the string in the advanced format.
<input value="’3[enter]’" row="0" col="0" movecursor="true"
xlatehostkeys="true" encrypted="false" />
However, if an attribute does not correspond to one of the input fields affected by
the advanced format, then you should not write the value enclosed in single
quotes, even if the macro is in the advanced format. For example, the name
attribute of the <screen> element should never be enclosed in single quotes:
<screen name="Screen1" entryscreen="true" exitscreen="true" transient="false" >
...
</screen>
In the descriptions in this chapter of macro language elements, this book indicates
such attributes (attributes that are unaffected by the advanced format) by not
specifying a data type. For example, the description of the name attribute of the
<screen> element is "Required" rather than as "Required string".
Typed data
Most attributes require a particular type of data: boolean, integer, string, double, or
imported. For these attributes, the same rules apply as in the Macro Editor:
v The consequences of selecting the basic macro format or advanced macro format
(see “Basic and advanced macro format” on page 15).
v The rules for representing strings and special characters, and for treating
operator characters (see “Representation of strings and non-alphanumeric
characters” on page 15).
v The rules for equivalent entities (see “Equivalents” on page 21).
v The rules for data type conversion (see “Automatic data type conversion” on
page 20).
<actions> element
The <actions> element, the <description> element, and <nextscreens> element are
the three primary structural elements that occur inside the <screen> element (see
“Conceptual view of a macro screen” on page 13).
Attributes
promptall
Optional boolean (the default is false). If this attribute is set to true then
the macro runtime, before performing any of the actions inside the
<actions> element, collects user input for any <prompt> elements inside
the element. More specifically:
1. The macro runtime searches the <actions> element to find any
<prompt> elements that occur within it.
2. The macro runtime displays the prompts for all the <prompt> elements
immediately (all the prompts are combined into one popup).
3. The macro runtime collects the user input for all the popup windows.
4. The macro runtime now performs all the elements in the <actions>
element as usual, in sequence.
5. When the macro runtime comes to a <prompt> action, it does not
display the popup window for user input, but instead performs the
<prompt> action using the input from step 3 above.
The promptall attribute of the <HAScript> element performs the same
function for all the <prompt> elements in one macro (see “<HAScript>
element” on page 180).
XML samples
<actions promptall="true">
...
</actions>
Attributes
plane Required. The data plane in which the attribute resides. The valid values
are:
v FIELD_PLANE
v COLOR_PLANE
v DBCS_PLANE
v GRID_PLANE
v EXFIELD_PLANE
v Any expression that evaluates to one of the above.
value Required. A hexadecimal value in the format 0x37. The value of the
attribute.
row Required integer. The row location of the attribute in the data plane.
col Required integer. The column location of the attribute in the data plane.
optional
Optional boolean (the default is false). See “Optional attribute” on page 39.
invertmatch
Optional boolean. See “Invertmatch attribute” on page 38.
XML samples
<comment> element
The <comment> element inserts a text comment as a sub-element within a
<screen> element. Limitations are:
v You cannot use a <comment> element outside a <screen> element.
v You cannot use more than one <comment> element inside the same <screen>
element. If you do so then the source view will discard all the <comment>
elements inside that <screen> element except the last one.
v No matter where in the <screen> element you place the <comment> element,
the source view will move the comment up to be the first element within the
<screen> element.
Attributes
None.
<commwait> element
The <commwait> action waits for the communication status of the session to
change to some specified value (see “Comm wait action (<commwait> element)”
on page 56). You must specify a timeout value.
Attributes
value Required. The communication status to wait for. The value must be one of
the following states:
v CONNECTION_INIT
v CONNECTION_PND_ACTIVE
v CONNECTION_ACTIVE
v CONNECTION_READY
v CONNECTION_DEVICE_NAME_READY
v CONNECTION_WORKSTATION_ID_READY
v CONNECTION_PND_INACTIVE
v CONNECTION_INACTIVE
timeout
Required integer. A timeout value in milliseconds. The macro runtime
terminates the action if the timeout expires before the specified
communication status occurs.
XML samples
Attributes
value Required expression. The conditional expression that the macro runtime is
to evaluate. This conditional expression can contain arithmetic expressions,
variables, return values from Java method calls, and other conditional
expressions.
optional
Optional boolean (the default is false). See “Optional attribute” on page 39.
invertmatch
Optional boolean. See “Invertmatch attribute” on page 38.
XML samples
<description>
<!-- Check the value of a variable -->
<condition value="$intPartsComplete$ == 4"
optional="false" invertmatch="false" />
<create> element
The <create> element creates and initializes a variable (see “Creating a variable” on
page 88).
Attributes
name Required. The name that you assign to the variable. There are a few
restrictions on the spelling of variable names (see “Variable names and
type names” on page 90).
type Required. The type of the variable. The standard types are string, integer,
double, boolean, field. You an also define an imported type representing a
Java class (see “Creating an imported type for a Java class” on page 89).
value Optional. The initial value for the variable. If you do not specify an initial
value then the default initial value depends on the variable type.
<vars>
<create name="$prp$" type="Properties" value="$new Properties()$" />
<create name="$strAccountName$" type="string" value="" />
<create name="$intAmount$" type="integer" value="0" />
<create name="$dblDistance$" type="double" value="0.0" />
<create name="$boolSignedUp$" type="boolean" value="false" />
<create name="$fldFunction$" type="field" />
</vars>
...
</HAScript>
<cursor> element
The <cursor> element is a descriptor that states the row and column location of the
text cursor on the host terminal (see “Cursor descriptor (<cursor> element)” on
page 45).
Attributes
row Required integer. The row location of the text cursor.
col Required integer. The column location of the text cursor.
optional
Optional boolean (the default is false). See “Optional attribute” on page 39.
invertmatch
Optional boolean. See “Invertmatch attribute” on page 38.
XML samples
<custom> element
The <custom> element allows you to invoke a custom Java program from inside
the <actions> element of a macro screen.
Attributes
id Required. An arbitrary string that identifies the custom Java program that
you want to run.
args Optional. The arguments that you want to pass to the custom Java
program.
XML samples
<customreco> element
This <customreco> element allows you to call custom description code.
The macro runtime performs the <customreco> element after performing all the
other descriptors.
Attributes
id Required string. The identifier that you have assigned to this custom
description.
optional
Optional boolean (the default is false). See “Optional attribute” on page 39.
invertmatch
Optional boolean. See “Invertmatch attribute” on page 38.
XML samples
<description> element
The <actions> element, the <description> element, and the <nextscreens> element
are the three primary structural elements that can occur inside the <screen>
element (see “Conceptual view of a macro screen” on page 13).
Attributes
uselogic
Optional boolean. Allows you to define more complex logical relations
among multiple descriptors than are available with the default combining
method (see “The uselogic attribute” on page 39).
XML samples
<description uselogic="true">
...
</actions>
<else> element
The <else> element contains a sequence of macro actions and must occur
immediately after an <if> element. The macro runtime evaluates the conditional
expression in the <if> element. Then:
v If the conditional expression is true:
– The macro runtime performs the sequence of macro actions in the <if>
element; and
– The macro runtime skips the following <else> element if there is one.
v If the conditional expression is false:
– The macro runtime skips the sequence of macro actions in the <if> element;
and
– The macro runtime performs the macro actions in the following <else>
element if there is one.
The Macro object uses the <if> element, and if necessary the <else> element, to
store a Conditional action (see “Conditional action (<if> element and <else>
element)” on page 57).
XML samples
<extract> element
The <extract> element captures data from the host terminal (see “Extract action
(<extract> element)” on page 58).
Attributes
For more information on the use of all these attributes see “Extract action
(<extract> element)” on page 58.
name Required string. A name to be assigned to the extracted data.
planetype
Required. The plane from which the data is to be extracted. Valid values
are:
v TEXT_PLANE
v FIELD_PLANE
v COLOR_PLANE
v EXFIELD_PLANE
v DBCS_PLANE
v GRID_PLANE
srow Required integer. The row of the first pair of row and column coordinates.
scol Required integer. The column of the first pair of row and column
coordinates.
erow Required integer. The row of the second pair of row and column
coordinates.
scol Required integer. The column of the second pair of row and column
coordinates.
unwrap
Optional boolean. Setting this attribute to true causes the macro runtime to
capture the entire contents of any field that begins inside the specified
rectangle. See “Unwrap attribute” on page 60.
continuous
Optional boolean. Setting this attribute to true causes the macro runtime to
interpret the row-column coordinates as the beginning and ending
locations of a continuous sequence of data that wraps from line to line if
necessary. If this attribute is set to false then the macro runtime interprets
XML samples
<HAScript> element
The <HAScript> element is the master element of a macro script. It contains the
other elements and specifies global information about the macro (see “Conceptual
view of a macro script” on page 10).
Attributes
name Required. The name of the macro.
description
Optional. Descriptive text about this macro. You should include here any
information that you want to remember about this macro.
timeout
Optional integer. The number of milliseconds allowed for screen
recognition. If this timeout value is specified and it is exceeded, then the
macro runtime terminates the macro and displays a message (see “Timeout
attribute on the <HAScript> element” on page 52). By default the Macro
Editor sets this value to 60000 milliseconds (60 seconds).
pausetime
Optional integer. The delay for the "pause between actions" (see “The
pausetime attribute” on page 81). By default the Macro Editor sets this
value to 300 milliseconds.
promptall
Required boolean. If this attribute is set to true then the macro runtime,
before performing any action in the first macro screen, collects user input
for all the <prompt> elements inside the entire macro, combining the
individual prompts into one large prompt. The promptall attribute of the
<actions> element performs a similar function for all the <prompt>
elements in one <actions> element (see “<actions> element” on page 172).
XML samples
The Macro object uses the <if> element, and if necessary the <else> element, to
store a Conditional action (see “Conditional action (<if> element and <else>
element)” on page 57).
Attributes
condition
Required. A conditional expression. The conditional expression can contain
logical operators and conditional operators and can contain terms that
include arithmetic expressions, immediate values, variables, and calls to
Java methods (see “Conditional and logical operators and expressions” on
page 19).
XML samples
<if condition=
"(($condition1$ !=’’)&&
($condition2$)||($condition3$ < 100))">
...
</if>
<else>
...
</else>
</actions>
</screen>
<import> element
The <import> element, the <vars> element, and the <screen> element are the three
primary structural elements that occur inside the <HAScript> element (see
“Conceptual view of a macro script” on page 10).
The <import> element must occur after the <HAScript> begin tag and before the
<vars> element.
Attributes
None.
XML samples
<vars>
<create name="$prp$" type="Properties" value="$new Properties()$" />
</vars>
...
</HAScript>
<input> element
The <input> element sends a sequence of keystrokes to the host terminal. The
sequence can include keys that display a character (such as a, b, c, #, &, and so on)
and also action keys (such as [enterreset], [copy], [paste], and others) (see “Input
action (<input> element)” on page 62).
Attributes
value Required string. The sequence of keys to be sent to the host terminal.
row Optional integer (default is the current position of the text cursor). Row at
which typing begins.
col Optional integer (default is the current position of the text cursor). Column
at which typing begins.
movecursor
Optional boolean (default is true). Setting this attribute to true causes the
macro runtime to move the text cursor to the end of the input (see “Move
cursor to end of input (movecursor attribute)” on page 62).
xlatehostkeys
Optional boolean (default is true). Setting this attribute to true causes the
macro runtime to interpret the name of an action key (such as [enter]) as
an action key rather than as a character sequence (see “Translate host
action keys (xlatehostkeys attribute)” on page 62).
encrypted
Optional boolean (default is false). Setting this attribute to true causes the
Macro Editor to encrypt the sequence of keys contained in the value
attribute when the Macro Editor is closed (see “Encrypted attribute” on
page 63).
XML samples
Attributes
row Required integer. The row of the row and column location on the host
terminal where the mouse click occurs.
col Required integer. The column of the row and column location on the host
terminal where the mouse click occurs.
XML samples
<nextscreen> element
The <nextscreen> element specifies the name of a <screen> element (macro screen)
that the macro runtime should consider, among others, as a candidate to be the
next macro screen to be processed (see “Recognizing valid next screens” on page
49).
Attributes
name Required. The name of the <screen> element that is a candidate to be the
next macro screen to be processed.
XML samples
<!--
The effect of the following <nextscreens> element and its contents
is that when the macro runtime finishes performing the actions in
the current screen, it adds ScreenS and ScreenG to the runtime list of
valid next screens.
-->
<nextscreens>
<nextscreen name="ScreenS">
<nextscreen name="ScreenG">
</nextscreens>
<nextscreens> element
The <actions> element, the <description> element, and the <nextscreens> element
are the three primary structural elements that occur inside the <screen> element
(see “Conceptual view of a macro screen” on page 13).
Attributes
timeout
Optional integer. The value in milliseconds of the screen recognition
timeout. The macro runtime terminates the macro if it cannot match a
macro screen whose name is on the runtime list of valid next screens to the
application screen before this timeout expires (see “Timeout settings for
screen recognition” on page 51).
XML samples
<!--
The effect of the following <nextscreens> element and its contents
is that when the macro runtime finishes performing the actions in
the current screen, it will attempt to recognize ScreenS and ScreenG.
-->
<nextscreens>
<nextscreen name="ScreenS">
<nextscreen name="ScreenG">
</nextscreens>
<numfields> element
The <numfields> element is a descriptor that states the number of 3270 or 5250
fields of all types that exist in the host terminal (see “Number of Fields descriptor
(<numfields> element)” on page 41).
Attributes
number
Required integer. The number of fields in the host terminal.
optional
Optional boolean (the default is false). See “Optional attribute” on page 39.
invertmatch
Optional boolean (the default is false). See “Invertmatch attribute” on page
38.
XML samples
Attributes
number
Required integer. The number of fields in the host terminal.
optional
Optional boolean (the default is false). See “Optional attribute” on page 39.
invertmatch
Optional boolean (the default is false). See “Invertmatch attribute” on page
38.
XML samples
<oia> element
The <oia> element is a descriptor that describes the state of the input inhibited
indicator in the host terminal (see “OIA descriptor (<oia> element)” on page 41).
Attributes
status Required. The value can be:
v NOTINHIBITED
The macro runtime evaluates the descriptor as true if the input inhibited
indicator is cleared, or false if the input inhibited indicator is set.
v DONTCARE
The macro runtime always evaluates the descriptor as true.
v An expression that evaluates to either NOTINHIBITED or DONTCARE
The macro runtime evaluates the expression and then, depending on the
result, evaluates the descriptor as usual.
optional
Optional boolean (the default is false). See “Optional attribute” on page 39.
invertmatch
Optional boolean. See “Invertmatch attribute” on page 38.
XML samples
Attributes
value Optional integer. The number of milliseconds to wait. If you do not specify
this attribute then the Macro object will add the attribute "value=10000" (10
seconds) to the element when it saves the script.
ignorepauseoverride
Optional boolean (the default is false). For 3270 Display sessions only.
Setting this attribute to true causes the macro runtime to process the
<pause> element even if the ignorepauseforenhancedtn attribute of the
<HAScript> element is set to true (see “Attributes that deal with screen
completion” on page 84).
XML samples
<pause timeout="5000">
<perform> element
The <perform> element invokes a method belonging to a Java class that you have
imported (see “Creating an imported type for a Java class” on page 89).
You can invoke a method in many other contexts besides the <perform> element.
However, the <perform> element is useful when you want to invoke a method that
does not return a value (see “Perform action (<perform> element)” on page 67).
Attributes
value Required. You must enclose a method call in dollar signs ($), just as you
would a variable (see “Syntax of a method call” on page 94). You should
specify the parameters, if any, of the method call in the same format that
you would use if you were creating a Perform action in the Macro Editor.
XML samples
<!-- Call the update() method associated with the class to which
importedVar belongs (such as mypackage.MyClass).
-->
<perform value="$importedVar.update( 5, ’Application’, $str$)$" />
There are restrictions on where in the <actions> element you can place a
<playmacro> element (see “Adding a PlayMacro action” on page 68).
Attributes
name Required. The name of the target macro. The target macro must reside in
the same location as the calling macro.
startscreen
Optional. The name of the macro screen (<screen> element) at which you
want the macro runtime to start processing the target macro. Use the value
*DEFAULT* or omit this parameter to have the macro runtime start at the
usual starting screen of the target macro.
transfervars
Required. Setting this attribute to Transfer causes the macro runtime to
transfer the variables belonging to the calling macro to the target macro
(see “Transferring variables” on page 69). The default is No Transfer.
XML samples
<prompt> element
The <prompt> element displays a popup window prompting the user for input,
waits for the user to click OK, and then sends the input to the host terminal (see
“Prompt action (<prompt> element)” on page 70).
Attributes
name Optional string. The text that is to be displayed in the popup window,
such as ’Enter your response here:’.
description
Optional string. A description of this action. This description is not
displayed.
row Required integer. The row on the host terminal at which you want the
macro runtime to start typing the input from the user.
col Required integer. The column on the host terminal at which you want the
macro runtime to start typing the input from the user.
len Required integer. The number of characters that the user is allowed to
enter into the prompt input field.
default
Optional string. The text to be displayed in the input field of the popup
XML samples
<recolimit> element
The <recolimit> element is an optional element that occurs within a <screen>
element, at the same level as the <description>, <actions>, and <nextscreens>
elements (see “Recognition limit” on page 53).
Attributes
value Required integer. The recognition limit. If the macro runtime recognizes the
macro screen this many times, then the macro runtime does not process the
actions of this macro screen but instead performs the specified action.
goto Optional string (the default is for the macro runtime to display an error
message and terminate the macro). The name of a macro screen that you
want the macro runtime to start processing when the recognition limit is
reached.
XML samples
<screen> element
The <screen> element, the <import> element, and the <vars> element are the three
primary structural elements that occur inside the <HAScript> element (see
“Conceptual view of a macro script” on page 10).
Multiple screen elements can occur inside a macro. One <screen> element contains
all the information for one macro screen (see “The macro screen and its
subcomponents” on page 11).
The <screen> element contains three primary structural elements: the <actions>
element, the <description> element, and <nextscreens> (see “Conceptual view of a
macro screen” on page 13).
Attributes
name Required. The name of this <screen> element (macro screen). The name
must not be the same as the name of an already existing <screen> element.
entryscreen
Optional boolean (the default is false). Setting this attribute to true causes
the macro runtime to treat this <screen> element as a valid beginning
screen for the macro (see “Entry screens” on page 49).
exitscreen
Optional boolean (the default is false). Setting this attribute to true causes
the macro runtime to treat this <screen> element as a valid ending screen
for the macro (see “Exit screens” on page 50).
transient
Optional boolean (the default is false). Setting this attribute to true causes
the macro runtime to treat this <screen> element as a screen that can
appear at any time and that always needs to be cleared (see “Transient
screens” on page 50).
pause Optional integer (the default is -1). Specifying a value in milliseconds for
XML samples
<sqlquery> element
The <sqlquery> element sends an SQL statement to a database, retrieves the data
resulting from the SQL statement, if any, and then stores the data into a macro
variable (see “SQLQuery action (<sqlquery> element)” on page 71).
Attributes
url Required string. The database URL for the database server to which the
SQL statement is sent, such as jdbc:as400://myHost.
driver Required string. The fully qualified package name of the driver used to
connect with the database server, such as COM.ibm.db2.jdbc.app.DB2DRIVER.
This package must be present on the client workstation.
userid Optional string. The user ID required to access the database, if one is
required.
password
Optional string. The password required to access the database, if one is
required.
statement
Required string. The SQL statement.
outputtype
Required integer. The destination where the data resulting from the SQL
statement is to be directed. The valid value is: 0 - The data is stored in the
macro variable $HMLSQLUtil$. You can retrieve the data by calling
methods on the variable.
XML samples
<string> element
The <string> element is a descriptor that specifies a sequence of characters and a
rectangular area of the host terminal in which the sequence occurs (see “String
descriptor (<string> element)” on page 42).
Attributes
value Required string. The sequence of characters.
row Optional integer (the default is to search the entire screen). The row
location of one corner of a rectangular block of text.
col Optional integer. The column location of one corner of a rectangular block
of text.
erow Optional integer. The row location of the opposite corner of a rectangular
block of text.
ecol Optional integer. The column location of the opposite corner of a
rectangular block of text.
casesense
Optional boolean (the default is false). Setting this attribute to true causes
the macro runtime to do a case-sensitive string compare.
wrap Optional boolean (the default is false).
v Setting this attribute to false causes the macro runtime to search for the
sequence of characters in each separate row of the rectangular block of
text. If the sequence of characters wraps from one row to the next, the
macro runtime will not find it.
v Setting this attribute to true causes the macro runtime to check for the
sequence of characters occurring in any row or wrapping from one row
to the next of the rectangular block of text (see “How the macro runtime
searches the rectangular area (Wrap attribute)” on page 43).
optional
Optional boolean (the default is false). See “Optional attribute” on page 39.
invertmatch
Optional boolean. See “Invertmatch attribute” on page 38.
XML samples
<!-- The string can occur in any single row of the session area -->
<string value="’Utility Selection Panel’" row="1" col="1"
erow="-1" ecol="-1" casesense="false" wrap="false"
optional="false" invertmatch="false" />
<trace> element
The <trace> element sends a trace message to a trace destination that you specify,
such as a console (see “Trace action (<trace> element)” on page 72).
Attributes
type Required. The destination for the trace data. The destination must be one
of the following:
v HODTRACE: The Host On-Demand Trace Facility.
v USER: A user trace handler.
v SYSOUT: The WebSphere console.
value Required string. The string that is to be sent to the trace destination.
XML samples
<type> element
The <type> element declares an imported type (such as Properties) that represents
a Java class (such as java.util.Properties). After you have declared the type, you
can create variables based on the type, create an instance of the Java class, and call
methods on the instance (see “Creating an imported type for a Java class” on page
89).
A type can also be used for directly calling static methods (no need to instantiate).
Attributes
class Required. The fully qualified class name of the class being imported,
including the package name if any (such as java.util.Properties).
name Optional. A short name (such as Properties) that you can use elsewhere in
the macro to refer to the imported type. If you do not specify a short
XML samples
<import>
<type class="java.util.Date" name="Date"/>
<type class="java.io.FileInputStream"/>
<type class="com.ibm.eNetwork.beans.HOD.HODBean" name="HODBean"/>
<type class="myPackage.MyClass" name="MyClass"/>
</import>
<vars> element
The <vars> element, the <import> element, and the <screen> element are the three
primary structural elements that occur inside the <HAScript> element (see
“Conceptual view of a macro script” on page 10).
To use variables, you must set the usevars element in <HAScript> to true.
Attributes
None.
XML samples
<vars>
<create name="$prp$" type="Properties" value="$new Properties()$" />
<create name="$strAccountName$" type="string" value="" />
<create name="$intAmount$" type="integer" value="0" />
<create name="$dblDistance$" type="double" value="0.0" />
<create name="$boolSignedUp$" type="boolean" value="false" />
<create name="$fldFunction$" type="field" />
</vars>
...
</HAScript>
You can also use the <varupdate> action in a <description> element (see “Variable
update action (<varupdate> element)” on page 73).
For more information on variables see Chapter 9, “Variables and imported Java
classes,” on page 87.
Attributes
name Required. The name of the variable.
value Required string. The value or expression to be assigned to the variable.
XML samples
<vars>
...
</vars>
<screen>
<description>
...
</description>
<actions>
<varupdate name="$var_boolean1$" value="false" />
<varupdate name="$var_int1$" value="5" />
<varupdate name="$var_double1$" value="5" />
<varupdate name="$var_string1$" value="’oak tree’" />
<varupdate name="$var_field1$" value="4,5" />
<varupdate name="$var_importedMC4$"
value="$new MyClass( ’myparam1’, ’myparam2’ )$" />
<varupdate name="$var_importedMC5$"
value="$var_importedMC4$" />
<varupdate name="$var_importedMC6$"
value="$MyClass.createInstance( ’mystringparam1’ )$" />
<varupdate name="$var_boolean2$"
value="$var_importedMC4.isEmpty()$" />
<varupdate name="$var_int2$"
value="$($var_importedMC4.getHashtable()$).size()$" />
<varupdate name="$var_double2$"
value="$var_importedMC4.getMeters()$" />
<varupdate name="$var_string2$"
value="$var_importedMC4.toString()" />
</actions>
</screen>
The following table shows the bidirectional keywords for the Input action.
Table 25. Bidirectional keywords for the Input action
Function: Keyword: 3270: 5250: VT:
Auto Push [autopush] x
Auto Reverse [autorev] x x
Base [base] x x
BIDI Layer [bidilayer]
Close [close] x
CSD [csd] x
End Push [endpush] x
Field Reverse [fldrev] x x
Field Shape [fieldshape] x
Final [final] x
Initial [initial] x
Isolated [isolated] x
Latin Layer [latinlayer] x x
Middle [middle] x
Push [push] x
Screen Reverse [screenrev] x x
IBM might have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not give you
any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
For license inquiries regarding double-byte (DBCS) information, contact the IBM
Intellectual Property Department in your country or send inquiries, in writing, to:
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan, Ltd.
19-21, Nihonbashi-Hakozakicho, Chuo-ku
Tokyo 103-8510, Japan
The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions, therefore, this statement might not apply
to you.
Any references in this information to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this IBM
product and use of those Web sites is at your own risk.
IBM might use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.
The licensed program described in this information and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement, or any equivalent agreement
between us.
This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
If you are viewing this information softcopy, the photographs and color
illustrations might not appear.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Oracle and/or its affiliates.
Printed in USA
SC27-5450-03