There is a small performance hit on current DASD with keeping the
obsolete IMBED REPLICATE structures , as John Eells has already implied
by use of "significant" in his statement that there is "no SIGNIFICANT
performance or space advantage". The consensus in shops requiring 24x7
availability is the small, "no significant impact" is much preferred to
any outage or risk required to reorganize a catalog.
Now if you have any IMBED REPLICATE catalogs defined with
sub-cylinder-sized CA's, which would probably be unusual, then that
could increase the hit: a catalog defined with a CA size of 3 tracks
would be throwing away 1/3 of its space on useless replicated INDEX CI
overhead, and a much higher percentage of its physical reads and writes
would be for redundant data. But that would be unusual, as typically
CYLINDER allocation was used for even small catalogs, which assured a
15-track CA size, precisely because even with old DASD that gave the
maximum benefit from IMBED REPLICATE at the minimum overhead cost.
If you are not constrained by 24x7 requirements, or have to take an
outage to move or resize a catalog anyway, then getting rid of the
obsolete structures at the same time is goodness. We always went to a
new master catalog with a new release of z/OS, so for us only the
USERCATs were an issue, and over a period of years we eventually had to
resize or move all of them and took care of the issue at that point for
each.
JC Ewing
On 07/20/2013 06:17 AM, Shameem .K .Shoukath wrote:
> hi John,
>
> The Health checker points these parms as a performance affecting parms.
> Also IGGHC104E in MVS System
> Messages Vol 9 for z/OS .13 Says
> The
> IMBED and REPLICATE attributes were intended as performance improvements but
> have proven to be otherwise. They have proven
> towaste
> DASD space and degrade performance. They have been obsoleted by the
> newer, cached DASD devices. In some cases, unplanned
> outages have
> occured. No supported release of z/OS allows you to define a user catalog
> or master catalog with either the IMBED or
> REPLICATE attributes.
> IBM intends to drop support for these attributes in the
> future.
> in our shop we have many catalogs (defined a long time back) has these parms
> coded and Health checker warns about this.
>
> Are you suggesting this parms has no performance implication? as documented
> in IGGHC104E message
>
>
>
> ________________________________
>
> Thanks and Regards
> Shameem K Shoukath
>
>
>
>
>
>> ________________________________
>> From: John Eells <[email protected]>
>> To: [email protected]
>> Sent: Wednesday, July 17, 2013 6:01 PM
>> Subject: Re: Old usercatalogs with IMBED and REPLICATE
>>
>>
>> Richard Marchant wrote:
>>> Before you install Z/OS 1.13 do you need to remove the IMBED and REPLICATE
>>> parameters from your old Usercatalogs or will they co-exist with Z/OS
>>> 1.13? We are currently running Z/OS 1.11 and a number of the Usercatalogs
>>> have the IMBED parameter with no obvious ill affect.
>>
>> As others have said, "No." You need not do anything. There are no
>> current plans for removing this support, either.
>>
>> Also, I am reliably told that there is no significant performance or
>> space advantage to be had that justifies making a catalog unavailable
>> solely for the purpose of removing these attributes.
>>
>> --
>> John Eells
>> z/OS Technical Marketing
>> IBM Poughkeepsie
>> [email protected]
>>
...
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
