[Db2 for z/OS V12] DSNU3350I

Ruediger Kurtz

[Db2 for z/OS V12] DSNU3350I
Hi folks,

I do have a problem understanding the DSNU3350Imessage.

The particular part of the message message I’m referring to runs as follows:

DSNU3350I SORT TASK SW07: 8835326 RECORDS SORTED, ESTIMATED 3885555

If I look at the quick reference my understanding is that almost 9 million rows were sorted whereas the load expected to sort about half the amount.
This expectation is apparently based on RTS.

But … RTS for this particular table shows 8835K rows, so someone is not giving me the right picture.

The reason for asking is that one load job abended because of a miscalculation of the necessary sortworks, the trouble is I don’t have the output handy anymore, but I still remember it was due to some sort-space problem. The abend may or may not have been related to that miscalculation, but while investigating the matter I stumbled about the discrepancy of figures in that message.

What am I reading wrong? Is it my misinterpreting the message? Any help is appreciated.

Have a great weekend

Best regards

Rüdiger



Rüdiger Kurtz
Abteilung Informatik – Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon: 09561 96-44148
Telefax: 09561 96-44104
E-Mail: [login to unmask email]
Internet: www.huk.de
________________________________
HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas (stv.).
________________________________
Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this information is strictly forbidden.
________________________________

Lizette Koehler

[Db2 for z/OS V12] DSNU3350I
(in response to Ruediger Kurtz)
So with DFSort, if you are not telling SORT how many records are going to be passed, then it will “guess” and possibly not have sufficient process for sorting.



I have worked on some application jobs that got RC16 in SORT due to insufficient SORT capacity. ICE046A.



I have added DFSPARM to the JCL for these jobs with larger than normal sort work and SYSDA allocations



If you can get the SORT Messages (ICE) from the job it should help you see the issue.



You can then setup special parms for SORT that tells it a large FILESZ= If that is the issue



So some steps



1. Talk to your z/OS Sysprog about what is the default settings for DFSORT
2. Talk to the z/OS Sysprog about setting up special SORT parms for this type of job, if needed
3. Make sure you have the ICE messages at run time to see what is going on.
4. Look at the Joblog of the failing job for messages indicating x37 abends on SORT Work DD Statements



Typically a DB2 Utility should be passing a correct FILESZ to DFSORT. The messages from DFSORT will identify what was requested (FILESZ and SYSDA) to see if it was a problem with DB2 invoking sort or something else



Note: There are a couple of other parms like FILESZ that could be used. So you may need to look up the other variations.



DB2 messages with SORT issues are general. You need the JOBLOG and ICE messages to see what really happened.





Questions:



1. What was running when the abend occurred? Utility name or how it was invoked (maybe through a Program?)
2. What are the ICE messages produced? If you are not routing your ICE Messages to archive with the job, that would be good to do
3. Are all PTFs on DFSORT and DB2 for these types of issues?



Lizette











From: Kurtz, Rüdiger [mailto:[login to unmask email]
Sent: Friday, August 11, 2017 3:38 AM
To: [login to unmask email]
Subject: [DB2-L] - [Db2 for z/OS V12] DSNU3350I



Hi folks,



I do have a problem understanding the DSNU3350Imessage.



The particular part of the message message I’m referring to runs as follows:

DSNU3350I SORT TASK SW07: 8835326 RECORDS SORTED, ESTIMATED 3885555



If I look at the quick reference my understanding is that almost 9 million rows were sorted whereas the load expected to sort about half the amount.
This expectation is apparently based on RTS.

But … RTS for this particular table shows 8835K rows, so someone is not giving me the right picture.

The reason for asking is that one load job abended because of a miscalculation of the necessary sortworks, the trouble is I don’t have the output handy anymore, but I still remember it was due to some sort-space problem. The abend may or may not have been related to that miscalculation, but while investigating the matter I stumbled about the discrepancy of figures in that message.

What am I reading wrong? Is it my misinterpreting the message? Any help is appreciated.

Have a great weekend

Best regards

Rüdiger



Rüdiger Kurtz
Abteilung Informatik – Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg


Telefon:

09561 96-44148


Telefax:

09561 96-44104


E-Mail:

[login to unmask email] <mailto:[login to unmask email]>


Internet:

www.huk.de http://www.huk.de



Ronny Schneider

AW: [Db2 for z/OS V12] DSNU3350I
(in response to Lizette Koehler)
Hi,

the problem of this question is not the abend in SORT but the message “DSNU3350I SORT TASK SW07: 8835326 RECORDS SORTED, ESTIMATED 3885555”

How the “estimated” value is calculated or which information is used for that value?

Kind regards,
Ronny


Ronny Schneider
Abteilung Informatik – Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon: 09561 96-44140
Telefax: 09561 96-44104
E-Mail: [login to unmask email]
Internet: www.huk.de
________________________________
HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas (stv.).
________________________________
Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this information is strictly forbidden.
________________________________
Von: Lizette Koehler [mailto:[login to unmask email]
Gesendet: Freitag, 11. August 2017 15:50
An: [login to unmask email]
Betreff: [DB2-L] - RE: [Db2 for z/OS V12] DSNU3350I

So with DFSort, if you are not telling SORT how many records are going to be passed, then it will “guess” and possibly not have sufficient process for sorting.

I have worked on some application jobs that got RC16 in SORT due to insufficient SORT capacity. ICE046A.

I have added DFSPARM to the JCL for these jobs with larger than normal sort work and SYSDA allocations

If you can get the SORT Messages (ICE) from the job it should help you see the issue.

You can then setup special parms for SORT that tells it a large FILESZ= If that is the issue

So some steps

1) Talk to your z/OS Sysprog about what is the default settings for DFSORT
2) Talk to the z/OS Sysprog about setting up special SORT parms for this type of job, if needed
3) Make sure you have the ICE messages at run time to see what is going on.
4) Look at the Joblog of the failing job for messages indicating x37 abends on SORT Work DD Statements

Typically a DB2 Utility should be passing a correct FILESZ to DFSORT. The messages from DFSORT will identify what was requested (FILESZ and SYSDA) to see if it was a problem with DB2 invoking sort or something else

Note: There are a couple of other parms like FILESZ that could be used. So you may need to look up the other variations.

DB2 messages with SORT issues are general. You need the JOBLOG and ICE messages to see what really happened.


Questions:

1) What was running when the abend occurred? Utility name or how it was invoked (maybe through a Program?)
2) What are the ICE messages produced? If you are not routing your ICE Messages to archive with the job, that would be good to do
3) Are all PTFs on DFSORT and DB2 for these types of issues?


Lizette





From: Kurtz, Rüdiger [mailto:[login to unmask email]
Sent: Friday, August 11, 2017 3:38 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - [Db2 for z/OS V12] DSNU3350I

Hi folks,

I do have a problem understanding the DSNU3350Imessage.

The particular part of the message message I’m referring to runs as follows:

DSNU3350I SORT TASK SW07: 8835326 RECORDS SORTED, ESTIMATED 3885555

If I look at the quick reference my understanding is that almost 9 million rows were sorted whereas the load expected to sort about half the amount.
This expectation is apparently based on RTS.

But … RTS for this particular table shows 8835K rows, so someone is not giving me the right picture.

The reason for asking is that one load job abended because of a miscalculation of the necessary sortworks, the trouble is I don’t have the output handy anymore, but I still remember it was due to some sort-space problem. The abend may or may not have been related to that miscalculation, but while investigating the matter I stumbled about the discrepancy of figures in that message.

What am I reading wrong? Is it my misinterpreting the message? Any help is appreciated.

Have a great weekend

Best regards

Rüdiger

Rüdiger Kurtz
Abteilung Informatik – Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon:

09561 96-44148

Telefax:

09561 96-44104

E-Mail:

[login to unmask email]<mailto:[login to unmask email]>

Internet:

www.huk.de http://www.huk.de



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

J&#248;rn Thyssen

RE: [Db2 for z/OS V12] DSNU3350I
(in response to Ruediger Kurtz)

Hi Rüdiger,

Do you have RTS history? It would be interesting to see the RTS from before the REORG...

Is the table regularly REORG'ed?

Best regards,

Jørn Thyssen

Rocket Software
77 Fourth Avenue • Waltham, MA • 02451 • USA
E: [login to unmask email] • W: www.rocketsoftware.com 

Views are personal. 

Ruediger Kurtz

AW: [Db2 for z/OS V12] DSNU3350I
(in response to Jørn Thyssen)
Jorn and all others,

sorry for replying that late, but I’ve been away from work for some weeks.

The table in question remains at a pretty stable level of prox 8.8 million rows.
It gets loaded one a month and is not reorged (last Reorg is from 2015).

Actually, the original question was not about Reorg but about Load.

When that particular load abended, the message issued clearly stated that about 9 million rows were sorted, whereas less than 4 million were expected, which – so I assume – led to the abnormal end of the load utility.

What I still do not understand, hence my original mail, where do the different numbers come from. One’s from RTS, but the other remains a mystery to me.

The statement in question is as follows:
DSNU3350I SORT TASK SW07: 8835326 RECORDS SORTED, ESTIMATED 3885555

Best regards

Ruediger


Rüdiger Kurtz
Abteilung Informatik – Betrieb

HUK-COBURG
Bahnhofsplatz
96444 Coburg
Telefon: 09561 96-44148
Telefax: 09561 96-44104
E-Mail: [login to unmask email]
Internet: www.huk.de
________________________________
HUK-COBURG Haftpflicht-Unterstützungs-Kasse kraftfahrender Beamter Deutschlands a. G. in Coburg
Reg.-Gericht Coburg HRB 100; St.-Nr. 9212/101/00021
Sitz der Gesellschaft: Bahnhofsplatz, 96444 Coburg
Vorsitzender des Aufsichtsrats: Prof. Dr. Heinrich R. Schradin.
Vorstand: Klaus-Jürgen Heitmann (Sprecher), Stefan Gronbach, Dr. Hans Olav Herøy, Dr. Jörg Rheinländer (stv.), Sarah Rössler, Daniel Thomas (stv.).
________________________________
Diese Nachricht enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese Nachricht irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Nachricht.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Nachricht ist nicht gestattet.

This information may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this information in error) please notify the
sender immediately and destroy this information.
Any unauthorized copying, disclosure or distribution of the material in this information is strictly forbidden.
-----End Original Message-----

Christian Michel

RE: AW: [Db2 for z/OS V12] DSNU3350I
(in response to Ruediger Kurtz)

Hi Rüdiger,

if you're running LOAD then we also look at the input data set to estimate how many records will be loaded. This can be a sketchy estimate if the input has variable length records and the LRECL is much larger than the average record length of the input data. We have NUMRECS (or SORTKEYS) to overcome estimation trouble in such cases.

Regards,
Christian Michel