MRP Crash - (CLOSED-RESOLVED)

Brian,
The problem was that our MRP regeneration runs would either crash or hang.
I don't know what the nullfixer routine does as nobody really explained it
but it apparently worked because we have run MRP successfully several
times now.
Dale.





Dale Walker
Director, Information Technology
Le Sueur Incorporated

507-665-6204 ext 277
www.lesueurinc.com


[Non-text portions of this message have been removed]
We are in the middle of a 3-day simulation and are in the ditch.
We are newbees and Epicor support has failed us once again.

We ran MRP late yesterday afternoon an it crashed with some archaic
error message. I called support first thing this morning, waited over
an hour and didn't hear back. I then called with a system down
condition since our simulation exercise cannot proceed without MRP
being completed. They wanted me to send log files and gave me the
folder and file names to send (which were the wrong ones by the
way...)

Anyway...we were told to re-run it again. We restarted it and it is
hung up. We updated the call asking for an expedited response and
have heard nothing. It is now 1:00 and we are still dead in the
water.

Can anyone here help?
We can see the "next part number" to process in the system monitor
and it is not changing.
What should we look for?
thx,
Dale.
What version are you on and are you a SQL customer?



-----Original Message-----
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of dswmaom
Sent: Tuesday, December 09, 2008 1:51 PM
To: vantage@yahoogroups.com
Subject: [Vantage] MRP Crash

We are in the middle of a 3-day simulation and are in the ditch.
We are newbees and Epicor support has failed us once again.

We ran MRP late yesterday afternoon an it crashed with some archaic
error message. I called support first thing this morning, waited over
an hour and didn't hear back. I then called with a system down
condition since our simulation exercise cannot proceed without MRP
being completed. They wanted me to send log files and gave me the
folder and file names to send (which were the wrong ones by the
way...)

Anyway...we were told to re-run it again. We restarted it and it is
hung up. We updated the call asking for an expedited response and
have heard nothing. It is now 1:00 and we are still dead in the
water.

Can anyone here help?
We can see the "next part number" to process in the system monitor
and it is not changing.
What should we look for?
thx,
Dale.



------------------------------------

Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
have already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder
and Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
8.03.406
SQL




Dale Walker
Director, Information Technology
Le Sueur Incorporated

507-665-6204 ext 277
www.lesueurinc.com




"Vic Drecchio" <Vic.Drecchio@...>
12/09/2008 12:51 PM

To
<vantage@yahoogroups.com>
cc
<dwalker@...>
Subject
RE: [Vantage] MRP Crash






What version are you on and are you a SQL customer?



-----Original Message-----
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of dswmaom
Sent: Tuesday, December 09, 2008 1:51 PM
To: vantage@yahoogroups.com
Subject: [Vantage] MRP Crash

We are in the middle of a 3-day simulation and are in the ditch.
We are newbees and Epicor support has failed us once again.

We ran MRP late yesterday afternoon an it crashed with some archaic
error message. I called support first thing this morning, waited over
an hour and didn't hear back. I then called with a system down
condition since our simulation exercise cannot proceed without MRP
being completed. They wanted me to send log files and gave me the
folder and file names to send (which were the wrong ones by the
way...)

Anyway...we were told to re-run it again. We restarted it and it is
hung up. We updated the call asking for an expedited response and
have heard nothing. It is now 1:00 and we are still dead in the
water.

Can anyone here help?
We can see the "next part number" to process in the system monitor
and it is not changing.
What should we look for?
thx,
Dale.



------------------------------------

Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
have already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder
and Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links






[Non-text portions of this message have been removed]
You may be experiencing record locking.

We are also a SQL customer and recently had similar issues.

Make sure you run MRP with only one process.

Also, if you haven't already, I *highly* recommend you run through
Epicor's SQL Tuning support doc (pasted below). It resolved all of our
record locking issues. Knock on wood, MRP has never frozen since.
Below is the document Epicor sent to me.

Also, run the SQL script attached. It changes some indexes to
non-clustered.

I went through each step below and now we're set.

Good luck.



--------------------------------------------------

Summary: PERF Performance Tuning for an SQL DB

Book: Support Solutions

Page: 8723MPS



XA803



FURTHER INFORMATION: An SQL database does not use most of the Progress

settings, so the performance tuning that can be done is limited.



This document is for an SQL databases only.



Remember that Epicor recommends having one server for Vantage alone.



RECOMMENDATIONS:

A. The mfgsys.pf file. This file is the parameter file for the Vantage

database. For an SQL database, it controls the client connection to the

database. The first line of that file should have the following

settings:

OE 10.0B:

-Mm 1024 -mmax 65534 -Bt 1024 -s 8000 -yy 1970 -stsh 31 -inp 32000 -tok

4000 -TB 31 -TM 32 -D 500 -l 1000

OE 10.1B:

-Mm 1024 -mmax 65534 -Bt 1024 -s 8000 -yy 1970 -stsh 31 -inp 32000 -tok

4000 -TB 31 -TM 32 -D 500 -l 1000 -ttmarshal 5



If any are missing, they can be added in. Changes will not take effect

until the AppServers and database are stopped and started in the

Progress Explorer Tool.



B. There may be a problem with AppServers trimming when they are no

longer needed. Any unused AppServers will hang, and not be available

for future processes that need them. This problem has been addressed in

the most recent Open Edge service packs: OE 10.1B0307 (and higher) or

OE 10.0B0546 (and higher).



If these service packs cannot be applied immediately, configure the

AppServer to not trim any unused AppServers. That will prevent any from

hanging and leave them available for future processes, but will use more

server resources with them open. Use the following procedure to set

this up:

1. Go the Vantage/Vista server.

2. Go to Start->Programs->Open Edge 10.1B->Progress Explorer Tool.

3. Expand the AppServer folder to MfgSys803.

4. Right-click on MfgSys803 and choose Properties.

5. Expand Agent and highlight Pool Range.

6. Change the Initial, Minimum, and Maximum to the same value. Some

experimentation may be necessary to get the correct value.

7. Click OK to save the changes.

8. These changes will not take effect until the AppServers are stopped

and restarted in the Progress Explorer Tool. Stop the AppServers, then

start the AppServers in the Progress Explorer Tool.

NOTE: This step will address performance problems caused by failure to

trim servers. But the increased number of AppServers will use more RAM

on the server. Things may run slower, but there will be less failures

to connect. Open Edge 10.1B03 hot fix 7 and higher (or OE 10.1B05

hotfix 46 or higher) address this problem. After this Open Edge patch

is installed, these Pool Range settings should be set back to their

original values.



C. Some setting for the schema holder in the Progress Explorer Tool can

be adjusted. These settings will vary depending on server resources,

database size, and the number of users. These changes will not take

effect until the DB is stopped and restarted in the Progress Explorer

Tool. Stop the AppServers, then stop the database. Start database,

then start the AppServers for this database in the Progress Explorer

Tool. NOTE: This step will not have any effect if step D (below) is

implemented.



1. # Blocks in DB Buffer. The number of data blocks that will

be loaded into memory when the database is started. With an SQL

database, this value is not used, so it can be set very low. Steps for

changing the #Blocks in DB Buffer:

A. Go the Vantage/Vista server.

B. Go to Start->Programs->Open Edge 10.1B->Progress Explorer Tool.

C. Expand the Database folder to MfgSys803, to Configurations, to

DefaultConfiguration.

D. Right-click on DefaultConfiguration and choose Properties.

E. Change the # Blocks in DB Buffer to 10000. That is all that is

needed for the Progress schema holder.

F. Click OK to save the changes.



2. # Lock Table Entries. The number of record locks made to

the data at any given time. This number can be quite large when running

processes like MRP. Some performance problems result from too many

records being accessed at a given time. The error "Lock table overflow,

increase -L on server (915)" may occur in this case. This can be

addressed by increasing the # Lock Table Entries in the Progress

Explorer Tool:

A. Go the Vantage/Vista server.

B. Go to Start->Programs->Open Edge 10.1B->Progress Explorer Tool.

C. Expand the Database folder to MfgSys803, to Configurations, to

DefaultConfiguration.

D. Right-click on DefaultConfiguration and choose Properties.

E. Increase the # Lock Table Entries.

F. Increase that number to 409600 or higher. A multiple of 8192 is

recommended by Progress.

G. Click OK to save the changes.



3. Spin Locks. The number of times a process tries to acquire

a latch before pausing. If the process cannot acquire the resource's

latch, it continues the attempt. This iterative process is called

spinning. Use the following steps to adjust the Spin Locks:

A. Go the Vantage/Vista server.

B. Go to Start->Programs->Open Edge 10.1B->Progress Explorer Tool.

C. Expand the Database folder to MfgSys803, to Configurations, to

DefaultConfiguration.

D. Right-click on DefaultConfiguration and choose Properties.

E. Go to the Advanced section.

F. Increase Spin Locks Retries. Progress recommends 20000 per

processor. So, dual/dual core CPU should be set to 80000.

G. Click OK to save the changes.



4. Background Writers. For an SQL database, these processes

are not used in the Progress Explorer Tool. Shutting them down will

free up some of the server's resources:

A. Go the Vantage/Vista server.

B. Go to Start->Programs->Open Edge 10.1B->Progress Explorer Tool.

C. Expand the Database folder to MfgSys803, to Configurations, to

DefaultConfiguration.

D. Right-click on DefaultConfiguration and choose Properties.

E. Go to the Background Writers section.

F. Set the # APW's to start to 0.

G. Uncheck the Auto startup check boxes for the Before-image writer and

After-image writer.

H. Click OK to save the changes.



D. The schema holders for the database can be set to read-only. This

may help with client performance. This should not be done if there are

third party products connecting to the Vantage DB. See document 8782MPS

for details. If there are third party products, contact Support.



E There is an SQL indexing script that can be run. The script changes

the Progress_recid index of tables to be non-clustered. This will help

improve performance, in cases of locking, poor performance, or MRP

issues. See document 8927MPS for details. If there are any questions

about this document, contact Support.



F. AppServers can be set to see which client PC is causing a problem.

This requires replacing one file on the server. AppServers will then

track the client PC name. See document 8973MPS (for V8.03.305) or

8974MPS (for V8.03.403) for details.



G. Permissions on the Vantage server. Epicor recommends both the

\Epicor folder and the \Mfgsysdata folders be shared full control, for

everyone.



H. Hardware. Microsoft SQL is self-tuning by default. If more

hardware resources are added to the Vantage server, SQL will

automatically tune itself for the new hardware.



I. Documents and Settings (DNS) Version Tracking. Customers

experiencing workstation problems (lockups and display issues) should do

the following:

1. At the workstation, get out of Vantage.

2. Right mouse click the Windows [Start] button, select Explorer.

3. Go to C:\Documents and Settings\All Users\Application

Data\Epicor\Vantage or Vista

4. Delete ALL of the Versional folders below the Vista or Vantage

folder.

5. Log back into Vista\Vantage.



J. Hyperthreading should not be enabled if SQL is installed. In most

cases, SQL2005 will not install. See page 7663MPS for how to turn off

Hyperthreading.



K. Business Activity Query and SQL Issues

SQL function syntax is stricter than Progress syntax. If you previously

ran the application using a Progress

database but now have moved to SQL, you may experience these syntax

issues.



The main issue is that you can use abbreviations within Progress; for

example, ABSOLUTE can be abbreviated to ABS, ABSO, or ABSOL within

Progress. BAQ formulas are directly sent to SQL. As long as these

formulas do not contain any abbreviations, they work as expected.

However if a formula references an abbreviation, syntax issues occur.



The following table displays the functions which are not identical

between Progress and SQL. The characters contained between the

parentheses are optional characters in Progress.



Progress SQL (Before Translation)

SQL (After Translation)

ABS(OLUTE) ABS

abs

ASC(II) ASC

ascii

INT(EGER) INTEGER

convert

MAX(IMUM) MAXIMUM

dbo.maximum (user-defined function)

MIN(IMUM) MINIMUM

dbo.minimum (user-defined function)



L. Check External Company Maintenance. If there are External Companies

setup that are not being used, those may cause a problem. If an

External Company is not being used, it should be deleted. NOTE: It is

*vitally* important that External Companies being used are *not*

deleted.



M. Full Text Cataloging Set to Track Changes. In SQL Server 2005, if

the tracking option is set to automatic, it can cause performance issues

such as locking and speed degradation. This is a known Microsoft issue

and will be addressed in SQL Server 2008. See page 9494MPS for more

details.



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

This is kind of painful, but it may help. Run MRP again, with logging, and have it log MRP and scheduling. When it's done open up the basic log - I use a name like "MRPTestA", changing the letter each time I run it on a given day [I'm about where you are, so I'm doing it repeatedly today]. Then scroll down until you find the long lines of text. [It's a big file, but most of the lines are pretty short, so you don't actually have to read each one closely, which lets this be reasonably quick.] In there you should find at least a hint of the problem. The one I've had more than once is a routing resource problem, as I have more than one plant, and MRP gags on a routing that uses resources from a different plant. The Engineering Workbench doesn't prevent you from making this error, either.

Or, at the moment, I'm trying to find the 'missing revision for subassembly' problem. Naturally, the log doesn't tell me WHICH assembly is missing a valid revision.

Can you call your consultant vice Epicor?

Good luck.

Lynn Thomas
Senior Engineer
SAIC
317-357-4041 X255



[Non-text portions of this message have been removed]
I¹ll confirm this as well. We had issues in .405 with MRP hanging. I ran
the performance tuning suggestions, particularly making the schema holder
read-only and changing the indexes to non-clustered, and MRP has (knock on
formica) been rock solid ever since.

This takes an hour or so to get working. I screwed up the .pf file
settings the first couple of times as the settings are a little subtle.

-bws


On 12/9/08 11:08 AM, "Vic Drecchio" <vic.drecchio@...> wrote:
>
>
> You may be experiencing record locking.
>
> We are also a SQL customer and recently had similar issues.
>
> Make sure you run MRP with only one process.
>
> Also, if you haven't already, I *highly* recommend you run through
> Epicor's SQL Tuning support doc (pasted below). It resolved all of our
> record locking issues. Knock on wood, MRP has never frozen since.
> Below is the document Epicor sent to me.
>
> Also, run the SQL script attached. It changes some indexes to
> non-clustered.
>
> I went through each step below and now we're set.
>
>
>
>
> .
>
>



[Non-text portions of this message have been removed]
I would suggest to first upgrade to 406A. I don't know of any specific issues with MRP, but in general 406 was buggy and after we went to 406A most of the bugs went away (although there were some new ones that showed up). This may help or it may not.


________________________________
From: "dwalker@..." <dwalker@...>
To: Vic Drecchio <Vic.Drecchio@...>
Cc: vantage@yahoogroups.com
Sent: Tuesday, December 9, 2008 1:54:42 PM
Subject: RE: [Vantage] MRP Crash


8.03.406
SQL

Dale Walker
Director, Information Technology
Le Sueur Incorporated

507-665-6204 ext 277
www.lesueurinc. com

"Vic Drecchio" <Vic.Drecchio@ TIMCO.aero>
12/09/2008 12:51 PM

To
<vantage@yahoogroups .com>
cc
<dwalker@lesueurinc. com>
Subject
RE: [Vantage] MRP Crash

What version are you on and are you a SQL customer?

-----Original Message-----
From: vantage@yahoogroups .com [mailto:vantage@yahoogroups .com] On Behalf
Of dswmaom
Sent: Tuesday, December 09, 2008 1:51 PM
To: vantage@yahoogroups .com
Subject: [Vantage] MRP Crash

We are in the middle of a 3-day simulation and are in the ditch.
We are newbees and Epicor support has failed us once again.

We ran MRP late yesterday afternoon an it crashed with some archaic
error message. I called support first thing this morning, waited over
an hour and didn't hear back. I then called with a system down
condition since our simulation exercise cannot proceed without MRP
being completed. They wanted me to send log files and gave me the
folder and file names to send (which were the wrong ones by the
way...)

Anyway...we were told to re-run it again. We restarted it and it is
hung up. We updated the call asking for an expedited response and
have heard nothing. It is now 1:00 and we are still dead in the
water.

Can anyone here help?
We can see the "next part number" to process in the system monitor
and it is not changing.
What should we look for?
thx,
Dale.


------------ --------- --------- ------

Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
have already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder
and Crystal Reports and other 'goodies', please goto:
http://groups. yahoo.com/ group/vantage/ files/.
(2) To search through old msg's goto:
http://groups. yahoo.com/ group/vantage/ messages
(3) To view links to Vendors that provide Vantage services goto:
http://groups. yahoo.com/ group/vantage/ linksYahoo! Groups Links

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






[Non-text portions of this message have been removed]
Also, in the .pf file you will want to make this change:

Original:
-Dsrv PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1,ZPRGRS_UPDLOCK_HINT,0

Change to:

-Dsrv
PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1,PRGRS_NATIVE_LOCKWAIT,32000

Also, if anyone else is already using the PRGRS_NATIVE_LOCKWAIT then make
sure you drop the number down to 32000 or less, Epicor reccomends 30000,
having it any more than that can cause the system to run in a loop forever,
never timing out at all since anything above 32000+change(I forget the exact
number) is not able to be processed so it assume it is 0, which means it
never times out. Many sites were set to 60000 upon installation, which is
why there may be a need for a change to anyone who is currently installed.


----- Original Message -----
From: "Vic Drecchio" <vic.drecchio@...>
To: <vantage@yahoogroups.com>
Cc: <dwalker@...>
Sent: Tuesday, December 09, 2008 2:08 PM
Subject: RE: [Vantage] MRP Crash


> You may be experiencing record locking.
>
> We are also a SQL customer and recently had similar issues.
>
> Make sure you run MRP with only one process.
>
> Also, if you haven't already, I *highly* recommend you run through
> Epicor's SQL Tuning support doc (pasted below). It resolved all of our
> record locking issues. Knock on wood, MRP has never frozen since.
> Below is the document Epicor sent to me.
>
> Also, run the SQL script attached. It changes some indexes to
> non-clustered.
>
> I went through each step below and now we're set.
>
> Good luck.
>
>
>
> --------------------------------------------------
>
> Summary: PERF Performance Tuning for an SQL DB
>
> Book: Support Solutions
>
> Page: 8723MPS
>
>
>
> XA803
>
>
>
> FURTHER INFORMATION: An SQL database does not use most of the Progress
>
> settings, so the performance tuning that can be done is limited.
>
>
>
> This document is for an SQL databases only.
>
>
>
> Remember that Epicor recommends having one server for Vantage alone.
>
>
>
> RECOMMENDATIONS:
>
> A. The mfgsys.pf file. This file is the parameter file for the Vantage
>
> database. For an SQL database, it controls the client connection to the
>
> database. The first line of that file should have the following
>
> settings:
>
> OE 10.0B:
>
> -Mm 1024 -mmax 65534 -Bt 1024 -s 8000 -yy 1970 -stsh 31 -inp 32000 -tok
>
> 4000 -TB 31 -TM 32 -D 500 -l 1000
>
> OE 10.1B:
>
> -Mm 1024 -mmax 65534 -Bt 1024 -s 8000 -yy 1970 -stsh 31 -inp 32000 -tok
>
> 4000 -TB 31 -TM 32 -D 500 -l 1000 -ttmarshal 5
>
>
>
> If any are missing, they can be added in. Changes will not take effect
>
> until the AppServers and database are stopped and started in the
>
> Progress Explorer Tool.
>
>
>
> B. There may be a problem with AppServers trimming when they are no
>
> longer needed. Any unused AppServers will hang, and not be available
>
> for future processes that need them. This problem has been addressed in
>
> the most recent Open Edge service packs: OE 10.1B0307 (and higher) or
>
> OE 10.0B0546 (and higher).
>
>
>
> If these service packs cannot be applied immediately, configure the
>
> AppServer to not trim any unused AppServers. That will prevent any from
>
> hanging and leave them available for future processes, but will use more
>
> server resources with them open. Use the following procedure to set
>
> this up:
>
> 1. Go the Vantage/Vista server.
>
> 2. Go to Start->Programs->Open Edge 10.1B->Progress Explorer Tool.
>
> 3. Expand the AppServer folder to MfgSys803.
>
> 4. Right-click on MfgSys803 and choose Properties.
>
> 5. Expand Agent and highlight Pool Range.
>
> 6. Change the Initial, Minimum, and Maximum to the same value. Some
>
> experimentation may be necessary to get the correct value.
>
> 7. Click OK to save the changes.
>
> 8. These changes will not take effect until the AppServers are stopped
>
> and restarted in the Progress Explorer Tool. Stop the AppServers, then
>
> start the AppServers in the Progress Explorer Tool.
>
> NOTE: This step will address performance problems caused by failure to
>
> trim servers. But the increased number of AppServers will use more RAM
>
> on the server. Things may run slower, but there will be less failures
>
> to connect. Open Edge 10.1B03 hot fix 7 and higher (or OE 10.1B05
>
> hotfix 46 or higher) address this problem. After this Open Edge patch
>
> is installed, these Pool Range settings should be set back to their
>
> original values.
>
>
>
> C. Some setting for the schema holder in the Progress Explorer Tool can
>
> be adjusted. These settings will vary depending on server resources,
>
> database size, and the number of users. These changes will not take
>
> effect until the DB is stopped and restarted in the Progress Explorer
>
> Tool. Stop the AppServers, then stop the database. Start database,
>
> then start the AppServers for this database in the Progress Explorer
>
> Tool. NOTE: This step will not have any effect if step D (below) is
>
> implemented.
>
>
>
> 1. # Blocks in DB Buffer. The number of data blocks that will
>
> be loaded into memory when the database is started. With an SQL
>
> database, this value is not used, so it can be set very low. Steps for
>
> changing the #Blocks in DB Buffer:
>
> A. Go the Vantage/Vista server.
>
> B. Go to Start->Programs->Open Edge 10.1B->Progress Explorer Tool.
>
> C. Expand the Database folder to MfgSys803, to Configurations, to
>
> DefaultConfiguration.
>
> D. Right-click on DefaultConfiguration and choose Properties.
>
> E. Change the # Blocks in DB Buffer to 10000. That is all that is
>
> needed for the Progress schema holder.
>
> F. Click OK to save the changes.
>
>
>
> 2. # Lock Table Entries. The number of record locks made to
>
> the data at any given time. This number can be quite large when running
>
> processes like MRP. Some performance problems result from too many
>
> records being accessed at a given time. The error "Lock table overflow,
>
> increase -L on server (915)" may occur in this case. This can be
>
> addressed by increasing the # Lock Table Entries in the Progress
>
> Explorer Tool:
>
> A. Go the Vantage/Vista server.
>
> B. Go to Start->Programs->Open Edge 10.1B->Progress Explorer Tool.
>
> C. Expand the Database folder to MfgSys803, to Configurations, to
>
> DefaultConfiguration.
>
> D. Right-click on DefaultConfiguration and choose Properties.
>
> E. Increase the # Lock Table Entries.
>
> F. Increase that number to 409600 or higher. A multiple of 8192 is
>
> recommended by Progress.
>
> G. Click OK to save the changes.
>
>
>
> 3. Spin Locks. The number of times a process tries to acquire
>
> a latch before pausing. If the process cannot acquire the resource's
>
> latch, it continues the attempt. This iterative process is called
>
> spinning. Use the following steps to adjust the Spin Locks:
>
> A. Go the Vantage/Vista server.
>
> B. Go to Start->Programs->Open Edge 10.1B->Progress Explorer Tool.
>
> C. Expand the Database folder to MfgSys803, to Configurations, to
>
> DefaultConfiguration.
>
> D. Right-click on DefaultConfiguration and choose Properties.
>
> E. Go to the Advanced section.
>
> F. Increase Spin Locks Retries. Progress recommends 20000 per
>
> processor. So, dual/dual core CPU should be set to 80000.
>
> G. Click OK to save the changes.
>
>
>
> 4. Background Writers. For an SQL database, these processes
>
> are not used in the Progress Explorer Tool. Shutting them down will
>
> free up some of the server's resources:
>
> A. Go the Vantage/Vista server.
>
> B. Go to Start->Programs->Open Edge 10.1B->Progress Explorer Tool.
>
> C. Expand the Database folder to MfgSys803, to Configurations, to
>
> DefaultConfiguration.
>
> D. Right-click on DefaultConfiguration and choose Properties.
>
> E. Go to the Background Writers section.
>
> F. Set the # APW's to start to 0.
>
> G. Uncheck the Auto startup check boxes for the Before-image writer and
>
> After-image writer.
>
> H. Click OK to save the changes.
>
>
>
> D. The schema holders for the database can be set to read-only. This
>
> may help with client performance. This should not be done if there are
>
> third party products connecting to the Vantage DB. See document 8782MPS
>
> for details. If there are third party products, contact Support.
>
>
>
> E There is an SQL indexing script that can be run. The script changes
>
> the Progress_recid index of tables to be non-clustered. This will help
>
> improve performance, in cases of locking, poor performance, or MRP
>
> issues. See document 8927MPS for details. If there are any questions
>
> about this document, contact Support.
>
>
>
> F. AppServers can be set to see which client PC is causing a problem.
>
> This requires replacing one file on the server. AppServers will then
>
> track the client PC name. See document 8973MPS (for V8.03.305) or
>
> 8974MPS (for V8.03.403) for details.
>
>
>
> G. Permissions on the Vantage server. Epicor recommends both the
>
> \Epicor folder and the \Mfgsysdata folders be shared full control, for
>
> everyone.
>
>
>
> H. Hardware. Microsoft SQL is self-tuning by default. If more
>
> hardware resources are added to the Vantage server, SQL will
>
> automatically tune itself for the new hardware.
>
>
>
> I. Documents and Settings (DNS) Version Tracking. Customers
>
> experiencing workstation problems (lockups and display issues) should do
>
> the following:
>
> 1. At the workstation, get out of Vantage.
>
> 2. Right mouse click the Windows [Start] button, select Explorer.
>
> 3. Go to C:\Documents and Settings\All Users\Application
>
> Data\Epicor\Vantage or Vista
>
> 4. Delete ALL of the Versional folders below the Vista or Vantage
>
> folder.
>
> 5. Log back into Vista\Vantage.
>
>
>
> J. Hyperthreading should not be enabled if SQL is installed. In most
>
> cases, SQL2005 will not install. See page 7663MPS for how to turn off
>
> Hyperthreading.
>
>
>
> K. Business Activity Query and SQL Issues
>
> SQL function syntax is stricter than Progress syntax. If you previously
>
> ran the application using a Progress
>
> database but now have moved to SQL, you may experience these syntax
>
> issues.
>
>
>
> The main issue is that you can use abbreviations within Progress; for
>
> example, ABSOLUTE can be abbreviated to ABS, ABSO, or ABSOL within
>
> Progress. BAQ formulas are directly sent to SQL. As long as these
>
> formulas do not contain any abbreviations, they work as expected.
>
> However if a formula references an abbreviation, syntax issues occur.
>
>
>
> The following table displays the functions which are not identical
>
> between Progress and SQL. The characters contained between the
>
> parentheses are optional characters in Progress.
>
>
>
> Progress SQL (Before Translation)
>
> SQL (After Translation)
>
> ABS(OLUTE) ABS
>
> abs
>
> ASC(II) ASC
>
> ascii
>
> INT(EGER) INTEGER
>
> convert
>
> MAX(IMUM) MAXIMUM
>
> dbo.maximum (user-defined function)
>
> MIN(IMUM) MINIMUM
>
> dbo.minimum (user-defined function)
>
>
>
> L. Check External Company Maintenance. If there are External Companies
>
> setup that are not being used, those may cause a problem. If an
>
> External Company is not being used, it should be deleted. NOTE: It is
>
> *vitally* important that External Companies being used are *not*
>
> deleted.
>
>
>
> M. Full Text Cataloging Set to Track Changes. In SQL Server 2005, if
>
> the tracking option is set to automatic, it can cause performance issues
>
> such as locking and speed degradation. This is a known Microsoft issue
>
> and will be addressed in SQL Server 2008. See page 9494MPS for more
>
> details.
>
>
>
> [Non-text portions of this message have been removed]
>
>
> ------------------------------------
>
> Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
> have already linked your email address to a yahoo id to enable access. )
> (1) To access the Files Section of our Yahoo!Group for Report Builder and
> Crystal Reports and other 'goodies', please goto:
> http://groups.yahoo.com/group/vantage/files/.
> (2) To search through old msg's goto:
> http://groups.yahoo.com/group/vantage/messages
> (3) To view links to Vendors that provide Vantage services goto:
> http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
>
>
>
On behalf of Dale Walker (Originator of this thread)

Thanks to all who replied to this thread !

The problem was that we needed to run the nullfixer.r program against
the database.

I did learn alot from the SQL tuning doc and I made the SQL Tuning
modifications, hopefully they will give us the best performance going
forward.

Regards to all who contributed.

Neil

--- In vantage@yahoogroups.com, "Ned" <TechnoBabbly@...> wrote:
>
> Also, in the .pf file you will want to make this change:
>
> Original:
> -Dsrv
PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1,ZPRGRS_UPDLOCK_HINT,0
>
> Change to:
>
> -Dsrv
>
PRGRS_CONNECT,DSN=MFGSYS803,TXN_ISOLATION,1,PRGRS_NATIVE_LOCKWAIT,3200
0
>
> Also, if anyone else is already using the PRGRS_NATIVE_LOCKWAIT
then make
> sure you drop the number down to 32000 or less, Epicor reccomends
30000,
> having it any more than that can cause the system to run in a loop
forever,
> never timing out at all since anything above 32000+change(I forget
the exact
> number) is not able to be processed so it assume it is 0, which
means it
> never times out. Many sites were set to 60000 upon installation,
which is
> why there may be a need for a change to anyone who is currently
installed.
>
>
> ----- Original Message -----
> From: "Vic Drecchio" <vic.drecchio@...>
> To: <vantage@yahoogroups.com>
> Cc: <dwalker@...>
> Sent: Tuesday, December 09, 2008 2:08 PM
> Subject: RE: [Vantage] MRP Crash
>
>
> > You may be experiencing record locking.
> >
> > We are also a SQL customer and recently had similar issues.
> >
> > Make sure you run MRP with only one process.
> >
> > Also, if you haven't already, I *highly* recommend you run through
> > Epicor's SQL Tuning support doc (pasted below). It resolved all
of our
> > record locking issues. Knock on wood, MRP has never frozen since.
> > Below is the document Epicor sent to me.
> >
> > Also, run the SQL script attached. It changes some indexes to
> > non-clustered.
> >
> > I went through each step below and now we're set.
> >
> > Good luck.
> >
> >
> >
> > --------------------------------------------------
> >
> > Summary: PERF Performance Tuning for an SQL DB
> >
> > Book: Support Solutions
> >
> > Page: 8723MPS
> >
> >
> >
> > XA803
> >
> >
> >
> > FURTHER INFORMATION: An SQL database does not use most of the
Progress
> >
> > settings, so the performance tuning that can be done is limited.
> >
> >
> >
> > This document is for an SQL databases only.
> >
> >
> >
> > Remember that Epicor recommends having one server for Vantage
alone.
> >
> >
> >
> > RECOMMENDATIONS:
> >
> > A. The mfgsys.pf file. This file is the parameter file for the
Vantage
> >
> > database. For an SQL database, it controls the client connection
to the
> >
> > database. The first line of that file should have the following
> >
> > settings:
> >
> > OE 10.0B:
> >
> > -Mm 1024 -mmax 65534 -Bt 1024 -s 8000 -yy 1970 -stsh 31 -inp
32000 -tok
> >
> > 4000 -TB 31 -TM 32 -D 500 -l 1000
> >
> > OE 10.1B:
> >
> > -Mm 1024 -mmax 65534 -Bt 1024 -s 8000 -yy 1970 -stsh 31 -inp
32000 -tok
> >
> > 4000 -TB 31 -TM 32 -D 500 -l 1000 -ttmarshal 5
> >
> >
> >
> > If any are missing, they can be added in. Changes will not take
effect
> >
> > until the AppServers and database are stopped and started in the
> >
> > Progress Explorer Tool.
> >
> >
> >
> > B. There may be a problem with AppServers trimming when they are
no
> >
> > longer needed. Any unused AppServers will hang, and not be
available
> >
> > for future processes that need them. This problem has been
addressed in
> >
> > the most recent Open Edge service packs: OE 10.1B0307 (and
higher) or
> >
> > OE 10.0B0546 (and higher).
> >
> >
> >
> > If these service packs cannot be applied immediately, configure
the
> >
> > AppServer to not trim any unused AppServers. That will prevent
any from
> >
> > hanging and leave them available for future processes, but will
use more
> >
> > server resources with them open. Use the following procedure to
set
> >
> > this up:
> >
> > 1. Go the Vantage/Vista server.
> >
> > 2. Go to Start->Programs->Open Edge 10.1B->Progress Explorer
Tool.
> >
> > 3. Expand the AppServer folder to MfgSys803.
> >
> > 4. Right-click on MfgSys803 and choose Properties.
> >
> > 5. Expand Agent and highlight Pool Range.
> >
> > 6. Change the Initial, Minimum, and Maximum to the same value.
Some
> >
> > experimentation may be necessary to get the correct value.
> >
> > 7. Click OK to save the changes.
> >
> > 8. These changes will not take effect until the AppServers are
stopped
> >
> > and restarted in the Progress Explorer Tool. Stop the
AppServers, then
> >
> > start the AppServers in the Progress Explorer Tool.
> >
> > NOTE: This step will address performance problems caused by
failure to
> >
> > trim servers. But the increased number of AppServers will use
more RAM
> >
> > on the server. Things may run slower, but there will be less
failures
> >
> > to connect. Open Edge 10.1B03 hot fix 7 and higher (or OE 10.1B05
> >
> > hotfix 46 or higher) address this problem. After this Open Edge
patch
> >
> > is installed, these Pool Range settings should be set back to
their
> >
> > original values.
> >
> >
> >
> > C. Some setting for the schema holder in the Progress Explorer
Tool can
> >
> > be adjusted. These settings will vary depending on server
resources,
> >
> > database size, and the number of users. These changes will not
take
> >
> > effect until the DB is stopped and restarted in the Progress
Explorer
> >
> > Tool. Stop the AppServers, then stop the database. Start
database,
> >
> > then start the AppServers for this database in the Progress
Explorer
> >
> > Tool. NOTE: This step will not have any effect if step D
(below) is
> >
> > implemented.
> >
> >
> >
> > 1. # Blocks in DB Buffer. The number of data blocks that
will
> >
> > be loaded into memory when the database is started. With an SQL
> >
> > database, this value is not used, so it can be set very low.
Steps for
> >
> > changing the #Blocks in DB Buffer:
> >
> > A. Go the Vantage/Vista server.
> >
> > B. Go to Start->Programs->Open Edge 10.1B->Progress Explorer
Tool.
> >
> > C. Expand the Database folder to MfgSys803, to Configurations, to
> >
> > DefaultConfiguration.
> >
> > D. Right-click on DefaultConfiguration and choose Properties.
> >
> > E. Change the # Blocks in DB Buffer to 10000. That is all that
is
> >
> > needed for the Progress schema holder.
> >
> > F. Click OK to save the changes.
> >
> >
> >
> > 2. # Lock Table Entries. The number of record locks made to
> >
> > the data at any given time. This number can be quite large when
running
> >
> > processes like MRP. Some performance problems result from too
many
> >
> > records being accessed at a given time. The error "Lock table
overflow,
> >
> > increase -L on server (915)" may occur in this case. This can be
> >
> > addressed by increasing the # Lock Table Entries in the Progress
> >
> > Explorer Tool:
> >
> > A. Go the Vantage/Vista server.
> >
> > B. Go to Start->Programs->Open Edge 10.1B->Progress Explorer
Tool.
> >
> > C. Expand the Database folder to MfgSys803, to Configurations, to
> >
> > DefaultConfiguration.
> >
> > D. Right-click on DefaultConfiguration and choose Properties.
> >
> > E. Increase the # Lock Table Entries.
> >
> > F. Increase that number to 409600 or higher. A multiple of 8192
is
> >
> > recommended by Progress.
> >
> > G. Click OK to save the changes.
> >
> >
> >
> > 3. Spin Locks. The number of times a process tries to
acquire
> >
> > a latch before pausing. If the process cannot acquire the
resource's
> >
> > latch, it continues the attempt. This iterative process is called
> >
> > spinning. Use the following steps to adjust the Spin Locks:
> >
> > A. Go the Vantage/Vista server.
> >
> > B. Go to Start->Programs->Open Edge 10.1B->Progress Explorer
Tool.
> >
> > C. Expand the Database folder to MfgSys803, to Configurations, to
> >
> > DefaultConfiguration.
> >
> > D. Right-click on DefaultConfiguration and choose Properties.
> >
> > E. Go to the Advanced section.
> >
> > F. Increase Spin Locks Retries. Progress recommends 20000 per
> >
> > processor. So, dual/dual core CPU should be set to 80000.
> >
> > G. Click OK to save the changes.
> >
> >
> >
> > 4. Background Writers. For an SQL database, these processes
> >
> > are not used in the Progress Explorer Tool. Shutting them down
will
> >
> > free up some of the server's resources:
> >
> > A. Go the Vantage/Vista server.
> >
> > B. Go to Start->Programs->Open Edge 10.1B->Progress Explorer
Tool.
> >
> > C. Expand the Database folder to MfgSys803, to Configurations, to
> >
> > DefaultConfiguration.
> >
> > D. Right-click on DefaultConfiguration and choose Properties.
> >
> > E. Go to the Background Writers section.
> >
> > F. Set the # APW's to start to 0.
> >
> > G. Uncheck the Auto startup check boxes for the Before-image
writer and
> >
> > After-image writer.
> >
> > H. Click OK to save the changes.
> >
> >
> >
> > D. The schema holders for the database can be set to read-only.
This
> >
> > may help with client performance. This should not be done if
there are
> >
> > third party products connecting to the Vantage DB. See document
8782MPS
> >
> > for details. If there are third party products, contact Support.
> >
> >
> >
> > E There is an SQL indexing script that can be run. The script
changes
> >
> > the Progress_recid index of tables to be non-clustered. This will
help
> >
> > improve performance, in cases of locking, poor performance, or MRP
> >
> > issues. See document 8927MPS for details. If there are any
questions
> >
> > about this document, contact Support.
> >
> >
> >
> > F. AppServers can be set to see which client PC is causing a
problem.
> >
> > This requires replacing one file on the server. AppServers will
then
> >
> > track the client PC name. See document 8973MPS (for V8.03.305) or
> >
> > 8974MPS (for V8.03.403) for details.
> >
> >
> >
> > G. Permissions on the Vantage server. Epicor recommends both the
> >
> > \Epicor folder and the \Mfgsysdata folders be shared full
control, for
> >
> > everyone.
> >
> >
> >
> > H. Hardware. Microsoft SQL is self-tuning by default. If more
> >
> > hardware resources are added to the Vantage server, SQL will
> >
> > automatically tune itself for the new hardware.
> >
> >
> >
> > I. Documents and Settings (DNS) Version Tracking. Customers
> >
> > experiencing workstation problems (lockups and display issues)
should do
> >
> > the following:
> >
> > 1. At the workstation, get out of Vantage.
> >
> > 2. Right mouse click the Windows [Start] button, select Explorer.
> >
> > 3. Go to C:\Documents and Settings\All Users\Application
> >
> > Data\Epicor\Vantage or Vista
> >
> > 4. Delete ALL of the Versional folders below the Vista or Vantage
> >
> > folder.
> >
> > 5. Log back into Vista\Vantage.
> >
> >
> >
> > J. Hyperthreading should not be enabled if SQL is installed.
In most
> >
> > cases, SQL2005 will not install. See page 7663MPS for how to
turn off
> >
> > Hyperthreading.
> >
> >
> >
> > K. Business Activity Query and SQL Issues
> >
> > SQL function syntax is stricter than Progress syntax. If you
previously
> >
> > ran the application using a Progress
> >
> > database but now have moved to SQL, you may experience these
syntax
> >
> > issues.
> >
> >
> >
> > The main issue is that you can use abbreviations within Progress;
for
> >
> > example, ABSOLUTE can be abbreviated to ABS, ABSO, or ABSOL within
> >
> > Progress. BAQ formulas are directly sent to SQL. As long as these
> >
> > formulas do not contain any abbreviations, they work as expected.
> >
> > However if a formula references an abbreviation, syntax issues
occur.
> >
> >
> >
> > The following table displays the functions which are not identical
> >
> > between Progress and SQL. The characters contained between the
> >
> > parentheses are optional characters in Progress.
> >
> >
> >
> > Progress SQL (Before Translation)
> >
> > SQL (After Translation)
> >
> > ABS(OLUTE) ABS
> >
> > abs
> >
> > ASC(II) ASC
> >
> > ascii
> >
> > INT(EGER) INTEGER
> >
> > convert
> >
> > MAX(IMUM) MAXIMUM
> >
> > dbo.maximum (user-defined function)
> >
> > MIN(IMUM) MINIMUM
> >
> > dbo.minimum (user-defined function)
> >
> >
> >
> > L. Check External Company Maintenance. If there are External
Companies
> >
> > setup that are not being used, those may cause a problem. If an
> >
> > External Company is not being used, it should be deleted. NOTE:
It is
> >
> > *vitally* important that External Companies being used are *not*
> >
> > deleted.
> >
> >
> >
> > M. Full Text Cataloging Set to Track Changes. In SQL Server
2005, if
> >
> > the tracking option is set to automatic, it can cause performance
issues
> >
> > such as locking and speed degradation. This is a known
Microsoft issue
> >
> > and will be addressed in SQL Server 2008. See page 9494MPS for
more
> >
> > details.
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> > ------------------------------------
> >
> > Useful links for the Yahoo!Groups Vantage Board are: ( Note: You
must
> > have already linked your email address to a yahoo id to enable
access. )
> > (1) To access the Files Section of our Yahoo!Group for Report
Builder and
> > Crystal Reports and other 'goodies', please goto:
> > http://groups.yahoo.com/group/vantage/files/.
> > (2) To search through old msg's goto:
> > http://groups.yahoo.com/group/vantage/messages
> > (3) To view links to Vendors that provide Vantage services goto:
> > http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
> >
> >
> >
>
So out of curiousity, what caused the underlying condition that required
you to run this utility?

On 12/11/08 2:59 PM, "too_much_hg" <neil_willet@...> wrote:
>
> On behalf of Dale Walker (Originator of this thread)
>
> Thanks to all who replied to this thread !
>
> The problem was that we needed to run the nullfixer.r program against
> the database.
>
> I did learn alot from the SQL tuning doc and I made the SQL Tuning
> modifications, hopefully they will give us the best performance going
> forward.
>
> Regards to all who contributed.
>
>
>
>
>
> .
>
>



[Non-text portions of this message have been removed]
We are in the process of converting/incorporating our data from our
old MRP system into Vantage.

During this last conversion attempt we had some errors in fields that
came thru clean on previous conversions.

I suspect that there were some inconsistancies in the conversion
process that caused our MRP run to crap out.

The null fixer found a bunch of stuff and fixed it, now it seems
happy.

I also ran the null fixer against the previous conversion to see if
that would run "clean", it did NOT run clean so maybe there was
something specific about some table/field that made MRP gag.

I haven't done a complete post mortem to find exactly where the fault
occured but I will be sending the log files to Epicor for analysis.

Neil

--- In vantage@yahoogroups.com, "Brian W, Spolarich" <bspolarich@...>
wrote:
>
>
> So out of curiousity, what caused the underlying condition that
required
> you to run this utility?
>
> On 12/11/08 2:59 PM, "too_much_hg" <neil_willet@...> wrote:
> >
> > On behalf of Dale Walker (Originator of this thread)
> >
> > Thanks to all who replied to this thread !
> >
> > The problem was that we needed to run the nullfixer.r program
against
> > the database.
> >
> > I did learn alot from the SQL tuning doc and I made the SQL Tuning
> > modifications, hopefully they will give us the best performance
going
> > forward.
> >
> > Regards to all who contributed.
> >
> >
> >
> >
> >
> > .
> >
> >
>
>
>
> [Non-text portions of this message have been removed]
>