icewall POC ODBC driver enhancement

From: Narain, Arvind
Sent: 2014年4月22日 8:21
To: Bhalgami, Chirag; Bhatt, Prashant; Lu, Ping (Daniel, HPIT-GADSC); Hegde, Anuradha
Cc: Kakarlamudi, Rao; Muddu, Rajeswari; Puppala, Pavani; Jin, Jian (Seth, HPIT-DS CDC)
Subject: Icewall issue

FYI. Encrypted passwords also should work, as long as we keep the fields as char and not varchar.

From: Bhalgami, Chirag
Sent: Monday, April 14, 2014 4:21 PM
To: Bhatt, Prashant; Narain, Arvind; Lu, Ping (Daniel, HPIT-GADSC); Hegde, Anuradha
Cc: Kakarlamudi, Rao; Muddu, Rajeswari
Subject: RE: Possible Fix for password error

Hi All,

Following IceWall configuration works with the Trafodion:
1. Set COL_FETCHSIZE_FIXED=1 in iwdb_spec_mysql.lib file
2. Set COL_DELSP=1 in dbattr.conf
3. Updated DDL script:

Added, Changed, Removed

CREATE TABLE NEO.ICEWALL.ICEWALLTEST
(
USERID CHAR(20) PRIMARY KEY NOT NULL NOT DROPPABLE,  Changed from: VARCHAR(20)
PASSWD CHAR(37) NOT NULL,
PASSCHANGE CHAR(1) NOT NULL,
PASSWDEXP CHAR(14) NULL,
PASSWDHIS CHAR(37) NULL,
CHGDATE CHAR(14) NULL,
LOGONDATE CHAR(14) NULL,
LASTDATE CHAR(14) NULL,
LOGONFAIL CHAR(14) NULL,
FAILCOUNT CHAR(38) DEFAULT 0 NOT NULL,  Changed from: NUMERIC(38)
LOCKOUT CHAR(1) DEFAULT 0 NOT NULL,
LOGONSTOP CHAR(1) DEFAULT 0 NOT NULL,
LOCKDATE CHAR(14) NULL,
LOGSTATUS CHAR(1) DEFAULT 0 NOT NULL
) ENGINE=InnoDB;

4. Updated DML script:

INSERT INTO icewalltest (USERID,PASSWD,PASSCHANGE,FAILCOUNT,LOCKOUT,LOGONSTOP,LOGSTATUS)
VALUES ('user06','user06','1','0','0','0','0');  Changed from encrypted value to the plain value

If VARCHAR fields needs to be used in a Trafodion table then the temporarily fixed driver provided by Daniel will be required. Otherwise, making above 4 changes will allow IceWall to work with Trafodion datalake drivers.

Thanks,
- Chirag

From: Bhatt, Prashant
Sent: Sunday, April 13, 2014 10:58 PM
To: Narain, Arvind; Lu, Ping (Daniel, HPIT-GADSC); Bhalgami, Chirag; Hegde, Anuradha
Cc: Kakarlamudi, Rao
Subject: RE: Possible Fix for password error

Hi Arvind,

Yes, your understanding is correct. Buffer length of 0 for a CHAR(x) is used to determine the length of the column and subsequent calls reads the data in chunks in an iterative loop.

And yes this iwdb_spec_mysql.lib:COL_FETCHSIZE_FIXED is used to handle columns as fixed length or varying length.

As for parameters, the following can change the behavior of the calls made to fetch the data
- COL_DELSP removes blank spaces
- COL_SIZEOF toggles between 32 bit and 64 bit data type while fetching the data
- COL_FETCHSIZE_FIXED handle columns as fixed length or varying length

Best regards,
Prashant

From: Narain, Arvind
Sent: Saturday, April 12, 2014 4:30 AM
To: Lu, Ping (Daniel, HPIT-GADSC); Bhalgami, Chirag; Hegde, Anuradha; Bhatt, Prashant
Cc: Kakarlamudi, Rao
Subject: RE: Possible Fix for password error

Hi Prashant,

Could you please check under what conditions would the software call SQLGetData with a bufferlength of 0 for a CHAR(x) column ? Is the software relying on the fact that SQLGetData will return the length and in the next call this length can be utilized? Searching on the net indicates that the correct behavior would be to get data in chunks if needed.

Also is this setting related or is there something that says to treat char columns as fixed length versus varying length? Any other parameter that would change the behavior of the calls made to fetch the data ?

iwdb_spec_mysql.lib:COL_FETCHSIZE_FIXED=0

Regards
Arvind

From: Narain, Arvind
Sent: Friday, April 11, 2014 10:57 AM
To: Lu, Ping (Daniel, HPIT-GADSC); Bhalgami, Chirag; Hegde, Anuradha; Bhatt, Prashant
Cc: Kakarlamudi, Rao
Subject: RE: Possible Fix for password error

Thanks Daniel

From: Lu, Ping (Daniel, HPIT-GADSC)
Sent: Friday, April 11, 2014 6:17 AM
To: Bhalgami, Chirag; Narain, Arvind; Hegde, Anuradha; Bhatt, Prashant
Subject: RE: Possible Fix for password error

Hi guys

Today, we are doing some debug on driver, we found the APP will be trying to get data length via SQLGetData() call with 0 bufferlength input parameter, which is a sophisticated usage.
Trafodion driver normally will only return available length only if the current call(SQLGetData) do return some characters. If the bufferlength for return is 0, then driver will not even evaluate the available character number at all(which behavior base on a performance consideration – if user don’t pull anything from driver, then driver do not need do the charset converting, so don’t know about actual length for the whole string. on the opposite, if driver do the charset converting, but user don’t want any result, it that a kind waste of CPU time?).

For your environment and test, I’ve made a temporary quick fix for you(pls do not delete or reinstall the driver). Now I have tested the UTT driver work great, can pass the login check. But this is not official fix, for this behavior, we need have some discussion with whole dev and QA team.

Hoping you will have a great weekend.

Regard
Daniel Lu