Main TAS page | Dates | TAS Data Dictionary | ReStructure | TAS data to ASCII |
Number fields
Before TAS-Pro 4 (which uses IEEE numeric format), TAS numeric
fields hold Binary Coded Decimal (BCD) integers. The position of
the decimal point is determined by reference to the data
dictionary field DICT.DEC. Each byte of the numeric field
represents two decimal digits. For odd-sized
fields, the first half-byte holds
either F (hex), indicating a positive or Eh, indicating a
negative value. The decimal value of each subsequent digit is
the hexadecimal value of each subsequent half-byte. Thus:
This also happens in 1792, where 1/1/1792 to 29/2/1792 display as 1/1/1536 to 29/3/1536, in 1536 (first 2 months as 1280) and 2304 (first 2 months as 2048).
I guess this isn't going to worry any of us much, especially as it seems to have been corrected in TAS 5.1. It probably arises from an erroneous byte-shift in the leap year routine.
TASDICT.M holds information about field names, sizes and types, which fields are keys and what the key types are. TASDICT.M also holds data about impending changes to the file structure, to enable files to be restructured. TASFILE.M holds data about data files. You can have several files with identical structures, referencing the same layout ("schema") in TASDICT.M. TASFILE.M links any particular file by its filename to the its schema in TASDICT.M.
The fields in TASDICT.M are as follows:
DICT.NAME | Field name | |
DICT.SCHEMA | Schema name | usually the file name |
DICT.SKEY | an overlaid key | |
DICT.OFFSET | Offset of the start of this field from the start of the record | 1-based |
DICT.TYPE | Alpha, numeric, date, etc | |
DICT.SIZE | Display size | |
DICT.DEC | Number of decimal places | |
DICT.UPCASE | Force uppercase if "Y" | |
DICT.HOLDER | Copy of DICT.ARRAY | used by ReStructure routine |
DICT.KEY | Key type | |
DICT.KEYN | Key number | |
DICT.OVLY | Indicates an overlay field if "Y" | |
DICT.SIZEH | Size in bytes (not necessarily the same as display size) | |
DICT.ARRAY | Number of array elements (if any) | |
DICT.DECH | Copy of DICT.DEC | used by ReStructure routine |
DICT.SIZEHLD | Copy of DICT.SIZEH | used by ReStructure routine |
DICT.OFFH | Copy of DICT.OFFSET | used by ReStructure routine |
When a TAS program is compiled, the compiler reads TASDICT.M and converts field names into offsets. TASDICT.M is also referenced by many of the TAS utility programs to get field data on the fly when maintaining or browsing data. It is not used at run time by compiled programs unless the program calls for it (eg many of the TAS system programs).
I wrote a fix for this, which I
have used to avoid further problems. If you want
to know how it was done, read on, else you can
skip over the following account, taken from the
documentation that I send out with the FIXRS package.
To fix these problems, it was necessary first to write FIXRS, which modifies the DICT.HOLDER field to agree with the DICT.ARRAY field. However, it was also necessary to ensure that file definitions in which any existing value of DICT.HOLDER did not agree with DICT.ARRAY were left unmodified, as this would indicate that a ReStructure was pending (TAS allows and ought to allow successive modifications of Dictionary between physical restructuring of files). This was accomplished by setting DICT.HOLDER to 1 if it was currently zero. A preliminary check for a DICT.HOLDER value greater than zero is thus effective in ensuring that a file is not subjected to FIXRS when it ought not to be. Provided no existing DICT.HOLDER values are greater than zero, it is assumed that the file has not been FIXRSed, and each relevant DICT.HOLDER value is set to equal DICT.ARRAY. This sets the file in a suitable state to perform correctly during the TAS ReStructure (RS) routine. It was also necessary to ensure that a similar routine was built in to the Create Database (TASADFLE) program after file initialisation because initialisation wrongly resets all the DICT.HOLDER fields to zero. The same routine was conditionally built into the Maintain Data Dictionary (TASDMGR) program for the case when the file is created by TASDMGR, and only in that case; subsequent changes to an existing structure must of course not result in updating of DICT.HOLDER. Finally, MENU.RUN had to be modified to run FIXRS following either a File Initialisation (FI) or a ReStructure (RS). This was more difficult, as TAS programs do not return to the calling program. I have still not succeeded in having FIXRS know what file has been restructured or initialised, so I cannot make the process entirely transparent. Before ending this discussion of ReStructure, the following points should be noted: 1. RESTRUCTURE will not handle an attempt to change the TYPE of a data field. It was never intended to. If you attempt to convert a numeric field to alpha, the effect will be to increase the record size, so there will be no difficulties (mutatis mutandis) with spurious record generation, but the data will effectively have been lost. The actual alpha field will hold whatever bytes were in the numeric field, and be right-padded with spaces (ASCII 32d, 20h). If you attempt to convert an alpha field to numeric, you will most likely end up with spurious pseudo-numeric "data" (often a lot of "20"s) in the resulting field. The way to deal with this (if you need to), is to define a new field of the appropriate type (ie numeric if you want to go alpha to numeric), restructure, write a short program containing a fragment like: find(B,keyfld,flerr) ;get first record loop: ;while not end of file alfld = numfld ;do the business save(flnam,n,n) ;save it in the file find(N,flnam,eof) ;get the next record goto loop ;and repeat eof: Then, after checking your results, redefine the structure to remove the unwanted field, restructure again and it's done! 2. When a new Key field is added to a file structure, it does not become effective until AFTER the file has been ReStructured. In this respect, TAS Professional differs from TAS-Plus, which required explicit re-initialisation and reindexing after ReStructure in order to implement a new key. YOU MUST NOT re-initialise a TAS Professional file unless you are prepared to abandon all its data! If you re- initialise, you lose the data permanently, in contrast to the TAS-Plus arrangement, which left the data file intact. The TAS Professional ReStructure routine involves a file initialisation, which is done prior to reading back the data which have been written out to a holding file (which is then deleted).