TCX Sky Communications Programming Ref

Toshiba Global Commerce Solutions
TCx Sky
Communications Programming
Reference
Version 1.2
TC62-0036-03
1
Note:
Before using this information and the product it supports, be sure to read Safety Information-Read This First, Warranty
Information, Uninterruptible Power Supply Information, and the information under Notices.
December 2019
This edition applies to Version 1.2 of the licensed program TCx Sky (program number 4690-SK1) and to all subsequent
releases and modifications until otherwise indicated in new editions.
If you send information to Toshiba Global Commerce Solutions (Toshiba), you grant Toshiba a nonexclusive right to use or
distribute whatever information you supply in any way it believes appropriate without incurring any obligation to you.
© Copyright Toshiba Global Commerce Solutions, Inc. 2013, 2019
Contents
Figures.......................................................5 Telnet server......................................................................44
Enhanced Telnet server (ADXHSIUL.286)................... 45
Tables........................................................ 7 LPR client (ADXHSIRL.286)........................................... 47
Rexec client (ADXHSIXL.286)........................................ 48
PCNFSD authentication server...................................... 48
Safety.........................................................9 4690 TCP/IP programming libraries.....................................49
16-bit to 32-bit conversion............................................... 49
Retrieving the local host name..............................................50
About this guide..................................... 11 TCP/IP in the terminal............................................................50
Who should use this guide.................................................... 11
Where to find more information...........................................11
TCx Sky Library................................................................11 Chapter 3. Using IP Filters..................... 51
Notice statements....................................................................12 IP Filters Overview................................................................. 51
Filter rules................................................................................ 51
Configuring filters...................................................................51
Summary of changes............................. 13 User-defined filter rules.................................................. 51
December 2019.........................................................................13 Predefined filter rules...................................................... 52
March 2019............................................................................... 13 Direction............................................................................ 52
December 2018.........................................................................13 Subnet masks.................................................................... 52
Examples of filter rules....................................................52
Filters and intrusion detection and prevention........... 54
Chapter 1. Introduction to 4690 IP Filter commands ................................................................57
genfilt command (adxipsgf.386).....................................57
communications..................................... 15 actfilt command (adxipsaf.386)...................................... 60
TCP/IP support........................................................................15
chfilt command (adxipscf.386)....................................... 61
mvfilt command (adxipsmf.386).................................... 63
rmfilt command (adxipsrf.386).......................................64
Chapter 2. Using TCP/IP in the lsfilt command (adxipslf.386)......................................... 64
operating system....................................17 gentun command (adxipsgt.386)....................................65
4690 TCP/IP file naming conventions.................................. 17 ipsecstat command (adxipsst.386)................................. 66
Configuring 4690 TCP/IP....................................................... 19
Enhanced loopback address configuration using
ifconfig...................................................................................... 21 Chapter 4. Using the Linux Secure
Identifying a network router.................................................21 Shell in the Operating System...............69
Using TCP/IP Host Names.................................................... 22
Introduction to SSH................................................................ 69
resolv File...........................................................................22
Coexistence with and Migration from 4690 Version 6
Hosts File........................................................................... 22
SSH............................................................................................ 69
Linux applications and Host Name resolution............23
Enabling SSH........................................................................... 70
Configuring TCP Keepalive and Connection
Hybrid File Name Use in Configuration Files....................70
Establishment Timer Values..................................................23
SSH Server (sshd)....................................................................71
Setting Up and Using Other TCP/IP Applications.............24
SSH sessions.............................................................................72
INETD Superserver (ADXHSI9L.286)........................... 24
Enhanced security permissions.............................................72
FTP Client (ADXHSIGL.286).......................................... 24
4690 OS account lockout........................................................ 73
FTP Server (ADXHSIFL.286).......................................... 25
Configuring the SSH server...................................................73
NFS server (ADXHSINL.386)......................................... 27
Other comments on SSH configuration............................... 73
NFS client (ADXHSIDL.286)...........................................29
Troubleshooting the SSH server........................................... 74
Telnet client (ADXHSIVL.286)....................................... 29
Secure FTP server....................................................................75
BOOTP client (ADXHSIBL.286)..................................... 29
SSH client programs............................................................... 75
BOOTP server (ADXHSIAL.286)................................... 30
Troubleshooting SSH Client Configuration issues............ 76
Configuring the PXE environment and DHCP
SSH Client shell....................................................................... 76
Server (DHCPD.386)........................................................ 31
Secure FTP client..................................................................... 77
Using TCC and PXE in a routed environment.............39
Secure Copy (SCP).................................................................. 77
Using the Remote Terminal Utility................................40
SSH key generator...................................................................78
SNMP agent (ADXHSI1L.286)........................................42
SFTP/SCP file permissions.....................................................78
© Copyright Toshiba Global Commerce Solutions, Inc. 2013, 2019 3

Industry Canada Class A Emission Compliance
statement..........................................................................138
Chapter 5. Using the Remote Avis de conformité à la réglementation
d'Industrie Canada.........................................................139
Command Processor............................. 81 Industry Canada Radiation Exposure Statement...... 139
Introduction to RCP................................................................81
European Union Electromagnetic Compatibility
The RCP Selection File............................................................81
(EMC) Directive Conformance Statement.................. 139
The RCP COMMAND File.................................................... 82
Germany Class A statement......................................... 139
Command Files on LAN Systems.........................................82
Australia and New Zealand Class A statement.........140
User-Created Output Files.............................................. 83
Aviso para los usuarios de México.............................. 140
Applying Maintenance on a LAN System
People's Republic of China Class A electronic
through RCP......................................................................84
emission statement.........................................................141
The RCP STATUS File............................................................ 84
Russian Electromagnetic Interference (EMI) Class
RCP Commands...................................................................... 86
A statement..................................................................... 141
Re-IPL Command.............................................................87
Japanese Electrical Appliance and Material
Remote STC Command................................................... 87
Safety Law statement.....................................................141
Dump Formatter Command........................................... 88
Japanese power line harmonics compliance
Trace Commands..............................................................89
statement..........................................................................141
Trace Formatter Command.............................................97
Japan Voluntary Control Council for Interference
File Management Command for Trace Output
Class A statement........................................................... 141
Data Files........................................................................... 98
Japan Electronics and Information Technology
System Log Formatter Command................................100
Industries Association (JEITA) statement...................142
File Management Command for System Log............ 103
Korean communications statement............................. 142
Configuration Activation Command.......................... 104
Taiwan Class A compliance statement........................142
Configuration Data Formatter Command.................. 105
Taiwan contact information..........................................142
Report Module Level Command................................. 106
Cable ferrite requirement.....................................................143
Audible Alarm Commands.......................................... 108
Electrostatic discharge (ESD).............................................. 143
Apply Software Maintenance Command................... 112
Product recycling and disposal...........................................143
SkyCheck Command..................................................... 113
Battery safety......................................................................... 144
Load All Terminals Command.....................................114
Battery return program........................................................ 145
Remote Set Terminal Characteristics Command.......115
For Taiwan:......................................................................145
Set System Time and Date Command.........................115
For the European Union:............................................... 145
File Compression⁄Decompression Command............116
For California:................................................................. 146
Problem analysis data compression command..........120
Flat panel displays................................................................ 146
Extract Store-Specific Configuration Command....... 122
Monitors and workstations..................................................146
Insert Store-Specific Configuration Command..........123
Trademarks............................................................................ 147
Commands for Remote CMOS and BIOS Update........... 123
Terminal CMOS update commands............................123
Controller BIOS Update commands............................125
Controller CMOS Update Commands........................ 125
Starting RCP...........................................................................125
Starting RCP from an Application............................... 126
Starting Applications Using RCP....................................... 126
Starting Applications on the 4690 Store System........ 126
Command Line Applications....................................... 127
Background Applications..............................................127
Retrieving Reports Formatted by RCP.............................. 131
Chapter 6. Systems Management

Information............................................ 133
Vital Product Data File......................................................... 133
MAC Address Data File....................................................... 134
Notices....................................................................................137
Telecommunication regulatory statement........................ 138
Electronic emission notices..................................................138
Federal Communications Commission (FCC)
statement..........................................................................138
FCC Radiation Exposure Statement............................ 138
4 Communications Programming Reference

Figures
1. Sample DHCP Configuration File.................................... 33

Tables
1. 4690 TCP/IP File Name Index........................................... 18
2. DHCP server error message event numbers...................38
3. Explanation of filter rules example.................................. 53
4. RCP STATUS File Entries.................................................. 84
5. Terminal CMOS Update Log File Entries......................124
6. Controller BIOS update return codes.............................125
7. Reports Formatted by RCP..............................................131

Safety
Before installing this product, read Safety Information.
Antes de instalar este produto, leia as Informações de Segurança.
Pred instalací tohoto produktu si prectete prírucku bezpecnostních instrukcí.

Læs sikkerhedsforskrifterne, før du installerer dette produkt.
Lees voordat u dit product installeert eerst de veiligheidsvoorschriften.
Ennen kuin asennat tämän tuotteen, lue turvaohjeet kohdasta Safety Information.
Avant d'installer ce produit, lisez les consignes de sécurité.
Vor der Installation dieses Produkts die Sicherheitshinweise lesen.
Prima di installare questo prodotto, leggere le Informazioni sulla Sicurezza.
Les sikkerhetsinformasjonen (Safety Information) før du installerer dette produktet.
Antes de instalar este produto, leia as Informações sobre Segurança.
Antes de instalar este producto, lea la información de seguridad.

Läs säkerhetsinformationen innan du installerar den här produkten.
Пре инсталирања овог производа, прочитајте Безбедносне информације.
Перш ніж встановлювати продукт, прочитайте Інформацію про безпеку.

About this guide
This guide describes procedures for customizing communications programs for use with the
4690 Store System. It is intended to help programmers develop communications for TCx™ Sky
(hereafter called the operating system) to meet the specific needs of their enterprise.
Who should use this guide

This guide is intended for programmers who are familiar with the concepts and facilities of the
operating system and the 4690 Store System. This guide assumes that you are familiar with the
following concepts and facilities:
• Local area networks (LANs)
• TCP/IP
Where to find more information

Current versions of Toshiba publications are available on the Toshiba Global Commerce
Solutions website at www.toshibacommerce.com/support/publications. The publications listed
under the General tab are available to the public.
Note: Access to the product publications require valid user credentials. For information on
obtaining a user ID and password, click About us, and then FAQs.
To access a specific Toshiba product publication:
1. Enter your user ID and Password.
2. Click Support.
3. Click Publications.
4. Click the OS tab.
5. Scroll down and select TCx Sky.
6. Select the appropriate manual listed under the Publications header, and the PDF will be
downloaded to your computer.
Accessing the TGCS Knowledgebase site

Toshiba Global Commerce Solutions has developed a variety of Knowledgebase articles to assist
you in using the Toshiba product set. To access the TGCS Knowledgebase articles:
1. Enter your user ID and Password.
2. Click Support.
3. Click Publications.
4. Click the Hardware dropdown menu.
5. Scroll down and select the desired product.
6. Click Restricted content (Security Alerts, BIOS & Publications).
7. Click the Knowledgebase link.
TCx Sky Library

The following publications are all listed under the TCx Sky library.
• TCx Sky: Planning, Installation, and Configuration Guide, TC62-0032
• TCx Sky: User's Guide, TC62-0033
• TCx Sky: Messages Guide, TC62-0034
• TCx Sky: Communication Programming Reference, TC62-0036

• TCx Sky: Programming Guide, TC62-0035
• TCx Sky: Application Interface Specification for 4610 printers, TC62-0037
• 4680 BASIC: Language Reference, SC30-3356
Notice statements
Notices in this guide are defined as follows:
Note
These notices provide important tips, guidance, or advice.
Important
These notices provide information or advice that might help you avoid inconvenient or
problem situations.
Attention
These notices indicate potential damage to programs, devices, or data. An attention notice
is placed just before the instruction or situation in which damage could occur.
CAUTION
These statements indicate situations that can be potentially hazardous to you. A caution
statement is placed just before the description of a potentially hazardous procedure step
or situation.
DANGER
These statements indicate situations that can be potentially lethal or extremely hazardous
to you. A danger statement is placed just before the description of a potentially lethal or
extremely hazardous procedure step or situation.

Summary of changes
December 2019
This edition of TCx Sky 1.2 includes:
• The addition of the Sky Product Build tool for generating Product Control files
• Support for Python 3 and terminal support of Python applications
• Container updates
• Support for TCx 300 4810-3x0 and 3x1
• Support for TCx 700 4900-xx6 and xx7
March 2019
This edition of TCx Sky Version 1 Release 1.2 includes support for iButton, KVM support, DB
support for postgres, Remote terminal hard drive format, Rxtx - Locking to serial port, extended
graphics screen support of pseudo keypad, and Windows preload system support. Includes fixes
and security updates.
December 2018
This edition of TCx Sky Version 1 Release 1.1 includes support for TCx 800 all-in-one POS
system, TCx Dual Station Printer, TCx Single Station Printer and Infrastructure for McAffee
Whitelisting. Includes fixes and security updates.

Chapter 1. Introduction to 4690 communications
Introduction to 4690 communications
This guide assumes that you are familiar with communications concepts and functions.
Knowledge of communication protocols is vital in understanding this chapter and this guide.
4690 OS is now TCx Sky. Toshiba Global Commerce Solutions has partnered with Wind River®
to create TCx Sky, building the reliability of 4690 OS onto a base of Wind River Linux, the
leading embedded Linux provider. The term "4690 OS" continues to appear throughout the
documentation and product screens.
TCP/IP support
TCP/IP protocols are supported by the 4690 Operating system. In addition, common TCP/IP
applications are provided by the operating system. User-level access to TCP/IP is provided
through the socket programming interface to allow users to write their own applications. Details
of 4690 TCP/IP support are provided in this document.

Chapter 2. Using TCP/IP in the operating system
Using TCP/IP in the operating system
This chapter describes using TCP/IP in both store controllers and terminals. Configuring the PXE
environment and configuring a DHCP server are discussed in this chapter. The chapter assumes
you are familiar with TCP/IP and, therefore, describes only how TCP/IP is used with the
operating system. If you need detailed information about TCP/IP, see the Transmission Control
Protocol/Internet Protocol for 4690 Application Interface Guide, which can be found at
www.toshibacommerce.com. Select Support > Publications to find information on the following
items.
TCP/IP support within the operating system is implemented as a communications device driver,
similar to the NetBIOS driver. 4690 TCP/IP can operate concurrently with NetBIOS and Terminal
Controller Communications (TCC) protocols.
4690 TCP/IP is supported on the Ethernet network. All Ethernet adapters supported by the
operating system are supported by 4690 TCP/IP. All 4690 TCP/IP functions and applications are
available on the Ethernet LAN. 4690 TCP/IP is supported on only one Ethernet interface.
User-level access to the driver is provided through the socket programming interface. A socket
runtime library is provided that can be linked to user-written applications. In addition to the
TCP/IP driver and socket library, a SNMP agent is implemented.
The 4690 TCP/IP stack does not provide the client or server implementation of the SOCKS proxy
protocol. In the case of an internal (enterprise) network within a firewall, TCP/IP applications are
not enabled to communicate through that firewall.
4690 TCP/IP can operate in one of two 4690 system configurations:
• 4690 LAN environment in which Distributed Data Application (DDA) is being used for store
controller communications, file mirroring, and file services. In this environment the 4690
store controller can have a role of Master, File Server, Alternate Master, Alternate File Server,
or Subordinate.
• Non-DDA LAN environment in which the store controller operates independent of any other
controller on the LAN. Typically, this environment consists of a single store controller
connected with other machines using a LAN adapter. It is normally designated as the Master
store controller although there are no Alternate or Subordinate store controllers.
When running TCP/IP applications in the controller, it is recommended that the HOSTNAME
logical name be defined to the value of the TCP/IP host name of the controller.
4690 TCP/IP file naming conventions

Most 4690 TCP/IP software program files, data files, and programming libraries adhere to the
operating system file naming conventions. In some cases, logical names are defined when 4690
TCP/IP is loaded. Table 1 maps the 4690 file names with logical names and their respective
function. The logical names attempt to provide the standard UNIX program names for the 4690
TCP/IP files. Wherever a logical name is defined for a physical file name, it can be used in place
of the name and the operating system performs the necessary replacement of the physical file
name.
Note: The API runtime libraries (*.L86 and .LIB) can be found on the 4690 Optionals. These files
are not copied onto the controller during the Apply Software Maintenance function.
Attention: You must not define a logical file name of “tcpip” because this file name is reserved
for use by the 4690 TCP/IP driver.

Table 1. 4690 TCP/IP File Name Index
4690 store controller physical file name 4690 logical name Description TCP/IP file
name
C:\ADXHSIDL.L86 none SNMP DPI library dpi.lib*
C:\ADXHSIRL.L86 none Sun RPC library sunrpc.lib*
C:\ADXHSISL.L86 none Socket library tcpip.lib
C:\ADXHSITL.L86 none FTP API library ftpapi.lib*
C:\ADX_SDT1\ADXHSIAF.DAT none BOOTP Server etc/bootptab
Bootptab
C:\ADX_SDT1\ADXHSIDF.DAT None SNMP trap snmptrap.dst
destination
C:\ADX_SDT1\ADXHSIGF.DAT none FTP client netrc etc/netrc
C:\ADX_SDT1\ADXHSIHF.DAT hosts Local hosts file etc/hosts
C:\ADX_SDT1\ADXHSIIF.DAT none INETD data inetd.lst
C:\ADX_SDT1\ADXHSIMF.DAT none Telnet server none
messages
C:\ADX_SDT1\ADXHSINF.DAT networks Lists networks etc/networks
C:\ADX_SDT1\ADXHSIPF.DAT protocol Lists IP protocols etc/protocol
C:\ADX_SDT1\ADXHSIQF.DAT none SNMP community pw.src
names
C:\ADX_SDT1\ADXHSIRF.DAT resolv Identifies name etc/resolv
server
C:\ADX_SDT1\ADXHSISF.DAT services Lists servers and etc/services
ports
C:\ADX_SDT1\ADXHSIUF.DAT none FTP server trusers etc/trusers
C:\ADX_SDT1\ADXHSIXF.DAT none NFS exports etc/exports
C:\ADX_SDT1\ADXHSIZF.DAT none SNMP environment none
names
C:\ADX_SDT1\ADXIP00D.DAT None Sample DHCP none
configuration file
C:\ADX_SDT1\ADXIP00Z.BAT None Sample config.batch SETUP.CMD
C:\ADX_SDT1\PCNFSD.DAT none PC NFS Users none
C:\ADX_SDT1\RPC.DAT none RPC server names etc/rpc
C:\ADX_SPGM\ADXHSI0L.BSX none TCP/IP driver none
symbols
C:\ADX_SPGM\ADXHSI0L.286 none TCP/IP protocol bin/inet.sys
driver
C:\ADX_SPGM\ADXHSI1L.286 none SNMP agent bin/snmpd.exe
C:\ADX_SPGM\ADXHSI2L.286 none Initialize TCP/IP bin/tcpstart.exe
C:\ADX_SPGM\ADXHSI3L.286 ifconfig Configure interface bin/ifconfig.exe

4690 store controller physical file name 4690 logical name Description TCP/IP file
name
C:\ADX_SPGM\ADXHSI4L.286 route Define network rout bin/route.exe
C:\ADX_SPGM\ADXHSI5L.286 ping Ping program bin/ping.exe
C:\ADX_SPGM\ADXHSI6L.286 netstat Check network status bin/netstat.exe
C:\ADX_SPGM\ADXHSI7L.286 finger Check remote users bin/finger.exe
C:\ADX_SPGM\ADXHSI8L.286 none SNMP names bin/
encryption make_pw.exe
C:\ADX_SPGM\ADXHSI9L.286 none INETD superserver bin/inetd.exe
C:\ADX_SPGM\ADXHSIAL.286 bootpd Bootp server bin/bootpd.exe
C:\ADX_SPGM\ADXHSIBL.286 bootp Bootp client bin/bootp.exe
C:\ADX_SPGM\ADXHSICL.286 none Bootp exfile compl none
C:\ADX_SPGM\ADXHSIFL.286 none FTP server bin/ftpd.exe
C:\ADX_SPGM\ADXHSIGL.286 ftp FTP client bin/ftp.exe
C:\ADX_SPGM\ADXHSIIL.286 none Telnet server bin/telnetd.exe
(keyboard)
C:\ADX_SPGM\ADXHSILL.286 none Lock local keyboard none
C:\ADX_SPGM\ADXHSINL.386 none NFS server bin/nfsd.exe
C:\ADX_SPGM\ADXHSIPL.286 none RPC Portmapper bin/portmap.exe
C:\ADX_SPGM\ADXHSIRL.286 lpr LPR client bin/lpr.exe
C:\ADX_SPGM\ADXHSISL.286 none Telnet server (screen) none
C:\ADX_SPGM\ADXHSIUL.286 none Telnet server bin/telnetd.exe
(Enhanced)
C:\ADX_SPGM\ADXHSIVL.286 vt100 VT100 telnet client bin/VT100.exe
C:\ADX_SPGM\ADXHSIXL.286 rexec REXEC client bin/rexec.exe
C:\ADX_SPGM\DHCPD.386 none DHCP server file none
C:\ADX_SPGM\DHCPINFO.386 none DHCP server utility none
C:\ADX_SPGM\HOST.286 none Host name resolution bin/host.exe
C:\ADX_SPGM\PCNFSD.286 none PC NFS authenticator bin/pcnfsd.exe
C:\ADX_SPGM\RPCINFO.286 none RPC status bin/rpcinfo.exe
C:\ADX_SPGM\SLIO.286 none SLIP driver bin/slip.exe
application
C:\ADX_SPGM\TRACERTE.286 none Packet routing trace bin/tracerte.exe
* These are 16-bit only.
Configuring 4690 TCP/IP

The 4690 TCP/IP protocol driver is loaded during the IPL of the store controller based on the
existence of the ADXIP??Z.BAT configuration batch file in the C:\ADX_SDT1 subdirectory,
where ?? is the local controller ID. A sample file, ADXIP00Z.BAT, is copied to the store
Chapter 2. Using TCP/IP in the operating system 19

controller during installation. You must rename or copy this file to the correct name to reflect the
ID of your store controller in order to activate TCP/IP. In an MCF network, the ADXIP??Z.BAT
file for all store controllers is created on the master file server and distributed to other controllers
on the network.
Note: You must have the configuration batch file on each machine that you want to run 4690
TCP/IP.
The configuration batch file must contain the following lines:
adxhsi2l [<number of sockets>]
ifconfig lan0 <ip_address>
where ip_address contains this machine’s (host) Internet address in a dotted decimal format. For
example 9.67.39.81 is a valid address. The assignment of addresses for a proprietary network are
enterprise defined. Addresses for the public Internet must be obtained from the administrators
of the Internet. All TCP/IP hosts in the network should have a unique Internet address. The
logical name lan0 represents the Ethernet interface.
Depending upon your configuration, you might have to use the netmask parameter on the
ifconfig command. For example:
ifconfig lan0 <ip_address> netmask 255.255.248.0
This parameter tells the TCP/IP stack how to interpret the IP address.
Note: IP addresses can be specified as decimal, hexadecimal, or octal. A leading 0x indicates hex.
A leading 0 (zero) indicates octal. Anything else indicates decimal. For example, the following
three IP addresses are identical.
• 9.67.39.83
• 0x9.0x43.0x27.0x53
• 011.0103.047.0123
In TCP/IP files that contain IP addresses, any leading zeros in the addresses are interpreted as
octal, not decimal. However, in terminal configuration, IP addresses are read as decimal.
If your system will run Linux applications which require IP communications, the eloopaddr
parameter may also be required on the ifconfig command. Refer to “Enhanced loopback
address configuration using ifconfig” on page 21 for more details.
After configuring TCP/IP on a 4690 store controller, it is advisable to use the following utilities to
ensure that your network is configured properly.
• netstat -a displays the addresses of the configured IP network interfaces.
• ifconfig lan0 displays IP configuration information for the specified interface.
• ping <ip address> sends an echo request to <ip address> to determine if a remote host is
accessible. If successful, your TCP/IP network is operational.
ADXHSI2L can accept a single parameter that indicates the maximum number of sockets that
can be active at any one time. If no parameter is specified, the default is 48 sockets, which is
sufficient for most instances. If more sockets are needed, enter a value between 49 and 600 after
the ADXHSI2L command. For example, to configure 217 sockets, edit the line to read:
adxhsi2l 217
Note:
1. Additional memory is allocated for each socket above 48 (about 2 KB per socket) regardless
of whether the socket has an active connection. Also, when set to a value, the maximum
number of sockets cannot be changed by a subsequent call of ADXHSI2L. The maximum
number of sockets can be set only once after a machine IPL. The maximum sockets value
represents the combined total of both UDP and TCP sockets.

2. Controller to Controller Communication over IP (CCC/IP) requires the use of extra sockets.
It is recommended that you increase the maximum number of sockets that can be active at
one time by 24 on each controller configured for CCC/IP.
3. If you use the Store Integrator Facility, increase the maximum number of sockets that can be
active at one time to at least 128 to avoid running out of sockets.
For more information regarding the IFCONFIG command and Internet addressing, see the
Transmission Control Protocol/Internet Protocol for 4690 Application Interface Guide.
4690 TCP/IP on Ethernet networks can support DIX V2 Ethernet or IEEE 802.2/802.3 Ethernet.
The default interface setting is DIX V2. If IEEE 802.2/802.3 is required, you must use the 802.3
command line switch for the IFCONFIG command.
Enhanced loopback address configuration using ifconfig

If IP communications are required between Linux applications and other 4690 applications on
the same system, you must configure an enhanced loopback address. The enhanced loopback
address is an IP address on the same subnet as the system running the Linux application. A
specific IP address may be configured or the keyword "last" may be used to specify the last valid
IP address on the subnet. The enhanced loopback address must be a unique IP address on the
network. When using the keyword "last", please ensure that this IP address is not already in use
on the network. Enhanced loopback communications are internal to the system, however,
communications with an external duplicate IP address will cause issues due to the nature of ARP
(Address Resolution Protocol).
To configure the enhanced loopback address on the controller, modify the IP configuration file,
adx_sdt1:adxip??z.bat, and add the eloopaddr parameter on the ifconfig command as shown in
the examples below:
ifconfig lan0 10.1.1.1 netmask 255.255.255.0 eloopaddr 10.1.1.200
ifconfig lan0 10.1.1.1 netmask 255.255.255.0 eloopaddr last (configures the eloopaddr
as 10.1.1.254)
To configure the enhanced loopback address on the terminal, modify the Terminal IP
configuration file, adx_spgm:ipconfig.dat, and add a new line to configure the eloopaddr
parameter as follows:
ifconfig lan0 eloopaddr last
After changing adx_spgm:ipconfig.dat, run terminal loadshrink (adxrtccl) and reload the
terminal.
To configure the enhanced loopback address on a controller configured for bootp, add an
ifconfig command to the bootp configuration file, adx_sdt1:adxbp??z.bat, with only the
eloopaddr parameter as follows:
ifconfig lan0 eloopaddr last
Identifying a network router

If your network contains an IP router, file ADXIP??Z.BAT can identify it using the ROUTE
command. For example:
route add default <router_ip_address> 1
where router_ip_address identifies the Internet address of the network router in a dotted decimal
format. The ROUTE command should follow the IFCONFIG command in the configuration
batch file ADXIP??Z.BAT.

Using TCP/IP Host Names
TCP/IP allows a host name to be used in place of the Internet address. To resolve a name to an
Internet address, these two methods are used:
• TCP/IP contacts the name server host that is designated in the RESOLV file using domain
name system (DNS) protocols to resolve the name.
• The local HOSTS file is searched for a match to resolve the name.
The order in which the two name resolution methods are used depends on whether you have
defined the ADXDNS2S logical name.
• If ADXDNS2S is not defined, TCP/IP contacts the name server host first. If the name server
cannot resolve the name, then the local HOSTS file is searched. This is the only search order
supported on 4690 OS prior to Version 4.
• If ADXDNS2S is defined, the local HOSTS file is first searched for a match and, if a match is
not found, then the name server is contacted to resolve the name. This search order is only
supported on 4690 OS Version 4 or higher.
Note that in Enhanced Mode, setting this logical name via the User Logical File Name menu, the
search order will only apply to controller applications. To change the search order for terminal
applications, define the ADXDNS2S logical name in ADX_IDT1:ADXTRMUF.DAT.
resolv File
TCP/IP attempts to contact the name server only if the C:\ADX_SDT1\ADXHSIRF.DAT RESOLV
file exists and identifies the domain and the address of the name server. During the 4690 TCP/IP
installation, a sample RESOLV file is copied onto the 4690 store controller. The domain and
nameserver entries in this sample RESOLV file are commented out. If your TCP/IP network uses
a name server, you should uncomment both of these entries in the RESOLV file and then change
them to match your IP network configuration. Otherwise, host names are resolved using your
local HOSTS file (See “Hosts File” on page 22).
You do not need to modify the sample RESOLV file if you are not using a name server. But, any
invalid entries in this file (such as an invalid IP address in the name server entry) causes name
resolution to be attempted, which could result in unnecessary delays.
Note: A 4690 store controller cannot be a name server. Therefore, the RESOLV file should not
identify a 4690 host Internet address. Refer to the sample RESOLV file for the format of its entries.
Hosts File
The local HOSTS file, C:\ADX_SDT1\ADXHSIHF.DAT, is searched for a match if any of these
conditions exists:
• A RESOLV file does not exist or is not configured
• The name server cannot resolve the name to an Internet address
• The ADXDSN2S logical name is defined
The HOSTS file correlates a host name to an Internet address. You can have numerous host
name and Internet address pairs in the HOSTS file. If you are not using a name server, you
should update the HOSTS file with names and addresses of those hosts with whom this machine
will normally communicate.
A sample HOSTS file is copied onto the controller when 4690 TCP/IP is installed. Some example
HOSTS file entries are shown below:
9.67.39.80 cc # 4690 controller CC
9.67.39.81 dd # 4690 controller DD
9.67.39.82 isp # TCP/IP In-Store Processor

Linux applications and Host Name resolution
The 4690 DNS configuration and HOSTS file entries are automatically configured in the Linux
OS for use by Linux applications. Some notable differences between controller and terminal
updates are described below:
• The HOSTNAME logical name on a controller is configured as the Linux Host Name.
• The Host Name configured via DHCP or static IP configuration on a terminal is configured as
the Linux Host Name.
• The Linux HOSTS file on a controller is updated with all HOSTS entries in the local controller
HOSTS file (C:\ADX_SDT1\ADXHSIHF.DAT).
• The Linux HOSTS file on a terminal is updated with the following entries:
• Host name entries from the controller HOSTS file excluding the DHCP entries.
• Entry mapping the local IP address to Linux Host Name.
Configuring TCP Keepalive and Connection Establishment Timer Values

The TCP/IP driver enables you to configure the tcp_keepidle and tcp_keepintvl timer values. These
timers are global values in the driver and are used for idle and probe interval timers for all TCP
connections that have the SO_KEEPALIVE option enabled. This option can be enabled or
disabled using the setsockopt() socket call and can be enabled by TCP applications. You can use
the following logical names to define the values.
• KEEPIDLE - specifies the length of time to keep an idle TCP connection alive before
“keepalive” probes are sent. This value is measured in minutes, with a default of 120 minutes.
The valid range of values for the KEEPIDLE logical name is 1 through 120.
• KEEPINTV - specifies the time interval between packets sent to validate the connection
(“keepalive” probes). This value is measured in seconds, with a default of 75 seconds. The
valid range of values for the KEEPINTV logical name is 10 through 75.
Note: These are system-level logical names and must be defined and activated using controller
configuration as User Logical File Names.
The following steps show how you could use the keepalive timer values in your socket
application:
1. Assume KEEPIDLE = 5 minutes and KEEPINTV = 20 seconds.
2. In your application, use the setsockopt() call to enable the SO_KEEPALIVE option for your
stream socket.
3. If that socket is connected to a remote host, and that connection has been idle for 5 minutes,
the TCP/IP driver sends a "keepalive" probe to validate the connection.
a. If a response is received as a result of the probe, the connection remains active and the
idle timer for that connection is reset to 5 minutes. Everything appears normal to your
application.
b. If no response is received as a result of the probe, the TCP/IP driver continues to send
probes approximately 20 seconds apart. If the TCP/IP driver does not receive a response
after sending a total of eight probes, the driver closes the connection. The next time
your application calls send() or recv(), an error is returned and the tcperrno external
variable is set to ETIMEDOUT.
4. To calculate how long an idle connection remains open when the SO_KEEPALIVE option is
enabled, add the idle timer value (KEEPIDLE) to the amount of time it takes to send eight
"keepalive" probes, which are separated by the interval timer value (KEEPINTV).
The connection establishment timer is also configurable using logical name KEEPINIT. This
timer represents the amount of time TCP waits for a new connection to be established. The
default timer value is 75 seconds. To change the timer value, set logical name KEEPINIT to the
new value, specified in seconds. The valid range is 10 - 75 seconds. The connection establishment
timer is global and applies to all TCP connections.

Setting Up and Using Other TCP/IP Applications
This section describes how to set up and use other TCP/IP applications.
INETD Superserver (ADXHSI9L.286)

TCP/IP servers are designed to be ready to accept client connections whenever they are listening
to their port number. Standard servers (for example, FTP and Telnet) listen to well-known ports
awaiting incoming connections from clients.
The INETD superserver is a TCP/IP server that can listen to multiple TCP ports awaiting
incoming client connections for specific servers (for example, FTP server or Telnet server). When
a client attempts to connect to a specific server, INETD automatically starts the server as a 4690
background application. Using INETD enables you to have a single server continuously running
instead of many servers. In addition, if using INETD to start servers, multiple instances of the
same server can be concurrently active.
The C:\ADX_SDT1\ADXHSIIF.DAT file identifies which servers INETD can start. This file is
copied onto the store controller during 4690 TCP/IP installation and contains an entry for the
FTP server and the regular Telnet server. You must change this file if you want to use the
Enhanced Telnet server, as described in “Enhanced Telnet server (ADXHSIUL.286)” on page
45.
The INETD server can be started automatically during controller IPL by setting the option in the
Networking section of System Configuration. If you specify automatic startup for INETD, then a
background slot is not used and the INETD superserver does not have the ability to display
messages on the background screen. Even if you specify automatic startup for the INETD
superserver, the services that it starts continue to be started in the background.
You can optionally specify a priority for each service started by the INETD server. If you adhere
to the following rules, the service will start with the specified priority; otherwise, the service will
start with the default priority of 5.
• Add a P=n string at the end of the line.
• The P=n string must be preceded by a blank.
• n must be a number from 1 to 9.
Attention: Be careful when editing the C:\ADX_SDT1\ADXHSIIF.DAT file; it must contain no
blank lines. If any of the lines (including the last line) are blank, the INETD superserver abends.
You can also start the INETD superserver by configuring it as a 4690 background application,
which is started when the store controller IPLs. The INETD superserver executable file name is
ADX_SPGM:ADXHSI9L.286. For more information about defining 4690 background
applications, see the TCx Sky User's Guide. Refer to the INETD data file copied onto your store
controller for the format of its entries.
Note: The INETD superserver can only start TCP servers. UDP servers must be started by other
means. For example, you can configure them as a 4690 background application, which starts at
IPL. Therefore, if you add servers to the INETD data file, ensure that they are TCP-based servers.
Also, if the server is a user-written TCP socket application and you would like INETD to start it
on demand, the application should be coded to expect the socket number passed to it as the
second input parameter (the first being the string "BACKGRND") in the argument list.
FTP Client (ADXHSIGL.286)

The FTP client is an interactive file transfer program invoked at the 4690 command line by
issuing the command ADXHSIGL. Optionally, the "ftp" logical name is defined during the
TCP/IP driver initialization to ADX_SPGM:ADXHSIGL.286 and can be used to start the FTP
client.

When invoked, the FTP client displays an FTP prompt. File Transfer commands or settings can
be issued at the FTP prompt. For a list of valid commands type HELP at the FTP prompt.
The NETRC file is an optional file that can be used by the FTP client to automate logon to certain
servers and provide macro definition for frequently used command strings. The 4690 NETRC file
is named C:\ADX_SDT1\ADXHSIGF.DAT. A sample NETRC file is copied onto the store
controller during 4690 TCP/IP installation. See the sample NETRC file for the format of its
entries.
Note: Some FTP client operations can also be invoked with user-written applications through the
use of the FTP Application Programming Interface (FTP API). See “FTP Server (ADXHSIFL.
286)” on page 25 for more information. See the Transmission Control Protocol/Internet Protocol for
4690 Application Interface Guide for more information.
FTP Server (ADXHSIFL.286)

The 4690 FTP server extends file transfer capabilities to an FTP client. Only a single FTP client
can be logged on to the FTP server at any given time. Under control of the INETD superserver, a
new instance of the FTP server will be started for each client logon request. This enables multiple
clients to be concurrently connected to multiple servers. However, if INETD is not used and the
FTP server is currently connected to a client, additional client requests will be rejected until the
server ends its connection and waits for incoming connections.
The client must first log on to the server using a user ID and (optional) password. The client user
ID and password are validated by the server when it finds a matching entry in the TRUSERS file.
Connection requests from unauthorized clients will be rejected.
The FTP server tracks invalid login attempts per user ID. The count is reset when a successful
login occurs for the user ID. If the configured number of invalid attempts is reached, the user ID
is locked out for the configured duration of time.
Either an invalid user ID or an invalid password counts as an invalid login attempt. If more than
50 invalid attempts occur, all FTP users will be locked out. This condition indicates an
unauthorized attack is occurring.
TRUSERS file
This file, C:\ADX_SDT1\ADXHSIUF.DAT, should contain an entry for each client with whom
the server will maintain an FTP session. You should update this file with the FTP clients to
which you want to grant access.
In addition to user ID and password information in the TRUSERS file, each entry lists the read
and write access privileges for that user. Access can be granted per drive or directory for
physical drives A:, C:, and D: and RAM drives T:, U:, V:, and W:. In addition, the 4690 printer
can be used as a file transfer destination for copying files directly from the client to a print
queue, for example prn7:.
A sample TRUSERS file is copied onto the controller during 4690 TCP/IP installation. This file
contains an entry for user anonymous (no password required) and gives read and write access to
the C:\ drive and its subdirectories.
Specify multiple drives or directories by listing them on the same line, separated by a blank, as
shown in the following example.
user: ftpuser 4690tcpip

wr: c:\anydir c:\adx_sdt1
rd: c:\
Note: The TRUSERS file must exist in order for the FTP server to successfully initialize. If the
server cannot access the C:\ADX_SDT1\ADXHSIUF.DAT file, it will reject the client logon
request, log a system message, and then terminate.

When configured as mentioned above, the TRUSERS file contains secure information in plain
text. For enhanced security, FTP User Definitions and FTP ID Security should be configured
under System Configuration. See the Planning, Installation and Configuration Guide for details.
Once you use System Configuration to configure FTP security, the TRUSERS file is converted
and encrypted, and you must continue using this method to make any future changes to the file.
Quote FTP client command

An additional command has been added to the 4690 FTP server to support the starting of 4690
background applications from an FTP client. This capability is provided using the quote FTP
client command with the ADXSTART server command. It assumes that the user at the client has
the necessary execution authorization.
An example of starting a background application named TESTPGM.286 is:
ftp> quote adxstart testpgm.286
This command causes the 4690 FTP server to start testpgm.286 as a 4690 background application.
The FTP server returns a message to the FTP client stating that the program has been started.
The server does not wait for the background program to complete.
The program name must be fully path-qualified and is limited to 22 characters. If using path-
qualified program names from a UNIX client, you might need to surround the entire quote
string in double quotes if the backslash character is required. Optionally, you can use forward
slash for the path name delimiter.
Program parameters can be specified immediately following the program name, each separated
by at least one blank. The length of the parameter list cannot exceed 46 characters. The program
will be started with default priority of 200 and cannot be changed.
User authority to start background applications using the quote command is granted through the
TRUSERS file. A special execution access privilege is granted to clients using the ex: tag for the
user. This tag is similar to the rd: and wr: tags used to grant read and write privileges. The
sample TRUSERS file, ADXHSIUF.DAT, contains an entry for user:anonymous (no password
required), and grants read access (rd:) for drive C:\ (and all subdirectories of the root directory).
The sample TRUSERS file also contains an entry for user:ftpuser with the password of
4690tcpip, and grants write access (wr:) for drive C:\ (and all subdirectories of the root
directory), read access (rd:) for drive C:\ (and all subdirectories of the root directory), and
background application initiation access (ex:). This entry is shown as:
user: anonymous
rd: c:\
user: ftpuser 4690tcpip
wr: c:\
rd: c:\
ex:
Note: The 'ex:' tag does not require additional parameters. Any user without execution authority
will receive a message from the FTP server indicating that they are not authorized to start
background applications.
Access for NFS and VFS Drives

NFS and Virtual File System (VFS) drives can also be given read and write access. To allow
access for NFS and VFS drives, the drives must be listed on the same line as shown in the
example below.
user: hayes
wr: c:\ g:\ h:\ i:\ j:\ k:\ l:\ m:\ n:\
rd: c:\ g:\ h:\ i:\ j:\ k:\ l:\ m:\ n:\
ex:

FTP server timeout
The 4690 FTP server contains a receive_data timeout to prevent a server hang condition in the
event that either the FTP client has crashed or the physical link between the client and server is
disconnected.
The timeout is set by the creation of a user-defined logical file name. To define the logical name,
use 4690 controller configuration to add the name ADXFTPTO. The definition for this name can
be a value between 1 and 14 400 and represents the maximum number of seconds to wait for a
client to transmit data to the server.
Note: This timeout value is only relevant to the server while it is receiving data. The value does
not affect either the FTP control connection IDLE time (which also can be configured from the
client using the FTP site command) or have any bearing on the retransmission of data when the
server is sending data to a client that might not be responding.
If the ADXFTPTO logical file name is not defined or is defined with an invalid value, a default
timeout of 2 hours is used. If the timeout expires, the FTP server closes all connections with the
client and terminates.
NFS server (ADXHSINL.386)

The Network File System server is a UDP-based server that enables remote access to files located
in 4690 directories. An NFS client mounts an exported 4690 directory and accesses files as if they
were local to the client machine. Multiple NFS clients can mount the same or different 4690
exported directories at the same time. However, only a single NFS server is required to be active
to handle and keep track of all client requests.
The NFS server determines which 4690 directories it can export and which users can mount
them using the EXPORTS file. You can export standard drives (A:, C:, and D:) as well as VFS
drives (M: and N:). C:\ADX_SDT1\ADXHSIXF.DAT, a sample EXPORTS file, is copied onto the
store controller during 4690 TCP/IP installation. You should modify this file to add, change, or
delete exported directories and access privileges as well as list additional users. See “Using the
EXPORTS file to give NFS clients access to files” on page 28 for examples of the format of the
EXPORTS file entries. The EXPORTS file is required in order for the 4690 NFS server to initialize
successfully. If the 4690 NFS server cannot obtain access to the EXPORTS file, it will log an error
in the system log and terminate.
The NFS Server logs messages during start-up to controller file c:\NFSDMSG.LOG. Check this
file for information if you experience problems with the NFS Server.
Note:
1. The remote procedure call (RPC) Portmapper is a mandatory prerequisite for the NFS
server. It must be active before the NFS server is started so that NFS procedures can be
registered. The Portmapper is program file, C:\ADX_SPGM\ADXHSIPL.286, and can be
started during a store controller IPL. Additionally, you can configure the NFS server to start
during IPL. However, you must ensure that you define the Portmapper background
application first, followed by the NFS server. The NFS server must be started after the
Portmapper is active. Defining the Portmapper first in the configuration causes it to start
before the NFS server. The NFS server program file name is C:\ADX_SPGM\ADXHSINL.
386.
2. If you do not have the TZ (time zone) logical name defined and you start the NFS server
from the command line, you will see a warning message indicating that the TZ environment
variable is not set. This message can be ignored because the NFS server will run with or
without this logical name defined. The operating system implements time zone information
differently than many NFS client and server implementations. Any time and date
information is passed using the timeval structure.
3. In order to mount the entire D: drive or A: drive, a directory named \NFSTMP must exist or
be created on this drive before mounting. This does not apply to the C: drive.

Read and write block size
The NFS client decides the maximum block size for reads and writes when it mounts the remote
file system (drive). Some systems might attempt a block size of 8000 bytes by default. The 4690
NFS server cannot support a block size of 8000 bytes. However, if a block size larger than
4000 bytes is required, the 4690 server will support up to 8000 bytes (not 8192) for read/write
block size.
Performance
In many cases, a typical NFS server (UNIX-based) will be running on a high-performance
network server machine with multiple clients concurrently mounted to multiple file systems. In
addition, the high-performance server might be a dedicated file server in the network and,
therefore, can have little or no other contention for its CPU. NFS clients are designed with the
intention that there is a high-performance server available. It is extremely likely that a client will
send multiple block-read requests simultaneously (such as if reading from the 4690 files) or
transmit multiple block-write requests simultaneously (such as if writing to the 4690 files).
In addition, most clients have relatively short timeout values if a response from the server is not
received. When the timeout expires, a retransmission of the block-read or block-write occurs.
This timeout/retransmission sequence can actually make the load worse on the potentially
already loaded server. Performance of the 4690 NFS server can be degraded under these
conditions, especially considering the controller can be executing many applications of higher
priority than NFS.
There are two approaches you could take if you suspect that your NFS performance could
improve. First, to help alleviate potential performance degradation, you should change the NFS
read/write timeout for the mounted file system (4690 drive) to a higher value than the default.
For example, on the AIX® operating system, the NFS client timeout is 0.7 seconds. A
recommended timeout of 7-10 seconds might help keep retransmissions low due to timer
expiration. Second, consider using FTP when a large file transfer is required.
Using the EXPORTS file to give NFS clients access to files

When an NFS client attempts to access an NFS server, the server reads the EXPORTS file to
determine the drives and directories that clients are allowed to access. Before NFS clients can
access your NFS server, you must create an EXPORTS file using a text editor. The file name for
the EXPORTS file is adx_sdt1/adxhsixf.dat.
Each line in the EXPORTS file lists the path to a directory. In addition, to give only certain clients
access to that directory, you can list those clients following the directory. You can also specify -
ro to limit the clients' access to read-only permission. A pound sign (#) at the beginning of a line
indicates a comment that extends to the end of the line.
Examples:
# Export read/write access to everyone
c:\
m:\
# Export read-only access to everyone

d:\ -ro
# Export read/write access to hosts jack and jill

c:\ jack jill
Note: The previous example includes comment lines, which begin with the pound sign (#), to
explain the intent of the line. Comment lines are optional. This example is not meant to imply
that comment lines are required as part of the file.
The EXPORTS file is read only during NFS server startup. Therefore, if you change the
EXPORTS file, you must stop and restart the NFS server for the changes to take effect.

NFS client (ADXHSIDL.286)
The Network File System client mounts an exported 4690 directory and accesses files as if they
were local to the client machine. Multiple NFS clients can mount the same or different 4690
exported directories at the same time. The 4690 OS NFS client is needed to access the M: and N:
drives from the terminal.
Configuring terminal NFS mount point data allows you to assign a terminal or group of
terminals to a remote host. By assigning terminals to a mount point group and defining mount
points within that group, you can define different resources to different terminals.
You can define a total of eight mount groups. Every terminal can be assigned to one of these
mount point groups. By default, each terminal is initially assigned to mount group 8. You can
define mount point data for this mount group to change the data for all terminals. Or, you can
override the default by assigning various terminals to different mount groups and then defining
different mount point data.
By default, no mount point data is defined for any of the mount groups. When you define mount
point data for a mount group, this data is retained. For example, if you define mount point data
for mount group 1 and then want to add a new terminal to mount group 1 at a later time, you do
not have to redefine the fields for mount group 1, you only need to add the new terminal to the
group.
Telnet client (ADXHSIVL.286)

The Telnet client support in 4690 TCP/IP enables a system to log on to a remote system using the
Telnet protocol. The remote system must have a Telnet server capable of supporting VT100 type
terminals. The Telnet client is a VT100 emulator and the program file name is C:\ADX_SPGM
\ADXHSIVL.286.
Use the ADXHSIVL command from a command prompt to start the 4690 Telnet client.
Optionally, the “vt100” (Telnet) logical name is defined during TCP/IP driver initialization to
ADX_SPGM:ADXHSIVL.286 and can be used to start the Telnet client.
While in a Telnet session, the escape sequence is CTRL+]. This enables you to set or display
different Telnet operating parameters. You can also exit the emulator by typing quit at the
VT100 prompt.
BOOTP client (ADXHSIBL.286)

The BOOTP client program (C:\ADX_SPGM\ADXHSIBL.286) is used to access TCP/IP host
initialization data from a BOOTP server in the network. Specifically, it can be used to obtain the
4690 IP address, domain name, name server IP address, and network router address. The
BOOTP client sends a broadcast request to a BOOTP server on the network and waits for a reply.
If no reply is received from a server within 25 seconds, the client gives up and does not update
any network initialization data.
When a server does reply, the BOOTP client performs the following:
1. Generates a batch file named C:\ADX_SDT1\ADXBP??Z.BAT (where ?? is the local store
controller/node ID) containing an ifconfig command that will configure the lan0 interface for
the received host IP address and, optionally, the subnet mask if one was sent. In addition, if
a network router (gateway) IP address was sent by the BOOTP server, a route command is
also added to this batch file.
2. Updates the resolv file with the name of the domain and IP address of the name server this
host should use to resolve hostnames to Internet addresses.
Note: The BOOTP client only builds the ADXBP??Z.BAT batch file, but does not actually invoke
the ifconfig and route commands. Prior to contacting a BOOTP server, the BOOTP client clears the

IP address of the controller, so the IP configuration batch file must be run after BOOTP
completes if network initialization is to occur.
To use the 4690 BOOTP client during IPL:
1. Copy the ifconfig lan0 and route (if used) commands contained in the configuration batch file
C:\ADX_SDT1\ADXIP??Z.BAT to another batch file named C:\ADX_SDT1\ADXBP??
Z.BAT. (You do not need to copy the adxhsi2l command to ADXBP??Z.BAT file.)
2. Delete the ifconfig lan0 and route (if used) commands from the ADXIP??Z.BAT file and
replace them with a single command that invokes the BOOTP client (for example, adxhsibl).
Next, use a call to the BOOTP batch file ADXBP??Z.
The two batch files would then look like this:
ADXIP??Z.BAT
adxhsi2l
adxhsibl
adx_sdt1:adxbp??z
ADXBP??Z.BAT
ifconfig lan0 <ip_address> ...
route add default <router_ip_address> ...
Using this example, when the BOOTP server is available and does respond, the BOOTP client
updates the batch file ADXBP??Z.BAT. It then returns control to the configuration batch file
ADXIP??Z.BAT, which then invokes the newly created configuration.
However, in the event that the BOOTP server is unavailable or does not respond to the BOOTP
client request in the timeout period, the 4690 would be able to initialize its interface based on the
current contents of the ADXBP??Z.BAT file.
Note: Prior to contacting a BOOTP server, the BOOTP client clears the IP address of the
controller, so the IP configuration batch file must be run if network initialization is to occur. This
is the case whether the BOOTP request was successful or failed.
Using the BOOTP protocol to update/create the SNMP trap

destination file
The 4690 BOOTP client can recognize a generic tag that specifies the host destination for SNMP
traps. The generic tag is placed in the BOOTPTAB file on the server. It can be specified as Tnnn:
where nnn is any integer between 128 and 254. The string associated with the generic tag must
begin with the characters SNMP: followed by the host name or IP address of the SNMP trap
destination. An example of a generic tag entry that indicates an SNMP trap destination can be
found in the ADXHSIAF.DAT file (BOOTPTAB) on the installation media.
When the 4690 BOOTP client recognizes the generic tag and determines that it is being used to
specify the SNMP trap destination, it creates or updates the SNMP trap destination file, C:
\ADX_SDT1\ADXHSIDF.DAT, with the name or IP address of the host that follows the SNMP:
prefix in the tag string. This enables automatic setting of the trap destination host during
network initialization.
BOOTP server (ADXHSIAL.286)

The 4690 BOOTP server program name is C:\ADX_SPGM\ADXHSIAL.286. It services requests
from BOOTP clients and supplies network initialization data, which it gathers from the
BOOTPTAB file C:\ADX_SDT1\ADXHSIAF.DAT. Because it is a UDP-based server, it cannot be
started directly from the INETD superserver. You can, however, configure it to be a 4690
background application, which starts during the store controller IPL.

The BOOTPTAB file is a data file that contains the network initialization data for specific hosts,
either based on the hardware adapter address or host IP address. A sample BOOTPTAB file is
copied onto the store controller during 4690 TCP/IP installation.
The format of the BOOTPTAB file and additional details on the BOOTP server can be found in
the Transmission Control Protocol / Internet Protocol for 4690 Application Interface (TCP/IP for 4690
Application Interface) document.
BOOTP extension file compiler

The BOOTP extension file compiler builds the extension path files described by RFC1497.
Configuring the PXE environment and DHCP Server (DHCPD.386)

The Preboot Execution Environment (PXE) provides a consistent and industry-standard means
for loading terminals. PXE provides an additional protocol for loading terminals versus the
proprietary RPL protocol previously used for loading terminals. PXE uses a standard set of
TCP/IP protocols, namely Dynamic Host Configuration Protocol (DHCP) and Trivial File
Transfer Protocol (TFTP). DHCP and TFTP provide network address allocation and network-
based booting on the client terminals.
PXE Environment Restrictions

The following restrictions apply to the PXE environment:
• Because PXE/DHCP involves IP broadcasting, the network should be configured in such a
way as to prevent "store hopping," that is allowing DHCP requests to be fulfilled by
controllers in other stores. In a non-routed network, "store hopping" can be prevented by
configuring each store on its own IP subnet.
• The 4690 DHCP Server only responds to DHCP requests from the terminals listed above as
being supported in a PXE environment. It is not intended for use as a general purpose DHCP
server.
PXE/DHCP/TFTP Server Communication

The flow for booting the 4690 terminals and how PXE, DHCP, and TFTP exchange information is
described below.
• The PXE/DHCP client running on the 4690 terminals uses DHCP to acquire an IP address and
boot information. The DHCP exchange can occur with any controller configured for DHCP
PXE services and may or may not be the configured primary or back-up controller for this
terminal.
• Upon receiving configuration and boot information from the DHCP exchange, the PXE client
uses TFTP or Multicast TFTP (MTFTP) to download the bootstrap. The MTFTP server is
automatically started on the controller for servicing PXE MTFTP requests.
Note: Multicast TFTP protocol is based on the standard TFTP protocol but, in this case, the
requested file is multicast to the client or to multiple clients who have joined the multicast
group.
• When the bootstrap code gains control, it uses MTFTP to download the operating system.
PXE Load Performance Considerations

In order to optimize load times for PXE terminals, the DHCP Server is configured to not check
for in-use addresses.
If the need to protect against duplicate IP addresses on the network is more critical, the DHCP
Server can be configured to check for in-use addresses before assigning an IP address to a 4690
terminal. This configuration is done by including the pingTime parameter with a value greater
than zero in the DHCP Server configuration file. The pingTime parameter with a nonzero value

tells the DHCP server to ping an IP address to insure that it is not already in use before offering
the IP address. The pingTime value specifies the amount of time (in milliseconds) that the DHCP
Server waits for a response after pinging the IP address. Because the in-use check causes a delay
in servicing DHCP requests, the recommendation is to specify a value of 200 ms or less. The
DHCP Server configuration file is named ADXIPxxD.DAT, where xx is the node ID of the
controller. The syntax to configure this item is: pingTime 200.
Note: The pingTime parameter is not configurable using the DHCP Server Configuration panels
in Controller Configuration.
PXE Configuration
Complete the following steps to configure the PXE environment:
1. Change the boot protocol in your terminal setup to PXE. Because this process is different for
each terminal type, refer to the manuals that shipped with your terminal for instructions on
how to change the boot protocol.
Note: If the terminal has a hard disk drive, disable the hard disk drive in the boot sequence
in your terminal setup.
2. Ensure the 4690 controller is configured for TCP/IP. See “Configuring 4690 TCP/IP” on page
19 for additional information.
3. Configure the DHCP server environment on the 4690 controller as described in
“Configuring the DHCP Server” on page 32.
Configuring the DHCP Server

The DHCP server can be configured by using either the GUI configuration panels under
Controller Configuration or by editing a text configuration file using a text editor. The
configuration data is for the operation of the DHCP, TFTP, and the PXE Dump servers on the
controller.
To use the DHCP Server GUI, choose Controller Configuration from the main menu and then
choose DHCP Server. In this case, the correct file name is created or modified for the controller
that is being configured. The DHCP Server GUI saves the changes to an inactive file. These
changes only become active after activating the controller configuration.
The DHCP server can also be configured by editing the active DHCP server configuration file.
To manually edit the DHCP configuration file, a sample DHCP configuration file is provided.
This sample configuration file specifies the necessary parameters for PXE booting and IP address
allocation. This file can be modified easily using any text editor. The sample DHCP
configuration file is named ADX_SDT1:ADXIP00D.DAT and is shown in Figure 1.
To begin, copy the sample configuration file (ADX_SDT1:ADXIP00D.DAT) to the active DHCP
configuration file, ADX_SDT1:ADXIPxxD.DAT, where xx is the 2-character controller node ID.
For example, if your controller node ID is CC, the copied file name will be
ADX_SDT1:ADXIPCCD.DAT.
After modifying the DHCP server configuration (using either the DHCP Server GUI followed by
controller configuration activation or by editing the active file), the configuration can be applied
by either IPLing the controller or by using the update option of the DHCPINFO Utility (dhcpinfo
-u). For additional details about using this feature, see “DHCPINFO utility” on page 36.
Note: The function of the StartPXEServers parameter is to start the PXE servers during controller
IPL. If you change the value of the parameter, it only has an effect when the controller is IPLed.
Note:
1. The active DHCP server configuration file name is ADX_SDT1:ADXIPxxD.DAT and is used
when editing the DHCP server configuration file. The inactive file name is
ADX_SDT1:ADXIPxxI.DAT, which is created by the DHCP Server GUI and is copied to the
active file name upon controller configuration activation. In both file names, xx is the 2-
character controller node ID.

2. See the TCx Sky Planning, Installation, and Configuration Guide for more information on how
to use the DHCP Server GUI.
3. Because the DHCP Server GUI has error detection capability, any errors made when
manually editing the DHCP server active configuration file (ADX_SDT1/ADXIPxxD.DAT)
could prevent the DHCP Server GUI from starting. If this situation occurs, delete the
inactive configuration file (ADX_SDT1/ADXIPxxI.DAT) and manually correct the error in
the active configuration file.
4. If you manually create the DHCP configuration file, the sample comments are also viewable
when you use the GUI.
# This file is a sample configuration file for a DHCP server supporting

# PXE clients. Comments are added to assist in understanding the
# configuration file.
# Start the servers required for PXE booting automatically: yes or no
StartPXEServers yes
# PXE boot file name
option 67 c:/adx_spgm/adxpxebl.btt # boot file name
option 13 64 # boot file size
# Global options. Passed to every client unless overridden at a lower scope.
# option 15 "test.ibm.com" # domain name
# option 6 10.1.1.1 # dns server
# option 3 10.1.1.1 # default router
# Setup to send options to the pxeclient. Sent in the encapsulated option 43.
vendor PXEClient
{
option 1 224.46.1.1 # multicast address for PXE bootstrap
option 2 76 # mtftp client - port 76
option 3 75 # mtftp server - port 75
option 4 2 # open timeout
option 5 2 # reopen timeout
option 200 224.46.1.2 # multicast address for OS load
}
# The following defines the IP address pool that the DHCP Server uses
# to assign IP addresses to DHCP clients. The format is as follows:
# subnet <subnet address> <netmask> <address range>
subnet 10.1.1.0 255.255.255.0 10.1.1.3-10.1.1.30
{
option 1 255.255.255.0 # netmask
}
#
# end of adxip00d.dat
#
Figure 1. Sample DHCP Configuration File
Quick DHCP Setup for PXE Booting

To setup DHCP quickly for PXE booting, complete the following steps:
1. Set the StartPXEServers parameter to yes in the controller's DHCP configuration file.
This parameter automatically starts the necessary servers, such as DHCP, during controller
IPL. Setting this parameter to yes is required for terminal loading.
2. Specify the IP subnet and address range for the IP address assignment by changing the
values after the subnet keyword in the controller's DHCP server configuration file. See
“Configuring values for subnet keyword” on page 34 for additional details.
3. Re-IPL the controller and you are ready for booting terminals using PXE.
DHCP Server Backup Configuration

To have backup capability for loading and dumping PXE terminals and/or for DHCP-assigned
IP addresses, and in addition to the prior configuration instructions, you can configure a DHCP
server to be running on more than one controller at the same time.
For each controller that will have DHCP running :

• Generate a DHCP configuration file (ADX_SDT1/ADXIPxxD.DAT, where xx is the controller
node ID).
• Set StartPXEServers to yes in each DHCP server configuration file.
• The multicast addresses (PXEClient vendor options 1 and 200) must be unique for each
DHCP server configuration file.
• The address range (on the subnet line) must be unique for each DHCP server configuration
file.
• Re-IPL the controller.
DHCP Configuration Options

The following list represents the set of options available for DHCP configuration in the DHCP
server configuration file.
• StartPXEServers - yes or no; indicates whether to automatically start the DHCP server
during controller IPL
• subnet - IP subnet/address range (see “Configuring values for subnet keyword” on page
34)
• vendor - vendor class (only "PXEClient" vendor is supported)
• PXEClient vendor option 1 - multicast IP address for loading bootstrap
• PXEClient vendor option 2 - multicast client UDP port
• PXEClient vendor option 3 - multicast server UDP port
• PXEClient vendor option 4 - multicast open timeout
• PXEClient vendor option 5 - multicast reopen timeout
• PXEClient vendor option 200 - multicast IP address for loading 4690 OS
• option 1 - network mask (not required for PXE environment)
• option 3 - router IP address (not required for PXE environment)
• option 6 - name server IP address (not required for PXE environment)
• option 13 - boot file size (always set to 64)
• option 15 - domain name (not required for PXE environment)
• option 67 - boot file name (always set to C:/ADX_SPGM/ADXPXEBL.BTT)
Note:
The PXEClient vendor options should be changed under the following conditions:
• The multicast IP addresses/ports (PXEClient vendor options 1, 2, 3, and 200) conflict with
other multicast IP addresses/IP ports on your LAN.
• You are running multiple, concurrent 4690 DHCP servers on the same LAN, in which case
the multicast IP addresses (PXEClient vendor options 1 and 200) must all be unique. These
addresses can be changed by simply changing the last field of the IP address.
Note: One or more subnet statements are allowed in a configuration file.
Configuring values for subnet keyword

subnet <Subnet address> [<Subnet Mask>] [<range>]
The Subnet address is the address of the subnet of this controller as configured in
ADXIPxxZ.BAT. The subnet address is specified in dotted decimal notation, for example,
9.17.32.0 or 128.81.22.0. The subnet must be within the subnet mask, and the address can be no
longer in bits than the subnet mask. For example, if the subnet mask is 255.255.255.0, the address
9.67.10.128 is too long. The subnet address can be optionally followed by the Subnet Mask or a
range.
The Subnet Mask for the subnet is specified in dotted decimal notation or in integer format. A
subnet mask divides the subnet address into a subnet portion and a host portion. If no value is
entered for the subnet mask, the default is the class mask that is appropriate for an A, B, or C

class network. The subnet mask is specified in dotted decimal notation, for example,
255.255.255.0.
If a range is specified, it describes the pool of addresses that this server will administer for this
subnet. A range is specified by host addresses in dotted decimal notation separated by a hyphen
with no intervening spaces, for example, 192.81.20.1-192.81.20.128. If no range is specified, all
host addresses in the subnet are administered by this server.
Note:
1. The address pools administered by different DHCP servers on the same subnet, that are
running at the same time, must not overlap; otherwise, two hosts could be assigned the
same address.\
2. Statically assigned IP addresses that are defined in the terminal load definition must not
overlap with the DHCP server address pool.
For example, to configure the range of addresses 192.81.20.1 through 192.81.20.127 on subnet
192.81.20.0 with subnet mask 255.255.255.0, create the subnet statement:
subnet 192.81.20.0 255.255.255.0 192.81.20.1-192.81.20.127
A subnet statement can be followed immediately by a pair of curly brackets, in which

parameters particular to this subnet can be specified, such as options.
Configuring DHCP for terminal TCP/IP

When the terminal has loaded the operating system, DHCP can be used to configure operational
IP information for use by TCP/IP applications running on the terminal. In this case, a DHCP
client runs on the terminal during terminal IPL to request an IP address and other IP
configuration information. To co-exist with multiple DHCP servers on the network, the DHCP
client can be tailored to limit the DHCP negotiation to only a 4690 DHCP server or to negotiate
with non-4690 DHCP servers. By default, the DHCP client accepts only an offer from a 4690
DHCP server.
To configure the DHCP client to accept offers from non-4690 DHCP servers, a terminal logical
name must be defined and named DHCPEXT in ADX_IDT1:ADXTRMUF.DAT. DHCPEXT must
be set to one of the following values:
• DHCPEXT = 1 - Client is serviced by the first offer that is received from any DHCP server
• DHCPEXT = 2 - Client is serviced by only non-4690 DHCP servers
DHCP for TCP/IP terminal configuration is available for Ethernet-attached terminals. First, in the
terminal load definition under the TCP/IP option, indicate 1 (yes). Second, under the Address
Method option, indicate 2 (DHCP server). In this case, the following options are available in the
DHCP server configuration file to configure your terminal for TCP/IP. These are the same fields
that would be configured under static TCP/IP configuration.
• option 1 - subnet mask
• option 3 - default router IP address
• option 6 - name server IP address
• option 15 - domain name
If a terminal is configured for TCP/IP using DHCP, the HOSTS file,
ADX_SDT1:ADXHSIHF.DAT, is updated by the DHCP server with the assigned hostname and
IP address. The terminal hostname has the format Tssssttt where ssss is the store number
and ttt is the terminal number. For example, terminal 005 in store 0055 is assigned IP address
10.10.1.4, and would add the following entry to the HOSTS file:
10.10.1.4 T0055005 #DHCP
This entry allows TCP/IP applications to address the terminal as host name, T0055005, rather
than the dotted decimal IP address. The #DHCP comment indicates that this entry was added by

the DHCP server and therefore, can be "managed" by the DHCP server. The user can still add
alias hostnames of their own choosing to the HOSTS file without the #DHCP comment. These
alias hostnames in the HOSTS file are not managed by the DHCP server.
DHCPINFO utility
DHCPINFO is a utility for displaying DHCP Server configuration information and lease status,
for removing leases, and for applying updates to the DHCP server configuration. The format for
the DHCPINFO Utility is shown below.
dhcpinfo [-s <server IP address>] [-r <IP address> | "all"] [-u]

[-t <RTU server IP address> | "0"] [-b "supps" [-v <minutes>] | -b "0"]
Where:
• dhcpinfo with no options displays DHCP server configuration information and lease status
on the local machine.
• -s specifies a remote server IP address for displaying status, removing leases, updating the
DHCP server, RTU configuration or supplemental boot mode configuration.
• -r specifies the IP address of an individual lease to remove or "all" for removing all leases.
• -u updates the DHCP server configuration using the current active configuration file. This
option allows you to apply a modified DHCP configuration without a controller IPL.
• -t applies the DHCP Remote Terminal Utility (RTU) option with the specified RTU Server IP
address or removes the applied RTU option if 0 is specified. The DHCP RTU option is active
only in DHCP server memory and is not retained on a controller IPL. Also, dhcpinfo -t
internally performs a DHCP configuration update (dhcpinfo -u) to apply the RTU option
settings; therefore any modifications in the active DHCP Server configuration file will also be
applied with dhcpinfo -t. Refer to “Using the Remote Terminal Utility” on page 40.
• -b supps applies the DHCP option to enable network supplemental boot or removes the
option if 0 is specified. By default, supplemental boot mode is enabled for a period of five
minutes and is automatically disabled after this time period. For more information on the
network supplemental boot option, refer to "Booting Enhanced Supplementals over the
network" in the TCx Sky User's Guide.
• -v -b supps parameter to set a time-out period (0-60 minutes) for the supplemental boot
mode other than the default of 5 minutes. A value of 0 indicates no time-out on supplemental
boot mode and the user may manually disable using the -b 0 parameter.
Examples:
dhcpinfo
displays the status of the DHCP server on the local machine
dhcpinfo -s 1.1.1.2
displays the status of the DHCP server that is running at IP address 1.1.1.2
dhcpinfo -r 1.1.1.5
removes the lease for the IP address 1.1.1.5 (local server)
dhcpinfo -r all
removes all the leases assigned by the local DHCP server
dhcpinfo -r 1.1.1.10 -s 1.1.1.2

removes the lease for IP address 1.1.1.10 that was assigned by server 1.1.1.2
dhcpinfo -u
updates the configuration of the DHCP server running on the local machine

dhcpinfo -u -s 1.1.1.2
updates the configuration of the DHCP server running at IP address 1.1.1.2
dhcpinfo -t 1.1.1.1
sets DHCP RTU option to 1.1.1.1 on local DHCP server
dhcpinfo -t 0
clears DHCP RTU option on local DHCP server
dhcpinfo -t 1.1.1.1 -s 1.1.1.2

sets DHCP RTU option to 1.1.1.1 on DHCP server 1.1.1.2
dhcpinfo -t 0 -s 1.1.1.2
clears DHCP RTU option on DHCP server 1.1.1.2
dhcpinfo -b supps
enables network supplemental boot on the DHCP server on the local machine for a
period of 5 minutes
dhcpinfo -b supps -v 10
extends the period of time the supplemental boot is enabled to 10 minutes
dhcpinfo -b supps -v 0
enables network supplemental without a timeout period
dhcpinfo -b supps -s 1.1.1.2

enables network supplemental boot on DHCP server that is running at IP address 1.1.1.2
dhcpinfo -b 0
disables network supplemental boot on the DHCP server on the local machine
dhcpinfo -b 0 -s 1.1.1.2
disables network supplemental boot on the DHCP server that is running at IP address
1.1.1.2
Following is a sample of output from the DHCPINFO Utility along with descriptions of the
output fields.
DHCP Status for Server 1.1.1.2:

RTU Server: 1.1.1.2
Boot Mode: supps
Address Status Lease Client ID Last Leased
------- ------ ----- --------- -----------
1.1.1.5 In Use 1000 0004acd12345
1.1.1.6 Leased 86400 0004acd23456 Oct 3 16:24:57 2001
1.1.1.7 Reserved 300 0004acd34567 Oct 3 16:25:01 2001
1.1.1.8 Leased Infinite 0004acd45678 Oct 3 16:27:59 2001
1.1.1.9 Released
1.1.1.10 Available
Address:
The IP addresses that are configured for assignment by this DHCP server.
Status:
• Available - The address is available for assignment by the DHCP server.

• Leased - The DHCP server has leased the address to a DHCP client.
• Released - The DHCP client has released the address.
• Reserved - The DHCP server has issued an offer to a DHCP client for this address.
• Expired - The lease has expired.
• In Use - The DHCP server has found this address to be in use.
Lease:
The amount of time in seconds of the lease for this address. The amount of time might
also be "Infinite" if it is a permanent lease. Reserved and in use addresses are also timed
with a short lease.
Client ID:
The MAC address of the client.
Last Leased:
The time when the DHCP server last assigned the address.
RTU Server:
The IP address that is configured for RTU by this DHCP server or none if an RTU server
is not configured.
Boot Mode: supps

The network supplemental boot option is enabled on this DHCP server. This line will be
blank if not enabled.
Troubleshooting the DHCP server

The DHCP server logs messages W978 and W980 to aid in problem resolution. Event number =
E200 indicates that the DHCP server logged the message. For the event numbers, see Table 2.
Table 2. DHCP server error message event numbers

Call Info RC Description
02xx DHCP INIT The DHCP server could not initialize due to
TCP/IP socket errors. Ensure that TCP/IP is
configured and running on your controller.
This message could also occur if you attempt
to start the DHCP server when it is already
running.
0301 config file name The DHCP server could not open the DHCP
server configuration file.
0402 DHCP NO IP The DHCP server has no IP addresses
available for assignment. All IP addresses in
the configured address pool have been
assigned by the DHCP server or are in use,
such as assigned by another DHCP server or
statically assigned. Use the DHCPINFO
Utility to determine the status of the DHCP IP
address assignment and whether the IP
address pool must be increased to cover the
number of terminals. This error can also
indicate that the subnets configured in the
DHCP Server Configuration do not include
the subnet of the host (terminal) requesting an
IP address. If assigning addresses on a local

Call Info RC Description
subnet only, the local subnet is determined by
the IP address of the controller where it is
running as configured in ADXIPxxZ.BAT. In
this case, review the ADXIPxxD.DAT and
ADXIPxxZ.BAT files and ensure that the
controller IP address and the DHCP address
range to be assigned to terminals are all on
the same subnet.
0403 / DHCP INIT The DHCP server could not initialize due to
0404 errors in the DHCP server configuration.
Review the ADXIPxxD.DAT file (where xx is
the controller node ID) for possible errors. A
common problem is that the address range
specified on the subnet statement is outside
the scope of the subnet.
0405 hostname IP address in The DHCP server could not update the
hexadecimal HOSTS file with the hostname and IP
format address. Most likely this is a result of no
acting master.
Using TCC and PXE in a routed environment

If communications between the 4690 store controller and the terminal pass through a routed
network, the 4690 environment must be configured to use IP protocols. First, TCP/IP must be
configured on the controller and terminals, including configuration of the default router. In
addition, the terminals must be configured for TCC over IP (TCC/IP), and the terminals must be
booted using PXE. Additional changes to configure the TCC/IP and PXE protocols for routing
are described below.
Because TCC over IP (TCC/IP) uses IP multicasting for communications between the controller
and the terminal, the IP Multicast TTL (time-to-live) must be adjusted for use over a router. TTL
is the number of hops or routers through which a packet passes before being discarded. By
default, the Multicast TTL is set to 1 to avoid unwanted forwarding of multicast packets. When
using TCC/IP over a router, the TCC Multicast TTL must be increased to the number of hops on
the TCC network. The TTL should be set to the minimum value required to pass through any in-
store routers to prevent multicast traffic from being forwarded to other stores. In addition, a
TCC Acknowledgment Time-Out value can be adjusted (although, this adjustment is not
required) to account for any delays introduced on the TCC network due to the presence of
routers. These values are set by editing the TCC/IP configuration file,
ADX_SPGM:ADXTCCIF.DAT, shown below. Details for modifying the TCC/IP configuration are
described in the TCC/IP configuration file itself.
PXE booting uses DHCP to provide IP configuration information to the PXE client on the
terminal. If passing through a router, the Router option, DHCP option 3, in the DHCP Server
Configuration should be configured with the IP address of the router. PXE booting uses
Multicast TFTP (MTFTP) for loading terminals, and uses the same TTL value configured in the
TCC/IP configuration file to set its Multicast TTL.
Configuration changes on the router are also required. The router must be configured to forward
the DHCP requests to the DHCP server on the store controllers. Depending on the actual router,
these configuration changes would include configuring the "DHCP (or BOOTP) Relay Agent"
and the "Helper Addresses." Also, the router must be configured for multicast support,
including enabling multicast and specifying that IGMP Version 1 is to be used.

TCC over IP configuration file (adx_spgm:adxtccif.dat)
# This file contains various default values for TCC over IP
# and is used by both controller and terminal.
# Comment lines begin with '#', edited values MUST begin in
# the leftmost column. You may edit any of the default values
# but DO NOT DELETE ANY OF THE LINES CONTAINING A DEFAULT
# VALUE OR CHANGE THEIR ORDER WITHIN THIS FILE. Any value
# which does not fall within the specified ranges will be
# assigned the default value.
# To activate changes to this file, build a new terminal
# load shrink, re-ipl controllers and reload terminals.
#
# The following is an explanation of the default
# values which are related to TCP/IP:
#
# IP Multicast addresses must fall within the range of
# 224.0.0.0 - 224.255.255.255 however do not use
# well known IP multicast addresses.
# Port numbers must fall within the range of 1024 - 65535
#
# CONTROLLER MULTICAST ADDRESS is the multicast group
# address which the controller joins.
# TERMINAL MULTICAST ADDRESS is the multicast group
# address which the terminal joins.
# PORT numbers are used by both controller and
# terminal for multicast and acknowledgments.
# These port numbers should not be configured in the ports file,
# ADXHSISF.DAT.
# IP MULTICAST TIME TO LIVE is the number of hops which a
# multicast can travel before it is discarded from the network.
#
# controller multicast address
224.46.90.1
# terminal multicast address
224.46.90.0
# multicast port
4691
# acknowledgment port
4692
# IP multicast time-to-live, range 1-255
1
#
# The following is an explanation of the default value which
# is related to TCC:
#
# ACK TIME OUT is used by a TCC network station to detect a failure
# to receive a required acknowledgment from another TCC network station.
# The duration of the timer should take into account the maximum delay
# between a controller and terminal in your TCC network. Also take into
# account that increasing the ack time out will increase, by a factor of 3,
# the time for a terminal to go offline and the time for the backup to
# respond. Normally, the default value of 1000ms (1 sec) is more than
# adequate for this delay, however, if a TCC network station requires a
# delay greater than 1 second, the value can be edited. The timer
# has a granularity of 32ms.
#
# ack time out, range 1000 - 99999
1000
Using the Remote Terminal Utility

The Remote Terminal Utility (RTU) provides the means to remotely load and run a utility on a
PXE terminal prior to loading the OS. This capability is useful for remotely configuring CMOS
settings on unattended terminals. RTU is supported on SurePOS Model 350, Model 74x, 77x and
78x terminals. RTU is not supported on newer model TCx series terminals or on terminals
configured to boot from the hard drive. RTU can be configured to run on one or more terminals
and can run the same or different utilities. The configured utility runs one time only on the next
terminal reload and subsequently loads the OS. Further terminal reloads will not run the utility

unless it is reconfigured. Details for configuring RTU are provided below. Information for
creating an RTU compatible utility image is provided in Creating the RTU image.
Note: Please take precautions when using any utility. RTU cannot safeguard against improper
usage of a utility, using the wrong utility, or a utility with incorrect data. Such cases of improper
usage could result in terminals not being able to load and might require service personnel to
resolve.
The RTU server (adxrtu.386) is a 32-bit application which runs on the store controller and
communicates with the PXE bootstrap to provide RTU information. The RTU server may be
started from the command line or as a background application.
The user provides a configuration file as input to the RTU server to indicate the list of terminals
and utilities to be processed. The RTU configuration file, adx_sdt1:adxrtucf.dat, is a local text file
created on the controller running the RTU server. The file contains a variable number of lines,
each line with a terminal number and name of the utility image file to be loaded. White space is
ignored and '#' in the first position of a line indicates a comment line. Example RTU
configuration entries are shown below to load cmos721.img on terminal 100 and cmos722.img on
terminal 105.
100 adx_boot:cmos721.img
105 adx_boot:cmos722.img
A DHCP option is used to trigger RTU requests on the terminal. The DHCP RTU option includes
the IP address of the controller running the RTU server. The user configures the RTU DHCP
option on each controller running a DHCP server. When a PXE terminal is booted, the RTU
DHCP option is included with the DHCP information provided to the terminal PXE bootstrap
and indicates to request RTU information from the RTU server running at the IP address
specified.
The DHCP RTU option is configured in one of two ways. The first method is to update the
DHCP Server Configuration file with the rtuserver keyword followed by the IP address of the
controller running the RTU server as shown below:
rtuserver 1.1.1.1
When the DHCP configuration file has been modified, the DHCP configuration is applied using
either dhcpinfo -u or by a controller IPL.
Another method of configuring the DHCP option is to use the -t parameter of the dhcpinfo
command to enable or disable RTU dynamically. Refer to “DHCPINFO utility” on page 36 for
more information.
If the RTU option is enabled, the terminal sends a request to the RTU server to inquire if it
should load a special image. The server responds with either an image name to load or indicates
to continue booting normally. The terminal uses TFTP to transfer the image and notifies the
server of the success or failure of the load. If successful, the terminal passes control to the RTU
image and the server updates its list of terminals to be processed indicating this terminal has
completed its RTU image load. The server also modifies the RTU configuration file with a
comment character (#) in column 1 of that entry. If the RTU image does not load, the terminal
remains in the RTU list to be attempted again on the next terminal reload and the terminal
continues to boot normally.
The RTU server maintains a log with time-stamped entries indicating success or failure of
terminals loading RTU images. Other RTU status, errors and informational messages are also
logged by the RTU server to maintain a history of RTU activity.
Note: The results of the actual utility started by the RTU service are not available to 4690 OS.
Instructions for running RTU

The list below summarizes the steps required to configure and run the RTU service:

1. Create the image file (such as CMOS set utility) and install on the controller in the c:/
adx_boot directory and distribute to other controllers.
2. Create the configuration file, adx_sdt1:adxrtucf.dat, with terminal number(s) and image
name(s) to load.
3. Start the RTU server, adxrtu.386, from either command line or background.
4. Configure the DHCP RTU option on each DHCP server using dhcpinfo -t x.x.x.x [-s y.y.y.y]
where
• x.x.x.x is the dotted decimal IP address of the RTU server.
• y.y.y.y is the IP address of the DHCP server (-s option not required if the DHCP server is
the local controller).
5. Load terminals. Terminals will run the image, reboot and load normally.
6. Check the output file, adx_sdt1:adxrtu.log, to determine status.
7. Issue dhcpinfo –t 0 to all DHCP servers to disable RTU checking on the terminal side. Stop
the RTU server.
Creating the RTU image

On a Windows system (or other OS supporting DOS capabilities), create a DOS bootable image
containing the following:
• The DOS utility to run on the terminal (for example, the CMOS set utility).
• coldrbt.com* (available on the 4690 OS Optional Programs package) to reload the terminal
after the utility has run (optional).
• autoexec.bat file invoking the utility and optionally invoking coldrbt.com.
Please reference the Toshiba support site at http://www.toshibacommerce.com/support for
information on CMOS utilities available for your specific POS hardware.
SNMP agent (ADXHSI1L.286)

The 4690 Simple Network Management Protocol (SNMP) agent (server) is designed to operate
with an SNMP network management station (client). The SNMP network management station
polls or queries the SNMP agent for information about the network (for example, number of
UDP datagrams transmitted). The information is stored by the agent in a database called the
Management Information Base, or MIB. The 4690 SNMP agent supports the MIB-II definition for
managed objects (excluding the Exterior Gateway Protocol group) for GET and GET-NEXT
requests. The setting (SET-request) of MIB objects is not supported.
In addition to providing access to MIB-II network objects, the SNMP agent can asynchronously
send TRAPs to the network management station whenever a significant network event occurs.
Currently, there are two different types of TRAPs that can be sent by the SNMP agent:
• Cold-Start, which notifies the network management station that this SNMP agent has just
been started
• Authentication Failure, which indicates that an attempt to access this SNMP agent’s MIB
objects was made by an unauthorized network management station
Because the SNMP agent is a UDP-based server, it cannot be started by the INETD superserver.
However, it can be configured as a 4690 background application, which starts during the store
controller IPL. See the TCx Sky User's Guide for information on configuring background
applications.
Community names file

Access to the 4690 MIB-II objects is only allowed for authorized network management stations.
Those stations are defined in the community names file.

The 4690 SNMP agent uses an encrypted community names file, C:
\ADX_SDT1\ADXHSIEF.DAT, to validate a network management station. The encrypted file is
built from an ASCII text file, C:\ADX_SDT1\ADXHSIQF.DAT, created by the user.
To build the encrypted community names file:
1. Create the ASCII text community names file as C:\ADX_SDT1\ADXHSIQF.DAT. (A
sample file is copied onto the store controller during 4690 TCP/IP installation. Refer to this
sample file for the format of its entries.)
2. Invoke the encryption program ADXHSI8L from a 4690 command line. This program
assumes the input file is C:\ADX_SDT1\ADXHSIQF.DAT and creates the encrypted output
file C:\ADX_SDT1\ADXHSIEF.DAT.
It is recommended that you build and maintain the ASCII text community names file in a secure
location. Only the encrypted community names file needs to exist on the 4690 store controller.
Note: The encrypted community names file must exist in order for the 4690 SNMP agent to
successfully initialize. If the SNMP agent cannot access the encrypted community names file, it
will log a system message and terminate.
SNMP agent environment names

In addition to the community names file, three environment names must be defined to the 4690
system. These names correspond directly to MIB objects. The environment names are:
• syscont - specifies who to contact in case of problems, for example, Joe Smith.
• sysloc - specifies the physical location of this host, for example, Store 101CC.
• hostname - specifies the name of the host on which you are running. This name must be able
to be resolved to an IP address either by a name server or using the hosts file.
These three environment names are defined by one of two methods: user-defined logical file
names in 4690 controller configuration or listed in the C:\ADX_SDT1\ADXHSIZF.DAT file.
The format of the SNMP environment names file, C:\ADX_SDT1\ADXHSIZF.DAT, is:
syscont Contact_Name # comment
hostname Host_Name # comment
sysloc System_Location # comment
A sample SNMP environment names file, C:\ADX_SDT1\ADXHSIZF.DAT, is copied onto the

4690 store controller during 4690 TCP/IP installation. Precedence is given to the logical file name
definition of the SNMP environment name before determining if the name is defined in the
SNMP environment names file.
Note: The three SNMP environment names must exist on each machine in which the 4690 SNMP
agent is to run either as user-defined logical file names or within the SNMP environment names
file (or some combination of both). However, the assignment for each name does not have to be
unique across all machines (for example, a syscont of Joe Smith might not be the same on every
machine).
SNMP trap destination file

The SNMP trap destination file identifies the network management station to which traps will be
sent. This file is named C:\ADX_SDT1\ADXHSIDF.DAT. A sample trap destination file is
copied onto the store controller during 4690 TCP/IP installation. Refer to the sample trap
destination file for the format of its entries. If the trap destination file does not exist, traps will
not be sent.
MIB-II
Extension of the MIB objects can be accomplished using the SNMP Distributed Program
Interface (SNMP DPI) for 4690. The SNMP DPI enables enterprise-specific MIB objects to be

created and also provides an application the capability to generate traps. Refer to your TCP/IP
documentation for information on MIB-II groups and objects.
Telnet server
The 4690 Telnet server can support a VT100, ANSITERM, or 3151 Telnet client. The following
4690 Telnet server characteristics must be noted:
• Only one client can access the 4690 Telnet server at a time.
• When logged on to the 4690 Telnet server, the client shares the main system keyboard and
display.
For an alternative Telnet server that does not have these limitations, see “Enhanced Telnet server
(ADXHSIUL.286)” on page 45.
Operation
A Telnet entry should be included in the INETD data file, C:\ADX_SDT1\ADXHSIIF.DAT, so
that the INETD superserver can start the Telnet server when a client attempts a connection. The
example INETD data file copied onto the store controller during 4690 TCP/IP installation
contains a Telnet entry. The INETD superserver will start the Telnet server automatically
whenever a client issues a connection request.
Logging On and Off

The Telnet server uses the 4690 system user IDs and passwords to grant login access to Telnet
clients. For example, the default 4690 system user ID is 99999999 with password of 99999999.
When the Telnet client is prompted for user ID and password, the server validates the input
against the 4690 system-maintained user IDs and passwords.
To log off normally, enter the Telnet command mode on the client terminal using the Telnet
escape sequence (usually Ctrl+]) and type quit. Ctrl+D will not close the connection. In addition,
Telnet sessions that are idle can be automatically disconnected by the 4690 Telnet server. The
timeout for disconnection due to inactivity can be set by creating a user-defined logical file name
of ADXTNDTO and assigning it a value (greater than 0) that corresponds to the number of idle
minutes the Telnet server will wait before it automatically disconnects. The default timeout is
infinite and is used if the ADXTNDTO logical file name does not exist or is defined to an invalid
value.
If a client attempts to log on to the server and someone else is already logged on or the server is
hung, an option of stopping the active Telnet server process is provided. If you choose to stop
the other process, the active session will be disconnected, and you will receive a message telling
you to try to log in again.
Using a keyboard
The 4690 System Request function is mapped to the tilda-backquote (~`) key transmitted by the
Telnet client. Other function keys transmitted from the PS/2®-style keyboards are known to
operate consistently with function keys entered from the 4690 keyboard.
Note: Due to time delays in some network environments, the Telnet server might need to issue
more than one read to get an entire function key sequence. For most networks, a 50 ms delay is
sufficient for the entire key sequence to arrive. If you are using a WAN environment or a slow
network, you might need to define the logical name TNDESCTO to the number of milliseconds
you want the Telnet server to wait for an entire function key sequence. The default is 50 ms.
Suggested values are 250 to 1000 ms (1/4 to 1 full second).
Locking out the local keyboard

When logged in through the Telnet server, it is possible to lock the local keyboard. This enables
only the remotely logged in user to have control of the console. The executable file is

ADX_SPGM:ADXHSILL.286. The local keyboard can be locked by issuing the following
command:
ADXHSILL LOCK
The local keyboard will be unlocked upon a normal or abnormal end of the Telnet server, or it
can be unlocked with the following command:
ADXHSILL UNLOCK
Also, you can lock and unlock the local keyboard from any screen without using the ADXHSILL
command directly. Typing Ctrl+B blocks the local keyboard and typing Ctrl+U unblocks it.
Terminfo and Termcap files

The 4690 Telnet server does not use TERMINFO or TERMCAP files. There are three basic
terminal types supported:
• VT100
• ANSI
• IBM 3151
Also, terminal types of aixterm, xterm, VT100-am (auto margins) are supersets of VT100 and are
supported using the VT100 protocols. If an attempt is made to log on to the 4690 Telnet server
from an unknown terminal type, the connection will be closed and the client is sent a message
indicating that the 4690 Telnet server cannot support the terminal.
Log files
The 4690 Telnet server is actually composed of two processes working together. Program
ADXHSIIL.286 is the keyboard input process, and program ADXHSISL.286 is the screen output
process. Both of these programs can log messages into the ADXHSIIL.LOG and ADXHSISL.LOG
files in the ADX_UPGM subdirectory.
Telnet server considerations

"Real" VT100 terminals are 24-row by 80-column displays. It is recommended that a 25-row
VT100 emulator is used. A 24-row emulator can be used, but display results are unpredictable
when the 25th row is received (for example, it is sometimes displayed and row 1 scrolls off the
display; other times row 25 is not displayed). Some terminal definitions of VT100-am are defined
with 25 rows.
Most ANSI terminal types are 25-row by 80-column displays. These terminals work well with
the 4690 Telnet server. In addition, if the connection is made to the server from an ANSI terminal
type, the color attributes of fields (if you have a color display) will be sent to the terminal. One
disadvantage to ANSI terminal types is that there appears to be no consistent definition of
function keys and other special keys.
Included on the installation media is an ANSI TERMINFO file for the AIX operating system
workstations. The file is called ANSITERM.TI and can be compiled using TIC in the /usr/lib/
terminfo directory (you must have root access to do this). You can use this TERMINFO file to
define your terminal as ANSI (that is, export TERM=ansi). If your client is on a color display, use
ANSI to allow color information to be sent from the 4690 Telnet server. VT100 terminal
emulation is black and white only.
Enhanced Telnet server (ADXHSIUL.286)

The 4690 Enhanced Telnet server supports VT220, VT100, ANSI and HFT. It can also support
other terminal types, especially where they are similar to the supported types. Unlike the regular

Telnet server, the Enhanced server enables multiple clients to be connected simultaneously. You
would configure this through the auxiliary console section of controller configuration.
Operation
A Telnet entry should be included in the INETD data file, C:\ADX_SDT1\ADXHSIIF.DAT, so
the INETD superserver can start the Telnet server when a client attempts a connection. The
example INETD data file copied onto the store controller during 4690 TCP/IP installation
contains the following entry for the regular Telnet server:
telnet tcp ADX_SPGM:ADXHSIIL.286
This should be changed for the Enhanced Telnet server to:

telnet tcp ADX_SPGM:ADXHSIUL.286
Note: The INETD superserver will start the Telnet server automatically whenever a client issues
a connection request.
Logging On and Off

When a connection is made to the Telnet server, the logon screen is presented, and you must log
on as if you were at the main console or another auxiliary console.
To log off normally, enter the Telnet command mode on the client terminal using the Telnet
escape sequence (usually Ctrl+]) and type quit. Alternatively, you can configure a one-key logoff
sequence that will log your user ID off normally and terminate your Telnet session. By default,
there is no one-key logoff. However, you can change this by defining a user logical name of
ADXTNDLO, which contains the ASCII value for the single character you want to use to log off.
For example, use Controller Configuration, User Logical File Names, and define the name
ADXTNDLO to have a value of 4. Now when you Telnet into the 4690 store controller, press Ctrl
+D to log off and terminate your Telnet session, this returns you to where you initiated the
session on your Telnet client.
Only the number of sessions configured using Controller Auxiliary Console configuration can be
supported. If an additional client attempts to connect when there are already the maximum
number of sessions in operation, then the connection is automatically refused.
From the Background Application Control menu you can see a separate copy of ADXHSIUL.286
operating for each connected session. It is also possible to terminate connections from this panel
using F8 (Stop).
By default, the Telnet server will request a device status report from the Telnet client after one
minute of inactivity. Most clients will automatically respond to this, and the server will keep the
connection open. If, after a longer time interval, there is no response, the server will end the
connection on the assumption that the client has been removed.
If you want to change the time interval at which this request is sent or disable it altogether, you
can define the user logical name ADXTNDTO to the number of minutes you want the interval to
be or to 0 minutes to disable it.
Using a keyboard
By default, the backquote character (`) is mapped to the 4690 System Request function. However,
you can change this by defining a user logical file name of ADXTNDSR, which contains the
ASCII value for the single character you want to map to the 4690 System Request. Also, if you
are using a VT220 client, you can use Alt+F12 as an alternate way to generate a 4690 SysRq.
For example, click Controller Configuration, User Logical File Names, and define the name
ADXTNDSR to have a value of 1. Now, when you Telnet into the 4690 store controller, pressing
Ctrl+A takes you to the system keys menu.

Note: Due to time delays in some network environments, the Telnet server might need to issue
more than one read to get an entire function key sequence. For most networks, a 50 ms delay is
sufficient for the entire key sequence to arrive. If you are running over a WAN or a slow
network, you might need to define the logical name TNDESCTO to the number of milliseconds
you want the Telnet server to wait for an entire function key sequence. The default is 50 ms.
Suggested values are from 250 to 1000 ms (1/4 to 1 full second).
Locking out the local keyboard

The Enhanced Telnet server operates the same as an auxiliary console. It does not lock out the
local keyboard.
Terminfo and Termcap files

The 4690 Enhanced Telnet server does not use TERMINFO or TERMCAP files. It has been tested
with the following terminal types:
• VT220
• VT100
• ANSI
• HFT
Other terminal types that are similar can also work. The Enhanced Telnet server does not reject
connections based upon the terminal type. A valid terminal type must be selected at the client.
Log files
The 4690 Enhanced Telnet server does not log messages to any files. Information messages will
be displayed on the background application control panel in the MESSAGE field for the
corresponding Telnet server.
Telnet server considerations

Some Telnet clients do not correctly support insert and delete escape sequences. This is most
noticeable in 4690 Command Mode, where the output on the client window, when using the
delete key, might not accurately reflect what has actually happened on the 4690 system.
See “Telnet server considerations” on page 45 for information about 24-row displays. If your
client supports VT220, you can use Alt+F12 to emulate 4690 SysRq.
LPR client (ADXHSIRL.286)

The LPR client program is invoked from a 4690 command line as ADXHSIRL and accepts the
same input parameters as the OS/2 LPR program. All required command parameters can be
explicitly provided to the 4690 LPR program. You can define a logical name of LPR_SRV instead
of using the “-s <server>” parameter to the LPR program in order to specify the default remote
print server. Similarly, you can define a logical name of LPR_PRT instead of using the “-p
<printer>” parameter in order to specify the default logical printer on the remote print server.
See the TCP / IP for 4690 Application Interface Guide for the command line interface to LPR.
Remote printing through the 4690 print spooler

The LPR client (ADXHSIRL.286) can also be used by the 4690 print spooler mechanism to send
print jobs to remote TCP/IP LPD network print servers. When defined to the 4690 system, these
network print queues can be accessed in the same way that local 4690 print queues are accessed.
To define a network print queue:
1. Define a network printer on one of the available printer ports, 1 through 8.
2. Select Installation and Update Aids from the SYSTEM MAIN MENU.

3. Select Change Configuration Data and then Controller Configuration.
4. Select Multiple Printers and the PRINTER DEFINITION panel displays.
5. Select Add Printer Definition for any available printer number and optionally configure
this printer as the system printer.
6. Select Activate Configuration from the CONFIGURATION MENU to make your changes
take effect.
For more detailed information on defining printers, see the TCx Sky Planning, Installation and
Configuration Guide.
7. Define the user-defined logical name LPRPARMx, where x is the port number of the
previously defined network printer. This logical name contains the parameters taken by the
LPR command. This logical name must contain the following two parameters:
• -S <hostname>, where hostname is the name of the LPD server
• -P <device>, where device is the print device on <hostname>
• -T, <timevalue>, where timevalue is the number of seconds that the LPR client should wait
for a response from the print server. If the print server does not respond and the timer
expires, the LPR client will re-drive the print attempt. This is an optional parameter, but
if it is not defined then the LPR Client on the controller will wait indefinitely for a
response from the print server.
For a list of valid options to the LPR command, see the TCP / IP for 4690 Application Interface
Guide.
An example of this is if you have just defined (and activated) a printer on port 7, and you want
all print jobs on that queue to be sent to a TCP/IP LPD print server named PRINTSRV, which has
a printer attached to device lpt1. You need to define a logical name called LPRPARM7, which is
defined to -S PRINTSRV -P LPT1. For more information on user-defined logical names, see
the TCx Sky User's Guide.
After successfully completing the above configuration steps, you should then be able to access
the defined print queue. For example, you can use the command:
print <filename> -d=prn7:
This command sends the print job to the remote TCP/IP LPD print server.
Note: If you want to use the LPR_SRV or LPR_PRT logical names, as described in “LPR client
(ADXHSIRL.286)” on page 47, with the print spooler function, these logical names must be
system-level defined logical names. The print spooler will not find process-level logical names.
Rexec client (ADXHSIXL.286)

The Rexec client program is invoked from a 4690 command line as ADXHSIXL and accepts the
same input parameters as the OS/2 rexec program. All required command parameters must be
explicitly provided to the 4690 rexec program. Enter REXEC from the 4690 command line to
display a usage message. See the TCP / IP for 4690 Application Interface Guide for the command
line interface to Rexec.
PCNFSD authentication server

The PCNFSD Authentication Server is required for many PC-based NFS clients. The NFS client
must first be authenticated at the server before remote drives/directories can be mounted.
The 4690 PCNFSD Authentication Server can be invoked either from a 4690 command line or as
a 4690 background application. It takes no parameters. The ADX_SDT1:PCNFSD.DAT file
contains a list of user IDs and passwords that must match those defined on the NFS client in
order for authentication to be successful. In 4690 OS Version 2 Release 4 or higher, there are no
default passwords and the comment character is a ; (semicolon), which must be in the first

position or column one. A sample file is copied to the store controller during installation and can
be modified with a text editor.
4690 TCP/IP programming libraries

See the TCP / IP for 4690 Application Interface Guide at www.toshibacommerce.com/support for
documentation on the following items. (Select Publications under the Support link).
Note: Access to Toshiba online publications requires an Enterprise ID. For more information,
contact your Toshiba representative, or [email protected].
• Writing 4690 TCP/IP applications
• Compiler, Linker
• Sockets
• FTP API
• SNMP DPI
• SUN RPC
The file names of the 4690 TCP/IP API runtime libraries are listed in Table 1. These files can be
found on the 4690 Optionals. They are not copied onto the store controller during the Apply
Software Maintenance operation. Also, C language header files for developing 4690 TCP/IP
applications can be downloaded in a .ZIP format from the supported Web site.
Note: This information describes the 16-bit libraries.
The operating system provides only the socket and RPC library portions of the TCP/IP interfaces
for use with the VisualAge compiler. 32-bit versions of the FTP or DPI libraries are not provided.
The link library name for the socket interfaces is TCPIP.LIB and the library name for the RPC
interfaces is RPC.LIB. The header files used for TCP/IP programming are located in the
INCLUDE\TCPIP subdirectory tree of the development environment .ZIP file.
Although tcperrno is used to retrieve the error values from failed socket calls, it shares its value
with the C runtime errno value. Therefore, any calls that affect one will affect the other. You must
include NERRNO.H to use tcperrno.
Many function prototypes were missing from the header files shipped with the 16-bit version of
TCP/IP. This has been corrected to ensure that all functions can be called properly.
In 16-bit mode, most buffer addresses are checked and an error is returned if a buffer is not
addressable by the application. In the 32-bit version of the library, some addresses are checked
(at the driver layer) but most are not. Therefore, if an invalid buffer or parameter address is
passed in the application will trap (or dump if the dump flag is on).
16-bit to 32-bit conversion

In previous versions of the operating system, the TCP/IP documentation and header files
assumed that C integers (type int) were 16 bits long. However, with the VisualAge compiler,
integers are 32 bits long.
Most of the existing APIs are unchanged (taking and returning integers as arguments). Even
though these values are now 32-bits wide, the sockets API is not able to use values larger than
the range of a short integer. If lengths larger than the limit of a short integer (32767 or 65535
depending on the function) are passed as arguments to a function an error is returned and
tcperrno is set to EINVAL. The only exception to this rule is the RECV function; the amount of
data that can be received is limited to 32767.
Most data structures used with the sockets API have been modified to contain fields of type short
instead of fields of type int. This ensures that the size and layout of these structures are
consistent between 16-bit and 32-bit versions. In particular, the linger structure used with the
getsockopt() function is now defined as containing two shorts instead of two ints.

Retrieving the local host name
The C language gethostname() function retrieves the TCP/IP host name of the local host. The
syntax of the call is as follows:
int gethostname (Name, NameLength)
char *Name;
int NameLength;
where:
Name
Specifies the address of an array of bytes where the host name is to be stored
NameLength
Specifies the length of the Name array
Upon successful completion, a value of 0 (zero) is returned, and the Name array contains the
TCP/IP host name of the local host. If the gethostname() function is unsuccessful, a value of -1
is returned.
In order to retrieve the local host name, you must define the user-defined logical name
HOSTNAME. This logical name contains the fully-qualified TCP/IP host name of the local host.
Upon successful completion, the Name array will contain the value of the HOSTNAME logical
name. If HOSTNAME is not defined, gethostname() will complete successfully and the Name
array will contain “localhost” for the TCP/IP host name. For more information on user-defined
logical names, see the TCx Sky User's Guide.
TCP/IP in the terminal

The 4690 TCP/IP driver has been enabled for the terminal. When properly configured, a terminal
will load the TCP/IP driver and have the capability of communicating via TCP/IP on your
network. This enables you to run TCP/IP applications on your terminal. Restrictions such as disk
dependencies and memory usage apply to these applications as with other terminal applications.
4690 TCP/IP applications shipped for the controller have not been enabled to run on the
terminal.
For more information regarding terminal TCP/IP configuration, see the TCx Sky Planning,
Installation and Configuration Guide.
Note:
IP addresses can be specified as decimal, hexadecimal, or octal. A leading 0x indicates hex. A
leading 0 (zero) indicates octal. Anything else indicates decimal. For example, the following
three IP addresses are identical.
• 9.67.39.83
• 0x9.0x43.0x27.0x53
• 011.0103.047.0123
In TCP/IP files that contain IP addresses, any leading zeros in the addresses are interpreted as
octal, not decimal. However, in terminal configuration, IP addresses are read as decimal.

Chapter 3. Using IP Filters
Using IP Filters
This chapter describes using IP Filters in your 4690 operating system. IP Filter support is only
available on 4690 controllers and only provides filtering for the native 4690OS TCP/IP stack.
Refer to the TCx Sky Planning, Installation and Configuration Guide for information about enabling
IP Filters during system configuration.
Note:
1. The options included in this product can help your company address the PCI DSS
requirements.
2. The customer is responsible for evaluation, selection and implementation of security
features, administrative procedures and appropriate controls.
3. PCI DSS is Payment Card Industry Data Security Standards.
IP Filters Overview
Filtering is a function in which incoming and outgoing packets can be accepted or denied based
on a variety of characteristics called rules. This function allows you to configure the store
controller to control the traffic between this controller and other hosts. Filtering is done on a
variety of packet properties, such as source and destination addresses, subnet masks, protocol,
port, fragmentation, interface, and tunnel definition. This filtering is done at the IP layer, so no
changes are required to the applications.
Filter rules
Filter rules provide basic firewall functionality to those who want to restrict traffic to or from
their machine in an intranet or in a network that does not have the protection of a true firewall.
In this scenario, filter rules provide a second barrier of protection around a group of machines.
After the filter rules are generated, they are stored in a table and loaded into the driver. When
packets are ready to be sent or received from the network, the filter rules are checked in the list
from top to bottom to determine whether the packet should be permitted, denied, or sent
through a tunnel. The criteria of the rule are compared to the packet characteristics until a match
is found or the default rule is reached.
Configuring filters
Filtering can be simple, using mostly auto-generated filter rules, or can be customized by
defining very specific filter functions based on the properties of the IP packets. Each line in a
filter table is known as a rule. A collection of rules determine what IP packets are accepted in and
out of the machine and how they are directed. Filter rules can control many aspects of
communications, including source and destination addresses and masks, protocol, port number,
direction, fragment control, tunnel, and interface type. The types of filter rules are as follows:
• User-defined filter rules
• Predefined filter rules
User-defined filter rules

User-defined filter rules are used in the general filtering of traffic or for associating traffic with
IPsec tunnels. They can be added, deleted, modified, and moved. An optional description text
field can be added to identify a specific rule.
User-defined filter rules are generated and managed using the following commands:
• genfilt – create filter
• actfilt – activate filter

• chfilt – change filter
• mvfilt – move filter
• rmfilt – remove filter
• lsfilt – list filter
Refer to “IP Filter commands ” on page 57 for details about the these commands.
Predefined filter rules

Predefined filter rules are generic filter rules that pertain to all traffic, such as the all traffic or
default rule. The default rule cannot be modified, moved, or deleted.
When filters are initialized, a predefined rule (called the default rule) is inserted into the filter
table and then activated. By default, this predefined rule is set to permit all packets, but it is
user-configurable and can be set to deny all packets. This will keep traffic from passing unless
that traffic is specifically defined by additional filter rules.
Direction
The direction flag (-w) of the genfilt command specifies whether the rule should be used
during input packet processing or output packet processing or both. When filtering is turned on,
at least one rule determines the fate of any incoming or outgoing network packet. For example,
when a packet is sent out from host A to host B, the outgoing IP packet has the source address of
A and the destination address of B. On host A this packet is processed by the filter driver during
the outbound processing and on host B during the inbound processing.
Note: The direction both implies that the associated rule is used for both incoming and outgoing
packets. However, it does not mean that the rule is applied when the source and destination
addresses are reversed. For instance, if server A has a rule with A as source address and B as
destination address and the direction is set to both, then the rule does not apply on server A to
an incoming packet with B as the source address and A as the destination address. Typically the
both option is used in gateways that forward the packets.
Subnet masks
Associated with filter rules are Subnet masks.Subnet masks are used to group a set of IP addresses
that are associated with a filter rule. The mask value is logically ANDed with the IP address in
the filter rule (using binary format) and compared to the IP address specified in the packet. For
example, a filter rule with a source IP address of 10.10.10.4 and a subnet mask of
255.255.255.255 (binary 11111111.11111111.11111111.11111111) specifies that an exact match
must occur of the IP address.
A 10.10.10.x subnet is specified using a subnet mask of 255.255.255.0. An incoming address
would have the subnet mask applied to it, then the combination would be compared to the IP
address/subnet mask combination in the filter rule. For example, an address of 10.10.10.100
becomes 10.10.10.0 after the subnet mask is applied, which matches the filter rule. A subnet mask
of 255.255.255.240 allows any value for the last four bits in the address.
Examples of filter rules

Following is a list of example filters along with descriptions. For readability, the filter list is
displayed in a condensed format with space-separated fields. The first list shown provides the
name of each field in the filter rule followed by example values from rule 1 in parentheses. The
list of example filter rules follows the first list.
• Rule (1)
• Rule Action (permit)
• Source Address (0.0.0.0)

• Source Mask (0.0.0.0)
• Destination Address (0.0.0.0)
• Destination Mask (0.0.0.0)
• Protocol (ah)
• Source Port (source port operator and source port value) (any 0)
• Destination Port (destination port operator and destination port value (any 0)
• Direction (both)
• Fragment Control (all packets)
• Tunnel ID number (0)
• Interface (all)
The following is a list of example filter rules:
1 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 ah any 0 any 0 both all packets 0 all
0 none none
2 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 esp any 0 any 0 both all packets 0 all
0 none none
3 permit 10.10.1.2 255.255.255.255 10.10.1.3 255.255.255.255 all any 0 any 0

outbound all packets 1 all 0 none none
4 permit 10.10.1.3 255.255.255.255 10.10.1.2 255.255.255.255 all any 0 any 0

inbound all packets 1 all 0 none none
5 permit 10.10.1.2 255.255.255.255 10.10.1.3 255.255.255.255 icmp any 0 any 0

6 permit 10.10.1.3 255.255.255.255 10.10.1.2 255.255.255.255 icmp any 0 any 0

7 permit 10.10.1.2 255.255.255.255 10.10.1.5 255.255.255.255 tcp gt 1023 eq 21

8 permit 10.10.1.5 255.255.255.255 10.10.1.2 255.255.255.255 tcp/ack eq 21 gt

1023 inbound all packets 3 all 0 none none
9 permit 10.10.1.5 255.255.255.255 10.10.1.2 255.255.255.255 tcp eq 20 gt 1023

10 permit 10.10.1.2 255.255.255.255 10.10.1.5 255.255.255.255 tcp/ack gt 1023

eq 20 outbound all packets 3 all 0 none none
11 permit 10.10.1.2 255.255.255.255 10.10.1.5 255.255.255.255 tcp gt 1023 gt

1023 outbound all packets 3 all 0 none none
12 permit 10.10.1.5 255.255.255.255 10.10.1.2 255.255.255.255 tcp/ack eq 1023

gt 1023 inbound all packets 3 all 0 none none
0 permit 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 all any 0 any 0 both all packets 0 all
0 none none Default Rule
Each rule in the previous example is described in Table 3.
Table 3. Explanation of filter rules example

Rule Explanation
Rules 1 and 2 Auto-generated rules that allow processing of authentication headers (AH)
and encapsulating security payload (ESP) headers for IPsec tunnels.
Note: Do not modify Rules 1 and 2.
Rules 3 and 4 Set of auto-generated rules that filter traffic between addresses 10.10.1.2 and
10.10.1.3 through tunnel 1. Rule 3 is for outbound traffic and rule 4 is for
inbound traffic.
Chapter 3. Using IP Filters 53

Rule Explanation
Rules 5 and 6 Set of user-defined rules that filter both inbound and outbound services of any
type between addresses 10.10.1.2 and 10.10.1.3 through tunnel 2.
Commands to generate:
genfilt -s 10.10.1.2 -d 10.10.1.3 -a P -c icmp -t 2 -w O
genfilt -s 10.10.1.3 -d 10.10.1.2 -a P -c icmp -t 2 -w I
Rules 7 User-defined filter rules that filter outbound file transfer protocol (FTP) service
through 12 from 10.10.1.2 and 10.10.1.5 through tunnel 3.
Commands to generate:
genfilt -s 10.10.1.2 -d 10.10.1.5 -a P -c tcp -o gt -p 1023 -O
eq -P 21 -t 3 -w O
genfilt -s 10.10.1.5 -d 10.10.1.2 -a P -c tcp/ack -o eq -p 21 -O
gt -P 1023 -t 3 -w I
genfilt -s 10.10.1.5 -d 10.10.1.2 -a P -c tcp -o eq -p 20 -O gt
-P 1023 -t 3 -w I
genfilt -s 10.10.1.2 -d 10.10.1.5 -a P -c tcp/ack -o gt -p 1023
-O eq -P 20 -t 3 -w O
genfilt -s 10.10.1.2 -d 10.10.1.5 -a P -c tcp -o gt -p 1023 -O
gt -P 1023 -t 3 -w O
Rule 0 Predefined rule, known as the default rule, which is always placed at the end
of the table. In this example, it permits all packets that do not match the other
filter rules. It can be set to deny all traffic not matching the other filter rules.
Each rule can be viewed separately (using the lsfilt command) to list each field with its value.
For example, entering lsfilt –n 7 shows the following (lsfilt with no parameters would list all the
rules in this format):
Rule 7:
Rule action : permit
Source Address : 10.10.1.2
Source Mask : 255.255.255.255
Destination Address : 10.10.1.5
Destination Mask : 255.255.255.255
Protocol : tcp
Source Port : gt 1023
Destination Port : eq 21
Direction : outbound
Fragment control : all packets
Tunnel ID number : 3
Interface : all
Auto-Generated : no
Expiration Time : 0
Description :
Filters and intrusion detection and prevention

Intrusion detection and prevention is the action of monitoring and analyzing system events in
order to intercept and reject any attempt of unauthorized system access. In 4690, this detection
and prevention of unauthorized access or attempted unauthorized access is done by observing
certain actions, and then applying filter rules to these actions.
Pattern matching filter rules

Pattern matching is the use of a filter rule for filtering networking packets. A filter pattern can be
a text string, a hexadecimal string, or a file containing more than one pattern. After a pattern
filter rule is established and that pattern is detected in the body of any network packet, then the
predefined action of the filter rule will result.

Pattern matching only applies to inbound network packets. Use the genfilt command to add a
pattern matching filter rule to the filter rule table. Use the actfilt command to activate or
deactivate the filter rules. A pattern file can contain a list, one per line, of text patterns or
hexadecimal patterns. Pattern matching filter rules can be used to guard against viruses, buffer
overflows, and other network security attacks.
Pattern matching filter rules can have a negative impact on system performance if they are used
too broadly and with a high number of patterns. It is best to keep the scope of their application
as narrow as possible. For example, if a known virus pattern applies to a specific application,
then specify the destination port of the application in the filter rule. This allows all other traffic to
pass without incurring a performance impact from pattern matching.
Note: Pattern matching is performed on incoming packets only.
There are three basic types of patterns: text, hexadecimal, and file.
• Text pattern — A text filter pattern is an ASCII string that looks similar to the following:
GET /../../../../../../../../
• Hexadecimal pattern — A hexadecimal pattern looks similar to the following:
0x33c0b805e0cd16b807e0cd1650558becc7460200f05d0733ffb8c800b9fffff3abb
00150e670e47132c0e67158fec03c80
Note: A hexadecimal pattern is differentiated from a text pattern by the leading 0x.
• Files that contain patterns — A file can contain a list, one per line, of text patterns or
hexadecimal patterns.
Shun port and shun host filter rules

By setting a shun filter rule, you can prevent a remote host or the remote host and port pair from
accessing the local machine. A shun filter rule dynamically creates an effect rule that denies the
remote host or the remote host and port pair from accessing the local machine when the
specified criteria of the rule are met. Because it is common for an attack to be preceded by a port
scan, shun filter rules are especially useful in preventing an intrusion by detecting this attack
behavior.
For example, if the local host does not use the server port 37, which is the time server, then the
remote host should not be accessing port 37, unless it is running a port scan. Place a shun filter
rule on port 37 so that if the remote host attempts to access that port, the shun filter rule creates
an effective rule that blocks that host from further access for the amount of time specified in the
shun rule expiration time field. If the expiration time field of a shun rule is set to 0, then the
dynamically created effective shun rule does not expire.
Note:
1. An expiration time specified by the shun port or shun host filter rule applies only to the
dynamically created effect rule.
2. Dynamically created effect rules can only be viewed with the lsfilt -a command.
3. When the criteria of a shun host filter rule is met, then the dynamically created effective rule
will block or shun all network traffic from the remote host for the specified expiration time.
4. When the criteria of a shun port filter rule is met, then the dynamically created effective rule
will only block or shun network traffic from this remote host’s particular port, until the
expiration time is exceeded.
Shun host example

The following example shows a shun host rule to shun any host for 2 minutes on the 10.10.1.0
network that attempts an FTP request. The command to generate the rule is as follows:
genfilt -a H -s 10.10.1.0 -m 255.255.255.0 -d 10.10.1.2 -c tcp -O eq -P 21 -e 120 -D
"shun host on FTP attempt for 2 min"

The lsift command would show the following:
Beginning of filter rules.

Rule 1:
Rule action : shunHost
Source Mask : 255.255.255.0
Protocol : tcp
Source Port : any 0
Direction : both
Interface : all
Auto-Generated : no
Expiration Time : 120
Description : shun host on FTP attempt for 2 min
Rule 0:
Source Mask : 0.0.0.0
Protocol : all
Source Port : any 0
Destination Port : any 0
Direction : both
Interface : all
Auto-Generated : no
Expiration Time : 0
Description : Default Rule
End of filter rules
When host 10.10.1.3 attempts an FTP to host 10.10.1.2, a dynamically created effective rule
appears in the active filter list (lsfilt -a) to deny all traffic from host 10.10.1.3 for 2 minutes. The
expiration time shown in the filter rule is approximate as indicated by the tilde (&tilde;). When
the expiration time is reached, the rule is automatically deleted from the active list as shown in
the following example.
Beginning of filter rules.
Rule 1:
Rule action : deny
Source Mask : 255.255.255.255
Protocol : all
Source Port : any 0
Direction : both
Interface : all
&tilde;Expiration Time : 92
Rule 2:
Rule action : shunHost
Source Mask : 255.255.255.0
Protocol : tcp
Source Port : any 0
Direction : both

Interface : all
Expiration Time : 120
Rule 3:
Source Mask : 0.0.0.0
Protocol : all
Source Port : any 0
Direction : both
Interface : all
Expiration Time : 0
End of filter rules.
Stateful filter rules

Stateful filters examine information such as source and destination addresses, port numbers, and
status. Then, by applying IF, ELSE or ENDIF filter rules to these header flags, stateful systems
can make filtering decisions in the context of an entire session rather than that of an individual
packet and its header information.
Stateful inspection examines incoming and outgoing communication packets. When stateful
filter rules are activated with the actfilt -u command, the rules in the ELSE block are always
examined until the IF rule is satisfied. After the IF rule or condition is satisfied, the rules in the IF
block are used until the filter rules are reactivated with the actfilt -u command.
Timed rules
Timed rules specify the amount of time, in seconds, that the filter rule is applied after it is made
effective with the actfilt -u command. The expiration time is specified with the -e option of the
genfilt command. For more information, see “actfilt command (adxipsaf.386)” on page 60 and
“genfilt command (adxipsgf.386)” on page 57.
Note: Timers have no effect on IF, ELSE or ENDIF rules. If an expiration time is specified in a
shun host or shun port rule, the time applies only to the effect rule that is initiated by the shun
rule. Shun rules have no expiration time.
IP Filter commands
Filters are configured, activated, managed, and displayed using command line functions. These
command line functions save the filter records in configuration files and pass the configuration
to the appropriate drivers by means of special calls. The following sections describe the
commands.
genfilt command (adxipsgf.386)

This section describes the genfilt command.
Purpose
Adds a filter rule to the filter configuration database.
Syntax
genfilt [ -n fid] [ -a D|P|I|L|E|H|S ] -s s_addr -m s_mask [-d d_addr] [ -M d_mask] [ -c protocol] [ -
o s_opr] [ -p s_port] [ -O d_opr] [ -P d_port] [ -w I|O|B ] [ -f Y|N|O|H ] [ -t tid] [ -i interface] [-D
description] [-e expiration_time] [-x quoted_pattern] [-X pattern_filename ]

Description
Use the command genfilt to add a filter rule to the filter configuration database. The filter rules
generated by this command are called user-defined filter rules.
Flags
-a action
The following action values are allowed:
• D (deny) blocks traffic.
• P (permit) allows traffic.
• I (if) makes this an IF filter rule.
• L (else) makes this an ELSE filter rule.
• E (endif) makes this an ENDIF filter rule.
• H (shunHost) makes this a SHUN HOST filter rule.
• S (shunPort) makes this a SHUN PORT filter rule.
Permit is the default action, if no other action is specified.
All IF rules must be closed with an associated ENDIF rule. These conditional rules can be
nested, but correct nesting and scope must be adhered to or the rules will not load
correctly with the actfilt command.
-c protocol
Specifies the protocol. The valid values are: udp, icmp, tcp, tcp/ack, esp, ah, and all. The
value all indicates that the filter rule will apply to all the protocols. The protocol can also
be specified numerically (between 1 and 252). The default value is all.
-D description
A short text description for the filter rule, specified as a quoted character string. This is an
optional flag for user-defined filter rules. Descriptions are truncated at 80 characters.
-d a_addr
Specifies the destination address. It can be an IP address or a host name. If a host name is
specified, the first IP address returned by the name server for that host will be used. This
value, along with the destination subnet mask, will be compared against the destination
address of the IP packets. If unspecified, the destination address defaults to 0.0.0.0
(indicating “any” address).
-e expiration_time
Specifies the expiration time. The expiration time is the amount of time the rule should
remain active in seconds. The expiration_time does not remove the filter rule from the
database. The expiration_time relates to the amount of time the filter rule is active while
processing network traffic. If no expiration_time is specified, then the life time of the filter
rule is infinite. If expiration_time is specified in conjunction with a SHUN PORT (-a S) or
SHUN HOST (-a H) filter rule, then this is the amount of time the remote port or remote
host is denied or shunned when the filter rule parameters are met. If expiration_time is
specified independent of a shun rule, then this value is the amount of time the filter rule
will remain active after the filter rules are loaded into the driver and start processing
network traffic. The valid values for expiration_time are 0 – 2592000 seconds, where 0
represents no expiration.
-f Y|N|O|H
Specifies the fragmentation control. This flag specifies that this rule will apply to either all
packets (Y), fragment headers and unfragmented packets only (H), fragments and
fragment headers only (O), or unfragmented packets only (N). The default value is Y.

-i interface
Specifies the name of IP interface(s) to which the filter rule applies. The examples of the
interface name are: all, tr0, and en0. The default value is all.
-m s_mask
Specifies the source subnet mask. This is used in the comparison of the source address of
the IP packet with the source address of the filter rule. This parameter is required if –d is
not specified. If unspecified, the subnet mask defaults to 255.255.255.255, indicating an
exact match with the specified source address, unless the source address is 0.0.0.0. An IP
address of 0.0.0.0 defaults to a mask of 0.0.0.0 for correct operation of the filter.
-M d_mask
Specifies the destination subnet mask. This is used in the comparison of the destination
address of the IP packet with the destination address of the filter rule. If unspecified, the
subnet mask defaults to 255.255.255.255, indicating an exact match with the specified
destination address, unless the destination address is 0.0.0.0. An IP address of 0.0.0.0
defaults to a mask of 0.0.0.0 for correct operation of the filter.
-n fid
Specifies the filter rule ID for filter rule placement. The new rule will be added BEFORE
the specified filter rule. The ID must be greater than 0 and less than the last filter ID +1, as
shown by the lsfilt command. If this flag is not used, the new rule will be added to the
end of the filter rule table.
-o s_opr
Specifies the source port or ICMP type operation. This is the operation that will be used
in the comparison between the source port or ICMP type of the packet and the source
port or ICMP type (-p flag) specified in this filter rule. The valid values are: lt (less than),
le (less than or equal), gt (greater than), ge (greater than or equal), eq (equal), neq (not
equal), and any. The default value is any.
-O d_opr
Specifies the destination port or ICMP code operation. This is the operation that will be
used in the comparison between the destination port or ICMP code of the packet and the
destination port or ICMP code (-P flag) specified in this filter rule. The valid values are: lt
(less than), le (less than or equal), gt (greater than), ge (greater than or equal), eq (equal),
neq (not equal), and any. The default value is any.
-p s_port
Specifies the source port or ICMP type. This is the value or ICMP type that will be
compared to the source port or ICMP type of the IP packet. The -o option must be
specified when the -p option is used.
-P d_port
Specifies the destination port or ICMP code. This is the value or ICMP code that will be
compared to the destination port or ICMP code of the IP packet. The -O option must be
specified when the -P option is used.
-s s_addr
Specifies the source address. It can be an IP address or a host name. If a host name is
value, along with the source subnet mask, will be compared against the source address of
the IP packets.

-t tid
Specifies the ID of the tunnel related to this filter rule. All the packets that match this filter
rule must go through the specified tunnel. If this flag is not specified, the value is 0 which
indicates that this rule only applies to non-tunnel traffic.
-w direction
Specifies whether the rule applies to incoming packets (I), outgoing packets (O), or both
(B). The default value is B. It is not valid to use O (outgoing packets) with the -x or -X
pattern options. It is valid to specify the (B) both directions with the pattern options, but
only the incoming packets are checked against the patterns.
-x quoted_pattern
Specifies a pattern to compare against network traffic. The pattern can be specified as a
quoted ASCII character string or a hexadecimal pattern preceded by 0x. The pattern is a
minimum of 4 and a maximum of 2048 ASCII characters or hexadecimal bytes.
Hexadecimal patterns must be specified as full bytes (2 hexadecimal characters per byte).
For long patterns, use the -X option with a pattern file because of the command line size
limitation.
-X pattern_filename
Specifies the pattern file name. If more than one pattern is associated with this filter rule,
then a pattern file name must be used. The pattern file must be in the format of one
pattern per line. A pattern is an unquoted character string, interpreted as an ASCII string
unless preceded by 0x, in which case it is interpreted as a hexadecimal pattern. Each
pattern is a minimum of 4 and a maximum of 2048 ASCII characters or hexadecimal
bytes. Each pattern in the file will be truncated at 2048 ASCII characters or hexadecimal
bytes. Hexadecimal patterns must be specified as full bytes (2 hexadecimal characters per
byte). This file is read when the filter rules are activated.
Note: The 4690 XE editor has a limit of approximately 1024 characters per line; therefore,
pattern files with longer patterns should be created on a different system and transferred
to the controller.
actfilt command (adxipsaf.386)

This section describes the actfilt command.
Purpose
Activates or deactivates the filter rules.
Syntax
actfilt -d|u [ -z P|D ] [ -i]
Description
Use the actfilt command to activate or deactivate the filter rules. This command activates or
deactivates the filter rules in the active driver filter table. After being activated, filters will be
matched with incoming and outgoing packets. IPsec filter rules for this command are configured
using the genfilt command.
Flags
-d
Deactivates the active filter rules. This flag cannot be used with the -u flag.

-u
Activates the filter rules in the filter rule table. This flag cannot be used with the -d flag.
-z P|D
Sets the action of the default filter rule to “permit” (P) or “deny” (D). The default filter
rule is the last rule in the filter rule table that will apply to traffic that does not apply to
any other filter rules in the table. Setting the action of this rule to “permit” will allow all
traffic that does not apply to any other filter rules. Setting this action to “deny” will not
allow traffic that does not apply to any other filter rules.
-i
Initialization flag. This flag only applies when the -u flag is also used. If the -i flag is used,
all the filter rules with an “active” status will be activated. If not used, all the filter rules
in the filter rule table will be activated. The actfilt -u -i command is issued during IPL to
activate the filter rules that were active just before the IPL.
chfilt command (adxipscf.386)

This section describes the chfilt command.
Purpose
Changes a filter rule.
Syntax
chfilt -n fid [ -a D|P|I|L|E|H|S ] [-s s_addr] [-m s_mask] [ -d d_addr] [ -M d_mask] [ -c protocol] [ -
o s_opr] [ -p s_port] [ -O d_opr] [ -P d_port] [ -w I|O|B ] [ -f Y|N|O|H ] [ -t tid] [ -i interface] [-D
description] [-e expiration_time] [-x quoted_pattern] [-X pattern_filename ]
Description
Use the chfilt command to change the definition of a filter rule in the filter rule table. Specify one
or more parameters to change in the filter specified by the -n parameter. All other filter
parameters remain as previously configured by the genfilt command. Auto-generated filter
rules and manual filter rules can be changed by this command. If an auto-generated filter rule is
modified by the chfilt command, it becomes a manual filter rule. IPsec filter rules for this
command are configured using the genfilt command.
Flags
-a action
The following action values are allowed:
• D (deny) blocks traffic.
• P (permit) allows traffic.
• I (if) makes this an IF filter rule.
• L (else) makes this an ELSE filter rule.
• E (endif) makes this an ENDIF filter rule.
• H (shunHost) makes this a SHUN HOST filter rule.
• S (shunPort) makes this a SHUN PORT filter rule.
All IF rules must be closed with an associated ENDIF rule. These conditional rules can be
nested, but correct nesting and scope must be adhered to or the rules will not load
correctly with the actfilt command.

-c protocol
Specifies the protocol. The valid values are: udp, icmp, tcp, tcp/ack, esp, ah, and all. The
value all indicates that the filter rule will apply to all the protocols. The protocol can also
be specified numerically (between 1 and 252).
-D description
A short text description for the filter rule, specified as a quoted character string. This is an
optional flag for user-defined filter rules. Descriptions are truncated at 80 characters.
-d a_addr
Specifies the destination address. It can be an IP address or a host name. If a host name is
value, along with the destination subnet mask, will be compared against the destination
address of the IP packets.
-e expiration_time
Specifies the expiration time. The expiration time is the amount of time the rule should
remain active in seconds. The expiration_time does not remove the filter rule from the
database. The expiration_time relates to the amount of time the filter rule is active while
processing network traffic. If no expiration_time is specified, then the life time of the filter
rule is infinite. If the expiration_time is specified in conjunction with a SHUN PORT (-a S)
or SHUN HOST (-a H) filter rule, then this is the amount of time the remote port or
remote host is denied or shunned when the filter rule parameters are met. If the
expiration_time is specified independent of a shun rule, then this value is the amount of
time the filter rule will remain active after the filter rules are loaded into the kernel and
start processing network traffic. The valid values for expiration_time are 0 – 2592000
seconds, where 0 represents no expiration.
-f Y|N|O|H
Specifies the fragmentation control. This flag specifies that this rule will apply to either all
packets (Y), fragment headers and unfragmented packets only (H), fragments and
fragment headers only (O), or unfragmented packets only (N).
-i interface
Specifies the name of IP interfaces to which the filter rule applies. The examples of the
interface name are: all, tr0, and en0.
-m s_mask
Specifies the source subnet mask. This mask will be applied to the source address (-s flag)
when compared with the source address of the IP packet.
-M d_mask
Specifies the destination subnet mask. This mask will be applied to the destination
address (-d flag) when compared with the destination address of the IP packet.
-n fid
Specifies the ID of the filter rule to change. It must exist in the filter rule table and it
cannot be 0. (Rule 0 is the default filter rule and cannot be changed with chfilt command).
-o s_opr
Specifies the source port or ICMP type operation. This is the operation that will be used
in the comparison between the source port or ICMP type of the packet and the source
port or ICMP type (-p flag) specified in this filter rule. The valid values are: lt (less than),
le (less than or equal), gt (greater than), ge (greater than or equal), eq (equal), neq (not
equal), and any. The -o option must be specified when the -p option is used.

-O d_opr
Specifies the destination port or ICMP code operation. This is the operation that will be
used in the comparison between the destination port or ICMP code of the packet and the
destination port or ICMP code (-P flag) specified in this filter rule. The valid values are: lt
(less than), le (less than or equal), gt (greater than), ge (greater than or equal), eq (equal),
neq (not equal), and any. The -O option must be specified when the -P option is used.
-p s_port
Specifies the source port or ICMP type. This is the value or ICMP type that will be
compared to the source port or ICMP type of the IP packet.
-P d_port
Specifies the destination port or ICMP code. This is the value or ICMP code that will be
compared to the destination port or ICMP code of the IP packet.
-s s_addr
Specifies the source address. It can be an IP address or a host name. If a host name is
value, along with the source subnet mask, will be compared against the source address of
the IP packets.
-t tid
Specifies the ID of the tunnel related to this filter rule. All the packets that match this filter
rule must go through the specified tunnel. A value of 0 indicates that no tunnels are
associated with this filter.
-w direction
Specifies whether the rule applies to incoming packets (I), outgoing packets (O), or both
(B). It is not valid to use O (outgoing packets) with the -x or -X pattern options. It is valid
to specify the (B) both directions with the pattern options, but only the incoming packets
are checked against the patterns.
-x quoted_pattern
Specifies a pattern to compare against network traffic. The pattern can be specified as a
quoted ASCII character string or a hexadecimal pattern preceded by 0x. The pattern is a
minimum of 4 and a maximum of 2048 ASCII characters or hexadecimal bytes.
Hexadecimal patterns must be specified as full bytes (2 hexadecimal characters per byte).
For long patterns, use the -X option with a pattern file because of command line size
limitations.
-X pattern_filename
Specifies the pattern file name. If more than one pattern is associated with this filter rule,
then a pattern file name must be used. The pattern file must be in the format of one
pattern per line. A pattern is an unquoted character string, interpreted as an ASCII string
unless preceded by 0x, in which case it is interpreted as a hexadecimal pattern. The
pattern is a minimum of 4 and a maximum of 2048 ASCII characters or hexadecimal
bytes. Hexadecimal patterns must be specified as full bytes (2 hexadecimal characters per
byte). This file is read when the filter rules are activated.
mvfilt command (adxipsmf.386)

This section describes the mvtfilt command.
Purpose
Moves a filter rule.

Syntax
mvfilt -p p_fid -n n_fid
Description
Use the mvfilt command to change the position of a filter rule in the filter rule table. IPsec filter
rules for this command are configured using the genfilt command.
Flags
-p p_fid
Filter rule ID. It specifies the previous position of the rule in the filter rule table. The
values of 0 and the last filter position in the filter table are not valid since the default filter
rule is unmovable and becomes the last filter rule when activated.
-n n_fid
Filter rule ID. It specifies the new position of the rule in the filter rule table after the move.
The values of 0 and the last filter position in the filter table are not valid since the default
filter rule is unmovable and becomes the last filter rule when activated.
rmfilt command (adxipsrf.386)

This section describes the rmtfilt command.
Purpose
Removes a filter rule from the filter rule table.
Syntax
rmfilt -n fid | all [-f] [-q]
Description
Use the rmfilt command to remove filter rules from the filter rule table. Actions by this
command will not affect the active driver filter list until the actfilt command is executed. IPsec
filter rules for this command are configured using the genfilt command. Only manual filter rules
can be removed.
Flags
-n fid | all
The ID of the filter rule to remove from the filter rule table. The value of 0 is not valid for
this flag since it is the default filter rule. If all is specified, all the user-defined filter rules
will be removed.
-f
Force to remove auto-generated filter rules. The -f flag works with -n all to remove all the
filter rules (user-defined and auto-generated filter rules) except rule number 0.
-q
The -q flag indicates “quiet mode” and suppresses the per-filter informational messages.
lsfilt command (adxipslf.386)

This section describes the lstfilt command.

Purpose
Lists filter rules from either the filter table in the filter configuration database or the active driver
filter list.
Syntax
lsfilt [-n fid_list] [-a]
Description
Use the lsfilt command to list filter rules and their status. lsfilt displays filters from the filter
configuration database (without -a) or from the active driver filter list (with -a). The default filter
rule is always displayed last when listing filter rules since it is always the last rule applied to
filter network traffic. The default filter rule ID is 0 in the filter configuration database and, when
activated, it becomes the last or highest filter ID in the filter table.
Note: Filter description fields are not listed in the active driver filter list. No filter description
text will be displayed when active rules are listed.
Flags
-a
List only the active filter rules. The active filter rules are rules that are currently in use by
the filter driver. If -a is omitted, all the filter rules in the filter rule table will be listed.
-n fid_list
Specifies the IDs of filter rules to be displayed. The fid_list is a single filter ID or a list of
filter IDs separated by a space, a comma (,) or a dash (-), where “-” represents a range.
Filter ID 0 (the default rule) cannot be specified in a range, but can be listed separately.
For example, lsfilt -n 1-3,0 will list filter rules 1,2,3, and 0. The -n option is not valid for
active filter rules. This flag cannot be used with the -a flag.
gentun command (adxipsgt.386)

This section describes the gentun command.
Purpose
Creates a tunnel definition in the tunnel database.
Syntax
gentun -s src_host_IP_address -d dst_host_IP_address [-m tunnel |transport] [-e [src_esp_algo]] [-a
[src_ah_algo]] [-b src_esp_auth_algo] [-p src_policy] [-E dst_esp_algo] [-A [dst_ah_algo]] [-B
dst_esp_auth_algo] [-P dst_policy] [-k src_esp_key] [-h src_ah_key] [-c src_esp_auth_key] [-K
dst_esp_key] [-H dst_ah_key] [-C dst_esp_auth_key] [-n src_esp_spi] [-u src_ah_spi] [-N dst_esp_spi] [-
U dst_ah_spi] [ -l lifetime] [-y Y|N] [-f fw_address [-x dst_mask]] [-g]
Description
The gentun command creates a definition of a tunnel between a local host and a tunnel partner
host. The associated auto-generated filter rules for the tunnel can be optionally generated by this
command.

Flags
-a src_ah_algo
Source AH authentication algorithm, used by source for IP packet authentication. The
default value is HMAC_MD5.
-A dst_ah_algo
Destination AH Authentication Algorithm, used by destination for IP packet
authentication. If this flag is not used, the value used by the -a flag is used.
-b src_esp_auth_algo
Source ESP Authentication Algorithm.
-B dst_esp_auth_algo
Destination ESP Authentication Algorithm. If this flag is not used, it is set to the same
value as the -b flag.
-c src_esp_auth_key
Source ESP Authentication Key. It must be a hexadecimal string started with 0x. If this
flag is not used, the system will generate one for you.
-C dst_esp_auth_key
Destination ESP Authentication Key. It must be a hexadecimal string started with 0x. If
this flag is not used, it is set to the same value as the -c flag.
ipsecstat command (adxipsst.386)

This section describes the ipsecstat command.
Purpose
Lists status of IP Security devices and statistics for IP Security packets.
Syntax
ipsecstat [-c ] [-d ]
Description
The ipsecstat command, used without flags, displays the status of the IP Security drivers and the
statistics of IP Security packets. The command can be used with flags to only list the status of IP
Security drivers or to reset statistics counters to zero.
Flags
-c
Resets statistics counters (after displaying current value). The -c flag cannot be used with
the -d flag.
-d
Lists only the status of the IP Security drivers. The -d flag cannot be used with the -c flag.

Sample output
The following example shows a sample of output from the command: ipsecstat:
IPsec Support: Available
IPSec Statistics -
Total incoming packets: 454
Incoming AH packets: 100
Incoming ESP packets: 100
Total outgoing packets: 116
Outgoing AH packets: 100
Outgoing ESP packets: 100
Total incoming packets dropped: 0
Filter denies on input: 0
AH did not compute: 0
ESP did not compute: 0
AH replay violation: 0
ESP replay violation: 0
IPsec tunnel/policy mismatch: 0
Total outgoing packets dropped: 0
Filter denies on output: 0
Tunnel cache entries added: 2
Tunnel cache entries expired: 0
Tunnel cache entries deleted: 0

Chapter 4. Using the Linux Secure Shell in the Operating System
Using the Linux Secure Shell in the Operating System
This chapter describes using Secure Shell (SSH) in your system.

Note:
1. The options included in this product can help your company address the Payment Card
Industry Data Security Standards (PCI DSS) requirements.
2. The customer is responsible for evaluation, selection and implementation of security
features, administrative procedures and appropriate controls. In particular, some
configuration settings (such as setting the LogLevel option to DEBUG) may compromise
security and should be carefully evaluated for use in a production environment.
Introduction to SSH
SSH is a standards-based application and an associated set of networking protocols that
provides secure, encrypted communications over an untrusted network (for example, the
Internet) between servers and clients.
The SSH implementation in TCx Sky is a set of Linux programs that use the OpenSSH source
code base as well as a set of launcher (proxy) programs that allow access to the SSH programs
from a 4690 command shell. This chapter will explain how to use OpenSSH with TCx Sky as well
as any TCx Sky unique behaviors. Information on SSH concepts, how to use OpenSSH programs,
and the meaning of various configuration options and flags can be found on the internet or in
books on OpenSSH. Reference http://www.openssh.com for information about OpenSSH
programs and configuration.
The version of OpenSSH initially shipped with TCx Sky Version 1 Release 1 is version 7.5,
however this will be updated as needed in future releases to ensure the security and stability of
secure sessions. This chapter will discuss any migration issues and may be able to aid in
migration when this happens. For example, support for the UsePrivilegeSeparation server
configuration keyword has been deprecated in version 7.5 release of OpenSSH and will cause the
server to fail to start if it is specified.
Note: The minimum key size for SSH RSA keys is 768 bits. In the future, OpenSSH will increase
this to 1024 bits. RSA keys are created with a default key size of 2048, however the version of
SSH initially shipped with 4690 Version 6 (version 3.8) had a 1024 bit default size. It is suggested
that you evaluate any existing key files and ensure the key size is adequate. The automatically
created host key files are generated using OpenSSH's default key sizes for each key type (or in
the case of DSA, the only allowed size).
Coexistence with and Migration from 4690 Version 6 SSH

The SSH code in TCx Sky is intended as a replacement for the SSH code delivered with 4690
Version 6. The installed version of SSH will not be removed when a system is migrated from
4690 Version 6 to TCx Sky. The existing programs are provided to allow continued access
immediately after migration. However we do recommend that existing users of Version 6 SSH
migrate to the SSH code provided by TCx Sky as soon as possible, due to the better security and
performance characteristics.
There are several differences to be aware of when using or migrating from 4690 Version 6:
• This document will use the term SSH to refer to the version of SSH delivered with TCx Sky.
When referring to the version of SSH provided with 4690 Version 6, the term “legacy SSH”
will be used.
• SSH provides access to its function and configuration using 4690 programs and files. The
program and file names have been changed relative to legacy SSH to allow for coexistence.

• Because the TCx Sky SSH is much newer than the one provided in 4690 Version 6, any
configuration options or command line flags used with the prior version should be evaluated
to ensure they are still supported and are the correct options/flags to use with this version.
• The SSH programs do not interact with the 4690 command line logging interface, therefore
user interactions with sftp and any Linux shells started by SSH will not be logged. However,
if a user logs into a 4690 command window and has command line logging activated, these
interactions will continue to be logged. The 4690 messages related to SSH will be logged by
the SSH code, but there are some differences:
• For message W620, the return code (RC) field will be set to the return code of the Linux
shell used to run the program. This is limited to 1 byte (a range from 0 to 255). If a process
ends due to a signal, the value will be negative and set to the signal number that caused
the process to end.
• The legacy SSH documentation indicates that the 4690 TCP/IP stack limited the sftp server to
a maximum of 8 sessions and a 16Kb buffer size. This limitation is no longer present.
However, a large number of simultaneous file transfers to the system may cause performance
issues due to the increased network, CPU, and disk utilization.
• When initiating a remote session to an SSH server, the client is allowed to provide a
command to run instead of using the user's default shell. This command is always handled
by the default shell of the user vxuser (/bin/sh, i.e. bash). In legacy SSH, the code only used a
command shell if the program appeared to be a BAT file, otherwise it invoked it directly.
• For the most part, Linux programs such as SSH only understand Linux path names. For ease
of use in configuration and sftp, 4690 “hybrid” path names may be used in some cases. See
the sections below for more details. To summarize, 4690 hybrid paths may be used in the
following locations:
• Paths are only converted in the configuration files in ADX_SDT1:VX_SSHDF.DAT and
ADX_SDT1:VX_SSHCF.DAT. The 4690 paths in these files are converted to Linux paths
when 4690 is started (for the server file) or when one of the client programs is run from
4690 (for the client file). The SSH programs do not direcltly support using 4690 paths in
the configuration files.
• When running the SFTP client on 4690, the any file names that refer to local paths are
hybrid paths.
• When connected to a 4690 system using sftp, any file names that refer to remote paths (i.e.
those paths that the server is responsible for) are hybrid paths.
• Legacy SSH (in particular sftp) allowed files on remote nodes to be accessed (using
ADXLXDDN::C:/file.dat for example). SSH does not have access to files on remote
4690 machines.
• Not all options are enabled (built in) to the SSH server. In particular, the Kerberos, S/KEY,
and GSSAPI authentication methods are not enabled.
Enabling SSH
The OpenSSH programs are part of the Linux subsystem on 4690 and as a result are always
present. However in order to run the SSH server or provide 4690 access to programs such as the
SSH client or Secure FTP, the “SSH” (ADXXTSSH.DAT) must be installed. This extension is
configurable for controllers only.
The 4690 programs that are part of SSH (sshdctl.386, vx_sshcl.386, vx_sshfl.386, and vx_sshcp.
386) are not installed on 4690 until the extension is enabled in configuration and 4690 is
restarted. Like other extension based programs (i.e. mbrowser) the program files are placed in
f:/adx_spgm.
Hybrid File Name Use in Configuration Files

Similar to legacy SSH, the SSH client and server programs are each configurable using
configuration files. As with legacy SSH, the default files used by these programs are stored in
C:/ADX_SDT1. Unlike legacy SSH, however, these files are copied and processed (changed)

before the SSH client/server program is run. More details are found below, however the primary
goal of the processing is to allow 4690 file name use in the configuration file.
Those configuration settings that contain file names are processed using the “hybrid” naming
convention documented in the Sharing Files Between 4690 and Linux chapter of the TCx Sky User's
Guide. If a filename refers to a file in the 4690 file system (and does not contain percent signs), the
file will be copied to a location in the Linux file system and the path in the configuration file
replaced with the new (Linux) path. All of the copied files will start with adxsshd- (for the
server) and adxssh- (for the client); the remainder of the file name will be based on the file
name and path of the source file. The changed lines in the config file will also be in the file by
comments starting with adxsshd: or adxssh: for the server and client respectively. All relative
and absolute file names are left as-is, allowing SSH to do its normal processing. In addition any
4690 paths that refer to files in the Linux filesystem (i.e. f:/file.dat) or files in the 4690
filesystem that contain percent signs (%) will be converted to Linux paths without making a
copy of the file. For example, f:/key.dat will be changed to /mnt/f/key.dat and m:/
files/%u.data will be changed to /mnt/m/files/%u.data. Note however that file
permissions are not changed in this case. Depending on the keyword being set, the SSH code
may have specific requirements about file and directory permissions, in particular, key files.
Permissions of files and directories in the Linux file system need to be manually set; files in the
4690 file system are set to a fixed value which may not be acceptable to SSH.
If a 4690 file listed in a configuration file doesn't exist or if there is an error copying a 4690 file,
the file will be removed from the configuration line and a comment about the failure added to
the configuration file. If no valid file names were found for a given keyword, the line containing
the keyword is commented out.
Some additional changes are done to the configuration files as well. Some settings are ignored by
the SSH code if they appear more than once in a file (or Match/Host section), with the server
code ignoring all but the first or last entry. For clarity, the 4690 processing code will comment
out the other entries and not process any file names on those lines.
If a property is not set (or is set to a missing or invalid file name causing the line to be
commented out of the configuration file), then SSH client programs will use the default values
for that property. As an example, the client configuration setting UserKnownHostsFile is set
to the 4690 file name c:/adx_sdt1/vx_sshkh.dat, which doesn't exist by default. If this file
is not created in 4690, SSH client code will use the default path for the known hosts file (~/.ssh/
known_hosts).
SSH Server (sshd)

The SSH Server (sshd) allows remote SSH clients to connect to 4690. The configuration file for
the SSH server is ADX_SDT1:VX_SSHDF.DAT; the file is not shipped with 4690. A sample file
(ADX_SDT1:VX_SSHDF.SMP) is provided as a reference. If this file exists, the server is started
automatically when 4690 starts. Unlike legacy SSH, the sample file is not used as a default
configuration file, the configuration file must be specifically copied or created (and distributed if
desired). If you create or make changes to the configuration file, 4690 must be warm booted for
the new file to take effect. Note that the configuration file would typically be distributed to all
controllers if you wish to start the SSHD server on all controllers (or you may wish to limit the
file to specific controllers).
In addition to creating the configuration file above, 4690 Enhanced Security must be enabled for
the SSH server to start.
Authentication to the SSH server may be done either by user id and password or using public
key authentication. In order to use an id and password to authenticate,
ChallengeResponseAuthentication and KbdInteractiveAuthentication must be
enabled in the configuration file. If a user’s password is expired, they will be prompted to
change it. Note that only the passwords for IDs managed by enhanced security can be changed
using this mechanism; directory services password changes come from the LDAP server.
Chapter 4. Using the Linux Secure Shell in the Operating System 71

In order to authenticate using a public key, the keys must be listed in one of the files indicated
with the AuthorizedKeysFile keyword in the configuration file.
Note: The value for AuthorizedKeysFile in the sample file mirrors the legacy SSH design
(listing a single file). These keys are shared among all users logging in. Any user holding the
corresponding private key to a key listed in this file can authenticate as any 4690 user as well as
authenticating directly as the Linux user vxuser. Once authenticated they do not have to run the
default shell (sshsession), which takes them to a 4690 login screen, but could run bash instead,
for example. Using percent sign expansion (specifically the %u token) in the key file name will
allow you to have keys that are specific to individual 4690 users; however, this still won’t
provide the same level of protection as a typical Linux system because all users still end up with
the same basic privileges (i.e. the Linux user id “vxuser”). It is recommended that authorized
keys be used only for users that require full administrative access or for things such as
automated background tasks, which are not tied to a specific user.
SSH sessions
The default shell for users logging into 4690 is a program (sshsession) that creates a login session
for 4690 users (displaying the 4690 login screen). As with legacy SSH in prior versions of 4690,
one or more auxiliary consoles must be configured for this to work. The number of simultaneous
remote sessions is equal to the number of auxiliary consoles configured (which is at most 8). This
limit does not apply if a different command is provided by the client or forced in the
configuration file.
If an SSH client provides a command to run instead of using the default shell, this command is
always run using the default shell of the Linux user that logs in (vxuser). The default shell for
vxuser is /bin/sh which corresponds to the bash shell. This is different behavior than legacy SSH,
which expected the name of a 4690 program or batch file. If you wish to run a 4690 program
using this mechanism, you have a several different ways of doing it:
• Run the program directly by providing bash with the Linux name of the program. For
example, /mnt/c/adx_spgm/adxzudir.286.
• If you need to use 4690 command shell commands or operations such as redirection, it would
be simplest to write a BAT file and put the operations in there. However, if you wish to send
this using an SSH command you must send the command in such a way that neither the
client shell nor server shell (bash) attempt to do the redirection early. For example, if you
wish to run the 4690 command dir and save this to the file c:/dir.out on 4690, the
following will work from a Windows machine:
ssh user@host /mnt/c/adx_spgm/command.286 -c "'dir -s c:/ > c:/dir.out'"
If you wish to run a bash shell or any other Linux program that requires a terminal, you will
need to tell the program to create a one. With the OpenSSH command ssh, this is done by using
the -t flag.
Enhanced security permissions

In order to initiate a session with the SSH server running on 4690, the 4690 user id must have
specific permissions, depending on the type of session requested.
• Users attempting to do a file transfer using sftp or scp must have the “SSH Secure FTP
Logon” permission (ADX_CPW_ATTR_SSH_SECURE_FTP_LOGON).
• Users attempting to open a default shell to 4690 (to access a 4690 logon screen as described
above) must have the the “SSH Secure Remote Logon” permission
(ADX_CPW_ATTR_SSH_SECURE_REMOTE_LOGON).
• Users attempting to run commands other than open a default shell, must have the “SSH
Secure Remote Logon” permission (ADX_CPW_ATTR_SSH_SECURE_REMOTE_LOGON) as well
as the Command Mode (ADX_CPW_ATTR_COMMAND_MODE) and Background Application
Control (ADX_CPW_ATTR_BACKGROUND_APPLICATION_CONTROL) permissions.

4690 OS account lockout
It is possible to create an account lockout policy that locks a user account and prevents logins
after some predetermined number of unsuccessful login attempts. It affects all password based
logins done through the SSH server (which includes sftp and scp).
You may configure the settings in System Configuration by choosing: System Configuration >
System Security > FTP ID Security.
Note: The SSH server lockout status is independent of both the legacy SSH server, console login,
and the FTP server; therefore, a user locked out by the SSH server is not locked out of the others.
Configuring the SSH server

Before the SSH server is started, the SSH server configuration file (ADX_SDT1:VX_SSHDF.DAT)
is processed by 4690, copied to the location expected by OpenSSH and given the correct
permissions. As part of this procedure, any 4690 files referenced in the configuration file are also
copied and protected.
In addition to the above file name processing, 4690 prevents certain keywords from being set in
the SSHD configuration file. Some of these options have default values which will be set
automatically. The list of keywords which cannot be used or changed is:
• AuthorizedKeysCommand
• AuthorizedKeysCommandUser
• AuthorizedPrincipalsCommand
• AuthorizedPrincipalsCommandUser
• PermitEmptyPasswords
• PermitRootLogin
• PidFile
• XAuthLocation
The legacy SSH code automatically created the RSA and DSA (private) host key files
(ADX_SDT1:ADXSSHRK.DAT and ADX_SDT1:ADXSSHDK.DAT) if they did not exist. SSHD also
allows host keys that use the ECDSA and ED25519 algorithms. The default sample file lists 4
host key files:
• ADX_SDT1:VX_SSHRK.DAT (RSA)
• ADX_SDT1:VX_SSHDK.DAT (DSA)
• ADX_SDT1:VX_SSHCK.DAT (ECDSA)
• ADX_SDT1:VX_SSHEK.DAT (ED25519)
If none of the four private host key files exist, all 4 files will be automatically created when 4690
is reloaded with the adxsshd extension configured. The public part of the key pairs will be stored
in a file of the same name but with the extension “.PBK”. Key file generation is done
independently of any contents of the SSH server configuration file (i.e. this step will be done
using the names above even if the file names used in the server configuration differ from those
in the sample file or not all files are listed). This allows you to comment out the line referencing
the DSA key, for example and still have the other files be auto-generated and used. If you wish
to use the legacy SSH keys instead, the key files may be copied or you can change the
configuration file to reference the older key files. Note that because host keys are intended to be
machine specific, the default host key files are created as local files and not distributed to other
controllers.
Other comments on SSH configuration

Although it is possible to use the contents of the legacy SSH server configuration file
(ADX_SDT1:ADXSSHDF.DAT) as a guide for SSH, not all settings will transfer properly. For

example, the sftp subsystem should refer to the Linux sftp program and not the 4690 SFTP
program.
The Match keyword uses the Linux user id (vxuser) and group (vx4690) for matching.
The value set in the MaxAuthTries keyword does not relate to the number of attempts allowed
for a 4690 user to enter their password (which is always 3). Instead this is related to the number
of authentication attempts made internally by OpenSSH. If you use a key manager that presents
multiple public keys for a single authentication attempt, any rejected keys will be counted as
failures.
Troubleshooting the SSH server

If you have problems connecting to the SSH server after creating/modifying
ADX_SDT1:VX_SSHDF.DAT and warm booting the controller, the first step to take is to run the
program sshdctl.386. The syntax for the program is:
sshdctl [command]
If no command is given, sshdctl will provide a brief summary of server status as well as
identify common problems like a missing server configuration file. Other available commands
are:
status -
Provides more detailed server status information that will be more useful to someone
used to managing Linux systemd services.
log -
Display the SSHD server log
reload -
Reload the server configuration file and restart SSHD. This does not end any existing
ssions.
help -
Display a summary of available commands
If the server didn’t start, it is probably due to an error in the configuration file or some external
reason (port in use, etc). The first step is to examine the configuration file to see if the 4690
processing reported any problems. Any messages added by 4690 will be in comments starting
with adxsshd. The 4690 accessible file adxvxlog:sshd_config is a link to the server
configuration file. You may use XE to edit the file (but not make changes since adxvxlog: is read-
only).
If the configuration file looks OK or if the server is running but not operating as expected, run
sshdctl log to examine the log entries generated by the sshd server. This should reveal
information about the cause of the problem. Increasing the level of information logged by
changing the LogLevel configuration property may also help, but be aware of the warnings in
the SSHD documentation (specifically that using the DEBUG levels may cause privacy/security
issues).
After changing the SSH server configuration file (or any files referenced by it such as key files),
the SSH server needs to be restarted to use the changed information. This may be done by warm
rebooting 4690 or by running sshdctl restart. Existing SSH client sessions are not ended
when the SSH server is restarted. If the server is indirectly restarted by warm booting 4690, any
existing sessions that are accessing 4690 resources such as sftp/scp sessions or 4690 console
sessions will lose access to those 4690 resources.

Secure FTP server
Secure ftp (sftp) allows a client machine to connect to a SSH server and transfer files in an
interactive session. The initial directory for a user logging in with sftp is determined by the sftp
permissions file (see below).
The remote file and directory names (that is, the files and directories on the 4690 machine) can be
either 4690 paths or Linux paths, specifically file and directory names resolved using the
“hybrid” naming convention documented in the Sharing Files Between 4690 and Linux chapter of
the User's Guide. For example, to change to the directory where 4690 stores its program files, a
remote user may use cd c:/adx_spgm or cd /mnt/c/adx_spgm. Command line invocations
and SFTP batch files should be evaluated to ensure that the correct paths are used. For example,
when using legacy SSH the command “cd /” would change to the root directory of the C: drive;
when using SSH it changes to the root directory of the Linux file system.
Note that when you use 4690 file names with sftp, the names printed during a transfer will look
a little strange. The remote sftp client always sends an absolute Linux file paths to the server (it
prepends the current working directory to any provided file name if it doesn't start with a slash).
For example if the user types the following commands (assuming the remote directory is f:/):
get c:/tmp/file.dat
put local.dat get adx_idt1:remote.dat
The client will display messages indicating that the following are the remote file names:
/cdrive/f_drive/c:/tmp/file.dat
/cdrive/f_drive/adx_idt1:remote.dat
In order to identify the 4690 path within a file name, the sftp server code on 4690 searched for a
colon. The start of the 4690 path is the first character after the immediately preceding slash. In
the above example, this will be:
c:/tmp/file.dat
adx_idt1:remote.dat
In order to transfer a file name containing a colon (i.e. a file that is on the F: drive and would
normally not be accessible by 4690 programs), add a colon to the path immediately following
any slash or at the beginning of a relative path. The single colon will be removed and the rest of
the path passed to Linux. For example to retrieve the file /tmp/hello:world, then either
change to that directory and run get :hello:world or use get /:tmp/hello:world or
get “/tmp/:hello:world”). In 4690 Version 6, a separate sftp server was shipped with 4690
(ADXSSHPL.386). This program was used internally by the legacy SSH server. There is no
replacement for this program in TCx Sky because it is not needed.
SSH client programs

Several SSH client programs are provided in TCx Sky. Each of these programs allows a 4690 user
to connect to an SSH server and perform various operations. The common aspect to each of these
programs is that they all use the SSH client configuration file (ADX_SDT1:VX_SSHCF.DAT). A
sample file is shipped with 4690 as ADX_SDT1:VX_SSHCF.SMP. The sample file contains default
values for the identity and known hosts files that are similar to the files used in legacy SSH (with
“vx_” replacing “adx” in the file names. You may wish to change the file to refer to the legacy
names or generate new TCx Sky specific files depending on your requirements.
When connecting using an SSH client program, the parameter list typically has the format
[user@]host as one of the parameters. This format also works if the user id is a directory
services user, who have user ids that end in “@” (there will just be two @ signs in the string). For
example, to protect user first.last@ to the host host.name, use the connection parameter
first.last@@host.name.

When one of the client programs below is started, the configuration file is processed and copied
to the Linux filesystem (as /home/vxuser/.ssh/config). This file can be accessed from 4690
as f:/adxetc/home/vxuser/.ssh/config. If the configuration file does not exist, the
sample file will be used instead. The sample file is overwritten by 4690 maintenance, so any
modifications to the defaults it uses must be made by copying the file to
ADX_SDT1:VX_SSHCF.DAT (and distributing it if desired).
As with the server configuration file, any keywords in the SSH client configuration file that refer
to files in the 4690 file system are copied in order to be usable by SSH client code. In many cases
this will involve copying them to the user’s SSH configuration directory (/home/vxuser/.ssh
or f:/adxetc/home/vxuser/.ssh). All of the copied files will start with adxssh-; the
remainder of the file name will be based on the file name and path of the source file. Any
existing files starting with adxssh- in the SSH configuration directory are deleted before file
processing starts. Note that processing for the Include keyword is slightly different. No copy is
made for files specified using the Include keyword (all 4690 paths are simply converted to
Linux paths). The contents of the include files themselves is also unmodified and must refer to
any files by their Linux paths.
The file(s) specified by UserKnownHosts is an exception to the file copying rules. These files
may be modified by the OpenSSH programs (when they prompt the user to add keys for new
hosts). Instead of blindly copying 4690 files to Linux when a SSH client program (vx_sshfl,
vx_sshcl, vx_sshcp) is started, the 4690 file is copied to Linux only if it's newer (or the Linux file
doesn't exist). If the Linux file exists and is newer, it is instead copied to the 4690 file. Note that
this will fail if the 4690 file is distributed and the controller is not the acting master.
When a client program (e.g. sftp) is run directly from Linux, the processing step is not done. By
default, client programs will use the default configuration file, which is the same one created by
the processing code above.
SSH requires that both the SSH client configuration file and private key files have very specific
permissions (typically read-write by the user and not accessible by group and other). If you
manually copy the key or configuration files from 4690 using the F: drive or copy them from an
existing file, the Linux file permissions will be incorrect. Specifically, 4690 uses permission 0660
(-rw-rw----) for files it creates on the F: drive. OpenSSH requires the more restricted permission
0600 (-rw-------).
Troubleshooting SSH Client Configuration issues

The first step is to examine the configuration file to see if the 4690 processing reported any
problems. The modified SSH client configuration file is written to ~/.ssh/config; this file is
accessible from 4690 as f:/adxetc/home/vxuser/.ssh/config (it’s also accessible in
adxvxlog:ssh_config). Any messages added by 4690 will be in comments starting with
adxsshd:.
The SSH client tools all the verbose flag (-v) to be specified to increase the debugging level. This
flag may be useful in identifying problems with the configuration file
SSH Client shell

The SSH client shell program (vx_sshcl.386) allows users to initiate a remote shell connection
with an SSH server. This 4690 program invokes the Linux ssh program passing all command line
parameters to it unchanged. Any files passed as parameters must be valid Linux paths (hybrid
path resolution is not done).
The default program run on the remote system depends on the configuration of the remote SSH
server; typically it's a command shell. The ability to properly use a shell's abilities (i.e. run full
screen programs) depends heavily on the ability of the remote shell to send the correct escape
sequences to 4690. When ssh is started using vx_sshcl.386 from a 4690 command window, it runs
the 4690 vt100 terminal emulation program to handle formatting data for display on the terminal
console. This is the same as the behavior as in older versions. This means that the telnet escape

sequence (Ctrl-]) will work as it did in legacy SSH and the normal SSH escape character will not
work. When ssh is invoked directly (as from an xterm window) the vt100 program is not run and
the normal SSH escape processing will work normally.
Secure FTP client

The secure ftp client program (vx_sshfl.386) allows 4690 users to connect to a SSH server and
transfer files in an interactive session. This 4690 program invokes the Linux sftp program
passing all command line parameters to it unchanged. Any files passed as parameters on the
command line must be valid Linux paths (hybrid path resolution is not done).
Once the SFTP client is running, local file and directory names (i.e. those representing files local
to the 4690 system) are treated as 4690 hybrid paths.
The following commands allow 4690 hybrid paths:
• lcd/lchdir – Changes the local working directory. Note that when lpwd is used to print
the local working directory, it will always be the corresponding Linux path.
• lmkdir – Creates a directory.
• lls – Note that the Linux ls command performs the file listing. Any parameters that appear
to be 4690 paths are converted to Linux paths before the command is run.
• get/mget – The target file name/path is a 4690 hybrid path.
• put/mput/reput – The source file name is a 4690 hybrid path.
Note that the ! (shell) command in sftp will always run the command using the default Linux
shell /bin/sh (bash). See the comments in “SSH sessions” on page 72 for information about how
to run 4690 programs from a Linux shell.
Secure Copy (SCP)

The secure copy program allows for secure file transfers just like the SFTP client does, but in a
more easily automatable fashion. The program provided by 4690 (vx_sshcp.386) invokes the
Linux scp program passing all command line parameters to it unchanged. The parameter format
for SCP allows for remote files to be accessed by preceding the file name with the host name or
IP address and separating the two with a colon.
[[userid@]host:]path
Because of this, 4690 path names would not normally be able to be used without also using a
host name. For the convenience of 4690 users, scp has been modified so that, if the file name
starts with a colon (that is, the host name is empty), it's assumed the file is a local file and the rest
of the file is used as-is. (This is unlike other OpenSSH implementations that would also treat the
file name as a local file name and would consider the colon part of the name). For example, if
you want to copy the file adx_stld:adxtm001.log to f:/logs on a remote 4690 machine
you could use the command:
scp :adx_stld:adxtm001.log remotehost:f:/logs/
In some cases you may be able to double the colon when the source filename is a remote file.
This is because internally scp invokes a copy of itself on the remote machine. For example, to
copy the file adx_stld:adxtm001.log from a host named “cc” to the same location as above,
you would use the command:
scp cc::adx_stld:adxtm007.log remotehost:f:/logs/
In this case, the first colon is used to separate the host name from the file name. The second colon
is used to indicate that the file name adx_stld:adxtm001.log set to the host cc is a local file
and that adx_stld is not the host name. Doubling the colon would also be required if a file
name with a drive letter was used:
scp cc::c:/adx_stld/adxtm042.log remotehost:f:/logs/

Because it is used for file transfer, SCP checks the same user permissions as SFTP does;
specifically the “SSH Secure SFTP Logon” function must be enabled.
File permission checks are done on all files transferred by scp (even if the files are local files); this
is used specifically to ensure that files are protected for remote-to-remote transfers. For example,
running scp src.dat tgt.dat will not involve an SSH connection at all, but both file names
will be checked against the security file. Note that the id of the currently logged in user is used
for local file checks.
Normally the shell (bash) handles wild card expansion in file names. For example, when running
the command scp *.log remotehost:. the shell will expand searches for any files matching
the specification *.log and passes that list to the scp program. The bash shell does not
understand 4690 paths, so running the command scp HYPERLINK "file:///c:/
adx_spgm/*.log" c:/adx_spgm/*.log remotehost:. results in the path HYPERLINK
"file:///c:/*.log" c:/adx_spgm/*.log being passed to scp. The scp program itself will
expand this file list so the latter command works as expected, however this does have some
caveats:
• SCP will only expand wild cards in 4690 path names. It is suggested that you use forward
slashes or use double quotes in 4690 path names to avoid bash's special treatment of the
backslash character.
• File names are expanded on the system where the files are located, that is, paths on remote
systems are expanded on the remote system.
• File names are expanded using the same wild card matching rules as the default bash shell,
which means you should get similar results when using the paths HYPERLINK
"file:///C:/wildcardspec" c:/wildcardspec and /mnt/c/wildcardspec.
SSH key generator

A program named ADXSSHKL.386 was provided with legacy SSH. This program allowed a 4960
command line user to generate key files for use by SSH. The Linux version of this program to
generate key files (ssh-keygen) is shipped with 4690, however there is no 4690 replacement for
ADXSSHKL.386. The file naming conventions and other expectations of the Linux tool do not
match well with conventions used by the legacy SSH tools. Keys previously generated by ssh-
keygen on other OpenSSH platforms may be transferred to 4690 and used.
SFTP/SCP file permissions

Legacy SSH used a permissions file named ADX_SDT1:ADXSSHXH.DAT to specify access
permissions for files in 4690. SSH uses the file ADX_SDT1:VX_SSHXH.DAT instead. The file lists
the directories a user is allowed to access or prevented from accessing. The format of the file is
intended to be similar to the 4690 SFTP permissions file (and is similar to the older ftp
permissions file), however there are some differences as listed below. The VX_SSHXH.DAT file is
required for SFTP and SCP to be used for file transfer; in the 4690 Version 6 documentation, it
was implied that ADXSSHXH.DAT was not required, but in practice it was. This means that any
user wishing to use sftp/scp must be listed in this file. The file should be distributed to all
controllers to which you wish to allow sftp/scp transfers.
Each line in the VX_SSHXH.DAT file consists of a keyword and a value separated by a colon;
blank lines and lines starting with semicolons are ignored. The keyword determines the format
of the remainder of the line. An example permission file is listed below:
user: 1 2 3
wr: c:/users c:/adx_sdt1
rd: c:/users c:/adx_sdt1 c:/adx_spgm
rd: f:/data/input
wr: f:/data/output
user: admin 99999999

rd: c:/
rd^: c:/private

wr: c:/
wr^: c:/private
The “user” keyword should be followed by a list of one or more user ids separated by spaces.
The user keyword should be followed by one or more lines defining the permissions for that
user. All permissions following user keywords are applied to the user(s) listed until the next user
keyword is read (or the end of the file). If there are no permission keywords following the entry
for a user or if a user is not listed in the file, then that user is considered to have no access at all
and will not be able to access 4690 using sftp. If a user is listed after more than one user keyword
in the file, only the first set of permissions are used.
The following keywords are used to indicate permissions for a user. The permissions keyword
should be followed by one or more directory names separated by spaces. If a user is allowed (or
denied) access to a directory, then that permission is recursive; it applies to all files in that
directory as well as subdirectories. The paths are considered hybrid 4690 paths; non-absolute
paths are resolved relative to the root directory of the C: drive.
• rd – Read permissions. The user is allowed to read (get) files from the directories listed after
this keyword. Read permission is also required to use the ls command to list files in a
directory and is also required for the source directory of a file being renamed.
• wr – Write permission. The user is allowed to write (put) files into the directories listed after
this keyword. Write permission is required for the target directory of a renamed file.
• rd^ / wr^ - These permissions are the inverse of the read and write permissions above. A
user is denied read or write access to any directories after one of these keywords. Deny access
is only checked if a user otherwise has read access to a file. This allows privileged users be
granted access to an entire drive (e.g. C:/) but to exclude specific directories on that drive (e.g.
C:/private).
The directory names above are hybrid paths as discussed above. Non-absolute paths are
resolved relative to the root of the C drive (c:/). Both read and write permission are required to
delete a file.
When using SFTP to transfer files to other systems, the initial current directory on the remote
system is typically the user's home directory. However SFTP in TCx Sky code mirrors the
behavior of the legacy SFTP code. Specifically the initial remote directory is set to the first
directory to which the user has write access (as listed by the wr keyword). If a user doesn't have
write access to any directories, then the initial remote directory is set to the first directory to
which the user has read access (as listed by the rd keyword). If a user has neither read nor write
permissions specified, then they will not be able to use sftp or scp to access files.
Note that any process launched by SSH runs as the Linux user “vxuser” (and group “vx4690”).
Access to Linux files and directories is limited to those that to which vxuser has access. In
addition, 4690 file access permissions may also prevent other files from being accessed (for
example files opened in exclusive mode or image versions of distributed files). For security
reasons, all users are prevented from changing, deleting or renaming
ADX_SDT1:VX_SSHXH.DAT using sftp.
When converting the legacy SFTP permission file for use with TCx Sky, it is important to be
aware of the following differences between the two files:
Lines can be up to 4096 bytes long (including the carriage return and line feed) with SSH (vs 80
bytes for legacy). Any bytes after 4096 are ignored.
More than one user id may follow the user keyword. 4690 SFTP silently ignores additional ids.
The paths are hybrid 4690 paths. This will primarily affect paths starting with a slash or
backslash. In legacy SSH these would have been files on the C: drive; in TCx Sky these are
relative to the root directory of the Linux file system.
Path names (for both the file being accessed and in the permissions file) are fully resolved before
allowing access. Thus, adding both f:/ and /mnt/f to allow access to files on the F: drive is not
required, either one alone will work.

In legacy SSH, when one of the deny permissions was used, it converted all file paths for the
same access type to deny permissions. For example, using the permission lines rd: c:/ and
rd^: c:/private would have denied read access for the entire C: drive (but would have
allowed access to all other drives). Unlike legacy SSH, deny permissions do not affect the allow
permissions. In order to determine whether access is allowed to a file, program checks the allow
list first and then the deny list. Access is allowed if the file containing directory is listed in the
allow list and NOT in the deny list (if any).

Chapter 5. Using the Remote Command Processor
Using the Remote Command Processor
This chapter introduces the Remote Command Processor (RCP) and explains its usage.
Introduction to RCP
The Remote Command Processor (RCP) is a 4690 application that enables you to perform the
following functions:
• Run the 4690 system applications on a remote 4690 system
• Initiate applications on the store controller
• Run any user application on a remote 4690 system
• Initiate an application on any node if using the Multiple Controller Feature
For example, if a local store is experiencing system problems, the remote site needs a system log
report from the store to analyze the problem. The RCP application is used to format the report.
When the report is formatted, it can be retrieved from the remote site for printing and analysis.
The exchange of information between the remote site and RCP happens as follows:
1. The remote site creates and transmits a SELECTION file and COMMAND file (or files) to
the remote store controller.
2. The remote site sends the command to start RCP on the remote store controller.
3. RCP reads the SELECTION file to find the name of the appropriate COMMAND file.
4. RCP finds and reads the COMMAND file and begins formatting the system log.
5. The remote site retrieves the formatted report.
To use RCP, you must first create two files: an RCP SELECTION file and an RCP COMMAND
file. The files may be transferred to a store controller at a remote site. RCP creates or appends to
a third file, the RCP STATUS file, when RCP executes.
Although RCP is a background application, it is not automatically started when the system IPLs.
You must start the application each time you want to use it. See “Starting RCP” on page 125 for
more information about starting RCP.
The RCP Selection File

The RCP SELECTION file resides in the ADX_IDT1 subdirectory on the hard disk drive of the
remote store controller. The RCP SELECTION file, ADXCSHCF.DAT, contains the name of the
RCP COMMAND file to be used.
The RCP SELECTION file might contain one or more COMMAND file names. RCP opens the
COMMAND file specified and finds the commands to execute. The COMMAND file name can
have any of the following levels associated with it:
File name
RCP assumes the file resides in ADX_IDT1 and has an extension of DAT.
ADX_IDT1:filename.DAT
File name and extension

RCP assumes the file resides in ADX_IDT1.
ADX_IDT1:filename.ext

Subdirectory, file name and extension
RCP takes the information as specified to gain access to the COMMAND file. For LAN
users, a two-character node ID (such as DD) might prefix the other parameters.
DD::fn.ext
or
DD::subdirectory:fn.ext
In a LAN environment, the distribution attributes of the RCP SELECTION file must be
Compound, Distribute On Close. The SELECTION file can contain one or more COMMAND file
names, but each file name must be on a separate line. In addition, each line must be ended by
ASCII CR/LF characters.
Because you can have several RCP COMMAND files, you must edit the RCP SELECTION file
each time you use it to ensure that the file contains the appropriate COMMAND file name. For
example, if you want to use ASM and that RCP COMMAND file is named ASM.DAT, you
would edit the RCP SELECTION file to ensure that it contained the file name ASM.DAT.
After building the RCP SELECTION file, transfer the file to the remote store controller. When
you are ready to initiate an RCP function, start RCP as described in “Starting RCP” on page 125.
The RCP COMMAND File

The RCP COMMAND file contains commands and parameters for applications. RCP starts the
applications on the 4690 system that has RCP running. You must transfer the file to your defined
subdirectory on the remote store controller. You must place it in the subdirectory that has been
named or assumed in the SELECTION file.
The COMMAND file can be any name you choose. The COMMAND file name must match the
file name in the SELECTION file. If the COMMAND file is sent to a 4690 store controller on a
LAN, the COMMAND file must be a local file.
The file can contain one or more commands, but each command must be on a separate line. Each
line must be ended by ASCII CR/LF characters. Each command can be prefixed by a two-
character node ID, subdirectory name, or both. If there is not a prefix to the command, RCP
assumes the command resides in the ADX_SPGM subdirectory. Therefore, the command is
started on the store controller that is running RCP. The parameters following the commands
have the same restrictions as the ADXSTART command in BASIC. The parameters must be no
more than 46 characters in length. Any parameters over 46 characters are ignored.
You might want to build several RCP COMMAND files to prepare for different situations. After
building an RCP COMMAND file, transmit the file to the remote store controller.
The following example shows commands and parameters that can be included in a COMMAND
file of a dump formatter command, followed by a system log formatter command:
ADXCSL0L Y 1
CC::ADX_SPGM:ADXCSN0L N 7 02⁄10⁄90 03:00 02⁄10⁄90 23:50 * * *
ADX_UPGM:USRPROG
Note: Certain commands cause the store controller to IPL. If the COMMAND file includes these
commands, the commands following them are not executed when RCP processes the
COMMAND file.
Command Files on LAN Systems

You can request that a program be started on a specific node in a LAN system by prefixing the
application name in the COMMAND file with a two-character node ID followed by two colons
(::). This function lets you start applications on any node in the LAN system from the store
controller connected to the host.

If you need to run an application on every store controller in the LAN, you can use one
command prefixed by two asterisks and two colons (**::). The asterisks tell RCP to start the
application on every store controller in the LAN.
The following example COMMAND file starts ASM on store controller JJ:
JJ::ADXCST0L N 1 S
The following example starts the module-level report formatter on all controllers in a LAN. A
single output file named ADX_SDT1:ADXCSSDF.DAT exists on the master controller. This file
contains all the reports from each store controller.
**::ADXCSS0L N 3 S
User-Created Output Files

In a LAN environment, output files created by applications started by RCP must be defined to
RCP. Defining the files enables RCP to move files to the master store controller where you can
retrieve them by the host. For the Toshiba system applications, you define these output files to
RCP by the ADX_SPGM:ADXCSHOF.DAT file. This file lists the 4690 applications and the
output files associated with each application.
A similar file is available that identifies output files from user applications. The name of this file
is ADX_SDT1:ADXCSHUF.DAT. This file should be used only when the output file from a user
application is to be placed on the master store controller after the application has run.
You can use any editor to build the ADX_SDT1:ADXCSHUF.DAT file. The user output file
consists of two types of entries:
Application Identification Entry

The applname part of this entry is 8 characters or less.
The extension associated with the application name must not be included on this entry.
–applname
Output File Identification Entry

This entry follows the application identification entry. You can have as many output file
identification entries following the application identification entry as needed to identify
all of the output files. The format of the entry is:
subdir:fn.ext
The following is an example of a user output definition file ADXCSHUF.DAT:

–USERAPPL
ADX_UDT1:UAOUT1.DAT
ADX_UDT4:UAOUT2.DAT
–UAPPL2
ADX_IDT1:SALESRPT.DAT
For this example, whenever you run USERAPPL on a LAN system on any store controller other
than the master, RCP copies ADX_UDT1:UAOUT1.DAT and ADX_UDT4:UAOUT2.DAT to the
master store controller into the same subdirectories from where the files came. Whenever you
run UAPPL2, RCP copies ADX_IDT1:SALESRPT.DAT to the master store controller into the
ADX_IDT1 subdirectory.
When the user output file exists, it must be a Compound file, which means it exists on every
store controller in a LAN environment. The user output name file is not used in a non-LAN
environment.
Chapter 5. Using the Remote Command Processor 83

Applying Maintenance on a LAN System through RCP
When applying maintenance on a LAN system through RCP, RCP reports a system status for the
maintenance activity. This system status reports the most severe error found on any store
controller on the LAN. RCP gathers status from each node in a LAN system and logs that status
in the RCP STATUS file ADXCSHSF.DAT on the master store controller during the IPL
processing of RCP.
The RCP STATUS File

When you run RCP and a 4690 Store System application or a user application that supports the
STATUS file, the application creates or updates the STATUS file. The RCP STATUS
file ,ADX_SDT1:ADXCSHSF.DAT, reports the results of the application. The file contains the
commands and parameters that were attempted when the requested program was executed. The
file tells you if the formatter you used is currently running, has failed, or has completed.
The STATUS file reports the results of all applications started. The 4690 application logs
messages into the RCP STATUS file. You can also write user applications that log messages in
the STATUS file.
Table 4 explains some of the messages that are logged.
Table 4. RCP STATUS File Entries

Message Explanation
dd⁄dd⁄dd tt:tt:tt The Remote Command Includes date and time followed by a message
Processor ended. indicating that RCP has ended.
dd⁄dd⁄dd tt:tt:tt The Remote Command Includes the date and time followed by a
Processor was started in store xxxx. message indicating that RCP has started.
The current node identifier is nn. This message is written only when RCP is
running on a LAN system. nn is the node ID
where RCP is running. This message tells you
on which node the command following is
executed. The message is not displayed in a
non-LAN environment.
dd⁄dd⁄dd tt:tt:tt The Remote Command This message is written when RCP was started
Processor was started in store xxxx due to a by IPL of the store controller and the IPL
store controller IPL. parameter passed to RCP.
tt:tt:tt Preparing to start a command. These messages are written when RCP is
tt:tt:tt Command execution is attempting to start a command on another
complete. node in a LAN environment. You can use
these messages as a debugging aid if other
expected messages are not written in the
STATUS file, especially when starting an
application. RCP writes the first message just
before it attempts to start a command. RCP
writes the second message when the it
recognizes the command is no longer running.
tt:tt:tt RUNNING command These messages are written as a result of the

parameters 4690 applications running. The messages tell
tt:tt:tt SUCCESS command parameters you the status of the command execution.
tt:tt:tt FAILURE command parameters
tt:tt:tt PARTIAL command parameters

Message Explanation
All entries in COMMAND file fn.ext have This message is written in the RCP STATUS
previously been executed. file when RCP has started an IPL of the store
controller and determined that all the
commands in the COMMAND file have been
executed.
Unable to copy ADXLXnnN::fffffffff to the RCP could not move a file associated with an
master node. Return code = xxxxxxxx application that has just completed to the
master. Such files are defined in the
ADXCSHOF.DAT file for Toshiba
applications, and in the ADXCSHUF.DAT file
for user applications. This causes RCP to end
with a return code of xFFFFFFFF if other errors
have not occurred. Check the RCP STATUS
file to determine if the return code for the file
move indicates an actual error for this RCP
session.
For example, if a System Log scan was just ran
to create a formatted output file
(ADXCSNRF.DAT), and an unformatted
output file (ADXCSNUF.DAT) was not
created, the message would indicate that
ADXCSNUF.DAT could not be moved (RC =
80204010). This return code indicates a file not
found condition. In this instance this is not an
error because the unformatted output file was
not created.
The return code from the previous command This message is written when RCP has
is xxxxxxxx. determined that the command started by RCP
is finished. RCP provides the return code in
hexadecimal.
The final return code is xxxxxxxx. This message written when RCP has started all
the commands requested in the COMMAND
files, and provides the lowest value return
code from all the commands in hexadecimal.
The STATUS file has at least two entries for each application that runs. The first entry contains
the following elements:
• Time the application was started
• Processing status of the application
• Application name and parameters
The second entry indicates the application completion status, which can be one of the following:
Success
Function completed without problems.
Failure
Function did not complete successfully.
Partial
Only a portion of the function was performed or none of the function was completed, and
the incorrect parameters are identified.

The time, the name, and the parameters of the application are listed after the completion status.
The next line identifies the return code. Other processing messages might appear between the
first and last entries.
An example of a STATUS file follows:
01⁄05⁄90 10:05:39 The Remote Command Processor
started in store 205.
RUNNING 10:05:45 ADXCS30L N 1 ADX_SMNT:
SUCCESS 10:06:18 ADXCS30L N 1 ADX_SMNT:
The return code for the previous command is 00000000.
01⁄05⁄90 10:06:27 The Remote Command Processor ended.
The final return code is 00000000.
RCP Commands
This section explains RCP commands and their parameters. You can include these commands in
your RCP COMMAND file as needed. All mandatory parameters for a command are listed.
Optional parameters are enclosed in brackets.
Use the following command to start RCP from the host.
Format
ADXCSH0L i [x] [o]
Where:
i=
The STATUS file reset indicator:
Y=
Reset the RCP STATUS file before executing any command.
N=
Do not reset the RCP STATUS file.
x=
The IPL indicator:
IPL =
RCP started as a result of an IPL and special processing must be performed.
o=
The options associated with RCP:
-2 =
The alternate STATUS file ADX_SDT1:ADXCSHAF.DAT is to be used for messages
generated by RCP. You can start RCP from an application using the ADXSTART
support. A separate STATUS file from the remote RCP applications and the local
RCP applications is available on the remote command processor. When you use the
-2 parameter, RCP creates the file ADX_SDT1:ADXCSHAF.DAT when RCP starts.
It is recommended that you use the STATUS file reset parameter on the RCP command to reset
the STATUS file. Set the status reset indicator to N on commands that are in the COMMAND
file. By entering Y for the STATUS file reset parameter in the COMMAND file, you erase the first

record that RCP writes into the STATUS files. The last record is logged telling you when RCP
ended.
For more information on starting RCP, see “Starting RCP” on page 125.
Re-IPL Command
This command is used to re-IPL all terminals, re-IPL one or all store controllers, cold boot a store
controller, or dump and reload a store controller.
Format
ADXCS20L i n
Where:
i=
STATUS file reset indicator:
Y=
Reset the RCP STATUS file before the command executes.
N=
n=
re-IPL request:
11 =
Re-IPL all terminals.
13 =
Reload store controller executing the RCP request.
14 =
Reload all store controllers on LAN system.
16 =
Cold boot store controller executing the RCP request.
17 =
Dump and cold boot store controller executing the RCP request.
Example
ADXCS20L Y 14
This command reloads all store controllers on the LAN if the command is executed at the master
store controller.
Remote STC Command

This command is used to remotely load the active terminal configuration for one or all terminals.
This command requests one or more terminals to reload the configuration data for their
previously loaded terminal number and does not perform other STC functions, such as
formatting the hard drive. This command will perform a cold boot of the terminal after applying
the active terminal configuration.

Format
ADXCS20L i n t
Where:
i=
Y=
N=
n=
Remote STC Request on:
12 =
all terminals
15 =
specific terminal
t=
Terminal number - applicable only when using 15 (specific terminal).
Example
The following command requests that Remote STC be run in terminal 34.
ADXCS20L Y 15 34
The following command requests that Remote STC be run on all terminals.
ADXCS20L Y 12
Dump Formatter Command

This command formats an existing dump into a report file.
Note: The Dump Formatter command does not cause or start a dump. It only formats an already
existing dump into a report file.
Format
ADXCSL0L i n
Where:
i=
Y=
N=

n=
Type of dump to be formatted:
1=
Terminal dump.
2=
Store controller dump.
Example
ADXCSL0L Y 2
This command resets the RCP STATUS file and requests that a store controller dump be
formatted in the report file named ADX_SDT1:ADXCSLRF.DAT.
Trace Commands
Trace commands are available for the collection of System Trace Data and Performance
Monitoring Data through RCP. Trace collection is available for the store controller hard disk
drive, Ethernet or device channel to aid in Problem Analysis. In addition, performance data may
be collected to understand utilization for key resources such as the hard disk drive, CPU or
device channel.. The COMMAND file contains the commands and parameters that initiate the
Start⁄Stop Trace. The format of the commands and parameters are described in the following
commands.
Note: System traces and performance traces are mutually exclusive.
Start⁄Stop Trace Command

When the system trace or performance is started, the data is collected in the file
ADXCSOHF.DAT. After you stop performance or the system trace, you can format the collected
data through the trace formatter using RCP.
Start Performance Command

This command starts the performance data collection for either a controller or a terminal. The
data is collected for a specified time. You can monitor terminals for up to 60 minutes, and you
can monitor controllers for up to 24 hours.
Format:
ADXCSQ0L i 1 t d
Where:
i=
Y=
N=
t=
Monitoring time for terminals in minutes (10 - 60). Monitoring time for controllers in
hours (0 - 24). t is a five-character starting time indicated as HH:MM, where:

HH =
Time in hours (0 - 24)
:=
Colon (:) or period (.)
MM =
Time in minutes (0 - 59)
d=
Device identification:
1–999
Terminal number in decimal
*
Controller
Note: You can use the HH:MM format only with controller monitoring. The device identification
must be an asterisk (*). The maximum time you can set is 24:00, and the time must be in the five-
character format. For example, 1:30 a.m. must be entered as 01:30 or 01.30.
Example 1
ADXCSQ0L Y 1 10 *
This command resets the STATUS file and requests performance monitoring for the store
controller for 10 minutes.
Example 2
ADXCSQ0L Y 1 30 23
This command resets the STATUS file and requests performance monitoring for terminal
number 23 for 30 minutes.
Example 3
ADXCSQ0L Y 1 24:00 *
This command resets the STATUS file and requests performance monitoring for the store
controller for 24 hours.
Format Performance Data Command

This command formats the data received from the Start Performance Data Command and stores
the data in the ADXCSPRF.DAT file in the ADX_SDT1 subdirectory.
Format
ADXCSP0L i b o st et
Where:
i=
Y=

N=
b
Available reports:
1=
All
2=
Disk
3=
CPU
5=
Device channel
o
Report style:
1=
Graph
2=
Raw utilizations
st
Five-character starting time in an HH:MM format. The default is to report all the data
collected.
HH =
Time in hours (9-24)
:=
Colon (:) or period (.)
MM =
Time in minutes (0-59)
et
Five-character ending time in an HH:MM format. This parameter is required if you select
a starting time.
Note: The first three parameters are required. et and st are only for reporting data that has
been collected for more than one hour.
Example 1
ADXCSP0L Y 1 2
This command resets the STATUS file and requests that the data for all devices for the entire
collection period be in a raw utilization format.

Example 2
ADXCSP0L Y 3 1 02:30 14:30
This command resets the STATUS file and requests that the data collected for the CPU from 2:30
a.m. until 2:30 p.m. be in a graphical output.
Start Trace Command for Hard Disk Drive

This command collects trace data for hard disk drive.
Format:
ADXCSQ0L i 2 p w
Where:
i=
Y=
N=
p=
Trace type:
2=
Disk
w=
Wrap character:
Y=
Wrap when trace full.
N=
No wrap; stop tracing when trace is full.
Example
ADXCSQ0L Y 2 2 Y
This command resets the STATUS file and collects trace data for the hard disk drive, wrapping
when the trace is full.
Start Trace Command for Device Channel

This command collects trace data for the device channel.
Format:
ADXCSQ0L i 2 4 d w
Where:
i=

Y=
N=
d=
1–999
w=
Wrap character:
Y=
Wrap when trace full.
N=
Example
ADXCSQ0L Y 2 4 15 N
This command resets the STATUS file and starts a trace for the device channel for terminal 15,
stopping the trace when the trace is full.
Start Trace Command to Start All Traces

This command starts the collection of all trace data.
Format
ADXCSQ0L i 2 * d w
Where:
i=
Y=
N=
Do not reset STATUS file.
d=
Device identification for device control
1–999
w=
Wrap character:

Y=
Wrap when trace is full.
N=
Example
ADXCSQ0L N 2 * 777 Y
This command starts a trace for the device channel for terminal number 777 and wraps when the
trace is full. This example does not reset the STATUS file.
Start Ethernet Trace Command

This command starts an Ethernet trace.
Format
ADXCSQ0L i 2 6 f w
Where:
i=
Y=
N=
f=
Change configuration option parameter:
1=
Any Service Access Point (SAP)
2=
Terminal Controller Communications (TCC)
Note: See the following section for tracing Terminal Controller Communications
(TCC).
4=
NetBIOS
5=
TCP/IP
7=
Specific SAP value
Note: See the following section for tracing a Service Access Point (SAP).
w=
Wrap character:

Y=
N=
Stop tracing when the trace is full.
Ethernet Trace (TCC)

Format
ADXCSQ0L i 2 6 2 d w
This command starts an Ethernet trace for an Ethernet TCC.

Where:
i=
Y=
N=
d=
1–999
= Terminal Number in decimal
w=
Wrap character:
Y=
N=
Ethernet Trace Service Access Point (SAP)

This command starts an Ethernet trace for a Service Access Point.
Format
ADXCSQ0L i 2 6 7 s w
Where:
i=
Y=

N=
s=
Service Access Point (2 hex digits):
EB =
TCC
F0 =
NetBIOS
AA =
TCP IP
xx =
any other specific SAP value.
w=
Wrap character:
Y=
N=
Example
ADXCSQ0L Y 2 6 7 AA N
This example has a Service Access Point value of AA and the trace stops when it is full.
If starting the trace generates any messages, they can be viewed by checking the contents of the
STATUS file ADX_SDTI:ADXCSHSF.DAT.
Stop Performance Command

This command stops the collection of performance data.
Format:
ADXCSQ0L i 3
Where:
i=
Y=
N=

Stop Trace Command
This command stops a system trace.
Format
ADXCSQ0L i 4
Where:
i=
Y=
N=
Trace Formatter Command

This command formats system trace data into a report file.
Note: This command does not start a trace. It only formats existing trace data into a report file.
Format
ADXCSM0L i t d: [ f [a] ]
Where:
i=
Y=
N=
t=
Type of trace to be formatted:
1=
All
3=
Disk
5=
Device channel
7=
Ethernet
d: =
Optional. Disk ID when the type of trace to be formatted is a disk. If this parameter is not
specified, the output defaults to the C: disk drive.

Note: An * can be specified to format all disk trace entries.
f=
Type of output file to be created. If this parameter is not specified, the output defaults to
formatted output. The formatted output file contains only one report. This parameter is
optional.
F=
Formatted system trace report file (ADX_SDT1:ADXCSMTF.DAT), or Performance
monitor report file (ADX_SDT1:ADXCSPRF).
U=
Unformatted trace report file (ADX_SDT1:ADXCSMUF.DAT).
a=
Action to be performed on the trace file. If this parameter is not specified, the output file
contains only one report. This parameter is optional.
-A =
Append the output trace report file to the current trace output file.
Example
ADXCSM0L Y 3 D: F
This command resets the RCP STATUS file and requests the D: disk trace entries to be formatted
to the report file named ADX_SDT1:ADXCSMTF.DAT.
File Management Command for Trace Output Data Files

Two output files locate system trace data:
• The formatted report file (ADX_SDT1:ADXCSMTF.DAT)
• The file containing unformatted trace entries (ADX_SDT1:ADXCSMUF.DAT)
Two questions need to be answered about the output files to support trace formatting:
1. Do you want to append data to the end of the current output files?
2. Do you want to erase data in the output files before writing to them?
To save the current data and append new data into the current output files, do not use the file
management command. To erase the data from either of the current output files, use the file
management command for trace output files.
The file management command enables you to identify the output file and the action to take on
the file.
Format
ADXCSM0L i 8 f o
Where:
i=
Y=

N=
f=
Format of file:
F=
Formatted system trace report file (ADX_SDT1:ADXCSMTF.DAT).
U=
Unformatted file (ADX_SDT1:ADXCSMUF.DAT).
o=
Current data status:
A=
Append
B=
Erase
Note: The command must have the p, f, o parameters or it is treated as a trace formatter
command attempt.
Examples of Trace Formatter Command

This section contains several examples. The examples show how you can tailor the trace
formatter command for the needs of your enterprise.
Example 1
Command Explanation
Erases the unformatted output file and writes an empty header
record to the output file.
ADXCSM0L Y 8 U B
Copies any ethernet trace data in the ADXCSOHF.DAT file into

the ADX_SDT1:ADXCSMUF.DAT file.
ADXCSM0L N 7 U
Writes the disk trace data to the unformatted output file

(ADX_SDT1:ADXCSMUF.DAT).
ADXCSM0L N 3 U
After the disk trace data is written to the unformatted output file, the header record is updated.
The header record in the unformatted output allows you to format the unformatted data file.
Typically, the host retrieves this file and transmits it to a master 4690 store controller. After
erasing existing trace data files, the file can be renamed to ADXCSOHF.DAT, and you can use
the screen interface to format the trace data collected in this file.
The unformatted file has no size restrictions. The traces are appended and can be processed later.
If more than one type of trace is in the unformatted file, you can process all or selected traces.
For example, you can process all disk trace entries in the order they were added to the file.
Example 2
Command Explanation
Erases the data in the formatted output file
ADX_SDT1:ADXCSMTF.DAT.
ADXCSM0L Y 8 F B

Command Explanation
Formats any ethernet trace data and places it in the formatted
output file.
ADXCSM0L N 7 U
Formats any disk trace data and appends it to the formatted

output file.
ADXCSM0L N 3 F
System Log Formatter Command

This command enables you to format the system log. You specify which errors or events you
want reported and the date and time interval.
Format
ADXCSN0L i b sd st ed et c t s [r]
Where:
i=
Y=
N=
b=
The log you choose to be reported and the format type:
• Short formats:
1=
Store controller hardware errors
2=
Terminal hardware errors
3=
Terminal events
4=
Store controller events
5=
System events
6=
Application events
7=
Format all sections 1 through 6
• Long formats:
A=
Store controller hardware errors

B=
Terminal hardware errors
C=
Terminal events
D=
Store controller events
E=
System events
F=
Application events
G=
Format all sections A through F
sd =
8-character starting date in the format mm⁄dd⁄yy
mm =
Month (01 - 12)
dd =
Day of the month (01 - 31)
yy =
Year (00 - 99):
86 to 99 =
1986 to 1999
00 to 85 =
2000 to 2085
st =
5-character starting time in the format HH:MM:
HH =
Hour (00 - 23)
MM =
Minute of the hour (00 - 59)
ed =
Ending date, in the format mm⁄dd⁄yy
et =
Ending time, in the format HH:MM
c=
Store controller ID:

CC - ZZ =
Store controller ID
*=
All store controller IDs. This value is valid if the section of the system log being
reported is store controller related.
If the section of the system log is terminal-related, this field is ignored.
t=
Terminal ID:
1 to 999 =
Terminal IDs in decimal
*=
All terminal ID. This value is valid if the section of the system log being reported is
terminal-related.
If the section of the system log is store controller-related, this field is ignored.
s=
Source number:
001-127 =
Source numbers
*=
All source numbers
See the TCx Sky Messages Guide for source numbers and their descriptions.
r=
Type of output to be acted on. If this parameter is not coded, the formatted output file
contains only this report. This is an optional parameter.
1=
Format report into new output file (ADX_SDT1:ADXCSNRF.DAT).
2=
Append formatted report to current output file.
3=
Put unformatted data into new output file (ADX_SDT1:ADXCSNUF.DAT).
4=
Append unformatted report to current output file.
Example
ADXCSN0L N 4 11⁄12⁄86 14:00 11⁄17⁄86 14:00 * * *
This command requests a system log report for store controller events from all sources. The
example requests the report to cover events beginning at 2:00 p.m. on 11⁄12⁄86 (November 12,
1986) and ending at 2:00 p.m. on 11⁄17⁄86 (November 17, 1986). The report is formatted into the
file named ADX_SDT1:ADXCSNRF.DAT.

File Management Command for System Log
You can create two types of output files:
1. Formatted Report File (ADX_SDT1:ADXCSNRF.DAT)
2. Unformatted Report File (ADX_SDT1:ADXCSNUF.DAT)
A system log formatter command can create the output files by appending data or by erasing
data. If you want to append data to the end of an output file, the file management command is
optional. The formatting command defaults to append data to the existing output file.
If you want to erase the current data in an output file before issuing the formatting command,
you should run the file management command. The file management command enables you to
identify the output file and the action to take with the file.
If you do not use the file management command to clear the output files, options of the system
log formatter command allow you to perform the same task.
Format
ADXCSN0L i 8 r z
Where:
i=
Status reset indicator:
Y=
N=
r=
Output file to be affected:
F=
Formatted output file (ADX_SDT1:ADXCSNRF.DAT)
U=
Unformatted data output file (ADX_SDT1:ADXCSNUF.DAT)
z=
Action for the output file:
A=
Append data to output file (do not reset the output file)
B=
Reset the output file (erase existing data in file)
Examples of System Log Formatter Command

This section contains several examples. The examples show how you can tailor the system log
formatter command for the needs of your enterprise.

Example 1
ADXCSN0L Y 8 F B
ADXCSN0L N 1 02⁄24⁄87 12:00 02⁄25⁄87 12:00 * * * 2
ADXCSN0L N 3 02⁄24⁄87 12:00 02⁄25⁄87 12:00 * * * 2
ADXCSN0L N 5 02⁄24⁄87 12:00 02⁄25⁄87 12:00 * * * 2
This example creates a formatter report file that contains only the data from the store controller
hardware log, terminal event log, and the system event log. The three reports in this example are
appended to the existing formatted report file.
Example 2
ADXCSN0L Y 8 U A
ADXCSN0L N 1 02⁄24⁄87 12:00 02⁄25⁄87 12:00 * * * 4
ADXCSN0L N 3 02⁄24⁄87 12:00 02⁄25⁄87 12:00 * * * 4
ADXCSN0L N 5 02⁄24⁄87 12:00 02⁄25⁄87 12:00 * * * 4
This example keeps the data previously contained in the unformatted output file. The last three
commands append the unformatted data from the store controller hardware log, the terminal
event log, and the system event log to the existing unformatted output file.
Example 3
ADXCSN0L N 1 02⁄24⁄87 12:00 02⁄25⁄87 12:00 * * * 2

ADXCSN0L N 3 02⁄24⁄87 12:00 02⁄25⁄87 12:00 * * * 2
ADXCSN0L N 5 02⁄24⁄87 12:00 02⁄25⁄87 12:00 * * * 2
When the file management command is not used, as in this example, the resulting formatted
report file contains the data previously in the file. These commands append the reports for the
store controller hardware log, terminal event log, and the system event log to the existing
formatted output file.
Configuration Activation Command

This command begins activation of the configuration specified by the user-provided parameter.
Format
ADXCSC0L i x y
Where:
i=
Y=
N=
x=
Change configuration option parameter:
4=
Activate configuration. All other values are invalid.
y=
Activation configuration option parameter:

1=
Terminal configuration
2=
Controller configuration
3=
System configuration
Example
ADXCSC0L Y 4 2
This example command causes the store controller to attempt activation of the controller
configuration files.
Error checking exists to verify the number and the values of the parameters that were passed to
the controller. If this activation of the configuration causes any messages, they can be viewed by
checking the contents of the STATUS file ADX_SDT1:ADXCSHSF.DAT.
Configuration Data Formatter Command

This command creates reports on the configuration of your terminals, controllers, and system.
When reporting on store controller configuration, the report contains information on the
controller that performed the command. To obtain controller configuration information for a
specific store controller on a LAN system, you must instruct RCP to run the command on the
store controller of interest. For example, you have a two-controller LAN system with nodes CC
and DD. Node CC has the host line attached to it. To obtain controller configuration information
for node DD, your RCP COMMAND file must contain this command:
DD::ADXCSD0L N 3 1
Format
ADXCSD0L i n s [a]
Where:
i=
Y=
N=
n=
Type of configuration reported:
1=
All of configuration

3=
Controller configuration
4=
System configuration
2 or 5 =
Terminal configuration
s=
Configuration status:
1=
Active configuration
2=
Inactive configuration
a=
Action to perform on the output file. If this parameter is not coded, the configuration
report output file contains only this report.
-A =
Append report to current output file.
Example
ADXCSD0L Y 3 1
ADXCSD0L N 2 2 -A
This example creates a formatted report file that contains the data for the store controller and
terminal configurations. The command saves the report in the file named
ADX_SDT1:ADXCSDTF.
The report will be saved in the file named ADX_SDT1:ADXCSDTF.DAT.
Report Module Level Command

This command creates module-level reports for the operating system and system applications.
Format
ADXCSS0L i n [f]p [f]p [f]p
Where:
i=
Y=
N=

n=
Report type:
1=
Product Summary Report
2=
Complete report with module integrity (checksum)
3=
Complete report without module integrity (no checksum)
4=
Module-level APAR report
5=
APAR search
6=
Installed features report
A checksum is an operation performed on each module to ensure that the module has not
been changed since it was first placed on the 4690 store controller by ASM.
f=
Product being reported. The letter f is the fifth letter of the Product Control File name,
ADXCfTpD.DAT.
Note: If the f is missing, S is assumed to be the fifth letter.
p=
Product being reported. The letter p is the seventh letter of the Product Control File name,
ADXCfTpD.DAT.
Note: The combination of f and p are used to determine the product. ADXCSTSD.DAT
reports on the base operating system.
Some examples are:
G=
4690 Application Program Product (General Sales, Supermarket, or Chain Drug
Application)
P=
Price Management Feature for the General Sales Application
S=
Operating System
B=
4690 Optionals
You can include a maximum of 21 installed products. If you want to include products other than
those shown, you must create a Product Control File for each product.
Example 1
ADXCSS0L Y 3 S

This command resets the RCP STATUS file and requests a module-level report for the operating
system, with no checksum operation to be performed. The command saves the report in the file
named ADX_SDT1:ADXCSSDF.DAT.
Audible Alarm Commands

This section describes the commands for issuing audible alarms.
Activate Command for a LAN System

This command activates audible alarms for a LAN system.
Format
ADXCS10L i 3 t c [s]
Where:
i=
Y=
N=
t=
Length of time the alarm is sounded.
1 - 99
= Number of seconds in decimal.
*=
Sound continuously. If the coded value is not valid, the default of “*” is used.
c=
Store controller ID. Must be present in LAN system as valid ID or *. No default is
assumed.
s=
System message:
-Y =
Use the configured severity level for the system message display panel and the
message number to determine if the message is to be alarmed.
-N =
Use only the message number to determine if the message is to be alarmed. This
value is the default.
The default is used if the coded value is not valid.
Activate Command for a Non-LAN System

This command activates audible alarms for non-LAN systems.
Format

ADXCS10L i 3 t [s]
Where:
i=
Y=
N=
t=
Length of time the alarm is sounded.
1 - 99
= Number of seconds in decimal.
*=
Sound continuously. The asterisk (*) is the default.
s=
System message:
-Y =
Use the configured severity level for the system message display panel and
the message number to determine if the message is to be alarmed.
-N =
Use only the message number to determine if the message is to be alarmed.
This value is the default.
Examples of an Audible Alarm Command for a LAN System

Example 1
ADXCS10L Y 3 10 *
In this example, the activate command resets the STATUS file and causes a 10-second alarm for
all store controllers in the system for any messages in the alarm message files. The system
message severity level is ignored because the optional parameter is not present (defaults
selection to -N).
Example 2
ADXCS10L Y 3 * * -Y
In this example, the activate command resets the STATUS file and causes a continuous alarm for
all store controllers in the system for any messages meeting the system message severity level
because the optional parameter -Y indicates YES for message level selection.
Example 3
ADXCS10L Y 3 10 EE -Y

In this example, the activate command resets the STATUS file and causes a 10-second alarm for
controller ID EE’s messages meeting the system message severity level because the optional
parameter -Y indicates YES for message level selection. No other controller’s audible alarm
function is affected.
Examples of an Audible Alarm Command for a Non-LAN System

Example 1
ADXCS10L Y 3 20 -N
In this example, the activate command resets the STATUS file, causes a 20-second alarm, and
sets the message level selection to NO. The system message severity level is ignored.
Example 2
ADXCS10L Y 3 * -Y
In this example, the activate command resets the STATUS file, causes a continuous alarm and
sets the message level selection -Y to YES. Only messages meeting the system message severity
level sound the alarm.
Example 3
ADXCS10L N 3 2
In this example, the activate command appends to the STATUS file and causes a 2-second alarm
for messages in the audible alarm file. The system message severity level is ignored (selection
defaulted to -N).
Example 4
ADXCS10L Y 3 *
In this example, the activate command resets the STATUS file and causes a continuous alarm for
all messages in the audible alarm message file. The default for message level (option not present)
selection is -N.
Example 5
ADXCS10L Y 3 10 DD -Y
This example illustrates an incorrect store controller ID. This command resets the STATUS file,
causes a 10-second alarm, and activates the audible alarm function in a LAN system store
controller with a valid ID of DD. For this example, a store controller DD does not exist, so the
command fails.
Deactivate Command
This command deactivates the audible alarm command.
Format
ADXCS10L i 4 [c]
Where:
i=

Y=
N=
c=
The store controller ID to deactivate:
CC - ZZ
= Store controller ID.
*=
All store controllers. This optional parameter is valid for multiple store controller
systems only.
Example
ADXCS10L Y 4 *
This command resets the RCP STATUS file and deactivates the audible alarm on all store
controllers.
Report Audible Alarm Status Command

This command creates a report showing the audible alarm status for store controllers.
Format
ADXCS10L i 2 [c]
Where:
i=
Y=
N=
c=
Store controller ID whose audible alarm status is to be reported:
CC - ZZ
= Store controller ID.
*=
All store controllers. This optional parameter is valid for multiple store controller
systems only.
Example
ADXCS10L Y 2 *

This command resets the RCP STATUS file and runs the report for all store controllers (the
report is in ADX_SDT1:ADXCS1RF.DAT).
Apply Software Maintenance Command

This command applies software maintenance to the operating system or system applications.
See the TCx Sky User's Guide for more information on the Apply Software Maintenance (ASM)
command.
Format
ADXCST0L i a[f]p ... a[f]p [TL] [BY] [NI]
Where:
i=
Y=
N=
a=
Action to be performed on the product:
1 or TST
= Test
2 or CNL
= Cancel
3 or ACC
= Accept
Note: For this parameter, you can use all numeric characters, all alphabetic characters, or
both. For example, you can use 1 to test and CNL to cancel in the same command.
f=
Product being activated. The f is the fifth letter of the Product Control File name. The
Product Control File for a product is found on the product’s master installation or
Corrective media under the format ADXCfTpD.DAT.
Note: If the f is missing, S is assumed to be the fifth letter. The S indicates that the report
module level assumes the maintenance is in ADX_SMNT (the system maintenance
subdirectory) unless otherwise specified.
p=
Product being activated. The p is the seventh letter of the Product Control File name. The
Product Control File for a product is found on the product’s master installation or
Corrective media under the format ADXCfTpD.DAT.
Note: The combination of f and p are used to determine the product. ADXCSTSD.DAT
reports on the base operating system.
Some examples are:

G=
4690 Application Program Product (General Sales, Supermarket, Store
Management, or Chain Drug Application)
P=
Price Management Feature for the General Sales Application
S=
Operating System
B=
4690 Optionals
If you want to include products other than those shown above, you must create a Product
Control File for each one. You cannot perform two actions on the same product in the
same parameter list.
TL =
Terminal load indicator. You can cause all terminals to be reloaded upon completion of
ASM by including the terminal load indicator, TL, in the command. The TL can be in any
position after the STATUS file reset indicator.
BY =
Bypass LAN problems indicator. You can optionally bypass LAN problems detected by
ASM by including the bypass indicator, BY, in the command. BY can be in any position
after the STATUS file reset indicator.
NI =
No IPL indicator. You can optionally get ready for the activation of the maintenance by
including the no-IPL indicator, NI, in the command. Checksums are verified,
maintenance is distributed, and the activation file is built. All that remains to activate the
maintenance is a manual IPL of the controller.
Example 1
ADXCST0L Y 1S 2G TL
This command resets the RCP STATUS file, puts the product indicated by Product Control File
ADXCSTSD.DAT into TEST mode, cancels the maintenance for the product named by the
Product Control File, ADXCSTGD.DAT, and reloads all terminals.
Example 2
ADXCST0L Y TSTS CNLG TL
This command resets the RCP STATUS file, puts the product indicated by the Product Control
File, ADXCSTSD.DAT, into test mode, cancels the maintenance for the product named by the
Product Control File, ADXCSTGD.DAT, and reloads all terminals.
SkyCheck Command
If you are migrating from 4690 OS V6R4 or V6R5 there are a number of TCx Sky prerequisites
regarding supported machine types, configuration options and resource requirements. The
SkyCheck tool is provided on the migrate CD/DVD to check for the most common problems that
may occur during OS migration.

Load All Terminals Command
This command enables you to load all terminals in your store. After maintenance on
applications, terminals should use new modules and files. Terminals must be reloaded to do
this. You can use this function to reload all terminals in a remote environment or if you do not
have operators working near your store controllers.
Note: The RCP STATUS file, (ADX_SDT1:ADXCSHSF.DAT) contains the completion status of
the command. The status does not include the terminal IDs of the terminals that have been
reloaded.
Format
ADXCS20L i n
Where:
i=
Y=
N=
n=
Request system function. A value of 11 specifies that all terminals will be loaded.
Example 1
ADXCS20L Y 11
This command resets the RCP STATUS file before the system function is started. The requested
system function is Load All Terminals.
On a system with the Multiple Controller Feature installed and running, terminals attached to
each store controller can be loaded. For example, the terminals are attached to store controller
CC and DD in a three-controller system. Controller EE is the store controller attached to the host
line. You would send a COMMAND file containing the following:
CC::ADXCS20L Y 11
DD::ADXCS20L N 11
This COMMAND file would cause RCP to start the Load All Terminals program on the store
controllers whose ID precedes the function name. The terminals attached to store controller CC
and DD are loaded.
Loading terminals in a LAN environment is needed to support all terminals. ADXCS20L support
only loads those terminals attached to the store controller where ADXCS20L is running.
Example 2
DD::ADXCS20L N 11
This COMMAND will cause RCP to start the Load All Terminals program on the store controller
whose ID precedes the function name. All of the terminals that are reachable via the LAN by the
DD controller will be reloaded. This example does not reset the RCP STATUS file.

Remote Set Terminal Characteristics Command
The function can also be started from the host. It is performed by the Remote Set Terminal
Characteristics command to change a terminal configuration. You can send terminal
configuration files from the host to the store controller as maintenance to be applied with ASM.
Then, you can start the Remote Set Terminal Characteristics command from the host.
Each terminal to be reconfigured must be assigned a terminal number. The Remote Set Terminal
Characteristics application runs when the command is accepted at the store controller. Any
terminal applications are stopped at this time. When Remote Set Terminal Characteristics begins
to run, Z100 is displayed on the terminals. If the command completes without errors, all
terminals reload with the new configuration.
However, if there are serious errors (for example, an error writing to hard totals) the manual
entry Set Terminal Characteristics is loaded on the terminals with errors and the operator must
run the Set Terminal Characteristics command manually on the partner terminal. For other
errors, the default applications are loaded and a message is logged in the system message file
indicating the type of error encountered. You can fix the problem and send the request again
from the host.
Note: If a partner terminal is also to be configured, it must be powered on at the time when the
Remote Set Terminal Characteristics command is issued. If it is not powered on, the device
group records are configured, but the default application is not configured.
The Remote Set Terminal Characteristics command enables a user to reconfigure terminals from
the host.
Format
ADXCS20L i 12
Where:
i=
Y=
N=
Do not reset STATUS file.
Example
ADXCS20L Y 12
This command resets the RCP STATUS file before the system function is executed. The requested
system function is the Remote Set Terminal Characteristics.
Note: This command must be executed at the master store controller.
Set System Time and Date Command

This function enables an application to set the system-wide date and time. Changes made using
this function are broadcast to all controllers and all terminals within the store system.
Format
ADXCS80L i
Where:

i=
RCP STATUS file reset indicator, BACKGRND, or blank.
Y=
Reset the RCP STATUS file and write output there.
N=
Do not reset RCP STATUS file but write output there.
BACKGRND
Running in background (no output).
"blank"
Running in foreground (Command Mode) with output to the console.
command
One or more of the following separated by spaces:
+1
Increment the current time by one hour.
-1
Decrease the current time by one hour.
-B
Broadcast current time without altering.
-Q
No output (quiet mode).
-T HHMMSS
Change the current time to HHMMSS.
-D YYMMDD
Change the date to YYMMDD.
Note: This comment will run only on the master controller if on a multiple controller network.
Some commands are mutually exclusive (+1, -1, -B, -T) and only the last command is recognized.
You must set the time if you set the date (that is, -D requires the -T). The order of the commands
is not important. All of the commands implicitly broadcast their changes; you do not need to
manually broadcast the time after making a change. You should use +1/-1 wherever possible to
avoid inherent delays with setting the time directly. The system date and time can also be set
using the system functions menu option. See the TCx Sky User's Guide for details on using this
method.
Example
ADXCS80L Y +1
This command resets the RCP STATUS file and increments the current time by one hour. By
default, the output of this application includes the time before execution and the time after
execution if one of the parameters should cause the time to change.
File Compression⁄Decompression Command

Two files are associated with file compression and decompression:

• An alternate STATUS file that you can use instead of the RCP STATUS file
• A file containing the processing file name messages
You can specify that the alternate STATUS file, ADX_SDT1:ADXCSHAF.DAT, be used when the
application using the ADXSTART function starts file compression. The alternate STATUS file
allows the messages produced by file compression to be placed in the secondary STATUS file.
For more information on starting RCP, see “RCP Commands” on page 86.
The processing messages are logged in the ADX_SDT1:ADXCS3PF.DAT STATUS file instead of
in the RCP STATUS file. In a LAN environment, the STATUS file is a local file on the store
controller that runs file compression.
The processing message file is reset when the STATUS file reset parameter is either Y or N. Any
other value for the STATUS file reset parameter causes new messages to be appended to the
existing RCP STATUS file. RCP pulls this file to the master as a report at the end of processing.
Format
ADXCS30L i n f s [d] [2]
Where:
i=
Y=
N=
n=
Selects the options:
1=
File compression
2=
File decompression
f=
Type of files requested:
1=
Single file or wildcard (*) files
2=
File named in the source is a list file (see “List File Format for File
Compression⁄Decompression” on page 119 for details)
3=
Source is a subdirectory
4=
Source is a disk drive
s=
Source file specification:

• For single files, you must specify the drive, subdirectory, file name, and optional file
extension. The file name and optional file extension can have wildcards. Logical
names are acceptable.
• For a list file name, this specification must conform to the single file requirements.
Wildcards are not acceptable when the list file name is given. See “List File Format for
File Compression⁄Decompression” on page 119 for details.
• For a subdirectory, you must specify the drive and subdirectory. Logical names are
acceptable.
• For a hard disk drive, the drive letter followed by a colon (:) is required.
• When using option 4 on the f parameter (the source is a disk drive), the s parameter
must contain a drive letter followed by a colon.
Note: You can specify a node name. If you do not specify a node, the local node ID is
assumed.
d=
Destination file specification:
Valid ways of identifying the destination files are:
• When the source is a file name, the destination can be one of the following:
• Not specified
• Drive
• Drive and subdirectory
• Drive, subdirectory, file name, and optional file extension
• Subdirectory
• Subdirectory, file name, and file extension
• When the source is a list file name, you cannot specify a destination. Any destination
you specify is ignored. See “List File Format for File Compression⁄Decompression” on
page 119 for details.
• When the source is a subdirectory, the destination must be one of the following:
• Not specified
• Drive
• Subdirectory
• When the source is a drive, the destination must be one of the following:
• Not specified
• Drive
• When the destination is not specified, the destination is the same as the source.
assumed. Logical names are acceptable.
Note: System limitations prevent using more than 46 characters for parameters on programs
started using RCP. Therefore, if the parameters for a compression⁄decompression operation
exceed 46 characters, use one of the following methods to shorten the command line:
• Use logical names for source and destination file names.
• Use a list file containing the parameters (which can exceed 46 characters) and possibly
containing more than one request.
Example 1
ADXCS30L N 1 3 C:\ADX_IPGM C:\BACKIPGM

This command compresses all files in the ADX_IPGM subdirectory on the C: drive and places
the compressed files into the BACKIPGM subdirectory on the C: drive. If the BACKIPGM
subdirectory does not exist, it is created.
List File Format for File Compression⁄Decompression

The list file can be built using any editor, including the DREDIX editor available on the operating
system. Each entry in the list file must have the following format:
Format
f s [d] cr-lf
Where:
f=
Indicates the type of files requested:
1=
Single file or wildcard files are requested.
3=
The source is a subdirectory.
4=
The source is a disk drive.
If 2 is specified, an error results and processing continues with the next entry in the list
file.
s=
The source file specification:
• For single files, you must specify the drive, subdirectory, file name, and optional file
extension. The file name and file extension can have wildcards. Logical names are
acceptable.
• For a subdirectory, you must specify the drive and subdirectory. Logical names are
acceptable.
• When using option 4 on the f parameter (the source is a disk drive), the s parameter
must contain a drive letter followed by a colon.
Note: A node name can be specified. If no node is specified, the local node ID
assumed.
d=
The destination file specification.
Valid ways of identifying the destination file are:
• When the source is a file name, the destination must be one of the following:
• Not specified
• Drive
• Drive, subdirectory, file name, and optional file extension
• Subdirectory
• Subdirectory, file name, and optional file extension
• When the source is a subdirectory, the destination must be one of the following:

• Not specified
• Drive
• Subdirectory
• When the destination is not specified, the destination is the same as the source. Logical
names are acceptable.
assumed.
cr-lf =
Delimiters that indicate the end of an entry in the list file. These are the carriage return
and line feed characters in ASCII. Most editors place these characters in the file when you
press the Enter key.
The end of file (EOF) character is optional at the end of the list file.
Problem analysis data compression command

This command enables you to capture problem analysis data to a hard disk drive. The data is
compressed in the zip format.
Create Problem Analysis data (CPAD) also uses list files to collect files. The OS provided list file,
ADX_SDT1:ADXCSRXL.DAT contains a list of files to be collected. Users must not modify this
file. It may be overwritten during future OS migrations and upgrades. Users may collect files by
creating the file, ADX_IDT1:ADXCSRUL.DAT.
Format of ADXCSRUL.DAT file:
• Wildcards (*) and (?) in file entries are supported
• Logical names in file entries are supported
• The file entries are treated as optional
• All errors received when attempting to open the files in the list are ignored
• The files are collected whenever CPAD is run
Several (optional) flags may be appended after the filename to change the behavior of the CPAD
program. These flags must be separated from the filename (and other flags) with one or more
spaces. The allowed flags are as follows. Note that flags are case sensitive.
-s - Open the file in shared mode. By default the file is opened in a mode that prevents other
programs from writing to the file when it is being collected. Some files, particularly log files,
may be kept open all the time and also worth collecting even if they are modified during
collection. Using this flag allows CPAD to collect these files as well.
Note: If a program opens a file for exclusive access (preventing other programs from reading it
at all), CPAD will not be able to collect it.
A log of the files collected (and those skipped due to access or other errors) is written to the file
ADX_SPGM:ADXNSZZL.LOG. Invalid flags in ADXCSRUL.DAT will cause the CPAD program to
stop with an error with no output file generated. More details in this case may be found in
ADXNSZZL.LOG.
Example entries for ADXCSRUL.DAT:
c:\program.log
ADX_SPGM:*.LOG
ADX_IDT1:ADXCSHCF.*
ADX_IPGM:???TS10L.SYM
ADX_UPGM:*.SYM
f:/myProgram/Logs/* -s

An ordered list of compressed output files is logged in the problem abstract file,
ADX_SDT1:ADXCSRCF.DAT. This list uses HCP file naming conventions. The compressed files
in the list can be retrieved by a host site.
The problem abstract file also contains a summary of which reports and dumps were
compressed, along with a summary of any requested problem analysis data that was not found.
Compressed output files are written to the ADX_SDT1 directory with the format
ADXZxxxF.DAT. The xxx is a counter that starts with 000, and is incremented when an output
file reaches its maximum size. If you plan to use HCP, it is recommended that each output file be
one megabyte in size, reducing the amount of data to retrieve should a host transmission error
occur.
Problem analysis report commands must be used to direct report output to disk before starting
ADXCSR0L. System and performance trace files must be formatted before starting ADXCSR0L.
Format
ADXCSR0L i n [d] [e] [x]

Where:
i=
• Y = Reset the RCP STATUS file before the command executes.
• N = Do not reset the RCP STATUS file.
n=
Type of files selected:
1 - 63 = the sum f1+f2+f3+f4+f5+f6,
where each fn is selected from:
Not applicable
=0
System Log Report

=1
Terminal Dump
=2
Controller Dump
=4
System Trace Report

=8
Performance Report
= 16
Module Level Report

= 32
d=
Destination. This is an optional parameter:

• 4 = Hard disk drive C
• 5 = Hard disk drive D, or
• C: = Hard disk drive C
• D: = Hard disk drive D
e=
Compressed file size. This is an optional parameter:
• 1 = 1024 KB
• 2-9 = Maximum number of megabytes per each output file
• * = All outputs to one file
x=
Single keyword description for problem abstract. This is an optional parameter.
Example 1
ADXCSR0L Y 13 4 2 PMR56789
This example:
• Resets the RCP STATUS file
• Gathers the Controller Dump, System Log, and System Trace because 4 + 1 + 8 equals 13
• Compresses output files to the C: drive
• Each output file is no larger than 2048 KB in size
• Problem abstract file contains PMR56789 keyword
It is assumed that the System Log and System Trace were previously formatted using
ADXCSN0L and ADXCSM0L.
Example 2
ADXCSR0L N 16
This example:
• Does not reset the RCP STATUS file
• Gathers the Performance Report only
• Compresses output files to the default drive
• Each output file is no larger than the default size
• No keyword is placed in the problem abstract file
It is assumed that the Performance Report was previously formatted using ADXCSP0L.
Example 3
ADXCSR0L N 34 D: *
This example:
• Does not reset the RCP STATUS file
• Gathers the Module Level Report and Terminal Dump because 32 + 2 equals 34
• Writes output files to the D: drive
• Compresses all output to one large file
• No keyword is placed in the problem abstract file
It is assumed that the Module Level Report was previously formatted using ADXCSS0L.
Extract Store-Specific Configuration Command

This command extracts store-specific configuration data from active files. The data can then be
inserted into inactive files using the ADXSSC1L command. The extracted data is written to the

ADX_SPGM:ADXSSCDF.DAT file. After the initial execution of this command, you only need to
run this command again to update the store-specific configuration data. However, you can run
this command before each transfer of a configuration file.
Format
ADXSSC0L i
Where:
i=
Example
ADXSSC0L Y
This command resets the RCP STATUS file and extracts the store-specific data from the active
files and writes the data to ADX_SPGM:ADXSSCDF.DAT.
Insert Store-Specific Configuration Command

This command writes the store-specific configuration data that was extracted using the
ADXSSC0L command to the inactive files. This command enables you to transfer the same file to
several stores without having to modify it first for store-unique data.
Format
ADXSSC1L i
Where:
i=
Example
ADXSSC1L Y
This command resets the RCP STATUS file and writes the extracted store-specific data to the
inactive files.
Commands for Remote CMOS and BIOS Update

The following sections provide information on the commands for Remote CMOS and BIOS
Update.
Terminal CMOS update commands

The Terminal CMOS update function allows the user to save the CMOS settings from a pre-
configured source terminal and apply the saved settings to other target terminals. The Terminal
CMOS update commands are launched on the store controller using the existing 4690 Terminal
Application Loader (TAL) program (ADXTAL4L.286) and may be launched remotely using RCP
or directly from the command line. The Terminal CMOS Update function uses 2 new parameters
on the TAL program to launch the CMOS update programs as follows:
• adxtal4l.286 –S - to launch the Terminal CMOS save program
• adxtal4l.286 –U - to launch the Terminal CMOS update program

The Terminal CMOS Update commands are supported on TCxWave 6140 and TCx 300/700
Series terminals. The source and target systems for the CMOS settings must be the same model
number and BIOS level. Instructions for using the Terminal CMOS update commands are
described below.
The user configures the terminal number(s) for saving or applying the CMOS settings using the
TAL configuration file (ADXTALTF.DAT) in the C:/ADX_IDT1 directory. The ADXTALTF.DAT
file is configured with a list of terminal numbers, one per line, and can be created or modified
with a text editor.
The Terminal CMOS Save function (adxtal4l.286 -S) saves the terminal CMOS settings
from the terminal specified in the TAL configuration file in the following filename:
C:/ADX_SDT1/<machinetypemodel>.<biosversion>
Example
C:/ADX_SDT1/4900786.150
Note that this file will be saved on the controller that is CONTROLLING the terminal in an MCF
environment. The log file with the results of the CMOS Save function is saved in C:/
ADX_SDT1/TMCMOSSA.<terminal ID>.
The Terminal CMOS Update function (adxtal4l.286 -U) applies the CMOS settings from file
C:/ADX_SDT1/<machinetypemodel>.<biosversion> on the controller to the target
terminals identified in the C:/ADX_IDT1/ADXTALTF.DAT configuration file. The log file with
the results of the CMOS Update function is saved in C:/ADX_SDT1/TMCMOSUP.<terminal
ID>.
After updating the CMOS settings on a terminal, a cold boot is required on the terminal for the
CMOS settings to take effect.
For debugging purpose, there is one additional log file. The program ADXTAL4L.286 creates
ADX_SDT1:ADXTAL4F.DAT on the controller that contains information about each execution of
ADXTAL4L.286.
Note: The file will grow indefinitely. The user may erase the file as needed to control its size.
The following table explains some of the messages that are logged.
Table 5. Terminal CMOS Update Log File Entries

Message Explanation
Terminal ###: 0 This message indicates that the utility ran
against terminal ### and ended successfully.
Terminal ###: -1003 This message indicates that the utility ran
against terminal ### but the OS is unable to
obtain an event for this operation.
Terminal ###: -1170 This message indicates that the utility ran
against terminal ### and the program to be
executed in the terminal is missing from the
controller or invalid. Restore the TMCMOSSA.
386 & TMCMOSUP.386 files on the controller.
Terminal ###: -1081 Terminal ### did not respond.
Terminal number is not valid: ### The file C:\ADX_IDT1\ADXTALTF.DAT
contains invalid terminal number ###.
Could not open <DIRECTORY>:<FILENAME.EXT> does not
<DIRECTORY>:<FILENAME.EXT> exist.

Message Explanation
Invalid Parameters The application was called with invalid
parameters.
Controller BIOS Update commands

The Controller BIOS Update command (C:/ADX_SPGM/BIOSUPDT.386) reprograms the
controller BIOS to the level shipped with 4690. The command is supported on the SurePOS 700
Series model xx5, TCxWave 6140 Series except models 6140-100 and 6140-120, SurePOS 300
Series, and TCx 300/700 Series controller systems. The program is launched with the BIOSUPDT
command. It can be run via RCP or from a command line.
Table 6. Controller BIOS update return codes

Return code Description
0 No errors, user can expect that the requested operation
completed successfully (BIOS was updated with no errors, etc)
3 File error, use for file not found, read-only, etc.
4 Corrupted BIOS, firmware file, tool, etc.
5 Unsupported system
The new BIOS level will not be active until the next cold boot of the controller. The user must
perform the cold boot separately after executing this command.
The return code is provided in the RCP status file ADX_SDT1:ADXCSHSF.DAT. For debugging
purpose, there is one additional log file biosupdt.log provided on the F: drive.
Controller CMOS Update Commands

The Controller CMOS Update function allows the user to deploy the same CMOS settings from a
source store controller to other target controllers. The CMOS update is performed in 2 steps:
1. CMOSSAVE.386 - saves the CMOS settings from a source controller
2. CMOSUPDT.386 - applies the CMOS settings to a target controller
The commands may be launched remotely using RCP or directly from the command line. The
function is available on the SurePOS 700 Series 4900-785, 4900-745, 4900-C45, 4900-C85,
TCxWave 6140 Series except models 6140-100 and 6140-120, and TCx 300/700 Series controller
systems. The source and target systems must be the same model and running with the same
BIOS level. Details of the commands are described below.
The Controller CMOS Save command (C:/ADX_SPGM/CMOSSAVE.386) clones the CMOS
settings from the controller where it is executed and saves the generated CMOS settings file(s) to
a directory on the F drive (F:/adxetc/bios). The results of the command and the name of the
generated CMOS setting file(s) will be displayed on the console (if running on command line)
and logged in file cmossave.log on the F drive.
The Controller CMOS Update command (C:/ADX_SPGM/CMOSUPDT.386) applies the CMOS
settings generated from the CMOSSAVE command to a target controller. The CMOS settings file(s)
should be placed in directory F:/adxetc/bios on the target controller prior to launching the
CMOSUPDT command. After applying the new settings, a cold boot must be performed on the
controller for the settings to take effect.
Starting RCP
You can start RCP from an application program. If you are using a LAN system, RCP must be
run on the Master controller.

Starting RCP from an Application
You can also start RCP from an application. Consider the following when starting RCP from an
application:
• The application can update the RCP SELECTION file, ADX_IDT1:ADXCSHCF.DAT, with the
name of the RCP COMMAND file.
• The application can update or create the RCP COMMAND file in the ADX_IDT1
subdirectory.
• The application can issue the ADXSTART command to start RCP as a background job. No
parameters need to be passed to RCP.
• RCP opens the RCP STATUS file with exclusive access. This means that no application should
open the RCP STATUS file while RCP is running.
• The application can check whether RCP is running by opening the pipe, pi:ADXCSHEP. If the
return code indicates pipe not found, the RCP is not running and the application can check the
RCP STATUS file. If the return code indicates anything other than pipe not found, the
application should delay for a short time and try again.
Starting Applications Using RCP

Running applications in the operating system requires knowledge of how the system starts the
application and what items the application must consider to handle this mode of operation. This
section discusses each way applications can be started and the implications to the application
writer. This section applies only to applications running on a 4690 store controller. Terminal
applications are not addressed.
Starting Applications on the 4690 Store System

There are three ways to start applications on the 4690 Store System: command line, background,
and foreground.
Command line starting of an application occurs when you enter the name of the application to
run, along with any parameters, in Command Mode. Starting applications from within BAT files
has the same characteristics as starting applications from the command line.
Starting applications in the background can be done different ways. To start the applications in
the background, you can:
• Configure the applications to be started from the background control screen by pressing
SysRq and selecting option b.
• Start applications using ADXSTART from another application.
• Use RCP to start applications in the background.
Applications can also be started in the foreground. To start applications in the foreground, select
option 2 (secondary application) on the store controller MAIN MENU panel. Then, choose an
application to start. You must configure the applications listed on the secondary application
screen before you can start them.
Each method requires the application writer to consider unique characteristics. These
characteristics determine the way in which parameters are passed to the application and the type
of I/O available to the application.
Passing Parameters to Main Routines

In the operating system, parameters are placed in the environment table. C language
applications access this table through calls defined in the C language interface section of the TCx
Sky Programming Guide. CBASIC language applications access this information by using the
COMMAND$ function (the command tail).

The command tail has two strings:
• One contains the name of the application started
• One contains the parameters
Note: This is different from the ARGC, ARGV format that is common in C language
programming. Parameters coming into the main routine are always in ASCII format. This means
any number coming into the application as a parameter to the main routine must be converted to
a numeric data type by the application if it is needed for numeric operations.
Command Line Applications

Parameters are passed to the main routine of the application in the command tail when the
application is started from the command line.
For example, you can start an application named APPLX from the command line with the
following entry:
C:> APPLX PARM1 PARM2 PARM3 PARM4
The command tail string containing the name of the application would be "APPLX". The double
quotes are not part of the string; they show the extent of the string. The command tail string
containing the parameters would be:
"PARM1 PARM2 PARM3 PARM4"
Note: The number of spaces between parameters remains exactly as they were entered on the
command line. However, if the user entered several blank characters after the last parameter,
these spaces would not appear in the parameter list string.
Input can come from Display Manager screens or from the basic I/O functions of the
programming language in addition to the command tail. Output can go anywhere that the
application wants to direct it. Both the keyboard and the video display are available to the
application.
Background Applications
RCP Applications
As with 4680 or 4690 applications, parameters are passed in the command tail when the
application is started in the background by RCP. For example, you can start an application
named APPLY from RCP using the COMMAND file containing the following line.
APPLY PARM1 PARM2 PARM3 PARM4
The command tail string containing the name of the application would be "APPLY". The double
"BACKGRND PARM1 PARM2 PARM3 PARM4 "
The operating system inserts the BACKGRND parameter into the command tail. This parameter
is inserted at the beginning of the command tail parameter string to inform the application that it
was started in the background. This is important because background applications do not have
keyboards available for input and they do not have video screens available for output. However,
the background application does have a status line on the background status screen that you can
use to write messages.
Also, note that the number of spaces between parameters is reduced to one. RCP does this to
ensure the maximum number of characters are passed to the application because there is a 45-

character limit to the number of characters passed to the application when it is started in the
background. In the example above, part of PARM4 would not have been passed to the
application if the space reduction had not taken place.
Also, note that there is a space after the last parameter. If you entered several blank characters
after the last parameter, only one space would appear at the end of the parameter list string.
Return codes from applications are provided as either four-byte integers or hexadecimal error
codes that are significant in RCP because RCP will put the return code each application ended
with in the RCP STATUS file. RCP notes the return code from each application RCP starts and,
when RCP ends, it will end with the most negative return code from all of the applications RCP
started in one session. RCP does this because NetView Distribution Manager operating at a host
machine receives a return code from the 4690 store controller where RCP is operating. This
action allows a host application to react to failing return codes from an RCP session.
If an application ends successfully, the return code from that application must be zero for it to be
recognized as a successful execution. When an application ends before completing the function it
was supposed to accomplish, the application should end with a negative return code.
Background Control Screen Started Applications

Applications started from the background control screen are similar to applications started by
RCP. The only difference is that spaces between parameters are placed in the command tail
parameter string just as they were entered during configuration of the background control
screen applications. As with other 4680 or 4690 applications, parameters are passed in the
command tail when the application is started from the background control screen.
For example, you can start an application named APPLY from the background control screen
entry containing the following line:
APPLY PARM1 PARM2 PARM3 PARM4
The command tail string containing the name of the application would be "APPLY". The double
"BACKGRND PARM1 PARM2 PARM3 "
The operating system inserts the BACKGRND parameter into the command tail. This parameter
is inserted at the beginning of the command tail parameter string to inform the application that it
was started in the background. This is important because background applications do not have
keyboards available for input and they do not have video screens available for output.
Note that the spaces between parameters are maintained. In this example, the PARM4 parameter
would not be passed to the application because it is beyond the 45-character limit for
background application parameter lists.
Background applications cannot have screens or keyboards associated with them. This reduces
the possibilities for input and output. Input can only come from places not requiring an
interactive user (for example, disk files). Output cannot be placed on any screen.
RCP STATUS File

The RCP STATUS file name is ADXCSHSF.DAT. The file resides in the ADX_SDT1 subdirectory
and contains processing messages and error messages from each application that RCP started in
a run. The STATUS file is the main form of communication between you and the background
application. Each application that can be started in the background puts four types of messages
into the RCP STATUS file.
The first message type identifies the application that is running and the parameters passed into
the application. The format of this entry is:
• tt:tt:tt (the time)

• RUNNING
• application
• parameters passed to application
The time field contains hours, minutes, and seconds. This entry is consistent with the same entry
placed in the RCP STATUS file by the 4680/90 system applications.
The second message type is a processing message. Some applications do a variety of tasks and it
might be important for you to see what the application accomplished. For example, this type of
message can be a file name when a list of files in a subdirectory are being processed by the
application. This type of message is a free form message.
The third type of message is an error message. Any time the application recognizes errors, a
message can be written to the RCP STATUS file. This type of message is a free form message.
The fourth type of message written to the RCP STATUS file is a completion message. It’s
purpose is to tell you how the application completed: successfully, failed, or only did part of the
requested function. The format of the completion message is:
• tt:tt:tt (the time)
• SUCCESS, FAILURE, or PARTIAL
• application
• parameters passed to application
The time field contains hours, minutes, and seconds. This entry is consistent with the same entry
placed in the RCP STATUS file by the 4680 or 4690 system applications.
Normally, the application writing to the RCP STATUS file will write its messages at the end of
the existing RCP STATUS file. This allows any application that was previously run in this RCP
session to keep its messages in the RCP STATUS file for someone to review. If no RCP STATUS
file exists, the application should create one in the ADX_SDT1 subdirectory.
If the system is a LAN system, the application should use the RCP STATUS file on the master
store controller, regardless of the node on which the application is actually run.
Foreground Applications
Applications started in the foreground are different from applications started using the other
methods. These are applications that are started by choosing an option on a 4690 screen. You
configure these applications on the secondary application screen.
No parameters can be configured for applications started in the foreground. However, that does
not mean there are no parameters for the application to consider. For example, if you start an
application named APPLZ from the secondary application screen, the command tail string
containing the name of the application would be “APPLZ”. The double quotes are not part of the
string; they show the extent of the string. The command tail string containing the parameters
would be:
"FOREGRND"
The FOREGRND parameter informs the application that it was started as a foreground
application and there is a video screen and keyboard associated with it. This is important
because foreground applications typically are interactive applications and communicate with
you using the video screen and keyboard.
Foreground applications have the most I/O flexibility. Input can come from any place and
output can go anywhere.
Application Programmer Considerations

If you intend for an application to be run only in one environment (command line, foreground,
or background) then only characteristics of that environment need to be addressed. However, if
the application is intended to be run in more than one environment, the application must be

flexible enough to handle the characteristics of each intended environment. Many of the 4680 or
4690 system applications are written in such a manner. For example, if you intend to run the
application from each of the three environments, the following characteristics apply:
• Inserted Parameters
The application should be able to determine how it was started by looking at the first
parameter. If the parameter is FOREGRND, it was started from the secondary application
screen. If the parameter is BACKGRND, it was started using one of the methods starting
background applications. If the first parameter is neither FOREGRND nor BACKGRND, or
there are no parameters, the application was started from the command line.
This assumes the application did not specify the first parameter for you to use to be
FOREGRND or BACKGRND.
• Parameter List Handling
The application extracting the parameters as they are encountered parses the parameter list
string. If the parameter list string is used as a fixed structure, parameters will not be correctly
used by the application when the application is started in each of the three possible
environments. This is due to the differing ways of handling spaces between parameters and
the differing number of parameters. This method of obtaining the parameters eliminates any
dependency that the parameters be presented in a certain format and allows the application
to get the same parameters in the same order regardless of the environment.
IPL Processing
When processing is needed during an IPL of the 4690 store controller, RCP can provide support
using a special SELECTION file named ADX_SDT1:ADXCSHDF.DAT. When RCP is started
during the IPL, it checks for the SELECTION file first. If the special SELECTION file exists, RCP
runs all commands listed in the COMMAND files. If any command in the SELECTION file
causes the store controller to IPL, when RCP is started again it runs the next command until all
commands have been executed.
To activate the unique IPL processing, you must configure RCP (ADXCSH0L) to be started in the
background on IPL of the store controller.
Note: You must code the IPL parameter before RCP knows that this is the special IPL type of
processing.
For a LAN, the master store controller is the only store controller that RCP is started on for the
IPL processing. RCP is not started on every node in a LAN environment during the IPL of the
store controller.
Processing Multiple Commands and COMMAND files

RCP enables you to request more than one command in a COMMAND file and more than one
COMMAND file name in a SELECTION file. Without the RCP IPL parameter, the IPL of a store
controller causes any commands that followed the IPL command to be ignored. With RCP IPL
processing, however, RCP issues all commands that are contained in each COMMAND file listed
in the SELECTION file, even if the commands cause a store controller to IPL. This situation is
possible because RCP starts on every IPL of the 4690 store controller and continually tracks the
commands that are issued. Tracking enables RCP to issue commands that were not issued when
RCP started.
When RCP started because of an IPL, you are notified in the RCP STATUS file,
ADX_SDT1:ADXCSHSF.DAT. When more than one command causes an IPL, RCP continues to
execute the next command on the next IPL until all commands are executed.
The following example illustrates the interaction between multiple commands and IPL
processing:
• ADXCSHCF.DAT contains: USERCMD.DAT.

• USERCMD.DAT contains:
ADX_UPGM:USERPROG
ADXCST0L N 3 M
ADXCSS0L N 1 M
In this example, the goal is to execute a user-written program, USERPROG, followed by the
Apply Software Maintenance command, ADXCST0L. After maintenance has been applied, the
ADXCSS0L command generates a module level report.
The USERPROG generates ADXCSHDF.DAT before ending and contains PREIPL.DAT. The
PREIPL.DAT file contains the command:
MOVEDATA ADX_UDT1 ADX_UBUL
When the ADXCST0L program runs, the store controller IPLs. RCP is started after the
maintenance has been applied. The MOVEDATA program is executed first, followed by the
execution of ADXCSS0L. RCP finds the ADXCSHDF.DAT file created by the USERPROG
program.
If RCP was not running immediately before the 4690 store controller IPLed, RCP does not issue
the list of commands identified by the ADXCSHCF.DAT file. RCP issues these commands only
when RCP is running immediately before a store controller IPL.
Retrieving Reports Formatted by RCP

You can retrieve a formatted report by using your transmission facility at your remote site and
specifying the appropriate name of the report you are retrieving. Table 7 shows which store
controller files contain the formatted report results.
Table 7. Reports Formatted by RCP

Report File Name Subdirectory
System Log ADXCSNRF.DAT ADX_SDT1
Trace Report ADXCSMTF.DAT ADX_SDT1
Configuration ADXCSDTF.DAT ADX_SDT1
Module Level Report ADXCSSDF.DAT ADX_SDT1
Dump Summary ADXCSLRF.DAT ADX_SDT1
Audible Alarm Status ADXCS1RF.DAT ADX_SDT1

Chapter 6. Systems Management Information
Systems Management Information
Vital Product Data File

The operating system stores Vital Product Data (VPD) for the store controller and terminals in
file, ADXCSCVF.DAT, on the store controller.
The VPD file is a keyed file created by the configuration process. The record keys for this file are
the assigned terminal numbers or controller IDs. The file contains 100-byte records for each
terminal and store controller identified during configuration.
Records in the VPD file have the following format:
Bytes 0 - 4
Record key
• For a store controller record:
bytes 0 - 1
Controller ID (ASCII, value range CC-ZZ)
bytes 2 - 4
ASCII, value 000
• For a terminal record:
bytes 0 - 1
ASCII, value 00
bytes 2 - 4
Terminal No. (ASCII, value range 001-999)
Bytes 5 - 11
Machine Type⁄Mod. No. (ASCII nnnnaaa)
• nnnn = 4 numeric digits
• aaa = 3 alphanumeric characters
Bytes 12 - 19
Serial No. (ASCII mm-sssss)
• For a store controller record, nn-nnnnn (ASCII, seven-digit Personal System/2 (PS⁄2)
serial no.)
• For a terminal record, mm-sssss (ASCII)
bytes 12 - 13
mm -- Plant of Manufacture
byte 14
Dash character (-)
bytes 15 - 19
sssss -- Sequence No.
Bytes 20 - 27
Planar Card EC No. (ASCII)

BIOS level of machine (supports all)
Bytes 28 - 34
Power Supply EC No. (ASCII)
This does not exist on a 4694 machine and appears as dashes (--)
Bytes 35 - 37
4683 Model 001 80286 ROS ID⁄EC No. pair (binary)
This appears as zeros on a 4694 machine
Bytes 38 - 97
30 8051 ID⁄EC Nos. (binary)
Bytes 98 - 99
Reserved
MAC Address Data File

The operating system provides a data file for functions like Wake on LAN that require a
mapping between 4690 OS terminal numbers and MAC addresses.
The file, ADX_SPGM:ADXCVMAC.DAT is a keyed file with a 128-byte record length and a 3-
byte key length. The key is the 3-digit ASCII representation of a terminal number. For example,
the key for terminal number 1 is 001 as three ASCII bytes.
The MAC file is created during controller IPL and is populated by individual terminals as they
come online.
Records in the MAC file have the following format:
Bytes 0 - 2
Record key (ASCII, value range 001-999)
Byte 3
WoL Supported (byte, value range 0-1)
Bytes 4 - 9
MAC address (Byte Array[6])
Bytes 10 - 127
Reserved
The MAC address recorded in this file is the "burned-in" MAC address of the POS terminal
Ethernet port.
The byte labelled "WoL Supported" reports 0 if Wake on LAN is not supported by this terminal
and reports 1 if Wake on LAN is supported by this terminal.
At present, only Enhanced Mode terminals are recorded in this file. Additional entries or record
data may be added in the future.
The operating system Keyed File Utility can convert the keyed file to a flat file, if an alternate
format is required. If so, remember to refresh the flat file periodically because the data changes
as POS terminals are added or renumbered and hardware replacement procedures alter the
effective MAC address of a given terminal number.
Regarding reverse lookup, entries are added or refreshed periodically as terminals reboot;
entries are never removed. As a result, program processing must take into account that obsolete
records might exist if terminal numbers are abandoned over time and those obsolete records

might result in the appearance of multiple terminal numbers associated to the same MAC
address.
The file is oversized to accommodate the full range of possible terminal numbers 000-999 with
additional space to minimize the possibility of overflow records and to allow additional records
to be added in the future without requiring the file to be resized.
Chapter 6. Systems Management Information 135

Notices
This information was developed for products and services offered in the U.S.A.
Toshiba Global Commerce Solutions may not offer the products, services, or features discussed
in this document in other countries. Consult your local Toshiba Global Commerce Solutions
representative for information on the products and services currently available in your area. Any
reference to a Toshiba Global Commerce Solutions product, program, or service is not intended
to state or imply that only that Toshiba Global Commerce Solutions product, program, or service
may be used. Any functionally equivalent product, program, or service that does not infringe
any Toshiba Global Commerce Solutions intellectual property right may be used instead.
However, it is the user's responsibility to evaluate and verify the operation of any non-Toshiba
Global Commerce Solutions product, program, or service.
Toshiba Global Commerce Solutions may have patents or pending patent applications covering
the subject matter in this document. The furnishing of this document does not give you any
license to these patents. You can send license inquiries, in writing, to:

Attn: General Counsel
3901 South Miami Blvd.
Durham, NC 27703
United States of America
The following paragraph does not apply to the United Kingdom or any other country where
such provisions are inconsistent with local law: TOSHIBA GLOBAL COMMERCE SOLUTIONS
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF NON-INFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR
PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain
transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are
periodically made to the information herein; these changes will be incorporated in new editions
of the publication. Toshiba Global Commerce Solutions may make improvements and/or
changes in the product(s) and/or program(s) described in this publication at any time without
notice.
Toshiba Global Commerce Solutions may use or distribute any of the information you supply in
any way it believes appropriate without incurring any obligation to you.
Any references in this information to non-Toshiba Global Commerce Solutions Web sites are
provided for convenience only and do not in any manner serve as an endorsement of those Web
sites. The materials at those Web sites are not part of the materials for this Toshiba Global
Commerce Solutions product and use of those Web sites is at your own risk.
Information concerning non-Toshiba Global Commerce Solutions products was obtained from
the suppliers of those products, their published announcements or other publicly available
sources. Toshiba Global Commerce Solutions has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-Toshiba Global
Commerce Solutions products. Questions on the capabilities of non-Toshiba Global Commerce
Solutions products should be addressed to the suppliers of those products.
This information is for planning purposes only. The information herein is subject to change
before the products described become available.

Telecommunication regulatory statement
This product is not intended to be connected directly or indirectly by any means whatsoever to
interfaces of public telecommunications networks, nor is it intended to be used in a public
services network.
Electronic emission notices

When you attach a monitor to the equipment, you must use the designated monitor cable and
any interference suppression devices that are supplied with the monitor.
Federal Communications Commission (FCC) statement

This equipment has been tested and found to comply with the limits for a Class A digital device,
pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection
against harmful interference when the equipment is operated in a commercial environment. This
equipment generates, uses, and can radiate radio frequency energy and, if not installed and used
in accordance with the instruction manual, may cause harmful interference to radio
communications. Operation of this equipment in a residential area is likely to cause harmful
interference, in which case the user will be required to correct the interference at his own
expense. There is no guarantee that interference will not occur in a particular installation. If this
equipment does cause harmful interference to radio or television reception, which can be
determined by turning the equipment off and on, the user is encouraged to try to correct the
interference by one or more of the following measures:
1. Reorient or relocate the receiving antenna.
2. Increase the separation between the equipment and receiver
3. Connect the equipment into an outlet on a circuit different from that to which the receiver is
connected.
4. Consult the dealer or experienced radio TV technician for help.
Properly shielded and grounded cables and connectors must be used in order to meet FCC
emission limits. Toshiba Global Commerce Solutions is not responsible for any radio or
television interference caused by using other than recommended cables and connectors or by
unauthorized changes or modifications to this equipment. Unauthorized changes or
modifications could void the user's authority to operate the equipment.
This device complies with part 15 of the FCC Rules. Operation is subject to the following two
conditions:
1. This device may not cause harmful interference, and
2. This device must accept any interference received, including interference that may cause
undesired operation.
FCC Radiation Exposure Statement

To comply with the FCC RF exposure compliance requirements, the separation distance between
the antenna and the body of all persons must be at least 20 cm (8 inches).
Industry Canada Class A Emission Compliance statement

This Class A digital apparatus complies with Canadian ICES-003 and RSS247.
Operation is subject to the following two conditions:
1. This device may not cause interference.
2. This device must accept any interference, including interference that may cause undesired
operation of the device.

Avis de conformité à la réglementation d'Industrie Canada
Cet appareil numérique de la classe A est conforme aux normes NMB-003 et RSS247 du Canada.
Le fonctionnement est soumis aux conditions suivantes :
1. Ce périphérique ne doit pas causer d’interférences;
2. Ce périphérique doit accepter toutes les interférences reçues, y compris celles qui risquent
d’entraîner un fonctionnement indésirable.
Industry Canada Radiation Exposure Statement

This equipment complies with IC radiation exposure limits set forth for an uncontrolled
environment. This equipment should be installed and operated with a minimum distance of 20
cm (8 inches) from the body of all persons.
European Union Electromagnetic Compatibility (EMC) Directive

Conformance Statement
This product is in conformity with the protection requirements of EU Council Directive
2014/30/EU on the approximation of the laws of the Member States relating to electromagnetic
compatibility. Toshiba Global Commerce Solutions cannot accept responsibility for any failure to
satisfy the protection requirements resulting from a non-recommended modification of the
product, including the fitting of non-Toshiba Global Commerce Solutions option cards.
This product has been tested and found to comply with the limits for Class A Information
Technology Equipment according to CISPR 32/European Standard EN 55032. The limits for Class
A equipment were derived for commercial and industrial environments to provide reasonable
protection against interference with licensed communication equipment.
Attention: This is a Class A product. In a domestic environment this product may cause radio
interference, in which case the user may be required to take adequate measures.
Responsible manufacturer:
Durham, NC 27703
European Community contact:
Toshiba Global Commerce Solutions, Inc.
Brand Manager - Europe, Middle East & Africa
Z.1 Researchpark 160, 1731 Asse, Belgium
Tel: 33-6845-35093
e-mail: [email protected]
Germany Class A statement

Deutschsprachiger EU Hinweis: Hinweis für Geräte der Klasse A EU-Richtlinie zur
Elektromagnetischen Verträglichkeit
Dieses Produkt entspricht den Schutzanforderungen der EU-Richtlinie 2014/30/EU zur
Angleichung der Rechtsvorschriften über die elektromagnetische Verträglichkeit in den EU-
Mitgliedsstaaten und hält die Grenzwerte der EN 55032 Klasse A ein.
Um dieses sicherzustellen, sind die Geräte wie in den Handbüchern beschrieben zu installieren
und zu betreiben. Des Weiteren dürfen auch nur von der Toshiba Global Commerce Solutions
Notices 139
empfohlene Kabel angeschlossen werden. Toshiba Global Commerce Solutions übernimmt keine
Verantwortung für die Einhaltung der Schutzanforderungen, wenn das Produkt ohne
Zustimmung der Toshiba Global Commerce Solutions verändert bzw. wenn
Erweiterungskomponenten von Fremdherstellern ohne Empfehlung der Toshiba Global
Commerce Solutions gesteckt/eingebaut werden.
EN 55032 Klasse A Geräte müssen mit folgendem Warnhinweis versehen werden: “Warnung:
Dieses ist eine Einrichtung der Klasse A. Diese Einrichtung kann im Wohnbereich Funk-
Störungen verursachen; in diesem Fall kann vom Betreiber verlangt werden, angemessene
Maβnahmen zu ergreifen und dafür aufzukommen.”
Deutschland: Einhaltung des Gesetzes über die elektromagnetische Verträglichkeit von
Geräten
Dieses Produkt entspricht dem “Gesetz über die elektromagnetische Verträglichkeit von Geräten
(EMVG)”. Dies ist die Umsetzung der EU-Richtlinie 2014/30/EU in der Bundesrepublik
Deutschland.
Zulassungsbescheinigung laut dem Deutschen Gesetz über die elektromagnetische
Verträglichkeit von Geräten (EMVG) (bzw. der EMC EG Richtlinie 2014/30/EU) für Geräte der
Klasse A
Dieses Gerät ist berechtigt, in Übereinstimmung mit dem Deutschen EMVG das EG-
Konformitätszeichen - CE - zu führen.
Verantwortlich für die Einhaltung der EMV Vorschriften ist der Hersteller:
Durham, NC 27703
Der verantwortliche Ansprechpartner des Herstellers in der EU ist:
Brand Manager - Europe, Middle East & Africa
Z.1 Researchpark 160, 1731 Asse, Belgium
Tel: 33-6845-35093
e-mail: [email protected]
Generelle Informationen:
Das Gerät erfüllt die Schutzanforderungen nach EN 55024 und EN 55032 Klasse A.
Australia and New Zealand Class A statement

Aviso para los usuarios de México

La operación de este equipo está sujeta a las siguientes dos condiciones:
1. Es posible que este equipo o dispositivo no cause interferencia prejudicial.
2. Este equipo o dispositivo debe aceptar cualquier interferencia. Incluyendo la que pueda
causar su operación no deseada.
Para saber el modelo de la tarjeta inalámbrica utilizada, revise la etiqueta regulatoria de la
impresora.

People's Republic of China Class A electronic emission statement
Russian Electromagnetic Interference (EMI) Class A statement
Japanese Electrical Appliance and Material Safety Law statement
Japanese power line harmonics compliance statement
Japan Voluntary Control Council for Interference Class A statement
Notices 141
Attention: This is a Class A product based on the standard of the Voluntary Control Council for
Interference (VCCI). If this equipment is used in a domestic environment, radio interference may
occur, in which case, the user may be required to take corrective actions.
Japan Electronics and Information Technology Industries

Association (JEITA) statement
Japan Electronics and Information Technology Industries Association (JEITA) Confirmed

Harmonics Guidelines with Modifications (products greater than 20 A per phase).
Korean communications statement
This is electromagnetic wave compatibility equipment for business (Type A). Sellers and users
need to pay attention to it. This is for any areas other than home.
Taiwan Class A compliance statement
Taiwan contact information

Toshiba Global Commerce Solutions Taiwan Product Service Contact Info:
Rm. 1, 5F., No.3-2, Park St., Nangang Dist., Taipei City, Taiwan
Telephone: 0800-001-939
Cable ferrite requirement

All cable ferrites are required to suppress radiated EMI emissions and must not be removed.
Electrostatic discharge (ESD)

Attention: Electrostatic discharge (ESD) damage can occur when there is a difference in charge
between the part, the product, and the service person. No damage will occur if the service
person and the part being installed are at the same charge level.
ESD damage prevention
Anytime a service action involves physical contact with logic cards, modules, back-panel pins, or
other ESD sensitive (ESDS) parts, the service person must be connected to an ESD common
ground point on the product through the ESD wrist strap and cord.
The ESD ground clip can be attached to any frame ground, ground braid, green wire ground, or
the round ground prong on the AC power plug. Coax or connector outside shells can also be
used.
Handling removed cards
Logic cards removed from a product should be placed in ESD protective containers. No other
object should be allowed inside the ESD container with the logic card. Attach tags or reports that
must accompany the card to the outside of the container.
Product recycling and disposal

This unit must be recycled or discarded according to applicable local and national regulations.
Toshiba Global Commerce Solutions encourages owners of information technology (IT)
equipment to responsibly recycle their equipment when it is no longer needed. Toshiba Global
Commerce Solutions offers a variety of product return programs and services in several
countries to assist equipment owners in recycling their IT products. Information on Toshiba
Global Commerce Solutions product recycling offerings can be found on the Toshiba Global
Commerce Solutions product recycling programs website.
Español: Esta unidad debe reciclarse o desecharse de acuerdo con lo establecido en la normativa
nacional o local aplicable. Toshiba Global Commerce Solutions recomienda a los propietarios de
equipos de tecnología de la información (TI) que reciclen responsablemente sus equipos cuando
éstos ya no les sean útiles. Toshiba Global Commerce Solutions dispone de una serie de
programas y servicios de devolución de productos en varios países, a fín de ayudar a los
propietarios de equipos a reciclar sus productos de TI. Se puede encontrar información sobre las
ofertas de reciclado de productos de Toshiba Global Commerce Solutions en el sitio web Toshiba
Global Commerce Solutions product recycling programs.
Notices 143
Note: This mark applies only to countries within the European Union (EU) and Norway.
Appliances are labeled in accordance with European Directive 2012/19/EU concerning waste
electrical and electronic equipment (WEEE). The Directive determines the framework for the
return and recycling of used appliances as applicable throughout the European Union. This label
is applied to various products to indicate that the product is not to be thrown away, but rather
reclaimed upon end of life per this Directive.
Remarque : Cette marque s’applique uniquement aux pays de l’Union Européenne et à la
Norvège. L’etiquette du système respecte la Directive européenne 2012/19/EU en matière de
Déchets des Equipements Electriques et Electroniques (DEEE), qui détermine les dispositions de
retour et de recyclage applicables aux systèmes utilisés à travers l’Union européenne.
Conformément à la directive, ladite étiquette précise que le produit sur lequel elle est apposée ne
doit pas être jeté mais être récupéré en fin de vie.
In accordance with the European WEEE Directive, electrical and electronic equipment (EEE) is to
be collected separately and to be reused, recycled, or recovered at end of life. Users of EEE with
the WEEE marking per Annex IV of the WEEE Directive, as shown above, must not dispose of
end of life EEE as unsorted municipal waste, but use the collection framework available to
customers for the return, recycling, and recovery of WEEE. Customer participation is important
to minimize any potential effects of EEE on the environment and human health due to the
potential presence of hazardous substances in EEE. For proper collection and treatment, contact
your local Toshiba Global Commerce Solutions representative.
Disposal of IT products should be in accordance with local ordinances and regulations.
Battery safety
FG：!"#$%&。()*+,，-./0"#1234"。
-.：6"#78198:;、6"#=>? 100°C (212°F) @A、BC1DE。 (C003)
Caution: Risk of explosion if battery is replaced by an incorrect type. Dispose of used

batteries according to the instructions.

Battery return program
This product may contain sealed lead acid, nickel cadmium, nickel metal hydride, lithium, or
lithium ion battery. Consult your user manual or service manual for specific battery information.
The battery must be recycled or disposed of properly. Recycling facilities may not be available in
your area. For information on disposal of batteries outside the United States, go to the Battery
disposal website or contact your local waste disposal facility.
For Taiwan:
Please recycle batteries.
For the European Union:
Notice: This mark applies only to countries within the European Union (EU)
Batteries or packaging for batteries are labeled in accordance with European Directive
2013/56/EU concerning batteries and accumulators and waste batteries and accumulators. The
Directive determines the framework for the return and recycling of used batteries and
accumulators as applicable throughout the European Union. This label is applied to various
Notices 145
batteries to indicate that the battery is not to be thrown away, but rather reclaimed upon end of
life per this Directive.
Les batteries ou emballages pour batteries sont étiquetés conformément aux directives
européennes 2013/56/EU, norme relative aux batteries et accumulateurs en usage et aux batteries
et accumulateurs usés. Les directives déterminent la marche à suivre en vigueur dans l'Union
Européenne pour le retour et le recyclage des batteries et accumulateurs usés. Cette étiquette est
appliquée sur diverses batteries pour indiquer que la batterie ne doit pas être mise au rebut mais
plutôt récupérée en fin de cycle de vie selon cette norme.
In accordance with the European Directive 2013/56/EU, batteries and accumulators are labeled to
indicate that they are to be collected separately and recycled at end of life. The label on the
battery may also include a chemical symbol for the metal concerned in the battery (Pb for lead,
Hg for mercury and Cd for cadmium). Users of batteries and accumulators must not dispose of
batteries and accumulators as unsorted municipal waste, but use the collection framework
available to customers for the return, recycling and treatment of batteries and accumulators.
Customer participation is important to minimize any potential effects of batteries and
accumulators on the environment and human health due to the potential presence of hazardous
substances. For proper collection and treatment, contact your local Toshiba Global Commerce
Solutions representative.
This notice is provided in accordance with Royal Decree 106/2008 of Spain: The retail price of
batteries, accumulators and power cells includes the cost of the environmental management of
their waste.
For California:
Perchlorate material – special handling may apply
Refer to www.dtsc.ca.gov/hazardouswaste/perchlorate.
The foregoing notice is provided in accordance with California Code of Regulations Title 22,
Division 4.5, Chapter 33: Best Management Practices for Perchlorate Materials. This product/part
includes a lithium manganese dioxide battery which contains a perchlorate substance.
Flat panel displays

The fluorescent lamp in the liquid crystal display contains mercury. Dispose of it as required by
local ordinances and regulations.
Monitors and workstations

Connecticut: Visit the website of the Department of Energy & Environmental Protection at
www.ct.gov/deep for information about recycling covered electronic devices in the State of
Connecticut, or telephone the Connecticut Department of Environmental Protection at
1-860-424-3000.
Oregon: For information regarding recycling covered electronic devices in the state of Oregon,
go to the Oregon Department of Environmental Quality site at www.deq.state.or.us/lq/
electronics.htm.
Washington: For information about recycling covered electronic devices in the State of
Washington, go to the Department of Ecology Website at fortress.wa.gov/ecy/recycle/ or
telephone the Washington Department of Ecology at 1-800-Recycle.

Trademarks
The following are trademarks or registered trademarks of Toshiba, Inc. in the United States or
other countries, or both:
Toshiba
The Toshiba logo
The following are trademarks of Toshiba Global Commerce Solutions in the United States or
other countries, or both:
AnyPlace
SureMark
SurePoint
SurePOS
TCxWave
TCxFlight
TCx
The following are trademarks of International Business Machines Corporation in the United
States or other countries, or both:
DB2
DB2 Universal Database
IBM and the IBM logo
PS/2
Wake on LAN
WebSphere
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Magellan is a registered trademark of Datalogic Scanning, Inc.
SYMBOL a registered trademark of Symbol Technologies, Inc.
Microsoft, Windows, Windows NT, and the Windows 95 logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.
Celeron and Intel are trademarks of Intel corporation in the United States, or other countries.
Java and all Java-based trademarks and logos are trademarks of Oracle, Inc. in the United States,
or other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
Notices 147
Index
BOOTP client with TCP/IP applications 29 commands (continued)
A BOOTP server with TCP/IP applications 30 start trace for RCP: all traces 93
start trace for RCP: device channel 92
actfilt command 60 start trace for RCP: loop, hard disk
activating
audible alarm for all store
C drive, host line 92
start⁄stop trace for RCP 89
controllers 110 stop performance command for
cable ferrite requirement 143
audible alarm for one store RCP 96
characteristics of terminal, setting 115
controller 110 stop trace for RCP 97
chfilt command 61
command for audible alarm function, system log formatter for RCP 100
Class A compliance statement
LAN system 108 system log formatter for RCP,
Australia and New Zealand 140
command for audible alarm function, example 103
China 141
non-LAN system 108 trace for RCP 89
European Union 139
remote audible alarm example using trace formatter for RCP 97
FCC (USA) 138
RCP 110 communications
Germany 139
ADXCS20L 87, 114 introduction to 15
Industry Canada 138
ADXCS30L 116 management 133
Japan 141
ADXCSH0L 86 Communications and Systems
Russia 141
ADXCSM0L 98, 122 Management
command file for RCP 82
ADXCSN0L 100, 122 MAC address data file 134
command to load all terminals 114
ADXCSP0L 90, 122 vital product data file 133
commands
ADXCSQ0L 92 compressing files
activate audible alarm for LAN
ADXCSR0L 121 file compression⁄decompression,
system 108
ADXCSS0L 106, 122 RCP 116
activate audible alarm for LAN system,
adxipsaf.386 60 list file format for file
examples 109
adxipscf.386 61 compression⁄decompression, RCP 119
activate audible alarm for non-LAN
adxipsgf.386 57 on hard disk drive, RCP 116
system 108
adxipsgt.386 65 on media, RCP 116
adxipslf.386 64 remotely, RCP 117
system, examples 110
adxipsmf.386 63 configuration
ADCS START USER PROGRAM for
adxipsrf.386 64 set date and time 115
starting RCP 125
adxipsst.386 66 set terminal characteristics 115
apply software maintenance 112
apply software maintenance command 112 configuration activation command,
audible alarm 108
applying software maintenance from a host RCP 104
BIND request for starting RCP 125
site 115 configuration data formatter command,
configuration activation for RCP 104
audible alarm RCP 105
configuration data formatter for
activate a store controller 110 configuration, PXE 32
RCP 105
activate all store controllers 110 configuring DHCP server 35
deactivate audible alarm 110
activate command for LAN system 108 configuring TCP/IP for 4690 OS
dump formatter 88
activate command for non-LAN controllers 19
dump formatter, remote (RCP) 88
system 108 configuring, DHCP server 32
ethernet trace 94
commands 108
file compression⁄decompression,
deactivate a store controller 110
RCP 116
deactivate all store controllers 110
deactivate command 110
file management command for trace for D
RCP 98, 99
examples for LAN system 109
file management for system log for damage from electrostatic discharge 143
examples for non-LAN system 110
RCP 103 deactivate
report audible alarm status
format performance data 90 audible alarm for one or all store
command 111
INITIATE FUNCTION for starting controllers 110
report audible alarm status for a store
RCP 125 command for audible alarm
controller 111
list file format for file function 110
report audible alarm status for all store
compression⁄decompression, RCP 119 remote audible alarm using RCP
controllers 111
load all terminals 114 command file 111
setting alarm duration 110
processing multiples for RCP 130 decompressing files
using Remote Command Processor
re-IPL command for RCP 87 file compression⁄decompression,
(RCP) 110, 111
Remote Command Processor 86 RCP 116
audible alarm commands 108
remote STC 87 list file format for file
report audible alarm status 111 compression⁄decompression, RCP 119
report module level for RCP 106 remotely, RCP 117
B run remote STC in one terminal, remote DHCP configuration file 33
(RCP) 87 DHCP configuration options 34
battery return program 145 start performance for RCP 89 DHCP server

DHCP server (continued) Internet Protocol Security (IPsec) (continued)
backup configuration 33 F commands 57
configuration file 33 configuring filters 51
configuration options 34 ferrite requirement 143 genfilt command 57
configuring 32 file compression⁄decompression gentun command 65
configuring for terminal IP address command 116 ipsecstat command 66
assignment 35 file management command for system log, lsfilt command 64
PXE booting 33 RCP 103 mvfilt command 63
troubleshooting 38 file management command for trace output rmfilt command 64
DHCP server backup configuration 33 data files for RCP 98, 99 introduction to communications 15
DHCP setup for PXE booting 33 filters IPL processing for RCP 130
DHCPINFO utility 36 configuring 51 IPsec
disposal of equipment 143 intrusion detection and prevention 54 actfilt command 60
dump rules adxipsaf.386 60
formatter command used with RCP 88 examples 52 adxipscf.386 61
remote store controller using RCP 88 pattern matching 54 adxipsgf.386 57
remote terminal dump using RCP 88 predefined 52 adxipsgt.386 65
shun host 55 adxipslf.386 64
shun port 55 adxipsmf.386 63
stateful 57
E subnet masks 52
adxipsrf.386 64
adxipsst.386 66
timed 57 chfilt command 61
electromagnetic Interference statement
user-defined 51 commands 57
Russia 141
flat panel displays 146 configuring filters 51
electronic emissions notices
format performance data 90 genfilt command 57
Australia and New Zealand 140
formatting gentun command 65
China 141
a trace from a remote site using ipsecstat command 66
European Union 139
RCP 98 lsfilt command 64
FCC (USA) 138
dumps from a host site 88 mvfilt command 63
Germany 139
system log formatter command, rmfilt command 64
Industry Canada 138
example 103 ipsecstat command 66
Japan 141
system log formatter for RCP 100
Korea 142
FTP client with TCP/IP applications 24
electrostatic discharge (ESD) 143
FTP server with TCP/IP applications 25
eloopaddr 20
full store controller dump using RCP 88
J
end of life disposal 143
full terminal dump using RCP 88
enhanced loopback address Japan Electronics and Information
functions of RCP 81
ifconfig 21 Technology Industries Association
equipment disposal 143 statement 142
ethernet trace, RCP 94 Japanese Electrical Appliance and Material
European Union battery recycling G Safety Law statement 141
statement 145 Japanese power line harmonics compliance
examples genfilt command 57 statement 141
activate audible alarm (remote) gentun command 65 Japanese VCCI Council Class A
command 110 statement 141
activate audible alarm for LAN
system 109 H
system 110 host
K
compress all files on hard disk drive, defining store controller 81 Korean communications statement 142
RCP 116
compress all files on media, RCP 116
configuration activation command 105
configuration data formatter
I L
command 106 identifying a network router, TCP/IP 21 list file format for file
deactivate audible alarm (remote) INETD superserver with TCP/IP compression⁄decompression, RCP 119
command 111 applications 24 listing
dump formatter command for RCP 89 Internet Protocol Security (IPsec) file format for file
ethernet trace 95 actfilt command 60 compression⁄decompression 119
ethernet trace SAP 96 adxipsaf.386 60 loading
load all terminals command 114 adxipscf.386 61 all terminals remotely 114
module level formatter command 106 adxipsgf.386 57 example of load command in RCP
RCP application flow 81 adxipsgt.386 65 command file 114
remote trace formatting for RCP 98 adxipslf.386 64 load all terminals command 114
report audible alarm (remote) status adxipsmf.386 63 lsfilt command 64
command 111 adxipsrf.386 64
system log command 102 adxipsst.386 66
system log formatter, RCP 103 chfilt command 61

Remote Command Processor (continued) report module level (continued)
M example of configuration activation example of in RCP command file 106
command 105 report module level command used with
MAC address data file 134 example of configuration data formatter RCP 106
MAC address data record format 134 command 106 report status command for audible alarm
management example of ethernet trace 95 function 111
communications 133 example of ethernet trace command 96 report status of audible alarm
systems 133 example of flow 81 for a store controller 111
mercury-added statement 146 example of system log command 102 for all store controllers 111
multiple commands and command files for example of system log formatter report store controller audible alarm
RCP 130 command 103 status 111
mvfilt command 63 file compression⁄decompression reports formatted by RCP 131
command 116 retrieving
file management command for system RCP reports 131
N log 103 rmfilt command 64
file management command for trace
NFS client with TCP/IP applications 29 output data files 98, 99
NFS server with TCP/IP applications 27 format performance data 90 S
notices functions of 81
battery recycling 145 how to use 81 safety information 9
cable ferrites 143 IPL processing 130 sample of RCP command file 82
electronic emissions 138 list file format for file Secure Shell (SSH)
electrostatic discharge (ESD) 143 compression⁄decompression introduction 69
end of life disposal 143 command 119 selection file used with RCP 81
Toshiba 137 load all terminals remotely 114 set system time and date 115
multiple commands and command set terminal characteristics 115
files 130 setting store controller audible alarms 110
P RCP selection file used with 81
re-IPL command 87
SSH
introduction 69
parameter for Remote Command report audible alarm status 111 start performance command for RCP 89
Processor 86 report module level command 106 start trace command for RCP: all traces 93
perchlorate 146 retrieving reports formatted by 131 start trace command for RCP: device
performance, PXE 31 run remote STC in one terminal channel 92
pingTime parameter, PXE 31 command 87 start trace command for RCP: loop, hard
PXE sample of 82 disk drive, host line 92
configuration 32 set date and time 115 start⁄stop trace command for RCP 89
DHCP setup 33 set terminal characteristics 115 starting RCP 125
IP address 31 start performance command 89 starting RCP from an application 126
performance considerations 31 start trace command 89 status file used with RCP 84
pingTime parameter 31 start trace command for all traces 93 stop performance command for RCP 96
restrictions 31 start trace command for device stop trace command for RCP 97
PXE booting 33 channel 92 store controller
PXE environment 31 start trace command for loop, hard disk activate audible alarm 110
PXE environment restrictions 31 drive, host line 92 remote dump using RCP 88
start⁄stop trace command 89 report audible alarm status 111
starting 125 subnet masks 52
R starting from an application 126 system log command, example in RCP
status file used with RCP 84 command file 102
re-ipl command for RCP 87 stop performance command 96 system log from a remote site for RCP 100
Remote Command Processor stop trace command 89, 97 system log, example of formatter
activate audible alarm 110 system log formatter 100 command 103
apply software maintenance trace commands 89 system log, file management command 103
command 112 trace formatter command 97 systems management 133
applying software maintenance user created output files 83
using 115 using command files on LAN
systems 82
audible alarm commands 108
remote configuration activation 104
T
command file 82
commands and parameters 86 remote dump formatting Taiwanese battery recycling statement 145
compress⁄decompress files store controller 88 TCP/IP
remotely 117 terminal dump using RCP 88 configuring 19
configuration activation command 104 remote ethernet trace command 94 identifying a network router 21
configuration data formatter remote reporting of configuration data 105 programming libraries 49
command 105 remote STC using RCP 87 setting up other TCP/IP
deactivate audible alarm 110 remote terminal invocation 115 applications 24
dump formatter command 88 report audible alarm (remote) status using host names 22
ethernet trace command 94 example of in RCP command file 111 using in the operating system 17
report module level using other TCP/IP applications 24
Index 151
Telecommunications regulatory
statement 138
Telnet client with TCP/IP applications 29
terminal characteristics, setting 115
terminal, remote dump 88
terminal, remote STC 87
time and date, setting 115
trace commands for RCP 89
trace formatter (remote)
example for RCP 98
file management command 98, 99
remote trace formatting 98, 99
trace formatter command for RCP 97
trademarks 147
troubleshooting DHCP server 38
U
user created output files for RCP 83
using host names, TCP/IP
configuring TCP keepalive timer
value 23
defining search order 22
hosts file 22
resolv file 22
using other TCP/IP applications
BOOTP client 29
BOOTP server 30
Enhanced Telnet server 45
FTP client 24
FTP server 25
INETD superserver 24
LPR client 47
NFS client 29
NFS server 27
PCNFSD authentication server 48
rexec client 48
SNMP agent 42
Telnet client 29
Telnet server 44
using RCP command files on LAN
systems 82
using the Remote Command Processor 81
utility, DHCPINFO 36
V
vital product data file 133
vital product data record format 133

TC62-0036-03

TCX Sky Communications Programming Ref

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TCX Sky Communications Programming Ref

Uploaded by

Copyright:

Available Formats

Toshiba Global Commerce Solutions

© Copyright Toshiba Global Commerce Solutions, Inc. 2013, 2019 3

Chapter 6. Systems Management

4 Communications Programming Reference

© Copyright Toshiba Global Commerce Solutions, Inc. 2013, 2019 5

© Copyright Toshiba Global Commerce Solutions, Inc. 2013, 2019 7

Before installing this product, read Safety Information.

Antes de instalar este produto, leia as Informações de Segurança.

Pred instalací tohoto produktu si prectete prírucku bezpecnostních instrukcí.

Prima di installare questo prodotto, leggere le Informazioni sulla Sicurezza.

Les sikkerhetsinformasjonen (Safety Information) før du installerer dette produktet.

Antes de instalar este produto, leia as Informações sobre Segurança.

Antes de instalar este producto, lea la información de seguridad.

© Copyright Toshiba Global Commerce Solutions, Inc. 2013, 2019 9

Who should use this guide

Where to find more information

Accessing the TGCS Knowledgebase site

TCx Sky Library

© Copyright Toshiba Global Commerce Solutions, Inc. 2013, 2019 11

12 Communications Programming Reference

© Copyright Toshiba Global Commerce Solutions, Inc. 2013, 2019 13

© Copyright Toshiba Global Commerce Solutions, Inc. 2013, 2019 15

4690 TCP/IP file naming conventions

© Copyright Toshiba Global Commerce Solutions, Inc. 2013, 2019 17

18 Communications Programming Reference

Configuring 4690 TCP/IP

Chapter 2. Using TCP/IP in the operating system 19

20 Communications Programming Reference

Enhanced loopback address configuration using ifconfig

ifconfig lan0 eloopaddr last

Identifying a network router

Chapter 2. Using TCP/IP in the operating system 21

22 Communications Programming Reference

Configuring TCP Keepalive and Connection Establishment Timer Values

Chapter 2. Using TCP/IP in the operating system 23

INETD Superserver (ADXHSI9L.286)

FTP Client (ADXHSIGL.286)

24 Communications Programming Reference

FTP Server (ADXHSIFL.286)

user: ftpuser 4690tcpip

Chapter 2. Using TCP/IP in the operating system 25

Quote FTP client command

Access for NFS and VFS Drives

26 Communications Programming Reference

NFS server (ADXHSINL.386)

Chapter 2. Using TCP/IP in the operating system 27

Using the EXPORTS file to give NFS clients access to files

# Export read-only access to everyone

# Export read/write access to hosts jack and jill

28 Communications Programming Reference

Telnet client (ADXHSIVL.286)

BOOTP client (ADXHSIBL.286)

Chapter 2. Using TCP/IP in the operating system 29

Using the BOOTP protocol to update/create the SNMP trap

BOOTP server (ADXHSIAL.286)

30 Communications Programming Reference

BOOTP extension file compiler

Configuring the PXE environment and DHCP Server (DHCPD.386)

PXE Environment Restrictions

PXE/DHCP/TFTP Server Communication

PXE Load Performance Considerations

Chapter 2. Using TCP/IP in the operating system 31

Configuring the DHCP Server