Compaq TP Desktop Connector
for ACMS
Client Application Programming Guide


Previous Contents Index

2.2.1.3 Choosing Between I/O and NO I/O Tasks

TP Desktop Connector software allows you to call I/O tasks (FORM I/O and REQUEST I/O) and NO I/O tasks (NO TERMINAL I/O) from a desktop client program. Choosing between I/O and NO I/O tasks is a choice of where to place control of the application flow. With I/O tasks, the task controls the application flow. With NO I/O tasks, the client program controls the application flow.

If the application supports only desktop systems or you are optimizing the ACMS application for desktop access, consider using only NO I/O tasks.

NO I/O tasks fit better with event-driven desktop systems, such as Microsoft Windows and Macintosh systems. With these systems, the desktop client program rather than the ACMS application controls the major processing flow.

NO I/O tasks also allow the greatest freedom in handling the logic in the desktop client program. However, task invocation can be more expensive than invoking processing steps within a task. Each task invocation requires workspace management by the ACMS Application Execution Controller (EXC), which is considerably more expensive in processor time than the workspace management done for exchange steps. Also, the ACMS system requires processor time to set up control structures when the task starts and to clear the structures when the task ends.

The additional central processor usage for task invocation compared to processing step invocation is generally small. However, the extra overhead for task invocation can be a significant factor in a system with high throughput requirements.

2.2.2 Application Design Approaches

Two approaches to a ACMS solution are the following:

2.2.2.1 Common ACMS Applications

TP Desktop Connector software allows you to structure a common ACMS application to be accessed from both desktop systems and VT terminals. The task definitions, workspace definitions, task group definition, and application definition can be the same.

If users at both VT terminals and desktop systems in your enterprise need to run the same tasks, it is best to have a common ACMS application. This minimizes your development and maintenance work. If you use a presentation tool that is portable between OpenVMS and the desktop system, possibly no additional code is required to support the presentation software on both platforms.

To use NO I/O tasks in an environment that has both desktop systems and VT devices, you can take advantage of the task-call-task feature of ACMS. Divide common processing steps into standalone NO I/O tasks. The desktop client program calls these NO I/O tasks directly. The VT-terminal users request I/O tasks that include exchange steps. These I/O tasks then use the task-call-task feature of ACMS to invoke the common NO I/O tasks as part of their processing steps. Any task error recovery within the common NO I/O tasks is shared by both presentation device types.

Maintenance increases slightly in this environment, because flow control is duplicated in the tasks called by the VT-terminal users and within the desktop client program.

2.2.2.2 Tailored ACMS Applications

If your TP Desktop Connector solution does not include VT terminals, you can tailor the ACMS application and design the tasks somewhat differently from a common application. Use one of the following alternatives:

These design approaches can also be applied to solutions that include both VT terminals and desktop systems. For example, to decrease network traffic, use a queued task model for the desktop systems and retain an interactive model for your VT terminals.

TP Desktop Connector software does not preclude optimizing the ACMS application for desktop systems and retaining a separate but comparable application for VT terminals. You can optimize the ACMS application by building separate desktop tasks within the same application definition or by building alternatives into the task definitions. However, carefully consider the additional maintenance cost required for such a solution.

2.2.2.3 Conversion of a Task: I/O to NO I/O

If you have I/O tasks and want to incorporate a desktop design in the application that does not depend on terminal interaction, you can convert the I/O tasks to NO I/O tasks. Converting an I/O task to a NO I/O task involves the following steps:

  1. Delete the exchange steps.
  2. Separate the processing steps into individual tasks.
  3. Modify the action clause for each processing step to eliminate references to exchange steps.
  4. Add a TASK ARGUMENTS clause for any workspaces used by a NO I/O task.
  5. Add the NO I/O tasks to the task group definition.

Task conversion can be done without affecting anything else in the application. Section 8.6.3 contains an example of task conversion for the Macintosh sample.

2.2.3 Preventing Loss of Work with Local Data Capture

In some applications, desktop systems are most effective as relatively independent data capture resources. Users work with reference data stored locally on their personal computer, building up a queue of completed transactions awaiting their forwarding to a ACMS system. The desktop system signs in to the ACMS system and uploads the transactions from the desktop system to the ACMS system.

TP Desktop Connector software can effectively support the data capture model for desktop systems. Figure 2-1 shows how such a queue-based system can work.

Figure 2-1 Using a Queued Task with TP Desktop Connector


The TP Desktop Connector software does not directly provide queuing facilities, for example, services for data capture. The desktop client program can create and manage a file of transactions to be transmitted to the ACMS system. It also can determine when to establish the connection, such as at regular intervals, or when the queue reaches a predefined threshold. The desktop client program can then use the TP Desktop Connector client services to invoke tasks in a ACMS application that either process the queued items directly or run other tasks to move the items into ACMS queues on the ACMS system.

The TP Desktop Connector client services do not guarantee that an item queued on the desktop system is processed only once. If this guarantee is required, the application must supply a capability, such as having the receiver application check a queue item identifier for duplicates before storing a transaction.

2.2.4 Event-Driven Systems and the Nonblocking Environment

In event-driven systems like OSF/Motif and Microsoft Windows, a program is structured to include an event-dispatching mechanism (event dispatcher) and a collection of procedures that this dispatching mechanism invokes as the result of an event. Ideally, these procedures quickly return control to the event dispatcher so that other events are dispatched (or processed) without delay. If these procedures fail to return control quickly, slow and undesirable behavior in programs can result. This characteristic is especially true for Windows programs. When a procedure hangs in any given Windows program, the system cannot give control to another Windows program.

By providing nonblocking services, TP Desktop Connector software allows a desktop client program to release control to the event dispatcher (in Microsoft Windows, the message dispatching loop) without waiting for the ACMS system to respond. This nonblocking characteristic is particularly important when the network delays a response or the ACMS system performs extensive processing.

Because the release of control to the event dispatcher is so critical in event-driven systems (for getting user input, and so on), TP Desktop Connector supports nonblocking presentation procedures as well as the basic nonblocking client services.

For a description of forced nonblocking, see Chapter 7.

2.2.5 Nonblocking Design Considerations

Consider the following when designing your desktop client program for a nonblocking program and runtime environment:

The AVERTZ sample applications for Motif and Microsoft Windows use a procedure to activate timer events so that pending TP Desktop Connector Gateway for ACMS messages can be processed. To process a timer event, the timer-event handler calls the TP Desktop Connector service acmsdi_dispatch_message to poll for and dispatch messages from the gateway.

2.2.6 TP Desktop Connector Gateway for ACMS Availability

Similar to distributed ACMS configurations for VT-terminal users, a desktop system can connect a desktop client program to multiple submitter nodes that in turn invoke applications on application nodes. This can be achieved by using multiple copies of the desktop client program or a single copy initiating multiple ACMS sign-ins.

As discussed in Chapter 1, if the application node fails in a distributed configuration, the user can automatically be routed to another ACMS system on the next task selection. Having a submitter node responsible for sign-in distinct from a ACMS system that actually processes the application requests can provide a high degree of availability without any extra work in the desktop client program. For example, in Figure 2-2, if the application Node A fails, the TP Desktop Connector Gateway for ACMS can automatically reroute subsequent requests to Node B.

Figure 2-2 Application Node Failover Configuration


If the submitter node to which desktop users are currently attached fails, the TP Desktop Connector client services do not automatically route signed-in users to a new submitter node. This is true even if the user is connected to one of several nodes in a VAXcluster or VMScluster system. Because authentication of the user is performed on the submitter node, a failure of the submitter node invalidates the authentication of the user.

A desktop client program can provide failover for submitter nodes. Because a desktop client program can support multiple active sign-ins (though not multiple active tasks within a single sign-in), the user can have sign-ins active on multiple submitter nodes. The desktop client program explicitly signs the user in to several submitter nodes. If the primary submitter node fails, the desktop client program can sense the failure and switch to another sign-in. The user is already signed in to an alternative system and is ready to continue operations more rapidly. In this case, as shown in Figure 2-3, the desktop client program can be written to hide the submitter node failure from the user.

Figure 2-3 Submitter Node Failover Configuration


2.2.7 Error Handling

As with any ACMS solution, some application errors are handled directly by the ACMS software. For example, fatal errors that are not handled by customer-written server procedures can cause the ACMS system to cancel a task. In general, however, the TP Desktop Connector software returns any error it receives to the desktop client program. Therefore, the desktop client program can appropriately handle virtually all error conditions.

With TP Desktop Connector sign-in, task call, and sign-out, the desktop client program can trap the status returned by these operations and take appropriate action. The ACMSDI return status values identify conditions to which the desktop client program should respond. These conditions include sign-in failures, task processing errors, TP Desktop Connector Gateway for ACMS failures, and other error conditions. For example, ACMSDI_NORMAL is the return status indicating successful completion of TP Desktop Connector client services. If the ACMSDI_INTERNAL error is returned, the desktop client program should end any active tasks, sign the user out of the ACMS system, and instruct the user to exit from the application.

Error handling for exchange steps in I/O tasks is straightforward. When a ACMS task is canceled, the TP Desktop Connector Gateway for ACMS reports a specific error where possible. If the gateway cannot convert a ACMS error to a specific TP Desktop Connector status, it returns ACMSDI_TASK_FAILED to the desktop client program.

If the desktop client program encounters an error during its own processing of an exchange step, that error can be handled within the desktop client program. The desktop client program can then return status information in a workspace to be evaluated in the task definition for appropriate action. The desktop client program can also return any valid OpenVMS error code (including DECforms, TDMS, and application-defined values) to the ACMS system to instruct ACMS to continue or cancel the task.

2.2.8 TP Desktop Connector Gateway for ACMS Error Checking

The TP Desktop Connector Gateway for ACMS responds to recoverable thread-level errors by dropping the thread in a controlled way, causing that thread to be cleaned up while insulating other threads from any ill effects. The gateway treats some errors (such as access violations) as fatal to the gateway, thereby dropping all active threads.

These checks detect errors from the following sources:

2.3 User Interface Design

This section discusses the considerations in designing an effective user interface for your desktop client program. Some aspects of the interface, such as application flow, are discussed in Section 2.2. This section focuses on those questions that are most directly related to what the user sees on the display device.

Following these and other published user interface design principles can maximize user productivity:

2.4 Data Design

The ability to have presentation code native to desktop systems communicate with application code native to OpenVMS systems raises many new questions. The following sections discuss how the software handles differences in data types between the various environments.

2.4.1 Data Conversion

Because TP Desktop Connector software does not manipulate workspace contents, it does not constrain what data types are used on the desktop system or in the ACMS application. However, TP Desktop Connector software does not automatically handle data conversion between the OpenVMS and desktop environments. In many cases, you can build your desktop client program such that data types are compatible between the desktop system and the ACMS system. If you have incompatible data between the systems, the application code must perform any conversion required.

The most commonly used data types are readily mapped between OpenVMS and desktop systems. Part 2 contains sections that list the data types that must be converted for each platform.

For Macintosh systems, most nontext data requires conversion between the desktop client program and the gateway.

Typically, data conversion is done most effectively in the desktop client program. Doing so takes advantage of the processing power of the desktop system, and ensures the portability of the ACMS application.

2.4.2 Data Alignment with RISC Architecture Clients and OpenVMS Servers

The RISC architecture requires that data references be naturally aligned. That is, short words (2 bytes) must be on an even byte boundary. Long words (4 bytes) must be accessed on a boundary evenly divisible by 4.

When Alpha clients define a C structure, they create padding in the structure, if necessary, to ensure that each field complies with these requirements. (The padding is not visible to you.)

OpenVMS, however, does not impose such restrictions on its data objects and does not pad its structures. The problem arises when data, defined on one of these machines, is transmitted across the network to the other machine, and interpreted using the same C structure definitions.

In a TP Desktop application, this is a concern only when ACMS workspaces are being sent (in either direction) between the client program on a RISC machine such as Tru64 UNIX Alpha and the ACMS application on OpenVMS.

Consider the following structure:


  struct wksp_type 
  { 
    char  field_1; 
    short   field_2; 
    char  field_3; 
  } my_wksp; 

On an Alpha client, my_wksp is stored as:


On an OpenVMS server, my_wksp is stored as:


If my_wksp is allocated on the OpenVMS server and sent to an Alpha client, the structure definition on the Alpha machine is expecting padding that is not there. At run time, your application on the Alpha machine generates the following message:


 Fixed up unaligned data access for pid nnnn (appl_name) at pc 0xnnnnnn 

One approach to dealing with this problem is to allocate new workspaces in the Alpha client program, and perform a byte copy of each field of the incoming OpenVMS server structure into the fields of the new client structure. For structures going from a RISC machine to OpenVMS, you also need to perform a byte copy of each field of the RISC structure to the outgoing data stream. If you are writing a portable application, this solution should not have an adverse effect when running on non-RISC platforms.

Example 6_9 and Example 6-10 show this approach from the AVERTZ Motif sample application.


Previous Next Contents Index