On 1/19/2019 12:08 PM, Jon Paris wrote:
I'm looking for as close to a call/parm as I can get.
In my opinion, Scott's UNIXCMD is as close as you're going to get.
The following is a discussion of using Python to assist an existing RPG
code base.
First I need to set expectations. Like OP, I have an existing RPG
program that needs Just One More Thing. Say I'm processing an incoming
file from a vendor that has 14 million rows and I need to convert as
many names as possible from upper to proper case. Python sure is
tempting in terms of LOC to achieve that goal.
Here's a minimalist example in RPG that uses UNIXCMD:
**free
// minimalist proof of concept
// this RPG program fires off a PASE / Python program
// by using Scott Klement's UNIXCMD
ctl-opt dftactgrp(*no) actgrp('QILE')
option(*srcstmt: *nodebugio: *nounref)
debug;
dcl-f pase disk(1024) handler('UNIXCMDOA' :paseCmd) usrOpn;
dcl-s paseCmd char(1024);
dcl-ds
stdout len(1024)
end-ds;
dcl-s msg char(52) ;
paseCmd = '/QOpenSys/pkgs/bin/python3 --version';
// the open fires the pase command as well as 'opens' the pipe to STDOUT
open pase;
// assume only one line comes back
// makes for the simplest (if stupid) example
read pase stdout;
// do something with the response
msg = stdout;
dsply msg;
close pase;
*inlr = *on;
For a production run, this would all get put into a sub-procedure and
then I'd have a simple properName = pythonUpper(custname); in the READ
loop in the mainline (really, in the input primary cycle, because my
program is a 2000 line monolith that was begun by a Sumerian scribe.)
That's a fair amount of wrapping for this particular present, and what
helped me considerably was thinking of Python as though it were on a
different system altogether. So whether one ultimately gets Python to
'talk back' via RPC (RFC 1050), Db2, data areas, pipes, message queues,
raw sockets, or a web service, it's really more akin to a process
running on a completely separate machine than it is to a sub-procedure
running on mine.
In summary, Python as an assistant to RPG seems do-able. In the near
future I plan to run 15M rows through the Python proper case converter
to see how the runtime performance is.
Alternatives I considered but abandoned:
1) Re-write the RPG program in Python and do all the work in Python.
Well, technically this is possible. Python reads and writes Db2 just
fine, but the idea of trying to work out all the business rules secretly
stashed away in all those indicators is enough to put me off my feed.
2) Refactor that RPG beast into sub-procedures / web services /
something that Python could invoke. Python would then become the
'primary cycle', reading and updating the proper database tables, while
the business rules would still live in RPG, usable by the rest of the
system. Haha, that was a good one!
3) Proper casing the names and sending them back to the vendor so that
*everyone* will have access to names that don't look like they were
typed in 1985.
Alternatives I'm still considering:
a) Make a new work file in the existing RPG-centric process. Add a new
Python program that reads the work file, and only proper cases the
names. Then fire the existing RPG program. This one has promise, but I'm
running out of 10 character names for scratch files. OK, that was an
exaggeration, but in a CLP that runs a dozen RPG programs, does 5
tagalong sorts and an addrout, do I really want another work file?
Maybe. I'll profile that too when I catch my breath.
b) Abandon the whole idea of proper cased names. Do people really care
that much if the letters they get in the mail are all upper case?
c) Write an RPG proper case routine. Until a few years ago, this would
have been my default position, my starting point. I have some naive code
that does the bulk of this work already, but the devil's in the details
as always...
midrange.com
