Author Topic: Please DON'T use OPEN in SB+ Paragraphs (Reposted from SBSolutions)  (Read 4834 times)

precisonline

  • President
  • Administrator
  • Rock Star
  • *****
  • Posts: 1612
    • Precision Solutions
To my esteemed SB+ friends and colleagues... an impassioned plea if I may?

PLEASE avoid the OPEN statement in SB+ paragraphs!

To further explain:

SB+ keeps a list of file names and open buffers in section 2 of the common variables (named FILES.OPENED and FILEVAR(), respectively).  As you request a file in a screen, paragraph, tool, or using one of the SB+ file open routines ( SB.OPEN.FILE or SB.FILEVAR.S), SB+ looks up the name of the file in FILES.OPENED and returns the corresponding open file buffer in FILEVAR.  Under normal circumstances, this works perfectly.  If SB+ needs to open a file and it doesn't already have it open, it'll open it and the routine needing that open file buffer doesn't need to worry about the details.

The OPEN statement in the paragraph language looks like this:

OPEN exprn TO number

..where exprn is an expression (usually a quoted literal) and number is a number from 0 to 30 representing either the F.FILE buffer (if zero) or one of the FILEVAR buffers (if 1-30).  While this sounds like a good optimization - I mean, we open files in BASIC before we use them, right? - if there is another process that is using file buffer #30 for something, this OPEN will overwrite that file buffer without warning.  This will not create a problem until this process returns to its caller (who is expecting file buffer #30 to be what it was before the called process changed it!)  If the caller then writes something to file buffer 30, it'll go in the wrong place.  In the best case, things just don't work right.  In the worst case, GL information ends up in the customer file, customer information in the purchase file, purchase order information goes in the VOC, and you can expect to spend hours, days, weeks, and possibly months trying to clean up the disaster.

Certainly using OPEN sparingly is okay, right?  Personally, I don't think so.  Anytime you circumvent SB+'s file handling mechanism you run the risk of information showing up in the wrong place, and if Murphy is to be trusted, it'll be 10 minutes before the payroll run at the end of the month on a Friday.  Here's the risk:

If one process uses OPEN and it calls another process (directly or indirectly) that uses OPEN, there is nothing in between these processes to preserve and restore the file buffers when the called process exits.  If the caller then writes anything to a numbered file buffer after having returned from the called routine, the data will likely go in the wrong place.  (Remember, these variables are in section 2 of the common map (the "transient variables") and SB+ does not manage them like section 1 variables.)

Because it's so easy for one process to call another, and that other process being called might itself call dozens or hundreds of other processes, the research involved to ensure that one paragraph using OPEN doesn't call another paragraph using OPEN to open something different to the same buffer could be a time consuming nightmare.  And you can bet that somewhere there'll be someone who simply won't believe this can happen to them and they'll "forget" to do the research and then will have moved on a month before this completely destroys the company's data.

The overhead of doing file I/O using quoted file names, (i.e. READ @OTHER.REC FROM "CUSTOMER",@KEY) is - as best I can tell - so nominal that there is very little benefit to opening a file in an SB+ paragraph, though - as I hope I have explained - there is significant risk.  By avoiding OPEN in SB+ paragraphs, this risk is mitigated with nearly nonexistent performance implications.
« Last Edit: October 04, 2007, 08:03:42 AM by precisonline »
-Kevin
Accidents "happen"; success, however, is planned and executed.