| I had this problem a long while ago, and my master file description
is no longer around, but I believe that you actually have to name
the first segment 'ROOT', i.e., SEGNAME=ROOT. Despite the fact
that the documentation does not show that, I believe that is the
way it has to be. I hope that helps, it's been awhile since I
have accessed ISAM files.
Mike
|
| We've been using ISAM files exclusively here at this site, since
we're evaluating conversion feasibility from FORTRAN hosted
applications. A short example that works for us follows:
{ This is for a file with four fields, record 26 characters long,
with a single, primary key containing 19 characters}
FILENAME=TLOCAT ,SUFFIX=ISAM,$
SEGNAME = LOCATION,$
GROUP=KEY, ALIAS=KEY ,USAGE = A19, ACTUAL = A19, $
FIELDNAME= CRSNM, ,USAGE = A10, ACTUAL = A10,$
FIELDNAME= ONDAT, ,USAGE = A6, ACTUAL = A6,$
FIELDNAME= TGRCD, ,USAGE = A3, ACTUAL = A3,$
FIELDNAME= SERIAL, ,USAGE = A7, ACTUAL = A7,$
Note that alternate key groups if any, need to be qualified with
FIELDTYPE=I to allow alternate key ordered retrievals, but the primary
key need not (and should not) be so qualified.
Hope this helps:
- Brian
|
| 17.1 is correct in that you need to describe the segment as 'root'.
Some thoughts about using FOCUS with RMS/ISAM files:
In many ways, FOCUS works better with ISAM files --- if your retrievals
are key oriented (discrete) --- than it does with its own file
organization. FOCUS, with ISAM files, automatically uses the primary
key for retrieval without the silly 'TABLE FILE file.index' structure
and can retrieve wildcards - which is really nice (normally FOCUS
requires equality conditions). Wildcards can be really helpful if you
have a file with concatenated keys such as BOOKING_CTR/BADGE_NO that
were concatenated to create a unique value. In FOCUS, you would
describe the retrieval as:
TABLE FILE X.ALT_KEY
IF ALT_KEY EQ 'ABC$*'
.
.
END
In this case, $* acts as a wildcard and provides retrieval on the
alternate key value. If this file were a true FOCUS file - the
retrieval would fail. Also, keyed file organization tends to have
indices in contigious space - rather than the typical FOCUS file
which has data all over the place (unless the REBUILD utility was
used). I have found FOCUS to be a pretty decent reporting tool
on ISAM files so long as you are going after discrete records.
There used to be some folks in Hudson, MA (Corporate Distribution??)
who used this setup.
-rpr-
|
| Now that I have signed in, I have a question concerning external
files that has been bugging me for the past few days.
I have a file which contains a lot of arrays that were part
of a FORTRAN data structure. So the data in the file has each element
written in a different fashion Each element of the array is repeated
instead of the whole record :
---------------------------------------
FOCUS : | A | B | C1 | C2 | C3 | C1 | C2 | C3 |
_______________________________________
---------------------------------------
FORTRAN : | A | B | C1 | C1 | C2 | C2 | C3 | C3 |
---------------------------------------
From what I got out of the manual, the only way to describe
that file is to describe each field as a segment with OCCURS=2 at
the end. If the arrays were arranged as in the first example, you
would only need one segment with three fields. There must be a better
way. As it is I have to describe a file with about 200 fields in
75 segments.
Any ideas ? It would seem that FOCUS should or ought to support
this type of structure better since most programming languages would
generate any arrays that way.
|