You mentioned that these problem SVTs were deleted but still keep attaching to Incidents. That suggests that the zSLMGen:<SLMID>_MeasReqAssoc`! filter for these SVTs were not removed. The slmbrsvc process is responsible for deleting the association and milestone filters when you delete an SVT.
As a quick-fix to prevent these SVTs from causing your further grief, once you know the SLMID number, you could delete or disable the related zSLMGen:<SLMID>_MeasReqAssoc`! filter in Dev Studio. When you submit an application ticket, it is these _MeasReqAssoc`! filters that create the SLM:Measurement in "Attached" status. Once you prevent this from happening (and it cannot happen if there is no association filter), that SVT will never be related to an Incident.
For those that are already related to Incident (assuming you really don't want them), you can delete the SLM:Measurement record. This won't cause any problems for the Incident. The link to the measurement is on the SLM:Measurement record itself (the 'ApplicationInstanceId' field on SLM:Measurement record holds the 'instanceId' (fieldid 179) of the related Incident) rather than on the Incident so once you delete the SLM:Measurement record it will simply no longer show up as related to the Incident. If there are any Milestone, Missed Goal, Warning events in SLM:EventSchedule for this measurement, those will be deleted too.
Dan, you mentioned that you hit ARERR 302 errors when building the SVTs. That suggests that there might be more than one slmbrsvc process attempting to action the Application Pending records to rebuild the SVTs. The slmbrsvc should only be active on the AR Server instance where Admin Operations are enabled. It is also important that the 'Server-Connect-Name:' parameter is present on this box and references its hostname so that slmbrsvc connects only to that AR instance. slmbrsvc on all other instances in the server group should be suspended. If you see 302 errors in the build-messages on the Admin tab on an SVT I cannot think of any other possibility.
For item 2 we would probably need more detail on the milestone's 'Execute When*' value. If this is 'When Start Condition occurs'... this can be quite open (i.e. 'Status' >= "New" perhaps) and so anytime the SVT is evaluated and that condition is true, the Milestone would fire. If this is the cause of the problem, perhaps using the 'Custom Qualification' Execute When* option might allow you to better qualify the 'Execute If*' qualification so that it is more in keeping with what is required.
Dan, the third item seems to have been truncated.
Anyway, I hope some of the above proves useful.
and thank you very much for your help! i will go digging in the SVT tables.
I will also check that slmbrsvc demon for SLM, which i know for sure i have not disabled on any server. I currently have 2 servers, one dedicated to admin functions, and one is server group member 1, of a single server SG. this is because i am going to add a second member soon (there used to be 2 before we did a full rebuild of the system last November)
The 3rd issue did indeed get truncated, not sure how…. Maybe it got cut on arslist where I also post this J
3. I have a 3rd problem (that BMC said that there is a known defect for) however they are not releasing a fix until the next major version (not even in a service pack). When you add an agreement-owner in SLM admin, you configure an email address (or multiple) inside the configuration of the agreement-owner. I then assign that agreement owner to a whole pile of Milestones, inside a whole bunch of SVTs. I then want to go back and change that agreement-owner due to a management reorg within the business. However, changing the email address within the agreement-owner does not actually work.
BMC suppot said they know about it but they do not have a fix yet. The only option is to add a new agreement owner, delete the original one and then go into each milestone action and change the agreement owner in there (this is a lot of work when you have 300 SVTs, each with around 15 milestone actions).
I am hoping that someone has an idea what tables under the hood might be able to be manually hacked to get the new email addresses in without having to go through this horrible piece of work…
Thank you again for your help
Item 3... Is the problem on the SLM:ConfigSLAOwners form where when you modify the Members* field values that this seems to have no effect?
If so, are you using the 'Save' button on the form itself (the one under the 'Expiration Message' - next to the 'Clear' button)?
There is a not-in-view field on this form called 'SLA_Owners_Name List Real' which some active links on the form's 'Save' button populates from the Members* field so that the names/addresses are separated by newline characters (i.e. one on each line). If you resave the record but not using this 'Save' button on the form itself, this 'SLA_Owners_Name List Real' field will not be updated (the Active Links will not run) and I suspect that might be the problem here.
So if we're talking about the same thing here, run a report on this form and check the contents of this not-in-view field for the relevant record(s). Then make your update to the Members* field... and save it using the 'Save' button and confirm you wish to overwrite the record. Then recheck the 'SLA_Owners_Name List Real'. It then should be updated. If it is I believe things will work as expected.
If I off-track here - please let me know the defect number and we can check further.
Tony here (I am working with Dan on these issues)
For issue 3. You are spot on with the 'SLA _Owners_Name List Real' field. However the problem is that the Save button you mention can only be selected when you initially complete a new Owner. When you try to amend an exsisting Owner it is greyed out.
I was thinking of two options -
1 - make the field visible and manually update it.
2 - do an export, change the 'Real' field in notepad, then reimport with the option to Update exsisting records with new data.
But both of these would only work if the only thing we need to do is complete that field with the data in the correct format (we can get the correct format by creating a new one and then copying to the old)
Any idea if that would work?
Thanks again by the way, you def know your SLM.
Ah yes - I see what you mean about the button being disabled in 7604sp1/2 :-)
Either option you suggested would work fine, I'm sure.
However, you could simply disable the active link "SLM:ConfigSLAOwners:OnCreateEnableSave" which would give you back the original functionality. Then you will be able to modify records as in previous versions.
Disbaled that active link and it works a treat. Made the "Real" field visible as well so we can check as we change them. Makes you wonder why someone went to the trouble of disabling it.
Thanks a million for that as it has saved us the awful job of manually changing 1000+ milestones.
We will get to work on the other two issues tomorrow.
as a final follow up on this, can you please give me some help on how to disable the slmbrsvc process on a remedy app server?
we currently have 2 server groups (soon to be 3). server 1 is a standalone server not in a remedy SG, used as an admin server. server 2 is a SG configured server holding ALL SG rankings, and is the only server in the SG at the present movement. there will be a second one soon
you mentioned we need to ensure that above process only should run on one server in a remedy application stack, can you tell me how to disable it when one server is not in the SG, so rankings do not take effect on it?
cheers again for all your help on this
Normally, if all servers were in the server group, it would just be a question of setting the rankings so that slmbrsvc was active on the same AR instance where Admin operations are enabled. It is important that slmbrsvc moves with Admin operations within a server group since its only role is to delete or create filters (Data Source, Service Target, Milestone etc. filters) and it can only do this on the AR instance where Admin operations are enabled.
Now, if you have a separate AR Server which is outside of the server group, it might be best to comment out the slmbrsvc.exe line in the armonitor.cfg/conf file on all servers in the server group. slmbrsvc.exe would run only on the Admin server (the one not in the server group in your scenario).
Since slmbrsvc.exe only comes into play when you need to rebuild SVTs or Data Sources it is not critical that it is running for 'normal operation'. It has no role in measurement calculations, compliance calculations or Milestone notifications. Some customers comment it out in armonitor.cfg/conf on all servers and simply start it manually on the Admin server when they wish to perform some SLM administration activity (build/rebuild SVTs etc.).
Anyway, I hope some of this helps!