| 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 |
Folks:
I am new to this conference so I don't know if the "problem" I have
encountered has been addressed here before or if it should be.
In any case, here goes:
I have noticed that for some of the messages that I recieve, the date
indicated as the recieved date is actually the date that the message
was created and/or last modified. I noticed this because when one is
doing an (I)ndex (R)ead look at your messages, items with this problem
stand out because they show up out of order. It seems like they are
sorted and displayed by recieved date, but the date displayed is the
created date.
I have checked this with the SH function.
regards,
Henry
SNOC01::SINGER
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 287.3 | STARS article about the date fields | AIMTEC::WICKS_A | Vote Bill'n'Opus for a weirder USA | Fri Mar 20 1992 16:30 | 106 |
PROBLEM:
The LAST MODIFIED field on an electronic message can
be seen by doing a SH (Show message status) from the EM menu.
If a message was addressed using remote addressing (for example
VALDEZ@A1), the Last Modified field changes once the message has
been delivered to the remote address. This happens even if the
remote address is the on the same system.
ANALYSIS:
The scenario below describes the behavior that has been observed
in reference to the Date fields on an electronic message header.
a. Date Created - This date is set when you type C. It
is never changed.
b. Last Modified - This should be the time the document
was last edited. However, investigation shows that in
the received message, the date is timestamped as the
time the document was created in the recipients file
cabinet.
This is wrong for two reasons:
1. It differs from the ALL-IN-1 documentation,
especially the User's Reference Manual (ALL-IN-1
V2.3), page 5-18. (The customer is using V2.2
ALL-IN-1, but has referenced the 2.3 Documentation
to find reference to the LAST MODIFIED field).
2. On remote messages, it will always be the same as
the Date Posted.
c. Date Sent - This is set when S is typed for Send and
is supposed to show the time when the message was sent
from the originating system. We cannot find an
occasion when this is changed. It seems to match up
with the Date Created.
d. Date Posted - It is supposed to show the time the
receiving system posted the message to the recipients.
Experimentation shows that this is changed at least
twice during the life of a message.
Just after the sender presses S, Date Posted has the
same timestamp as Date Sent. Then, when the Sender runs
and passes the message onto Message Router, this date
is updated to show that time in the Sender's OUTBOX
copy.
Finally, when the receiving system gets the message
from Message Router, this timestamp is updated with the
time the document was created in the recipient's File
Cabinet.
What is being seen is something like the table below:
Time Action Created Modified Sent Posted
==== ====== ======= ======== ==== ======
11:00 Create 11:00 11:00 blank blank
11:15 Edit 11:00 11:15 " "
11:30 Send 11:00 11:15 11:30 11:30
11:45 Sender Runs 11:00 11:15 11:30 11:45
12:00 Fetcher Runs 11:00 12:00 11:30 12:00
The 11:45 action is the last change to the OUTBOX copy and 12:00
action is the only change to the INBOX copy.
SOLUTION:
The User Guide is misleading in the description of the Modified Date
field. The description is only true for local mail.
The behaviour you describe can be explained as follows:
For Remote Mail:
The Posted Date indicates the time the mail was transferred to/from
Message
Router. Thus The Sender's Posted date is the time the remote Sender
ran. This field contains the date/time the message was placed in
the Sender Queue while
waiting for the sender to run. The MR ID indicates that the Sender
has tranferred the message to Message Router.
When the Fetcher runs it retrieves the Mail from MR and creates a NEW
document (it could have come from another Node).
The Created and Sent Date is taken from the Original document(as
maintained in the MR files).
The Posted Date indicates the Date/Time the message was transferred
from MR to ALL-IN-1.
The Modified Date indicates the Date/Time the New Version was
created.
Thus the Modified Date and Posted date will be the same until the
document is modified again.
Note the Modified Date of received mail will only indicate the Original
(Sent)
Document's last modified date if the mail is sent locally.
| |||||
| 287.4 | STARS article about Timezones | AIMTEC::WICKS_A | Vote Bill'n'Opus for a weirder USA | Fri Mar 20 1992 16:34 | 66 |
INFORMATION:
Timestamps in ALL-IN-1 and Message Router
Basically what you start with is a standard called GMT - Greenwich Mean
Time. From this standard you adjust to your specific time zone. You
have to do this in 2 places if you are sending or receiving remote
mail.
The first place is from the Message Management menu in ALL-IN-1
- SM MM CTZ - (this is not done for you automatically by the
installation procedure). The other place is in the Management Service
component of Message Router.
An example :
If it is 11:30 EST then it is 3:30 GMT- because EST = GMT - 4. Message
Router carries mail in GMT time only. If you send a remote message
from
your EST system it would end up in Message Router with a time that is 4
hours behind GMT, therefore you will need to have a time offset of +4
in Message Router. In order to set this up you will need to:
- Stop all components of Message Router
@sys$manager:mb$control stop = (er,ts,dds,ms)
- Run the MB$CONFIG program to set the time offset in Message
Services
@sys$manager:mb$config
MBC> SET MS
MBC> ENABLE MS
MBC> RECOVER MS
you will be asked several questions - just take the defaults
until
you are asked about the timezone offset. Enter the value that
is
correct for your particular timezone (+4 in this example).
- Start all components of Message Router
@sys$manager:mb$control start = (ms,ts,dds,er)
That sets things up for messages going off of your system. Now you
must
convert the GMT Message Router time to EST for ALL-IN-1 so that
messages coming into ALL-IN-1 from Message Router will have the correct
time. To do this you go into ALL-IN-1 - SM MM CTZ and put in the
offset necessary to get from GMT to EST (in this case) which would be
-4 hour (3:30 GMT is 11:30 EST).
to adjust those 2 parameters accordingly.
There have been cases where messages appear to be created after
they were received and other similar type problems. If you use the
above explanation as reference, you can see how easily this could
happen
if all the systems in your network are not set up properly.
Remember that when the time changes in the spring and autumn you have
to adjust those 2 parameters accordingly.
| |||||
| 287.5 | re-stating the problem | SNOC01::SINGER | Sat Mar 21 1992 00:43 | 23 | |
Andrew,
If I had to guess, the former (.3) is written by the CSC person, and the
latter (.4) by the engineer.
I may be wrong, but I don't think the underlying problem has actually
been covered by these messages.
Problem Statement:
The date recieved is NOT the date displayed as recieved when using the
IR function. It would seem that when it goes to display the date it is
pointing to the wrong date (the date last modified), even though it knows
which date to use when sorting the messages for display. (ie. it displays
the messages in the correct order, but with the wrong date displayed).
The message I used to identify the problem with was sent to me from the
same system, same time zone, from an ALL-IN-1 account.
Regards,
Henry
| |||||
| 287.6 | The answer I think | AIMTEC::WICKS_A | Vote Bill'n'Opus for a weirder USA | Sun Mar 22 1992 17:23 | 75 |
Henry,
OK we're getting somewhere and guess what there's a STARS article on
it - see below. The main reason is the one listed in the section
marked "Note" i.e that one attribute is in the DOCdb and the other in
the DAF.
I'd recommend changing the labelling at the top of the Index but this
appears to be the same in v3.0.
P.S You were wrong on guessing who wrote which articles but there is
a striking difference in style isn't there.
Regards,
Andrew.D.Wicks
Index Is Misleading
PROBLEM:
When using the Index Inbox (II) or Index Read (IR) option from the
Electronic Mail (EM) menu in ALL-IN-1 V2.3, the 'Received' date should
be displayed. This is what the heading at the top of the form implies,
but the date that actually displayed is the 'Last Modified' date of the
message. This is misleading because if you create a message
today and send it to a local user tomorrow the 'received' date will
appear to be yesterday.
ANALYSIS:
The field which is displayed is the MODIFIED field in the CAB$ DSAB.
For a message sent locally in ALL-IN-1 this indicates the last time
the message was modified (may be date created, or later date if
subsequent edits where performed). For a remote message this date
indicates the creation date of the document on the local system when
received from Message Router by the ALL-IN-1 Fetcher. Depending
on whether the message was sent locally or remotely the heading
and data displayed may be the cause of confusion. For a Remote
message this is actually the date that the message is received
by ALL-IN-1 on the local system.
SOLUTION:
This has been forwarded to Engineering and the suggestion
to display the actual date the message is received will
be considered for inclusion in a future release.
The data displayed for the Received date on the EM Index forms
is the MODIFIED field in the CAB$DSAB. The value represented in
this field is described above. If you desire you may change the
form to display another more appropriate field value.
The index forms (ie EM$INDEX$READ for the IR option) map to this
CAB$ DSAB field, by defining a field in the phantom data set by the
same name as the field name in the CAB$ data set . The field name in
the Index form is currently named MODIFIED which correlates to the
field CAB$.MODIFIED. This field name may be change to DELIVERED,
in which case it would reflect the data in the field CAB$.DELIVERED.
To change the name of the field on the index form from the FMS editor
menu, select option A (assign field attributes), then option 3
(Specific field), Enter MODIFIED as field name. Then change Field Name:
to reflect DELIVERED.
NOTE:
One caution is that the performance will drop if the above field is
used since it has to go the extended attributes files (DAF) for the
field DELIVERED. The MODIFIED field is stored in the DOCDB, and so II and
IR don't require the added access.
| |||||
| 287.7 | Did we move ? | WAYLND::HOWARD | Hail to the Redskins! | Mon Mar 23 1992 16:42 | 11 |
This looks like it would be fairly easy for the customer to fix. But I notice that the STARS article says: > If it is 11:30 EST then it is 3:30 GMT- because EST = GMT - 4. Message At last check, EST = GMT - 5. Perhaps I have been wrong on this all these years. In a couple of weeks we will change to EDT (Eastern Daylight Time), which is a 4 hour difference from GMT (but still a 5-hour difference from BST). Perhaps that was what the author was thinking of... Ben | |||||