Re: CALL QP2SHELL variables

[Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>]

On thing to keep in mind while setting these types of job streams up.  
The most expensive (from the perspective of system resources)  action 
the system takes is start/stop jobs.  The amount of work that goes on to 
start, process, then end a job is very high.  At light loads, the system 
deals with lots of jobs without breaking  a sweat.  However if there is 
memory contention particularly in *MACHINE or *BASE pools or significant 
transaction rates, starting and stopping a significant number of jobs in 
a process like the one described below can bring a system into a 
non-responsive state in a hurry.

I believe the technique that Scott created (and Tony as well) avoids 
most of the job start/stop activity making the process significantly 
more efficient.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 11/21/2012 8:56 AM, Porterfield, Sean wrote:
> Hi Scott,
>
> I should have clarified some of the points in my question.
>
> The program with Qp2RunPase that calls the expect script is unrelated to the PHP script I initially mentioned in this thread; I hijacked my own thread based on your I/O comments.
>
> I copied the program several weeks ago from a much older one.  I do plan to change the technique used and follow your recommendations before I put the program into production.
>
> I called the program interactively from a command prompt.  It looked like it created a separate BCI job for every line in the expect script.  There is only one line in each spooled file, containing the name of the script followed by:
>
> [2]: spawn:  not found
> [3]: expect:  not found
> [4]: send:  not found
> [5]: expect:  not found
> [6]: send:  not found
> [7]: expect:  not found
> [8]: send:  not found
> [9]: expect:  not found
> [10]: send:  not found
>
> I know I've run the script, so I'm guessing I was in QP2TERM rather than calling a program.  Anyway, I'm not expecting (no pun intended) you to solve my problems on this, I was just wondering if your comment on the stdio descriptors related to the system creating multiple jobs with one line of spooled output in each instead of one BCI with all the results.
> --
> Sean Porterfield
>
>
> -----Original Message-----
> From: Scott Klement
> Sent: Tuesday, November 20, 2012 17:27
> To: Midrange Systems Technical Discussion
> Subject: Re: CALL QP2SHELL variables
>
> Hi Sean,
>
> QP2SHELL is really just a wrapper around Qp2RunPase to simplify it.
>
> In an interactive job, the ILE C stdio descriptors should map to the screen. In a batch job, they'll go to a spooled file, instead.
>
> If you wish to use either the Qp2RunPase or QP2SHELL API, I would recommend setting up descriptors properly.  To do that, you should use the pipe() API to create at least 2 descriptors (maybe 3 if you want to keep stderr/stdout separate.)  Then use the spawn() API to create a new job where the proper end of the pipe is associated with the proper descriptors in the new job.
>
> I do have an open source implementation of this spawn/pipe technique called "UNIXCMD", which also interfaces with an RPG SPECIAL file to make it as simple as possible.
> http://www.scottklement.com/unixcmd
>
> An IBMer named Tony Cairns also created one named popen that does the same thing -- though, unsurprisingly, I like mine better:-)  http://174.79.32.155/wiki/index.php/RPGpopen/RPGpopen
>
> But, of course you can write it yourself using pipe/spawn, too.
>
> Or, as I said in the last e-mail, you can simply call the QSH/STRQSH command instead of using QP2SHELL or Qp2RunPase.  STRQSH takes care of the pipes for you (but the disadvantage is you can't read the output directly into a program, you have to load it into a file first, then read the file.)
>
> -SK
>
>
> On 11/20/2012 1:00 PM, Porterfield, Sean wrote:
> > >
> > >  Is the part below why I get a bunch of spooled files when I run an
> > >  expect script?  (Despite your numerous emails telling me not to do it
> > >  this way;)  )
> > >
> > >  First time using expect on i, so of course I just copied my previous
> > >  setup.  Good time for me to improve and follow your recommendations.
> > >
> > >  Specifically, today is using Qp2RunPase from RPGLE rather than
> > >  QP2SHELL from CL, but your warnings applied to that previously.
> > >
> > >  --
> > >  Sean Porterfield
> > >
> > >
> > >  -----Original Message-----
> > >  From: Scott Klement
> > >  Sent: Monday, November 19, 2012 16:08
> > >  To: Midrange Systems Technical Discussion
> > >  Subject: Re: CALL QP2SHELL variables
> > >
> > >  Having said that -- I strongly discourage you from using QP2SHELL this way.  QP2SHELL does not create proper stdio descriptors (stdin, stdout,
> > >  stderr) but rather uses whatever the calling job has set up.  In this environment, that's either "nothing", or "the ILE C ones".  Neither of these are threadsafe.