Conference iosg::all-in-1_v30

	Shalom, Chaim!

	Re: #1 --

	Could you explain what *does* happen when she tries to delete an event?
Is the event past or future?  Is she the scheduler of the event?  Is she using
Set Owner at all?

	Re: #2 --

� 2. Every time she creates an event with attendees, no matter who she invites,
�    she always gets the same two attendees with a "Y" immediately.

	First of all, is this an uncustomized system?  For instance, they aren't
using SES, or some other customizations, are they?  (I realize that this is
the Hebrew implementation; you might want to check with Suzy Doty about any
"strangeness" occurring...)

	Next, could you clarify something:  when you say that she always gets
the same two attendees, do you mean in the scrolled region of the argument form
(SCHDMA)??  If that's the case, then my guess is that the scrolled DSAB
(CAL$SCROLL_ATTENDEES) isn't being cleared from the last time.  (This is a
common error when customizing TM.)  Turn on tracing, and check for a function
CAL(ENDAR) CLEAR_ATTENDEES being executed.

	Re: #3 --

	What do you mean by "erratic"?  What *does* happen?  Is it only related
to events she has scheduled?  Or tried to delete?  Or has had problems with in
the past?

	I wish I could offer some other suggestions; but without more specific
information, it's difficult to tell.

	F

	P.S.  Hope you're feeling better...

    Thanks Frank,
    
    >Could you explain what *does* happen when she tries to delete an
     event?
    
     Nothing.... no message ... the event just remains
    
    >Is the event past or future?  
    
     I believe neither works.
    
    >Is she the scheduler of the event?  Is she using Set Owner at all?

     She does use SET OWNER for her boss's account, but the problem occurs
     with regard to her calendar
    
    
    >	First of all, is this an uncustomized system?  For instance, they
    >aren't using SES, or some other customizations, are they?  (I realize
    >that this is the Hebrew implementation; you might want to check with
    >Suzy Doty about any "strangeness" occurring...)
    
     No customization within the TM system

    >	Next, could you clarify something:  when you say that she always
    >gets the same two attendees, do you mean in the scrolled region of the
    >argument form (SCHDMA)??  If that's the case, then my guess is that the
    >scrolled DSAB (CAL$SCROLL_ATTENDEES) isn't being cleared from the last
    >time.  (This is a common error when customizing TM.)  Turn on tracing,
    >and check for a function CAL(ENDAR) CLEAR_ATTENDEES being executed.

     The error is NOT within the SCHDMA form. This form displays correctly
    and she can enter any attendee that she wants. However, no matter who
    she entered as attendee, when she READS the event she sees two
    consistant attendees who have "answered" YES, though no mail was sent
    to any attendee.
	
    >	What do you mean by "erratic"?  What *does* happen?  Is it only
    >related to events she has scheduled?  Or tried to delete?  Or has had
    >problems with in the past?

     While trying to navigate on the calendar grid, the movements will jump
    around; she'll be at the 3rd and try to move one day backwards to the
    2nd and it will jump back to the previous month.
    
    >	P.S.  Hope you're feeling better...

    Much better, thanks...
    
    Keep em comin ...........
    
    Cb.

�     The error is NOT within the SCHDMA form. This form displays correctly
�    and she can enter any attendee that she wants. However, no matter who
�    she entered as attendee, when she READS the event she sees two
�    consistant attendees who have "answered" YES, though no mail was sent
�    to any attendee.

	Well, here's the part that bothers me the most.  Because if we ass/u/me
a normal (!), uncustomized TM system, where the user is working with her own
calendar, and scheduling meetings for herself, then we have a fairly simple
situation.

	The list of attendees is going to be created on form SCHDMA, and saved
in the scrolled DSAB CAL$SCROLL_ATTENDEES.  Later in the TMAPMEC script, a
CALENDAR SCHEDULE MEETING (or CALENDAR SCHEDULE APPOINTMENT, if there are no
attendees) will be done.

	The only place that CALENDAR SCHEDULE MEETING gets its list of attendees
is from the CAL$SCROLL_ATTENDEES DSAB.  Therefore, what I'd advise that you do
is to look at this DSAB at various times during the Create process.  It's easy
to do; whenever you want to look at it, just do something like:

	<FOR CAL$SCROLL_ATTENDEES DO GET .%WHOLE

	Some places you might look at this:

	o  From the Events menu, just before you do a Create
	o  From the SCHEDMUIB form, just before you go to SCHDMA (use Gold
	   Keypad 7 to enter Command mode)
	o  From the SCHDMA form, after you've entered some names
	o  From the Events menu, *after* you do a Create

	The entire process of scheduling the meeting, putting the entry into
your own calendar, placing appropriate entries into MEETING.DAT and ATTENDEE.DAT
and sending mail messages is all done internally within the CALENDAR SCHEDULE
MEETING function.

	One other thing you might want to check:  Which attendees *really*
got scheduled (not which ones received mail, but which ones were placed in
ATTENDEE.DAT for that meeting; they should be one and the same, but this sounds
like a wierd situation).  To check that, you'll want to look up all entries in
ATTENDEE.DAT that have the same meeting pointer.  Do something like:

     <FOR CAL$ATTENDEE WITH .%KEY = #CAL_MEETING_POINTER DO GET .ATTENDEE_NAME

	You should see only the correct attendees (i.e., the same ones that
were listed in CAL$SCROLL_ATTENDEES).

	HTH,

	F

        I believe you've been effected by the calendar corruption bug. 
        There are some data pointers in the .A1CAL file that are incorrect
        and probably a record or two in the system files that are bad.
        
        .A1CAL file layout
        0-15	start date & time + uniqueifier
        16-30	end date & time + 000
        31-60	scheduler
        61-76	pointer to record in MEETING.DAT
        77	event type indicator (M or A)
        
        Write a short program to compare characters 0-11 with 61-72 in
        each record.  Also test for all an M in position 77 and the
        scheduler or MEETING.DAT pointer being missing.  You should find
        one or more of these.
        
        The select operation (and GOLD arrows) use the start date & time
        plus uniquifier to find an entry in user calendar.  For a
        meeting, the pointer to MEETING.DAT is checked and that appears to
        be where the finally selected date comes from.
        
        There is, most probably, a record at the start of MEETING.DAT or
        ATTENDEE.DAT that ia partially or completely blank.  This also
        needs to be removed.
        
        Dave Zaniewski

    This problem keeps reoccurring for ONE particular user.
    
    I had created a NEW user.a1cal for her, and for several days everything
    was fine. Then the same problem started to reoccur.
    
    I am going to visit the customer tomorrow, and I still haven't tke
    slightest idea what is happening.
    
    Thanks,
    
    Cb.

	Sounds like your best bet is going to be to write some "synchronization"
test scripts, something along the lines of what's been mentioned in the previous
replies.  I think others have already done this sort of thing, but since I'm not
sure where to get my hands on it, I'd probably just write the thing from
scratch.

	Basically, you just want to insure that all of the TM files are in
synch.  And since you seem to be able to pin this down to a single user, that
should make it easier, because you probably won't have to check everyone's
.A1CAL file.

	So write some code that will process through CAL$CALENDAR, and insure
that every appointment (i.e., event with no attendees) has its flag set to "A",
has its meeting pointer cleared (i.e., no attendees), etc.  Then go through
CAL$MEETING and CAL$ATTENDEE to see that *they* are in synch.  To simplify
things, you could start by looking only at those events where your "problem"
user is the scheduler -- since that would narrow down the keys of the Meeting
and Attendee files.  Make sure, for instance, that there's nothing in Meeting
or Attendee that is *scheduled* by that person, but which doesn't appear on
their calendar.

	Finally, you could check *all* events for which that person is an atten-
dee, and see if those events are, indeed, on their calendar correctly.

	It sounds drastic, but it's not that tough.  A couple of FOR loops will
get you going.  I tend to agree with Dave's reply re: file corruption, espec-
ially when you say that a new .A1CAL file seems to clear up the problem, at
least temporarily.

	Good luck, and if you devise any particularly useful TM tools, please
let us know!  We'll give you all the credit!!!   8^)

	F

        Sounds like your user is experiencing the same problem I see
        several times a week.  I wrote the following command procedure to
        detect it.  If the .A1CAL is in a subdirectory of SYS$LOGIN for
        the user, place the command procedure is SYS$LOGIN and execute it. 
        A CALENDAR.ODD file is produced that contains interesting events
        to examine.  I usually wind up removing the records from the
        .A1CAL file.
        
        Dave Zaniewski
        
$!	assume the file is in the subdirectory of SYS$LOGIN
$calendar=f$search("[.*]*.a1cal")
$!	
$!	open the calendar file
$open/read cal 'calendar
$!
$!	create a temporary file to write the results to and open it
$create sys$login:calendar.odd
$open/append odd calendar.odd
$!
$!	start of read the next record loop
$LOOP:
$read/end_of_file=lastone cal record
$!
$!	gather some data
$type=f$extract(77,1,record)
$key=f$extract(0,16,record)
$meet=f$extract(61,16,record)
$calpoint=f$extract(0,12,record)
$meetpoint=f$extract(61,12,record)
$scheduler=f$extract(31,60,record)
$!
$!	check the information just read
$!		we don't care about events with no attendees
$!		check for two start date/times for the matches
$xyz="''type'   ''calpoint'   ''meetpoint'"
$sh sym xyz
$if type .nes. "M" then goto loop
$if calpoint .nes. meetpoint then goto odd
$if scheduler .eqs. "" then goto odd
$goto loop
$ODD:
$write odd "''key' ''meet'"
$goto loop
$!
$!	clean up
$LASTONE:
$close cal
$close odd
$exit

    I just returned from the customer site. I used all the
    suggestions/ideas from the replies. Here are my findings:
    
    1. Using the command procedure in .7 did uncover two suspicious meeting
    records. One had a definite mismatch between the start date and the
    meeting pointer, the other was missing a meeting pointer completely.
    
    I deleted these records.
    
    2. MEETING.DAT contained a very suspicious records which I deleted. It
    was the first record in the file and seemed to contain an empty key
    field.
    
    3. ATTENDEE.DAT contained two suspicious records which I deleted. One
    seemed to be a bunch of NULLs, the other seemed to contain an empty key
    field.
    
    4. Alphabetically this user (ANGELA) is the FIRST. This is the only
    thing which sets her apart form other users. This together with the
    fact that any suspicious records were being generated at the beginning
    of the file led me to do the following. I created a new user named
    AAAAAAA and created an event with attendees. This user will NOT be
    used, ever. If the reason that ANGELA was being corrupted had anything
    to do with the fact that alphabetically she was first, will now have
    been changed. 
    
    I still haven't the slightest idea what is actually happening. 
    
    Thanks,
    
    Cb.

        Looks like your user knows the magic keystroke sequence.  We've
        got one person in the CSC who produces the same result on a
        regular basis.  It has something to do with the interaction of
        multiple accounts scheduling events at the same time and users
        reading/not reading the event notices.  SRE and conflicts are also
        part of the puzzle.  The problem is still present in v3.0.
        
        Dave Zaniewski

	Dave,

	Are you referring to the problem with the MEETING_POINTER:30 and the
uniquifier?  Because we picked that up on some of our SES update stuff and it
was fixed (?) in BL122C.  What base level of Diamond are you running at the
CSC?  We can't get it to happen here.  Can you supply the "magic keystrokes"?

	F

        Hi Frank,
        
        I wish I had the magic keystrokes.  That's one of the things I'll
        be working on in the next few weeks.  We've been running BL122D
        and experiencing the problem.  At least my special user has 8-) 
        I've had him running with trace on for about a week, without
        success.  The time he forgets to turn trace on whamo!
        
        Dave Zaniewski