Welcome Guest | My Membership | Login

The Six Million Dollar Open


Article

In the opening to the TV show, Six Million Dollar Man, they promised to rebuild him - better, faster, and stronger. This occasional series, the Six Million Dollar _____ will offer suggestions on how to elevate mvBASIC commands by making them better, faster, and stronger. We have the technology.

Cold Open

Consider the OPEN command:

OPEN 'ACCOUNTS.RECEIVING' TO B ELSE NULL

I hope I don't have to point out why opening a file to a single letter variable is bad. This example gets extra demerits for using a letter that doesn't even appear in the table name. Likewise, using NULL in the ELSE clause will suppress all error reporting. While there are edge cases for doing that, generally we want to know when an OPEN fails. Unfortunately, this command will compile, making your life harder.

Since we can't rebuild and replace the actual OPEN command, our best course is to wrap the command in code which makes it more robust and consistent. Have a look at this alternative [Figure. 1 and Figure. 2] .

BP OPENER
001 subroutine OPENER(D.LEVEL,FNAME,MODE)
002 * by Charles Barouch (Results@HDWP.com)
003 * as seen in International Spectrum Magazine
004 include BP FILECORE.INC
005 if unassigned(FILE.STATUS) then FILE.STATUS = ''
006 *
007 OP.FLAG = 1;* Yes, we should open the file
008 if D.LEVEL = 'DICT' then
009   * Don't open it if it is already open 
010   locate('DICT-':FNAME,FILE.STATUS,1;FS.POS) then
011     if FILE.STATUS<2,FS.POS> # '' then OP.FLAG = 0
012   end
013 end else
014   locate(FNAME,FILE.STATUS,1;FS.POS) then
015     if FILE.STATUS<2,FS.POS> # '' then OP.FLAG = 0
016   end
017 end
018 if MODE = 'RESET' or (OP.FLAG) then
019   open D.LEVEL,FNAME to FILES(FS.POS) then
020     FILE.STATUS<2,FS.POS> = 1
021   end else
022   call CALL.AUDIT('OPENER',FNAME:' did not open','SHOW,ABORT')
023 end
024 return
 
BP FILECORE.INC
001 * by Charles Barouch (Results@HDWP.com) 
002 * as seen in International Spectrum Magazine
003 common /FILECORE/ FILES(200), FILE.STATUS
004 *
005 equ DICT.ACCOUNTS.RECEIVING.FILE to FILES(1)
006 equ ACCOUNTS.RECEIVING.FILE to FILES(2)

Why is This Better?

Any errors generated by any OPEN command will be logged the same way. This will make audits (internal and external) much easier and improve your ability to fix your system. As a bonus, the common area will keep the file open for the lifetime of the user's session, making future requests to open faster because they will only be confirming status, not doing a real open. Additionally, the common area, combined with the equates, will keep the name of the file handle consistent through all of your programs. That's a huge win when debugging and documenting.

While those three benefits are significant, there's a bigger win. If you want more information, like the name of the calling program, the port number, the time and date, or anything else, you can add those features to this one routine and you gain that information in every program that previously would have had to perform an open separately. You could also make your version of the OPENER program smart enough to auto-create workfiles when they are needed.

Got your own wrapper for a MultiValue BASIC command or TCL verb? Send us your Six Million Dollar make-overs so we can share them with the community. Email editor@intl-spectrum.com.

 

# # #          # # #          # # #

 

Related Articles

  • From the Inside July/August 2017

    We're already planning for the next Spectrum conference. If you haven't yet seen the information for the 2018 Spectrum, it will be April 23rd-26th at The Henderson in Destin, Florida. This is a new venue for the conference.

  • MultiValue Database and Framework Benchmarking

    Benchmarking has been a topic that's been around for several years, but nothing really has been provided to the MultiValue Community to use. I've heard many different reasons for the lack of benchmarking, so I'll go through a few of them.

  • Expanding Your Toolkit: JSON vs. XML

    MultiValue strings are an excellent way to express data compactly. In a world where, increasingly, every system seems to need to talk to every other system, it is useful — and desirable — to have as many communication formats available to you as is reasonable. Last time out, Bennett Barouch gave you a good look at JSON. This time he's pulling back the curtain on XML.


Return to top