Accessing Your Paging Server
with the Async Professional Paging Components

Async Professional 3.0 includes new paging components that support the growing TAP and SNPP protocol standards for Alphanumeric paging.   For these to work, your paging company has to provide “servers” that support these protocols.  Having an available Paging Server is an absolute requirement, but even giving that your company provides them is far from a guarantee that their implementations are complete or conform to the standards.


The main awkwardness that is likely to arise is from poor or incomplete TAP implementations, as the “standards” (if one may call them that) for TAP are relatively new and don’t have the full force of Internet standard making behind them (as is the case with SNPP and RFC-1861).

The TApdTAPPager component provides what should be a reasonably generic approach to communicating with a wide range of TAP paging servers; even so there may still arise some locations to which you find yourself unable to successfully log into or send.

TApdTAPPager provides a few built in properties to let you modify how it interacts with the Paging server.  In particular the MessageLength property lets you specify the maximum length that a message block will occupy, some Paging Servers appear to have trouble dealing with message blocks greater than about 80 characters (thus the default); even though the TAP specification allows blocks up to 256 characters.

Similarly the TAP version 1.8 specification allows sending “control” characters as part of messages via an escaping system.  This may be turned on and off via the TApdTAPPager UseEscapes property.  But since many Paging Servers are still apparently using software that supports lower versions, the default for this is to have UseEscapes turned off.

Another possibility is that some servers may respond to subtly different message structures, or may send subtly different response codes than are expected by the TApdTAPPager component as-is.  We anticipate this being a rarity, but if you find yourself in this situation, you have access to the codes that are being used in the AdPager source code. 


  {TAP server repsonse sequences}

  TAP_ID_PROMPT   : string = 'ID=';

  TAP_LOGIN_ACK   : string = cAck + cCr;

  TAP_LOGIN_NAK   : string = cNak + cCr;

  TAP_LOGIN_FAIL  : string = cEsc + cEot + cCr;

  TAP_MSG_OKTOSEND: string = cEsc + '[p';

  TAP_MSG_ACK     : string = cAck + cCr;

  TAP_MSG_NAK     : string = cNak + cCr;

  TAP_MSG_RS      : string = cRs + cCr;

  TAP_DISCONNECT  : string = cEsc + cEot + cCr;

  TAP_AUTO_LOGIN  : string = cEsc + 'PG1' + cCr;

  TAP_LOGOUT      : string = cEot + cCr;

(Note, the various “cXxx” constants for the control characters are to be found in the OoMisc unit)

Since these are defined as “typed constants”, these may be modified by run-time code. You should change these only after you’ve determined for certain that the Paging Server is sending incompatible sequences.  One good way to examine in detail what you’re actually getting from the server is to configure your TApdComPort component to generate a “Dispatcher Log” (set TApdComPort.Logging = tlOn).  This will show precisely what is being sent over the port.

Explaining the precise functioning of all of these sequences is really beyond the scope of this particular how-to, if you find you need this you’ll also need to peruse the TAP specification (and determine how your Server’s implementation varies from it).


An SNPP communication consists of a series of request/response transactions wherein the client sends some information and the server responds with either an acknowledgement or an error.  The formatting of these requests and responses is defined in the SNPP specification (RFC-1861); it remains possible, of course, for SNPP servers to do non-compliant things.  This will most likely arise in the form of non-standard response strings from the SNPP server. 

The TApdSNPPPager component provides run-time properties that allow changing the strings used to send server requests and to detect server responses:

·    ServerInitString

·    ServerSuccessString

·    ServerDataInput

·    ServerResponseFailContinue

·    ServerResponseFailTerminate

·    ServerDoneString

The functioning of each of these properties is described in the Async Professional Reference Guide.

This site is not affiliated, endorsed, or otherwise associated with the entity formerly known as TurboPower Software. The owners and maintainers of were merely meager employees of the aforementioned organization, providing this site out of the pure goodness of their collective hearts. Logo

Last updated: July 22, 2003.