Thanks for your info. I guess most people went through field relayering in
3.0 or 2.x -> 3.2.1. So that makes my scenario kind of academic.

But if anyone is interested... It seems to me that shared cache does make
updates easier on the users as Barry described. Only it seems that it
recaches for each field change. I think "unshared" cache, while it has more
caches to update, waits for the "build" or "compile" or whatever of the
whole form before it refreshes cache, so if you have 100 fields in 2 views
and 10 server processes, if my guess is correct, you're looking at
100(fields) * 2(views) * 2 (caches--shared cache and admin) = 400 refreshes
with shared cache, but only 1(form) * 10 (individual caches) = 10 refreshes
with unshared cache. So if you're only changing, say, filters, or you're
only changing one field on a form (and the save doesn't relayer all the
other fields), you're better off with shared cache; but, if you still have
lots of "un-relayered" forms, you're better off waiting to turn on shared
cache. This all assumes MPSO, and assumes you don't have the option of
going back and forth between shared and unshared at will.

Enlightenment hereby solicited--TIA,

Jim O'Hara

> ----------
> From: Cox, Barry BJ[SMTP:Cox.Barry.BJ@BHP.COM.AU]
> Reply To: Action Request System discussion list(ARSList)
> Sent: March 14, 2000 3:04 PM
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: ARS 3.2 Upgrade
>
> Jim,
>
> Interesting comments on shared cache. I had shared cache enabled on 3.2.1
> and that didn't change when I went to 4.0.3. We also have MPSO, in fact I
> don;t beliebe there would be any reason to enable shared cache without
> MPSO. We have 5 fast, 10 list and a private server daemon running on our
> prod system.
>
> The purpose of the shared cache is to enable one to change schemas etc
> more easily while the system is in use. Rather than all servers having
> their own copy of the data definitions, each will use a shared copied and
> if there is a new change they will pick it up from memory rather than
> having to recache from disk. So my understanding is shared cache is
> supposed to help the problem, not make it worse. The draw back is you
> need to expend some sharable memory.
>
> The relayering "problem" I saw in the upgrade from 2.1.3 to 3.2.1. It
> seems that any upgrade adds display features to the data dictionary but
> the old forms don't convert "properly". So the first save after the
> upgrade actually updates all the fields which can be a big hit. But as
> stated above, I would have thought that shared cache would help to
> alleviate this.
>
> regards, Barry
>
> ----------
> From: Jonathan Cantu[SMTP:Jonathan.Cantu@LEVEL3.COM]
> Reply To: Action Request System discussion list(ARSList)
> Sent: March 14, 2000 12:35 PM
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: ARS 3.2 Upgrade
>
> This is exactly right. Once you turn on shared caching and MPSO this
> situation worsens. What I have been told by Remedy (and this info is also
> in Admin Guide Vol.2 pg. 1-10 to 1-12) is that shared cache size should be
> whatever the command 'arserverd -c -r 390680' returns times total number
> of
> arserverd's in your environment times 1.25. The larger your shared cache
> is, however, the longer (more impactive) it takes to make changes via the
> admin tool. Also, they are recommending that the SHMIN value in the
> kernel
> configuration be set to 20. However, you also cannot make shared cache too
> small or you have unpredictable behavior in other areas. Somewhere
> amongst
> all of these parameters (plus database memory configurations).
>
> We are having a problem right now where we are having 'arserverd'
> processes
> die several times per day and restart by 'arservtcd'. If we look in our
> arerror.log file we see the following throughout:
>
> Fri Mar 10 08:57:48 2000 390623 : AR System server terminated when a
> signal/exception was received by the server (ARNOTE 20)
> Fri Mar 10 08:57:48 2000 11
> Fri Mar 10 08:57:58 2000 390623 : AR System server terminated -- fatal
> error encountered (ARNOTE 21)
> Fri Mar 10 08:57:58 2000 AR System server terminated unexpectedly --
> restarting (ARTCNOTE 802)
> Fri Mar 10 08:57:58 2000 Server -- 390623
>
> Appearently, Remedy is saying, we have the incorrect SHMIN value ('1') for
> the Shared-Cache-Segment-Size (71MB) we have established. So we are
> changing this to '20' tonight in order to have the least impact on users.
>
>
> -----Original Message-----
> From: O'Hara, Jim [mailto:JLO4@PGE.COM]
> Sent: Tuesday, March 14, 2000 12:04 PM
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: ARS 3.2 Upgrade
>
>
> Thomas,
>
> We went from 3.0.1 server to 4.0.3. We don't use shared cache (yet--see
> below), so admin changes hit the server harder. When I upgraded the admin
> tool, I noticed that the first time one opens a view, it modifies
> (relayers)
> every field to make the view compatible with various clients. Don't
> understand this completely, but my understanding is that if shared cache
> is
> on, a recache will happen for every field change, so, if you have a form
> with a lot of fields, you're looking at a lot of recaches. That's why I
> haven't turned shared cache on yet. Maybe I'm making some mental errors
> here--would welcome correction. I still have to be careful about form
> changes, because even without shared cache, it still takes a long time to
> update several fields. I don't know of any way to avoid this with the
> 4.0.3
> admin tool--even if you only want to make a minor change, all the fields
> in
> your view will be modified on the first save with the 4.0.3 admin tool.
>
> A related problem was the following. I have a dial-up machine at home,
> Windows 98. I was getting the same scenario I described above--it wanted
> to
> relayer all the fields, even if the form had been saved with a 4.0.3 admin
> tool already. My "fix" was to copy the fonts section of my ar.ini file on
> my work (Win95) machine to my home machine. Don't completely understand
> that one, either. I had opened a case with Remedy, and they never did
> resolve it. I just made a lucky guess and it worked. I wrote back to
> Remedy asking why it worked, no answer yet.
>
> Like Barry, I have a lot of users, and upgrading their clients is still in
> the future somewhere. It hasn't made it to the top of anyone's priority
> list yet. I'm feeling cautious here, since I've read about a lot of
> client
> issues here on arslist.
>
> One other issue I had--a push fields filter which was supposed to create a
> new record in a "child" form sometimes fired twice on one modification,
> when
> it should only fire once. I had to retire that filter and go back to
> running a macro from the filter. I opened a case with Remedy, but they
> haven't solved it.
>
> Remedy 4.0.3 server
> Sybase 11.9.2
> Solaris 2.5.1
>
> Jim.
>
> > ----------
> > From: Cox, Barry BJ[SMTP:Cox.Barry.BJ@BHP.COM.AU]
> > Reply To: Action Request System discussion list(ARSList)
> > Sent: March 13, 2000 6:44 PM
> > To: ARSLIST@LISTSERV.VISTAIT.COM
> > Subject: Re: ARS 3.2 Upgrade
> >
> > Thomas,
> >
> > We're a Solaris/Sybase site but we just recently (Sunday) upgraded from
> > 3.2.1 to 4.0.3 with next to zero impact.
> >
> > We're yet to roll out the client and there are a lot of issues there.
> If
> > you connect with a 3.2.1 client the only difference I've seen is that
> the
> > password field is filled with asterisks instead of just having the
> number
> > of asterisks equal to the length of the password.
> >
> > We have >1000 clients so the client roll out is going to be a much
> bigger
> > project but upgrading the server, not a problem! (so far... fingers
> > crossed :-)
> >
> > regards, Barry
> >
> > -----Original Message-----
> > From: Truax, Thomas [mailto:thomas.truax@LMCO.COM]
> > Sent: Tuesday, 14 March 2000 9:54
> > To: ARSLIST@LISTSERV.VISTAIT.COM
> > Subject: ARS 3.2 Upgrade
> >
> >
> > We are planning to upgrade from ARS 321 to 4.0n later on this year.
> > We are using AIX, Oracle 7.n on the server and Win 95 clients. We are
> > planning on upgrading the AIX and Oracle to the latest versions. The
> > clients will be Win 95 and Win 2000, and some UNIX.
> > Is there a "lessons learned" web page that we can go to for help ? Or
> are
> > there other converters that have gone through this that will share their
> > experiences, good and bad ?? Any help will be greatly appreciated.
> > Thank you all very much.
> >
> > ps. I've been on other "forums" that have been no where as useful as
> this
> > "forum". This tool is invaluable for this work. It's excellent.
> >
> > Thomas Truax
> > Lockheed Martin Federal Systems
> > Owego Help Desk & Remedy Dev.
> > thomas.truax@lmco.com
> > 607-751-3336
> >
> >
> > Unsubscribe to: Text is: unsubscribe
> arslist
> >
> > EOM
> >
> > NOTICE - This message contains information intended only for the use of
> > the addressee named above. It may also be confidential and/or
> privileged.
> > If you are not the intended recipient of this message you are hereby
> > notified that you must not disseminate, copy or take any action in
> > reliance on it. If you have received this message in error please
> notify
> > postmaster@bhp.com.au.
> >
> >
> > Unsubscribe to: Text is: unsubscribe
> arslist
> >
>
>
> Unsubscribe to: Text is: unsubscribe arslist
>
>
> Unsubscribe to: Text is: unsubscribe arslist
>


Unsubscribe to: Text is: unsubscribe arslist

Interesting info, thanks for the clarification. That's still a bit of a bummer though. Unfortunately I don't have the luxury of MPSO on our development server so I haven't been able to do much testing with Shared Cache and other MPSO issues. It's has coused us to get burnt from time to time but that is what budget cuts do, just ask NASA. :-)

Should we ask Remedy to change the way shared cache works so that it does wait for this "compile" phase to complete? It sounds like a simple thing that would only make things better.

regards, Barry

-----Original Message-----
From: O'Hara, Jim [mailto:JLO4@PGE.COM]
Sent: Thursday, 16 March 2000 3:59
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: ARS 3.2 Upgrade (shared cache)


Barry, Jonathan,

Thanks for your info. I guess most people went through field relayering in
3.0 or 2.x -> 3.2.1. So that makes my scenario kind of academic.

But if anyone is interested... It seems to me that shared cache does make
updates easier on the users as Barry described. Only it seems that it
recaches for each field change. I think "unshared" cache, while it has more
caches to update, waits for the "build" or "compile" or whatever of the
whole form before it refreshes cache, so if you have 100 fields in 2 views
and 10 server processes, if my guess is correct, you're looking at
100(fields) * 2(views) * 2 (caches--shared cache and admin) = 400 refreshes
with shared cache, but only 1(form) * 10 (individual caches) = 10 refreshes
with unshared cache. So if you're only changing, say, filters, or you're
only changing one field on a form (and the save doesn't relayer all the
other fields), you're better off with shared cache; but, if you still have
lots of "un-relayered" forms, you're better off waiting to turn on shared
cache. This all assumes MPSO, and assumes you don't have the option of
going back and forth between shared and unshared at will.

Enlightenment hereby solicited--TIA,

Jim O'Hara

> ----------
> From: Cox, Barry BJ[SMTP:Cox.Barry.BJ@BHP.COM.AU]
> Reply To: Action Request System discussion list(ARSList)
> Sent: March 14, 2000 3:04 PM
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: ARS 3.2 Upgrade
>
> Jim,
>
> Interesting comments on shared cache. I had shared cache enabled on 3.2.1
> and that didn't change when I went to 4.0.3. We also have MPSO, in fact I
> don;t beliebe there would be any reason to enable shared cache without
> MPSO. We have 5 fast, 10 list and a private server daemon running on our
> prod system.
>
> The purpose of the shared cache is to enable one to change schemas etc
> more easily while the system is in use. Rather than all servers having
> their own copy of the data definitions, each will use a shared copied and
> if there is a new change they will pick it up from memory rather than
> having to recache from disk. So my understanding is shared cache is
> supposed to help the problem, not make it worse. The draw back is you
> need to expend some sharable memory.
>
> The relayering "problem" I saw in the upgrade from 2.1.3 to 3.2.1. It
> seems that any upgrade adds display features to the data dictionary but
> the old forms don't convert "properly". So the first save after the
> upgrade actually updates all the fields which can be a big hit. But as
> stated above, I would have thought that shared cache would help to
> alleviate this.
>
> regards, Barry
>
> ----------
> From: Jonathan Cantu[SMTP:Jonathan.Cantu@LEVEL3.COM]
> Reply To: Action Request System discussion list(ARSList)
> Sent: March 14, 2000 12:35 PM
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: ARS 3.2 Upgrade
>
> This is exactly right. Once you turn on shared caching and MPSO this
> situation worsens. What I have been told by Remedy (and this info is also
> in Admin Guide Vol.2 pg. 1-10 to 1-12) is that shared cache size should be
> whatever the command 'arserverd -c -r 390680' returns times total number
> of
> arserverd's in your environment times 1.25. The larger your shared cache
> is, however, the longer (more impactive) it takes to make changes via the
> admin tool. Also, they are recommending that the SHMIN value in the
> kernel
> configuration be set to 20. However, you also cannot make shared cache too
> small or you have unpredictable behavior in other areas. Somewhere
> amongst
> all of these parameters (plus database memory configurations).
>
> We are having a problem right now where we are having 'arserverd'
> processes
> die several times per day and restart by 'arservtcd'. If we look in our
> arerror.log file we see the following throughout:
>
> Fri Mar 10 08:57:48 2000 390623 : AR System server terminated when a
> signal/exception was received by the server (ARNOTE 20)
> Fri Mar 10 08:57:48 2000 11
> Fri Mar 10 08:57:58 2000 390623 : AR System server terminated -- fatal
> error encountered (ARNOTE 21)
> Fri Mar 10 08:57:58 2000 AR System server terminated unexpectedly --
> restarting (ARTCNOTE 802)
> Fri Mar 10 08:57:58 2000 Server -- 390623
>
> Appearently, Remedy is saying, we have the incorrect SHMIN value ('1') for
> the Shared-Cache-Segment-Size (71MB) we have established. So we are
> changing this to '20' tonight in order to have the least impact on users.
>
>
> -----Original Message-----
> From: O'Hara, Jim [mailto:JLO4@PGE.COM]
> Sent: Tuesday, March 14, 2000 12:04 PM
> To: ARSLIST@LISTSERV.VISTAIT.COM
> Subject: Re: ARS 3.2 Upgrade
>
>
> Thomas,
>
> We went from 3.0.1 server to 4.0.3. We don't use shared cache (yet--see
> below), so admin changes hit the server harder. When I upgraded the admin
> tool, I noticed that the first time one opens a view, it modifies
> (relayers)
> every field to make the view compatible with various clients. Don't
> understand this completely, but my understanding is that if shared cache
> is
> on, a recache will happen for every field change, so, if you have a form
> with a lot of fields, you're looking at a lot of recaches. That's why I
> haven't turned shared cache on yet. Maybe I'm making some mental errors
> here--would welcome correction. I still have to be careful about form
> changes, because even without shared cache, it still takes a long time to
> update several fields. I don't know of any way to avoid this with the
> 4.0.3
> admin tool--even if you only want to make a minor change, all the fields
> in
> your view will be modified on the first save with the 4.0.3 admin tool.
>
> A related problem was the following. I have a dial-up machine at home,
> Windows 98. I was getting the same scenario I described above--it wanted
> to
> relayer all the fields, even if the form had been saved with a 4.0.3 admin
> tool already. My "fix" was to copy the fonts section of my ar.ini file on
> my work (Win95) machine to my home machine. Don't completely understand
> that one, either. I had opened a case with Remedy, and they never did
> resolve it. I just made a lucky guess and it worked. I wrote back to
> Remedy asking why it worked, no answer yet.
>
> Like Barry, I have a lot of users, and upgrading their clients is still in
> the future somewhere. It hasn't made it to the top of anyone's priority
> list yet. I'm feeling cautious here, since I've read about a lot of
> client
> issues here on arslist.
>
> One other issue I had--a push fields filter which was supposed to create a
> new record in a "child" form sometimes fired twice on one modification,
> when
> it should only fire once. I had to retire that filter and go back to
> running a macro from the filter. I opened a case with Remedy, but they
> haven't solved it.
>
> Remedy 4.0.3 server
> Sybase 11.9.2
> Solaris 2.5.1
>
> Jim.
>
> > ----------
> > From: Cox, Barry BJ[SMTP:Cox.Barry.BJ@BHP.COM.AU]
> > Reply To: Action Request System discussion list(ARSList)
> > Sent: March 13, 2000 6:44 PM
> > To: ARSLIST@LISTSERV.VISTAIT.COM
> > Subject: Re: ARS 3.2 Upgrade
> >
> > Thomas,
> >
> > We're a Solaris/Sybase site but we just recently (Sunday) upgraded from
> > 3.2.1 to 4.0.3 with next to zero impact.
> >
> > We're yet to roll out the client and there are a lot of issues there.
> If
> > you connect with a 3.2.1 client the only difference I've seen is that
> the
> > password field is filled with asterisks instead of just having the
> number
> > of asterisks equal to the length of the password.
> >
> > We have >1000 clients so the client roll out is going to be a much
> bigger
> > project but upgrading the server, not a problem! (so far... fingers
> > crossed :-)
> >
> > regards, Barry
> >
> > -----Original Message-----
> > From: Truax, Thomas [mailto:thomas.truax@LMCO.COM]
> > Sent: Tuesday, 14 March 2000 9:54
> > To: ARSLIST@LISTSERV.VISTAIT.COM
> > Subject: ARS 3.2 Upgrade
> >
> >
> > We are planning to upgrade from ARS 321 to 4.0n later on this year.
> > We are using AIX, Oracle 7.n on the server and Win 95 clients. We are
> > planning on upgrading the AIX and Oracle to the latest versions. The
> > clients will be Win 95 and Win 2000, and some UNIX.
> > Is there a "lessons learned" web page that we can go to for help ? Or
> are
> > there other converters that have gone through this that will share their
> > experiences, good and bad ?? Any help will be greatly appreciated.
> > Thank you all very much.
> >
> > ps. I've been on other "forums" that have been no where as useful as
> this
> > "forum". This tool is invaluable for this work. It's excellent.
> >
> > Thomas Truax
> > Lockheed Martin Federal Systems
> > Owego Help Desk & Remedy Dev.
> > thomas.truax@lmco.com
> > 607-751-3336
> >
> >
> > Unsubscribe to: Text is: unsubscribe
> arslist
> >
> > EOM
> >
> > NOTICE - This message contains information intended only for the use of
> > the addressee named above. It may also be confidential and/or
> privileged.
> > If you are not the intended recipient of this message you are hereby
> > notified that you must not disseminate, copy or take any action in
> > reliance on it. If you have received this message in error please
> notify
> > postmaster@bhp.com.au.
> >
> >
> > Unsubscribe to: Text is: unsubscribe
> arslist
> >
>
>
> Unsubscribe to: Text is: unsubscribe arslist
>
>
> Unsubscribe to: Text is: unsubscribe arslist
>


Unsubscribe to: Text is: unsubscribe arslist

EOM

NOTICE - This message contains information intended only for the use of the addressee named above. It may also be confidential and/or privileged. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify postmaster@bhp.com.au.


Unsubscribe to: Text is: unsubscribe arslist

>
> Interesting info, thanks for the clarification. That's still a
> bit of a bummer though. Unfortunately I don't have the luxury of
> MPSO on our development server so I haven't been able to do much
> testing with Shared Cache and other MPSO issues. It's has coused
> us to get burnt from time to time but that is what budget cuts
> do, just ask NASA. :-)
>
> Should we ask Remedy to change the way shared cache works so that
> it does wait for this "compile" phase to complete? It sounds
> like a simple thing that would only make things better.


The next version will have a new "version" of shared cache, without using
shared memory segment.

--
Jarl Grøneng
jgroneng@online.no

Now playing: Nothing, probably working.....

"Choose a job you love and you will never work a day in your life"
--Confucius


Unsubscribe to: Text is: unsubscribe arslist

I believe your analogy is slightly flawed. The cache is only updated when
you hit the save button. So if you change 100 fields in 2 views and hit the
save button you will update 1 cache with shared caching turned on. In the
other scenario, you would update 10 individual caches and the users would
not be able access the system will the caches update.

An additional note from the Performance Tuning Class, shared cache does NOT
increase performance for operations that rebuild the form database tables.
The server will not be available to any user while the table rebuild process
is executing. This is dependant on the database being used.

Here is the info on shared cache from the Admin Manual Vol 2.

Shared Cache
Without a shared cache, each server process on a machine loads a copy of the
AR System structures from the database. Whenever a structure is changed (for
example, by adding a field to a form), each server process reloads its
cache. Because a server is inaccessible to users while it accesses the
database, administrators of machines without shared cache should make
changes to AR System structures during nonwork hours.

With a shared cache, AR System servers can access database information in a
cache shared by all the server processes on a machine. When one server
process changes a structure, it changes the cache at the same time it
modifies the database. All other processes on that machine will then use the
new structures in the shared cache. This enables servers to retrieve
structure information without having to access the database directly,
improving system performance and enabling administrators to make changes
during work hours.

Shared cache is available for machines configured to run with shared memory
and semaphores.

Windows NT
Windows NT machines always use a shared cache and need no special
configuration. Use of the shared cache cannot be disabled on Windows

Dave

>Date: Wed, 15 Mar 2000 08:59:06 -0800
>From: "O'Hara, Jim"
>Subject: Re: ARS 3.2 Upgrade (shared cache)
>
>Barry, Jonathan,
>
>Thanks for your info. I guess most people went through field relayering in
>3.0 or 2.x -> 3.2.1. So that makes my scenario kind of academic.
>
>But if anyone is interested... It seems to me that shared cache does make
>updates easier on the users as Barry described. Only it seems that it
>recaches for each field change. I think "unshared" cache, while it has
more
>caches to update, waits for the "build" or "compile" or whatever of the
>whole form before it refreshes cache, so if you have 100 fields in 2 views
>and 10 server processes, if my guess is correct, you're looking at
>100(fields) * 2(views) * 2 (caches--shared cache and admin) = 400 refreshes
>with shared cache, but only 1(form) * 10 (individual caches) = 10 refreshes
>with unshared cache. So if you're only changing, say, filters, or you're
>only changing one field on a form (and the save doesn't relayer all the
>other fields), you're better off with shared cache; but, if you still have
>lots of "un-relayered" forms, you're better off waiting to turn on shared
>cache. This all assumes MPSO, and assumes you don't have the option of
>going back and forth between shared and unshared at will.
>
>Enlightenment hereby solicited--TIA,
>
>Jim O'Hara

Dave Shellman

Phone: (717)810-3687
Fax: (717)810-2124
email: dave.shellman@tycoelectronics.com

tyco ELECTRONICS GROUP
A tyco INTERNATIONAL LTD COMPANY
MS 194-026
PO Box 3608
Harrisburg, PA 17105-3607


Unsubscribe to: Text is: unsubscribe arslist