[Info-vax] Changing SMTP server presented hostname in UCX

[Bill Gunshannon]

In article <lup62n$ae1$1 at news.albasani.net>,
	Jan-Erik Soderholm <jan-erik.soderholm at telia.com> writes:
> David Froble wrote 2014-09-10 09:42:
>> Jan-Erik Soderholm wrote:
>>> David Froble wrote 2014-09-09 21:15:
>>>
>>>>
>>>> I consider the mod way back where, once a queue was set up, in
>>>> subsequent re-boots of the system, re-defining the queues was not
>>>> required, to be a big mistake...
>>>
>>> Now, if the *queues* does not survive a reboot, what
>>> would you like to happen with any pending *entries*
>>> on those queues ?
>>>
>>> Jan-Erik.
>>
>> Well, I don't know, which is why I'd want to find out what happened before
>> letting anything just run.  But that's just the way I am ..
> 
> If I do a planned re-boot, I definitely do now want to lose
> all pending/timed batch jobs! And there is no reason to "find
> out" anything if I did the re-boot myself...
> 
> And also, it would be a real mess if someone lost tens of
> printouts for a stalled printer ("paper out", or similar)
> just becuse of a re-boot.
> 
> No, the only practical way is of course to let the queue
> database, including all queues and entries, survive a re-boot.
> 

OK, this is a real question from someone who never had to deal with
VMS print queues.

Is communication with the printer bi-directional?  Does the printer
send back a signal that the job has finished physically printing?
If not, based on the amount of memory in many printers today how do
you deal with all the data for a (one or more!) printjobs that has
already reached the printer when someone kicks the plug out :-) or
someother occurance cause the printer to reset?

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>