Re: Help with identifying process id for a specific arserverd Thread on linux
It's not obvious is it?
I've created KB with an example of how to do it, which should be published
soon.
Mark
Preview Knowledge Article
Content Entry Fields
Title
How to Convert Thread IDs (TID) in AR Server Logs to Linux LWP IDs.
Problem
On Solaris the TID used in the AR Server logs is the same as that used by the
OS to identify individual threads. This makes it easy to take the output of
commands such as pstack/top and map the activity of a particular thread to
SQL/API being run by the server. This is not the case on Linux as the OS
utilities may show different LWP Ids that do no match the TID values used in
the server logs. For example, on startup the server thread log records the
creation of each thread;
THRD /* Tue Feb 26 2013 07:14:36.3408 */ Thread Id 1106151744 (thread number
9) on LIST queue started.
THRD /* Tue Feb 26 2013 07:14:36.3409 */ Thread Id 1086691648 (thread number
10) on PRIVATE queue 390680 started.
The server logs use the Thread Id value;
API TID: 1086691648 RPC ID: 001180 Queue: Prv:390680 Client-RPC:
390680USER: Remedy Application Service/* Tue Feb 26
2013 07:24:39.8051 */+GESARGetEntryStatistics
However, OS utilities show LWP Ids;
$ top
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
3533 remedy15 0 564m 160m 21m S 6.7 8.0 0:00.20 arserverd
3469 remedy15 0 564m 160m 21m S 0.0 8.0 0:00.48 arserverd
3470 remedy15 0 564m 160m 21m S 0.0 8.0 0:00.00 arserverd
3471 remedy15 0 564m 160m 21m S 0.0 8.0 0:00.00 arserverd
$ pstack
Thread 11 (Thread 0x40c59940 (LWP 3533)):
#0 0x003742e0a899 in pthread_cond_wait@@GLIBC_2.3.2 ()
#1 0x009df414 in WaitForRxSemaphore ()
#2 0x006c40a4 in GetCall ()
#3 0x0045490b in HandleRPCs ()
#4 0x007e9266 in WorkerThread ()
#5 0x009df95c in RestartableThreadMain ()
#6 0x009df8e7 in UnixThreadStartRoutine ()
#7 0x003742e06367 in start_thread () from /lib64/libpthread.so.0
#8 0x0037422d30ad in clone () from /lib64/libc.so.6
Solution
It is possible to find the mapping between the different Ids being used by
taking the hexadecimal thread number from the pstack output and converting it
to decimal.
In the example above we can see that Thread 0x40c59940 is also known as LWP
3533. The decimal value of 0x40c59940 can be found by using this Linux command
line, or a similar converter;
$ echo $((0x40c59940))
1086691648
LWP 3533 is the thread logged as TID: 1086691648 in the server logs. Note that
the Thread 11 in the pstack output does NOT match the thread number recorded in
the arthread.log file.
A full list of mappings for an arserverd process can be found using the gdb
debugger or pstack/gstack command;
WARNING - although the risk is low please be careful running this command
against a production system. These are debugging tools and it will suspend the
arserverd process for a moment which may cause problems on a very busy server.
If possible run this command when the server is not heavily loaded.
$ echo quit | gdb arserverd `pgrep arserverd` | grep LWP | sort -k5 | awk
'BEGIN {print TID\t\tLWP\t\tHEX;}{ printf %i\t%i\t\t%s\n, strtonum($3), $5,
$3}'
TIDLWP HEX
47883904271504 3469 0x2b8cd71ac490
1088616768 3470 0x40e2f940
1089669440 3471 0x40f30940
1092467008 3472 0x411db940
1095625024 3527 0x414de940
1102993728 3528 0x41be5940
1100888384 3529 0x419e3940
1101941056 3530 0x41ae4940
1084586304 3531 0x40a57940
1106151744 3532 0x41ee8940
1086691648 3533 0x40c59940
1094572352 3534 0x413dd940
1104046400 3535 0x41ce6940
1097730368 3536 0x416e0940
1107204416 3537 0x41fe9940
1093519680 3538 0x412dc940
1105099072 3539 0x41de7940
1085638976 3540 0x40b58940
1083533632 3542 0x40956940
1099835712 3547 0x418e2940
The same output can be found using pstack/gstack;
$ pstack `pgrep arserverd` | grep '(LWP ' | sort -k6 | awk 'BEGIN {print
TID\t\tLWP\t\tHEX;}{ printf %i\t%i\t\t%s\n, strtonum($4), $6, $4}'
TIDLWP HEX
47883904271504 3469 0x2b8cd71ac490
1088616768 3470 0x40e2f940
1089669440 3471 0x40f30940
1092467008 3472 0x411db940
1095625024 3527 0x414de940
1102993728 3528 0x41be5940
1100888384 3529 0x419e3940
1101941056
Re: WWRUG13?
In case anyone is wondering what Conference I was referring to when I mentioned Fusion: http://www.servicemanagementfusion.com/ As it turns out the week that was reserved at the Fairmont cannot be used now because Fusion has been scheduled that week, And BMC and many others need to be there. Daniel ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Help with identifying process id for a specific arserverd Thread on linux
Wow, that's fantastic, thanks
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Walters, Mark
Sent: Tuesday, February 26, 2013 5:17 AM
To: arslist@ARSLIST.ORG
Subject: Re: Help with identifying process id for a specific arserverd Thread
on linux
**
It's not obvious is it?
I've created KB with an example of how to do it, which should be published
soon.
Mark
Preview Knowledge Article
Content Entry Fields
Title
How to Convert Thread IDs (TID) in AR Server Logs to Linux LWP IDs.
Problem
On Solaris the TID used in the AR Server logs is the same as that used by the
OS to identify individual threads. This makes it easy to take the output of
commands such as pstack/top and map the activity of a particular thread to
SQL/API being run by the server. This is not the case on Linux as the OS
utilities may show different LWP Ids that do no match the TID values used in
the server logs. For example, on startup the server thread log records the
creation of each thread;
THRD /* Tue Feb 26 2013 07:14:36.3408 */ Thread Id 1106151744 (thread number
9) on LIST queue started.
THRD /* Tue Feb 26 2013 07:14:36.3409 */ Thread Id 1086691648 (thread number
10) on PRIVATE queue 390680 started.
The server logs use the Thread Id value;
API TID: 1086691648 RPC ID: 001180 Queue: Prv:390680 Client-RPC:
390680USER: Remedy Application Service/* Tue Feb 26
2013 07:24:39.8051 */+GESARGetEntryStatistics
However, OS utilities show LWP Ids;
$ top
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
3533 remedy15 0 564m 160m 21m S 6.7 8.0 0:00.20 arserverd
3469 remedy15 0 564m 160m 21m S 0.0 8.0 0:00.48 arserverd
3470 remedy15 0 564m 160m 21m S 0.0 8.0 0:00.00 arserverd
3471 remedy15 0 564m 160m 21m S 0.0 8.0 0:00.00 arserverd
$ pstack
Thread 11 (Thread 0x40c59940 (LWP 3533)):
#0 0x003742e0a899 in pthread_cond_wait@@GLIBC_2.3.2 ()
#1 0x009df414 in WaitForRxSemaphore ()
#2 0x006c40a4 in GetCall ()
#3 0x0045490b in HandleRPCs ()
#4 0x007e9266 in WorkerThread ()
#5 0x009df95c in RestartableThreadMain ()
#6 0x009df8e7 in UnixThreadStartRoutine ()
#7 0x003742e06367 in start_thread () from /lib64/libpthread.so.0
#8 0x0037422d30ad in clone () from /lib64/libc.so.6
Solution
It is possible to find the mapping between the different Ids being used by
taking the hexadecimal thread number from the pstack output and converting it
to decimal.
In the example above we can see that Thread 0x40c59940 is also known as LWP
3533. The decimal value of 0x40c59940 can be found by using this Linux command
line, or a similar converter;
$ echo $((0x40c59940))
1086691648
LWP 3533 is the thread logged as TID: 1086691648 in the server logs. Note that
the Thread 11 in the pstack output does NOT match the thread number recorded in
the arthread.log file.
A full list of mappings for an arserverd process can be found using the gdb
debugger or pstack/gstack command;
WARNING - although the risk is low please be careful running this command
against a production system. These are debugging tools and it will suspend the
arserverd process for a moment which may cause problems on a very busy server.
If possible run this command when the server is not heavily loaded.
$ echo quit | gdb arserverd `pgrep arserverd` | grep LWP | sort -k5 | awk
'BEGIN {print TID\t\tLWP\t\tHEX;}{ printf %i\t%i\t\t%s\n, strtonum($3), $5,
$3}'
TIDLWP HEX
47883904271504 3469 0x2b8cd71ac490
1088616768 3470 0x40e2f940
1089669440 3471 0x40f30940
1092467008 3472 0x411db940
1095625024 3527 0x414de940
1102993728 3528 0x41be5940
1100888384 3529 0x419e3940
1101941056 3530 0x41ae4940
1084586304 3531 0x40a57940
1106151744 3532 0x41ee8940
1086691648 3533 0x40c59940
1094572352 3534 0x413dd940
1104046400 3535 0x41ce6940
1097730368 3536 0x416e0940
1107204416 3537 0x41fe9940
1093519680 3538 0x412dc940
1105099072 3539 0x41de7940
1085638976 3540 0x40b58940
1083533632 3542 0x40956940
1099835712 3547 0x418e2940
The same output can be found using pstack/gstack;
$ pstack `pgrep arserverd` | grep '(LWP ' | sort -k6 | awk 'BEGIN {print
TID\t\tLWP\t\tHEX;}{ printf %i\t%i\t\t%s\n, strtonum($4), $6, $4}'
TIDLWP HEX
47883904271504 3469 0x2b8cd71ac490
1088616768 3470
Re: New custom field oddity
For what it's worth, I've flushed both the browser and mid-tier cache multiple times without change. With the caches flushed, I'm not sure why these fields would perform differently between browsers. Any other ideas? I've looked at the client logs both in Chrome and IE and they both look the same from my untrained eye. The AL that sets the field value is working in the same way in both logs. Thanks again, Ron -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky Sent: Monday, February 25, 2013 12:49 PM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity Hi, The Window-Open and Window-Loaded does not happen that much in ITSM76 with the Inline-Type form display used. The Display should always happen when you search and display a new ticket though. The way BMC has build the Inline forms for ITSM76, it pretty much hides/shows the form you are currently accessing, but keeps the form loaded in a hidden View Field. The other thing that might be problematic is the Mid-Tier Cache. I have sometimes had severe problems getting Inline form caches to be recached. I suspect that you have something cached for the browser that is not yet working. Either in the client-browser-cache or on the Mid-Tier server. The client-side log I was talking about was what you see in Mid-Tier when you turn on logging for a user. This is done in the User Preference form. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11/12): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. The AL's are triggered on display, window open, and window loaded. When you say client side logging, I hear user tool. Both of these fields work perfectly within the user tool if that makes any difference. Which log should be enabled for web clients? Is that mid-tier logging? Thanks, Ron -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky Sent: Monday, February 25, 2013 11:23 AM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity Hi, What exactly triggers the ACTL that fill in the fields? What does your client side logging say? Have you compared the two? Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11/12): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se Hi all, I created a new field on both the HPD:Help Desk and CHG:Infrastructure Change forms. They are both similar in that they are read-only display fields. Each one has an active link that gives the field its value. The AL is working fine as the value is correct on both. The issue I'm having is browser based. Both fields work correctly in IE. However, Only the INC field works in FF and Chrome. The field is there and visible, but I'm unable to interact with it. I can't select/highlight/copy the field contents in those browsers. Any thoughts why one field works but not the other? Is there some setting that I'm missing? Thanks in advance, Ron ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years . ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
ticket direct URLs and login sessions
Hello, We recently updated our notification templates to contain HTML direct links to incidents and changes. We disabled the default link at the beginning of all messages and created our own. An example of our INC URL is this: http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Deskserver=AR_SERVERqual='Incident ID*%2B'%3D%22INC_NUMBER%22 This is the odd behavior and it happens in all browsers. · If a user is not logged into the mid-tier, the link requires authentication and then they're taken directly to the Incident. Normal and as expected. · If the user (not already logged into the mid-tier) uses the direct link, logs in, accesses the ticket AND THEN (without logging out) clicks on another direct link from a different email notification (or the same), they are taken directly to that ticket without any required authentication. Normal and as expected. · If the user had already been logged into the mid-tier, the direct link in the notification still requires authentication instead of taking them directly in. Odd o If the user declines the authentication (closes the browser tab/window) and goes back to their original, already logged in session, that session has now been logged out and they have to re-authenticate (Session is invalid or has timed out. Please reload page to log in again. (ARERR 9201)). Annoying Now, I've done some more testing. I re-enabled the 'Add URL' on the notification filter that has the form of: http://MID_TIER:8080/arsys//servlet/ViewFormServlet?form=NTE%3aNotifierserver=AR_SERVEReid=NTS00772848 (-- I don't know what the NTS number relates to) The new notifications (in Dev) have both URL types. With this being the case, I can't make it fail as before. I've also re-removed the 'Add URL' from the filter and it still won't fail in that environment though our production environment is still acting odd. This feels like something has gotten cached that works for the filter URL but not for my direct one. Anyone have any idea what's going on here? Thanks again, Ron ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: New custom field oddity
Ron, This is a real shot in the dark but is there any chance that the blank label of an adjacent field is laying on top of this field? The only thing I can think of is that one browser puts your field in the foreground and the other puts it in the background. Mark -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Tuesday, February 26, 2013 11:25 AM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity For what it's worth, I've flushed both the browser and mid-tier cache multiple times without change. With the caches flushed, I'm not sure why these fields would perform differently between browsers. Any other ideas? I've looked at the client logs both in Chrome and IE and they both look the same from my untrained eye. The AL that sets the field value is working in the same way in both logs. Thanks again, Ron -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky Sent: Monday, February 25, 2013 12:49 PM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity Hi, The Window-Open and Window-Loaded does not happen that much in ITSM76 with the Inline-Type form display used. The Display should always happen when you search and display a new ticket though. The way BMC has build the Inline forms for ITSM76, it pretty much hides/shows the form you are currently accessing, but keeps the form loaded in a hidden View Field. The other thing that might be problematic is the Mid-Tier Cache. I have sometimes had severe problems getting Inline form caches to be recached. I suspect that you have something cached for the browser that is not yet working. Either in the client-browser-cache or on the Mid-Tier server. The client-side log I was talking about was what you see in Mid-Tier when you turn on logging for a user. This is done in the User Preference form. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11/12): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. The AL's are triggered on display, window open, and window loaded. When you say client side logging, I hear user tool. Both of these fields work perfectly within the user tool if that makes any difference. Which log should be enabled for web clients? Is that mid-tier logging? Thanks, Ron -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky Sent: Monday, February 25, 2013 11:23 AM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity Hi, What exactly triggers the ACTL that fill in the fields? What does your client side logging say? Have you compared the two? Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11/12): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se Hi all, I created a new field on both the HPD:Help Desk and CHG:Infrastructure Change forms. They are both similar in that they are read-only display fields. Each one has an active link that gives the field its value. The AL is working fine as the value is correct on both. The issue I'm having is browser based. Both fields work correctly in IE. However, Only the INC field works in FF and Chrome. The field is there and visible, but I'm unable to interact with it. I can't select/highlight/copy the field contents in those browsers. Any thoughts why one field works but not the other? Is there some setting that I'm missing? Thanks in advance, Ron _ __ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years . __ _ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years This e-mail is the property of NaviSite, Inc. It is intended only for the person or entity to which it is addressed and may contain information that is
Re: ticket direct URLs and login sessions
HI Ron, Just learning this myself. With the ITSM Notification Engine, an OTB notification when the Incident is assigned to a person, creates a record in the NTE:Notifier form and the engine send out the email. It appears that when you select the URL, it take you to the NTE:Notifier record and then workflow redirects you to the Incident, change, etc. The ITSM Notification Engine Guide explains this better than I am doing here. Also OTB, 21 days after the notification is sent, the NTE:Notifier record is archive/deleted and the URL is no longer valid. Mark From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Tuesday, February 26, 2013 12:49 PM To: arslist@ARSLIST.ORG Subject: ticket direct URLs and login sessions ** Hello, We recently updated our notification templates to contain HTML direct links to incidents and changes. We disabled the default link at the beginning of all messages and created our own. An example of our INC URL is this: http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Deskserver=AR_SERVERqual='Incident ID*%2B'%3D%22INC_NUMBER%22 This is the odd behavior and it happens in all browsers. · If a user is not logged into the mid-tier, the link requires authentication and then they're taken directly to the Incident. Normal and as expected. · If the user (not already logged into the mid-tier) uses the direct link, logs in, accesses the ticket AND THEN (without logging out) clicks on another direct link from a different email notification (or the same), they are taken directly to that ticket without any required authentication. Normal and as expected. · If the user had already been logged into the mid-tier, the direct link in the notification still requires authentication instead of taking them directly in. Odd o If the user declines the authentication (closes the browser tab/window) and goes back to their original, already logged in session, that session has now been logged out and they have to re-authenticate (Session is invalid or has timed out. Please reload page to log in again. (ARERR 9201)). Annoying Now, I've done some more testing. I re-enabled the 'Add URL' on the notification filter that has the form of: http://MID_TIER:8080/arsys//servlet/ViewFormServlet?form=NTE%3aNotifierserver=AR_SERVEReid=NTS00772848http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=NTE%3aNotifierserver=AR_SERVEReid=NTS00772848 (-- I don't know what the NTS number relates to) The new notifications (in Dev) have both URL types. With this being the case, I can't make it fail as before. I've also re-removed the 'Add URL' from the filter and it still won't fail in that environment though our production environment is still acting odd. This feels like something has gotten cached that works for the filter URL but not for my direct one. Anyone have any idea what's going on here? Thanks again, Ron _ARSlist: Where the Answers Are and have been for 20 years_ This e-mail is the property of NaviSite, Inc. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: ticket direct URLs and login sessions
Excellent. That makes sense. The 21 day expiration also makes sense with when those links stopped working. Now to figure out the authentication oddity. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brittain, Mark Sent: Tuesday, February 26, 2013 10:06 AM To: arslist@ARSLIST.ORG Subject: Re: ticket direct URLs and login sessions ** HI Ron, Just learning this myself. With the ITSM Notification Engine, an OTB notification when the Incident is assigned to a person, creates a record in the NTE:Notifier form and the engine send out the email. It appears that when you select the URL, it take you to the NTE:Notifier record and then workflow redirects you to the Incident, change, etc. The ITSM Notification Engine Guide explains this better than I am doing here. Also OTB, 21 days after the notification is sent, the NTE:Notifier record is archive/deleted and the URL is no longer valid. Mark From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Tuesday, February 26, 2013 12:49 PM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: ticket direct URLs and login sessions ** Hello, We recently updated our notification templates to contain HTML direct links to incidents and changes. We disabled the default link at the beginning of all messages and created our own. An example of our INC URL is this: http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Deskserver=AR_SERVERqual='Incident ID*%2B'%3D%22INC_NUMBER%22 This is the odd behavior and it happens in all browsers. · If a user is not logged into the mid-tier, the link requires authentication and then they're taken directly to the Incident. Normal and as expected. · If the user (not already logged into the mid-tier) uses the direct link, logs in, accesses the ticket AND THEN (without logging out) clicks on another direct link from a different email notification (or the same), they are taken directly to that ticket without any required authentication. Normal and as expected. · If the user had already been logged into the mid-tier, the direct link in the notification still requires authentication instead of taking them directly in. Odd o If the user declines the authentication (closes the browser tab/window) and goes back to their original, already logged in session, that session has now been logged out and they have to re-authenticate (Session is invalid or has timed out. Please reload page to log in again. (ARERR 9201)). Annoying Now, I've done some more testing. I re-enabled the 'Add URL' on the notification filter that has the form of: http://MID_TIER:8080/arsys//servlet/ViewFormServlet?form=NTE%3aNotifierserver=AR_SERVEReid=NTS00772848http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=NTE%3aNotifierserver=AR_SERVEReid=NTS00772848 (-- I don't know what the NTS number relates to) The new notifications (in Dev) have both URL types. With this being the case, I can't make it fail as before. I've also re-removed the 'Add URL' from the filter and it still won't fail in that environment though our production environment is still acting odd. This feels like something has gotten cached that works for the filter URL but not for my direct one. Anyone have any idea what's going on here? Thanks again, Ron _ARSlist: Where the Answers Are and have been for 20 years_ This e-mail is the property of NaviSite, Inc. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: New custom field oddity
I don't think so. I've moved the field around to various parts of the form with no changes. Weird that it works in IE and the user tool but not the other browsers. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Brittain, Mark Sent: Tuesday, February 26, 2013 9:54 AM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity Ron, This is a real shot in the dark but is there any chance that the blank label of an adjacent field is laying on top of this field? The only thing I can think of is that one browser puts your field in the foreground and the other puts it in the background. Mark -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Tuesday, February 26, 2013 11:25 AM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity For what it's worth, I've flushed both the browser and mid-tier cache multiple times without change. With the caches flushed, I'm not sure why these fields would perform differently between browsers. Any other ideas? I've looked at the client logs both in Chrome and IE and they both look the same from my untrained eye. The AL that sets the field value is working in the same way in both logs. Thanks again, Ron -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky Sent: Monday, February 25, 2013 12:49 PM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity Hi, The Window-Open and Window-Loaded does not happen that much in ITSM76 with the Inline-Type form display used. The Display should always happen when you search and display a new ticket though. The way BMC has build the Inline forms for ITSM76, it pretty much hides/shows the form you are currently accessing, but keeps the form loaded in a hidden View Field. The other thing that might be problematic is the Mid-Tier Cache. I have sometimes had severe problems getting Inline form caches to be recached. I suspect that you have something cached for the browser that is not yet working. Either in the client-browser-cache or on the Mid-Tier server. The client-side log I was talking about was what you see in Mid-Tier when you turn on logging for a user. This is done in the User Preference form. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11/12): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. The AL's are triggered on display, window open, and window loaded. When you say client side logging, I hear user tool. Both of these fields work perfectly within the user tool if that makes any difference. Which log should be enabled for web clients? Is that mid-tier logging? Thanks, Ron -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky Sent: Monday, February 25, 2013 11:23 AM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity Hi, What exactly triggers the ACTL that fill in the fields? What does your client side logging say? Have you compared the two? Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11/12): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se Hi all, I created a new field on both the HPD:Help Desk and CHG:Infrastructure Change forms. They are both similar in that they are read-only display fields. Each one has an active link that gives the field its value. The AL is working fine as the value is correct on both. The issue I'm having is browser based. Both fields work correctly in IE. However, Only the INC field works in FF and Chrome. The field is there and visible, but I'm unable to interact with it. I can't select/highlight/copy the field contents in those browsers. Any thoughts why one field works but not the other? Is there some setting that I'm missing? Thanks in advance, Ron _ __ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years . __ _ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at
Re: ticket direct URLs and login sessions
Ron, I don't have an answer for the question...but I can tell you what the NTS number is :) That is a control form that all notifications are sent out through, and there is workflow on it that opens the proper form that needs to be opened for that notification. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Tuesday, February 26, 2013 10:49 AM To: arslist@ARSLIST.ORG Subject: ticket direct URLs and login sessions ** Hello, We recently updated our notification templates to contain HTML direct links to incidents and changes. We disabled the default link at the beginning of all messages and created our own. An example of our INC URL is this: http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Deskserver=AR_SERVERqual='Incident ID*%2B'%3D%22INC_NUMBER%22 This is the odd behavior and it happens in all browsers. · If a user is not logged into the mid-tier, the link requires authentication and then they're taken directly to the Incident. Normal and as expected. · If the user (not already logged into the mid-tier) uses the direct link, logs in, accesses the ticket AND THEN (without logging out) clicks on another direct link from a different email notification (or the same), they are taken directly to that ticket without any required authentication. Normal and as expected. · If the user had already been logged into the mid-tier, the direct link in the notification still requires authentication instead of taking them directly in. Odd o If the user declines the authentication (closes the browser tab/window) and goes back to their original, already logged in session, that session has now been logged out and they have to re-authenticate (Session is invalid or has timed out. Please reload page to log in again. (ARERR 9201)). Annoying Now, I've done some more testing. I re-enabled the 'Add URL' on the notification filter that has the form of: http://MID_TIER:8080/arsys//servlet/ViewFormServlet?form=NTE%3aNotifierserver=AR_SERVEReid=NTS00772848http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=NTE%3aNotifierserver=AR_SERVEReid=NTS00772848 (-- I don't know what the NTS number relates to) The new notifications (in Dev) have both URL types. With this being the case, I can't make it fail as before. I've also re-removed the 'Add URL' from the filter and it still won't fail in that environment though our production environment is still acting odd. This feels like something has gotten cached that works for the filter URL but not for my direct one. Anyone have any idea what's going on here? Thanks again, Ron _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: ticket direct URLs and login sessions
Ron, One url lists ...arsys//servlet... (two slashes) and the other ...arsys/servlet... Is that a typo, or might it have something to do with the authentication issue? David Durling University of Georgia From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Longwing, LJ CTR MDA/IC Sent: Tuesday, February 26, 2013 2:09 PM To: arslist@ARSLIST.ORG Subject: Re: ticket direct URLs and login sessions ** Ron, I don't have an answer for the question...but I can tell you what the NTS number is :) That is a control form that all notifications are sent out through, and there is workflow on it that opens the proper form that needs to be opened for that notification. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Tuesday, February 26, 2013 10:49 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: ticket direct URLs and login sessions ** Hello, We recently updated our notification templates to contain HTML direct links to incidents and changes. We disabled the default link at the beginning of all messages and created our own. An example of our INC URL is this: http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Deskserver=AR_SERVERqual='Incident ID*%2B'%3D%22INC_NUMBER%22 This is the odd behavior and it happens in all browsers. * If a user is not logged into the mid-tier, the link requires authentication and then they're taken directly to the Incident. Normal and as expected. * If the user (not already logged into the mid-tier) uses the direct link, logs in, accesses the ticket AND THEN (without logging out) clicks on another direct link from a different email notification (or the same), they are taken directly to that ticket without any required authentication. Normal and as expected. * If the user had already been logged into the mid-tier, the direct link in the notification still requires authentication instead of taking them directly in. Odd o If the user declines the authentication (closes the browser tab/window) and goes back to their original, already logged in session, that session has now been logged out and they have to re-authenticate (Session is invalid or has timed out. Please reload page to log in again. (ARERR 9201)). Annoying Now, I've done some more testing. I re-enabled the 'Add URL' on the notification filter that has the form of: http://MID_TIER:8080/arsys//servlet/ViewFormServlet?form=NTE%3aNotifierserver=AR_SERVEReid=NTS00772848http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=NTE%3aNotifierserver=AR_SERVEReid=NTS00772848 (-- I don't know what the NTS number relates to) The new notifications (in Dev) have both URL types. With this being the case, I can't make it fail as before. I've also re-removed the 'Add URL' from the filter and it still won't fail in that environment though our production environment is still acting odd. This feels like something has gotten cached that works for the filter URL but not for my direct one. Anyone have any idea what's going on here? Thanks again, Ron _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Integrating Approval with Problem Management
Hi List, Here’s an interesting one – the customer wants an ability to have “approval” for the “problems tickets” – because of multiple reasons. I understand this might not be a recommended customization – and can alternatively use approval tasks etc... been there, done that... Has anyone done this/similar with AE and PM? Any suggestion/recommendation/things-to-be-aware-of for the implementation? Cheers Rishi ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Suspect actions in a macro..
Thanks Fred, That’s what I suspected. I didn’t have too many ‘good macros’ to compare as I saw a number of them that had this same ‘problem’. I’m suspecting that the client tool is actually running that search twice. I haven’t done tests to confirm that but if those instructions appear twice within the macro I don’t see how it would perform it only once. I may have some clean up to do. I have no idea why they have these statements twice – these were perhaps developed by end users and not the developer is my best guess. Since the macro recording process does not actually display the contents of what it has already recorded, it might have been easy for the end user to repeat some actions without suspecting the consequence. Joe _ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Monday, February 25, 2013 6:05 PM To: arslist@ARSLIST.ORG Subject: Re: Suspect actions in a macro.. I just looked at a couple here (I can’t believe I still had some macros on a network share) were in the format of Set Working Schema Perform Query Form-open Form-entry-list Form-final: modify So, Yes I believe lines 5 and line 6 are unnecessary and can be deleted. Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe D'Souza Sent: Monday, February 25, 2013 4:38 PM To: arslist@ARSLIST.ORG Subject: Suspect actions in a macro.. ** When I used armacroed for checking out a macro definition, this is what it returned: 1) Set Current Working Schema to FormName (ServerName) 2) Perform Query Query bar -- '536871083' = $Start Date$ AND '536871083' = $End Date$ AND '536870932' = Tier2 Customer Support AND '7' = Closed 3) ** Unknown command ** Form-open: 4) ** Unknown command ** Form-entry-list: 0 5) Perform Query Query bar -- '536871083' = $Start Date$ AND '536871083' = $End Date$ AND '536870932' = Tier2 Customer Support AND '7' = Closed 6) ** Unknown command ** Form-entry-list: 0 7) ** Unknown command ** Form-final: modify☺@ I find it a little suspicious that the same action/query, is repeated twice. Since I did not develop it I cannot say with certainty if this was actually recorded twice. I suspect it was. Would this mean that this macro would perform that same query twice? I am yet to test the run of these macros to log if it actually runs the query twice. What do you’ll think? Is line 5 and 6 unnecessary and will repeat the query the second time? Joe _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Suspect actions in a macro..
Hi, I think it is the Form-Final that actually performs the search. Why not start client-side API-logging and see what happens? Why not record new macros in the user client? Macros still exists, right? Best Regards - Misi, RRR AB, http://rrr.se Thanks Fred, That’s what I suspected. I didn’t have too many ‘good macros’ to compare as I saw a number of them that had this same ‘problem’. I’m suspecting that the client tool is actually running that search twice. I haven’t done tests to confirm that but if those instructions appear twice within the macro I don’t see how it would perform it only once. I may have some clean up to do. I have no idea why they have these statements twice – these were perhaps developed by end users and not the developer is my best guess. Since the macro recording process does not actually display the contents of what it has already recorded, it might have been easy for the end user to repeat some actions without suspecting the consequence. Joe _ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Monday, February 25, 2013 6:05 PM To: arslist@ARSLIST.ORG Subject: Re: Suspect actions in a macro.. I just looked at a couple here (I can’t believe I still had some macros on a network share) were in the format of Set Working Schema Perform Query Form-open Form-entry-list Form-final: modify So, Yes I believe lines 5 and line 6 are unnecessary and can be deleted. Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe D'Souza Sent: Monday, February 25, 2013 4:38 PM To: arslist@ARSLIST.ORG Subject: Suspect actions in a macro.. ** When I used armacroed for checking out a macro definition, this is what it returned: 1) Set Current Working Schema to FormName (ServerName) 2) Perform Query Query bar -- '536871083' = $Start Date$ AND '536871083' = $End Date$ AND '536870932' = Tier2 Customer Support AND '7' = Closed 3) ** Unknown command ** Form-open: 4) ** Unknown command ** Form-entry-list: 0 5) Perform Query Query bar -- '536871083' = $Start Date$ AND '536871083' = $End Date$ AND '536870932' = Tier2 Customer Support AND '7' = Closed 6) ** Unknown command ** Form-entry-list: 0 7) ** Unknown command ** Form-final: modify☺@ I find it a little suspicious that the same action/query, is repeated twice. Since I did not develop it I cannot say with certainty if this was actually recorded twice. I suspect it was. Would this mean that this macro would perform that same query twice? I am yet to test the run of these macros to log if it actually runs the query twice. What do you’ll think? Is line 5 and 6 unnecessary and will repeat the query the second time? Joe _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: ticket direct URLs and login sessions
I did notice that difference and it is not a typo. It comes from the OOTB link from the filter notification. I'll give it a shot to see if it makes any difference. Not sure why this seems like so much black magic. Thanks, Ron From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of David Durling Sent: Tuesday, February 26, 2013 11:26 AM To: arslist@ARSLIST.ORG Subject: Re: ticket direct URLs and login sessions ** Ron, One url lists ...arsys//servlet... (two slashes) and the other ...arsys/servlet... Is that a typo, or might it have something to do with the authentication issue? David Durling University of Georgia From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Longwing, LJ CTR MDA/IC Sent: Tuesday, February 26, 2013 2:09 PM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: Re: ticket direct URLs and login sessions ** Ron, I don't have an answer for the question...but I can tell you what the NTS number is :) That is a control form that all notifications are sent out through, and there is workflow on it that opens the proper form that needs to be opened for that notification. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Tuesday, February 26, 2013 10:49 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: ticket direct URLs and login sessions ** Hello, We recently updated our notification templates to contain HTML direct links to incidents and changes. We disabled the default link at the beginning of all messages and created our own. An example of our INC URL is this: http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Deskserver=AR_SERVERqual='Incident ID*%2B'%3D%22INC_NUMBER%22 This is the odd behavior and it happens in all browsers. · If a user is not logged into the mid-tier, the link requires authentication and then they're taken directly to the Incident. Normal and as expected. · If the user (not already logged into the mid-tier) uses the direct link, logs in, accesses the ticket AND THEN (without logging out) clicks on another direct link from a different email notification (or the same), they are taken directly to that ticket without any required authentication. Normal and as expected. · If the user had already been logged into the mid-tier, the direct link in the notification still requires authentication instead of taking them directly in. Odd o If the user declines the authentication (closes the browser tab/window) and goes back to their original, already logged in session, that session has now been logged out and they have to re-authenticate (Session is invalid or has timed out. Please reload page to log in again. (ARERR 9201)). Annoying Now, I've done some more testing. I re-enabled the 'Add URL' on the notification filter that has the form of: http://MID_TIER:8080/arsys//servlet/ViewFormServlet?form=NTE%3aNotifierserver=AR_SERVEReid=NTS00772848http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=NTE%3aNotifierserver=AR_SERVEReid=NTS00772848 (-- I don't know what the NTS number relates to) The new notifications (in Dev) have both URL types. With this being the case, I can't make it fail as before. I've also re-removed the 'Add URL' from the filter and it still won't fail in that environment though our production environment is still acting odd. This feels like something has gotten cached that works for the filter URL but not for my direct one. Anyone have any idea what's going on here? Thanks again, Ron _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: ticket direct URLs and login sessions
Thanks for the info. Ron From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Longwing, LJ CTR MDA/IC Sent: Tuesday, February 26, 2013 11:09 AM To: arslist@ARSLIST.ORG Subject: Re: ticket direct URLs and login sessions ** Ron, I don't have an answer for the question...but I can tell you what the NTS number is :) That is a control form that all notifications are sent out through, and there is workflow on it that opens the proper form that needs to be opened for that notification. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Tuesday, February 26, 2013 10:49 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: ticket direct URLs and login sessions ** Hello, We recently updated our notification templates to contain HTML direct links to incidents and changes. We disabled the default link at the beginning of all messages and created our own. An example of our INC URL is this: http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Deskserver=AR_SERVERqual='Incident ID*%2B'%3D%22INC_NUMBER%22 This is the odd behavior and it happens in all browsers. · If a user is not logged into the mid-tier, the link requires authentication and then they're taken directly to the Incident. Normal and as expected. · If the user (not already logged into the mid-tier) uses the direct link, logs in, accesses the ticket AND THEN (without logging out) clicks on another direct link from a different email notification (or the same), they are taken directly to that ticket without any required authentication. Normal and as expected. · If the user had already been logged into the mid-tier, the direct link in the notification still requires authentication instead of taking them directly in. Odd o If the user declines the authentication (closes the browser tab/window) and goes back to their original, already logged in session, that session has now been logged out and they have to re-authenticate (Session is invalid or has timed out. Please reload page to log in again. (ARERR 9201)). Annoying Now, I've done some more testing. I re-enabled the 'Add URL' on the notification filter that has the form of: http://MID_TIER:8080/arsys//servlet/ViewFormServlet?form=NTE%3aNotifierserver=AR_SERVEReid=NTS00772848http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=NTE%3aNotifierserver=AR_SERVEReid=NTS00772848 (-- I don't know what the NTS number relates to) The new notifications (in Dev) have both URL types. With this being the case, I can't make it fail as before. I've also re-removed the 'Add URL' from the filter and it still won't fail in that environment though our production environment is still acting odd. This feels like something has gotten cached that works for the filter URL but not for my direct one. Anyone have any idea what's going on here? Thanks again, Ron _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Tables/views in Analytics
Does anyone have a list of the tables and/or views BMC analytics uses in its reporting? We have a universe setup with business objects and would like to replicate the reports in analytics. Thanks, Paul Hodgdon UNH ITSM Applications Manager Sent from my iPad ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: [EXTERNAL] Tables/views in Analytics
Paul: Supposedly at least some of that information is available in KA345616 in the BMC Knowledge Base. But good luck finding it. I sure can't. However, I found a document I downloaded from somewhere on BMC's website back in June of 2011 that is probably similar to what's in the KBA article, and that is Analytics for AR 7.5 7.6 and BOXI 3.1. I think that is slightly out of date for our installation. I don't even remember where I found this thing now - I just remember thinking it looked useful. If it's reasonably close to your version and you are interested, I'd be happy to send it to you offline as an attachment. Natalie Stroud SAIC @ Sandia National Laboratories ARS-ITSM Tester Albuquerque, NM USA nkst...@sandia.gov ITSM 7.6.04 SP2 - Windows 2003 - SQL Server 2008 -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Hodgdon, Paul Sent: Tuesday, February 26, 2013 2:18 PM To: arslist@ARSLIST.ORG Subject: [EXTERNAL] Tables/views in Analytics Does anyone have a list of the tables and/or views BMC analytics uses in its reporting? We have a universe setup with business objects and would like to replicate the reports in analytics. Thanks, Paul Hodgdon UNH ITSM Applications Manager Sent from my iPad ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: New custom field oddity
After some more testing, I can rule out the AL. I simply created a new character field on both forms, gave them a default value, gave them 'display' for their entry modes, and changed their name/display from 'character field' to 'test field'. I added them both to their respective 'work detail' tabs in an open space for visibility. Flushed cache. In Chrome/FF, when creating a new record, the field on HPD:Help Desk has it's default value that can be highlighted/copied/pasted etc. The field on CHG:Infrastructure Change can do no such thing though it is accessible within IE. I'm still pretty green at this but that just seems stupid. Am I missing a setting? Thoughts? Thanks. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pargeter, Christie :CO IS Sent: Monday, February 25, 2013 3:16 PM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity ** Did you flush your MidTier cache after you added the field? From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Monday, February 25, 2013 10:57 AM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG Subject: New custom field oddity ** Hi all, I created a new field on both the HPD:Help Desk and CHG:Infrastructure Change forms. They are both similar in that they are read-only display fields. Each one has an active link that gives the field its value. The AL is working fine as the value is correct on both. The issue I'm having is browser based. Both fields work correctly in IE. However, Only the INC field works in FF and Chrome. The field is there and visible, but I'm unable to interact with it. I can't select/highlight/copy the field contents in those browsers. Any thoughts why one field works but not the other? Is there some setting that I'm missing? Thanks in advance, Ron _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: New custom field oddity
Ron, What version of Remedy and what version of Mid-Tier are you running? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Tuesday, February 26, 2013 4:28 PM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity ** After some more testing, I can rule out the AL. I simply created a new character field on both forms, gave them a default value, gave them 'display' for their entry modes, and changed their name/display from 'character field' to 'test field'. I added them both to their respective 'work detail' tabs in an open space for visibility. Flushed cache. In Chrome/FF, when creating a new record, the field on HPD:Help Desk has it's default value that can be highlighted/copied/pasted etc. The field on CHG:Infrastructure Change can do no such thing though it is accessible within IE. I'm still pretty green at this but that just seems stupid. Am I missing a setting? Thoughts? Thanks. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pargeter, Christie :CO IS Sent: Monday, February 25, 2013 3:16 PM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity ** Did you flush your MidTier cache after you added the field? From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Monday, February 25, 2013 10:57 AM To: arslist@ARSLIST.ORG Subject: New custom field oddity ** Hi all, I created a new field on both the HPD:Help Desk and CHG:Infrastructure Change forms. They are both similar in that they are read-only display fields. Each one has an active link that gives the field its value. The AL is working fine as the value is correct on both. The issue I'm having is browser based. Both fields work correctly in IE. However, Only the INC field works in FF and Chrome. The field is there and visible, but I'm unable to interact with it. I can't select/highlight/copy the field contents in those browsers. Any thoughts why one field works but not the other? Is there some setting that I'm missing? Thanks in advance, Ron _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Suspect actions in a macro..
Yes I need to do that, but there's another 'slight' problem that I need to address before doing that :-) The slight problem is, that the macros that have this particular problem, have underlying tables that are in excess of 200K records, one of them is actually having a record count of 6.5 million. And many of the columns used in the where part of the queries are not indexed, resulting in the operation chocking the server to near death. Which is why I ended up inspecting all those many macros to find out what I can from them. Obviously now is not the time to run those macros to fire the searches. I am in the process of collecting data to optimize these queries in the first place, so once that is done and implemented, I plan to tackle the problem of those queries appearing twice. Thanks for your suggestions anyways.. How's the little girl doing? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky Sent: Tuesday, February 26, 2013 3:24 PM To: arslist@ARSLIST.ORG Subject: Re: Suspect actions in a macro.. Hi, I think it is the Form-Final that actually performs the search. Why not start client-side API-logging and see what happens? Why not record new macros in the user client? Macros still exists, right? Best Regards - Misi, RRR AB, http://rrr.se Thanks Fred, That’s what I suspected. I didn’t have too many ‘good macros’ to compare as I saw a number of them that had this same ‘problem’. I’m suspecting that the client tool is actually running that search twice. I haven’t done tests to confirm that but if those instructions appear twice within the macro I don’t see how it would perform it only once. I may have some clean up to do. I have no idea why they have these statements twice – these were perhaps developed by end users and not the developer is my best guess. Since the macro recording process does not actually display the contents of what it has already recorded, it might have been easy for the end user to repeat some actions without suspecting the consequence. Joe _ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Monday, February 25, 2013 6:05 PM To: arslist@ARSLIST.ORG Subject: Re: Suspect actions in a macro.. I just looked at a couple here (I can’t believe I still had some macros on a network share) were in the format of Set Working Schema Perform Query Form-open Form-entry-list Form-final: modify So, Yes I believe lines 5 and line 6 are unnecessary and can be deleted. Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe D'Souza Sent: Monday, February 25, 2013 4:38 PM To: arslist@ARSLIST.ORG Subject: Suspect actions in a macro.. ** When I used armacroed for checking out a macro definition, this is what it returned: 1) Set Current Working Schema to FormName (ServerName) 2) Perform Query Query bar -- '536871083' = $Start Date$ AND '536871083' = $End Date$ AND '536870932' = Tier2 Customer Support AND '7' = Closed 3) ** Unknown command ** Form-open: 4) ** Unknown command ** Form-entry-list: 0 5) Perform Query Query bar -- '536871083' = $Start Date$ AND '536871083' = $End Date$ AND '536870932' = Tier2 Customer Support AND '7' = Closed 6) ** Unknown command ** Form-entry-list: 0 7) ** Unknown command ** Form-final: modify☺@ I find it a little suspicious that the same action/query, is repeated twice. Since I did not develop it I cannot say with certainty if this was actually recorded twice. I suspect it was. Would this mean that this macro would perform that same query twice? I am yet to test the run of these macros to log if it actually runs the query twice. What do you’ll think? Is line 5 and 6 unnecessary and will repeat the query the second time? Joe _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: ticket direct URLs and login sessions
Hi Peter, Few things :) In the system generated link: http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=NTE%3aNotifierserver=AR_SERVEReid=NTS00772848 the NTS00772848 stand for entry id in default request id or in the case of NTE:Notifier the Notification ID field id 1 (NTS just a prefix in the field), so eid= stands for bring record number(entry id) NTS00772848 On the HPD:Help Desk form the Incident ID is not Entry ID which has field ID 1, so you can't use eid= and have to use qual= qualification instead with encoded qualification string where you refer the field by name or by db id. You got it almost right, but looks like you have ' and a space that should be encoded in your link. Try this http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Deskserver=AR_SERVERqual=%27Incident%20ID*%2B%27%3D%22INC_NUMBER%22 Or this by field ID: http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Deskserver=AR_SERVERqual=%27100161%27%3D%22INC_NUMBER%22 Also, check that MID_TIER server name is the same in the link and in the path when your user logged in. Could be host name in one and FQDN in the other. By the way the encoder is at http://MID_TIER:8080/arsys/shared/ar_url_encoder.jsp Hope this helps Nik From: Peters, Ron rpet...@columbia.com To: arslist@ARSLIST.ORG Sent: Tuesday, February 26, 2013 10:48 AM Subject: ticket direct URLs and login sessions ** Hello, We recently updated our notification templates to contain HTML direct links to incidents and changes. We disabled the default link at the beginning of all messages and created our own. An example of our INC URL is this: http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Deskserver=AR_SERVERqual='Incident ID*%2B'%3D%22INC_NUMBER%22 This is the odd behavior and it happens in all browsers. · If a user is not logged into the mid-tier, the link requires authentication and then they’re taken directly to the Incident. Normal and as expected. · If the user (not already logged into the mid-tier) uses the direct link, logs in, accesses the ticket AND THEN (without logging out) clicks on another direct link from a different email notification (or the same), they are taken directly to that ticket without any required authentication. Normal and as expected. · If the user had already been logged into the mid-tier, the direct link in the notification still requires authentication instead of taking them directly in. Odd o If the user declines the authentication (closes the browser tab/window) and goes back to their original, already logged in session, that session has now been logged out and they have to re-authenticate (Session is invalid or has timed out. Please reload page to log in again. (ARERR 9201)). Annoying Now, I’ve done some more testing. I re-enabled the ‘Add URL’ on the notification filter that has the form of: http://MID_TIER:8080/arsys//servlet/ViewFormServlet?form=NTE%3aNotifierserver=AR_SERVEReid=NTS00772848 (ß I don’t know what the NTS number relates to) The new notifications (in Dev) have both URL types. With this being the case, I can’t make it fail as before. I’ve also re-removed the ‘Add URL’ from the filter and it still won’t fail in that environment though our production environment is still acting odd. This feels like something has gotten cached that works for the filter URL but not for my direct one. Anyone have any idea what’s going on here? Thanks again, Ron _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: New custom field oddity
Have you tried accessing the form with multiple user accounts? I have recently seen that sometimes when making a change to form fields that some users will see the change and others won't if only a simple MT cache flush has been done. We now stop Tomcat, delete the cache files and restart Tomcat to effectively rebuild the cache from scratch instead of just refreshing it. This seems to have resolved the seemingly arbitrary issues we were seeing for one subset of users one time, then a different subset of users another time. -Rick ___ Rick Westbrock QMX Support Services -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Longwing, LJ CTR MDA/IC Sent: Tuesday, February 26, 2013 3:36 PM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity Ron, What version of Remedy and what version of Mid-Tier are you running? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Tuesday, February 26, 2013 4:28 PM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity ** After some more testing, I can rule out the AL. I simply created a new character field on both forms, gave them a default value, gave them 'display' for their entry modes, and changed their name/display from 'character field' to 'test field'. I added them both to their respective 'work detail' tabs in an open space for visibility. Flushed cache. In Chrome/FF, when creating a new record, the field on HPD:Help Desk has it's default value that can be highlighted/copied/pasted etc. The field on CHG:Infrastructure Change can do no such thing though it is accessible within IE. I'm still pretty green at this but that just seems stupid. Am I missing a setting? Thoughts? Thanks. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pargeter, Christie :CO IS Sent: Monday, February 25, 2013 3:16 PM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity ** Did you flush your MidTier cache after you added the field? From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Monday, February 25, 2013 10:57 AM To: arslist@ARSLIST.ORG Subject: New custom field oddity ** Hi all, I created a new field on both the HPD:Help Desk and CHG:Infrastructure Change forms. They are both similar in that they are read-only display fields. Each one has an active link that gives the field its value. The AL is working fine as the value is correct on both. The issue I'm having is browser based. Both fields work correctly in IE. However, Only the INC field works in FF and Chrome. The field is there and visible, but I'm unable to interact with it. I can't select/highlight/copy the field contents in those browsers. Any thoughts why one field works but not the other? Is there some setting that I'm missing? Thanks in advance, Ron _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: New custom field oddity
You bring up a good point. Flushing the cache from the mid-tier server will force a re-pull of the object definitions from the Remedy server. Just hitting save on the Remedy server doesn't necessarily mean that all of the definitions are updated across the server group. Each server in the server group will pick up the changes when it notices, which is not necessarily immediately. It very well could be an issue where you are seeing slightly different versions between the session. However, there are small differences between the browser interfaces. I have never set about itemizing them because the differences are usually innocuous. Sometimes they are a bit bigger. For instance, with one release of mid-tier you can only multi-select table fields in certain browsers. This could be a situation where with this particular version of midtier behaves slightly differently between browsers. I just re-verified. I have no problem seeing or copying read only fields. The behavior described sounds like a disabled field rather than a read-only field. Is this behavior being exhibited across other read only fields or just this one? I would do things like: * re-creating the field from scratch (no copy/pasting) * moving the field around * deleting the functionality, clear the cache, go get coffee. Recreate it, go get coffee, flush midtier, flush browser cache, reboot my pc, try again. * check client side logs to verify that there's no unexpected changes to the field by workflow. * spend some time querying the KB and reading release notes. (maybe this should be earlier in my process :) ) * having a look at things in something like firebug. On Tue, Feb 26, 2013 at 4:40 PM, Rick Westbrock rwestbr...@qmxs.com wrote: Have you tried accessing the form with multiple user accounts? I have recently seen that sometimes when making a change to form fields that some users will see the change and others won't if only a simple MT cache flush has been done. We now stop Tomcat, delete the cache files and restart Tomcat to effectively rebuild the cache from scratch instead of just refreshing it. This seems to have resolved the seemingly arbitrary issues we were seeing for one subset of users one time, then a different subset of users another time. -Rick ___ Rick Westbrock QMX Support Services -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Longwing, LJ CTR MDA/IC Sent: Tuesday, February 26, 2013 3:36 PM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity Ron, What version of Remedy and what version of Mid-Tier are you running? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Tuesday, February 26, 2013 4:28 PM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity ** After some more testing, I can rule out the AL. I simply created a new character field on both forms, gave them a default value, gave them 'display' for their entry modes, and changed their name/display from 'character field' to 'test field'. I added them both to their respective 'work detail' tabs in an open space for visibility. Flushed cache. In Chrome/FF, when creating a new record, the field on HPD:Help Desk has it's default value that can be highlighted/copied/pasted etc. The field on CHG:Infrastructure Change can do no such thing though it is accessible within IE. I'm still pretty green at this but that just seems stupid. Am I missing a setting? Thoughts? Thanks. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pargeter, Christie :CO IS Sent: Monday, February 25, 2013 3:16 PM To: arslist@ARSLIST.ORG Subject: Re: New custom field oddity ** Did you flush your MidTier cache after you added the field? From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron Sent: Monday, February 25, 2013 10:57 AM To: arslist@ARSLIST.ORG Subject: New custom field oddity ** Hi all, I created a new field on both the HPD:Help Desk and CHG:Infrastructure Change forms. They are both similar in that they are read-only display fields. Each one has an active link that gives the field its value. The AL is working fine as the value is correct on both. The issue I'm having is browser based. Both fields work correctly in IE. However, Only the INC field works in FF and Chrome. The field is there and visible, but I'm unable to interact with it. I can't select/highlight/copy the field contents in those browsers. Any thoughts why one field works but not the other? Is there some setting that I'm missing? Thanks in advance, Ron _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are and have been for 20 years_ _ARSlist: Where the Answers Are
Re: [EXTERNAL] Tables/views in Analytics
Thanks I did find what I wanted in the BMC docs. Should have looked there first. Sent from my iPad On Feb 26, 2013, at 5:30 PM, Stroud, Natalie K nkst...@sandia.gov wrote: Paul: Supposedly at least some of that information is available in KA345616 in the BMC Knowledge Base. But good luck finding it. I sure can't. However, I found a document I downloaded from somewhere on BMC's website back in June of 2011 that is probably similar to what's in the KBA article, and that is Analytics for AR 7.5 7.6 and BOXI 3.1. I think that is slightly out of date for our installation. I don't even remember where I found this thing now - I just remember thinking it looked useful. If it's reasonably close to your version and you are interested, I'd be happy to send it to you offline as an attachment. Natalie Stroud SAIC @ Sandia National Laboratories ARS-ITSM Tester Albuquerque, NM USA nkst...@sandia.gov ITSM 7.6.04 SP2 - Windows 2003 - SQL Server 2008 -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Hodgdon, Paul Sent: Tuesday, February 26, 2013 2:18 PM To: arslist@ARSLIST.ORG Subject: [EXTERNAL] Tables/views in Analytics Does anyone have a list of the tables and/or views BMC analytics uses in its reporting? We have a universe setup with business objects and would like to replicate the reports in analytics. Thanks, Paul Hodgdon UNH ITSM Applications Manager Sent from my iPad ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
