ca.portal.admin

Re:Performance Degradation after Database Enlarge/Expand

Discussion created by ca.portal.admin on Feb 8, 2006
From: Bill Vohs, SC Data Center, Monroe, Wi
Date: February 1, 2006

Subject: Enlarge/Expand IDMS Database Causes Severe Performance
Degradation

We are running:

z/OS 1.4
IDMS Release 16 SP02
EMC DMX2000 DASD

We have a need to enlarge a number of the IDMS databases.

Every time we do, we experience severe performance degradation.
Run times elongate by a factor of 3 to 5.
Job that ran in 30 minutes now takes 3-4 hours.

Our first attempt was back in November 2005.
The approach at that time was to do an UNLOAD and RELOAD to the enlarged
area.
This time we enlarged the databases by a factor of 3.
I.e. One database went from 15,000 tracks to 45,000 tracks.
Another database went from 7,000 tracks to 21,000
tracks.
These all on 3390 DASD on the EMC DMX2000.

Our run times were:

Before UNLOAD/RELOAD 11/09/2005 74
minutes
11/10/2005 46 minutes

After UNLOAD/RELOAD 11/16/2005 174
minutes
11/1/2005 198 minutes

This happened with almost every one of our jobs.

Our second attempt was January 29, 2006..
The approach this time was to do a EXPAND PAGE to an enlarged area
This time the databases were enlarged by a factor of 2.
One database went from PAGE SIZE 5064 to 10796 from 15,000 tracks to
30,000
tracks.
Another database went from PAGE SIZE 5064 to 10796 from 7,000 tracks to
14,000 tracks.

The run times are:

Before EXPAND PAGE 01/26/2006
64
minutes

After EXPAND PAGE 01/31/2006
209
minutes
02/01/2006 212 minutes


We have had an IDMS consultant review our work and he says every thing
looks
great.

Our z/OS and IDMS statistics show nothing out of the ordinary.

We are at a bit of a loss.

Might anybody have any suggestion for us?

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
HSL products with Z/OS 1.7
"Is anyone running HSL products under Z/OS 1.7 - specifically Date
Simulator, DBSTATS, and DBSpace?

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
External security overhead
"We're being pushed to turn all our IDMS security over to RACF.

Years ago (when first going to Release 12), the overhead of the calls
through the SVC to RACF was immense (when we eliminated 90% of the
calls, we also got a 63% CPU reduction, but, of course, no remembers this
little fact). The question is has anything improved in Release 14.1 or
16?? Do I even dare try it??

Alan Fields
VF Corporation
Greensboro, NC

336-424-4773
Alan_Fields@vfc.com

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Index key length
"What is the maximum length (in bytes) of an index key?

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
An update to the Performance Problem after Database Enlarge/Exten d
"From: Bill Vohs, SC Data Center, Monroe, Wi
Date: February 9, 2006

Subject: Enlarge/Expand IDMS Database Causes Severe Performance
Degradation

I really hate to tell you this, but
A lot of these questions I am being asked are going right over my head.

We don't have a DBA.
I am a 'Systems Programmer' that was volunteered to do this stuff.
I know absolutely nothing about IDMS.
I am just copying/using JCL that was created years ago.

I do know:
These job are all run CV-Mode.
We have over 100,000 buffer pages allocated.
The buffers are split between files. The busier the file the more
buffers it has.
PREFETCH=NO.

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Index key length
"Kay,
Per Documentation (Rel 14)
Sort-element-name specifies the name of a group or elementary data item
defined in an element description statement for the named member record
type, with the following restrictions:
No element named FILLER can be used in the sort control element.
No element that redefines another element or is subordinate to an
element that redefines another element can be used in the sort control
element.
No repeating element (that is, one defined with an OCCURS clause) and no
element subordinate to a repeating element can be used in the sort
control element.
No element exceeding 256 bytes can be used in the sort control element.
Multiple sort-element-name values (each with its own order) can be
coded, forming a compound sort control element and thereby allowing the
member records to be sorted on more than 1 element within the record.
The element names that make up the sort control element need not be
contiguous within the member record. Note, however, that the combined
lengths of the elements (as defined in the PICTURE and USAGE clauses of
the ELEMENT substatement) must not exceed 256 bytes. Do not code
multiple sort-element-names for native VSAM sets.

Note the statemSent: ""Note, however, that the combined lengths of the
elements (as defined in the PICTURE and USAGE clauses of the ELEMENT
substatement) must not exceed 256 bytes.""

Answer is 256.

Scott

Outcomes