| This is not an official statement.
MR/MEMO is not a high revenue product and in these days of engineering
cutbacks and increasingly aggressive revenue goals, no product is
100% safe. MR/MEMO isn't even a product in most of the world (only in
Sweden and Germany - otherwise it's an ASSET).
Now over to the plans.
In Sweden, there are currently no plans that we know of to retire MR/MEMO or
change its product status. Germany's plans about MR/MEMO's product status
in Germany are unknown to us.
It is a good policy within Digital to *not* go about and talk about other
companies and their products. Verimation should adopt some of this policy too.
They have no way of knowing the status of MRMEMO. It's unclear what they mean
with a "freeze". You could say that MR/MEMO currently is in some kind of
"maintenance mode". That means that there are no fixed plans for a new version
at the moment. Future plans depend on a lot of factors, among them the market
status of MEMO itself.
We do, however, fix problems by issuing patches (see note 5.* in this
conference). If a major problem should occur in the current version (V2.1)
in some way that can't be fixed by a patch (e.g. because of a change in
some prerequisite product such as VMS or MR), we would *very likely*
correct that by creating a new MR/MEMO version. (By "very likely" we mean
that we *will* do it, but we don't have the authority to make a commitment
:-)
It has been stated in this conference before, but deserves repeating: the
MRMEMO developers are currently working with customer paid projects, and
one sure way of getting MRMEMO enhancements is to have your customer
explicitly pay for them. It doesn't need to be expensive, one major customer
in Germany had important modifications made at a cost of only 4-5 man weeks.
The good thing about this model is that the customer gets what he explicitly
wants, and not, as may be the case in a normal product update, 10% changes
that he wants and 90% that he doesn't.
Hopefully this clears the picture.
Anders Olsson,
Stefan Persson
former MR/MEMO developers,
currently part time MR/MEMO maintainers
|
|
I can't really comment on whether it will work or not. If they say so I
guess we'll have to trust them. The customer should be aware though
that he's trodding on virgin ground.
I can think of some disadvantages (pretty big ones too). Please note
that my knowledge of MR/S is limited and ancient, and I do not
guarantee that all of the below statements are correct:
- If you go through SNADS/Disoss (I don't know which component works as
the Transfer Agent) you add another Gateway between MEMO and MAILBUS,
so instead of the direct MEMO->MRMEMO->MAILBUS you go
MEMO->SNADS/Disoss->MR/S->MAILBUS. Each Gateway is bound to have its
limitations, which means, the more Gateways, the less functionality.
- MR/S requires that all MAILBUS users are registered in DDS, whereas
in MEMO this is optional. The reason for this requirement in MR/S is
that SNADS/Disoss *only* allows 8+8 characters (DGN.DEN) in the message
address. This means that the MAILBUS syntax addresses
(USERID@ROUTE[@ROUTE...]) will have to be mapped to DDS records with
SNLOCATION and SNUSERNAME for each MAILBUS user. As far as I know this
applies to X.400 users too, which means that an X.400 message from MRX
will be rejected (!) by MR/S unless the sender (who might be an external
user) is registered in DDS. MEMO however, although based on DGN.DGN
adressing, allows longer addresses through the MEMO/Gateway, so the
strict DDS validation is not necessary.
- To elaborate on DDS validation, MRMEMO has a feature called "address
translation" which means that if a MAILBUS originator/recipient is
found in DDS, then the address will be translated according to the DDS
record, otherwise the message will be transferred with the original
address unchanged. This means in effect that a MEMO user can address a
MAILBUS user using a DGN.DEN, Freeform (given+surname) or pure mailbus
syntax. It also means that a MAILBUS sender will be presented to the
MEMO recipient with a MEMO-type address *if found* in DDS, otherwise
with a MAILBUS-type address.
- MEMO has a sophisticated way of handling notification messages and
the correlation to the original message. The notifications merely
affect a status line which indicates "SENT", "RECEIVED" "FAILED" or
"SELECTED" (read) for each message. A lot of effort has been put into
MRMEMO in order to test this functionality against MAILBUS delivery and
receipt notifications. There is no guarantee (to put it mildly) that
this functionality works as good through MR/S/SNADS/Dissos. It depends
on how well the SNADS/Disoss protocol maps to MEMO/Gateway in this
area. I can tell you that if the MEMO users start to receive individual
notification messages instead, they will be annoyed. As a matter of
fact, they would rather not have the messages confirmed at all. This is
why you can disable requests for notification messages by setting
MRMEMO parameters.
- Please note that I'm not knocking MR/S. There is probably no other
way to implement that Gateway. I just do not trust the SNADS/Disoss
protocol (it really is annoying not knowing what it's actually
called) to be sufficiently transparent and feature-rich. I'm not even
sure the MR/S Gateway was intended to use this way. Maybe you should ask
the people in FORTY2::MAILBUS to comment?
If your customer regards MRMEMO as an "Interim solution", it looks like
a golden opportunity to implement it, and then let them prove that
they can reach the same functionality going through SNADS/Disoss.
|
|
Hi again,
> The impression the customer has been given from Verimation is that the
> MR-GATE product on the IBM will no longer be supported as a new piece
> of code which supersedes it is being developed and that code will work
> directly with MR/S.
That's certainly not the impression that we've got. I'll try and get a
statement from Verimation.
> At the moment we are testing both products ...
>
> A1MAIL -> MRS -> DISOSS -> MEMO
>
> and
>
> A1MAIL -> MEMO -> MEMO -> DISOSS
>
> Ideally we only want one gateway.
I see your point but I think you'll need both or you'll lose
functionality. Have you considered that whether you choose one or the
other of the above configs it means that DISOSS *or* MEMO will serve as
an "extra" Gateway? So in a functional sense you won't get less
gateways, only they will run on the IBM.
Anyway since you're in a position to be able to test both solutions
you should be OK. If you drop a few lines here to tell us your findings
we'd appreciate it.
cheers,
Stefan
|