Antwort: Re: [DB2-L] DB2 z/OS V8 NFM - UNICODE -- EBCDIC madness

Roy Boxwell

Antwort: Re: [DB2-L] DB2 z/OS V8 NFM - UNICODE -- EBCDIC madness
With POSSTR now the first query finds nothing (of course!)
SELECT SUBSTR(STMT, 9 , 20) AS COL1
,POSSTR(STMT,CAST('SET' AS CHAR(3) CCSID UNICODE)) AS COL3
FROM SYSIBM.SYSPACKSTMT
WHERE LOCATION = ' '
AND COLLID = 'MVNXTEST'
AND NAME = 'MDB2ACT'
AND SUBSTR(STMT , 9 , 3) = 'SET'
;
---------+---------+---------+---------+---------+---------+------
COL1 COL3
---------+---------+---------+---------+---------+---------+------
DSNE610I NUMBER OF ROWS DISPLAYED IS 0
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100
---------+---------+---------+---------+---------+---------+------
SELECT SUBSTR(STMT, 9 , 20) AS COL1
,CAST(SUBSTR(STMT, 9 , 20) AS CHAR(20) CCSID EBCDIC) AS COL2
,POSSTR(STMT,CAST('SET' AS CHAR(3) CCSID UNICODE)) AS COL3
FROM SYSIBM.SYSPACKSTMT
WHERE LOCATION = ' '
AND COLLID = 'MVNXTEST'
AND NAME = 'MDB2ACT'
AND SUBSTR(STMT , 9 , 3) = 'SET'
;
---------+---------+---------+---------+---------+---------+------
COL1 COL2 COL3
---------+---------+---------+---------+---------+---------+------
DSNE610I NUMBER OF ROWS DISPLAYED IS 0
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100
---------+---------+---------+---------+---------+---------+------
SELECT SUBSTR(STMT, 9 , 20) AS COL1
,CAST(SUBSTR(STMT, 9 , 20) AS CHAR(20) CCSID EBCDIC) AS COL2
,POSSTR(STMT,CAST('SET' AS CHAR(3) CCSID UNICODE)) AS COL3
FROM SYSIBM.SYSPACKSTMT
WHERE LOCATION = ' '
AND COLLID = 'MVNXTEST'
AND NAME = 'MDB2ACT'
AND SUBSTR(STMT , 9 , 3) = CAST('SET' AS CHAR(3) CCSID UNICODE)
;
---------+---------+---------+---------+---------+---------+------
COL1 COL2 COL3
---------+---------+---------+---------+---------+---------+------
ëáè.+è â<á.< ëè^{ç + ëáè.+è â<á.< ëè^{ç + 9

Weird...
Roy Boxwell
SOFTWARE ENGINEERING GMBH
-Product Development-
Robert-Stolz-Strasse 5
40470 Duesseldorf/Germany
Tel. +49 (0)211 96149-0
Fax +49 (0)211 96149-35
E-mail [login to unmask email]
Homepage www.seg.de


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Mike Vaughan

Re: Antwort: Re: [DB2-L] DB2 z/OS V8 NFM - UNICODE -- EBCDIC madness
(in response to Roy Boxwell)
Sorry, I wasn't real clear on that -- I meant add the POSSTR and pull off the part of the where clause looking for "SET" (and qualify the row using something like STMTNO). The reason for wondering the results of this was to see where the "SET" actually ends up, which should give a little insight as to what is being converted and where. I found that I'm able to recreate this locally and have been able to confirm that my theory was not correct (the POSSTR returns a "9" in the cases where a row would be qualified and a "0" when it's not).
One of the things I have noticed in the past was that when converting the stmt text to ebcdic (using something along the lines of "CAST(CAST(STMT AS VARCHAR(3500) CCSID 1208) AS VARCHAR(3500) CCSID EBCDIC)" as mentioned in the "everything you wanted to know..." redbook), occasionally some of the text is truncated at the beginning when some of the control data combines with the statement text (for example, you might see ".........ET " instead of ".........SET "). My theory was that while "AND SUBSTR(STMT,9,3) = 'SET'" did not qualify a row, "AND SUBSTR(STMT,9,3) = 'ET '" might (or possibly "AND SUBSTR(STMT,9,2) = 'T '") due to the lead characters being swallowed up in a ccsid conversion. This *shouldn't* have impacted your query since you are explicitly looking in position 9, but I was thinking it may have come down to what is being converted and at which point (but as I mentioned, this doesn't appear to be the case).


________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Roy Boxwell
Sent: Friday, November 17, 2006 5:24 AM
To: [login to unmask email]
Subject: [DB2-L] Antwort: Re: [DB2-L] DB2 z/OS V8 NFM - UNICODE -- EBCDIC madness



With POSSTR now the first query finds nothing (of course!)
SELECT SUBSTR(STMT, 9 , 20) AS COL1
,POSSTR(STMT,CAST('SET' AS CHAR(3) CCSID UNICODE)) AS COL3
FROM SYSIBM.SYSPACKSTMT
WHERE LOCATION = ' '
AND COLLID = 'MVNXTEST'
AND NAME = 'MDB2ACT'
AND SUBSTR(STMT , 9 , 3) = 'SET'
;
---------+---------+---------+---------+---------+---------+------
COL1 COL3
---------+---------+---------+---------+---------+---------+------
DSNE610I NUMBER OF ROWS DISPLAYED IS 0
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100
---------+---------+---------+---------+---------+---------+------
SELECT SUBSTR(STMT, 9 , 20) AS COL1
,CAST(SUBSTR(STMT, 9 , 20) AS CHAR(20) CCSID EBCDIC) AS COL2
,POSSTR(STMT,CAST('SET' AS CHAR(3) CCSID UNICODE)) AS COL3
FROM SYSIBM.SYSPACKSTMT
WHERE LOCATION = ' '
AND COLLID = 'MVNXTEST'
AND NAME = 'MDB2ACT'
AND SUBSTR(STMT , 9 , 3) = 'SET'
;
---------+---------+---------+---------+---------+---------+------
COL1 COL2 COL3
---------+---------+---------+---------+---------+---------+------
DSNE610I NUMBER OF ROWS DISPLAYED IS 0
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100
---------+---------+---------+---------+---------+---------+------
SELECT SUBSTR(STMT, 9 , 20) AS COL1
,CAST(SUBSTR(STMT, 9 , 20) AS CHAR(20) CCSID EBCDIC) AS COL2
,POSSTR(STMT,CAST('SET' AS CHAR(3) CCSID UNICODE)) AS COL3
FROM SYSIBM.SYSPACKSTMT
WHERE LOCATION = ' '
AND COLLID = 'MVNXTEST'
AND NAME = 'MDB2ACT'
AND SUBSTR(STMT , 9 , 3) = CAST('SET' AS CHAR(3) CCSID UNICODE)
;
---------+---------+---------+---------+---------+---------+------
COL1 COL2 COL3
---------+---------+---------+---------+---------+---------+------
ëáè.+è â<á.< ëè^{ç + ëáè.+è â<á.< ëè^{ç + 9

Weird...
Roy Boxwell
SOFTWARE ENGINEERING GMBH
-Product Development-
Robert-Stolz-Strasse 5
40470 Duesseldorf/Germany
Tel. +49 (0)211 96149-0
Fax +49 (0)211 96149-35
E-mail [login to unmask email]
Homepage www.seg.de
--------------------------------------------------------------------------------- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm


-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to [login to unmask email] and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.

While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Sysdba AHE

Re: DB2 z/OS V8 NFM - UNICODE -- EBCDIC madness
(in response to Mike Vaughan)
Roy,

I've done some experimentation and determined that if you use
CAST(SUBSTR(STMT,9,50) AS CHAR(75) UNICODE FOR MIXED DATA) in your 3rd
example you'll get the SQL statement in printable EBCDIC. The increased
number of characters avoids a conversion error - I'm not sure why that
happens.

You've been trying to tell DB2 what to convert TO, which it already knows.
The above will tell DB2 to convert FROM Unicode - at the moment it's not
doing so because of the FOR BIT DATA attribute.

I know this doesn't solve the mystery of the WHERE clause, but it might
help you get what you want.

However there's a further mystery. I attempted to detect which statements
are Unicode and which are EBCDIC. I can do it with a UNION:

SELECT
SUBSTR(VERSION,1,16),
SUBSTR(STMT, 9 , 50)
FROM SYSIBM.SYSPACKSTMT
WHERE LOCATION = ' '
AND COLLID = 'DSNTEP2'
AND NAME = '[login to unmask email]'
AND CAST(SUBSTR(STMT, 9 , 1) AS CHAR(1) CCSID EBCDIC)
>= CAST('A' AS CHAR(1) CCSID EBCDIC)
AND SUBSTR(STMT , 9 , 3) = 'SET'
UNION ALL
SELECT
SUBSTR(VERSION,1,16),
CAST(SUBSTR(STMT, 9 , 50) AS CHAR(75) CCSID UNICODE FOR MIXED DATA)
FROM SYSIBM.SYSPACKSTMT
WHERE LOCATION = ' '
AND COLLID = 'DSNTEP2'
AND NAME = '[login to unmask email]'
AND CAST(SUBSTR(STMT, 9 , 1) AS CHAR(1) CCSID EBCDIC)
< CAST('A' AS CHAR(1) CCSID EBCDIC)
AND SUBSTR(STMT , 9 , 3) = CAST('SET' AS CHAR(3) CCSID UNICODE)
;
---------+---------+---------+---------+---------+---------+---------+-
---------+---------+---------+---------+---------+---------+---------+-
V6R1 SET CONNECTION : H Ø D SETCL
V7R1 SET CONNECTION : H Ø D SETCL
V7R1.A94911 SET : H = INTEGER ( CURRENT APPLICATION ENCODING S
V7R1.A94911 SET CONNECTION : H Ø D SETCL
V8R1.A21876 SET : H = INTEGER ( CURRENT APPLICATION ENCODING S
V8R1.A21876 SET CONNECTION : H SETCL
DSNT400I SQLCODE = 000, SUCCESSFUL EXECUTION
DSNT418I SQLSTATE = 01517 SQLSTATE RETURN CODE
DSNT416I SQLERRD = 0 0 0 -1 0 0 SQL DIAGNOSTIC INFORMATION
---------+---------+---------+---------+---------+---------+---------+-
DSNT416I SQLERRD = X'00000000' X'00000000' X'00000000' X'FFFFFFFF
X'00000000' X'00000000' SQL DIAGNOSTIC INFORMATION
DSNT417I SQLWARN0-5 = W,,,,, SQL WARNINGS
DSNT417I SQLWARN6-A = ,,W,, SQL WARNINGS
DSNE610I NUMBER OF ROWS DISPLAYED IS 6
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100
---------+---------+---------+---------+---------+---------+---------+-

but if I try to get rid of the UNION and use CASE, it doesn't work:

SELECT
SUBSTR(VERSION,1,16),
CASE WHEN
CAST(SUBSTR(STMT, 9 , 1) AS CHAR(1) CCSID EBCDIC)
< CAST('A' AS CHAR(1) CCSID EBCDIC)
THEN
CAST(SUBSTR(STMT, 9 , 50) AS CHAR(75) CCSID UNICODE FOR MIXED DATA)
ELSE
SUBSTR(STMT, 9 , 50)
END
FROM SYSIBM.SYSPACKSTMT
WHERE LOCATION = ' '
AND COLLID = 'DSNTEP2'
AND NAME = '[login to unmask email]'
AND ( SUBSTR(STMT , 9 , 3) = 'SET'
OR SUBSTR(STMT , 9 , 3) = CAST('SET' AS CHAR(3) CCSID UNICODE)
)
;
---------+---------+---------+---------+---------+---------+---------+-
---------+---------+---------+---------+---------+---------+---------+-
V6R1 SET CONNECTION : H Ø D SETCL
V7R1 SET CONNECTION : H Ø D SETCL
V7R1.A94911 SET : H = INTEGER ( CURRENT APPLICATION ENCODING S
V7R1.A94911 SET CONNECTION : H Ø D SETCL
V8R1.A21876 ëáè ç ñ+èáåáê äíêêá+è &&<ñä èñ!+ á+ä!àñ+å ë
V8R1.A21876 ëáè ä!++áäèñ!+ ç Ø D ëáèä<
DSNE610I NUMBER OF ROWS DISPLAYED IS 6
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100
---------+---------+---------+---------+---------+---------+---------+-

Where am I going wrong?

Neil Price
TNT Express, UK

---------------------------------------------------------------------------------------------------------------
This message and any attachment are confidential and may be privileged or otherwise protected from disclosure.
If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system.
If you are not the intended recipient you must not copy this message or attachment or disclose the contents to any other person.
---------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Mike Bell

Re: DB2 z/OS V8 NFM - UNICODE -- EBCDIC madness
(in response to Sysdba AHE)

The information in SYSSTMT and SYSPACKSTMT is closely tied to the format of
the DBRM.
The DBRM is mapped by DSNXDBRM from SDSNMACS. The field that identifies if
a DBRM is unicode is col 79 of the first line of the DBRM = 'L'
col 80 is of course the version of the precompiler that created the DBRM.
The DBRM header is the row in SYSPACKSTMT that has SEQNO, SECTNO, STMTNO all
= 0 but the information in SYSPACKSTMT starts with position 33 of the DBRM
header and it is alway in EBCIDIC (well positions 47 and 48 are - the rest
is bitmaped flags from the DBRM). If the character in position 47 of
SYSPACKSTMT header is 'L' then the DBRM was created with NEWFUN and the rest
of the text is unicode. As other people have mentioned, the SQL text starts
in position 9 for a length that depends on the source from the DBRM. One SQL
statement can span multiple rows in SYSPACKSTMT.

This assumes that the information in SYSPACKSTMT is not the result of a BIND
COPY from a different subsystem. The BIND COPY does not copy all the
expected information from the source subsystem.

Mike
HLS Technologies


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of Sysdba AHE
Sent: Friday, November 17, 2006 12:23 PM
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 z/OS V8 NFM - UNICODE -- EBCDIC madness


Roy,

I've done some experimentation and determined that if you use
CAST(SUBSTR(STMT,9,50) AS CHAR(75) UNICODE FOR MIXED DATA) in your 3rd
example you'll get the SQL statement in printable EBCDIC. The increased
number of characters avoids a conversion error - I'm not sure why that
happens.

You've been trying to tell DB2 what to convert TO, which it already knows.
The above will tell DB2 to convert FROM Unicode - at the moment it's not
doing so because of the FOR BIT DATA attribute.

I know this doesn't solve the mystery of the WHERE clause, but it might help
you get what you want.

However there's a further mystery. I attempted to detect which statements
are Unicode and which are EBCDIC. I can do it with a UNION:

SELECT
SUBSTR(VERSION,1,16),
SUBSTR(STMT, 9 , 50)
FROM SYSIBM.SYSPACKSTMT
WHERE LOCATION = ' '
AND COLLID = 'DSNTEP2'
AND NAME = '[login to unmask email]'
AND CAST(SUBSTR(STMT, 9 , 1) AS CHAR(1) CCSID EBCDIC)
>= CAST('A' AS CHAR(1) CCSID EBCDIC)
AND SUBSTR(STMT , 9 , 3) = 'SET'
UNION ALL
SELECT
SUBSTR(VERSION,1,16),
CAST(SUBSTR(STMT, 9 , 50) AS CHAR(75) CCSID UNICODE FOR MIXED DATA)
FROM SYSIBM.SYSPACKSTMT
WHERE LOCATION = ' '
AND COLLID = 'DSNTEP2'
AND NAME = '[login to unmask email]'
AND CAST(SUBSTR(STMT, 9 , 1) AS CHAR(1) CCSID EBCDIC)
< CAST('A' AS CHAR(1) CCSID EBCDIC)
AND SUBSTR(STMT , 9 , 3) = CAST('SET' AS CHAR(3) CCSID UNICODE)
;
---------+---------+---------+---------+---------+---------+---------+-
---------+---------+---------+---------+---------+---------+---------+-
V6R1 SET CONNECTION : H Ø D SETCL
V7R1 SET CONNECTION : H Ø D SETCL
V7R1.A94911 SET : H = INTEGER ( CURRENT APPLICATION ENCODING S
V7R1.A94911 SET CONNECTION : H Ø D SETCL
V8R1.A21876 SET : H = INTEGER ( CURRENT APPLICATION ENCODING S
V8R1.A21876 SET CONNECTION : H SETCL
DSNT400I SQLCODE = 000, SUCCESSFUL EXECUTION
DSNT418I SQLSTATE = 01517 SQLSTATE RETURN CODE
DSNT416I SQLERRD = 0 0 0 -1 0 0 SQL DIAGNOSTIC INFORMATION
---------+---------+---------+---------+---------+---------+---------+-
DSNT416I SQLERRD = X'00000000' X'00000000' X'00000000' X'FFFFFFFF
X'00000000' X'00000000' SQL DIAGNOSTIC INFORMATION
DSNT417I SQLWARN0-5 = W,,,,, SQL WARNINGS
DSNT417I SQLWARN6-A = ,,W,, SQL WARNINGS
DSNE610I NUMBER OF ROWS DISPLAYED IS 6
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100
---------+---------+---------+---------+---------+---------+---------+-

but if I try to get rid of the UNION and use CASE, it doesn't work:

SELECT
SUBSTR(VERSION,1,16),
CASE WHEN
CAST(SUBSTR(STMT, 9 , 1) AS CHAR(1) CCSID EBCDIC)
< CAST('A' AS CHAR(1) CCSID EBCDIC)
THEN
CAST(SUBSTR(STMT, 9 , 50) AS CHAR(75) CCSID UNICODE FOR MIXED DATA)
ELSE
SUBSTR(STMT, 9 , 50)
END
FROM SYSIBM.SYSPACKSTMT
WHERE LOCATION = ' '
AND COLLID = 'DSNTEP2'
AND NAME = '[login to unmask email]'
AND ( SUBSTR(STMT , 9 , 3) = 'SET'
OR SUBSTR(STMT , 9 , 3) = CAST('SET' AS CHAR(3) CCSID UNICODE)
)
;
---------+---------+---------+---------+---------+---------+---------+-
---------+---------+---------+---------+---------+---------+---------+-
V6R1 SET CONNECTION : H Ø D SETCL
V7R1 SET CONNECTION : H Ø D SETCL
V7R1.A94911 SET : H = INTEGER ( CURRENT APPLICATION ENCODING S
V7R1.A94911 SET CONNECTION : H Ø D SETCL
V8R1.A21876 ëáè ç ñ+èáåáê äíêêá+è &&<ñä èñ!+ á+ä!àñ+å ë
V8R1.A21876 ëáè ä!++áäèñ!+ ç Ø D ëáèä<
DSNE610I NUMBER OF ROWS DISPLAYED IS 6
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100
---------+---------+---------+---------+---------+---------+---------+-

Where am I going wrong?

Neil Price
TNT Express, UK



----------------------------------------------------------------------------
-----------------------------------
This message and any attachment are confidential and may be privileged or
otherwise protected from disclosure.
If you are not the intended recipient, please telephone or email the sender
and delete this message and any attachment from your system.
If you are not the intended recipient you must not copy this message or
attachment or disclose the contents to any other person.
----------------------------------------------------------------------------
-----------------------------------



----------------------------------------------------------------------------
----- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Sysdba AHE

Re: DB2 z/OS V8 NFM - UNICODE -- EBCDIC madness
(in response to Mike Bell)
I found that this query works for me:

SELECT
SUBSTR(VERSION,1,16),
CASE WHEN
CAST(SUBSTR(STMT, 9 , 1) AS CHAR(1) CCSID EBCDIC)
< CAST('A' AS CHAR(1) CCSID EBCDIC)
THEN
CAST(
CAST(SUBSTR(STMT,9,50) AS CHAR(60) CCSID UNICODE FOR MIXED DATA)
AS CHAR(60) CCSID EBCDIC)
ELSE
SUBSTR(STMT, 9 , 50)
END
FROM SYSIBM.SYSPACKSTMT
WHERE LOCATION = ' '
AND COLLID = 'DSNTEP2'
AND NAME = '[login to unmask email]'
AND ( SUBSTR(STMT , 9 , 3) = 'SET'
OR SUBSTR(STMT , 9 , 3) = CAST('SET' AS CHAR(3) CCSID UNICODE)
)
;

I think the extra CAST fixes a mismatch between the 2 possible results
which was preventing the first CAST from being effective.

Thanks to Mike Bell for the info about the proper way to identify a Unicode
DBRM. I'll give that a go later.

Neil Price
TNT Express, UK



---------------------------------------------------------------------------------------------------------------
This message and any attachment are confidential and may be privileged or otherwise protected from disclosure.
If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system.
If you are not the intended recipient you must not copy this message or attachment or disclose the contents to any other person.
---------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Roy Boxwell

DB2 z/OS V8 NFM - UNICODE -- EBCDIC madness
(in response to Sysdba AHE)
thanks to all who have replied, the last query works for me as well but
the *really* weird bit is that the original queries worked about 1 year
ago.....ho humm....

Roy Boxwell
SOFTWARE ENGINEERING GMBH
-Product Development-
Robert-Stolz-Strasse 5
40470 Duesseldorf/Germany
Tel. +49 (0)211 96149-0
Fax +49 (0)211 96149-35
E-mail [login to unmask email]
Homepage www.seg.de





Sysdba AHE <[login to unmask email]>
Gesendet von: DB2 Data Base Discussion List <[login to unmask email]>
17.11.2006 22:41
Bitte antworten an DB2 Database Discussion list at IDUG


An: [login to unmask email]
Kopie:
Thema: Re: [DB2-L] DB2 z/OS V8 NFM - UNICODE -- EBCDIC madness


I found that this query works for me:

SELECT
SUBSTR(VERSION,1,16),
CASE WHEN
CAST(SUBSTR(STMT, 9 , 1) AS CHAR(1) CCSID EBCDIC)
< CAST('A' AS CHAR(1) CCSID EBCDIC)
THEN
CAST(
CAST(SUBSTR(STMT,9,50) AS CHAR(60) CCSID UNICODE FOR MIXED DATA)
AS CHAR(60) CCSID EBCDIC)
ELSE
SUBSTR(STMT, 9 , 50)
END
FROM SYSIBM.SYSPACKSTMT
WHERE LOCATION = ' '
AND COLLID = 'DSNTEP2'
AND NAME = '[login to unmask email]'
AND ( SUBSTR(STMT , 9 , 3) = 'SET'
OR SUBSTR(STMT , 9 , 3) = CAST('SET' AS CHAR(3) CCSID UNICODE)
)
;

I think the extra CAST fixes a mismatch between the 2 possible results
which was preventing the first CAST from being effective.

Thanks to Mike Bell for the info about the proper way to identify a
Unicode
DBRM. I'll give that a go later.

Neil Price
TNT Express, UK



---------------------------------------------------------------------------------------------------------------
This message and any attachment are confidential and may be privileged or
otherwise protected from disclosure.
If you are not the intended recipient, please telephone or email the
sender and delete this message and any attachment from your system.
If you are not the intended recipient you must not copy this message or
attachment or disclose the contents to any other person.
---------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email]
Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm



---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Myron Miller

DB2 Z/OS V8 NFM
(in response to Roy Boxwell)
I'm just starting to play with MQTs in NFM on DB2 Z/OS. One item that I ran
into is that if a query is using the MQT, it can return wrong data if the
underlying base table is updated after the refresh of the MQT and there is no
way of knowing that.

Anybody have any experience in this area. Needless to say, this worries me
about SYSTEM MAINTAINED MQTs. Certainly, I can setup triggers to ensure that
the MQT is always kept current but then that eliminates the need for a REFRESH.

Comments.

Myron

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Tom Moulder

Re: DB2 Z/OS V8 NFM
(in response to Myron Miller)
Myron

If the MQT is defined as SYSTEM maintained, then the query returned a result
set that you did not want; however, it did return the correct result set
based on the definition of the MQT. The manuals are clear that if you
define an MQT as SYSTEM maintained, then the data returned from the MQT will
be current as of the last refresh. While an MQT may resemble a view in many
respects, it is the materialization of the view at a point in time that is
stored in a table for later use.

There are many uses for an MQT that allow for return of data that does not
represent current data in the underlying base table(s).

Tom Moulder
TREX Associates, Inc.
9728 Delmonico Dr.
Keller, Tx. 76248-9559
+1 817 741-5549 Office
+1 817 741-5548 Fax
+1 682 558-6527 Mobile
[login to unmask email]
www.t-rex-associates.com


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of Myron Miller
Sent: Tuesday, November 21, 2006 4:15 PM
To: [login to unmask email]
Subject: [DB2-L] DB2 Z/OS V8 NFM

I'm just starting to play with MQTs in NFM on DB2 Z/OS. One item that I ran
into is that if a query is using the MQT, it can return wrong data if the
underlying base table is updated after the refresh of the MQT and there is
no
way of knowing that.

Anybody have any experience in this area. Needless to say, this worries me
about SYSTEM MAINTAINED MQTs. Certainly, I can setup triggers to ensure
that
the MQT is always kept current but then that eliminates the need for a
REFRESH.

Comments.

Myron

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org.
The IDUG List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at http://conferences.idug.org/index.cfm


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.11/543 - Release Date: 11/20/2006

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Myron Miller

Re: DB2 Z/OS V8 NFM
(in response to Tom Moulder)
Tom,
That may be true that there are uses for MQTs for non-accurate data.
But you can't use them to improve performance on any tables where you might
potentially need accurate current data. So the utility of them is nowhere near
what IBM has been promoting.

And the user doesn't know that there is a MQT. All he knows is that he's
getting different answers on a working query for some reason.

Consider that MQTs in UDB for Linux, et al have had full currency for several
years now. When data changes in the base table it's accurately reflected in the
MQT table as well automatically. Z/OS MQTs seem definitely like another good
idea that has been only partially implemented again. More or less like LOBs
were when they were first implemented in V6. Great feature, lousy support and
implementation. Same situation with Text Search extenders. Great feature but
didn't work with any real volumes on Z/OS and an especially cumbersome
implementation and coordination with Z/OS.

This practice reminds me of the early days of Oracle when they used to document
features coming that did not work on that version yet.

And "it's working as designed". IBM actually designed it for Z/OS to not
reflect current data rather than how they implemented it for Linux UDB. And
DB2 is the same DB2 on all platforms, NOT by design!

To say I'm a bit hacked off about the implementation specifics is probably an
understatement. My question would be why does IBM put in a feature that is
only partially implemented and rather than waiting to put it in correctly?
Advertising feature availability comes to mind.

Myron

--- Tom Moulder <[login to unmask email]> wrote:

> Myron
>
> If the MQT is defined as SYSTEM maintained, then the query returned a result
> set that you did not want; however, it did return the correct result set
> based on the definition of the MQT. The manuals are clear that if you
> define an MQT as SYSTEM maintained, then the data returned from the MQT will
> be current as of the last refresh. While an MQT may resemble a view in many
> respects, it is the materialization of the view at a point in time that is
> stored in a table for later use.
>
> There are many uses for an MQT that allow for return of data that does not
> represent current data in the underlying base table(s).
>
> Tom Moulder
> TREX Associates, Inc.
> 9728 Delmonico Dr.
> Keller, Tx. 76248-9559
> +1 817 741-5549 Office
> +1 817 741-5548 Fax
> +1 682 558-6527 Mobile
> [login to unmask email]
> www.t-rex-associates.com
>
>
> -----Original Message-----
> From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
> Of Myron Miller
> Sent: Tuesday, November 21, 2006 4:15 PM
> To: [login to unmask email]
> Subject: [DB2-L] DB2 Z/OS V8 NFM
>
> I'm just starting to play with MQTs in NFM on DB2 Z/OS. One item that I ran
> into is that if a query is using the MQT, it can return wrong data if the
> underlying base table is updated after the refresh of the MQT and there is
> no
> way of knowing that.
>
> Anybody have any experience in this area. Needless to say, this worries me
> about SYSTEM MAINTAINED MQTs. Certainly, I can setup triggers to ensure
> that
> the MQT is always kept current but then that eliminates the need for a
> REFRESH.
>
> Comments.
>
> Myron
>
> ----------------------------------------------------------------------------
> -----
> Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
> page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
> "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org.
> The IDUG List Admins can be reached at [login to unmask email] Find
> out the latest on IDUG conferences at http://conferences.idug.org/index.cfm
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.409 / Virus Database: 268.14.11/543 - Release Date: 11/20/2006
>
>
---------------------------------------------------------------------------------
> Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
> page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
> "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org.
> The IDUG List Admins can be reached at [login to unmask email] Find
> out the latest on IDUG conferences at http://conferences.idug.org/index.cfm
>

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Suresh Sane

Re: DB2 Z/OS V8 NFM
(in response to Myron Miller)
Myron,

I think you are misunderstanding the intent of MQTs. They work well in a
warehouse environment, the main reason for their existence. In an OLTP
environment, you have static & dynamic sql. Static never gets
auto-query-reqwrite. You get what you asked for - real table or mqt as you
sepcifiy (knowing the data may be inaccurate). For dynamic again, you
declare your intentions that you can tolerate data that is inaccuare by
specifying current refresh age = any. If you don't, DB2 honors your
request.

So, the bottom line is DB2 rewrites your query only if you say it is OK to
do so.

I do share your views about IBM advertising some features before they are
ready (or really useful). This one is NOT it.

Thx
Suresh


>From: Myron Miller <[login to unmask email]>
>Reply-To: DB2 Database Discussion list at IDUG <[login to unmask email]>
>To: [login to unmask email]
>Subject: Re: [DB2-L] DB2 Z/OS V8 NFM
>Date: Thu, 23 Nov 2006 08:47:59 -0800
>
>Tom,
> That may be true that there are uses for MQTs for non-accurate data.
>But you can't use them to improve performance on any tables where you might
>potentially need accurate current data. So the utility of them is nowhere
>near
>what IBM has been promoting.
>
>And the user doesn't know that there is a MQT. All he knows is that he's
>getting different answers on a working query for some reason.
>
>Consider that MQTs in UDB for Linux, et al have had full currency for
>several
>years now. When data changes in the base table it's accurately reflected in
>the
>MQT table as well automatically. Z/OS MQTs seem definitely like another
>good
>idea that has been only partially implemented again. More or less like
>LOBs
>were when they were first implemented in V6. Great feature, lousy support
>and
>implementation. Same situation with Text Search extenders. Great feature
>but
>didn't work with any real volumes on Z/OS and an especially cumbersome
>implementation and coordination with Z/OS.
>
>This practice reminds me of the early days of Oracle when they used to
>document
>features coming that did not work on that version yet.
>
>And "it's working as designed". IBM actually designed it for Z/OS to not
>reflect current data rather than how they implemented it for Linux UDB.
>And
>DB2 is the same DB2 on all platforms, NOT by design!
>
>To say I'm a bit hacked off about the implementation specifics is probably
>an
>understatement. My question would be why does IBM put in a feature that is
>only partially implemented and rather than waiting to put it in correctly?
>Advertising feature availability comes to mind.
>
>Myron
>
>--- Tom Moulder <[login to unmask email]> wrote:
>
> > Myron
> >
> > If the MQT is defined as SYSTEM maintained, then the query returned a
>result
> > set that you did not want; however, it did return the correct result set
> > based on the definition of the MQT. The manuals are clear that if you
> > define an MQT as SYSTEM maintained, then the data returned from the MQT
>will
> > be current as of the last refresh. While an MQT may resemble a view in
>many
> > respects, it is the materialization of the view at a point in time that
>is
> > stored in a table for later use.
> >
> > There are many uses for an MQT that allow for return of data that does
>not
> > represent current data in the underlying base table(s).
> >
> > Tom Moulder
> > TREX Associates, Inc.
> > 9728 Delmonico Dr.
> > Keller, Tx. 76248-9559
> > +1 817 741-5549 Office
> > +1 817 741-5548 Fax
> > +1 682 558-6527 Mobile
> > [login to unmask email]
> > www.t-rex-associates.com
> >
> >
> > -----Original Message-----
> > From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
>Behalf
> > Of Myron Miller
> > Sent: Tuesday, November 21, 2006 4:15 PM
> > To: [login to unmask email]
> > Subject: [DB2-L] DB2 Z/OS V8 NFM
> >
> > I'm just starting to play with MQTs in NFM on DB2 Z/OS. One item that I
>ran
> > into is that if a query is using the MQT, it can return wrong data if
>the
> > underlying base table is updated after the refresh of the MQT and there
>is
> > no
> > way of knowing that.
> >
> > Anybody have any experience in this area. Needless to say, this worries
>me
> > about SYSTEM MAINTAINED MQTs. Certainly, I can setup triggers to ensure
> > that
> > the MQT is always kept current but then that eliminates the need for a
> > REFRESH.
> >
> > Comments.
> >
> > Myron
> >
> >
>----------------------------------------------------------------------------
> > -----
> > Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
>home
> > page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
>select
> > "Join or Leave the list". The IDUG DB2-L FAQ is at
>http://www.idugdb2-l.org.
> > The IDUG List Admins can be reached at [login to unmask email]
>Find
> > out the latest on IDUG conferences at
>http://conferences.idug.org/index.cfm
> >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.409 / Virus Database: 268.14.11/543 - Release Date:
>11/20/2006
> >
> >
>---------------------------------------------------------------------------------
> > Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
>home
> > page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
>select
> > "Join or Leave the list". The IDUG DB2-L FAQ is at
>http://www.idugdb2-l.org.
> > The IDUG List Admins can be reached at [login to unmask email]
>Find
> > out the latest on IDUG conferences at
>http://conferences.idug.org/index.cfm
> >
>
>---------------------------------------------------------------------------------
>Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
>page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
>"Join or Leave the list". The IDUG DB2-L FAQ is at
>http://www.idugdb2-l.org. The IDUG List Admins can be reached at
>[login to unmask email] Find out the latest on IDUG conferences at
>http://conferences.idug.org/index.cfm

_________________________________________________________________
Stay up-to-date with your friends through the Windows Live Spaces friends
list.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Tom Moulder

Re: DB2 Z/OS V8 NFM
(in response to Suresh Sane)
Let's take these statements in order.

First, you use the term "non-accurate" data and I have a hard time with that
description. It may not be the results that you were looking for because it
is not current; however, according the description of an MQT when using DB2
for z/OS, the data is accurate.

MQT does not provide a cure all for application performance. When the user
is satisfied with data that may or may not be current, then an MQT can
provide significant performance improvements. This is especially true when
the query contains aggregations or summarizations and the MQT contains the
values already computed.

IBM has a ways to go yet for UDB to be the same in implementation across
platforms. MQT implementation is just one example.

I worked for a software company formerly and so my perspective on this may
be somewhat unusual. My previous employer spent significant time in
development analyzing as many permutations as possible of how a customer
might use a product and insuring that all possible uses of the product would
function as the casual user would expect. The result was that this company
was continual later than others with production releases, but the products
were for the most part considered to be the best in the industry. The
problem a company like that faces is gaining market share from an
established customer base for its competitors. This is even harder today
since most of management simply want to know if you can do your job with the
product you have. In that environment, the only way to displace the
competition is to provide a price that is lower than the competition's
maintenance costs. From a business perspective, try to sell this
combination to management --> I am going to spend more money and time in
development than all my competition and then when I get the product to
market I am going to have a one time license charge that is 20% of the
competition. On the other hand, like it or not, from a business
perspective, IBM has successfully delivered product after product with a
bare minimum support for each feature or function and then allowed the ETR
process to be the driving force behind the sophistication that gets added to
the products. I can tell you that no matter how hard you try with
feature/function matrix there will be many customers who come requesting
some change to a product. So, from a software development perspective,
deliver minimum function that requires the least amount of change to DB2 and
evolve the feature based on feedback of those users of the feature. Seems
to me like that is what you are saying about LOB data.

Going back to the original point, it seems to me that the real problem here
is that you have experience with MQT functionality on other platforms and
z/OS did not quite measure up to your expectations on this initial
implementation. It looks like its time for the ETR process to work its
magic on MQT for subsequent versions of DB2.

I'm not telling you that you have to like what is happening. However, I
would hope that my explanation will help you to understand what is
happening. Perhaps it will relieve a little bit of frustration.

Personally, I have done many a workshop, seminar or V8 migration contract
over the last two years and I have always stressed the reality of MQT usage
just as you have realized from your experience. I know that the manuals
make this implementation quite clear. So, I am disappointed that somehow
you were led to believe that an MQT on z/OS would be just like LUW.

Tom Moulder
TREX Associates, Inc.
9728 Delmonico Dr.
Keller, Tx. 76248-9559
+1 817 741-5549 Office
+1 817 741-5548 Fax
+1 682 558-6527 Mobile
[login to unmask email]
www.t-rex-associates.com


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of Myron Miller
Sent: Thursday, November 23, 2006 10:48 AM
To: [login to unmask email]
Subject: Re: [DB2-L] DB2 Z/OS V8 NFM

Tom,
That may be true that there are uses for MQTs for non-accurate data.
But you can't use them to improve performance on any tables where you might
potentially need accurate current data. So the utility of them is nowhere
near
what IBM has been promoting.

And the user doesn't know that there is a MQT. All he knows is that he's
getting different answers on a working query for some reason.

Consider that MQTs in UDB for Linux, et al have had full currency for
several
years now. When data changes in the base table it's accurately reflected in
the
MQT table as well automatically. Z/OS MQTs seem definitely like another good
idea that has been only partially implemented again. More or less like LOBs
were when they were first implemented in V6. Great feature, lousy support
and
implementation. Same situation with Text Search extenders. Great feature
but
didn't work with any real volumes on Z/OS and an especially cumbersome
implementation and coordination with Z/OS.

This practice reminds me of the early days of Oracle when they used to
document
features coming that did not work on that version yet.

And "it's working as designed". IBM actually designed it for Z/OS to not
reflect current data rather than how they implemented it for Linux UDB. And
DB2 is the same DB2 on all platforms, NOT by design!

To say I'm a bit hacked off about the implementation specifics is probably
an
understatement. My question would be why does IBM put in a feature that is
only partially implemented and rather than waiting to put it in correctly?
Advertising feature availability comes to mind.

Myron

--- Tom Moulder <[login to unmask email]> wrote:

> Myron
>
> If the MQT is defined as SYSTEM maintained, then the query returned a
result
> set that you did not want; however, it did return the correct result set
> based on the definition of the MQT. The manuals are clear that if you
> define an MQT as SYSTEM maintained, then the data returned from the MQT
will
> be current as of the last refresh. While an MQT may resemble a view in
many
> respects, it is the materialization of the view at a point in time that is
> stored in a table for later use.
>
> There are many uses for an MQT that allow for return of data that does not
> represent current data in the underlying base table(s).
>
> Tom Moulder
> TREX Associates, Inc.
> 9728 Delmonico Dr.
> Keller, Tx. 76248-9559
> +1 817 741-5549 Office
> +1 817 741-5548 Fax
> +1 682 558-6527 Mobile
> [login to unmask email]
> www.t-rex-associates.com
>
>
> -----Original Message-----
> From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
> Of Myron Miller
> Sent: Tuesday, November 21, 2006 4:15 PM
> To: [login to unmask email]
> Subject: [DB2-L] DB2 Z/OS V8 NFM
>
> I'm just starting to play with MQTs in NFM on DB2 Z/OS. One item that I
ran
> into is that if a query is using the MQT, it can return wrong data if the
> underlying base table is updated after the refresh of the MQT and there is
> no
> way of knowing that.
>
> Anybody have any experience in this area. Needless to say, this worries
me
> about SYSTEM MAINTAINED MQTs. Certainly, I can setup triggers to ensure
> that
> the MQT is always kept current but then that eliminates the need for a
> REFRESH.
>
> Comments.
>
> Myron
>
>
----------------------------------------------------------------------------
> -----
> Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home
> page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select
> "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org.
> The IDUG List Admins can be reached at [login to unmask email]
Find
> out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.409 / Virus Database: 268.14.11/543 - Release Date:
11/20/2006
>
>
----------------------------------------------------------------------------
-----
> Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home
> page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select
> "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org.
> The IDUG List Admins can be reached at [login to unmask email]
Find
> out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm
>

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org.
The IDUG List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at http://conferences.idug.org/index.cfm


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.14/547 - Release Date: 11/22/2006

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm