Newsflash
|
InSight! 1.0 - 'Experience Full Control of POS Terminals and Store Controllers'! It is now possible to monitor, remote control, and retrieve vital statistics and data from POS Terminals. Manage loss prevention, hardware service, development, testing, help desk, network managment and more with InSight! |
| QConnect DOS Overview |
|
| Documentation - QConnect | |
General DescriptionQConnect is a QVS product that runs in a DOS environment and allows non-IBM retailterminals to run IBM Supermarket and General Sales Applications that are designed to run on the IBM-proprietary 4690 OS. The terminal sales application programs designed to run in the 4690 terminal operating system environment should run without requiring any modification to the program or even recompilation. In order to run without modification, the QConnect emulator program intercepts all operating system calls or requests from the application and performs the required service in the DOS operating system environment. In addition, peripheral devices such as printers, displays and keyboards which are accessed via 4690 driver service requests such as open, close, read, write, etc. are rerouted to appropriate DOS drivers to perform the desired service, reporting results back to the application as if the service were performed in the 4690 OS environment. There are some limitations to the functionality of the QConnect DOS system vs. the IBM 4690 Operating system. DOS is a single-tasking system but 4690 OS is a multi-tasking system. Due to this difference, the QConnect DOS system does not support multiple sets of peripherals attached to a single base unit such as the IBM 4683 or 4693 POS terminals models 1 and 2. Also due to memory restrictions and other multitasking requirements, Java applications are not supported by the QConnect DOS product. In addition, the QConnect product is normally built for a specific customer or particular POS hardware vendor so if the customer decides to change the hardware configuration of the terminal, the customer should contact QVS to verify support for the changed configuration. The QConnect product is designed to be used in the 4690 store system environment. It is assumed that the store configuration will include at least one IBM 4690 store controller or an appropriately configured Windows server with the QVS Controller Services product installed and active. Refer to the appropriate QVS documents for complete information on the server products. Refer to IBM’s 4690 OS documentation for information on its configuration and operation. QConnect allows customers who have a variety of retail terminal hardware to run a common checkout application on all their terminals. In response to a customer request, QConnect can be adapted to run on most any Intel PC platform. Currently, QConnect can execute in the following terminal types: Wincor: BEETLE L BEETLE M NCR: 7052 7450 7451 7452 IBM: 4694 SurePOS QConnect can be installed on and loaded from a hard drive. It can be installed on and loaded from the Store Controller. If the terminal is set up to boot DOS from its Hard Drive, QVS provides an initialization sequence to the customer. This load package contains the necessary components of DOS, all needed drivers for the attached peripherals, and the QConnect emulator program. If the QConnect implementation requires an image to be loaded from the controller, QVS will provide that image and the appropriate loader to load that image into the terminal at boot time. A variety of peripherals can be attached to the QConnect DOS terminal. One major attachment popular with many customers is the NCR Dynakey. This unit contains an LCD display, a keyboard and a set of 8 keys alongside the display whose function can be dynamically modified as the IBM application progresses. This unit provides a significant improvement for training and for saving operator keystrokes. In addition, the following RS-232-attached devices are supported, depending on the terminal model: IBM 4610 printer NCR 7875-compatible Flatbed Scanner/Scale Metrologic MS9540 Hand-Held Scanner Wincor 2x20 display Wincor POS Keyboard NCR Parallel Port-attached 2x20 display NCR Serial Port-attached 2x20 display NCR 32 Key keyboard NCR 56 Key keyboard NCR 64 Key keyboard NCR Big Ticket keyboard Most any Pin Pad Model NCR compatible Hand Held Scanner IBM compatible Signature Capture Devices The following devices are supported only on the IBM terminal attached to an RS-485 port: IBM 50 Key Keyboard IBM Single or Dual 2x20 Display IBM-compatible scanner/scale IBM-compatible hand held scanner IBM 4610 printer IBM Mod 3 or 4 printer IBM Cash Drawer The following devices are supported attached to their appropriate ports: Cash Drawer (sometimes connected to the printer or special terminal port) Hand Held scanner (attached to the “wedge input” on the dynakey) VGA Monitor (color or mono) Configuration of PeripheralsSome machine configuration takes place as the terminal boots. Configuration files and executable code used during the terminal initialization process are provided by QVS and should not be modified. The bulk of the terminal configuration is done as the terminal loads and reads a file from the controller. The file on the master store controller, ADX_UDT1\CDIFILE.000, contains most all the configuration information needed. It specifies the port to which most of the peripherals are attached in addition so some other peripheral-specific information. QVS provides the customer with a working CDIFILE.000 file, along with instructions on which COM port to use to connect each device. A copy of a sample CDIFILE.000 file is in Appendix A of this document. Study this to get an idea of the information that this file contains. If there are reasons why a store would install a mix of QConnect terminal types, a method is available to allow differing terminal types to co-exist. All terminals, as they load the QConnect configuration information from the controller, check to see if a CDIFILE.nnn exists where nnn is their terminal number. If not, they use the CDIFILE.000 default file. So, if you are trying to load some terminals attached to the store controller that require a different configuration than the others, you simply create a CDIFILE.xxx file for each different configuration that you require. Example: To configure terminal 21 different than the others, create a new CDIFILE and name it C:\ADX_UDT1\CDIFILE.021 on the store master controller. Configuration of the KeyboardQConnect must be configured to provide to the IBM application the correct function code when a particular key is pressed. These codes are specified in the C:\ADX_UDT1\KEYMAP.000 file on the Master Store Controller. An example file for a POS Keyboard is shown in Appendix B. Examine that file for a description of the layout of the keyboard and for an example of how function codes are defined for each key. In the unlikely event that you are using different keyboard types or you are configuring keyboards to be laid out differently in the same store, you can create unique KEYMAP files by using the specific terminal address as the file type instead of the default, 000. Example: you could create a different keymap file for terminal 21 by naming the differing keymap file: C:\ADX_UDT1\KEYMAP.021. As terminal 21 initializes, it would read that file instead of the default file, C:\ADX_UDT1\KEYMAP.000 on the master store controller. The KEYMAP files on our web site have more detailed information on key assignments: http://www.qvssoftware.com/help_file-QCDOS.html Configuration of the QConnect Terminal under 4690 OSIn order for the terminal to load the IBM application, the application name must be set in the4690 terminal configuration file. The application name is the only parameter used in that file. In order to properly set up and load the QCONNECT terminal, a terminal definition for that terminal number must be created. A legacy terminal should be defined. It has to be a valid IBM terminal type and it has to use a valid keyboard layout (even if this information is ignored by the QVS emulator). When the valid terminal load for that terminal is set up, the application name and location must be valid since this is required by the QConnect setup. In addition, that terminal number must be defined in the LAN CONFIGURATION section of the IBM system configuration screens. Both of these configuration definitions must then be activated without error and the controller rebooted for the system changes to take place. Maintenance of QConnect emulator codeAs fixes are provided or new functions are added, QVS may provide code updates from time to time. In that event, the QConnect emulator module will need to be updated on each of the terminals. If you boot your QConnect terminals from an image located on the Store Controller, QVS provides a new image that replaces the old image. As each terminal is booted, the changes are then loaded. If you boot your QConnect terminals from a hard drive, the emulator can also be updated in an automated way. As each terminal boots, one of the tasks of the QConnect startup is to examine the master store controller to see if an updated C:ADX_UDT1\QMAINT.DAT file exists. If so, that file is downloaded and its contents are installed on the terminal. A more detailed description of the installation and use of this file is contained in Appendix C. Generally, the only module that receives fixes or new functions is the QConnect Emulator modules. QVS will provide you an updated QMAINT.DAT file to be used in updating all your terminals. APPENDIX A: Sample CDIFILE.000| |+ CDIFILE.xxx SAMPLE dated 3/16/99 | APPENDIX B: Sample Keymap.000 File/* Row #1, left to right APPENDIX C:QConnect Maintenance for Terminals Booting from the Hard DriveSUMMARYThis article provides details about the maintenance facility used for DOS QConnect terminals attached to an IBM4680 Controller and booting from the terminal hard drive: · How maintenance is detected and applied · Potential problems that can affect the application of maintenance · Recovery procedures for terminals with misapplied maintenance MORE INFORMATIONHow maintenance is detected and applied: Maintenance in the QConnect environment is accomplished by use of a archive (ZIP) file that is transferred to the terminal and expanded. ZIP file contents: Typically, the zip file will consist of the modules to be upgraded on the machine and an optional batch file that can be used to perform a variety of tasks when maintenance is installed. If files to be replaced are in subdirectories under the root directory, the zip file should contain the same directory structure. For instance, if maintenance needs to replace the files C:\AUTOEXEC.BAT and C:\RETAIL\VECTOR.BAT, then the ZIP file should be built with subdirectory paths as well. This can easily be done by creating a directory (e.g. MAINT) on your machine and the subdirectory RETAIL under it. Place the new VECTOR.BAT in the RETAIL directory and the new AUTOEXEC.BAT in MAINT. From the MAINT directory, build an archive using the argument <-Pr> for PKZIP or the equivalent for other archive programs. The archive must be named QMAINT.DAT. If you want to include a batch file so that commands can be executed when maintenance is applied, the batch file must be named QMAINT.BAT. Note that since most terminals do not have a VGA display or PC keyboard, QMAINT.BAT should be written to run without operator intervention and should be thoroughly tested before distribution. Note that most Archive utilities compatible with PKZIP will work fine: however, remember that the DOS file system and the extract utility used on the terminal are not compatible with long file names. All file and directory entries archived must be in the “8.3” format, meaning no more than eight characters, followed by a period (.), followed by no more than three characters, and excluding any of the punctuation or special characters prohibited in the DOS environment. Please refer to the diagram below for the way that Maintenance functions in the terminal. Note that files prefaced with <R::> are controller files and those with <C:> are terminal files Terminal is Rebooted AUTOEXEC.BAT starts QConnect Does <R::ADX_UDT1:QMAINT.DAT> Exist? NO YES Does <R::ADX_UDT1:QMAINT.DAT> match <C:\QMAINT.CUR>? YES NO Start Transfer Input file: <R::ADX_UDT1:QMAINT.DAT> Output file: <C:\QMAINT.EXE> Were there READ errors during transfer? NO YES Create file <C:\QMAINT.BAD Were there WRITE errors during transfer? YES NO QConnect exits, returns control to AUTOEXEC.BAT Does the file <C:\QMAINT.BAD> exist? NO Does the file <C:\QMAINT.EXE> exist? YES NO QConnect executes normally Control Transferred to RUNMAINT.BAT Test QMAINT.EXE for Integrity Is Archive OK? YES NO Delete <C:\QMAINT.BAD> Reboot Rename <C:\QMAINT.EXE> to <C:\QMAINT.CUR> Reboot Exit to Command Line 1 Notes: 1. RUNMAINT.BAT is in control while files are extracted from the ZIP. If a new RUNMAINT.BAT is needed, then it should be archived under a different name and copied on top of RUNMAINT.BAT by an included QMAINT.BAT. The QMAINT.BAT should then execute all of the remaining steps that RUNMAINT would normally execute and reboot the system without returning control to RUNMAINT. This will avoid problems that can occur in DOS if a batch file is changed while it is being processed. 2. QMAINT.BAT can be used to perform a variety of operations, such as moving and/or deleting files, running tests, etc. Potential problems that can affect the application of maintenance: #1 – Maintenance fails to transfer If a large number of terminals are loaded at the same time or there is an intermittent problem with the Network, maintenance may fail to transfer. If errors occur, then the terminal is reloaded and the process repeats. Since the bulk of terminals will properly retrieve the maintenance on the first iteration, the conditions will be much improved for the few terminals that need to request maintenance a second time. Note that reducing the size of the QMAINT.DAT file as much as possible significantly reduces the risk of error, as well as shortening the time required to apply the maintenance #2 – Maintenance file is corrupt There remains the chance that the QMAINT.DAT installed on the controller is corrupt. The archive is tested before any files are extracted. If the archive is found to be invalid, the update will be ignored and the terminal will load and run the pre-existing version. Note that the terminal does not reboot and re-try, since a corrupt QMAINT.DAT on the controller would cause the terminals to continuously reboot until the offending file is removed. 1 Unzip all files in Archive, preserving directory structure Was there a QMAINT.BAT in the Archive? NO YES Call QMAINT.BAT Rename <C:QMAINT.EXE> to <C:\QMAINT.CUR> Delete <C:\QMAINT.BAT> (if it exists) Reboot Recovery procedures for terminals with misapplied maintenance: There are two possibilities here: That the basic infrastructure (AUTOEXEC.BAT, QSNBTEMU.EXE, and/or RUNMAINT.BAT) is corrupt and no updates will load, or that you simply want to uninstall the latest version. In any event, the customer should keep a QMAINT.DAT that includes all of the files on the terminal. Alternately, QMAINT.DAT could be unzipped (using the –d command to preserve the directory structure) onto an archive machine and updates could be applied to that machine. Once the updates are in place, a new QMAINT.DAT could be created which contains the base code and any deltas you wish to install. In the first failure scenario (no updates will apply), the only solution is to re-initialize the terminal using the PCMCIA card that is used for new terminals and the full QMAINT.DAT. In order to uninstall the latest version, the simplest method would be to create a QMAINT.DAT which contains all files necessary to transform the latest release into the prior release. For instance, if an update contained QSNBTEMU.EXE and you want to back out that release, you would create a QMAINT.DAT which contained the prior (known good) version of QSNBTEMU.EXE. When this update is applied, the files will be overlaid with the prior known good versions of the files |
|
| < Prev | Next > |
|---|