Does addition of disk require running AUTOGEN

[Chaim Budnick]

At one of our customer sites a new DKA device was added.

Does this in itself require/justify/indicate that AUTOGEN be run?

Chaim

[Kris Clippeleyr · Accepted solution]

Chaim,

No need to run AUTOGEN when a disk is added.

Greetz,

Kris.

[Himanshu_3]

Hi Chaim,

Although autogen is not required to be run after a new device is added but possibly its always better to do following if you are on a cluster and want your systems to identify the new device which has been added

$ MC SYSMAN
SYSMAN> SET ENVIRONMENT/CLUSTER
SYSMAN> IO AUTOCONFIGURE/LOG
SYSMAN> EXIT


If you are haveing Fibre channel you can also put following to assign names
SYSMAN> IO FIND_WWID


Cheers,
HP

[Bojan Nemec]

Chaim,

The number of disks partecipate in the computation of the NPAGEDYN parameter. So autogen is needed only if you are low on nonpaged dynamic memory.

Bojan

[Uwe Zessin]

"SYSMAN> IO FIND_WWID" is required to make the necessary entries to SYS$DEVICES.DAT for fibre channel attached tape devices and their robotics. For disk devices an "IO AUTOCONFIGURE" is sufficient.

[John Gillings]

AUTOGEN counts the number of disks and uses the value in calculating appropriate settings for several parameters, including NPAGEDYN, PAGEDYN and sizing the ACP cache.

Unless your system is running very tight on resources, adding a single disk probably won't make much difference, so you can most likely avoid the inconvenience of a reboot.

Running AUTOGEN is no big deal - you don't have to reboot and use the recommendations (indeed, I would always recommend AGAINST letting AUTOGEN reboot your system). To see how much difference it would make, run AUTOGEN to SETPARAMS:

$ @SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS

and compare the new values with the old:

$ DIFF/PARA SYS$SYSTEM:SETPARAMS.DAT

if you don't like the new values, modify MODPARAMS.DAT to adjust them back to what you want. Make sure you don't leave the system in a state that running AUTOGEN causes surprises!

[Jan van den Ende]

Chaim,

John's is a wise advise!

We take it even one step further:
Each week at a (expected) rather quiet time, we run a batch which essentially does:
$ @AUTOGEN SAVPARAMS TESTFILE
This does all calculations and reporting, without making any modification.
So, we read the reports, and decide if any action is needed.
And because of the regular weekly reports, we also notice any CHANGES in the reports.
THOSE are the ones that best indicate any slipping away from optimal settings, allowing to foresee deviations growing to unacceptable level, and that gives us time for preemptive corrective actions, at a time that suits us.

HTH

Cheers.

Have one on me.

Jan

[Wim Van den Wyngaert]

I would add that each modification reported by autogen must be investigated. A looping program can generate too many processes, too many network connections etc and autogen would increase the parameters based upon this erronious loop.

Wim

[Keith Parris]

> Each week at a (expected) rather quiet
> time, we run a batch which essentially
> does:
> $ @AUTOGEN SAVPARAMS TESTFILE

I'd recommend doing the feedback data data collection:
$ @AUTOGEN SAVPARAMS
during a busy (peak) time if possible. Some of the feedback data AUTOGEN gathers doesn't have peak value data cells available, and only snapshot "in-use" values can be gathered, so it seems to me that the results could be slightly better if one gathers feedback at a peak time.

The remainder of the AUTOGEN calculations can be deferred to a less-busy time:
$ @AUTOGEN GETDATA TESTFILES

[Jan van den Ende]

Thanks for the hint Keith!

I'll make the advised change.
Always prepared to leave a good thing for a better one!

Cheers.

Have one on me.

Jan