Products | About Us

Error messages

Out of the blue production getting these errors on jobs that passes through PD. Can't tell which queue from the message. Running 4.1.1583. No changes to any queue made lately.

06/11/2008 06:38 Couldn't open read file in .\source\actions.cpp at 2234

06/11/2008 09:20 Error parsing script text in .\source\actions.cpp at 1697

Harvey Kaye
6th Nov 2008

BTW, Had similar problems before, were resolved by a server restart. In this case the problem did not go away after a restart. I have opened the script in the editor and it seems to be able to parse.

On this subject, I think I would prefer that this configuration be changed to point at a file location for a script, rather than depending on your editor to update. It seems dangerous and bad source management practise to do it this way. Suggestion for a future update.

Harvey Kaye
6th Nov 2008

The second error is misleading, it isn't a parsing problem. This is resolved in 4.2

The first error tends to indicate your script or an object you are using in your script has a lock on the print file. You might be better off making a copy of the print file and work on the copy.

You could save your script as a vbs file and call wscript.exe from the Run Program action passing in the path to your external script and any parameters you need. This would give you an external script file.

Tony Edgecombe
7th Nov 2008

Thanks, would the external script have access to the global variables still?

Harvey Kaye
7th Nov 2008

Another point, on the first error message, open read file.. this is also occurring on a server with print distributor with no scripting in use.

In the end, in order to fix this problem on the server with scripting, I had to delete the old queue, recreate a queue under a completely new name, then rename it to the old name. If I just deleted and recreated it, the problem continued. Very odd.

Harvey Kaye
7th Nov 2008

You would have to pass in the global variables that you needed on the command line.

I can't see how creating the queue with a different name would have an effect, it might just be coincidence.

If it isn't your script that has a lock on the file I wonder if your anti-virus software is scanning it still? If you have any anti virus software it might be worth turning it off for the raw and queue folders.

Tony Edgecombe
7th Nov 2008

We have two servers running PD, and only one has scripting in use. On Friday(11/07), I changed the anti-virus to exclude the folders you suggested below on both servers.

Since then both servers are still reporting this "couldn't open read file" message on Saturday(11/08).

I can't tell what print file or what queue so don't know if the documents are being processed or are being dropped. This definately needs improvment in the logging area, really need: date/time/queue/document name/end result (file printed, dropped etc).

How can I tell?

Thanks.

Harvey Kaye
10th Nov 2008

I'll look into this, I think we can improve the error message here.

Tony Edgecombe
11th Nov 2008

Harvey,

There is a new build at http://www.printdistributor.com/dl/setuppd-4.2.2069.exe

There are three changes we have made:

1. We now flush the print file, there was a small chance it could have still been writing to disk from the Windows cache although I don't think this was the problem in your case.

2. We have improved the error handling in the reprint action, it should now give you more information on the problem.

3. We have added a LogMessage method to the script action, this lets you add your own information to the log file. You can use it by adding a new script action to the end of your actions and paste in some code like this:

If Exception Then
LogMessage("Printer name: " & PrinterName)
LogMessage("Windows error code: " & ExceptionCode)
LogMessage("Windows error description: " & ExceptionDescription)
End If

Tony Edgecombe
13th Nov 2008

We installed this new version after the holidays. Thank you for the update, however it does seem to still fail on large files. The available memory on the server dips close to zero and the CPU utilization goes flat out 100% on a dual xeon server.

After the script is processed, the log file show this series of messages. The first is a logmessage which prints the length of the file in bytes. The script works fine for smaller files. I'd be happy to send you the script code, please let me know where to send it.

07/01/2009 13:59 len(str)=34777479
07/01/2009 13:59 Syntax error in line: 229 column: 2
in ..\common\scriptsite.cpp at 215
07/01/2009 13:59 Printer name: VCalligoQA-SW1
07/01/2009 13:59 Windows error code: 0
07/01/2009 13:59 Windows error description: Syntax error in line: 229 column: 2
in ..\common\scriptsite.cpp at 215

The code at line 229 is: ReDim ahex(len(str) - 1)


Harvey Kaye
7th Jan 2009

It clearly isn't a syntax error, I'm guessing from the messages it's a memory allocation failure.

Although there is no restriction on the size of a string I'm not sure it's sensible to put 70MB of data in them.

You can send the script to support at frogmorecs.com and we will take a look.

Tony Edgecombe
8th Jan 2009

This thread is closed to new posts.

Feed