ca.portal.admin

Re:Re: 2 PDE copies in memory

Discussion created by ca.portal.admin on Aug 30, 2007
Luis,

From everything that you have posted - especially the PDE memory
display, this should never happen..

You should do a DCMT D PRO to see if you have programs out of
sequence....(display should be alphabetical)

This looks like a corrupted PDT (Program Definition Table)

If this is something that happens all the time, you should open an
issue..

The DCMT D PRO walks an alphabetic index and should not have exactly the
same entries for programs..unless they are from different
dictnames,dictnodes,loadlibs,versions etc.

The PDE displays you sent are identical and this is not normal (nor
acceptable)..

The LOAD/CALL counts can increment on either PDE since the binary search
(when using this program) could find either index entry at different
times.

Bottom line.. this is NOT normal...

If you see this consistently occurring on your CA-IDMS CV --

You should open an issue with CA, and make sure no one is varying a
program name in memory at any time.



Regards,

Edward F McKinney

CA-IDMS L2



________________________________

From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of luish@BR.IBM.COM
Sent: Wednesday, August 29, 2007 5:52 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: 2 copies in memory




Thanks for your comments.

Here is the both PDE's:


This is the PDE at 1C06D9A8:



and this is the PDE at 1B061350:




Luis H.
+55 11 8339-0102
ManageNow: LUISHMR
IDMS / DB2 - System Support Team - SSO
IBM Global Services - VISTEON
=========================================



Don Casey <donjcasey@COMCAST.NET>
Sent by: IDMS Public Discussion Forum <IDMS-L@LISTSERV.IUASSN.COM>

29/08/2007 15:29

Please respond to
IDMS Public Discussion Forum <IDMS-L@LISTSERV.IUASSN.COM>

To

IDMS-L@LISTSERV.IUASSN.COM

cc



Subject

Re: [IDMSVENDOR-L] Calling IDMSCOM










This is strange.



Based on the displays, there appears to be only one load module, coming
out of one dictionary, but it is being controlled by 2 PDEs and
therefore there are two copies in memory.



The PDEs appear identical (but there are clearly two), and the only
theory I have at this point is that the DICTNODE fields are not
identical, with perhaps un-displayable characters in one.



Can you get a memory display of both PDEs to see if one DICTNODE is
blank and the other nulls?



_____

From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On
Behalf Of luish@BR.IBM.COM
Sent: Wednesday, August 29, 2007 8:50 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: [IDMSVENDOR-L] Calling IDMSCOM
Importance: High




Hi,

I need to understand why I have 2 copies of the same program in
memory. Both are loaded from DICTDB and are exactly the same.
Both copies are in use and the times called is growing for both
copies.

We are at 15.0.

The program is a MAP and REUSABLE.

Could someone point me the pages to read about this or explain
something about that ?


From sysgen manual:
REUSable
Specifies the program can be executed repeatedly. When a request to load
the

program is issued, the system will load a copy of the program from
external storage only if no copy exists in the program pool.





Thanks in advance.

Luis H.
IBM - VISTEON
=========================================


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








High

Normal
Re: System Index area expansion
"Without knowing more about your physical design, my guess is that the full
uncompressed size of your SR8s are larger than 35% of the page size.

The Database Administration manual has the formulas, but it is basically
(the size of the symbolic key + dbkey_length) * (IBC + 1) plus pointer
positions. Make it about 20% of the block size and you should be safe, you
can change that either by changing the IBC clause, or increasing the page
size.

Since you ended up with twice the number of SR8s as you started out with, I
assume that the index is on a field that contains values that are not
coming in sequence.
To improve the index performance you will need special DMCL and schema for
the index rebuild. The DMCL should have a page reserve, and the Index
should be defined with a smaller IBC in the schema. If you make the IBC
90% of the original, make the page reserve at least 10% of the page size.
I usually lower the IBC by 20% and make the page reserve 10% plus the size
of an SR8. This allows for the SR8s to grow, and one split on each page.
You can play around with the numbers, but usually you won't know the full
impact until it is implemented in the production database.

Tommy Petersen




Woo Liew
<woo_liew.lim@CPF
.GOV.SG> To
Sent by: IDMS IDMS-L@LISTSERV.IUASSN.COM
Public Discussion cc
Forum
<IDMS-L@LISTSERV. Subject
IUASSN.COM> System Index area expansion


09/04/2007 06:39
AM


Please respond to
IDMS Public
Discussion Forum
<IDMS-L@LISTSERV.
IUASSN.COM>







Hi,

Recently, we had done a system index area expansion. We unloaded the index
data, increased the page range of the area and reloaded back the data to
the area. The occurrences of the SR8 were reduced significantly from about
60k to about 20k. However, when the application programmer run their
routine job to store the data into the related record area ( member of the
index set), it experienced significant slowness. The job took about 45min
to 1 hour to store the same amount of data (about 150k) before the
expansion and took about 10 hours after the index expansion. The number of
SR8 increased from 20k to 40k after the completion of the job.

This was the first time we did an index area expansion. We are not so sure
what has gone wrong and what is the cause of the slowness after the
expansion.

We need the expert's advice on this.

Thks in advance

Rgds


Lim


WARNING: This communication is meant only for the addressee(s) named above
and may contain information which is confidential and/or legally
privileged. If you are not the named addressee(s), or the agent responsible
for receiving and delivering this communication to the named addressee(s),
this communication has been sent to you in error. If so, kindly notify the
sender and delete the information immediately. Unauthorised dissemination,
distribution, copying or reliance on this communication is prohibited and
may attract criminal penalties.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Pro's & Con's of Multiple Target and DLIB Zones in SMP/E
"If my memory is correct, when I did this about 10 years ago, I only had one
group of SMP/E libraries, that was actually separate from the CV''s Loadlibs.
Each CV had it's own group of three concatenated loadlibs that kept the
various releases so that backouts could be done quickly and easily. I did keep
detailed records of where I was at. I never had any problem with this setup.
The three concatenated loadlibs per CV were left over from the pre SMP/E days
when PTFS were applied. I wasn't all that excited about maintaining all
sorts of SMP/E libraries, one set was bad enough.

Thomas M. De Neui
Consultant


**************************************
Get a sneak peek of the
all-new AOL at http://discover.aol.com/memed/aolcom30tour
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: System Index area expansion
"Hi Lim,
Did you specify a page reserve of approx. 29% in the index area
definition? This allows for the index to grow without using too much
overflow pages. Also make sure that you have done your maths concerning
the index block contains (IBC) and page offset values in conjunction
with the page size and the number of pages in the area. Just increasing
the page range by itself is in general not sufficient. The index will
have plenty of space to grow, but this space will not be used
efficiently and you will end up with SR8's scattered all over you area.
Note that you can specify the IBC and pageoffset in the DMCL (segment
defintion) using a symbolic key that must match the same key in the
schema. The Database Administration guide contains information on both
the page reserve and on how to calculate the IBC, page offset, number of
pages and pagesize. If you get them wrong the insert performance will
suffer, especially if it's the first large insert job after the
expansion. In addition you could take a look at some reports that tell
you about the index' structure (IDMSDBAN, PRINT INDEX, etc.). Indexes
that have a high upgrade factor (many insert and deletes) are candidates
for regular maintenance using the REBUILD INDEX utility.

Good luck,
Martin Wieland
Neckermann.com



-----Oorspronkelijk bericht-----
Van: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
Namens Woo Liew
Verzonden: dinsdag 4 september 2007 12:39
Aan: IDMS-L@LISTSERV.IUASSN.COM
Onderwerp: System Index area expansion


Hi,

Recently, we had done a system index area expansion. We unloaded the
index
data, increased the page range of the area and reloaded back the data to
the area. The occurrences of the SR8 were reduced significantly from
about
60k to about 20k. However, when the application programmer run their
routine job to store the data into the related record area ( member of
the
index set), it experienced significant slowness. The job took about
45min
to 1 hour to store the same amount of data (about 150k) before the
expansion and took about 10 hours after the index expansion. The number
of
SR8 increased from 20k to 40k after the completion of the job.

This was the first time we did an index area expansion. We are not so
sure
what has gone wrong and what is the cause of the slowness after the
expansion.

We need the expert's advice on this.

Thks in advance

Rgds


Lim


WARNING: This communication is meant only for the addressee(s) named
above and may contain information which is confidential and/or legally
privileged. If you are not the named addressee(s), or the agent
responsible for receiving and delivering this communication to the named
addressee(s), this communication has been sent to you in error. If so,
kindly notify the sender and delete the information immediately.
Unauthorised dissemination, distribution, copying or reliance on this
communication is prohibited and may attract criminal penalties.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
System Index area expansion
"Hi,

Recently, we had done a system index area expansion. We unloaded the index
data, increased the page range of the area and reloaded back the data to
the area. The occurrences of the SR8 were reduced significantly from about
60k to about 20k. However, when the application programmer run their
routine job to store the data into the related record area ( member of the
index set), it experienced significant slowness. The job took about 45min
to 1 hour to store the same amount of data (about 150k) before the
expansion and took about 10 hours after the index expansion. The number of
SR8 increased from 20k to 40k after the completion of the job.

This was the first time we did an index area expansion. We are not so sure
what has gone wrong and what is the cause of the slowness after the
expansion.

We need the expert's advice on this.

Thks in advance

Rgds


Lim


WARNING: This communication is meant only for the addressee(s) named above and may contain information which is confidential and/or legally privileged. If you are not the named addressee(s), or the agent responsible for receiving and delivering this communication to the named addressee(s), this communication has been sent to you in error. If so, kindly notify the sender and delete the information immediately. Unauthorised dissemination, distribution, copying or reliance on this communication is prohibited and may attract criminal penalties.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: 2 PDE copies in memory
"The only time I have varied memory on a sysgened pde was when a dc-cobol
program was compiled as batch and when IDMS attempted to load it an
error message about a bad version of cobol was issued, and this was in a
test system. I would not think doing this in a production environment.

Steve

Outcomes