RUBIN@YKTVMX.BITNET (Bill Rubin) (01/09/90)
Even though it didn't say so in the header, I assume it was Hank Radnowski who wrote: > I did a little experimenting and found that the file that is currently stuck >in SMTP's rdr is 2381 records long and IS in a user hold, but that hold is >mistakenly applied by SMTP itself. If my arithmetic is correct 2381 records >should occupy less than 50 blocks (blksize = 4096). SMTP has over 4300 blocks >available on its A-disk but when I clear the hold and restart SMTP (either by >executing the profile exec or by logging off) the message 'Disk almost full. >Spool file xxxx placed in HOLD status' goes into SMTP's console. No one, >postmaster or otherwise, is ever notified of this condition. > > Am I correct in assuming that this is a bug? Am I correct in also saying >that it is a bug that no one is notified of this condition? Assuming that >enough mass-storage did become available during the normal running of SMTP, >would the hold condition be cleared programatically and the mail file then >processed normally? If not, who is supposed to clear the hold (since nobody >is ever notified of its existence)? > > Hank Yes, it is a bug that the file is held. It can occur on VM/XA systems because the response from Q DISK is off by one character due to 4 digit disk addresses and we mistakenly think that the disk is full. Here is a fix: SMTPBTCH 13QDISK ./ I 08180000 $ 8190000 10000 10/19/89 01:38:05 StartPos : integer; ./ I 08783600 $ 8783700 100 10/19/89 01:38:05 if RdrResponse(.34.) = SpaceChar then StartPos := 30 else StartPos := 31; {we must be running under XA} ./ R 08784200 08784500 $ 8784390 190 10/19/89 01:38:05 if RdrResponse(.StartPos+i-1.) <> SpaceChar then Blksize := Blksize*10 + ord(RdrResponse(.StartPos+i-1.)) - ord(Zero); The question of whether no one is informed is a bug is open to discussion. I think we certainly agree that someone should be notified when a file is left in the reader, and we will consider implementing this in a future release, assuming there is one. Bill Rubin IBM TJ Watson Research