ABS_CATLG_00001 process

[Guenther Froehlin · Accepted solution]

Hold on! This catalog is of type DISKS. There's only very minimal amount of data produced in the staging file. Not worth to even have staging enabled. Turn it off with:

$ MDMS SET CATALOG SRAY_CATALOG/NOSTAGING

It should not even allow staging for a DISK type catalog. That should be changed...but not by me anymore.

The ABS_CATLG_nnnn processes are created (with $CREPRC) at the end of the save operation by the ABS coordinator process and not through MDMS' scheduling feature.

One of the SAVE logfiles should contain the log for creating ABS_CATLG_00001. Maybe this is not for a SAVE using CATALOG SRAY_CATALOG?

Use SDA SHOW PROCESS/CHANNEL on this process and look for a .DAT and .LOG file it has open. It may give more information on what this process is doing.

You cannot have a SAVE/ARCHIVE without a CATALOG. In case of catalog type DISKS only the save set information is stored in the catalog...no individual infromation of files saved. This catalog type produces very small catalog files.

/Guenther

[Guenther Froehlin]

This is how the staging info looks in a SAVE log:

00:22:15 COORD: Staging process PID : 20403E01
00:22:15 COORD: Staging catalog : ABS$CATALOG:1MONTH_99_1.STG;1
00:22:15 COORD: Staging procedure : ABS$CATALOG:1MONTH_99_1_1.COM;1
00:22:15 COORD: Staging logfile : ABS$LOG:1MONTH_99_1.LOG
00:22:31 THREAD #1: Normal successful completion

You get the PID of the process and not the name. Sorry my memory has fainted a bit on ABS...

/Guenther

[Trace Trembath]

Thank you Guenther.

I've searched all of my ABS log files and I don't see any of them that have a reference to abs_catlg. I do see in the save request log files where the staging process is kicked off though.

What confuses me most is what this abs_catlg_0000n process is doing for hours at at time. If I'm using a catalog of type disks, then shouldn't any catlog processing take mere seconds/minutes to complete?

The abs_catlg process appears to be happening on Sunday mornings, so I will watch for it then and see what SDA can tell me if I can catch it running.

Thanks.

Regards,
Trace

[Trace Trembath]

I think I might have found something. I do have one save request that runs on Sunday mornings. It's call drp_backup and it uses the default ABS catalog. It only backs up the system/ABS and a secondary system disks.

$mdms show catalog/full abs_catalog

Catalog Name: ABS_CATALOG
Catalog Node: SRAY7
Access Control: NONE
Directory: ABS$ROOT:[CATALOG]
Last Cleaned: 02-OCT-2007 12:30:01
Owner: ABS
Staging : YES
Type: FILES

This must be kicking off the abs_catlg process. However, the log files for the staging process only take a few minutes to complete.

I'm sure I'm getting close now. Thanks Guenther!

Regards,
Trace

[Robert_Boyd]

Trace,

The ABS_LOCAL directory and all of its contents are things that I set up. It does not come standard with the ABS install.

I found that I wanted to put a number of ABS related command procedures such as login, environment prologue and epilogue procedures, monthly catalog tuning procedures, etc ... all in one place but NOT in the standard ABS directories. That way I can easily maintain my own procedures without worrying that an ABS software update will stomp on them.

If you want to know more about the procedures that I use to do maintenance on ABS, let me know.

Cheers,
Robert

[Robert_Boyd]

Trace,

I'm using ABS V4.4(901). The help text on catalog configuration claims that STAGING is not even used on DISK type catalogs since no information about individual files is stored in these catalogs.

You might want to go through all of your catalogs and look at the settings to make sure that they are all the types you think they are(or not).

Also, have you ever done any tuning of your catalogs? If not, you could be having excessive IO activity because they need to be tuned.

This is an area that I've never been impressed with the out of the box tools they give you with ABS. If you want assistance with attempting a tune-up of all your catalogs I can try to help out with some DCL that you could adapt to your environment.

Robert

[Trace Trembath]

Hi Robert,

I think my problem is that I have 1 save request that's still using the default catalog of abs_catalog, which is of type files. I think I can either tune the abs_catalog catalog, or switch that backup to use my sray_catalog catalogk, which is of type disk.

I'd be interested in your tuning procedures if you don't mind sending them to me at trace.trembath@shell.com

Thanks!

Regards,
Trace

[Guenther Froehlin]

If this ABS_CATLG_nnn process runs for 24 hours and still shows activity then I would expect a bug somewhere.

If you don't want to do specific file restores for these disks then it should use a DISKS type catalog. Otherwise I would assign the SAVE/ARCHIVE to a newly created FILES type catalog.

I've seen a couple of cases where the default ABS catalog files were 50GB+ in size without a CONVERT done for a long time. That has some performance impact on inserts but also on the ABS Catalog Cleanup job.

I always setup our devo cluster SAVEs with individual ARCHIVEs and catalogs - all starting with the same name for easy recognition.

That makes the catalogs (size) more manageable for regular CONVERTs and the catalog cleanup runs faster. I did no other tuning because catalog performance was acceptable with this setup.

/Guenther