|
Newsletters
(November, 1998)
- Conversion Of Transaction Capture Files From Adabas To DB2
- The Hexadecimal Date
Conversion Of Transaction Capture Files From Adabas To DB2 Tilbage
123
THE BACKGROUND
The Transaction Capture System is used in a foreign bank by ‘The Wholesale Cheque Clearing Centre’ for transferring foreign currency payments between customers without for-eign currency accounts.
Although only a comparatively small system, approximately 3000 transactions a day, it is complex, as there are a great many variable situations to be handled. It was written in 1985 and comprised approximately 40 Cobol/CICS/Adabas programs for input and validation, 10 background assembler programs and used 15 Adabas tables. Each Cobol program had a corresponding Adamint module, linked at compile time.
The screen handling was controlled by an internally written Generalised Input System (G.I.S) which was used by all Wholesale Systems Applications. This also used Adabas.
When the system was originally designed an assembler module (366IAA) had been written to handle all the calls to the Adabas files. This module was called with parameters for access (Read, Update etc) key, File required and returned the data as specified in the Adamint module.
The version of Adabas in use was not Y2K compliant, and, as it was no longer a strategic product within the bank the data/programs had to be converted.
THE PLAN
The assembler module was to be replaced with a similar module to control the DB2 access.
Each program would also have an additional program written to control the screen handling, using the original file names and GIS commarea, of which very little would be used.
All the field names would remain the same, so that very few changes would be needed to the original programs.
It was decided to try this approach on one simple transaction, the input of additional data to a cheque record.
A major consideration was the lack of experienced staff. It was hoped that once one transac-tion was completed, then this could act as a basis from which the less experienced people could work.
THE REALITY
The coding changes and new screen handling program were written quickly ,as was the ba-sis for the assembler module replacement. This was only for the Cheque table, as that was all that would be required initially.
The testing began!!
It was then that we realised that things were not going to be quite so straightforward.
To reduce the coding changes to the original programs all the original commareas had been kept, including those used for GIS.
These, combined with the new commareas meant that trying to keep track of the processing was virtually impossible.
THE RETHINK
It was then decided to strip out the unnecessary processing. Instead of one replacement as-sembler module, there would be one for each DB2 table.
Although the coding changes took longer, once done they could be used as a basis for all the other programs.
The rewritten assembler module was used, but new ones would need to be written for each of the other DB2 tables.
A new screen-handling module was written, again this could be used as a basis for all the others.
Once done the testing started again. This time with much greater success!!!
THE MORAL
What seems the simplest solution isn’t always the case.
The Hexadecimal Date Tilbage
123
INTRODUCTION
In the year 1967 the very first projects for computerised information systems were getting under way. In the quest for standardisation and integration within the organisational unit the first corner-stones were laid on which subsequent systems were to be built. Such corner-stones were, for example, naming conventions, field formats, output standards and, very important, the internal representation of data, since in those early days physical storage de-vices were expensive and inefficient, requiring that data be stored as economically as possi-ble. Leaning on this philosophy many an organisation chose date fields as candidates for economisation of storage space, with the result that now, just a few months before the last year of the twentieth century is heralded in, the corner-stones of their information systems have to be dug up, reshaped and relaid before the fruits of over 30 years of operations crum-ble to dust overnight.
THE HEXADECIMAL DATE IS BORN
Throughout most years of a century manipulations with date fields will work perfectly with-out reference to the century part of the year in a date. In the ‘60s and ‘70s this was very much the case, so it made sense to save space by leaving out the century information before storing date fields. But space could also be saved in a way which would not lead to disaster at the turn of the century, and this way was opted for by one organisation which preferred the initial higher investment in development, in return for integrity of date fields and the programs processing them over the end of the century and into the next.
The idea to be developed was to store a date converted to hexadecimal information in the space of two bytes. The type of data that the organisation had to manage influenced the de-velopment of the concept, but once the mechanism was clear, it had a facility for handling date data which was logical despite the lack of logic in the day-to-day calendar, and flexible enough to be applied across almost every constellation of information system where dates have to be handled.
THE CONCEPT OF THE HEXADECIMAL DATE
A date is stored as a two-byte field and as such is said to be compressed.
- Each and every year has exactly 385 days.
- Each and every month has exactly 32 days.
- The first day of a year is 00.00.YYYY.
- The first day of a month is 00.MM.YYYY.
- X’0000’ corresponds to 00.00.1867.
- (This was because in 1967 the oldest inhabitant stored in a file was 100 years old).
- X’FFFF’ corresponds to 20.03.2037, which is a Friday.
- Each day is flagged according to validity, whether a working day or not, and given its weekday name.
ROUTINES DEVELOPED AROUND THE HEXADECIMAL DATE
- Compress a date from the form DD.MM.YY or DD.MM.YYYY.
- Decompress a date to the form DD.MM.YY or DD.MM.YYYY.
- Validise a date in the form DD.MM.YYYY.
- Add or subtract days with a date in the form DD.MM.YY or DD.MM.YYYY.
- Return weekday information of a date in the form DD.MM.YY or DD.MM.YYYY.
EXAMPLES OF USE IN PL1 SYNTAX
EXAMPLE 1
Assume the date is a key and occurrences are to be stored in LIFO order. Subroutine COMP_DATE compresses the date “TODAY” to the two-byte variable HEX_DATE:
HEX_DATE = COMP_DATE (TODAY);
The inverse key DATE_KEY is then formed from HEX_DATE as follows:
UNSPEC (DATE_KEY) = ^ UNSPEC (HEX_DATE);
EXAMPLE 2
Today’s date is 11th November 1998. Subtracting 385 from its hexadecimal value will bring us back exactly one year:
YEAR_AGO = DECOMP_DATE (UNSPEC (BIN(UNSPEC(COMP_DATE(TODAY))-385, 15)));
CONCLUSION
It is clear that the hexadecimal date concept explained above has its days numbered when the year 2037 approaches. But by then the database will be equipped with eight-digit date fields, and maybe a few members of the organisation will remember the problems that other organisations had had long ago at the change of th
Return to Newsletters
|
