DB2 z/OS SHRLEVEL CHANGE Log phase

Steven Lamb

DB2 z/OS SHRLEVEL CHANGE Log phase

What are the (main) factors that can affect the duration of the Log phase of a SHRLELVEL CHANGE Reorg?

For partitioned tablespaces we typically run Reorgs against the individual partitions. The Log phase timings for different partitions of the same tablespace in the same Reorg job can vary from 1 second up to 67 seconds, as indicated by message DSNU385I. This is in a four member DSG, so there are cross-member log reads going on.

Presumably the amount of log data as a whole being produced will have an impact. However, the Reorg for part 35 ran over a period when approx. 30m log records were created and had a Log phase time of 32 seconds.

The Reorg for part 36 had a Log phase of 67 seconds and also ran over a period with approx. 30m log records. Both Reorgs had two iterations.

There were 2 Inserts and 1 update for part 36 between the start of the Reorg and the end of the Log phase for part 36, so not a huge amount of activity. The SMF Stats records covering the Log phase say that all 41 Log reads across the DSG were satisfied either from the output buffers (13) or from the active logs (28).

 

Does anybody have any thoughts?

 

Regards,

Steve

Walter Janißen

AW: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Steven Lamb)
Hi Steve

So it seems as if applying the log records affects the log phase. When I understand you correctly for part 35 there where no updates during the reorg where as 2 Inserts and 1 update for part 36.

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: Steven Lamb [mailto:[login to unmask email]
Gesendet: Dienstag, 20. Februar 2018 14:23
An: [login to unmask email]
Betreff: [DB2-L] - DB2 z/OS SHRLEVEL CHANGE Log phase


What are the (main) factors that can affect the duration of the Log phase of a SHRLELVEL CHANGE Reorg?

For partitioned tablespaces we typically run Reorgs against the individual partitions. The Log phase timings for different partitions of the same tablespace in the same Reorg job can vary from 1 second up to 67 seconds, as indicated by message DSNU385I. This is in a four member DSG, so there are cross-member log reads going on.

Presumably the amount of log data as a whole being produced will have an impact. However, the Reorg for part 35 ran over a period when approx. 30m log records were created and had a Log phase time of 32 seconds.

The Reorg for part 36 had a Log phase of 67 seconds and also ran over a period with approx. 30m log records. Both Reorgs had two iterations.

There were 2 Inserts and 1 update for part 36 between the start of the Reorg and the end of the Log phase for part 36, so not a huge amount of activity. The SMF Stats records covering the Log phase say that all 41 Log reads across the DSG were satisfied either from the output buffers (13) or from the active logs (28).



Does anybody have any thoughts?



Regards,

Steve

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

  • image001.png (2.6k)

Steven Lamb

RE: AW: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Walter Janißen)

Hi Walter,

 

The number of "changes" to the partition don't seem to have an impact. So, in yesterday morning's Reorg job, most of the partitions had zero records to apply to the shadow instance, but the Log phase times range from 1 second to over 30, even during "quiet" periods in terms of the amount of log data being produced. As I said, I would have thought the amount of log data being produced would be the main factor, but there doesn't seem to be a direct correlation.

Part 35 had zero log records to apply (message DSNU1139I) and the Log phase took 32 seconds in a busy period.

Part 36 had 2 log records to apply (even though I believe there were 2 Inserts and 1 Update) and had a Log phase of 67 seconds in a busy period

Part 40 had 6 log records to apply and had a Log phase of 46 seconds, again in a busy period.

Some of the Reorg output:

DSNU1139I   050 05:33:02.09 DSNURLGD - FINAL LOG ITERATION STATISTICS. NUMBER OF LOG RECORDS = 0                
DSNU386I    050 05:33:02.09 DSNURLGD - LOG PHASE STATISTICS. NUMBER OF ITERATIONS = 2, NUMBER OF LOG RECORDS = 17
DSNU385I    050 05:33:02.09 DSNURLGD - LOG PHASE COMPLETE, ELAPSED TIME = 00:00:01        

  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  78 Line(s) not Di

DSNU1139I   050 05:48:25.99 DSNURLGD - FINAL LOG ITERATION STATISTICS. NUMBER OF LOG RECORDS = 0
DSNU386I    050 05:48:25.99 DSNURLGD - LOG PHASE STATISTICS. NUMBER OF ITERATIONS = 2, NUMBER OF LOG RECORDS = 30 
DSNU385I    050 05:48:25.99 DSNURLGD - LOG PHASE COMPLETE, ELAPSED TIME = 00:00:32               
  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  78 Line(s) not Di
DSNU1139I   050 06:05:39.64 DSNURLGD - FINAL LOG ITERATION STATISTICS. NUMBER OF LOG RECORDS = 2
DSNU386I    050 06:05:39.64 DSNURLGD - LOG PHASE STATISTICS. NUMBER OF ITERATIONS = 2, NUMBER OF LOG RECORDS = 27 
DSNU385I    050 06:05:39.64 DSNURLGD - LOG PHASE COMPLETE, ELAPSED TIME = 00:01:07    
  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  78 Line(s) not Di
DSNU1139I   050 06:22:36.35 DSNURLGD - FINAL LOG ITERATION STATISTICS. NUMBER OF LOG RECORDS = 0
DSNU386I    050 06:22:36.35 DSNURLGD - LOG PHASE STATISTICS. NUMBER OF ITERATIONS = 2, NUMBER OF LOG RECORDS = 19 
DSNU385I    050 06:22:36.35 DSNURLGD - LOG PHASE COMPLETE, ELAPSED TIME = 00:00:38          
  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  78 Line(s) not Di
DSNU1139I   050 06:39:34.20 DSNURLGD - FINAL LOG ITERATION STATISTICS. NUMBER OF LOG RECORDS = 6
DSNU386I    050 06:39:34.20 DSNURLGD - LOG PHASE STATISTICS. NUMBER OF ITERATIONS = 2, NUMBER OF LOG RECORDS = 98
DSNU385I    050 06:39:34.20 DSNURLGD - LOG PHASE COMPLETE, ELAPSED TIME = 00:00:47      

 

Regards,

Steve

Bruce Williamson

RE: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Steven Lamb)

Howzit Steve?

We have very tight constraints at our shop with regard to REORG housekeeping and zero tolerance for impact on customer transaction processing so I've spent far to much time in this area :)

The first thing I'd advise is to add DIAGNOSE TYPE(100,101,102) to your REORG process to get detailed timings of what's happening under the covers.

These delays can be attributed to many things, REORG parms, DASD vendor, system load, transaction volumes, etc. to name just a few.

With our previous DASD vendor we were seeing the type of delays you are describing and after various code enhancements from IBM including dedicated diagnose parms in order to meet our operating constraints the majority of our delays finally came down to DASD microcode which was "arbitrarily" causing delays in VTOC VVDS updates. We are now on IBM DASD and the improvement has been mind-boggling, that's not to say we're out of the woods as we continue to work with IBM to squeeze every ounce (or should that be gram) of performance out of our DASD sub-system. BTW IBM Haven't paid me to say that ;)

Typically in our shop these delays manifest themselves not so much in the log processing but in the final iteration of the log processing so the area I would advise you to focus on at this stage is the "LOG FORCE WRITE" log subprocess.

It might be useful to share your REORG parms and the output from DIAGNOSE TYPE(100,101,102) if you decide to adopt? Does this only happen in your production systems?

Cheers
Bruce

 

P.S. Want to make a difference but don't know how? Join the RFE Community (Requests For Enhancement), no time like the present!!!

P.P.S. While you're at it why not join the "All DB2 for z/OS" group and vote on community proposals

Steven Lamb

RE: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Bruce Williamson)

Hi Bruce,

 

I would have said that things are OK, but this Reorg issue isn't right. It's not something I look at on a regular basis, but I've got a feeling it's only started getting bad recently, so what's the cause? As you know, we're in the same situation as you - we don't want any impact on customers. Looking at yesterday's stats for the Reorgs we had DRAIN LOCK times of up to 14.9 seconds for one partition, with Rollbacks :(. Not good.

 

We use IBM disks - 8870s, so reasonably modern. Our Reorg jobs are generated dynamically by the IBM Automation Tool, so making changes like adding DIAGNOSE TYPE are a PITA, but I guess I'll have to do it. I'll also start looking back through the change system to see if there have been any microcode changes or similar that might be playing a part in this.

The Reorg parms used were

REORG TABLESPACE LIST REO11002 LISTPARTS 1      
SCOPE ALL
LOG NO
SORTDATA YES
NOSYSREC
COPYDDN (R1LP0001,R1LB0001)
SHRLEVEL CHANGE
TIMEOUT TERM
AUX NO
DEADLINE CURRENT DATE + 6 HOURS + 55 MINUTES
DRAIN_WAIT 1
RETRY 2 RETRY_DELAY 30
MAPPINGTABLE "BP0P353D"."REORG_CMP00301"
MAXRO 5
DRAIN ALL
LONGLOG TERM
DELAY 600
LOGRANGES YES
DRAIN_ALLPARTS NO
FASTSWITCH YES
SORTNPSI NO
UNLOAD CONTINUE
KEEPDICTIONARY
STATISTICS
TABLE(ALL)
SAMPLE 20
INDEX(ALL)
FREQVAL NUMCOLS 1 COUNT 10
FREQVAL NUMCOLS 2 COUNT 10
FREQVAL NUMCOLS 3 COUNT 10
FREQVAL NUMCOLS 4 COUNT 10
REPORT NO
UPDATE ALL
HISTORY ALL
FORCEROLLUP YES
SORTDEVT 3390 PREFORMAT

 

Regards,

Steve

Michael Hannan

RE: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Steven Lamb)

Steven,

I am not running Reorgs so don't have the experience of others, however I am well aware of Drains on the objects being a possible cause of significant delays, if other processes have Claims on the objects. Data Sharing probably complicates that further. So it is not just the level of actual Inserts/Updates/Deletes that are occurring on the Reorged table. Drains have very long wait at times and no deadlock detection.

Issues of inability to break into very long running threads.

Michael Hannan,
DB2 Application Performance Specialist
CPT Global Ltd

Steven Lamb

RE: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Michael Hannan)

Hi Michael,

 

That's another avenue I'm exploring, plus one of the problems - we can identify transactions that "change" a pageset but struggle with identifying read-only transactions as their access isn't logged. We don't want to start turning on lots of traces because of the performance overhead.  

However, the messages displayed indicate that the Reorg obtains the drain quickly, but it's the final log iteration that is taking a long time

E.g.

DSNU1138I -BP0C 051 06:25:18.49 DSNURLOG - DRAIN ALL WITH START TIME 2018-02-20-06.25.18.387101 HAS COMPLETED

DSNU1139I   051 06:25:36.16 DSNURLGD - FINAL LOG ITERATION STATISTICS. NUMBER OF LOG RECORDS = 2                
DSNU386I    051 06:25:36.16 DSNURLGD - LOG PHASE STATISTICS. NUMBER OF ITERATIONS = 2, NUMBER OF LOG RECORDS = 25
DSNU385I    051 06:25:36.16 DSNURLGD - LOG PHASE COMPLETE, ELAPSED TIME = 00:01:21 

So the drain was obtained in approx. 0.1 seconds as indicated by message DSNU1138I, but the final iteration took 17.67 seconds even though MAXRO is 5 seconds.

 

Regards,
Steve

Edited By:
Steven Lamb[Organization Members] @ Feb 21, 2018 - 10:22 AM (Europe/London)

Roy Boxwell

DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Steven Lamb)
I just change the PARM string to look like:

//ROU001 EXEC PGM=DSNUTILB,REGION=32M,
// PARM=(ssid,utilityname,,STATSLVL(SUBPROCESS))

Normally easier than adding control cards to the flow!

Roy Boxwell

SOFTWARE ENGINEERING GMBH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/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 http://www.seg.de

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

From: Steven Lamb [mailto:[login to unmask email]
Sent: Wednesday, February 21, 2018 9:37 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: DB2 z/OS SHRLEVEL CHANGE Log phase


Hi Bruce,



I would have said that things are OK, but this Reorg issue isn't right. It's not something I look at on a regular basis, but I've got a feeling it's only started getting bad recently, so what's the cause? As you know, we're in the same situation as you - we don't want any impact on customers. Looking at yesterday's stats for the Reorgs we had DRAIN LOCK times of up to 14.9 seconds for one partition, with Rollbacks :(. Not good.



We use IBM disks - 8870s, so reasonably modern. Our Reorg jobs are generated dynamically by the IBM Automation Tool, so making changes like adding DIAGNOSE TYPE are a PITA, but I guess I'll have to do it. I'll also start looking back through the change system to see if there have been any microcode changes or similar that might be playing a part in this.

The Reorg parms used were

REORG TABLESPACE LIST REO11002 LISTPARTS 1
SCOPE ALL
LOG NO
SORTDATA YES
NOSYSREC
COPYDDN (R1LP0001,R1LB0001)
SHRLEVEL CHANGE
TIMEOUT TERM
AUX NO
DEADLINE CURRENT DATE + 6 HOURS + 55 MINUTES
DRAIN_WAIT 1
RETRY 2 RETRY_DELAY 30
MAPPINGTABLE "BP0P353D"."REORG_CMP00301"
MAXRO 5
DRAIN ALL
LONGLOG TERM
DELAY 600
LOGRANGES YES
DRAIN_ALLPARTS NO
FASTSWITCH YES
SORTNPSI NO
UNLOAD CONTINUE
KEEPDICTIONARY
STATISTICS
TABLE(ALL)
SAMPLE 20
INDEX(ALL)
FREQVAL NUMCOLS 1 COUNT 10
FREQVAL NUMCOLS 2 COUNT 10
FREQVAL NUMCOLS 3 COUNT 10
FREQVAL NUMCOLS 4 COUNT 10
REPORT NO
UPDATE ALL
HISTORY ALL
FORCEROLLUP YES
SORTDEVT 3390 PREFORMAT



Regards,

Steve

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

Steven Lamb

RE: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Roy Boxwell)

Hi Roy,

 

Will that produce the same output as the DIAGNOSE? I can't find it documented anywhere - and I panicked slightly when I got an S04E abend; I'd missed out the extra comma :)

 

Regards,
Steve

Roy Boxwell

DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Steven Lamb)
That I couldnt tell you... It is a hidden parameter but I have used it for years with no problems. Try a REORG with DIAGNOSE and then try one with PARM and see how it looks...

Roy Boxwell

SOFTWARE ENGINEERING GMBH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/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 http://www.seg.de

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

From: Steven Lamb [mailto:[login to unmask email]
Sent: Wednesday, February 21, 2018 1:56 PM
To: [login to unmask email]
Subject: [DB2-L] - RE: DB2 z/OS SHRLEVEL CHANGE Log phase


Hi Roy,



Will that produce the same output as the DIAGNOSE? I can't find it documented anywhere - and I panicked slightly when I got an S04E abend; I'd missed out the extra comma :)



Regards,
Steve

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

Steven Lamb

RE: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Roy Boxwell)

It looks pretty similar, with a few minor layout differences.

With DIAGNOSE you can put the control cards where you want in the input stream e.g. after any Template and Listdef statements, whereas STATSLVL(SUBPROCESS) will obviously operate on all utility statements in the input stream.

Now I've just got to remember which Automation Tool skeletons to amend to include the statements.

The problem is in production of course, so it'll be a while before I can get the info from the real Reorg jobs, due to having to raise a change request and getting it authorised.

 

Regards,

Steve

Edited By:
Steven Lamb[Organization Members] @ Feb 21, 2018 - 04:03 PM (Europe/London)

Bruce Williamson

RE: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Roy Boxwell)

Yes Steve, STATSLEVEL will produce the same output as DIAGNOSE.

BUT and it's a big BUT, if you are using DB2 Auto Tool you can't use either IF you use the "Generation Options" "Capture run times for Load Balancing = Y" because utility output is dumped to a temporary dataset and interpreted by DB2 Auto Tool before being dumped to sysout. Unfortunately it's unable to interpret DIAGNOSE/STATSLEVEL output and the job will abend :(

I have raised this with the DB2 Tools folks but their view is that they can't code for all the possible DIAGNOSE combinations customers could potentially be running which is probably fair enough but for the fact that STATSLEVEL is supported as a job PARM so IMHO opinion it should be catered for. I will raise it at the next CAC meeting and see if we can get some traction.

Cheers
Bruce

 

P.S. Want to make a difference but don't know how? Join the RFE Community (Requests For Enhancement), no time like the present!!!

P.P.S. While you're at it why not join the "All DB2 for z/OS" group and 

Bruce Williamson

RE: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Steven Lamb)

A quick question, is the problem that you have customer transactions doing rollbacks or that the REORGs are not completing successfully?

Cheers
Bruce



In Reply to Steven Lamb:

Hi Bruce,

 

I would have said that things are OK, but this Reorg issue isn't right. It's not something I look at on a regular basis, but I've got a feeling it's only started getting bad recently, so what's the cause? As you know, we're in the same situation as you - we don't want any impact on customers. Looking at yesterday's stats for the Reorgs we had DRAIN LOCK times of up to 14.9 seconds for one partition, with Rollbacks :(. Not good.

 

We use IBM disks - 8870s, so reasonably modern. Our Reorg jobs are generated dynamically by the IBM Automation Tool, so making changes like adding DIAGNOSE TYPE are a PITA, but I guess I'll have to do it. I'll also start looking back through the change system to see if there have been any microcode changes or similar that might be playing a part in this.

The Reorg parms used were

REORG TABLESPACE LIST REO11002 LISTPARTS 1      
SCOPE ALL
LOG NO
SORTDATA YES
NOSYSREC
COPYDDN (R1LP0001,R1LB0001)
SHRLEVEL CHANGE
TIMEOUT TERM
AUX NO
DEADLINE CURRENT DATE + 6 HOURS + 55 MINUTES
DRAIN_WAIT 1
RETRY 2 RETRY_DELAY 30
MAPPINGTABLE "BP0P353D"."REORG_CMP00301"
MAXRO 5
DRAIN ALL
LONGLOG TERM
DELAY 600
LOGRANGES YES
DRAIN_ALLPARTS NO
FASTSWITCH YES
SORTNPSI NO
UNLOAD CONTINUE
KEEPDICTIONARY
STATISTICS
TABLE(ALL)
SAMPLE 20
INDEX(ALL)
FREQVAL NUMCOLS 1 COUNT 10
FREQVAL NUMCOLS 2 COUNT 10
FREQVAL NUMCOLS 3 COUNT 10
FREQVAL NUMCOLS 4 COUNT 10
REPORT NO
UPDATE ALL
HISTORY ALL
FORCEROLLUP YES
SORTDEVT 3390 PREFORMAT

 

Regards,

Steve



P.S. Want to make a difference but don't know how? Join the RFE Community (Requests For Enhancement), no time like the present!!!

P.P.S. While you're at it why not join the "All DB2 for z/OS" group and 

Horacio Villa

DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Roy Boxwell)

Hi,

I tried STATSLVL(SUBPROCESS)) to see what it gives and got:

DSNU024I DSNUTILB - PARM FIELD ERROR - 'DS2B,FDBK,,STATSLVL(SUBPROCESS))'
DSNU016I DSNUTILB - UTILITY BATCH MEMORY EXECUTION ABENDED,
REASON=X'00E40018'

Also
ABPU5903W DSNUTILF EXIT IS INOPERATIVE FOR SSID: DS2B, RSN: 0002
IEF450I D1EFXXAA RUNSTTS - ABEND=S04E U0000 REASON=00E40018

What's the relation of this PARM with DB2 Utilities Enhancement Tool?
Without the PARM the job runs successfully.

Horacio
























From: "Boxwell, Roy" <[login to unmask email]>
To: "[login to unmask email]" <[login to unmask email]>
Date: 02/21/2018 08:21 AM
Subject: [DB2-L] - RE: DB2 z/OS SHRLEVEL CHANGE Log phase



I just change the PARM string to look like:

//ROU001 EXEC PGM=DSNUTILB,REGION=32M,
// PARM=(ssid,utilityname,,STATSLVL(SUBPROCESS))

Normally easier than adding control cards to the flow!

Roy Boxwell

SOFTWARE ENGINEERING GMBH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/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









Attachments

  • ecblank.gif (<1k)
  • graycol.gif (<1k)

Roy Boxwell

DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Horacio Villa)
Looks like your PARM does not start with an ( character you can use quotes but then you must end with a quote and not a second ) so it would look like

// PARM='ssid,utilityname,,STATSLVL(SUBPROCESS)'


Roy Boxwell

SOFTWARE ENGINEERING GMBH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/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 http://www.seg.de

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

From: Horacio Villa [mailto:[login to unmask email]
Sent: Thursday, February 22, 2018 1:51 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: DB2 z/OS SHRLEVEL CHANGE Log phase


Hi,

I tried STATSLVL(SUBPROCESS)) to see what it gives and got:

DSNU024I DSNUTILB - PARM FIELD ERROR - 'DS2B,FDBK,,STATSLVL(SUBPROCESS))'
DSNU016I DSNUTILB - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40018'

Also
ABPU5903W DSNUTILF EXIT IS INOPERATIVE FOR SSID: DS2B, RSN: 0002
IEF450I D1EFXXAA RUNSTTS - ABEND=S04E U0000 REASON=00E40018

What's the relation of this PARM with DB2 Utilities Enhancement Tool?
Without the PARM the job runs successfully.

Horacio


















[Inactive hide details for "Boxwell, Roy" ---02/21/2018 08:21:06 AM---I just change the PARM string to look like: //ROU001 EXE]"Boxwell, Roy" ---02/21/2018 08:21:06 AM---I just change the PARM string to look like: //ROU001 EXEC PGM=DSNUTILB,REGION=32M,

From: "Boxwell, Roy" <[login to unmask email]<mailto:[login to unmask email]>>
To: "[login to unmask email]<mailto:[login to unmask email]>" <[login to unmask email]<mailto:[login to unmask email]>>
Date: 02/21/2018 08:21 AM
Subject: [DB2-L] - RE: DB2 z/OS SHRLEVEL CHANGE Log phase

________________________________



I just change the PARM string to look like:

//ROU001 EXEC PGM=DSNUTILB,REGION=32M,
// PARM=(ssid,utilityname,,STATSLVL(SUBPROCESS))

Normally easier than adding control cards to the flow!

Roy Boxwell

SOFTWARE ENGINEERING GMBH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/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 http://www.seg.de

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



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

Steven Lamb

RE: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Horacio Villa)

Thanks Bruce - I'll have a play to see what the best way of doing it is. We do capture the run times from the Auto Tool, so I'll probably have to turn it off temporarily for the jobs in question.

The Reorgs all complete successfully, but the application transactions may Rollback depending on the calling system's "tolerance" for delays. So if there's a long final log iteration holding things up, this may exceed the calling system's timeout values and so the transaction is rolled back.

 

Regards,
Steve

Edited By:
Steven Lamb[Organization Members] @ Feb 22, 2018 - 08:27 AM (Europe/London)

Roy Boxwell

DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Steven Lamb)
Nah, the two commas are there. I think it was the trailing ) that caught him out!

Roy Boxwell

SOFTWARE ENGINEERING GMBH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/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 http://www.seg.de

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

From: Steven Lamb [mailto:[login to unmask email]
Sent: Thursday, February 22, 2018 9:26 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: DB2 z/OS SHRLEVEL CHANGE Log phase


Thanks Bruce - I'll have a play to see what the best way of doing it is. We do capture the run times from the Auto Tool, so I'll probably have to turn it off temporarily for the jobs in question.

The Reorgs all complete successfully, but the application transactions may Rollback depending on the calling system's "tolerance" for delays. So if there's a long final log iteration holding things up, this may exceed the calling system's timeout values and so the transaction is rolled back.



Horacio - looks like you did what I did initially and missed out a comma :). Roy deliberately put two commas in his example, as both are required.



Regards,
Steve

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

Steven Lamb

RE: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Roy Boxwell)

Yep, I tried removing that comment about the extra comma after I checked it properly. You're just too quick for me Roy! :)

 

Regards,
Steve

J&#248;rn Thyssen

RE: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Steven Lamb)

Hi Steve,

Feel free to contact me off-list if you need help getting DIAGNOSE added to your REORG jobs with IBM Db2 Automation Tool.

Best regards,

Jørn Thyssen

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

2018 IBM Champion.

Views are personal. 

Horacio Villa

DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Roy Boxwell)
You're right Roy.
But look, I cut/paste what I received in your original mail, which is
copied here.
Thanks!

Horacio Villa

DB2 z/OS DBA Support, Database
Administration

IBM Certified DataBase Administrator – DB2
9 DBA for z/OS

IBM Corporation

( 5070-3443 / tl 840-3443 cell 15
6178-8908

* [login to unmask email]











From: "Boxwell, Roy" <[login to unmask email]>
To: "[login to unmask email]" <[login to unmask email]>
Date: 02/22/2018 05:14 AM
Subject: [DB2-L] - RE: DB2 z/OS SHRLEVEL CHANGE Log phase



Looks like your PARM does not start with an ( character you can use quotes
but then you must end with a quote and not a second ) so it would look like

// PARM=’ssid,utilityname,,STATSLVL(SUBPROCESS)’


Roy Boxwell

SOFTWARE ENGINEERING GMBH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/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

From: Horacio Villa [mailto:[login to unmask email]
Sent: Thursday, February 22, 2018 1:51 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: DB2 z/OS SHRLEVEL CHANGE Log phase



Hi,

I tried STATSLVL(SUBPROCESS)) to see what it gives and got:

DSNU024I DSNUTILB - PARM FIELD ERROR - 'DS2B,FDBK,,STATSLVL(SUBPROCESS))'
DSNU016I DSNUTILB - UTILITY BATCH MEMORY EXECUTION ABENDED,
REASON=X'00E40018'

Also
ABPU5903W DSNUTILF EXIT IS INOPERATIVE FOR SSID: DS2B, RSN: 0002
IEF450I D1EFXXAA RUNSTTS - ABEND=S04E U0000 REASON=00E40018

What's the relation of this PARM with DB2 Utilities Enhancement Tool?
Without the PARM the job runs successfully.

Horacio

























"Boxwell, Roy" ---02/21/2018 08:21:06 AM---I just change the PARM string to
look like: //ROU001 EXEC PGM=DSNUTILB,REGION=32M,

From: "Boxwell, Roy" <[login to unmask email]>
To: "[login to unmask email]" <[login to unmask email]>
Date: 02/21/2018 08:21 AM
Subject: [DB2-L] - RE: DB2 z/OS SHRLEVEL CHANGE Log phase




I just change the PARM string to look like:

//ROU001 EXEC PGM=DSNUTILB,REGION=32M,
// PARM=(ssid,utilityname,,STATSLVL(SUBPROCESS))

Normally easier than adding control cards to the flow!

Roy Boxwell

SOFTWARE ENGINEERING GMBH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/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



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


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]


** ** ** IDUG DB2 Data and Analytics Technical Summit in Bengaluru, India
2018 ** ** **
---> Bengaluru, India, March 27, 2018 <---
http://ibm.biz/IDUGBengaluru2018



Use of this email content is governed by the terms of service at:
http://www.idug.org/p/cm/ld/fid=2








Attachments

  • ecblank.gif (<1k)
  • graycol.gif (<1k)

Bruce Williamson

RE: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Steven Lamb)

Ok, please contact me offline for an undocumented solution which I'm not sure I'm at liberty to publish on a public forum like DB2-L.

Cheers
Bruce



In Reply to Steven Lamb:

Thanks Bruce - I'll have a play to see what the best way of doing it is. We do capture the run times from the Auto Tool, so I'll probably have to turn it off temporarily for the jobs in question.

The Reorgs all complete successfully, but the application transactions may Rollback depending on the calling system's "tolerance" for delays. So if there's a long final log iteration holding things up, this may exceed the calling system's timeout values and so the transaction is rolled back.

 

Regards,
Steve



P.S. Want to make a difference to DB2 but don't know how? Join the RFE Community?

P.P.S. While you're at it why not join the "All DB2 for z/OS" group and vote on community proposals

Steven Lamb

RE: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Bruce Williamson)

Thanks Bruce. I've worked out which skeleton I need to amend (HAAREORD) and tested some code in there so that the DIAGNOSE only gets added to the jobs that I want to add it to. A test job ran successfully without the DIAGNOSE END statement, so that makes it simpler.

 

Regards,

Steve

Steven Lamb

RE: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Steven Lamb)

The change is now in, with the DIAGNOSE statement, so I just need to wait for a "bad" run now.

Steven Lamb

RE: DB2 z/OS SHRLEVEL CHANGE Log phase
(in response to Steven Lamb)

The DIAGNOSE is doing its stuff, although I haven't seen any really bad runs since I put the change in.

I've attached the output for the reorg of one partition and as Bruce implied, it's the LOG FORCE WRITE / LOG SUBPROCESS in the final log iteration that seems to be the culprit - 4.4 seconds in this case. Another partition of the same tablespace that was reorged by the same batch job had a corresponding time of 0.019 seconds, so quite a variation.

What exactly is this LOG FORCE WRITE? Presumably it's a sync log write and the SWITCH phase can't be performed until the log records are written out.

 

Regards,

Steve

Attachments

  • Output.txt (51.1k)