Brief: E-mail on the AS/400 has traditionally been a closed environment. It
hasn't been able to transmit the wide variety of documents, such as graphics,
audio, and video, typical in today's business environment. The X.400 standard
enables the exchange of these diverse types of messages and documents. This
article introduces the concepts behind X.400 and discusses the AS/400 features
available to support it.
We've all seen the impact the fax machine has had on business communications. A
similar revolution is happening with E-mail. E-mail has eliminated hard copy
memos (and the many positions once employed to type and file those memos).
The next step for internal E-mail systems is to connect to some outside mail
forwarding service to communicate with customers and vendors. This step is as
natural an evolution as using a fax machine to send hard copy documents to a
customer or supplier.
Unfortunately, E-mail systems haven't developed with the same coherent, clear-
cut standards as fax systems. Most E-mail systems will only communicate with
the same type of mail system. Popular E-mail packages in many companies include
IBM OfficeVision and Lotus cc:Mail and Notes.
In addition to the problem of different mail systems, there's the problem of
different types of computers and different communications protocols to contend
with. The problem is becoming increasingly complicated because documents can
now include graphics, scanned pictures, audio, and full-motion video in
addition to plain text.
ISO and OSI
The International Standards Organization (ISO) has proposed the Open Systems
Interconnect (OSI) standard, which includes an E-mail services specification
known as X.400. A related specification is X.500, a specification for directory
services used to route mail to addressees. (For more information on the OSI
standard, see "Connectivity Framework: Defining the OSI Reference Model," MC,
September 1994.)
In general, European and Japanese corporations have been quicker than those in
the United States to adopt OSI (including X.400). These corporations'
subsequent savings and competitive edge may push the adoption of OSI in the
rest of the world as companies try to keep pace with the more standards-
oriented European and Japanese marketplaces.
Many current E-mail systems either use the X.400 specification directly or
provide a gateway function to translate mail to the X.400 specification. The
AS/400 supports both methodsùa set of licensed products gives the AS/400 the
ability to provide a direct application interface to other X.400-compliant
machines through the X.25 communications interface, and OfficeVision offers
gateway capability.
In order to implement OSI on the AS/400, you must have at least one X.25 line
and three licensed programs. OSI Communications Subsystem/400 (V3R1 program
number 5763-OSI) provides configuration functions, network management support,
and directory services; OSI Message Services/400 (5763-MS1) provides X.400
services; and OSI File Services/400 (5763-FS1) provides File Transfer, Access,
and Management (FTAM) services.
X.400's OSI application standards enable the global exchange of E-mail
messages. X.400 was first published as a set of CCITT (an international
standards organization) recommendations in 1984. In 1988, ISO and CCITT jointly
published an enhanced set of X.400 standards.
The 1988 version of the X.400 standard describes the exchange of Electronic
Data Interchange (EDI) documents, images, facsimiles, as well as voice. This
allows X.400 to be used for more than just E-mail. IBM's current AS/400 X.400
product is built to the 1984 standards, but it will undoubtedly be updated to
the 1988 standard soon.
The Format of X.400 Messages
There are three types of X.400 messagesùan actual message, a probe, and a
delivery report. For actual messages and probes, information in the envelope
specifies who the recipients are and how the message is to be handled. This
information includes the following:
? The Originator/Recipient (O/R) name of the originator.
? The O/R names of the recipients.
? The content type (for example, P2, EDI).
? Other information about how the message should be handled by the message
transfer agents.
? The size of the message (for a probe only).
? Whether a delivery or non-delivery report is to be returned to the originator
for each recipient (for a message submission).
While an actual message consists of both the envelope and the content parts, a
probe consists only of an envelope. Probes are used to determine whether a
recipient can accept a message with certain characteristics, so the actual
message content is not sent on the probe.
A complete X.400 message handling system is composed of several subcomponentsù
the message transfer agent, a message store, and a user agent. The complete
message handling system has a close analogy to typical real-world postal
services, as shown in 1.
services, as shown in Figure 1.
The user agent is the component through which a mail user or mail application
accesses the X.400 message handling system. An E-mail userùthe originatorùuses
a user agent to compose and submit an electronic message bound for one or more
recipients. This message consists of two parts: an envelope that contains
addressing information and the message itself, which is the contents of the
envelope.
The user agent submits the message to either a message store or a message
transfer agent. For the recipient of an X.400 message, it's the recipient's
user agent that takes delivery of the message from either a message store or a
message transfer agent. A user can also send a probe to one or more recipients
to find out whether the recipient can accept delivery of messages that have
certain content type, size, or data encoding.
Besides providing the services for composing, receiving, and perhaps displaying
messages, it's the originator's user agent that must encode the message in a
format that can be understood by the recipient's user agent. Therefore, the
originator and recipient user agents need to understand the format of the
message content being transferred. The X.400 message envelope has a content-
type field that allows the receiving user agent to determine whether it can
process a message received.
When a message is submitted to a message transfer agent from a user agent or a
message store, or received from another message transfer agent, it's the
message transfer agent's responsibility to route the message to the intended
recipients. A recipient could be within the delivery domain of the message
transfer agent (i.e., a user agent or message store served by this message
transfer agent). In this case, the message stays with the message transfer
agent until it is delivered to the user agent or message store.
If a recipient is outside the delivery area of the message transfer agent, then
the message transfer agent must route the message to another message transfer
agent. Depending on the algorithm set up for routing between message transfer
agents, a message may pass through several message transfer agents before it
reaches its final destination. The network of cooperating message transfer
agents is called a message transfer system.
The originator of a message can request that the message transfer agent return
a delivery report when a message has been delivered to a specific recipient or
when a message cannot be delivered. A delivery report includes information
about the originator of the message (the recipient of the delivery report) and
the delivery result for each recipient. All the report information is sent in
an envelope part.
A content part is included in a delivery report only if the message was not
deliverable, and the originator has explicitly requested that the message be
returned with the non-delivery report. In the message handling system, a
delivery report is treated just like a message and is transported through the
message handling system until it reaches the message transfer agent serving the
originator. Message transfer agents also use delivery reports to respond to
probes.
A new element introduced in the 1988 X.400 standard is the message store.
Messages destined for a user agent can be delivered to a message store first.
Subsequently, the user agent retrieves the messages from its message store.
Thus, mail can be delivered instead of held by the message transfer agent, even
when a user agent cannot be reached for an extended period of time.
The message store provides additional services to the user, such as a list of
messages in the store, allowing selected messages to be received by the user
agent. These services are not provided by the message transfer agent, which
delivers messages based on a completely different set of criteria.
X.400 Addressing Scheme
In the 1984 X.400 standards, an O/R name consists of an O/R address. The O/R
address provides information on how to reach the recipient and is made up of a
set of elements called attributes. Each attribute has a type and value. X.400
has specified a set of O/R address variants, as well as the attribute types
that may be used for each variant. 2 lists the variants and the
that may be used for each variant. Figure 2 lists the variants and the
attribute types allowed for them.
Most attribute types are self-explanatory. A few, however, justify some
additional discussion. Administration management domains are usually government
agencies, such as a public telephone, and telegraph service (PTT).
Private management domains are generally private enterprises, such as IBM. In
countries where the PTT is a monopoly, a private management domain may route
messages within its own domain but may not be allowed to route messages
directly to other private domains. An administration management domain is
required to route messages between private domains. This is the reason
administration management domains are mandatory attributes.
Administration management domains also affect how routing is done in the
message transfer system. For a message going between two private management
domains, the message may need to be relayed through several administration
management domain message transfer agents.
Domain-defined attributes are additional identification attributes that can be
defined by public or private management domains. Each domain-defined attribute
is made up of a type and value, both represented with character strings.
Differences Between 1984 and 1988 X.400 Standards
Several key differences exist between the 1984 and 1988 versions of X.400
standards:
? The message store is not a component of the 1984 standard.
? The 1984 O/R name is equivalent to the 1988 O/R address. The 1988 standard
expanded the O/R name to consist of either an O/R address, a distinguished
name, or both.
? The 1988 standard allows an O/R name to refer to a distribution list, and
specifies procedures on how a distribution list is expanded in the message
handling system.
? The 1988 standard allows other content types, such as EDI, to be specified.
The 1988 standard provides the directory access support.
? Security features have been added to the 1988 standard.
? When a 1988 message transfer agent communicates with a 1984 message transfer
agent, the 1988 enhancements are removed from the message. If critical new
enhancements (such as security features) are present, the message becomes
undeliverable.
Beyond E-mail
It is possible to use X.400 for communications that are more complex than text-
based E-mail. We'll look at two of these possibilities: FTAM, which provides
facilities for remote file access, and EDI.
EDI is the electronic exchange of computer-readable, structured business
documents, such as purchase orders, invoices, shipping specifications,
statistics, and import and export documentation. EDI is part of the 1988
specification and is very important in electronic messaging between businesses.
Therefore, it will likely be added to the AS/400 X.400 product soon.
In traditional business procedures, companies define the components of their
business documents on their own. For EDI to work, data needs to be exchanged
according to a standard format so that both the sending and receiving
applications recognize the data.
For current EDI standards, three elements are necessary for successful
transmission of documents.
Document format standards. In a paper-based system, documents can be received
in many different formats. A computer application, however, can interpret only
data structured in the exact format it expects to read. A variety of data
standards have evolved over the years, including ANSIX12, UN/EDIFACT, ODETTE,
and TDI.
Document translation. Because each business application has its own data format
and syntax requirements, a translator converts the data produced by a company's
in-house application into the agreed-upon interchange format, and vice versa.
Document transmission. To transmit documents electronically, trading partners
also need to agree on which type of network to use.
All of the EDI components (standards, applications, translations, communication
systems, and trading partners) have to be defined before a transaction takes
place. They are defined in a contract between trading partners, which is called
an Interchange Agreement.
The 1984 X.400 recommendations do not describe specifically how EDI should be
carried out, so two ad hoc approaches were developed. The first approach
involves using only X.400's general application independent support, which
treats EDI as an undefined application. All of the partners have to define how
the undefined application works. The X.400 user agent programs corresponding to
these conventions could then be developed for EDI.
An alternative approach has gained greater favor in Europe. With this approach,
EDI data is carried as an interpersonal messaging protocol (IPMs), with the
actual document carried as the body part of the IPM. This approach depends on
the fact that the EDI data is character-oriented.
In the 1988 X.400 recommendations, the EDI messaging system is defined. This
system is accessed through an EDI user agent that supports the EDI messaging
content type, called Pedi.
AS/400 FTAM
The AS/400 X.400 product supports FTAM. FTAM is a complex and complete standard
that includes file-level or record-level access to files on a remote OSI
system. This standard is similar to distributed data management (DDM), which is
IBM's SNA protocol for remote file access. Since FTAM is a finalized standard
like X.400, most vendors have a product to implement FTAM. Because of its
complexity, however, most vendor implementations at this stage provide only
file-level access to remote files and support only a subset of the file types
described in the standard.
FTAM is already being used in Europe for government reporting by financial
institutions and by automobile manufacturers in the United States. The AS/400
product supports file-level copy, move, and create functions for files of
unstructured text or binary data and limited file management.
What Does It All Mean?
E-mail and EDI are fast becoming an integral part of most corporate cultures.
The ability to exchange mail messages between corporate entities will become as
important in the near future as the ability to exchange fax documents is today.
The major suppliers of E-mail systems are pushing hard to become dominant.
Lotus Notes is taking hold at a rapid pace. Microsoft is building a mail
facility into its next generation of operating system products. Existing E-mail
systems, such as the TCP/IP Simple Mail Transfer Protocol (SMTP), are being
expanded to transport additional document types. (With V3R1, SMTP is now
included with OS/400 at no additional cost as part of the TCP/IP Connectivity
Utilities/400.)
X.400 will also become an important standard for the exchange of E-mail between
companies. At the present time, most implementations of X.400 are limited to
the exchange of text-based mail. All mail systems in use today, though, are
moving toward the ability to exchange a wide variety of documents, including
EDI, fax, voice, graphics, and video. It's a little soon to declare a winner in
the E-mail sweepstakes, but X.400 will at least be an important gateway
protocol for exchanging mail between competing systems.
REFERENCES
OSI Communications Subsystems/400 (GC41-3072, CD-ROM QBKAJK00).
OSI File Services/400 (GC41-3065, CD-ROM QBKAJE00).
OSI Message Services/400 (GC41-3065, CD-ROM QBKAI400).
X.400 E-mail Standards in an AS/400 World
Figure 1Postal Service Counterparts to an X.400 Message Ha
X.400 POSTAL SERVICE Message Transfer Agent Post office Message Store Post office mailbox or private mailbox User Agent Person or company using the postal service OSI Network The transportation network that carries mail between post offices, mailboxes, and users
X.400 E-mail Standards in an AS/400 World
Figure 2O/R Address Variants and Attribute Types
O/R Address Applicable O/R Variant Types Address Attributes Mandatory/Optional Mnemonic Country Mandatory Administration Mandatory management domains Private management Optional domains Organization Optional Organizational units Optional (maximum of 4) Surname Mandatory when specifying a personal name; otherwise, optional Given name Optional Initials Optional Generation Optional Domain-defined Optional (maximum of 4) attributes Numeric Country Mandatory Administration Mandatory management domains Private management Optional domains Numeric user Mandatory identifier Domain-defined Optional (maximum of 4)
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online