RE: Home grown descriptors in RPG/ILE

>One thing you should watch out for is making sure you can 're-use' a
descriptor.   In other words, after you've closed/destroyed a descriptor it
should return to the 'pool of unused descriptors'.  Otherwise, long running
jobs that use your service program could run out of descriptors.

Good Point.  I will definitely run into this with how my apps are written.

I have a question on how you do your errors.  I read your "4.2. improvement
#2: error handling" from the Socket Tutorial and I am wondering if I should
create my own RPG/ILE error module that would do what you are describing
below?  Then if an error occurs all I have to do is pass back a -1 from the
called module and write an error to the error module.  The calling program
would then look to the error module for the actual error code and message.
Is that basically what your FOO_ERROR() is doing?

Aaron Bartell

-----Original Message-----
From: Scott Klement [mailto:klemscot@klements.com]
Sent: Thursday, November 07, 2002 4:29 PM
To: 'rpg400-l@midrange.com'
Subject: Re: Home grown descriptors in RPG/ILE



I've done this.   Though, instead of an overlaid array, I used a multiple
occurrance data structure...  I've found that a little easier to code,
since you don't have to subscript every "global" variable... but I doubt
that makes much difference.

One thing you should watch out for is making sure you can 're-use' a
descriptor.   In other words, after you've closed/destroyed a descriptor
it should return to the 'pool of unused descriptors'.  Otherwise, long
running jobs that use your service program could run out of descriptors.

The only other thing I can think of is saving error information.  I
usually have a FOO_ERROR() subprocedure that retruns the last error
that occurred.  With descriptors, it's nice to keep track of the error
code seperately for each descriptor...  the problem comes when you
have an error in the FOO_new() or FOO_open() procedure, since that
proc generally doesn't return a valid descriptor unless things succeeded,
you can't keep descriptor-specific error messages.   You have to provide
some seperate way of returning errors for that procedure, then.

Other than that, it works well.


On Thu, 7 Nov 2002, Bartell, Aaron L. (TC) wrote:

> I am creating an RPG interface that will facilitate sending out emails.
In
> creating this I realized that I may want to have more than one email being
> created at one time in the same program, much like how you might have more
> than one IFS file open in your program at any given time.
>
> So now I am venturing into creating a descriptor of sorts so I can keep
> track of different emails.  For instance it would look something like
this:
>
> D emlDescr1       s      10i 0
> D emlDescr2       s      10i 0
>
> /free
>   emlDescr1 = newEmail()
>     // emlDescr1 is equal to 0000000001
>   emlDescr2 = newEmail()
>     // emlDescr2 is equal to 0000000002
>
>   addToAdr(emlDescr1:'me@yahoo.com')
>   addToAdr(emlDescr2:'ITDept@helpdesk.com')
>
>   error = sndEmail(emlDescr1)
>   if error <> ' '
>     sndEmail(emlDescr2)
>   endif
> /end-free
>
> In the example above I would create two emails.  Each time the newEmail()
> function was called I would increment a counter by 1 and send it back to
the
> calling program.  The way I was planning on storing them in my module was
to
> have an overlayed array called 'ToAdr' with the descriptor being the first
> subfield so I could tell which addresses belonged to each email.  For
> example:
>
>      D                 DS                              inz
>      D ToAdr                        266    dim(9999)
>      D  Descr                        10i 0 overlay(ToAdr)
>      D  Adr                         256    overlay(ToAdr:*next)
>
> Has anybody ever done something similar to creating your own descriptors
> before?  I am just trying to see if there is anything I should be watching
> out for. . .
>
> Aaron Bartell

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.