Thanks for reporting! I have particular interest in hearing what it's
like for folks whose "native" computing environment is IBM midrange.
First of all, did you have a particular reason to choose Python 2
instead of Python 3? If I had to guess, it would be that you had
already played around a little with iSeriesPython, which is a Python
2, so that was the most natural (and scientific!) step.
Further comments in-line below:
On Tue, Mar 7, 2017 at 5:26 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
The Python script uses ibm_db to access DB2 for i.
Hm. OK, did you really use ibm_db (directly), or ibm_db_dbi? If ibm_db
directly, any particular reason?
The reason I ask is that Python stipulates a standard programmer
interface to databases (you can Google it as PEP 249), and ibm_db_dbi
is meant as a kind of wrapper module which adheres to that standard.
"Naked" ibm_db is a somewhat lower-level and more DB2-specific
interface.
I used the new DB2
service UDTF qsys2.parse_statement() to extract the column names to be
used as the heading row. For 'select *' statements, this returns zero
columns, but the ibm_db2.columns() function will get the column names
from the table itself.
The Python standard database interface stipulates that cursor objects
should have an attribute (called "description") which gives you
exactly the columns that were retrieved, regardless of whether you
used the star. I don't know if cursors returned by ibm_db have this,
or whether you need to use ibm_db_dbi cursors. But it would go
something like
connection = ibm_db_dbi.connect(database='*LOCAL')
c1 = connection.cursor()
c1.execute('select col1, col2, col3 from myschema.mytable')
for column_info in c1.description:
print column_info
Those column_info objects are tuples, guaranteed to have the column
name and type in the leftmost two elements. Some implementations will
provide more info than that. To get just the column names, idiomatic
Python would probably be something like
column_names = [t[0] for t in c1.description]
I was going to say that finding the documentation was kind of a pain,
but it's such a new domain to me that I can't judge until I've got used
to the new idiom.
Which documentation? Python in general? IBM's Python? ibm_db? xlsxwriter?
I would like to find out where, if anywhere, your experiences differ
from mine; and work toward improving the situation.
Mixing CLP, Python, DB2, Excel, and the new DB2 services was very easy.
The only thing I wanted to do but didn't was to feed the exit code back
from Python to the CLP.
Interesting. I'm not sure how easy or useful that will be. I mean, I
understand why one would want to do it, and how it *ought to* be
useful. But I don't know if it works out that nicely in Python, and in
particular IBM's Python for PASE.
A while ago, you expressed a bit of confusion over how to mentally fit
Python into your RPG-centric modules-and-functions style of program
architecture. I think you were hoping that Python would somehow be
another language for writing subprocedures. I suggested that it
doesn't really fit that model. You can do modules and functions within
Python, and Python can call out to other stuff (like CL or RPG) and
get results back. But you don't generally call into Python to get a
return value, except from other Python code. (And this is pretty much
the case for all the scripting languages.) Any "results" you get from
Python tend to be in the form of database changes, IFS files, data
across a socket, etc. In other words, as viewed from the outside
world, Python is usually operating by side-effect. But from within
Python, you are free to have almost whatever architecture you like.
Altogether, quite a pleasant experience. I really like the short
feedback loop of an interpreted language.
Me too. I look forward to hearing more.
Oh, quick question: What are you using to edit your Python source? RDi?
John Y.
midrange.com
