Conference iosg::all-in-1_v30

    I have set the previous note hidden because it discusses futures.
    
    Regards,
    
    Andrew.D.Wicks

I can guess what was in .1, so I'll avoid that side of things.  (Although as an
aside, I don't see why futures are "verboten", as this conf is only readable by
Deccies, all of whom know the rules for what can be said to customers, plus an
explicit rule of the conf is that no info here may be given directly to
customers...)  Anyway:

The reason port-printers for paper mail don't work in V3.0 is as follows:

Suppose my printer is "PORT" and my MAIDES is "PAPER MAIL".  Someone sends me a
mail while I'm not logged in, and while my printer is turned off.  What should
ALL-IN-1 do with the mail?  Generating a non-delivery because the user isn't
logged in rather defeats the point of having e-mail.  What in fact happened in
V2.4 was that the mail just disappeared: ie actual data loss.

Suppose next that the sender and recipient both have port printers.  If a
recipient's MAIDES / printer is PAPERMAIL / PORT, then which port printer should
the mail print on?  The recipient might expect that as they've specified "their"
port printer, that's where the mail should print.  But when the mail is sent,
the (local, first-class) send operation runs in the context of the sender (ie
the person sending the mail, not the Sender job!), so
the only port printer it knows about is the sender's.  Thus the mail prints
on the sender's printer.  As the sender then has to go and deliver this bit of
paper, I wonder why such sites bother to use e-mail; a typewriter would seem
to be all they need, and I would suggest that we could sell them some
consultancy/training on how better to use their system :-)

On the other hand, second class and remote mail (ie Sender / Fetcher) doesn't
have a user / terminal context, so has no notion of any port printer,
even if both sender and recipient have port printers on their terminals.  In
this case, the mail went to that graet bit-bucket in the sky: ie actual data
loss again.

(Even if the Sender / Fetcher could identify a terminal / port, how would it
know if it was the right one?  The definition of a PORT printer is the printer
attached to the terminal which the user is using.  If the user isn't logged in,
then by definition there is no port printer, and the mail can't be delivered.)

As we all know, customers don't like Actual Data Loss, so in V3.0 we "fixed"
it to disallow mail delivery to port printers, and thus prevent the problem
of data loss arising.  Unfortunately we didn't realise that there were so many
customers using such a daft way of sending mail!  (and let's not get into
finger pointing as to why this info wasn't made known to engineering!)

But "the customer is always right", so obviously a compromise is needed.  I
won't say what the compromise is, as that might be classed as futures and get
my wrists slapped; let's just say it "might possibly be considered for possible
inclusion in a possible future release or patch".  Obscure enough? :-)

Scott

Hi Again,

It just occurred to me that the obvious reply to my last note is "Thanks for
the info, but is there a workaround?"

Unfortunately, the "compromise" itself can't be used as a workaround, as it
involves changes to non-customisable base modules.

My suggestion for a workaround is this: for sites that have users set up as
PAPER MAIL / PORT, the Send option is basically a "print n copies" option, where
n is the number of paper mail addressees.  It would be fairly simple to
customise the Send options to call a script instead of doing the send.

This script then searches the addressee list, adds up the number of paper mail
addressees, and initiates a Print operation to print that many copies on the
sender's PORT printer.  If there are any other addressees, these can then be
sent in the usual manner.

An even simpler workaround is to point out to the user's that when they type S
(Send) they aren't really sending e-mail, they're just printing it out.  So
suggest to them they use the P option instead.  The end result will be the same,
except that the mail would stay in the CREATED folder with STATUS UNSENT; again
it is a trivial customisation to fix this.

Scott

    Re: .3
    
    I once remember submitting an SPR on VMS regarding data loss.  It seems
    that if you send a document to an LN03 device queue while the LN03 is
    turned off, bits dropped out of the RS-232 cable and onto the floor. 
    My question to engineering was if there was any way to have the 
    print-queue stall when the LN03 is turned off so bits don't go away.
    
    The answer from engineering was: "No, because that's the standard."
    
    My point is, that it is quite standard here in the Far East for our
    customers to use this feature of having PAPER MAIL sent to the printer
    attached to their PC.  Now, one of our first major customers here to
    upgrade to ALL-IN-1 Version 3.0 is asking if their users are going to
    have to walk to another building where the network printer is, just to
    get the PAPER MAIL.
    
    I'd submit an SPR asking for this feature to be reinstated, but I'm 
    afraid that the answer I'd get back would be something like:
    
    "No, because that's not the standard."
    
    Life can be cruel...  *;')
    
    Doug                      

Hi,

>> The answer from engineering was: "No, because that's the standard."

Which roughly translated probably meant "This is difficult to do and we
don't have the resources" :-)

>> PAPER MAIL sent to the printer attached to their PC

See .3 for problems identifying "their" PC, why the data gets lost, etc, etc

>> one of our first major customers here to upgrade to ALL-IN-1 Version 3.0
>> is asking if their users are going to have to walk to another building
>> where the network printer is, just to get the PAPER MAIL.

With base ALL-IN-1, yes.  But in .3 I did try and drop some hints about what
might possibly change if there are any patches or further releases of ALL-IN-1,
which of course I can neither confirm nor deny here... :-)

>> I'd submit an SPR asking for this feature to be reinstated

Already been done.

>> I'm afraid that the answer I'd get back would be something like:
>> "No, because that's not the standard."

From a puritanical point of view, that is the right answer, as they aren't
using the system in the way it was intended to be used.

However a pragmatic answer would be that we should do whatever the customer
wants.  The rules of the conference prevent me saying whether we are in fact
doing what the customer wants in this instance... but let's just say I can sleep
soundly over this issue :-)

Scott

    Alright.  Until there is an SSB or patch resolution for this one that
    will bring back customer satisfaction, in the mean time is there any
    kind of a "formal statement" from engineering we can issue to our 
    customers explaining why this "bug" was removed?
    
    If no, then I suppose I'll have to resort to massaging .3 to create a
    formal statement from the field, unless someone out there does not
    thing that is a wise idea.
    
    Doug

>    Alright.  Until there is an SSB or patch resolution for this one that
>    will bring back customer satisfaction, in the mean time is there any
>    kind of a "formal statement" from engineering we can issue to our 
>    customers explaining why this "bug" was removed?

    Contact the ALL-IN-1 Product manager - Dave Holt @reo  (IOSG::HOLTD)
    
    /Paul.

    >> massaging .3
    
    If you do this, I think you should also include the info on suggested
    workarounds in .4, so the customers realise there are simple ways they
    can retain the functionality with which they are familiar, and that
    they don't need to walk to the network printer in another building.
    
    However, as Paul says, in the first instance you should contact the
    product manager.
    
    Scott
                   

    Re. 7 (Doug)
    
    You may not to need to do any massaging - though what you do in your
    spare time is of course up to you (:==:) since ALL-IN-1 v3.0-1
    is now of course a real shipping product (except via US SSB apparently)
    one of the Engineers is now allowed to say whether or not this was
    indeed fixed in that patch.
    
    regards,
    
    Andrew.D.wicks       

    Re: .10
    
    So was it?
    
    Joe

    JOE,
    
    Oh I couldn't possibly answer for Engineering - You could get
    a copy of v3.0-1 and see for yourself.
    
    Regards,
    
    Andrew.D.Wicks