× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I do this but I compile the service program with ACTGRP(*CALLER) and leave
LR off in the 'GET' sub-procedure. Actually it is an SQL sub-procedure that
returns a pointer to a MODS. Sort of like returning a record set.  The only
caveat is that I have to pass a numeric variable and populate it with the
number of records returned in order to process the MODS in the calling
procedure.


Thanks,

Mark


Mark Walter
Sr. Programmer/Analyst
Hanover Wire Cloth a div of CCX, Inc.
mwalter@hanoverwire.com
http://www.hanoverwire.com
717.637.3795 Ext.3040
/"\
\ /
 X
/ \



|--------+-------------------------------->
|        |          "Chevalier, Rick"     |
|        |          <Rick.Chevalier@americ|
|        |          redit.com>            |
|        |          Sent by:              |
|        |          rpg400-l-admin@midrang|
|        |          e.com                 |
|        |                                |
|        |                                |
|        |          11/22/2002 02:28 PM   |
|        |          Please respond to     |
|        |          rpg400-l              |
|        |                                |
|--------+-------------------------------->
  
>-----------------------------------------------------------------------------------------------------------|
  |                                                                             
                              |
  |       To:     "'rpg400-l@midrange.com'" <rpg400-l@midrange.com>             
                              |
  |       cc:                                                                   
                              |
  |       Subject:     RE: Main Proc for Subproc not compiling                  
                              |
  
>-----------------------------------------------------------------------------------------------------------|




Joe,

I don't think it's as easy as it sounds to allocate the storage and pass
back the record read.  I have tried this in some sub-procedures and ran
into
a problem.  When the sub-program ended the memory was released.  The
pointer
made it back to the calling program OK but the storage it pointed to didn't
contain the data I wanted.  I had to pass the pointer into the
sub-procedure
to make it work.

Of course it could be I just wasn't doing something correctly with the
sub-procedure.

Rick

 -----Original Message-----
From:           Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent:           Friday, November 22, 2002 1:30 PM
To:        rpg400-l@midrange.com
Subject:        RE: Main Proc for Subproc not compiling

> From: Barbara Morris
>
> You could return the structure instead of using a parm, but that might
> involve returning a "large value", which is not really recommended.

This is an interesting point, Barbara.  Let's say I want to create a group
of procedures that are, for lack of a better term, object-like.  By that, I
mean that I use them to grab data from the database, pass it around to
other
procedures, and eventually perhaps update it.  For example, let's say it's
item data.

Okay, I want to use a data structure to hold this data.  And since I can
have multiple "instances" of the data, I want the application, not the
procedure, to keep track of the storage.  Finally, say that one of the
procedures is the "create" (or perhaps "get" is a better word) procedure.
Something like this:

H nomain
FITEMFILE if      e       disk
D ItemDS      e ds               extname(ITEMFILE)

D GetItem   pr                   like(ItemDS) EXTPROC('GETITEM')
D   ItemKey                      like(ITEMNUMBER) const

ITEMBUMBER is an alpha field, so I could conceivably do:

C           eval  ItemDS = GetItem('MyItemKey')

But you're suggesting that returning a DS is not a good idea.  Why is that?
And what would you recommend instead?

D GetItem   pr             10I 0 EXTPROC('GETITEM')
D   ItemPtr                  *   const
D   ItemKey                      like(ITEMNUMBER) const

C           eval  rc = GetItem(%addr(ItemDS):'MyItemKey)

And having the called procedure copy the data into the pointer?  I actually
can see where this might have more utility, because the 'rc' allows for
better error checking.  I'm just trying to get my head around a generic way
to handle these sorts of object-based issues.

Way back when, we did exactly this sort of thing with C, although we
usually
went one step further:

H nomain
FITEMFILE if      e       disk
D ItemDS      e ds               extname(ITEMFILE) BASED(pItemDS)

D GetItem   pr                   like(pItemDS) EXTPROC('GETITEM')
D   ItemKey                      like(ITEMNUMBER) const

C           eval  pItemDS = GetItem('MyItemKey)

GetItem would actually allocate the memory for the ItemDS and return it.
We'd check pItemDS for null to check for an error.  I suppose I could just
as easily code:

D GetItem   pr             10I 0 EXTPROC('GETITEM')
D   ItemPtr                      like(pItemDS)
D   ItemKey                      like(ITEMNUMBER) const

C           eval  rc = GetItem(pItemDS:'MyItemKey)

Since pItemDS is not constant, the called procedure could allocate the
memory and update the pointer.

Given this plethora of options, which is suggested and why?

Joe

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







As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2024 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.