The end user-impact is minor, but the catalog like any VSAM dataset with
IMBED/REPLICATE takes up slightly more space than it would otherwise, as
the replicated index CI requires one track in each DATA space CA and
reduces the amount of usable space per DATA CA (especially significant
if the CA is less than 1 cylinder). The redundant replicated INDEX CI's
in that track no doubt "wastes" some cache in the DASD subsystem when
the dataset is processed, and there would be additional overhead in
maintaining the replicated INDEX CI's when changed.
Before massive DASD subsystem cache and smart DASD subsystems,
IMBED/REPLICATE improved speed of DASD access by eliminating a physical
seek and the rotational delay to read the INDEX CI associated with a
DATA CA. Now it actually degrades performance slightly since the
physical read of a CA contains fewer useful CI's and a highly used INDEX
CI would already be in DASD cache or cached in the application address
space (the CATALOG address space in the case of MVS catalogs).
Note that removing these attributes is not just a matter of rebuilding
the INDEX component but requires a complete reorganizing of the dataset
to rebuild both DATA and INDEX components, as IMBED/REPLICATE causes
INDEX sequence set CIs to be stored inside each DATA component CA.
Joel C EWing
On 07/16/2013 08:17 PM, Mike Schwab wrote:
> Here is an idea. Add to IDCAMS ALTER parameter REBUILDINDEX.
> Creates a new index component for an existing dataset (in case of an
> index error, reorg just the index, or getting rid of the IMBED /
> REPLICATE index).
> Leaves the old index for backup. Would not be good after an update.
>
> Add to IDCAMS ALTER parameter DELOLDINDEX.
> Deletes old index component for an existing dataset left by REBUILDINDEX.
> Reformats IMBEDED INDEXES tracks as empty DATA control intervals.
> Resets RBAs in all records to reflect bigger CAs (IMBED REPLICATE
> would be 1 track per cylinder, IMBED REPLICATE might be smaller).
>
> On Tue, Jul 16, 2013 at 5:37 PM, Skip Robinson <[email protected]>
> wrote:
>> AFAIK customer retention of obsolete attributes is mostly IBM's problem,
>> not the customer's. They stopped honoring those attributes on new
>> allocations years ago, but as long any customers retain them, DFP code
>> still has to account for them. That means additional regression testing
>> for pretty much nothing. I sympathize with the change team, but I don't
>> think there's an end user performance hit.
>>
>> .
>> .
>> JO.Skip Robinson
>> Southern California Edison Company
>> Electric Dragon Team Paddler
>> SHARE MVS Program Co-Manager
>> 626-302-7535 Office
>> 323-715-0595 Mobile
>> [email protected]
>>
>>
>>
>> From: Mike Schwab <[email protected]>
>> To: [email protected],
>> Date: 07/16/2013 02:48 PM
>> Subject: Re: Old usercatalogs with IMBED and REPLICATE
>> Sent by: IBM Mainframe Discussion List <[email protected]>
>>
>>
>>
>> Another option would be to move various Aliases (HLQs) to new
>> usercatalogs. Perhaps splitting them into more, smaller user
>> catalogs.
>>
>> On Tue, Jul 16, 2013 at 2:26 PM, John McKown
>> <[email protected]> wrote:
>>> OK, OK, all ya'all have worn me out! <grin/> I scan to see how many
>> catalog
>>> I'm talking about and which ones they are. Then mention it to my boss.
>>> Upper IT management basically won't care, so long as nothing goes wrong.
>>> <more redacted>
>
--
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
