[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

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

1917.0. "TM and long addresses??" by STKAI2::PSVENSSON () Tue Dec 08 1992 09:47

    After upgrade to ALL-IN-1 3.0 we have problem with a very
    lot of messages in Inboxes with status NOTED. This occours from
    mail created in TM subsystem, after read when a record shall be
    written to the meeting file.
    
    As far as I understand the adress length has been increased from
    30 to 512 characters in 3.0. We suggested the users to always use
    DDS to pick up the addresses when using TM adressing.
    This works fine for addresses up to 33 characters then it's cut
    and the user get a Message Delivery Report from MTS.
    
    eg. areschoug.bengt@a1stkai2@stkmts@s    (where is should be @soo at
    end)
                        
    
    I checked the new file for "long" adresses ATTENDEE_OVERFLOW.DAT
    and it's cut after 33 characters there as well.
    
    This begins to be a frustration now and people really want to
    use TM to book people at remote systems.
    
    No customizations has been applied the SCHDMA form.
    
    
    P-O Svensson, IS Stockholm

T.R Title User Personal
Name Date Lines

1917.1 Documented in the release notes and STARS AIMTEC::ZANIEWSKI_D Why would CSC specialists need training? Tue Dec 08 1992 13:07 54

T.R	Title	User	Personal Name	Date	Lines
1917.1	Documented in the release notes and STARS	AIMTEC::ZANIEWSKI_D	Why would CSC specialists need training?	`Tue Dec 08 1992 13:07`	54
	I tried my best to have this fixed before v3.0 shipped. Dave Zaniewski Response To Event When Area Routing Used Cannot Be Read By Scheduler PROBLEM: If you create an event notice and address it to an address that is more than 30 characters in length, when you try to read the response there are problems. Create the event TM EV C address it to SMITH_D@A1@CALLQ@OASS@CALLQ then send it The response is read, and the return address is SMITH @DIM @DIMUND. When the message gets back to the original node (i.e., DIMUND), try reading it and the follwoing problems occur: 1) The terminal hangs for about 2 minutes, presumably because you have a large ATTENDEE.DAT (copied from another system) then the following displays: "%OA-E-CMATNDWRITERR, Error occurred writing to the attendee file" 2) The message status goes to NOTED and this message can't be read or deleted. Attempts to read or delete this produces the hang described in #1. ANALYSIS: This problem affects MTS addressing, when 'area routing' is implemented. On receipt of event replies the TM code currently attempts a direct indexed read of the ATTENDEE file using the MEETING_POINTER + FROM_ADDRESS from the current mail message (which may have been 'area routized'). If this fails begin a sequential search starting from a point indicated by the date and time of the current MEETING_POINTER of the ENTIRE ATTENDEE file looking for an exact match between the FROM_ADDRESS and the ATTENDEE_NAME field contained in the ATTENDEE file. If this fails (after a long pause...) it will signal the error above. SOLUTION: This has been reported to Engineering. It appears that the problem cannot be easily resolved as it requires a major change to the design of TM, however doing nothing leaves the customer in the situation where users will have mail messages that they cannot get out of their INBOX (every read fails and leaves the mail in a NOTED status), which is not the normal situation. The only workaround requires the user to have CMD privilege to set the DELETE flag of the message to Y so that you can delete it and this will not be an acceptable workround to many customers.

        I tried my best to have this fixed before v3.0 shipped.
        
        Dave Zaniewski
        
Response To Event When Area Routing Used Cannot Be Read By Scheduler

PROBLEM:

If you create an event notice and address it to an address that is more than 30
characters in length, when you try to read the response there are problems.

Create the event
TM EV C
address it to SMITH_D@A1@CALLQ@OASS@CALLQ
then send it

The response is read, and the return address is SMITH @DIM @DIMUND. When the
message gets back to the original node (i.e., DIMUND), try reading it and the
follwoing problems occur:

1) The terminal hangs for about 2 minutes, presumably because you have
a large ATTENDEE.DAT (copied from another system) then the following
displays:

 "%OA-E-CMATNDWRITERR, Error occurred writing to the attendee file"

2) The message status goes to NOTED and this message can't be read or
deleted.  Attempts to read or delete this produces the hang described
in #1.


ANALYSIS:

This problem affects MTS addressing, when 'area routing' is implemented.

On receipt of event replies the TM code currently attempts a direct indexed
read of the ATTENDEE file using the MEETING_POINTER + FROM_ADDRESS from the
current mail message (which may have been 'area routized').  If this fails
begin a sequential search starting from a point indicated by the date and time
of the current MEETING_POINTER of the ENTIRE ATTENDEE file looking for an exact
match between the FROM_ADDRESS and the ATTENDEE_NAME field contained in the
ATTENDEE file.  If this fails (after a long pause...) it will signal the error
above.

SOLUTION:

This has been reported to Engineering. It appears that the problem cannot be
easily resolved as it requires a major change to the design of TM, however
doing nothing leaves the customer in the situation where users will have mail
messages that they cannot get out of their INBOX (every read fails and leaves
the mail in a NOTED status), which is not the normal situation. The only
workaround requires the user to have CMD privilege to set the DELETE flag of
the message to Y so that you can delete it and this will not be an acceptable
workround to many customers.