ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103

Gary Snider

ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
Hello,

We are running DB2 V11 in conversion mode on our development system and monitoring IFCID 366 for application compatibility issues. We have several packages that have been reported for identifier 1103, which is related to the change on how the ASUTIME for dynamic statements is applied. While we do have RLF started on the system, it only has one package specified in DSNRLST01 as predictive. This is not one of the packages that was reported. The packages that were reported are used as stored procedures. However, it is my understanding that the ASUTIME specified in the stored procedure definition works independently of the RLF ASUTIME. So, I do not understand why these packages are being reported.

Would appreciate if someone could explain.

Thanks.

Andy Smith

RE: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
(in response to Gary Snider)

Gary

I've seen 1103 in our IFCID 366 traces too.

I'm not sure about your Stored Procedure question (being independent of RLF) but the DB2 11 Technical Overview offers this explanation regarding 1103 (which might explain why you are seeing packages reported that are not in RLF):

 

A DYNAMIC SQL STATEMENT USES THE ASUTIME LIMIT THAT WAS SET FOR THE ENTIRE THREAD FOR RLF REACTIVE GOVERNING.

FOR EXAMPLE, WHEN A DYNAMIC SQL STATEMENT IS PROCESSED FROM PACKAGE A, IF THE ASUTIME LIMIT WAS ALREADY SET DURING OTHER DYNAMIC SQL PROCESSING FROM PACKAGE B IN THE SAME THREAD, THE SQL FROM PACKAGE A USES THE ASUTIME LIMIT THAT WAS SET DURING THE SQL PROCESSING FROM PACKAGE B.

STARTING WITH V11, DYNAMIC SQL FROM MULTIPLE PACKAGES USES THE ASUTIME LIMIT THAT IS SET IN THEIR OWN PACKAGE INFORMATION.

 

I hope this helps
Andy 

Gary Snider

RE: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
(in response to Andy Smith)

Thanks for the reply Andy.  I have read that in the guide.  But, for me, that doesn't explain why the packages are showing up.  They are not specified in our RLF table.

Muthuraj Kumaresan

ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
(in response to Gary Snider)

Did you check if the SP runs any dynamic SQLs?

As per my understanding, dynamic SQLs inside the SP will have CPU threshold from RLF.. while whole SP will have limit from ASUTIME you mentioned as part of SP..

Sent from my iPhone

> On 9 Mar 2017, at 2:11 AM, Gary Snider <[login to unmask email]> wrote:
>
> Thanks for the reply Andy. I have read that in the guide. But, for me, that doesn't explain why the packages are showing up. They are not specified in our RLF table.
>
>
> Site Links: View post online View mailing list online Start new thread via email Unsubscribe from this mailing list Manage your subscription
>
> This email has been sent to: [login to unmask email]
> ** ** ** Attend the 2017 IDUG Tech Conference North America ** ** **
> ---> Anaheim, California, April 30 - May 04, 2017 <---
> http://www.idug.org/na
>
> Use of this email content is governed by the terms of service at:
> http://www.idug.org/p/cm/ld/fid=2
>

Walter Jani&#223;en

AW: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
(in response to Gary Snider)
Hi

I also check regularly these trace-records, more specific I am looking at IFCID376. I wonder, why this trace record with subtype 1103 is written at all. What shall we do with this information and how can we prevent that it is being written to get rid of these records. I decided to ignore these records and don’t do anything.

Kind regards
Walter Janißen [standard_IBM+Champ+7+Yr+Analytics]

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Technische Anwendungsarchitektur
Victoriaplatz 2
D-40198 Düsseldorf
[login to unmask email]<mailto:[login to unmask email]>

ITERGO Informationstechnologie GmbH
Vorsitzender des Aufsichtsrats: Christian Diedrich
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Lothar Engelke, Ina Kirchhof, Dr. Michael Regauer
Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf HRB 37996

Von: Gary Snider [mailto:[login to unmask email]
Gesendet: Mittwoch, 8. März 2017 19:11
An: [login to unmask email]
Betreff: [DB2-L] - RE: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103


Thanks for the reply Andy. I have read that in the guide. But, for me, that doesn't explain why the packages are showing up. They are not specified in our RLF table.

-----End Original Message-----
Attachments

  • image001.png (2.6k)

Mike Vaughan

ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
(in response to Walter Janißen)
My impression from looking through these records was any process doing dynamic sql from more than one package is cutting an 1103 record and I came to the same conclusion – seems like more of an information message stating that somethings going to change and really nothing that can be done about it (but we just thought you should know at least once for every transaction you run). I’m also just ignoring those and actually have the same issue but with more volume on the 1108 subtype. At this point we actually have the trace limited to exclude most ddf traffic since the volume of records (particularly the 1108’s) was so excessive but it sure would be nice to have an option to exclude specific subtypes from that trace (I’ll happily buy a beer for someone who can point out if that option exists and I just don’t know it).

Seems like a bit of a catch-22. I know the 1103/1108/etc will stop being produced if we rebind to applcompat(V11R1) but we can’t really do that without looking through the records to see what will really break by doing that rebind and I can’t really run the trace for any length of time due to the volume.

And on a side note, I’ve seen a comment a few times that the applcompat bind parameter doesn’t control dynamic sql but that seems pretty misleading when you chase it down. I suppose technically that may be correct, but since dynamic sql is controlled by the CURRENT APPLICATION COMPATIBILITY special register which is defaulted by the bind parameter on the package, it still has the same effect.

If anyone’s figured out the magic for working through this I’d love to hear it.

Thanks,
Mike Vaughan

From: Walter Janißen [mailto:[login to unmask email]
Sent: Thursday, March 09, 2017 8:56 AM
To: [login to unmask email]
Subject: [DB2-L] - AW: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103

Hi

I also check regularly these trace-records, more specific I am looking at IFCID376. I wonder, why this trace record with subtype 1103 is written at all. What shall we do with this information and how can we prevent that it is being written to get rid of these records. I decided to ignore these records and don’t do anything.

Kind regards
Walter Janißen [standard_IBM+Champ+7+Yr+Analytics]

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Technische Anwendungsarchitektur
Victoriaplatz 2
D-40198 Düsseldorf
[login to unmask email]<mailto:[login to unmask email]>

ITERGO Informationstechnologie GmbH
Vorsitzender des Aufsichtsrats: Christian Diedrich
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Lothar Engelke, Ina Kirchhof, Dr. Michael Regauer
Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf HRB 37996

Von: Gary Snider [mailto:[login to unmask email]
Gesendet: Mittwoch, 8. März 2017 19:11
An: [login to unmask email]<mailto:[login to unmask email]>
Betreff: [DB2-L] - RE: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103


Thanks for the reply Andy. I have read that in the guide. But, for me, that doesn't explain why the packages are showing up. They are not specified in our RLF table.

-----End Original Message-----

-----End Original Message-----
-----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.

If you no longer wish to receive any further solicitation from the Principal Financial Group you may unsubscribe at https://www.principal.com/do-not-contact-form any time.

If you are a Canadian resident and no longer wish to receive commercial electronic messages you may unsubscribe at https://www.principal.com/do-not-email-request-canadian-residents any time.

Chris Hoelscher

ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
(in response to Mike Vaughan)
At our site, we are ignoring the 1104-1108 and as a result the only non-bif hit we are getting is timestamp literal errors – and we have only of those in production – as such – after those are corrected (while in applcompat V10 mode), we will change the applcompat value to V11 across the board (prod and non-prod) – we will then go to work on modifying the char/varchar issues …

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
[Description: Description: cid:[login to unmask email]: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538

From: Vaughan, Mike [mailto:[login to unmask email]
Sent: Friday, March 10, 2017 12:02 PM
To: [login to unmask email]
Subject: [DB2-L] - RE: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103

My impression from looking through these records was any process doing dynamic sql from more than one package is cutting an 1103 record and I came to the same conclusion – seems like more of an information message stating that somethings going to change and really nothing that can be done about it (but we just thought you should know at least once for every transaction you run). I’m also just ignoring those and actually have the same issue but with more volume on the 1108 subtype. At this point we actually have the trace limited to exclude most ddf traffic since the volume of records (particularly the 1108’s) was so excessive but it sure would be nice to have an option to exclude specific subtypes from that trace (I’ll happily buy a beer for someone who can point out if that option exists and I just don’t know it).

Seems like a bit of a catch-22. I know the 1103/1108/etc will stop being produced if we rebind to applcompat(V11R1) but we can’t really do that without looking through the records to see what will really break by doing that rebind and I can’t really run the trace for any length of time due to the volume.

And on a side note, I’ve seen a comment a few times that the applcompat bind parameter doesn’t control dynamic sql but that seems pretty misleading when you chase it down. I suppose technically that may be correct, but since dynamic sql is controlled by the CURRENT APPLICATION COMPATIBILITY special register which is defaulted by the bind parameter on the package, it still has the same effect.

If anyone’s figured out the magic for working through this I’d love to hear it.

Thanks,
Mike Vaughan

From: Walter Janißen [mailto:[login to unmask email]
Sent: Thursday, March 09, 2017 8:56 AM
To: [login to unmask email]
Subject: [DB2-L] - AW: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103

Hi

I also check regularly these trace-records, more specific I am looking at IFCID376. I wonder, why this trace record with subtype 1103 is written at all. What shall we do with this information and how can we prevent that it is being written to get rid of these records. I decided to ignore these records and don’t do anything.

Kind regards
Walter Janißen [standard_IBM+Champ+7+Yr+Analytics]

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Technische Anwendungsarchitektur
Victoriaplatz 2
D-40198 Düsseldorf
[login to unmask email]<mailto:[login to unmask email]>

ITERGO Informationstechnologie GmbH
Vorsitzender des Aufsichtsrats: Christian Diedrich
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Lothar Engelke, Ina Kirchhof, Dr. Michael Regauer
Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf HRB 37996

Von: Gary Snider [mailto:[login to unmask email]
Gesendet: Mittwoch, 8. März 2017 19:11
An: [login to unmask email]<mailto:[login to unmask email]>
Betreff: [DB2-L] - RE: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103


Thanks for the reply Andy. I have read that in the guide. But, for me, that doesn't explain why the packages are showing up. They are not specified in our RLF table.

-----End Original Message-----

-----End Original Message-----
-----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]<mailto:[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.
If you no longer wish to receive any further solicitation from the Principal Financial Group you may unsubscribe at https://www.principal.com/do-not-contact-form any time.
If you are a Canadian resident and no longer wish to receive commercial electronic messages you may unsubscribe at https://www.principal.com/do-not-email-request-canadian-residents any time.


-----End Original Message-----

The information transmitted is intended only for the person or entity to which it is addressed
and may contain CONFIDENTIAL material. If you receive this material/information in error,
please contact the sender and delete or destroy the material/information.
Attachments

  • image002.jpg (<1k)

Muthuraj Kumaresan

ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
(in response to Chris Hoelscher)
Mike,

Did you try IFCID 376 instead of 366? That should reduce a lot of records.. it will cut one record for each unique combination..

Handling 1103 is a bit tricky.. IFCID 366/376 are not going to tell you the nested call details.. the best thing is that I will review the current dynamic SQL's CPU usage using dynamic SQL Cache or any vendor product and make sure the package which runs the SQL is configured with enough RLF limit..


Muthu
Sent from my iPhone

> On 11 Mar 2017, at 2:39 AM, Chris Hoelscher <[login to unmask email]> wrote:
>
> At our site, we are ignoring the 1104-1108 and as a result the only non-bif hit we are getting is timestamp literal errors – and we have only of those in production – as such – after those are corrected (while in applcompat V10 mode), we will change the applcompat value to V11 across the board (prod and non-prod) – we will then go to work on modifying the char/varchar issues …
>
> Chris Hoelscher
> Technology Architect, Database Infrastructure Services
> Technology Solution Services
> <image002.jpg>: humana.com
> 123 East Main Street
> Louisville, KY 40202
> Humana.com
> (502) 714-8615, (502) 476-2538
>
> From: Vaughan, Mike [mailto:[login to unmask email]
> Sent: Friday, March 10, 2017 12:02 PM
> To: [login to unmask email]
> Subject: [DB2-L] - RE: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
>
> My impression from looking through these records was any process doing dynamic sql from more than one package is cutting an 1103 record and I came to the same conclusion – seems like more of an information message stating that somethings going to change and really nothing that can be done about it (but we just thought you should know at least once for every transaction you run). I’m also just ignoring those and actually have the same issue but with more volume on the 1108 subtype. At this point we actually have the trace limited to exclude most ddf traffic since the volume of records (particularly the 1108’s) was so excessive but it sure would be nice to have an option to exclude specific subtypes from that trace (I’ll happily buy a beer for someone who can point out if that option exists and I just don’t know it).
>
> Seems like a bit of a catch-22. I know the 1103/1108/etc will stop being produced if we rebind to applcompat(V11R1) but we can’t really do that without looking through the records to see what will really break by doing that rebind and I can’t really run the trace for any length of time due to the volume.
>
> And on a side note, I’ve seen a comment a few times that the applcompat bind parameter doesn’t control dynamic sql but that seems pretty misleading when you chase it down. I suppose technically that may be correct, but since dynamic sql is controlled by the CURRENT APPLICATION COMPATIBILITY special register which is defaulted by the bind parameter on the package, it still has the same effect.
>
> If anyone’s figured out the magic for working through this I’d love to hear it.
>
> Thanks,
> Mike Vaughan
>
> From: Walter Janißen [mailto:[login to unmask email]
> Sent: Thursday, March 09, 2017 8:56 AM
> To: [login to unmask email]
> Subject: [DB2-L] - AW: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
>
> Hi
>
> I also check regularly these trace-records, more specific I am looking at IFCID376. I wonder, why this trace record with subtype 1103 is written at all. What shall we do with this information and how can we prevent that it is being written to get rid of these records. I decided to ignore these records and don’t do anything.
>
> Kind regards
> Walter Janißen
>
> ITERGO Informationstechnologie GmbH
> Anwendungsentwicklung
> Technische Anwendungsarchitektur
> Victoriaplatz 2
> D-40198 Düsseldorf
> [login to unmask email]
>
> ITERGO Informationstechnologie GmbH
> Vorsitzender des Aufsichtsrats: Christian Diedrich
> Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
> Lothar Engelke, Ina Kirchhof, Dr. Michael Regauer
> Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf HRB 37996
>
> Von: Gary Snider [mailto:[login to unmask email]
> Gesendet: Mittwoch, 8. März 2017 19:11
> An: [login to unmask email]
> Betreff: [DB2-L] - RE: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
>
> Thanks for the reply Andy. I have read that in the guide. But, for me, that doesn't explain why the packages are showing up. They are not specified in our RLF table.
>
>
> -----End Original Message-----
>
> -----End Original Message-----
> -----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.
> If you no longer wish to receive any further solicitation from the Principal Financial Group you may unsubscribe at https://www.principal.com/do-not-contact-form any time.
> If you are a Canadian resident and no longer wish to receive commercial electronic messages you may unsubscribe at https://www.principal.com/do-not-email-request-canadian-residents any time.
>
>
> -----End Original Message-----
>
> The information transmitted is intended only for the person or entity to which it is addressed
> and may contain CONFIDENTIAL material. If you receive this material/information in error,
> please contact the sender and delete or destroy the material/information.
>
> Attachment Links: image002.jpg (1 k)
> Site Links: View post online View mailing list online Start new thread via email Unsubscribe from this mailing list Manage your subscription
>
> This email has been sent to: [login to unmask email]
> ** ** ** Attend the 2017 IDUG Tech Conference North America ** ** **
> ---> Anaheim, California, April 30 - May 04, 2017 <---
> http://www.idug.org/na
>
> Use of this email content is governed by the terms of service at:
> http://www.idug.org/p/cm/ld/fid=2
>
Attachments

  • image001.png (2.6k)

Roy Boxwell

ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
(in response to Muthuraj Kumaresan)
376 does not have a count... was it issued for one execute or 6 million...
See WLX to solve this as well

Roy Boxwell
SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-
Heinrichstrasse 83-85
40239 Düsseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]<mailto:[login to unmask email]>
http://www.seg.de

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Bettina Schubert

On 11 Mar 2017, at 02:37, mzkumaresan <[login to unmask email]<mailto:[login to unmask email]>> wrote:

Mike,

Did you try IFCID 376 instead of 366? That should reduce a lot of records.. it will cut one record for each unique combination..

Handling 1103 is a bit tricky.. IFCID 366/376 are not going to tell you the nested call details.. the best thing is that I will review the current dynamic SQL's CPU usage using dynamic SQL Cache or any vendor product and make sure the package which runs the SQL is configured with enough RLF limit..


Muthu
Sent from my iPhone

On 11 Mar 2017, at 2:39 AM, Chris Hoelscher <[login to unmask email]<mailto:[login to unmask email]>> wrote:

At our site, we are ignoring the 1104-1108 and as a result the only non-bif hit we are getting is timestamp literal errors – and we have only of those in production – as such – after those are corrected (while in applcompat V10 mode), we will change the applcompat value to V11 across the board (prod and non-prod) – we will then go to work on modifying the char/varchar issues …

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
<image002.jpg>: humana.com<http://humana.com>
123 East Main Street
Louisville, KY 40202
Humana.com<http://Humana.com>
(502) 714-8615, (502) 476-2538

From: Vaughan, Mike [mailto:[login to unmask email]
Sent: Friday, March 10, 2017 12:02 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103

My impression from looking through these records was any process doing dynamic sql from more than one package is cutting an 1103 record and I came to the same conclusion – seems like more of an information message stating that somethings going to change and really nothing that can be done about it (but we just thought you should know at least once for every transaction you run). I’m also just ignoring those and actually have the same issue but with more volume on the 1108 subtype. At this point we actually have the trace limited to exclude most ddf traffic since the volume of records (particularly the 1108’s) was so excessive but it sure would be nice to have an option to exclude specific subtypes from that trace (I’ll happily buy a beer for someone who can point out if that option exists and I just don’t know it).

Seems like a bit of a catch-22. I know the 1103/1108/etc will stop being produced if we rebind to applcompat(V11R1) but we can’t really do that without looking through the records to see what will really break by doing that rebind and I can’t really run the trace for any length of time due to the volume.

And on a side note, I’ve seen a comment a few times that the applcompat bind parameter doesn’t control dynamic sql but that seems pretty misleading when you chase it down. I suppose technically that may be correct, but since dynamic sql is controlled by the CURRENT APPLICATION COMPATIBILITY special register which is defaulted by the bind parameter on the package, it still has the same effect.

If anyone’s figured out the magic for working through this I’d love to hear it.

Thanks,
Mike Vaughan

From: Walter Janißen [mailto:[login to unmask email]
Sent: Thursday, March 09, 2017 8:56 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - AW: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103

Hi

I also check regularly these trace-records, more specific I am looking at IFCID376. I wonder, why this trace record with subtype 1103 is written at all. What shall we do with this information and how can we prevent that it is being written to get rid of these records. I decided to ignore these records and don’t do anything.

Kind regards
Walter Janißen <image001.png>

ITERGO Informationstechnologie GmbH
Anwendungsentwicklung
Technische Anwendungsarchitektur
Victoriaplatz 2
D-40198 Düsseldorf
[login to unmask email]<mailto:[login to unmask email]>

ITERGO Informationstechnologie GmbH
Vorsitzender des Aufsichtsrats: Christian Diedrich
Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
Lothar Engelke, Ina Kirchhof, Dr. Michael Regauer
Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf HRB 37996

Von: Gary Snider [mailto:[login to unmask email]
Gesendet: Mittwoch, 8. März 2017 19:11
An: [login to unmask email]<mailto:[login to unmask email]>
Betreff: [DB2-L] - RE: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103


Thanks for the reply Andy. I have read that in the guide. But, for me, that doesn't explain why the packages are showing up. They are not specified in our RLF table.

-----End Original Message-----

-----End Original Message-----
-----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]<mailto:[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.
If you no longer wish to receive any further solicitation from the Principal Financial Group you may unsubscribe at https://www.principal.com/do-not-contact-form any time.
If you are a Canadian resident and no longer wish to receive commercial electronic messages you may unsubscribe at https://www.principal.com/do-not-email-request-canadian-residents any time.


-----End Original Message-----

The information transmitted is intended only for the person or entity to which it is addressed
and may contain CONFIDENTIAL material. If you receive this material/information in error,
please contact the sender and delete or destroy the material/information.

-----End Original Message-----

-----End Original Message-----
Attachments

  • image001.png (2.6k)

Muthuraj Kumaresan

ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
(in response to Roy Boxwell)
It won't count for sure.. I think the intention would be to find the SQLs experiencing incompatibilities.. yes.. there are times where you will need to find the counts to know the criticality of the statement which is experiencing the incompatibilities..

Once we found the sql which is experiencing incompatibilities, we can find the number of calls for that SQL using cache or performance repo..




Sent from my iPhone

> On 12 Mar 2017, at 8:16 PM, Boxwell, Roy <[login to unmask email]> wrote
> 376 does not have a count... was it issued for one execute or 6 million...
> See WLX to solve this as well
>
> Roy Boxwell
> SOFTWARE ENGINEERING GmbH and SEGUS Inc.
> -Product Development-
> Heinrichstrasse 83-85
> 40239 Düsseldorf/Germany
> Tel. +49 (0)211 96149-675
> Fax +49 (0)211 96149-32
> Email: [login to unmask email]
> http://www.seg.de
>
> Software Engineering GmbH
> Amtsgericht Düsseldorf, HRB 37894
> Geschäftsführung: Gerhard Schubert, Bettina Schubert
>
> On 11 Mar 2017, at 02:37, mzkumaresan <[login to unmask email]> wrote:
>
>> Mike,
>>
>> Did you try IFCID 376 instead of 366? That should reduce a lot of records.. it will cut one record for each unique combination..
>>
>> Handling 1103 is a bit tricky.. IFCID 366/376 are not going to tell you the nested call details.. the best thing is that I will review the current dynamic SQL's CPU usage using dynamic SQL Cache or any vendor product and make sure the package which runs the SQL is configured with enough RLF limit..
>>
>>
>> Muthu
>> Sent from my iPhone
>>
>> On 11 Mar 2017, at 2:39 AM, Chris Hoelscher <[login to unmask email]> wrote:
>>
>>> At our site, we are ignoring the 1104-1108 and as a result the only non-bif hit we are getting is timestamp literal errors – and we have only of those in production – as such – after those are corrected (while in applcompat V10 mode), we will change the applcompat value to V11 across the board (prod and non-prod) – we will then go to work on modifying the char/varchar issues …
>>>
>>> Chris Hoelscher
>>> Technology Architect, Database Infrastructure Services
>>> Technology Solution Services
>>> <image002.jpg>: humana.com
>>> 123 East Main Street
>>> Louisville, KY 40202
>>> Humana.com
>>> (502) 714-8615, (502) 476-2538
>>>
>>> From: Vaughan, Mike [mailto:[login to unmask email]
>>> Sent: Friday, March 10, 2017 12:02 PM
>>> To: [login to unmask email]
>>> Subject: [DB2-L] - RE: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
>>>
>>> My impression from looking through these records was any process doing dynamic sql from more than one package is cutting an 1103 record and I came to the same conclusion – seems like more of an information message stating that somethings going to change and really nothing that can be done about it (but we just thought you should know at least once for every transaction you run). I’m also just ignoring those and actually have the same issue but with more volume on the 1108 subtype. At this point we actually have the trace limited to exclude most ddf traffic since the volume of records (particularly the 1108’s) was so excessive but it sure would be nice to have an option to exclude specific subtypes from that trace (I’ll happily buy a beer for someone who can point out if that option exists and I just don’t know it).
>>>
>>> Seems like a bit of a catch-22. I know the 1103/1108/etc will stop being produced if we rebind to applcompat(V11R1) but we can’t really do that without looking through the records to see what will really break by doing that rebind and I can’t really run the trace for any length of time due to the volume.
>>>
>>> And on a side note, I’ve seen a comment a few times that the applcompat bind parameter doesn’t control dynamic sql but that seems pretty misleading when you chase it down. I suppose technically that may be correct, but since dynamic sql is controlled by the CURRENT APPLICATION COMPATIBILITY special register which is defaulted by the bind parameter on the package, it still has the same effect.
>>>
>>> If anyone’s figured out the magic for working through this I’d love to hear it.
>>>
>>> Thanks,
>>> Mike Vaughan
>>>
>>> From: Walter Janißen [mailto:[login to unmask email]
>>> Sent: Thursday, March 09, 2017 8:56 AM
>>> To: [login to unmask email]
>>> Subject: [DB2-L] - AW: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
>>>
>>> Hi
>>>
>>> I also check regularly these trace-records, more specific I am looking at IFCID376. I wonder, why this trace record with subtype 1103 is written at all. What shall we do with this information and how can we prevent that it is being written to get rid of these records. I decided to ignore these records and don’t do anything.
>>>
>>> Kind regards
>>> Walter Janißen <image001.png>
>>>
>>> ITERGO Informationstechnologie GmbH
>>> Anwendungsentwicklung
>>> Technische Anwendungsarchitektur
>>> Victoriaplatz 2
>>> D-40198 Düsseldorf
>>> [login to unmask email]
>>>
>>> ITERGO Informationstechnologie GmbH
>>> Vorsitzender des Aufsichtsrats: Christian Diedrich
>>> Geschäftsführung: Dr. Bettina Anders (Vorsitzende),
>>> Lothar Engelke, Ina Kirchhof, Dr. Michael Regauer
>>> Sitz: Düsseldorf, Handelsregister: Amtsgericht Düsseldorf HRB 37996
>>>
>>> Von: Gary Snider [mailto:[login to unmask email]
>>> Gesendet: Mittwoch, 8. März 2017 19:11
>>> An: [login to unmask email]
>>> Betreff: [DB2-L] - RE: ZOS 2.1 DB2 V11 (CM) Monitoring IFCID 366 identifier 1103
>>>
>>> Thanks for the reply Andy. I have read that in the guide. But, for me, that doesn't explain why the packages are showing up. They are not specified in our RLF table.
>>>
>>>
>>> -----End Original Message-----
>>>
>>> -----End Original Message-----
>>> -----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.
>>> If you no longer wish to receive any further solicitation from the Principal Financial Group you may unsubscribe at https://www.principal.com/do-not-contact-form any time.
>>> If you are a Canadian resident and no longer wish to receive commercial electronic messages you may unsubscribe at https://www.principal.com/do-not-email-request-canadian-residents any time.
>>>
>>>
>>> -----End Original Message-----
>>>
>>> The information transmitted is intended only for the person or entity to which it is addressed
>>> and may contain CONFIDENTIAL material. If you receive this material/information in error,
>>> please contact the sender and delete or destroy the material/information.
>>>
>>> -----End Original Message-----
>>
>> -----End Original Message-----
>
> Attachment Links: image001.png (3 k)
> Site Links: View post online View mailing list online Start new thread via email Unsubscribe from this mailing list Manage your subscription
>
> This email has been sent to: [login to unmask email]
> ** ** ** Attend the 2017 IDUG Tech Conference North America ** ** **
> ---> Anaheim, California, April 30 - May 04, 2017 <---
> http://www.idug.org/na
>
> Use of this email content is governed by the terms of service at:
> http://www.idug.org/p/cm/ld/fid=2
>