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