STANDARDS AND SYSTEM PERFORMANCE

PURVEYOR has been written with the goals of making the application easily modifiable and extensible by the client administrators and users and of keeping your system performance level up, even in the busiest times, so that your hardware dollars can go towards maximum utilization of database resources, not towards making up for sloppy or unimaginative programming strategies. This extends to making modifications as easy as they can be and providing online programming documentation and help to administrators and end-users.

SERVICE-ORIENTED ARCHITECTURE (SOA)

• all major parameters and file variables are loaded at logon to enhance application integrity, speed of execution, and to create the basis of a common "language" within the application's programming
• all major parameters can be maintained by the administrator and have descriptions associated with them, as well as being documented in the Purveyor User Manual, though consultation with Racine Enterprises is advised before changing those with which one is not familiar
• all major utilities are standard throughout the application
• administrator-defined, menu-driven file maintenance is provided
• Purveyor is modular and each module can be brought live one at a time
• vertical (application) and horizontal (utility) variables, functions, and procedures are kept discrete and separate
• Purveyor is rich in reusable code such as subroutines and compiler "includes"
• all Purveyor programs and subroutines are cataloged allowing customized programs to be easily copied into a separate custom program file, modified, compiled, and cataloged in the Master Dictionaries thus allowing a simple installation of custom code throughout the system.
• menus are simple scripts which can be easily maintained by the administrator
• the Racine Enterprises BB4GL provides a common user-interface throughout. The BB4GL is a set of powerful Rapid Application Development (RAD) tools which REI designed and developed independently to accelerate the development of the REI Purveyor Software application and to offer as a separate product, apart from Purveyor, as well. While we did develop these independently, we did so from our experience with other systems and pulled heavily from best practices there.
• a full library of statements, commands, and "code snippets" (compiler $includes) which differ from Pick platform to Pick platform can be switched and recompiled with the tweak of a single parameter
• both field-level and screen-level help is administrator-customizable
• software issues can be automatically reported to Racine Enterprises by Outlook e-mail with an automatically captured and attached screen print which hopefully illuminates the issue to support and debugging Racine Enterprises staff
• spooler assignments may be specified and stored for each user by the administrator
• security may be specified by program and menu and may be maintained by the administrator using a simple screen
• documents may be easily imported into MS Word, NotePad, and WordPad
• Purveyor-provided reports may be executed, edited or created new, re-run, and stored safely by the everyday user, at both the Pick/mvBase/Purveyor level and MS Access/Excel
• a safe spooler menu is available to all users while a more powerful one is available to the administrator
• "power"-users can download their own data from Purveyor files, independent of the Report Writer
• most "master" files such as customer, vendor, product, inventory, route, etc. can be maintained using the UPD common user-interface file maintenance and screen generation tool from the BB4GL
• function keys may be entered and stored on Purveyor and reloaded as necessary without the need for programming at the user end
• a global application calendar can be maintained by the administrator
• administrator-definable fields exist on every major file, allowing users to create their own parameters for their querying, reporting, and updating purposes.
• all data entry is entered through one BB4GL input subprogram which allows arrow key, mouse, and a special Edit mode to edit text, besides the normal Insert and Replace modes. This also provides a standard user interface throughout the application and the BB4GL, including the ability to stop any program when at a prompt or to log off entirely when at a prompt. The mode is indicated either by a message at the very bottom of the screen or, occasionally, in some programs (especially the EP editor and the Stacker/Report Writer), by a small 'i', 'r', or 'e' to indicate the mode. <ctrl>-X will clear most fields while <ctrl>-Y will invoke the special edit function in the field input/editor. <ctrl>-R gives context-specific help. These are already specified by function keys. All data entry can be audited through this subprogram, if desired, by the administrator. Changes made to this subprogram will affect all users.

USER INTERFACE STANDARDS

• While they are context-sensitive, most programs can be exited by using X, or the ESCape key, or END,(to exit or back out of a program), O (logs off from all of the 'Bar' menus), <ctrl>-O (logs off from all of the 'Bar' menus and the 'Pull-Down' menus and almost any data entry field except "cruising' and verification (Ok? (Y,N)) fields), Exit and Logoff (from all of the 'Pull-Down' menus), clicking Close (from the Tree menus), or OFF (from the Stacker/Build in Report Writer). Also, some data entry programs which have product entry will use the DELETE key to delete a line item. This is not always implemented and must be tried on an application by application basis.
  
• The HELP, CLEAR, LKUP, EDIT, END, DELETE, DRV, BCK, OFF, and STP keys are autoprogrammed into each user's AccuTerm session function keys at logon. The administrator can configure additional permanent function keys on a user by user basis (or change or remove these as modifications necessitate). HELP brings up the PRINT.SCREEN tool which allows printing the screen, e-mailing to support, entrance to a limited inquiry menu, and contextual and overall help in a documentation browser. CLEAR clears the data entry field for redoing an entry. END clears the field then enters "END", which should exit from the immediate program segment back to the one before, to the beginning of the program, or out of the program entirely, depending on context. INQ clears the data entry field then enters a "?", which is the standard entry for bringing up scrolled lists of items. These items can serve as a Radio Button or as a selection screen for multiple entries, depending on the data entry field's requirements. DELETE serves to delete line items from data entry grids. These are short-cuts to what could, conceivably be entered at the keyboard but which are so oft used that it is worth shortening them. DRV works with the UPD processor to drive through associated files. BACK works with the SUI menus to back up one menu, which is especially helpful on the Pull-Down Menus. OFF logs the user out of Purveyor. STP stops the current program, returning to the one that started it, usually the menu. They are arranged so that the most destructive (END, DELETE, OFF, and STP) are placed out to the right to avoid inadvertent hitting of the wrong key. (People doing data entry typically enter a great amount of data using their right hands and use their left hands to hit common function keys. Thus, the common ones are F1-F5 which is where we place the most oft-used function keys.)
• B generally means begin and P often means Print, but in data entry screens, it can mean P to post (update). Many data entry screens finish by answering a (Y,N) question to Post. T indicates report output to the terminal or PC. R can mean Return to the previous screen, having the same meaning as B to go Back a screen. V means to void (exit without posting/updating).
• ! or <ctrl>-P invoke print-screen, help, support, and inquiry, on almost all fields, while ? invokes lookups, especially on coding files, such as department codes, tax jurisdictions, and ship vias. This can also be invoked from the Purveyor-supplied standard function key, F1=HELP.
• All of the five menu types use the Utilities submenu: the B=Bar, D=pullDown, G=GUI Bar, M=Multiple Tree, and S=Single Tree menus, so this has become a standard user interface. I recommend the B=Bar menu for most users. It is the one I prefer, and not because it reminds me of "happy hour" :-) ; I find that it is the quickest through which to navigate and the least prone to create errors due to over-sensitivity on the keyboard.
• The program file and item name generally appear in the upper left hand corner of the screen for reference for development, debugging, and support purposes.
• Record lock messages are displayed showing user names of locking process and locks are never set in inquiry programs.
• Spooler settings are displayed for each user at the top or bottom of each screen.
• We are getting very close to accomodating mixed case entry throughout the system. This has been a gradual process. Many programs had to be changed and tested. Any such issues still remaining will be treated as a "bug" and fixed.
• Single character inputs require a carriage return but not when "cruising" through multiple items in a listing, such as in lot selection or product, vendor, and customer lookups, to name a few. These only require a single character to mo(ve forward and backwards through selections, without a carriage return. Likewise, entries in Bar and Pull-Down menus, navigation in the UPD multi-value window, and in lookup scrolling windows do not require a carriage return. Most update validations, e.g. "Ok (Y,N)?" do or should require the same termination characters as the multiple character entries, mentioned below.
• Multiple character entries generally require a carriage return, a TAB, up or down arrows, page up or page down, an ESC, or a Shift-TAB to terminate, and, in fact, we would probably consider it to be a product flaw (bug) if one were encountered which didn't require these. This standard helps to prevent mistaken entries, allows the replacement of incorrectly entered text, and helps forward, backward, and escape navigation. (Note: Shift-TABbing/Backtabbing (to go back a field) is available on all data entry screens.) <ctrl>-X will clear most fields while <ctrl>-Y will invoke the special edit function in the field input/editor. <ctrl>-R yields context-specific help.
• There are cursor- and mouse-controlled field-editing routines which provide a common user-interface for editing all fields.
• The lookup/scrolling routines for selecting from lists are standard throughout.
• Similar to the simple scrolling routines, the product, customer, and vendor routines provide the same interface with extended functionality particular to their function.
• The customer and vendor lookups function much like each other and both can lookup on their own or jump into scrolling at the touch of a button.
• The product lookup is consistently implemented throughout the application and provides a common user-interface for product and inventory lookup.
• Generally-speaking, if a field has a high-lighted letter, it is not only a Hot-key, but can also be clicked on by the mouse. Any underlined, non-blinking field can also be clicked by the mouse. Using AccuTerm, a little hand appears when the mouse may be clicked for use.
• Generally, a Reverse Blinking message on the screen indicates Updating, Processing, or Purging.
• Generally, a simple Blinking message indicates Printing, though if a message contradicts this, the message is correct.

SPEED

• Named common blocks allow file addresses, global constants, authorizations, and terminal control attributes to be read in at logon only, avoiding hundreds of thousands of unnecessary, useless disk I/Os.
  
• Local common blocks allow data common to a programming module (such as an order record in sales entry) to remain common (global) to all called routines used in sales entry, eliminating the overhead associated with passing (and thereby copying) arrays
  back and forth between calling and called programs.
  
• Dimensioned arrays are used whenever appropriate to lower CPU requirements to extract data from multivalued records.
  
• Dynamic arrays are used whenever appropriate to lower CPU requirements to extract data from multivalued records when few extractions are necessary.
  
• Overall, care has been taken to see that redundant processing is not performed, especially within loops.
  
• a high degree of screen storage and repainting at the client level lessens the overhead associated with complete screen changing and repainting, especially when jumping in and out of applications for inquiry.
• Well planned, efficient, multipurpose data structures allow for the extraction of data based on a strong cross referencing strategy that requires a minimum of file searching. This is a key advantage of PURVEYOR.
• the use of mvBase/Pick/MiltiValue systems provides low overhead because they use hashed file systems whose speed does not degrade with size increase. Multi-valued data structures can improve this also when used effectively. They also have indexing for speed, although Purveyor uses its own 4GL indices for the purposes of greater data integrity and better administrator maintenance. Also, their variable-length fields are physically part of the records instead of pointers to BLOBs outside of a fixed-length record structure. Actually, all of their fields and records are delimited, variable-length of virtually any length.

• Payables and receivables are extractable by parent or individual customer for any report or screen by prestored, system maintained lists that eliminate most needs for file searches in accounting. Sort times are radically reduced.
  
• Repeated inquiries on the same customer, vendor, or parent become simple, cheap, and quick, allowing high level analysis onscreen at the time questions are raised.
  
• Products are cross referenced by line and category.
  
• A separate Product file exists that acts as a product catalog and as a superset of all items in inventory.
  
• Each branch has a separate inventory file, allowing ease of branch level reporting for physicals and analysis.
  
• These product and inventory file structures allow for lower overhead both when the entire inventory must be searched or when an individual item is accessed. If inventory related data is not necessary, as in the case of pricing reports, the inventory file does not have to be accessed, only the product, since it has the descriptions.
  
• Descriptive product attributes such as description, line, alternate part number, keyword, vendor part number, etc. are stored only on the product record, keeping disk storage requirements to a minimum and disk seek times to a minimum as well.

• a file exists which documents each file on the PURVEYOR system, giving a quick overview of what its purpose is.
• each program has a description on line 2 of what its use or purpose is.
• program variables are usually given descriptive names to lessen confusion and the resultant chaos.
  
• each file attribute is documented with description, help lines, and checking for data entry purposes, and valid answers.
• user attributes are available on every file, with a program that can be run from the utility menu to extend the number of them when necessary.

• one major factor in data integrity on Purveyor is that users are led through data entry fields prompt-by-prompt, forcing them to deal with important issues rather than just automatically leaving it all to defaults because it is simpler data entry. Defaults are often not good enough; that's the reason we have fields.
• the method of loading file variables, program control variables, authorizations, and screen control variables is much more than just a speed enhancement, it is a database integrity check every time someone logs on.
• standards are enforced system-wide for aliasing file and control variables, so that INVOICEFILE always refers to the INVOICE file, for instance. This is a powerful programming management device which allows for faster development and higher quality development. These standards provide a common vocabulary throughout the system, providing a frame of reference without as much reading and study overhead. This lower learning curve improves quality because fewer serious mistakes are made.
• module common blocks contain lists of the programs which use that common block, allowing the list to be selected for searching, programming, and compilation, though those doing serious develoment work should be advised that doing full file searching for those program names is both more fool-proof and is also is practical today because searches run very quickly on today's computers..
• all programs may be aborted by using the break key except those involved in crucial processing. Each of these has special programming to defeat 'breaking' out until completion.
• "behind the scenes" as well as command-line TCL & Pick Access queries can optionally be completely monitored and audited by the administrator, as can all data entry inputs, either by user or overall. Overall menu commands and security overrides can also be audited.
• the wide use of the UPD processor helps ensure data integrity because it is based on dictionary parameters. These parameters are off limits to all but the administrator.
• like the %type function in Oracle PL/SQL, the REI 4GL functions OCV and ICV can be used to validate data for output and input, respectively, using the same dictionary items used for validation in the UPD processor (and the same advanced logic in ICV) and which are used for outputting reports as well.
• ICV validates numeric, date, length, valid answer lists, Basic language subroutine call validation, pattern matching, file/record existence, and it also padds record ids to their required length, filled with zeros before file/record existence and returns it to the program that way.. This can be invoked in quiet, verbose, or verbose-interactive modes. It can handle multi-value fields.
• OCV performs output conversion based on dictionary conversion codes, ensuring consistent display of data. It can handle multivalue fields.