**********************************************************************
README.UTL for Multi-Protocol Transport Services               10/13/95

                          Table Of Contents

SECTION 1: Applets
         1.1 - NBJDSTAT
         1.2 - DTF4
         1.3 - MCL
         1.4 - SNIFFLE
         1.5 - NETPING
         1.6 - LAPSDUMP
         1.7 - MAPNAME
         1.8 - CASSETUP
         1.9 - OS2SNIFF
         1.10 - NB64K
         1.11 - NETTRACE
         1.12 - XTRACE
         1.13 - HOSTID

SECTION 2: Toolkit Files for Developers

SECTION 3: LAN CID Utility
         3.1 - NEW CID RETURN CODES
         3.2 - Warp Server LCU CID Installation from CD-ROM

===============================================================================
SECTION 1                       APPLETS

    The APPLET directory contains 13 MPTS utilities.  These applications
    are supplied "as is" and IBM does not provide any support for these
    programs.


1.1 - NBJDSTAT

    NBJDSTAT issues a NETBIOS STATUS command for either a local or remote
    workstation and displays the NCB STATUS information to the screen.
    NCB.STATUS information can be useful when you are doing system
    configuration and application debug.  It includes such information as
    the adapter's encoded address, the NetBIOS release number, and the local
    name  table. For more information on the status command, see the
    "IBM LAN Technical Reference" (SC30-3383-XX), Chapter 4.
    NetBIOS must be loaded before this utility can produce meaningful results.

    NBJDSTAT is case sensitive and the command line options are:

 Usage:nbjdstat remote_name options

     remote_name:NETBIOS name to find(length: 16 characters [case sensitive])
        If the name is less than 16 characters, blanks(0x20) are appended.
        * specifies local name.
     options:
        /a  :specifies adapter to use (default:0) - valid:0,1,2,3
        /h  :intrepet value as hex value and append to remote name
             example: SERVER1 /h20
             entire remote name may be specified as hex value
             example: /h41555320202020202020202020202020
        /m  :to make the name as IBM LS messager name
        /n  :to append 0x00 to the name up to 16 characters
        /q  :to make the name as IBM LS requester name
        /v  :to make the name as IBM LS server name
        /rxy:to make the name as IBM DB2/2 requester name
             x can be: s(sql name); i(interrupt name)
             y can be: 0(adapter 0); 1(adapter 1)
        /sxy:to make the name as IBM DB2/2 server name
             if x: is c(catcher name))
             y can be: 0(adapter 0); 1(adapter 1)
             if x: is b(callback name)
             y can be: p(primary adapter); s(secondary adapter)

    An example of its use for the local workstation's NetBIOS Status is:
                    nbjdstat *

    An example of its use for LS Server NetBIOS name SERVER1 and redirecting
    the output to a file, is:
                    nbjdstat SERVER1 /v > nbjdstat.out


1.2 - DTF4

    DTF4 formats LAN trace points from TRACEFMT output.  This information
    can be useful when you are debugging LAN applications.  The following
    statements must be in CONFIG.SYS before you can use the system trace
    utility:

           TRACEBUF=63
           TRACE=ON 164

    You can then use TRACEFMT to produce a file containing the trace
    information.  After you have successfully saved the system trace
    information into a file, you can use DTF4 to format the LAN trace data
    into a readable format.  For more information on TRACEFMT, on OS/2 1.3
    systems issue HELP TRACEFMT on the command line.  On OS/2 2.x systems,
    enter TRACEFMT on the command line.  Then select HELP from the action
    bar. NOTE !! when using OS/2 2.x TRACEFMT, you *MUST* save the output
    as FORMATTED. (see TRACEFMT help for more information)

    An example of its use for the system trace information file
    TRACEFMT.SAV would be to type the following at an OS/2 command prompt:

                  DTF4 tracefmt.sav > tracefmt.dtf /T

    The /T parameter provides the ASCII interruption of the transport frames.


1.3 - MCL

    MCL outputs the microcode level and adapter address of up to four
    Token Ring adapters.  This utility provides a quick way to
    determine the microcode level  as well as the universal and encoded
    adapter addresses for IBM Token Ring adapters.  802.2 support (LANDD.OS2)
    is required for this program.


1.4 - SNIFFLE

    SNIFFLE is a stand alone utility that is intended to aid in the
    development of network information files (NIFs).  Invoked against
    one or more NIFs, SNIFFLE ensures that the NIF sections, keywords, and
    values are consistent both with the extended NIF format definition
    and with each other.  For more information on the extended NIF format
    definition, see the "IBM OS/2 NDIS Driver Implementation Package".
    If an error is detected, SNIFFLE indicates the location of the error
    and provides a description of the error condition.

    An example of its use for the IBMTOK.NIF would be to type the following
    at an OS/2 command prompt.

                        SNIFFLE IBMTOK.NIF


1.5 - NETPING


    NETPING is a NetBIOS utility that executes a NETBIOS NCB.FIND.NAME.
    Command line options provide the capability of searching for various
    application's NetBIOS names, such as LAN Server and DB2/2.
    If the NetBIOS name is present on the LAN, the following information
    will be displayed:

         - NetBIOS name type
         - Node Address
         - Routing Information (if name was not found on local segment)

    NETPING is case sensitive and the command line options are:

           /a  :specifies adapter to use (default:0)
                valid adapter: 0,1,2,3
           /m  :to make the name as IBM LS messager name
           /n  :to append 0x00 to the name up to 16 characters
           /q  :to make the name as IBM LS requester name
           /v  :to make the name as IBM LS server name
           /rxy:to make the name as IBM DB2/2 requester name
                x can be: s(sql name); i(interrupt name)
                y can be: 0(adapter 0); 1(adapter 1)
           /sxy:to make the name as IBM DB2/2 server name
                if x: is c(catcher name))
                y can be: 0(adapter 0); 1(adapter 1)
                if x: is b(callback name)
                y can be: p(primary adapter); s(secondary adapter)

    An example of its use for LS Server NetBIOS name SERVER1, searching on
    adapter 1 is:   netping SERVER1 /a1 /v


1.6 - LAPSDUMP


    LAPSDUMP is an utility that extracts memory segments from the LAN Adapter
    and Protocol Support (LAPS) modules and formats/dumps that memory.
    The command options for LAPSDUMP are:

         /fl     : format the LANDD (802.2) memory segments
         /fn     : format the NETBEUI/NETBIOS memory segments
         /fy     : format only the NETBIOS memory segment
         /a      : specifies primary (0) or an alternate (1|2|3) adapter
         /d      : in addition to formatting, dump the specified memory areas

    Formatting all segments is the default.

    An example of its use for formatting all segments on adapter 0 and
    redirecting the output to a file (req1.dmp) is:

                       lapsdump > req1.dmp


1.7 - MAPNAME


    MAPNAME is a utility which encodes NetBIOS names into the format used
    by NetBIOS over TCP/IP (RFC-encoded name).  MAPNAME also decodes
    the RFC-encoded name into a standard NetBIOS name.  The primary use
    for this utility is to aid entry of NetBIOS names in the RFC-encoded
    format into a TCP/IP domain name server.

    Command format: mapname input /fdblxx
      input: a) filename.LST or filename.RFC
             b) name(max. 16 char. for NB name, and 32 char. for RFC name)
                - name can be any char.+ \xDD in any order, surrounded by "[]".
                - D is hex digit(\xDD = one char.).
          f: indicates the file I/O(default is name.)
          d: indicates the I/O direction
             a) r: NETBIOS -> RFC
             b) n: RFC - > NETBIOS
          b: pending blanks up to 16 char.(default is null char.).
        lxx: indicates last char.(xx can be any hex value)

   NOTE: "b" and "lxx" options are not supported for file I/O conversion.


    Examples:
    mapname station1.lst /fr                 input: file station1.lst
                                            output: file station1.rfc
                                         direction: NETBIOS -> RFC

    mapname station1.rfc /fn                 input: file station1.rfc
                                            output: file station1.net
                                         direction: RFC -> NETBIOS

    mapname station1\x85name\x86 /r            input: name station1…name†
                                            output: name(RFC format)
                                         direction: NETBIOS -> RFC

    mapname station1 /rbl20                    input: name station1 as SRV name
                                            output: name(RFC format)
                                         direction: NETBIOS -> RFC


1.8 CASSETUP -- code server setup utility

        Contents:

        1.8.1  An introduction to CASSETUP

        1.8.2  What to do first
               1.8.2.1  Installing CASSETUP
               1.8.2.2  Loading Srvifs/LAN CID Utility Support
               1.8.2.3  Loading OS/2, MPTS and LS 4.0 images
               1.8.2.4  Pruning the list of load-able applications

        1.8.3  Restrictions
               1.8.3.1  General
               1.8.3.2  Closing CASSETUP from the Windows List
               1.8.3.3  CASPREP files and command files generated by CASSETUP.
               1.8.3.4  Creating OS/2 2.1 boot diskettes on a workstation
                        running OS/2 2.11
               1.8.3.5  Long path names
               1.8.3.6  Multiple instances of CASSETUP
               1.8.3.7  Building Boot Diskettes on drive B:


1.8.1  An introduction to CASSETUP

        CASSETUP provides a single graphical interface for several
        common tasks involved in installing CID enabled products over
        the network.  It allows you to:

        - install Srvifs/LAN CID Utility Support which consists of:

          . The LAN CID Utility

          . Srvifs (a simple file server)

        - load application install images from diskettes or
          CD ROM onto a Code Server,

        - build boot diskettes for use with LAN CID Utility, and

        - create CASPREP files which can be used to generate
          LAN CID utility command files.

        A big advantage of this version of CASSETUP is that it can
        handle many different applications.  To add an application to
        the set that CASSETUP understands, you simply add an application
        profile to the profiles directory.  See the online documentation
        for information on application profiles.  Similarly, to build
        new kinds of boot diskettes (with a different version of OS/2,
        perhaps) you just create a diskette-build script, using the
        provided scripts as a template.


1.8.2  What to do first

        To get started, do these steps:

        - Install CASSETUP (see section 2.1)
        - After rebooting, review the online documentation by issuing
          the command
                        view cassetup.inf
          from the directory where you installed CASSETUP.
        - Invoke CASSETUP by double clicking on the desk-top icon.
        - Install Srvifs/LAN CID Utility Support (see section 2.2)
        - Load OS/2, MPTS, and LS 4.0 install images (see section 2.3)
        - If you wish, prune the list of applications that can be loaded
          (see section 2.4)
        - Load application images as needed.

1.8.2.1 Installing CASSETUP.

        CASSETUP is located on the MPTS diskette 3. The CASSETUP files
        are packed in a file called CASSETUP.ZIP in the \APPLETS
        directory on the MPTS diskette 3.

        Installing from MPTS diskette 3
        -------------------------------

        To install CASSETUP from MPTS diskette 3, perform the following
        steps:

        -- To unpack the CASSETUP files into the desired directory, insert
           the MPTS diskette 3 into drive A: on the code server and
           issue the following command:

              PKUNZIP2 A:\APPLETS\CASSETUP.ZIP <path>\CASSETUP

           Note:  If PKUNZIP2.EXE is not in a directory that is in the
                  current path, you may copy the PKUNZIP2.EXE program from
                  the root directory of MPTS diskette 1 into a directory
                  that is in the current path.

        -- To initialize CASSETUP files and put the CASSETUP icon on
           the desktop, issue the following command:

              <path>\CASSETUP\CASINST


        Installing from a code server
        -----------------------------

        The complete instructions on how to install CASSETUP from a code
        server are located in the CASSETUP.INF file packed in the file
        CASSETUP.ZIP in the \APPLETS directory on the MPTS diskette 3.
        CASSETUP.INF would be located in the <path>\CASSETUP directory
        on the code server if you followed the installation instructions
        in Installing from MPTS diskette 3.

        After installation, shut down and reboot your system.

1.8.2.2 Loading Srvifs and LAN CID Utility Support

        To load LAN CID Utility and Srvifs, do these things:

        - Display the Code Server Setup Container window by double clicking
          on the Code Server Setup icon on your desktop.

        - Display the Code Servers Container window by double clicking
          on the Code Servers icon in the Code Server Setup Container
          window.

        - Select the "Selected" from the Code Servers Container window
          menu bar, select "Srvifs/LAN CID Utility support", and then
          select "Load...".  This will cause the Load Srvifs/LAN CID
          Utility Support window to be displayed.

        - Select the OK pushbutton to start the load if the defaults are
          acceptable.

        If the defaults that have been provided are not exactly what you
        want then you can do the following:

        - You can accept the default Srvifs server target path or specify
          one of your own.  The default is "x:\server", where x is the
          drive where the Code Server Setup files were installed.  This
          target path determines where the Srvifs server files will be
          loaded.

        - You can accept the default source image path or specify one of
          your own.  The default is "A:".  This can be any valid drive
          and path, and must be accessible at this time.

        - The Srvifs Client/LAN CID utility target is a composite of
          an alias and an optional path extension.  The aliases that
          come with the Code Server Setup utility are:  READONLY and
          READW (read/write).  Both of these are associated with the
          drive where the Code Server Setup files were installed.  These
          can be modified (delete and add) or you can create new
          aliases.  READONLY is the default alias and the default path
          extension is blank.

        The path to the Srvifs client/LAN CID utility cannot exceed 227
        characters.  If you enter a combination of alias and path that
        exceeds this amount you will receive a error message showing the
        path and the number of characters over this limit.

        - Select the OK pushbutton to start the load.

1.8.2.3 Loading OS/2, MPTS, and LS 4.0 images

        Obtain the install diskettes for OS/2 Version 2.1 or Version
        2.11.  Also obtain either the LAN Server 4.0 install diskettes
        or the LAN Server 4.0 Install CDROM.

        Start CASSETUP by double clicking the CASSETUP icon.

        Open the Code Servers object by double clicking on it.

        Open the Applications object by double clicking on it.

        Drag the icon representing your OS/2 version onto the code
        server icon.  Follow the instructions on the screen to load the
        images.

        Drag the icon representing MPTS for your media onto the code
        server icon.  Follow the instructions on the screen to load the
        images.

        Drag the icon representing LS 4.0 for your media and package
        onto the code server icon.  Follow the instructions on the
        screen to load the images.  Drag the icon representing LS 4.0
        requester for your package onto the code server icon.  Select
        the Register radio button and then select OK.

        Now you are ready to put more images on the code server, or to
        generate CASPREP files, convert them to command files, or create
        client boot diskettes.

1.8.2.4 Pruning the list of load-able applications

        The Applications container shows each of the applications (and
        variations of applications) for which images can be loaded on
        the code server.  You may not be interested in all these
        applications.  For example, if you have purchased the LAN Server
        4.0 Advanced package on CDROM, you may not have a need to load
        images for LAN Server 4.0 Entry on diskette.

        You can keep unneeded applications from appearing in the
        container by moving the Application Profiles associated with the
        applications to another directory.  The LAN Server-related
        Application Profiles are:

             ls40a.pro         - LAN Server 4.0 Advanced Server on diskette
             ls40cda.pro       - LAN Server 4.0 Advanced Server on CDROM
             ls40areq.pro      - LAN Server 4.0 Advanced Requester
             ls40e.pro         - LAN Server 4.0 Entry Server on diskette
             ls40cde.pro       - LAN Server 4.0 Entry Server on CDROM
             ls40ereq.pro      - LAN Server 4.0 Entry Requester

        If you will just be installing LS4.0 Advanced from the images
        shipped on CDROM, issue the following commands to remove the
        unneeded profiles.  Assume that CASSETUP is installed in
        d:\cassetup.

             d:
             CD cassetup
             MD probkup
             MOVE ls40a.pro probkup
             MOVE ls40e.pro probkup
             MOVE ls40cde.pro probkup
             MOVE ls40ereq.pro probkup

        If you find later that you need to install one of these
        application images, reverse the MOVE command to put the
        application profile back in the main CASSETUP directory.


1.8.3  Restrictions

1.8.3.1 General.

        CASSETUP is supplied as an applet.  Use it as-is.
        No support is provided for CASSETUP.

1.8.3.2 Closing CASSETUP from the Window List.

        If you close CASSETUP from the Workplace Shell Window List,
        changes you have made to notebook settings may not be preserved.
        Always close CASSETUP from the main dialog's system menu.

1.8.3.3 CASPREP files and command files generated by CASSETUP.

        Always carefully examine the CASPREP files and command files
        generated by CASSETUP.  They are designed to generate all the
        information needed to install the selected applications, but
        their content depends on the data in the application profiles.
        Refer to the LAN CID utility documentation for more information
        about CASPREP files and command files.

1.8.3.4 Creating OS/2 2.1 boot diskettes on a workstation running OS/2 2.11.

        The program used to create OS/2 boot diskettes is sensitive to
        the level of the operating system under which it is being run.
        If the operating system on your workstation is OS/2 version
        2.11, you will not be able to created boot diskettes for OS/2
        version 2.1 or earlier.  The work-around for this is to do the
        following steps from an OS/2 command line:

        - change to the directory that contains the OS/2 2.1
          version of SYSINSTX.COM.  This is the DISK_0 subdirectory
          of the install images.  For example

                cd d:\CID\IMG\OS2V21\DISK_0

        - Create a backup copy of the OS/2 2.1 SYSINSTX.  For example

                copy SYSINSTX.COM SYSINSTX.BKP

        - Replace the OS/2 2.1 SYSINSTX with the version for the
          operating system running on your workstation.  (This requires
          that you have the install diskettes for your current
          version of OS/2, or that the current version also be loaded
          on the code server.)

          If you have the install diskettes for your current version,
          you might put the first diskette ("boot" diskette) in drive
          a: and issue

                copy A:\SYSINSTX.COM .

          If you have your current version's images loaded on the code
          server, the command might be

                copy d:\CID\IMG\OS2V211\DISK_0\SYSINSTX.COM .

        - Build the boot diskettes using CASSETUP

        - Restore the OS/2 2.1 SYSINSTX.COM by issuing commands similar to

                cd d:\CID\IMG\OS2V21\DISK_0
                copy SYSINSTX.BKP SYSINSTX.COM

1.8.3.5 Long path names

        In some cases, very long path names (greater than about 250
        characters) may not be properly removed by CASSETUP.  If this
        occurs, remove the paths manually.

1.8.3.6 Multiple instances of CASSETUP

        Only one instance of CASSETUP.EXE should be running at any one
        time.  Multiples can be started, but the modifications that
        result from one or more of the instances of CASSETUP.EXE can be
        lost.  The loss of these changes is not always predictable.

1.8.3.7 Building Boot Diskettes on drive B:

        When you create boot diskettes on a boot drive other than A:,
        manual steps are needed to make the diskettes able to boot from
        drive A:.  Using a text editor such as E or EPM, edit the
        config.sys on the second boot diskette.  Change all instances of
        B:\ to A:\ and save the changes back to the diskette.


1.9 - OS2SNIFF


        Network adapter detection (OS2SNIFF.EXE) is one of the new applets
        of NTS/2. This applet will detect network adapters installed on the
        user workstation.

        To execute OS2SNIFF.EXE, the files NCD.DLL and NCD.MSG must be in a
        directory that is in the PATH/DPATH statement of the config.sys. From
        an OS/2 command prompt execute OS2SNIFF.  The following information
        will be displayed:

                           CARD TITLE:
                           LS SUPPORTED:
                           NIF FILENAME:
                           I/O LENGTH:
                           RAM LENGTH:
                           BUS TYPE:
                           SLOT:
                           ID NUMBER:

        Network adapter detection has the ability to recognize different types
        of adapters installed in micro-channel architecture (MCA), extended
        industry standard architecture (EISA), and industry standard
        architecture (ISA) bus computers.  Different methods are used to
        detect network adapters on MCA, EISA, and ISA computers.

        Network adapters used in MCA bus computers are detected via their
        programmable option select (POS) ID.  Each MCA network adapter has
        a unique POS ID.  This POS ID corresponds to an adapter definition
        file (ADF) shipped with each MCA adapter.  In detecting the network
        adapters, each slot that contains an adapter in the computer is
        interrogated for its POS ID.  The returned POS IDs from the
        interrogation are cross checked with an internal table specifically
        for MCA network adapters to determine if they are recognizable.
        The network adapter detection function then passes the detected
        adapters along with their specific information back to the
        configuration/installation program.

        Network adapters used in EISA bus computers are detected via their
        expansion board identifier (product ID).  Each EISA network adapter
        has a unique product ID.  This product ID corresponds to a
        configuration (CFG) file shipped with each EISA adapter.  Detecting
        EISA network adapters is similar to detecting MCA network adapters.
        Each slot containing an adapter is interrogated.  The returned product
        IDs from the interrogation are cross checked with the internal table
        specifically for EISA network adapters to determine if they are
        recognizable.  There are some ISA network adapters that have a CFG
        file so that the network adapter could be configured as an EISA
        network adapter via the EISA configuration utility.  These network
        adapters are also recognized using the EISA detection methodology.

        Network adapters used in ISA bus computers are detected via information
        returned from the combination of the adapter input/output (I/O)
        ports, the range of the read-only memory (ROM) address, and the range
        of the random access memory (RAM) address.  Information such as I/O
        port, range of ROM and RAM addresses are obtained from technical
        specifications from the network adapter's manufacturer.  A specific
        routine is written for each recognizable network adapter.  This
        routine may manipulate the adapter's I/O ports and scan the ROM and
        RAM address ranges to find the unique signature that is identify
        with the card.



1.10 - NB64K

       The NETBEUI environment space must fit within 64k.  NB64K will help
       maximize the usage of these 65535 bytes.

       Various settings located in the PROTOCOL.INI file affect how much
       memory NetBIOS allocates for NETBEUI.  Enter the desired values in
       the Commands (NCBS), Names, Packets, Selectors, Datagram Packets,
       and Loop Packets fields; then hit the calculate push button to
       determine if this configuration is possible.  You will receive a
       warning if the size exceeds 64k.

       This program will work with NETBEUI.OS2 drivers from earlier releases,
       however, the overhead and size multipliers will be a close estimate.

       Once a suitable configuration is obtained, update the PROTOCOL.INI
       file using the MPTS configuration utility.

       NB64K.HLP must be located in the DPATH statement of the config.sys.


1.11 - NETTRACE

       NETTRACE.EXE will set/reset the OS2TRACEMASK parameter for NetBEUI.
       Running it from the command line with no options will give you the
       current setting. The syntax is:

                            NETTRACE 0xFFFF


1.12 - XTRACE

       Extended Trace works by first turning on OS/2 Trace.  Then it checks
       the 63K byte system trace buffer every so often, and if "full enough"
       copies the new trace therein to a larger buffer of its own in memory.
       Between checks of the system trace buffer, it puts itself to sleep,
       giving up CPU.  Once the larger buffer (the Extended Trace Buffer)
       becomes "full enough", its contents are dumped to a binary file on the
       hard drive.  This file is treated as a circular buffer much like the
       system trace buffer is, only can be much larger (many megabytes).
       The Extended Trace program, once started, runs in the background,
       detached from the session in which it was started.

       Once Extended Trace has been stopped, Extended Trace Format can be
       invoked.  This program traverses the raw trace contained in the file
       that was produced by Extended Trace and formats it.   If trace at any
       point was lost for whatever reason, a message stating so is written
       at that point in the formatted file.  The Extended Trace Format program
       runs in the foreground, returning control when formatting is complete.

       NOTE:  Extended Trace Format looks for raw trace file produced by
              Extended Trace in the current directory, so run Extended Trace
              and Extended Trace Format in the same directory.

       In the current version, not only are the raw trace file and formatted
       trace file produced, but 'flight recorder' files are produced.  One
       other file is produced, which allows Extended Trace to communicate
       with Extended Trace Format any parameters or information needing to
       be shared between them.  This file must NOT be erased or modified
       between the time Extended Trace and Extended Trace Format are run.


       Here are the names of the files produced:

       XTRACE.RAW    -- raw trace stored here
       XTRACE.FMT    -- formatted trace stored here
       XTFLIGHT.DAT  -- flight recorder information for Extended Trace
       XFFLIGHT.DAT  -- flight recorder information for Extended Trace Format
       XTARGS.DAT    -- infomation shared between the two

       To install, follow these step:
       1. Make sure that following files are in a directory in the PATH
          statement:
                      XTRACE.EXE
                      XTFORMAT.EXE
                      XTWAD.EXE
       2. Move FINDSTDA.SYS to a directory you wish to leave it in.
       3. Add the following lines to CONFIG.SYS:
                      device=pathname\FINDSTDA.SYS
                      tracebuf=63
          where pathname is the path in which FINDSTDA.SYS resides.
          NOTE: Extended Trace will NOT work if the trace buffer size is
                set to anything other than63K bytes.
       4. Shutdown and reboot the system to activate the device driver and
          make it possible to use Extended Trace and Extended Trace Format.

       Extended Trace has been implemented as an OS/2 executable, XTRACE.EXE,
       to be called similarly to the executable TRACE.EXE that is shipped
       with OS/2.  Arguments specific to Extended Trace must be specified
       between the program name (XTRACE) and the "ON" keyword, while arguments
       to be passed to OS/2 trace must be specified after the "ON" keyword.
       To invoke Extended Trace, issue the program name, XTRACE, as one
       would, in general, to run any OS/2 executable program, with arguments
       appropriate for tracing whatever is desired or for turning Extend Trace
       off.

       The format for turning Extended Trace ON is the following:

          XTRACE (Extended Trace options) ON (OS/2 trace options)

       Extend Trace options are specified wth a forward slash ("/") followed
       immediately by the option name, a space, and the value desired for
       that option.  When turning Extended Trace ON, any option that is
       supported by regular OS/2 Trace is also supported and can be
       specified exactly as for OS/2 Trace, immediately following the "ON"
       keyword in the command.

       OPTION   DESCRIPTION                         MIN     MAX     DEFAULT
       ---------------------------------------------------------------------
       XS       eXtended trace buffer size (Kbytes)  63     1024      512
       FL       Formatted trace file size Limit       1   102400     4096
       ST       System trace buffer full Threshold    0%      90%      40%
       XT       eXtended trace buffer full Threshold  0%      90%      70%
       WC       Wait between Copies to extended
                trace buf, in milliseconds           100    10000     500
       WB       Wrap Buffer if full, rather than
                stopping trace (YES/NO)              N/A      N/A     YES
       KS       Keep Statistics, output when
                XTRACE turned off (YES/NO)           N/A      N/A     YES

       The following is an example:

                    XTRACE ON 164
                    XTRACE /XS 400 /WC 1000 ON 164
                    XTRACE /FL 8192 ON /P:002
                    XTRACE OFF

       When turning Extended Trace OFF, no special options are supported; the
       command
                    XTRACE OFF

       will turn Extended Trace off completely (for ALL trace points).  Note
       that this deviates from normal OS/2 TRACE, which supports not only
       turning TRACE off fully, but also turning off only selected tracepoints
       and options, while leaving others on.  If turning only selected
       tracepoints is desired, this can be done directly by the user through
       execution of the OS/2 Trace program, e.g.:

                    TRACE OFF 164

       To invoke Extended Trace Format, simply enter XTFORMAT on the command
       line.  Extended Trace Format will then format the raw trace file in
       the current directory, producing a text formatted trace file.  It
       runs in the foreground and does not return until the formatting job
       is done.

       NOTE:  The size of the formatted trace file may be less than that
              specified with the /FL option, since XTRACE may not have
              been run long enough to capture an amount of trace that,
              when formattted, would file that large a file.

       NOTE:  Time taken to format the raw trace file is directly related to
              the amount of raw trace there is to format.  It may take many
              minutes to complete the formatting if many megabytes of formatted
              output is to be produced.

       Below are examples of three trace records formatted by Extended Trace
       Format as they would appear in the formatted output file.  This data
       in the event specifier line for each record (except for the optional
       timestamp) are displayed in hexadecimal.  Note that if there is no
       timestamp, the TS field is left out altogether.  Also note that,
       just as in the case of OS/2 TRACEFMT, data follows the event
       specifier line, is broken up byte-to=byte, and also is displayed in
       hexidecimal.  The sizes of the fields in the trace record header line
       are constant throughout th formatting, i.e. each will always start
       in column and have the same number of digits.

        EVENT #00029 : maj=08, min=003B, PID=0011, TS=131.44
        03 B2 11 07 68 11 00 00 00 00 A0 01 00 00 23 FF
        1D 00 00 2B 08

        EVENT #0002A : maj=01, min=0008, PID=0004
        00 01 FF

        EVENT #0002B : maj=1E, min=0002, PID=0001, TS=009.21

       The formatting of trace records is plain in order to conserve space.
       No interpreting or parsing of the data within the records is done,
       unlike OS/2 TRACEFMT.  However, the expansion ratio from raw trace
       file size to formatted trace file size is much lower with Extended
       Trace Format than it is with OS/2 TRACEFMT.

       The internal formats of raw trace files produced by OS/2 TRACEFMT
       (when the option to dump the raw trace to disk is selected) and by
       the Extended Trace are not compatible.  This means that one cannot
       use OS/2 TRACEFMT to format raw trace generated by Extended Trace,
       nor can one use Extended Trace Format to format raw trace generated
       by OS/2 TRACE.


1.13 - HOSTID

       HOSTID.EXE allows the user to change the Primary IP Address of the
       system.

       Usage: hostid

       will display the current Primary IP Address.

       Usage: hostid a.b.c.d

       will set the Primary IP address of the system to a.b.c.d
       where a.b.c.d is a valid IP address.



===============================================================================

SECTION 2: TOOLKIT FILES FOR DEVELOPERS


    The TOOLKIT directory contains files to aid in development of
    NetBIOS and Socket applications.  \TOOLKIT\LAPSTK.ZIP
    contains the files for LAPS development and is located on
    MPTS Disk - 4.  \TOOLKIT\MPTNTK.ZIP contains the files for
    Socket development and is also located on MPTS Disk - 4.

    To install LAPS Toolkit files from MPTS Disk - 4, perform the
    following steps:

    -- To unpack the LAPS files into the desired directory, insert
       the MPTS Disk - 4 into drive A: on the code server and type the
       following command:

       PKUNZIP2 -d A:\TOOLKIT\LAPSTK.ZIP <e:\path>

    To install Socket Toolkit files from MPTS Disk - 4, follow these
    steps:

    -- To unpack the Socket files into the desired directory, insert
       MPTS Disk - 4 into drive A: on the code server and type the
       following command:

       PKUNZIP2 -d A:\TOOLKIT\MPTNTK.ZIP <e:\path>


    Example of putting the LAPS developer toolkit files onto drive C:

       PKUNZIP2 -d A:\TOOLKIT\LAPSTK.ZIP C:\

    Note:  If MPTS is not installed on the workstation on which you are
           unpacking LAPS Toolkit, you must copy the PKUNZIP2.EXE program from
           the root directory of MPTS Disk - 1 into a directory that is  in
           the current path.



===============================================================================

SECTION 3:  LAN CID UTILITY

__________________________
3.1 - NEW CID RETURN CODES

    The CID architecture has define a new range of CID return codes which
    are now implimented by the LAN CID Utility (LCU).

    The defintions of the new CID return code ranges implimented in LCU are
    as follows:

 FE 00 TO FE 3F

 EXPLANATION:  Successful Program Termination- Reboot and do not invoke again

           FE 01 TO FE 03  This range of Return Codes is reserved for
                           CID-Enabled Applications that want the flexibility
                           of specifying product specific Return Code defi-
                           nitions. Products must of course then document the
                           meaning of these Return Codes used from this range.
                           The defined SDM action for this range is:
                           Successful program termination-- Reboot and do not
                           invoke again.

           FE 05 TO FE 07  Same as FE 01 to FE 03

           FE 09 TO FE 11  Same as FE 01 to FE 03

           FE 13 TO FE 3F  Same as FE 01 to FE 03

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


 FE 40 TO FE 7F

 EXPLANATION:  Successful Program Termination-No Reboot

           RETURN CODE     DESCRIPTION

           FE 40 TO FE 7F  This range of Return Codes is reserved for
                           CID-Enabled Applications that want the flexibility
                           of specifying product specific Return Code defi-
                           nitions. Products must of course then document the
                           meaning of these Return Codes used from this range.
                           The defined SDM action for this range is:
                           Successful program termination--No Reboot

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


 FE 80 TO FE FF

 EXPLANATION:  Unsuccessful Program Termination-No Reboot

           RETURN CODE     DESCRIPTION

           FE 80 TO FE FF  This range of Return Codes is reserved for
                           CID-Enabled Applications that want the flexibility
                           of specifying product specific Return Code defi-
                           nitions. Products must of course then document the
                           meaning of these Return Codes used from this range.
                           The defined SDM action for this range is:
                           Unsuccessful program termination--No Reboot



__________________________________________________
3.2 - Warp Server LCU CID Installation from CD-ROM


LAN CID Utilities is included in OS/2 Warp Server to support lightly attended
remote install scenarios of both client and server components to machines
that do not have any software installed.  If you require assistance with
setting up your CID Server, support is available through your local IBM
Branch office.

  Setting Up Remote Install of Server Components using LAN CID Utilities

There are two major steps setting up a for remote installations using
LAN CID Utilities: setting up the code server and creating the boot
diskettes for the target machine.  The general procedures for performing
these steps are described in the LAN CID Utility Guide.  A soft copy
of this guide can be found on MPTS disk 5 in the README.UTL file.
The README.UTL file can be found on the OS/2 Warp Server CD-ROM
in directory \CID\SERVER\IBMLS\IBM500N5 subdirectory.

The OS/2 Warp Server CD-ROM includes install images that
can be used directly from its CD-ROM and there are files
included to assist setting up a code server to utilize this feature.


OS/2 Warp Server includes a ZIP file that contains a set of default
response files and a default LCU command file.  To un-zip these
files, issue the following command.

        PKUNZIP2 -d x:\CID\SERVER\IBMLS\IBM500\LCU\WARPSRV.ZIP <target path>

where x is the drive letter of the CD-ROM drive that contains the
OS/2 Warp Server CD-ROM.  The ZIP file is designed to place the
response files and default LCU command file in the appropriate
locations in the CID directory structure (as indicated below) and
<target path> is the drive and path where the response files and default
LCU command file will be placed.  In the example directory structure above,
the <target path> is "D:\".  Warp Server's "Up and Running" describes both
LCU and SYSVIEW/2 for CID installations.



       Setting Up an Code Server for the OS/2 Warp Server CD-ROM

The following steps are required for setting up a code server for
the OS/2 Warp Server CD-ROM:

            - Install and configure the SRVIFS server.
              Copy the \CID\SRVIFS directory of the Warp Server CD-ROM
              onto the CID code server in the \SRVIFS directory.  The
              \SRVIFS directory will be created when the WARPSRV.ZIP
              file is unzipped using the -d option and the sample service.ini
              for Warp Server will be placed in this directory
              when unzipped using the -d option.
            - Create the CID directory stucture on the CID code server for
              response files, install logs, and the client install
              REXX command.  The directories will also be created when
              the WARPSRV.ZIP file is unzipped using the -d option.  The -d
              will place the Warp Server default response files and default
              client install command file will also be placed in the
              appropriate locations in the CID directory structure.


Refer to the "LCU Configuration Guide" for the procedure for installing
the SRVIFS server.  The following statements should be used
in the SRVIFS "SERVICE.INI" file on the code server.  The  "LCU Configuration
Guide" should be consulted for changes necessary to address your unique
environment.
-----------------------------------------------------------------------------
;
Adapter       = 0
MaxClients    = 5
MaxFiles      = 102
Name          = CIDSERVER
Groupname     = No
ClientWorkers = 6
;
Path          = d:\
perclient     = No
PermitWrite   = Yes
;
alias= readonly,single,cdrom,e:\
alias= readwrite,single,writedsk,d:\cid
-----------------------------------------------------------------------------

In the example above, the CID directory structure is configured for drive "D:"
and the install images from the OS/2 Warp Server CD-ROM is configured for
drive "E:".  If your code server configuration is different, you will need
to change the appropriate statements to reflect your code server's configuration.
Drive "D:" appears twice, once in the "Path" statement and once in the
second alias statement.  Drive "E:" appears once in the first alias statement.

Also notice that the name of the code server has been set to "CIDSERVER".
If you have no other machines on the network using the NETBIOS name
"CIDSERVER", this name will work fine.  However, you should also feel
free to change this name to the name you would prefer.

Once SRVIFS is installed and configured on your code server, you must
activate SRVIFS with the following command:

        "SERVICE /INI=SERVICE"


The following directory structure should be setup as the source
of response files, installation log files, and client installation command
files on the code server:

D:\CID\CLIENT
D:\CID\RSP\WARPSRV
D:\CID\RSP\MPTS
D:\CID\RSP\LS
D:\CID\RSP\TCPAPPS
D:\CID\RSP\NWREQ
D:\CID\RSP\LDCS
D:\CID\RSP\SYSVIEW2
D:\CID\RSP\PSNS
D:\CID\RSP\PSF
D:\CID\LOGS\WARPSRV
D:\CID\LOGS\MPTS
D:\CID\LOGS\LS
D:\CID\LOGS\NSC
D:\CID\LOGS\TCPAPPS
D:\CID\LOGS\NWREQ
D:\CID\LOGS\LDCS
D:\CID\LOGS\SYSVIEW2
D:\CID\LOGS\PSNS
D:\CID\LOGS\PSF
D:\CID\LOGS\SRVIFS
D:\CID\LOGS\LCU


Your code server is now ready to perform a default installation of
all server components from OS/2 Warp Server.  However, you probably
do not want exactly a default install on any of your server machines.
At this point, you should modify the default response files to
match the configuration of the server component you want and
you should create LCU command files for each server you want
to install.  When you edit LCU command files, copy the default
command file to another file (the name of the file should equal the
name of the target machine to be installed and the extension should
be "CMD") and comment out the sections pertaining to the
server components not required.  Make sure that the variable "ldcs_install"
in the default command file points to the \CID\SERVER\LDCS subdirectory
that ends with a1 in order to correctly point to the LAN Distance source
directory.

                  Creating LCU Boot Diskettes

To create the LCU boot diskettes, execute the following commands
from the Warp Server CD-ROM:

    (S: Source Drive)
    (E: drive is the CD-ROM drive)
    (D: drive is the CID Server harddrive)
    (T: Target Drive)


    E:\CID\EXE\OS2\SEDISK.EXE
                               /S:E:\OS2IMAGE
                               /T:A:

    E:\CID\SERVER\MPTS\THINLAPS.EXE
                                     E:\CID\SERVER\MPTS
                                     A:
                                     nif_file_name (nif file name of the LAN
                                                     adapter in the target
                                                     machine)

    E:\CID\SRVIFS\THINIFS.EXE /D:X
                              /S:E:\CID\SRVIFS
                              /T:A:
                              /TU:A:
                              /SRV:\\CIDSERVER\CDROM
                              /REQ:* (* indicates that a random SRVIFS NETBIOS
                                       name will be used)

    E:\CID\SRVIFS\THINIFS.EXE /D:W
                              /S:E:\CID\SRVIFS
                              /T:A:
                              /TU:A:
                              /SRV:\\CIDSERVER\WRITEDSK /REQ:*

    E:\CID\LOCINSTU\CASINSTL.EXE /TU:A: /CMD:W:\CLIENT
                                 /PL:X:\CID\LOCINSTU;X:\CID\DLL\OS2
                                 /PA:X:\CID\LOCINSTU
                                 /REQ:*
                                 /D (indicates that the default LCU command
                                      file "DEFAULT.CMD will be used if the
                                      client LCU command file cannot be found)

