7.6.3 - network slowdown 3

[ultrav]

We are on PSQL.2000 and Windows XP workstations

Has anyone noticed any slowness after the upgrade especially when printing? Sometimes when something is being printed it will just hang up for minutes.

I am interested if anyone else is experiencing this.

Celeste

 

[MacolaHelp]

What version were you on before? 7.6.200 was definitely slower than 7.6.100a. It's that dll technology they are now using. It seems like the psql sites are slower the mssql as well. No surprise since they have gone to dlls to be more microsoft compatible.

Best thing to resolve printing is to initialize the print default file & reselect your printers again. There is also a cleanup utility that may help. There were lots of printing problems with 7.6.200 and many patches, but I heard 7.6.300 was better.

I just installed my first 7.6.300 upgrade & gave up trying to "upgrade". It may have been a network problem at the site, but I ended up doing a fresh install to the server & copying back data, pwe, screens, etc from the old macola installation. The update wouldn't go in for love nor money. We have had surprising few issues after this installation.

 

[ultrav]

We were on 7.6.100a - it seems like some of the printing problems that we are having are particular to certain orders, P.O.s etc (so far just a couple - most appear to be printing correctly) -we are going to rebuild the files and see if it helps.

 

[crystalreporting]

90% of the slowness problems that we run into relate to client-side real-time virus scans. Since 7.6.200 and 7.6.300 use DLL's, the DLL's are scanned by any client software when they are bought across the network and loaded into the client's memory. Disable any real-time virus scans and see if you notice a difference.

On one site in particular, long 'canned' Macola reports would take over an hour on XP workstations, and less than 10 minutes on 98 workstations ON THE SAME NETWORK USING THE SAME DATABASE AND THE SAME REPORT! Again, this problem was due to real-time anti-virus software.

Peter Shirley

http://www.linkcorp.com

 

[ultrav]

WHat I thought was a network slowdown appears to be another problem - there are a few P.O.s and invoices that will not print - they get hung up at the print status screen(when we print one that works you barely see the screen come up) - I have waited 15-20 minutes with no success. Rebuilding the file makes no difference - it appears to be a normal order - can view it - make changes - just will not print. Anyone else having this problem? Any suggestions?

 

[ultrav]

The only thing that we have noticed that these orders have in common is that they all have 6 line items - it will print orders with 5 or 7 line items but not six. Any ideas?

 

[dgillz]

Run a file validation report on the IMITMIDX and IMINVLOC on the items on these POs and tell me if anything comes up.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports
askdon@srhconsulting.com

http://www.srhconsulting.com

 

[ultrav]

Got the following error when trying to run a file validation:
JMP0015I-U [PID:00000E54 TID:00000288] CANNOT CALL PROGRAM 'VALID'. CODE=0x7e PGM=VBMACEXE ADR=0040516C

I am in contact with a support person from Exact(about printing immediate pick tickets not working for us - also getting a COBOL error) - I am notifying them about this as well.

Thank you for all your help.

 

[kscheeler]

Here's the infomine to correct the issue you have with running the file validation.

After upgrading to 7.6.200, users are not able to run file validation. They will receive an error that includes "Cannot Call Program 'Valid'".


To resolve this, it will be necessary to edit the Progression menu.

Launch Progression and log in as Supervisor.

Go to System Manager\Maintain\Visuaul Menu Builder.

Expand the tree and select Supervisor from under Non-Grouped Users.

In the module list, select SMMENU.

Then, click the Customize Menu Option (the button on the menu bar that is farthest to the right).

Scroll through the list to File ~Validation.

Right click and select Properties.

On the Properties screen change the Program Name to VALID1


If you are unable to enter the '1', place the cursor to the right of the 'D' and press the delete key several times, there may be spaces after the 'D'. This entry is case sensitive.

Click OK.

Click on the diskette to save the change.

This change will need to be done for each user that needs to access file validation.

This is not an issue on new installs of 7.6.200.


Kevin Scheeler

 

[ultrav]

Thank you - that did clear up the problem with the file validation. The items on the P.O.s and orders did not show a problem.

Celeste

 

[ultrav]

Ok - Found a bug report on my problem
Bug report Macola Progr. 7.x - 12.215.051

Thank you everyone for your help

Celeste

 

[dgillz]

UltraV,

What was the nature of the bug? Please expound on it here so we can all see it.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports
askdon@srhconsulting.com

http://www.srhconsulting.com

 

[ultrav]

The bug involved P.O.s not printing when there were enough line items (7-9 line items - my problem was 6) to get to the bottom of the form (they also mentioned that you had to be using subtotal) I Printed my P.O.s on a different form that I have (the form I have has details about shipping - so I printed the p.o.s on a blank form). They listed a dll as a fix - and it states it will be fixed in 7.6.3b.

The Orders will print if a order header comment is added - throws it past the bottom of the form.

I do not have the dll yet -so I am not sure if it takes care of both problems. Will keep you posted.

 

[crystalreporting]

OK - quick update. Earlier in this thread, I mentioned that real-time virus scan updates cause 90% of the performance problems I see with 7.6.200 and 7.6.300. Most anti-virus software have provisions for excluding folders and/or files from the real-time monitoring function. Some months ago I spent a little time trying to exclude Macola DLL's and files from the real-time scan, however I could not get this to work. I tried again today, and was finally able to exclude the Macola files by referencing the MACAPPS folder via the network name, NOT the mapped network drive i.e. //SERVER/MACAPPS.

Peter Shirley

http://www.linkcorp.com

 

[dgillz]

Peter,

CAn you tell me exactly how you did this?

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports
askdon@srhconsulting.com

http://www.srhconsulting.com

 

[crystalreporting]

Don,

The client I tested this with is using Symantec's client side real-time monitoring software. I haven't tried the same 'fix' with Norton, but I'm confident it will work - just about every 'real-time' monitoring software has provision to exclude files or folders. As you already know, since Macola moved to the Fujitsu compiler, DLL's are loaded over the network as they are needed. Real-time monitoring intercepts and scans the DLL's and DRAMATICALLY slows down both the opening of Macola, and the opening of applications within Macola.

You can test this yourself, by simply disabling the scan, and testing Macola performance.

I had tried some time ago to configure Symantec to not scan Macola DLL's, but excluding the common files folder, and the mapped Macola drive (normally M) did not work. I finally tried excluding the Macapps folder via the UNC name (//SERVER/MACAPPS) and it worked. This needs to be done at each client.



Peter Shirley

http://www.linkcorp.com

 

[MacolaHelp]

Thanks for the update & the info. I'm going to start trying this at my sites. Have you any insights on spybot or adaware doing anything like this? A gold star for you!