PMDF System Manager's Guide

On Tru64 UNIX, for OSI transport using DECnet/OSI, you will need to define the PMDF-X400 application together with appropriate OSI network service. Supported network services are connection-less (CLNS) and connection-oriented (CONS). CONS is likely to be of use only if you are implementing an X.400 connection over an X.25 datalink.

The definitions need to include:

• NCL commands that define OSI transport entities. These include:
  • OSI transport template which defines required transport parameters and the network service (CLNS or CONS). NCL commands required will be along the lines of:

    ncl> create osi transport template ... ncl> set osi transport template ...

  • (CONS only) X.25 access template which defines parameters required for making outgoing X.25 calls.
• Optionally, for a CONS network layer, you can also choose to explicitly define:
  • (CONS only) X.25 access filter which specifies call data required for routing inbound X.25 calls to OSI transport, and thereby to the PMDF-X400 application.
• Finally, these NCL definitions will necessarily depend upon other DECnet/OSI parameters configured when you installed DECnet/OSI and related, optional components such as X.25. Those definitions are not specific to PMDF-X400, but pertain to your general DECnet/OSI configuration. They include, but are not limited to:
  • devices, routing ports and address towers
  • (CONS only) X.25 access DTE class and service nodes

During configuration of PMDF-X400 using the pmdf configure x400 (UNIX) utility, a pmdf_x400_service.ncl file will be created in the PMDF table directory containing the NCL commands required for the service and any associated OSI transport entities. You will need to ensure that this file of NCL commands is executed by your system startup procedures sometime after the PMDF startup procedure has run. This can be done by placing a symbolic link from /var/dna/scripts to the PMDF NCL definitions, e.g.:

# ln -s /pmdf/table/pmdf_x400_service.ncl /var/dna/scripts

The first section of the generated file contains OSI transport definitions required for your chosen network service and beginning with an OSI Transport Template. The contents here will depend upon whether CLNS or CONS network service was chosen; see Section 41.6.1.1 or Section 41.6.1.2, respectively.

41.6.1.1 DECnet OSI Using CLNS

Such an NCL command is:

create osi transport template template-name

where template-name matches the transport template named specified using the PMDF CONFIGURE X400 utility.

For instance, suppose the pmdf configure x400 utility was instructed to use a transport template named PMDF-CLNS. This results in an entry in the file which includes:

TEMPLATE=PMDF-CLNS

Then the associated DECnet/OSI definition written to the file pmdf_x400_service.ncl is simply:

create osi transport template PMDF-CLNS

In the unlikely event that your network requires modification of the standard CLNS template parameters, you will need to add additional

set osi transport template PMDF-CLNS ...

commands to the pmdf_x400_service.ncl file.

41.6.1.2 DECnet/OSI Using CONS

Such NCL commands to configure the CONS connection would be along the lines of:³

create osi transport template template-name set osi transport template template-name classes {0,4} set osi transport template template-name cons template X25-name set osi transport template template-name checksums false

where template-name is the template name specified using the PMDF-X400 configuration utility, and where X25-name is the name of an X.25 template already defined with commands such as

create X25 access template X25-name set X25 access template X25-name dte class DTE-class-name set X25 access template X25-name call data %X03010100

Here DTE-class-name is the name of the DTE class, as defined during DECnet/OSI X.25 configuration.

That takes care of outbound calls. For inbound calls, X.25 must be directed to pass OSI calls up to the OSI transport. DECnet/OSI allows this by default, so normally nothing further need be done. However, if you want to explicitly configure it to allow incoming calls to PMDF-X400, (note that you will need to shutdown DECnet/OSI in order to do so), see the following procedure.

Normally the Call User Data of 03010100 indicates an OSI call; i.e.,

create X25 access filter X25-name set X25 access filter X25-name call data value %X03010100, - call data mask %XFFFFFFFF set X25 access filter X25-name priority 255

where X25-name is the same X.25 template name used above. This defines a filter which will match any incoming calls with that Call User Data. Note that you can also use other criteria such as a particular subaddress or a particular DTE Class. If necessary, this will require that you add additional NCL commands.

Finally, the OSI Transport is instructed to accept calls on that filter so that inbound calls with that Call User Data will be passed to and accepted by the OSI Transport.

add osi transport cons filters {X25-name}

41.6.1.2.1 Sample CONS Configuration NCL Commands

TEMPLATE=PMDF-CONS

In addition, the predefined X.25 access DTE class named SAT, is assumed to already exist, (presumably having been defined during the configuration of X.25). (Note that your DTE class is very likely to use some name other than SAT, as this is quite site-specific.)

Continuing this example, the definition of the OSI Transport Template would look like:

create osi transport template PMDF-CONS set osi transport template PMDF-CONS network service CONS set osi transport template PMDF-CONS classes {0,4} set osi transport template PMDF-CONS cons template PMDF-X25 set osi transport template PMDF-CONS checksums false

Note that this template in turn refers to an X.25 template PMDF-X25 which is defined:

create X25 access template PMDF-X25 set X25 access template PMDF-X25 dte class SAT set X25 access template PMDF-X25 call data %X03010100

This entry directs the X25 call to the DTE Class SAT and sets the Call User Data to the OSI standard value. (As mentioned above, the DTE Class is presumed to have been defined previously, during DECnet/OSI X.25 configuration.)

The above commands take care of the case of outbound calls. Normally, nothing need be done to allow incoming calls since DECnet/OSI allows them by default. However, if you want to explicitly configure it to allow incoming calls to be routed to PMDF-X400, see the following additional example commands.

The commands to handle inbound calls, i.e., to direct X.25 to pass OSI calls up to the OSI transport, would be:

create X25 access filter PMDF-X25 set X25 access filter PMDF-X25 call data value %X03010100, - call data mask %XFFFFFFFF set X25 access filter PMDF-X25 priority 255

since normally the Call User Data of 03010100 indicates an OSI call. This defines a filter which will match any incoming calls with that Call User Data. (Additional NCL commands could be used to allow matching on other criteria such as a particular subaddress or a particular DTE class.)

Finally, the OSI Transport is instructed to accept calls on that filter so that inbound calls with that Call User Data will be passed to and accepted by the OSI Transport.

add osi transport cons filters {PMDF-X25}