Paradox (DOS) - Y2K / 19xx-suppression / Epoch
|This page just contains some general notes on
Y2K compliance in Paradox (DOS), and some brief details on a facility
to change the default behaviour of any COM or EXE file where internal ASCII
or binary values in the range 00-99 are transformed to 1900-1999, and vice
Some notes on Paradox - Y2K:
|Paradox (DOS) 3.5, 4.0x, and 4.5 are themselves
fully Y2K compliant. I believe, though I'm not certain, that previous
versions are also Y2K compliant.
However, as a warning, Y2K issues might arise in:
- how users submit input dates,
- how application software (PAL) handles dates
- how dates appear on outputs (reports, graphs,
- how dates are handled in import files, and in export
Also, there are some claims of a few very minor quirks in how
Paradox deals with Dates. (Unfortunately, I've not checked some of these
issues in detail):
- Apparently, if reports have Group Totalling,
and if this grouping is based on Dates (perhaps specifically just Month and
Year), and if data is present for November 1999 and/or December 1999, the
reports do not show correct data for these two months. (The November '99
data is grouped by Day, and the December '99 data is positioned wrongly in
the report). The recommended solution is to append one or two extra fields
to the report tables (for the Year and Month, or equivalent), to populate
these using a short PAL script, and to use these for Grouping of the output.
- In the Paradox-DOS Graph engine, if dates are shown
along an axis, and if dates are in the 19xx range, the engine removes the
"19" from the year, and just shows DD-MM-YY or MM-DD-YY, etc. In the
examples I've seen, if the dates are outside the 19xx range, the
engine just shows the dates as "******" !. Perhaps dates outside the 19xx
range show correctly in some instances - maybe when few values are graphed
and adequate display space is available per entry.
- Apparently, if queries include selections based on
date-fields, and ".." matching is used, and a selection on year is
used, (eg, ../98), then the query runs correctly. However, if the year
selection is specified with a 4-digit year (eg, ../1998), the query does not
run correctly. There may be additional conditions for this behaviour.
- Paradox gets a little confused with Date-arithmetic, if the
dates extend back to around years 0000-0100, and prior. (I appreciate that
very few users would have date values going back about 2000 years !). To
understand, insert some current dates into a table, and then run some calcs
on these, perhaps creating additional date fields, where about
1800-1900-2000 years are subtracted from the keyed dates. When the
calculated dates are displayed, all dates back to year 0100 will show
correctly. Then, dates prior to year 0100 will appear as 19xx/20xx (current
period), and dates prior to year 0000 will appear as
1900...1800...1700...back. The dates on file are accurate. The displayed
dates are incorrect, because Paradox sees a 1-digit or 2-digit year (or
prior), and adds 1900 to the value.
- Some users have reported Y2K issues where Paradox suppresses
leading zeros in 2-digit years (eg, 2000 might change to 00, or 0, or even a
single space or a null), and then tries to create files with this "Year" in
the file-name. Embedded spaces in filenames are not acceptable. See the
/Z command-line option in Lesspace.
"19" Suppression / "19"-->"20" / Set Epoch:
|The basic Y2K rule for some products (including
Paradox-DOS) is as follows:
- On input, if a 1-digit or 2-digit year
is submitted, the software always assumes that the century digits are "19".
(With Paradox, the equivalent of a full 4-digit year is always retained in
- On output, these systems will, unless
programmed otherwise, discard the "19", and show only the remaining 1 or 2
low-order digits. Effectively, Y2K windowing is to always use a
base of "1900" !.
We have developed a utility to scan the machine code embedded in an EXE file
(or a COM file), seeking code which suppresses this "19" treatment. The
utility can then either:
- disable this "19-suppression", or
- change the "19-suppression" to "20-suppression", or
- change the EXE file to activate a variable base window (Set
This utility just scans EXE/COM files, seeking and altering a variety of
machine-code patterns - it is not specifically Paradox-related. Within
the Paradox family, we have successfully tested this approach on both
Interactive and RunTime releases, of versions 3.5, 4.0x, and 4.5. (The
Set-Epoch subject, also defined as Windowing, is discussed in detail on a
separate page here, and may be activated only in conjunction with the
lesspace utility). In the case of Paradox-DOS, this utility changes the
behaviour of Paradox, as specified, for all data-entry, data-display,
reporting, etc, but it does NOT change the in-built date-behaviour of the
graphing engine, as mentioned above. (We could investigate this graphing
issue, if required).
This program will not be made available, but the service is
available, under strict terms:
- The user must send us the EXE file to be patched.
- Thus user must request either "19"-suppression, or
change the "19" to "20", or set an Epoch. (Each option results in a
different EXE file).
- Thus user must confirm that:
patched file will be used solely at his/her own risk.
will not hold us responsible in any way for any results of the use of the
will not hassle the program authors/owners/manufacturers re the patched
will not distribute the patched file to any other parties.
will do all possible testing as outlined below.
- The user will contact us on any
problems, but only if these are definitely related to the Y2K patches.
- We may not be able to resolve any problems that arise.
Hopefully, these terms are clear. The overall objective is to make our best
efforts (but with no iron-clad guarantees) to change the behaviour of your
Y2K systems, so that their operation is more acceptable. However, this
change must also not negatively impact the relationship between user and
authors, suppliers, etc.
For testing with the modified EXE/COM file, the user should:
- first, do all possible testing using an unmodified
version of the EXE file,
- only when the app is finished and fully tested, then
switch to the modified EXE file,
- confirm that the modified EXE/COM runs exactly as the
original - except for the intended patch.
Our approach to the normal installation and running of the modified EXE
files is as follows:
- Retain the unmodified EXE/COM files, and use different
file-names on the modified versions,
- Assume the modified version of the code is the normal
one in use,
- Activate the app with a BAT file, with an input parameter to
run the unmodified EXE/COM option.
- Ensure that it is very easy for a user to select the
unmodified version, using the predefined parameter,
- If any problem arises which could be in any related to the
Y2K modifications, then switch to the unmodified EXE/COM file, and observe
behaviour there. It should readily become clear if any problems are related
to the modifications.
The cost of changing the behaviour of an EXE file, as per
the above terms, is USD $ 85.00. This applies to each EXE file generated.
Furthermore, to implement the full Epoch option, the user also
needs a registered installation of Lesspace (ver 3.0 or higher).
If you have queries, or want further info, please
Misc Notes on Paradox-DOS:
|I bumped into
old (but very good) "Survival Guide" on Paradox-DOS apps. I don't know the
And, curiously, also bumped into the CVs of 2 of the 5 people who were
involved in the very early days of the development of Paradox (at ANSA):
David L Gardner, and
John C Frykland.
has references to other ANSA folks - under Feb, 1987. And Mark Pauker was
also at ANSA - but I've no info on Mark.
When configuring a shortcut to run PDoxDOS, then, in the Properties of the
Shortcut, ensure the Working directory path does NOT have a trailing
[ Home ] [ What's New ] [ Contact Us ] [ Referrals ] [ Feedback ] [ Products Summary ] [ DownLoads ] [ Orders ] [ Links ] [ Anti-Spyware ]