Re: mi access to a dtaara

["Larry Loen" <lwloen@xxxxxxxxxx>]

>Why is there not a chgdtaara api?
 >ibm has had a long enough time to decide to do it
 >and it seems simple enough to do
 >and the fact that rpg and C call their own run time pgms, each with
>limitations,  to do it shows that there is a need for a unified, full
>functional api.
>    and rpg ile is a bit limited without it because IN and OUT cannot be
>used in a sub procedure.
>
>And yet, no api.

But, is this really necessary?  Data areas were invented, what, back in
1979 or so?

I thought the purpose of data areas was to provide a persistent storage
location for a handful of key variables.

Why isn't a call to a CL program containing a CHGDTAARA command sufficient?
Maybe my imagination is deficient, but I can't for the life of me think of
why this should ever be performance critical enough to merit a new API.
Surely, many other API requests come ahead of this?

Moreover, I would myself want a structured approach to any data area I used
in production.  An ILE CL program approach, coupled with the right
activation group strategy, would also have me exporting this in some sort
of structured fashion which I could then reflect in an object-oriented
design of some sort (C++, maybe even Java).  I don't see how it us
particularly useful or valuable to have uncontrolled access to a data area.
And, that's the only real merit I can forsee over just using what's there.
What exists gives pretty structured access.  I thought uncontrolled access
was what user spaces were for.

I guess my imagination is just deficient, here. . .


Larry W. Loen  -   Senior Java and iSeries Performance Analyst
                          Dept HP4, Rochester MN

Speaking on his own. . .

+---
| 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
+---