Support

It’s not based on time. The terminal agent has a fixed-size memory buffer for each device. For keystrokes, it’s more like ‘ the buffer will hold typically nn keystrokes.’ The current value is approximately 50 keystrokes

Additional notes:

The controller agent also has a per-device memory buffer and this buffer may be a different size than the terminal buffer. The controller agent puts keystrokes into its buffer when a terminal is being monitored. If a 2nd client comes up and wants to monitor a terminal, the 2nd client will be given history from the controller agent instead of the terminal agent (in order to minimize POS loop/lan traffic). The controller agent’s buffer is flushed when there are no more clients.

We are likely to end up with a couple of versions of the terminal agent: small and normal. The small version may have smaller history buffers than the normal version.

We may make the terminal device history buffer sizes configurable if it seems like default sizes can’t meet the needs of different customers.

We will likely have an optional feature in future versions that allows keystrokes and other device history to be saved on the controller. For example, ‘save past n days worth of device history for all terminals for these devices.’

Bottom line is that there is some minimum but what the user actually sees can vary based on several factors.

Some other current defaults for device history buff sizes:

• 40 2×20 display lines
• 10 cashdrawer open commands
• 30 receipt lines (38 chars each)
• 50 vdisplay display lines (80 chars/attrs each)

No. The default installation will start the InSight controller agent as a hidden process similar to how 4690 starts its DHCP server task (the DHCP server task is used when PXE terminal loading is enabled). Optionally, a user can configure the controller agent to run as a 4690 background task.

Yes.

No. The InSight terminal agent communicates with the controller agent(s) using a system pipe routing services (PRS) pipe. System PRS pipes differ from application PRS pipes in that no pipe ‘letter’ must be assigned and managed. TCP/IP could be used in the future but only if customers already are using TCP/IP. InSight is specifically designed to run on existing/legacy systems without requiring new hardware or changes to configuration.

InSight is capable of supporting 3 history modes: no history, in-memory history in the terminal (default), history logged to the controller.

In-memory history is kept on a device-by-device basis. Each device has its own history buffer. History buffer size defaults are set so that a) in most cases, there is history back to the start of a transaction and b) if there is a problem and the terminal is dumped, there is enough history to figure out what led up to the problem.

History kept on the controller is a feature that we haven’t fully decided how to implement (and that we are looking for feedback on). It is not currently in the planned Version 1 feature set. Here are the kinds of question we have yet to answer: If we were to keep 2 or 3 days history for critical devices (system display, keyboard, scanner, printer?), just how much data is that? How much LAN traffic is it? Would customers need it for all registers always, or would they just turn it on for a register or range of registers when they are trying to track down a problem? Does the InSight ‘snapshot terminal dump’ and in-memory history meet 99% of the requirement?

Generally, it is expected that customers will set up InSight in a way that it uses negligible amounts of these resources. In an expected typical configuration where InSight’s terminal agent is tracking some device histories but these histories are not being kept on the controller, the terminal agent is expected to run on the oldest legacy hardware (8Mhz 80286 in a 4683) without noticeable effect. Almost no terminal/controller communications takes place between the terminal and controller agents unless monitoring is enabled. With monitoring enabled, there is still only a very small amount of loop/lan traffic. InSight’s terminal agent and device message flow is based on the compression/gathering techniques that QVS developed for its TC product. TC was proven to run 50 general merchandise 4683 lanes running on a 38 Kbps store loop at peak season.

The following numbers are not exact but are meant to give an idea of TC requirements. Without knowing a lot of details about a potential system, it isn’t possible to be exact.
Disk space:

TC/Windows – Figure on 1GB. TC binaries are not very large but its debug logging facility can generate a lot of data (10MB per terminal) and the virtual memory swap space used by TC processes can be 100MB or so.

TC/4690 – Figure on 250 MB mostly for TC debug data files.

Memory:

Windows NT – 32MB as base amount. This covers a base for NT and a base amount for TC. Then multiply terminal data space plus a base of 250KB times the number of terminals (250KB data space plus 250KB base = 500KB * 60 terminals = 30MB). In the example just shown, the total would be 64MB.

Windows 2000 – Same as Windows NT except a base amount of 80 MB should be the starting point instead of 32MB.

4690 – 32MB as a base amount which covers 1st application instance. This covers a base amount for 4690OS (20 MB) and a base amount for TC (12 MB). After the first head, assume approximately 1.5MB for each additional head.

TC/Windows – 64 terminals
TC/Windows XL Version – 80 terminals
TC/4690 – 60 terminals

The differences can be broken down into the following categories:

• Where TC is relative to the 4690 controller and files.
• Whether or not and how other applications running in the concentrator interact with TC or the sales application.
• Method of I/O device emulation or access.
• If I/O device access is provided by the TC Remote Peripheral Access Method (RPAM), the type of communication that is used between the client terminal and the TC server.
• If I/O device access is provide by RPAM, the terminal type of the client.

For additional information, see Knowledge Base Article “Terminal Concentrator Technical Differences (KB000107)”

Handheld terminals: Self shopping or price checker or line busting applications where there is a desire to have the price generated by the customer’s standard TGCS SA/GSA terminal sales application.

Non-TGCS traditional POS terminals: when customer wants to use non-TGCS, (typically older), hardware but run TGCS SA/GSA sales applications.

Older TGCS terminals that are low on memory and can no longer hold an application that has grown in size.

Note: For complete diagnostic information, QVS may also need “client-side” diagnostic logs. This means that your code must enable client-side logging. This is not necessary if you are running Terminal Concentrator with a standard TGCS terminal.

In order to obtain traces of Terminal Concentrator execution do the the following steps:

1. On the Master Controller, rename the file: c:\tc46\logging.off to c:\tc46\logging.on.
2. If you need to trace an actual TGCS terminal running the QVS “client” program, termrpam.286, copy any file to c:\tc46\logging.nnn, where nnn is a TC terminal number between 800 and 899.
3. Using the background task screen, stop and restart terminal concentrator task (tc_bin:tc4690.286) on the master controller
4. If you are obtaining a trace also of the TGCS “client” program, be sure to reload the terminal application, termrpam.286, for any terminal you wish to trace.
5. Execute the procedure you are trying to capture. When this is done, proceed to the next step.
6. Go to a DOS prompt and type: c:\tc_bin:tprocess -k1
7. After the command completes, retrieve all the log files in directory c:\tc46\log
8. Erase the log files in the c:\tc46\log directory
9. Rename c:\tc46\logging.on to c:tc46\logging.off
10. Restart Terminal Concentrator from the background screen
11. If you have created a terminal client logging file, c:\tc46\logging.nnn, please erase or rename the file(s) and reload the termrpam.286 program in each of those terminals.
12. Send all log files to QVS for analysis.

Note: For complete diagnostic information, QVS may also need any generated “client-side” diagnostic logs. This means that your code must enable client-side logging.

If you are using either a “COM RPAM” or “Java” client, these logs are created when the following command is issued from your client code:

Java: Set RPAMApp.setTracing(true)
COM RPAM: Set CRPAMApp->put_Tracing(1);

If this condition is met or if it is determined by QVS personnel that client-sde logs are not needed to diagnose a particular problem, proceed to the next steps.

1. Execute:
2. From a command prompt, execute the following command:
   del c:\tc_nt\log\*.* (This command erases any pre-existing log files)
3. Start Terminal Concentrator
4. Recreate the problem
5. Stop Terminal Concentrator
6. Zip up all files contained in the “TC_NT\log” directory and send them to QVS personnel for analysis.

If you are running a COM RPAM client in the same machine that is running Terminal Concentrator, you have all the data you need.

If you are running the COM RPAM client in a machine separate from Terminal Concentrator, execute the following steps:

1. Locate the LOG directory your client code is using. To locate that directory, search for the file, qvsrpam.exe. Make note of the directory name in which this file is located.
2. Relative to that directory, go to the “..\log” directory to find the log files. You should find files such as “logsdbq.bin, applicq.pan, qvs1.bin, qvs1.bi1, qvs2.bin, etc.”. For example, if qvsrpam.exe were in c:\qvs, then the logs would be found in c:\log.
3. Zip up these files and send them to QVS personnel for analysis.

If you are running a Java client, then you will need to retrieve logs for the java client. These logs are located in the “log” subdirectory in the directory tree in which your Java Virtual Machine (JVM) code is located. For example, if you are running JAVA.EXE located in c:\jdk1.3\bin, the logs will be located in the c:\jdk1.3\log directory. The Java log files will have names similar to “qvs1.log”, “qvs2.log”, etc. Sometimes it can be difficult to find these logs because people don’t often know here their JVM is located or because they have more than one JVM on their machine. The easiest way to find them is to do a “dir qvs?.log /s” from the root directory of the drives on the machine. Then look for the ones with a date-time stamp that corresponds with the time of the failure. Zip up these files and send them to QVS personnel for analysis.