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-0430.cfm v1.0


plb-t010.cfm
 

ANSI Standard PL/B Language and Visual PL/B

REVDATE / REVISION - Application version control



There are numerous ways for a programmer to keep up with the versions of a program which is under development or in maintenance status.

MMCC wanted an automatic method for immediately showing the compile date of any program ever written. The method we chose was to INCLUDE in every program a small snippit of code (REVISION.PLS) containing a variable showing the date the program was compiled. This include defined the values:
   REV      INIT      "0.0"
   REVDATE  INIT      "mm/dd/ccyy hh:mm:ss"
            TITLE     "mm/dd/ccyy hh:mm:ss"


Old PL/B (prior to version 9)
All compiles were done via the batch file "ACB.BAT". Within that bat we would execute a small PL/B program called REVDATE (.dbs / .plc). That program would clock the current time and then write the small REVISION.DBS file, which was the include file.

This was done before and after the complile. The after version would compute the elapsed time and display that so we could get a feel for how fast the compiler was.


PL/B version 9 and later
When PL/b version 9 came out, the methods used to run the little REVDATE program stopped working.

HOWEVER... The new version of PL/b included GETMODE instructions that allowed us to retrieve information about the compile of the program being executed.

The REVISION.DBS include file was changed to have the instructions to retrieve the PL/b compiler information when the program was executed. This was how it should have been from the beginning.

Under version 9 and after, the ACB.BAT files was changed to leave out the REVDATE program. The REVISION.DBS and .PLS includes were changed to run the new instructions then create the variables for the revdate.

After the one-time change to the ACB.BAT, and copying the REVISION code from another system that is already running version 9 or better, the change is transparent.


v9+ LOADMOD WARNING

In most programs REVISION.DBS appears at the beginning of the program code. When execution begins it starts at the top and goes forward. Revision is ALWAYS run first.

LOADMODS are different. They have one of more starting points. When a LOADMOD is called the caller names the starting point. That means that the REVDATE code included at the beginning of the module is NOT executed.

The solution is to include another copy of REVISION with each entry point.

WARNING 2

The REVISION.DBS module contains work area definitions. If a loadmod has more than one entry point, this will have to be addressed since you'll get a compile error on any includes after the first one.


DETAILS

PL/B PROGRAMS PRIOR TO VERION 9
To make this automatic, we wrote a small program called "REVDATE.DBS" which creates a file called "REVISION.DBS". (It also creates another file for including in COBOL programs, of which we once had many.) The "REVISION.DBS" file contains the following lines:
   REV      INIT      "0.0"
   REVDATE  INIT      "mm/dd/ccyy hh:mm:ss"
            TITLE     "mm/dd/ccyy hh:mm:ss"
	
Including this little module allows the program to simply display the variable REVDATE to show the date and time when the program was last compiled.

The REVDATE program is a SUNDB86A command line program. It's run as part of MMCC's standard compile BATCH file. That means that every compiled program automatically gets an include which shows the time that the program was compiled.

Our practice has been to standardize our character based screen format. The top two lines are always reserved for program indentification. The program name appears in the upper left corner. The current date and time are in the upper right corner. The "REV DATE" is always on the right end of the second line.

When moving to the GUI environment, we continue to use the REVDATE program. We also use a BATCH procedure for invoking the compiler and REVDATE is part of that procedure.


FOR PLBWIN THERE ARE BETTER WAYS
    The PLBWIN compiler has provided this and more information automatically as well. Having this information, our REVDATE procedure could be dropped.

    We continue to use REVDATE, however, because REVDATE also provides some little date checking analysis tricks. Like seeing if the computer's clock has gone backward... and calculating the elapsed time since the last time REVDATE was run. We find these features useful.
To retreive the compiler information within a program compiled under PLBWIN, you use the GETMODE statement. We have included several variables in the COMMONWK.PLS include unit which is also used in every program.
..... items found in COMMONWK.PLS:
    $PROG_NAME      DIM   20     Name of source code file
    $PROG_SERIAL    DIM   10     Serial number assigned by compiler
    $PROG_STAMP     DIM   15     Timestamp when program was compiled
    $PROG_VER       DIM    5     Version of the compiler
    $PROG_REVDATE   DIM   20     Work are to build our own edited revdate

..... instructions placed in individual programs
..... (We actually include this in the "ssssOPEN.PLS" include units)

         GETMODE   *PROGNAME=$PROG_NAME
         GETMODE   *PROGSERIAL=$PROG_SERIAL
         GETMODE   *PROGSTAMP=&PROG_STAMP
         GETMODE   *PROGVER=$PROG_VER
         UNPACK    $PROG_STAMP,ccyy,mm,dd,hrs,min,sec
         PACK      $PROG_REVDATE, mm,"/",dd,"/",ccyy," ":
                                  hrs,":",min,":",sec

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