On 09 May 2013 14:11, Stone, Joel wrote:
The "no repeating fields" rule is hardly limited to database
terminology IMO.
I am aware of normalizing a database, but in an /object/ an effective
array, a list of like-elements, is not something that must inherently be
avoided.? Or does this "no repeating fields" rule apply there as well?
It just seems like bad coding practice whether for database design OR
operating system commands. Sooner or later the number of repetitions
reaches the maximum and things stop working.
Maximums are reached irrespective of implementation, be that an
implementation via so-called "repeating fields" or whatever else. Good
design dictates making consideration for impacts on future expansion of
any limit\maximum that is being imposed in the original design; i.e.
that the code changes necessary to effect such changes are reasonable
and that the compatibility across the releases is ensured.
This IIRC occurred with the LIBL max of 25 libraries. It took YEARS
(decades??) for IBM to expand that low limit because the dreaded
"repeating fields" concept was used in the design.
Implying that IBM was trying, over all those years [what, since 1988?
or maybe since System/38?] to make that happen? Laughable. Hardly the
case. The function came [almost exactly] 12 years ago in a base release
and version, plus support added from a data area (QLMTUSRLIB) to enforce
a 25-lib limit in a job for those user applications that could not deal
with the effects of the expanded limit; e.g. per use of RTVJOBA
USRLIBL(&tooshort). Making any change by IBM was surely a very low
priority, most likely because there were almost no requirements ever
presented for which there was no easy alternative as resolution; i.e.
the requester need simply use the system in the manner the design
intended, rather than forcing the system to function aligned with how
they perceived things should work for them even if doing so would be to
the detriment of the overall performance and usability of their
application on the system.
There were few technical challenges in expanding that limit, so very
unlikely some specific difficulty for IBM impeded making the change for
which its arrival was delayed. Surely there were some difficulties, at
least for any interface for which no consideration had been given for
the potential future expansion in the original design for their use of
the library list. Lacking such design foresight likely would have been
an issue even if the library list had been maintained in a separate
object; i.e. any interfaces to the /list/ for which there was a failure
to consider an expansion, likely would have encountered the same
difficulties in effecting their own expansion, regardless of whence the
expanded list was obtained. For example, the impacts to the RTVJOBA
USRLIBL() would not have been ameliorated. Most of the OS does not have
any concern for the maximum number of libraries in the library list, and
was able to remain unchanged and completely unaffected by the increase;
i.e. the use by most components of the library list, is limited to their
use of RSLVSP, for which knowing how many libraries that MI instruction
searches is irrelevant to the invoker, because they only care about the
system pointer to what was [not] found.
I expect that the biggest reason for not making the change sooner was
that there were few if any legitimate requirements proposed by any
software providers [or other customers] for increasing that limit.
There was nobody, figuratively, lining up with bags of money in hand, to
emphasize the effect was imperative. The two cases I had encountered for
example, were each a software vendor claiming the capability was
necessary. In both cases their lack of both familiarity and a good
understanding of the system for its capabilities and design patterns led
to their false perception of a requirement for a larger library list. I
have yet to see any worthwhile example whereby the resolution was most
easily effected by adding more than a dozen libraries to the LIBL. For
all of the years since the capability was made available, I have never
seen any example of a library list in QPDSPJOB output that was more than
a couple lines longer than what was visible in the presentation area for
DSPSPLF on a 132-wide 5250; and with almost always at least five
libraries in the SYSLIBL, that means likely 20 or fewer.
I expect the second biggest reason was that the RSLVSP MI instruction
was designed with the lower fixed-number long ago, with no intention of
ever expanding the design for a larger "name resolution list". Having
one of the most base methods of the system involved in such a change,
like was required for the iASP capabilities, impacts nearly everything
on the system [everything uses RSLVSP], and thus requires careful
planning and test for which delivery in a new Version [vs just a new
release] was most appropriate. There are almost always some previously
unidentified impacts; e.g. code copying portions of the LIBL into their
own storage for whatever reason, by direct access versus a common
interface that was updated to reflect the expansion. In my estimation,
the change was done in conjunction with iASP support only because all of
the code had to change anyway for the iASP support; i.e. if it were not
for the iASP, I doubt the change only to increase the number of
libraries would have been considered a worthwhile endeavor.
midrange.com
