Pathmaker Programming Guide
Designing a Pathmaker Application
Preparing for Pathmaker Application Development
067868 Tandem Computers Incorporated 2–9
Designing Requesters A requester is an application module under control of a Pathway terminal control
process (TCP) that interacts with a user. The requester translates the user’s input into
requests for action by a service. Each requester contains the presentation logic for a
single logical screen (which can contain several pages). Requesters define terminal
context associated with the logical screen, communicate with services, and contain
navigation logic.
The description of the requesters for an application should include:
A chart of the application screen hierarchy
Requester type
Type of terminal where the application will be run (6520, 6530, 3270, or terminals
that accept Kanji characters)
A picture of the screen layout, including function keys and the name of the service
or requester a function key accesses
The name of a master requester to copy (if applicable)
The name of modified requester skeleton to use (if applicable)
Planning the Screens and Screen Hierarchy
As you plan the screens for a Pathmaker application, you should decide what function
or functions each screen will have and how end users will navigate among them. The
Pathmaker full screen interface, for example, has screens dedicated to navigation, to
updating the database, and to listing items in the database. The Pathmaker full screen
interface is illustrated in a diagram in Appendix A of this manual.
Drawing a screen hierarchy diagram can help you plan the flow of the user interface
and maintain consistency when you assign function keys for navigation. In addition,
planning the order of presentation and the function of each screen helps you decide
which services are required for each requester.
An efficient way to design consistent requesters is to design one requester and assign
standard function key actions to it. Then application developers can use the COPY
feature (Copy Requester screen) for all other requesters in the application.
In general, an application’s function keys should operate like Pathmaker function
keys; that is, a function key should perform one action each time it is pressed. Actions
that are used in many screens should have a specific function key dedicated to that
use. For example, in Pathmaker, F2 is the Update function key for every screen that
can be updated. Standardizing function keys will help end users in understanding
how to use the interface.