There
are three components to the overall efficiency of the part of your application
that the end user sees: processor path length, communications line utilization,
and user time. Path length and line time used to be paramount, and much design
and programming effort has been invested in minimizing them.
As online systems have evolved, however, the emphasis has shifted steadily
to making things as easy, pleasant and quick for the user as possible, at
the expense of the other factors if necessary. Also, as processors have become
cheaper, designers have been willing to expend cycles to reduce programming
and maintenance effort as well as to make the user interface better.
We have already given you references on elements of good design for the
user interface, in Personal computers, and usually these should be your
overriding considerations. In this section, we point out some ways that you
can reduce path length and line time as well. You need to judge for yourself
whether and to what extent the savings justify extra programming effort or
a less general design.
Ordinarily, the number of instructions
executed in a single CICS® command is large in comparison to the number of
instructions in the application program that invoked it. Consequently, the
path length for a given task ordinarily depends more on the number and type
of CICS commands than on anything else, and commands are the most fertile
area for tuning. Commands vary by type, of course, and path length for any
given command may vary considerably with circumstances.
For BMS, some recommendations are:
- Build screens (pages) with a single command when practical. Avoid building
a composite screen with the ACCUM feature when a modest amount of additional
programming accomplishes the same function, and avoid building a composite
screen by multiple physical writes, as described in Outside the map,
except in unusual circumstances.
- Avoid producing more output at one time than the user is likely to inspect.
Some transactions--inquiries, especially--produce many pages of
output for certain input values. When this happens, the user usually narrows
the search and repeats the inquiry, rather than page through the initial output.
To avoid the path length of producing output that is never viewed, you can
limit it to some reasonable number of pages, inform the user on the last page
that there is more, and save the information required to restart the search
from that point if the user requests it. The extra programming is minimal;
see Sharing data across transactions for ways to save the restart data.
- Use commands that are on the BMS "fast path" if possible. (See Minimum BMS for the commands and terminal types that qualify.)
- Use terminal control commands for very simple inputs an outputs, where
you do not need BMS formatting or other function. If path length is critical,
you may want to use terminal control entirely. However, the advantages of
BMS over terminal control in terms of flexibility, initial programming effort
and maintainability are significant, and usually outweigh the path length
penalty.
You can take advantage of
3270 hardware to reduce the length of both inbound and outbound messages.
If the bandwidth in any link between the terminal and the processor is constrained,
you get better response overall with shorter messages. However, the time for
any given transmission depends on the behavior of other users of those links
at the time, and so you may not see improvement directly. Here are some of
the possibilities for reducing the length of a 3270 datastream:
- Avoid turning on MDTs unnecessarily when you send a screen, because they
cause the associated input fields to be transmitted on input. Ordinarily,
you do not need to set the tag on, because the hardware does this when the
user enters input into the field. The tag remains on, no matter how many times
the screen is transmitted, until explicitly turned off by program (by FRSET,
ERASEAUP, or ERASE, or by an override attribute byte with the tag off). The
only time you need to set it on by program is when you want to store data
on the screen in a field that the user does not modify, or when you highlight
a field in error and you want the field returned whether or not the user changes
it. In this case you need to turn on the MDT as well as the highlighting.
- Use FRSET to reset the MDTs when you do not want input on a screen retransmitted
(that is, when you have saved it and the user does not need to change it on
a subsequent transmission of the same screen). (See Saving the good input
for more.)
- Do not initialize input fields to blanks when you send the screen because,
on input, blanks are transmitted and nulls are not. Hence the data stream
is shortened by the unused positions in each modified field if you initialize
with nulls. The appearance on the screen is the same, and the data returned
to the program is also the same, if you map the input.
- For single-screen data entry operations, use ERASEAUP to clear data from
the screen, rather than resending the screen.
- If you are updating a screen, send only the changed fields, especially
if the changes are modest, as when you highlight fields in error or add a
message to the screen. In BMS, you can use the DATAONLY option, both to shorten
the data stream and reduce the path length (see DATAONLY option). To
highlight a field, in fact, you send only the new attribute byte; the field
data remains undisturbed on the screen.
- If you are using terminal control commands, format with set buffer address
(SBA) and repeat-to-address (RA) orders, rather than spacing with blanks and
nulls. (BMS does this for you.)
[[ Contents Previous Page | Next Page Index ]]