Recently, we have started having a problem with a number of our user machines where the client side printer port capture is being dropped.

We are running Windows 95 (OSR2, I believe) and logging into a Novell 4.x network.

All printer capture statements are being performed client side, through Windows 95. We are not using Novell capture statements.

I've done some research, but cannot find any reason for the capture to get dropped. I have ensured that the "reconnect at login" box is checked. The capture will remain in place for a while, and then will just go away.

If anyone has seen this before, or has any ideas, I would appreciate it.

TIA,

[email protected]

I just wanted to check and see if when you are windows98/95 you start| settings |printers | (select your printer) |properties that it is mapped to \\machine name\printer name ?

Dale

When the capture is lost, then yes the printer is mapped to \\machine\printer.

When the capture is in place, then it is printing to LPT1 (\\machine\printer).

[email protected]

Don't use Novell. But usually set the MS Networking Service option to quick logon. I kept losing network connections, printers included. This Quick option reconnects when the device is officially addressed. This seems to have helped. Except for this dipfrit HP722 thats about ready to become a tire chock!

Much luck.

The capture may be lost if

(a) you Alt-Tab from AREV to another program with print capabilities

(b) you shell out to DOS with a PCPERFORM statement

I have had no problems by using a SUSPEND EXIT CAPTURE…… statement ahead of every report to assert the printer destination before PRINTER ON is issued. This works even with the Microsoft client for Netware.

Which Novell client version are you using?

Steve

]]Don't use Novell«

Sorry Charles, but simplicity has a value for some. NT, for all its perceived advantages, ain't simple. Give me Novell any day.

Steve

Most errors are errors in perception, not errors in logic

Steve,

But doesn't using a SUSPEND EXIT CAPTURE necessitate knowing the printer path?

Our users are separated over several floors and several buildings, and use a variety of network printers through NDS.

To implement the ability to track the printer assigned to each user and then forcing a capture on the printer is unfortunately prohibitive.

I have enough other work to do without having to rewrite our entire printing schema, which is in a shambles anyway. It could use a good rewrite, but we just don't have the time or manpower to do it.

[email protected]

OK, so bring the mountain to Mohammed,

When a user logs in, in the AREV VOC LOGON script, run a program to trap their Novell USERNAME (either with an RBASIC utility or from the environment setting) then perform a capture /show and pipe the output to a file and write it against their username to a separate file. Or you might be able to get my old utilities to work in this context (though they do use older API calls and may not be NDS compatible).

OK so now you know which printer is used by which person, all from about 10 lines of code.

From this file, you can then assert the printer capture statement for each user individually. That's five lines for each report (an open, and a read and a suspend). I'd call a subroutine to do it - that way you can patch it globally.

Anyway, I don't mean to oversimplify your problem, - it does sound like a massive task, but I guess I would approach it this way. Some days it's like they hold a gun to your head, hog-tie you and ask you to tap-dance .

Another possible solution might be to disable Alt-Tab from the Windows shortcut for your AREV application, or use a small TSR ahead of AREV to similar effect.

Steve

I had a customer have a problem about loosing the whole network connection. It was because the server had a sleep mode set up. When the server went to sleep, and then woke up… it took too long to wake up, so the user pc decided that the network connection was no good anymore (all connections even printer captures).

A thousand pardons. My finger must have slipped on the trigger. The first line should have read "I don't use Novell." Not to imply the other. I don't have any installations that require Novell (let alone NT) but I will say I wasn't that impressed with ther original Star System way back when. But then, that preceded DOS 3.3. And I'm not looking forward to learning W2K (aka NT5) either.

Life keeps accelerating. I wonder. Will we go to warp. Or just expand to infinite mass. My scale don't go that high.

Its a wierd day.

Charles

"All social amenities are expressed or implied."

Hmmm - Steve,

Are your observations/experiences Novell specific? I've got 2 little things that are in the same league in a MS Network.

1. We just can't seem to keep the a connection with an HP 722C. The problem is is that it's local to the system having a problem printing to it. Wierd. We think its the printer and its drivers because it will print just find to a remote HP Laser (not using JetDirect, I think) so plan to replace it with a 1220C. However, don't want to repeat the problem.

2. Have a workstation that keeps losing its net connection. User tasks out to MS apps for price checks, catalog disks, and Word so I can see the kernel getting busy. At times, if he's tasked out and leaves the station for a while, on his return, his Rev app is frozen. Sometimes even screaming something out of the speakers. Other times, his Rev app freezes while he's in it. Disconcerting when customers are lined up 3 deep waiting for invoicing. The oddity is that's it appears progressive - occurences increasing with frequency as time passes. I'm running an experiment to see if the problem lies with the server since they generally leave it up 24/7. I rebooted the server on monday and haven't heard of any problem.

Did I just answer my own question?

Anyway, everybody else runs generally fine. The only difference is this station is a building and 2 hubs (cheap Danpex 10BaseTs) away in the shop. Isolated circuits and UPSes all around.

Still looking for a explanation (beyond the meaning of life).

Charles

View this thread on the forum...