This rather strange option invokes two features related to "hexadecade" date notation (in which 1-Jan-2000 is coded as "0101A0", 15-Jun-2014 is "0615B4", etc.) which can possibly eliminate a lot of Y2K conversion programming in some legacy applications.
The first feature causes the VAL() function (whether called explicitly or implicitly, by assigning a string to a numeric variable) to accept a single leading hex digit. Thus, VAL("A5") would return 105. This may allow ASB routines which add and subtract dates to continue to work, even with hexadecade format dates.
The second feature causes PRINT to scan the output for strings which look like hexadecade dates (e.g. ##/##/A#) and convert any such pattern to the 'standard' notation. For example, PRINT "12/15/A2" would display 12/15/02. This feature may eliminate much of the need to manually clean up the output when switching to hexadecade date format.
Note that all of the above would probably only make sense if you were also using INFLD’s hexadecade feature.
The HEXDEC PRINT formatting logic also applies to XCALL PRINT.
