| Title: | *OLD* ALL-IN-1 (tm) Support Conference |
| Notice: | Closed - See Note 4331.l to move to IOSG::ALL-IN-1 |
| Moderator: | IOSG::PYE |
| Created: | Thu Jan 30 1992 |
| Last Modified: | Tue Jan 23 1996 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4343 |
| Total number of notes: | 18308 |
Regarding the conversion process of nicknames.dat to oanicknames.dat...
One of our customers is running ALL-IN-1 2.4 and has customized
nicknames by modifying the length of the REALNAME field in NIENTR.
He is planning to upgrade to 3.0 soon.
We tested a conversion of nicknames with a realname field
of 75 characters and it appears to have truncated the realname field
back to 47 characters.
We've devised a workaround for this that will prevent the conversion
from taking place and the customer will do the convert using another
method. The question is, does the conversion procedure
do anything besides converting the nicknames file and deleting
NICKNAMES.DAT that isn't apparent and should be done prior to a user
running 3.0?
Thanks,
Angela
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 967.2 | More lengthily (is that a word?)... | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Wed Jul 01 1992 09:27 | 15 |
The form NIENTR that maps the Nicknames file is marked as a mandatory
chnage by the CART, so presumably the customer knew they had to do
something in advance of the installation. There's a long explanation (I
should know, I wrote it!) about how to handle customised entry forms
that map data files that are going to be converted. I assume that's
what you based your workround on :-)
For those who can't get to the code, basically it checks if you have
enough quota to hold the new copy of the file, does the conversion, and
sets a PST symbol ($EM_NICKNAME_CONVERT) to show it's been done.
The conversion is just a BLISS way into the same code as
<OA$CNV_CONVERT would call from the API.
Graham
| |||||