Two changes in one routine, DIAU.

NO.: 14641                              VERSION: 22.2T1
  TAG: passim                           ROUTINE NAME OR GLOBAL REF: DIAU
  REPORTER: CAROL MONAHAN               DATE CHANGED: JAN 25,2013
  PROGRAMMER: RICK MARSHALL             PREVIOUS CHECKSUM: B37812759
  CHANGE: Auditing: Overhaul Auditing Menu
  UPDATED UCIS: DEV
  RELATED CHANGE NUMBERS: [add Sam's post-install change when he's done]
  DOCUMENTATION NEEDED: YES
  DOCUMENTATION NOTES: Auditing Menu: New Ordering, Numbers, and Menu Text
  NEW VERSION: <22.2T1>
 LONG DESCRIPTION:
 With all the work George has done for auditing since version 22, and with
 the new documentation coming, we took this opportunity to reorganize,
 renumber, and rename the auditing options for clarity and ease of
 selection.

 Before:

    Choose from:
    1            FIELDS BEING AUDITED
    2            MONITOR A USER

Type <Enter> to continue or '^' to exit:
    3            PURGE DATA AUDITS
    4            PURGE DD AUDITS
    5            TURN DATA AUDIT ON/OFF
    6            SHOW PAST CHANGES TO DD'S

 Select AUDIT OPTION:

 After:

    Choose from:
    1            LIST FIELDS BEING AUDITED
    2            TURN DATA AUDIT ON/OFF
    3            DATA AUDIT TRAIL PURGE
    4            SHOW DD AUDIT TRAIL
    5            DD AUDIT TRAIL PURGE
    6            MONITOR A USER

 Select AUDIT OPTION:

 While in DIAU, I also did a very light refactoring of header lines and
 last lines throughout the routine and reorganized the subroutines to
 follow the order of the new menu.
  EXPLANATION FOR TEST SITES: AUDITING: REORGANIZE AUDITING MENU
 DETAILED TESTING INSTRUCTIONS:
 Just run all the options to make sure they still work. Other than a
 possible displatching problem if I didn't match things up correctly,
 there shouldn't be any other kinds of errors possible with this change.

Type <Enter> to continue or '^' to exit:

NO.: 14642                              VERSION: 22.2
  TAG: 4+4                              ROUTINE NAME OR GLOBAL REF: DIAU
  REPORTER: SMH                         DATE CHANGED: JAN 27,2013
  PROGRAMMER: GEORGE TIMSON
  CHANGE: Better help for SHOW DD AUDIT TRAIL option on what to enter.
  DOCUMENTATION NEEDED: NO              NEW VERSION: <22.2>
 LONG DESCRIPTION:
 This line is added:

 >  S DIR("?")="Enter a date.  All audited changes to Data Dictionaries,
 starting with that date, will be shown."
 DETAILED TESTING INSTRUCTIONS:
 Under the menu option, do a "?" to see if the text is there.
Partial Numeric Match fix with U/Q flags for Finder/Lister.
NO.: 14639                              VERSION: 22.2T1
  TAG: C5+4:12                          ROUTINE NAME OR GLOBAL REF: DICUIX2
  REPORTER: ZACH GONZALES               DATE CHANGED: JAN 25,2013
  PROGRAMMER: RICK MARSHALL             PREVIOUS CHECKSUM: B34510586
  SUPPORTING DOCUMENT NUMBERS: JIRA [FILEMAN-6]
  CHANGE: Lookup: make U (classic) or Q (Finder/Lister) flag should suppress par
tial numeric matches on pointer values  UPDATED UCIS: DEV
  DOCUMENTATION NEEDED: NO              NEW VERSION: <22.2T1>
 LONG DESCRIPTION:
 Partial numeric matches, the ability to enter a short number and have it
 match a longer one, was added to deal with free text and code fields that
 have the syntax numbers but the semantics of strings, like social
 security numbers, health record numbers, and other numeric strings.

 Unfortunately, they are being applied too widely, even to actual numbers
 in some cases. The issue at hand is that during an untransformed lookup
 on a pointer index, which stores the internal number of the
 cross-referenced records in an index's value subscript, due to a bug in
 the code, the Fileman lookup is allowing partial numeric matches on these
 internal pointer values. The potential for chaos is high, since there are
 few if any files in VISTA in which records are meaningfully grouped from

Type <Enter> to continue or '^' to exit:
 a user perspective according to the first digit or digits of their record
 numbers.

 Probably, a widespread examination of the current behavior of partial
 numeric matches should be made to ensure they are only being applied to
 free text and set-of-codes fields, for this issue we ask only that when
 the U (untransformed) flag is passed to the classic lookup or the Q
 (quick) flag to the Finder or Lister, partial-numeric matches be
 suppressed on pointer lookups.

 This feature - partial numeric match - is actually two different features.

 First, it enables a lookup value of 1 to match the numbers 1, 12, 135,
 etc. This makes sense when dealing with the kinds of pseudo-numbers I
 wrote about in my original description.

 Second, it ensures that when a field allows both pure numerics and
 alphanumeric strings, that partial matches where the lookup value itself
 is pure numeric will check both the numeric part of the index and the
 string part of the index. So, for example, a lookup value of 9 should
 match both 9 and "9A".

 These two features are inseparable in the Fileman Lookup. I wonder,
 though, whether both features are useful in precisely the same
 circumstances, or whether it might be desirable to separate them.

 Routine DICLIX0 handles the associated calculations for DICLIX (the
 Lister walker), for DICFIX (the Finder walker), and for DIC3 (for the

Type <Enter> to continue or '^' to exit:
 classic lookup). COMMON1^DICUIX2 also does part of the calculation,
 setting DINDEX(DISUB,"MORE?") to flag those routines to consider doing
 the calculations. My temporary fix is in the wrong place, I think; I
 fixed it in DICUIX2, which may be too early. Pointer fields can have
 input transforms that alter DIC(0) for purposes of doing that pointer
 lookup. We should consider whether that pointer-specific DIC(0) ought to
 have any bearing on this later partial numeric match calculation being
 used to help decide how to traverse an index that cross-references that
 field. Even if not, the relationship between the calculation in DICUIX2
 and that in DICLIX0 should be better defined.

 There is also some confusion between the documentation on these three
 contexts and the shared code that does the calculation. This areas should
 be thoroughly tested, and if necessary the code and/or the documentation
 should be updated until it all makes sense and matches.

 Our first attempt to fix this bug was broken because it used the wrong
 variable to test the data subscript's type. It used DINDEX(DISUB,"TYPE"),
 following the Fileman team's internal documentation, but it turns out the
 documentation was wrong. The original author of the Finder was too damn
 clever by half and made this variable actually record the type the lookup
 will treat the subscript as, not its true type. The difference arises when
 we pass in the Q flag to the Finder or Lister to do a Quick Find or Quick
 Lookup. In this case, DINDEX(DISUB,"TYPE") equals F for free text, which
 makes the lookup avoid the elaborate strategies it usually follows for
 doing lookups on pointers. Thus, the original author should have named
 this subscript "ASTYPE" rather than "TYPE". The original author (me) finds
 himself hoist on his own petard. It never pays to be too clever with our

Type <Enter> to continue or '^' to exit:
 algorithms. Baby code.

 For now, we fixed our fix by using DITYPE instead, a variable that does
 (temporarily) contain the field's type (along with the other
 field-descriptor flags). Our tests show that the classic lookup, Lister,
 and Finder all now properly suppress partial numeric matches on pointer
 subscripts when the right flag (U or Q, conditionally) is passed.

 The fix itself is to conditionally suppress the setting of the Any More?
 flag, which plays a key role in activating the search for partial numeric
 matches. For all data types, we suppres it if we're doing exact matching.
 For pointers and variable pointers, we suppress it when the flags tell us
 to do an untransformed lookup. In the case of pointers and variable
 pointers, that's codeword for a lookup in which we're being passed in the
 right IEN and just need to find it in the index; partial numeric matching
 can cause trouble in this scenario, so we suppress it.

 Here are the new lines for C5:

         . ;
         . Q:DIFLAGS["X"  ; no partial-numeric matches if require exact
         . N PNM S PNM=0 ; suppress PNM for pointers or variable pointers?
         . I "VP"[$E(DITYPE) D  Q:'PNM  ; at least for these cases:
         . . I DIFLAGS["l",DIC(0)["U" Q  ; classic, untransformed lookup
         . . I DIFLAGS[3,DIFLAGS["Q" Q  ; Lister, quick list
         . . I DIFLAGS[4,DIFLAGS["Q" Q  ; Finder, quick lookup
         . . S PNM=1 ; otherwise, allow it on ptrs or vptrs
         . ;

Type <Enter> to continue or '^' to exit:
  EXPLANATION FOR TEST SITES: [FILEMAN-6] U (CLASSIC) OR Q (FINDER/LISTER) FLAG
SHOULD SUPPRESS PARTIAL NUMERIC MATCHES ON POINTER VALUES; X SHOULD ALWAYS SUPPR
ESS IT
 DETAILED TESTING INSTRUCTIONS:
 To test the suppression of partial numeric matches with the X flag, set
 up a test file with a set of fields, one for each cross-referenceable
 data type; design all of those fields to accept numerals, whatever their
 data type (for example, allow one code to be 3 and another code to be 30).
 Put indexes on each one. Enter a pair of entries in the file so you have
 partial numeric matches between the entries for the same field in both
 files (free text of 10 in one, 100 in the other, pointer to record 2 in
 one, 20 in the other, and so on).

 Then set up calls through IX^DIC, one for each index, each passing in the
 short numeric value that ought to cause partial numeric matching to
 happen, and always passing the X flag. Lookup will incorrectly prompt the
 user to pick between both values in most or all cases before the fix,
 never after the fix.

 To test suppression of partial numeric matches with the U flag on
 pointers and variable pointers, use the same test file and call IX^DIC
 without the X flag but with the U flag on the pointer index and then
 again on the variable pointer index. They will both incorrectly offer
 both choices, even though you passed in an IEN that matches the shorter
 value. After the fix, this should no longer happen.

 To test it with the Q flags, set up Finder and Lister calls on those same
 indexes. Again, the before and after should demonstrate that the fix

Type <Enter> to continue or '^' to exit:
 worked.
Beta version internal testing file