Hi Benjamin,

no, it isn't.

I use a dispatcher routine which makes use of 3 containers (aka uniface lists).

the first container is some kind of envelope and holds informations what is requires
the second container contains all the input parameters
the third container holds all information which needs to be returned.

second and third conatiner are only important for the sender and the processor;
all parties in between just pass this string

this entry uses a selectcase to link to the processing utilities.

Very fast, very easy, extremely flexible (even for delegations) and a one-signature-only option.

Uli

This doesn't help with needing to create lots of operations but it may be of some help. One way to have these test operations in your code, but remove them when compiling for production is to use some pre-compiler directives and a global constant. If you wrap the test code with something like:

#if (<ENVIRONMENT> != "DEVELOPMENT")
...
#endif

Then in your development environment create a global constant called "ENVIRONMENT" with the value "DEVELOPMENT". In your build environment either remove the constant or have it set to "PRODUCTION".

This should allow you to create a "Testable" version and a "Production" version of your source.

Regards,

James

Hi Benjamin

There is no way to call a local entry dynamically at runtime.
But you can use your operation and then use a SELECTCASE statement to call the needed entry.

Something like this:

OPERATION DISPATCH
  params
    string v_ENTRY:IN
    string v_VALUES:INOUT
  endparams
  SELECTCASE v_ENTRY
  CASE "ENTRY1"
    call LP_ENTRY1(v_VALUES)
    RETURN($status)
  CASE "ENTRY2"
    call LP_ENTRY2(v_VALUES)
    RETURN($status)
...
  ELSECASE
    RETURN(-1109)
  ENDSELECTACSE
END

Gruß Ingo