After going to DB2 V12 problems extending datasets

William Proctor

After going to DB2 V12 problems extending datasets

I migrated db2 z/os 11.1 to V12 and things were going smooth until we started rebuilding indexes and loading a couple of tables.  now I am getting unable to extend datasets.  this is happening on various tables and indexes.  did something change in V12 that I missed or mistakenly changed a zparm?  I'm reading thru Doc's but need to get this resolved before my next migration tonight.   I can change the stogroup to our extended dataset pool and it works.   All Help is appreciated.

Lizette Koehler

After going to DB2 V12 problems extending datasets
(in response to William Proctor)
Could you post the entire message you are getting?


And did you check to see if there are other IEC type messages or IGD?



Maybe your SMS routines need to be reviewed



Lizette





From: William Proctor <[login to unmask email]>
Sent: Friday, May 15, 2020 7:10 AM
To: [login to unmask email]
Subject: [DB2-L] - After going to DB2 V12 problems extending datasets



I migrated db2 z/os 11.1 to V12 and things were going smooth until we started rebuilding indexes and loading a couple of tables. now I am getting unable to extend datasets. this is happening on various tables and indexes. did something change in V12 that I missed or mistakenly changed a zparm? I'm reading thru Doc's but need to get this resolved before my next migration tonight. I can change the stogroup to our extended dataset pool and it works. All Help is appreciated.



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

William Proctor

After going to DB2 V12 problems extending datasets
(in response to Lizette Koehler)

In jesmsglg output:

12.21.19 JOB07959 IEC705I TAPE ON 7333,P30220,SL,COMP,CCXLD065,DSNUPROC.LOAD065,MEDIA3
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9
12.21.20 JOB07959 IEA995I SYMPTOM DUMP OUTPUT 990
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9
990 SYSTEM COMPLETION CODE=04E REASON CODE=00E40347


In load utility output:

DSNU241I -Q 135 12:21:19.95 DSNURBDC - DICTIONARY WITH 4096 ENTRIES HAS BEEN SUCCESSFULLY BUILT FROM 1225 ROWS FOR
TABLE SPACE CXS3.TSCX065, PARTITION 1
DSNU016I 135 12:21:21.07 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'
DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'
DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'
DSNU398I -Q 135 12:21:20.85 DSNURWBF - UNEXPECTED PROCESSING ERROR, REASON=X'00E40318' ON TABLE - CXS3.CO_DA_FEE
DSNT500I 135 12:21:24.94 DSNUGBAC - RESOURCE UNAVAILABLE
REASON 00D70014
TYPE 00000220
NAME DB2Q.DSNDBC.CXS3.TSCX065.I0001.A001
DSNU017I 135 12:21:24.94 DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E40347'
CAUSE=X'00E40318'

From: Lizette Koehler <[login to unmask email]>
Sent: Friday, May 15, 2020 9:35 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Please see the Vine for additional information on malicious email.
Could you post the entire message you are getting?

And did you check to see if there are other IEC type messages or IGD?

Maybe your SMS routines need to be reviewed

Lizette


From: William Proctor <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 7:10 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - After going to DB2 V12 problems extending datasets


I migrated db2 z/os 11.1 to V12 and things were going smooth until we started rebuilding indexes and loading a couple of tables. now I am getting unable to extend datasets. this is happening on various tables and indexes. did something change in V12 that I missed or mistakenly changed a zparm? I'm reading thru Doc's but need to get this resolved before my next migration tonight. I can change the stogroup to our extended dataset pool and it works. All Help is appreciated.

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

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

Lizette Koehler

After going to DB2 V12 problems extending datasets
(in response to William Proctor)
Thanks for the details



One of the reasons might be One possible cause for this error is that the primary space allocation for the shadow data set is too small.

Check the packs available to the data set. They might merely be full or the data set might have reached its maximum allowable extents. For more information, see the description of message DSNP001I.





Is this the first time you executed this process after upgrading to DB2 V12?

Have you checked with your Storage Admins to see if the DB2 dataset is being managed differently?

Is there sufficient storage in the pool for the DB2 File?







From: Proctor, William <[login to unmask email]>
Sent: Friday, May 15, 2020 7:40 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets





In jesmsglg output:



12.21.19 JOB07959 IEC705I TAPE ON 7333,P30220,SL,COMP,CCXLD065,DSNUPROC.LOAD065,MEDIA3

12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

12.21.20 JOB07959 IEA995I SYMPTOM DUMP OUTPUT 990

12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

990 SYSTEM COMPLETION CODE=04E REASON CODE=00E40347





In load utility output:



DSNU241I -Q 135 12:21:19.95 DSNURBDC - DICTIONARY WITH 4096 ENTRIES HAS BEEN SUCCESSFULLY BUILT FROM 1225 ROWS FOR

TABLE SPACE CXS3.TSCX065, PARTITION 1

DSNU016I 135 12:21:21.07 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

DSNU398I -Q 135 12:21:20.85 DSNURWBF - UNEXPECTED PROCESSING ERROR, REASON=X'00E40318' ON TABLE - CXS3.CO_DA_FEE

DSNT500I 135 12:21:24.94 DSNUGBAC - RESOURCE UNAVAILABLE

REASON 00D70014

TYPE 00000220

NAME DB2Q.DSNDBC.CXS3.TSCX065.I0001.A001

DSNU017I 135 12:21:24.94 DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E40347'

CAUSE=X'00E40318'



From: Lizette Koehler <[login to unmask email] <mailto:[login to unmask email]> >
Sent: Friday, May 15, 2020 9:35 AM
To: [login to unmask email] <mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets



CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Please see the Vine for additional information on malicious email.

Could you post the entire message you are getting?


And did you check to see if there are other IEC type messages or IGD?



Maybe your SMS routines need to be reviewed



Lizette





From: William Proctor <[login to unmask email] <mailto:[login to unmask email]> >
Sent: Friday, May 15, 2020 7:10 AM
To: [login to unmask email] <mailto:[login to unmask email]>
Subject: [DB2-L] - After going to DB2 V12 problems extending datasets



I migrated db2 z/os 11.1 to V12 and things were going smooth until we started rebuilding indexes and loading a couple of tables. now I am getting unable to extend datasets. this is happening on various tables and indexes. did something change in V12 that I missed or mistakenly changed a zparm? I'm reading thru Doc's but need to get this resolved before my next migration tonight. I can change the stogroup to our extended dataset pool and it works. All Help is appreciated.



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



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



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

Randy Bright

After going to DB2 V12 problems extending datasets
(in response to William Proctor)
Are you REORGing or REBUILDing to convert to Extended RBA/LRSN from Basic?

If so, when converting to Extended RBA/LRSN it is possible fewer rows/keys will fit on a page due to the extended size of the page trailer. If you were very close to the DSSIZE limit before conversion this could be the issue. Try reducing PCTFREE or increasing FREEPAGE. Or increase DSSIZE. A LISTCAT will show you HURBA before the REBUILD.

Just one possibility.


Randy Bright
Solutions Architect, BMC Software, inc.

From: Proctor, William <[login to unmask email]>
Sent: Friday, May 15, 2020 9:40 AM
To: [login to unmask email]
Subject: [EXTERNAL] [DB2-L] - RE: After going to DB2 V12 problems extending datasets


In jesmsglg output:

12.21.19 JOB07959 IEC705I TAPE ON 7333,P30220,SL,COMP,CCXLD065,DSNUPROC.LOAD065,MEDIA3
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9
12.21.20 JOB07959 IEA995I SYMPTOM DUMP OUTPUT 990
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9
990 SYSTEM COMPLETION CODE=04E REASON CODE=00E40347


In load utility output:

DSNU241I -Q 135 12:21:19.95 DSNURBDC - DICTIONARY WITH 4096 ENTRIES HAS BEEN SUCCESSFULLY BUILT FROM 1225 ROWS FOR
TABLE SPACE CXS3.TSCX065, PARTITION 1
DSNU016I 135 12:21:21.07 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'
DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'
DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'
DSNU398I -Q 135 12:21:20.85 DSNURWBF - UNEXPECTED PROCESSING ERROR, REASON=X'00E40318' ON TABLE - CXS3.CO_DA_FEE
DSNT500I 135 12:21:24.94 DSNUGBAC - RESOURCE UNAVAILABLE
REASON 00D70014
TYPE 00000220
NAME DB2Q.DSNDBC.CXS3.TSCX065.I0001.A001
DSNU017I 135 12:21:24.94 DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E40347'
CAUSE=X'00E40318'

From: Lizette Koehler <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 9:35 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Please see the Vine for additional information on malicious email.
Could you post the entire message you are getting?

And did you check to see if there are other IEC type messages or IGD?

Maybe your SMS routines need to be reviewed

Lizette


From: William Proctor <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 7:10 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - After going to DB2 V12 problems extending datasets


I migrated db2 z/os 11.1 to V12 and things were going smooth until we started rebuilding indexes and loading a couple of tables. now I am getting unable to extend datasets. this is happening on various tables and indexes. did something change in V12 that I missed or mistakenly changed a zparm? I'm reading thru Doc's but need to get this resolved before my next migration tonight. I can change the stogroup to our extended dataset pool and it works. All Help is appreciated.

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

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

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

Horacio Villa

After going to DB2 V12 problems extending datasets
(in response to William Proctor)
you may also want to see messages on the console, LOG on SDSF.

Horacio Villa

William Proctor

After going to DB2 V12 problems extending datasets
(in response to Horacio Villa)
This is what's on the console log: I'm at a loss as to what I could have change that is causing datasets to exceed the 4 gb limit. These files haven't changed in years except we migrated to V12.

IEC070I 034(004)-220,DSNCDBM1,IEFPROC DSNCDBM1,A0000070,AC6E,DDBC52, 346
IEC070I DB2C.DSNDBC.CACS.TSCX065.I0001.A006,
IEC070I DB2C.DSNDBD.CACS.TSCX065.I0001.A006,CATALOG.DB2DEV.USERCAT
SVM4161I - PRS41412 USING 64-BIT EDB
SVM4161E - PRS41412 64-BIT EDB ID ERROR
SVM4161I - PRS43411 USING 64-BIT EDB
SVM4161E - PRS43411 64-BIT EDB ID ERROR
SVM4922S EXTENT WILL EXCEED THE 4GB LIMIT

+-----------------+---------------------------------------------------------+
|004 |End of volume - Non-extended addressable. The new |
| |allocation amount would exceed 4 GB. |



From: Horacio Villa <[login to unmask email]>
Sent: Friday, May 15, 2020 12:13 PM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Please see the Vine for additional information on malicious email.
you may also want to see messages on the console, LOG on SDSF.

Horacio Villa
-----End Original Message-----

William Proctor

After going to DB2 V12 problems extending datasets
(in response to Lizette Koehler)
I changed my tablespaces and index spaces to go to our extended addressability dasd pool and the jobs will work as long as I do that. We have plenty of disk space in both pools. V12 doesn’t require all dataset to be in extended addressability does it?


From: Lizette Koehler <[login to unmask email]>
Sent: Friday, May 15, 2020 9:52 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

Thanks for the details

One of the reasons might be One possible cause for this error is that the primary space allocation for the shadow data set is too small.
Check the packs available to the data set. They might merely be full or the data set might have reached its maximum allowable extents. For more information, see the description of message DSNP001I.


Is this the first time you executed this process after upgrading to DB2 V12?
Have you checked with your Storage Admins to see if the DB2 dataset is being managed differently?
Is there sufficient storage in the pool for the DB2 File?



From: Proctor, William <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 7:40 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets


In jesmsglg output:

12.21.19 JOB07959 IEC705I TAPE ON 7333,P30220,SL,COMP,CCXLD065,DSNUPROC.LOAD065,MEDIA3
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9
12.21.20 JOB07959 IEA995I SYMPTOM DUMP OUTPUT 990
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9
990 SYSTEM COMPLETION CODE=04E REASON CODE=00E40347


In load utility output:

DSNU241I -Q 135 12:21:19.95 DSNURBDC - DICTIONARY WITH 4096 ENTRIES HAS BEEN SUCCESSFULLY BUILT FROM 1225 ROWS FOR
TABLE SPACE CXS3.TSCX065, PARTITION 1
DSNU016I 135 12:21:21.07 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'
DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'
DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'
DSNU398I -Q 135 12:21:20.85 DSNURWBF - UNEXPECTED PROCESSING ERROR, REASON=X'00E40318' ON TABLE - CXS3.CO_DA_FEE
DSNT500I 135 12:21:24.94 DSNUGBAC - RESOURCE UNAVAILABLE
REASON 00D70014
TYPE 00000220
NAME DB2Q.DSNDBC.CXS3.TSCX065.I0001.A001
DSNU017I 135 12:21:24.94 DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E40347'
CAUSE=X'00E40318'

From: Lizette Koehler <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 9:35 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Please see the Vine for additional information on malicious email.
Could you post the entire message you are getting?

And did you check to see if there are other IEC type messages or IGD?

Maybe your SMS routines need to be reviewed

Lizette


From: William Proctor <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 7:10 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - After going to DB2 V12 problems extending datasets


I migrated db2 z/os 11.1 to V12 and things were going smooth until we started rebuilding indexes and loading a couple of tables. now I am getting unable to extend datasets. this is happening on various tables and indexes. did something change in V12 that I missed or mistakenly changed a zparm? I'm reading thru Doc's but need to get this resolved before my next migration tonight. I can change the stogroup to our extended dataset pool and it works. All Help is appreciated.

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

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

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

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

Horacio Villa

After going to DB2 V12 problems extending datasets
(in response to William Proctor)
No, it doesn't.
It would be nice to know how's your tablespace defined, and the allocated
space it had previously.
But in other answer you were told that maybe the LRSN conversion from 6 to
10 bytes the cause.
Have you analyzed that?

Horacio Villa












From: "Proctor, William" <[login to unmask email]>
To: "[login to unmask email]" <[login to unmask email]>
Date: 15/05/2020 16:27
Subject: [EXTERNAL] [DB2-L] - RE: After going to DB2 V12 problems
extending datasets



I changed my tablespaces and index spaces to go to our extended
addressability dasd pool and the jobs will work as long as I do that. We
have plenty of disk space in both pools. V12 doesn?t require all dataset
to be in extended addressability does it?


From: Lizette Koehler <[login to unmask email]>
Sent: Friday, May 15, 2020 9:52 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

Thanks for the details

One of the reasons might be One possible cause for this error is that the
primary space allocation for the shadow data set is too small.
Check the packs available to the data set. They might merely be full or
the data set might have reached its maximum allowable extents. For more
information, see the description of message DSNP001I.


Is this the first time you executed this process after upgrading to DB2
V12?
Have you checked with your Storage Admins to see if the DB2 dataset is
being managed differently?
Is there sufficient storage in the pool for the DB2 File?



From: Proctor, William <[login to unmask email]>
Sent: Friday, May 15, 2020 7:40 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets


In jesmsglg output:

12.21.19 JOB07959 IEC705I TAPE ON
7333,P30220,SL,COMP,CCXLD065,DSNUPROC.LOAD065,MEDIA3
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to
unsupported execution environment: TCB Not protect KEY 8 or 9
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to
unsupported execution environment: TCB Not protect KEY 8 or 9
12.21.20 JOB07959 IEA995I SYMPTOM DUMP OUTPUT 990
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to
unsupported execution environment: TCB Not protect KEY 8 or 9
990 SYSTEM COMPLETION CODE=04E REASON CODE=00E40347



In load utility output:

DSNU241I -Q 135 12:21:19.95 DSNURBDC - DICTIONARY WITH 4096 ENTRIES HAS
BEEN SUCCESSFULLY BUILT FROM 1225 ROWS FOR
TABLE SPACE CXS3.TSCX065, PARTITION 1
DSNU016I 135 12:21:21.07 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION
ABENDED, REASON=X'00E40347'
DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION
ABENDED, REASON=X'00E40347'
DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION
ABENDED, REASON=X'00E40347'
DSNU398I -Q 135 12:21:20.85 DSNURWBF - UNEXPECTED PROCESSING ERROR,
REASON=X'00E40318' ON TABLE - CXS3.CO_DA_FEE
DSNT500I 135 12:21:24.94 DSNUGBAC - RESOURCE UNAVAILABLE
REASON 00D70014
TYPE 00000220
NAME DB2Q.DSNDBC.CXS3.TSCX065.I0001.A001
DSNU017I 135 12:21:24.94 DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY
EXECUTION ABENDED, REASON=X'00E40347'
CAUSE=X'00E40318'

From: Lizette Koehler <[login to unmask email]>
Sent: Friday, May 15, 2020 9:35 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know
the content is safe. Please see the Vine for additional information on
malicious email.
Could you post the entire message you are getting?

And did you check to see if there are other IEC type messages or IGD?

Maybe your SMS routines need to be reviewed

Lizette


From: William Proctor <[login to unmask email]>
Sent: Friday, May 15, 2020 7:10 AM
To: [login to unmask email]
Subject: [DB2-L] - After going to DB2 V12 problems extending datasets

I migrated db2 z/os 11.1 to V12 and things were going smooth until we
started rebuilding indexes and loading a couple of tables. now I am
getting unable to extend datasets. this is happening on various tables
and indexes. did something change in V12 that I missed or mistakenly
changed a zparm? I'm reading thru Doc's but need to get this resolved
before my next migration tonight. I can change the stogroup to our
extended dataset pool and it works. All Help is appreciated.

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

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

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

-----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]
Try BCV5, the BCV5 Masking Tool, & XDM a rapid Refresh/Clone/TDM Suite for
Db2 z & distributed.
DBARS -Audit,record,& block Db2 accesses to sensitive data real-time, NO
audit trace or log required
http://www.ESAIGroup.com/IDUG

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




William Proctor

After going to DB2 V12 problems extending datasets
(in response to Horacio Villa)
I've been looking at that but I think our systems program has found a problem with our tool that intercepts extending dataset request. I'm hoping this is it. I will post the resolution if that's it.

From: Horacio Villa <[login to unmask email]>
Sent: Friday, May 15, 2020 2:54 PM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

No, it doesn't.
It would be nice to know how's your tablespace defined, and the allocated space it had previously.
But in other answer you were told that maybe the LRSN conversion from 6 to 10 bytes the cause.
Have you analyzed that?

Horacio Villa





From: "Proctor, William" <[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: 15/05/2020 16:27
Subject: [EXTERNAL] [DB2-L] - RE: After going to DB2 V12 problems extending datasets
________________________________



I changed my tablespaces and index spaces to go to our extended addressability dasd pool and the jobs will work as long as I do that. We have plenty of disk space in both pools. V12 doesn't require all dataset to be in extended addressability does it?


From: Lizette Koehler <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 9:52 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

Thanks for the details

One of the reasons might be One possible cause for this error is that the primary space allocation for the shadow data set is too small.
Check the packs available to the data set. They might merely be full or the data set might have reached its maximum allowable extents. For more information, see the description of message DSNP001I.


Is this the first time you executed this process after upgrading to DB2 V12?
Have you checked with your Storage Admins to see if the DB2 dataset is being managed differently?
Is there sufficient storage in the pool for the DB2 File?



From: Proctor, William <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 7:40 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets


In jesmsglg output:

12.21.19 JOB07959 IEC705I TAPE ON 7333,P30220,SL,COMP,CCXLD065,DSNUPROC.LOAD065,MEDIA3
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9
12.21.20 JOB07959 IEA995I SYMPTOM DUMP OUTPUT 990
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9
990 SYSTEM COMPLETION CODE=04E REASON CODE=00E40347


In load utility output:

DSNU241I -Q 135 12:21:19.95 DSNURBDC - DICTIONARY WITH 4096 ENTRIES HAS BEEN SUCCESSFULLY BUILT FROM 1225 ROWS FOR
TABLE SPACE CXS3.TSCX065, PARTITION 1
DSNU016I 135 12:21:21.07 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'
DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'
DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'
DSNU398I -Q 135 12:21:20.85 DSNURWBF - UNEXPECTED PROCESSING ERROR, REASON=X'00E40318' ON TABLE - CXS3.CO_DA_FEE
DSNT500I 135 12:21:24.94 DSNUGBAC - RESOURCE UNAVAILABLE
REASON 00D70014
TYPE 00000220
NAME DB2Q.DSNDBC.CXS3.TSCX065.I0001.A001
DSNU017I 135 12:21:24.94 DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E40347'
CAUSE=X'00E40318'

From: Lizette Koehler <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 9:35 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

CAUTION:This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Please see the Vine for additional information on malicious email.
Could you post the entire message you are getting?

And did you check to see if there are other IEC type messages or IGD?

Maybe your SMS routines need to be reviewed

Lizette


From: William Proctor <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 7:10 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - After going to DB2 V12 problems extending datasets


I migrated db2 z/os 11.1 to V12 and things were going smooth until we started rebuilding indexes and loading a couple of tables. now I am getting unable to extend datasets. this is happening on various tables and indexes. did something change in V12 that I missed or mistakenly changed a zparm? I'm reading thru Doc's but need to get this resolved before my next migration tonight. I can change the stogroup to our extended dataset pool and it works. All Help is appreciated.

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

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

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

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

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

Roy Boxwell

After going to DB2 V12 problems extending datasets
(in response to William Proctor)
Remember that any datasets over 4GB need those two “extended” attributes...
And there was a recent PMR in Db2 12 which fixed a nasty bug when your datasets tried to extend over 4GB...

Roy Boxwell
SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-
Vagedesstrasse 19
40479 Dusseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]
http://www.seg.de
Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz

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

On 15 May 2020, at 21:27, Proctor, William <[login to unmask email]> wrote:


I changed my tablespaces and index spaces to go to our extended addressability dasd pool and the jobs will work as long as I do that. We have plenty of disk space in both pools. V12 doesn’t require all dataset to be in extended addressability does it?


From: Lizette Koehler <[login to unmask email]>
Sent: Friday, May 15, 2020 9:52 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

Thanks for the details

One of the reasons might be One possible cause for this error is that the primary space allocation for the shadow data set is too small.
Check the packs available to the data set. They might merely be full or the data set might have reached its maximum allowable extents. For more information, see the description of message DSNP001I.


Is this the first time you executed this process after upgrading to DB2 V12?
Have you checked with your Storage Admins to see if the DB2 dataset is being managed differently?
Is there sufficient storage in the pool for the DB2 File?



From: Proctor, William <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 7:40 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets


In jesmsglg output:

12.21.19 JOB07959 IEC705I TAPE ON 7333,P30220,SL,COMP,CCXLD065,DSNUPROC.LOAD065,MEDIA3
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9
12.21.20 JOB07959 IEA995I SYMPTOM DUMP OUTPUT 990
12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9
990 SYSTEM COMPLETION CODE=04E REASON CODE=00E40347


In load utility output:

DSNU241I -Q 135 12:21:19.95 DSNURBDC - DICTIONARY WITH 4096 ENTRIES HAS BEEN SUCCESSFULLY BUILT FROM 1225 ROWS FOR
TABLE SPACE CXS3.TSCX065, PARTITION 1
DSNU016I 135 12:21:21.07 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'
DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'
DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'
DSNU398I -Q 135 12:21:20.85 DSNURWBF - UNEXPECTED PROCESSING ERROR, REASON=X'00E40318' ON TABLE - CXS3.CO_DA_FEE
DSNT500I 135 12:21:24.94 DSNUGBAC - RESOURCE UNAVAILABLE
REASON 00D70014
TYPE 00000220
NAME DB2Q.DSNDBC.CXS3.TSCX065.I0001.A001
DSNU017I 135 12:21:24.94 DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E40347'
CAUSE=X'00E40318'

From: Lizette Koehler <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 9:35 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Please see the Vine for additional information on malicious email.
Could you post the entire message you are getting?

And did you check to see if there are other IEC type messages or IGD?

Maybe your SMS routines need to be reviewed

Lizette


From: William Proctor <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 7:10 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - After going to DB2 V12 problems extending datasets


I migrated db2 z/os 11.1 to V12 and things were going smooth until we started rebuilding indexes and loading a couple of tables. now I am getting unable to extend datasets. this is happening on various tables and indexes. did something change in V12 that I missed or mistakenly changed a zparm? I'm reading thru Doc's but need to get this resolved before my next migration tonight. I can change the stogroup to our extended dataset pool and it works. All Help is appreciated.

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

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

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

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

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

Lizette Koehler

After going to DB2 V12 problems extending datasets
(in response to Roy Boxwell)
I think all of our DB2 linear datasets are in EA/EF format. Saves waking up at 2am to fix a db2 storage issue.



Lizette





From: Boxwell, Roy <[login to unmask email]>
Sent: Friday, May 15, 2020 2:20 PM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets



Remember that any datasets over 4GB need those two “extended” attributes...

And there was a recent PMR in Db2 12 which fixed a nasty bug when your datasets tried to extend over 4GB...

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.

-Product Development-

Vagedesstrasse 19

40479 Dusseldorf/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

Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz



Software Engineering GmbH

Amtsgericht Düsseldorf, HRB 37894

Geschäftsführung: Gerhard Schubert, Ulf Heinrich





On 15 May 2020, at 21:27, Proctor, William <[login to unmask email] <mailto:[login to unmask email]> > wrote:



I changed my tablespaces and index spaces to go to our extended addressability dasd pool and the jobs will work as long as I do that. We have plenty of disk space in both pools. V12 doesn’t require all dataset to be in extended addressability does it?





From: Lizette Koehler <[login to unmask email] <mailto:[login to unmask email]> >
Sent: Friday, May 15, 2020 9:52 AM
To: [login to unmask email] <mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets



Thanks for the details



One of the reasons might be One possible cause for this error is that the primary space allocation for the shadow data set is too small.

Check the packs available to the data set. They might merely be full or the data set might have reached its maximum allowable extents. For more information, see the description of message DSNP001I.





Is this the first time you executed this process after upgrading to DB2 V12?

Have you checked with your Storage Admins to see if the DB2 dataset is being managed differently?

Is there sufficient storage in the pool for the DB2 File?







From: Proctor, William <[login to unmask email] <mailto:[login to unmask email]> >
Sent: Friday, May 15, 2020 7:40 AM
To: [login to unmask email] <mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets





In jesmsglg output:



12.21.19 JOB07959 IEC705I TAPE ON 7333,P30220,SL,COMP,CCXLD065,DSNUPROC.LOAD065,MEDIA3

12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

12.21.20 JOB07959 IEA995I SYMPTOM DUMP OUTPUT 990

12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

990 SYSTEM COMPLETION CODE=04E REASON CODE=00E40347





In load utility output:



DSNU241I -Q 135 12:21:19.95 DSNURBDC - DICTIONARY WITH 4096 ENTRIES HAS BEEN SUCCESSFULLY BUILT FROM 1225 ROWS FOR

TABLE SPACE CXS3.TSCX065, PARTITION 1

DSNU016I 135 12:21:21.07 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

DSNU398I -Q 135 12:21:20.85 DSNURWBF - UNEXPECTED PROCESSING ERROR, REASON=X'00E40318' ON TABLE - CXS3.CO_DA_FEE

DSNT500I 135 12:21:24.94 DSNUGBAC - RESOURCE UNAVAILABLE

REASON 00D70014

TYPE 00000220

NAME DB2Q.DSNDBC.CXS3.TSCX065.I0001.A001

DSNU017I 135 12:21:24.94 DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E40347'

CAUSE=X'00E40318'



From: Lizette Koehler <[login to unmask email] <mailto:[login to unmask email]> >
Sent: Friday, May 15, 2020 9:35 AM
To: [login to unmask email] <mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets



CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Please see the Vine for additional information on malicious email.

Could you post the entire message you are getting?


And did you check to see if there are other IEC type messages or IGD?



Maybe your SMS routines need to be reviewed



Lizette





From: William Proctor <[login to unmask email] <mailto:[login to unmask email]> >
Sent: Friday, May 15, 2020 7:10 AM
To: [login to unmask email] <mailto:[login to unmask email]>
Subject: [DB2-L] - After going to DB2 V12 problems extending datasets



I migrated db2 z/os 11.1 to V12 and things were going smooth until we started rebuilding indexes and loading a couple of tables. now I am getting unable to extend datasets. this is happening on various tables and indexes. did something change in V12 that I missed or mistakenly changed a zparm? I'm reading thru Doc's but need to get this resolved before my next migration tonight. I can change the stogroup to our extended dataset pool and it works. All Help is appreciated.



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



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



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



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



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



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

Leila Hosseini

After going to DB2 V12 problems extending datasets
(in response to Lizette Koehler)
Regards to bellow error message which I Cut and paste from your email

IEC070I DB2C.DSNDBC.CACS.TSCX065.I0001.A006,                              

IEC070I DB2C.DSNDBD.CACS.TSCX065.I0001.A006,CATALOG.DB2DEV.USERCAT        

SVM4161I - PRS41412 USING 64-BIT EDB                                      

SVM4161E - PRS41412 64-BIT EDB ID ERROR                                   

SVM4161I - PRS43411 USING 64-BIT EDB                                      

SVM4161E - PRS43411 64-BIT EDB ID ERROR                                    

SVM4922S EXTENT WILL EXCEED THE 4GB LIMIT  
It is a partitioned tablespace which exceedes 4G in part 6.You should have Alter limit key for part 6 in order to reduce rows in part 6 which leads to less  required space for part 6 vsam file.Before Alter limit key you should have consider rows in part 7 as well.Because rows will  be pushed to next part.Before Alter limit key , you should 
Unload part 6 ,7Delete part 6,7Alter limit key part 6Load part 6,7Runstat

The other solution could be as below:One time the vsam files exceeded the Dssize , and I defined new  Partitioned tablespace unload/reload whole table space and then Rename.
Hopefully it helpsRegards Leila
Sent from Yahoo Mail for iPhone


On Friday, May 15, 2020, 5:32 PM, Lizette Koehler <[login to unmask email]> wrote:

#yiv3518353908 #yiv3518353908 -- _filtered {} _filtered {}#yiv3518353908 #yiv3518353908 p.yiv3518353908MsoNormal, #yiv3518353908 li.yiv3518353908MsoNormal, #yiv3518353908 div.yiv3518353908MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:sans-serif;}#yiv3518353908 a:link, #yiv3518353908 span.yiv3518353908MsoHyperlink {color:blue;text-decoration:underline;}#yiv3518353908 .yiv3518353908MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv3518353908 div.yiv3518353908WordSection1 {}#yiv3518353908
I think all of our DB2 linear datasets are in EA/EF format.  Saves waking up at 2am to fix a db2 storage issue.

 

Lizette

 

 

From: Boxwell, Roy <[login to unmask email]>
Sent: Friday, May 15, 2020 2:20 PM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

 

Remember that any datasets over 4GB need those two “extended” attributes...

And there was a recent PMR in Db2 12 which fixed a nasty bug when your datasets tried to extend over 4GB...

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.

-Product Development-

Vagedesstrasse 19

40479 Dusseldorf/Germany

Tel. +49 (0)211 96149-675

Fax +49 (0)211 96149-32

Email: [login to unmask email]

http://www.seg.de

Link zur Datenschutzerklärung

 

Software Engineering GmbH

Amtsgericht Düsseldorf, HRB 37894

Geschäftsführung: Gerhard Schubert, Ulf Heinrich 






On 15 May 2020, at 21:27, Proctor, William <[login to unmask email]> wrote:





I changed my tablespaces and index spaces to go to our extended addressability dasd pool and the jobs will work as long as I do that.   We have plenty of disk space in both pools.  V12 doesn’t require all dataset to be in extended addressability does it?

 

 

From: Lizette Koehler <[login to unmask email]>
Sent: Friday, May 15, 2020 9:52 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

 

Thanks for the details

 

One of the reasons might be One possible cause for this error is that the primary space allocation for the shadow data set is too small.

Check the packs available to the data set. They might merely be full or the data set might have reached its maximum allowable extents. For more information, see the description of message DSNP001I.

 

 

Is this the first time you executed this process after upgrading to DB2 V12?

Have you checked with your Storage Admins to see if the DB2 dataset is being managed differently?

Is there sufficient storage in the pool for the DB2 File?

 

 

 

From: Proctor, William <[login to unmask email]>
Sent: Friday, May 15, 2020 7:40 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

 

 

In jesmsglg output:

 

12.21.19 JOB07959  IEC705I TAPE ON 7333,P30220,SL,COMP,CCXLD065,DSNUPROC.LOAD065,MEDIA3                                            

12.21.20 JOB07959  IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

12.21.20 JOB07959  IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

12.21.20 JOB07959  IEA995I SYMPTOM DUMP OUTPUT  990                                                                                

12.21.20 JOB07959  IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

   990             SYSTEM COMPLETION CODE=04E  REASON CODE=00E40347                                                                

 

 

In load utility output:

 

DSNU241I  -Q 135 12:21:19.95 DSNURBDC - DICTIONARY WITH 4096 ENTRIES HAS BEEN SUCCESSFULLY BUILT FROM 1225 ROWS FOR    

TABLE SPACE CXS3.TSCX065, PARTITION 1                                                                                   

DSNU016I    135 12:21:21.07 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'                      

DSNU016I    135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'                      

DSNU016I    135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'                      

DSNU398I  -Q 135 12:21:20.85 DSNURWBF - UNEXPECTED PROCESSING ERROR, REASON=X'00E40318' ON TABLE - CXS3.CO_DA_FEE      

DSNT500I    135 12:21:24.94 DSNUGBAC - RESOURCE UNAVAILABLE                                                            

                      REASON 00D70014                                                                                  

                      TYPE 00000220                                                                                     

                      NAME DB2Q.DSNDBC.CXS3.TSCX065.I0001.A001                                                         

DSNU017I    135 12:21:24.94 DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E40347'         

CAUSE=X'00E40318'                                                                                                      

 

From: Lizette Koehler <[login to unmask email]>
Sent: Friday, May 15, 2020 9:35 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Please see the Vine for additional information on malicious email.

Could you post the entire message you are getting?


And did you check to see if there are other IEC type messages or IGD?

 

Maybe your SMS routines need to be reviewed

 

Lizette

 

 

From: William Proctor <[login to unmask email]>
Sent: Friday, May 15, 2020 7:10 AM
To: [login to unmask email]
Subject: [DB2-L] - After going to DB2 V12 problems extending datasets

 

I migrated db2 z/os 11.1 to V12 and things were going smooth until we started rebuilding indexes and loading a couple of tables.  now I am getting unable to extend datasets.  this is happening on various tables and indexes.  did something change in V12 that I missed or mistakenly changed a zparm?  I'm reading thru Doc's but need to get this resolved before my next migration tonight.   I can change the stogroup to our extended dataset pool and it works.   All Help is appreciated.

 

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

 

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

 

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

 

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

 

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


 
-----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]
Try BCV5, the BCV5 Masking Tool, & XDM a rapid Refresh/Clone/TDM Suite for Db2 z & distributed.
DBARS -Audit,record,& block Db2 accesses to sensitive data real-time, NO audit trace or log required
http://www.ESAIGroup.com/IDUG



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



don isenstadt

After going to DB2 V12 problems extending datasets
(in response to Leila Hosseini)
If you are on DB2 V12 FL500 or above .. consider RPN – relative page number ..then you can change DSSIZE by partition without reorg. Very nice feature ..

From: Leila hosseini <[login to unmask email]>
Sent: Friday, May 15, 2020 5:53 PM
To: [login to unmask email]
Subject: [EXT] [DB2-L] - RE: After going to DB2 V12 problems extending datasets

Regards to bellow error message which I Cut and paste from your email



IEC070I DB2C.DSNDBC.CACS.TSCX065.I0001.A006,

IEC070I DB2C.DSNDBD.CACS.TSCX065.I0001.A006,CATALOG.DB2DEV.USERCAT

SVM4161I - PRS41412 USING 64-BIT EDB

SVM4161E - PRS41412 64-BIT EDB ID ERROR

SVM4161I - PRS43411 USING 64-BIT EDB

SVM4161E - PRS43411 64-BIT EDB ID ERROR

SVM4922S EXTENT WILL EXCEED THE 4GB LIMIT
It is a partitioned tablespace which exceedes 4G in part 6.
You should have Alter limit key for part 6 in order to reduce rows in part 6 which leads to less required space for part 6 vsam file.
Before Alter limit key you should have consider rows in part 7 as well.Because rows will be pushed to next part.
Before Alter limit key , you should

Unload part 6 ,7
Delete part 6,7
Alter limit key part 6
Load part 6,7
Runstat


The other solution could be as below:
One time the vsam files exceeded the Dssize , and I defined new Partitioned tablespace unload/reload whole table space and then Rename.

Hopefully it helps
Regards
Leila

Sent from Yahoo Mail for iPhone https://urldefense.proofpoint.com/v2/url?u=https-3A__overview.mail.yahoo.com_-3F.src-3DiOS&d=DwMFaQ&c=zQLjxGaFENyz7VqOLRV_eQ&r=YYJeIjQmwOPmpdSI5kr3va7kMQC7npk_rze_KSpW0lE&m=FqMjKOsBcY8XSHIHow9ZAW2ycUSDdcrQ9aNlLYvhMSM&s=6dbCGqHXou6Zniq6ltwieTiMngkycxzSTkQS2-R_9kw&e=

On Friday, May 15, 2020, 5:32 PM, Lizette Koehler <[login to unmask email]<mailto:[login to unmask email]>> wrote:

I think all of our DB2 linear datasets are in EA/EF format. Saves waking up at 2am to fix a db2 storage issue.



Lizette





From: Boxwell, Roy <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 2:20 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets



Remember that any datasets over 4GB need those two “extended” attributes...

And there was a recent PMR in Db2 12 which fixed a nasty bug when your datasets tried to extend over 4GB...

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.

-Product Development-

Vagedesstrasse 19

40479 Dusseldorf/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 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.seg.de&d=DwMFaQ&c=zQLjxGaFENyz7VqOLRV_eQ&r=YYJeIjQmwOPmpdSI5kr3va7kMQC7npk_rze_KSpW0lE&m=FqMjKOsBcY8XSHIHow9ZAW2ycUSDdcrQ9aNlLYvhMSM&s=tlsdDHsY3016T_iqolCcIq5JdjJkZm-e4l5BDr_0H2I&e=

Link zur Datenschutzerklärung https://urldefense.proofpoint.com/v2/url?u=https-3A__www.seg.de_corporate_rechtliche-2Dhinweise_datenschutz_&d=DwMFaQ&c=zQLjxGaFENyz7VqOLRV_eQ&r=YYJeIjQmwOPmpdSI5kr3va7kMQC7npk_rze_KSpW0lE&m=FqMjKOsBcY8XSHIHow9ZAW2ycUSDdcrQ9aNlLYvhMSM&s=RFvJQ7ts3q1L0lD0ZC2dxi0fdQtzIZsZsz_1D1Is4us&e=



Software Engineering GmbH

Amtsgericht Düsseldorf, HRB 37894

Geschäftsführung: Gerhard Schubert, Ulf Heinrich



On 15 May 2020, at 21:27, Proctor, William <[login to unmask email]<mailto:[login to unmask email]>> wrote:



I changed my tablespaces and index spaces to go to our extended addressability dasd pool and the jobs will work as long as I do that. We have plenty of disk space in both pools. V12 doesn’t require all dataset to be in extended addressability does it?





From: Lizette Koehler <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 9:52 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets



Thanks for the details



One of the reasons might be One possible cause for this error is that the primary space allocation for the shadow data set is too small.

Check the packs available to the data set. They might merely be full or the data set might have reached its maximum allowable extents. For more information, see the description of message DSNP001I.





Is this the first time you executed this process after upgrading to DB2 V12?

Have you checked with your Storage Admins to see if the DB2 dataset is being managed differently?

Is there sufficient storage in the pool for the DB2 File?







From: Proctor, William <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 7:40 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets





In jesmsglg output:



12.21.19 JOB07959 IEC705I TAPE ON 7333,P30220,SL,COMP,CCXLD065,DSNUPROC.LOAD065,MEDIA3

12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

12.21.20 JOB07959 IEA995I SYMPTOM DUMP OUTPUT 990

12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

990 SYSTEM COMPLETION CODE=04E REASON CODE=00E40347





In load utility output:



DSNU241I -Q 135 12:21:19.95 DSNURBDC - DICTIONARY WITH 4096 ENTRIES HAS BEEN SUCCESSFULLY BUILT FROM 1225 ROWS FOR

TABLE SPACE CXS3.TSCX065, PARTITION 1

DSNU016I 135 12:21:21.07 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

DSNU398I -Q 135 12:21:20.85 DSNURWBF - UNEXPECTED PROCESSING ERROR, REASON=X'00E40318' ON TABLE - CXS3.CO_DA_FEE

DSNT500I 135 12:21:24.94 DSNUGBAC - RESOURCE UNAVAILABLE

REASON 00D70014

TYPE 00000220

NAME DB2Q.DSNDBC.CXS3.TSCX065.I0001.A001

DSNU017I 135 12:21:24.94 DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E40347'

CAUSE=X'00E40318'



From: Lizette Koehler <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 9:35 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets



CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Please see the Vine for additional information on malicious email.

Could you post the entire message you are getting?

And did you check to see if there are other IEC type messages or IGD?



Maybe your SMS routines need to be reviewed



Lizette





From: William Proctor <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 7:10 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - After going to DB2 V12 problems extending datasets



I migrated db2 z/os 11.1 to V12 and things were going smooth until we started rebuilding indexes and loading a couple of tables. now I am getting unable to extend datasets. this is happening on various tables and indexes. did something change in V12 that I missed or mistakenly changed a zparm? I'm reading thru Doc's but need to get this resolved before my next migration tonight. I can change the stogroup to our extended dataset pool and it works. All Help is appreciated.



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



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



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



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



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


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

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

Leila Hosseini

After going to DB2 V12 problems extending datasets
(in response to don isenstadt)



Sent from Yahoo Mail for iPhone


On Saturday, May 16, 2020, 11:26 AM, Don Isenstadt <[login to unmask email]> wrote:

#yiv2838804832 #yiv2838804832 -- _filtered {} _filtered {}#yiv2838804832 #yiv2838804832 p.yiv2838804832MsoNormal, #yiv2838804832 li.yiv2838804832MsoNormal, #yiv2838804832 div.yiv2838804832MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:sans-serif;}#yiv2838804832 a:link, #yiv2838804832 span.yiv2838804832MsoHyperlink {color:blue;text-decoration:underline;}#yiv2838804832 a:visited, #yiv2838804832 span.yiv2838804832MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv2838804832 p.yiv2838804832msonormal0, #yiv2838804832 li.yiv2838804832msonormal0, #yiv2838804832 div.yiv2838804832msonormal0 {margin-right:0in;margin-left:0in;font-size:11.0pt;font-family:sans-serif;}#yiv2838804832 p.yiv2838804832msonormal, #yiv2838804832 li.yiv2838804832msonormal, #yiv2838804832 div.yiv2838804832msonormal {margin-right:0in;margin-left:0in;font-size:11.0pt;font-family:sans-serif;}#yiv2838804832 p.yiv2838804832yahoo-quoted-begin, #yiv2838804832 li.yiv2838804832yahoo-quoted-begin, #yiv2838804832 div.yiv2838804832yahoo-quoted-begin {margin-right:0in;margin-left:0in;font-size:11.0pt;font-family:sans-serif;}#yiv2838804832 p.yiv2838804832msonormal, #yiv2838804832 li.yiv2838804832msonormal, #yiv2838804832 div.yiv2838804832msonormal {margin-right:0in;margin-left:0in;font-size:11.0pt;font-family:sans-serif;}#yiv2838804832 p.yiv2838804832msochpdefault, #yiv2838804832 li.yiv2838804832msochpdefault, #yiv2838804832 div.yiv2838804832msochpdefault {margin-right:0in;margin-left:0in;font-size:11.0pt;font-family:sans-serif;}#yiv2838804832 span.yiv2838804832msohyperlink {}#yiv2838804832 p.yiv2838804832msonormal1, #yiv2838804832 li.yiv2838804832msonormal1, #yiv2838804832 div.yiv2838804832msonormal1 {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:sans-serif;}#yiv2838804832 p.yiv2838804832msonormal2, #yiv2838804832 li.yiv2838804832msonormal2, #yiv2838804832 div.yiv2838804832msonormal2 {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:sans-serif;}#yiv2838804832 span.yiv2838804832msohyperlink1 {color:blue;text-decoration:underline;}#yiv2838804832 p.yiv2838804832msochpdefault1, #yiv2838804832 li.yiv2838804832msochpdefault1, #yiv2838804832 div.yiv2838804832msochpdefault1 {margin-right:0in;margin-left:0in;font-size:10.0pt;font-family:sans-serif;}#yiv2838804832 span.yiv2838804832EmailStyle29 {font-family:sans-serif;color:windowtext;}#yiv2838804832 .yiv2838804832MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv2838804832 div.yiv2838804832WordSection1 {}#yiv2838804832
If you are on DB2 V12 FL500 or above .. consider RPN – relative page number ..then you can change DSSIZE by partition  without reorg. Very nice feature ..

 

From: Leila hosseini <[login to unmask email]>
Sent: Friday, May 15, 2020 5:53 PM
To: [login to unmask email]
Subject: [EXT] [DB2-L] - RE: After going to DB2 V12 problems extending datasets

 

Regards to bellow error message which I Cut and paste from your email





IEC070I DB2C.DSNDBC.CACS.TSCX065.I0001.A006,                              

IEC070I DB2C.DSNDBD.CACS.TSCX065.I0001.A006,CATALOG.DB2DEV.USERCAT        

SVM4161I - PRS41412 USING 64-BIT EDB                                      

SVM4161E - PRS41412 64-BIT EDB ID ERROR                                   

SVM4161I - PRS43411 USING 64-BIT EDB                                      

SVM4161E - PRS43411 64-BIT EDB ID ERROR                                    

SVM4922S EXTENT WILL EXCEED THE 4GB LIMIT  

It is a partitioned tablespace which exceedes 4G in part 6.

You should have Alter limit key for part 6 in order to reduce rows in part 6 which leads to less  required space for part 6 vsam file.

Before Alter limit key you should have consider rows in part 7 as well.Because rows will  be pushed to next part.

Before Alter limit key , you should 

 

Unload part 6 ,7

Delete part 6,7

Alter limit key part 6

Load part 6,7

Runstat

 

 

The other solution could be as below:

One time the vsam files exceeded the Dssize , and I defined new  Partitioned tablespace unload/reload whole table space and then Rename.

 

Hopefully it helps

Regards 

Leila


Sent from Yahoo Mail for iPhone

On Friday, May 15, 2020, 5:32 PM, Lizette Koehler <[login to unmask email]> wrote:


I think all of our DB2 linear datasets are in EA/EF format.  Saves waking up at 2am to fix a db2 storage issue.

 

Lizette

 

 

From: Boxwell, Roy <[login to unmask email]>
Sent: Friday, May 15, 2020 2:20 PM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

 

Remember that any datasets over 4GB need those two “extended” attributes...

And there was a recent PMR in Db2 12 which fixed a nasty bug when your datasets tried to extend over 4GB...

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.

-Product Development-

Vagedesstrasse 19

40479 Dusseldorf/Germany

Tel. +49 (0)211 96149-675

Fax +49 (0)211 96149-32

Email: [login to unmask email]

http://www.seg.de

Link zur Datenschutzerklärung

 

Software Engineering GmbH

Amtsgericht Düsseldorf, HRB 37894

Geschäftsführung: Gerhard Schubert, Ulf Heinrich 

 


On 15 May 2020, at 21:27, Proctor, William <[login to unmask email]> wrote:





I changed my tablespaces and index spaces to go to our extended addressability dasd pool and the jobs will work as long as I do that.   We have plenty of disk space in both pools.  V12 doesn’t require all dataset to be in extended addressability does it?

 

 

From: Lizette Koehler <[login to unmask email]>
Sent: Friday, May 15, 2020 9:52 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

 

Thanks for the details

 

One of the reasons might be One possible cause for this error is that the primary space allocation for the shadow data set is too small.

Check the packs available to the data set. They might merely be full or the data set might have reached its maximum allowable extents. For more information, see the description of message DSNP001I.

 

 

Is this the first time you executed this process after upgrading to DB2 V12?

Have you checked with your Storage Admins to see if the DB2 dataset is being managed differently?

Is there sufficient storage in the pool for the DB2 File?

 

 

 

From: Proctor, William <[login to unmask email]>
Sent: Friday, May 15, 2020 7:40 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

 

 

In jesmsglg output:

 

12.21.19 JOB07959  IEC705I TAPE ON 7333,P30220,SL,COMP,CCXLD065,DSNUPROC.LOAD065,MEDIA3                                            

12.21.20 JOB07959  IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

12.21.20 JOB07959  IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

12.21.20 JOB07959  IEA995I SYMPTOM DUMP OUTPUT  990                                                                                

12.21.20 JOB07959  IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

   990             SYSTEM COMPLETION CODE=04E  REASON CODE=00E40347                                                                

 

 

In load utility output:

 

DSNU241I  -Q 135 12:21:19.95 DSNURBDC - DICTIONARY WITH 4096 ENTRIES HAS BEEN SUCCESSFULLY BUILT FROM 1225 ROWS FOR    

TABLE SPACE CXS3.TSCX065, PARTITION 1                                                                                   

DSNU016I    135 12:21:21.07 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'                      

DSNU016I    135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'                      

DSNU016I    135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'                      

DSNU398I  -Q 135 12:21:20.85 DSNURWBF - UNEXPECTED PROCESSING ERROR, REASON=X'00E40318' ON TABLE - CXS3.CO_DA_FEE      

DSNT500I    135 12:21:24.94 DSNUGBAC - RESOURCE UNAVAILABLE                                                            

                      REASON 00D70014                                                                                  

                      TYPE 00000220                                                                                     

                      NAME DB2Q.DSNDBC.CXS3.TSCX065.I0001.A001                                                         

DSNU017I    135 12:21:24.94 DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E40347'         

CAUSE=X'00E40318'                                                                                                      

 

From: Lizette Koehler <[login to unmask email]>
Sent: Friday, May 15, 2020 9:35 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Please see the Vine for additional information on malicious email.

Could you post the entire message you are getting?


And did you check to see if there are other IEC type messages or IGD?

 

Maybe your SMS routines need to be reviewed

 

Lizette

 

 

From: William Proctor <[login to unmask email]>
Sent: Friday, May 15, 2020 7:10 AM
To: [login to unmask email]
Subject: [DB2-L] - After going to DB2 V12 problems extending datasets

 

I migrated db2 z/os 11.1 to V12 and things were going smooth until we started rebuilding indexes and loading a couple of tables.  now I am getting unable to extend datasets.  this is happening on various tables and indexes.  did something change in V12 that I missed or mistakenly changed a zparm?  I'm reading thru Doc's but need to get this resolved before my next migration tonight.   I can change the stogroup to our extended dataset pool and it works.   All Help is appreciated.

 

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

 

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

 

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

 

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

 

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


 

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

 
-----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]
Try BCV5, the BCV5 Masking Tool, & XDM a rapid Refresh/Clone/TDM Suite for Db2 z & distributed.
DBARS -Audit,record,& block Db2 accesses to sensitive data real-time, NO audit trace or log required
http://www.ESAIGroup.com/IDUG



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




Roy Boxwell

After going to DB2 V12 problems extending datasets
(in response to Roy Boxwell)
Here’s the APAR and PTF for the 4GB problem in Db2 12: PH10015 UI64089





Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.
-Product Development-

Vagedesstrasse 19
40479 Dusseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: <mailto:[login to unmask email]> [login to unmask email]
Web http://www.seg.de http://www.seg.de

https://www.seg.de/corporate/rechtliche-hinweise/datenschutz Link zur Datenschutzerklärung


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



From: Boxwell, Roy <[login to unmask email]>
Sent: Friday, May 15, 2020 11:20 PM
To: [login to unmask email]
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets



Remember that any datasets over 4GB need those two “extended” attributes...

And there was a recent PMR in Db2 12 which fixed a nasty bug when your datasets tried to extend over 4GB...

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.

-Product Development-

Vagedesstrasse 19

40479 Dusseldorf/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

Link zur Datenschutzerklärung https://www.seg.de/corporate/rechtliche-hinweise/datenschutz



Software Engineering GmbH

Amtsgericht Düsseldorf, HRB 37894

Geschäftsführung: Gerhard Schubert, Ulf Heinrich





On 15 May 2020, at 21:27, Proctor, William <[login to unmask email] <mailto:[login to unmask email]> > wrote:



I changed my tablespaces and index spaces to go to our extended addressability dasd pool and the jobs will work as long as I do that. We have plenty of disk space in both pools. V12 doesn’t require all dataset to be in extended addressability does it?





From: Lizette Koehler <[login to unmask email] <mailto:[login to unmask email]> >
Sent: Friday, May 15, 2020 9:52 AM
To: [login to unmask email] <mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets



Thanks for the details



One of the reasons might be One possible cause for this error is that the primary space allocation for the shadow data set is too small.

Check the packs available to the data set. They might merely be full or the data set might have reached its maximum allowable extents. For more information, see the description of message DSNP001I.





Is this the first time you executed this process after upgrading to DB2 V12?

Have you checked with your Storage Admins to see if the DB2 dataset is being managed differently?

Is there sufficient storage in the pool for the DB2 File?







From: Proctor, William <[login to unmask email] <mailto:[login to unmask email]> >
Sent: Friday, May 15, 2020 7:40 AM
To: [login to unmask email] <mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets





In jesmsglg output:



12.21.19 JOB07959 IEC705I TAPE ON 7333,P30220,SL,COMP,CCXLD065,DSNUPROC.LOAD065,MEDIA3

12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

12.21.20 JOB07959 IEA995I SYMPTOM DUMP OUTPUT 990

12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

990 SYSTEM COMPLETION CODE=04E REASON CODE=00E40347





In load utility output:



DSNU241I -Q 135 12:21:19.95 DSNURBDC - DICTIONARY WITH 4096 ENTRIES HAS BEEN SUCCESSFULLY BUILT FROM 1225 ROWS FOR

TABLE SPACE CXS3.TSCX065, PARTITION 1

DSNU016I 135 12:21:21.07 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

DSNU398I -Q 135 12:21:20.85 DSNURWBF - UNEXPECTED PROCESSING ERROR, REASON=X'00E40318' ON TABLE - CXS3.CO_DA_FEE

DSNT500I 135 12:21:24.94 DSNUGBAC - RESOURCE UNAVAILABLE

REASON 00D70014

TYPE 00000220

NAME DB2Q.DSNDBC.CXS3.TSCX065.I0001.A001

DSNU017I 135 12:21:24.94 DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E40347'

CAUSE=X'00E40318'



From: Lizette Koehler <[login to unmask email] <mailto:[login to unmask email]> >
Sent: Friday, May 15, 2020 9:35 AM
To: [login to unmask email] <mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets



CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Please see the Vine for additional information on malicious email.

Could you post the entire message you are getting?


And did you check to see if there are other IEC type messages or IGD?



Maybe your SMS routines need to be reviewed



Lizette





From: William Proctor <[login to unmask email] <mailto:[login to unmask email]> >
Sent: Friday, May 15, 2020 7:10 AM
To: [login to unmask email] <mailto:[login to unmask email]>
Subject: [DB2-L] - After going to DB2 V12 problems extending datasets



I migrated db2 z/os 11.1 to V12 and things were going smooth until we started rebuilding indexes and loading a couple of tables. now I am getting unable to extend datasets. this is happening on various tables and indexes. did something change in V12 that I missed or mistakenly changed a zparm? I'm reading thru Doc's but need to get this resolved before my next migration tonight. I can change the stogroup to our extended dataset pool and it works. All Help is appreciated.



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



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



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



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



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



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

Attachments

  • smime.p7s (5.1k)

Larry Jardine

After going to DB2 V12 problems extending datasets
(in response to Leila Hosseini)
Or just REORG tsname PART 6:7 REBALANCE SHRLEVEL CHANGE STATISTICS TABLE ALL INDEX (ALL) UPDATE ALL.
Then REBIND impacted packages.

I favor that over ANY option that includes unloading and dropping data.

Larry Jardine
Database Advisor, Aetna, a CVS Health Company

[CVS]
CONFIDENTIALITY NOTICE: This communication and any attachments may contain confidential and/or privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. If you have received this communication in error, please notify the sender immediately by email or telephone and destroy all copies of this communication and any attachments.



Proprietary
From: Leila hosseini <[login to unmask email]>
Sent: Friday, May 15, 2020 5:53 PM
To: [login to unmask email]
Subject: [EXTERNAL] [DB2-L] - RE: After going to DB2 V12 problems extending datasets

**** External Email - Use Caution ****
Regards to bellow error message which I Cut and paste from your email


IEC070I DB2C.DSNDBC.CACS.TSCX065.I0001.A006,

IEC070I DB2C.DSNDBD.CACS.TSCX065.I0001.A006,CATALOG.DB2DEV.USERCAT

SVM4161I - PRS41412 USING 64-BIT EDB

SVM4161E - PRS41412 64-BIT EDB ID ERROR

SVM4161I - PRS43411 USING 64-BIT EDB

SVM4161E - PRS43411 64-BIT EDB ID ERROR

SVM4922S EXTENT WILL EXCEED THE 4GB LIMIT
It is a partitioned tablespace which exceedes 4G in part 6.
You should have Alter limit key for part 6 in order to reduce rows in part 6 which leads to less required space for part 6 vsam file.
Before Alter limit key you should have consider rows in part 7 as well.Because rows will be pushed to next part.
Before Alter limit key , you should

Unload part 6 ,7
Delete part 6,7
Alter limit key part 6
Load part 6,7
Runstat


The other solution could be as below:
One time the vsam files exceeded the Dssize , and I defined new Partitioned tablespace unload/reload whole table space and then Rename.

Hopefully it helps
Regards
Leila

Sent from Yahoo Mail for iPhone https://urldefense.proofpoint.com/v2/url?u=https-3A__overview.mail.yahoo.com_-3F.src-3DiOS&d=DwMFaQ&c=wluqKIiwffOpZ6k5sqMWMBOn0vyYnlulRJmmvOXCFpM&r=wfE0VOZJYg9uIjc5BuTMYexNGrByDwh1giBA3sSm6qo&m=O3CsWml40m3TerTV_ShCI9yFcoSdF7lL8S32UBJCtP4&s=6N4-u7aUh_RQGEpkc9kpnsAbTvy13WzUaSNfksWPYTs&e=

On Friday, May 15, 2020, 5:32 PM, Lizette Koehler <[login to unmask email]<mailto:[login to unmask email]>> wrote:

I think all of our DB2 linear datasets are in EA/EF format. Saves waking up at 2am to fix a db2 storage issue.



Lizette





From: Boxwell, Roy <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 2:20 PM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets



Remember that any datasets over 4GB need those two “extended” attributes...

And there was a recent PMR in Db2 12 which fixed a nasty bug when your datasets tried to extend over 4GB...

Roy Boxwell

SOFTWARE ENGINEERING GmbH and SEGUS Inc.

-Product Development-

Vagedesstrasse 19

40479 Dusseldorf/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 https://urldefense.proofpoint.com/v2/url?u=http-3A__www.seg.de&d=DwMFaQ&c=wluqKIiwffOpZ6k5sqMWMBOn0vyYnlulRJmmvOXCFpM&r=wfE0VOZJYg9uIjc5BuTMYexNGrByDwh1giBA3sSm6qo&m=O3CsWml40m3TerTV_ShCI9yFcoSdF7lL8S32UBJCtP4&s=lI4EiOmHVbcziF2Dhd5Ns9Xm0u8xYk54vFxg1LBgNGc&e=

Link zur Datenschutzerklärung https://urldefense.proofpoint.com/v2/url?u=https-3A__www.seg.de_corporate_rechtliche-2Dhinweise_datenschutz_&d=DwMFaQ&c=wluqKIiwffOpZ6k5sqMWMBOn0vyYnlulRJmmvOXCFpM&r=wfE0VOZJYg9uIjc5BuTMYexNGrByDwh1giBA3sSm6qo&m=O3CsWml40m3TerTV_ShCI9yFcoSdF7lL8S32UBJCtP4&s=Mny7IUCqbCAYv6UhGw6umj5GTlmUaSSA9rzGvydhjzA&e=



Software Engineering GmbH

Amtsgericht Düsseldorf, HRB 37894

Geschäftsführung: Gerhard Schubert, Ulf Heinrich



On 15 May 2020, at 21:27, Proctor, William <[login to unmask email]<mailto:[login to unmask email]>> wrote:



I changed my tablespaces and index spaces to go to our extended addressability dasd pool and the jobs will work as long as I do that. We have plenty of disk space in both pools. V12 doesn’t require all dataset to be in extended addressability does it?





From: Lizette Koehler <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 9:52 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets



Thanks for the details



One of the reasons might be One possible cause for this error is that the primary space allocation for the shadow data set is too small.

Check the packs available to the data set. They might merely be full or the data set might have reached its maximum allowable extents. For more information, see the description of message DSNP001I.





Is this the first time you executed this process after upgrading to DB2 V12?

Have you checked with your Storage Admins to see if the DB2 dataset is being managed differently?

Is there sufficient storage in the pool for the DB2 File?







From: Proctor, William <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 7:40 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets





In jesmsglg output:



12.21.19 JOB07959 IEC705I TAPE ON 7333,P30220,SL,COMP,CCXLD065,DSNUPROC.LOAD065,MEDIA3

12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

12.21.20 JOB07959 IEA995I SYMPTOM DUMP OUTPUT 990

12.21.20 JOB07959 IDI0123S Processing of abend S04E terminated due to unsupported execution environment: TCB Not protect KEY 8 or 9

990 SYSTEM COMPLETION CODE=04E REASON CODE=00E40347





In load utility output:



DSNU241I -Q 135 12:21:19.95 DSNURBDC - DICTIONARY WITH 4096 ENTRIES HAS BEEN SUCCESSFULLY BUILT FROM 1225 ROWS FOR

TABLE SPACE CXS3.TSCX065, PARTITION 1

DSNU016I 135 12:21:21.07 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

DSNU016I 135 12:21:21.10 DSNUGSAT - UTILITY BATCH MEMORY EXECUTION ABENDED, REASON=X'00E40347'

DSNU398I -Q 135 12:21:20.85 DSNURWBF - UNEXPECTED PROCESSING ERROR, REASON=X'00E40318' ON TABLE - CXS3.CO_DA_FEE

DSNT500I 135 12:21:24.94 DSNUGBAC - RESOURCE UNAVAILABLE

REASON 00D70014

TYPE 00000220

NAME DB2Q.DSNDBC.CXS3.TSCX065.I0001.A001

DSNU017I 135 12:21:24.94 DSNUGBAC - UTILITY DATA BASE SERVICES MEMORY EXECUTION ABENDED, REASON=X'00E40347'

CAUSE=X'00E40318'



From: Lizette Koehler <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 9:35 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - RE: After going to DB2 V12 problems extending datasets



CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Please see the Vine for additional information on malicious email.

Could you post the entire message you are getting?

And did you check to see if there are other IEC type messages or IGD?



Maybe your SMS routines need to be reviewed



Lizette





From: William Proctor <[login to unmask email]<mailto:[login to unmask email]>>
Sent: Friday, May 15, 2020 7:10 AM
To: [login to unmask email]<mailto:[login to unmask email]>
Subject: [DB2-L] - After going to DB2 V12 problems extending datasets



I migrated db2 z/os 11.1 to V12 and things were going smooth until we started rebuilding indexes and loading a couple of tables. now I am getting unable to extend datasets. this is happening on various tables and indexes. did something change in V12 that I missed or mistakenly changed a zparm? I'm reading thru Doc's but need to get this resolved before my next migration tonight. I can change the stogroup to our extended dataset pool and it works. All Help is appreciated.



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



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



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



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



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


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

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

NOTICE TO RECIPIENT OF INFORMATION:
This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately.
This e-mail may also contain protected health information (PHI) with information about sensitive medical conditions, including, but not limited to, treatment for substance use disorders, behavioral health, HIV/AIDS, or pregnancy. This type of information may be protected by various federal and/or state laws which prohibit any further disclosure without the express written consent of the person to whom it pertains or as otherwise permitted by law. Any unauthorized further disclosure may be considered a violation of federal and/or state law. A general authorization for the release of medical or other information may NOT be sufficient consent for release of this type of information.
Thank you. Aetna
Attachments

  • image003.png (3.8k)