U436296 Release Notes


.h5 ix36919
SLIP support has been added to AIX.

 SLIPLOGIN(8)             (March 16, 1993)            SLIPLOGIN(8)

.h5 NAME
 sliplogin - attach a serial line network interface

.h5 SYNOPSIS
 sliplogin (-cia) (-p loginname )
            (-t ttyname )
            (-b baudrate )
            (-h localhost )
            (-r remotehost )
            (-m mtu )
            (-n netmask )
            (-d dialstring )

.h5 DESCRIPTION
 sliplogin is used to turn the terminal line on standard input into a Serial Line IP (SLIP) link to a remote host. To do this, the program searches the file /etc/slip.hosts for an entry matching loginname (which defaults to the current login name if omitted).  If a matching entry is found, the line is configured appropriately for slip (8-bit transparent i/o) and converted to SLIP line discipline.  A shell script is then invoked to initialize the slip interface with the appropriate local and remote IP address, netmask, etc.

The usual initialization script is /etc/slip.login but, if particular hosts need special initialization, the file /etc/slip.login.loginname will be executed instead if it exists.  The script is invoked with the parameters:

   slipunit
       The unit number of the slip interface assigned to this line.  E.g., 0 for sl0.

   speed
       The speed of the line.

   args
       The arguments from the /etc/slip.hosts entry, in order starting with loginname.

Only the super-user may attach a network interface.  The interface is automatically detached when the other end hangs up or the sliplogin process dies.  If the kernel slip module has been configured for it, all routes through that interface will also disappear at the same time.  If there is other processing a site would like done on hang-up, the file /etc/slip.logout or /etc/slip.logout.loginname is executed if it exists. It is given the same arguments as the login script.

 Format of /etc/slip.hosts
 Comments (lines starting with a '#') and blank lines are ignored.  Other lines must start with a loginname but the remaining arguments can be whatever is appropriate for the slip.login file that will be executed for that name.
   Arguments are separated by white space and follow normal sh(1) quoting conventions (however, loginname cannot be quoted).  Usually, lines have the form:
    loginname local-addr remote-addr netmask mtu opt-args
 where local-address and remote-address are the IP host names or addresses of the local and remote ends of the slip line and netmask is the appropriate IP netmask and mtu is the interface maximum transmission unit. These arguments are
passed directly to ifconfig(8).  Opt-args are optional arguments used to configure the line.

It is also possible to use command line flags and arguments to specify the items found in the slip.hosts file. If  present, command line arguments take precedence over values found in the file.

          The options are as follows:

          -c   Use TCP header compression.

          -i   Ignore ICMP packets. All ICMP packets will be discarded.

          -a   Autoenable TCP header compression if it is detected
               that the remote site is using it.

          -p loginname Use loginname instead of the current login.

          -t ttyname Open ttyname instead of the current terminal.

          -b baudrate Set the baud rate to baudrate.

          -h localhost Specify the IP address of the local host.

          -r remotehost Specify the IP address of the remote host.

          -m mtu Set the maximum packet size of the interface.

          -n netmask
               Set an IP address netmask. Not required if address is
               not subnetted.

          -d dialstring Specify a dialstring for remote slip connections.

.h5 EXAMPLE
 The normal use of sliplogin is to create a /etc/passwd entry for each legal, remote slip site with sliplogin as the shell for that entry.  E.g.,
     Sfoo : pjy6 : 2010 : 1 : slip line to foo : /tmp : /etc/sliplogin sp

(Our convention is to name the account used by remote host hostname as Shostname.)  Then an entry is added to slip.hosts that looks like:
     Sfoo 'hostname'     foo  netmask
.sp
where 'hostname' will be evaluated by sh to the local host
name and netmask is the local host IP netmask.

Note that sliplogin must be setuid to root and, while not a
security hole, moral defectives can use it to place terminal
lines in an unusable state and/or deny access to legitimate
users of a remote slip line.  To prevent this, a site can
create a group, say slip, that only the slip login accounts
are put in then make sure that /etc/sliplogin is in group
slip and mode 4550 (setuid root, only group slip can execute
binary).

.h5 DIAGNOSTICS
 sliplogin logs various information to the system log daemon,
syslogd(8), with a facility code of daemon.  The messages
are listed here, grouped by severity level.

     Err Severity
          ioctl (TCGETS): reason
               A TCGETS ioctl to get the line parameters failed.

          ioctl (TCSETS): reason
               A TCSETS ioctl to set the line parameters failed.

          /etc/slip.hosts: reason
               The /etc/slip.hosts file could not be opened.

          access denied for user
               No entry for user was found in /etc/slip.hosts.

     Notice Severity
          attaching slip unit unit for loginname
               SLIP unit unit was successfully attached.

.h5 SEE ALSO
          slattach(8), syslogd(8)



SLATTACH
 

.h5 PURPOSE
 Attaches serial lines as network interfaces.

.h5 SYNTAX
 slattach ttyname ( baudrate )

.h5 DESCRIPTION
 slattach is used to assign a tty line to a network interface, and
to  define  the  network  source  and  destination addresses. The
ttyname  parameter  is  a  string  of  the   form   "ttyXX,"   or
"/dev/ttyXX."  The optional baudrate parameter is used to set the
speed of the connection.  If not specified, the default  of  9600
is used.

        Only the super-user may attach a network interface.

To detach the interface, use 'ifconfig interface-name down  after
killing  off  the  slattach  process.  interface-name is the name
that is shown by netstat

.h5 EXAMPLES

          slattach ttyh8
          slattach /dev/tty01 4800

.h5 RELATED INFORMATION
 The following commands:  "rc" and "netstat."


.h5 ix36920
Simple Network Management Protocol running on PS/2 gives
the capability to talk to Network Managers (Monitor Programs) based
on SNMP protocol. Eg: NetView, Open View (HP).

         Simple Network Management Protocol (SNMP)
.h6 About SNMP
 This LPP is not a complete network management system.
This LPP provides a minimal agent functionality.
There are no Network Operation Center (NOC) / Network
Manager tools provided with the current SNMP LPP.

.h6 Requirements
 To install and use SNMP, you must have the following:
AIX PS/2 TCP/IP License Program Product installed.
One or more of the following network interfaces :
  Ethernet, Token Ring, X.25

.h6 Overview
 The SNMP LPP provides the following servers, tools and
libraries and file formats.

The snmpd server acts as a management agent, implementing
the Simple Network Management Protocol for Berkeley UNIX
systems.

 The snmpt server acts as a trap sink.

 The unixd daemon is a SMUX peer to the SNMP agent.

 The snmpi is a simple program to test snmpd.

 pepsy - table driven replacement for posy/pepy

 The libicompat library makes an attempt of providing an
interface for similar services under different operating
system

 The libtsap library contains a set of routines which implement
transport services on top of the TCP.

 The libpsap library contains a set of routines which implement
presentation syntax abstractions.

                AIX PS/2 SNMP Logical Layers

                        NOC Tools
                        SNMP servers / MIB
                        TCP/IP
                        Network

.h6 Configuring SNMP
 The SNMP servers can be started/stopped when the system comes up
by including the stanzas for server daemons in /etc/rc.tcpip.
Also, the file /etc/services has to be edited if you choose to
assign different ports other than the existing port numbers for
the servers.

For further configuration, files and formats for SNMP read the
following text.

--------------------------------------------------------------

     NAME
          pepsy - table driven replacement for posy/pepy

     SYNOPSIS
          pepsy (-A) (-a) (-f) (-hoption) (-s) module.py

     DESCRIPTION
          The pepsy program reads a description of a presentation
          module and produces definitions and tables for use with the
          C programming language.  It is meant to be backwards
          compatible with the posy system.  (So, pepsy will ignore any
          pepy-style augmentations in the input file.)

          The '-A' (All) switch directs pepsy to generate tables for
          encoders, decoders, and printers.

          The '-a' switch directs pepsy to augment the #include file
          with commentary text.

          The '-f' switch directs pepsy to generate C macros to deallocate
          the structures it defines.

          The '-h' switch enables additional heuristics when pepsy
          generates a C language structure definition.  Option '0'
          enables the default heuristics.  Enabling any other option
          also results in enabling option '0'.  Option '1' enables
          clever but non-unique structure naming.  Option '2' enables
          the generation of arrays rather than linked-lists whenever
          possible.

          Normally, pepsy prints the name of each type as it works.
          The '-s' switch disables this behavior.

     FILES
          module.ph          extern type definitions from module
          module_tables.c    initialized tables for processing module
          module-types.h     C structure definitions from module
          module_pre_defs.h  Preprocessor constants for each type in module
          module_defs.h      macros to support pepy routines for module's types

     SEE ALSO
          pepy(1), posy(1),
          The ISO Development Environment: User's Manual

     AUTHOR
          Andrew Worsley, CSIRO and UCL

--------------------------------------------------------------

     NAME
          snmpi - really minimal SNMP initiator

     SYNOPSIS
          snmpi (-a agent) (-c community) (-f file) (-p portno) (-d)
               (-v) (-w)

     DESCRIPTION
          The snmpi program is an extremely simple program, used to
          test snmpd.  Once snmpd is started, to see if it's running,
          do:

               % snmpi dump

          This should generate voluminous output.

     OPTIONS
          The '-a' switch sets the address of the SNMP agent.  Either
          a hostname, an IP-address, or a transport address (using
          Kille's string syntax) may be used.  The default is the
          localhost.  Similarly, the '-p' switch sets the UDP port
          number that the agent resides on (if an IP-style address is
          given, obviously).  The default is UDP port 161.

          The '-c' switch sets the community name for the SNMP
          request.  The default is public.

          The '-d' switch enables debugging.  This doesn't do anything
          yet.

          The '-f' switch selects a file containing compiled MIB
          module definitions.  The default is objects.defs.

          The '-w' switch enables watching.  When SNMP messages are
          exchanged, they will be pretty-printed on the terminal if
          the user is watching.

          The '-v' switch enables verbose interaction.  This doesn't
          do anything yet.

     FILES
          /usr/etc/objects.defs  MIB definitions

     NOTE WELL
          The names of the objects in objects.defs are case sensitive.
          This was necessary to improve the efficiency of the hashing
          algorithm used for object lookup.

     SEE ALSO
          RFCs 1155, 1156, and 1157.

          S.E. Kille, A string encoding of Presentation Address,
          Research Note RN/89/14, Department of Computer Science,
          University College London, (February, 1989).

     AUTHOR
          Marshall T. Rose, Performance Systems International

          This work was partially supported by the U.S. Defense
          Advanced Research Projects Agency and the Rome Air Development
          Center of the U.S. Air Force Systems Command under contract
          number F30602-88-C-0016.

          Although this package is distributed with the ISODE, it is
          not an OSI program, per se.  Inasmuch as the continued survival
          of the Internet hinges on all nodes becoming network
          manageable, this package was developed using the ISODE and
          is being freely distributed with releases of Berkeley UNIX.

          It must be stressed that this package is not a complete network
          management system.  In particular, whilst snmpd provides a
          minimal agent functionality, there are no Network
          Operation Center (NOC) tools--snmpi is a debugging aid only.

--------------------------------------------------------------

     NAME
          snmpd - SNMP agent for BSD UNIX

     SYNOPSIS
          /etc/snmp/snmpd (-b size) (-d) (-t) (-x) (-z) (-p  portno)
               (-a x121address) (-i pid) (-r) (-s)
          (under /etc/rc.local)

     DESCRIPTION
          The snmpd server acts as a management agent, implementing
          the Simple Network Management Protocol for Berkeley UNIX
          systems.  Upon receipt of a message, it authenticates the
          request, attempts the operation, and then returns a
          response.

          The managed objects manipulated by snmpd are defined in the
          file snmpd.defs, kept in the system administrator's area.
          These objects conform to the Internet-standard Management
          Information Base (commonly referred to as MIB-I), which is
          defined in RFC 1156.  The rules used for naming and describing
          objects are taken from the Internet-standard Structure
          of Management Information (SMI), which is defined in RFC
          1155.

          At present, snmpd permits only a read-only SNMP access mode.
          This restriction may be lifted in the future.

          Most objects are realized via reading /dev/kmem.  There are
          some exceptions, which can be set via a configuration file,
          which is read once, when the daemon starts.

     TRANSPORTS
          For a UDP-based network service, the server listens on port
          161 for SNMP messages.  The '-p' option overrides the
          default UDP port.

          For an X.25-based network service, the server implements the
          transport class 0 protocol, decodes the connection request
          packet, and execs the appropriate program to enter the protocol
          and provide the service.  The '-a' switch is used to
          specify the X.121 address of the local host - this overrides
          the entry in the isotailor file.  In addition, the '-i'
          switch is used to specify the protocol ID to listen on - the
          default is 03018200.  Note that on most X.25 implementations,
          if the local X.121 address is not present in the isotailor
          file, then the '-a' switch must be used in order for
          the server to receive incoming calls.

          For a TP4-based transport service, the server simply listens
          to any incoming connections for selector snmp.

          By default, all network services are enabled (if defined in
          the configuration).  The '-t' option specifies TCP-only
          operation, the '-x' option specifies X.25-only operation,
          and the '-z' option specifies TP4-only operation.

     SMUX
          The agent supports the SNMP Multiplexing (SMUX) protocol.
          To disable this, use the '-s' option.

     CONFIGURATION
          The snmpd.rc file, which is kept in the system
          administrator's area, contains customization commands.  This
          file must be owned by root unless the '-r' option is given.
          At present, the directives are:

          community name address access view
               defines an SNMP community called 'name' with the indicated
               level of 'access'.  The 'address' token is either
               a hostname, an IP-address, or a network address (using
               Kille's string syntax).  If present and a value other
               than 0.0.0.0 is used, then incoming messages claiming
               to belong to the named community must come from this
               address.  The 'access' token, if present, is one of
               readOnly, readWrite, or none, and defaults to readOnly.
               The 'view' token, if present, is an object identifier,
               which names the corresponding view of MIB objects that
               this community may access; otherwise, it defaults to a
               view containing all variables known to the agent.

          view name subtree ...
               defines a collection of manageable objects with the
               given object identifier as its name.  All variables
               scoped by the 'subtree' tokens, each an object identifier,
               given in the directive are placed in the view.  If
               no subtress are listed, the view contains all variables
               known to the agent.

          proxy name domain address community
               defines an SNMP proxy relationship, in terms of a view
               called 'name'.  Management requests for this view will
               be encapsulated via the access method for 'domain' and
               sent to the named address/community.  At present, only
               the domain 'rfc1157' (SNMP over UDP) is supported, and
               the format of the 'address' token is identical to that
               used by the community directive.

          logging ava ...
               sets the logging parameters accordingly.  The one or
               more 'ava' tokens are of the form attribute=value.  The
               attributes are: file, which is the filename for the
               log, this is interpreted relative to the ISODE logging
               area, unless the value starts with a slash; size, which
               takes an integer value describing the maximum file size
               (in KBytes) that the log should be allowed to grow;
               slevel, which takes a string value indicating which
               events should be logged (one of none, fatal, exceptions,
               notice, trace, pdus, debug, or all); dlevel,
               which says which events should not be logged; sflags,
               which takes a string value indicating logging options
               should be enabled (one of close (to close the log after
               each entry), create (to create the log if it does not
               already exist), zero (to reset the log if the size is
               exceeded), and tty (to log events to the user's terminal
               in addition to the file)); and, dflags, which says
               which logging options should be disabled.

          trap name address view
               defines a trap sink for the SNMP community called
               'name', on the indicated address, which is either a
               hostname, an IP-address, or a network address (using
               Kille's string syntax).  Note that at present, traps
               sinks must be reachable via UDP (the network address
               must be an IP-address).  By default, a view is not
               named for the trap sink.

          variable name value
               sets the named variable to the indicated value.  At
               present, these variables may be set: sysDescr, which
               takes a string value describing the management agent;
               sysObjectID, which takes an OBJECT IDENTIFIER value
               containing similar information; sysContact, which takes
               a string value describing the person responsible for
               the node; sysName, which takes a string value giving an
               administratively assigned name for the node; sysLocation,
               which takes a string value describing the location of
               the node; and, sysServices, which takes an
               integer describing the services offered by the node.
               See RFC 1156 for a more thorough explanation of these
               objects.  (The last four are defined in MIB-II, RFC
               1158, the follow-on to RFC 1156.)

          variable snmpEnableAuthTraps ( enabled | disabled )
               enables (or disables) the generation of authentication
               Failure traps.

          variable interface name ava ...
               sets attributes for the named interface.  The 'name'
               token is an interface name as reported by netstat -i.
               The one or more 'ava' tokens are of the form
               attribute=value.  At present, only three attributes may
               be set for each interface: ifType, which takes an
               integer value describing the kind of interface;
               ifSpeed, which takes an integer value describing the
               speed of the interface; and, ifAdminStatus, which takes
               an integer value describing the adminstrative state of
               the interface.  See RFC 1156 for a more thorough
               explanation of these objects.

     DEBUG OPERATION
          If snmpd is started interactively, or if the '-d' switch is
          given, then debug mode is entered.  In this case, all logging
          activity is displayed on the user's terminal.  In addition,
          the logging information is more verbose.

          The '-b' switch can be used to specify the maximum message
          size supported by the daemon.  (This is useful for testing
          how management stations recover from tooBig errors.)

     FILES
          /etc/snmp/snmpd.defs     MIB definitions
          /etc/snmp/snmpd.rc       configuration file
          /etc/snmp/tmp/snmpd.log  log file
          /etc/snmpd.pid           daemon PID file

     NOTE WELL
          The names of the objects in snmpd.defs are case sensitive.
          This was necessary to improve the efficiency of the hashing
          algorithm used for object lookup.

     SEE ALSO
          RFCs 1155, 1156, and 1157.

          S.E. Kille, A string encoding of Presentation Address,
          Research Note RN/89/14, Department of Computer Science,
          University College London, (February, 1989).

     AUTHOR
          Marshall T. Rose, Performance Systems International

          This work was partially supported by the U.S. Defense
          Advanced Research Projects Agency and the Rome Air Development
          Center of the U.S. Air Force Systems Command under contract
          number F30602-88-C-0016.

          Although this package is distributed with the ISODE, it is
          not an OSI program, per se.  Inasmuch as the continued survival
          of the Internet hinges on all nodes becoming network
          manageable, this package was developed using the ISODE and
          is being freely distributed with releases of Berkeley UNIX.

          It must be stressed that this package is not a complete network
          management system.  In particular, whilst snmpd provides a
          minimal agent functionality, there are no Network
          Operation Center (NOC) tools--snmpi is a debugging aid only.

--------------------------------------------------------------

     NAME
          unixd - daemon for UNIX MIB

     SYNOPSIS
          /etc/snmp/smux.unixd (-d)
          (under /etc/rc.local)

     DESCRIPTION
          The unixd daemon is a SMUX peer to the SNMP agent,
          snmpd (8c).  At present, it implements the mbuf subtree of
          the UNIX MIB.

     FILES
          /etc/snmp/unixd.defs MIB definitions

     NOTE WELL
          The names of the various in unixd.defs are case sensitive.
          This was necessary to improve the efficiency of the hashing
          algorithm used for object lookup.

     SEE ALSO
          snmpd(8c)

     AUTHOR
          Marshall T. Rose, Performance Systems International

          This work was partially supported by the U.S. Defense
          Advanced Research Projects Agency and the Rome Air Development
          Center of the U.S. Air Force Systems Command under contract
          number F30602-88-C-0016.

          Although this package is distributed with the ISODE, it is
          not an OSI program, per se.  Inasmuch as the continued survival
          of the Internet hinges on all nodes becoming network
          manageable, this package was developed using the ISODE and
          is being freely distributed with releases of Berkeley UNIX.

--------------------------------------------------------------

     NAME
          snmpt - SNMP trap sink

     SYNOPSIS
          snmpt (-t) (-x) (-z) (-p portno) (-a x121address) (-i pid)
               (-f audit-file)
          (under /etc/rc.local)

     DESCRIPTION
          The snmpt server acts as a trap sink.  Upon receipt of a
          message, it simply logs it to an audit-file.

     TRANSPORTS
          For a UDP-based network service, the server listens on port
          162 for SNMP messages.  The '-p' option overrides the
          default UDP port.

          For an X.25-based network service, the server implements the
          transport class 0 protocol, decodes the connection request
          packet, and execs the appropriate program to enter the protocol
          and provide the service.  The '-a' switch is used to
          specify the X.121 address of the local host - this overrides
          the entry in the isotailor file.  In addition, the '-i'
          switch is used to specify the protocol ID to listen on - the
          default is 03019000.  Note that on most X.25 implementations,
          if the local X.121 address is not present in the isotailor file,
          then the '-a' switch must be used in order for
          the server to receive incoming calls.

          For a TP4-based transport service, the server simply listens
          to any incoming connections for selector snmp-trap.

          By default, all network services are enabled (if defined in
          the configuration).  The '-t' option specifies TCP-only
          operation, the '-x' option specifies X.25-only operation,
          and the '-z' option specifies TP4-only operation.

     DEBUG OPERATION
          If snmpt is started interactively, or if the '-d' switch is
          given, then debug mode is entered.  In this case, all logging
          activity is displayed on the user's terminal.  In addition, the
          logging information is more verbose.

     FILES
          snmpt.log   log file
          snmp.traps  trap file
          /etc/snmpt.piddaemon PID file

     SEE ALSO
          RFCs 1155, 1156, and 1157.

     AUTHOR
          Marshall T. Rose, PSI Inc.  This work was partially
          supported by the U.S. Defense Advanced Research Projects
          Agency and the Rome Air Development Center of the U.S. Air
          Force Systems Command under contract number F30602-88-C-0016.

          Although this package is distributed with the ISODE, it is
          not an OSI program, per se.  Inasmuch as the continued survival
          of the Internet hinges on all nodes becoming network
          manageable, this package was developed using the ISODE and
          is being freely distributed with releases of Berkeley UNIX.

          It must be stressed that this package is not a complete network
          management system.  In particular, whilst snmpd provides a
          minimal agent functionality, there are no Network
          Operation Center (NOC) tools--snmpi is a debugging aid only.

--------------------------------------------------------------

     NAME
          isoaliases - ISODE aliases database

     DESCRIPTION
          The isoaliases file contains information regarding local
          aliases for either user-friendly names or distinguished
          names for use with the OSI Directory.

          Items are separated by any number of blanks and/or tab
          characters.  However, double-quotes may be used to prevent
          separation between arguments.  The character '#' at the
          beginning of a line indicates a comment line.

          The first item is the alias, a simple string.  The second
          item is the value.

     USER-SPECIFIC ALIASES
          By default a user-specific aliases database is consulted
          before the system-wide aliases file.  The user-specific file
          is called .isode_aliases in the user's home directory.

     FILES
          /etc/snmp/isoaliases  ISODE aliases database
          $HOME/.isode_aliases  user-specific aliases database

     SEE ALSO
          dsabuild(8c),
          The ISO Development Environment: User's Manual, Volume 1:
          Application Services, The ISODE Aliases Database.

     AUTHOR
          Marshall T. Rose

--------------------------------------------------------------

     NAME
          isoentities - ISODE entities database

     DESCRIPTION
          The isoentities file contains information regarding the
          known application-entity titles (AETs).  This file is used
          by the stub-directory service in ISODE.

          NB : Use of this database is deprecated.  Consult the ISODE
          User's Manual for further information.

          Entries are separated by blank lines (or the end-of-file).
          Items are separated by any number of blanks and/or tab
          characters, though double-quotes may be used to prevent
          separation between arguments.  The character '#' at the
          beginning of a line indicates a comment line.

          Each entry consists of four items: the first two, the designator
          and qualifier, for the object descriptor of the
          application-entity information (the distinguished designator
          default is used for a template entry); the third item is the
          object identifier of application-entity information in
          dot notation (if no application-entity information is desired
          the string NULL should be used instead); and the fourth item
          is  the entire presentation address expressed using the
          ISODE string format.  Note that since double-quotes are
          often used in the new string format, it is very important to
          quote them correctly in the isoentities file.  Usually
          preceding the first character of the address with single
          backslash is adequate.

          It is suggested for readability purposes that a blank line
          should seperate entries.

          Note that this database is used by the stub-directory service
          in ISODE.  A real directory uses an entirely different
          mechanism for resolving lookups.  The stub-directory mechanism
          in ISODE transforms the internal AET notion (the object
          identifiers) into one which appears to have come from a real
          directory (i.e., application-entity information).

     RFC1085 SUPPORT
          Since applications using RFC1085 (the lightweight presentation
          protocol) usually demultiplex on the basis of TCP or
          UDP port, a further definition for the qualifier is placed
          in /etc/services, one of:

               qualifier    portno/lpp
               qualifier    portno/tcp
               qualifier    portno/udp

          The first alternative says that the service lives on both
                  TCP and UDP; the second alternative says that the service
          lives on TCP only; and, the third alternative says that the
          service lives on UDP only.

     FILES
          /etc/snmp/isoentities  ISODE entities database

     SEE ALSO
          isobjects(5), isoservices(5),
          The ISO Development Environment: User's Manual, Volume 1:
          Application Services, The ISODE Entities Database.

     AUTHOR
          Marshall T. Rose
          with design conceptualization by Stephen E. Kille, University
          College London.

--------------------------------------------------------------

     NAME
          isomacros - ISODE macros database

     DESCRIPTION
          The isomacros file contains information regarding local macros
          for network addresses.

          Items are separated by any number of blanks and/or tab characters.
          However, double-quotes may be used to prevent
          separation between arguments.  The character '#' at the
          beginning of a line indicates a comment line.

          The first item is the macro, a simple string.  The second
          item is the prefix for the corresponding network address.

     USER-SPECIFIC MACROS
          By default a user-specific macros database is consulted
          before the system-wide macros file.  The user-specific file
          is called .isode_macros in the user's home directory.

     FILES
          /etc/snmp/isomacros  ISODE macros database
          $HOME/.isode_macros  user-specific macros database

     SEE ALSO
          isoentities(5),
          The ISO Development Environment: User's Manual, Volume 1:
          Application Services, The ISODE Macros Database,
          A string encoding of Presentation Address, S.E. Kille
          An Interim approach to use of Network Addresses, S.E. Kille

     AUTHOR
          Marshall T. Rose

--------------------------------------------------------------

     NAME
          isobjects - ISODE objects database

     DESCRIPTION
          The isobjects file contains information regarding the known
          objects on the host.

          Items are separated by any number of blanks and/or tab
          characters.  However, double-quotes may be used to prevent
          separation between arguments.  The character '#' at the
          beginning of a line indicates a comment line.

          The first item is the descriptor of the object, a simple
          string.  The second item is the corresponding object identifier.

     FILES
          /etc/snmp/isobjects  ISODE objects database

     SEE ALSO
          isoentities(5), isoservices(5),
          The ISO Development Environment: User's Manual, Volume 1:
          Application Services, The ISODE Objects Database.

     AUTHOR
          Marshall T. Rose

--------------------------------------------------------------

     NAME
          isoservices - ISODE services database

     DESCRIPTION
          The isoservices file contains information regarding the
          known services on the host.

          NB : Use of this database is deprecated.  Consult the ISODE
          User's Manual for further information.

          Items are separated by any number of blanks and/or tab
          characters.  However, double-quotes may be used to prevent
          separation between arguments in the vector.  The character
          '#' at the beginning of a line indicates a comment line.

          Each line consists of the name of the provider, a slash, and
          the name of the entity residing above the provider; the
          selector used to identify the entity to the provider; and,
          the program and argument vector to execvp when the service
          is requested.  If the selector starts with a hash-mark ('#')
          it is interpreted numerically as a decimal short-word quantity;
          otherwise if it appears in double-quotes, it is interpreted
          as an ascii string, with the usual escape mechanisms
          for introducing non-printable characters; otherwise, it is
          interpreted as an exploded octet string.

     FILES
          /etc/snmp/isoservices  ISODE services database

     SEE ALSO
          isoentities(5), isobjects(5),
          The ISO Development Environment: User's Manual, Volume 2:
          Underlying Services, The ISODE Service Database.

     AUTHOR
          Marshall T. Rose

--------------------------------------------------------------

     NAME
          isotailor - ISODE tailoring file

     DESCRIPTION
          The isotailor file contains information used to run-time
          configure the ISODE distribution.  Entries are separated by
          end-of-line (or the end-of-file).  The character '#' at the
          beginning of a line indicates a comment line.  The syntax
          is:

               variable: value

          as in

               sbindir: /usr/etc/

          The entries come in several types. There are general ISODE
          configuration parameters, operating system specific tailoring
          and interface specific tailoring parameters.

     LOCAL ENVIRONMENT TAILORING
          There are some variables that are used to make up for
          deficiencies in operating systems, or to override the operating
          system. These are described as follows.

          localname
               This takes a string as a parameter and is used as the
               name of the local host if the gethostname call (or
               equivalent, e.g., uname) is not used. This will also
               override any other run-time determination of the local
               hostname.

          binpath
               This takes a string as a parameter and indicates the
               directory where the ISODE user programs are kept (be
               sure to use a trailing slash).

          sbinpath
               This takes a string as a parameter and indicates the
               directory where the ISODE system programs are kept (be
               sure to use a trailing slash).

          etcpath
               This takes a string as a parameter and indicates the
               directory where the ISODE configuration files are kept
               (be sure to use a trailing slash).

     LOGGING TAILORING
          There are a number of options that can be set for each layer
          of ISODE.  The first variable indicates the default logging
          directory, the other variables give information about each
          log file.

          logpath
               This variable takes a string as a parameter and indicates
               the directory where the ISODE log files are kept
               (be sure to use a trailing slash).

          The remaining variables are all configured in the same way
          and are in the general format:

           xyzlevel: (none) (exceptions) (notice) (pdus) (trace) (debug) (all)
           xyzfile: filename

          The filename can be either the name of a file of a '-' in
          which case the standard error is used. If the filename contains
          the string '%d' then this is replaced by the current
          process id.

          The normal level for this style of tailoring is to set
          exceptions. The other two values can be added in when debugging,
          if so desired.  The current variables in this format
          are as follows.

               compatlevel  native services subsystem
               compatfile
               addrlevel    addressing subsystem
               addrfile
               tsaplevel    transport level
               tsapfile
               ssaplevel    session level
               ssapfile
               psaplevel    presentation elements
               psapfile
               psap2level   presentation level
               psap2file
               acsaplevel   association control level
               acsapfile
               rtsaplevel   reliable transfer level
               rtsapfile
               rosaplevel   remote operations level
               rosapfile
 

     TRANSPORT STACK TAILORING
          There are several variables which can be used to en/disable
          configured TS-stacks and to define OSI communities and their
          relationship to this system.

        TS-STACKS
          ts_stacks
               which takes one or more of the following values:

                    (tcp) (x25) (bridge) (tp4) (all)

               indicates which TS-stacks should be enabled.  This is
               useful when multiple machines (with different interfaces)
               share the same executables.  For example, the
               /etc/snmp/isotailor file is a normally symbolic link to
               /private/etc/snmp/isotailor.

        OSI COMMUNITIES
          ts_interim
               which takes one or more OSI community names as a value.
               Each community name must be defined as a macro in the
               isomacros (5) file.

          ts_communities
               which takes one or more of the following values:

                    (int-x25) (janet) (internet) (realns) (localTCP) (all)

               This variable is used to distinguish membership in
               various OSI communities.  For example, a site with an
               X.25 connection might be attached to the International
               X.25 network, but not the JANET.  Thus ts_stacks would
               include x25, and ts_communities would include int-x25
               but not janet.  Note that the ordering of communities
               is important: network addresses will be tried in the
               order that their respective communities are listed with
               this variable.

          default_nsap_community
               which takes an integer value, declaring the default
               community to be used for NSAP addresses.

          default_x25_community
               declaring the default community to be used for X.25
               (DTE) addresses.

          default_tcp_community
               declaring the default community to be used for TCP
               (RFC1006) addresses.

        TS-BRIDGE
          These are the parameters that are used in the Transport
          Service Bridge implementation.

          tsb_communities
               A list of pairs of values.  The first of each value
               should be a community as defined in the ts_communities
               variable (obviously the values none and all are not
               permissible).  The second value of the pair should be a
               presentation address using the ISODE string format.
               When a call is to be placed and the network corresponds
               to one of the communities given here, then a call
               through the bridge given in the second variable will be
               made automatically.

          tsb_default_address
               This variable contains a string encoded presentation
               address which the bridge will listen on by default.
               This should normally consist of a set of network
               addresses with no selectors present.

          Consider the case of a host with access to both the Internet
          and the International X.25 network.  This host might have
          this entry in its isotailor file:

               tsb_default_address: Internet=sheriff+17004\|Int-X25(80)=23426020
017299+PID+03018000

          This tells the bridge to listen on two network endpoints.
          Hosts in the Internet community wishing to reach the
          International X.25 community would have this entry in their
          isotailor file:

               tsb_communities: int-x25 Internet=sheriff+17004

          Similarly, hosts in the International X.25 community wishing
          to reach the Internet community, would have the entry:

               tsb_communities: internet Int-X25(80)=23426020017299+PID+03018000
 

     INTERFACE SPECIFIC TAILORING
          Most interfaces that ISODE runs over have some form of
          tailoring.  These are usually very dependent on the interface.
          Each interface which supports tailoring will now be
          described.

        General X.25 Tailoring
          There are two specific variables that can be used with any
          X.25 interface.

          x25_local_dte
               This is the X.121 address that ISODE processes will
               listen on by default.  It may be a full X.121 address
               or a sub-address.

          x25_local_pid
               This is the X.25 protocol ID that ISODE processes will
               listen on by default.  Traditionally, this is the first
               four octets of the CUDF in hex-notation, e.g.,
               03010100.

          There are also three variables for performing address
          manipulation as required by some network vendors.

          x25_intl_zero
               If this has the value 'on' then any international DTEs
               (i.e.  having non-local DNICs) will have a leading zero
               introduced before being passed to the network.

          x25_strip_dnic
               If this has the value 'on' then any local DTEs (i.e.
               having the local DNIC) will have this DNIC removed
               before being passed to the network.

          x25_dnic_prefix
               This should be set to the local DNIC (the first four
               digits of the DTE) of the host machine.  It should only
               be set if one or both of the previous two variables has
               the value 'on'.

          There are also two variables for logging X.25 statistics.

          x25level
               Defines the level of logging to be used for X.25
               statistics logging.  (At present, only notice level
               messages are generated.)

          x25file
               Defines the filename to be used for X.25 statistics
               logging.

        SUNLINK X.25
          These setting are only useful when SUN_X25 is defined along
          with X25.  The effect of these parameters is more fully
          documented in the Sun manuals.

          reverse_charge
               Set to 1 or 0 to enable/disable reverse charging.

          recvpktsize
          sendpktsize
               This should be set to one of 0 (default), 16, 32, 64,
               128, 256, 512 or 1024 to set the send/receive packet
               size.

          recvwndsize
          sendwndsize
               This sets the send/receive window sizes. Legal values
               are 0 (default), 7 and 127.

          recvthruput
          sendthruput
               This sets the sending/receiving throughput values.
               Legal values are 0 (default) 75, 150, 300, 600, 1200,
               2400, 4800, 9600, 19200, 48000.

          cug_req
               Closed user group request. Set to either 0 or 1.

          cug_index
               Sets the closed user group index number.

          fast_select_type
               Sets the fast select parameters. Either 0, 1 or 2.

          rpoa_req
                rpoa Recognised private operating agency parameters.

        CAMTEC CCL
          These are used when the Camtec X.25 is accessed via the CCL
          (sockets) mechanism.

          x25_outgoing_port
               This selects which port on the Camtec card will be used
               for outgoing calls, and takes the value A, B or #.  A
               and B are the two X.21 WAN interfaces and # is the Ethernet.
               Listening is automatically done on all three
               ports.

        BRIDGE X.25
          These are parameters that are used in the tp0bridge implementation.

          x25_bridge_host
               The host machine that is running the tp0bridge.

          x25_bridge_port
               This is the TCP port that is to be used for bridging.
               The default is 146, which should be in defined in
               /etc/services.

          x25_bridge_addr
               The X.121 address of the remote host.

          x25_bridge_listen
               The X.121 address to listen on for incoming calls, on
               the remote host.

          x25_bridge_pid
               The protocol ID used for listening along with the
               previous address.  This is encoded as a string of eight
               hex digits.

          x25_bridge_discrim
               A string used to discriminate the network. When
               attempting to place an X.25 call with BRIDGE_X25 and
               real X25 configured in, this string is used to decide
               which interface to use. If the string is empty, the
               bridge will be used. If it is set to '-' the bridge
               will not be used.  If the string is anything else, it
               is compared against the called X.121 address. If there
               is a match, then the bridge is used, otherwise the real
               interface is used.

     DIRECTORY SERVICES TAILORING
          There are two variables that can be tailored:

          ns_enable
               This takes either the string on or off as a parameter.
               If on, then the user-friendly nameservice" will be used
               to perform name/address resolution.  If the nameservice
               lookup fails, the stub-directory will be used as a
               fallback.

          ns_address
               This is the transport address of the nameservice.  It
               is specified using the ISODE string format, e.g.,
                    Internet=wp.psi.com+17006
               which indicates that the nameservice lives in the
               TCP/IP communications domain on TCP port 17006 at host
               wp.psi.com.  The nameservice is accessed via the OSI
               CO-mode transport service, so other kinds of addresses
               (e.g., X.25 addresses can be used as well).

     PROGRAM-SPECIFIC TAILORING
          By default a program-specific tailoring file is consulted
          before the system-wide tailoring file.  The program-specific
          file is called .myname_tailor in the user's home directory,
          where myname is the name that the program was invoked with.

     FILES
          /etc/snmp/isotailor   ISODE tailoring file
          $HOME/.myname_tailor  program-specific tailoring file

     SEE ALSO
          The ISO Development Environment: User's Manual, Volume 2:
          Underlying Services, The ISODE Tailoring File.

     AUTHORS
          Marshall T. Rose
          Simon Walton, University College London
 

--------------------------------------------------------------

     NAME
          libicompat - compatibility library

     SYNOPSIS
          cc ... -licompat

     DESCRIPTION
          The libicompat library makes an attempt of providing an
          interface for similar services under different operating
          systems.  Currently, the library works on most variants of
          Berkeley UNIX and AT&T UNIX.

     FILES
          None

     DIAGNOSTICS
     AUTHOR
          Marshall T. Rose

     BUGS
          To misquote M.A. Padlipsky, sometimes when you try to make
          an apple look like an orange you get back something that
          smells like a lemon.

--------------------------------------------------------------

     NAME
          libtsap - Transport Services library

     SYNOPSIS
          #include <isode/tsap.h>

          cc ... -ltsap

     DESCRIPTION
          The libtsap library contains a set of routines which implement
          transport services on top of the TCP.  In essence, they
          implement a Transport Service Access Point (TSAP) interface
          to the native TCP/IP implementation on Berkeley UNIX.

          Although the ISO model is symmetric, the TCP/IP model (and
          this implementation) is based on a client/server paradigm
          and hence asymmetric.  The information herein is skeletal:
          consult the User's Manual for actual examples of how ISO
          servers and clients are coded and interact with the libtsap
          library.

     ADDRESSES
          TSAP addresses are represented by the TSAPaddr structure.
          This contains one more more network addresses, and a
          transport-selector as found in the isoservices (5) database.

     SERVER INITIALIZATION
          A program providing an ISO service is invoked under
          tsapd (8c), with the argument vector listed in the ISODE
          services database.  The server's very first action is to
          re-capture the TSAP state as recorded by tsapd.  This is
          accomplished by calling TInit.  Information returned by this
          call is equivalent to the parameters passed by a
          T-CONNECTION.INDICATION event.  If the call is successful,
          the program can then examine the argument vector that was
          passed via execvp (it's important to call TInit prior to
          reading argc and argv).  If the call to TInit is not successful,
          information returned by the call indicates the reason for failure.

          After examining the information provided by TInit (and possibly
          the argument vector), the server should either accept
          or reject the connection.  If accepting, the TConnResponse
          routine is called (which corresponds to the
          T-CONNECT.RESPONSE action).  If the call is successful, the
          interaction is henceforth symmetric.  If un-successful,
          information returned by the call indicates the reason for
          failure.  If rejecting, the TDiscRequest routine is called
          (which corresponds to the T-DISCONNECT.REQUEST action), and
          the program may exit.

     CLIENT INITIALIZATION
          A program requesting an ISO service calls TConnRequest
          (which corresponds to the T-CONNECT.REQUEST action).  If
          successful, the interaction is henceforth symmetric.  If
          un-successful, information returned by the call indicates
          the reason for failure.

     TRANSPORT-DESCRIPTORS
          Once a connection has been established via a successful
          return from TConnResponse (for servers) or TConnRequest (for
          clients), a connection is referenced by a small integer
          (returned in a structure passed to these calls) called a
          transport-descriptor.  The transport-descriptor appears as
          an argument to the peer routines described below.

          By default, events associated with a transport-descriptor
          are synchronous in nature: activity in the network won't
          generate an INDICATION event without program first asking to
          be told of any activity.  To mark a transport-descriptor as
          asynchronous, a call to TSetIndications is made with the
          addresses of an integer function to handle these events:

               routine  events
               func1    T-DATA.INDICATION, T-EXPEDITED DATA.INDICATION
               func2    T-DISCONNECT.INDICATION

          Upon a successful return from TSetIndications, these functions
          will be called as appropriate in this fashion:

               (*func1) (sd, tx);

               (*func2) (sd, td);

          where sd is the transport-descriptor, tx is a pointer to a
          TSAPdata structure, and td is a pointer to a TSAPdisconnect
          structure.  Any value returned by these functions is
          ignored.

          Note well: the -ltsap library uses the SIGEMT signal to provide
          this interface.  Programs loaded with -ltsap that use
          asynchronous transport-descriptors should NOT use SIGEMT for
          other purposes.

          For synchronous multiplexing of several connections, the
          routine TSelectMask updates a file-descriptor mask and
          counter for use with select (2).

     PEER
          As a rule, a fatal failure (consult the User's Manual) on
          return from any of these routines is equivalent to a
          T-DISCONNECT.INDICATION.

               routine        action
               TDataRequest   T-DATA.REQUEST
               TExpdRequest   T-EXPEDITED-DATA.REQUEST
               TWriteRequest  T-WRITE.REQUEST (write user data vectors)
               TReadRequest   T-READ.REQUEST (synchronous read)
               TDiscRequest   T-DISCONNECT.REQUEST

          Note that the TReadRequest routine returns data from the
          peer by allocating memory.  It should be freed before the
          structure is re-used.

          Finally, the routine TErrString takes a failure code from a
          TSAPdisconnect structure and returns a null-terminated
          diagnostic string.  Also, the routine TLocalHostName returns a
          null-terminated string denoting the name of the localhost.

     FILES
          /etc/snmp/isoservices  ISODE services database

     SEE ALSO
          isoc(1c), isoservices(5), isod(8c), isore(8c), tsapd(8c),
          The ISO Development Environment: User's Manual,
          RFC1006: ISO Transport Services on top of the TCP, Version:
          3,
          ISO 8072: Information Processing Systems -- Open Systems
          Interconnection -- Transport Service Definition,
          CCITT Recommendation X.214: Transport Service Definition for
          Open Systems Interconnection (OSI) for CCITT Applications

     DIAGNOSTICS
          All routines return the manifest constant NOTOK (-1) on
          error.  In addition, those routines which take a pointer to
          a TSAPdisconnect structure fill-in the structure as
          appropriate.

     AUTHORS
          Marshall T. Rose
          Dwight E. Cass, Northrop Research and Technology Center

     BUGS
          Do not confuse transport-descriptors with file-descriptors.
          Unlike file-descriptors which are implemented by the kernel,
          transport-descriptors do not work across forks and execs.

--------------------------------------------------------------

     NAME
          libpsap - asn.1 presentation services library

     SYNOPSIS
          #include <isode/psap.h>

          cc ... -lpsap

     DESCRIPTION
          the libpsap library contains a set of routines which
          implement presentation syntax abstractions.  two primary objects
          are manipulated: presentation elements and presentation
          streams.

     PRESENTATION STREAMS
          a stream is an object, similar to a file* object in
          stdio (3), which is used to read and write elements.  a
          stream is created by calling ps_alloc with the address of an
          integer-valued routine that will initialize certain
          stream-dependent variables (presently, the read and write
          routines).  two standard initialization routines are available:
          std_open, which is used for presentation streams connected to
          stdio objects; and, str_open, which is used for
          presentation streams connected to string objects.  after
          ps_alloc successfully returns, final initialization is
          performed, usually by calling either std_setup with the stdio
          object to be bound; or, str_setup with the string object to
          be bound.  after the setup routine successfully returns, the
          presentation stream is ready for reading or writing.

          currently streams which have been initialized by these routines
          are uni-directional.  This might change in a future
          distribution.  Streams which have been initialized by
          std_open and str_open will automatically allocate additional
          resources when necessary, to the limits allowed by the
          operating system (e.g., repeated calls to a stream connected
          to a string object will result in additional memory being
          allocated from UNIX).

          Low-level I/O is done from/to the stream by the macros
          ps_read and ps_write.  These both call an internal routine
          which switches to the object-specific read or write routine
          as appropriate.  This internal routine, ps_io, implements
          the consistent presentation stream abstraction.

          Finally, when a stream has been exhausted, it can be closed
          and de-allocated with ps_free.

          The user may implement additional stream objects.  Examine
          the source to the std_ and str_ routines to understand the
          internal protocol and uniform interface.

     TRANSLATION
          The routine ps2pe can be used to read the next presentation
          element from a stream.  This routine returns a pointer to
          the element or NULLPE on error.  Similarly, pe2ps can be
          used to write a presentation element at the end of the
          stream.  This returns returns OK if all went well, NOTOK
          otherwise.  On errors with either routine, the ps_errno
          field of the stream can be consulted to see what happened.

          When writing to a presentation stream, the variable
          ps_len_strategy controls how long CONStructor types are
          represented.  If this variable is equal to PS_LEN_SPAG (the
          default), then the indefinite form is used whenever the
          length field of the element can not be represented in one
          octet.  If PS_LEN_INDF, then the indefinite form is used
          regardless of the length of the element.  Otherwise, if
          PS_LEN_LONG, then the indefinite form is never used.

          For debugging purposes, instead of treating a presentation
          stream as a binary object, the routines pl2pe and pe2pl can
          be used.  These translate between presentation lists and
          presentation elements.  A list is an ASCII text representation,
          with a simple LISP-like syntax which contains semantic
          information identical to its presentation stream counterpart.

     PRESENTATION ELEMENTS
          Once a presentation stream has been initialized and elements
          are being read, there are several routines that can be used
          to translate between the machine-independent representation
          of the element and machine-specific objects such as
          integers, strings, and the like.  It is extremely important
          that programs use these routines to perform the translation
          between objects.  They have been carefully coded to present
          a simple, uniform interface between machine-specifics and
          the machine-independent presentation protocol.

          A new element can be created with pe_alloc, and de-allocated
          with pe_free (see the warning in the BUGS section below).
          Two elements can be compared with pe_cmp, and an element can
          be copied with pe_cpy.

          A boolean is an integer taking on the values 0 or 1.  The
          routine prim2bool takes an element and returns the boolean
          value encoded therein.  Similarly, bool2prim takes a boolean
          and returns an element which encodes that value.

          An integer is a signed-quantity, whose precision is specific
          to a particular host.  The routine prim2int takes an element
          and returns the integer value encoded therein (if the value
          is NOTOK, check the pe_errno field of the element to see if
          there was an error).  The routine int2prim performs the
          inverse operation.

          An octetstring is a pair of values, a character pointer and
          an integer length.  The pointer addresses the first octet in
          the string (which need not be null-terminated), the length
          indicates how many octets are in the string.  The routine
          prim2oct takes an element and allocates a new string
          containing the value encoded therein.  The routine oct2prim
          performs the inverse operation, copying the original string
          (and not de-allocating it).

          A bitvector is an arbitrarily long string of bits with three
          operations: bit_on which turns the indicated bit on, bit_off
          which turns the indicated bit off, and, bit_test which
          returns a boolean value telling if the indicated bit was on.
          The routine prim2bit takes an element and builds such an
          abstraction containing the value encoded therein.  The
          routine bit2prim performs the inverse operation.

          A timestring represents a date/time in many forms.  Consult
          <isode/psap.h> for the elements in this structure.  The
          routines prim2utc and utc2prim are used to translate between a
          machine-specific internal form and the machine-independent
          form.

          Two list disciplines are implemented: sets, in which each
          member is distinguished by a unique identifier; and,
          sequences, in which each element is distinguished by its
          offset from the head of the list.  On both types of lists,
          the macro first_member returns the first member in the list,
          while next_member returns the next member.

          The routines prim2set and set2prim are used to translate
          between presentation elements and the set list; set_add may
          be called to add a new member to the set; set_del may be
          called to remove the identified member from the set; and,
          set_find may be called to locate the identified member.

          The routines prim2seq and seq2prim are used to translate
          between presentation elements and the sequence list; seq_add
          may be called to add a new element to the sequence; seq_del
          may be called to remove the identified element from the
          sequence; and, seq_find may be called to locate the
          identified element.

          With both lists, a convenient way of stepping through all
          the members is:

               for (p = first_member (pe); p; p = next_member (pe, p))
                   switch (discriminator) {
                       ....
                   }

          where discriminator is:
               PE_ID (p -> pe_class, p -> pe_id)

          for sets, and:

               p -> pe_offset

          for sequences.

     FILES
          None

     SEE ALSO
          pepy(1),
          The ISO Development Environment: User's Manual,
          ISO 8825: Information Processing -- Open Systems
          Interconnection -- Specification of basic encoding rules for
          Abstract Syntax Notation One (ASN.1),
          CCITT Recommendation X.409: Message Handling Systems:
          Presentation Transfer Syntax and Notation

     DIAGNOSTICS
          Most routines either return the manifest constant NULL (0) or NOTOK (-1) on error.  In addition, routines called with a pointer to a presentation stream also update the ps_errno field of the stream on error.  The routine ps_error returns
 a null-termianted diagnostic string when given the value of this field.  Similarly, routines called with a pointer to a
          presentation element also update the pe_errno field of the
          stream on error.  The routine pe_error returns a
          null-termianted diagnostic string when given the value of
          this field.

     AUTHOR
          Marshall T. Rose

     BUGS
          A virtual presentation element option should be available to avoid reading everything in-core during parsing.

          When using pe_free on an element, care must be taken to remove any references to that element in other structures. For example, if you have a sequence containing a sequence, and you free the child sequence, be sure to zero-out the parent's pointer to the child, otherwise subsequent calls using the parent will go romping through hyperspace.

9595 Main Page