[DB2 V8 NFM] IMMEDWRITE YES or NO

Walter Janißen

[DB2 V8 NFM] IMMEDWRITE YES or NO

Hi

In our installation we use IMMEDWRITE NO during package bind for almost all our packages. With some of them, we experience problems in a data sharing environment, because soemtimes a row was not found, although it was just inserted. This happens regardless of using the clause WITH UR. Now, we are pondering about changing the default of IMMEDWRITE to YES. What is the opinion of the list? Any hints or ideas are highly appreciated.

Mit freundlichen Grüßen
Walter Janißen

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Laufzeitarchitektur
Hans-Böckler-Str. 36
D-40477 Düsseldorf
Tel.: +49 211 477-2928
Fax: +49 211 477-2615
mailto:[login to unmask email]
http:// www.itergo.com
Vorsitzender des Aufsichtsrats: Dr. Torsten Oletzky
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Dr. Michael Regauer, Wolfgang Schön.
Sitz: Düsseldorf | Handelsregister: Amtsgericht Düsseldorf, HRB 37996


-----Ursprüngliche Nachricht-----
Von: DB2 Data Base Discussion List [mailto:[login to unmask email] Im Auftrag von Avram Friedman
Gesendet: Mittwoch, 9. Januar 2008 14:48
An: [login to unmask email]
Betreff: Re: [DB2-L] DB2 Log Analysis Tool

RAM
I discovered a a Goole search that the first message means

ALAA477I Error occurred during error processing.

Explanation:
Some problem occurred that prevented the normal processing of an error condition. This may be an expected or unexpected situation. For example, some errors can occur before enough information about the environment is available to properly handle message processing (expected situation). Other errors can occur because the environment has not been properly setup (unexpected situation). In either case, the true error message is displayed below this message



The second line does not look like the true error message My guess is the true code is ALAA069E which means

ALAA069E
ALAPARMS file bad for ssid, missing DB2 Log Analysis parm data.

Explanation
For the SSID specified on the message, there is missing configuration data.

User response
Verify that DB2® Log Analysis has been properly configured by your product administrator and that all needed parameters were provided for the failing subsystem.



If you are not the product administrator I suggest you contact him / her.
If you are the administrator then you should open a problem with the vendor.
For this particular product the vendor is probally IBM but it is possible that it might be Rocket Software (depending on your license agreement)

Best Wishes
Avram Friedman

By the way there is an old computer saying in the computer industry RTFM which means Read The F...ing Manual (IE look up the message). There are several different opinions concering the exact word the F stands for.



On Wed, 9 Jan 2008 12:49:24 +0530, Ramachandran A
<[login to unmask email]> wrote:

>Hi Listers
>
>We configured DB2 Log Analysis tool (V2R3) for DB2 v8.1 on zOS v1R8
system,

>following messages,
>
>ALAA477I: ERROR OCCURRED DURING ERROR PROCESSING
>ALAA069 <-ERROR MSG BEING PROCESSED
>

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Avram Friedman

Re: [DB2 V8 NFM] IMMEDWRITE YES or NO
(in response to Walter Janißen)
Walter
I suggest reviewing OLD 1999 and 2000 APARs
PQ22895
PQ25337

They introduced the IMMEDWRITE option and discuss other circumventions.

My view of the performance issue associate with IMMEDWRITE YES is that its
mostly midigated. In 99 and 00 people were using 1st generation CMOS boxes
for CFs and they were quite slow. Today I think most people are using ICFs
on there much faster general purpose production processors.

With IMMEDWRITE there is a risk that the same modified page will be written
to the CF more than once but the cost and CF capicity concerns with the
extra writes are reduced to the point of often being uninteresting.

I would still agree with the comments in the APAR that advise only using
IMMEDWRITE in the condition it identifies ... Spawned work on a diffrent
member.

Regards
Avram Friedman



On Wed, 9 Jan 2008 15:24:48 +0100, [login to unmask email] wrote:

>
>Hi
>
>In our installation we use IMMEDWRITE NO during package bind for almost all
our packages. With some of them, we experience problems in a data sharing
environment, because soemtimes a row was not found, although it was just
inserted. This happens regardless of using the clause WITH UR. Now, we are
pondering about changing the default of IMMEDWRITE to YES. What is the
opinion of the list? Any hints or ideas are highly appreciated.
>

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information, and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms