Re: mi access to a dtaara

Œ
Hello Steve,

You wrote:
>I think this list should be more loosely defined as a forum for discussion
>of the architecture, technical issues that span all languages, anything in
>the system api reference, ...   But I am new to the list and am asking more
>than answering, so I will defer to the opinions of others.

I meant that your questions were specifically about accessing data areas from 
RPG and C and thus are better suited to the other lists.

>I am writing a computer language for the as400, so my main purpose in posing
>questions is to get the info that I need.

What?  Yet another programming language ....

>but I find this topic interesting just in an academic sense.

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

No there isn't a need for it.  You might require it but the majority of users 
don't.  Second guessing IBM here ...

Normal customer access to data areas is via the CL commands.  An API was 
provided to retrieve data area contents to avoid the overhead associated with 
calling CL from an HLL.  The C interface was probably provided at the request 
of a business partner or other IBM group and thus does only what they required. 
 
The RPG interface was provided years ago before the concept of hardened APIs 
really existed in Rochester or Toronto. I don't think COBOL has support for 
data areas.  So the requirment isn't as big as you think.

Anything you can do with a data area can be be done better and more flexibly 
with a user space.  IBM are not going to create a hardened interface to 
absolutely everything.  They will create APIs for things they need and for 
things business partners or customers request.  Data areas are pretty low on 
the scale of things to have.

>    and rpg ile is a bit limited without it because IN and OUT cannot be
>used in a sub procedure.

Minor irritation.  Replace the data areas with a user space.

>And yet, no api.  And there is also no materialize dtaara defn api.

See above -- insufficient demand.

>The dtaara does seem to have its design faults. It looks like it is just a
>space with a data portion and an object defn portion.  This forces the
>object into the system domain so it can be protected from an out of control
>spcptr.  Any kind of granular locking of the dtaara ( lock a location in the
>dtaara ) is prevented by the design.    A better way to do it would have
>been a dual object design. one object holds the defn, the 2nd hold the data.
>this would allow a spcptr to be set to the dtaara data. a space lock could
>be applied.

Data areas are horrible for other reasons also -- synchronous I/O being the 
main culprit.  Your locking requirements can probably be satisifed with a user 
space but I haven't tried issuing a Lock Space Location against one.

>can ibm not make up its mind on whether it wants to introduce a new  dtaara
>type object or not?

It doesn't need to.  That's what a user space is for.

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\   «»
«» Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /   «»
«»                                                           X    «»
«»               ASCII Ribbon campaign against HTML E-Mail  / \   «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
+---
| 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
+---