| DESCRIPTION OF ENHANCEMENTS |
Description:
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-
references.
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
installation.
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
appropriate.
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.
|
