× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



If you are looking for ways to save on characters in column names I have
found a way to allow up to 14 (or is it 13?) characters by using the PREFIX
keyword on the file spec. For example...


DDS:
A R JDFCFGR TEXT('JDF Config')
A XMLDIR 128A COLHDG('XML Dir')
A ACHDIR 128A COLHDG('Archive Dir')
A DEBUG 1A COLHDG('Debug T/F')

Program:
FJDFCFG if a e k disk prefix('CFG.')

D CFG e ds qualified extname(JDFCFG)

Then I can reference them in my program like this:

subProc(CFG.XMLDIR: CFG.ACHDIR);

With this approach I never have to worry about naming conflicts (i.e.
another file with a column named XMLDIR) because I can prefix in each
program to suit my needs. I also never prefix DDS columns anymore which is
nice :-)

HTH,
Aaron Bartell
http://mowyourlawn.com

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Simon Coulter
Sent: Friday, February 29, 2008 3:11 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Data dictionnary


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 / \
--------------------------------------------------------------------




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.