RE: JOBD analysis

The "no repeating fields" rule is hardly limited to database terminology imo.

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.

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.



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, May 09, 2013 12:30 PM
To: Midrange Systems Technical Discussion
Subject: RE: JOBD analysis

I disagree that it's wasted energy. I've submitted DCR's and several of
them have come to fruition. What is wasted energy is complaining about
it around the water cooler with your fellow coworkers.
https://www-912.ibm.com/r_dir/ReqDesChange.nsf/Request_for_Design_Change?OpenForm

I think that "no repeating fields" is some form level of database
terminology. Job descriptions are not a database object. If you read the
section on processing list entries with an API, and also processing other
items returned by APIs with multiple values, you will see things like
Offset to list entries
Number of list entries
Size of list entries.
So, irregardless of whether it's some *USRSPC or just a large variable you
get a pointer to either of that user space, or to the beginning of that
variable. Then you add the "Offset to list entries" to that pointer. Base
a data structure on that pointer. And now that datastructure will contain
your data. Then you just add "Size of list entries" to that pointer and
now your data structure contains the next item. Repeat for the "Number of
list entries".
Is it as easy as what you are familiar with in database? Like, 'select
library, jobd, jobdlib from dspobjdpf order by library, jobdlib, jobd' no,
it isn't near that easy. But it's what's available.


Rob Berendt