Print Spooler Problem 1

[AKPolarBear]

Macola print jobs have suddenly started taking a long time to clear the NT print spooler. They will process for a bit, dump nearly all of the job to the spooler and the last little bit of the print job takes a long time to finish and print. Other non-Macola jobs print normally unless there is a Macola job in the spool ahead of it. Some example of print time have been 3 minutes per document to 20 minutes per document. Sometimes, they print normally, in under a minute. We are SQL based on 7.6.100a. OS is Advance Server, Macola software on identical server to SQL, Term Server is on NT box with Citrix Metaframe 1.8, 2 gig ram. All servers are multi-processors. We have about 50 users.
We recently added and then subtracted a plotter to the network. Also we found some of the setting for the SQL server have changed, perhaps due to a recent update from Microsoft (it was not set up that way). Further, one of our modifications reset itself as if it had been initialized. No viruses have been found anywhere in the system.
Any thoughts?

 

[MacolaHelp]

Which server handles the print services? Have you configured printing on this server to start printing after last page is spooled? Or are you trying to manage settings at 50 workstations instead of the server? If you are managing at the server, the spool after last page is far better for macola as too many jobs are "think & print" jobs that are doing math on the fly such as open item reports. You can also initialize the reptpass file & the print default file. If you initialize the latter, the users will need to reselect their default printers the next time they run a job. Maybe taking the plotter off & back on did something toasty to the printer setup on the server?

 

[AKPolarBear]

Printers are all managed on another server (Our Exchange server). They are all set to spool and print immediately.
I will try to initialize the reptpass file first and I will change the setting on one of the printers to see if that helps.
I agree the plotter may have been the straw that broke it as this was not a problem before. Could still be another issue.
A side note, the users are now using another program called Maxview which is Adobe based. I have noticed an increase in the number of applications running for this program. I wonder if it is tying up resources more than I can see.

 

[AKPolarBear]

Update:

Other problems have appeared. After rebooting the server, I observed that pick tickets were still taking 10 or so minutes to print. As I was watching one spool, another Macola job, 7 pages long prints so fast, I barely saw it on the screen. It was a packing slip job. No problem and according to the few users that print those, has not been a problem all along.

 

[stravis]

Are you using the Crystal pick tickets? Macola has two different reporting/printing mechanism, COBOL reports an Integrated Crystal Reports. Are you using the Integrated Crystal Reports and do you see a difference in performance with these reports as oppossed to the COBOL reports?

Scott

 

[AKPolarBear]

We are not using the Crystal pick tickets, but that is not a bad idea.
A resolution of sorts was found. We are now able to print nearly as fast as before the problem. Our VAR had to get Macola directly involved with the correction. Can't wait for that bill to come through...
It apparently also resolved another problem/grief with MRP merge & regen. The regens are now taking about 30 minutes from 1 - 1/12 hours prior. Similar time savings in merge and during the month end close process. We have also made a hardware change (added a switch between the servers) and are now planning some other software changes.
It's odd that all the problems most definitely began after the installation of "routine" security updates for the W2K servers. This is where we found servers settings changed.

 

[JillofAllTrades]

Would you care to elaborate, AKPolarBear? We also noticed a big slowdown in printing after W2K updates.

Christine

 

[AKPolarBear]

Are you SQL based? The W2k updates I applied were on our SQL server and the Macola server only.

What I found were that some settings had changed or did not appear to be what was originally setup.

Are you having the same type of spooling problems? The clue to what eventually resolved our problem came in a Comm/Ado message we started getting at the end of a merge or regen. In that message, it was noticed that the server it named was different than the name of the server. It almost looked like a license key number was used to name it. The server apparently was trying to resolve the name and that what was causing the delay. Not only has the printing returned to almost normal speed, but the regen and merge have improved substantially. I don't think we are completely back to the pick ticket printing performance but its only off by a few seconds and maybe that is just perception. Our packing slips still print faster than PT's do now but were at one point the same speed.
I must give credit (it hurts to say this) but it was the tech at Macola that discovered the name change and helped me to correct it.
On the plus side, the faster performance in the other areas more than compensated the few extra seconds of pick ticket delay. Regen went from about an hour plus to 20 -30 minutes.

 

[dgillz]

Bob,

Thanks much for sharing this information. Very enlightening.

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

http://www.trianglepartners.com

 

[JillofAllTrades]

Yes, we are SQL based.

So where did you locate the wrong server name to check/change it?

Christine

 

[AKPolarBear]

Unfortunately, my SQL knowledge is little. Do a query to check the version and I think the server name will be listed there.
Then you will need to change it through SQL. I believe it was done through query and did not require a reboot. It only took a few minutes to correct.

I suspect dgilliz could give better instructions.

Last week, I notice the other older name in yet another location on the SQL server and am still working on locating where that came from.

 

[stravis]

In order to correct the name in SQL Server you should never do it through the system tables directly. You should always use a two special stored procedure to correct your SQL Server Name. The most common reason why this procedure would need to be run, is after changing the name of the server on the network.

Please refer to SQL Books Online for the sp_dropserver and sp_addserver stored procedures. These two procedures must be used in your master database in order to "fix" the name of your SQL Server.

 

[dgillz]

Thanks Scott, this is great info.

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

http://www.trianglepartners.com

 

[JillofAllTrades]

Thanks for expanding on this.
I checked with sp_helpserver and it seems that my server name is correct. So I guess I will continue looking elsewhere for the answer to my problems.

Christine

 

[dgillz]

Jill,

You are having this only on pick tickets correct?

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

http://www.trianglepartners.com

 

[AKPolarBear]

Jill,
What MS patches did you apply? I found this in a TechNet article this morning:

Some users who have applied the patches in the massive MS04-011 Security Bulletin are reporting problems ranging from failure of sound cards to an inability to boot Windows 2000 systems with the patch installed. Others are reporting that some antivirus software is failing after applying the patches, which address 14 major and minor IE bugs. As such, there have been some updates to MS04-011. One update (835732 <

http://support.microsoft.com/default.aspx?scid=kb;en-us;835732>)

explains some of the problems known to be caused by installing the patch:
--Windows 2000 system locks up (841382 <

http://support.microsoft.com/default.aspx?kbid=841382>).

--Adobe Illustrator EMF image files can’t be viewed (840997 <

http://support.microsoft.com/default.aspx?kbid=840997>).

--Error message "STOP 0x00000079" is displayed on Windows NT 4.0 systems (841384 <

http://support.microsoft.com/default.aspx?kbid=841384>).

--A maximum of 7.8 GB system partition problem exists on NT 4.0 (224526 <

http://support.microsoft.com/default.aspx?kbid=224526>).

The patches I applied were:

MS04-004, 006, 007, 008, KB828026 and an Intel device update (network card).

These were all installed by the auto update program. While the problems listed above are not for the patches I installed, it does show that problems can occur. do any of the patches you installed match any of these?