• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 657
  • Last Modified:

Application can't print to LPT1

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
anadrash
Asked:
anadrash
  • 3
1 Solution
 
ZombiteCommented:
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
 
anadrashAuthor Commented:
"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
 
jstegallCommented:
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
 
anadrashAuthor Commented:
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
 
anadrashAuthor Commented:
Oops,

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

Thanks again, Yiannis

0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now