v8.1.4 new features

[PM \(pm3iinc-nospam\)]

For those interested in new features,
Suggested reading...

http://publib.boulder.ibm.com/infoce...help/index.jsp
Release info.
v8.1.4
app.dev.enhence ments
sql data change operations

Result set retrieval from SQL data-change operations

ex:
SELECT * FROM FINAL TABLE (INSERT ...)

You should also check the include columns page.
In UPDATE statements, you can use include columns to return both the old
and new column values for a row.

SELECT salary, oldSalary FROM FINAL TABLE
(UPDATE employee INCLUDE (oldSalary decimal(9,2))
SET oldSalary = salary, salary = salary * 1.05
WHERE job = 'CLERK')
PM

[Serge Rielau]

Mark,

I value that opinion and you are certainly not alone with it.
It used to be that every fixpack contained significant function.
This has since been changed (due to comments such as yours) to be split
into even and odd. Odd numbers are fixes only (V8 FP1 and V8 FP3). Even
numbers contain function (V8 FP2 and FP4.

The problem is, and I'm in no position to judge the resulting decision,
that there is significant pressure to get function out. This pressure is
not comming from within IBM. It is being placed on us by customers who
cannot accept to wait for feature x for another year.

I suppose you could stick with odd-fixpacks....

Cheers
Serge

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[Mark Yudkin]

As I mentioned, we had 8.1.3 - and a problem. And as I also said, IBM
support's stock response is "you're not current - install the latest Fixpak
and see if it fixes your problem". Unless you make it clear to support that
they should never insist on installation of even fixpaks, your suggestion of
sticking to odd fixaks won't help.

I would definitely prefer to wait for a function until it had been tested,
rather than being the poor bloke that tests and locates IBM's new (HIPER!)
defects due to their releasing inadequately tested code, whilst all I'm
trying to do is resolve some problem. In particular, I'd like to retain the
feeling that installing a fixpak is a relatively harmless operation that
does not require multi-month testing (new versions of a product get that
sort of testing as a matter of course). We, as service providers to our
users, need to be able to meet our service level agreements. And that means
we take the blame if you release buggy software and we go live with it,
regardless of who created the bug.

Microsoft learnt not to add functionality with fixpaks. NT4 SP3 was the last
major function-adder: they got yelled at enough after that, that they
stopped releasing new function in fixpaks. Instead they created the "Options
Pack" and related techniques for adding functionality (including bundling
with other server products). Perhaps IBM could create some form of separate
delivery mechanism for adding functionality; that way we - the customer -
could apply adequate testing to the functional enhancements, whilst
retaining a basic trust in the fixpak process as a vehicle for delivering
fixes to APARs.

As http://www-306.ibm.com/software/data...b/support.html puts it:
Authorized Program Analysis Reports, or APARs, are bugs in DB2's code that
require a fix. Fixes for APARs are provided through DB2 FixPaks.

Also, if you go to
http://www-306.ibm.com/cgi-bin/db2ww...oad.d2w/report,
you will note that FP4 is the only one listed. It mentions that earlier fixp
aks are available, but no warning is given that FP4 may be a buggier than
FP3 due to the addition if inadequately tested new functionality.

"Serge Rielau" <sr*****@ca.e ye-bee-m.com> wrote in message
news:bt******** **@hanover.toro lab.ibm.com...

Mark,

I value that opinion and you are certainly not alone with it.
It used to be that every fixpack contained significant function.
This has since been changed (due to comments such as yours) to be split
into even and odd. Odd numbers are fixes only (V8 FP1 and V8 FP3). Even
numbers contain function (V8 FP2 and FP4.

The problem is, and I'm in no position to judge the resulting decision,
that there is significant pressure to get function out. This pressure is
not comming from within IBM. It is being placed on us by customers who
cannot accept to wait for feature x for another year.

I suppose you could stick with odd-fixpacks....

Cheers
Serge

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[Larry]

Mark,

Just a couple of comments:

I never accept what appears to be a blanket directive from any support
analyst to install the latest fixpack as an initial attempt at
resolution of a problem, and you shouldn't either. I always make them
point to a specific reason or apar which they feel with a reasonable
degree of confidence would be highly likely to resolve the problem (and
direct my customers to do the same). If they can convince me (or if I'm
convinced that there is absolutely no other alternative way to move
forward), then I'll do it.

Another good practice that I recommend (whether using alternate fixpacks
or not) is to wait 4-8 weeks after a fixpack is published prior to
installing in a customer environment ... unless there is a HIPER that
is required for some reason. This is simply good systems mgt. and gives
any potential issues a chance to shakeout.

I don't really have much to add to your other comments ... although I
think you'd be surprised at the lengths that the lab goes through to
test fixpacks. It's really a very rigorous process that takes literally
weeks. Do you have some type of QA process that you normally put new
code through (either IBM or other)?

Larry Edelstein

Mark Yudkin wrote:

As I mentioned, we had 8.1.3 - and a problem. And as I also said, IBM
support's stock response is "you're not current - install the latest Fixpak
and see if it fixes your problem". Unless you make it clear to support that
they should never insist on installation of even fixpaks, your suggestion of
sticking to odd fixaks won't help.

I would definitely prefer to wait for a function until it had been tested,
rather than being the poor bloke that tests and locates IBM's new (HIPER!)
defects due to their releasing inadequately tested code, whilst all I'm
trying to do is resolve some problem. In particular, I'd like to retain the
feeling that installing a fixpak is a relatively harmless operation that
does not require multi-month testing (new versions of a product get that
sort of testing as a matter of course). We, as service providers to our
users, need to be able to meet our service level agreements. And that means
we take the blame if you release buggy software and we go live with it,
regardless of who created the bug.

Microsoft learnt not to add functionality with fixpaks. NT4 SP3 was the last
major function-adder: they got yelled at enough after that, that they
stopped releasing new function in fixpaks. Instead they created the "Options
Pack" and related techniques for adding functionality (including bundling
with other server products). Perhaps IBM could create some form of separate
delivery mechanism for adding functionality; that way we - the customer -
could apply adequate testing to the functional enhancements, whilst
retaining a basic trust in the fixpak process as a vehicle for delivering
fixes to APARs.

As http://www-306.ibm.com/software/data...b/support.html puts it:
Authorized Program Analysis Reports, or APARs, are bugs in DB2's code that
require a fix. Fixes for APARs are provided through DB2 FixPaks.

Also, if you go to
http://www-306.ibm.com/cgi-bin/db2ww...oad.d2w/report,
you will note that FP4 is the only one listed. It mentions that earlier fixp
aks are available, but no warning is given that FP4 may be a buggier than
FP3 due to the addition if inadequately tested new functionality.

"Serge Rielau" <sr*****@ca.e ye-bee-m.com> wrote in message
news:bt******** **@hanover.toro lab.ibm.com...

Mark,

I value that opinion and you are certainly not alone with it.
It used to be that every fixpack contained significant function.
This has since been changed (due to comments such as yours) to be split
into even and odd. Odd numbers are fixes only (V8 FP1 and V8 FP3). Even
numbers contain function (V8 FP2 and FP4.

The problem is, and I'm in no position to judge the resulting decision,
that there is significant pressure to get function out. This pressure is
not comming from within IBM. It is being placed on us by customers who
cannot accept to wait for feature x for another year.

I suppose you could stick with odd-fixpacks....

Cheers
Serge

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[Serge Rielau]

APAR# IY51795, just so we all knwo hwat we're talking about.

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[Mark Yudkin]

Unfortunately, the APAR text doesn't seem to have been made public just yet
(I can't locate it from
http://www.ibm.com/cgi-bin/db2www/da...ib.d2w/report).

"Serge Rielau" <sr*****@ca.e ye-bee-m.com> wrote in message
news:bt******** **@hanover.toro lab.ibm.com...

APAR# IY51795, just so we all knwo hwat we're talking about.

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[Mark Yudkin]

Unfortunately, the APAR text doesn't seem to have been made public just yet
(I can't locate it from
http://www.ibm.com/cgi-bin/db2www/da...ib.d2w/report).

"Serge Rielau" <sr*****@ca.e ye-bee-m.com> wrote in message
news:bt******** **@hanover.toro lab.ibm.com...

APAR# IY51795, just so we all knwo hwat we're talking about.

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[Mark Yudkin]

Of course we have a QA process that we use to test new releases, and indeed,
we apply these to DB2 fixpaks (as well as all other internal and external
code). We do not apply fixes to production until they've been through the QA
process. And we use a copy of the real database for testing, so as not to
get caught by scalability issues.

Nevertheless, we do have a different level of QA testing for new releases (a
long testing period) and fixpaks (generally, just a few weeks). Also, we
have no choice but to install a fixpak when IBM supports requires this to be
done before processing a PMR further (they usually claim some specific fix
as being possibly relevant). We can avoid new versions (IBM don't insist on
our upgrading to the latest version when the previous one is still
supported), but not fixpaks. This is part of my complaint about bundling of
new functionality in fixpaks.

Fixpaks are released very frequently. We cannot reasonably test a fixpak for
longer than it will take for the next one to arrive. As a result, we tend to
stay on an earlier release for some time after the new version is issued.

I fully accept that IBM test their fixes before releasing them in a fixpak.
My comment here concerns the risk of adding new functionality to what is
ostensibly a collection of fixes. It is my contention that the risk is too
great for the benefit, and such a gamble should not be taken.

"Larry" <la***@nospam.n et> wrote in message
news:gI******** **************@ news4.srv.hcvln y.cv.net...

Mark,

Just a couple of comments:

I never accept what appears to be a blanket directive from any support
analyst to install the latest fixpack as an initial attempt at
resolution of a problem, and you shouldn't either. I always make them
point to a specific reason or apar which they feel with a reasonable
degree of confidence would be highly likely to resolve the problem (and
direct my customers to do the same). If they can convince me (or if I'm
convinced that there is absolutely no other alternative way to move
forward), then I'll do it.

Another good practice that I recommend (whether using alternate fixpacks
or not) is to wait 4-8 weeks after a fixpack is published prior to
installing in a customer environment ... unless there is a HIPER that
is required for some reason. This is simply good systems mgt. and gives
any potential issues a chance to shakeout.

I don't really have much to add to your other comments ... although I
think you'd be surprised at the lengths that the lab goes through to
test fixpacks. It's really a very rigorous process that takes literally
weeks. Do you have some type of QA process that you normally put new
code through (either IBM or other)?

Larry Edelstein

Mark Yudkin wrote:

As I mentioned, we had 8.1.3 - and a problem. And as I also said, IBM
support's stock response is "you're not current - install the latest Fixpak and see if it fixes your problem". Unless you make it clear to support that they should never insist on installation of even fixpaks, your suggestion of sticking to odd fixaks won't help.

I would definitely prefer to wait for a function until it had been tested, rather than being the poor bloke that tests and locates IBM's new (HIPER!) defects due to their releasing inadequately tested code, whilst all I'm
trying to do is resolve some problem. In particular, I'd like to retain the feeling that installing a fixpak is a relatively harmless operation that
does not require multi-month testing (new versions of a product get that
sort of testing as a matter of course). We, as service providers to our
users, need to be able to meet our service level agreements. And that means we take the blame if you release buggy software and we go live with it,
regardless of who created the bug.

Microsoft learnt not to add functionality with fixpaks. NT4 SP3 was the last major function-adder: they got yelled at enough after that, that they
stopped releasing new function in fixpaks. Instead they created the "Options Pack" and related techniques for adding functionality (including bundling with other server products). Perhaps IBM could create some form of separate delivery mechanism for adding functionality; that way we - the customer - could apply adequate testing to the functional enhancements, whilst
retaining a basic trust in the fixpak process as a vehicle for delivering fixes to APARs.

As http://www-306.ibm.com/software/data...b/support.html puts it:
Authorized Program Analysis Reports, or APARs, are bugs in DB2's code that require a fix. Fixes for APARs are provided through DB2 FixPaks.

Also, if you go to
http://www-306.ibm.com/cgi-bin/db2ww...oad.d2w/report, you will note that FP4 is the only one listed. It mentions that earlier fixp aks are available, but no warning is given that FP4 may be a buggier than FP3 due to the addition if inadequately tested new functionality.

"Serge Rielau" <sr*****@ca.e ye-bee-m.com> wrote in message
news:bt******** **@hanover.toro lab.ibm.com...

Mark,

I value that opinion and you are certainly not alone with it.
It used to be that every fixpack contained significant function.
This has since been changed (due to comments such as yours) to be split
into even and odd. Odd numbers are fixes only (V8 FP1 and V8 FP3). Even
numbers contain function (V8 FP2 and FP4.

The problem is, and I'm in no position to judge the resulting decision,
that there is significant pressure to get function out. This pressure is
not comming from within IBM. It is being placed on us by customers who
cannot accept to wait for feature x for another year.

I suppose you could stick with odd-fixpacks....

Cheers
Serge

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[Blair Adamache]

FYI - Here's what I found about it on our internal system:

APAR= IY51795 SER= 069609 IN INCORROUT
With same where condition, using distinct will give more data w
ich do not match the where condition.
STAT= CLOSED
SB03/12/11 RC CL03/12/11 PD SEV= 2

RCOMP= 5765E6100 AIX 5L FOR POWE RREL= R510

ERROR DESCRIPTION:
Environment: WIN2K, DB2_v81, FP4.
Internal Defect# given by lv3: 303868

Sympton:
statement1:sele ct distinct(col) from <tbname> where <condition>
statement2:sele ct (col) from <tbname> where <condition>.
While statement1 and 2 have same where condition. statement1
return more records and those extra records actually do not
match the where condition.

Mark Yudkin wrote:

Unfortunately, the APAR text doesn't seem to have been made public just yet
(I can't locate it from
http://www.ibm.com/cgi-bin/db2www/da...ib.d2w/report).

"Serge Rielau" <sr*****@ca.e ye-bee-m.com> wrote in message
news:bt******** **@hanover.toro lab.ibm.com...

APAR# IY51795, just so we all knwo hwat we're talking about.

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[Bill Chen]

Hi Blair,
Thanks for the information. As we are going to move to V8, and our
application does use distinct. I have some questions about this APAR:
1. What kind of WHERE condition will cause the problem?
2. Is this problem only happened on WIN2K? or on other platform as
well (such as AIX)?
3. I think the fix will be included in the next Fixpack. When the next
Fixpack will be available?(or Where we can get the HotFix if the next
FP is too far away from now?)

Regards,

Bill
Blair Adamache <ba*******@2muc hspam.yahoo.com > wrote in message news:<3F******* *******@2muchsp am.yahoo.com>.. .

FYI - Here's what I found about it on our internal system:

APAR= IY51795 SER= 069609 IN INCORROUT
With same where condition, using distinct will give more data w
ich do not match the where condition.
STAT= CLOSED
SB03/12/11 RC CL03/12/11 PD SEV= 2

RCOMP= 5765E6100 AIX 5L FOR POWE RREL= R510

ERROR DESCRIPTION:
Environment: WIN2K, DB2_v81, FP4.
Internal Defect# given by lv3: 303868

Sympton:
statement1:sele ct distinct(col) from <tbname> where <condition>
statement2:sele ct (col) from <tbname> where <condition>.
While statement1 and 2 have same where condition. statement1
return more records and those extra records actually do not
match the where condition.

Mark Yudkin wrote:

Unfortunately, the APAR text doesn't seem to have been made public just yet
(I can't locate it from
http://www.ibm.com/cgi-bin/db2www/da...ib.d2w/report).

"Serge Rielau" <sr*****@ca.e ye-bee-m.com> wrote in message
news:bt******** **@hanover.toro lab.ibm.com...

APAR# IY51795, just so we all knwo hwat we're talking about.

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[Blair Adamache]

answers inline

Bill Chen wrote:

Hi Blair,
Thanks for the information. As we are going to move to V8, and our
application does use distinct. I have some questions about this APAR:
1. What kind of WHERE condition will cause the problem? can't comment on that 2. Is this problem only happened on WIN2K? or on other platform as
well (such as AIX)? all platfroms 3. I think the fix will be included in the next Fixpack. When the next
Fixpack will be available?(or Where we can get the HotFix if the next
FP is too far away from now?) It will be in fixpak 5, which may be out in 1-2 months. If that's too
long, contact IBM Support and ask for a special build.

Regards,

Bill
Blair Adamache <ba*******@2muc hspam.yahoo.com > wrote in message news:<3F******* *******@2muchsp am.yahoo.com>.. .

FYI - Here's what I found about it on our internal system:

APAR= IY51795 SER= 069609 IN INCORROUT
With same where condition, using distinct will give more data w
ich do not match the where condition.
STAT= CLOSED
SB03/12/11 RC CL03/12/11 PD SEV= 2

RCOMP= 5765E6100 AIX 5L FOR POWE RREL= R510

ERROR DESCRIPTION:
Environment : WIN2K, DB2_v81, FP4.
Internal Defect# given by lv3: 303868

Sympton:
statement1:se lect distinct(col) from <tbname> where <condition>
statement2:se lect (col) from <tbname> where <condition>.
While statement1 and 2 have same where condition. statement1
return more records and those extra records actually do not
match the where condition.

Mark Yudkin wrote:

Unfortunatel y, the APAR text doesn't seem to have been made public just yet
(I can't locate it from
http://www.ibm.com/cgi-bin/db2www/da...ib.d2w/report).

"Serge Rielau" <sr*****@ca.e ye-bee-m.com> wrote in message
news:bt***** *****@hanover.t orolab.ibm.com. ..
APAR# IY51795, just so we all knwo hwat we're talking about.

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab