| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Strange interaction between DB2 and ESQL in zOS |
« View previous topic :: View next topic » |
| Author |
Message
|
| Testo |
 Posted: Thu Oct 28, 2004 10:21 am Post subject: Strange interaction between DB2 and ESQL in zOS |
 |
|
Centurion
Joined: 26 Feb 2003
Posts: 120
Location: Italy - Milan
|
WMQI 2.1 CD4 on zOS
DB2 7.1.1
We have the following ESQL code:
| Code: |
DECLARE new_id BLOB;
SET Environment.Variables.unique[] = PASSTHRU('SELECT GENERATE_UNIQUE() FROM SYSIBM.SYSDUMMY1');
SET new_id = CAST(Environment.Variables.unique[1].UNIQUE_ID AS BLOB);
|
The GENERATE_UNIQUE function returns a bit data character string 13 bytes long (CHAR(13) FOR BIT DATA) that is unique compared to any other execution of the same function.
This piece of code works great in Windows environment, returning effectively a bit data character string 13 bytes long; in zOS on the contrary, it returns a 16 bytes long one, where the last three bytes are x'404040', i.e. blanks.
We suspect this is a problem related to the interaction between DB2 and WMQI through the ODBC driver...
Have anyone of you encountered a similar behavior when treating bit data columns? Any suggestions?
Cheers,
Andrea Tedone
IBM IT Specialist |
|
| Back to top |
|
 |
| PGoodhart |
| Posted: Fri Oct 29, 2004 5:40 am Post subject: |
|
|
Master
Joined: 17 Jun 2004
Posts: 278
Location: Harrisburg PA
|
You may want to check the length of the field in the Database layout. I suspect that you will find it is 16 bits long. Depending on the driver settings it think it will pad with zeros or spaces automaticaly to maintain a fix length on the fields. I believe you can control this. Look for a pad with spaces option. Z/OS is such a different operating system and COBOL is so common on it, that it is fairly common practice to make everything a fixed length. It makes it a lot easier to put the data into a copybook if everything is fixed length. Beware that if anyone else is using the driver that you don't change the option without consulting with them. You could break a lot of programs by accident.
_________________
Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
| Back to top |
|
|
| Testo |
| Posted: Mon Nov 01, 2004 2:18 am Post subject: Thanks |
|
|
Centurion
Joined: 26 Feb 2003
Posts: 120
Location: Italy - Milan
|
Thank you Patrick for your reply.
We have performed some more experiments, trying to get the same kind of value from a table instead of the GENERATE_UNIQUE() DB2 function. And the problem is the same: performing a SELECT from a column defined as 'CHAR(13) FOR BIT DATA' where we INSERT a 13 BIT value through QMF and the GENERATE_UNIQUE() function, we got, in the eSQL, the same wrong data with the original exadecimal value plus '404040' appended at the end.
We are going to contact the WMQI support tomorrow morning to understand if there is already an APAR, otherways we are going to open a PMR.
Obviously, we can manipulate the eSQL code to cast that BIT value as a CHAR, reformat it through SUBSTRING and delete the '404040' appendix but this is in any case a problem that has to be investigated.
Cheers,
Andrea |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
