MMCC MASTHEAD




MMCC's PL/B notes
  •    Notes home
  •    Intro
  •    History
  •    Article index
  •    MMCC Standards

    v1.10
    • Mid-Michigan Computer Consultants, Inc.
    509 Center
    Bay City, Michigan
    Sales (989) 892-9242             Support (989) 686-8860

    ANSI Standard PL/B Language
    MMCC Programming Standards
    NOTE TO OUR READERS
    This web resource is written for our own use. But we feel strongly that the PL/B language should be shared with the software community. So feel free to use this at will! BUT PLEASE... if you find errors or omissions or have a better way to do something. TELL US! Dialog helps us all. Send e-mail to: support@mmcctech.com

    MMCC STANDARD SYSTEM FILES


    MMCC software is written in a systematic way. Most of our systems include a handful of files which are very similar if not exactly the same. These include:

    AL FILE: Name and Address List

    The "AL" file is not entirely consistent from one system to another. The name, however, is commonly used for member files, customer files, and address list files. (The name came from "address list").

    Most systems which have an AL file have some of the same general processing routines in the I/O include unit. For example, there are routines to handle names, street addresses, and related things. In most cases these are very similar from system to system.

    As a standard, names are stored in the file in the format:
        lastname,firstname
    or
        lastname^firstname
    The idea is that the file can be directly indexed on the name and it will come out in alpha sequence. Because the name is compressed, unlike it would be if the last name and first name were separate fields, the index key can be shorter.

    One of the standard routines in the I/O module will swap the name based on the first comma or the first "hat" (^) character. The "hat" takes precedence over comma. So if a comma must be in the name but is not the splitter, you can put the "hat" at the point you want to swap the names.

    Back to     Standards Index

    CF FILE: Configuration

    Most systems include a "configuration" file. This file contains the client name and various system constraints and settings.

    Most records in the CF file are encrypted using a proprietary algorithm.

    Each system has an "xxxxNAME" program which lets us insert the name and other factors. These items are then encrypted.

    There are user programs provided to maintain settings that users can change.

    Back to     Standards Index

    HC FILE: General codes

    Many of our systems include an "HC" file. This is a general file for maintaining common lists of "codes". The name came from "Homes Codes" in our first PC system, for real estate, back in the mid-80's.

    The key to the HC file is typically: 
    HC_CLASS      DIM    2
HCGROUP       DIM    8
HCRECODE      DIM    1
HCCODE        DIM    6
    The HC_CLASS was intended to provide a high level grouping to codes. In fact it's almost always "**".

    The HCGROUP organizes groups of codes, such as owner types, carpet options, appliances, units of measure, state names, etc.

    The HCRECODE was intended to be a record code within the group. No system uses it. It's always blank.

    The HCCODE is the actual code value.

    Most systems have a general purpose loadmod to manage lists of codes. We also normally put a "HC CODES" program on the menu which is a shell to call the loadmod for general use. The loadmod could also be called by specific programs if appropriate.

    The code groups are identified in the XC file rather than in the HC file itself. (That was done before secondary indexes were so easy.) You can get a list of all HC code groups by just looking in the XC file for records which start with HC.

    Most systems were written to internally define the primary groups of codes from the programs. We originally thought to let users define their own groups, but a real use for that never came up.

    In most of our systems, the MASTER program, or in the MENU program, will check the HC file insure that all of the required code groups are identified in the XC file. In some cases we'll even fill in some basic individual codes in the HC file itself. Usually we ask the clients to do that.

    Some common examples of HC codes are:

    AUTO-PAY: Auto pay methods
      CA Cash
      CC Contract by Credit Card
      DA Dues by EFT
      DC Dues by Credit Card
      BA All by EFT
      BC All by Credit card     		ARH-TYPE: A/R transaction types
      LT-FEE Late fee
      SALE   Manual sale
      OPEN-B Opening balance
    PETBREED: Pet breeds
      GS  German Shepherd
      YIP Little yippie dog
      DOB Doberman     		STATES: States
      AK Alaska
      AL Alabama
      AR Arkansas
       etc.


    In practical use, the HC file allows the programs to be written at the abstract level and allows the user to control many selecction lists that we'd otherwise hard code. In the example above, for Pets, we would most likely present a combo box for the user to select a pet code from. The combo is populated at runtime by whatever is int the HC file under PETBREED. If more breeds need to be added, the user can do that.

    One other note. The loadmod (which is just about the same in all our systems), includes a routine to load combo box.

    Back to     Standards Index

    SS FILE: System Security

    The SS System Security file is used in several of our packages. Originally we used the same general concept but coded the specifics into each system. A few years ago we began to convert that to a standard set of routines that will work in any of our packages.

    The security modules are built as INCLUDE units and a PLFORM which are stored in the SUNDB folder. We will not go into details here for the sake of (what else) security. The modules are documented in the code.

    See more about this in the     security article.

    Back to Standards Index

    TC: Transaction codes file

    Most of our systems which have Accounts Receivable components include a TC file. This is a simple file identifying all the ways that the system can accept money: Cash, Checks, Visa cards, etc. The system doesn't care what is in the file, but every money transaction must be associated with a transaction code.

    The TC record contains a description as well a use codes, colors, and accumulators for daily, MTD, YTD and last year values.

    Some systems also contain a TT file which is the Transaction code totals file. During daily or monthly proccesing, the TC records are written to the TT file with a date and time stamp. That gives a history of transaction code usage.

    Back to     Standards Index



    XC FILE: System Control File

    The XC file is a general purpose file for storing just about any small data items. The file took it's name as the "index control" file where we stored the results of an INDEX run. This way we could come back at any time and see the date, time and results of the last index run made under program control. (See the     xxxx8802 program for more information on that one!)

    The XC file has a very simple structure. The key is basically a 13 byte string. It has fields, but we usually just pack up the 13 byte XCRECKEY string before reading, writing or updating.

    The XC record has several fields, but the most commonly used field is the XCDESCR. It's about 78 bytes long (depending on the application system). We normally read the XC record and unpack the XCDESCR into a list structure. We later do a PACKKEY to put the list back into the XC record before updating.

    Originally we used the first two bytes of the key to define the type of reccord. That's still done to some degree, but it's not as consistent as it once was. The keys are unique and meaningful enough to be self describing and self documenting.

    One of the most common XC records is program option strings. The key to these records is normally something like PRxxxxxxxxnpp.
    PR tells us that the record belongs to a program.

    xxxxxxxx is the name or other identifier for the program which owns the record. It may be the full name and may be part of the name.

    n This is the number of the option string. Most programs have one option string. Some have several option records.

    pp is the port number. This allows each port to have it's own option set.
    There are many other uses of the XC file. We try to always make the key easily identified by inspection. At the worst case you may have to search the source library for a system to find the literal used to create the key.

    The XC file has an extra routine in the I/O include module called XC_UPDATE. This little routine looks at the XCNIF flag to decide if the record needs to be updated or written. It makes coding the option update in a program very easy.

    Back to Standards Index



    USER LICENSE

    A user license process has been developed which allows an encrypted license to be e-mailed or otherwise distributed to any user. Similar to the concept used by Sunbelt, the user gets a name string uniquely identifying them plus an encrypted string of characters. Each user system using the license has a loadmod to update the license and to check its validity.

    The license is created by a utility program in the UTIL-PLB folder and system. There's an ANSWER and MASTER program in that folder plus a MENU. The Menu includes the create license program.

    The license concepts are documented in the source of those programs and will not be discussed here.



    See more about this in the     software license article.

    Back to Standards Index

    © 2001 mmcc All Rights Reserved.

    Report problems or suggestions to support@mmcctech.com