_is_ibmi() returning incorrect result?

[soundstripe]

When I connect to my POWER9 running i7.4 via ssh and run

$ python3.6 -c "import sys; print(sys.platform)"

I get: 'aix7'

But _is_ibmi() seems to be checking for 'OS400' here. When I try to use ibm_db_dbi to connect to a database other than *LOCAL, I'm getting an error which seems related to this:

>>> import ibm_db_dbi
>>> ibm_db_dbi.connect('DATABASE=PRODDB', '', '')
Traceback (most recent call last):
  File "/QOpenSys/pkgs/lib/python3.6/site-packages/ibm_db_dbi.py", line 657, in _connect_helper
    ibm_db.set_option(conn, {SQL_ATTR_CURRENT_SCHEMA : user}, 1)
Exception: Supplied connection object Parameter is invalid

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/QOpenSys/pkgs/lib/python3.6/site-packages/ibm_db_dbi.py", line 667, in connect
    return _connect_helper(ibm_db.connect, dsn, user, password, host, database, conn_options)
  File "/QOpenSys/pkgs/lib/python3.6/site-packages/ibm_db_dbi.py", line 659, in _connect_helper
    raise _get_exception(inst)
ibm_db_dbi.Error: ibm_db_dbi::Error: Supplied connection object Parameter is invalid
>>>

The reason I think it is related is that if I first SET sys.platform = 'OS400', the connect() does complete properly.

I attempted to run a later version of ibm_db via pip install but as noted elsewhere (ibmdb#624) this is not currently working).

[kadler]

I think you meant to check this:

$ python3.6 -c "import platform; print(platform.system())"
OS400

Confusingly, Python has both sys.platform and platform.system()... (and we're using the latter)

Seems like there's a bug in the ibm_db_dbi code that is setting this attribute (which is not defined on IBM i) and perhaps IBM i 7.4 has changed behavior in how it deals with undefined/invalid attributes. Looks like this line should have been in the else block above it.

[soundstripe]

You're right... I thought I had double checked this but I was changing multiple things at a time.

Turns out it works for me as long as I use a DSN that includes UID and PWD like:
'DATABASE=PRODDB;UID=myuser;PWD=mypassword'

But not if I try to supply the user and password as the 2nd and 3rd params to the connect function. The platform was not the issue. Thanks!

[kadler]

Ahh yes, that's slightly confusing and something we inherited from upstream. You should use either a DSN string or the DB/UID/PWD parameters, but not both.