All,
Finally got BMC Support staff to talk to their engineers (after fighting with 
them for almost 2 weeks)
Sure enough it was a known bug, and they've created a defect against it.
Should be fixed in Patch 6.

Issue: ISS03343227
Defect: SW00304242

Thanks,
Matthew Perrault

From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Joe DeSouza
Sent: Tuesday, October 07, 2008 3:59 PM
To: arslist@ARSLIST.ORG
Subject: Re: Another Issue with 7.1 Mid-Tier Patch 3/4

**
I got a 9351 error last evening which went away with recaching.
Unable to setup data connection, which is preventing the application from 
working correctly. (ARERR 9351)

I suspected something wrong with the cache because I didn't get this error on 
every form or tab within a page but only on some forms or some tabs within a 
form..

Joe

----- Original Message ----
From: strauss <[EMAIL PROTECTED]>
To: arslist@ARSLIST.ORG
Sent: Tuesday, October 7, 2008 4:08:56 PM
Subject: Re: Another Issue with 7.1 Mid-Tier Patch 3/4

**
More specific than that... and we are on Tomcat 5.5.26 which is a contributing 
factor to the 9350 error:

Issue:


Issue Summary:

receiving 9350 error when trying to save a task via the midtier



...and

A form definition has been changed, so unable to retrieve data. Please contact 
administrator (ARERR 9352)


(does not occur in User Tool)

Response (eventually):


"This is due a defect:

"SW00285864

BMC Remedy Mid Tier sporadically returned an error: A form definition has been 
changed, so unable to retrieve data, even though the form definition had not 
changed."



fixed in patch 5.

Please update your Mid-Tier to Patch 5 and retry."

Christopher Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing & IT Center
http://itsm.unt.edu/
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Joe DeSouza
Sent: Tuesday, October 07, 2008 2:57 PM
To: arslist@ARSLIST.ORG
Subject: Re: Another Issue with 7.1 Mid-Tier Patch 3/4

**
What kind of errors are you having in form definition change?

The reason I am asking is that we are running MT 7.1 Patch 3 here, and we do 
have problems sometimes when a new column is added to a table field (null 
pointer assignment). I cannot say for certain if this happens on additions of 
other fields too as I am yet to determine all the reasons why I get that error. 
This error goes away after manually flushing the cache.

Also I have reasons to believe that if you have persistent cache turned on, and 
if in case you do restart the web server daemon, the object invalidation 
counter probably gets reset? I noticed on one of our forms, the changes to the 
definition weren't yet caught by the mid tier way after the invalidation 
interval, and the only reason I can think of is that this counter gets reset 
everytime the web server daemon is restarted.

Is your problem something similar?

Joe

----- Original Message ----
From: strauss <[EMAIL PROTECTED]>
To: arslist@ARSLIST.ORG
Sent: Tuesday, October 7, 2008 3:33:57 PM
Subject: Re: Another Issue with 7.1 Mid-Tier Patch 3/4

**
Do you know if it has been fixed in the soon-to-be-released patch 005???  I'm 
waiting on that to solve a problem with form definition change errors.

Christopher Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing & IT Center
http://itsm.unt.edu/
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Matthew Perrault
Sent: Tuesday, October 07, 2008 12:01 PM
To: arslist@ARSLIST.ORG
Subject: Another Issue with 7.1 Mid-Tier Patch 3/4

**
All,
Got another issue with the 7.1 Mid-Tier Patch 3 and Patch 4.
Have Created an Issue with BMC: ISS03343227
Will let you know when I have a defect ID and what that Defect ID is.

MS Server 2003
IIS 6 (I think)
Apache/Tomcat
Mid-Tier 7.1 Patch 3 (and tested with Patch 4).

It appears there is a problem with how ViewFormServlet handles the User Time 
Zone and passed in Field Parameters.

Here's the situation:
We send emails from our system. In those Emails we include a URL.
This URL includes parameters for the Incident #, Server, Mid-Tier, View, 
UserName, Password and some other field values.
Well, the first time that a person clicks on the link, it appears that 
ViewFormServlet is wiping out all the passed field parameters with this:
usertimezone=America%2FChicago.
Well, the second time the user clicks on the link it all works fine and brings 
up the incident without issue.
So, Hazarding a guess, it looks like the first time, it tries to find the 
User's TimeZone in the cache based on the URL that was supplied,
Doesn't find it and slaps that over the top of the other parameters, then 
Caches the Timezone.
Next Time the person clicks on the link, it pulls the timezone out of the cache 
and works correctly.

For example:
You give the URL:
http://MID_TIER_SERVER/arsys/servlet/ViewFormServlet?form=FORM_X&view=VIEW_X&server=AR_SERVER&username=Bozo&pwd=TheClown&F1000000868=00001&F2020000916=XXXX&F1990001=IncidentEmail&?mode=Query<http://mid_tier_server/arsys/servlet/ViewFormServlet?form=FORM_X&view=VIEW_X&server=AR_SERVER&username=Bozo&pwd=TheClown&F1000000868=00001&F2020000916=XXXX&F1990001=IncidentEmail&?mode=Query>

It will translate into the following URL:
http://MID_TIER_SERVER/arsys/forms/AR_SERVER/FORM_X/VIEW_X/?usertimezone=America%2FChicago&cacheid=25255df7<http://mid_tier_server/arsys/forms/AR_SERVER/FORM_X/VIEW_X/?usertimezone=America%2FChicago&cacheid=25255df7>

Then if you click on the link a second time it works.
Also,
If you pass the usertimezone parameter in on the first URL it will also work 
fine.
The problem with that is now you are hardcoding a specific timezone into the 
URL.
That won't work for us as we could have a person in the US, sending this link 
to some one in India and it needs to pick up that person's local timezone.

Bottom Line ViewFormServlet is not picking up the TimeZone from the user's PC 
and handling it correctly.

Thanks,
Matthew Perrault

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

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

Reply via email to