On 28/02/2008, at 10:47 PM, David Foxwell wrote:
The problem now is, the dictionary is full ! We can no longer add
any zones
!
I presume by "full" you mean the maximum number of fields in a file
has been reached?
The solution proposed is to create a second PF ( like a volume 2 )
OK.
Replace the file DICTIONARY by a LF with the same name which points
to two
PFs ( volumes 1 and 2).
Logical files are also limited by the maximum number of fields in a
file so unless I completely misunderstand your intention this won't
work.
We will still be limited to using names of 6
characters.
Only because you waste 4 characters for the RPG prefix of DFN_
Any other ideas ? How do others get round this?
Data dictionaries should define "base" types such as NAME, ADDRESS,
POSTCODE, ZONE, etc. They should not define every instance of such a
field. By that I mean your dictionary contains:
A ADDRESS 35A COLHDG('Address')
A TEXT('Address')
A ALWNULL
It should not contain ADDRESS1, ADDRESS2, SHIPADDR, etc. These, if
you need them, should be defined in the actual file referring back to
the base ADDRESS type.
A SHIPADDR R REFFLD(ADDRESS)
A zone has 5 letters : 2 syllables of 3 and 2.
That defines the zone NAME. I presume each zone is the same data type
(e.g., character) and size (e.g., 5 bytes).
In the referencing file we add a prefix for example :
A CMAJDT R REFFLD(MAJDT)
Thus for your zones should have only a base ZONE type defined. The
prefix (C) and two-part name should be defined in the actual file
referring back to the base ZONE type.
A CMAJDT R REFFLD(ZONE)
This approach will immediately reduce the number of individual fields
in the dictionary and will allow you to remain within the database
limits.
To declare a new zone in an RPGLE all that is needed is
D gStsMt S LIKE ( DFN_STSMT )
Which means gStsMt is the same as the zone STSMT in the dictionary.
Which would become:
D gStsMt S LIKE(DFN_ZONE)
presuming you continue to consume four characters fro the prefix.
I don't see why you need to define each individual zone field in the
dictionary when they are all of "type" zone.
As we are gradually moving
towards SQL, I wonder how should we be referencing columns in SQL
tables?
iSeries SQL has support for referencing fields LIKE another field
(can't recall exactly when it came in but fairly recent--maybe
VRM530). However, SQL in general, doesn't have this concept (partly
because there should only be one location of a given entity).
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
