Envoy Application Programming Manual
Table Of Contents
- What’s New in This Manual
- About This Manual
- 1 Application Programming With Envoy
- 7 ADM-2 Multipoint Supervisor Protocol
- 8 TINET Multipoint Supervisor Protocol
- 9 Burroughs Point-To-Point Protocol
- 10 Asynchronous Line Supervisor Protocol
- A ASCII Character Set
- B ASCII to EBCDIC Code Conversion
- C File-System Procedures
- D Statistics Messages
- E S-Series Changes to Envoy
- NonStop™ Himalaya S-Series Server Architecture
- G-Series Migration Considerations
- CBSENSEON and CFSENSEON Modifiers
- LEOTRESYN and NOLEOTRESYN Modifiers
- Treatment of Characters After the Termination Character
- Number of SYN Characters
- DTR Drop
- Reporting of Parity Error
- Half-Duplex Support for Asynchronous Lines
- Controller Replacement
- SYSGEN and COUP
- Unit Numbers
- FDX Line Changes
- No Support for Auto-Call Unit
- Glossary
- Index
Software Concepts
Envoy Application Programming Manual—427159-001
2-23
Programming Considerations for NonStop™
Himalaya Servers
Programming Considerations for NonStop™
Himalaya Servers
Programming for NonStop™ Himalaya servers affects application program design in
two areas:
•
Recovery from the failure of a path to a communications line (specifically, this
means a failure of the processor module where the primary communications process
is executing or a failure of the primary I/O channel to the communications device.)
•
Recovery from a failure of the processor module where the application process is
executing.
In either case, the line may be in an indeterminate state following the failure. Therefore,
the same action is recommended for either type of failure:
•
If the transmission format can be specified by the application, such as when two (or
more) Compaq systems communicate with one another, then the application can
perform message-level error recovery. That is, the application can be designed so
that if a failure occurs on the receiver side, an indication can be returned to the
sender, causing the sender to retransmit the message. Likewise, if a failure occurs on
the sender side, the sender can automatically retransmit the last message; and the
receiver can contain logic to discard any duplicate messages (for example, each
message could be identified by a sequence number).
•
If the transmission format is already defined (other manufacturers’ terminals are
often configured this way), then the application process, when communicating with
such terminals, should issue an EOT (or comparable) control sequence or close the
line if an error is detected. The application process should then return to the state
where it is waiting for a transmission to begin.
Example 2-9
shows the action of the receiver when a failure occurs on its side, and the
associated action on the sender side.