Cannot start schedule on client?

ldmwndletsm

ADSM.ORG Senior Member
Joined
Oct 30, 2019
Messages
232
Reaction score
5
Points
0
PREDATAR Control23

We've been using schedmode Polling on a Linux client. This client uses two stanzas (two nodes, two .opt files) and two dsmcad processes. Each schedule has been running once each night, as set on the server, all fine and well.

However, I wanted to do some testing that required changing the start time for one of the client schedules wherein I wanted to run it as soon as possible. There were no sessions running, and no tape drives were busy. But every time I change it (10 minutes from now, 30 minutes, 1 hour), the activity log reports that the client missed its startup window, and the backup never runs. I even stopped the dsmcad processes, changed the schedmode to Prompted, and restarted. Still no luck. For testing, I want to limit the wait time as much as possible.

Can somebody tell me if the 'Query Schedule Period' is causing the mischief? I did not set the values defined on the server, so if those have to remain as is then is there something that I can do on the client side to resolve this?

[ Here's what the server reports for `q status` ]

Schedule Randomization Percentage: 25
Query Schedule Period: 6 Hour(s)
Maximum Command Retries: Client
Retry Period: Client
Scheduling Modes: Any

[ The schedule on the server has been thus ]

Action: Incremental
Priority: 1
Start Date/Time: 03/27/2020 22:40:00
Duration: 1 Minute(s)
Maximum Run Time (Minutes): 0
Schedule Style: Classic
Period: 1 Day(s)
Day of Week: Any

[ The stanza in the dsm.sys file has these values ]

PASSWordaccess Generate
MANAGEDServices schedule
SCHEDMode prompted (was polling before I changed it)
queryschedperiod 1
 
PREDATAR Control23

So prompted is what you want, that the TSM server saying run now.

I think having the duration of being only 1 minute is an issue. Per the help for def schedule:
DURUnits Specifies the time units used to determine the duration of the window in which the schedule can start. This parameter is optional. The default is HOURS. Use this parameter with the DURATION parameter to specify how long the startup window remains open to process the schedule. For example, if DURATION=20 and DURUNITS=MINUTES, the schedule must be started within 20 minutes of the start date and start time. The schedule may not necessarily complete processing within this window. If the schedule needs to be retried for any reason, the retry attempts must begin before the startup window elapses, or the operation does not restart. The default value for the length of the startup window is 1 hour.
My thought is you are not giving the system enough time to be told what to do.

The schedule randomization value is only for polling schedules. See 'help set randomize'.
 
PREDATAR Control23

Okay, I'll try increasing that to something more reasonable and retry the Prompted method. I originally had that value set to at least one hour sometime back, with a priority of 5. I changed it only to try to expedite the testing due to another problem we were having at that time, and I didn't want to wait an hour or more for results. I just never changed it back. According to the activity log, the schedule was successfully running each night (while using Polling mode), it just isn't happy when I change it on the fly, which seems puzzling. I could see it being finicky if I set it to start in only a few minutes, though.

BTW: Regarding polling, if you are using Polling mode, do you know if the 'Query Schedule Period: 6 Hour(s)' defined on the server, forces the client to only be able to check every 6 hours?

For example, if the schedule was set to 10 PM, and at 11 AM, I change the schedule to noon, but the client last checked at 10 AM, then 6 hours later would be 4 PM. So does that mean that the client won't be updated with the change until 4 PM, in which case, it will have missed its startup window and thus won't run the noon backup until the following day? From what I could see on the documentation on this option, it looks to override anything the client has set, at least as far as Polling is concerned.
 
PREDATAR Control23

For example, if the schedule was set to 10 PM, and at 11 AM, I change the schedule to noon, but the client last checked at 10 AM, then 6 hours later would be 4 PM. So does that mean that the client won't be updated with the change until 4 PM, in which case, it will have missed its startup window and thus won't run the noon backup until the following day?

Yes, that is my experience. I generally stick to prompted for most of my clients.
So I could be wrong here, but what I see on the few clients that I have set up to poll is this:
Code:
03/29/2020 22:30:02 Sending results for scheduled event 'FS_DAILY_INC_2200'.
03/29/2020 22:30:03 Results sent to server for scheduled event 'FS_DAILY_INC_2200'.

03/29/2020 22:30:03 TSM Backup-Archive Client Version 7, Release 1, Level 8.3
03/29/2020 22:30:03 Querying server for next scheduled event.
03/29/2020 22:30:03 Node Name: <server name>
03/29/2020 22:30:03 Session established with server <TSM server name>: AIX
03/29/2020 22:30:03   Server Version 8, Release 1, Level 9.100
03/29/2020 22:30:03   Server date/time: 03/29/2020 22:30:03  Last access: 03/29/2020 22:08:24

03/29/2020 22:30:03 --- SCHEDULEREC QUERY BEGIN
03/29/2020 22:30:03 --- SCHEDULEREC QUERY END
03/29/2020 22:30:03 Next operation scheduled:
03/29/2020 22:30:03 ------------------------------------------------------------
03/29/2020 22:30:03 Schedule Name:         FS_DAILY_INC_2200
03/29/2020 22:30:03 Action:                Incremental
03/29/2020 22:30:03 Objects:               
03/29/2020 22:30:03 Options:               
03/29/2020 22:30:03 Server Window Start:   22:00:00 on 03/30/2020
03/29/2020 22:30:03 ------------------------------------------------------------
03/29/2020 22:30:03 Schedule will be refreshed in 4 hours.
03/30/2020 02:30:03 TSM Backup-Archive Client Version 7, Release 1, Level 8.3
03/30/2020 02:30:03 Querying server for next scheduled event.
03/30/2020 02:30:03 Node Name: <server name>
03/30/2020 02:30:03 Session established with server <TSM server name>: AIX
03/30/2020 02:30:03   Server Version 8, Release 1, Level 9.100
03/30/2020 02:30:03   Server date/time: 03/30/2020 02:30:03  Last access: 03/29/2020 22:30:03

03/30/2020 02:30:03 --- SCHEDULEREC QUERY BEGIN
03/30/2020 02:30:03 --- SCHEDULEREC QUERY END
03/30/2020 02:30:03 Next operation scheduled:
03/30/2020 02:30:03 ------------------------------------------------------------
03/30/2020 02:30:03 Schedule Name:         FS_DAILY_INC_2200
03/30/2020 02:30:03 Action:                Incremental
03/30/2020 02:30:03 Objects:               
03/30/2020 02:30:03 Options:               
03/30/2020 02:30:03 Server Window Start:   22:00:00 on 03/30/2020
03/30/2020 02:30:03 ------------------------------------------------------------
03/30/2020 02:30:03 Schedule will be refreshed in 4 hours.


To override the server schedule period you would need to add QUERYSCHEDPERIOD to the dsm.opt or dsm.sys file. This supports a value of 1-9999 I think. That is in hours, not minutes. https://www.ibm.com/support/knowled...m.itsm.client.doc/r_opt_queryschedperiod.html

I think you also need to set these options as well if they are not set:
Query Schedule Period: Client
Maximum Command Retries: Client
Retry Period: Client
You can see the current settings from a 'q st'
And another document! https://www.ibm.com/support/knowledgecenter/en/SSEQVQ_8.1.9/srv.reference/r_cmd_status_query.html
Also may be worth while to verify 'Scheduling Modes: Any' is set as well.

I am not sure what the default polling interval is however.
Hope this helps a bit.
 
PREDATAR Control23

Thanks for that info. :cool: We do have those last two values set to client, but the first one is still set to 6 hours. We do have 'Scheduling Modes: Any'. I am not able to change the Query Schedule Period at this time, though.

The IBM document link does say: "Query Schedule Period Specifies the frequency with which clients poll the server to obtain scheduled work, in client-polling mode. If the value in this field is Client, the polling frequency is determined by the client node."

To me, this means that the client is at the mercy of that value, assuming it's using Polling mode.

But the strange thing is that earlier today, around 13:18 (EDT), we changed it back to Polling mode and then increased the client schedule Duration as you suggested. We changed it from from 1 minute to 1 hour and then we changed the start time to be 13:25 (EDT). Soon after making those changes, the schedule did run!

Now, I'm wondering how that could have happened when the Query Schedule Period is still set to 6 hours on the server? Unless, maybe it was just luck that it happened to all choreograph in close proximity?
I wonder if we change the schedule again to, say, 20 minutes past the current time, if it will still work, or if that darn 6 hour query schedule period will lock us out for another 6 hours. I'll retest and report back.
 
PREDATAR Control23

I'm honestly not sure if you must change the query schedule period. its been a while since I messed with any of that. And I agree with your assessment of the client being at the mercy of that value. It could be overridden on a client by client basis with the client option? Sorry, my environment is setup a little differently than yours :)

I would think an order of operations plays a key part here. Did you change the schedule on the tsm server first before updating the client? Assuming the client schedule service/systemd unit was cycled it would have picked up the change. Actually, there is a small delay when the service is started before it checks in with the tsm server. So you could have updated and refreshed the client, then gone off to the server made a change, and THEN the client decided to check in.

No matter what, when the client is stopped and restarted it checks in with the server. Makes sure that it can talk to the server, that its password is valid and if not exits. It also queries its upcoming events as well. Likely a few other things as well. So my theory is, it checked in, seen that its next start time would be x, and goes OK I'm ready to run! That time came about and off to the races!

Actlog and client logs would help track down what happened :)
 
PREDATAR Control23

Thank you, RecoveryOne! Okay, so here's what I was able to confirm and test (we are using Polling on the client):

1. First, I checked the dsmsched log on the client, going back several days, and what I noticed -- I guess this is no surprise -- is that once every 6 hours, there are entries pertaining to the schedule, e.g.:

03/30/2020 19:52:45 Scheduler has been started by Dsmcad.
--------------blah-blah-blah---------------
03/30/2020 19:52:46 Server Window Start: 22:40:00 on 03/30/2020
03/30/2020 19:52:46 ------------------------------------------------------------
03/30/2020 19:52:46 Scheduler has been stopped.

So this is consistent with the Query Schedule Period being set to 6 hours on the server.

2. On the server, I changed the start time on the schedule to 17:00. I did this around 16:30, so this gave me enough time to make the subsequent changes to the systemd dsmcad unit file (step 3 below) on the client that I've been wanting to test.

3. On the client, I then stopped the dsmcad process (using systemd here), edited the unit file and made my changes, ran `systemctl daemon-reload` , and then `systemctl restart service_name` and then I ran `/bin/systemctl show service_name` to confirm the settings.

4. I then checked the client log file again, and there were entries in there for the Scheduler being started by Dsmcad (from 3 above) and then stopped.

I then waited a little while, and around 17:07, there was another set of entries for the scheduler, and information about files being backed up. I checked the client sessions on the server, and the client was running, and the activity log reported the successful start and completion for the schedule. Yay!

So from what I can see, it looks like the Query Schedule Period simply dictates how often the client will check in with the server. And based on what I read in the IBM document link, this would override any setting on the client that might try to poll more frequently. However, as you correctly noted, that doesn't have to lock you in. All you have to do is stop/restart dsmcad, and it will then check back in with the server.

So I guess that's the trick, if you're using Polling, and you make a change to the schedule starttime, and you don't want to have to wait until the next Query Schedule Period. Okay, maybe not a trick, but it wasn't obvious to me until now. Prior, I didn't know about the Query Schedule Period, let alone how it worked. I just thought I could change (carte blanche) the schedule time, and it would work, so it was very puzzling when it didn't. Moreover, as you noted, having that duration at such a low number (1 minute) was creating mischief as well.

Thanks again :)
 
PREDATAR Control23

Glad you were able to get it working. Happy to know I wasn't too far off in the weeds!

So from what I can see, it looks like the Query Schedule Period simply dictates how often the client will check in with the server. And based on what I read in the IBM document link, this would override any setting on the client that might try to poll more frequently.
I would think that the client setting of queryschedperiod would override the the setting pass down by the server, unless the server is doing a force? Perhaps one of the more knowledgeable TSM people can weigh in on that :)

So I guess that's the trick, if you're using Polling, and you make a change to the schedule starttime, and you don't want to have to wait until the next Query Schedule Period. Okay, maybe not a trick, but it wasn't obvious to me until now. Prior, I didn't know about the Query Schedule Period, let alone how it worked. I just thought I could change (carte blanche) the schedule time, and it would work, so it was very puzzling when it didn't. Moreover, as you noted, having that duration at such a low number (1 minute) was creating mischief as well.
TSM has for lack of a better term, many tricks to get it what you want it to do. I'll admit, some of them are fairly archaic. And yeah, any change to the dsm.opt or dsm.sys for the clients (polling or otherwise) its best to restart the client scheduler service. And when it comes to polling, you are spot on. Best way to think of it, your family said to meet them at 4. But they decided to get together at 2, and then wondered where you were without telling you of the change.
 
PREDATAR Control23

For the most parts, schedules are not updated frequently, so checking for schedules every 6 hours or less is perfectly acceptable.

However, if there's a business requirement to frequently update a schedule for a specific client, such as it's dependent on another activity to finish, there are a few ways to accommodate that:
- use a preschedulecmd (pre schedule command) to run the other activity if it's on the same machine, the backup will start right after
- use prompted if the schedule is updated frequently so that it's never missed
- use a lower queryschedperiod to reduce the likelihood to miss a schedule
 
Top