L.Lawliett

Absent Member.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2010-05-09
10:35
433 views
Radia Timer Issues
hi all.
i've got some timer issues. hope u guys can help me out. i've set my "patch timer" to something like DAILY(ZSYSDATE,1230,1300) & "RANDOM" + "DEFERRED". what i like it to do is for clients to connect to RCS everyday ONLY between 1230hrs to 1330hrs to check for new patches. but it seems like every time the machines login or restart, it'll also check for the patches. is there anything i need to edit?
another issue is, i've specify "cop=y" for the radskman command. but it seems like the machines sometimes execute the command without the "cop=y". any ideas?
thks.
i've got some timer issues. hope u guys can help me out. i've set my "patch timer" to something like DAILY(ZSYSDATE,1230,1300) & "RANDOM" + "DEFERRED". what i like it to do is for clients to connect to RCS everyday ONLY between 1230hrs to 1330hrs to check for new patches. but it seems like every time the machines login or restart, it'll also check for the patches. is there anything i need to edit?
another issue is, i've specify "cop=y" for the radskman command. but it seems like the machines sometimes execute the command without the "cop=y". any ideas?
thks.
14 Replies


Absent Member..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2010-05-11
13:00
Hard to say not knowing what version you are on, but...
RE Timer: You need to add a 'dead stop' time: DAILY(ZSYSDATE,1230,1300,####) for PCs that are powered off or busy during the window so they don't kick off when they are powered on.
In regards to PCs that are kicking off patch connects even when they are powered on during that window - double check the ZTIMEQ object in the client's lib folder & event logs to make sure it's actually the timer that is causing it. We had an issue in our environment with qcount heaps (basically a patch connect with a qcount variable in the connect string, not set up by a timer) that were causing repeated patch connects on the clients regardless of timers and it required a client update from support.
RE Cop: Symptoms that make it seem like the clients aren't using cop? Logs?
RE Timer: You need to add a 'dead stop' time: DAILY(ZSYSDATE,1230,1300,####) for PCs that are powered off or busy during the window so they don't kick off when they are powered on.
In regards to PCs that are kicking off patch connects even when they are powered on during that window - double check the ZTIMEQ object in the client's lib folder & event logs to make sure it's actually the timer that is causing it. We had an issue in our environment with qcount heaps (basically a patch connect with a qcount variable in the connect string, not set up by a timer) that were causing repeated patch connects on the clients regardless of timers and it required a client update from support.
RE Cop: Symptoms that make it seem like the clients aren't using cop? Logs?
L.Lawliett

Absent Member.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2010-05-11
14:49
L.Lawliett

Absent Member.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2010-05-11
14:52


Absent Member..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2010-05-11
17:11
Look at the ZTIMEQ object in an affected client's lib folder (and/or upload to share). This will show you what connects are being scheduled and possibly what is scheduling them.
L.Lawliett

Absent Member.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2010-05-12
14:14
Grant Morgan

Absent Member.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2010-06-04
02:21
In COP there is a setting to control whether or not you want HPCA to run in place of a login script. I'm sorry i don't remember the exactly Class or property name.
Also in the Timer properties there is a setting to control whether or not to execute if the last scheduled time was missed.
Hope this helps a little.
Also in the Timer properties there is a setting to control whether or not to execute if the last scheduled time was missed.
Hope this helps a little.
Grant Morgan

Absent Member.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2010-06-06
14:53
I had a chance to get those properties...
In Client\Settings
LSCRIPT=Y
This will disable HPCA from running after user login. Some HPCA installs will still cause a login run to occur.
(Looks like you already had this one)
In Software\Timer
Change yoru timer property ZSCHTYPE to DEFFERRED.
I'm not sure if this helps, but something to check.
Also you might want to check the script that is setup as EXBEXIT in Client\Settings.
In our old enviroment, when we used patch manager - a Software connect took place and then Patch mgmt connect - if software required a reboot then the EXBEXIT script would populate ZTIMEQ with a "ONCE"/"STARTUP" timer.
I'm not sure if this one would work at all but on your timer instance, you can try adding userfreq=23,machfreq=23. So that it doesn't run the connect if it has run within the last 23 hours. I'm not sure if this is passed to the Startup timer, but may be worth a try.
In Client\Settings
LSCRIPT=Y
This will disable HPCA from running after user login. Some HPCA installs will still cause a login run to occur.
(Looks like you already had this one)
In Software\Timer
Change yoru timer property ZSCHTYPE to DEFFERRED.
I'm not sure if this helps, but something to check.
Also you might want to check the script that is setup as EXBEXIT in Client\Settings.
In our old enviroment, when we used patch manager - a Software connect took place and then Patch mgmt connect - if software required a reboot then the EXBEXIT script would populate ZTIMEQ with a "ONCE"/"STARTUP" timer.
I'm not sure if this one would work at all but on your timer instance, you can try adding userfreq=23,machfreq=23. So that it doesn't run the connect if it has run within the last 23 hours. I'm not sure if this is passed to the Startup timer, but may be worth a try.
L.Lawliett

Absent Member.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2010-06-06
16:01
thks for the advice.
Justin Lipple

Absent Member.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2010-07-28
07:57
@jloxton
Hi jloxton, was just wondering which patch(es) you applied to your clients to fix the "issue in our environment with qcount heaps (basically a patch connect with a qcount variable in the connect string, not set up by a timer)" - as we have the same problem.
Any info would be most appriciated!
Cheers,
Justin
Hi jloxton, was just wondering which patch(es) you applied to your clients to fix the "issue in our environment with qcount heaps (basically a patch connect with a qcount variable in the connect string, not set up by a timer)" - as we have the same problem.
Any info would be most appriciated!
Cheers,
Justin
DanieI

Micro Focus Expert
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2010-07-28
13:34
Hi Justin,
Please confirm the version you are running.
Please confirm the version you are running.
Justin Lipple

Absent Member.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2010-07-29
00:31