Where is queryschedperiod set ?

[ldmwndletsm]

Using Linux (both server and clients).

I see this value is set to 6 hours ("query stat") on the backup server. This jibes with what the scheduler log files report on the nodes. I do not see this value set in the options ("query options") on the server nor do I see it in the server options file nor do I see it in the CLOPTSET ("query cloptset"). Also, the nodes do not specify this in the dsm.sys.

The setting is fine. I don't need to change it, but just wondering how it was set ? If someone ran "set queryschedperiod 6" on the server then is that static and remains in effect between restarts and reboots until someone runs the command again with a different value ? If not, then where is this actually set ?

 

[LED888]

Okay, we issue the "q status" to see what the QUERYSCHEDPERIOD is set to.
If this parameter is not set, then its each client determines its own value for this parameter.
QUERYSCHEDPERIOD default value is 4 for the client.

NOTE: This parameter is valid with the Backup/Archive client with schedmode polling.
The API does not support this option.

With the "set" command the option takes into affect immediately and will not change until some one issue the same command but with a different parameter.

QUERYSCHEDPERIOD is not a parameter that can be manually set in the dsmserv.opt file.
If we update an option in the dsmserv.opt file, then the setting will take into affect until the TSM/SP sever is stop and restarted. For non-valid parameter, there will be an error message when the TSM/SP Server start.

If the QUERYSCHEDPERIOD is not set on the TSM/SP Server.
More than likely someone may have updated the dsm.opt and dsm.sys, but did not stop/restart the schedule service/daemon. You can make changes to the dsm.opt/dsm.sys, but if we do not stop/restart the schedule service/daemon the original settings are still in affect.

If you suspect that someone issue Set QUERYSCH 6, check the actlog.
Hopefully we keep the actlog long enough and hopefully that information is still within the time frame.
If some one issue the command some time ago that information may not be within the actlog.

Good Luck,
Sias

 

[ldmwndletsm]

Thank you, Sias. I cannot search that far back in the activity log, but this setting has been in effect for as long as I've been playing with this product (several years now), and it has remained between restarts of all the systems and reboots. None of the clients, including the backup server, specifies any such setting in its dsm.sys or dsm.opt files, and again, they've all been restarted multiple times over umpteen months. So if I check the dsmsched.log files on all the nodes, I can see that they are checking in with the server for their next scheduled backup every 6 hours, and always have, going all the way back to time immemorial. But I am simply at a loss to explain how this can be if the default is 4, and this setting does not appear to be set anywhere on any machine, including the server. Clearly, the default is being overridden somewhere, so the only explanation that I can come up with is that someone must have run `Set QUERYSCHEDPERIOD 6` on the backup server a long time ago, and it's just remained ever since ?

This brings up a more general question and that is where are the settings, reported by "query stat" actually set, if they are not the default values ? Would they be set by someone manually running a command, and it just lingers until someone resets it ?

 

[marclant]

This brings up a more general question and that is where are the settings, reported by "query stat" actually set, if they are not the default values ?

They are set in the DB. Options set by `SET` are stored in the DB and seen in `QUERY STATUS` and options set by `SETOPT` are stored in dsmserv.opt and seen with `QUERY OPTION`.

 

[lp1167]

Okay, we issue the "q status" to see what the QUERYSCHEDPERIOD is set to.
If this parameter is not set, then its each client determines its own value for this parameter.
QUERYSCHEDPERIOD default value is 4 for the client.

NOTE: This parameter is valid with the Backup/Archive client with schedmode polling.
The API does not support this option.

With the "set" command the option takes into affect immediately and will not change until some one issue the same command but with a different parameter.

QUERYSCHEDPERIOD is not a parameter that can be manually set in the dsmserv.opt file.
If we update an option in the dsmserv.opt file, then the setting will take into affect until the TSM/SP sever is stop and restarted. For non-valid parameter, there will be an error message when the TSM/SP Server start.

If the QUERYSCHEDPERIOD is not set on the TSM/SP Server.
More than likely someone may have updated the dsm.opt and dsm.sys, but did not stop/restart the schedule service/daemon. You can make changes to the dsm.opt/dsm.sys, but if we do not stop/restart the schedule service/daemon the original settings are still in affect.

If you suspect that someone issue Set QUERYSCH 6, check the actlog.
Hopefully we keep the actlog long enough and hopefully that information is still within the time frame.
If some one issue the command some time ago that information may not be within the actlog.

Good Luck,
Sias

Set it to 1 ... incase you update anything, the clients are uptodate