ITSM upgrade

[SriSamSri Appecherla]

Hi Listers,

Just wondering if anybody was able to upgrade ITSM from 7.5 to 7.6.03. I had
an issue while performing the upgrade. I raised it with BMC and they say it
is a known issue and does not have a ready work around. So just wanted to
know if anybody has really been able to upgrade.

Regards,
SriSamSri Appecherla
Mobile# +91 991 610 6008

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Macro not honoring the data retrival settings

[Viki_kulkarni]

hi all,

Thanks guys i think the server side restriction is working well..

regards,
Viki

Misi Mladoniczky wrote:
> 
> Hi,
> 
> If you are trying to limit access in that way, it is probably the wrong
> way.
> 
> If you really need to limit the number of records returned, listen to Fred
> Grooms, do it on the server side.
> 
> The other way to limit things are by permissions.
> 
> The client side limit is always advisory. You can write API-programs or
> something to circumvent that kind of limitation.
> 
> Macros look exactly the same to the server as ordinary user activity.
> 
> Best Regards - Misi, RRR AB, http://www.rrr.se
> 
> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
> * 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,
>>
>> No the names are in place as well. Is there any way we can disable macros
>> to
>> run for any user? I mean is there any server setting to disable macros
>> globally.
>>
>> I am trying to look for it but not able to find anything about it.
>>
>> Thanks,
>> viki
>>
>>
>> Misi Mladoniczky wrote:
>>>
>>> Hi,
>>>
>>> Could it be that you have different server names in the Macro and in
>>> your
>>> Login? For example a hostname, IP-address or a fully qualified hostname?
>>>
>>> Best Regards - Misi, RRR AB, http://rrr.se
>>>
 I too tried this on my 75 environment and it seems to work. Also one
 more
 strange think it is not happening for all forms..

 I changed the form to search with a similar macro and on that form it
 did
 honor..

 Am i missing something??

 thanks,
 Viki

 Misi Mladoniczky wrote:
>
> Hi,
>
> I recall that some settings could be changed during macro recording in
> the
> past. Apparently not the max-records-returned setting...
>
> I tried this on my 7.6.03 environment.
>
> The Macro honored the setting for my user regardless of the setting
> during
> the actual macro recording. This seems to be at odds with what you are
> seeing.
>
> I would not expect the version of the server to affect this.
>
> Best Regards - Misi, RRR AB, http://www.rrr.se
>
> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
> * 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 Misi,
>>
>> it still gives me more than 1000 records..
>>
>> Thanks,
>> Vikrant
>>
>> Misi Mladoniczky wrote:
>>>
>>> Hi,
>>>
>>> Try recording a new macro where you actually go in and change this
>>> setting
>>> to 1000 during the recording.
>>>
>>> You may have to set it to something other than 1000 before you start
>>> the
>>> recording...
>>>
>>> Best Regards - Misi, RRR AB, http://www.rrr.se
>>>
>>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
>>> * 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 have a macro running on a form that searches for all records on
 the
 form
 which has more than 1000 records.
 now we have set the max number of records to retrieve = 1000 in the
 user
 tools option.

 what we see is that when we make a search call explicit on that
 form
 we
 get
 only 1000 records as per the settings but if we perform the same
 search
 via
 a simple search macro we get more than 1000 records in fact we get
 the
 actual number of records.

 can any one share any idea how to avoid this?? we are on ARS 5.0.1
 and
 user
 tool is 701.


 Thanks,
 Viki
 --
 View this message in context:
 http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30716698p30716698.html
 Sent from the ARS (Action Request System) mailing list archive at
 Nabble.com.

 ___
 UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
 attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

>>>
>>> ___
>>> UNSUBSCRIBE or access ARSlist Archives at ww

Re: User login issue

[Jason Miller]

Hi Anne,

Do you mind sharing what the problem was?

Jason
On Jan 20, 2011 10:25 AM, "Ramey, Anne"  wrote:
> That did allow me to spot the issue. I had forgotten that was so easy to
change. Thanks for the reminder.
>
> Anne Ramey
> ***
> E-mail correspondence to and from this address may be subject to the North
Carolina Public Records Law and may be disclosed to third parties only by an
authorized State Official.
>
>
> -Original Message-
> From: Action Request System discussion list(ARSList) [mailto:
arslist@ARSLIST.ORG] On Behalf Of Danny Kellett
> Sent: Thursday, January 20, 2011 12:58 PM
> To: arslist@ARSLIST.ORG
> Subject: Re: User login issue
>
> If you set the plugin log level to ALL then you can see the ldap reply
> codes that will tell you exactly whats wrong
>
>> We are running a server group (ARS 7.1 ITSM 7.0.03 p 9) and are seeing a
>> strange issue. We use LDAP authentication and have exactly the same LDAP
>> settings on both servers in the server group...they point to the same
>> server and use the same user to bind and the same settings to
authenticate
>> users. We have a series of newly created users that can login to one
>> server in the server group, but not the other. When they can't login
>> successfully, we see
>> 20 2011 08:43:36.8357 */ LOGIN FAILED  (user)
>> In the user log, with a matching
>> C: 390695> /* Thu Jan 20 2011 08:43:36.8285 */+VL
>> AREAVerifyLoginCallback -- user 
>> C: 390695> /* Thu Jan 20 2011 08:43:36.8306 */-VL
>> FAIL
>> In the arplugin log.
>> But if the same user logs in on the other server, it all works perfectly.
>> If this was happening to all users on the problem server, I could
>> understand that, but it seems to just be those created in the last month
>> or so. We are working with our AD admins to see if they can see a
>> problem, but since the working server is using the same AD server, I
can't
>> see how it can be their problem. Any ideas are appreciated.
>>
>> Anne Ramey
>>
>> ***
>> E-mail correspondence to and from this address may be subject to the
North
>> Carolina Public Records Law and may be disclosed to third parties only by
>> an authorized State Official.
>>
>>
>>
___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>>
>
>
___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>
>
___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Strange ARS Timeout Problem

[LJ LongWing]

Eric,

Did your DBA look for any locking?  We used to experience this a lot till we
figure out what was happening.  I could give you SQLServer instructions on
how to find it.but you aren't using that.and your DBA should be able to run
a query that'll tell you about things that are causing blocking and things
that are blocked.

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of ZHANG, ERIC L
Sent: Thursday, January 20, 2011 2:11 PM
To: arslist@ARSLIST.ORG
Subject: Strange ARS Timeout Problem

 

** 

Hi Listers.

 

We are experiencing intermittent timeouts with the ARS. Without me doing
anything, the AR system becomes normal again after about 5 minutes. All
users are getting timeout (or hourglass) but no process is being restarted
in armonitor.log. 

 

This is the message showing in arerror.log:

 

Tue Jan 18 12:09:24 2011  Dispatch : Timeout during data retrieval due to
busy server -- retry the operation (server_name)  ARERR - 93

Tue Jan 18 12:10:04 2011  Approve : Timeout during database query --
consider using more specific search criteria to narrow the results, and
retry the operation (ARERR 94)

 

In the API log, it shows a 5-minute gap:

 

   
  /* Tue Jan 18 2011 12:06:16.2224 */-GLEWFOK

   
  /* Tue Jan 18 2011 12:11:16.0001 */+GLEWF  ARGetListEntryWithFields --
schema OBJSTR:Class from Unidentified Client (protocol 12) at IP address

 

Our DBA was monitoring the database during the time and found few activities
in the database. The activities shown in SQL log during the timeout were all
for user AR_ESCALATOR, which means the escalation was still running during
the time. This can also be verified from the escalation log.

 

When this occurs, the CPU and RAM utilizations are dramatically dropping to
the lowest levels on both the ARS server and the database server. There was
no application change in the last couple of months. The problem started
about two weeks ago. It could occur 3 times a day and sometimes it works
fine for days without it occurring.

 

Our configuration/environment:

 

ARS: 7.1 patch 7

ITSM: 7.0.03 patch 9

SLM: 7.1 patch 2

SRM: 2.2 patch 4

Midtier: 7.6.03

 

ARS Server: Solaris 10 (16 GB of Physical Memory, 18 GB of SWAP, 8 CPUs) -
Dedicated to ARServer, ITSM, SLM, and SRM.

Midtier Server: Windows Server 2003 SP2 (2 CPUs, 2 GB of RAM) - Used only by
customers to submit service request.

Database: Oracle: 10gR2 (remote)

 

The following are threads settings in ar.conf:

 

Private-RPC-Socket:  390601   2   6

Private-RPC-Socket:  390603   2   2

Private-RPC-Socket:  390620  16  24  (FAST)

Private-RPC-Socket:  390626   8  16

Private-RPC-Socket:  390627   2  12

Private-RPC-Socket:  390635  24  30  (LIST)

Private-RPC-Socket:  390680  24  24

Private-RPC-Socket:  390693   2   4

Private-RPC-Socket:  390698   2   4

 

We have about 300 concurrent Remedy users during the peak hours. ARServer is
running as non-root process. The number of open file descriptors for
arserverd (~700) was well below the ulimit 3072.  The FAST and LIST threads
never reached the maximums.

 

I have an open ticket with BMC Support but thought I might get a solution
quicker from the Arslist here.

 

Thanks,

Eric

 

_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ 


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Strange ARS Timeout Problem

[Dennis Ruble]

Eric,
We had a similar symptom many years back.  There were 3 DNS servers 
configured for our AR System server.  Over time the first and second ones 
were retired and the DNS configuration did not get updated.  So, for every 
DNS call the system had to wait for the first and second servers to 
timeout before trying the third and if the third was busy everything just 
went to sleep while waiting for a response.  We updated our DNS config and 
hosts file and everything returned to normal. 

Suppose there might also be other resources besides DNS servers that could 
cause the same symptom.  Our network guys sniffed the network to see what 
we were waiting on.

HTH,
Dennis





"ZHANG, ERIC L"  
Sent by: "Action Request System discussion list(ARSList)" 

01/20/2011 03:10 PM
Please respond to
arslist@ARSLIST.ORG


To
arslist@ARSLIST.ORG
cc

Subject
Strange ARS Timeout Problem






** 
Hi Listers.
 
We are experiencing intermittent timeouts with the ARS. Without me doing 
anything, the AR system becomes normal again after about 5 minutes. All 
users are getting timeout (or hourglass) but no process is being restarted 
in armonitor.log. 
 
This is the message showing in arerror.log:
 
Tue Jan 18 12:09:24 2011  Dispatch : Timeout during data retrieval due to 
busy server -- retry the operation (server_name)  ARERR - 93
Tue Jan 18 12:10:04 2011  Approve : Timeout during database query -- 
consider using more specific search criteria to narrow the results, and 
retry the operation (ARERR 94)
 
In the API log, it shows a 5-minute gap:
 

  /* Tue Jan 18 
2011 12:06:16.2224 */-GLEWFOK

  /* Tue Jan 18 
2011 12:11:16.0001 */+GLEWF  ARGetListEntryWithFields -- schema 
OBJSTR:Class from Unidentified Client (protocol 12) at IP address
 
Our DBA was monitoring the database during the time and found few 
activities in the database. The activities shown in SQL log during the 
timeout were all for user AR_ESCALATOR, which means the escalation was 
still running during the time. This can also be verified from the 
escalation log.
 
When this occurs, the CPU and RAM utilizations are dramatically dropping 
to the lowest levels on both the ARS server and the database server. There 
was no application change in the last couple of months. The problem 
started about two weeks ago. It could occur 3 times a day and sometimes it 
works fine for days without it occurring.
 
Our configuration/environment:
 
ARS: 7.1 patch 7
ITSM: 7.0.03 patch 9
SLM: 7.1 patch 2
SRM: 2.2 patch 4
Midtier: 7.6.03
 
ARS Server: Solaris 10 (16 GB of Physical Memory, 18 GB of SWAP, 8 CPUs) ? 
Dedicated to ARServer, ITSM, SLM, and SRM.
Midtier Server: Windows Server 2003 SP2 (2 CPUs, 2 GB of RAM) ? Used only 
by customers to submit service request.
Database: Oracle: 10gR2 (remote)
 
The following are threads settings in ar.conf:
 
Private-RPC-Socket:  390601   2   6
Private-RPC-Socket:  390603   2   2
Private-RPC-Socket:  390620  16  24  (FAST)
Private-RPC-Socket:  390626   8  16
Private-RPC-Socket:  390627   2  12
Private-RPC-Socket:  390635  24  30  (LIST)
Private-RPC-Socket:  390680  24  24
Private-RPC-Socket:  390693   2   4
Private-RPC-Socket:  390698   2   4
 
We have about 300 concurrent Remedy users during the peak hours. ARServer 
is running as non-root process. The number of open file descriptors for 
arserverd (~700) was well below the ulimit 3072.  The FAST and LIST 
threads never reached the maximums.
 
I have an open ticket with BMC Support but thought I might get a solution 
quicker from the Arslist here.
 
Thanks,
Eric
 
_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Strange ARS Timeout Problem

[Brittain, Mark]

Hi Eric,

Couple things you might check.
Have you checked the indexing against the Run If in the escalations? NULL in 
the Run If ignores indexing and should be avoided.

If you have a time calculation is the field on one side and the calculation on 
the other (Create Date < $TIMESTAMP$ - 3600) vs. (Create Date +3600 < 
$TIMESTAMP$). Calculating on the field value is slower.

Is there a SQL query to an external table in the Set Field action? Could be a 
change/cause there.

Likewise is the escalation doing a set field using information from another 
form that you users frequently use? If so the issue might be the indexing there.

These are small things that you can get away with when there is a relatively 
limited number of records. Then at some magic number the warts start to show.

Hope this helps and good luck.

Mark

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of ZHANG, ERIC L
Sent: Thursday, January 20, 2011 4:11 PM
To: arslist@ARSLIST.ORG
Subject: Strange ARS Timeout Problem

**
Hi Listers.

We are experiencing intermittent timeouts with the ARS. Without me doing 
anything, the AR system becomes normal again after about 5 minutes. All users 
are getting timeout (or hourglass) but no process is being restarted in 
armonitor.log.

This is the message showing in arerror.log:

Tue Jan 18 12:09:24 2011  Dispatch : Timeout during data retrieval due to busy 
server -- retry the operation (server_name)  ARERR - 93
Tue Jan 18 12:10:04 2011  Approve : Timeout during database query -- consider 
using more specific search criteria to narrow the results, and retry the 
operation (ARERR 94)

In the API log, it shows a 5-minute gap:

  /* Tue Jan 18 
2011 12:06:16.2224 */-GLEWFOK
  /* Tue Jan 18 
2011 12:11:16.0001 */+GLEWF  ARGetListEntryWithFields -- schema OBJSTR:Class 
from Unidentified Client (protocol 12) at IP address

Our DBA was monitoring the database during the time and found few activities in 
the database. The activities shown in SQL log during the timeout were all for 
user AR_ESCALATOR, which means the escalation was still running during the 
time. This can also be verified from the escalation log.

When this occurs, the CPU and RAM utilizations are dramatically dropping to the 
lowest levels on both the ARS server and the database server. There was no 
application change in the last couple of months. The problem started about two 
weeks ago. It could occur 3 times a day and sometimes it works fine for days 
without it occurring.

Our configuration/environment:

ARS: 7.1 patch 7
ITSM: 7.0.03 patch 9
SLM: 7.1 patch 2
SRM: 2.2 patch 4
Midtier: 7.6.03

ARS Server: Solaris 10 (16 GB of Physical Memory, 18 GB of SWAP, 8 CPUs) - 
Dedicated to ARServer, ITSM, SLM, and SRM.
Midtier Server: Windows Server 2003 SP2 (2 CPUs, 2 GB of RAM) - Used only by 
customers to submit service request.
Database: Oracle: 10gR2 (remote)

The following are threads settings in ar.conf:

Private-RPC-Socket:  390601   2   6
Private-RPC-Socket:  390603   2   2
Private-RPC-Socket:  390620  16  24  (FAST)
Private-RPC-Socket:  390626   8  16
Private-RPC-Socket:  390627   2  12
Private-RPC-Socket:  390635  24  30  (LIST)
Private-RPC-Socket:  390680  24  24
Private-RPC-Socket:  390693   2   4
Private-RPC-Socket:  390698   2   4

We have about 300 concurrent Remedy users during the peak hours. ARServer is 
running as non-root process. The number of open file descriptors for arserverd 
(~700) was well below the ulimit 3072.  The FAST and LIST threads never reached 
the maximums.

I have an open ticket with BMC Support but thought I might get a solution 
quicker from the Arslist here.

Thanks,
Eric

_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_


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
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Strange ARS Timeout Problem

[ZHANG, ERIC L]

Hi Listers.

 

We are experiencing intermittent timeouts with the ARS. Without me doing
anything, the AR system becomes normal again after about 5 minutes. All
users are getting timeout (or hourglass) but no process is being
restarted in armonitor.log. 

 

This is the message showing in arerror.log:

 

Tue Jan 18 12:09:24 2011  Dispatch : Timeout during data retrieval due
to busy server -- retry the operation (server_name)  ARERR - 93

Tue Jan 18 12:10:04 2011  Approve : Timeout during database query --
consider using more specific search criteria to narrow the results, and
retry the operation (ARERR 94)

 

In the API log, it shows a 5-minute gap:

 

   
  /* Tue Jan 18 2011 12:06:16.2224 */-GLEWFOK

   
  /* Tue Jan 18 2011 12:11:16.0001 */+GLEWF  ARGetListEntryWithFields --
schema OBJSTR:Class from Unidentified Client (protocol 12) at IP address

 

Our DBA was monitoring the database during the time and found few
activities in the database. The activities shown in SQL log during the
timeout were all for user AR_ESCALATOR, which means the escalation was
still running during the time. This can also be verified from the
escalation log.

 

When this occurs, the CPU and RAM utilizations are dramatically dropping
to the lowest levels on both the ARS server and the database server.
There was no application change in the last couple of months. The
problem started about two weeks ago. It could occur 3 times a day and
sometimes it works fine for days without it occurring.

 

Our configuration/environment:

 

ARS: 7.1 patch 7

ITSM: 7.0.03 patch 9

SLM: 7.1 patch 2

SRM: 2.2 patch 4

Midtier: 7.6.03

 

ARS Server: Solaris 10 (16 GB of Physical Memory, 18 GB of SWAP, 8 CPUs)
- Dedicated to ARServer, ITSM, SLM, and SRM.

Midtier Server: Windows Server 2003 SP2 (2 CPUs, 2 GB of RAM) - Used
only by customers to submit service request.

Database: Oracle: 10gR2 (remote)

 

The following are threads settings in ar.conf:

 

Private-RPC-Socket:  390601   2   6

Private-RPC-Socket:  390603   2   2

Private-RPC-Socket:  390620  16  24  (FAST)

Private-RPC-Socket:  390626   8  16

Private-RPC-Socket:  390627   2  12

Private-RPC-Socket:  390635  24  30  (LIST)

Private-RPC-Socket:  390680  24  24

Private-RPC-Socket:  390693   2   4

Private-RPC-Socket:  390698   2   4

 

We have about 300 concurrent Remedy users during the peak hours.
ARServer is running as non-root process. The number of open file
descriptors for arserverd (~700) was well below the ulimit 3072.  The
FAST and LIST threads never reached the maximums.

 

I have an open ticket with BMC Support but thought I might get a
solution quicker from the Arslist here.

 

Thanks,

Eric

 


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Bulk Load Document Relationships

[Jason Miller]

What Class of Relationship do you want to create?

Just taking a quick look I started a new Relationship Mapping, set the
Relationship Source to "External Data into CMDB", External Data Store as
FlatFile, NameSpace to BMC.CORE, Relationship Class Name to
BMC_BaseRelationship (and BMC_Component for giggles) and can see
BMC_Document in the menu for both Primary and Secondary Class.  I didn't
save the new mapping but it looks like you should be able to do it with a
flat file (we have done it with other classes besides BMC_Document).

HTH,
Jason

On Thu, Jan 20, 2011 at 11:11 AM, Mike Ziniti  wrote:

> We have approx 5K CIs of class type Document. Currently there are no
> relationships between this CIs in the CMDB. I would like to be able to
> create relationships between them but do it in a bulk fashion via flatfile.
> I was under the assumption you could load relationship data using AIE but I
> don't see the option for the Document class. Is there another way to do
> this?
> --
> View this message in context:
> http://ars-action-request-system.1093659.n2.nabble.com/Bulk-Load-Document-Relationships-tp5911310p5944987.html
> Sent from the ARS (Action Request System) mailing list archive at
> Nabble.com.
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Job: Senior Remedy Developer position - New York

[Qaiser Iqbal]

We are looking for Senior Remedy developer with Kinetic experience for
fulltime employee position in Brooklyn, NY area. I interested, please
contact me offline at qiq...@doitt.nyc.gov for details.

Thanks
Qaiser Iqbal

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Consuming Remedy Web Service Using Other WSDL

[Mike]

Has anyone successfully been able to create a web service in remedy (any 
version) using a custom schema (XSD) and then consume it without using the 
remedy generated WSDL, but one that includes the same schema used to create the 
web service?
It seems like this should be possible but I am having trouble. The remedy 
generated WSDL includes both the schema that I used to create the web service 
and another auto-generated one used as a wrapper. The SOAP requests that remedy 
is expecting and generating for responses look like this:
 



http://...";>
...
...
...




ns0:OperationResponse is nowhere defined in the schema that I imported. It is 
from the remedy generated schema and the client errors out when it receives 
this response becasue it is not expecting it. According to the schema that the 
client uses (the one I used to create the web service) it should look like this:
 



...
...
...


 
Remedy is essentially modifying the schema. I have been able tweak the custom 
schema to work with the soap request coming in but I can't find a way to 
prevent remedy from sending the additional OperationResponse element in the 
response messages. Is there any way to make remedy not modify my schema?

-Mike 
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Bulk Load Document Relationships

[Mike Ziniti]

After reviewing the logs when creating a relationship manually it seems like
there is more going on then just a record being created in the BMC CORE
Dependency form. Are there any other supplement forms that need to have data
in order to make this is a legit relationship?
-- 
View this message in context: 
http://ars-action-request-system.1093659.n2.nabble.com/Bulk-Load-Document-Relationships-tp5911310p5945301.html
Sent from the ARS (Action Request System) mailing list archive at Nabble.com.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: No Plans To Fix (SW00377001)

[LJ LongWing]

FYI, I'm working with ColumnIT to get the defect re-openedhopefully this 
will make it into patches for 7.5+

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky
Sent: Thursday, January 20, 2011 1:18 PM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

Hi,

This is something I have had to "fix" on the RRR|License side.

It seems like this is happening to all READ-grants from a certain version
of the AR Server.

I can not understand how anyone could think that this is a client related
issue, it is definitely an error on the server side!!!

And it should be very easy to fix, as it is consistent and apparently part
of an error in a sprintf-statement or something similar...

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

Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
* 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.

> It is not a client defect, it is a SERVER defect..server 'User
> Logging'..the
> server doesn't properly log the license type allocated for Read users..
>
>
>
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
> Sent: Thursday, January 20, 2011 10:05 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: No Plans To Fix (SW00377001)
>
>
>
> **
>
> Hi LJ,
>
>
>
>   The defect was logged against the AR System 7.5.00 Remedy User client.
> As
> announced over a year ago, the Remedy User client is being discontinued.
> Only business critical issues would be addressed in any patches to
> existing
> versions of the Remedy User client.
>
>
>
>   Also, the defect was tentatively targeted to be considered in the 7.6.04
> release of AR System, but again only business critical issues would be
> addressed around the Remedy User client and it was evaluated by BMC that
> this was not of critical business impact.   According to the defect, it
> was
> not ever assigned to be delivered in a patch - the target release was
> always
> the internal codename for the 7.6.04 release.
>
>
>
> Hope that helps answer your question.
>
>
>
> -David J. Easter
>
> Manager of Product Management, Remedy Platform
>
> BMC Software, Inc.
>
>
>
> The opinions, statements, and/or suggested courses of action expressed in
> this E-mail do not necessarily reflect those of BMC Software, Inc.  My
> voluntary participation in this forum is not intended to convey a role as
> a
> spokesperson, liaison or public relations representative for BMC Software,
> Inc.
>
>
>
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
> Sent: Thursday, January 20, 2011 08:38 AM
> To: arslist@ARSLIST.ORG
> Subject: No Plans To Fix (SW00377001)
>
>
>
> **
>
> WHAT
>
>
>
> Ok.here is the problem.  I logged a support ticket with ColumnIT regarding
> a
> problem in 7.5 where when a Read user logs in, if you have user logging
> turned on it shows garbage characters in the log where the word 'READ'
> should appear.  Column IT opens an issue with BMC.  BMC recognizes it as a
> Defect and opens Defect ID SW00377001 stating that it will be corrected in
> a
> later patch.  Today I checked back to see if it was going into a 'soon'
> patch and see that the defect is closed.I look at the details and see that
> the classification of the defect is 'No Plans to Fix'
>
>
>
> I can't believe this.I go through all the effort to report a bug, they
> recognize it as a bug, but close the defect saying they aren't planning on
> fixing it?what is this crap?
>
> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_
>
> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Bulk Load Document Relationships

[Peter Romain]

You can use the data import tool to create relationships from a csv file if
that helps.

All you need to do is import the source instanceid, destination instanceid,
datasetid and name into, for example, the BMC.CORE:BMC_Dependency form and
the relationship is created.


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Mike Ziniti
Sent: 20 January 2011 19:11
To: arslist@ARSLIST.ORG
Subject: Re: Bulk Load Document Relationships

We have approx 5K CIs of class type Document. Currently there are no
relationships between this CIs in the CMDB. I would like to be able to
create relationships between them but do it in a bulk fashion via flatfile.
I was under the assumption you could load relationship data using AIE but I
don't see the option for the Document class. Is there another way to do
this?
-- 
View this message in context:
http://ars-action-request-system.1093659.n2.nabble.com/Bulk-Load-Document-Re
lationships-tp5911310p5944987.html
Sent from the ARS (Action Request System) mailing list archive at
Nabble.com.


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: No Plans To Fix (SW00377001)

[Misi Mladoniczky]

Hi,

This is something I have had to "fix" on the RRR|License side.

It seems like this is happening to all READ-grants from a certain version
of the AR Server.

I can not understand how anyone could think that this is a client related
issue, it is definitely an error on the server side!!!

And it should be very easy to fix, as it is consistent and apparently part
of an error in a sprintf-statement or something similar...

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

Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
* 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.

> It is not a client defect, it is a SERVER defect..server 'User
> Logging'..the
> server doesn't properly log the license type allocated for Read users..
>
>
>
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
> Sent: Thursday, January 20, 2011 10:05 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: No Plans To Fix (SW00377001)
>
>
>
> **
>
> Hi LJ,
>
>
>
>   The defect was logged against the AR System 7.5.00 Remedy User client.
> As
> announced over a year ago, the Remedy User client is being discontinued.
> Only business critical issues would be addressed in any patches to
> existing
> versions of the Remedy User client.
>
>
>
>   Also, the defect was tentatively targeted to be considered in the 7.6.04
> release of AR System, but again only business critical issues would be
> addressed around the Remedy User client and it was evaluated by BMC that
> this was not of critical business impact.   According to the defect, it
> was
> not ever assigned to be delivered in a patch - the target release was
> always
> the internal codename for the 7.6.04 release.
>
>
>
> Hope that helps answer your question.
>
>
>
> -David J. Easter
>
> Manager of Product Management, Remedy Platform
>
> BMC Software, Inc.
>
>
>
> The opinions, statements, and/or suggested courses of action expressed in
> this E-mail do not necessarily reflect those of BMC Software, Inc.  My
> voluntary participation in this forum is not intended to convey a role as
> a
> spokesperson, liaison or public relations representative for BMC Software,
> Inc.
>
>
>
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
> Sent: Thursday, January 20, 2011 08:38 AM
> To: arslist@ARSLIST.ORG
> Subject: No Plans To Fix (SW00377001)
>
>
>
> **
>
> WHAT
>
>
>
> Ok.here is the problem.  I logged a support ticket with ColumnIT regarding
> a
> problem in 7.5 where when a Read user logs in, if you have user logging
> turned on it shows garbage characters in the log where the word 'READ'
> should appear.  Column IT opens an issue with BMC.  BMC recognizes it as a
> Defect and opens Defect ID SW00377001 stating that it will be corrected in
> a
> later patch.  Today I checked back to see if it was going into a 'soon'
> patch and see that the defect is closed.I look at the details and see that
> the classification of the defect is 'No Plans to Fix'
>
>
>
> I can't believe this.I go through all the effort to report a bug, they
> recognize it as a bug, but close the defect saying they aren't planning on
> fixing it?what is this crap?
>
> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_
>
> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Macro not honoring the data retrival settings

[Misi Mladoniczky]

Hi,

If you are trying to limit access in that way, it is probably the wrong way.

If you really need to limit the number of records returned, listen to Fred
Grooms, do it on the server side.

The other way to limit things are by permissions.

The client side limit is always advisory. You can write API-programs or
something to circumvent that kind of limitation.

Macros look exactly the same to the server as ordinary user activity.

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

Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
* 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,
>
> No the names are in place as well. Is there any way we can disable macros
> to
> run for any user? I mean is there any server setting to disable macros
> globally.
>
> I am trying to look for it but not able to find anything about it.
>
> Thanks,
> viki
>
>
> Misi Mladoniczky wrote:
>>
>> Hi,
>>
>> Could it be that you have different server names in the Macro and in
>> your
>> Login? For example a hostname, IP-address or a fully qualified hostname?
>>
>> Best Regards - Misi, RRR AB, http://rrr.se
>>
>>> I too tried this on my 75 environment and it seems to work. Also one
>>> more
>>> strange think it is not happening for all forms..
>>>
>>> I changed the form to search with a similar macro and on that form it
>>> did
>>> honor..
>>>
>>> Am i missing something??
>>>
>>> thanks,
>>> Viki
>>>
>>> Misi Mladoniczky wrote:

 Hi,

 I recall that some settings could be changed during macro recording in
 the
 past. Apparently not the max-records-returned setting...

 I tried this on my 7.6.03 environment.

 The Macro honored the setting for my user regardless of the setting
 during
 the actual macro recording. This seems to be at odds with what you are
 seeing.

 I would not expect the version of the server to affect this.

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

 Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
 * 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 Misi,
>
> it still gives me more than 1000 records..
>
> Thanks,
> Vikrant
>
> Misi Mladoniczky wrote:
>>
>> Hi,
>>
>> Try recording a new macro where you actually go in and change this
>> setting
>> to 1000 during the recording.
>>
>> You may have to set it to something other than 1000 before you start
>> the
>> recording...
>>
>> Best Regards - Misi, RRR AB, http://www.rrr.se
>>
>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
>> * 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 have a macro running on a form that searches for all records on
>>> the
>>> form
>>> which has more than 1000 records.
>>> now we have set the max number of records to retrieve = 1000 in the
>>> user
>>> tools option.
>>>
>>> what we see is that when we make a search call explicit on that
>>> form
>>> we
>>> get
>>> only 1000 records as per the settings but if we perform the same
>>> search
>>> via
>>> a simple search macro we get more than 1000 records in fact we get
>>> the
>>> actual number of records.
>>>
>>> can any one share any idea how to avoid this?? we are on ARS 5.0.1
>>> and
>>> user
>>> tool is 701.
>>>
>>>
>>> Thanks,
>>> Viki
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30716698p30716698.html
>>> Sent from the ARS (Action Request System) mailing list archive at
>>> Nabble.com.
>>>
>>> ___
>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>>>
>>
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>>
>>
>
> --
> View this message in context:
> http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30716698p30716858.html
> Sent from the ARS (Action Request System) 

Re: User login issue

[Danny Kellett]

No problem :)

Sent from my iPhone

On 20 Jan 2011, at 18:23, "Ramey, Anne"  wrote:

> That did allow me to spot the issue.  I had forgotten that was so easy to 
> change.  Thanks for the reminder.
> 
> Anne Ramey
> ***
> E-mail correspondence to and from this address may be subject to the North 
> Carolina Public Records Law and may be disclosed to third parties only by an 
> authorized State Official.
> 
> 
> -Original Message-
> From: Action Request System discussion list(ARSList) 
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Danny Kellett
> Sent: Thursday, January 20, 2011 12:58 PM
> To: arslist@ARSLIST.ORG
> Subject: Re: User login issue
> 
> If you set the plugin log level to ALL then you can see the ldap reply
> codes that will tell you exactly whats wrong
> 
>> We are running a server group (ARS 7.1 ITSM 7.0.03 p 9) and are seeing a
>> strange issue.  We use LDAP authentication and have exactly the same LDAP
>> settings on both servers in the server group...they point to the same
>> server and use the same user to bind and the same settings to authenticate
>> users.  We have a series of newly created users that can login to one
>> server in the server group, but not the other.  When they can't login
>> successfully, we see
>> 20 2011 08:43:36.8357 */ LOGIN FAILED  (user)
>> In the user log, with a matching
>> C: 390695> /* Thu Jan 20 2011 08:43:36.8285 */+VL
>> AREAVerifyLoginCallback  -- user 
>> C: 390695> /* Thu Jan 20 2011 08:43:36.8306 */-VL
>>  FAIL
>> In the arplugin log.
>> But if the same user logs in on the other server, it all works perfectly.
>> If this was happening to all users on the problem server, I could
>> understand that, but it seems to just be those created in the last month
>> or so.  We are working with our AD admins to see if they can see a
>> problem, but since the working server is using the same AD server, I can't
>> see how it can be their problem.  Any ideas are appreciated.
>> 
>> Anne Ramey
>> 
>> ***
>> E-mail correspondence to and from this address may be subject to the North
>> Carolina Public Records Law and may be disclosed to third parties only by
>> an authorized State Official.
>> 
>> 
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>> 
> 
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
> 
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Bulk Load Document Relationships

[Mike Ziniti]

We have approx 5K CIs of class type Document. Currently there are no
relationships between this CIs in the CMDB. I would like to be able to
create relationships between them but do it in a bulk fashion via flatfile.
I was under the assumption you could load relationship data using AIE but I
don't see the option for the Document class. Is there another way to do
this?
-- 
View this message in context: 
http://ars-action-request-system.1093659.n2.nabble.com/Bulk-Load-Document-Relationships-tp5911310p5944987.html
Sent from the ARS (Action Request System) mailing list archive at Nabble.com.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: No Plans To Fix (SW00377001)

[Axton]

Looks like a invalid memory operation; accessing a freed pointer, character
array without terminating NULL character and bad data handling...  At some
point this will resurface as something a bit more sinister if not addressed
(random crashes, remote code execution, etc.).  I'd be curious to know if
this causes a crash/core dump on Solaris if using libumem.

The opinions, statements, and/or suggested courses of action expressed in
this E-mail do not necessarily reflect those of BMC Software, Inc.  My
voluntary participation in this forum is not intended to convey a role as a
spokesperson, liaison or public relations representative for BMC Software,
Inc.

On Thu, Jan 20, 2011 at 11:56 AM, Easter, David wrote:

> If Column logged the original defect, they should contact BMC Support and
> explain the situation. Or, another customer with a maintenance contract (or
> Column itself) could open a new defect.  Either works.
>
> -David J. Easter
> Manager of Product Management, Remedy Platform
> BMC Software, Inc.
>
> The opinions, statements, and/or suggested courses of action expressed in
> this E-mail do not necessarily reflect those of BMC Software, Inc.  My
> voluntary participation in this forum is not intended to convey a role as a
> spokesperson, liaison or public relations representative for BMC Software,
> Inc.
>
>
> -Original Message-
> From: Action Request System discussion list(ARSList) [mailto:
> arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
> Sent: Thursday, January 20, 2011 09:52 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: No Plans To Fix (SW00377001)
>
> Sowhat needs to happen to get this defect re-opened?it is happening
> against the Web client.
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
> Sent: Thursday, January 20, 2011 10:35 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: No Plans To Fix (SW00377001)
>
> That would be correct.  If the issue can be duplicated when a user logs in
> through the Mid-Tier or an API program, then it would remain a valid defect
> and could continue to be considered for a future release.  If that's the
> case, then the defect was closed in error (influenced, as you say, but it
> being logged against the wrong component).
>
> In general, this is an important concept to remember when logging defects
> or
> RFEs.  Because the future is the web client, make sure that issues not
> unique to the Remedy User client are submitted as occurring through the web
> client (or API programs) as well.  It will help ensure the issue is
> processed properly.
>
> Thanks,
>
> -David J. Easter
> Manager of Product Management, Remedy Platform
> BMC Software, Inc.
>
> The opinions, statements, and/or suggested courses of action expressed in
> this E-mail do not necessarily reflect those of BMC Software, Inc.  My
> voluntary participation in this forum is not intended to convey a role as a
> spokesperson, liaison or public relations representative for BMC Software,
> Inc.
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W
> Sent: Thursday, January 20, 2011 09:19 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: No Plans To Fix (SW00377001)
>
> LJ,
>
> What if a read user logs in thru Mid-Tier?  If the logs show the same thing
> then it sounds like ColumnIT opened the ticket to Remedy against the wrong
> item  (Client instead of Server).
>
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
> Sent: Thursday, January 20, 2011 11:05 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: No Plans To Fix (SW00377001)
>
> **
> Hi LJ,
>
>   The defect was logged against the AR System 7.5.00 Remedy User client.
> As
> announced over a year ago, the Remedy User client is being discontinued.
> Only business critical issues would be addressed in any patches to existing
> versions of the Remedy User client.
>
>   Also, the defect was tentatively targeted to be considered in the 7.6.04
> release of AR System, but again only business critical issues would be
> addressed around the Remedy User client and it was evaluated by BMC that
> this was not of critical business impact.   According to the defect, it was
> not ever assigned to be delivered in a patch - the target release was
> always
> the internal codename for the 7.6.04 release.
>
> Hope that helps answer your question.
>
> -David J. Easter
> Manager of Product Management, Remedy Platform
> BMC Software, Inc.
>
> The opinions, statements, and/or suggested courses of action expressed in
> this E-mail do not necessarily reflect those of BMC Software, Inc.  My
> voluntary participation in this forum is not intended to convey a role as a
> spokesperson, liaison or public relations representative for BMC Software,
> Inc.
>
> -Original Message-
> From: Action Request

Re: User login issue

[Ramey, Anne]

That did allow me to spot the issue.  I had forgotten that was so easy to 
change.  Thanks for the reminder.

Anne Ramey
***
E-mail correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties only by an 
authorized State Official.


-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Danny Kellett
Sent: Thursday, January 20, 2011 12:58 PM
To: arslist@ARSLIST.ORG
Subject: Re: User login issue

If you set the plugin log level to ALL then you can see the ldap reply
codes that will tell you exactly whats wrong

> We are running a server group (ARS 7.1 ITSM 7.0.03 p 9) and are seeing a
> strange issue.  We use LDAP authentication and have exactly the same LDAP
> settings on both servers in the server group...they point to the same
> server and use the same user to bind and the same settings to authenticate
> users.  We have a series of newly created users that can login to one
> server in the server group, but not the other.  When they can't login
> successfully, we see
> 20 2011 08:43:36.8357 */ LOGIN FAILED  (user)
> In the user log, with a matching
> C: 390695> /* Thu Jan 20 2011 08:43:36.8285 */+VL
> AREAVerifyLoginCallback  -- user 
> C: 390695> /* Thu Jan 20 2011 08:43:36.8306 */-VL
>   FAIL
> In the arplugin log.
> But if the same user logs in on the other server, it all works perfectly.
> If this was happening to all users on the problem server, I could
> understand that, but it seems to just be those created in the last month
> or so.  We are working with our AD admins to see if they can see a
> problem, but since the working server is using the same AD server, I can't
> see how it can be their problem.  Any ideas are appreciated.
>
> Anne Ramey
>
> ***
> E-mail correspondence to and from this address may be subject to the North
> Carolina Public Records Law and may be disclosed to third parties only by
> an authorized State Official.
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: No Plans To Fix (SW00377001)

[LJ LongWing]

David,
I have contacted ColumnIT to have them do the necessary work on their end to
either get this one re-opened, or to have them log another.  Thanks for your
guidance on this issue.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
Sent: Thursday, January 20, 2011 10:57 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

If Column logged the original defect, they should contact BMC Support and
explain the situation. Or, another customer with a maintenance contract (or
Column itself) could open a new defect.  Either works.

-David J. Easter
Manager of Product Management, Remedy Platform
BMC Software, Inc.
 
The opinions, statements, and/or suggested courses of action expressed in
this E-mail do not necessarily reflect those of BMC Software, Inc.  My
voluntary participation in this forum is not intended to convey a role as a
spokesperson, liaison or public relations representative for BMC Software,
Inc.


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Thursday, January 20, 2011 09:52 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

Sowhat needs to happen to get this defect re-opened?it is happening
against the Web client.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
Sent: Thursday, January 20, 2011 10:35 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

That would be correct.  If the issue can be duplicated when a user logs in
through the Mid-Tier or an API program, then it would remain a valid defect
and could continue to be considered for a future release.  If that's the
case, then the defect was closed in error (influenced, as you say, but it
being logged against the wrong component).

In general, this is an important concept to remember when logging defects or
RFEs.  Because the future is the web client, make sure that issues not
unique to the Remedy User client are submitted as occurring through the web
client (or API programs) as well.  It will help ensure the issue is
processed properly.  

Thanks,

-David J. Easter
Manager of Product Management, Remedy Platform
BMC Software, Inc.
 
The opinions, statements, and/or suggested courses of action expressed in
this E-mail do not necessarily reflect those of BMC Software, Inc.  My
voluntary participation in this forum is not intended to convey a role as a
spokesperson, liaison or public relations representative for BMC Software,
Inc.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W
Sent: Thursday, January 20, 2011 09:19 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

LJ,

What if a read user logs in thru Mid-Tier?  If the logs show the same thing
then it sounds like ColumnIT opened the ticket to Remedy against the wrong
item  (Client instead of Server).


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
Sent: Thursday, January 20, 2011 11:05 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

** 
Hi LJ,

  The defect was logged against the AR System 7.5.00 Remedy User client.  As
announced over a year ago, the Remedy User client is being discontinued. 
Only business critical issues would be addressed in any patches to existing
versions of the Remedy User client.

  Also, the defect was tentatively targeted to be considered in the 7.6.04
release of AR System, but again only business critical issues would be
addressed around the Remedy User client and it was evaluated by BMC that
this was not of critical business impact.   According to the defect, it was
not ever assigned to be delivered in a patch - the target release was always
the internal codename for the 7.6.04 release.

Hope that helps answer your question.

-David J. Easter
Manager of Product Management, Remedy Platform
BMC Software, Inc.
 
The opinions, statements, and/or suggested courses of action expressed in
this E-mail do not necessarily reflect those of BMC Software, Inc.  My
voluntary participation in this forum is not intended to convey a role as a
spokesperson, liaison or public relations representative for BMC Software,
Inc.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Thursday, January 20, 2011 08:38 AM
To: arslist@ARSLIST.ORG
Subject: No Plans To Fix (SW00377001)

** 
WHAT

Ok.here is the problem.  I logged a support ticket with ColumnIT regarding a
problem in 7.5 where when a Read user logs in, if you have user logging
turned on it shows garbage characters in the log where the word 'READ'
should appear.  Column IT opens an issue with BMC.

Re: Compile Driver on 64Bit Solaris

[Frank Caruso]

Thanks Fred. That appears to have fixed that issue.
However, I am getting the following:

/usr/include/pthread.h:229 error: parse error before '*' token

It is repeated many times.

Any idea?


On Thu, Jan 20, 2011 at 11:57 AM, Grooms, Frederick W <
frederick.w.gro...@xo.com> wrote:

> gcc uses  -m64 instead of -xarch=v9
>
> Fred
>
> -Original Message-
> From: Action Request System discussion list(ARSList) [mailto:
> arslist@ARSLIST.ORG] On Behalf Of Axton
> Sent: Thursday, January 20, 2011 10:31 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Compile Driver on 64Bit Solaris
>
> ** Any reason you are using gcc over SUNWspro's cc?  Chances are, if you
> are seeing this error, the Makefile was constructed for SUNWspro.
>
> Axton Grams
>
> -Original Message-
> From: Action Request System discussion list(ARSList) [mailto:
> arslist@ARSLIST.ORG] On Behalf Of Frank Caruso
> Sent: Thursday, January 20, 2011 10:14 AM
> To: arslist@ARSLIST.ORG
> Subject: Compile Driver on 64Bit Solaris
>
> ** ARS 7.6.3
>
> Anyone out there been able to compile the driver program on Solaris 10
> 64bit?
>
> Using gcc 3.4.2 and get errors about "language arch=v9 not recognized"
>
> Thanks.
>
> Frank Caruso
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: User login issue

[Danny Kellett]

If you set the plugin log level to ALL then you can see the ldap reply
codes that will tell you exactly whats wrong

> We are running a server group (ARS 7.1 ITSM 7.0.03 p 9) and are seeing a
> strange issue.  We use LDAP authentication and have exactly the same LDAP
> settings on both servers in the server group...they point to the same
> server and use the same user to bind and the same settings to authenticate
> users.  We have a series of newly created users that can login to one
> server in the server group, but not the other.  When they can't login
> successfully, we see
> 20 2011 08:43:36.8357 */ LOGIN FAILED  (user)
> In the user log, with a matching
> C: 390695> /* Thu Jan 20 2011 08:43:36.8285 */+VL
> AREAVerifyLoginCallback  -- user 
> C: 390695> /* Thu Jan 20 2011 08:43:36.8306 */-VL
>   FAIL
> In the arplugin log.
> But if the same user logs in on the other server, it all works perfectly.
> If this was happening to all users on the problem server, I could
> understand that, but it seems to just be those created in the last month
> or so.  We are working with our AD admins to see if they can see a
> problem, but since the working server is using the same AD server, I can't
> see how it can be their problem.  Any ideas are appreciated.
>
> Anne Ramey
>
> ***
> E-mail correspondence to and from this address may be subject to the North
> Carolina Public Records Law and may be disclosed to third parties only by
> an authorized State Official.
>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: No Plans To Fix (SW00377001)

[Easter, David]

If Column logged the original defect, they should contact BMC Support and 
explain the situation. Or, another customer with a maintenance contract (or 
Column itself) could open a new defect.  Either works.

-David J. Easter
Manager of Product Management, Remedy Platform
BMC Software, Inc.
 
The opinions, statements, and/or suggested courses of action expressed in this 
E-mail do not necessarily reflect those of BMC Software, Inc.  My voluntary 
participation in this forum is not intended to convey a role as a spokesperson, 
liaison or public relations representative for BMC Software, Inc.


-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Thursday, January 20, 2011 09:52 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

Sowhat needs to happen to get this defect re-opened?it is happening
against the Web client.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
Sent: Thursday, January 20, 2011 10:35 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

That would be correct.  If the issue can be duplicated when a user logs in
through the Mid-Tier or an API program, then it would remain a valid defect
and could continue to be considered for a future release.  If that's the
case, then the defect was closed in error (influenced, as you say, but it
being logged against the wrong component).

In general, this is an important concept to remember when logging defects or
RFEs.  Because the future is the web client, make sure that issues not
unique to the Remedy User client are submitted as occurring through the web
client (or API programs) as well.  It will help ensure the issue is
processed properly.  

Thanks,

-David J. Easter
Manager of Product Management, Remedy Platform
BMC Software, Inc.
 
The opinions, statements, and/or suggested courses of action expressed in
this E-mail do not necessarily reflect those of BMC Software, Inc.  My
voluntary participation in this forum is not intended to convey a role as a
spokesperson, liaison or public relations representative for BMC Software,
Inc.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W
Sent: Thursday, January 20, 2011 09:19 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

LJ,

What if a read user logs in thru Mid-Tier?  If the logs show the same thing
then it sounds like ColumnIT opened the ticket to Remedy against the wrong
item  (Client instead of Server).


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
Sent: Thursday, January 20, 2011 11:05 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

** 
Hi LJ,

  The defect was logged against the AR System 7.5.00 Remedy User client.  As
announced over a year ago, the Remedy User client is being discontinued. 
Only business critical issues would be addressed in any patches to existing
versions of the Remedy User client.

  Also, the defect was tentatively targeted to be considered in the 7.6.04
release of AR System, but again only business critical issues would be
addressed around the Remedy User client and it was evaluated by BMC that
this was not of critical business impact.   According to the defect, it was
not ever assigned to be delivered in a patch - the target release was always
the internal codename for the 7.6.04 release.

Hope that helps answer your question.

-David J. Easter
Manager of Product Management, Remedy Platform
BMC Software, Inc.
 
The opinions, statements, and/or suggested courses of action expressed in
this E-mail do not necessarily reflect those of BMC Software, Inc.  My
voluntary participation in this forum is not intended to convey a role as a
spokesperson, liaison or public relations representative for BMC Software,
Inc.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Thursday, January 20, 2011 08:38 AM
To: arslist@ARSLIST.ORG
Subject: No Plans To Fix (SW00377001)

** 
WHAT

Ok.here is the problem.  I logged a support ticket with ColumnIT regarding a
problem in 7.5 where when a Read user logs in, if you have user logging
turned on it shows garbage characters in the log where the word 'READ'
should appear.  Column IT opens an issue with BMC.  BMC recognizes it as a
Defect and opens Defect ID SW00377001 stating that it will be corrected in a
later patch.  Today I checked back to see if it was going into a 'soon'
patch and see that the defect is closed.I look at the details and see that
the classification of the defect is 'No Plans to Fix'

I can't believe this.I go through all the effort to report a bug, they
recognize it as a bug, but close the defect saying

Re: No Plans To Fix (SW00377001)

[LJ LongWing]

Sowhat needs to happen to get this defect re-opened?it is happening
against the Web client.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
Sent: Thursday, January 20, 2011 10:35 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

That would be correct.  If the issue can be duplicated when a user logs in
through the Mid-Tier or an API program, then it would remain a valid defect
and could continue to be considered for a future release.  If that's the
case, then the defect was closed in error (influenced, as you say, but it
being logged against the wrong component).

In general, this is an important concept to remember when logging defects or
RFEs.  Because the future is the web client, make sure that issues not
unique to the Remedy User client are submitted as occurring through the web
client (or API programs) as well.  It will help ensure the issue is
processed properly.  

Thanks,

-David J. Easter
Manager of Product Management, Remedy Platform
BMC Software, Inc.
 
The opinions, statements, and/or suggested courses of action expressed in
this E-mail do not necessarily reflect those of BMC Software, Inc.  My
voluntary participation in this forum is not intended to convey a role as a
spokesperson, liaison or public relations representative for BMC Software,
Inc.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W
Sent: Thursday, January 20, 2011 09:19 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

LJ,

What if a read user logs in thru Mid-Tier?  If the logs show the same thing
then it sounds like ColumnIT opened the ticket to Remedy against the wrong
item  (Client instead of Server).


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
Sent: Thursday, January 20, 2011 11:05 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

** 
Hi LJ,

  The defect was logged against the AR System 7.5.00 Remedy User client.  As
announced over a year ago, the Remedy User client is being discontinued. 
Only business critical issues would be addressed in any patches to existing
versions of the Remedy User client.

  Also, the defect was tentatively targeted to be considered in the 7.6.04
release of AR System, but again only business critical issues would be
addressed around the Remedy User client and it was evaluated by BMC that
this was not of critical business impact.   According to the defect, it was
not ever assigned to be delivered in a patch - the target release was always
the internal codename for the 7.6.04 release.

Hope that helps answer your question.

-David J. Easter
Manager of Product Management, Remedy Platform
BMC Software, Inc.
 
The opinions, statements, and/or suggested courses of action expressed in
this E-mail do not necessarily reflect those of BMC Software, Inc.  My
voluntary participation in this forum is not intended to convey a role as a
spokesperson, liaison or public relations representative for BMC Software,
Inc.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Thursday, January 20, 2011 08:38 AM
To: arslist@ARSLIST.ORG
Subject: No Plans To Fix (SW00377001)

** 
WHAT

Ok.here is the problem.  I logged a support ticket with ColumnIT regarding a
problem in 7.5 where when a Read user logs in, if you have user logging
turned on it shows garbage characters in the log where the word 'READ'
should appear.  Column IT opens an issue with BMC.  BMC recognizes it as a
Defect and opens Defect ID SW00377001 stating that it will be corrected in a
later patch.  Today I checked back to see if it was going into a 'soon'
patch and see that the defect is closed.I look at the details and see that
the classification of the defect is 'No Plans to Fix'

I can't believe this.I go through all the effort to report a bug, they
recognize it as a bug, but close the defect saying they aren't planning on
fixing it?what is this crap?


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Trying to setup Remedy Import into HPD:IncidentInterface_Create

[Roger Justice]

This would be an error writing to the HPD:Help Desk form review the filter that 
writes to this form.





-Original Message-
From: Lammey, Peter A. 
To: arslist 
Sent: Thu, Jan 20, 2011 11:44 am
Subject: Trying to setup Remedy Import into HPD:IncidentInterface_Create


** 
I was tasked to setup a spreadsheet ingest process that would create resolved 
incidents in our Incident 7.02 system.
I updated all filters on the HPD:IncidentInterface_Create form to fire on Merge 
as well as Submit and it works for creating open Assigned tickets however after 
mapping all the fields that seemed necessary I seem to be getting this error:
 
Field does not exist on this form (ARERR 314)
 
I don’t know where to go with this error.
I ran filter logging on the server to see if anything surfaced on this but 
nothing jumped out as to why this is happening.
 
I have separate interfaces that were setup for different projects that included 
a display form that people would fill out and click a Submit Resolved button 
and the data would be pushed to IncidentInterface_Create with the same fields I 
am importing and the tickets get generated as resolved with no problem.
 
Perhaps a merge is surfacing bad code or something?
Anyone have any ideas?
 
Thanks 
Peter Lammey 
ESPN IT Packaging and Automation 
860-766-4761 
_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ 

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Trying to setup Remedy Import into HPD:IncidentInterface_Create

[Lammey, Peter A.]

I was tasked to setup a spreadsheet ingest process that would create resolved 
incidents in our Incident 7.02 system.
I updated all filters on the HPD:IncidentInterface_Create form to fire on Merge 
as well as Submit and it works for creating open Assigned tickets however after 
mapping all the fields that seemed necessary I seem to be getting this error:

Field does not exist on this form (ARERR 314)

I don't know where to go with this error.
I ran filter logging on the server to see if anything surfaced on this but 
nothing jumped out as to why this is happening.

I have separate interfaces that were setup for different projects that included 
a display form that people would fill out and click a Submit Resolved button 
and the data would be pushed to IncidentInterface_Create with the same fields I 
am importing and the tickets get generated as resolved with no problem.

Perhaps a merge is surfacing bad code or something?
Anyone have any ideas?

Thanks
Peter Lammey
ESPN IT Packaging and Automation
860-766-4761

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: User login issue

[LJ LongWing]

Anne,

Turn your logging level up to 'All' and see what kind of details you can
find regarding why it's failing.

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Ramey, Anne
Sent: Thursday, January 20, 2011 10:22 AM
To: arslist@ARSLIST.ORG
Subject: User login issue

 

** 

We are running a server group (ARS 7.1 ITSM 7.0.03 p 9) and are seeing a
strange issue.  We use LDAP authentication and have exactly the same LDAP
settings on both servers in the server group.they point to the same server
and use the same user to bind and the same settings to authenticate users.
We have a series of newly created users that can login to one server in the
server group, but not the other.  When they can't login successfully, we see


20 2011 08:43:36.8357 */ LOGIN FAILED  (user)

In the user log, with a matching

C: 390695> /* Thu Jan 20 2011 08:43:36.8285 */+VLAREAVerifyLoginCallback
-- user

C: 390695> /* Thu Jan 20 2011 08:43:36.8306 */-VL
FAIL

In the arplugin log.

But if the same user logs in on the other server, it all works perfectly.
If this was happening to all users on the problem server, I could understand
that, but it seems to just be those created in the last month or so.  We are
working with our AD admins to see if they can see a problem, but since the
working server is using the same AD server, I can't see how it can be their
problem.  Any ideas are appreciated.

 

Anne Ramey

***

E-mail correspondence to and from this address may be subject to the North
Carolina Public Records Law and may be disclosed to third parties only by an
authorized State Official.

 

_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ 


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: No Plans To Fix (SW00377001)

[LJ LongWing]

All of my users are Mid-Tierso it's the same thingSo being someone
logged the defect wrong, does that mean that I need to open ANOTHER ticket
with ColumnIT to have BMC log the defect properly?

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W
Sent: Thursday, January 20, 2011 10:19 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

LJ,

What if a read user logs in thru Mid-Tier?  If the logs show the same thing
then it sounds like ColumnIT opened the ticket to Remedy against the wrong
item  (Client instead of Server).


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
Sent: Thursday, January 20, 2011 11:05 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

** 
Hi LJ,

  The defect was logged against the AR System 7.5.00 Remedy User client.  As
announced over a year ago, the Remedy User client is being discontinued. 
Only business critical issues would be addressed in any patches to existing
versions of the Remedy User client.

  Also, the defect was tentatively targeted to be considered in the 7.6.04
release of AR System, but again only business critical issues would be
addressed around the Remedy User client and it was evaluated by BMC that
this was not of critical business impact.   According to the defect, it was
not ever assigned to be delivered in a patch - the target release was always
the internal codename for the 7.6.04 release.

Hope that helps answer your question.

-David J. Easter
Manager of Product Management, Remedy Platform
BMC Software, Inc.
 
The opinions, statements, and/or suggested courses of action expressed in
this E-mail do not necessarily reflect those of BMC Software, Inc.  My
voluntary participation in this forum is not intended to convey a role as a
spokesperson, liaison or public relations representative for BMC Software,
Inc.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Thursday, January 20, 2011 08:38 AM
To: arslist@ARSLIST.ORG
Subject: No Plans To Fix (SW00377001)

** 
WHAT

Ok.here is the problem.  I logged a support ticket with ColumnIT regarding a
problem in 7.5 where when a Read user logs in, if you have user logging
turned on it shows garbage characters in the log where the word 'READ'
should appear.  Column IT opens an issue with BMC.  BMC recognizes it as a
Defect and opens Defect ID SW00377001 stating that it will be corrected in a
later patch.  Today I checked back to see if it was going into a 'soon'
patch and see that the defect is closed.I look at the details and see that
the classification of the defect is 'No Plans to Fix'

I can't believe this.I go through all the effort to report a bug, they
recognize it as a bug, but close the defect saying they aren't planning on
fixing it?what is this crap?


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: issue in setting up reconciliation rules..

[rmduser]

thanks


rmduser wrote:
> 
> Thanks a lot Peter.Your post really helps.
>  I had an understanding that we can transform the recon rules according to
> our way to whatever depth. & that was the reason, I gave relationship
> identification rules also, just to make sure that I dont miss on any of
> the data of test dataset.
> 
> 
> Peter Romain-2 wrote:
>> 
>> Hi,
>> 
>> What you describe is the behaviour I would expect.
>> 
>> When a Computer CI is related to an IP CI via a weak relationship (hosted
>> access point is weak) then the Computer and IP are treated as a composite
>> object and not individually.
>> 
>> The IP in the test dataset will only be reconciled against an existing IP
>> in
>> the production dataset if they are both related to the same computer.
>> 
>> Try your test again using strong relationships between the computer and
>> IP
>> CIs and you should see the behaviour you are expecting (though you should
>> revert to the hosted access point relationship after testing).
>> 
>> I don't understand why you are identifying relationships. Just create
>> identification rules for the main CI's and the relationships will take
>> care
>> of themselves.
>> 
>> Cheers
>> 
>> Peter
>> 
>> 
>> -Original Message-
>> From: Action Request System discussion list(ARSList)
>> [mailto:arslist@ARSLIST.ORG] On Behalf Of rmdusr
>> Sent: 19 January 2011 13:27
>> To: arslist@ARSLIST.ORG
>> Subject: issue in setting up reconciliation rules..
>> 
>> Hi,
>> 
>> Env: ARS 7.5 patch4, Atrium CMDB 7.6 patch1,ITSM 7.0.3 patch9
>>  
>> I will try best to explain this complex issue in simple way!
>> 
>> I am making a custom recon job, which identifies a test
>> dataset(containing
>> computer system , IP Endpoint, LANendpoint, Hosted
>> accesspoint(relationships
>> between comp-IP & comp-LAN).
>> 
>>  
>> Idea is to update the existing CIs & create the new ones.
>> 
>>  
>> I have set 'identification rulesets' for each CI class based on AssetId (
>> 'AssetID' = $AssetID$)
>> 
>> For the relationship class(hosted accesspoint), my identification rule
>> set
>> is ('Source Reconid' =$SourceReconid$) & ('Destination Reconid' =
>> $Destination Reconid$).
>> 
>>  
>> Now if my test dataset has Computer System C1, it checks against
>> Production
>> dataset's Computer system C1, & updates it. If it does not find it, it
>> creates C1. 
>> 
>>  
>> But, this does not happen for IPEndpoint class, if CI with AssetID, say
>> IP1
>> is already existing in prod dataset & may be related to C2 in production
>> dataset.When the test dataset has IP1 related to C3, C3 gets
>> created(because
>> it was not in prod dataset before) but a duplicate IP1 also gets created
>> in
>> production dataset. along with their relationship(C3--->IP1), although I
>> already have C2>IP1 in the prod dataset. So, in nut shell, I have 2
>> instances of same Asset id IP1(ofcourse they have different recon ids), 1
>> linked to computer C2 & other to computer C3.
>> 
>>  
>> The same thing happens for LANEndpoint class.
>> 
>>  
>> I am aware of the cardinality of hostedaccesspoint is 1-Many. So, 1 Comp
>> CI
>> can have multiple IPEndpoints, but not vice versa. So, holding this
>> standard
>> architecture rule, I expect that recon job should create only new IP CIs,
>> &
>> not duplicates.
>> 
>>  
>> & talking bout relationship CIs, then if it encounters an IP1 which is
>> already related to a Computer C2, it should not create a second
>> relationship
>> 
>> 
>> C3--->IP1.
>> 
>> Any help!
>> 
>> -- 
>> View this message in context:
>> http://ars-action-request-system.1093659.n2.nabble.com/issue-in-setting-up-r
>> econciliation-rules-tp5939613p5939613.html
>> Sent from the ARS (Action Request System) mailing list archive at
>> Nabble.com.
>> 
>> 
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>> 
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>> 
>> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/issue-in-setting-up-reconciliation-rules..-tp30709825p30721509.html
Sent from the ARS (Action Request System) mailing list archive at Nabble.com.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: No Plans To Fix (SW00377001)

[LJ LongWing]

It is not a client defect, it is a SERVER defect..server 'User Logging'..the
server doesn't properly log the license type allocated for Read users..

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
Sent: Thursday, January 20, 2011 10:05 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

 

** 

Hi LJ,

 

  The defect was logged against the AR System 7.5.00 Remedy User client.  As
announced over a year ago, the Remedy User client is being discontinued.
Only business critical issues would be addressed in any patches to existing
versions of the Remedy User client.

 

  Also, the defect was tentatively targeted to be considered in the 7.6.04
release of AR System, but again only business critical issues would be
addressed around the Remedy User client and it was evaluated by BMC that
this was not of critical business impact.   According to the defect, it was
not ever assigned to be delivered in a patch - the target release was always
the internal codename for the 7.6.04 release.

 

Hope that helps answer your question.

 

-David J. Easter

Manager of Product Management, Remedy Platform

BMC Software, Inc.

 

The opinions, statements, and/or suggested courses of action expressed in
this E-mail do not necessarily reflect those of BMC Software, Inc.  My
voluntary participation in this forum is not intended to convey a role as a
spokesperson, liaison or public relations representative for BMC Software,
Inc.

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Thursday, January 20, 2011 08:38 AM
To: arslist@ARSLIST.ORG
Subject: No Plans To Fix (SW00377001)

 

** 

WHAT

 

Ok.here is the problem.  I logged a support ticket with ColumnIT regarding a
problem in 7.5 where when a Read user logs in, if you have user logging
turned on it shows garbage characters in the log where the word 'READ'
should appear.  Column IT opens an issue with BMC.  BMC recognizes it as a
Defect and opens Defect ID SW00377001 stating that it will be corrected in a
later patch.  Today I checked back to see if it was going into a 'soon'
patch and see that the defect is closed.I look at the details and see that
the classification of the defect is 'No Plans to Fix'

 

I can't believe this.I go through all the effort to report a bug, they
recognize it as a bug, but close the defect saying they aren't planning on
fixing it?what is this crap?

_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ 

_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ 


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: No Plans To Fix (SW00377001)

[Easter, David]

That would be correct.  If the issue can be duplicated when a user logs in 
through the Mid-Tier or an API program, then it would remain a valid defect and 
could continue to be considered for a future release.  If that's the case, then 
the defect was closed in error (influenced, as you say, but it being logged 
against the wrong component).

In general, this is an important concept to remember when logging defects or 
RFEs.  Because the future is the web client, make sure that issues not unique 
to the Remedy User client are submitted as occurring through the web client (or 
API programs) as well.  It will help ensure the issue is processed properly.  

Thanks,

-David J. Easter
Manager of Product Management, Remedy Platform
BMC Software, Inc.
 
The opinions, statements, and/or suggested courses of action expressed in this 
E-mail do not necessarily reflect those of BMC Software, Inc.  My voluntary 
participation in this forum is not intended to convey a role as a spokesperson, 
liaison or public relations representative for BMC Software, Inc.

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W
Sent: Thursday, January 20, 2011 09:19 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

LJ,

What if a read user logs in thru Mid-Tier?  If the logs show the same thing 
then it sounds like ColumnIT opened the ticket to Remedy against the wrong item 
 (Client instead of Server).


-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
Sent: Thursday, January 20, 2011 11:05 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

** 
Hi LJ,

  The defect was logged against the AR System 7.5.00 Remedy User client.  As 
announced over a year ago, the Remedy User client is being discontinued.  Only 
business critical issues would be addressed in any patches to existing versions 
of the Remedy User client.

  Also, the defect was tentatively targeted to be considered in the 7.6.04 
release of AR System, but again only business critical issues would be 
addressed around the Remedy User client and it was evaluated by BMC that this 
was not of critical business impact.   According to the defect, it was not ever 
assigned to be delivered in a patch - the target release was always the 
internal codename for the 7.6.04 release.

Hope that helps answer your question.

-David J. Easter
Manager of Product Management, Remedy Platform
BMC Software, Inc.
 
The opinions, statements, and/or suggested courses of action expressed in this 
E-mail do not necessarily reflect those of BMC Software, Inc.  My voluntary 
participation in this forum is not intended to convey a role as a spokesperson, 
liaison or public relations representative for BMC Software, Inc.

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Thursday, January 20, 2011 08:38 AM
To: arslist@ARSLIST.ORG
Subject: No Plans To Fix (SW00377001)

** 
WHAT

Ok.here is the problem.  I logged a support ticket with ColumnIT regarding a 
problem in 7.5 where when a Read user logs in, if you have user logging turned 
on it shows garbage characters in the log where the word 'READ' should appear.  
Column IT opens an issue with BMC.  BMC recognizes it as a Defect and opens 
Defect ID SW00377001 stating that it will be corrected in a later patch.  Today 
I checked back to see if it was going into a 'soon' patch and see that the 
defect is closed.I look at the details and see that the classification of the 
defect is 'No Plans to Fix'

I can't believe this.I go through all the effort to report a bug, they 
recognize it as a bug, but close the defect saying they aren't planning on 
fixing it?what is this crap?

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: No Plans To Fix (SW00377001)

[LJ LongWing]

Yes…exactly like that….safe to ignore?I would say no…and the fact that
BMC considers it a ‘no plans to fix’, then I would definitely say no…not
safe to ignore….I expect that BMC would want to be reporting their license
type properly in their logs….can I get you to log a defect with them citing
this defect #?  Can I get EVERYONE on the list to log a defect?I don’t
consider it acceptable that they won’t fix this.

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Brien Dieterle
Sent: Thursday, January 20, 2011 9:52 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

 

** 

You mean like this?

?WH
#æµá˜÷Ø[Þ  GRANT READ  

This is normal-- Remedy has three types of licenses, "FIXED", "FLOAT", and
*SNEEZE*.  Seriously though, I'm glad we're not the only ones seeing this in
the the user log, thanks for reporting it.  I suppose that means it is safe
to ignore then?

Brien 

On 1/20/2011 9:37 AM, LJ LongWing wrote: 

** 

WHAT

 

Ok…here is the problem.  I logged a support ticket with ColumnIT regarding a
problem in 7.5 where when a Read user logs in, if you have user logging
turned on it shows garbage characters in the log where the word ‘READ’
should appear.  Column IT opens an issue with BMC.  BMC recognizes it as a
Defect and opens Defect ID SW00377001 stating that it will be corrected in a
later patch.  Today I checked back to see if it was going into a ‘soon’
patch and see that the defect is closed…I look at the details and see that
the classification of the defect is ‘No Plans to Fix’

 

I can’t believe this…I go through all the effort to report a bug, they
recognize it as a bug, but close the defect saying they aren’t planning on
fixing it?what is this crap?

_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ 

_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

User login issue

[Ramey, Anne]

We are running a server group (ARS 7.1 ITSM 7.0.03 p 9) and are seeing a 
strange issue.  We use LDAP authentication and have exactly the same LDAP 
settings on both servers in the server group...they point to the same server 
and use the same user to bind and the same settings to authenticate users.  We 
have a series of newly created users that can login to one server in the server 
group, but not the other.  When they can't login successfully, we see
20 2011 08:43:36.8357 */ LOGIN FAILED  (user)
In the user log, with a matching
C: 390695> /* Thu Jan 20 2011 08:43:36.8285 */+VLAREAVerifyLoginCallback
  -- user 
C: 390695> /* Thu Jan 20 2011 08:43:36.8306 */-VL   
 FAIL
In the arplugin log.
But if the same user logs in on the other server, it all works perfectly.  If 
this was happening to all users on the problem server, I could understand that, 
but it seems to just be those created in the last month or so.  We are working 
with our AD admins to see if they can see a problem, but since the working 
server is using the same AD server, I can't see how it can be their problem.  
Any ideas are appreciated.

Anne Ramey

***
E-mail correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties only by an 
authorized State Official.


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: No Plans To Fix (SW00377001)

[Grooms, Frederick W]

LJ,

What if a read user logs in thru Mid-Tier?  If the logs show the same thing 
then it sounds like ColumnIT opened the ticket to Remedy against the wrong item 
 (Client instead of Server).


-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
Sent: Thursday, January 20, 2011 11:05 AM
To: arslist@ARSLIST.ORG
Subject: Re: No Plans To Fix (SW00377001)

** 
Hi LJ,

  The defect was logged against the AR System 7.5.00 Remedy User client.  As 
announced over a year ago, the Remedy User client is being discontinued.  Only 
business critical issues would be addressed in any patches to existing versions 
of the Remedy User client.

  Also, the defect was tentatively targeted to be considered in the 7.6.04 
release of AR System, but again only business critical issues would be 
addressed around the Remedy User client and it was evaluated by BMC that this 
was not of critical business impact.   According to the defect, it was not ever 
assigned to be delivered in a patch - the target release was always the 
internal codename for the 7.6.04 release.

Hope that helps answer your question.

-David J. Easter
Manager of Product Management, Remedy Platform
BMC Software, Inc.
 
The opinions, statements, and/or suggested courses of action expressed in this 
E-mail do not necessarily reflect those of BMC Software, Inc.  My voluntary 
participation in this forum is not intended to convey a role as a spokesperson, 
liaison or public relations representative for BMC Software, Inc.

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Thursday, January 20, 2011 08:38 AM
To: arslist@ARSLIST.ORG
Subject: No Plans To Fix (SW00377001)

** 
WHAT

Ok.here is the problem.  I logged a support ticket with ColumnIT regarding a 
problem in 7.5 where when a Read user logs in, if you have user logging turned 
on it shows garbage characters in the log where the word 'READ' should appear.  
Column IT opens an issue with BMC.  BMC recognizes it as a Defect and opens 
Defect ID SW00377001 stating that it will be corrected in a later patch.  Today 
I checked back to see if it was going into a 'soon' patch and see that the 
defect is closed.I look at the details and see that the classification of the 
defect is 'No Plans to Fix'

I can't believe this.I go through all the effort to report a bug, they 
recognize it as a bug, but close the defect saying they aren't planning on 
fixing it?what is this crap?

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Compile Driver on 64Bit Solaris

[Grooms, Frederick W]

gcc uses  -m64 instead of -xarch=v9

Fred

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Axton
Sent: Thursday, January 20, 2011 10:31 AM
To: arslist@ARSLIST.ORG
Subject: Re: Compile Driver on 64Bit Solaris

** Any reason you are using gcc over SUNWspro's cc?  Chances are, if you are 
seeing this error, the Makefile was constructed for SUNWspro.

Axton Grams

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Frank Caruso
Sent: Thursday, January 20, 2011 10:14 AM
To: arslist@ARSLIST.ORG
Subject: Compile Driver on 64Bit Solaris

** ARS 7.6.3

Anyone out there been able to compile the driver program on Solaris 10 64bit?

Using gcc 3.4.2 and get errors about "language arch=v9 not recognized"

Thanks.

Frank Caruso

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: No Plans To Fix (SW00377001)

[Easter, David]

Hi LJ,

  The defect was logged against the AR System 7.5.00 Remedy User client.  As 
announced over a year ago, the Remedy User client is being discontinued.  Only 
business critical issues would be addressed in any patches to existing versions 
of the Remedy User client.

  Also, the defect was tentatively targeted to be considered in the 7.6.04 
release of AR System, but again only business critical issues would be 
addressed around the Remedy User client and it was evaluated by BMC that this 
was not of critical business impact.   According to the defect, it was not ever 
assigned to be delivered in a patch - the target release was always the 
internal codename for the 7.6.04 release.

Hope that helps answer your question.

-David J. Easter
Manager of Product Management, Remedy Platform
BMC Software, Inc.

The opinions, statements, and/or suggested courses of action expressed in this 
E-mail do not necessarily reflect those of BMC Software, Inc.  My voluntary 
participation in this forum is not intended to convey a role as a spokesperson, 
liaison or public relations representative for BMC Software, Inc.

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Thursday, January 20, 2011 08:38 AM
To: arslist@ARSLIST.ORG
Subject: No Plans To Fix (SW00377001)

**
WHAT

Ok...here is the problem.  I logged a support ticket with ColumnIT regarding a 
problem in 7.5 where when a Read user logs in, if you have user logging turned 
on it shows garbage characters in the log where the word 'READ' should appear.  
Column IT opens an issue with BMC.  BMC recognizes it as a Defect and opens 
Defect ID SW00377001 stating that it will be corrected in a later patch.  Today 
I checked back to see if it was going into a 'soon' patch and see that the 
defect is closed...I look at the details and see that the classification of the 
defect is 'No Plans to Fix'

I can't believe this...I go through all the effort to report a bug, they 
recognize it as a bug, but close the defect saying they aren't planning on 
fixing it?what is this crap?
_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: No Plans To Fix (SW00377001)

[Brien Dieterle]

**


  
  
You mean like this?

?WH#æµá˜÷Ø[Þ  GRANT READ  

This is normal-- Remedy has three types of licenses, "FIXED",
"FLOAT", and *SNEEZE*.  Seriously though, I'm glad we're not the
only ones seeing this in the the user log, thanks for reporting it. 
I suppose that means it is safe to ignore then?

Brien 

On 1/20/2011 9:37 AM, LJ LongWing wrote:
**
  
  
  
  
WHAT
 
Ok…here is the problem.  I logged a support
ticket
with ColumnIT regarding a problem in 7.5 where when a Read
user logs in, if you
have user logging turned on it shows garbage characters in
the log where the
word ‘READ’ should appear.  Column IT opens an issue with
BMC.  BMC recognizes it as a Defect and opens Defect ID
SW00377001 stating
that it will be corrected in a later patch.  Today I checked
back to see
if it was going into a ‘soon’ patch and see that the defect
is
closed…I look at the details and see that the classification
of the
defect is ‘No Plans to Fix’
 
I can’t believe this…I go through all the effort
to
report a bug, they recognize it as a bug, but close the
defect saying they aren’t
planning on fixing it?what is this crap?
  
  _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_

  

_attend WWRUG11 www.wwrug.com  ARSlist: "Where the Answers Are"_

No Plans To Fix (SW00377001)

[LJ LongWing]

WHAT

 

Ok.here is the problem.  I logged a support ticket with ColumnIT regarding a
problem in 7.5 where when a Read user logs in, if you have user logging
turned on it shows garbage characters in the log where the word 'READ'
should appear.  Column IT opens an issue with BMC.  BMC recognizes it as a
Defect and opens Defect ID SW00377001 stating that it will be corrected in a
later patch.  Today I checked back to see if it was going into a 'soon'
patch and see that the defect is closed.I look at the details and see that
the classification of the defect is 'No Plans to Fix'

 

I can't believe this.I go through all the effort to report a bug, they
recognize it as a bug, but close the defect saying they aren't planning on
fixing it?what is this crap?


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Compile Driver on 64Bit Solaris

[Axton]

Any reason you are using gcc over SUNWspro's cc?  Chances are, if you are
seeing this error, the Makefile was constructed for SUNWspro.

Axton Grams

The opinions, statements, and/or suggested courses of action expressed in
this E-mail do not necessarily reflect those of BMC Software, Inc.  My
voluntary participation in this forum is not intended to convey a role as a
spokesperson, liaison or public relations representative for BMC Software,
Inc.

On Thu, Jan 20, 2011 at 10:14 AM, Frank Caruso wrote:

> ** ARS 7.6.3
>
> Anyone out there been able to compile the driver program on Solaris 10
> 64bit?
>
> Using gcc 3.4.2 and get errors about "language arch=v9 not recognized"
>
> Thanks.
>
> Frank Caruso
> _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Compile Driver on 64Bit Solaris

[Frank Caruso]

ARS 7.6.3

Anyone out there been able to compile the driver program on Solaris 10
64bit?

Using gcc 3.4.2 and get errors about "language arch=v9 not recognized"

Thanks.

Frank Caruso

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Macro not honoring the data retrival settings

[Grooms, Frederick W]

Let me get this straight ...You want the Macro to also be limited to the 
1000 records returned.

You can go in on the server and set the Max Rows returned (for 5.0.1 check the 
server properties thru the Admin tool.  I think the Advanced tab)

Fred

-Original Message-
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Viki_kulkarni
Sent: Thursday, January 20, 2011 1:01 AM
To: arslist@ARSLIST.ORG
Subject: Macro not honoring the data retrival settings

hi all,

I have a macro running on a form that searches for all records on the form
which has more than 1000 records.
now we have set the max number of records to retrieve = 1000 in the user
tools option.

what we see is that when we make a search call explicit on that form we get
only 1000 records as per the settings but if we perform the same search via
a simple search macro we get more than 1000 records in fact we get the
actual number of records.

can any one share any idea how to avoid this?? we are on ARS 5.0.1 and user
tool is 701.


Thanks,
Viki

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: OWASP assessment (Mid-Tier)?

[Leihkauff, Kenneth]

Thank you, David.  This is very helpful information when trying to satisfy 
customer inquiries.

Ken Leihkauff
North American Integrated Services Management Center (NAISMC)
Science Applications International Corp. (SAIC)

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Easter, David
Sent: Wednesday, January 19, 2011 3:51 PM
To: arslist@ARSLIST.ORG
Subject: Re: OWASP assessment (Mid-Tier)?

**
There is a security white paper that describes how AR System deals with these 
kind of security situations:

02-Nov-2010

BMC Remedy Action Request System 7.6.03 AR System Security

PDF


AR System 7.5.00 is also undergoing Common Criteria certification as can be 
seen here: http://www.niap-ccevs.org/in_evaluation/.  AR System 6.3.00 already 
achieved Common Criteria at EAL3 a few years ago: 
http://www.niap-ccevs.org/cc-scheme/st/vid10101/

-David J. Easter
Manager of Product Management, Remedy Platform
BMC Software, Inc.

The opinions, statements, and/or suggested courses of action expressed in this 
E-mail do not necessarily reflect those of BMC Software, Inc.  My voluntary 
participation in this forum is not intended to convey a role as a spokesperson, 
liaison or public relations representative for BMC Software, Inc.

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Leihkauff, Kenneth
Sent: Wednesday, January 19, 2011 12:20 PM
To: arslist@ARSLIST.ORG
Subject: OWASP assessment (Mid-Tier)?

**
Does anyone know if Remedy Mid-Tier has been evaluated with respect to the 
"Open Web Application Security Project (OWASP)" top 10 web applications 
security vulnerabilities list?

Thank you.
The OWASP Top 10 Web Application Security Risks for 2010 are:

 *   A1: Injection
 *   A2: Cross-Site Scripting (XSS)
 *   A3: Broken Authentication and Session Management
 *   A4: Insecure Direct Object References
 *   A5: Cross-Site Request Forgery (CSRF)
 *   A6: Security Misconfiguration
 *   A7: Insecure Cryptographic Storage
 *   A8: Failure to Restrict URL Access
 *   A9: Insufficient Transport Layer Protection
 *   A10: Unvalidated Redirects and Forwards

Ken Leihkauff
North American Integrated Services Management Center (NAISMC)
Science Applications International Corp. (SAIC)

_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_
_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Set fields problem

[Brittain, Mark]

Hi Cindy,

I am on V6 and it is not so bad. What happens if you run the same action in the 
RUT? Do you get the desired results? Sounds like there is a rogue active link 
there that comes later and is overwriting what the first active link is doing.  
Use ARS Log Display to capture the activity and have a look.

Mark

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Basile, Cindy
Sent: Wednesday, January 19, 2011 4:59 PM
To: arslist@ARSLIST.ORG
Subject: Set fields problem

**

Hello,

First off, I'm using Remedy V6 - I know, I know  =)

I am opening a WEB form via a URL - in the URL is the Change ID+ from a 
particular change control.  I have an active link that is using a set fields to 
populate some fields on the WEB form on "window open/window loaded/display".  
The set fields IS getting the data from the correct Change control - the 
problem is that some of the fields are being populated with data from what 
should be mapping to other fields.  I have an active link log and I can see the 
data being sent to the wrong fields, but it correctly mapped in the AL.  For 
instance,
Set-fields 536871283 = testbed testbed
should be being populated with the association, but its being populated with 
the Requesters Name, 536871419, which is in the AL but not in the log.

Now, if I open the WEB form as an administrator, the fields map correctly.  Any 
help would be greatly appreciated!

FieldList.Query([object Object], @, CHG:Change, 3, 2)
  Set-fields 536871431 = 1/1/4713 BC - (should not be displaying the BC date, 
just a date)
  Set-fields 536871078 = 1/21/2011
  Set-fields 536871270 = FPI
  Set-fields 536871429 = test sar - please ignore
  Set-fields 536880913 =
  Set-fields 35043 =
  Set-fields 35042 =
  Set-fields 536871430 =
  Set-fields 536871283 = testbed testbed
  Set-fields 536871057 = Cindy Basile
  Set-fields 536871058 = Useruser
  Set-fields 536871055 = juser2
  Set-fields 536871080 = truck driver
  Set-fields 536871094 = New Employee
ARStateChange Complete : Current state is 1

Thank you,
Cindy Basile


Cindy Basile
System Support Lead
Financial Partners, Inc.
509-340-5480




CONFIDENTIALITY NOTICE:

This e-mail transmission may contain confidential information.

This information is solely for the use of the individual(s) or

entity to whom or which it was intended. If not an intended

recipient, any review, copying, printing, disclosure,

distribution or any other use is strictly prohibited.

If you have received this email in error, please immediately

notify the sender by reply e-mail. Please delete this e-mail

from your files if you are not the intended recipient. Thank you.





_attend WWRUG11 www.wwrug.com  ARSlist: "Where the Answers Are"_


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
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Macro not honoring the data retrival settings

[Viki_kulkarni]

hi,

No the names are in place as well. Is there any way we can disable macros to
run for any user? I mean is there any server setting to disable macros
globally.

I am trying to look for it but not able to find anything about it.

Thanks,
viki


Misi Mladoniczky wrote:
> 
> Hi,
> 
> Could it be that you have different server names in the Macro and in your
> Login? For example a hostname, IP-address or a fully qualified hostname?
> 
> Best Regards - Misi, RRR AB, http://rrr.se
> 
>> I too tried this on my 75 environment and it seems to work. Also one more
>> strange think it is not happening for all forms..
>>
>> I changed the form to search with a similar macro and on that form it did
>> honor..
>>
>> Am i missing something??
>>
>> thanks,
>> Viki
>>
>> Misi Mladoniczky wrote:
>>>
>>> Hi,
>>>
>>> I recall that some settings could be changed during macro recording in
>>> the
>>> past. Apparently not the max-records-returned setting...
>>>
>>> I tried this on my 7.6.03 environment.
>>>
>>> The Macro honored the setting for my user regardless of the setting
>>> during
>>> the actual macro recording. This seems to be at odds with what you are
>>> seeing.
>>>
>>> I would not expect the version of the server to affect this.
>>>
>>> Best Regards - Misi, RRR AB, http://www.rrr.se
>>>
>>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
>>> * 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 Misi,

 it still gives me more than 1000 records..

 Thanks,
 Vikrant

 Misi Mladoniczky wrote:
>
> Hi,
>
> Try recording a new macro where you actually go in and change this
> setting
> to 1000 during the recording.
>
> You may have to set it to something other than 1000 before you start
> the
> recording...
>
> Best Regards - Misi, RRR AB, http://www.rrr.se
>
> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
> * 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 have a macro running on a form that searches for all records on the
>> form
>> which has more than 1000 records.
>> now we have set the max number of records to retrieve = 1000 in the
>> user
>> tools option.
>>
>> what we see is that when we make a search call explicit on that form
>> we
>> get
>> only 1000 records as per the settings but if we perform the same
>> search
>> via
>> a simple search macro we get more than 1000 records in fact we get
>> the
>> actual number of records.
>>
>> can any one share any idea how to avoid this?? we are on ARS 5.0.1
>> and
>> user
>> tool is 701.
>>
>>
>> Thanks,
>> Viki
>> --
>> View this message in context:
>> http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30716698p30716698.html
>> Sent from the ARS (Action Request System) mailing list archive at
>> Nabble.com.
>>
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>>
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>
>

 --
 View this message in context:
 http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30716698p30716858.html
 Sent from the ARS (Action Request System) mailing list archive at
 Nabble.com.

 ___
 UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
 attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

>>>
>>> ___
>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>>>
>>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30716698p30717307.html
>> Sent from the ARS (Action Request System) mailing list archive at
>> Nabble.com.
>>
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>>
> 
> 

Re: Macro not honoring the data retrival settings

[Misi Mladoniczky]

Hi,

Could it be that you have different server names in the Macro and in your
Login? For example a hostname, IP-address or a fully qualified hostname?

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

> I too tried this on my 75 environment and it seems to work. Also one more
> strange think it is not happening for all forms..
>
> I changed the form to search with a similar macro and on that form it did
> honor..
>
> Am i missing something??
>
> thanks,
> Viki
>
> Misi Mladoniczky wrote:
>>
>> Hi,
>>
>> I recall that some settings could be changed during macro recording in
>> the
>> past. Apparently not the max-records-returned setting...
>>
>> I tried this on my 7.6.03 environment.
>>
>> The Macro honored the setting for my user regardless of the setting
>> during
>> the actual macro recording. This seems to be at odds with what you are
>> seeing.
>>
>> I would not expect the version of the server to affect this.
>>
>> Best Regards - Misi, RRR AB, http://www.rrr.se
>>
>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
>> * 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 Misi,
>>>
>>> it still gives me more than 1000 records..
>>>
>>> Thanks,
>>> Vikrant
>>>
>>> Misi Mladoniczky wrote:

 Hi,

 Try recording a new macro where you actually go in and change this
 setting
 to 1000 during the recording.

 You may have to set it to something other than 1000 before you start
 the
 recording...

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

 Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
 * 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 have a macro running on a form that searches for all records on the
> form
> which has more than 1000 records.
> now we have set the max number of records to retrieve = 1000 in the
> user
> tools option.
>
> what we see is that when we make a search call explicit on that form
> we
> get
> only 1000 records as per the settings but if we perform the same
> search
> via
> a simple search macro we get more than 1000 records in fact we get
> the
> actual number of records.
>
> can any one share any idea how to avoid this?? we are on ARS 5.0.1
> and
> user
> tool is 701.
>
>
> Thanks,
> Viki
> --
> View this message in context:
> http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30716698p30716698.html
> Sent from the ARS (Action Request System) mailing list archive at
> Nabble.com.
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>

 ___
 UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
 attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"


>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30716698p30716858.html
>>> Sent from the ARS (Action Request System) mailing list archive at
>>> Nabble.com.
>>>
>>> ___
>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>>>
>>
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>>
>>
>
> --
> View this message in context:
> http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30716698p30717307.html
> Sent from the ARS (Action Request System) mailing list archive at
> Nabble.com.
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Macro not honoring the data retrival settings

[Viki_kulkarni]

I too tried this on my 75 environment and it seems to work. Also one more
strange think it is not happening for all forms.. 

I changed the form to search with a similar macro and on that form it did
honor..

Am i missing something??

thanks,
Viki

Misi Mladoniczky wrote:
> 
> Hi,
> 
> I recall that some settings could be changed during macro recording in the
> past. Apparently not the max-records-returned setting...
> 
> I tried this on my 7.6.03 environment.
> 
> The Macro honored the setting for my user regardless of the setting during
> the actual macro recording. This seems to be at odds with what you are
> seeing.
> 
> I would not expect the version of the server to affect this.
> 
> Best Regards - Misi, RRR AB, http://www.rrr.se
> 
> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
> * 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 Misi,
>>
>> it still gives me more than 1000 records..
>>
>> Thanks,
>> Vikrant
>>
>> Misi Mladoniczky wrote:
>>>
>>> Hi,
>>>
>>> Try recording a new macro where you actually go in and change this
>>> setting
>>> to 1000 during the recording.
>>>
>>> You may have to set it to something other than 1000 before you start the
>>> recording...
>>>
>>> Best Regards - Misi, RRR AB, http://www.rrr.se
>>>
>>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
>>> * 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 have a macro running on a form that searches for all records on the
 form
 which has more than 1000 records.
 now we have set the max number of records to retrieve = 1000 in the
 user
 tools option.

 what we see is that when we make a search call explicit on that form we
 get
 only 1000 records as per the settings but if we perform the same search
 via
 a simple search macro we get more than 1000 records in fact we get the
 actual number of records.

 can any one share any idea how to avoid this?? we are on ARS 5.0.1 and
 user
 tool is 701.


 Thanks,
 Viki
 --
 View this message in context:
 http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30716698p30716698.html
 Sent from the ARS (Action Request System) mailing list archive at
 Nabble.com.

 ___
 UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
 attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

>>>
>>> ___
>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>>>
>>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30716698p30716858.html
>> Sent from the ARS (Action Request System) mailing list archive at
>> Nabble.com.
>>
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>>
> 
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30716698p30717307.html
Sent from the ARS (Action Request System) mailing list archive at Nabble.com.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Macro not honoring the data retrieval settings

[Misi Mladoniczky]

Hi,

Macros are supported as long as we have a Windows Client with
Macro-functionality.

Open Window was introduced after 5.0.1, so that is not an option.

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

> Hello All
>
> Way try to record a macro when there is 'Open window' action?
>
> Macros are no longer supported.
>
> Daniel
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Viki_kulkarni
> Sent: Thursday, January 20, 2011 9:01 AM
> To: arslist@ARSLIST.ORG
> Subject: Macro not honoring the data retrival settings
>
> hi all,
>
> I have a macro running on a form that searches for all records on the
> form
> which has more than 1000 records.
> now we have set the max number of records to retrieve = 1000 in the user
> tools option.
>
> what we see is that when we make a search call explicit on that form we
> get
> only 1000 records as per the settings but if we perform the same search
> via
> a simple search macro we get more than 1000 records in fact we get the
> actual number of records.
>
> can any one share any idea how to avoid this?? we are on ARS 5.0.1 and
> user
> tool is 701.
>
>
> Thanks,
> Viki
> --
> View this message in context:
> http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30
> 716698p30716698.html
> Sent from the ARS (Action Request System) mailing list archive at
> Nabble.com.
>
> 
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>
> *
> This message and any attachments (the "message") are confidential and
> intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered,
> changed or falsified.
> If you are not the intended addressee of this message, please cancel it
> immediately and inform the sender.
> 
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Macro not honoring the data retrieval settings

[Daniel Condrea]

Hello All

Way try to record a macro when there is 'Open window' action?

Macros are no longer supported.

Daniel

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Viki_kulkarni
Sent: Thursday, January 20, 2011 9:01 AM
To: arslist@ARSLIST.ORG
Subject: Macro not honoring the data retrival settings

hi all,

I have a macro running on a form that searches for all records on the
form
which has more than 1000 records.
now we have set the max number of records to retrieve = 1000 in the user
tools option.

what we see is that when we make a search call explicit on that form we
get
only 1000 records as per the settings but if we perform the same search
via
a simple search macro we get more than 1000 records in fact we get the
actual number of records.

can any one share any idea how to avoid this?? we are on ARS 5.0.1 and
user
tool is 701.


Thanks,
Viki
-- 
View this message in context:
http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30
716698p30716698.html
Sent from the ARS (Action Request System) mailing list archive at
Nabble.com.


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

*
This message and any attachments (the "message") are confidential and intended 
solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or 
falsified.
If you are not the intended addressee of this message, please cancel it 
immediately and inform the sender.


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Macro not honoring the data retrival settings

[Misi Mladoniczky]

Hi,

I recall that some settings could be changed during macro recording in the
past. Apparently not the max-records-returned setting...

I tried this on my 7.6.03 environment.

The Macro honored the setting for my user regardless of the setting during
the actual macro recording. This seems to be at odds with what you are
seeing.

I would not expect the version of the server to affect this.

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

Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
* 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 Misi,
>
> it still gives me more than 1000 records..
>
> Thanks,
> Vikrant
>
> Misi Mladoniczky wrote:
>>
>> Hi,
>>
>> Try recording a new macro where you actually go in and change this
>> setting
>> to 1000 during the recording.
>>
>> You may have to set it to something other than 1000 before you start the
>> recording...
>>
>> Best Regards - Misi, RRR AB, http://www.rrr.se
>>
>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
>> * 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 have a macro running on a form that searches for all records on the
>>> form
>>> which has more than 1000 records.
>>> now we have set the max number of records to retrieve = 1000 in the
>>> user
>>> tools option.
>>>
>>> what we see is that when we make a search call explicit on that form we
>>> get
>>> only 1000 records as per the settings but if we perform the same search
>>> via
>>> a simple search macro we get more than 1000 records in fact we get the
>>> actual number of records.
>>>
>>> can any one share any idea how to avoid this?? we are on ARS 5.0.1 and
>>> user
>>> tool is 701.
>>>
>>>
>>> Thanks,
>>> Viki
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30716698p30716698.html
>>> Sent from the ARS (Action Request System) mailing list archive at
>>> Nabble.com.
>>>
>>> ___
>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>>>
>>
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>>
>>
>
> --
> View this message in context:
> http://old.nabble.com/Macro-not-honoring-the-data-retrival-settings-tp30716698p30716858.html
> Sent from the ARS (Action Request System) mailing list archive at
> Nabble.com.
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"