[Migrated content. Thread originally posted on 07 January 2003]

Has anyone had problems with assigning printers with the -Q printer name:direct=on or just with -Q printer name in general with version 5.2.1? My system keeps locking up after selecting the printer this way. After the system locks up with the -Q assignment, if I go to the settings, printer selection, all my window printers are gone. After rebooting the printer icons reappear. If I use -d LPTn, it never locks up but I do occaisonaly get status 94's, no printer found. This is a NOvell network so I can't use -d //que name printer name. This type of assignment is not supported by Novell (at least that's what acucorp support tells me)

There was a few problems with -Q in 5.2.0, but to my knowledge there are no known issues for 5.2.1.

May I see the entire entry you use with the -Q?

Also, from where do you obtain the printer name you use, can you verify that it matches the name that appears if you run the sample program prndemox?

I presume a functional printer driver for the printer in question are installed and works with for instance Notepad?

---

[Migrated content. Thread originally posted on 07 January 2003]

Has anyone had problems with assigning printers with the -Q printer name:direct=on or just with -Q printer name in general with version 5.2.1? My system keeps locking up after selecting the printer this way. After the system locks up with the -Q assignment, if I go to the settings, printer selection, all my window printers are gone. After rebooting the printer icons reappear. If I use -d LPTn, it never locks up but I do occaisonaly get status 94's, no printer found. This is a NOvell network so I can't use -d //que name printer name. This type of assignment is not supported by Novell (at least that's what acucorp support tells me)

Thanks for your response!

In my application I offer the operator a selection of printers. I then from within the program execute the following line of code:
Set Environment "PRINTER" to w-assignment.
In this case w-assignment = "-Q PM4410;DIRECT=ON"

I used the program graphprn.cob from the sample directory to get my list of printers. It displays "PM4410". In the windows, start, printers, click on properties, the driver being used is 4410. There are no other problems printing to this printer and in fact printing in this manner works about half the time. However on one particular program it will work and print correctly, then if I go back to my main menu program, call the program a second time, the program will get to the open output printerfile statement and lock up. Most of the time it's a hard lock and I have to reset the machine in which case I do not get a trace file. I know it locks on this command however since I was following in a debug mode. In the event I can get out of the lock without resetting and look at the printers control box, all the printer icons have disappeared. They reappear after rebooting.

This morning my client changed the properties on the printer from "spool print jobs", to "print directly to printer". She has not had a lock up since but it's only been several hours.

The printer by the way is a okidata 4410 line printer. Another note is the Novell login script issues a capture of this printer to LPT3. The printer is used for reports and is accessed by up to 4 workstations. For years I used the -D lpt3 as the assignment, but I started getting a lot of status 94's on the printer files as if the printer wasn't there. I upgraded to 5.2.1 to use the -Q to correct that problem.

I am also using the winreg.acu program sent to me by customer support to solve the other 5.2.1 problem of extremely poor performance at this site and the status 30 problems that would crop up when accessing data files. I hope acucorp realizes the seriousous of the problems caused by 5.2.1. I realize it was changed to help run in a "safe mode" preventing status 98's. This may be so but I almost lost a client due to the performance and the constant interuption due to status 30's. I put in the winreg program a few days ago and so far it seems to have corrected the performance and the status 30's. As far as the performance, I timed one program in the debug mode. An open I-O took 10 - 12 seconds, multiply that by 6 to 8 files and the client was waiting almost a minute and a half before the files were even open, compared to less than 2 seconds in 5.2.0.
Thank you for any help or ideas you may have.

---

[Migrated content. Thread originally posted on 07 January 2003]

Has anyone had problems with assigning printers with the -Q printer name:direct=on or just with -Q printer name in general with version 5.2.1? My system keeps locking up after selecting the printer this way. After the system locks up with the -Q assignment, if I go to the settings, printer selection, all my window printers are gone. After rebooting the printer icons reappear. If I use -d LPTn, it never locks up but I do occaisonaly get status 94's, no printer found. This is a NOvell network so I can't use -d //que name printer name. This type of assignment is not supported by Novell (at least that's what acucorp support tells me)

Hi Mike,

You might have to take this through Tech support as it seems the problem may be something that we are not aware of, that appears in Novell environments.
Anyway, what puzzles me is that the symptoms you refer to, has a very good match to a case that was fixed and corrected in version 5.2.1. Are you 110% sure that the customer is using 5.2.1?
Obviously you are, otherwise you wouldn't have stated the performance loss and the related flagging in the registry. I think you will have to try to make as small a sample program as possible that illustrates the behavior and hopefully reproduces it, and then we will see if we can have it reproduced using one of our Novell servers.

As for the performance hit in 5.2.1, as you yourself point out, there is a price to pay. Our problem here is that we don't get proper answers when we ask these questions to whom they belong to. We know that with the high performance access, it usually works fine, in some certain configurations, for which we haven't been able to determine the difference, it fails. The fallback then is the secure, but oh so slow alternative. We chose to give priority to security above performance as a default.

Believe me, there is nothing we would like more than to join both security and performance, but this problem has its roots down into the competition on server market. If it can serve for any good, the name of this problem is Oportunistic locking, and it doesn't only bother vision files, but also flat file systems from vendors like MS themselves, Borland and more.

A final note on your printing issue, with the advent of the 6.0 beta, you might be one of those that has signed up there? It would have been interesting to know if the printing problem was present also with 6.0.

Sorry for not being able to provide you with exact answers though.

---

[Migrated content. Thread originally posted on 07 January 2003]

Has anyone had problems with assigning printers with the -Q printer name:direct=on or just with -Q printer name in general with version 5.2.1? My system keeps locking up after selecting the printer this way. After the system locks up with the -Q assignment, if I go to the settings, printer selection, all my window printers are gone. After rebooting the printer icons reappear. If I use -d LPTn, it never locks up but I do occaisonaly get status 94's, no printer found. This is a NOvell network so I can't use -d //que name printer name. This type of assignment is not supported by Novell (at least that's what acucorp support tells me)

Hi Mike,

You might have to take this through Tech support as it seems the problem may be something that we are not aware of, that appears in Novell environments.
Anyway, what puzzles me is that the symptoms you refer to, has a very good match to a case that was fixed and corrected in version 5.2.1. Are you 110% sure that the customer is using 5.2.1?
Obviously you are, otherwise you wouldn't have stated the performance loss and the related flagging in the registry. I think you will have to try to make as small a sample program as possible that illustrates the behavior and hopefully reproduces it, and then we will see if we can have it reproduced using one of our Novell servers.

As for the performance hit in 5.2.1, as you yourself point out, there is a price to pay. Our problem here is that we don't get proper answers when we ask these questions to whom they belong to. We know that with the high performance access, it usually works fine, in some certain configurations, for which we haven't been able to determine the difference, it fails. The fallback then is the secure, but oh so slow alternative. We chose to give priority to security above performance as a default.

Believe me, there is nothing we would like more than to join both security and performance, but this problem has its roots down into the competition on server market. If it can serve for any good, the name of this problem is Oportunistic locking, and it doesn't only bother vision files, but also flat file systems from vendors like MS themselves, Borland and more.

A final note on your printing issue, with the advent of the 6.0 beta, you might be one of those that has signed up there? It would have been interesting to know if the printing problem was present also with 6.0.

Sorry for not being able to provide you with exact answers though.

---