Re: mi access to a dtaara

["Steve Richter" <srichter@xxxxxxxxxxxxx>]

>
>You will note that MS does not provide access to absolutely everything
>within the OS.  There is a selected set of objects that are accessible by
>the .NET approach.  Unless and until MS provides access to absolutely every
>object in the OS, your analogy is not valid.
>
>This is innovative?!?!  Isn't this accomplished by simply providing header
>files for the objects they choose to make "manageable" or "public" or
>whatever?  Is this somehow different from the IBM API approach?  What's new
>here?
>--
>Dennis Lovelady             Fayetteville, GA



Dennis,

I dont have working knowledge of .NET. Just 2 yrs of c++ and the win32 api.
So I will defer to you on what it really offers.

Imo it is relevant to an as400 api discussion bc it provides the working
example of another approach.

I think that just as the C++ class/member approach to programming is
superior to the flat ile module approach, the class/member organization and
access to system api's will prove superior to the standalone system api.

An example. This dtaara api issue. The as400 does provide api's for all
dtaara functions. Some like ChgDtaAra and DltDtaAra have to be called from a
cl pgm, others like the rtvdtaara api can be called from a hll pgm. If an os
uses the class/mbr approach the os is organizationally forced to provide all
the dtaara api's as class mbr functions, accessible from any language.

2nd example. Chgs and additions to the api.  As400 adds addn parms to its
api, adds another rtn fmt name ( objd0100, objd0200, ... ) when it adds a
new feature to its api.  This makes the api increasing more complex to use.
Some parms are ignored, others must be set to a specific value, ...   In the
class/mbr paradigm, when an api gets a new feature, a new mbr function is
added to the class. No chg to the original mbr function. The os knows which
one is being called based on the nbr of arguments passed, the types of these
arguments.

See mark, no mention of .Net <g>

Have a nice weekend,

Steve Richter


+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---