Re: BOM processing example? (WAS: Re: Procedure pointer)

I spent about 10 months last year developing a real time scheduling engine
that has me traversing bills of material.  I did this using recursion and
it runs very quick.  I'm very happy with the technique I used except for
the fact that every time I need to write a new procedure to traverse a
bill of material with different rules (different programs and purposes) I
have to copy the program, gut the business logic and replace it with the
current algorithm.

From what I'm hearing I could actually have just one general bill of

material traversing program and have different programs call it and then
inside of the BOM program call back to the caller for the rules processing
on each item?  I think this is what I'm reading here and if that is the
case I'd love to explore this more... with some help from list on this
technique since I never realized this was possible until this thread.


Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777



Simon Coulter <shc@xxxxxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
04/07/2010 04:24 PM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
cc

Subject
Re: Procedure pointer







On 07/04/2010, at 7:32 PM, David FOXWELL wrote:

Can Program1 call Program2 with a procedure pointer as a parameter
to tell program2 which subprocedure of program2 to call?

Simple answer is yes (and I see later appends give you information on
how to do that) but ...

I think this is impossible as Program1 needs to get the procedure
address of the subprocedures in program2. But, I am often wrong.

... this is where it gets weird. Normally this sort of behaviour is
used for a call-back routine. That is Program1 calls Program2 passing
a procedure pointer to a routine in Program1. Program2 then uses that
procedure pointer at some point in generic processing by "calling-
back" to Program1 to perform some operation that is specific to
Program1's requirements. It means Program2 can provide a generic
function that can be made more specific by the calling program.
Classic example is a sort function. The process of sorting is generic
but the actual data comparison is specific thus sort procedures often
take a procedure (or function) pointer to a specific comparison routine.

In your case you're doing the reverse; you want Program1 to invoke a
procedure in Program2 via a procedure pointer--almost as a direct call
into Program2. That means Program1 needs to know stuff about Program2
(otherwise known as tight-coupling). That would normally be better
served by a function-code parameter which Program1 uses to request
Program2 to perform a specific type of processing. This does result in
Program2 having a (possibly big) select statement that tests the
function-code and branches to the correct procedure but the resulting
interface is a lot cleaner than what you're proposing.

If you REALLY need Program1 to choose the procedures in Program2 then
Program2 should be a service program (with defined public interface)
and then you can just use normal ILE binding although you could also
use procedure pointers if required.

Seems to me you are trying to solve the wrong problem and as a result
making things far more complicated than they need be.

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         OS/400, i5/OS Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 2 6657 8251   Mobile: +61 0411 091 400        /"\
   Fax:   +61 2 6657 8251                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------



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



--- This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us and destroy this message immediately. ---
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.