Why Parallel Unload/Reload would have helped.........

[ca.portal.admin]

Thought I would share some interesting statistics from a=20 situation
where the new Express Unload/Reload would have helped.=20

We added a new area/records that we added to satisfy some Sarbanes Oxley

compliance requirements. This new area grew at a rate no one
anticipated.=20 One fine Wednesday before we can look at the weekly
print space reports, I get a call that this new production area has
filled up=20 and task are taking 1211's all over the place.=20

Since this was our busiest production region we had to act quickly
and=20 ran an expand page and changed the block size from 6516 to
13032.=20 We were only down 18 minutes and the earthquake only measured
2.3=20 on the management scale...

However, before I could get a good weekend to unload/reload the area,
the area fills once again in the middle of a week. (Murphy's law hard at
work) This time I decided an extend space was in order and I added 3
datasets to the=20 area. So now I have an area that has been xpaged and
extended.=20

I expected the I/O to the area to go up because of the space=20
management implications, but the interesting part is the I/O went=20
through the roof! See the real daily I/O to the area below;=20

I/O per day
Before XPAGE 450,000 =20
After XPAGE 902,177 =20
After Extend Space 10,773,437 - yes, over 10 million, this is not a typo

After Unload/Reload 497,783 =20

As you can see when we were able to unload/reload it=20 cut the I/O
considerably (understatement!).=20 The good news is the new Express
Unload/Reload would=20 have allowed me to unload reload the area in a
much smaller time frame.=20 I could have reorganized the area before it
filled the second time.=20 We are all looking forward to this new SP4
feature.

Regards,
Terry Schwartz

"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: Why Parallel Unload/Reload would have helped.........
"Henny,

What's the format of your dbkey? (430 records per page tells me it's not the
default).
Is it a problem users are not able to access the data being unloaded for
such a long time or do they have access to a copy of the data?


Kind Regards,

Sibe Verbeek
DBA
Fortis Bank
Tel. [phone]
Woerden
The Netherlands

-----Oorspronkelijk bericht-----
Van: IDMS Public Discussion Forum
[mailTo:[e-mail]]Namens [e-mail]
Verzonden: donderdag 15 juni 2006 11:27
Aan: [e-mail]
Onderwerp: Why Parallel Unload/Reload would have helped.........


Terry,

At this time I'm busy (waiting) with a Unload/reload of 2 area's. This
is a big one.
The biggest area contains 865,000,000 recs.
It has a pagesize of 13690 and 2,000,000 pages.
New size is 8904 and 4,000,000 pages.
It takes me 10 days to do it.
I use all the time 2 tapeunits and 130 packs for work.
When i could use the new Utility I think it would cost me 3 days and 600
packs because it don't work with tape.

Met vriendelijke groeten/ Kind regards,

Henny Malipaard

RVS IT Services/AMSpecials/DBA
Locatiecode VPT F03.01
Postbus 225, 6710 DA, Ede (gld)
Loevestein 33, 6714 BS, Ede (gld)
T [phone], F [phone]
E [e-mail]

Parttimedag: vrijdagmiddag

Date: Wed, 14 Jun 2006 16:16:26 -0500
From: ""Schwartz, Terry"" <[e-mail]>
Subject: Why Parallel Unload/Reload would have helped.........

Thought I would share some interesting statistics from a=20 situation
where the new Express Unload/Reload would have helped.=20

We added a new area/records that we added to satisfy some Sarbanes Oxley

compliance requirements. This new area grew at a rate no one
anticipated.=20 One fine Wednesday before we can look at the weekly
print space reports, I get a call that this new production area has
filled up=20 and task are taking 1211's all over the place.=20

Since this was our busiest production region we had to act quickly
and=20 ran an expand page and changed the block size from 6516 to
13032.=20 We were only down 18 minutes and the earthquake only measured
2.3=20 on the management scale...

However, before I could get a good weekend to unload/reload the area,
the area fills once again in the middle of a week. (Murphy's law hard at
work) This time I decided an extend space was in order and I added 3
datasets to the=20 area. So now I have an area that has been xpaged and
extended.=20

I expected the I/O to the area to go up because of the space=20
management implications, but the interesting part is the I/O went=20
through the roof! See the real daily I/O to the area below;=20

I/O per day
Before XPAGE 450,000 =20
After XPAGE 902,177 =20
After Extend Space 10,773,437 - yes, over 10 million, this is not a typo

After Unload/Reload 497,783 =20

As you can see when we were able to unload/reload it=20
cut the I/O considerably (understatement!).=20
The good news is the new Express Unload/Reload would=20
have allowed me to unload reload the area in a much smaller time
frame.=20 I could have reorganized the area before it filled the second
time.=20 We are all looking forward to this new SP4 feature.

Regards,
Terry Schwartz
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------


****************************DISCLAIMER***********************************
Deze e-mail is uitsluitend bestemd voor de geadresseerde(n). Verstrekking aan en gebruik door anderen is niet toegestaan. Fortis sluit iedere aansprakelijkheid uit die voortvloeit uit electronische verzending.

This e-mail is intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). Fortis rules out any and every liability resulting from any electronic transmission.
******************************************************************************

"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Why Parallel Unload/Reload would have helped.........
"Terry,

At this time I'm busy (waiting) with a Unload/reload of 2 area's. This
is a big one.
The biggest area contains 865,000,000 recs.
It has a pagesize of 13690 and 2,000,000 pages.
New size is 8904 and 4,000,000 pages.
It takes me 10 days to do it.
I use all the time 2 tapeunits and 130 packs for work.
When i could use the new Utility I think it would cost me 3 days and 600
packs because it don't work with tape.

Met vriendelijke groeten/ Kind regards,

Henny Malipaard

RVS IT Services/AMSpecials/DBA
Locatiecode VPT F03.01
Postbus 225, 6710 DA, Ede (gld)
Loevestein 33, 6714 BS, Ede (gld)
T [phone], F [phone]
E [e-mail]

Parttimedag: vrijdagmiddag

Date: Wed, 14 Jun 2006 16:16:26 -0500
From: ""Schwartz, Terry"" <[e-mail]>
Subject: Why Parallel Unload/Reload would have helped.........

Thought I would share some interesting statistics from a=20 situation
where the new Express Unload/Reload would have helped.=20

We added a new area/records that we added to satisfy some Sarbanes Oxley

compliance requirements. This new area grew at a rate no one
anticipated.=20 One fine Wednesday before we can look at the weekly
print space reports, I get a call that this new production area has
filled up=20 and task are taking 1211's all over the place.=20

Since this was our busiest production region we had to act quickly
and=20 ran an expand page and changed the block size from 6516 to
13032.=20 We were only down 18 minutes and the earthquake only measured
2.3=20 on the management scale...

However, before I could get a good weekend to unload/reload the area,
the area fills once again in the middle of a week. (Murphy's law hard at
work) This time I decided an extend space was in order and I added 3
datasets to the=20 area. So now I have an area that has been xpaged and
extended.=20

I expected the I/O to the area to go up because of the space=20
management implications, but the interesting part is the I/O went=20
through the roof! See the real daily I/O to the area below;=20

I/O per day
Before XPAGE 450,000 =20
After XPAGE 902,177 =20
After Extend Space 10,773,437 - yes, over 10 million, this is not a typo

After Unload/Reload 497,783 =20

As you can see when we were able to unload/reload it=20
cut the I/O considerably (understatement!).=20
The good news is the new Express Unload/Reload would=20
have allowed me to unload reload the area in a much smaller time
frame.=20 I could have reorganized the area before it filled the second
time.=20 We are all looking forward to this new SP4 feature.

Regards,
Terry Schwartz
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------

"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
ADS question
"Hi everyone,

I have what I hope is a very simple question, but I can't find the
answer. In ADS, I need to test to make sure a field does not contain
any special characters. In other words, the 8 bytes field can contain A
thru Z, 0 thru 9, in any combination, but no other character is
permitted. Is there an easy way to test for this ?

Thanks,
Laura Rochon
Ajilon

"
IDMS Public Discussion Forum
[e-mail]
SMTP
[e-mail]
[e-mail]
SMTP








Normal

Normal
Re: ADS question
"I would use VERIFY to test the field. This statement would be true if
it found a character NOT in the string.

IF VER(WK-FIELD,'0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ ') NE 0
THEN
DISPLAY TEXT 'INVALID SPECIFICATION FOR FIELD'.