Conference iosg::all-in-1_v30

    Hi,
    
  1. Invalid DAF pointer...
    
    In the DOCDB record there is a DAPOINTER field which should be P to
    denote a private document, A an archived document, or S a shared mail
    message. The error "Invalid DAF pointer" appears when the code finds
    none of these values in the record. The usual cause is that somehow the
    application has lost the currency of the current document.
    
  2. Error in COPY function ... [.msg]zblabla.wpl
    
    When this occurs there is usually another message in the GOLD W buffer
    saying what the error actually was. Common errors would be file not
    found, file protection problems, disk quota problems.
    
  3. emd-w-nocurmess
    
    Similar to 1. A mail function has been attempted but there is no
    current mail message.
    
    Tracing and DEBUG are the main tools for tracking down and solving the
    causes of these problems.
    
    Cheers
    
    Stuart

Maurice,	

Thanks for the reply.


>  1. Invalid DAF pointer...
>    
>    In the DOCDB record there is a DAPOINTER field which should be P to
>    denote a private document, A an archived document, or S a shared mail
>    message. The error "Invalid DAF pointer" appears when the code finds
>    none of these values in the record. The usual cause is that somehow the
>    application has lost the currency of the current document.
>    

Then this does not necessarily indicate a file corruption with regard to DOCDB?

>  2. Error in COPY function ... [.msg]zblabla.wpl
>    
>    When this occurs there is usually another message in the GOLD W buffer
>    saying what the error actually was. Common errors would be file not
>    found, file protection problems, disk quota problems.
>    

Unfortunately, the customized application continues processing, and by the time
it has completed, this message is no longer in the GOLD-W message buffer.

>  3. emd-w-nocurmess
>    
>    Similar to 1. A mail function has been attempted but there is no
>    current mail message.
>    
>    Tracing and DEBUG are the main tools for tracking down and solving the
>    causes of these problems.

Yep, that's exactly what I intend to do if I'm requested to go on-site. In the
meantime I've been looking for common reasons for this particular type of
behavior. Right now it appears that the application has gotten its nickers in a
twist and has somehow lost its curmess pointer.

Thanks,

Cb.

    Re .2
    
> Then this does not necessarily indicate a file corruption with regard to DOCDB?
    
    It never has in my experience. It has always turned out to be an
    application error.
    
> Unfortunately, the customized application continues processing, and by the time
> it has completed, this message is no longer in the GOLD-W message buffer.
    
    The application could use VIEW$ to get all the error messages and
    report them. There are examples in oa$lib:smreorg_jan.scp.
    
    The code to loop through all error messages is:
    
    	for view$:"messages_text" do ...
    
    Cheers
    
    Stuart

The customer just FAXed me a listing of the script file she uses. It basically
issues:

MAIL PUSH
MAIL CREATE/OPEN/NOSEND
MAIL SUBJECT "KUKU"
MAIL TO #ADDRESS 
.
.
.

Then she issues the following command

CAB SET_DRAWER OA$MAIL_DRAWER

On this command she receives:

MESLOCKED, Message currently being accessed by another user

At this point any subsequent MAIL functions fail.

The reason she issued this command was that she wanted to make sure that all
the recipients would receive the message in the MAIN drawer. Since this will
happen anyway, this command is not needed. Actually it wouldn't have any affect
on the recipients in any case.

If we remove the CAB SET command it works fine.

The question is why should she get this error. I tried invoking this same
sequence of commands and do not receive this error. 


Thanks,

Cb.

    Hi,
    
    The order seems to be all wrong. It looks like the customer is trying
    to ensure that mail happens in the default drawer. The CAB SET_DRAWER
    should happen before the mail message is created. Also the SET_DRAWER
    should only be done when the drawer context is not the mail drawer.
    Finally the drawer context should be reset on completion.
    
    For an example of this see script oa$do:GS_DL_FROM_GROUP.SCP
    
    I would guess a NEWDIR is involved. Were this to be the case then if
    the application did CAB SET_DRAWER OA$MAIL_DRAWER after a NEWDIR then
    the document made current would be that of the other user, were that
    user to be logged in.
    
    Cheers
    
    Stuart

Maurice,

>    The order seems to be all wrong. It looks like the customer is trying
>    to ensure that mail happens in the default drawer. The CAB SET_DRAWER
>    should happen before the mail message is created. 
>    Finally the drawer context should be reset on completion.

I agree. She actually had it all wrong. I suggested that she do precisely what
you suggest so that the sender will always have his mail messages (CREATED,
OUTBOX) in his/her MAIN drawer.

>    Also the SET_DRAWER
>    should only be done when the drawer context is not the mail drawer.

Why is this; please explain.

>    I would guess a NEWDIR is involved. Were this to be the case then if
>    the application did CAB SET_DRAWER OA$MAIL_DRAWER after a NEWDIR then
>    the document made current would be that of the other user, were that
>    user to be logged in.

No, there is no NEWDIR involved. However, the MAIN drawer for the user is
shared with another user.

Thanks,

Cb.

>>    Also the SET_DRAWER
>>    should only be done when the drawer context is not the mail drawer.
>
>Why is this; please explain.
    
    It's for performance. The CAB SET_DRAWER is an expensive function
    because it always reopens the DOCDB & DAF files. When the drawer you
    want is already current it gives better performance to avoid the
    SET_DRAWER function.
    
    Cheers
    
    Stuart