Re: arslist Digest - 27 May 2008 to 28 May 2008 (#2008-226)

[[EMAIL PROTECTED]]

I will be out of the office from May 23, 2008 until June 2, 2008 

If you need immediate information or assistance with any of the Remedy
applications, please contact Michael White  at 504-426-2475.   Please contact
Diane Schmit at 504-426-2060 for non-Remedy related inquiries.

Thanks,

Maria Bertucci

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Next ID Blocking = faster submits?

[Joe D'Souza]

Recently I had used 500 as a block when creating about 32 K records in the
CTM:People form and User form after using AIE to connect to a PS database. I
didn't really see a significant difference in the processing time when not
using the Next ID blocking.. In both cases it took an average of about 35
minutes to run.

I then reverted back to the default setting of 0 as I preferred a sequential
request ID consistent to the create date..

But like LJ said over a million records - maybe it would make a difference..

Joe
  -Original Message-
  From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of LJ Longwing
  Sent: Wednesday, May 28, 2008 4:39 PM
  To: arslist@ARSLIST.ORG
  Subject: Re: Next ID Blocking = faster submits?


  **
  Rick,
  As mentioned by Chad.  I have heard this 3rd person...and never
experienced it myself, but it's my understanding that the reason that the
next-id block feature was implemented was because when you are submitting
millions of records an hour (as sometimes happens with the larger shops) a
single id at a time isn't enough to ensure you get all of the IDs handed out
in time...so it's more of a contention issue than it was a performance
enhancement...if you have 30 threads, each with 100 ids, you will only have
30 calls to get new ids instead of 3000 calls to get ids, that reduction in
update calls to that one table removes it as a bottleneck.




--
  From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
  Sent: Wednesday, May 28, 2008 2:02 PM
  To: arslist@ARSLIST.ORG
  Subject: Next ID Blocking = faster submits?


  ** I've been doing some testing to see how much this really helps
performance, and my preliminary numbers were surprising and disappointing.
NOTE:  I don't think a single sample is enough from which to draw a global
conclusion.  HOWEVER...I am concerned enough to ask some questions.

  I have two new servers, equal hardware, same OS (RHEL 5) and AR System 7.1
p2, same code, same DB version, same code and similar (but separate)
databases.

  I ran an Escalation that submits hundreds of records into a relatively
small form (perhaps 25 fields) that previously contained no records.  There
was no other load or user on either server.

  Server A is set up without the NextId blocking.
  Server B is set up WITH the NextId blocking set for 100 at the server
level but NOT on the form itself, threaded escalations, and the Status
History update disabled for the form in question.

  I went through the SQL logs and tracked the time difference between each
"UPDATE arschema SET nextId = nextId + <1/100> WHERE schemaId = 475" entry.
The results?

  Server A: Each fetch of single NextIds  was separated by an average of .07
seconds, which is 7 seconds per hundred.

  Server B: Each fetch of 100 NextIds was separated by a mean value of 12.4
seconds per entry (hundred).  A second run showed an average of 12.8
seconds, so I'm fairly confident that's a good number.  The fastest was 5.3
seconds, the slowest almost 40 seconds.

  Then just to eliminate the possibility that the environments were the
issue, I turned on the NextId blocking on Server A to the same parameters I
had set for Server B.  Result?  Average of 8 seconds per hundred, though if
I throw out the first two gets (which were 11 sec. ea), the remaining runs
average around 7.25 seconds per hundred.  Even in a best-case scenario, it's
still slightly slower than doing it singly.

  The median value between the values in all three sets across two servers
was 8 seconds.  The mean value is 11 seconds.  Again, the time it takes to
"get" 100 NextId updates 1 at a time was 7 seconds per hundred.

  So the newer, "faster" feature actually appears no faster, and in some
cases slower, than the process it's supposed to have improved.

  Maybe it's not hitting the DB as often, but then why are we not seeing the
omission of 99 DB calls reflected in faster overall submit times at the AR
System level?  Am I doing something wrong?  Are my expectations
unreasonable?  Is there some data in a white paper or something that shows
empirically what improvements one should expect from deploying this new
functionality?

  Is anyone seeing improved performance because of this feature?  I don't
see it.

  Rick
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.24.1/1468 - Release Date: 5/26/2008
3:23 PM

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

FW: BMC_SLM_JAVA_HOME Error

[Schon, Stuart]

Hi
 
I have just been down this path and was finally able to install SLM
successfully with JAVA 1.6 on Solaris.
 
The problems I encountered was 
1.  trying to run it in -console mode, you can't, it says so in the
install manual.
2.  running in XWindows didn't work either until I ran it as root
and set the JAVA_HOME and BMC_SLA JAVA_HOME environment variables. Even
then it still unpacks and installs its own version of Java (1.4), it is
also a good idea to put java into the PATH.
 
SLM works fine with Java 1.6
 
Once SLM was installed it broke the arplugin, arsystem start returns an
error and almost all of the ITSM suite is stuffed. I had to add 
LD_PRELOAD=libCrun.so.1:libiostream.so.1; export LD_PRELOAD
into the arsystem script. (info found on the BMC Developer site BMCDN)
 
Note: I have also installed SLM on win2003 svr and apart from setting
the BMC_SLA JAVA_HOME it all went just fine.
Regards
Stuart Schon
Remedy Solutions
KAZ Group
 
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the
Answers Are" html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: SLM - What sets the Required Resolution Date?

[strauss]

Me neither, so I made it up as I went along.

We are using Estimated Resolution Date as a Start Date and Required
Resolution Date as an End Date for scheduled outages, further defining
those as Service Type = Infrastructure Event (to be displayed in Kinetic
Calendar as scheduled outages). They are entered manually or by a
Kinetic Request service item. We see some of our groups using Required
Resolution on User Service Requests as a target date to complete the
service request, and as such they are not the same as the Goals set by
service targets in SLM, which are very generic across our primary
customer group and vary with priority and service type (documented on
our web site). We will probably add the Required Resolution Date to some
of our other Kinetic Service Items as they evolve, pushing it directly
into the Incidents to identify issues that have a time constraint.

In our current setup, the fact that SLM sets Estimated Resolution Date
from the first Service Target (some of the time, not always), which
happens to be Incident Response, not Incident Resolution, is actually an
error, but typical of the quality of the SLM to Incident Management
"integration."

Have you been able to see a pattern in when SLM (or something) sets
Estimated Resolution Date from the first Service Target goal date,
versus when it is left blank??  I have not.

Christopher Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing & IT Center
http://itsm.unt.edu/

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of LisaD
Sent: Wednesday, May 28, 2008 3:42 PM
To: arslist@ARSLIST.ORG
Subject: SLM - What sets the Required Resolution Date?

I have not found documentation to explain the Estimated Resolution Date
or
the Requried resolution Date on an incident.

I see that the estimated resolution date pulls in the first service
target's
goal date, and that you can manually put in a required resolution date
on
creation but that's it.

Any ideas?

Thanks - Lisa

-
Lisa W
[EMAIL PROTECTED]
-- 
View this message in context:
http://www.nabble.com/SLM---What-sets-the-Required-Resolution-Date--tp17
521299p17521299.html
Sent from the ARS (Action Request System) mailing list archive at
Nabble.com.


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Next ID Blocking = faster submits?

[LJ Longwing]

If I had to guess...and this is purely a guess...it's possible that the
additional overhead of managing the list with 100 ids in it caused the
retrieval to be slower...but that slow down would be insignificant in the
circumstances that would cause this table to be a bottleneck.

  _  

From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Wednesday, May 28, 2008 2:51 PM
To: arslist@ARSLIST.ORG
Subject: Re: Next ID Blocking = faster submits?


** OK, so it seems that I wasn't hitting the server hard enough to see a
real performance increase.  Why would I see a performance DECREASE?  Why
wouldn't the fact that I'm reducing the number of DB calls and locks show up
as a performance increase regardless of load, or at least be a push at lower
load levels?

Rick


On Wed, May 28, 2008 at 1:39 PM, LJ Longwing <[EMAIL PROTECTED]> wrote:


** 
Rick,
As mentioned by Chad.  I have heard this 3rd person...and never experienced
it myself, but it's my understanding that the reason that the next-id block
feature was implemented was because when you are submitting millions of
records an hour (as sometimes happens with the larger shops) a single id at
a time isn't enough to ensure you get all of the IDs handed out in time...so
it's more of a contention issue than it was a performance enhancement...if
you have 30 threads, each with 100 ids, you will only have 30 calls to get
new ids instead of 3000 calls to get ids, that reduction in update calls to
that one table removes it as a bottleneck.

  _  


From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook

Sent: Wednesday, May 28, 2008 2:02 PM
To: arslist@ARSLIST.ORG
Subject: Next ID Blocking = faster submits?


** I've been doing some testing to see how much this really helps
performance, and my preliminary numbers were surprising and disappointing.
NOTE:  I don't think a single sample is enough from which to draw a global
conclusion.  HOWEVER...I am concerned enough to ask some questions. 


I have two new servers, equal hardware, same OS (RHEL 5) and AR System 7.1
p2, same code, same DB version, same code and similar (but separate)
databases.

I ran an Escalation that submits hundreds of records into a relatively small
form (perhaps 25 fields) that previously contained no records.  There was no
other load or user on either server.

Server A is set up without the NextId blocking.
Server B is set up WITH the NextId blocking set for 100 at the server level
but NOT on the form itself, threaded escalations, and the Status History
update disabled for the form in question.

I went through the SQL logs and tracked the time difference between each
"UPDATE arschema SET nextId = nextId + <1/100> WHERE schemaId = 475" entry.
The results?

Server A: Each fetch of single NextIds  was separated by an average of .07
seconds, which is 7 seconds per hundred.

Server B: Each fetch of 100 NextIds was separated by a mean value of 12.4
seconds per entry (hundred).  A second run showed an average of 12.8
seconds, so I'm fairly confident that's a good number.  The fastest was 5.3
seconds, the slowest almost 40 seconds.  

Then just to eliminate the possibility that the environments were the issue,
I turned on the NextId blocking on Server A to the same parameters I had set
for Server B.  Result?  Average of 8 seconds per hundred, though if I throw
out the first two gets (which were 11 sec. ea), the remaining runs average
around 7.25 seconds per hundred.  Even in a best-case scenario, it's still
slightly slower than doing it singly.

The median value between the values in all three sets across two servers was
8 seconds.  The mean value is 11 seconds.  Again, the time it takes to "get"
100 NextId updates 1 at a time was 7 seconds per hundred.

So the newer, "faster" feature actually appears no faster, and in some cases
slower, than the process it's supposed to have improved.

Maybe it's not hitting the DB as often, but then why are we not seeing the
omission of 99 DB calls reflected in faster overall submit times at the AR
System level?  Am I doing something wrong?  Are my expectations
unreasonable?  Is there some data in a white paper or something that shows
empirically what improvements one should expect from deploying this new
functionality?

Is anyone seeing improved performance because of this feature?  I don't see
it.

Rick

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 


__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Next ID Blocking = faster submits?

[Hall Chad - chahal]

You really only have one sample on Server A without NextID blocks, so
perhaps a few more samples there would show its really the same as when
you used NextID blocks on that server. Which would indicate you weren't
bumping the bottleneck that this alleviates. I suspect something is
different on Server B that caused it to be significantly slower, so you
might try several tests there without NextID blocks.

 

 

Chad Hall  
(501) 342-2650



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Wednesday, May 28, 2008 3:51 PM
To: arslist@ARSLIST.ORG
Subject: Re: Next ID Blocking = faster submits?

 

** OK, so it seems that I wasn't hitting the server hard enough to see a
real performance increase.  Why would I see a performance DECREASE?  Why
wouldn't the fact that I'm reducing the number of DB calls and locks
show up as a performance increase regardless of load, or at least be a
push at lower load levels?

Rick

On Wed, May 28, 2008 at 1:39 PM, LJ Longwing <[EMAIL PROTECTED]>
wrote:

** 

Rick,

As mentioned by Chad.  I have heard this 3rd person...and never
experienced it myself, but it's my understanding that the reason that
the next-id block feature was implemented was because when you are
submitting millions of records an hour (as sometimes happens with the
larger shops) a single id at a time isn't enough to ensure you get all
of the IDs handed out in time...so it's more of a contention issue than
it was a performance enhancement...if you have 30 threads, each with 100
ids, you will only have 30 calls to get new ids instead of 3000 calls to
get ids, that reduction in update calls to that one table removes it as
a bottleneck.

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook

Sent: Wednesday, May 28, 2008 2:02 PM
To: arslist@ARSLIST.ORG
Subject: Next ID Blocking = faster submits?

** I've been doing some testing to see how much this really helps
performance, and my preliminary numbers were surprising and
disappointing.  NOTE:  I don't think a single sample is enough from
which to draw a global conclusion.  HOWEVER...I am concerned enough to
ask some questions.



I have two new servers, equal hardware, same OS (RHEL 5) and AR System
7.1 p2, same code, same DB version, same code and similar (but separate)
databases.

I ran an Escalation that submits hundreds of records into a relatively
small form (perhaps 25 fields) that previously contained no records.
There was no other load or user on either server.

Server A is set up without the NextId blocking.
Server B is set up WITH the NextId blocking set for 100 at the server
level but NOT on the form itself, threaded escalations, and the Status
History update disabled for the form in question.

I went through the SQL logs and tracked the time difference between each
"UPDATE arschema SET nextId = nextId + <1/100> WHERE schemaId = 475"
entry.  The results?

Server A: Each fetch of single NextIds  was separated by an average of
.07 seconds, which is 7 seconds per hundred.

Server B: Each fetch of 100 NextIds was separated by a mean value of
12.4 seconds per entry (hundred).  A second run showed an average of
12.8 seconds, so I'm fairly confident that's a good number.  The fastest
was 5.3 seconds, the slowest almost 40 seconds.  

Then just to eliminate the possibility that the environments were the
issue, I turned on the NextId blocking on Server A to the same
parameters I had set for Server B.  Result?  Average of 8 seconds per
hundred, though if I throw out the first two gets (which were 11 sec.
ea), the remaining runs average around 7.25 seconds per hundred.  Even
in a best-case scenario, it's still slightly slower than doing it
singly.

The median value between the values in all three sets across two servers
was 8 seconds.  The mean value is 11 seconds.  Again, the time it takes
to "get" 100 NextId updates 1 at a time was 7 seconds per hundred.

So the newer, "faster" feature actually appears no faster, and in some
cases slower, than the process it's supposed to have improved.

Maybe it's not hitting the DB as often, but then why are we not seeing
the omission of 99 DB calls reflected in faster overall submit times at
the AR System level?  Am I doing something wrong?  Are my expectations
unreasonable?  Is there some data in a white paper or something that
shows empirically what improvements one should expect from deploying
this new functionality?

Is anyone seeing improved performance because of this feature?  I don't
see it.

Rick

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 


__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 

***
The information contained in this commu

Re: Next ID Blocking = faster submits?

[Rick Cook]

OK, so it seems that I wasn't hitting the server hard enough to see a real
performance increase.  Why would I see a performance DECREASE?  Why wouldn't
the fact that I'm reducing the number of DB calls and locks show up as a
performance increase regardless of load, or at least be a push at lower load
levels?

Rick

On Wed, May 28, 2008 at 1:39 PM, LJ Longwing <[EMAIL PROTECTED]> wrote:

> ** Rick,
> As mentioned by Chad.  I have heard this 3rd person...and never experienced
> it myself, but it's my understanding that the reason that the next-id block
> feature was implemented was because when you are submitting millions of
> records an hour (as sometimes happens with the larger shops) a single id at
> a time isn't enough to ensure you get all of the IDs handed out in time...so
> it's more of a contention issue than it was a performance enhancement...if
> you have 30 threads, each with 100 ids, you will only have 30 calls to get
> new ids instead of 3000 calls to get ids, that reduction in update calls to
> that one table removes it as a bottleneck.
>
>  --
> *From:* Action Request System discussion list(ARSList) [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Rick Cook
> *Sent:* Wednesday, May 28, 2008 2:02 PM
> *To:* arslist@ARSLIST.ORG
> *Subject:* Next ID Blocking = faster submits?
>
> ** I've been doing some testing to see how much this really helps
> performance, and my preliminary numbers were surprising and disappointing.
> NOTE:  I don't think a single sample is enough from which to draw a global
> conclusion.  HOWEVER...I am concerned enough to ask some questions.
>
>
> I have two new servers, equal hardware, same OS (RHEL 5) and AR System 7.1
> p2, same code, same DB version, same code and similar (but separate)
> databases.
>
> I ran an Escalation that submits hundreds of records into a relatively
> small form (perhaps 25 fields) that previously contained no records.  There
> was no other load or user on either server.
>
> Server A is set up without the NextId blocking.
> Server B is set up WITH the NextId blocking set for 100 at the server level
> but NOT on the form itself, threaded escalations, and the Status History
> update disabled for the form in question.
>
> I went through the SQL logs and tracked the time difference between each
> "UPDATE arschema SET nextId = nextId + <1/100> WHERE schemaId = 475" entry.
> The results?
>
> Server A: Each fetch of single NextIds  was separated by an average of .07
> seconds, which is 7 seconds per hundred.
>
> Server B: Each fetch of 100 NextIds was separated by a mean value of 12.4
> seconds per entry (hundred).  A second run showed an average of 12.8
> seconds, so I'm fairly confident that's a good number.  The fastest was 5.3
> seconds, the slowest almost 40 seconds.
>
> Then just to eliminate the possibility that the environments were the
> issue, I turned on the NextId blocking on Server A to the same parameters I
> had set for Server B.  Result?  Average of 8 seconds per hundred, though if
> I throw out the first two gets (which were 11 sec. ea), the remaining runs
> average around 7.25 seconds per hundred.  Even in a best-case scenario, it's
> still slightly slower than doing it singly.
>
> The median value between the values in all three sets across two servers
> was 8 seconds.  The mean value is 11 seconds.  Again, the time it takes to
> "get" 100 NextId updates 1 at a time was 7 seconds per hundred.
>
> So the newer, "faster" feature actually appears no faster, and in some
> cases slower, than the process it's supposed to have improved.
>
> Maybe it's not hitting the DB as often, but then why are we not seeing the
> omission of 99 DB calls reflected in faster overall submit times at the AR
> System level?  Am I doing something wrong?  Are my expectations
> unreasonable?  Is there some data in a white paper or something that shows
> empirically what improvements one should expect from deploying this new
> functionality?
>
> Is anyone seeing improved performance because of this feature?  I don't see
> it.
>
> Rick
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

SLM - What sets the Required Resolution Date?

[LisaD]

I have not found documentation to explain the Estimated Resolution Date or
the Requried resolution Date on an incident.

I see that the estimated resolution date pulls in the first service target's
goal date, and that you can manually put in a required resolution date on
creation but that's it.

Any ideas?

Thanks - Lisa

-
Lisa W
[EMAIL PROTECTED]
-- 
View this message in context: 
http://www.nabble.com/SLM---What-sets-the-Required-Resolution-Date--tp17521299p17521299.html
Sent from the ARS (Action Request System) mailing list archive at Nabble.com.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Next ID Blocking = faster submits?

[LJ Longwing]

Rick,
As mentioned by Chad.  I have heard this 3rd person...and never experienced
it myself, but it's my understanding that the reason that the next-id block
feature was implemented was because when you are submitting millions of
records an hour (as sometimes happens with the larger shops) a single id at
a time isn't enough to ensure you get all of the IDs handed out in time...so
it's more of a contention issue than it was a performance enhancement...if
you have 30 threads, each with 100 ids, you will only have 30 calls to get
new ids instead of 3000 calls to get ids, that reduction in update calls to
that one table removes it as a bottleneck.

  _  

From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Wednesday, May 28, 2008 2:02 PM
To: arslist@ARSLIST.ORG
Subject: Next ID Blocking = faster submits?


** I've been doing some testing to see how much this really helps
performance, and my preliminary numbers were surprising and disappointing.
NOTE:  I don't think a single sample is enough from which to draw a global
conclusion.  HOWEVER...I am concerned enough to ask some questions.

I have two new servers, equal hardware, same OS (RHEL 5) and AR System 7.1
p2, same code, same DB version, same code and similar (but separate)
databases.

I ran an Escalation that submits hundreds of records into a relatively small
form (perhaps 25 fields) that previously contained no records.  There was no
other load or user on either server.

Server A is set up without the NextId blocking.
Server B is set up WITH the NextId blocking set for 100 at the server level
but NOT on the form itself, threaded escalations, and the Status History
update disabled for the form in question.

I went through the SQL logs and tracked the time difference between each
"UPDATE arschema SET nextId = nextId + <1/100> WHERE schemaId = 475" entry.
The results?

Server A: Each fetch of single NextIds  was separated by an average of .07
seconds, which is 7 seconds per hundred.

Server B: Each fetch of 100 NextIds was separated by a mean value of 12.4
seconds per entry (hundred).  A second run showed an average of 12.8
seconds, so I'm fairly confident that's a good number.  The fastest was 5.3
seconds, the slowest almost 40 seconds.  

Then just to eliminate the possibility that the environments were the issue,
I turned on the NextId blocking on Server A to the same parameters I had set
for Server B.  Result?  Average of 8 seconds per hundred, though if I throw
out the first two gets (which were 11 sec. ea), the remaining runs average
around 7.25 seconds per hundred.  Even in a best-case scenario, it's still
slightly slower than doing it singly.

The median value between the values in all three sets across two servers was
8 seconds.  The mean value is 11 seconds.  Again, the time it takes to "get"
100 NextId updates 1 at a time was 7 seconds per hundred.

So the newer, "faster" feature actually appears no faster, and in some cases
slower, than the process it's supposed to have improved.

Maybe it's not hitting the DB as often, but then why are we not seeing the
omission of 99 DB calls reflected in faster overall submit times at the AR
System level?  Am I doing something wrong?  Are my expectations
unreasonable?  Is there some data in a white paper or something that shows
empirically what improvements one should expect from deploying this new
functionality?

Is anyone seeing improved performance because of this feature?  I don't see
it.

Rick
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Next ID Blocking = faster submits?

[Rick Cook]

Maybe you're right, Chad.  Obviously, BMC did enough testing to know what
the break points are, and proved the value of this feature to the point of
developing it.  I would like to see more of that data, so that I can figure
out when/if I might see the benefit on my own system.

Rick

On Wed, May 28, 2008 at 1:21 PM, Hall Chad - chahal <[EMAIL PROTECTED]>
wrote:

> **
>
> I don't think you'll see the true benefit until you test it with several
> threads submitting records at the same time. That's when the contention on
> the arschema table will become a bottleneck. And as fast as that SQL call
> is, you may need LOTS of threads very quickly submitting LOTS of records.
>
>
>
> We saw problems with contention on this back in 6.3. The real problem was
> actually a very slow and poorly configured SAN for our database system,
> along with very fragmented tables. But the end result was long waits and
> blocked processes at the database while arschema was being updated that led
> to slow response or even timeouts for our end users while they submitted
> records. A bigger, better, faster SAN configuration took all of our problems
> away, but I'm confident NextID blocks would have helped us.
>
>
>
> I just upgraded to 7.0.1 and used NextID blocks on a few major forms, but
> unfortunately I didn't benchmark anything before or after.
>
>
>
> *Chad Hall*
> (501) 342-2650
>   --
>
> *From:* Action Request System discussion list(ARSList) [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Rick Cook
> *Sent:* Wednesday, May 28, 2008 3:14 PM
> *To:* arslist@ARSLIST.ORG
> *Subject:* Re: Next ID Blocking = faster submits?
>
>
>
> ** I could do that, Axton, but I wanted to test the increase in performance
> of just the NextID blocking.  Unless there's something that says that none
> of these new features will benefit us without enabling them all, I would
> like to evaluate them individually and in smaller sets before I do them all.
>
> Rick
>
> On Wed, May 28, 2008 at 1:08 PM, Axton <[EMAIL PROTECTED]> wrote:
>
> What about performing the same test creating a series of entries on
> separate threads.  Then break down the results based on the thread
> count.
>
> Axton Grams
>
> On Wed, May 28, 2008 at 4:01 PM, Rick Cook <[EMAIL PROTECTED]> wrote:
> > ** I've been doing some testing to see how much this really helps
>
> > performance, and my preliminary numbers were surprising and
> disappointing.
> > NOTE:  I don't think a single sample is enough from which to draw a
> global
> > conclusion.  HOWEVER...I am concerned enough to ask some questions.
> >
> > I have two new servers, equal hardware, same OS (RHEL 5) and AR System
> 7.1
> > p2, same code, same DB version, same code and similar (but separate)
> > databases.
> >
> > I ran an Escalation that submits hundreds of records into a relatively
> small
> > form (perhaps 25 fields) that previously contained no records.  There was
> no
> > other load or user on either server.
> >
> > Server A is set up without the NextId blocking.
> > Server B is set up WITH the NextId blocking set for 100 at the server
> level
> > but NOT on the form itself, threaded escalations, and the Status History
> > update disabled for the form in question.
> >
> > I went through the SQL logs and tracked the time difference between each
> > "UPDATE arschema SET nextId = nextId + <1/100> WHERE schemaId = 475"
> entry.
> > The results?
> >
> > Server A: Each fetch of single NextIds  was separated by an average of
> .07
> > seconds, which is 7 seconds per hundred.
> >
> > Server B: Each fetch of 100 NextIds was separated by a mean value of 12.4
> > seconds per entry (hundred).  A second run showed an average of 12.8
> > seconds, so I'm fairly confident that's a good number.  The fastest was
> 5.3
> > seconds, the slowest almost 40 seconds.
> >
> > Then just to eliminate the possibility that the environments were the
> issue,
> > I turned on the NextId blocking on Server A to the same parameters I had
> set
> > for Server B.  Result?  Average of 8 seconds per hundred, though if I
> throw
> > out the first two gets (which were 11 sec. ea), the remaining runs
> average
> > around 7.25 seconds per hundred.  Even in a best-case scenario, it's
> still
> > slightly slower than doing it singly.
> >
> > The median value between the values in all three sets across two servers
> was
> > 8 seconds.  The mean value is 11 seconds.  Again, the time it takes to
> "get"
> > 100 NextId updates 1 at a time was 7 seconds per hundred.
> >
> > So the newer, "faster" feature actually appears no faster, and in some
> cases
> > slower, than the process it's supposed to have improved.
> >
> > Maybe it's not hitting the DB as often, but then why are we not seeing
> the
> > omission of 99 DB calls reflected in faster overall submit times at the
> AR
> > System level?  Am I doing something wrong?  Are my expectations
> > unreasonable?  Is there some data in a white paper or something that
> shows
> > empirically what

MattReinfeldt.com and RemedyUserGroups.com outtage today

[Matt Reinfeldt]

Folks,

 

I want to apologize to everyone who was trying to get to my sites today and
was unable to.  My server went through a painful data center move.  J  I
believe it is all up and running now.

 

Also, I want to take this time to let everyone know that I am starting to
migrate my downloads area to some new software, if it works well for
everyone.  As a test, I have placed the UserWorld 2007 presentations (thanks
BMC sr. mgmt for once again allowing that!) there for your enjoyment!
http://www.mattreinfeldt.com/dl ... if you get a 404 error, please try
later, and hopefully the dns info will propagate quickly.

 

Please send any feedback to matt.reinfeldt at gmail.com

 

Thanks!



Matt R.

 

 


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Next ID Blocking = faster submits?

[Andrew Fremont]

I believe the "improvement" performance is for multiple concurrent users
(100+) submitting entries to the same form. This option may not work best
for single user.

AF.

On Wed, May 28, 2008 at 1:13 PM, Rick Cook <[EMAIL PROTECTED]> wrote:

> ** I could do that, Axton, but I wanted to test the increase in performance
> of just the NextID blocking.  Unless there's something that says that none
> of these new features will benefit us without enabling them all, I would
> like to evaluate them individually and in smaller sets before I do them all.
>
> Rick
>
>
> On Wed, May 28, 2008 at 1:08 PM, Axton <[EMAIL PROTECTED]> wrote:
>
>> What about performing the same test creating a series of entries on
>> separate threads.  Then break down the results based on the thread
>> count.
>>
>> Axton Grams
>>
>> On Wed, May 28, 2008 at 4:01 PM, Rick Cook <[EMAIL PROTECTED]> wrote:
>> > ** I've been doing some testing to see how much this really helps
>> > performance, and my preliminary numbers were surprising and
>> disappointing.
>> > NOTE:  I don't think a single sample is enough from which to draw a
>> global
>> > conclusion.  HOWEVER...I am concerned enough to ask some questions.
>> >
>> > I have two new servers, equal hardware, same OS (RHEL 5) and AR System
>> 7.1
>> > p2, same code, same DB version, same code and similar (but separate)
>> > databases.
>> >
>> > I ran an Escalation that submits hundreds of records into a relatively
>> small
>> > form (perhaps 25 fields) that previously contained no records.  There
>> was no
>> > other load or user on either server.
>> >
>> > Server A is set up without the NextId blocking.
>> > Server B is set up WITH the NextId blocking set for 100 at the server
>> level
>> > but NOT on the form itself, threaded escalations, and the Status History
>> > update disabled for the form in question.
>> >
>> > I went through the SQL logs and tracked the time difference between each
>> > "UPDATE arschema SET nextId = nextId + <1/100> WHERE schemaId = 475"
>> entry.
>> > The results?
>> >
>> > Server A: Each fetch of single NextIds  was separated by an average of
>> .07
>> > seconds, which is 7 seconds per hundred.
>> >
>> > Server B: Each fetch of 100 NextIds was separated by a mean value of
>> 12.4
>> > seconds per entry (hundred).  A second run showed an average of 12.8
>> > seconds, so I'm fairly confident that's a good number.  The fastest was
>> 5.3
>> > seconds, the slowest almost 40 seconds.
>> >
>> > Then just to eliminate the possibility that the environments were the
>> issue,
>> > I turned on the NextId blocking on Server A to the same parameters I had
>> set
>> > for Server B.  Result?  Average of 8 seconds per hundred, though if I
>> throw
>> > out the first two gets (which were 11 sec. ea), the remaining runs
>> average
>> > around 7.25 seconds per hundred.  Even in a best-case scenario, it's
>> still
>> > slightly slower than doing it singly.
>> >
>> > The median value between the values in all three sets across two servers
>> was
>> > 8 seconds.  The mean value is 11 seconds.  Again, the time it takes to
>> "get"
>> > 100 NextId updates 1 at a time was 7 seconds per hundred.
>> >
>> > So the newer, "faster" feature actually appears no faster, and in some
>> cases
>> > slower, than the process it's supposed to have improved.
>> >
>> > Maybe it's not hitting the DB as often, but then why are we not seeing
>> the
>> > omission of 99 DB calls reflected in faster overall submit times at the
>> AR
>> > System level?  Am I doing something wrong?  Are my expectations
>> > unreasonable?  Is there some data in a white paper or something that
>> shows
>> > empirically what improvements one should expect from deploying this new
>> > functionality?
>> >
>> > Is anyone seeing improved performance because of this feature?  I don't
>> see
>> > it.
>> >
>> > Rick
>> > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>> > html___
>>
>>
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>>
>
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Next ID Blocking = faster submits?

[Hall Chad - chahal]

I don't think you'll see the true benefit until you test it with several
threads submitting records at the same time. That's when the contention
on the arschema table will become a bottleneck. And as fast as that SQL
call is, you may need LOTS of threads very quickly submitting LOTS of
records.

 

We saw problems with contention on this back in 6.3. The real problem
was actually a very slow and poorly configured SAN for our database
system, along with very fragmented tables. But the end result was long
waits and blocked processes at the database while arschema was being
updated that led to slow response or even timeouts for our end users
while they submitted records. A bigger, better, faster SAN configuration
took all of our problems away, but I'm confident NextID blocks would
have helped us.

 

I just upgraded to 7.0.1 and used NextID blocks on a few major forms,
but unfortunately I didn't benchmark anything before or after.

 

Chad Hall  
(501) 342-2650



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Wednesday, May 28, 2008 3:14 PM
To: arslist@ARSLIST.ORG
Subject: Re: Next ID Blocking = faster submits?

 

** I could do that, Axton, but I wanted to test the increase in
performance of just the NextID blocking.  Unless there's something that
says that none of these new features will benefit us without enabling
them all, I would like to evaluate them individually and in smaller sets
before I do them all.

Rick

On Wed, May 28, 2008 at 1:08 PM, Axton <[EMAIL PROTECTED]> wrote:

What about performing the same test creating a series of entries on
separate threads.  Then break down the results based on the thread
count.

Axton Grams

On Wed, May 28, 2008 at 4:01 PM, Rick Cook <[EMAIL PROTECTED]> wrote:
> ** I've been doing some testing to see how much this really helps

> performance, and my preliminary numbers were surprising and
disappointing.
> NOTE:  I don't think a single sample is enough from which to draw a
global
> conclusion.  HOWEVER...I am concerned enough to ask some questions.
>
> I have two new servers, equal hardware, same OS (RHEL 5) and AR System
7.1
> p2, same code, same DB version, same code and similar (but separate)
> databases.
>
> I ran an Escalation that submits hundreds of records into a relatively
small
> form (perhaps 25 fields) that previously contained no records.  There
was no
> other load or user on either server.
>
> Server A is set up without the NextId blocking.
> Server B is set up WITH the NextId blocking set for 100 at the server
level
> but NOT on the form itself, threaded escalations, and the Status
History
> update disabled for the form in question.
>
> I went through the SQL logs and tracked the time difference between
each
> "UPDATE arschema SET nextId = nextId + <1/100> WHERE schemaId = 475"
entry.
> The results?
>
> Server A: Each fetch of single NextIds  was separated by an average of
.07
> seconds, which is 7 seconds per hundred.
>
> Server B: Each fetch of 100 NextIds was separated by a mean value of
12.4
> seconds per entry (hundred).  A second run showed an average of 12.8
> seconds, so I'm fairly confident that's a good number.  The fastest
was 5.3
> seconds, the slowest almost 40 seconds.
>
> Then just to eliminate the possibility that the environments were the
issue,
> I turned on the NextId blocking on Server A to the same parameters I
had set
> for Server B.  Result?  Average of 8 seconds per hundred, though if I
throw
> out the first two gets (which were 11 sec. ea), the remaining runs
average
> around 7.25 seconds per hundred.  Even in a best-case scenario, it's
still
> slightly slower than doing it singly.
>
> The median value between the values in all three sets across two
servers was
> 8 seconds.  The mean value is 11 seconds.  Again, the time it takes to
"get"
> 100 NextId updates 1 at a time was 7 seconds per hundred.
>
> So the newer, "faster" feature actually appears no faster, and in some
cases
> slower, than the process it's supposed to have improved.
>
> Maybe it's not hitting the DB as often, but then why are we not seeing
the
> omission of 99 DB calls reflected in faster overall submit times at
the AR
> System level?  Am I doing something wrong?  Are my expectations
> unreasonable?  Is there some data in a white paper or something that
shows
> empirically what improvements one should expect from deploying this
new
> functionality?
>
> Is anyone seeing improved performance because of this feature?  I
don't see
> it.
>
> Rick

> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"


__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 

Re: croom contact

[Matt Reinfeldt]

Deepak,

I have forwarded your e-mail on to James.  I'm sure he'll get in touch.

Enjoy,

Matt R.

-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Deepak Thohan
Sent: Wednesday, May 28, 2008 7:49 AM
To: arslist@ARSLIST.ORG
Subject: croom contact

Hello ARS List, 



I am trying to find any current contact within Croom Consulting and thought 
perhaps someone from their organisation watched this list. Or perhaps someone 
else on the list have up to date information or could pass a request on ? We 
have been trying to communicate through available details on the croom web-site 
for over a month but have not managed to make contact through phone or email. 
Is this company still trading?



Deepak Thohan 

[EMAIL PROTECTED]
+44 1784 497047

Administrator

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Next ID Blocking = faster submits?

[Rick Cook]

I could do that, Axton, but I wanted to test the increase in performance of
just the NextID blocking.  Unless there's something that says that none of
these new features will benefit us without enabling them all, I would like
to evaluate them individually and in smaller sets before I do them all.

Rick

On Wed, May 28, 2008 at 1:08 PM, Axton <[EMAIL PROTECTED]> wrote:

> What about performing the same test creating a series of entries on
> separate threads.  Then break down the results based on the thread
> count.
>
> Axton Grams
>
> On Wed, May 28, 2008 at 4:01 PM, Rick Cook <[EMAIL PROTECTED]> wrote:
> > ** I've been doing some testing to see how much this really helps
> > performance, and my preliminary numbers were surprising and
> disappointing.
> > NOTE:  I don't think a single sample is enough from which to draw a
> global
> > conclusion.  HOWEVER...I am concerned enough to ask some questions.
> >
> > I have two new servers, equal hardware, same OS (RHEL 5) and AR System
> 7.1
> > p2, same code, same DB version, same code and similar (but separate)
> > databases.
> >
> > I ran an Escalation that submits hundreds of records into a relatively
> small
> > form (perhaps 25 fields) that previously contained no records.  There was
> no
> > other load or user on either server.
> >
> > Server A is set up without the NextId blocking.
> > Server B is set up WITH the NextId blocking set for 100 at the server
> level
> > but NOT on the form itself, threaded escalations, and the Status History
> > update disabled for the form in question.
> >
> > I went through the SQL logs and tracked the time difference between each
> > "UPDATE arschema SET nextId = nextId + <1/100> WHERE schemaId = 475"
> entry.
> > The results?
> >
> > Server A: Each fetch of single NextIds  was separated by an average of
> .07
> > seconds, which is 7 seconds per hundred.
> >
> > Server B: Each fetch of 100 NextIds was separated by a mean value of 12.4
> > seconds per entry (hundred).  A second run showed an average of 12.8
> > seconds, so I'm fairly confident that's a good number.  The fastest was
> 5.3
> > seconds, the slowest almost 40 seconds.
> >
> > Then just to eliminate the possibility that the environments were the
> issue,
> > I turned on the NextId blocking on Server A to the same parameters I had
> set
> > for Server B.  Result?  Average of 8 seconds per hundred, though if I
> throw
> > out the first two gets (which were 11 sec. ea), the remaining runs
> average
> > around 7.25 seconds per hundred.  Even in a best-case scenario, it's
> still
> > slightly slower than doing it singly.
> >
> > The median value between the values in all three sets across two servers
> was
> > 8 seconds.  The mean value is 11 seconds.  Again, the time it takes to
> "get"
> > 100 NextId updates 1 at a time was 7 seconds per hundred.
> >
> > So the newer, "faster" feature actually appears no faster, and in some
> cases
> > slower, than the process it's supposed to have improved.
> >
> > Maybe it's not hitting the DB as often, but then why are we not seeing
> the
> > omission of 99 DB calls reflected in faster overall submit times at the
> AR
> > System level?  Am I doing something wrong?  Are my expectations
> > unreasonable?  Is there some data in a white paper or something that
> shows
> > empirically what improvements one should expect from deploying this new
> > functionality?
> >
> > Is anyone seeing improved performance because of this feature?  I don't
> see
> > it.
> >
> > Rick
> > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> > html___
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Next ID Blocking = faster submits?

[Axton]

What about performing the same test creating a series of entries on
separate threads.  Then break down the results based on the thread
count.

Axton Grams

On Wed, May 28, 2008 at 4:01 PM, Rick Cook <[EMAIL PROTECTED]> wrote:
> ** I've been doing some testing to see how much this really helps
> performance, and my preliminary numbers were surprising and disappointing.
> NOTE:  I don't think a single sample is enough from which to draw a global
> conclusion.  HOWEVER...I am concerned enough to ask some questions.
>
> I have two new servers, equal hardware, same OS (RHEL 5) and AR System 7.1
> p2, same code, same DB version, same code and similar (but separate)
> databases.
>
> I ran an Escalation that submits hundreds of records into a relatively small
> form (perhaps 25 fields) that previously contained no records.  There was no
> other load or user on either server.
>
> Server A is set up without the NextId blocking.
> Server B is set up WITH the NextId blocking set for 100 at the server level
> but NOT on the form itself, threaded escalations, and the Status History
> update disabled for the form in question.
>
> I went through the SQL logs and tracked the time difference between each
> "UPDATE arschema SET nextId = nextId + <1/100> WHERE schemaId = 475" entry.
> The results?
>
> Server A: Each fetch of single NextIds  was separated by an average of .07
> seconds, which is 7 seconds per hundred.
>
> Server B: Each fetch of 100 NextIds was separated by a mean value of 12.4
> seconds per entry (hundred).  A second run showed an average of 12.8
> seconds, so I'm fairly confident that's a good number.  The fastest was 5.3
> seconds, the slowest almost 40 seconds.
>
> Then just to eliminate the possibility that the environments were the issue,
> I turned on the NextId blocking on Server A to the same parameters I had set
> for Server B.  Result?  Average of 8 seconds per hundred, though if I throw
> out the first two gets (which were 11 sec. ea), the remaining runs average
> around 7.25 seconds per hundred.  Even in a best-case scenario, it's still
> slightly slower than doing it singly.
>
> The median value between the values in all three sets across two servers was
> 8 seconds.  The mean value is 11 seconds.  Again, the time it takes to "get"
> 100 NextId updates 1 at a time was 7 seconds per hundred.
>
> So the newer, "faster" feature actually appears no faster, and in some cases
> slower, than the process it's supposed to have improved.
>
> Maybe it's not hitting the DB as often, but then why are we not seeing the
> omission of 99 DB calls reflected in faster overall submit times at the AR
> System level?  Am I doing something wrong?  Are my expectations
> unreasonable?  Is there some data in a white paper or something that shows
> empirically what improvements one should expect from deploying this new
> functionality?
>
> Is anyone seeing improved performance because of this feature?  I don't see
> it.
>
> Rick
> __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Next ID Blocking = faster submits?

[Rick Cook]

I've been doing some testing to see how much this really helps performance,
and my preliminary numbers were surprising and disappointing.  NOTE:  I
don't think a single sample is enough from which to draw a global
conclusion.  HOWEVER...I am concerned enough to ask some questions.

I have two new servers, equal hardware, same OS (RHEL 5) and AR System 7.1
p2, same code, same DB version, same code and similar (but separate)
databases.

I ran an Escalation that submits hundreds of records into a relatively small
form (perhaps 25 fields) that previously contained no records.  There was no
other load or user on either server.

Server A is set up without the NextId blocking.
Server B is set up WITH the NextId blocking set for 100 at the server level
but NOT on the form itself, threaded escalations, and the Status History
update disabled for the form in question.

I went through the SQL logs and tracked the time difference between each
"UPDATE arschema SET nextId = nextId + <1/100> WHERE schemaId = 475" entry.
The results?

Server A: Each fetch of single NextIds  was separated by an average of .07
seconds, which is 7 seconds per hundred.

Server B: Each fetch of 100 NextIds was separated by a mean value of 12.4
seconds per entry (hundred).  A second run showed an average of 12.8
seconds, so I'm fairly confident that's a good number.  The fastest was 5.3
seconds, the slowest almost 40 seconds.

Then just to eliminate the possibility that the environments were the issue,
I turned on the NextId blocking on Server A to the same parameters I had set
for Server B.  Result?  Average of 8 seconds per hundred, though if I throw
out the first two gets (which were 11 sec. ea), the remaining runs average
around 7.25 seconds per hundred.  Even in a best-case scenario, it's still
slightly slower than doing it singly.

The median value between the values in all three sets across two servers was
8 seconds.  The mean value is 11 seconds.  Again, the time it takes to "get"
100 NextId updates 1 at a time was 7 seconds per hundred.

So the newer, "faster" feature actually appears no faster, and in some cases
slower, than the process it's supposed to have improved.

Maybe it's not hitting the DB as often, but then why are we not seeing the
omission of 99 DB calls reflected in faster overall submit times at the AR
System level?  Am I doing something wrong?  Are my expectations
unreasonable?  Is there some data in a white paper or something that shows
empirically what improvements one should expect from deploying this new
functionality?

Is anyone seeing improved performance because of this feature?  I don't see
it.

Rick

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

en_US and ev_CA issue with SRM selecting request

[haeyoon . lee]

Hi,

I have a ticket open but haven't heard from BMC is a long time.  Seems
to take them a while to 1. look at the bug 2. admit there is a bug. 3.
escalate it 4. get it fixed.

Anyway.
Does any one with SRM have this issue?
If you use en_US on the server but the clients have en_CA or en_AU, it
gives an error message in Request Entry (SRM) when selecting a SRD.
The message is something like start time and end time are not proper
or something.

I have tested and I know the issue is the date format of en_US vs
en_CA/en_AU.
en_US = mm/dd/
en_CA = dd/mm/

I think this has an effect on SLM calculations also.

Anyone with these issues?

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Web Services XML Questions - Very Interesting Implementation

[Carey Matthew Black]

I would even go so far as to advocate that the interface should be
independent of the OOB stuff.

So while the OOB application my have a web service that could work
with the current application. There simply is no contract/expectation
that the WebService will not change during a patch to the application
or an upgrade of ARS. By using a separate form/application you are
insulated when the OOB stuff changes and you have a chance of adding
additional workflow/corrections to the interface to map it to the "new
OOB" application. (And if you are real lucky.. not have to change the
"non-ARS" side of the integration at all.)


However, to the specific concerns of "transaction control, retries,
log or any other type of control."

  Transaction control well that is a bit hard to address
unless your a bit more specific. It is the responsibility of the WS
client to complete the WS call. (And retry, or error if needed.) But
you likely are asking about more of a "transaction broker" that will
accept the WS request and then turn around and be the real WS client
and deal with all of the retry/error/reply stuff asynchronously. ( I
believe those features go beyond the standard WS design and are not
even targeted in the ARS WS universe for either publishing nor
consuming.) You could write your own broker, but that seems silly to
me. You could do a kind of "DSO" design where you have consuming
requests entered into an ARS form that you have an external process
poll and process. The processing may then update the parent in a
determined way to complete the processing of the request. However for
the publishing side... ARS WS are just not alterable. You could write
your own WS and use ARS API behind them if you wanted to. (But that is
likely more work than you want.)

  I think "Logs" should be possible, but you may need to look at API
logs to see some of what you might find useful. ( And likely Plugin
Server logs too.)

HTH

-- 
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.

On Wed, May 28, 2008 at 11:09 AM, strauss <[EMAIL PROTECTED]> wrote:
> We don't use web services at all so are not familiar with that
> particular problem, but we found the same limitations that you did with
> the HPD:IncidentInterface form when integrating Kinetic Request.  We
> learned that we have to set Kinetic to create HPD:WorkInfo entries
> directly, and then used custom filters to make specific changes to the
> Incident record without going through the HPD:IncidentInterface join
> form. We implemented customer ability to update an incident, close an
> incident, or reopen an incident in this way, adding a few custom fields
> for action flags to the HPD:WorkInfo form. HPD:IncidentInterface is just
> too cumbersome to work with, as you have seen, and the bizarre design of
> it _promotes_ data corruption.
>
> If you are trying to push a consolidation of data out through web
> services, my bet would be that you will need to create custom join
> forms, similar to what you would build to support custom reporting, that
> contain all of the data that you want to push out to the web service
> interface. You then can build any custom workflow that you want against
> the custom join form to control your output to the web services.
>
> Christopher Strauss, Ph.D.
> Call Tracking Administration Manager
> University of North Texas Computing & IT Center
> http://itsm.unt.edu/
>
>> -Original Message-
>> From: Action Request System discussion list(ARSList)
>> [mailto:[EMAIL PROTECTED] On Behalf Of renato.fichmann
>> Sent: Wednesday, May 28, 2008 12:15 AM
>> To: arslist@ARSLIST.ORG
>> Subject: Web Services XML Questions - Very Interesting Implementation
>>
>> Hi Guys,
>> I have a ITSM7 / ARS 7 system and we'd like to heavily use the web
>> services interface to connect our Remedy infrastructure to several
>> different systems such as alarm systems, other ITSM solutions, CRM
>> based application among others.
>>
>> We've faced several limitation in regarding Web services, BMC is
>> giving us some options around 3rd part applications in between, which
>> is not the best solution at the moment. The issues are:
>>
>> 1. When the consumer system updates only some fields, like incident
>> status through the out of the box webservices interface and form,
>> Remedy set the other fields as NULL. This documented limitation forces
>> the interface to either populates all the fields in the incident form,
>> even if they are only changing a single field, or find an alternative
>> solution.
>>
>> 2. In the other direction when pushing content to a provider, the
>> requirement is to send more than just the incident related fields, but
>> also the CIs related and some additional related subforms. The out of
>> the box solution doesn't care about transaction control, retries, log
>> or any other type of control.
>>
>> Have you guys experim

Publishing Web services crashes the server - RESOLVED

[Pascale Boyer]

Just in case anyone is interested:

Our server kept crashing each time someone was trying to consume a web 
service we were publishing.  We had a "stack dump".

After several tests this is what I found:

In the Input and output mapping, the XML type property of the elements 
were set to True ==> server crashes

The Input mapping XML type property of the elements set to True AND XML 
Type property of the elements set to False in the Output mapping ==> 
Server OK

XML Type property of the elements to False in both the Input and Output 
mapping ==> Server OK

As soon as I change the XML Type back to True in the Output mapping ==> 
Server crashes

Now the question is WHY

But we are back on track for our dev.

Hope this can help someone else.

Pascale Boyer
Analyste Remedy Expert
Vidéotron Technologie Inc
Développement produits affaires & service corporatifs
300, avenue Viger Est - 
5e étage Est
Montréal (Québec) H2X 3W4
Tél.: (514) 380-7841
Courriel: [EMAIL PROTECTED]

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: active links not recaching

[jham36]

You could have also gone into your user tool's windows home directory
and deleted the arf and arv files for the form you are working on.  It
wouldn't hurt to delete them all to make sure.  Most are within
folders resembling the form name.

On May 28, 12:15 pm, "Gary Opela (Corporate)" <[EMAIL PROTECTED]>
wrote:
> Rick, my Development Cache Mode is unchecked.
>
> Thanks,
>
> Gary Opela, Jr., RSP
> Remedy Engineer
> Leader Communications, Inc.http://www.5pointleader.comhttp://www.lcibest.com
> Best Product, Best People, Best PriceTM
> An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company
> 
> From: Action Request System discussion list(ARSList) [mailto:[EMAIL 
> PROTECTED] On Behalf Of Rick Cook
> Sent: Wednesday, May 28, 2008 11:11 AM
> To: [EMAIL PROTECTED]
> Subject: Re: active links not recaching
>
> ** Gary, did you have Development Cache mode turned on or off?
>
> Rick
> On Wed, May 28, 2008 at 9:07 AM, Gary Opela (Corporate) <[EMAIL 
> PROTECTED]> wrote:
> **
>
> Okay, scratch this, it just picked up all of my changes.
>
> I have no idea why it took so long or why it didn't re-cache after all of my 
> changes, but it just now re-cached, finally...
>
> Thanks,
>
> Gary Opela, Jr., RSP
>
> Remedy Engineer
>
> Leader Communications, Inc.
>
> http://www.5pointleader.com
>
> http://www.lcibest.com
>
> Best Product, Best People, Best PriceTM
>
> An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company
>
> 
>
> From: Gary Opela (Corporate)
> Sent: Wednesday, May 28, 2008 11:04 AM
> To: '[EMAIL PROTECTED]'
> Subject: active links not recaching
>
> MS SQL Server 2k5
>
> Windows Server 2k3
>
> ARSystem 7.1
>
> Client 7.1
>
> Admin 7.1
>
> Java 1.6
>
> Tomcat 5.5.23
>
> I made a change to an active link today, tested it, and it failed the test. I 
> went back and verified everything was good, but what I changed (a new set 
> fields) wasn't getting picked up by my client. I did the regular, log 
> out/back in with my client tool, still it didn't work. I rebooted my PC, 
> still no luck. Added a Message that said HI that ran in the same active link, 
> but on a sooner action, and the message didn't pop up.
>
> Then I cycled arserver, tried again, still not working. So I cycled SQL 
> server, still no luck. I rebooted the server, still my changes were not being 
> picked up. Then I went in and disabled the active link, and tested, the other 
> actions were still firing, even though the AL was disabled. I went back to 
> the object (button on a vertical navigation bar) that was firing the AL to 
> verify that it had no other ALs that it fired, and it didn't, just the one. 
> So I went in and removed the message, changed the AL to fire on an EO of 5, 
> created a new AL that said Hi as the message, retested, nothing, it was still 
> doing what it did this morning before I had made any changes.
>
> Logged out of/back in to remedy on my client tool, still no luck.
>
> I did notice in the event viewer under Applications logs, that whenever I 
> rebooted my server, I received the following four errors:
>
> MSSQLSERVER:
>
> 10:29:23                  Could not find database ID 2, name 'tempdb'. The 
> database may be offline. Wait a few minutes and try again.
>
> 10:29:23                 Could not find database ID 2, name 'tempdb'. The 
> database may be offline. Wait a few minutes and try again.
>
> AR System Monitor:
>
> 10:29:22                 390600 : Failure during SQL operation to the 
> database (ARERR 552)
>
> 10:29:22                  Cannot open database "ARSystem" requested by the 
> login. The login failed. (SQL Server 4060)
>
> It picked up the changes I did this morning to my form, I added a few display 
> only fields to a view form, however, since then, no active link changes are 
> being picked up by the server, even after cycling the server.
>
> Does anyone have any idea of where I should look?
>
> Thanks,
>
> Gary Opela, Jr., RSP
>
> Remedy Engineer
>
> Leader Communications, Inc.
>
> http://www.5pointleader.com
>
> http://www.lcibest.com
>
> Best Product, Best People, Best PriceTM
>
> An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company
>
> __Platinum Sponsor:www.rmsportal.com ARSlist: 
> "Where the Answers Are" html___
>
> __Platinum Sponsor:www.rmsportal.comARSlist: "Where the Answers Are" html___
>
> ___­
> UNSUBSCRIBE or access ARSlist Archives atwww.arslist.org
> Platinum Sponsor:www.rmsportal.comARSlist: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: active links not recaching

[Gary Opela (Corporate)]

Rick, my Development Cache Mode is unchecked.

Thanks,

Gary Opela, Jr., RSP
Remedy Engineer
Leader Communications, Inc.
http://www.5pointleader.com
http://www.lcibest.com
Best Product, Best People, Best PriceTM
An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company

From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Rick Cook
Sent: Wednesday, May 28, 2008 11:11 AM
To: arslist@ARSLIST.ORG
Subject: Re: active links not recaching

** Gary, did you have Development Cache mode turned on or off?

Rick
On Wed, May 28, 2008 at 9:07 AM, Gary Opela (Corporate) <[EMAIL 
PROTECTED]> wrote:
**

Okay, scratch this, it just picked up all of my changes.



I have no idea why it took so long or why it didn't re-cache after all of my 
changes, but it just now re-cached, finally...



Thanks,



Gary Opela, Jr., RSP

Remedy Engineer

Leader Communications, Inc.

http://www.5pointleader.com

http://www.lcibest.com

Best Product, Best People, Best PriceTM

An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company



From: Gary Opela (Corporate)
Sent: Wednesday, May 28, 2008 11:04 AM
To: 'arslist@ARSLIST.ORG'
Subject: active links not recaching



MS SQL Server 2k5

Windows Server 2k3

ARSystem 7.1

Client 7.1

Admin 7.1

Java 1.6

Tomcat 5.5.23



I made a change to an active link today, tested it, and it failed the test. I 
went back and verified everything was good, but what I changed (a new set 
fields) wasn't getting picked up by my client. I did the regular, log out/back 
in with my client tool, still it didn't work. I rebooted my PC, still no luck. 
Added a Message that said HI that ran in the same active link, but on a sooner 
action, and the message didn't pop up.



Then I cycled arserver, tried again, still not working. So I cycled SQL server, 
still no luck. I rebooted the server, still my changes were not being picked 
up. Then I went in and disabled the active link, and tested, the other actions 
were still firing, even though the AL was disabled. I went back to the object 
(button on a vertical navigation bar) that was firing the AL to verify that it 
had no other ALs that it fired, and it didn't, just the one. So I went in and 
removed the message, changed the AL to fire on an EO of 5, created a new AL 
that said Hi as the message, retested, nothing, it was still doing what it did 
this morning before I had made any changes.



Logged out of/back in to remedy on my client tool, still no luck.



I did notice in the event viewer under Applications logs, that whenever I 
rebooted my server, I received the following four errors:



MSSQLSERVER:



10:29:23  Could not find database ID 2, name 'tempdb'. The 
database may be offline. Wait a few minutes and try again.

10:29:23 Could not find database ID 2, name 'tempdb'. The 
database may be offline. Wait a few minutes and try again.







AR System Monitor:



10:29:22 390600 : Failure during SQL operation to the database 
(ARERR 552)

10:29:22  Cannot open database "ARSystem" requested by the 
login. The login failed. (SQL Server 4060)



It picked up the changes I did this morning to my form, I added a few display 
only fields to a view form, however, since then, no active link changes are 
being picked up by the server, even after cycling the server.



Does anyone have any idea of where I should look?



Thanks,



Gary Opela, Jr., RSP

Remedy Engineer

Leader Communications, Inc.

http://www.5pointleader.com

http://www.lcibest.com

Best Product, Best People, Best PriceTM

An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company


__Platinum Sponsor: www.rmsportal.com ARSlist: "Where 
the Answers Are" html___

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: active links not recaching

[Gary Opela (Corporate)]

No, it does not, nor does the second AL I created, neither of which got picked 
up.
Thanks,



Gary Opela, Jr., RSP

Remedy Engineer

Leader Communications, Inc.

http://www.5pointleader.com

http://www.lcibest.com

Best Product, Best People, Best PriceTM

An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company

-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Kaiser Norm E CIV USAF 96 CS/SCCE
Sent: Wednesday, May 28, 2008 11:04 AM
To: arslist@ARSLIST.ORG
Subject: Re: active links not recaching

Gary, take a look at the NAME of the AL in question.  Does it have a
trailing space on the end of it?

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Gary Opela (Corporate)
Sent: Wednesday, May 28, 2008 11:04 AM
To: arslist@ARSLIST.ORG
Subject: active links not recaching

**

MS SQL Server 2k5

Windows Server 2k3

ARSystem 7.1

Client 7.1

Admin 7.1

Java 1.6

Tomcat 5.5.23



I made a change to an active link today, tested it, and it failed the
test. I went back and verified everything was good, but what I changed
(a new set fields) wasn't getting picked up by my client. I did the
regular, log out/back in with my client tool, still it didn't work. I
rebooted my PC, still no luck. Added a Message that said HI that ran in
the same active link, but on a sooner action, and the message didn't pop
up.



Then I cycled arserver, tried again, still not working. So I cycled SQL
server, still no luck. I rebooted the server, still my changes were not
being picked up. Then I went in and disabled the active link, and
tested, the other actions were still firing, even though the AL was
disabled. I went back to the object (button on a vertical navigation
bar) that was firing the AL to verify that it had no other ALs that it
fired, and it didn't, just the one. So I went in and removed the
message, changed the AL to fire on an EO of 5, created a new AL that
said Hi as the message, retested, nothing, it was still doing what it
did this morning before I had made any changes.



Logged out of/back in to remedy on my client tool, still no luck.



I did notice in the event viewer under Applications logs, that whenever
I rebooted my server, I received the following four errors:



MSSQLSERVER:



10:29:23  Could not find database ID 2, name 'tempdb'.
The database may be offline. Wait a few minutes and try again.

10:29:23 Could not find database ID 2, name 'tempdb'.
The database may be offline. Wait a few minutes and try again.







AR System Monitor:



10:29:22 390600 : Failure during SQL operation to the
database (ARERR 552)

10:29:22  Cannot open database "ARSystem" requested by
the login. The login failed. (SQL Server 4060)



It picked up the changes I did this morning to my form, I added a few
display only fields to a view form, however, since then, no active link
changes are being picked up by the server, even after cycling the
server.



Does anyone have any idea of where I should look?



Thanks,



Gary Opela, Jr., RSP

Remedy Engineer

Leader Communications, Inc.

http://www.5pointleader.com

http://www.lcibest.com

Best Product, Best People, Best PriceTM

An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company



__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: active links not recaching

[Rick Cook]

Gary, did you have Development Cache mode turned on or off?

Rick

On Wed, May 28, 2008 at 9:07 AM, Gary Opela (Corporate) <
[EMAIL PROTECTED]> wrote:

> **
>
> Okay, scratch this, it just picked up all of my changes.
>
>
>
> I have no idea why it took so long or why it didn't re-cache after all of
> my changes, but it just now re-cached, finally…
>
>
>
> Thanks,
>
>
>
> Gary Opela, Jr., RSP
>
> Remedy Engineer
>
> Leader Communications, Inc.
>
> http://www.5pointleader.com
>
> http://www.lcibest.com
>
> *Best Product, Best People, Best Price**TM*
>
> *An ISO 9001:2000 Certified, CMMI(R) Level 3 Rated Company***
>   --
>
> *From:* Gary Opela (Corporate)
> *Sent:* Wednesday, May 28, 2008 11:04 AM
> *To:* 'arslist@ARSLIST.ORG'
> *Subject:* active links not recaching
>
>
>
> MS SQL Server 2k5
>
> Windows Server 2k3
>
> ARSystem 7.1
>
> Client 7.1
>
> Admin 7.1
>
> Java 1.6
>
> Tomcat 5.5.23
>
>
>
> I made a change to an active link today, tested it, and it failed the test.
> I went back and verified everything was good, but what I changed (a new set
> fields) wasn't getting picked up by my client. I did the regular, log
> out/back in with my client tool, still it didn't work. I rebooted my PC,
> still no luck. Added a Message that said HI that ran in the same active
> link, but on a sooner action, and the message didn't pop up.
>
>
>
> Then I cycled arserver, tried again, still not working. So I cycled SQL
> server, still no luck. I rebooted the server, still my changes were not
> being picked up. Then I went in and disabled the active link, and tested,
> the other actions were still firing, even though the AL was disabled. I went
> back to the object (button on a vertical navigation bar) that was firing the
> AL to verify that it had no other ALs that it fired, and it didn't, just the
> one. So I went in and removed the message, changed the AL to fire on an EO
> of 5, created a new AL that said Hi as the message, retested, nothing, it
> was still doing what it did this morning before I had made any changes.
>
>
>
> Logged out of/back in to remedy on my client tool, still no luck.
>
>
>
> I did notice in the event viewer under Applications logs, that whenever I
> rebooted my server, I received the following four errors:
>
>
>
> MSSQLSERVER:
>
>
>
> 10:29:23  Could not find database ID 2, name 'tempdb'. The
> database may be offline. Wait a few minutes and try again.
>
> 10:29:23 Could not find database ID 2, name 'tempdb'. The
> database may be offline. Wait a few minutes and try again.
>
>
>
>
>
>
>
> AR System Monitor:
>
>
>
> 10:29:22 390600 : Failure during SQL operation to the
> database (ARERR 552)
>
> 10:29:22  Cannot open database "ARSystem" requested by the
> login. The login failed. (SQL Server 4060)
>
>
>
> It picked up the changes I did this morning to my form, I added a few
> display only fields to a view form, however, since then, no active link
> changes are being picked up by the server, even after cycling the server.
>
>
>
> Does anyone have any idea of where I should look?
>
>
>
> Thanks,
>
>
>
> Gary Opela, Jr., RSP
>
> Remedy Engineer
>
> Leader Communications, Inc.
>
> http://www.5pointleader.com
>
> http://www.lcibest.com
>
> *Best Product, Best People, Best Price**TM*
>
> *An ISO 9001:2000 Certified, CMMI(R) Level 3 Rated Company***
>
>
>  __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
> html___

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: active links not recaching

[Kaiser Norm E CIV USAF 96 CS/SCCE]

Gary, take a look at the NAME of the AL in question.  Does it have a
trailing space on the end of it?

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Gary Opela (Corporate)
Sent: Wednesday, May 28, 2008 11:04 AM
To: arslist@ARSLIST.ORG
Subject: active links not recaching

** 

MS SQL Server 2k5

Windows Server 2k3

ARSystem 7.1

Client 7.1

Admin 7.1

Java 1.6

Tomcat 5.5.23

 

I made a change to an active link today, tested it, and it failed the
test. I went back and verified everything was good, but what I changed
(a new set fields) wasn't getting picked up by my client. I did the
regular, log out/back in with my client tool, still it didn't work. I
rebooted my PC, still no luck. Added a Message that said HI that ran in
the same active link, but on a sooner action, and the message didn't pop
up. 

 

Then I cycled arserver, tried again, still not working. So I cycled SQL
server, still no luck. I rebooted the server, still my changes were not
being picked up. Then I went in and disabled the active link, and
tested, the other actions were still firing, even though the AL was
disabled. I went back to the object (button on a vertical navigation
bar) that was firing the AL to verify that it had no other ALs that it
fired, and it didn't, just the one. So I went in and removed the
message, changed the AL to fire on an EO of 5, created a new AL that
said Hi as the message, retested, nothing, it was still doing what it
did this morning before I had made any changes.

 

Logged out of/back in to remedy on my client tool, still no luck.

 

I did notice in the event viewer under Applications logs, that whenever
I rebooted my server, I received the following four errors:

 

MSSQLSERVER:

 

10:29:23  Could not find database ID 2, name 'tempdb'.
The database may be offline. Wait a few minutes and try again.

10:29:23 Could not find database ID 2, name 'tempdb'.
The database may be offline. Wait a few minutes and try again.

 

 

 

AR System Monitor:

 

10:29:22 390600 : Failure during SQL operation to the
database (ARERR 552)

10:29:22  Cannot open database "ARSystem" requested by
the login. The login failed. (SQL Server 4060)

 

It picked up the changes I did this morning to my form, I added a few
display only fields to a view form, however, since then, no active link
changes are being picked up by the server, even after cycling the
server.

 

Does anyone have any idea of where I should look?

 

Thanks,

 

Gary Opela, Jr., RSP

Remedy Engineer

Leader Communications, Inc.

http://www.5pointleader.com

http://www.lcibest.com

Best Product, Best People, Best PriceTM

An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company

 

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: active links not recaching

[Gary Opela (Corporate)]

Okay, scratch this, it just picked up all of my changes.

I have no idea why it took so long or why it didn't re-cache after all of my 
changes, but it just now re-cached, finally...

Thanks,

Gary Opela, Jr., RSP
Remedy Engineer
Leader Communications, Inc.
http://www.5pointleader.com
http://www.lcibest.com
Best Product, Best People, Best PriceTM
An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company

From: Gary Opela (Corporate)
Sent: Wednesday, May 28, 2008 11:04 AM
To: 'arslist@ARSLIST.ORG'
Subject: active links not recaching

MS SQL Server 2k5
Windows Server 2k3
ARSystem 7.1
Client 7.1
Admin 7.1
Java 1.6
Tomcat 5.5.23

I made a change to an active link today, tested it, and it failed the test. I 
went back and verified everything was good, but what I changed (a new set 
fields) wasn't getting picked up by my client. I did the regular, log out/back 
in with my client tool, still it didn't work. I rebooted my PC, still no luck. 
Added a Message that said HI that ran in the same active link, but on a sooner 
action, and the message didn't pop up.

Then I cycled arserver, tried again, still not working. So I cycled SQL server, 
still no luck. I rebooted the server, still my changes were not being picked 
up. Then I went in and disabled the active link, and tested, the other actions 
were still firing, even though the AL was disabled. I went back to the object 
(button on a vertical navigation bar) that was firing the AL to verify that it 
had no other ALs that it fired, and it didn't, just the one. So I went in and 
removed the message, changed the AL to fire on an EO of 5, created a new AL 
that said Hi as the message, retested, nothing, it was still doing what it did 
this morning before I had made any changes.

Logged out of/back in to remedy on my client tool, still no luck.

I did notice in the event viewer under Applications logs, that whenever I 
rebooted my server, I received the following four errors:

MSSQLSERVER:

10:29:23  Could not find database ID 2, name 'tempdb'. The 
database may be offline. Wait a few minutes and try again.
10:29:23 Could not find database ID 2, name 'tempdb'. The 
database may be offline. Wait a few minutes and try again.



AR System Monitor:

10:29:22 390600 : Failure during SQL operation to the database 
(ARERR 552)
10:29:22  Cannot open database "ARSystem" requested by the 
login. The login failed. (SQL Server 4060)

It picked up the changes I did this morning to my form, I added a few display 
only fields to a view form, however, since then, no active link changes are 
being picked up by the server, even after cycling the server.

Does anyone have any idea of where I should look?

Thanks,

Gary Opela, Jr., RSP
Remedy Engineer
Leader Communications, Inc.
http://www.5pointleader.com
http://www.lcibest.com
Best Product, Best People, Best PriceTM
An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

active links not recaching

[Gary Opela (Corporate)]

MS SQL Server 2k5
Windows Server 2k3
ARSystem 7.1
Client 7.1
Admin 7.1
Java 1.6
Tomcat 5.5.23

I made a change to an active link today, tested it, and it failed the test. I 
went back and verified everything was good, but what I changed (a new set 
fields) wasn't getting picked up by my client. I did the regular, log out/back 
in with my client tool, still it didn't work. I rebooted my PC, still no luck. 
Added a Message that said HI that ran in the same active link, but on a sooner 
action, and the message didn't pop up.

Then I cycled arserver, tried again, still not working. So I cycled SQL server, 
still no luck. I rebooted the server, still my changes were not being picked 
up. Then I went in and disabled the active link, and tested, the other actions 
were still firing, even though the AL was disabled. I went back to the object 
(button on a vertical navigation bar) that was firing the AL to verify that it 
had no other ALs that it fired, and it didn't, just the one. So I went in and 
removed the message, changed the AL to fire on an EO of 5, created a new AL 
that said Hi as the message, retested, nothing, it was still doing what it did 
this morning before I had made any changes.

Logged out of/back in to remedy on my client tool, still no luck.

I did notice in the event viewer under Applications logs, that whenever I 
rebooted my server, I received the following four errors:

MSSQLSERVER:

10:29:23  Could not find database ID 2, name 'tempdb'. The 
database may be offline. Wait a few minutes and try again.
10:29:23 Could not find database ID 2, name 'tempdb'. The 
database may be offline. Wait a few minutes and try again.



AR System Monitor:

10:29:22 390600 : Failure during SQL operation to the database 
(ARERR 552)
10:29:22  Cannot open database "ARSystem" requested by the 
login. The login failed. (SQL Server 4060)

It picked up the changes I did this morning to my form, I added a few display 
only fields to a view form, however, since then, no active link changes are 
being picked up by the server, even after cycling the server.

Does anyone have any idea of where I should look?

Thanks,

Gary Opela, Jr., RSP
Remedy Engineer
Leader Communications, Inc.
http://www.5pointleader.com
http://www.lcibest.com
Best Product, Best People, Best PriceTM
An ISO 9001:2000 Certified, CMMI(r) Level 3 Rated Company


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

BMC Patrol Training in India?

[Nazish Bano]

Hello, would anyone know of any company providing BMC training esp patrol 
training in India.
   
  Of what I saw on BMC education Patrol trainings are offered at Singapore, 
Hongkong and Australia.
   
  -nazish
   

   
-
 Planet Earth is in the hot seat. Know more.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Web Services XML Questions - Very Interesting Implementation

[strauss]

We don't use web services at all so are not familiar with that
particular problem, but we found the same limitations that you did with
the HPD:IncidentInterface form when integrating Kinetic Request.  We
learned that we have to set Kinetic to create HPD:WorkInfo entries
directly, and then used custom filters to make specific changes to the
Incident record without going through the HPD:IncidentInterface join
form. We implemented customer ability to update an incident, close an
incident, or reopen an incident in this way, adding a few custom fields
for action flags to the HPD:WorkInfo form. HPD:IncidentInterface is just
too cumbersome to work with, as you have seen, and the bizarre design of
it _promotes_ data corruption.

If you are trying to push a consolidation of data out through web
services, my bet would be that you will need to create custom join
forms, similar to what you would build to support custom reporting, that
contain all of the data that you want to push out to the web service
interface. You then can build any custom workflow that you want against
the custom join form to control your output to the web services.

Christopher Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing & IT Center
http://itsm.unt.edu/

> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of renato.fichmann
> Sent: Wednesday, May 28, 2008 12:15 AM
> To: arslist@ARSLIST.ORG
> Subject: Web Services XML Questions - Very Interesting Implementation
> 
> Hi Guys,
> I have a ITSM7 / ARS 7 system and we'd like to heavily use the web
> services interface to connect our Remedy infrastructure to several
> different systems such as alarm systems, other ITSM solutions, CRM
> based application among others.
> 
> We've faced several limitation in regarding Web services, BMC is
> giving us some options around 3rd part applications in between, which
> is not the best solution at the moment. The issues are:
> 
> 1. When the consumer system updates only some fields, like incident
> status through the out of the box webservices interface and form,
> Remedy set the other fields as NULL. This documented limitation forces
> the interface to either populates all the fields in the incident form,
> even if they are only changing a single field, or find an alternative
> solution.
> 
> 2. In the other direction when pushing content to a provider, the
> requirement is to send more than just the incident related fields, but
> also the CIs related and some additional related subforms. The out of
> the box solution doesn't care about transaction control, retries, log
> or any other type of control.
> 
> Have you guys experimented any of these situations in your
> infrastructure? What about the high level solutions for these demands?
> 
> Regards,
> 
>
___
> 
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: source contol implementation

[Joe Castleman]

I think I have seen something similar happen in 6.3, or at least I think
it's what happened:  A co-worker left the project before checking an object
back in. (Nice.)  I tried doing an "undo checkout", etc., without admin
rights (figuring I might as well try it), and in the process the "checked
out" name changed from the co-worker's to "unknown."

 

Something else I noticed is that the Admin tool did not like DEF files that
I had pulled out of SourceSafe's history.  Maybe it should, but it
didn't/doesn't (the SourceSafe DEF files look OK in a text editor, for what
that's worth).  This means that SourceSafe does track the version history,
but I can't actually do anything with the versions, I have to keep DEF files
that I export directly from the Admin tool.

 

--Joe Castleman

  _  

From: Pierson, Shawn
Sent: Wednesday, May 28, 2008 7:54 AM
To: arslist@ARSLIST.ORG
Subject: Re: [ARSLIST] source contol implementation

 

I have used it as well, and it worked fine with version 6.3 of ARS.
However, prior versions did have problems (although it could have been an
older Source Safe) where you would exit the Admin Tool where things are
checked out to you, then when you go back in they are still checked out but
not to you.  Instead, they are checked out but it doesn't say to what user
and you have to have admin rights to go back in and fix it on those items..


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: LDAP login issue....

[Grooms, Frederick W]

You can add field 118 (AD User Auth) to the User form and backfill it
with your domain.  FYI  Users can also put the domain in the
Authentication field on the login and have just their username in the
User Name field when logging in.
 
Field 118 is described in the ConfigGuide-630.pdf manual starting on
page 64
 
Fred



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Richard Copits
Sent: Wednesday, May 28, 2008 7:53 AM
To: arslist@ARSLIST.ORG
Subject: LDAP login issue

First, a BIG THANK YOU to all who responded to my emails for LDAP 
advice. I now have it running - and apparently correctly. However, I
have one more question. Previously, when I entered username and
password into Remedy, a user could log in using just the username 
and password. Now that the LDAP code is working, users now have
to enter their username in the form "domain/username". Since we
only have one login domain, is there any way I can add code to Remedy
that automatically "tacks on" the domain name to the front so that they
only have to type in their username? Thanks for any help, suggestions,
etc. 



 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: croom contact

[Graham Dyer]

This is the last contact e-mail I have:

James Croom [EMAIL PROTECTED]


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Deepak Thohan
Sent: Wednesday, May 28, 2008 7:49 AM
To: arslist@ARSLIST.ORG
Subject: croom contact


Hello ARS List, 



I am trying to find any current contact within Croom Consulting and
thought perhaps someone from their organisation watched this list. Or
perhaps someone else on the list have up to date information or could
pass a request on ? We have been trying to communicate through available
details on the croom web-site for over a month but have not managed to
make contact through phone or email. Is this company still trading?



Deepak Thohan 

[EMAIL PROTECTED]
+44 1784 497047

Administrator


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

croom contact

[Deepak Thohan]

Hello ARS List, 



I am trying to find any current contact within Croom Consulting and thought 
perhaps someone from their organisation watched this list. Or perhaps someone 
else on the list have up to date information or could pass a request on ? We 
have been trying to communicate through available details on the croom web-site 
for over a month but have not managed to make contact through phone or email. 
Is this company still trading?



Deepak Thohan 

[EMAIL PROTECTED]
+44 1784 497047

Administrator

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

LDAP login issue....

[Richard Copits]

First, a BIG THANK YOU to all who responded to my emails for LDAP 

advice. I now have it running - and apparently correctly. However, I

have one more question. Previously, when I entered username and

password into Remedy, a user could log in using just the username 

and password. Now that the LDAP code is working, users now have

to enter their username in the form "domain/username". Since we

only have one login domain, is there any way I can add code to Remedy

that automatically "tacks on" the domain name to the front so that they

only have to type in their username? Thanks for any help, suggestions,

etc. 



Portions of this message may be confidential under an exemption to Ohio's 
public records law or under a legal privilege. If you have received this 
message in error or due to an unauthorized transmission or interception, please 
delete all copies from your system without disclosing, copying, or transmitting 
this message.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: ARS 4.5.2 license problem

[Henderson, Danielle R CNTR]

We finally got the server up and running. Apparently the license had to
be enter differently. I was told by BMC Tech support to enter AR System
in the field next to the number of licenses in the license tool. Never
heard of this but it worked. The unix admins resolved the host ID issue
by moving back to the original box. Luckily we will be going to
production in August. This server is on its last leg.
 
Thanks to all that replied. Really appreciate your help
 
Danielle Henderson
[EMAIL PROTECTED]
L3 Communications Titan Corp



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Mauro Pedone
Sent: Monday, May 26, 2008 3:08 AM
To: arslist@ARSLIST.ORG
Subject: Re: ARS 4.5.2 license problem


** 
there are two or more network adapter?
maybe remedy reads an other network adapter mac address


2008/5/26 Henderson, Danielle R CNTR <[EMAIL PROTECTED]>:



Hello everyone,

I have problem. We are currently using ARS 4.5.2 on a unix box,
with
oracle database. During a network upgrade the application fail
to come
up. The unix admins moved the drive to a different box. For some
reason
all the current license keys are missing and it is showing
windows
license keys that we have used previously.

I was able to get support purge a few licenses keys but I am
receiving
the following error message.  ARERR (337) You have reach the
maximum
number of database entries permitted with this version of the
Action
Request System. Only the Server license can be added. I'm
getting
invalid keys for any user license I try to add. It is also
populating
the wrong HostID. I a newbie here but I have searched everywhere
trying
to find out where it getting the incorrect hostid with no luck.

Any Ideas? I would greatly appreciate any help I can get. The
work day
start on Tuesday and I have to have this app back up an running
before
the workday starts at 6am.


Danielle Henderson
[EMAIL PROTECTED]
L-3 Communication Titan Corp



___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
 
Platinum Sponsor: www.rmsportal.com 
ARSlist: "Where the Answers Are"



__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___ 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: source contol implementation

[Pierson, Shawn]

I have used it as well, and it worked fine with version 6.3 of ARS.  However, 
prior versions did have problems (although it could have been an older Source 
Safe) where you would exit the Admin Tool where things are checked out to you, 
then when you go back in they are still checked out but not to you.  Instead, 
they are checked out but it doesn’t say to what user and you have to have admin 
rights to go back in and fix it on those items.

 

Also, does anyone know if any future versions of ARS will work with Microsoft 
Visual Studio Team System, which has replaced Source Safe?

 

Thanks,

 

Shawn Pierson

 

From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of TeresaSFannin
Sent: Tuesday, May 27, 2008 9:24 PM
To: arslist@ARSLIST.ORG
Subject: Re: source contol implementation

 

** 

I have used Source Safe before and that worked very well.  I would only put in 
source safe new or  modified  workflow.   Don't try to put all of the out of 
the box workflow and forms in source control.   But before you modify anything 
put it in source control and check out to make the change.   It really helps to 
start source control on day one that you start customizations.  Upgrades can be 
accomplished easier as well because you know all that you have changed. 

Teresa

 

 

 

In a message dated 05/27/08 06:49:49 Central Daylight Time, [EMAIL PROTECTED] 
writes:

dear list, 

we would like to enable source control integration within the Remedy. 
Any comment/experience/suggestion will be very welcome. 
Thank you. 
Serouche 


___ 
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" 

 



Stay informed, get connected and more with AOL on your phone 

 .

__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ 


Private and confidential as detailed here: 
http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access the 
link, please e-mail sender.

Re: Error on Change Template Tasks ( ARERR 45093 )

[T. Dee]

You can not start working on the Task(s) until the Change is in
"Implementation in Progress".


On 5/28/08, Bulls-n-Bears <[EMAIL PROTECTED]> wrote:
> Greetings All,
>
> Am trying to create a new change ticket using a change template. The
> ticket got created successfully . When I now switch to Tasks tab and
> try closing a task with Status reason as "Success"., I recieve the
> following error.
>
> "This task (or group)  must be activated (from the parent) before it
> can be changed to the status:  Closed Success (ARERR 45093)".
>
> The change ticket is freshly created. The Task template is
> successfully attached to the ticket and I'm seeing the three tasks
> coming in from the template in Tasks tab.
>
> My env : ITSM 7.0 on Solaris and User Tool ( 7.0) on WinXP.
>
> Any ideas how to fix this ?
>
> Cheers,
> BnB
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Error on Change Template Tasks ( ARERR 45093 )

[Bulls-n-Bears]

Greetings All,

Am trying to create a new change ticket using a change template. The
ticket got created successfully . When I now switch to Tasks tab and
try closing a task with Status reason as "Success"., I recieve the
following error.

"This task (or group)  must be activated (from the parent) before it
can be changed to the status:  Closed Success (ARERR 45093)".

The change ticket is freshly created. The Task template is
successfully attached to the ticket and I'm seeing the three tasks
coming in from the template in Tasks tab.

My env : ITSM 7.0 on Solaris and User Tool ( 7.0) on WinXP.

Any ideas how to fix this ?

Cheers,
BnB

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Date fields clarification in Incident Mgmt 7.0.2

[Kenneth]

Hi All,

I have some questions on the date fields in HPD:Help Desk form.

On the Incident User Guide, it says that the 'Responded Date' is actually
used for SLM.  When an incident is recorded by the HelpDesk and then
responded to by the support team, a support person must manually mark that
it was responded to and the date will be populated.

I would like to understand on the HPD:Help Desk form, when will the
following dates be populated and under which Incident Status:
- Acknowledged Date will be same as Reported Date (on Submit, Status is New)
  I notice that the Acknowledged Date is always the same as Reported Date.
So this field is not populated when Incident changes from Assigned to In
Progress.

- Responded Date

- Re-Opened Date
  I use the Re-Open option to change the incident status from Resolved back
to In Progress. But the date is not populated. So how would I know that this
incident has been re-opened before?

Thanks for your time.


Regards
Kenneth

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: Business Objects XI - Solaris MidTier integration issues - RESOLVED

[Prashant Patil]

Hi All,

My problem is solved. I am able to see reports on the web. The problem was
in ARWebReportViewer configuration - AR System ODBC Date Source Connection.
During installation of this application on BO server I had given a custom
datasource name. But now I changed it to match the standard name given in
Windows ODBC drivers list - "AR System ODBC Data Source"

Regards,
Prashant


On Sun, May 25, 2008 at 2:33 PM, Prashant Patil <[EMAIL PROTECTED]> wrote:

> Dear All,
>
>
> I am in the process of configuring ARS web reporting – using ARS7.1 with
> Business Objects XI. At the current stage I am facing the following error:
> Failed to process the request!! An unexpected error has occurred 
> com.crystaldecisions.sdk.exception.SDKException$Unexpected:
> An unexpected error has occurred cause:java.io.IOException: CreateProcess:
> "C:\Program Files\Business Objects\BusinessObjects Enterprise
> 11\win32_x86\plugins\desktop\CrystalEnterprise.Report\ReportAdd.exe" -report
> "C:\Program Files\AR
> System\ARWebReportViewerITSM\reports\m11c23c11b16\4461F84D76B2DA56A269A03CB0FA2257\HPD5fOpenIncidents5fbyDaysActive.rpt"
> -newrpt -discard -version 1100 -thumbnail -outfile -token
> [EMAIL PROTECTED]>NLViXg \MO40NLViXg
>
>
> I am sure I am missing something related to defining paths. I appreciate
> all the help as I am struggling to get web reports to work. I have gone
> through a post by William Rentfrow (
> http://www.nabble.com/Re%3A-boxi-crystal-report-location---Longish-response-tt15828219.html)
> but am confused about the path settings
>
>
>
> Our configuration and steps done are:
>
>
>
> 1 - Solaris AR Server 7.1 & MidTier 7.0.01
>
> 1 – Business Objects XI Windows box running IIS 6
>
>  I need to get mid-tier solaris box(es) to display Crystal Reports on the
> web.
>
> (A) Configure Business Objects XI Server
>
> 1) Installed Java SDK 1.5.0_12
>
> 2) Installed Tomcat 5.5.23
>
> 3) Installed Apache Tomcat IIS Redirector 1.2.14.0
>
> 4) Restart IIS Admin Service
>
> 5) Checked Apache homepage (http://BO-server-name:8080) – OK
>
> 6) Installed the ARWebReportViewer.
>
> 7) Checked ARReports link (
> http://BO-server-name:8080/arreports/shared/config/configreport.jsp) - OK
>
>
>
> (B) Configure Report Settings on Solaris MidTier
>
> 1) Crystal/BO Report Engine Deployment - BOXI/Crystal Reports Server XI on
> a different machine without a mid tier
>
> 2) Reporting Working Directory - /apps/remedyitsm/mid-tier/reports (local
> folder on MidTier server)
>
> 3) BOXI/Crystal Report Server 11 Location - http://BO-server-name:8080
>
>
>
> (C) Update Crystal entry in "Report Type" form using User Tool
>
> Old Entry value – "Crystal10URL=$CRTLOC$/arreports/….."
>
> Updated to – "Crystal10URL= http://BO-server-name:8080/arreports/…..";
>
>
> (D) Configure Report Settings in ARWebReportViewer application on BO server
>
> 1) Reporting Working Directory* - C:\Program Files\AR
> System\ARWebReportViewerITSM\reports
>
> 2) CMS Machine Name* - BO-server-name
>
> 3) CMS Machine Connection Details –
>
> Chose Business Objects Enterprise XI
>
> AR System ODBC Data Source Name - ARSITSM
>
> CMS Folder Name - ARReports
> CMS User Name & Pwd – Used same access details after
> testing with BO URL  -
> http://BO-server-name/businessobjects/enterprise115/InfoView/logon.aspx
>
>
>
>
> Thanks.
>
> Regards,
> Prashant
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Re: AR System Log Display

[Shyam Attavar]

Also, there are special settings that I downloaded from the old Remedy 
download site that has some neat color coding for definition files as well 
in Notepad++. I use it for almost everything these days. You can download 
Notepad++ from sourceforge.

Cheers,
--
Shyam

"Schon, Stuart" <[EMAIL PROTECTED]> wrote in message 
news:<[EMAIL PROTECTED]>...

Hi

I use notepad++ which is free and does a very good job of resolving 
only files, its also excellent at viewing many other file types in full
colour i.e. XML


Regards
Stuart Schon
Remedy Solutions


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Misi Mladoniczky
Sent: 28 May 2008 06:03
To: arslist@ARSLIST.ORG
Subject: Re: AR System Log Display

Hi,

Use a decent editor that handelse CR-only. For instance Wordpad. You
will
find Wordpad in any Windows installation.

Another suggestion would be to use RRR|Log, that handles this and much
more:
http://rrr.se/tmp/rrrLogActiveLinks.html

The test-version works fine for ACTL-logging. The only limitation is for
50 API-calls or 500 SQL-calls.

Acces the test-version at: https://www.rrr.se/cgi/rrrlog/main

Use the search-page to review your Active Links nicely formatted.

   Best Regards - Misi, RRR AB, http://rrr.se

Products from RRR Scandinavia:
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
logs.
* RRR|Translator - Manage and automate your language translations.
Find these products, and many free tools and utilities, at
http://rrr.se.


Does anyone know what kind of setting can be changed to allow for the
wrapping on filter logging in ARLogDisplay.exe to work differently?



This is a snippet of filter logging in ARLogDisplay



 /* Tue May 27

2008

09:57:55.9910 */ Start filter processing (phase 1) -- Operation -

GET

on
CTM:CFG-ApplicationPreferences - IPF0001  
002916>

  


jsprenger> /* Tue May 27 2008
09:57:55.9910 */ End of filter processing (phase 1) -- Operation -

GET

on CTM:CFG-ApplicationPreferences - IPF0001  
  


jsprenger> /* Tue May 27 2008
09:57:56.0380 */ Start filter processing (phase 1) -- Operation -

GET

on
SYS:Date Time Query Rules - 001  


ID: 163993>   
/* Tue May 27 2008 09:57:56.0380 */ End of filter processing

(phase

1)

-- Operation - GET on SYS:Date Time Query Rules - 001



  


390620   >  /* Tue May 27 2008 10:02:31 */

 Start active link processing -- Operation - On Window Open

 For Schema - HPD:Help Desk

 On screen type - CREATE

 Checking HPD:SHR:SetGlobal_000_GetUserPreference (0)

 -> Passed qualification -- perform if actions

  0: Set Fields



As you can see, there is a pretty significant difference with the
wrapping.



Any help is appreciated.



User tool (and Server) 7.1.0 Patch 2  (Also seems to occur in other 7
versions)



Thanks,

Janie

 







___

UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

--
This message was scanned by ESVA and is believed to be clean.





___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

--

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"