Its either as you described - change an itemNumber attribute in one field ref file and recompile and you are good to go;


Locate all physical files which utilize the item # (with various names)
Search thru all HLL code looking for data structures, parms, arrays, and work fields which re-define the itemNumber (oftentimes with various and different names and different lengths and types)
Rebuild everything, promote to production, and try to fix the stuff that was missed.

Of course the first scenario depends on each developer referencing back to a single description of each data element.

Other OS's and dev platforms do this out of the box; everything is described in a data dictionary.

With Iseries, it is the only method I know of to inherit field attributes from one repository.

Isnt that important to reduce the maintenance costs to our organizations? I am thinking that it is a major expense if not used.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, October 30, 2012 10:30 AM
To: Midrange Systems Technical Discussion
Subject: Re: DDS field reference equivalent in SQL

Are field reference files really that useful? I understand the concept;
change itemNumber in your FREF, 'recompile' all files based off of this
column and now they are that size. But what about when you run over the
number of columns and other concerns?
What other use are they?

Rob Berendt

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page