Newsgroups: vmsnet.uucp,vmsnet.mail.mx
Subject: Re: Problems with UUCP and MX
From: mark@infocomm.com
Date: 16 Oct 92 07:17:39 PDT
Organization: INFO COMM - Computer Consulting, Redwood City, Ca

In article <1992Oct14.084936.309@cutler>, john@cutler.com (John E. Babbitt Jr.) writes:
> In article <1bdjbmINNq28@golem.wcc.govt.nz>, brockie@golem.wcc.govt.nz (Roger Brockie) writes:
>>
>> The following is an extract from the uucp_log:uuxqt.log file.
>> Has anyone seen this problem before ?
>> [...]
>> $	    RMAIL DUA12:[UUCP.SPOOL.TOSH]D.TOSH19576; "brockie@med.wcc.govt.nz"
>> %RMS-F-FLK, file currently locked by another user
>> %TRACE-F-TRACEBACK, symbolic stack dump follows
>> module name     routine name                     line       rel PC    abs PC
>> MX_RMAIL        MX_RMAIL                          127      00000033  00001C47
>> $ FAILED_RMAIL:
>> Attempt to send mail to <brockie@med.wcc.govt.nz> failed with status %X1001828C
>> %RENAME-I-RENAMED, DUA12:[UUCP.SPOOL.TOSH]X.TOSH19576;1 renamed to DUA12:[UUCP.SPOOL.TOSH]REMAIL_X.TOSH19576;1
>
> If only I could've seen the first few lines of the uucp log just prior to
> the above, I may have had an answer for you.
>
> I've seen where some uucp software attempts to send the X file first, then
> the D file after.  Of course, the X get processed immediately (or it used
> to in pre-2.0) and one of the two things happen: 1) doesn't find the D.*
> file; 2) Finds the D. file as it's being renamed from a temporary name
> (and it's still locked by the renaming process).  The odds of 2) happening
> is very small, I must admit.
>
> The uucp software that sends the X first then D is called "Coherent".

It might actually be called "InCoherent".  :-)

Seriously, It is might NOT be the uucp transport software that is at fault
for  sending the X. and D. files in the wrong order.  What ever program
created the "C." work file that lists the order of transfer operations
could have listed them in the wrong order.  The program that usually
creates the "C." work file is usually uux which would certainly be
considered "part of the uucp software" but it also could be some other
program as well.

As to above message regarding the failed RMAIL attempt, I think that out
of order arrival of X. and D. files is NOT actually responsible for the
"%RMS-F-FLK, file currently locked by another user" message.  If out of
order arrival was at fault, the expected message would be: "%RMS-E-FNF,
file not found" The reason behind this belief is:  While a file is
arriving, it  is actually named "TM_pid".  Once the the whole file has
arrived, the file  named TM_pid is closed, and then renamed to D.whatever.
The routine that does the rename does a SYS$PARSE followed by a SYS$RENAME.
The SYS$PARSE isn't going to lock the file, and SYS$RENAME isn't either
since it only creates a directory entry. and has no need to lock the file.
Ooops, the next thing that IS done is a SYS$OPEN followed immediately by a
SYS$CLOSE, the purpose of which is to restore the file modify dates to what
it was before the SYS$RENAME, the file would indeed be locked during this
brief operation, so I guess the out of order conjecture is possibly right,
but "file not found" is a MUCH more likely message which would indicate
the X. and D. files transferred in the wrong order.

Mr. Babbitt is certainly right, let's stop guessing and look in the UUCP.LOG
file for the relevant info regarding the transfer of these D. and X. files.

--
Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca
PHONE:	(415)369-9366	UUCP:  decwrl!infopiz!mark or uunet!lupine!infopiz!mark
DOMAIN:	mark@infocomm.com