Really, it's complicated ?
The use-case for this is mainly developers who want to be able to consume Python scripts and data from standard RPG, CL and COBOL.
The audience may be limited, but I have lots of real-world use for this.
This caller takes the same approach as the MONO wrapper commands and other PASE/QSH front end commands I've written. Been using this same technique for the past 12+ years quite successfully with PHP, Node and Java and other misc commands, so they are pretty battle tested.
The PYRUN CL command allows the Python app to be run and STDOUT to be consumed via: IFS file, Outfile, Joblog or printed spool file and even displayed for debugging.
Parms and return code info are quite easy to return in the STDOUT buffer and then pick off from an RPG, CL or even a COBOL application by reading the outfile.
The idea for more specific system commands is to build them as a thin-veneer over the generic Python script call and then return parms to your hearts content.
Use as many or few of the PYRUN parms as you like and bury them in your own system commands like say: PYQRYDBXLS or PYSENDMAIL or PYFLASKSVR or something else and then allow your IBMi programmers who won't touch Python to use them. Win, win for the dev team.
One thing I will probably do at some point is convert the individual parms to a list like I did with the MONO command.
Not really many parms the user needs to sort through. Script dir, name and any desired parms are the only things required. Same thing I would do calling from QSH or PASE command line directly. The rest are convenience parms for logging.
As with every programming technique there are several ways to do things and we all have opinions. These specifically just happen to be mine and are time tested.
Since this is an open source initiative you can certainly contribute to it. I plan to use it for much of my IBMi specific Python work and am happy to also publish any command caller variants or examples that get contributed to the project by anyone.
Like many projects, participation is not guaranteed, but feedback and criticism are always.
It's a 90% chance I won't be at COMMON. Haven't presented for the past several years, although make sure to check out Calvins Mono presentation and say hello to him.
You can always reach me on Ryver, here, email or LinkedIn.
Regards,
Richard Schoen
Web:
http://www.richardschoen.net
Email: richard@xxxxxxxxxxxxxxxxx
Phn: (612) 315-1745
-----Original Message-----
Very interesting, excellent work, and now some quibbles:
- Somewhat elaborate in attempting a generalized CL launcher for Python
progs that makes using it fairly complicated.
- Very many parameters the user has to sort through.
- The defaults in simply running a Python program via QSH are often
correct.
- No provision is made for output parameters back into CL.
- We've discussed this at length on this list
- Several design patterns for that have been proposed
- I'll show two at COMMON
Overall, it's a good tutorial exercise. But instead of handing folks a
whale, it would be nice if they'd learn to fish for trout themselves. It's
very easy to call Python from CL and also to return values back into CL
params from Python. There are a few tricks around quoting for the shell,
etc., but overall, understanding the design pattern is likely to be more
useful on the ground and in the long run than learning to use a script
which attempts (and comes up short of) solving every problem.
I believe, Richard Schoen, you will be at COMMON next month. We should
attend each other's sessions and compare notes and maybe do some impromptu
discussion groups with other users.
midrange.com
