DB2 Z Monday grouchiness

Aurora Emanuela Dellanno

DB2 Z Monday grouchiness

sorry, I think we need no comment and just admire the genius here :

 

++ HOLD(UI63392) SYSTEM DATE(19154) FMID(HDBBB10) REASON(ACTION)
COMMENT(
With the application of the PTF for PH08983, a change of behavior will occur in the following situation:
LOAD specifying PARALLEL with a single input data set and having discarding active with the discard data set defined
with a TEMPLATE.

Previous to this APAR, the discard data set in the above scenario would not have been allocated if there were no rows
to be discarded. Now with this fix, the discard data set will be allocated whether there are rows being discarded or not.).

Jorg Lueke

RE: DB2 Z Monday grouchiness
(in response to Aurora Emanuela Dellanno)

Were you able to leave it out of the JCL entirely before or was the DD still required but just not allocated?

Jørn Thyssen

RE: DB2 Z Monday grouchiness
(in response to Aurora Emanuela Dellanno)

I think the problem was that the dataset had incorrect dataset format under some circumstances. Instead of getting a discard dataset with undefined/invalid record format, record length, and block size, the discard dataset will now be allocated with those attributes matching the input load data set. This is the normal behavior when not using the PARALLEL keyword.

At least that's how I interpret the APAR cover letter: https://www-01.ibm.com/support/docview.wss?crawler=1&uid=swg1PH08983

If you have some downstream processing of discard files you could run into OPEN issues without PH08983 applied.

In Reply to Aurora Emanuela Dellanno:

sorry, I think we need no comment and just admire the genius here :

 

++ HOLD(UI63392) SYSTEM DATE(19154) FMID(HDBBB10) REASON(ACTION)
COMMENT(
With the application of the PTF for PH08983, a change of behavior will occur in the following situation:
LOAD specifying PARALLEL with a single input data set and having discarding active with the discard data set defined
with a TEMPLATE.

Previous to this APAR, the discard data set in the above scenario would not have been allocated if there were no rows
to be discarded. Now with this fix, the discard data set will be allocated whether there are rows being discarded or not.).



 

Best regards,

Jørn Thyssen

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

2019 IBM Champion.

Views are personal. 

Aurora Emanuela Dellanno

RE: DB2 Z Monday grouchiness
(in response to Jorg Lueke)

from my understanding, the DD was required but only checked when/if the discard dataset was created.

 

problems now may mean:

 

ABENDs if the DD specifies invalid DS names/attributes; or

ABENDs if the DD specifies an existing name with DISP=NEW; and

Thousands of unused/empty datasets allocated with names that don't expire...

 

Jorn, I see what you mean but the I'm moaning about here is allocating the dataset in everay situation: "Previous to this APAR, the discard data set in the above scenario would not have been allocated if there were no rows to be discarded. Now with this fix, the discard data set will be allocated whether there are rows being discarded or not".

 

Another Monday :)

 

Aurora

Jørn Thyssen

RE: DB2 Z Monday grouchiness
(in response to Aurora Emanuela Dellanno)

I believe the HOLD text is incorrect.

Previously, the discard dataset would have been allocated but with an invalid DCB.

The customer that opened the PMR that led to this APAR had some downstream processing of DISCARD datasets which would fail because of the invalid DCB (the OPEN macro fails even though the dataset is empty).

In Reply to Aurora Emanuela Dellanno:

from my understanding, the DD was required but only checked when/if the discard dataset was created.

 

problems now may mean:

 

ABENDs if the DD specifies invalid DS names/attributes; or

ABENDs if the DD specifies an existing name with DISP=NEW; and

Thousands of unused/empty datasets allocated with names that don't expire...

 

Jorn, I see what you mean but the I'm moaning about here is allocating the dataset in everay situation: "Previous to this APAR, the discard data set in the above scenario would not have been allocated if there were no rows to be discarded. Now with this fix, the discard data set will be allocated whether there are rows being discarded or not".

 

Another Monday :)

 

Aurora



 

Best regards,

Jørn Thyssen

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

2019 IBM Champion.

Views are personal. 

Aurora Emanuela Dellanno

RE: DB2 Z Monday grouchiness
(in response to Jørn Thyssen)

hmmmmmm interesting point, since in fact we are bracing ourselves to find out how many ancient load jobs we have in our production systems that may give our people on call work to do... (and also forewarning our storage people)...

Jørn Thyssen

RE: DB2 Z Monday grouchiness
(in response to Aurora Emanuela Dellanno)

I take that back :) There might be impact if you use LOAD PARALLEL and have a TEMPLATE for SYSDISC.

 

You might want to run a test with and without PH08983 applied.

 

In Reply to Aurora Emanuela Dellanno:

hmmmmmm interesting point, since in fact we are bracing ourselves to find out how many ancient load jobs we have in our production systems that may give our people on call work to do... (and also forewarning our storage people)...



 

Best regards,

Jørn Thyssen

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

2019 IBM Champion.

Views are personal.