Paradox-DOS

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 versa.

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 internally,
    - how dates appear on outputs (reports, graphs, screen-forms),
    - how dates are handled in import files, and in export files.

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 the databases).
   - 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 Epoch).
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:
            - The patched file will be used solely at his/her own risk.
            - He/she will not hold us responsible in any way for any results of the use of the patched file.
            - He/she will not hassle the program authors/owners/manufacturers re the patched file.
            - He/she will not distribute the patched file to any other parties.
            - He/she 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 contact us.

Misc Notes on Paradox-DOS:

I bumped into this old (but very good) "Survival Guide" on Paradox-DOS apps. I don't know the author.

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. This site 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 back-slash.

[Top]
[ Home ] [ What's New ] [ Contact Us ] [ Referrals ] [ Feedback ] [ Products Summary ] [ DownLoads ] [ Orders ] [ Links ] [ Anti-Spyware ]