home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 10 Tools
/
10-Tools.zip
/
lansystk.zip
/
MPTSUTIL
/
README.UTL
Wrap
Text File
|
1998-05-08
|
49KB
|
1,114 lines
**********************************************************************
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)