ANSI Standard PL/B Language and Visual PL/B

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 Name and address list
• CF configuration file
• HC general codes file
• SS System security file
• TC Transaction codes file
• XC System control file
• User License
  
  
• Back to Standards Index

---

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

---

v1.10