Zero Value Inventory

[system]

If there is a chance that the part will be needed again, I agree with
Charlie, pull the remainder of the job, improve it's PL, and put it in
inventory at it's original cost for future use. On the other hand, if there
is no foreseen use of the remaining parts, don't purchase it for stock.
Don't enter the part number in the part master. Purchase it to the job
where most or all will be consumed and perhaps unneeded or unusable
leftovers discarded. In either method, the cost is in the proper places.

Stan



_____

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Charlie Smith
Sent: Wednesday, March 05, 2008 11:14 AM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] Zero Value Inventory

Why does it have a value at all? If you have already consumed the cost
of the materials in a job, the cost of the materials would be $0.00. On
the other hand if you didn't use it and took it back out of the job, you
have a better P&L on the job and the parts are in inventory with their
original cost.

With Vista/Vantage if you do a return materials, it will place it back
into inventory at its original cost. Otherwise, you have to do an
inventory cost adjustment to place a value on that part and then do an
inventory adjustment to get that part back into stock at the new value
of the parts. With that you will have indicated that the materials were
consumed in the job and the job absorbed that cost and that by a
miracle, you now have the same amount of parts in stock and at a
particular cost.

Charlie Smith

Smith Business Services / 2W Technologies LLC

www.vistaconsultant.com <http://www.vistacon
<http://www.vistaconsultant.com/> sultant.com/> /
www.2WTech.com

From: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com
[mailto:vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com] On
Behalf
Of Dale R. Kalsow
Sent: Wednesday, March 05, 2008 9:55 AM
To: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com
Subject: [Vantage] Zero Value Inventory

We are currently migrating to Epicor and was wondering if any of you do
something similar to this:

In our existing system we have what we call penny inventory. We may
purchase a part specifically for a manufacturing job. This part we do
not currently stock. In the end, if we don't use that part, it is still
costed to that job but we put it back into our inventory at a penny. Is
anyone doing something similar with epicor and if so how are you handing
it?

Thanks!

Dale Kalsow | Information Technologies Director
__________________________________________________________
Determan Brownie, Inc. | 1241 72nd Avenue NE | Minneapolis, MN 55432

* Phone: (763) 502-9689 | * Fax: (763) 571-1789

* dale.r.kalsow@ <mailto:dale.r.kalsow%40determan.com> determan.com
<mailto:dale.r.kalsow%40determan.com> | *
http://determan. <http://determan.com/> com/

"Ambition is the path to success. Persistence is the vehicle you arrive
in."

Electronic Privacy Notice. This e-mail, and any attachments, contains
information that is, or may be, covered by the Electronic Communications
Privacy Act, 18 U.S.C. 2510-2521, and is also confidential and
proprietary in nature. If you are not the intended recipient, please be
advised that you are legally prohibited from retaining, using, copying,
distributing, or otherwise disclosing this information in any manner.
Instead, please reply to the sender that you have received this
communication in error, and then immediately delete it. Thank you in
advance for your cooperation.

________________________________

From: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com
<mailto:vantage%40yahoogroups.com>
[mailto:vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com
<mailto:vantage%40yahoogroups.com> ] On
Behalf
Of Joe Luster
Sent: Wednesday, March 05, 2008 7:46 AM
To: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com
<mailto:vantage%40yahoogroups.com>
Subject: RE: [Vantage] Re: Vantage System Stability with SQL ?

Check out Answerbook #8782MPS about setting the schema holder to read
only. Have you done this? We did last week and I think Vantage is a lot
more stable on SQL now.

Joe Luster

Network Administrator

Cold Jet, LLC

513-831-3211 ext. 308

513-831-1209 FAX

From: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com
<mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com>
[mailto:vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com
<mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com> ] On
Behalf
Of tnewellar
Sent: Tuesday, March 04, 2008 5:28 PM
To: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com
<mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com>
Subject: [Vantage] Re: Vantage System Stability with SQL ?

Hello Gary, Are you still having this issue?

We were having a similar problem on Win64 with SQL 2005 64 bit. Our
app servers would just stop serving client requests. We would be
lucky to get 24 hours of system stability.

I applied the latest open edge patch 3. We are currently on
8.03.403C. This has helped the progress app servers stay stable for us.

The real down side for us is we purchased this system for 100
concurrent users and this (among other issues) technical glitch
completely halted our implementation. We have service and support,
pre-paid, and they did not even help us for 4 months. I feel lucky we
are not yet in production and completely regret purchasing vantage.

Tony

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]



[Non-text portions of this message have been removed]

[system]

Hello, all,

I have to ask if anyone else might be having problems with Vantage
v8.03.305x, when using the MSSQL-2000 database ? We went live in late
April, & have not been able to keep our system from crashing for
longer than 8 days or so ! The number of Progress AppServers tends to
climb way beyond the configured maximum (30, right now), right before
the system craters, we frequently see 'orphan' appservers showing up
in Progress Explorer (but, no longer appearing in Windows Task
Manager), & despite some extreme efforts by both Epicor and Progress
support, we've spent the last 4+ months (!!) fighting this beast.

When the system does crash, it tends to completely run the system out
of available virtual memory /hard disk space (with system-managed
virtual memory). Pretty messy !!

We are being advised to upgrade to Service pack .40x, but that also
requires SQL-2005, which we don't yet have in place.

Anyone else out there suffering as much as we appear to be ??

Thanks in advance for any consolation & help you can offer.

Best Regards,
- Gary -

[system]

Gary,



We are seeing a similar problem, but we are on progress data base and do not
have anything in sql. I have been working with vantage and progress to try
to find the problem and as of today they still have not found the solution
to fixing the problem.



Steve



-----Original Message-----
From: Gary Franks [mailto:garyfr2003@...]
Sent: October 02, 2007 11:48 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Vantage System Stability with SQL ?



Hello, all,

I have to ask if anyone else might be having problems with Vantage
v8.03.305x, when using the MSSQL-2000 database ? We went live in late
April, & have not been able to keep our system from crashing for
longer than 8 days or so ! The number of Progress AppServers tends to
climb way beyond the configured maximum (30, right now), right before
the system craters, we frequently see 'orphan' appservers showing up
in Progress Explorer (but, no longer appearing in Windows Task
Manager), & despite some extreme efforts by both Epicor and Progress
support, we've spent the last 4+ months (!!) fighting this beast.

When the system does crash, it tends to completely run the system out
of available virtual memory /hard disk space (with system-managed
virtual memory). Pretty messy !!

We are being advised to upgrade to Service pack .40x, but that also
requires SQL-2005, which we don't yet have in place.

Anyone else out there suffering as much as we appear to be ??

Thanks in advance for any consolation & help you can offer.

Best Regards,
- Gary -





[Non-text portions of this message have been removed]

[system]

Steve, what operating system are you on, Windows, Linux or Unix?



________________________________

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of vantage
Sent: Tuesday, October 02, 2007 2:05 PM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] Vantage System Stability with SQL ?



Gary,

We are seeing a similar problem, but we are on progress data base and do
not
have anything in sql. I have been working with vantage and progress to
try
to find the problem and as of today they still have not found the
solution
to fixing the problem.

Steve

-----Original Message-----
From: Gary Franks [mailto:garyfr2003@...
<mailto:garyfr2003%40yahoo.com> ]
Sent: October 02, 2007 11:48 AM
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Subject: [Vantage] Vantage System Stability with SQL ?

Hello, all,

I have to ask if anyone else might be having problems with Vantage
v8.03.305x, when using the MSSQL-2000 database ? We went live in late
April, & have not been able to keep our system from crashing for
longer than 8 days or so ! The number of Progress AppServers tends to
climb way beyond the configured maximum (30, right now), right before
the system craters, we frequently see 'orphan' appservers showing up
in Progress Explorer (but, no longer appearing in Windows Task
Manager), & despite some extreme efforts by both Epicor and Progress
support, we've spent the last 4+ months (!!) fighting this beast.

When the system does crash, it tends to completely run the system out
of available virtual memory /hard disk space (with system-managed
virtual memory). Pretty messy !!

We are being advised to upgrade to Service pack .40x, but that also
requires SQL-2005, which we don't yet have in place.

Anyone else out there suffering as much as we appear to be ??

Thanks in advance for any consolation & help you can offer.

Best Regards,
- Gary -

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]

[system]

Hi Gary,

I presume the system crash's in the same manor each
time?

How many Licenses do you have for vantage and when it
crashes if you look at maintain sessions - how many sessions are
displayed

Also when patch level are you running

Did you see any of this behavior in your test / piloting
environment?

Prior to a failure what are the resources like on the
server.

Do you have all other appservers instances (test train
pilot environments turned off?)

You mentioned that the configured maximum gets exceeded
(what are your settings for initial start - minimum and maximum for the
agents?)

Please post your mfgsys.pf file - to detail the startup
parameters you have configured.

Also provide an overview of the hardware the server is
utilizing (disk, CPU RAM)

Does the server have any other roles other than vantage?



Regards,

Stephen



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Gary Franks
Sent: 02 October 2007 17:48
To: vantage@yahoogroups.com
Subject: [Vantage] Vantage System Stability with SQL ?



Hello, all,

I have to ask if anyone else might be having problems with Vantage
v8.03.305x, when using the MSSQL-2000 database ? We went live in late
April, & have not been able to keep our system from crashing for
longer than 8 days or so ! The number of Progress AppServers tends to
climb way beyond the configured maximum (30, right now), right before
the system craters, we frequently see 'orphan' appservers showing up
in Progress Explorer (but, no longer appearing in Windows Task
Manager), & despite some extreme efforts by both Epicor and Progress
support, we've spent the last 4+ months (!!) fighting this beast.

When the system does crash, it tends to completely run the system out
of available virtual memory /hard disk space (with system-managed
virtual memory). Pretty messy !!

We are being advised to upgrade to Service pack .40x, but that also
requires SQL-2005, which we don't yet have in place.

Anyone else out there suffering as much as we appear to be ??

Thanks in advance for any consolation & help you can offer.

Best Regards,
- Gary -



[Non-text portions of this message have been removed]

[system]

Windows (server2003)



-----Original Message-----
From: Mike Anstey [mailto:manstey@...]
Sent: October 02, 2007 1:43 PM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] Vantage System Stability with SQL ?



Steve, what operating system are you on, Windows, Linux or Unix?

________________________________

From: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com
[mailto:vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com] On
Behalf
Of vantage
Sent: Tuesday, October 02, 2007 2:05 PM
To: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com
Subject: RE: [Vantage] Vantage System Stability with SQL ?

Gary,

We are seeing a similar problem, but we are on progress data base and do
not
have anything in sql. I have been working with vantage and progress to
try
to find the problem and as of today they still have not found the
solution
to fixing the problem.

Steve

-----Original Message-----
From: Gary Franks [mailto:garyfr2003@yahoo. <mailto:garyfr2003%40yahoo.com>
com
<mailto:garyfr2003%40yahoo.com> ]
Sent: October 02, 2007 11:48 AM
To: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com
<mailto:vantage%40yahoogroups.com>
Subject: [Vantage] Vantage System Stability with SQL ?

Hello, all,

I have to ask if anyone else might be having problems with Vantage
v8.03.305x, when using the MSSQL-2000 database ? We went live in late
April, & have not been able to keep our system from crashing for
longer than 8 days or so ! The number of Progress AppServers tends to
climb way beyond the configured maximum (30, right now), right before
the system craters, we frequently see 'orphan' appservers showing up
in Progress Explorer (but, no longer appearing in Windows Task
Manager), & despite some extreme efforts by both Epicor and Progress
support, we've spent the last 4+ months (!!) fighting this beast.

When the system does crash, it tends to completely run the system out
of available virtual memory /hard disk space (with system-managed
virtual memory). Pretty messy !!

We are being advised to upgrade to Service pack .40x, but that also
requires SQL-2005, which we don't yet have in place.

Anyone else out there suffering as much as we appear to be ??

Thanks in advance for any consolation & help you can offer.

Best Regards,
- Gary -

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]

[system]

Hi, Stephen.....I'll try to answer your questions in the order you
posed them :

1.) Yes, the crashes happen just about the same way each time. 'Early
Warning' is given by looking at the status of the main
appserver....after MRP runs overnight. If I see anything above the
initial value (currently 25), or approaching the configured max value
(currently 30), it's almost certain that we'll see a crash in the next
24 hours or less (usually less).
2.) I think we have 46 'Office' Licenses for Vantage, and 38 MES
licenses. When a crash happens, we are close to the maximum on sessions.
3.) We are at 8.03.305F...considering upgrading to either .305H or .403B
4.) Our DEV server is a separate box...no problems ever seen there
because it's a lightly-used system.
5.) Right before a crash, the resources will suddenly drop down on the
server....very quickly in most cases.
6.) All other databases and appservers have been disabled for months,
since we've been having this stability issue.
7.) 25 initial appservers, 30 max....I've seen that value climb as
high as 149 (!!!) before the quad-dual-core processor, running Windows
Server R2, latest service pack, 8GB ram, runs totally out of
system-managed virtual memory & simply stops responding.

8.) MFGSYS.PF File : (heavily modified by Epicor
Developers...especially the "-s 8000" parameter value !
======================================
-Mm 1024 -mmax 65534 -Bt 2048 -s 8000 -yy 1970 -stsh 31 -inp 32000
-tok 4000 -TB 31 -TM 32 -D 500 -l 1000
-tmpbsize 8
-lkwtmo 180
-T C:\epicor\AppserverTempFiles
-db f:\epicor\mfgsys803\db\mfgsyssh
-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
-q


#### 07/05/2007 - Raj - Added -tmpbsize 8, changed -T to point to C:\
drive
#### Original settings before Raj changed it on 5/3/07
#-Mm 1024 -mmax 4000 -Bt 200 -s 200 -yy 1970 -stsh 31 -inp 32000 -tok
4000 -lkwtmo 300
#-T f:\epicor\mfgwrk803
#-db f:\epicor\mfgsys803\db\mfgsyssh
#-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
# -q requires restart of appserver when you copy any new dotR code
this includes patch.

#### 08/16/2007 - Gary ... Changed -s parameter, above, to 8000 per
S.Johanns
#### Here is what is was before it was changed :
#-Mm 1024 -mmax 65534 -Bt 2048 -s 4000 -yy 1970 -stsh 31 -inp 32000
-tok 4000 -TB 31 -TM 32 -D 500 -l 1000
#-tmpbsize 8
#-lkwtmo 180
#-T C:\epicor\AppserverTempFiles
#-db f:\epicor\mfgsys803\db\mfgsyssh
#-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
#-q
=============================================
9.) This server ONLY runs Vantage....nothing else, not even
anti-virus. It has MS-SQL-2000 for the db, however.

Thanks again for your interest.......Gary

- In vantage@yahoogroups.com, "Stephen Edginton" <stephene@...> wrote:

>
> Hi Gary,
>
> I presume the system crash's in the same manor each
> time?
>
> How many Licenses do you have for vantage and when it
> crashes if you look at maintain sessions - how many sessions are
> displayed
>
> Also when patch level are you running
>
> Did you see any of this behavior in your test / piloting
> environment?
>
> Prior to a failure what are the resources like on the
> server.
>
> Do you have all other appservers instances (test train
> pilot environments turned off?)
>
> You mentioned that the configured maximum gets exceeded
> (what are your settings for initial start - minimum and maximum for the
> agents?)
>
> Please post your mfgsys.pf file - to detail the startup
> parameters you have configured.
>
> Also provide an overview of the hardware the server is
> utilizing (disk, CPU RAM)
>
> Does the server have any other roles other than vantage?
>
>
>
> Regards,
>
> Stephen
>
>
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
> Of Gary Franks
> Sent: 02 October 2007 17:48
> To: vantage@yahoogroups.com
> Subject: [Vantage] Vantage System Stability with SQL ?
>
>
>
> Hello, all,
>
> I have to ask if anyone else might be having problems with Vantage
> v8.03.305x, when using the MSSQL-2000 database ? We went live in late
> April, & have not been able to keep our system from crashing for
> longer than 8 days or so ! The number of Progress AppServers tends to
> climb way beyond the configured maximum (30, right now), right before
> the system craters, we frequently see 'orphan' appservers showing up
> in Progress Explorer (but, no longer appearing in Windows Task
> Manager), & despite some extreme efforts by both Epicor and Progress
> support, we've spent the last 4+ months (!!) fighting this beast.
>
> When the system does crash, it tends to completely run the system out
> of available virtual memory /hard disk space (with system-managed
> virtual memory). Pretty messy !!
>
> We are being advised to upgrade to Service pack .40x, but that also
> requires SQL-2005, which we don't yet have in place.
>
> Anyone else out there suffering as much as we appear to be ??
>
> Thanks in advance for any consolation & help you can offer.
>
> Best Regards,
> - Gary -
>
>
>
> [Non-text portions of this message have been removed]
>

[system]

> 1.) Yes, the crashes happen just about the same way each time. 'Early
> Warning' is given by looking at the status of the main
> appserver....after MRP runs overnight. If I see anything above the
> initial value (currently 25), or approaching the configured max value
> (currently 30), it's almost certain that we'll see a crash in the next
> 24 hours or less (usually less).

Do you use ODBC access to your Vantage database? We found that one user who
was access PartTran via ODBC was not set to "READ UNCOMMIT" and it was
crashing our AppServers.

Mark W.

[system]

Actually, we have a LOT of ODBC in use....much of that is embedded in
our customized Crystal Reports (which our Epicor consultant wrote for
us). I've been here on Sundays and late at night (trying to keep this
thing running !), & have seen the appservers simply crash when only
one person was on the system, accessing Vantage to enter Sales Orders.
We also have Service Connect, which now has its own box, its own
appservers & for a long time, Epicor was promoting that it was Service
Connect that was the culprit. Well, I think we've ruled that pretty
much out now that we even have those webservices being run on a
totally separate box.

We just received some 'debug' objects from Progress, which I'm
installing here tonight, in the hope that some 'enhanced logging' of
the ubroker will help to isolate the root cause(s). Sure hope so.

Thanks VERY much for your input.......Gary

--- In vantage@yahoogroups.com, "Mark Wonsil" <mark_wonsil@...> wrote:
>
> > 1.) Yes, the crashes happen just about the same way each time. 'Early
> > Warning' is given by looking at the status of the main
> > appserver....after MRP runs overnight. If I see anything above the
> > initial value (currently 25), or approaching the configured max value
> > (currently 30), it's almost certain that we'll see a crash in the next
> > 24 hours or less (usually less).
>
> Do you use ODBC access to your Vantage database? We found that one
user who
> was access PartTran via ODBC was not set to "READ UNCOMMIT" and it was
> crashing our AppServers.
>
> Mark W.
>

[system]

In



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Gary Franks
Sent: 03 October 2007 17:55
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Vantage System Stability with SQL ?



Hi, Stephen.....I'll try to answer your questions in the order you
posed them :

1.) Yes, the crashes happen just about the same way each time. 'Early
Warning' is given by looking at the status of the main
appserver....after MRP runs overnight. If I see anything above the
initial value (currently 25), or approaching the configured max value
(currently 30), it's almost certain that we'll see a crash in the next
24 hours or less (usually less).
2.) I think we have 46 'Office' Licenses for Vantage, and 38 MES
licenses. When a crash happens, we are close to the maximum on sessions.
3.) We are at 8.03.305F...considering upgrading to either .305H or .403B
4.) Our DEV server is a separate box...no problems ever seen there
because it's a lightly-used system.
5.) Right before a crash, the resources will suddenly drop down on the
server....very quickly in most cases.
6.) All other databases and appservers have been disabled for months,
since we've been having this stability issue.
7.) 25 initial appservers, 30 max....I've seen that value climb as
high as 149 (!!!) before the quad-dual-core processor, running Windows
Server R2, latest service pack, 8GB ram, runs totally out of
system-managed virtual memory & simply stops responding.

8.) MFGSYS.PF File : (heavily modified by Epicor
Developers...especially the "-s 8000" parameter value !
======================================
-Mm 1024 -mmax 65534 -Bt 2048 -s 8000 -yy 1970 -stsh 31 -inp 32000
-tok 4000 -TB 31 -TM 32 -D 500 -l 1000
-tmpbsize 8
-lkwtmo 180
-T C:\epicor\AppserverTempFiles
-db f:\epicor\mfgsys803\db\mfgsyssh
-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
-q

#### 07/05/2007 - Raj - Added -tmpbsize 8, changed -T to point to C:\
drive
#### Original settings before Raj changed it on 5/3/07
#-Mm 1024 -mmax 4000 -Bt 200 -s 200 -yy 1970 -stsh 31 -inp 32000 -tok
4000 -lkwtmo 300
#-T f:\epicor\mfgwrk803
#-db f:\epicor\mfgsys803\db\mfgsyssh
#-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
# -q requires restart of appserver when you copy any new dotR code
this includes patch.

#### 08/16/2007 - Gary ... Changed -s parameter, above, to 8000 per
S.Johanns
#### Here is what is was before it was changed :
#-Mm 1024 -mmax 65534 -Bt 2048 -s 4000 -yy 1970 -stsh 31 -inp 32000
-tok 4000 -TB 31 -TM 32 -D 500 -l 1000
#-tmpbsize 8
#-lkwtmo 180
#-T C:\epicor\AppserverTempFiles
#-db f:\epicor\mfgsys803\db\mfgsyssh
#-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
#-q
=============================================
9.) This server ONLY runs Vantage....nothing else, not even
anti-virus. It has MS-SQL-2000 for the db, however.

Thanks again for your interest.......Gary

- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"Stephen Edginton" <stephene@...> wrote:

>
> Hi Gary,
>
> I presume the system crash's in the same manor each
> time?
>
> How many Licenses do you have for vantage and when it
> crashes if you look at maintain sessions - how many sessions are
> displayed
>
> Also when patch level are you running
>
> Did you see any of this behavior in your test / piloting
> environment?
>
> Prior to a failure what are the resources like on the
> server.
>
> Do you have all other appservers instances (test train
> pilot environments turned off?)
>
> You mentioned that the configured maximum gets exceeded
> (what are your settings for initial start - minimum and maximum for

the

> agents?)
>
> Please post your mfgsys.pf file - to detail the startup
> parameters you have configured.
>
> Also provide an overview of the hardware the server is
> utilizing (disk, CPU RAM)
>
> Does the server have any other roles other than vantage?
>
>
>
> Regards,
>
> Stephen
>
>
>
> From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
Behalf

> Of Gary Franks
> Sent: 02 October 2007 17:48
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Subject: [Vantage] Vantage System Stability with SQL ?
>
>
>
> Hello, all,
>
> I have to ask if anyone else might be having problems with Vantage
> v8.03.305x, when using the MSSQL-2000 database ? We went live in late
> April, & have not been able to keep our system from crashing for
> longer than 8 days or so ! The number of Progress AppServers tends to
> climb way beyond the configured maximum (30, right now), right before
> the system craters, we frequently see 'orphan' appservers showing up
> in Progress Explorer (but, no longer appearing in Windows Task
> Manager), & despite some extreme efforts by both Epicor and Progress
> support, we've spent the last 4+ months (!!) fighting this beast.
>
> When the system does crash, it tends to completely run the system out
> of available virtual memory /hard disk space (with system-managed
> virtual memory). Pretty messy !!
>
> We are being advised to upgrade to Service pack .40x, but that also
> requires SQL-2005, which we don't yet have in place.
>
> Anyone else out there suffering as much as we appear to be ??
>
> Thanks in advance for any consolation & help you can offer.
>
> Best Regards,
> - Gary -
>
>
>
> [Non-text portions of this message have been removed]
>

[Non-text portions of this message have been removed]

[system]

Just a few more questions



Do you have the backflush process running?

If so is it running along side MRP when it runs on a schedule?



If you start the MRP task manually and not from a schedule do you see
any difference in the stability.

Do you ever get failures in MRP running? What is the duration of the
process.

Do you have multiple schedulers and multiple mrp processes in the MRP
task?

Do you see any locks referenced or errors in the mfgsys803.server log?

Do you see invalid user ID or password just before a meltdown in the
server logs if not do you see any reference?



I presume you have enabled verbose logging - when the system is
exhausted of all resources is there any indication as to the procedures
that are being called prior - during?

Does the Broker log identify these appservers instances (upto 149!) that
get spawned?

Do you use session timeouts on the users?



Regarding the .pf file have you found any more stability with the
modifications that were made over the default .pf file?

What was the reasoning for decreasing the lock wait timeout parameter -
where you finding areas of the system locking repeatedly?

Also regarding the -s parameter were you seeing stack overflow errors,
if so what procedures where causing these?



When you look at the main appservers status - if you look at the PID of
each of the appservers instances what is there status and if monitored
with

Process explorer Are they processing / reading disk / taking up more and
more resources?

Do you find that resources are taken up because of the number of
appservers instances that are started (to 149!)

Or that single instances have taken up too much resource.



Regards,

Stephen



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Gary Franks
Sent: 03 October 2007 17:55
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Vantage System Stability with SQL ?



Hi, Stephen.....I'll try to answer your questions in the order you
posed them :

1.) Yes, the crashes happen just about the same way each time. 'Early
Warning' is given by looking at the status of the main
appserver....after MRP runs overnight. If I see anything above the
initial value (currently 25), or approaching the configured max value
(currently 30), it's almost certain that we'll see a crash in the next
24 hours or less (usually less).
2.) I think we have 46 'Office' Licenses for Vantage, and 38 MES
licenses. When a crash happens, we are close to the maximum on sessions.
3.) We are at 8.03.305F...considering upgrading to either .305H or .403B
4.) Our DEV server is a separate box...no problems ever seen there
because it's a lightly-used system.
5.) Right before a crash, the resources will suddenly drop down on the
server....very quickly in most cases.
6.) All other databases and appservers have been disabled for months,
since we've been having this stability issue.
7.) 25 initial appservers, 30 max....I've seen that value climb as
high as 149 (!!!) before the quad-dual-core processor, running Windows
Server R2, latest service pack, 8GB ram, runs totally out of
system-managed virtual memory & simply stops responding.

8.) MFGSYS.PF File : (heavily modified by Epicor
Developers...especially the "-s 8000" parameter value !
======================================
-Mm 1024 -mmax 65534 -Bt 2048 -s 8000 -yy 1970 -stsh 31 -inp 32000
-tok 4000 -TB 31 -TM 32 -D 500 -l 1000
-tmpbsize 8
-lkwtmo 180
-T C:\epicor\AppserverTempFiles
-db f:\epicor\mfgsys803\db\mfgsyssh
-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
-q

#### 07/05/2007 - Raj - Added -tmpbsize 8, changed -T to point to C:\
drive
#### Original settings before Raj changed it on 5/3/07
#-Mm 1024 -mmax 4000 -Bt 200 -s 200 -yy 1970 -stsh 31 -inp 32000 -tok
4000 -lkwtmo 300
#-T f:\epicor\mfgwrk803
#-db f:\epicor\mfgsys803\db\mfgsyssh
#-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
# -q requires restart of appserver when you copy any new dotR code
this includes patch.

#### 08/16/2007 - Gary ... Changed -s parameter, above, to 8000 per
S.Johanns
#### Here is what is was before it was changed :
#-Mm 1024 -mmax 65534 -Bt 2048 -s 4000 -yy 1970 -stsh 31 -inp 32000
-tok 4000 -TB 31 -TM 32 -D 500 -l 1000
#-tmpbsize 8
#-lkwtmo 180
#-T C:\epicor\AppserverTempFiles
#-db f:\epicor\mfgsys803\db\mfgsyssh
#-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
#-q
=============================================
9.) This server ONLY runs Vantage....nothing else, not even
anti-virus. It has MS-SQL-2000 for the db, however.

Thanks again for your interest.......Gary

- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"Stephen Edginton" <stephene@...> wrote:

>
> Hi Gary,
>
> I presume the system crash's in the same manor each
> time?
>
> How many Licenses do you have for vantage and when it
> crashes if you look at maintain sessions - how many sessions are
> displayed
>
> Also when patch level are you running
>
> Did you see any of this behavior in your test / piloting
> environment?
>
> Prior to a failure what are the resources like on the
> server.
>
> Do you have all other appservers instances (test train
> pilot environments turned off?)
>
> You mentioned that the configured maximum gets exceeded
> (what are your settings for initial start - minimum and maximum for

the

> agents?)
>
> Please post your mfgsys.pf file - to detail the startup
> parameters you have configured.
>
> Also provide an overview of the hardware the server is
> utilizing (disk, CPU RAM)
>
> Does the server have any other roles other than vantage?
>
>
>
> Regards,
>
> Stephen
>
>
>
> From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
Behalf

> Of Gary Franks
> Sent: 02 October 2007 17:48
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Subject: [Vantage] Vantage System Stability with SQL ?
>
>
>
> Hello, all,
>
> I have to ask if anyone else might be having problems with Vantage
> v8.03.305x, when using the MSSQL-2000 database ? We went live in late
> April, & have not been able to keep our system from crashing for
> longer than 8 days or so ! The number of Progress AppServers tends to
> climb way beyond the configured maximum (30, right now), right before
> the system craters, we frequently see 'orphan' appservers showing up
> in Progress Explorer (but, no longer appearing in Windows Task
> Manager), & despite some extreme efforts by both Epicor and Progress
> support, we've spent the last 4+ months (!!) fighting this beast.
>
> When the system does crash, it tends to completely run the system out
> of available virtual memory /hard disk space (with system-managed
> virtual memory). Pretty messy !!
>
> We are being advised to upgrade to Service pack .40x, but that also
> requires SQL-2005, which we don't yet have in place.
>
> Anyone else out there suffering as much as we appear to be ??
>
> Thanks in advance for any consolation & help you can offer.
>
> Best Regards,
> - Gary -
>
>
>
> [Non-text portions of this message have been removed]
>

[Non-text portions of this message have been removed]

[system]

Hello, Stephen,

1.) No, we do not have the backflush process running at all right now.
2.) We haven't tried running MRP manually since we went live...it
always runs from the System Agent as a task.
3.) We have experimented with the schedulers and processes quite a
lot, with Epicor's help....right now, I think we're at 8 & 8.
4.) We do occasionally see locks referenced, & that's why our *.pf
file has a value of 8000, & our 'lock-wait-timeout' is currently set
at 3 minutes, I believe.
5.) We seldom see invalid ID's/Passwords entries...it happens , but
not all that frequently.
6.) Verbose logging is enabled, & we just installed fresh 'debug'
objects from progress that gives even more info in the ubroker log.
7.) We've sent dozens of captured log files to Epicor when the system
craters.....so far, the best of the developers appears stumped, along
with the Progress support developers.
8.) Interesting question on the appservers and resources. Initially,
we would see ALL appservers go into a SENDING state, & stay there.
After numerous 'tuning' sessions with the Vantage developer connected
remotely, we no longer see that situation. Now, instead, we see
appserver PID's in Progress Explorer which are NOT showing up in
Windows Task Manager...this is a constant happening now. When the
number of appservers exceeds 30 (our configured maximum), each and
every one beyond 30 seems to be an 'orphan'...i.e...not in Task
Manager. If we don't catch the situation quickly enough, the number
continues to grow until all Virtual memory is consumed (i.e...the hard
disk fills up) and/or we max out on database connections & even
Progress Explorer can't be started.
9.) All users are set with a 15-minute timeout window on their session.
10.) Yes,after tuning, instead of crashing every 1-2 hours (!!), we
went to crashing around every 24-48 hours. Still not good, obviously.
11.) INitially, we were seeing quite a lot of SQL-timeout errors in
the log files. Decreasing the lock-wait-timeout value was a
'shortcut' to allow those locks to be released early. Artificial, but
something the developer from Epicor really wanted to do.
12.) The -s parameter setting was one jointly recommended by Microsoft
and Progress, to better match Microsoft's SQL 'standard' value. This
one was thought to be 'the magic bullet' for our woes....didn't turn
out that way, unfortunately.
13.) We typically find that resources are being consumed by the
multiple instances of appservers that are spawned....sometimes to the
extreme that it's almost impossible to get the Windows console itself
to respond to the server keyboard for 5-10 minutes.

Hope this answers your questions...greatly appreciate your time to
chat about this.

Sincerely,
- Gary -

--- In vantage@yahoogroups.com, "Stephen Edginton" <stephene@...> wrote:
>
> Just a few more questions
>
>
>
> Do you have the backflush process running?
>
> If so is it running along side MRP when it runs on a schedule?
>
>
>
> If you start the MRP task manually and not from a schedule do you see
> any difference in the stability.
>
> Do you ever get failures in MRP running? What is the duration of the
> process.
>
> Do you have multiple schedulers and multiple mrp processes in the MRP
> task?
>
> Do you see any locks referenced or errors in the mfgsys803.server log?
>
> Do you see invalid user ID or password just before a meltdown in the
> server logs if not do you see any reference?
>
>
>
> I presume you have enabled verbose logging - when the system is
> exhausted of all resources is there any indication as to the procedures
> that are being called prior - during?
>
> Does the Broker log identify these appservers instances (upto 149!) that
> get spawned?
>
> Do you use session timeouts on the users?
>
>
>
> Regarding the .pf file have you found any more stability with the
> modifications that were made over the default .pf file?
>
> What was the reasoning for decreasing the lock wait timeout parameter -
> where you finding areas of the system locking repeatedly?
>
> Also regarding the -s parameter were you seeing stack overflow errors,
> if so what procedures where causing these?
>
>
>
> When you look at the main appservers status - if you look at the PID of
> each of the appservers instances what is there status and if monitored
> with
>
> Process explorer Are they processing / reading disk / taking up more and
> more resources?
>
> Do you find that resources are taken up because of the number of
> appservers instances that are started (to 149!)
>
> Or that single instances have taken up too much resource.
>
>
>
> Regards,
>
> Stephen
>
>
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
> Of Gary Franks
> Sent: 03 October 2007 17:55
> To: vantage@yahoogroups.com
> Subject: [Vantage] Re: Vantage System Stability with SQL ?
>
>
>
> Hi, Stephen.....I'll try to answer your questions in the order you
> posed them :
>
> 1.) Yes, the crashes happen just about the same way each time. 'Early
> Warning' is given by looking at the status of the main
> appserver....after MRP runs overnight. If I see anything above the
> initial value (currently 25), or approaching the configured max value
> (currently 30), it's almost certain that we'll see a crash in the next
> 24 hours or less (usually less).
> 2.) I think we have 46 'Office' Licenses for Vantage, and 38 MES
> licenses. When a crash happens, we are close to the maximum on sessions.
> 3.) We are at 8.03.305F...considering upgrading to either .305H or .403B
> 4.) Our DEV server is a separate box...no problems ever seen there
> because it's a lightly-used system.
> 5.) Right before a crash, the resources will suddenly drop down on the
> server....very quickly in most cases.
> 6.) All other databases and appservers have been disabled for months,
> since we've been having this stability issue.
> 7.) 25 initial appservers, 30 max....I've seen that value climb as
> high as 149 (!!!) before the quad-dual-core processor, running Windows
> Server R2, latest service pack, 8GB ram, runs totally out of
> system-managed virtual memory & simply stops responding.
>
> 8.) MFGSYS.PF File : (heavily modified by Epicor
> Developers...especially the "-s 8000" parameter value !
> ======================================
> -Mm 1024 -mmax 65534 -Bt 2048 -s 8000 -yy 1970 -stsh 31 -inp 32000
> -tok 4000 -TB 31 -TM 32 -D 500 -l 1000
> -tmpbsize 8
> -lkwtmo 180
> -T C:\epicor\AppserverTempFiles
> -db f:\epicor\mfgsys803\db\mfgsyssh
> -db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> -q
>
> #### 07/05/2007 - Raj - Added -tmpbsize 8, changed -T to point to C:\
> drive
> #### Original settings before Raj changed it on 5/3/07
> #-Mm 1024 -mmax 4000 -Bt 200 -s 200 -yy 1970 -stsh 31 -inp 32000 -tok
> 4000 -lkwtmo 300
> #-T f:\epicor\mfgwrk803
> #-db f:\epicor\mfgsys803\db\mfgsyssh
> #-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> # -q requires restart of appserver when you copy any new dotR code
> this includes patch.
>
> #### 08/16/2007 - Gary ... Changed -s parameter, above, to 8000 per
> S.Johanns
> #### Here is what is was before it was changed :
> #-Mm 1024 -mmax 65534 -Bt 2048 -s 4000 -yy 1970 -stsh 31 -inp 32000
> -tok 4000 -TB 31 -TM 32 -D 500 -l 1000
> #-tmpbsize 8
> #-lkwtmo 180
> #-T C:\epicor\AppserverTempFiles
> #-db f:\epicor\mfgsys803\db\mfgsyssh
> #-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> #-q
> =============================================
> 9.) This server ONLY runs Vantage....nothing else, not even
> anti-virus. It has MS-SQL-2000 for the db, however.
>
> Thanks again for your interest.......Gary
>
> - In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
> "Stephen Edginton" <stephene@> wrote:
> >
> > Hi Gary,
> >
> > I presume the system crash's in the same manor each
> > time?
> >
> > How many Licenses do you have for vantage and when it
> > crashes if you look at maintain sessions - how many sessions are
> > displayed
> >
> > Also when patch level are you running
> >
> > Did you see any of this behavior in your test / piloting
> > environment?
> >
> > Prior to a failure what are the resources like on the
> > server.
> >
> > Do you have all other appservers instances (test train
> > pilot environments turned off?)
> >
> > You mentioned that the configured maximum gets exceeded
> > (what are your settings for initial start - minimum and maximum for
> the
> > agents?)
> >
> > Please post your mfgsys.pf file - to detail the startup
> > parameters you have configured.
> >
> > Also provide an overview of the hardware the server is
> > utilizing (disk, CPU RAM)
> >
> > Does the server have any other roles other than vantage?
> >
> >
> >
> > Regards,
> >
> > Stephen
> >
> >
> >
> > From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> [mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
> Behalf
> > Of Gary Franks
> > Sent: 02 October 2007 17:48
> > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > Subject: [Vantage] Vantage System Stability with SQL ?
> >
> >
> >
> > Hello, all,
> >
> > I have to ask if anyone else might be having problems with Vantage
> > v8.03.305x, when using the MSSQL-2000 database ? We went live in late
> > April, & have not been able to keep our system from crashing for
> > longer than 8 days or so ! The number of Progress AppServers tends to
> > climb way beyond the configured maximum (30, right now), right before
> > the system craters, we frequently see 'orphan' appservers showing up
> > in Progress Explorer (but, no longer appearing in Windows Task
> > Manager), & despite some extreme efforts by both Epicor and Progress
> > support, we've spent the last 4+ months (!!) fighting this beast.
> >
> > When the system does crash, it tends to completely run the system out
> > of available virtual memory /hard disk space (with system-managed
> > virtual memory). Pretty messy !!
> >
> > We are being advised to upgrade to Service pack .40x, but that also
> > requires SQL-2005, which we don't yet have in place.
> >
> > Anyone else out there suffering as much as we appear to be ??
> >
> > Thanks in advance for any consolation & help you can offer.
> >
> > Best Regards,
> > - Gary -
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
> [Non-text portions of this message have been removed]
>

[system]

Gary,

With 8 & 8 for MRP what is the difference in run time to
1 and 1 (and stability if anything)

4) 8000 is the -s parameter this is stack size - your
locks are -lkwtmo 180 = 2 minutes - does it seem that locks are seen
before a failure?

7) that's not too good!

8) this is very strange - you must be doing something
different to a lot of other users........



You mentioned before Service connect and that it has been moved to
process on another server.

What kinds of workflows do you have configured - how often are these
being utilized.

Have you tried pointing your workflows to your test environment or
disabling there process for a period of time?

Do you utilize BPM much?



What I find strange is that your stability is so poor - with a default
install of vantage on SQL 2000 you run for less than 2 hours before
failure.

Have you looked at trying to run against your development box for all
users - to try and simulate the same issues in a different environment?

Maybe restore the database - switch DNS to point to your development
environment?



Do you have the network adapters in the server teamed? Have you ruled
out hardware at this stage?



Regards,

Stephen



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Gary Franks
Sent: 04 October 2007 05:14
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Vantage System Stability with SQL ?



Hello, Stephen,

1.) No, we do not have the backflush process running at all right now.
2.) We haven't tried running MRP manually since we went live...it
always runs from the System Agent as a task.
3.) We have experimented with the schedulers and processes quite a
lot, with Epicor's help....right now, I think we're at 8 & 8.
4.) We do occasionally see locks referenced, & that's why our *.pf
file has a value of 8000, & our 'lock-wait-timeout' is currently set
at 3 minutes, I believe.
5.) We seldom see invalid ID's/Passwords entries...it happens , but
not all that frequently.
6.) Verbose logging is enabled, & we just installed fresh 'debug'
objects from progress that gives even more info in the ubroker log.
7.) We've sent dozens of captured log files to Epicor when the system
craters.....so far, the best of the developers appears stumped, along
with the Progress support developers.
8.) Interesting question on the appservers and resources. Initially,
we would see ALL appservers go into a SENDING state, & stay there.
After numerous 'tuning' sessions with the Vantage developer connected
remotely, we no longer see that situation. Now, instead, we see
appserver PID's in Progress Explorer which are NOT showing up in
Windows Task Manager...this is a constant happening now. When the
number of appservers exceeds 30 (our configured maximum), each and
every one beyond 30 seems to be an 'orphan'...i.e...not in Task
Manager. If we don't catch the situation quickly enough, the number
continues to grow until all Virtual memory is consumed (i.e...the hard
disk fills up) and/or we max out on database connections & even
Progress Explorer can't be started.
9.) All users are set with a 15-minute timeout window on their session.
10.) Yes,after tuning, instead of crashing every 1-2 hours (!!), we
went to crashing around every 24-48 hours. Still not good, obviously.
11.) INitially, we were seeing quite a lot of SQL-timeout errors in
the log files. Decreasing the lock-wait-timeout value was a
'shortcut' to allow those locks to be released early. Artificial, but
something the developer from Epicor really wanted to do.
12.) The -s parameter setting was one jointly recommended by Microsoft
and Progress, to better match Microsoft's SQL 'standard' value. This
one was thought to be 'the magic bullet' for our woes....didn't turn
out that way, unfortunately.
13.) We typically find that resources are being consumed by the
multiple instances of appservers that are spawned....sometimes to the
extreme that it's almost impossible to get the Windows console itself
to respond to the server keyboard for 5-10 minutes.

Hope this answers your questions...greatly appreciate your time to
chat about this.

Sincerely,
- Gary -

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"Stephen Edginton" <stephene@...> wrote:

>
> Just a few more questions
>
>
>
> Do you have the backflush process running?
>
> If so is it running along side MRP when it runs on a schedule?
>
>
>
> If you start the MRP task manually and not from a schedule do you see
> any difference in the stability.
>
> Do you ever get failures in MRP running? What is the duration of the
> process.
>
> Do you have multiple schedulers and multiple mrp processes in the MRP
> task?
>
> Do you see any locks referenced or errors in the mfgsys803.server log?
>
> Do you see invalid user ID or password just before a meltdown in the
> server logs if not do you see any reference?
>
>
>
> I presume you have enabled verbose logging - when the system is
> exhausted of all resources is there any indication as to the

procedures

> that are being called prior - during?
>
> Does the Broker log identify these appservers instances (upto 149!)

that

> get spawned?
>
> Do you use session timeouts on the users?
>
>
>
> Regarding the .pf file have you found any more stability with the
> modifications that were made over the default .pf file?
>
> What was the reasoning for decreasing the lock wait timeout parameter

-

> where you finding areas of the system locking repeatedly?
>
> Also regarding the -s parameter were you seeing stack overflow errors,
> if so what procedures where causing these?
>
>
>
> When you look at the main appservers status - if you look at the PID

of

> each of the appservers instances what is there status and if monitored
> with
>
> Process explorer Are they processing / reading disk / taking up more

and

> more resources?
>
> Do you find that resources are taken up because of the number of
> appservers instances that are started (to 149!)
>
> Or that single instances have taken up too much resource.
>
>
>
> Regards,
>
> Stephen
>
>
>
> From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
Behalf

> Of Gary Franks
> Sent: 03 October 2007 17:55
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Subject: [Vantage] Re: Vantage System Stability with SQL ?
>
>
>
> Hi, Stephen.....I'll try to answer your questions in the order you
> posed them :
>
> 1.) Yes, the crashes happen just about the same way each time. 'Early
> Warning' is given by looking at the status of the main
> appserver....after MRP runs overnight. If I see anything above the
> initial value (currently 25), or approaching the configured max value
> (currently 30), it's almost certain that we'll see a crash in the next
> 24 hours or less (usually less).
> 2.) I think we have 46 'Office' Licenses for Vantage, and 38 MES
> licenses. When a crash happens, we are close to the maximum on

sessions.

> 3.) We are at 8.03.305F...considering upgrading to either .305H or

.403B

> 4.) Our DEV server is a separate box...no problems ever seen there
> because it's a lightly-used system.
> 5.) Right before a crash, the resources will suddenly drop down on the
> server....very quickly in most cases.
> 6.) All other databases and appservers have been disabled for months,
> since we've been having this stability issue.
> 7.) 25 initial appservers, 30 max....I've seen that value climb as
> high as 149 (!!!) before the quad-dual-core processor, running Windows
> Server R2, latest service pack, 8GB ram, runs totally out of
> system-managed virtual memory & simply stops responding.
>
> 8.) MFGSYS.PF File : (heavily modified by Epicor
> Developers...especially the "-s 8000" parameter value !
> ======================================
> -Mm 1024 -mmax 65534 -Bt 2048 -s 8000 -yy 1970 -stsh 31 -inp 32000
> -tok 4000 -TB 31 -TM 32 -D 500 -l 1000
> -tmpbsize 8
> -lkwtmo 180
> -T C:\epicor\AppserverTempFiles
> -db f:\epicor\mfgsys803\db\mfgsyssh
> -db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> -q
>
> #### 07/05/2007 - Raj - Added -tmpbsize 8, changed -T to point to C:\
> drive
> #### Original settings before Raj changed it on 5/3/07
> #-Mm 1024 -mmax 4000 -Bt 200 -s 200 -yy 1970 -stsh 31 -inp 32000 -tok
> 4000 -lkwtmo 300
> #-T f:\epicor\mfgwrk803
> #-db f:\epicor\mfgsys803\db\mfgsyssh
> #-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> # -q requires restart of appserver when you copy any new dotR code
> this includes patch.
>
> #### 08/16/2007 - Gary ... Changed -s parameter, above, to 8000 per
> S.Johanns
> #### Here is what is was before it was changed :
> #-Mm 1024 -mmax 65534 -Bt 2048 -s 4000 -yy 1970 -stsh 31 -inp 32000
> -tok 4000 -TB 31 -TM 32 -D 500 -l 1000
> #-tmpbsize 8
> #-lkwtmo 180
> #-T C:\epicor\AppserverTempFiles
> #-db f:\epicor\mfgsys803\db\mfgsyssh
> #-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> #-q
> =============================================
> 9.) This server ONLY runs Vantage....nothing else, not even
> anti-virus. It has MS-SQL-2000 for the db, however.
>
> Thanks again for your interest.......Gary
>
> - In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

<mailto:vantage%40yahoogroups.com> ,

> "Stephen Edginton" <stephene@> wrote:
> >
> > Hi Gary,
> >
> > I presume the system crash's in the same manor each
> > time?
> >
> > How many Licenses do you have for vantage and when it
> > crashes if you look at maintain sessions - how many sessions are
> > displayed
> >
> > Also when patch level are you running
> >
> > Did you see any of this behavior in your test / piloting
> > environment?
> >
> > Prior to a failure what are the resources like on the
> > server.
> >
> > Do you have all other appservers instances (test train
> > pilot environments turned off?)
> >
> > You mentioned that the configured maximum gets exceeded
> > (what are your settings for initial start - minimum and maximum for
> the
> > agents?)
> >
> > Please post your mfgsys.pf file - to detail the startup
> > parameters you have configured.
> >
> > Also provide an overview of the hardware the server is
> > utilizing (disk, CPU RAM)
> >
> > Does the server have any other roles other than vantage?
> >
> >
> >
> > Regards,
> >
> > Stephen
> >
> >
> >
> > From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

<mailto:vantage%40yahoogroups.com>

> [mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

<mailto:vantage%40yahoogroups.com> ] On

> Behalf
> > Of Gary Franks
> > Sent: 02 October 2007 17:48
> > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

<mailto:vantage%40yahoogroups.com>

> > Subject: [Vantage] Vantage System Stability with SQL ?
> >
> >
> >
> > Hello, all,
> >
> > I have to ask if anyone else might be having problems with Vantage
> > v8.03.305x, when using the MSSQL-2000 database ? We went live in

late

> > April, & have not been able to keep our system from crashing for
> > longer than 8 days or so ! The number of Progress AppServers tends

to

> > climb way beyond the configured maximum (30, right now), right

before

> > the system craters, we frequently see 'orphan' appservers showing up
> > in Progress Explorer (but, no longer appearing in Windows Task
> > Manager), & despite some extreme efforts by both Epicor and Progress
> > support, we've spent the last 4+ months (!!) fighting this beast.
> >
> > When the system does crash, it tends to completely run the system

out

> > of available virtual memory /hard disk space (with system-managed
> > virtual memory). Pretty messy !!
> >
> > We are being advised to upgrade to Service pack .40x, but that also
> > requires SQL-2005, which we don't yet have in place.
> >
> > Anyone else out there suffering as much as we appear to be ??
> >
> > Thanks in advance for any consolation & help you can offer.
> >
> > Best Regards,
> > - Gary -
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
> [Non-text portions of this message have been removed]
>

[Non-text portions of this message have been removed]

[system]

Hi, Steven...thanks for staying around on this one...

There is about a 1.5 hour difference in run time for MRP between 8&8
and 1&1...no difference in stability.

I think 180 for lock-wait-timeout = (180/60)=3 minutes, not 2 ?

I don't think we're unique at all....although we use Service Connect
to interface to our Gentran EDI Translator, rather than use the
less-capable offerings from Epicor. Can't live without EDI..it's over
65% of our total business. Also can't use our DEV system in
PRODuction, as it only has half the processing and memory capacity.

We've done LOTS of work unloading/reloading the DB...no joy.

Our only BPM's are two...and, both simply 'trigger' outbound EDI
transactions.

We do not see lock wait timeouts much at all anymore....just every few
days, the system starts building lots of extra appservers all of a
sudden, & crashes. Just about everything seems to point to some
serious problem with Progress, & even the Progress folks seem to agree.

Early on, we did have server hardware (memory) problems, but no
longer. I look at our HP diags console every morning, 7 days a week,
& no longer see what we encountered (memory management would have
trouble) months ago. It's been clean ever since.

Earlier, Progress and Epicor both wanted to blame this on 'some sort
of network problem, maybe DNS', but many nights of work by Microsoft
have ruled that out...and, independently confirmed by a non-Microsoft
consultant as well.

Using a single network adapter...have tried both in this box, with
identical results. We've even had the system board replaced more than
once by HP, 'just in case'....still did not help at all.

We've had HP bring in their 'environmental' experts, to do long-term
monitoring of our server room power....it's clean...well-grounded...no
troubles.

We've spent so much time on this problem that our ownership and upper
management are wondering just what their next avenue for relief might
be if Epicor and/or Progress can't get it figured out. As the
implementation project co-manager, and as our Corporate IT Mgr., my
job and reputation are also on the line on this one....

Thanks again for your thoughts ...... Gary

--- In vantage@yahoogroups.com, "Stephen Edginton" <stephene@...> wrote:
>
> Gary,
>
> With 8 & 8 for MRP what is the difference in run time to
> 1 and 1 (and stability if anything)
>
> 4) 8000 is the -s parameter this is stack size - your
> locks are -lkwtmo 180 = 2 minutes - does it seem that locks are seen
> before a failure?
>
> 7) that's not too good!
>
> 8) this is very strange - you must be doing something
> different to a lot of other users........
>
>
>
> You mentioned before Service connect and that it has been moved to
> process on another server.
>
> What kinds of workflows do you have configured - how often are these
> being utilized.
>
> Have you tried pointing your workflows to your test environment or
> disabling there process for a period of time?
>
> Do you utilize BPM much?
>
>
>
> What I find strange is that your stability is so poor - with a default
> install of vantage on SQL 2000 you run for less than 2 hours before
> failure.
>
> Have you looked at trying to run against your development box for all
> users - to try and simulate the same issues in a different environment?
>
> Maybe restore the database - switch DNS to point to your development
> environment?
>
>
>
> Do you have the network adapters in the server teamed? Have you ruled
> out hardware at this stage?
>
>
>
> Regards,
>
> Stephen
>
>
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
> Of Gary Franks
> Sent: 04 October 2007 05:14
> To: vantage@yahoogroups.com
> Subject: [Vantage] Re: Vantage System Stability with SQL ?
>
>
>
> Hello, Stephen,
>
> 1.) No, we do not have the backflush process running at all right now.
> 2.) We haven't tried running MRP manually since we went live...it
> always runs from the System Agent as a task.
> 3.) We have experimented with the schedulers and processes quite a
> lot, with Epicor's help....right now, I think we're at 8 & 8.
> 4.) We do occasionally see locks referenced, & that's why our *.pf
> file has a value of 8000, & our 'lock-wait-timeout' is currently set
> at 3 minutes, I believe.
> 5.) We seldom see invalid ID's/Passwords entries...it happens , but
> not all that frequently.
> 6.) Verbose logging is enabled, & we just installed fresh 'debug'
> objects from progress that gives even more info in the ubroker log.
> 7.) We've sent dozens of captured log files to Epicor when the system
> craters.....so far, the best of the developers appears stumped, along
> with the Progress support developers.
> 8.) Interesting question on the appservers and resources. Initially,
> we would see ALL appservers go into a SENDING state, & stay there.
> After numerous 'tuning' sessions with the Vantage developer connected
> remotely, we no longer see that situation. Now, instead, we see
> appserver PID's in Progress Explorer which are NOT showing up in
> Windows Task Manager...this is a constant happening now. When the
> number of appservers exceeds 30 (our configured maximum), each and
> every one beyond 30 seems to be an 'orphan'...i.e...not in Task
> Manager. If we don't catch the situation quickly enough, the number
> continues to grow until all Virtual memory is consumed (i.e...the hard
> disk fills up) and/or we max out on database connections & even
> Progress Explorer can't be started.
> 9.) All users are set with a 15-minute timeout window on their session.
> 10.) Yes,after tuning, instead of crashing every 1-2 hours (!!), we
> went to crashing around every 24-48 hours. Still not good, obviously.
> 11.) INitially, we were seeing quite a lot of SQL-timeout errors in
> the log files. Decreasing the lock-wait-timeout value was a
> 'shortcut' to allow those locks to be released early. Artificial, but
> something the developer from Epicor really wanted to do.
> 12.) The -s parameter setting was one jointly recommended by Microsoft
> and Progress, to better match Microsoft's SQL 'standard' value. This
> one was thought to be 'the magic bullet' for our woes....didn't turn
> out that way, unfortunately.
> 13.) We typically find that resources are being consumed by the
> multiple instances of appservers that are spawned....sometimes to the
> extreme that it's almost impossible to get the Windows console itself
> to respond to the server keyboard for 5-10 minutes.
>
> Hope this answers your questions...greatly appreciate your time to
> chat about this.
>
> Sincerely,
> - Gary -
>
> --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
> "Stephen Edginton" <stephene@> wrote:
> >
> > Just a few more questions
> >
> >
> >
> > Do you have the backflush process running?
> >
> > If so is it running along side MRP when it runs on a schedule?
> >
> >
> >
> > If you start the MRP task manually and not from a schedule do you see
> > any difference in the stability.
> >
> > Do you ever get failures in MRP running? What is the duration of the
> > process.
> >
> > Do you have multiple schedulers and multiple mrp processes in the MRP
> > task?
> >
> > Do you see any locks referenced or errors in the mfgsys803.server log?
> >
> > Do you see invalid user ID or password just before a meltdown in the
> > server logs if not do you see any reference?
> >
> >
> >
> > I presume you have enabled verbose logging - when the system is
> > exhausted of all resources is there any indication as to the
> procedures
> > that are being called prior - during?
> >
> > Does the Broker log identify these appservers instances (upto 149!)
> that
> > get spawned?
> >
> > Do you use session timeouts on the users?
> >
> >
> >
> > Regarding the .pf file have you found any more stability with the
> > modifications that were made over the default .pf file?
> >
> > What was the reasoning for decreasing the lock wait timeout parameter
> -
> > where you finding areas of the system locking repeatedly?
> >
> > Also regarding the -s parameter were you seeing stack overflow errors,
> > if so what procedures where causing these?
> >
> >
> >
> > When you look at the main appservers status - if you look at the PID
> of
> > each of the appservers instances what is there status and if monitored
> > with
> >
> > Process explorer Are they processing / reading disk / taking up more
> and
> > more resources?
> >
> > Do you find that resources are taken up because of the number of
> > appservers instances that are started (to 149!)
> >
> > Or that single instances have taken up too much resource.
> >
> >
> >
> > Regards,
> >
> > Stephen
> >
> >
> >
> > From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> [mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
> Behalf
> > Of Gary Franks
> > Sent: 03 October 2007 17:55
> > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > Subject: [Vantage] Re: Vantage System Stability with SQL ?
> >
> >
> >
> > Hi, Stephen.....I'll try to answer your questions in the order you
> > posed them :
> >
> > 1.) Yes, the crashes happen just about the same way each time. 'Early
> > Warning' is given by looking at the status of the main
> > appserver....after MRP runs overnight. If I see anything above the
> > initial value (currently 25), or approaching the configured max value
> > (currently 30), it's almost certain that we'll see a crash in the next
> > 24 hours or less (usually less).
> > 2.) I think we have 46 'Office' Licenses for Vantage, and 38 MES
> > licenses. When a crash happens, we are close to the maximum on
> sessions.
> > 3.) We are at 8.03.305F...considering upgrading to either .305H or
> .403B
> > 4.) Our DEV server is a separate box...no problems ever seen there
> > because it's a lightly-used system.
> > 5.) Right before a crash, the resources will suddenly drop down on the
> > server....very quickly in most cases.
> > 6.) All other databases and appservers have been disabled for months,
> > since we've been having this stability issue.
> > 7.) 25 initial appservers, 30 max....I've seen that value climb as
> > high as 149 (!!!) before the quad-dual-core processor, running Windows
> > Server R2, latest service pack, 8GB ram, runs totally out of
> > system-managed virtual memory & simply stops responding.
> >
> > 8.) MFGSYS.PF File : (heavily modified by Epicor
> > Developers...especially the "-s 8000" parameter value !
> > ======================================
> > -Mm 1024 -mmax 65534 -Bt 2048 -s 8000 -yy 1970 -stsh 31 -inp 32000
> > -tok 4000 -TB 31 -TM 32 -D 500 -l 1000
> > -tmpbsize 8
> > -lkwtmo 180
> > -T C:\epicor\AppserverTempFiles
> > -db f:\epicor\mfgsys803\db\mfgsyssh
> > -db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> > PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> > -q
> >
> > #### 07/05/2007 - Raj - Added -tmpbsize 8, changed -T to point to C:\
> > drive
> > #### Original settings before Raj changed it on 5/3/07
> > #-Mm 1024 -mmax 4000 -Bt 200 -s 200 -yy 1970 -stsh 31 -inp 32000 -tok
> > 4000 -lkwtmo 300
> > #-T f:\epicor\mfgwrk803
> > #-db f:\epicor\mfgsys803\db\mfgsyssh
> > #-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> > PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> > # -q requires restart of appserver when you copy any new dotR code
> > this includes patch.
> >
> > #### 08/16/2007 - Gary ... Changed -s parameter, above, to 8000 per
> > S.Johanns
> > #### Here is what is was before it was changed :
> > #-Mm 1024 -mmax 65534 -Bt 2048 -s 4000 -yy 1970 -stsh 31 -inp 32000
> > -tok 4000 -TB 31 -TM 32 -D 500 -l 1000
> > #-tmpbsize 8
> > #-lkwtmo 180
> > #-T C:\epicor\AppserverTempFiles
> > #-db f:\epicor\mfgsys803\db\mfgsyssh
> > #-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> > PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> > #-q
> > =============================================
> > 9.) This server ONLY runs Vantage....nothing else, not even
> > anti-virus. It has MS-SQL-2000 for the db, however.
> >
> > Thanks again for your interest.......Gary
> >
> > - In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> <mailto:vantage%40yahoogroups.com> ,
> > "Stephen Edginton" <stephene@> wrote:
> > >
> > > Hi Gary,
> > >
> > > I presume the system crash's in the same manor each
> > > time?
> > >
> > > How many Licenses do you have for vantage and when it
> > > crashes if you look at maintain sessions - how many sessions are
> > > displayed
> > >
> > > Also when patch level are you running
> > >
> > > Did you see any of this behavior in your test / piloting
> > > environment?
> > >
> > > Prior to a failure what are the resources like on the
> > > server.
> > >
> > > Do you have all other appservers instances (test train
> > > pilot environments turned off?)
> > >
> > > You mentioned that the configured maximum gets exceeded
> > > (what are your settings for initial start - minimum and maximum for
> > the
> > > agents?)
> > >
> > > Please post your mfgsys.pf file - to detail the startup
> > > parameters you have configured.
> > >
> > > Also provide an overview of the hardware the server is
> > > utilizing (disk, CPU RAM)
> > >
> > > Does the server have any other roles other than vantage?
> > >
> > >
> > >
> > > Regards,
> > >
> > > Stephen
> > >
> > >
> > >
> > > From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> <mailto:vantage%40yahoogroups.com>
> > [mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> <mailto:vantage%40yahoogroups.com> ] On
> > Behalf
> > > Of Gary Franks
> > > Sent: 02 October 2007 17:48
> > > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> <mailto:vantage%40yahoogroups.com>
> > > Subject: [Vantage] Vantage System Stability with SQL ?
> > >
> > >
> > >
> > > Hello, all,
> > >
> > > I have to ask if anyone else might be having problems with Vantage
> > > v8.03.305x, when using the MSSQL-2000 database ? We went live in
> late
> > > April, & have not been able to keep our system from crashing for
> > > longer than 8 days or so ! The number of Progress AppServers tends
> to
> > > climb way beyond the configured maximum (30, right now), right
> before
> > > the system craters, we frequently see 'orphan' appservers showing up
> > > in Progress Explorer (but, no longer appearing in Windows Task
> > > Manager), & despite some extreme efforts by both Epicor and Progress
> > > support, we've spent the last 4+ months (!!) fighting this beast.
> > >
> > > When the system does crash, it tends to completely run the system
> out
> > > of available virtual memory /hard disk space (with system-managed
> > > virtual memory). Pretty messy !!
> > >
> > > We are being advised to upgrade to Service pack .40x, but that also
> > > requires SQL-2005, which we don't yet have in place.
> > >
> > > Anyone else out there suffering as much as we appear to be ??
> > >
> > > Thanks in advance for any consolation & help you can offer.
> > >
> > > Best Regards,
> > > - Gary -
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
> [Non-text portions of this message have been removed]
>

[system]

Well, our unstable system is true to form this morning....After less
than 48 hours, we have 'orphan' appservers (initiated, but no longer
showing in Windows Task Manager), appservers are maxxed-out at our
configured limit of 30 (and, climbing), with no end to this madness in
sight ! Sending log files to Progress and Epicor is somewhat akin to
spitting in the ocean, it seems. We feel more than a little be 'at
our wits end'..... Suggestions from the Epicor help desk basically
boil down to 'upgrade to service pack .403B', which means we have to
upgrade our SQL-2000 environment first, so that's not quite so quick
to do.

We've had Epicor's best hardware guru looking at our system, no
problems found. He helped spec the system, by the way.

I think my next step is to mail-order one of those crystal amulets to
suspend over the server....

- Gary -

--- In vantage@yahoogroups.com, "Gary Franks" <garyfr2003@...> wrote:
>
> Hi, Steven...thanks for staying around on this one...
>
> There is about a 1.5 hour difference in run time for MRP between 8&8
> and 1&1...no difference in stability.
>
> I think 180 for lock-wait-timeout = (180/60)=3 minutes, not 2 ?
>
> I don't think we're unique at all....although we use Service Connect
> to interface to our Gentran EDI Translator, rather than use the
> less-capable offerings from Epicor. Can't live without EDI..it's over
> 65% of our total business. Also can't use our DEV system in
> PRODuction, as it only has half the processing and memory capacity.
>
> We've done LOTS of work unloading/reloading the DB...no joy.
>
> Our only BPM's are two...and, both simply 'trigger' outbound EDI
> transactions.
>
> We do not see lock wait timeouts much at all anymore....just every few
> days, the system starts building lots of extra appservers all of a
> sudden, & crashes. Just about everything seems to point to some
> serious problem with Progress, & even the Progress folks seem to agree.
>
> Early on, we did have server hardware (memory) problems, but no
> longer. I look at our HP diags console every morning, 7 days a week,
> & no longer see what we encountered (memory management would have
> trouble) months ago. It's been clean ever since.
>
> Earlier, Progress and Epicor both wanted to blame this on 'some sort
> of network problem, maybe DNS', but many nights of work by Microsoft
> have ruled that out...and, independently confirmed by a non-Microsoft
> consultant as well.
>
> Using a single network adapter...have tried both in this box, with
> identical results. We've even had the system board replaced more than
> once by HP, 'just in case'....still did not help at all.
>
> We've had HP bring in their 'environmental' experts, to do long-term
> monitoring of our server room power....it's clean...well-grounded...no
> troubles.
>
> We've spent so much time on this problem that our ownership and upper
> management are wondering just what their next avenue for relief might
> be if Epicor and/or Progress can't get it figured out. As the
> implementation project co-manager, and as our Corporate IT Mgr., my
> job and reputation are also on the line on this one....
>
> Thanks again for your thoughts ...... Gary
>
>
> --- In vantage@yahoogroups.com, "Stephen Edginton" <stephene@> wrote:
> >
> > Gary,
> >
> > With 8 & 8 for MRP what is the difference in run
time to
> > 1 and 1 (and stability if anything)
> >
> > 4) 8000 is the -s parameter this is stack size - your
> > locks are -lkwtmo 180 = 2 minutes - does it seem that locks are seen
> > before a failure?
> >
> > 7) that's not too good!
> >
> > 8) this is very strange - you must be doing something
> > different to a lot of other users........
> >
> >
> >
> > You mentioned before Service connect and that it has been moved to
> > process on another server.
> >
> > What kinds of workflows do you have configured - how often are these
> > being utilized.
> >
> > Have you tried pointing your workflows to your test environment or
> > disabling there process for a period of time?
> >
> > Do you utilize BPM much?
> >
> >
> >
> > What I find strange is that your stability is so poor - with a default
> > install of vantage on SQL 2000 you run for less than 2 hours before
> > failure.
> >
> > Have you looked at trying to run against your development box for all
> > users - to try and simulate the same issues in a different
environment?
> >
> > Maybe restore the database - switch DNS to point to your development
> > environment?
> >
> >
> >
> > Do you have the network adapters in the server teamed? Have you ruled
> > out hardware at this stage?
> >
> >
> >
> > Regards,
> >
> > Stephen
> >
> >
> >
> > From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
Behalf
> > Of Gary Franks
> > Sent: 04 October 2007 05:14
> > To: vantage@yahoogroups.com
> > Subject: [Vantage] Re: Vantage System Stability with SQL ?
> >
> >
> >
> > Hello, Stephen,
> >
> > 1.) No, we do not have the backflush process running at all right now.
> > 2.) We haven't tried running MRP manually since we went live...it
> > always runs from the System Agent as a task.
> > 3.) We have experimented with the schedulers and processes quite a
> > lot, with Epicor's help....right now, I think we're at 8 & 8.
> > 4.) We do occasionally see locks referenced, & that's why our *.pf
> > file has a value of 8000, & our 'lock-wait-timeout' is currently set
> > at 3 minutes, I believe.
> > 5.) We seldom see invalid ID's/Passwords entries...it happens , but
> > not all that frequently.
> > 6.) Verbose logging is enabled, & we just installed fresh 'debug'
> > objects from progress that gives even more info in the ubroker log.
> > 7.) We've sent dozens of captured log files to Epicor when the system
> > craters.....so far, the best of the developers appears stumped, along
> > with the Progress support developers.
> > 8.) Interesting question on the appservers and resources. Initially,
> > we would see ALL appservers go into a SENDING state, & stay there.
> > After numerous 'tuning' sessions with the Vantage developer connected
> > remotely, we no longer see that situation. Now, instead, we see
> > appserver PID's in Progress Explorer which are NOT showing up in
> > Windows Task Manager...this is a constant happening now. When the
> > number of appservers exceeds 30 (our configured maximum), each and
> > every one beyond 30 seems to be an 'orphan'...i.e...not in Task
> > Manager. If we don't catch the situation quickly enough, the number
> > continues to grow until all Virtual memory is consumed (i.e...the hard
> > disk fills up) and/or we max out on database connections & even
> > Progress Explorer can't be started.
> > 9.) All users are set with a 15-minute timeout window on their
session.
> > 10.) Yes,after tuning, instead of crashing every 1-2 hours (!!), we
> > went to crashing around every 24-48 hours. Still not good, obviously.
> > 11.) INitially, we were seeing quite a lot of SQL-timeout errors in
> > the log files. Decreasing the lock-wait-timeout value was a
> > 'shortcut' to allow those locks to be released early. Artificial, but
> > something the developer from Epicor really wanted to do.
> > 12.) The -s parameter setting was one jointly recommended by Microsoft
> > and Progress, to better match Microsoft's SQL 'standard' value. This
> > one was thought to be 'the magic bullet' for our woes....didn't turn
> > out that way, unfortunately.
> > 13.) We typically find that resources are being consumed by the
> > multiple instances of appservers that are spawned....sometimes to the
> > extreme that it's almost impossible to get the Windows console itself
> > to respond to the server keyboard for 5-10 minutes.
> >
> > Hope this answers your questions...greatly appreciate your time to
> > chat about this.
> >
> > Sincerely,
> > - Gary -
> >
> > --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
> > "Stephen Edginton" <stephene@> wrote:
> > >
> > > Just a few more questions
> > >
> > >
> > >
> > > Do you have the backflush process running?
> > >
> > > If so is it running along side MRP when it runs on a schedule?
> > >
> > >
> > >
> > > If you start the MRP task manually and not from a schedule do
you see
> > > any difference in the stability.
> > >
> > > Do you ever get failures in MRP running? What is the duration of the
> > > process.
> > >
> > > Do you have multiple schedulers and multiple mrp processes in
the MRP
> > > task?
> > >
> > > Do you see any locks referenced or errors in the
mfgsys803.server log?
> > >
> > > Do you see invalid user ID or password just before a meltdown in the
> > > server logs if not do you see any reference?
> > >
> > >
> > >
> > > I presume you have enabled verbose logging - when the system is
> > > exhausted of all resources is there any indication as to the
> > procedures
> > > that are being called prior - during?
> > >
> > > Does the Broker log identify these appservers instances (upto 149!)
> > that
> > > get spawned?
> > >
> > > Do you use session timeouts on the users?
> > >
> > >
> > >
> > > Regarding the .pf file have you found any more stability with the
> > > modifications that were made over the default .pf file?
> > >
> > > What was the reasoning for decreasing the lock wait timeout
parameter
> > -
> > > where you finding areas of the system locking repeatedly?
> > >
> > > Also regarding the -s parameter were you seeing stack overflow
errors,
> > > if so what procedures where causing these?
> > >
> > >
> > >
> > > When you look at the main appservers status - if you look at the PID
> > of
> > > each of the appservers instances what is there status and if
monitored
> > > with
> > >
> > > Process explorer Are they processing / reading disk / taking up more
> > and
> > > more resources?
> > >
> > > Do you find that resources are taken up because of the number of
> > > appservers instances that are started (to 149!)
> > >
> > > Or that single instances have taken up too much resource.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Stephen
> > >
> > >
> > >
> > > From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > [mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
] On
> > Behalf
> > > Of Gary Franks
> > > Sent: 03 October 2007 17:55
> > > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > > Subject: [Vantage] Re: Vantage System Stability with SQL ?
> > >
> > >
> > >
> > > Hi, Stephen.....I'll try to answer your questions in the order you
> > > posed them :
> > >
> > > 1.) Yes, the crashes happen just about the same way each time.
'Early
> > > Warning' is given by looking at the status of the main
> > > appserver....after MRP runs overnight. If I see anything above the
> > > initial value (currently 25), or approaching the configured max
value
> > > (currently 30), it's almost certain that we'll see a crash in
the next
> > > 24 hours or less (usually less).
> > > 2.) I think we have 46 'Office' Licenses for Vantage, and 38 MES
> > > licenses. When a crash happens, we are close to the maximum on
> > sessions.
> > > 3.) We are at 8.03.305F...considering upgrading to either .305H or
> > .403B
> > > 4.) Our DEV server is a separate box...no problems ever seen there
> > > because it's a lightly-used system.
> > > 5.) Right before a crash, the resources will suddenly drop down
on the
> > > server....very quickly in most cases.
> > > 6.) All other databases and appservers have been disabled for
months,
> > > since we've been having this stability issue.
> > > 7.) 25 initial appservers, 30 max....I've seen that value climb as
> > > high as 149 (!!!) before the quad-dual-core processor, running
Windows
> > > Server R2, latest service pack, 8GB ram, runs totally out of
> > > system-managed virtual memory & simply stops responding.
> > >
> > > 8.) MFGSYS.PF File : (heavily modified by Epicor
> > > Developers...especially the "-s 8000" parameter value !
> > > ======================================
> > > -Mm 1024 -mmax 65534 -Bt 2048 -s 8000 -yy 1970 -stsh 31 -inp 32000
> > > -tok 4000 -TB 31 -TM 32 -D 500 -l 1000
> > > -tmpbsize 8
> > > -lkwtmo 180
> > > -T C:\epicor\AppserverTempFiles
> > > -db f:\epicor\mfgsys803\db\mfgsyssh
> > > -db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> > > PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> > > -q
> > >
> > > #### 07/05/2007 - Raj - Added -tmpbsize 8, changed -T to point
to C:\
> > > drive
> > > #### Original settings before Raj changed it on 5/3/07
> > > #-Mm 1024 -mmax 4000 -Bt 200 -s 200 -yy 1970 -stsh 31 -inp 32000
-tok
> > > 4000 -lkwtmo 300
> > > #-T f:\epicor\mfgwrk803
> > > #-db f:\epicor\mfgsys803\db\mfgsyssh
> > > #-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> > > PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> > > # -q requires restart of appserver when you copy any new dotR code
> > > this includes patch.
> > >
> > > #### 08/16/2007 - Gary ... Changed -s parameter, above, to 8000 per
> > > S.Johanns
> > > #### Here is what is was before it was changed :
> > > #-Mm 1024 -mmax 65534 -Bt 2048 -s 4000 -yy 1970 -stsh 31 -inp 32000
> > > -tok 4000 -TB 31 -TM 32 -D 500 -l 1000
> > > #-tmpbsize 8
> > > #-lkwtmo 180
> > > #-T C:\epicor\AppserverTempFiles
> > > #-db f:\epicor\mfgsys803\db\mfgsyssh
> > > #-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> > > PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> > > #-q
> > > =============================================
> > > 9.) This server ONLY runs Vantage....nothing else, not even
> > > anti-virus. It has MS-SQL-2000 for the db, however.
> > >
> > > Thanks again for your interest.......Gary
> > >
> > > - In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > <mailto:vantage%40yahoogroups.com> ,
> > > "Stephen Edginton" <stephene@> wrote:
> > > >
> > > > Hi Gary,
> > > >
> > > > I presume the system crash's in the same manor each
> > > > time?
> > > >
> > > > How many Licenses do you have for vantage and when it
> > > > crashes if you look at maintain sessions - how many sessions are
> > > > displayed
> > > >
> > > > Also when patch level are you running
> > > >
> > > > Did you see any of this behavior in your test / piloting
> > > > environment?
> > > >
> > > > Prior to a failure what are the resources like on the
> > > > server.
> > > >
> > > > Do you have all other appservers instances (test train
> > > > pilot environments turned off?)
> > > >
> > > > You mentioned that the configured maximum gets exceeded
> > > > (what are your settings for initial start - minimum and
maximum for
> > > the
> > > > agents?)
> > > >
> > > > Please post your mfgsys.pf file - to detail the startup
> > > > parameters you have configured.
> > > >
> > > > Also provide an overview of the hardware the server is
> > > > utilizing (disk, CPU RAM)
> > > >
> > > > Does the server have any other roles other than vantage?
> > > >
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Stephen
> > > >
> > > >
> > > >
> > > > From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > <mailto:vantage%40yahoogroups.com>
> > > [mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > <mailto:vantage%40yahoogroups.com> ] On
> > > Behalf
> > > > Of Gary Franks
> > > > Sent: 02 October 2007 17:48
> > > > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > <mailto:vantage%40yahoogroups.com>
> > > > Subject: [Vantage] Vantage System Stability with SQL ?
> > > >
> > > >
> > > >
> > > > Hello, all,
> > > >
> > > > I have to ask if anyone else might be having problems with Vantage
> > > > v8.03.305x, when using the MSSQL-2000 database ? We went live in
> > late
> > > > April, & have not been able to keep our system from crashing for
> > > > longer than 8 days or so ! The number of Progress AppServers tends
> > to
> > > > climb way beyond the configured maximum (30, right now), right
> > before
> > > > the system craters, we frequently see 'orphan' appservers
showing up
> > > > in Progress Explorer (but, no longer appearing in Windows Task
> > > > Manager), & despite some extreme efforts by both Epicor and
Progress
> > > > support, we've spent the last 4+ months (!!) fighting this beast.
> > > >
> > > > When the system does crash, it tends to completely run the system
> > out
> > > > of available virtual memory /hard disk space (with system-managed
> > > > virtual memory). Pretty messy !!
> > > >
> > > > We are being advised to upgrade to Service pack .40x, but that
also
> > > > requires SQL-2005, which we don't yet have in place.
> > > >
> > > > Anyone else out there suffering as much as we appear to be ??
> > > >
> > > > Thanks in advance for any consolation & help you can offer.
> > > >
> > > > Best Regards,
> > > > - Gary -
> > > >
> > > >
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>

[system]

Gary,

Can you detail further the Web services you are using.

I have heard of one site that had similar issues which
occurred when calling the ar Invoice webservice.

Do you ever get any errors logged on service connect for
any of the transactions around the time things go unstable?

Or have you identified that there is no correlation to
issues and transactions processed by service connect workflows.



What were the results of the progress debugging objects
that you loaded?



In my opinion you need to replicate these issues in
another environment - i.e. set all the parameters to be default - such
that you see it happen more frequently.

Save the EDI transactions to replay them in the testing
environment and get a number of user to use the system.



I presume that SQL 2000 is on the same box as the
Appservers



Regards,

Stephen



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Gary Franks
Sent: 09 October 2007 11:39
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Vantage System Stability with SQL ?



Well, our unstable system is true to form this morning....After less
than 48 hours, we have 'orphan' appservers (initiated, but no longer
showing in Windows Task Manager), appservers are maxxed-out at our
configured limit of 30 (and, climbing), with no end to this madness in
sight ! Sending log files to Progress and Epicor is somewhat akin to
spitting in the ocean, it seems. We feel more than a little be 'at
our wits end'..... Suggestions from the Epicor help desk basically
boil down to 'upgrade to service pack .403B', which means we have to
upgrade our SQL-2000 environment first, so that's not quite so quick
to do.

We've had Epicor's best hardware guru looking at our system, no
problems found. He helped spec the system, by the way.

I think my next step is to mail-order one of those crystal amulets to
suspend over the server....

- Gary -

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"Gary Franks" <garyfr2003@...> wrote:

>
> Hi, Steven...thanks for staying around on this one...
>
> There is about a 1.5 hour difference in run time for MRP between 8&8
> and 1&1...no difference in stability.
>
> I think 180 for lock-wait-timeout = (180/60)=3 minutes, not 2 ?
>
> I don't think we're unique at all....although we use Service Connect
> to interface to our Gentran EDI Translator, rather than use the
> less-capable offerings from Epicor. Can't live without EDI..it's over
> 65% of our total business. Also can't use our DEV system in
> PRODuction, as it only has half the processing and memory capacity.
>
> We've done LOTS of work unloading/reloading the DB...no joy.
>
> Our only BPM's are two...and, both simply 'trigger' outbound EDI
> transactions.
>
> We do not see lock wait timeouts much at all anymore....just every few
> days, the system starts building lots of extra appservers all of a
> sudden, & crashes. Just about everything seems to point to some
> serious problem with Progress, & even the Progress folks seem to

agree.

>
> Early on, we did have server hardware (memory) problems, but no
> longer. I look at our HP diags console every morning, 7 days a week,
> & no longer see what we encountered (memory management would have
> trouble) months ago. It's been clean ever since.
>
> Earlier, Progress and Epicor both wanted to blame this on 'some sort
> of network problem, maybe DNS', but many nights of work by Microsoft
> have ruled that out...and, independently confirmed by a non-Microsoft
> consultant as well.
>
> Using a single network adapter...have tried both in this box, with
> identical results. We've even had the system board replaced more than
> once by HP, 'just in case'....still did not help at all.
>
> We've had HP bring in their 'environmental' experts, to do long-term
> monitoring of our server room power....it's clean...well-grounded...no
> troubles.
>
> We've spent so much time on this problem that our ownership and upper
> management are wondering just what their next avenue for relief might
> be if Epicor and/or Progress can't get it figured out. As the
> implementation project co-manager, and as our Corporate IT Mgr., my
> job and reputation are also on the line on this one....
>
> Thanks again for your thoughts ...... Gary
>
>
> --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,

"Stephen Edginton" <stephene@> wrote:

> >
> > Gary,
> >
> > With 8 & 8 for MRP what is the difference in run

time to

> > 1 and 1 (and stability if anything)
> >
> > 4) 8000 is the -s parameter this is stack size - your
> > locks are -lkwtmo 180 = 2 minutes - does it seem that locks are seen
> > before a failure?
> >
> > 7) that's not too good!
> >
> > 8) this is very strange - you must be doing something
> > different to a lot of other users........
> >
> >
> >
> > You mentioned before Service connect and that it has been moved to
> > process on another server.
> >
> > What kinds of workflows do you have configured - how often are these
> > being utilized.
> >
> > Have you tried pointing your workflows to your test environment or
> > disabling there process for a period of time?
> >
> > Do you utilize BPM much?
> >
> >
> >
> > What I find strange is that your stability is so poor - with a

default

> > install of vantage on SQL 2000 you run for less than 2 hours before
> > failure.
> >
> > Have you looked at trying to run against your development box for

all

> > users - to try and simulate the same issues in a different

environment?

> >
> > Maybe restore the database - switch DNS to point to your development
> > environment?
> >
> >
> >
> > Do you have the network adapters in the server teamed? Have you

ruled

> > out hardware at this stage?
> >
> >
> >
> > Regards,
> >
> > Stephen
> >
> >
> >
> > From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
Behalf

> > Of Gary Franks
> > Sent: 04 October 2007 05:14
> > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > Subject: [Vantage] Re: Vantage System Stability with SQL ?
> >
> >
> >
> > Hello, Stephen,
> >
> > 1.) No, we do not have the backflush process running at all right

now.

> > 2.) We haven't tried running MRP manually since we went live...it
> > always runs from the System Agent as a task.
> > 3.) We have experimented with the schedulers and processes quite a
> > lot, with Epicor's help....right now, I think we're at 8 & 8.
> > 4.) We do occasionally see locks referenced, & that's why our *.pf
> > file has a value of 8000, & our 'lock-wait-timeout' is currently set
> > at 3 minutes, I believe.
> > 5.) We seldom see invalid ID's/Passwords entries...it happens , but
> > not all that frequently.
> > 6.) Verbose logging is enabled, & we just installed fresh 'debug'
> > objects from progress that gives even more info in the ubroker log.
> > 7.) We've sent dozens of captured log files to Epicor when the

system

> > craters.....so far, the best of the developers appears stumped,

along

> > with the Progress support developers.
> > 8.) Interesting question on the appservers and resources. Initially,
> > we would see ALL appservers go into a SENDING state, & stay there.
> > After numerous 'tuning' sessions with the Vantage developer

connected

> > remotely, we no longer see that situation. Now, instead, we see
> > appserver PID's in Progress Explorer which are NOT showing up in
> > Windows Task Manager...this is a constant happening now. When the
> > number of appservers exceeds 30 (our configured maximum), each and
> > every one beyond 30 seems to be an 'orphan'...i.e...not in Task
> > Manager. If we don't catch the situation quickly enough, the number
> > continues to grow until all Virtual memory is consumed (i.e...the

hard

> > disk fills up) and/or we max out on database connections & even
> > Progress Explorer can't be started.
> > 9.) All users are set with a 15-minute timeout window on their

session.

> > 10.) Yes,after tuning, instead of crashing every 1-2 hours (!!), we
> > went to crashing around every 24-48 hours. Still not good,

obviously.

> > 11.) INitially, we were seeing quite a lot of SQL-timeout errors in
> > the log files. Decreasing the lock-wait-timeout value was a
> > 'shortcut' to allow those locks to be released early. Artificial,

but

> > something the developer from Epicor really wanted to do.
> > 12.) The -s parameter setting was one jointly recommended by

Microsoft

> > and Progress, to better match Microsoft's SQL 'standard' value. This
> > one was thought to be 'the magic bullet' for our woes....didn't turn
> > out that way, unfortunately.
> > 13.) We typically find that resources are being consumed by the
> > multiple instances of appservers that are spawned....sometimes to

the

> > extreme that it's almost impossible to get the Windows console

itself

> > to respond to the server keyboard for 5-10 minutes.
> >
> > Hope this answers your questions...greatly appreciate your time to
> > chat about this.
> >
> > Sincerely,
> > - Gary -
> >
> > --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

<mailto:vantage%40yahoogroups.com> ,

> > "Stephen Edginton" <stephene@> wrote:
> > >
> > > Just a few more questions
> > >
> > >
> > >
> > > Do you have the backflush process running?
> > >
> > > If so is it running along side MRP when it runs on a schedule?
> > >
> > >
> > >
> > > If you start the MRP task manually and not from a schedule do

you see

> > > any difference in the stability.
> > >
> > > Do you ever get failures in MRP running? What is the duration of

the

> > > process.
> > >
> > > Do you have multiple schedulers and multiple mrp processes in

the MRP

> > > task?
> > >
> > > Do you see any locks referenced or errors in the

mfgsys803.server log?

> > >
> > > Do you see invalid user ID or password just before a meltdown in

the

> > > server logs if not do you see any reference?
> > >
> > >
> > >
> > > I presume you have enabled verbose logging - when the system is
> > > exhausted of all resources is there any indication as to the
> > procedures
> > > that are being called prior - during?
> > >
> > > Does the Broker log identify these appservers instances (upto

149!)

> > that
> > > get spawned?
> > >
> > > Do you use session timeouts on the users?
> > >
> > >
> > >
> > > Regarding the .pf file have you found any more stability with the
> > > modifications that were made over the default .pf file?
> > >
> > > What was the reasoning for decreasing the lock wait timeout

parameter

> > -
> > > where you finding areas of the system locking repeatedly?
> > >
> > > Also regarding the -s parameter were you seeing stack overflow

errors,

> > > if so what procedures where causing these?
> > >
> > >
> > >
> > > When you look at the main appservers status - if you look at the

PID

> > of
> > > each of the appservers instances what is there status and if

monitored

> > > with
> > >
> > > Process explorer Are they processing / reading disk / taking up

more

> > and
> > > more resources?
> > >
> > > Do you find that resources are taken up because of the number of
> > > appservers instances that are started (to 149!)
> > >
> > > Or that single instances have taken up too much resource.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Stephen
> > >
> > >
> > >
> > > From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

<mailto:vantage%40yahoogroups.com>

> > [mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

<mailto:vantage%40yahoogroups.com>
] On

> > Behalf
> > > Of Gary Franks
> > > Sent: 03 October 2007 17:55
> > > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

<mailto:vantage%40yahoogroups.com>

> > > Subject: [Vantage] Re: Vantage System Stability with SQL ?
> > >
> > >
> > >
> > > Hi, Stephen.....I'll try to answer your questions in the order you
> > > posed them :
> > >
> > > 1.) Yes, the crashes happen just about the same way each time.

'Early

> > > Warning' is given by looking at the status of the main
> > > appserver....after MRP runs overnight. If I see anything above the
> > > initial value (currently 25), or approaching the configured max

value

> > > (currently 30), it's almost certain that we'll see a crash in

the next

> > > 24 hours or less (usually less).
> > > 2.) I think we have 46 'Office' Licenses for Vantage, and 38 MES
> > > licenses. When a crash happens, we are close to the maximum on
> > sessions.
> > > 3.) We are at 8.03.305F...considering upgrading to either .305H or
> > .403B
> > > 4.) Our DEV server is a separate box...no problems ever seen there
> > > because it's a lightly-used system.
> > > 5.) Right before a crash, the resources will suddenly drop down

on the

> > > server....very quickly in most cases.
> > > 6.) All other databases and appservers have been disabled for

months,

> > > since we've been having this stability issue.
> > > 7.) 25 initial appservers, 30 max....I've seen that value climb as
> > > high as 149 (!!!) before the quad-dual-core processor, running

Windows

> > > Server R2, latest service pack, 8GB ram, runs totally out of
> > > system-managed virtual memory & simply stops responding.
> > >
> > > 8.) MFGSYS.PF File : (heavily modified by Epicor
> > > Developers...especially the "-s 8000" parameter value !
> > > ======================================
> > > -Mm 1024 -mmax 65534 -Bt 2048 -s 8000 -yy 1970 -stsh 31 -inp 32000
> > > -tok 4000 -TB 31 -TM 32 -D 500 -l 1000
> > > -tmpbsize 8
> > > -lkwtmo 180
> > > -T C:\epicor\AppserverTempFiles
> > > -db f:\epicor\mfgsys803\db\mfgsyssh
> > > -db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> > > PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> > > -q
> > >
> > > #### 07/05/2007 - Raj - Added -tmpbsize 8, changed -T to point

to C:\

> > > drive
> > > #### Original settings before Raj changed it on 5/3/07
> > > #-Mm 1024 -mmax 4000 -Bt 200 -s 200 -yy 1970 -stsh 31 -inp 32000

-tok

> > > 4000 -lkwtmo 300
> > > #-T f:\epicor\mfgwrk803
> > > #-db f:\epicor\mfgsys803\db\mfgsyssh
> > > #-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> > > PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> > > # -q requires restart of appserver when you copy any new dotR code
> > > this includes patch.
> > >
> > > #### 08/16/2007 - Gary ... Changed -s parameter, above, to 8000

per

> > > S.Johanns
> > > #### Here is what is was before it was changed :
> > > #-Mm 1024 -mmax 65534 -Bt 2048 -s 4000 -yy 1970 -stsh 31 -inp

32000

> > > -tok 4000 -TB 31 -TM 32 -D 500 -l 1000
> > > #-tmpbsize 8
> > > #-lkwtmo 180
> > > #-T C:\epicor\AppserverTempFiles
> > > #-db f:\epicor\mfgsys803\db\mfgsyssh
> > > #-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> > > PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> > > #-q
> > > =============================================
> > > 9.) This server ONLY runs Vantage....nothing else, not even
> > > anti-virus. It has MS-SQL-2000 for the db, however.
> > >
> > > Thanks again for your interest.......Gary
> > >
> > > - In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

<mailto:vantage%40yahoogroups.com>

> > <mailto:vantage%40yahoogroups.com> ,
> > > "Stephen Edginton" <stephene@> wrote:
> > > >
> > > > Hi Gary,
> > > >
> > > > I presume the system crash's in the same manor each
> > > > time?
> > > >
> > > > How many Licenses do you have for vantage and when it
> > > > crashes if you look at maintain sessions - how many sessions are
> > > > displayed
> > > >
> > > > Also when patch level are you running
> > > >
> > > > Did you see any of this behavior in your test / piloting
> > > > environment?
> > > >
> > > > Prior to a failure what are the resources like on the
> > > > server.
> > > >
> > > > Do you have all other appservers instances (test train
> > > > pilot environments turned off?)
> > > >
> > > > You mentioned that the configured maximum gets exceeded
> > > > (what are your settings for initial start - minimum and

maximum for

> > > the
> > > > agents?)
> > > >
> > > > Please post your mfgsys.pf file - to detail the startup
> > > > parameters you have configured.
> > > >
> > > > Also provide an overview of the hardware the server is
> > > > utilizing (disk, CPU RAM)
> > > >
> > > > Does the server have any other roles other than vantage?
> > > >
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Stephen
> > > >
> > > >
> > > >
> > > > From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

<mailto:vantage%40yahoogroups.com>

> > <mailto:vantage%40yahoogroups.com>
> > > [mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

<mailto:vantage%40yahoogroups.com>

> > <mailto:vantage%40yahoogroups.com> ] On
> > > Behalf
> > > > Of Gary Franks
> > > > Sent: 02 October 2007 17:48
> > > > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>

<mailto:vantage%40yahoogroups.com>

> > <mailto:vantage%40yahoogroups.com>
> > > > Subject: [Vantage] Vantage System Stability with SQL ?
> > > >
> > > >
> > > >
> > > > Hello, all,
> > > >
> > > > I have to ask if anyone else might be having problems with

Vantage

> > > > v8.03.305x, when using the MSSQL-2000 database ? We went live in
> > late
> > > > April, & have not been able to keep our system from crashing for
> > > > longer than 8 days or so ! The number of Progress AppServers

tends

> > to
> > > > climb way beyond the configured maximum (30, right now), right
> > before
> > > > the system craters, we frequently see 'orphan' appservers

showing up

> > > > in Progress Explorer (but, no longer appearing in Windows Task
> > > > Manager), & despite some extreme efforts by both Epicor and

Progress

> > > > support, we've spent the last 4+ months (!!) fighting this

beast.

> > > >
> > > > When the system does crash, it tends to completely run the

system

> > out
> > > > of available virtual memory /hard disk space (with

system-managed

> > > > virtual memory). Pretty messy !!
> > > >
> > > > We are being advised to upgrade to Service pack .40x, but that

also

> > > > requires SQL-2005, which we don't yet have in place.
> > > >
> > > > Anyone else out there suffering as much as we appear to be ??
> > > >
> > > > Thanks in advance for any consolation & help you can offer.
> > > >
> > > > Best Regards,
> > > > - Gary -
> > > >
> > > >
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>

[Non-text portions of this message have been removed]

[system]

"As Epicor Turns...."

2 crashes in the last 48 hours; more debug objects from Progress, some
didn't work, & had to be rebuilt again; Progress says that the
'watchdog' process for instantiating and trimming appservers attempts
to kill a _proapsrv.exe instance...it fails...& then the watchdog
process itself is 'hung.' Additional attempts to build new, needed,
appservers after that point in time no longer are constrained by the
configured MAX setting, & can climb high enough to run the entire
server out of virtual memory ! The debug objects are only to FIND one
or more root-causes, they're not any closer to FIXing anything yet,
unfortunately.

Seems that the instability of appservers has been somewhat of a 'known
commodity' since sometime in MARCH of this year, according to some
other users who have been kind enough to write me privately.

Still struggling....
Gary

--- In vantage@yahoogroups.com, "Gary Franks" <garyfr2003@...> wrote:
>
> Well, our unstable system is true to form this morning....After less
> than 48 hours, we have 'orphan' appservers (initiated, but no longer
> showing in Windows Task Manager), appservers are maxxed-out at our
> configured limit of 30 (and, climbing), with no end to this madness in
> sight ! Sending log files to Progress and Epicor is somewhat akin to
> spitting in the ocean, it seems. We feel more than a little be 'at
> our wits end'..... Suggestions from the Epicor help desk basically
> boil down to 'upgrade to service pack .403B', which means we have to
> upgrade our SQL-2000 environment first, so that's not quite so quick
> to do.
>
> We've had Epicor's best hardware guru looking at our system, no
> problems found. He helped spec the system, by the way.
>
> I think my next step is to mail-order one of those crystal amulets to
> suspend over the server....
>
> - Gary -
>
> --- In vantage@yahoogroups.com, "Gary Franks" <garyfr2003@> wrote:
> >
> > Hi, Steven...thanks for staying around on this one...
> >
> > There is about a 1.5 hour difference in run time for MRP between 8&8
> > and 1&1...no difference in stability.
> >
> > I think 180 for lock-wait-timeout = (180/60)=3 minutes, not 2 ?
> >
> > I don't think we're unique at all....although we use Service Connect
> > to interface to our Gentran EDI Translator, rather than use the
> > less-capable offerings from Epicor. Can't live without EDI..it's over
> > 65% of our total business. Also can't use our DEV system in
> > PRODuction, as it only has half the processing and memory capacity.
> >
> > We've done LOTS of work unloading/reloading the DB...no joy.
> >
> > Our only BPM's are two...and, both simply 'trigger' outbound EDI
> > transactions.
> >
> > We do not see lock wait timeouts much at all anymore....just every few
> > days, the system starts building lots of extra appservers all of a
> > sudden, & crashes. Just about everything seems to point to some
> > serious problem with Progress, & even the Progress folks seem to
agree.
> >
> > Early on, we did have server hardware (memory) problems, but no
> > longer. I look at our HP diags console every morning, 7 days a week,
> > & no longer see what we encountered (memory management would have
> > trouble) months ago. It's been clean ever since.
> >
> > Earlier, Progress and Epicor both wanted to blame this on 'some sort
> > of network problem, maybe DNS', but many nights of work by Microsoft
> > have ruled that out...and, independently confirmed by a non-Microsoft
> > consultant as well.
> >
> > Using a single network adapter...have tried both in this box, with
> > identical results. We've even had the system board replaced more than
> > once by HP, 'just in case'....still did not help at all.
> >
> > We've had HP bring in their 'environmental' experts, to do long-term
> > monitoring of our server room power....it's clean...well-grounded...no
> > troubles.
> >
> > We've spent so much time on this problem that our ownership and upper
> > management are wondering just what their next avenue for relief might
> > be if Epicor and/or Progress can't get it figured out. As the
> > implementation project co-manager, and as our Corporate IT Mgr., my
> > job and reputation are also on the line on this one....
> >
> > Thanks again for your thoughts ...... Gary
> >
> >
> > --- In vantage@yahoogroups.com, "Stephen Edginton" <stephene@> wrote:
> > >
> > > Gary,
> > >
> > > With 8 & 8 for MRP what is the difference in run
> time to
> > > 1 and 1 (and stability if anything)
> > >
> > > 4) 8000 is the -s parameter this is stack size -
your
> > > locks are -lkwtmo 180 = 2 minutes - does it seem that locks are seen
> > > before a failure?
> > >
> > > 7) that's not too good!
> > >
> > > 8) this is very strange - you must be doing
something
> > > different to a lot of other users........
> > >
> > >
> > >
> > > You mentioned before Service connect and that it has been moved to
> > > process on another server.
> > >
> > > What kinds of workflows do you have configured - how often are these
> > > being utilized.
> > >
> > > Have you tried pointing your workflows to your test environment or
> > > disabling there process for a period of time?
> > >
> > > Do you utilize BPM much?
> > >
> > >
> > >
> > > What I find strange is that your stability is so poor - with a
default
> > > install of vantage on SQL 2000 you run for less than 2 hours before
> > > failure.
> > >
> > > Have you looked at trying to run against your development box
for all
> > > users - to try and simulate the same issues in a different
> environment?
> > >
> > > Maybe restore the database - switch DNS to point to your development
> > > environment?
> > >
> > >
> > >
> > > Do you have the network adapters in the server teamed? Have you
ruled
> > > out hardware at this stage?
> > >
> > >
> > >
> > > Regards,
> > >
> > > Stephen
> > >
> > >
> > >
> > > From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
> Behalf
> > > Of Gary Franks
> > > Sent: 04 October 2007 05:14
> > > To: vantage@yahoogroups.com
> > > Subject: [Vantage] Re: Vantage System Stability with SQL ?
> > >
> > >
> > >
> > > Hello, Stephen,
> > >
> > > 1.) No, we do not have the backflush process running at all
right now.
> > > 2.) We haven't tried running MRP manually since we went live...it
> > > always runs from the System Agent as a task.
> > > 3.) We have experimented with the schedulers and processes quite a
> > > lot, with Epicor's help....right now, I think we're at 8 & 8.
> > > 4.) We do occasionally see locks referenced, & that's why our *.pf
> > > file has a value of 8000, & our 'lock-wait-timeout' is currently set
> > > at 3 minutes, I believe.
> > > 5.) We seldom see invalid ID's/Passwords entries...it happens , but
> > > not all that frequently.
> > > 6.) Verbose logging is enabled, & we just installed fresh 'debug'
> > > objects from progress that gives even more info in the ubroker log.
> > > 7.) We've sent dozens of captured log files to Epicor when the
system
> > > craters.....so far, the best of the developers appears stumped,
along
> > > with the Progress support developers.
> > > 8.) Interesting question on the appservers and resources. Initially,
> > > we would see ALL appservers go into a SENDING state, & stay there.
> > > After numerous 'tuning' sessions with the Vantage developer
connected
> > > remotely, we no longer see that situation. Now, instead, we see
> > > appserver PID's in Progress Explorer which are NOT showing up in
> > > Windows Task Manager...this is a constant happening now. When the
> > > number of appservers exceeds 30 (our configured maximum), each and
> > > every one beyond 30 seems to be an 'orphan'...i.e...not in Task
> > > Manager. If we don't catch the situation quickly enough, the number
> > > continues to grow until all Virtual memory is consumed
(i.e...the hard
> > > disk fills up) and/or we max out on database connections & even
> > > Progress Explorer can't be started.
> > > 9.) All users are set with a 15-minute timeout window on their
> session.
> > > 10.) Yes,after tuning, instead of crashing every 1-2 hours (!!), we
> > > went to crashing around every 24-48 hours. Still not good,
obviously.
> > > 11.) INitially, we were seeing quite a lot of SQL-timeout errors in
> > > the log files. Decreasing the lock-wait-timeout value was a
> > > 'shortcut' to allow those locks to be released early.
Artificial, but
> > > something the developer from Epicor really wanted to do.
> > > 12.) The -s parameter setting was one jointly recommended by
Microsoft
> > > and Progress, to better match Microsoft's SQL 'standard' value. This
> > > one was thought to be 'the magic bullet' for our woes....didn't turn
> > > out that way, unfortunately.
> > > 13.) We typically find that resources are being consumed by the
> > > multiple instances of appservers that are spawned....sometimes
to the
> > > extreme that it's almost impossible to get the Windows console
itself
> > > to respond to the server keyboard for 5-10 minutes.
> > >
> > > Hope this answers your questions...greatly appreciate your time to
> > > chat about this.
> > >
> > > Sincerely,
> > > - Gary -
> > >
> > > --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
> > > "Stephen Edginton" <stephene@> wrote:
> > > >
> > > > Just a few more questions
> > > >
> > > >
> > > >
> > > > Do you have the backflush process running?
> > > >
> > > > If so is it running along side MRP when it runs on a schedule?
> > > >
> > > >
> > > >
> > > > If you start the MRP task manually and not from a schedule do
> you see
> > > > any difference in the stability.
> > > >
> > > > Do you ever get failures in MRP running? What is the duration
of the
> > > > process.
> > > >
> > > > Do you have multiple schedulers and multiple mrp processes in
> the MRP
> > > > task?
> > > >
> > > > Do you see any locks referenced or errors in the
> mfgsys803.server log?
> > > >
> > > > Do you see invalid user ID or password just before a meltdown
in the
> > > > server logs if not do you see any reference?
> > > >
> > > >
> > > >
> > > > I presume you have enabled verbose logging - when the system is
> > > > exhausted of all resources is there any indication as to the
> > > procedures
> > > > that are being called prior - during?
> > > >
> > > > Does the Broker log identify these appservers instances (upto
149!)
> > > that
> > > > get spawned?
> > > >
> > > > Do you use session timeouts on the users?
> > > >
> > > >
> > > >
> > > > Regarding the .pf file have you found any more stability with the
> > > > modifications that were made over the default .pf file?
> > > >
> > > > What was the reasoning for decreasing the lock wait timeout
> parameter
> > > -
> > > > where you finding areas of the system locking repeatedly?
> > > >
> > > > Also regarding the -s parameter were you seeing stack overflow
> errors,
> > > > if so what procedures where causing these?
> > > >
> > > >
> > > >
> > > > When you look at the main appservers status - if you look at
the PID
> > > of
> > > > each of the appservers instances what is there status and if
> monitored
> > > > with
> > > >
> > > > Process explorer Are they processing / reading disk / taking
up more
> > > and
> > > > more resources?
> > > >
> > > > Do you find that resources are taken up because of the number of
> > > > appservers instances that are started (to 149!)
> > > >
> > > > Or that single instances have taken up too much resource.
> > > >
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Stephen
> > > >
> > > >
> > > >
> > > > From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > > [mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> ] On
> > > Behalf
> > > > Of Gary Franks
> > > > Sent: 03 October 2007 17:55
> > > > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > > > Subject: [Vantage] Re: Vantage System Stability with SQL ?
> > > >
> > > >
> > > >
> > > > Hi, Stephen.....I'll try to answer your questions in the order you
> > > > posed them :
> > > >
> > > > 1.) Yes, the crashes happen just about the same way each time.
> 'Early
> > > > Warning' is given by looking at the status of the main
> > > > appserver....after MRP runs overnight. If I see anything above the
> > > > initial value (currently 25), or approaching the configured max
> value
> > > > (currently 30), it's almost certain that we'll see a crash in
> the next
> > > > 24 hours or less (usually less).
> > > > 2.) I think we have 46 'Office' Licenses for Vantage, and 38 MES
> > > > licenses. When a crash happens, we are close to the maximum on
> > > sessions.
> > > > 3.) We are at 8.03.305F...considering upgrading to either .305H or
> > > .403B
> > > > 4.) Our DEV server is a separate box...no problems ever seen there
> > > > because it's a lightly-used system.
> > > > 5.) Right before a crash, the resources will suddenly drop down
> on the
> > > > server....very quickly in most cases.
> > > > 6.) All other databases and appservers have been disabled for
> months,
> > > > since we've been having this stability issue.
> > > > 7.) 25 initial appservers, 30 max....I've seen that value climb as
> > > > high as 149 (!!!) before the quad-dual-core processor, running
> Windows
> > > > Server R2, latest service pack, 8GB ram, runs totally out of
> > > > system-managed virtual memory & simply stops responding.
> > > >
> > > > 8.) MFGSYS.PF File : (heavily modified by Epicor
> > > > Developers...especially the "-s 8000" parameter value !
> > > > ======================================
> > > > -Mm 1024 -mmax 65534 -Bt 2048 -s 8000 -yy 1970 -stsh 31 -inp 32000
> > > > -tok 4000 -TB 31 -TM 32 -D 500 -l 1000
> > > > -tmpbsize 8
> > > > -lkwtmo 180
> > > > -T C:\epicor\AppserverTempFiles
> > > > -db f:\epicor\mfgsys803\db\mfgsyssh
> > > > -db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> > > > PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> > > > -q
> > > >
> > > > #### 07/05/2007 - Raj - Added -tmpbsize 8, changed -T to point
> to C:\
> > > > drive
> > > > #### Original settings before Raj changed it on 5/3/07
> > > > #-Mm 1024 -mmax 4000 -Bt 200 -s 200 -yy 1970 -stsh 31 -inp 32000
> -tok
> > > > 4000 -lkwtmo 300
> > > > #-T f:\epicor\mfgwrk803
> > > > #-db f:\epicor\mfgsys803\db\mfgsyssh
> > > > #-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> > > > PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> > > > # -q requires restart of appserver when you copy any new dotR code
> > > > this includes patch.
> > > >
> > > > #### 08/16/2007 - Gary ... Changed -s parameter, above, to
8000 per
> > > > S.Johanns
> > > > #### Here is what is was before it was changed :
> > > > #-Mm 1024 -mmax 65534 -Bt 2048 -s 4000 -yy 1970 -stsh 31 -inp
32000
> > > > -tok 4000 -TB 31 -TM 32 -D 500 -l 1000
> > > > #-tmpbsize 8
> > > > #-lkwtmo 180
> > > > #-T C:\epicor\AppserverTempFiles
> > > > #-db f:\epicor\mfgsys803\db\mfgsyssh
> > > > #-db mfgsys803 -dt MSS -ld mfgsys -Dsrv
> > > > PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1
> > > > #-q
> > > > =============================================
> > > > 9.) This server ONLY runs Vantage....nothing else, not even
> > > > anti-virus. It has MS-SQL-2000 for the db, however.
> > > >
> > > > Thanks again for your interest.......Gary
> > > >
> > > > - In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > > <mailto:vantage%40yahoogroups.com> ,
> > > > "Stephen Edginton" <stephene@> wrote:
> > > > >
> > > > > Hi Gary,
> > > > >
> > > > > I presume the system crash's in the same manor each
> > > > > time?
> > > > >
> > > > > How many Licenses do you have for vantage and when it
> > > > > crashes if you look at maintain sessions - how many sessions are
> > > > > displayed
> > > > >
> > > > > Also when patch level are you running
> > > > >
> > > > > Did you see any of this behavior in your test / piloting
> > > > > environment?
> > > > >
> > > > > Prior to a failure what are the resources like on the
> > > > > server.
> > > > >
> > > > > Do you have all other appservers instances (test train
> > > > > pilot environments turned off?)
> > > > >
> > > > > You mentioned that the configured maximum gets exceeded
> > > > > (what are your settings for initial start - minimum and
> maximum for
> > > > the
> > > > > agents?)
> > > > >
> > > > > Please post your mfgsys.pf file - to detail the startup
> > > > > parameters you have configured.
> > > > >
> > > > > Also provide an overview of the hardware the server is
> > > > > utilizing (disk, CPU RAM)
> > > > >
> > > > > Does the server have any other roles other than vantage?
> > > > >
> > > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Stephen
> > > > >
> > > > >
> > > > >
> > > > > From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > > <mailto:vantage%40yahoogroups.com>
> > > > [mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > > <mailto:vantage%40yahoogroups.com> ] On
> > > > Behalf
> > > > > Of Gary Franks
> > > > > Sent: 02 October 2007 17:48
> > > > > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > > <mailto:vantage%40yahoogroups.com>
> > > > > Subject: [Vantage] Vantage System Stability with SQL ?
> > > > >
> > > > >
> > > > >
> > > > > Hello, all,
> > > > >
> > > > > I have to ask if anyone else might be having problems with
Vantage
> > > > > v8.03.305x, when using the MSSQL-2000 database ? We went live in
> > > late
> > > > > April, & have not been able to keep our system from crashing for
> > > > > longer than 8 days or so ! The number of Progress AppServers
tends
> > > to
> > > > > climb way beyond the configured maximum (30, right now), right
> > > before
> > > > > the system craters, we frequently see 'orphan' appservers
> showing up
> > > > > in Progress Explorer (but, no longer appearing in Windows Task
> > > > > Manager), & despite some extreme efforts by both Epicor and
> Progress
> > > > > support, we've spent the last 4+ months (!!) fighting this
beast.
> > > > >
> > > > > When the system does crash, it tends to completely run the
system
> > > out
> > > > > of available virtual memory /hard disk space (with
system-managed
> > > > > virtual memory). Pretty messy !!
> > > > >
> > > > > We are being advised to upgrade to Service pack .40x, but that
> also
> > > > > requires SQL-2005, which we don't yet have in place.
> > > > >
> > > > > Anyone else out there suffering as much as we appear to be ??
> > > > >
> > > > > Thanks in advance for any consolation & help you can offer.
> > > > >
> > > > > Best Regards,
> > > > > - Gary -
> > > > >
> > > > >
> > > > >
> > > > > [Non-text portions of this message have been removed]
> > > > >
> > > >
> > > >
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
>

[system]

Hello Gary, Are you still having this issue?

We were having a similar problem on Win64 with SQL 2005 64 bit. Our
app servers would just stop serving client requests. We would be
lucky to get 24 hours of system stability.

I applied the latest open edge patch 3. We are currently on
8.03.403C. This has helped the progress app servers stay stable for us.

The real down side for us is we purchased this system for 100
concurrent users and this (among other issues) technical glitch
completely halted our implementation. We have service and support,
pre-paid, and they did not even help us for 4 months. I feel lucky we
are not yet in production and completely regret purchasing vantage.

Tony

[system]

Check out Answerbook #8782MPS about setting the schema holder to read
only. Have you done this? We did last week and I think Vantage is a lot
more stable on SQL now.



Joe Luster

Network Administrator

Cold Jet, LLC

513-831-3211 ext. 308

513-831-1209 FAX





From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of tnewellar
Sent: Tuesday, March 04, 2008 5:28 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Vantage System Stability with SQL ?



Hello Gary, Are you still having this issue?

We were having a similar problem on Win64 with SQL 2005 64 bit. Our
app servers would just stop serving client requests. We would be
lucky to get 24 hours of system stability.

I applied the latest open edge patch 3. We are currently on
8.03.403C. This has helped the progress app servers stay stable for us.

The real down side for us is we purchased this system for 100
concurrent users and this (among other issues) technical glitch
completely halted our implementation. We have service and support,
pre-paid, and they did not even help us for 4 months. I feel lucky we
are not yet in production and completely regret purchasing vantage.

Tony





[Non-text portions of this message have been removed]

[system]

We had the same issue as well with 64-bit Win 2003 and 64-bit SQL
2005. We did not see this issue while testing Vantage. We went live
at the beginning of February. The problem did not really get bad
until the middle of February.

It took a couple of weeks to get an answer from Epicor. I had the
best luck with a technician from Monterrey Mexico. Upgrading to
OpenEdge 10.1 Sp3 Hotfix 7 seems to have fixed our stability
problems.

--- In vantage@yahoogroups.com, "tnewellar" <tonyn@...> wrote:
>
> Hello Gary, Are you still having this issue?
>
> We were having a similar problem on Win64 with SQL 2005 64 bit. Our
> app servers would just stop serving client requests. We would be
> lucky to get 24 hours of system stability.
>
> I applied the latest open edge patch 3. We are currently on
> 8.03.403C. This has helped the progress app servers stay stable
for us.
>
> The real down side for us is we purchased this system for 100
> concurrent users and this (among other issues) technical glitch
> completely halted our implementation. We have service and support,
> pre-paid, and they did not even help us for 4 months. I feel lucky
we
> are not yet in production and completely regret purchasing vantage.
>
> Tony
>