please lookup "rexxpg.pdf", chapter 9, Rexx C++ Application Programming

There you will find the C++ APIs documented, and among the documentation
you will find the new options and there the option named
"DIRECT_ENVIRONMENTS" which supplies a context for the purpose you need.
Chapter 9.13, Command Handler Interface, gives an example.

Instead of RexxStart() you would use RexxCreateInterpreter() and from a
thread context something like "CallProgram(...)". The new type handler
then will have the variable context available to it.

Therefore I think that no changes to the ooRexx 4.0 APIs are necessary
to accomodate to your needs.



James Johnson wrote:
> I have a library that implements CMS/TSO Piprlines support for the PC.
> I have interfaced this library to ooRexx 4.0. To accomplish this I had 
> to make so changes
> to the 4.0 beta.
> 1) The interface is thru a SubCom environment. I had to modify the 
> subcom CommandHandler to
>      pass a CallContext to the library entry point. Like the following:
>     __declspec(dllexport) RexxReturnCode REXXENTRY PipeSubCom(
>           RexxCallContext *context,
>           PCONSTRXSTRING Command, /* Command string passed from the 
> caller */
>           unsigned short *Flags, /* pointer too short for return of flags */
>            PRXSTRING Retstr) /* pointer to RXSTRING for RC return */
>      This was necessary because the PipeLine library creates several 
> threads to process the request.
>       Thus the RexxVariablePool is not available to these new threads.
>       The RexxCallContext provides the needed access via 
> GetContextVariable() and SetContextVariable().
>       Although for my testing purposes I did not do this, I think the 
> best way to handle this
>       would be to add a fourth optional parameter to the "RxSubCom 
> Register" request.
>        This optional parameter would specify the context to passed on a 
> call to the subcom entry point. IE
>              "rxsubcom register  rxpipe rxpipe pipesubcom  callcontext"
> 2)  The user is able to write their own pipeline stages in Rexx. The 
> pipeline invokes these stages via
>      a new Rexx function "RexxStartSubCom". This routine is just 
> RexxStart with an additional parameter.
>      I had to add an additional parameter for a pointer to the pipeline 
> context that the user stages is running
>      under. I stored this pointer in the "LocalEnvironment" directory. 
> The RexxCallContext has routines to
>      access this directory.  I am not particular where this pointer is 
> stored as long as I have access to it.
>      Also I am happy to use the new interface to invoke the user stages. 
> This way just seemed easier for my
>      testing purposes.
>      This is my new RexxStartSubCom:
>          int REXXENTRY RexxStartSubCom (
>            size_t,                       /* Num of args passed to rexx */
>            PCONSTRXSTRING,               /* Array of args passed to rex */
>            const char *,                 /* [d:][path] filename[.ext]  */
>            PRXSTRING,                    /* Loc of rexx proc in memory */
>             void *,                       /* SubCom context             */
>             const char *,                 /* ASCIIZ initial environment.*/
>             int,                          /* type (command,subrtn,funct) */
>             PRXSYSEXIT,                   /* SysExit env. names &  codes */
>             short *,                      /* Ret code from if numeric   */
>             PRXSTRING );                  /* Retvalue from the rexx proc */
> typedef RexxReturnCode (REXXENTRY *PFNREXXSTARTSUBCOM)(size_t, 
>        const  char *, PRXSTRING,  void *, const char *, int, PRXSYSEXIT, 
> short *,   PRXSTRING);
> #define REXXSTARTSUBCOM RexxStartSubCom
>        In ActivityDispather.hpp I changed the definition of
>             "virtual void invoke(PRXSYSEXIT exits, const char *env);"
>        to the following:
>                virtual void invoke(PRXSYSEXIT exits, const char *env, 
> void *subComContext);
>        Thus in my RexxStartSubCOm I have the following:
>            arguments.invoke(exits, envname, subComContext);
>         I also changed the other occurrences of arguments.invoke() to be:
>             arguments.invoke(exits, envname, NULL);
>          I modified the ActivityDispatcher::invoke() routine as follows:
>          void ActivityDispatcher::invoke(PRXSYSEXIT exits, const char 
> *env, void * subComContext)
>         {
>             // this creates a new instance to run under, with an active 
> activity
>            InstanceBlock instance(exits, env);
>            if (subComContext) {
>               RexxString *index = new_string("SubComContext");
>               RexxPointer *ptr = new_pointer(subComContext);
>               RexxDirectory *local = instance.instance->getLocal();
>               local->put(ptr, index);
>           }
>         // go run the instance on the current activity
>         instance.activity->run(*this);
>         } 
> Is there any chance of getting these changes into ooRexx 4.0?

The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
Oorexx-devel mailing list

Reply via email to