From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: vmsnet.uucp
Subject: Re: HELP!!! Multiple versions in uucp_spool:d.*
Date: 7 Nov 92 06:39:43 GMT
Organization: St. Peter's College, US

In article <1992Nov6.092136.18184@infocomm.com>, mark@infocomm.com writes:
> In article <1992Nov5.222054.4328@spcvxb.spc.edu>, terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes:
>>   I got bit by this problem yesterday. I deleted the SEQUENCE.NUMBER;1 file
>> and things looked good for a few hours (sequences went down to things like
>> 00C), but the problem seems to be back. My sequence numbers jumped back up
>> to things like 6CQ and I'me getting duplicate versions.
> 
> You certainly DON'T want to do the "$ DELETE UUCP_DATA:SEQUENCE.NUMBER;1"
> too often or you can get duplicate versions of you still have UUCP traffic
> queued based on the "last time" you reset the sequence number.

  Right. However, we'd been running V2.0 for a few months now, and when I saw
the item here which seemed to match my symptoms, I figured I'd try it.

> If you indeed have "new" jobs with sequence numbers of "6CQ" already, then
> something else strange is going on.  "6CQ" represents approximately
> 6*36*36+13*36+17 or 8261 which, although high, should not be close to "O07"
> (32767) which is the largest value that would not cause a problem.

  Yup - I doubt I generated that many batch jobs. In fact, it went straight 
from 00something to 6Csomething.

>>   Is there anything else that could be happening?
> 
> It seems so, but I'm not yet sure what it is.  Exactly what do you mean by
> "getting duplicate versions".  What are some examples of the files in question?
> what is the current contents of UUCP_DATA:SEQUENCE.NUMBER as shown with the VMS
> DUMP command?

  Well, my first warning was a few days ago, when I got automated mail saying
something was wrong. It was very non-descriptive. I don't have any copies as
I thought that deleting the SEQUENCE file would fix it. However, I do have
the logfiles...

p:uucp    h:-       [11/02-21:33:34-204016ae]  STARTUP         (Version cmkrnl-2.0 {Jun 19 1992 15:59:46}) u:UU_RHUX 
p:uucp -< h:-       [11/02-21:33:36-204016ae]   Incoming       (_LTA5348: 19200 bps LT2012/DIALUP.915-9471C) u:UU_RHUX 
p:uucp -< h:rhux    [11/02-21:33:40-204016ae]   Call from      (rhux) u:UU_RHUX 
21:33:43.60       rcv_ctl() xwmax set to 3
21:33:43.79       rcv_ctl() xbmax set to 64
21:33:43.82       rcv_ctl() xwmax set to 3
p:uucp << h:rhux    [11/02-21:33:43-204016ae]   Startup ok     (Protocol: (g, xmt(3/64), rcv(3/64))) u:UU_RHUX 
p:uucp << h:rhux    [11/02-21:33:50-204016ae]   We want to send (S D.spcvxb6CH D.spcvxb6CH newsmgr - D.spcvxb6CH 0666 ) u:newsmgr 
p:uucp << h:rhux    [11/02-21:33:58-204016ae]   File sent ok   (2968 bytes, 5 secs, 594 Cps) u:newsmgr 
p:uucp << h:rhux    [11/02-21:34:00-204016ae]   We want to send (S B.spcvxb6CH X.spcvxbN6CH newsmgr - B.spcvxb6CH 0666 ) u:newsmgr 
p:uucp << h:rhux    [11/02-21:34:03-204016ae]   File sent ok   (69 bytes, 1 secs, 69 Cps) u:newsmgr 
p:uucp << h:rhux    [11/02-21:34:09-204016ae]   We want to send (S D.spcvxb6CI D.spcvxb6CI newsmgr - D.spcvxb6CI 0666 ) u:newsmgr 
p:uucp << h:rhux    [11/02-21:34:26-204016ae]   File sent ok   (9598 bytes, 14 secs, 686 Cps) u:newsmgr 
p:uucp << h:rhux    [11/02-21:34:28-204016ae]   We want to send (S B.spcvxb6CI X.spcvxbN6CI newsmgr - B.spcvxb6CI 0666 ) u:newsmgr 
[so far, so good]
p:uucp << h:rhux    [11/02-21:44:58-204016ae]   We want to send (S D.spcvxb6D0 D.spcvxb6D0 newsmgr - D.spcvxb6D0 0666 ) u:newsmgr 
p:uucp << h:rhux    [11/02-21:45:55-204016ae]   File sent ok   (35481 bytes, 53 secs, 669 Cps) u:newsmgr 
p:uucp << h:rhux    [11/02-21:45:56-204016ae]   We want to send (S B.spcvxb6D0 X.spcvxbN6D0 newsmgr - B.spcvxb6D0 0666 ) u:newsmgr 
p:uucp << h:rhux    [11/02-21:45:59-204016ae]   File sent ok   (69 bytes, 1 secs, 69 Cps) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:06-204016ae]   We want to send (S D.spcvxb6CH D.spcvxb6CH newsmgr - D.spcvxb6CH 0666 ) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:10-204016ae] * They refused our rqst ((SN2) - remote access to path/file denied) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:12-204016ae] * Error in work file ($1$DUA4:[UUCP.SPOOL]C.RHUX_N6CH;2) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:14-204016ae] * Bad line is    (S D.spcvxb6CH D.spcvxb6CH newsmgr - D.spcvxb6CH 0666
) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:15-204016ae]   We want to send (S B.spcvxb6CH X.spcvxbN6CH newsmgr - B.spcvxb6CH 0666 ) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:17-204016ae] * They refused our rqst ((SN2) - remote access to path/file denied) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:20-204016ae] * Error in work file ($1$DUA4:[UUCP.SPOOL]C.RHUX_N6CH;2) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:22-204016ae] * Bad line is    (S B.spcvxb6CH X.spcvxbN6CH newsmgr - B.spcvxb6CH 0666
) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:33-204016ae]   We want to send (S D.spcvxb6CI D.spcvxb6CI newsmgr - D.spcvxb6CI 0666 ) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:38-204016ae] * They refused our rqst ((SN2) - remote access to path/file denied) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:41-204016ae] * Error in work file ($1$DUA4:[UUCP.SPOOL]C.RHUX_N6CI;1) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:44-204016ae] * Bad line is    (S D.spcvxb6CI D.spcvxb6CI newsmgr - D.spcvxb6CI 0666
) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:47-204016ae]   We want to send (S B.spcvxb6CI X.spcvxbN6CI newsmgr - B.spcvxb6CI 0666 ) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:50-204016ae] * They refused our rqst ((SN2) - remote access to path/file denied) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:51-204016ae] * Error in work file ($1$DUA4:[UUCP.SPOOL]C.RHUX_N6CI;1) u:newsmgr 
p:uucp << h:rhux    [11/02-21:46:53-204016ae] * Bad line is    (S B.spcvxb6CI X.spcvxbN6CI newsmgr - B.spcvxb6CI 0666
) u:newsmgr 
[lots more of the same]

  If I did a DIR of UUCP_SPOOL:, I'd see a ;1 and a ;2 of a particular B.host_
seq file, likewise with a D.host_seq file. Sometimes I'd see the ;1 and the ;2
of the C file have a different hostname (batches destined for two different
systems). Sometimes there would only be a single C file - I assume one was de-
leted by whatever job discovered the error that generated the mail messages.

  I wound up deleting all the old batches in UUCP_SPOOL. I didn't reset the
sequence number, and we appear to be proceeding with the 6xx series (we're up
to 6Fx at this point, with similar traffic the last few days, which makes the
leap from 00x to 6Cx even more inexplicable).

  Wait a minute: UUCP is running on one node of the cluster and NEWSSKIM on
another. Is it possible that both nodes tried updating the file at the same 
time and that one node had cached the old value?

Dump of file USER6:[UUCP.DATA]SEQUENCE.NUMBER;1 on  7-NOV-1992 01:32:19.09
File ID (444,17068,0)   End of file block 1 / Allocated 3

Virtual block number 1 (00000001), 512 (0200) bytes

 00000000 00000000 0000000A 34202093 .  4............ 000000
 00000000 00000000 00000000 00000000 ................ 000010
[all 0's]

> Since we originally released UUCP, the only way the file naming scheme has
> changed along these lines (i.e. which hostname is used), was very early on with
> UUX_RNEWS.  I think this was in 1.1 and "fixed" in 1.2.  There is good reason
> for which name is being used for the files that get stored on the remote
> computer.  The sending computer is not sure what "spool directory" management
> scheme is being used on the remote system and how many remote systems the
> remote site is using.  If all sites sending traffic to a particular remote
> system end up dumping their traffic into the same directory AND the file names
> being used are derived from the names of the destination system instead of the
> originating system, there exist much greater likelyhood of file naming
> collisions and what follows then is chaos.  :-)

  Well, nothing says that you have to use the same names both internally and
externally for the files. 8-)

	Thanks,
	Terry