Deferred reports - processor at 100% util 1

[Macoladownunder]

We are running a deferred reports process to post our OE invoices on a nightly basis. As soon as we set the process, the Processor on the machine that we have set aside to run it hits 100% utilisation - VBAmacexe.exe file is the culprit. The machine (the second we have tried this on) is a P4, 2.4ghz, 512mb ram spec - so I would expect that it would have plenty of staying power.

Has anyone got the same problem? Or have you overcome it?

MacolaDownUnder
Aussies using Macola

 

[dgillz]

When you say that vbmac.exe is the culprit, how did you come to that conclusion?

Also, since vbmac.exe is a PWE thing, have you tried running this from plain vanilla progression explorer as a workaround?

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[vbajock]

There's a bug in it. If you run deferred processing on Win 2000 or XP machines, it maxes out the ram on the box. Classic memory leak.

For unattended use, the only fix I found was to use an old Win 98 box. Works perfect.

 

[Macoladownunder]

Thanks Don and vbajock - we tried the SQL explorer (non PWE) option but the processor still shoots up to 100%. We see the culprit file, vbmac.exe, via task manager.
We are going to look at it on a W98 box as soon as we can get one from Fred and Barney. Pebbles and BamBam are still using one. But if that is what it takes, then so be it.


MacolaDownUnder
Aussies using Macola

 

[vbajock]

I think you can get one at Compurock

 

[MacolaHelp]

vbmacexe is the pwe process that loads on the workstation. macexe is the progression explorer process that loads. So pwe is loaded in the background somewhere. I have random instances of pwe sessions remaining open on terminal server win2k & win2003 running pervasive 2000i, but haven't seen it at sql sites. I'll try deferred report processes on 2 different sites I can log in to & let you know my findings. Often, when I've seen that 100% utilitization in the systray, it hasn't really been @ 100%

 

[vbajock]

It's maxed 100% alright. We tried running deferred MRP on a 2000 server machine and it maxed it so bad other apps couldn't even start. We moved it to an XP workstation and it did the same thing. Something in their code is not closing properly on 2000 and up op systems.

 

[MacolaHelp]

I just logged into a LAN xp workstation at one of my sites. It has 256k memory. Launched the deferred processing menu & it went off just fine. On my initial login to pwe, my utilization went to 55%, but then stayed at 10-35 while the report was running. I had deferred the ar aging because it is resource intensive since it performs the math subtotals on the fly. The report took about 15 minutes to run & completed fine. This site is pervasive sql 200i sp4 on a win2k/sp4 server. The ar open file is over 100 megs. I had also spooled to disk, not printer.

I can try an sql site over the weekend for you, too. Could it be something in the Australian version? Have you tried another deferred job to see if perhaps the volume of data processing during posting invoices might be choking the performance?

 

[MacolaHelp]

Another thought: you refer to a thing with putting sales tax on every line in your "oe cannot change qty" post. This would be a very unusual configuration in the States. I wonder if the posting is having trouble with the tax code files. I assume that if you post during the day rather than deferred, that win2k or xp workstations work as expected? I also see you are sql in that post, so I'll let you know what I find out from that site. It may also be a 7.6.200 problem, so I try it on an sql 7.6.200 install I have on Monday if you haven't solved by then.

 

[Macoladownunder]

Macolahelp,
There is no such thing as an Australian version. We use the same programs/CD's/patches as the US. We are supported by a firm in California and they make no concessions for us. The standard Macola system works fine for us - the thing is we have a Goods & Services Tax on most items we sell, so we have the Ar|Setup|Tax Sch set to enforced.

Your advice on the AR ageing as a deferred report may be correct. I am yet to test a 'non posting' deferred job. Since I was last on here we found a document on Exact's site that says that posting is not recommended using deferred processes. My question is 'why have the option to do so' on those processes?. Nonetheless, we run the posting each night using deferred reports. It works, but because of the memory hunger (be it real or not), we have set up a dedicated box just to do this. We process over 1000 orders per day, so our posting takes quite some time and we need to do it after hours.

Thanks for your help on this mate.

David

MacolaDownUnder
Aussies using Macola

 

[MacolaHelp]

Macola has conflicting docs in infomine on this subject. They indicate that any process that produces a report can be deferred, such as mrp, reset allocations & on orders, etc. I thought there was something specific you got on AP check printing that we don't have in the US that someone else started a thread on (that's why I said Australian version). My SQL site sent my remote access machine away, so I'll have to try it elsewhere for you. Are you sure all users are out of macola when you launch the deferred process? MRP regen takes quite a bit of time at many sites & processes large files in some cases. I imagine your order history files & inventory transaction files are quite large if you do 1000 orders/day. If you start posting at the end of the day to file rather than deferred, does the CPU also jump up to 100%?