MMCC MASTHEAD
Mid-Michigan Computer Consultants - Bay City, Michigan
 


CONTENTS       (old style)
Mid-Michigan Computer Consultants
509 Center
Bay City, Michigan

Sales (989) 892-9242
Support (989) 686-8860

Plb-0100.cfm v1.0


plb-t010.cfm
 

ANSI Standard PL/B Language and Visual PL/B

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
STANDARDS           rev 9/02/2016

Overall Organization

SOURCE FILE FOLDER ORGANIZATION

Where is everything?

The first thing you need to know is where to find things. By mid-2016, only one programmer is handling all PL/b work and that's being done at the main development office. There are two computers there. One Dell with Windows XP Pro is dedicated to desktop work and PL/B. The second is an HP Windows 10 dedicated to MMCC's web site work. The Windows 10 does have all of the development tools for PL/b, but is synchronized with the XP machine only every month or so.

This article deals primarily with the PL/b organization. Although that is on the XP machine, this discussion could be for any machine. The environment is easily duplicated and, in fact, can be found on MMCC's laptop as well.

SUNBELT VISUAL PL/b Suite

MMCC uses Visual PL/B from Sunbelt Computer Systems of Tyler, Texas. Sunbelt can be found at sunbelt-plb.com.

The entire Sunbelt suite will be found in the SUNBELT folder off the root of drive C: on each of MMCC's development computers. This is the standard location used by Sunbelt's installation procedure.

Under the SUNBELT folder is a folder for each general release of PLBWIN. Again, this is the Sunbelt standard. These folders are PLBWIN.87, PLBWIN.91, PLBWIN.94D, etc. where the number designates the release.

Under the general release folder, like PLBWIN.94D, you will find 3 more folders: CODE, DEMO, and RPTWRT. These are standard folders set up by the plbwin install procedures.

Note that there was a major demarcation between general releases 8 and 9. Although MMCC has software running in versions, the majority of systems were converted to version 9. All of the MMCC folders and shortcuts reflect the release through pathing and directories.

The primary difference between version 8 and 9 is the indexed file structure. Version 9 uses a NEW index. It is not backward compatible with 8. The version 8 index, however can be both read, written and updated by version 9. Provided the file is built by version 8, or the index is created with the version 8 SUNIDXNT utility program, it can be used on both systems.

FOR THIS REASON, MMCC has continued to use the version 8 index utility on all systems. That makes the files compatible with both versions with only limited loss of features, which we don't use anyway.

The entire SUNBELT folder can be copied from the root of one computer to the root of another computer. You can use Sunbelt's own install procedure to officially install the system, but by providing specific path in command lines, you don't need to register the thing. Just copy the folder to your computer.

MMCC-WIN folder
MMCC-WIN is the main folder containing ALL of the systems that MMCC has written. Each system is in its own sub-folder. These folders include (among others):
ADDRLIST General Address list used by many clients
base-plb "Stub" system once used for starting a new system. Rarely used now
CHS Central High School Store (still used as of 2015)
HOMES Real Estate Software: Freddy and Freddy Mobile
imt-2200 Obsolete Intermodal Trucking: Replaced by internet based system.
ODA Outdoor Adventures - largest and most important PL/b system
PJ-WIN Diesel Fuel Shop system. Windows version (there's a DOS version too)
PRJ-WIN Obsolete Project Management system
PT-WIN Personal Checkbook and tax system
SHOP-SYS POS Point of Sale system. Used by Homespun Peddler
SUNDB Common utility routines and includes used by all of the above systems.
UTILmmcc Various older utility programs - version 8
UTIL-plb Obsolete General utility programs - version 8
UTILPLB9 Primary General utility programs - version 9
Contains a number of example programs.
Also contains various sub-folders.


SUNDB sub-folder
The SUNDB folder is mentioned now because it is special.

SUNDB contains all of the common source code INCLUDE units that are used across many application systems.

All programs, in every applications system, identify these common includes units by including the drive letter "Z:".

INCLUDE Z:COMMON
INCLUDE Z:TRAPNEW
INCLUDE Z:MMCCSERV

The compile procedure should either map drive Z: to the SUNDB folder or SUBST drive letter Z: to that folder. Alternatively, the SUNDB folder could be included in the PLBWIN.INI files path statements for the compiler.

 


MMCC-WIN
MMCC-WIN is a root level folder that contains a sub-folder for each application system.
For example:
c:\MMCC-WIN\ADDRLIST
c:\MMCC-WIN\UTIL-PLB
c:\MMCC-WIN\SHOP-SYS
APPLICATIONS: Each Application system is totally contained within it's own sub-folder under MMCC-WIN as shown above. The folder contains both source and compiled PLC's.

One exception is the HOMES system. There are sub folders under that one for the MLS-book processing (obsolete) and Freddy Mobile (still active in 2016). The regular FREDDY programs are stored in HOMEDATA by the compile bat file in the HOMES folder.

The Application folder also contains it's own compile batch procedure. This allows us to handle special cases. For example, the HOMES folder contains a sub-folder called FREDDATA, which contains the PLC's. The compile procedure includes copy statements to move the compiled program to that folder.

DATA: Testing data files are organized under one of several master folders, such as:
\MMCC-DAT
    \ADDRLIST
    \PTSYSTEM
\MMCC-DA2
    \ODA-DATA
    \VOR-DATA

Each client's data is stored in a sub-folder under one of these root level folders. That folder contains a PLBWIN.INI file (usually with a different name) which provides a path to the PLC's which are in the source folder.

We usually create desktop shortcuts for testing client systems. We do similar shortcuts at the client sites. This is defined below in the Desktop Shortcuts section.

An example of the folder struture showing several clients for the POS system would be:
\MMCC-DAT
    SHOP-SYS
        AHEAVEN
        BSE
        DEMO
        FAB-FAIR
        PEDDLER


When installed at a customer site, EVERYTHING (source, data, plbwin runtime) is stored in a single folder.

Pulling test data
At most client sites a backup procedure is used to "zip-up" all text and isi files. That zip file can be sent to MMCC and restored to the testing folder on the local machine. This gives a full copy of the live data, just as fresh as the backup. That is done regularly.


Back to Standards Index

MMCC BACKUP PROCEDURES Our source code Backups are normally written to DVD. By organizing systems under the MMCC-WIN folder, that entire folder can be written to a DVD and get all of our systems. In actual practice we backup five folders on one DVD: MMCCMENU, MMCC-WIN, MMCC-DAT, MMCC-DA5 and MY DOCUMENTS.

The DVD backups are essentially COPIES of the files. There is no compression or special coding. These DVD backups are directly readable on just about any computer and we use them frequently for moving files around.

NOTE: On earlier Windows systems, if you just drag a DVD folder onto your desktop, the files may be copied as READ-ONLY since the DVD is, by definition, read only. If you find that files can't be edited after being copied from a DVD, you should check the attributes. If the files did, in fact, come over as read-only, you should explore to the folder, select ALL, look at properties, and turn off the "read-only" check box.

Note that we make several backup sets on DVD. The "WIN/DOC/DAT" set includes MMCC-WIN (source code), which includes the most volitile files. They change very frequenlty so the backups are run very frequently. The other sets are various data files, test data, client data. They are done less frequently.

The contents of each backup sets is listed in SGK's continuing TIME log files. Since those files go back a long way, there are many copies of these lists. A printed copy is in the white book on SGK's desk at home. Basically the organization is:
WIN/DOC/DAT
MMCC-WIN
MMCC-MENU
MMCC-DAT
MMCC-DA5
MY DOCUMENTS
Backups are done almost daily. Sometimes multiple backups are made in the same day. (Burning a DVD is relatively quick).

Virtually ALL backup DVD's have been saved for years. From a practical point of view only the most current are useful, but there have been times when very old backups have been used to see how something worked years ago.

Backup CD's are kept in multiple locations. The most current backup is kept by SGK on his desk. Other copies are at SGK's daughter's house. (When the main office was regularly used by staff, backup DVD's were taken there regularly. The staff now works remotely and the main office is always rented, so the old backups came to SGK's office.)

Anytime SGK is traveling, he takes his laptop, which has a full development system. Fresh backups are run for everything and that data is updated to the laptop. Backups are also updated to the Windows 10 computer at that time. All current backups go along with the laptop.

Because everything is burned to DVD+R then that DVD is locked by the burning software. Each DVD becomse a snapshot in time. You can go back many generations if necessary to get an older version of a program!

Back to Standards Index

WORKFLOW and INFRASTRUCTURE

Most development work is done at SGK's home office. The working environment is based on a Windows XP Pro system for PL/b desktop systems. A second Windows 10 system is used for internet systems.

These computers are wired to a wireless router that includes several ports for wired connections. Cell phones, laptops and other devices use the wireless option.

DROPBOX is used to pass information between all devices. When Dropbox withdrew support for Windows XP at the end of August 2016, our workflow was really messed up. The plan is to enable Windows networking between the XP and W-10 machines and use the Dropbox folder on the W-10 machine. XP will just write to that folder across the network.

We use Sunbelt's IDE for all program editing. We do not use this IDE to it's full potential with projects. Rather we simply open individual files as needed. Not great, but it works.

(YES WE KNOW... we're way out of date. The Visual PL/B IDE development environment is fantastic. One of these days we may have time to learn the other methods. It's unfortunate that Sunbelt does not have good manuals to explain the concepts and characteristics for these ideas. But that's another subject.)

Back to Standards Index

COMPILE PROCEDURES

Each system folder contains an ACB.BAT batch file. (The meaning of "ACB" has been lost over time. It's not significant other than being the standard name).

Each system may have an ACB-ALL.BAT as well. If it exists it will be a list of CALLs to the standard ACB procedure, one call for each program. You can run this procedure to compile everything.

Note that the ACB-ALL.bat procedure SETs an environment variable called ACSTOP=P. See the note below in the ACB.BAT procedure about the PRT-AC program.

An example of the Standard ACB.BAT file is shown below and described after the example: 

@ECHO OFF
echo ------------------------------------------------------------------
echo              PL/B WIN Compile Procedure - RBR-2200 / ODA   
echo ------------------------------------------------------------------

rem -----  Version 9 ---------- 8/12/2009

sundbsys REVDATE

subst z: c:\mmcc-win\sundb
subst

.... Change to 94d  4/25/2011
@ECHO on
\SUNBELT\PLBWIN.94d\CODE\plbCON \SUNBELT\PLBWIN.94d\CODE\plbcmp %1 %2 %3 %4 -ZG -ZT
@ECHO off
@IF ERRORLEVEL=4 goto BADRUN

sundbsys REVDATE


@ECHO 08-04-2014 Put a copy of the PLC into dropbox too.
copy %1.plc "C:\Documents and Settings\Stephen Kent\My Documents\Dropbox\ODA-PLC\%1.plc"

@ECHO 03-25-2015 Always copy ODA-MODS to dropbox.
copy ODA-MODS.PLS "C:\Documents and Settings\Stephen Kent\My Documents\Dropbox\ODA-PLC\ODA-MODS.PLS"



@ECHO ----------- acb using 9.3a 8/12/2009 -----------------
IF "%ACSTOP%"=="P" PRT-AC %1.EXE was OK
GOTO EXITIT

:BADRUN
IF "%ACSTOP%"=="S" PAUSE
IF "%ACSTOP%"=="P" PRT-AC %1.EXE compile error

:EXITIT

REM get rid of SUBST so it doesn't conflict with anyone's MAP
subst z: /d


The procedure starts with an ECHO signon.

REVDATE: This is a DOS style PL/B program. The bat file is run from a command prompt (DOS) window. It assumes that SUNDBSYS has been loaded and is running in that DOS session window. We start SUNDBSYS when the window is opened and then forget it.

Revdate is a tiny program that does a couple of things. First it writes three small code files which can be used as includes in all of our PL/B programs. Secondly, it looks at the previous value of the files and computes the elapsed time. We run a REVDATE before the compile and another one after.

The three files written by REVDATE are:
  • REVISION.DBS
  • REVISION.PLS
  • REVDATE.COP (left over from our COBOL days)

    The PL/B REVISION files contain two variables: 
    REV      INIT     "0.0"
REVDATE  INIT     "10/12/2005 12:24:08"
         TITLE    "10/12/2005 12:24:08"
    This whole thing goes back to the days before we could get the compile date and time from as part of the language. We needed some way to know when the program was compiled. Every program displays this value in the title bar so we can always know exactly when the program was last changed.

    map z: /d
    subst z: c:\mmcc-win\sundb

    The map z: /d is a hold over from when the SUNDB folder ran on the DOS machine and we used a 3rd party network to connect the machines. (In fact, we STILL use that network on some systems.) The MAP is just to get rid of the z: in case it's still mapped.

    The SUBST Z: C:\mmcc-win\sundb is the new technique in use since putting everything on the same computer. This allows our source to remain unchanged using the Z: to get include units.

    @ECHO on
    \SUNBELT\PLBWIN.87\CODE\PLBCON \SUNBELT\PLBWIN.87\CODE\plbcmp %1 %2 %3 %4 -ZG
    @ECHO off

    We turn on the echo just to be able to see the command for the compiler. The compile is run under PLBCON which allows us to run from the command prompt (DOS) window. We give the full path to both PLBCON and to PLBCMP.

    The %1 %2 %3 %4 are for parameters on the command line. On the command ACB SHOP1020 the SHOP1020 takes the %1 position and names the program. We can add additional compiler commands after that if we wish.

    The -ZG parameter tells the compiler to "Allow GUI statements". That may well be a default by now. We've used it since the beginning.

    @IF ERRORLEVEL=4 goto BADRUN

    The compiler sets ERRORLEVEL 4 if the compile fails. The IF statement jumps to the BADRUN label if the compile fails.

    If it's been a while since you read a .BAT file, the @ at the beginning of the line turns off the ECHO for the line regardless of the default value for ECHO.

    REVDATE
    IF "%ACSTOP%"=="P" PRT-AC %1.PLC was OK
    GOTO EXITIT

    When the compile is successful we fall into the statements above. We do a final REVDATE which also computes and displays the elapsed time for the compile. (The compiler tells us that now, but in the early days it did not and we wanted to know how long the compile takes.

    The IF statement checks to see if the environment variable ACSTOP is set to the value P. If it is then we want to print a line to LPT1 saying that the compile was successful. The PRT-AC program is one of the old DOS PL/B programs running under SUNDBSYS.

    After checking the print request, we jump to the EXITIT tag to wrap up.

    :BADRUN
    IF "%ACSTOP%"=="S" PAUSE
    IF "%ACSTOP%"=="P" PRT-AC %1.PLC compile error

    If the compile failed, control would have jumpped to the :BADRUN tag. We check the ACSTOP environment variable again. If it's set then we pause the batch job. The user can do a CTRL-C to kill the batch run or tap enter to continue. If he continues then we check the ACSTOP again and print the compile error line to LPT1 if it's set.

    :EXITIT
    REM get rid of subst to avoid potential conflict with MAP
    subst z: /d

    The :EXITIT tag is the common wrap up. We clear the SUBST to drive Z: using the /d parameter. This prevents it from conflicting with other batch files we might run. It also insures that the SUBST is not left over for other DOS windows.

    Back to     Standards Index

    DESKTOP SHORTCUTS

    We keep a number of short cuts on the desktop for the development machines. Typically we'll browse to the program in question and right drag a program name to the desktop. When we drop it we choose the "create shortcut" menu option. Then we can modify the properties as approiriate.

    Typical shortcuts include:
    • PLB Designer for working on forms
    • PLB Help shortcuts for both the compiler and the run time.
    • DOS window. (We find the one in START or START/ACCESSORIES and right drag it to the desktop and make a copy. We then change the START IN property to start at the C:\ root.)
    • System run short cuts for various user level systems. These are described next:
    For testing and for running on client machines we create PLBWIN runtime shortcuts as follows.
    • First we browse to the SUNBELT\PLBWIN.nn and find the PLBWIN application. We right drag that to the desktop and choose create shortcut. That gives us a base shortcut to the PLBWIN runtime.

    • With the shortcut on the desktop we modify the properties as follows by "TARGET" to specify the INI file to be used and by changing the "START IN" to the user's data folder. The properties would end up something like: 
          Target:   C:\Sunbelt\plbwin.87\code\PLBWIN.EXE -i plb-sgk.ini answer
    Start In: C:\mmcc-win\shop-sys\peddler
      On a user's system everything is stored in a single folder at the root. Each port would have it's own INI file with a unique port number (see the next section). The shortcut in this case would be: 
          Target:   PLBWIN.EXE -i plb-sgk-nn.ini answer
    Start In: C:\mmcc-win\shop-sys\peddler
    The "-i plb-sgk.ini", or "-i plb-sgk-nn.ini", on the target line points to the PLB INI file to be used for this shortcut. A typical INI file would be something like the following example. Note that the "SHOP_xxx" lines in this INI are unique to a given system. Each of our software systems uses these parameters to set some basic contidions.

    The most important system specific INI parameter is the xxxx_PORT line. This identifies the port number being used. In a multi-user system, each port would have it's own desktop shortcut which would point to a unique INI file. Each of those files would identify a different port number. We use this port numbering scheme within our programs. (And, sorry, the highest port number is 99.) 
    [environment]
PLB_TERM=ansi
PLB_SYSTEM=c:\SUNBELT\PLBWIN.87\CODE
PLB_PATH=c:\MMCC-win\SHOP-SYS;C:\MMCC-WIN\UTIL-PLB
PLBWIN_ICON=HOMESPNw.ICO
[SHOP-SYS]
SHOP_SYS=HSP
SHOP_PORT=01
SHOP_PORTNAME=Stephen's W/98 machine
SHOP_SUPERVISOR=Y
SHOP_HISTPATH=[
SHOP_HISTDRIVE=[
SHOP_PICPATH=[
SHOP_PICDRIVE=[
SHOP_FILEPATH=[
SHOP_DIAG=N


    Back to     Standards Index

    PROGRAM and FILE NAMING CONVENTIONS

    Almost all program and file names use the 8.3 naming convention from the DOS days. We've stuck with that because it works for us and is just about universial. As we move farther and farther away from the DOS days, some data file names are now longer.

    PROGRAM NAMES started with a very formal organization. The first 4 bytes identified the system, version and type of module. The last four bytes was the serial number and was organized in a somewhat functional way:
    • The first 2 bytes were the system like PD for dental, PJ for the diesel, FR for Freddy.
    • The 3rd byte was to be the version (0, 1, 2, etc.). That was never really implemented.
    • The 4th byte indicated the type of module being named: P was a program, I was an include unit, etc.
    • The last 4 bytes were the program number and they were roughly organized into functions. The 1000 series was maintenance, 2000's were reports, 4000's were daily procedures, etc.
    As we moved into the Windows world that formality has not been followed with new systems. Now the first few bytes define the system, but we don't worry about a version. Examples include "SHOP" for the point of sale system, "ODA-" for the resort management system, etc.

    We have continued to maintain the program number and functional series idea. But even that has eroded. In the DOS world it was very useful based on the way we did menus. The program number closely paralleled the menu from which the program was called.

    In the windows world menus are graphical and we have tooltips which allow us to identify the program name. We're much less rigid now.

    One thing that we do use is an "X" in a program name or number to designate a "loadmod". For example, ODAX20AR is a load mod in the ODA system.

    FILE NAME conventions have and continue to be well defined and closely followed. The name is made up of a three byte "CLIENT ID" followed by a 2 byte file type and a 3 character file ID.

    The file ID identifies the primary file in the first 2 bytes and secondary indexes in the third byte. When talking about a file we'll typically just call it by these letters: the FM file, the FMA file, the PM file, etc.

    For example, take the dental system:
    • xxx Client ID such as JAD, CEB, RWH.
    • D0 Dental data, version 0
    • xxx specific file:
          FM0 Family master
          FMA Family Master, alpha index
          PM0 Patient master
          DC0 Detail charges
    In more recent, Windows, systems the last 5 digits are not as tightly controlled, but they are consistent within any given system.

    The CLIENT ID concept is significant. Every CLIENT is assigned a unique 3 byte ID. All of their data files start with those 3 bytes. This allows us to put multiple client data sets in the same folder and still segregate them.

    When we execute the first program in a given system, the first thing it asks for is a System ID. That is the 3 byte Client ID. The program confirms that those files exist then stores the 3 byte ID in common. All programs then build file names using that common value for opening files.

    In many cases we'll put two data sets on a client's computer. One is named with the client's ID, the other is named TST for testing. For client "BAR", we can copy "BAR*.txt" to TST*.txt, index the TST files, and we have a testing data set. The client can execute the software and log on to either his live data or the TST data.

    Refer to the indexing program in the     standard programs section for notes on how to index those files.

    The old DOS programs gave the user the ability to set some standard screen colors. It was common practice to set the screen background color to something awful for the test system. This insureed that everyone knew just by looking if they were in the test data set.

    The Windows systems have limited color controls for the user to set. We do, in some cases, identify the TST data set in the menu and set the background color to a nasty red.

    Back to Standards Index


    v1.10

    • Write to MMCC Technical Support at:               Send e-mail to MMCC.
    MMCC - Technical Support
    600 W. Midland
    Bay City, MI 48708
    (989) 686-8860
    © 1997 - 2024 MMCC - All Rights Reserved