×

Good News Everybody!

The new search engine is LIVE!

Please report any problems to david (at) midrange.com.




Why are you doing it that way?  You can greatly improve the efficiency of
your programs by just creating the space once, and then accessing it with
a pointer.

Even if you did have a procedure to call instead of a program, it wouldn't
make a big difference, since the process of creating a new object on disk
(which is what a user space is) isn't very fast.


On Thu, 26 Sep 2002, Uma Balasubramanian wrote:
>
> the two calls are being made many times ... in the sense, we have a
> procedure in a service program is using these user space APIs and the
> procedures is being called from many programs (both online and batch) many
> times.
>
> Scott Klement <klemscot@klements.com>@midrange.com on 09/26/2002 12:52:34
> PM
>
> On Thu, 26 Sep 2002, Uma Balasubramanian wrote:
> >
> > Are APIs (I am looking for User space API - in particular) available as
> > 'procedure's? In other words, when I call a User Space API in my RPGLE
> > program, through I use CALLP, it is a program. Are procedures available
> for
> > these ?
> >
>
> There are many APIs that are implemented as procedures in service
> programs.  There are many others that are implemented as programs instead.
> The advantage of procedures is that they're faster, the advantage of
> programs is that they're usable from OPM applications.
>
> The User Space APIs, as you've already noticed, are programs.  This is a
> good thing, because it means you can call them from more different
> environments.
>
> Speed isn't really important for the User Space APIs, since you only need
> to make two calls.   One to create the space, and one to get a pointer to
> the space.   Once you've gotten the pointer, you don't need to call the
> APIs.... so speed isn't really an issue.
>



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2026 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.