Re: [Oorexx-devel] CMS/TSO Pipelines support for Rexx
Sounds like a bug to meif you can provide a sample to debug it, that would be useful. Rick On Thu, May 14, 2009 at 4:37 PM, James Johnson j...@iland.net wrote: Rony G. Flatscher wrote: James, please lookup rexxpg.pdf, chapter 9, Rexx C++ Application Programming Interfaces. 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. HTH, ---rony Using the new APIs solved all of my problems. I have noticed one little annoyance though. When I create the interpreter instance I specify the option EXTERNAL_CALL_EXTENSIONS. This works fine for the initial program executed and the programs that it calls. However, when I do an AttachThread and then a CallProgram on the new thread, the program name must have the extension. It looks like the EXTERNAL_CALL_EXTENSIONS are not carried forward to the new thread. Is this by design or a bug? Thanks James Johnson -- 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 Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- 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 Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] CMS/TSO Pipelines support for Rexx
James, The CallProgram() API was not performing any path or extension resolution at all, so I'm a bit puzzled with your statement that this worked on the first invocation...it should not have worked at all. I've fixed this, but I'd like to verify with a sample program from you. If you'll open a bug and attach a program to that, I'll be able to verify my fix corrects your problem. Rick On Thu, May 14, 2009 at 4:37 PM, James Johnson j...@iland.net wrote: Rony G. Flatscher wrote: James, please lookup rexxpg.pdf, chapter 9, Rexx C++ Application Programming Interfaces. 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. HTH, ---rony Using the new APIs solved all of my problems. I have noticed one little annoyance though. When I create the interpreter instance I specify the option EXTERNAL_CALL_EXTENSIONS. This works fine for the initial program executed and the programs that it calls. However, when I do an AttachThread and then a CallProgram on the new thread, the program name must have the extension. It looks like the EXTERNAL_CALL_EXTENSIONS are not carried forward to the new thread. Is this by design or a bug? Thanks James Johnson -- 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 Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] CMS/TSO Pipelines support for Rexx
I went back and check my source code and I supply an extension on the first invocation. When I remove the extension it fails with error code 3001. Do you still need a sample program? Rick McGuire wrote: James, The CallProgram() API was not performing any path or extension resolution at all, so I'm a bit puzzled with your statement that this worked on the first invocation...it should not have worked at all. I've fixed this, but I'd like to verify with a sample program from you. If you'll open a bug and attach a program to that, I'll be able to verify my fix corrects your problem. Rick -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] CMS/TSO Pipelines support for Rexx
James,
please lookup rexxpg.pdf, chapter 9, Rexx C++ Application Programming
Interfaces.
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.
HTH,
---rony
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,
PCONSTRXSTRING,
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);
}
[Oorexx-devel] CMS/TSO Pipelines support for Rexx
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,
PCONSTRXSTRING,
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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
