Latest News
Performance Improvements at Point Of Sale - A Guide to Getting the most out of your 4690 System. It is clear that many of the IBM 4690 POS applications could use an overhaul. But who has the time? And where would one start? |
| How to Configure the QConnect DYNAKEY File |
|
Purpose of Document Purpose of Document This document provides basic concepts for programming commands used to configure the DynaKey peripheral on any POS terminal with the IBM Supermarket Application. The configuration (text) file created through the use of these commands is saved under the naming convention of DYNAKEY.XXX, where XXX is the terminal number. The default application name is DYNAKEY.000. Any terminal that does not have a specific DYNAKEY.XXX file assigned to it will use this default application. All DYNAKEY.XXX files will reside in the "ADX_UDT1" file directory on the IBM store controller which is configured as the Master File Server. The DYNAKEY.XXX file allows the customer to dynamically change the definition of a series of dynamic keys located adjacent to the DYNAKEY screen. Depending on the state of the application at any point in time, the key definitions could be different. Human Factors Considerations in Designing DYNAKEY screens The following suggestions are made in the interest of increasing screen useability and consistency:
DESC="->Key Name" (Ex: DESC="->Quantity") DESC="Menu >>" (Example: DESC="Departments >>") DESC="->FunctionKey >>" (Example: ->Quantity >> " What commands cause the display and key definitions to change? This change can be intiated from several different sources:
When an application begins, the STATE command always puts up the first screen. The STATE command is associated with a unique state value and is executed anytime that particular state value is opened. A new state is generated by the application. In a standard IBM application, different states may make certain keys invalid or require the use of unique key sequences. DYNAKEY layouts associated with a particular state are displayed each time that specific state value is opened (see the section " Can I prevent a reset of the DYNAKEY display " for the one exception to this rule). The INPUTS parameter specifies the DYNAKEYS to be displayed whenever the specified STATE is entered. The DESC parm is also displayed in the upper left corner of the DYNAKEY display. Example: STATE=10 DESC="**** ITEM SALES ****" INPUTS=G1,G2,G3,G4,G5,G6,G7,G8 In this case, when state 10 is entered, keys associated with groups 1-8 are displayed on the DYNAKEY screen. In addition, the descriptor field, "**** ITEM SALES ****", is displayed in the upper left corner of the DYNAKEY screen. A GROUP command is generally called by a STATE or another GROUP command. The example above shows a series of groups being called by a STATE command. Similarly, a GROUP command can call other GROUP commands. Example of a GROUP calling another GROUP: GROUP=100 DESC="SUPERVISOR MENU" INPUTS=G101,G102,G103,G104 In this case, GROUP=100 (G100) represents a DYNAKEY which has the SUPERVISOR MENU descriptor. When the operator presses this DYNAKEY ("SUPERVISOR MENU"), descriptors represented by G101, G102, G103, and G104 are displayed as the new DYNAKEYS. In addition, the phrase, "SUPERVISOR MENU" is displayed in the upper left area of the DYNAKEY screen.
Example:
Example: GROUP=3 DESC="TOTAL" DATA=81 INPUTS=G11,G12,G13,G14 GROUP=500 DESC="ENTER COUPON AMT" DATA=%,80 INPUTS=G501,G502 NEXT=G3
How do I determine the order in which the keys will be displayed on the screen?They will always be displayed in the order in which they appear in the INPUTS or LIST parameters. How do I change the Description posted alongside a key? Use to the DESC parameter associated with the display of a particular key and change that descriptor. Note that the descriptor length is limited to a total of 20 characters. When this key is pressed, the DESC string will be written to the upper left area of the DYNAKEY screen unless a state change takes place simultaneously. In this case, the DESC field of the STATE command will take precedence. How do I set up a dynakey to act like a regular application key? Use the FCODE command. The FCODE must be defined to be the function code that is given to the application by the standard IBM application. These codes are normally shown in the Planning Guide for any given application. These codes would be listed in a section dealing with the keyboard layouts used by the application. This FCODE would be referred to by other statements as Fxx where xx is the function number . Example: FCODE=61 DESC="SIGN ON/OFF" For this example, the text "SIGN ON/OFF" would be displayed when that key became posted on the DYNAKEY screen (the result of a STATE command or an INPUTS parameter using F61). The code "61" would be sent to the application if that particular key were pressed by the operator. Note that any data entered by the operator prior to pressing the DYNAKEY associated with the function code would also be sent to the application. Since no INPUTS parms are specified in this case, any change in the screen would be caused by the expected STATE change. Entry of the Sign On code would normally cause a state change and display of a new screen associated with the new STATE. Example: FCODE=75 DESC="QUANTITY" INPUTS=G301,G302,G303,G304,G305,G306 In this case, if the operator keys in a quantity then hits this DYNAKEY, the quantity entered by the operator followed by the "75" function code will be sent to the application and the INPUTS parms will be ignored. If no data is entered by the operator, nothing is sent to the application, but the DYNAKEY screen will now display the DYNAKEY groups represented, in sequence, by G301, G302, etc. How can I generate a string of keys to be sent to the application? Use the GROUP command and the DATA parameter to do this. The group number is used to make the group definition unique. The DATA parameter defines what function codes are sent to the application. Successive key codes are separated by commas. These codes are normally shown in the Planning Guide for any given application. These codes would be listed in a section dealing with the keyboard layouts used by the application. This GROUP command would be referred to by other statements as Gxx where xx is the group number . Any keyboard data would precede this data stream. Example: GROUP=2 DESC="GIFT CERT $ 50.00 " DATA=5,0,0,0,94 In this example, depression of this key would cause a series of keystrokes to appear as if the operator had entered a number, 5000, followed by the Miscellaneous Tender key. How can I use DYNAKEY to send keystrokes in addition to numbers I have keyed? Normally, any numeric data entered from the keyboard prior to a DYNAKEY entry is followed by the DATA codes specified. If the keyed data should go elsewhere in a DATA sequence, a "%" character should be used to specify where the keyed numeric data will be inserted. Example #1: GROUP=44 DESC="KEY CUPN AMT HERE" DATA=80 In this example, when this key is hit, data from the keyboard is sent to the application followed by an "80" function key (ENTER). If no data is keyed, only an "80" function key is sent to the application. In this example, no NEXT or INPUTS statement is specified. This example implies that a state change will cause the next display to occur. Example #2: GROUP=65 DESC="MFR COUPON $" DATA=65,1,9,1,85,%,80 INPUTS=G20,G21 In this example, when the DYNAKEY is hit, the % symbol specifies that data from the keyboard is sent to the application after the "85" key and before the "80" (ENTER) key. If no numeric data is keyed by the user, only the data up to the "%" location (65,1,9,1,85) is sent to the application and the keys specified by the INPUTS statement are displayed.. How can I define a DYNAKEY to enter an exact amount from a balance due? Use the +R0 parameter with the DATA entry as below. Note that the balance due amount due will be displayed immediately to the right of the DESC field on the DYNAKEY screen. Note that the balance due information can be obtained two ways. A special Bal Due driver can provide the exact balance due to DYNAKEY. This requires a special User Exit to implement, but is more accurate. If the driver is not available, the Bal Due comes from the last amount displayed in the 2x20 area of the display. Example: GROUP=11 DESC="EXACT AMT $ " DATA=+R0,91 In this example, the "+R0" data parameter substitutes the balance due from the application as if an operator had keyed it. This number is then followed by the "91" key (Cash). How can I define a DYNAKEY to round up a balance due? Use the +Rxx parameter with the DATA entry as below. Note that the balance due will be displayed immediately to the right of the DESC field on the DYNAKEY screen. Note that the balance due information can be obtained two ways. A special Bal Due driver can provide the exact balance due to DYNAKEY. This requires a special User Exit to implement, but is more accurate. If the driver is not available, the Bal Due comes from the last amount displayed in the 2x20 area of the display. This is useful in providing common payment amounts offered by the customer. Example: GROUP=9311 DESC="$ " DATA=+R100,91 In this example, the "+R100" data parameter substitutes the balance due from the application and rounds it to the next dollar as if an operator had keyed it. This number is then followed by the CASH key(code 91). How can I define a DYNAKEY to add a specific amount to a balance due? Use the +xx parameter with the DATA entry as below. Note that the balance due plus the "xx" amount will be displayed immediately to the right of the DESC field on the DYNAKEY screen. Note that the balance due information can be obtained two ways. A special Bal Due driver can provide the exact balance due to DYNAKEY. This requires a special User Exit to implement, but is more accurate. If the driver is not available, the Bal Due comes from the last amount displayed in the 2x20 area of the display. Example: GROUP=9311 DESC="$ " DATA=+1000,92 In this example, the "+1000" data parameter substitutes the balance due from the application and adds ten dollars as if an operator had keyed it. This number is then followed by the CHECK key(code 92). How do I define a DYNAKEY to cause a new screen to be displayed? This is done using the INPUTS parameter on a GROUP or FCODE statement. The items in the INPUTS list are displayed on the DYNAKEY screen in sequence in which they appear in the list. Example: GROUP=3 DESC="FOOD STAMPS >" DATA=93,81 INPUTS=G41,G42 In this example, pressing this key will send data to the application (codes 93 and 81), then display GROUP 41 and GROUP 42 on the dynakey screen. Can I display different DYNAKEY screens depending on whether data is keyed?Yes, you use the NEXT command. The NEXT command must be used in conjunction with the % sign. The % sign specifies where data, if keyed by the operator, is placed in the sequence of information. If data is keyed by the operator, the command sp ecified by the NEXT instruction is actually EXECUTED, not simply displayed. If no data is keyed, the statement behaves as it normally would without a NEXT statement. If no operator data is keyed, all data from the % sign onward is truncated from the string and the INPUTS command is executed. Two different results can be had using the NEXT command: Case 1: If no data is entered by the operator, all data in the string from the % statement on is truncated and sent to the application. In addition, the INPUTS are displayed. Example: In this example, if the operator keys no data, group 20 sends the data string: "100" to the appl (no state change occurs). The INPUTS are then displayed which cause Group 21 to be displayed, prompting the operator for the check account number. Note that, since no % is used in the group 21 sequence, the keyed data will preceed the "90" command. The sequence of operation in this example is: Group 20 is displayed on dynakey screen, dynakey 20 is pressed, 100 is sent to the application (no state change occurs), group 21 is displayed, operator keys data, presses DYNAKEY 21 key: keyed data, 100,1,78 is sent to the application (no state change occurs), group 25 is displayed with "enter check $" prompt, keyed data, group 25 key is pressed: keyed data, 92 is sent to the application (state change occurs). Case 2: If the NEXT command is used with the % statement and data is entered by the operator, the full string of specified DATA statements and keyed data is sent to the application. In addition, the DYNAKEY specified by the NEXT statement is executed and any associated DATA statements are also sent to the application. Example: In this example, Group 20 sends the data string: 100,xxxxx to the application, where xxxxx represents operator-keyed data. The NEXT command executes GROUP 21, sending the data string "90,1,78" to the application. Since this statement is executed, Group 25 is displayed, prompting the operator for the amount of the check. Note: The user should be aware that in any of the above situations, the data sent to the application could result in a STATE change that would override either the expected display of the INPUTS or the execution of a NEXT statement. How can I prevent the display of sensitive information on the customer screen? Normally, data written to the printer will also be displayed on the simulated customer receipt tape on the DYNAKEY display or, alternatively, on the Customer Information Display (VGA). The DYNAKEY file offers a way to prevent display of certain print lines. Suppression of display of CID data is toggled on by entries in the DYNAKEY.xxx file. For the case in which a particular dynakey initiates suppression, a ",10" is put at the end of the DATA string. Two examples follow: GROUP=32021 DESC="TENDER TILL REPORT" DATA=100,91,10 GROUP=9504 DESC="GIVE MONEY BACK" DATA=0,94,10 Examples of dynakey definitions that do NOT trigger CID data display suppression follow: GROUP=32021 DESC="TENDER TILL REPORT" DATA=100,91 GROUP=9504 DESC="GIVE MONEY BACK" DATA=0,94 The ",10" string is not sent to the application, but is used internally to signal QCONNECT to suppress future writes to the CID. This suppression will be in effect until a trigger to redisplay is seen by the QCONNECT emulator code. CID redisplay is triggered by either the scan of an item or a DYNAKEY is hit that does not suppress CID display (has no ",10" at the end of its definition). The customer should be aware that, the CDIFILE (or QCDIFILE) offers another way to suppress the display of certain print lines. This alternative method may be simpler to implement. Please refer to the CDIFILE sample available on web site, WWW.QVSSOFTWARE.COM. Look under HELP files to find this sample. In short, a parameter is available to be entered into the CDIFILE which will allow an entire print line to be suppressed from display on either the DYNAKEY or Customer Information Display (CID) if a particular phrase is contained within that print line. Can I define more than 8 keys to be displayed when a DYNAKEY is pressed or a state change occurs? Yes. In this event, DYNAKEY displays the first 7 keys, then automatically creates an 8th entry, the MORE key. When the MORE key is pressed, up to 7 more entries are displayed, along with the MORE key. If there are more DYNAKEYS to be displayed, they continue to be displayed in a similar fashion each time the MORE key is hit. On the last page of DYNAKEYS, pressing the MORE key causes display of the first page of DYNAKEYs and so on. Can I cause display of lists of information on the dynakey? Display of lists is done using the LIST parameter. This feature is often used to show the cashier the item or department code for a variety of produce. The list to be displayed is contained in a file kept on the Master File Server store controller in directory, ADX_UDT1:. Each line of text within the list file can contain up to 36 characters. The DYNAKEY screen is capable of displaying up to 24 lines of text. The text can be displayed in either upper or lower case. If the list file contains more than 24 lines of text, the eighth dynakey will automatically become a <<MORE>> key. Depression of this key will display a second, third, fourth, etc. screen of text. On the last screen of text, a MORE key will cause re-display of the first screen of text, etc. To exit the list file screen, you must press a keyboard key, not a DYNAKEY. Normally, the CLEAR key (defined on the keyboard) would cause a STATE command to update the DYNAKEY definitions. Example: LIST=51 DESC="MENS TOILETRIES" FILE=DEPT50.LST The LIST command identifies the LIST number, the description to be used when they DYNAKEY is displayed on screen, and the name of the file to be displayed. The LIST command would normally be called as part of a STATE command or an INPUTS or NEXT statement on another DYNAKEY definition. Example: GROUP=50 DESC="NON-FOOD" INPUTS=L51,L52,L53,L54,L55,L56,L57,L58 The GROUP command calls for the display of 8 LIST dynakeys (L51-L58). Contents of a sample LIST file, (DEPT51.LST): 510 - Toothpaste 511- Shaving Cream 512 - Toothbrushes 513 - Razor Blades 514 - Anti-Fungal Cream Is there a way to easily define a series of keys that may be referenced from many different sources? Use the INLIST command. This simply provides an easy way to reference a commonly-used DYNAKEY display. The INLIST, once defined, can be easily referenced. Example: INLIST=10 INPUTS=G1,G2,G3,L1,L2,L3,F1 It may be referenced as follows: GROUP=55 DESC="MAIN MENU" INPUTS=I10 In this case, when the Group 55 DYNAKEY is pressed, the INPUTS defined by the I10 INLIST will be displayed. Do the DYNAKEY commands have to be defined in any particular order? Only in one case: The LIST commands should come at the end of the DYNAKEY.XXX file preceded by the STATE commands. Can I prevent unnecessary reset of the DYNAKEY screen? Only in certain limited conditions. Customers have been annoyed when a scan of a check causes the application to re-open an already open state. This causes redisplay of the "home" screen, something the customer did not want to have happen. For this limited circumstance, this redisplay can be prevented. The command to prevent the re-display of the DYNAKEY screen when the CURRENT state is re-opened is set when any DYNAKEY with the HOLD_PROMPT parm is hit by the customer. The
parm is part of the string of data that calls a DYNAKEY screen which you do not want to be unnecessarily reset. The parm is invoked as follows: HOLD_PROMPT=YES Example: GROUP=9206 DESC="->ENTER CHECK AMT" DATA=92 HOLD_PROMPT=YESThe need for this option was found in the Supermarket application when a check was scanned by an external pin pad. For some reason, this act generated an unlock/lock command, reopening IOPROC to the same state. To prevent the unwarranted screen change, this parm was added. It must be used as a parm for any DYNAKEY that can take you to a screen that you do not want to be reset if such a lock/unlock were to occur. This state is reset under either of the following conditions:
How can I make Dynakey behave differently on different terminals? The standard way to implement different dynakey displays on different terminals within a store is to have dynakey files on the controller which are unique for a particular terminal ID. The default DYNAKEY file is named DYNAKEY.000. If you have a terminal which will be designed to behave differently based on its terminal address (ex: Pharmacy terminal), a unique dynakey file can be created with the name, DYNAKEY.xxx (where xxx represents the terminal ID). Normally, just a few changes in dynakey behavior are called for on some of these specialty terminals so the rest of the dynakey file for that terminal would be the same as the default. The store has the burden of creating multiple dynakey files for the different terminal tasks within the store. There is an alternative method that you may prefer. Using this method, only one DYNAKEY.000 file is created. Within that file are conditional statements that implement different dynakey screens based on variables that have been DEFINED when the CDIFILE was processed for that terminal. Please refer to the QVS web site for documentation (sample CDIFILE). In general, the variables are DEFINED based on either the terminal number (TERM_NUM) or the store number (STORE_NUM). Once those defines have been created, DYNAKEY statements within the DYNAKEY.000 file can be activated based on if, then, else logic. An example follows. This example assumes that the variables used within this example have been set when the CDIFILE was executed by the terminal during terminal initiation. EXAMPLE: #if ((MANHATTAN) || (LONG_ISLAND)) then INLIST=5 INPUTS=G3000,G3001,G3002,G3003,G3004,G3005 #else INLIST=5 INPUTS=G4000,G4001,G4002,G4003,G4004,G4005 #endif In addition to the variables defined during the CDIFILE execution, the global variables TERM_NUM and STORE_NUM are available for use. The #ifelse statement is also available for use. "If" clauses can be nested. This feature provides the ability to define DYNAKEY behavior chain-wide for all stores in one DYNAKEY.000 file. ============================================================================== SAMPLE DYNAKEY FILE This sample file is in use in the field and apparently has been tested with a specific application. There may be some errors and some definitions that are never referenced, but it is as good a place to start as any. FCODE=62 DESC="TAX EXEMPT ORDER" |