I have been doing a little more research now that I am on a full blown
computer.  I found a reference to business time changes in the 7.5 what's
new doc but still haven't nailed down if that is when Business Time 2.0
commands were introduced (I am pretty sure it is though).

>From the 8.0 docs
<https://docs.bmc.com/docs/display/public/ars8000/Business+Time+introduction>
:
*Note*

If you used the Business Time Holidays and Business Time Workdays forms in
prior releases, you can still use them to define holidays and workdays with
the old set of Business Time commands. However, in Business Time 2.0, all
activities (including holidays and workdays) are defined in the Business
Time Segment form, and you must use a new set of commands to work with the
time segments defined in that form. The "offset" that was previously
available in the Business Time Workdays form is now available in the
Business Time Segment form. The Business Time 2.0 commands provide the same
functionality as the old Business Time commands (Add, Subtract, and Diff);
however, *all future enhancements will be made to Business Time 2.0 only*.

I don't think this is necessarily what is happening here since they have
been on 7.5 for a long time.  But it is a gentle reminder for us with older
defs to take a look and maybe start looking at using BT 2.0.

Jason


On Wed, Dec 3, 2014 at 8:39 AM, Rick Westbrock <[email protected]>
wrote:

> **
>
> They changed the business time process again in 7.5? I remember having to
> modify workflow to account for a business time change when upgrading from
> 4.x to 5.1.2 way back when.
>
>
>
> -Rick
>
>
>
> *From:* Action Request System discussion list(ARSList) [mailto:
> [email protected]] *On Behalf Of *Jason Miller
> *Sent:* Wednesday, December 03, 2014 8:19 AM
> *To:* [email protected]
> *Subject:* Re: Filters actions are firing wierd or correctly ..
>
>
>
> **
>
> What jumped out at me after reading LJ's response is pushing back the the
> next run by 1 minute. Has the record count in the table built up over the
> years and now it takes more than a minute to execute this process? Maybe a
> large record count in combination with a recent change (not necessarily
> related to the paging process) has lengthened the time it takes for this
> process to run over a minute? These are the kind of variables that come to
> mind when a problem just pops up out of nowhere. This and making sure your
> business time calendars have not expired.
>
> I don't remember what version but I think it was around 7.5 where the old
> business time process was replaced with a newer one (from memory business
> time 2). They both still worked in parallel but maybe you have hit the end
> of life of the old business time process?
>
> Jason
>
> On Dec 3, 2014 7:40 AM, "LJ LongWing" <[email protected]> wrote:
>
> **
>
> Well..I can't answer why it 'suddenly' started happening....but, it
> doesn't appear that your qualifications are mutually exclusive.
>
>
>
> Filter fires on 'Status != Closed and Field set to pending approval'
>
>
>
> The Escalation is setting fields:
>
> Time1 =  NULL
> Setfield Notify= yes
>
>
>
> So....the Escalation is not setting any values that would cause the filter
> to NOT fire, and being the Filter is setting fields that would cause the
> Escalation to fire...I can see how a loop would form....
>
>
>
> Now....if you changed the Run-If for the filter to only fire if Setfield
> Notify = No, or something like that...then the Escalation wouldn't cause
> the filter to fire...but as it's custom, I don't know your system, so I
> don't know if that would be appropriate or not.
>
>
>
> Now...one thing that may need to be looked into is what value is coming
> out of
>
>
>
> $PROCESS$ Application-Bus-Time-Add "$TIMESTAMP$" "1" "2" "holiday" "Change"
>
>
>
> According to the Docs
>
>
>
> Application-Bus-Time-Add "<s*tartTime>*" ["<a*mount>*" ["<a*mountUnits>*"
> ["<*holidayScheduleName>*" [HTMLUATarsadministering1030:"<
> *workdayScheduleName>*"]]]]
>
>
>
> So, according to your command, you are adding 1 minute to 'now', based on
> the holiday schedule named 'holiday', and the workday schedule named
> 'Change'
>
>
>
> So, again, I don't know your system...but I don't know if you are
> intending to add '1 business minute' or not...but...that does seem to be
> what's happening, which is causing the escalation to fire again on it's
> next run....
>
>
>
> You may also want to check with your holiday and Change calendars to
> ensure they are still accurate.
>
>
>
> On Wed, Dec 3, 2014 at 8:05 AM, ddussie <[email protected]> wrote:
>
> Hello List,
>
> This is our scenario, we have had remedy since 1.x... but since since
> conversion at 6.3x mark we have steadily upgraded - as we are a custom shop
> no modules. That being said,  since the day light saving time change,
> filters and escalation have been acting weird; from all investigation it is
> not a result of timing issue; but possible a coincidence with Time change.
> This is what we are experiencing,
>
> A change request in the custom change system, on creation of the ticket
> will
> notify a group if this filter is met.
>
> on Execution Submit & Modify
> qualification = Status != Closed and Field set to pending approval
> Then
> Setfield to Time1 = $PROCESS$ Application-Bus-Time-Add "$TIMESTAMP$" "1"
> "2"
> "holiday" "Change" Setfield Notify=No
> Runprocess to call telalert to email.
>
> Then an escalation
> On 4 min interval
> Qualification: Time1 != $NULL$ and Notify=No and TimeStamp> Time1
> Then  Setfield to Time1 =  NULL
> Setfield Notify= yes
> Runprocess to call telalert to text/page.
>
>
> Since yesterday, 3pm this workflow started looping.
>
> So as the filter fires, the escalation fires, looping on Execution action
> modify.
>
> This sent 300 emails and 300 pages to group.
>
> Its wierd as the filter execution on submit and modify  has been working
> for
> atleast 7 years i have been managing this tool.
>
> I'm not sure which version of remedy 6.3x to 7.5x that built that workflow.
> I have rebuilt in 7.5p4 version; however that didnot resolve.
>
> Can anyone assist with an explanation?
>
> We are behind in upgrading.
> ARS 7.5.00 Patch 004 201002051027
> Oracle 11.2.0.3.0 - 64bit Production
> UNIX AIX 6.1
>
> Cluster JVM & Cluster Http & Bigip
> MT Version 7.5.00 Patch 004 201002051027
> WebSphere IBM WebSphere Application Server/6.1
> Java Version 1.5.0
>
>
>
>
>
>
>
>
>
> --
> View this message in context:
> http://ars-action-request-system.1.n7.nabble.com/Filters-actions-are-firing-wierd-or-correctly-tp119984.html
> Sent from the ARS (Action Request System) mailing list archive at
> Nabble.com.
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>
>
>
> _ARSlist: "Where the Answers Are" and have been for 20 years_
>
> _ARSlist: "Where the Answers Are" and have been for 20 years_
>  _ARSlist: "Where the Answers Are" and have been for 20 years_
>

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Reply via email to