P1024B Specification
Tony Wei
Yves Gaffarel
teletype like email messages (zczc....nnnn) between airlines.
I suggest you contact some SITA technical contact person (www.sita.net). As
the protocol was used by all airlines, you can probably get a copy of the
manual from airlines IT/telecom technical personnel.
By the way, P1024B was supported on several Unisys (and, previously, Sperry)
systems. If you are in touch with Unisys personnel previously involved in
Sperry telecom, you might be lucky there.
"Tony Wei" <nap...@hotmail.com> wrote in message
news:1b906ba6.03022...@posting.google.com...
John Crosland
originally known
in Airline networks as as conventional) messages. TYPEB/TTY is not the same
as P1024B.
P1024B is a SITA version of a specification that came IBM as part of
the original PARS, IPARS, and TPF development for the airline industry.
These are operating systems and application environments that run on IBM
mainframes. TPF is the operating environment for most of the large-scale
IBM-based airline and banking systems. The terminals that were designed by
IBM to commmunicate with these systems use a protocol called ALC (Airline
Link Control).
When SITA incorporated support for these terminals into their network,
they developed their specification for the behavior of the ASCUs (a SITA
name referring to the Agent Set Control Unit) and how they would interact
with the network. That specification is P1024B. In addition to P1024B and
ALC, the protocol (and screen presentation) also go by a wide variety of
names like IPARS (really the name of an IBM-based reservations system, and
Sabretalk. Because the protocol used a 6-bit character set (like the old
Uinvac fielddata but not the same values), it can support a very limited
number of non-alphanumeric characters. Many if not most of the Airline GDSs
(Global Distributions Systems) like Sabre, WorldSpan, Amadeus and a lot of
the IBM-based CRSs (Computer Reservation Systems) like Delta, KLM, and BA,
have developed their own "private" versions of the character set. In many
cases, they have also created their own "private" way to envelope and handle
printing. They all behave the same way in term of how the data is handled
in the network and how the ASCUs interact with the network but then can
invoke or expect different behavior within the terminal. You really have to
map the TE to the expectations of the target GDS or ACS. These issues are
transparent to the transport network and largely unaddressed in the P1024B
specification.
The P1024B specification deals mostly with the specs for the exchanges
between the terminal control unit and the network using these 6 bit
characters and IA (Interchange Address) and TA (terminal address) to
identify the site and the terminal. It is a syncronous protocol so it almost
always requires an external modem. Even so, I have never seen it
successfully done using a standard PC serial port. All of the TEs that I
have seen in the market have required special syncronous interface cards
that have their own API. Not an easy task to develop against. Innosys and
Westinghouse Canada which became part of Norfork Gruman had some of the most
popular products. There was a third company that was big with Sabre called
ICOT but they went out of business. I know of at least two products in the
genre that used a Persys card from Emulex as the basis for their
communications links. These cards are not cheap but probably still
available
Many people even in the industry, use the term P1024B (somewhat
incorrectly) to refer to the terminal datastream. It really focuses much
more on the behavior of the control unit when it it polled by the network.
Rather than dealing with the syncronous polling protocol specified by
P1024B, I would suggest that you consider development either using MATIP the
publicly available Internet RFC specified earlier,or EMTOX over X.25 (not so
publicly available but purchasable from either SITA, IATA, or ATA. In
MATIP, you exchange ALC/IPARS/SabreTalk formated terminal messages across a
TCP socket. In EMTOX, you can exchange them across any number of available
X.25 software packages you could install on the workstation or Unix server.
Because IBM is dropping support for the older airline network protocols, all
of the GDSs and CRSs are moving as quickly as they can to MATIP or EMTOX
with the same stream of terminal data. If you really want to do the sync
poll/response stuff, CISCO has software that can be installed in their
routers (called MATIP or ALPS) that will take the traffic it receives when
it polls your ASCU on a sync circuit and create the MATIP messages from
them. CISCO and their ALPS or MATIP product docs may also be another source
of info.
If you have a commercial relationship with Unisys, you might ask to
talk to their Airnet staff in Roseville and London (within the ADC - Airline
Development Center - group) for more info. You might contact Innosys and
ask them for a product specification for their P1024B handlers. You could
also talk to a company called Quickware that I believe has had some
experience there as well. The absolute best source for technical
information would the technical staff of the GDS or CRS with which you
intend to be communicating. Regardless of what other information you have,
I doubt that you would be successful without the latter.
If you are willing to pay them, there are companies like Innosys and
Advanced Travel Services (ATS - a part of SITA now) will provide the
protocol libraries and an API that would let you integrate the protocol into
your program. It depends on if your task is to write a TE as an end product
or simply use the connectivity as a means to another end.
Brgds,
John
"Yves Gaffarel" <pas...@pas.ici> wrote in message news:<b3ojiv$91$1...@si05.rsvl.unisys.com>...
Halldór Ísak Gylfason
an IATA standard? Is it a transport protocol, or is it some predefined
message format?
I think I've heard somewhere that TYPE A messages are transferred over
X.25 in the SITA network. Is that correct?
John Crosland
In the airline industry, TYPEA messages refer to transactional
(sometimes also called conversational) messages. They are usually
transactional exchanges between terminals and host or in some cases
hosts and hosts. They are exchanged "at risk" with no message
recovery or guarantee of delivery in the network. This is the norm
for agent transactional traffic. The focus is fast transit and
response. The thinking is that if the agent does not receive a reply,
they wll unlock the keyboard and re-transmit. It is also
possible/normal to exchange them via TCP/IP and MATIP in which case
you have the normal retranmission/recovery procedures that are a part
of TCP.
TYPEB messages can be exchanged point to point but usually
involved the services of a store-and-forward message router. TYPEB
exchanges include an ack mechanism between the sender and the
messaging service as well as a deliver ack between the receiever and
the messaging service. There are standard AIRIMP formats for many
machine-processable TYPEB messages that allow the airlines to exchange
lot of information automatically. Think of them as Email although
long before the Internet or even IP.
Both TYPEA and TYPEB messages can be exchanged over a wide
variety of link, network, and transport protocols including X.25 and
TCP/IP.
Both IATA and ATA are active in coordinating the AIRIMP TYPEB
standards as well as the EDIFACT/U.N. standards for airline messaging.
I believe there has also been a lot of work among the airlines to
agree on XML message formats and contents as well.
Yves Gaffarel
"John Crosland" <UPERBV...@spammotel.com> wrote in message
news:fc5a6aa5.03022...@posting.google.com...