DI*21.0*42 (720)    BUILD (9.6)

Name Value
NAME DI*21.0*42
DATE DISTRIBUTED 1997-07-01 00:00:00
      Most cross-reference are not sensitive to the order in which they 
      are fired. For example, a regular cross-reference simply creates 
      an index entry based on the current field value, and has no effect 
      on other field values or other indexes. However, a trigger does 
      affect other fields, and will affect other indexes if those fields 
      are cross-referenced. For example, if an entire record is being 
      reindexed, a cross-reference on the .01 field might trigger a new 
      value into field 1. If field 1 is cross-referenced before field 
      .01, field 1's indexes will use the old value instead of the new 
      For a complete explanation, please read this description
      one that the .01 trigger will put there.
      When you create a new entry, you enter the values for the .01 
      field before any other fields (generally speaking), so the cross-
      references on the .01 field fire first. However, before this 
      patch, when reindexing a record FileMan always saves the cross-
      references on the .01 field for last. Using our previous example 
      of the trigger on the .01, this means when adding an entry the 
      cross-references on field 1 use the new value triggered by the .01 
      but when reindexing field 1's cross-references fire first, using 
      carefully. Because these changes are not backward-compatible, we
      the old value, and then cross-references on field .01 fire, 
      triggering the new value into field 1 but not affecting its cross-
      This effectively prevents you from writing code sensitive to fire 
      order that will work when reindexed. After a great deal of 
      consideration, we have decided that the fire order for the Set 
      Logic should always fire as if a new entry were being added; that 
      is, the .01 cross-references always fire first even when 
      reindexing. We decide the Kill Logic is firing in the correct 
      have taken time to explain the reasons and effects in detail. For
      order already; that is, the kill logic for the .01 should fire 
      last so that FileMan-compatibility is preserved by keeping a B 
      cross-reference on any record for as long as possible.
      The Merge package uses extensive reindexing when merging two 
      records together, and requested this change. This change made the 
      package easier to code, and has produced no visible side effects 
      at the test sites.
 Test Sites :
      more information on these changes, send email to
      Finder and Comma-Piecing Change:
      Houston VAMC
      The Imaging Project Team
      Reindexing Fire Order Change:
      Columbia VAMC
      G.FMTEAM@DOMAIN.EXT, or call Rick Marshall at 206-764-2283.
      Tucson VAMC
 Routine Summary :
      The following is a list of the routines included in this patch.
      The second line of each of these routines now looks like:
      <tab>;;21.0;VA FileMan;**patch list**;Dec 28, 1994
      Please notify us immediately if you experience any ill effects
 Checksums According to CHECK^XTSUMBLD:
   Rtn Nm   Chksum Before   Chksum After  Patch List
   ------   -------------   ------------  ----------
   DICF     7072808         7066780       17,27,42
   DICF1    5555141         5908138       42
   DICF3    6296720         9189474       17,42
   DIK      7325945         7352303       42
   DIK1     5820262         5943602       42
      from either of these changes.
      To test if the transport has been corrupted, you can use the
      "Verify Package Integrity" option.  This option is under Utilities
      under the KIDS menu.  It will compare the checksums in the build
      with the current checksums and list any that differ.
 Installation Instructions:
 NOTE any instructions that are different for 486 or Alpha sites.
      1.   Users ARE NOT allowed to be on the system during the
      2.   DO place TaskMan in a WAIT state.
      3.   These routines are not usually mapped on systems that allow
      it so you will probably not have to disable mapping.
      4.   Use the 'INSTALL/CHECK MESSAGE' option on the PackMan menu.
      Change 1: Finder and Comma-Piecing
      This option will load the KIDS package onto your system.
      5.   The patch has now been loaded into a Transport global on your
      system. You now need to use KIDS to install the Transport global.
      6.   On the KIDS menu, under the 'Installation' menu, use the
      following options:
            Verify Checksums in Transport Global
            Print Transport Global
            Compare Transport Global to Current System
            Backup a Transport Global
            Install Package(s)
            INSTALL NAME: DI*21.0*42
      7.   MSM Sites - Answer YES to the question 'Want to MOVE
      routines to other CPUs?'. Enter the names of your Compute and
      Print server(s).
      The Finder, like the classic DIC Lookup call, processes lookup
           AXP Sites - Answer NO to this question.
      8.   Rebuild your mapped set if necessary.
      9.   DO remove TaskMan from a WAIT state.
      values that contain commas specially. We have reduced the power of 
      the Finder's algorithm in order to buy a substantial performance 
      gain, and have introduced a new "C" flag to allow callers to get 
      the full power of the original algorithm when they need it. DIC's 
      algorithm has not been changed, which means DIC and the Finder do 
      not handle commas the same way unless you include the "C" flag in 
      your Finder call.
      The need to make this backward-incompatible change arises from 
      another difference between the classic DIC lookup and the Finder: 
      short-circuiting. In general, the Finder call was designed to 
      emulate the DIC lookup, but one feature of DIC caused a great deal 
      of confusion: the way DIC short-circuits its lookup whenever it 
      has possible matches. DIC rarely presents all of the matches 
      available, but instead at fixed points during the lookup will quit 
      early if it has any matches. This feature is designed to focus the 
      lookup on what DIC considers the most likely matches, but many 
      users report they find the behavior counter-intuitive.
      This patch changes two different features of FileMan in important
      For this reason, the Finder was designed to always locate all 
      possible matches, to avoid short-circuiting out of the lookup 
      early. Since the Finder always runs all relevant parts of the 
      lookup algorithm, it always pays the performance costs of those 
      parts. Comma-piecing, a powerful but expensive part of DIC's 
      lookup, was usually short-circuited out of DIC's main lookup, but 
      in the Finder, of course, is always run on lookup values 
      containing commas. Thus, with values containing commas, the Finder 
      is usually much slower than DIC.
      ways. The changes are to 1) how the Finder DBS call processes
      The Imaging project, in particular, discovered that the 
      performance cost was too much to pay, and asked the FileMan team 
      to change the Finder's behavior. Although comma-piecing is 
      documented (FileMan 21 Programmer Manual, pages 208-209, and 
      FileMan 21 User Manual, page 12 ("^ST,ADD" in part 3)), most users 
      polled do not realize the full power of this feature, but believe 
      it has a limited capability specific to names. Although the 
      FileMan team rarely considers making backward-incompatible 
      changes, in this case most experts were unaware of and therefore 
      commas in lookup values, and 2) the order in which cross-
      not relying on the parts of this algorithm that made it expensive. 
      In return for making this change, lookups at Houston VAMC 
      involving values containing commas passed to the Finder that used 
      to take 90 seconds now take 4. The sheer magnitude of the trade-
      off led us to reduce the power of comma-piecing Finder lookups to 
      what people have known about, while adding the "C" flag for those 
      who know about and need the full power.
      Most users and developers believe comma piecing is specifically 
      used with names, so that a lookup values like "DI,MI" will match 
      references fire during reindexing. Although these changes are NOT
      "DISTASO,MICHAEL" and "DISNEY,MICHELLE". In other words, the comma 
      in the lookup value stands for a real comma in the index value, 
      and a partial match is run on both the first and last names. This 
      is what the Finder has been changed to do.
      What comma-piecing does in DIC, what it did in the Finder before 
      this patch, and what the Finder does after this patch if the "C" 
      flag is passed is far more powerful. The comma stands for any 
      arbitrary string of characters followed by any punctuation 
      character. "DI,MI" then will match not just the values most users 
      backward-compatible, they have not disrupted sites we've tested
      expect, but also "DISTASO,XACHARY MICHAEL" and "DINNER WITH 
      MICHAEL". This is the principle behind the "^ST,ADD" example in 
      the FileMan 21 User Manual. This feature requires a tremendous 
      amount of processing, but yields far more flexible results, and 
      programmers are encouraged to use the Finder's new "C" flag when 
      Change 2: Reindexing Fire Order Change
      The order in which cross-references fire can be crucial. We have 
      at, and provide a great deal of benefit in return.
      changed this order to correct what we perceive to be a flaw in the 
      algorithm. By its nature, this can affect the integrity of the 
      database. We believe the new order is the correct one, but if 
      there is code in VistA that relies on the old order this change 
      has the capability of introducing database corruption. We did not 
      make this change lightly. Not only do we believe the new fire 
      order is correct, but it is likely that code that relied upon the 
      old fire order was already introducing database corruption. We 
      have found no evidence yet of code that relied on the old fire 
      order, but in a system this complex we can never be sure.
    • DICF
      CHECKSUM:   B24909377
    • DICF1
      CHECKSUM:   B20706919
    • DICF3
      CHECKSUM:   B33895706
    • DIK
      CHECKSUM:   B16283274
    • DIK1
      CHECKSUM:   B10746869