Terminal Concentrator FAQs

What are the memory and disk requirements of TC?

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.

What are the current limits on number of terminals for TC?

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

What are the technical differences between the various TC versions?

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)”

What are some examples of how TC is used in customer environments?

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.

How do I do a terminal concentrator trace in a 4690 environment?

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.

How do I do a terminal concentrator trace in a windows environment?

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.