Re: DDS Support -- MIDRANGE-L

Hi Mark,

I've enjoyed this discussion, but we must agree to disagree.

"M. Lazarus" wrote:
> 
> James,
> 
> At 6/27/00 11:31 PM -0700, you wrote:
> 
> > >   Out of curiosity, would you have the same opinion if we were
> > talking
> > > about replacing CL with REXX?
> >
> > That would be a bit more of a challenge. <g>  But since REXX is
> > available on just about every platform and OS, it wouldn't break my
> > heart to see CL wither on the vine.  Don't get me wrong, I like CL,
> > I'm
> > just not married to it.
> 
>  My point is that just because it exists on "all" platforms doesn't
> mean that we should be forced to switch to it.  Where is the ROI?

The ROI is in the expanded availability of talent.  Now, as a business
owner, the capitalist pig that I can be, if I can gain in available
talent pool, I've gained.  The following may make some people
uncomfortable, but AS/400 talent is a niche skill.  The platform is such
a kick butt system that those that know CL and DDS can demand wages/fees
that are inconsistent with the industry in general.  Now SQL skill may
be foreign to the AS/400 community, but it is common knowledge in the
industry as a whole.  Therefore the adoption of SQL for the AS/400
brings in a larger talent pool, more competition, demand for improvement
(see comment below).
> 
> > But back to the main topic, I would propose energy should be spent
> > having SQL enhanced to allow for a REFFLD type of definition and any
> > other feature that PF/LF DDS possesses that is not within SQL.  In
> > the
> > mean time, I'll write my own data dictionary and format definition
> > processor which does have REFFLD capability and use it to generate
> > the SQL.
> 
>  Now here's the rub.  Putting those features in SQL would make SQL
> non-compatible w/ the rest of the world.  So all the cross platform
> compatibility arguments fall my the wayside.  So now we're back where
> we started from - IBM may as well enhance DDS and get it over with.

This is the point where we take a fork in the road.  Standards are a
wonderful thing (there's so many to choose from <g>).  "Standards" are
created by two methods: 1) a governing organization, at glacial speed,
debates the merits of a feature and sooner or later or never gets around
to accepting it, or 2) a body follows the lead that Netscape did when
they just put out the features of things like tables in HTML and told
the standards committee and the rest of the world the keep up or eat
dust.

I'm in camp #2, IBM or anybody that places a REFFLD capability in SQL
would have a following and force the remaining SQL providers to follow
suit. Ergo, a new standard.  DDS, in your wildest dreams, will -never-
become a standard.  And if you think that the AS/400, and it's
particular definition languages, will live forever, ask any person with
S/3x background to give you the timeline of the decline of OCL or IDDU
or WSU or #GSORT.

The S/36 outsold the S/38 about 8 to 1, so why isn't OCL the AS/400
command language and IDDU the file definition language or WSU the method
to handle subfiles?  Personally, I liked being able to have // IF
statements condition the #GSORT specifications but I got around it by
writing my own dynamic QRYSLT string builder.
> 
> > > >BTW, if you -do- have to change the underlying DB (and at some
> > time you
> > > >undoubtedly will), with the appropriate tool you can create new
> > DDS and
> > > >new SQL and a conversion program when CHGPF or CPYF *MAP *DROP
> > won't do
> > > >the job for you.
> > >
> > >   When is this the case?
> 
> >  When you take some file that had the date in separate mo/dy/yr
> > fields
> > and want to create a single field that is a date data type comes to
> > mind.
> 
>  Then you're changing the layout or format of the data, so that's not
> a fair comparison.  But you actually can do it by mapping the fields
> in a *LF and then doing the CPYF *MAP *DROP

Yes it is a fair comparison. This is the whole essence of my point, when
you, yes you, control the definition of your database, you can control
these issues.  I'm not talking about changing your customer name field
from 32 char to 40 char, but some real world stuff. If you've been
paying attention for the last couple of years, for most, the change of
data type has been a very real issue.  Dates come to mind. For those
that just worked around it (like me) it is still an issue to be dealt
with.

Maybe you can educate me on this one. (deadlines do put such a crimp on
experimentation). When I get some free time, I'll try to CAT three
fields (MM, DD, YY) and have it output to a date data type.  BTW, which
way should I order the CAT mdy?, ymd?, dmy?  What about a cyymmdd 7,0p
field?

What happens when new data types are indroduced? Like "currancy" where
you can qualify it as US$, CN$, yen, sorry I don't have a euro symbol on
my keyboard.  How about a data type for quantity? So you can specify
pounds, tons, metric tons, stones, kilograms as a "format" just as we
specify dates as *ISO or *USA?  Let's not forget time duration, where
7:30 is 7 hours and 30 minutes and 7.50 is 7 and one half hours.

Sorry to go on for so long, it's been above 80 for the past four days
and for us folks in the Pacific NW it makes us gateish <g>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---