couldn't find the tables in the data base until you explained it a little
better. Unfortunately, I couldn't find these tables in Volume 2 of the
Admin Guide, The AR System and the ... Database, either. I suspect we've
messed these up in the past and didn't quite know how to recover from the
problem.

Ray Doue
rdoue@scitor.com
http://www.scitor.com/aerospace/aerospace.htm
408 745-8221
408 745-8296 (fax)

-----Original Message-----
From: Brett Sloan [mailto:bsloan@SOUTHWIND.NET]
Sent: Tuesday, September 28, 1999 7:45 PM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: HELP - Don't know why this is happening!-- Questions


Ray,

Our Remedy installation sets on top of Oracle and I also have worked
with one over MS SQL Server. In both of these DBs there is a table or
view (I don't remember which right now) called server_cache. Typically
in an installation like ours there should be one entry (record) in this
table/view that contains the fields server or server_name and serverid.
What the exact function of this table/view is I don't know. I do know
that on a couple of occasions we had strange problems centered around
users and groups not showing up or not having permissions they should
have, etc. On these occasions Remedy support (and another time a RAC)
had me check out the server_cache in the db and I found multiple entries
in the server_cache table/view for our server with different serverids
and different forms of the server name. For example, we use HP Service
Guard for failover to another server in the cluster if required thus our
Remedy server has a package name that does not reflect the machine name.

What had happened at the time is our server name was the same as the
machine name on the network until we got the high availability fail-over
setup at which time we changed the name to the package name. When we
started using the package name another entry got put in the server_cache
table/view reflecting that name with a different serverid. Also, as
client login information was reconfigured to reflect the new package
name, some were configured with the short name for the package and
others were configured with the fully qualified name for the package.
Consequently additional records ended up in the server_cache to reflect
the differences in the server name configured in the clients and thus
different serverids as the serverid is incremented by one each time a
new entry ends up in the server_cache.

Now the problems arise because the serverid from server_cache is also
embedded in the user_cache and group_cache. Consequently you can end up
with groups and users that are assigned to a different serverid and thus
a different server name. This seems to cause problems with workflow
where the server is identified in an active link or filter and the users
or groups trying to use that particular active link or filter are
assigned to a different serverid in the cache files.

For example:

Original Server Name: pwic068.st.company.com
Some clients configured with: pwic068.st.company.com
Other clients configured with: pwic068

New package name added: usa-app1c-ars.st.company.com
Some clients reconfigured with: usa-app1c-ars.st.company.com
Other clients reconfigured with: usa-app1c-ars

Subsequently the server_cache table/view looked like this:

Server_Name ServerID
pwico68.st.company.com 1
pwic068 2
usa-app1c-ars.st.company.com 3
usa-app1c-ars 4

Consequently we had a lot of strange things going on.

In these cases they (Remedy/RACS) had me delete all records except the
one with the proper server name and reset the serverid,

Server_Name ServerID
usa-app1c-ars.st.company.com 1

Then they had me do a SQL updates directly to the db to user_cache and
group_cache to insure that the serverid value in those views was equal
to 1 for all records. And finally (should be done first) insure that
all clients had the same server name removing any of the other
variations. Seems if you run a client with just the short qualifier
then it will poke another entry back into the server_cache file.
Arreload does not solve the problems associated with this situation.

Point is, it doesn't matter if you settle on the short or long names,
just be consistent throughout the clients. Ours got that way because we
were using short names in some clients and long names in the other
clients. Then the problem was compounded by the server name change to
the package name which ended up being used in both the short and long
fashions in different clients and finally to top it off we had
developers with different name configurations in their clients and admin
tools building workflow throughout this time. So, since the workflow
like active links and filters that use actions that require a server
designation and the serverid is stored in the workflow, we had workflow
looking at different renditions of the server names. Causes strange
behavior.

Hope this helps.

Brett Sloan
------------

Doue, Ray wrote:
>
> Hi Brett,
>
> I've been chewing on this response for awhile and had the following
> questions:
>
> 1. When you say "server cache file", do you mean ar.cfg or ar.conf? I
> didn't see an entry in the SQL portion of the data base.
> 2. When you refer to "deleting records you don't want", do you mean going
> into the SQL data base directly or removing entries in the memory cache
> using arreload or arcache utilities or what? Any references to ARS docs?
> 2. What circumstances caused this problem for you?
>
> Thanks for any further info you can provide,
>
> Thanks,
>
> Ray Doue
> rdoue@scitor.com
> http://www.scitor.com/aerospace/aerospace.htm
> 408 745-8221
>
> -----Original Message-----
> From: Brett Sloan [mailto:bsloan@SOUTHWIND.NET]
> Sent: Wednesday, August 25, 1999 9:50 PM
> To: ARSLIST@LISTSERV.ACSU.BUFFALO.EDU
> Subject: Re: HELP - Don't know why this is happening!
>
> Sean,
>
> If 4.0 is similar to 3.21 you will probably find a server cache file in
> your database and both the unqualified and fully qualified names will be
> in there under different server ID numbers. This can become a problem
> as your user and group caches will have the server id number in each
> record of caches and things can get confused if some users and groups
> are operating under one server id while others are operating under the
> other server ID.
>
> You will need to delete the record you don't want, set the id number to
> 1 and set the server id number to 1 for all user and group cache
> records. Some of your workflow may be affected too. Export it server
> independent, do the clean up and re-import it.
>
> Also, as another caution, I wouldn't necessarily want to have both my
> production and development servers listed in my ar file as their are
> instances where you might want to use a utility to do something on your
> development server and it might perform the same thing on your
> production server even though you don't want it to. We keep production
> and development servers separate with only their own server name in the
> ar file. That goes for the server cache file too.
>
> Brett Sloan
> -----------
>
> Sean Christensen wrote:
> >
> > I've had the most peculiar behaviour begin to occur in my Remedy system.
> > I'm running 4.0.2 on an HPUX 11 server. My client is 4.0.2. I've
opened
> my
> > Remedy Administrator tool to look at an active link. In my set fields
> > action, I have 4 options to pick:
> > CURRENT TRANSACTION
> > remedy (my production server)
> > remedydevel (my development server)
> > remedy.franklins.com.au (my production server with the
> full
> > qualified name)
> >
> > Now you may be asking yourself, why do I have my production server in
> there
> > twice. I'd like to know the reason why as well. I've checked the ar
and
> > ar.conf files on both my production, development and client machines and
I
> > only have the first 2 servers listed. I exported all my server
> definitions
> > and looked through them in Wordpad and discovered that the fully
qualified
> > server name is showing up, I never set anything up this way prior to
> today.
> >
> > Has anyone seen this behaviour before in Remedy??? This is a most
> > interesting feature that I've not seen before, Remedy dynamically
changing
> > server names on me in my workflow definitions.
> >
> > Sean Christensen
> > Technical Specialist & Remedy Team Leader
> > Customer Service Support - IT, Franklins Limited
> > * desk - (02) 9722.1640
> > * mobile - 0412.029.054
> > * e-mail - christensens@franklins.com.au
> > "Let your Yes be Yes and No be No in all you do"
> >
> >
>
---------------------------------------------------------------------------
> > To unsubscribe from this list, send mail to
listserv@listserv.buffalo.edu
> > with a body of "signoff arslist". The subject line is ignored.
>
>
---------------------------------------------------------------------------
> To unsubscribe from this list, send mail to listserv@listserv.buffalo.edu
> with a body of "signoff arslist". The subject line is ignored.
>
> To Unsubscribe send e-mail to:
> body of text is: unsubscribe arslist

To Unsubscribe send e-mail to:
body of text is: unsubscribe arslist

To Unsubscribe send e-mail to:
body of text is: unsubscribe arslist