Conference 7.286::postscript_printing

This error only shows up when you turn off notification in the Registry.  If 
you haven't done that, you won't see it.  Turn off notification, jam the 
printer, and send a job to the printer, and you will see it.  Some testing 
reveals that the problem may be fixed in NT 4.0, but I have not seen that 
myself. I'm told that the problem happens on MRO-OFFICE-1 constantly, and have 
passed this note on to those who support that system.

The reason why people turn off notification is that it generally sends the 
notification to the person who logged on first with the same last name as the 
person who printed the job.  So Joe Smith in MRO prints a job and Fred Smith 
in REO gets notified.  When Fred complains, the helpdesk tells him he must 
have printed a job in MRO.  "No," he says, "I don't think I ever would."  

I have instructions to turn off notification, but I hate to have someone mess 
up their registry if I made a mistake.  

Ben
(Who still clears this notice 10 times a day in TAY.  You are certainly 
welcome to come here and take a look)

    We're seeing it quite frequently in LKG.
    
    I'm running NT4.0 SP2 Intel tyalking to LPS20.
    
    I'm in one IP subnet (16.22.32.188) and the printer is in another
    (16.20.96.176). The routers that connects things are frequently broken
    or overloaded.
    
    Is there some way to lengthen the timeout value? Perhaps some
    undocumented registry value would do the trick. This would greatly
    reduce the annoyance factor, even if it doesn't fix the underlying
    problem(s).
    
    Is there some way to stop the extremely annoying dialog box? A service
    should NEVER create a dialog box on NT. That's what the error log is
    for. I suppose it's too much to expect Microsoft to change their code
    in our lifetime, but we can hope.
    
    Is there some way the Digital portion of this mess could log something
    to the error log so we can better sort out what's going on? I know we
    can turn on "log everything" but (1) that's to a file and (2) it logs
    much more than necessary. A "the printer subsystem detected a problem
    and MS code is too stupid to produce a reasonable error message so
    here's what they should have told you" error log would be quite nice.
    
    Steveg

I received a memo today that this problem is *not* happening in MRO, 
but it definitely is happening in TAY1.  It doesn't happen in TAY2 
because on one server there is very little printing, and on the other 
two notification is turned on.  When it was turned on, it happened 
constantly.  There is a meeting on right now to discuss "printing 
problems in TAY1", and I'm sure this is one of the major problems.  
The users don't know it, since they don't see it.  They just know 
that their printer won't print from NT, and often the VMS side won't 
print either.  

One issue here is that we have had about 90% turnover in TAY in the 
past year, and virtually all the users have been converted to 
print via NT rather than from PATHWORKS as they were in the past.  In 
some other facilities, people may be grandfathered into PATHWORKS.  
So they don't have the volume that we have. 

Ben 

    Re: .2
    
    After chatting with the remaining implementors, it seems there isn't
    any way to change the timeout value in the code. The suggestions you
    raise are good ones.