lbeazley
asked on
legacy printing in Netware 6.5
I recently purchased a new server with Netware 6.5 migrated from 5.0. I explained to the company doing the migration that I have several legacy applications running on the server and that they worked well in Novell 5.0 and 3.2. After a horrible migration experience the technician told me that he didn't believe that legacy printing would work on Netware 6.5. As this is a family site, I won't repeat my verbal reaction. Anyways, here are the problems. One of the problems is that I have users who use a MS DOS program as their main tool. They print to ques using batch files that call upon the Nprint command. This exe does not seem to be available in 6.5 and, as I said above the technician told me that it won't work. First off, I know about the whiz bang world of NDPS and Iprint and etc. so no one needs to flame me about using que based printing. It is used because it is the best solution for printing from an DOS prompt especially if you depend upon printer definitions to format the output. The other problem I am having is with two non-NDPS printer objects that networked Konica copiers use. Before anyone can print to these copiers, I must turn them off and back on. This reattaches them and then users can print. These copiers have ques of their own attached to non-NDPS printer objects. The solution may be as simple as recreating the printer objects but I havent had a chance to try it due to the other migration problems. Any help would be appreciated.
PS. That util works great for NDPS printers, so you might finally be able to get rid of legacy queues altogether.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks to the both of you for your advice. I had moved nprint earlier but it wasn't working. Once I moved the .msg from the NLS/English directory it started working. I still cant get the printer definitions to work. All of my printer objects are in a container called Printers. This container has different printer definitions found under Print Job Configuration (Non-NDPS). Each def has a field to link it to a que or printer object. In between fixing file system problems I have been trying different configurations but nothing has been working. On the Netware 5.0 system, the queues were attached to NDPS printer objects and the printer definitions worked just fine. The folks who print in DOS uses a batch files to print to the queues. For example a batch file called PTF1 reads nprint %1 j=tabf1 nff nb. The printer definition in the Printers container has this in the field:Printer/Queue:Q1.Pri
We don't flame, we educate. This isn't slashdot.
Unfortunately, what you've run into is the inevitable price of progress. A number of 16-bit command-line applications were deprecated starting with NetWare 6, because they were based on old technology and operating paradigms whose time had come, so to speak. Things like NPRINT.EXE, which was really a holdover from NetWare 3.x, and kinda tied to IPX/SPX as well as having 16-bit limitations, and it was surprising was supplied (if not supported) in NetWare 5.x to begin with, bit the dust.
I realize you don't like the idea of having to fix something that wasn't broke to begin with, but that happens sometimes. You'll have to use something other than NPRINT.EXE to print whatever the batch file was printing.
You could continue to use queue-based printing if you want, which will allow you to capture & endcap your printers from DOS batch files; then, you could maybe replace NPRINT.EXE with dos PRINT, and print to the captured LPT port. Have you tried modifying the batch file to replace the single NPRINT statement with a capture followed by print followed by capture /endcap?
If you want to move to NDPS/iPrint, that comes with a replacement for the capture command, icapture.exe.
I haven't used it so I don't know how well it works in a DOS environment.
What do you use for clients with your MS-DOS systems? NETX, VLM, Client32 2.71? Are you logging in to eDirectory or in bindery mode? Or are the clients running WinXP and opening up a command prompt to run this MS-DOS program?
Unfortunately, what you've run into is the inevitable price of progress. A number of 16-bit command-line applications were deprecated starting with NetWare 6, because they were based on old technology and operating paradigms whose time had come, so to speak. Things like NPRINT.EXE, which was really a holdover from NetWare 3.x, and kinda tied to IPX/SPX as well as having 16-bit limitations, and it was surprising was supplied (if not supported) in NetWare 5.x to begin with, bit the dust.
I realize you don't like the idea of having to fix something that wasn't broke to begin with, but that happens sometimes. You'll have to use something other than NPRINT.EXE to print whatever the batch file was printing.
You could continue to use queue-based printing if you want, which will allow you to capture & endcap your printers from DOS batch files; then, you could maybe replace NPRINT.EXE with dos PRINT, and print to the captured LPT port. Have you tried modifying the batch file to replace the single NPRINT statement with a capture followed by print followed by capture /endcap?
If you want to move to NDPS/iPrint, that comes with a replacement for the capture command, icapture.exe.
I haven't used it so I don't know how well it works in a DOS environment.
What do you use for clients with your MS-DOS systems? NETX, VLM, Client32 2.71? Are you logging in to eDirectory or in bindery mode? Or are the clients running WinXP and opening up a command prompt to run this MS-DOS program?
http://www.andtechnologies.com/printraw.html
nwadmn32 still has it's uses, and queue based printing is one of them.
As regards the disconnection, what support pack revision are you on? There have been absolutely loads of print updates for NW6.5. It almost seems that every time they add an "i" to the front of a product name it breaks stuff which worked perfectly well for years.