Solved

Application can't print to LPT1

Posted on 1998-06-14
5
572 Views
Last Modified: 2012-06-27
An application that runs under dos, made with CA-Clipper 5.3b cannot print to local printer in Novell 3.11 or 3.12. Returns error code "0" inerpreted as "invalid file handle".

The strange thing is that this happens in one lan and does not happen in others (about 10) of the same type.

For people that are familiar to clipper the command is:
"Copy &filename to &OutputDev", where OutputDev="LPT1".
The syntax "!copy &FileName &OutputDev", that calls the OS shell to execute the command works fine.

What could be the cause of such a strange behaviour? I have never worked with Novell 3.1x, only with 2.2 and 4.x where I never had such a problem and I never had it with other clients of mine that installed my application on 3.1x.

Thanks, Yiannis
0
Comment
Question by:anadrash
  • 3
5 Comments
 
LVL 4

Expert Comment

by:Zombite
ID: 1592630
Depending on what client you are running. This may help in relation to default directory. Suggest the site upgrade to latest clients - may help the problem.



--------------------------------------------------------------------------------
Symptom
Customer upgraded to the VLMs from NETX and could no longer printer to his local printer from within Clipper. If the port was captured the job would print fine to the network printer. However if the port was not captured and they attempted to print locally while on a network drive they would get the error of:

                   Error Base/2012 Create Error: Files\prn
                                  (Dos error 1)

They could print locally as long as they were on a local drive.


--------------------------------------------------------------------------------
Cause
The application prints to the system device PRN. Within the application they had set up a default directory (in this case "files") - and when the application attempted to print it would preface PRN with \files. So the command was to write to the file \files\prn. When DOS receives a command and sees that a network drive is involved it does not parse anything after the network drive letter and passes the command to the VLMs. In other words it does not realize that in reality the command is to write to the system device PRN (which DOS controls) and sends the command to the VLMs. The VLM looks at the command - says this is a system device that it does not know about and sends the command back to DOS - and DOS returns the error to the application.


--------------------------------------------------------------------------------
Solution
The solution is to remove the default directory and leave it blank. With no default directory in Clipper everything worked fine. With no defualt directory the command sent from Clipper to DOS was to write to PRN - instead of \files\prn. DOS will read the command and see that it is the system device PRN and send the job to the port. The reason that NETX worked was that it was a shell and would recognize what the application was trying to do. This same problem will happen to any application that prints to the system device prn and puts anything before it like a \. The problem is caused by the fact that DOS does not parse the entire line to see that we are dealing with a system device - as soon as it sees the network drive DOS passes the command to the VLM.

 
0
 

Author Comment

by:anadrash
ID: 1592631
"The solution is to remove the default directory and leave it blank."

This solution cannot be accepted since the application is designed in a specific way. I'm familiar with the explanation given in your comment and I have tried simple programs (just printing files from the current directory) that worked fine.
Your comment gives a complete description of the cause of the problem, but I would like a positive solution.

Thanks, Yiannis

0
 
LVL 5

Accepted Solution

by:
jstegall earned 150 total points
ID: 1592632
Try adding the line "Local Printers = 1" in Your net.cfg
file for the workstations that have local printers,  it
solved a simular problem for me.  Worth a try if you haven't
added the line already.  HTH
0
 

Author Comment

by:anadrash
ID: 1592633
The problem was solved updating the client drivers.
The line in net.cfg was added after the updating (which was done by the company's people after my telephone conversation with them) but was necessary.
The newer vlm drivers had already solved the problem without the need to edit net.cfg, as I found out lately.

Sorry for the mess and espesially to zombite who fully described the problem and had given the solution at the top.

Thanks, Yiannis

0
 

Author Comment

by:anadrash
ID: 1592634
Oops,

"but was necessary" in my last comment should be "but was NOT necessary".

Thanks again, Yiannis

0

Featured Post

Gigs: Get Your Project Delivered by an Expert

Select from freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely and get projects done right.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This tutorial shows how to create a greeting card by combining two image layers and a text layer on a PC using a free image editing app.
Employees depend heavily on their PCs, and new threats like ransomware make it even more critical to protect their important data.
In a recent question (https://www.experts-exchange.com/questions/28997919/Pagination-in-Adobe-Acrobat.html) here at Experts Exchange, a member asked how to add page numbers to a PDF file using Adobe Acrobat XI Pro. This short video Micro Tutorial sh…
Two types of users will appreciate AOMEI Backupper Pro: 1 - Those with PCIe drives (and haven't found cloning software that works on them). 2 - Those who want a fast clone of their boot drive (no re-boots needed) and it can clone your drive wh…

776 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question