| Regina,
yes this is very strange - maybe you're the first person who tried it?
if so I was the second and I got the same thing i.e a nickname that
looked like
Nickname Entry
Nickname: DEF
Mail Address:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaa@bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
ccccccccccccccccccccccccccccccccccccccccccccccccccccccccc@dddddd
dddddddddddddddddddddddddddddddddddddddddddd
the original wrap at 57 is even weirder when you notice the strange
behaviour on lines 2 and 3 caused by trying to write 78 characters
(see form EM$CNS) to fields REALNAME2, 3 and 4 that are
actually only 64 characters long!!
the real nickname should look like:
Nickname: ABC
Mail Address:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa@
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb@
ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc@
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
I put the '@' characters at the end of the line so you could see what
happened when you use the unmodified form
Now using CM (of course) if you take the form EM$CNS and change the 56
and 78s to 64s
;;.TYPE;;
ARG /OVERLAY/HARD=EM$_CNS_HRD_TITLE/POST="IFEXIT\
WRITE ADD NIENTR NICKNAME = NICKNAME,
REALNAME = #EMAON:64,
REALNAME2 = #EMAON:64:64,
REALNAME3 = #EMAON:64:128,
REALNAME4 = #EMAON:64:192\
GET OA$DISPLAY EM$_CNS_NICKNAME_CREATED"
/PRE= "GET #EMAON = CAB$.FROM_ADDRESS[OA$CURDOC]"
;;ADDRESS1;;
/GET_SAVE = #EMAON:64/HARD=OA$_GBL_HRD_ADD_LINE_1
;;ADDRESS2;;
/GET_SAVE = #EMAON:64:64/HARD=OA$_GBL_HRD_ADD_LINE_2
;;ADDRESS3;;
/GET_SAVE = #EMAON:64:128/HARD=OA$_GBL_HRD_ADD_LINE_3
;;ADDRESS4;;
/GET_SAVE = #EMAON:64:192/HARD=OA$_GBL_HRD_ADD_LINE_4
;;NICKNAME;;
/INVALID=NIENTR.NICKNAME[.NICKNAME]/HARD=OA$_NI_HRD_NICKNAME
You need to tidy up the screen field lengths as well but it appears to
work without it.
Regards,
Andrew.D.Wicks (ex Nicknames developer)
|
| AN does the same.
I have just written an SPR on it:
---
Long nicknames created with the AN option don't work properly.
-------------------------------------------------------------
Reproducable:
EM C create a mail. In the TO: field, do a DDS search, select a long
x.400 address. Then select AN in order to add this address to your
nickname file.
The nickname gets created without error messages.
But if it is more than 56 characters long, it gets wrapped and becomes
invalid.
A TIMA STARS article describes the same problem with the CNS option and
suggests a change to form EM$CNS. I would guess that the same solution
can be applied to form DDS$ADD$NICKNAME.
Let me know if this will be done by the MUPA, or if I should tell the
customer to customize the two forms. They are running on a test system
now and plan to upgrade their production cluster with 3000 IOS users to
v3.0 in a month or two.
---
I now see that I forgot to put the name of the article into my SPR.
It is "V3.0 Creating Nicknames From Long Address Not Working Properly"
in database OA1. (And contains Andrews 5 minute fix.)
Elin
|
| Elin,
Sorry can't talk about any possible future patch in this notesfile
but if you look in ABBOTT::A1INFO you just might see a proposed list
of contents and will then be able to tell what the best course of
action is for your customer. Since you've just reported the AN problem
I think you can possibly make an assumption about the answer -
possibly!
Regards,
Andrew.D.Wicks
|