LUSGR@VAX1.CC.LEHIGH.EDU (STEVE ROSEMAN) (01/05/90)
I have just upgraded to V5.9c from V5.8b and I have several comments/problems.
1. The NNTP batch file changed names again! (From NEWS.BATCH to NNTP.BATCH
to NNTP_pid.BATCH. At first I thought of this as a minor annoyance,
remedied by changing the RENAME in my batch job. But, NOOO, it has
caused real problems. Previously I went through some pains to ensure
the ADD FILE file.name.*/DELETE got the files in order as received,
with "RENAME NNTP.BATCH.* NNTP.REVBAT.". That reversed the versions
(*.*.high became *.*.1, *.*.-1 -> *.*.2, etc.) Now, when I do a
"RENAME NNTP*.BATCH.* NNTP.REVBAT.", the files end up in an order
depending on the NNTP job's PID! I am getting an annoying number of
followups before seeing the original message.
I will (unless someone else has done it) write and sent out code
to make the name something like NNTP_900104_125631_03AB.BATCH.
(that's NNTP_yymmdd_hhmmss_pid.BATCH) Hopefully in a very few days..
2. After OPEN MAIL and deleting an item, I got strange problems. Once
I got something like 'Bad Block Address' messages when I tried to
read items after the delete, and the other time the newsgroup
directory was totally messed up.
3. Does anyone else have problems with keypad mode being lost after
spawning or posting? I use MG, and when I return to NEWS, my
KP7 is 7, etc. I suspect an SMG$ call may be necessary on return.
Comments?
4. In NNTP_FEED.C, there is a NNTP_MAX_OFFER (??) definition of 500 items
to send at one time. I often will have many more. Is there a reason
it is set so low?
Otherwise, I am very happy with the package, really!
Steve
-------------------------------------------------------------------------
Steve Roseman
Lehigh University Computing Center
LUSGR@VAX1.CC.Lehigh.EDUgih900@CSC.DNET (Geoff Huston) (01/20/90)
>I have just upgraded to V5.9c from V5.8b and I have several comments/problems. > >1. The NNTP batch file changed names again! (From NEWS.BATCH to NNTP.BATCH > to NNTP_pid.BATCH. At first I thought of this as a minor annoyance, > remedied by changing the RENAME in my batch job. But, NOOO, it has > caused real problems. Previously I went through some pains to ensure > the ADD FILE file.name.*/DELETE got the files in order as received, > with "RENAME NNTP.BATCH.* NNTP.REVBAT.". That reversed the versions > (*.*.high became *.*.1, *.*.-1 -> *.*.2, etc.) Now, when I do a > "RENAME NNTP*.BATCH.* NNTP.REVBAT.", the files end up in an order > depending on the NNTP job's PID! I am getting an annoying number of > followups before seeing the original message. > > I will (unless someone else has done it) write and sent out code > to make the name something like NNTP_900104_125631_03AB.BATCH. > (that's NNTP_yymmdd_hhmmss_pid.BATCH) Hopefully in a very few days.. Here's my solution:... NNTP_SERVER.C /* file names - change this line */ #define NEWSBATCH "NEWS_MANAGER:NNTP_%s_%X.BATCH" /* new procedure */ static char timestr[14]; static char *time_str() { int ctime; struct tm *stm; time(&ctime); stm = localtime(&ctime); sprintf(timestr,"%02d%02d%02d%02d%02d%02d", stm->tm_year,stm->tm_mon,stm->tm_mday,stm->tm_hour,stm->tm_min,stm->tm_sec); return(timestr); } /* ...... */ /* char batch[] was previously declared as a local var to add_item */ static char batch[FILE_STRLEN] = ""; static add_item(fn,mode,msgbuf,stm) char *fn; int mode; char *msgbuf; int stm; { FILE *fpr, *fpw; char line[BUFF_STRLEN], batch[FILE_STRLEN]; struct stat sbuffer; if (mode == POST) return(post_add_item(fn,msgbuf,stm)); if (!(fpr = fopen(fn,"r"))) { strcpy(msgbuf,"File handler error in NNTP Server."); return(0); } if (!*batch) sprintf(batch,NEWSBATCH,time_str(),getpid()); if (!stat(batch,&sbuffer)) { if (sbuffer.st_size > NEWS_BATCH_SIZE) { sprintf(batch,NEWSBATCH,time_str(),getpid()); fpw = fopen(batch,"w","alq=30","deq=30"); } else if (!(fpw = fopen(batch,"a"))) { sprintf(batch,NEWSBATCH,time_str(),getpid()); fpw = fopen(batch,"w","alq=30","deq=30"); } } else { sprintf(batch,NEWSBATCH,time_str(),getpid()); fpw = fopen(batch,"w","alq=30","deq=30"); } if (!fpw) { strcpy(msgbuf,"File handler error in NNTP Server."); return(0); } fprintf(fpw,"#! rnews %d\n", (ihave_size > 0 ? ihave_size : 1)); while (fgets(line,BUFF_STRLEN,fpr)) fputs(line,fpw); fclose(fpr); fclose(fpw); strcpy(msgbuf,"Item successfully spooled."); while (!delete(fn)); return(1); } that should do the trick - it will be included in the next release. >2. After OPEN MAIL and deleting an item, I got strange problems. Once > I got something like 'Bad Block Address' messages when I tried to > read items after the delete, and the other time the newsgroup > directory was totally messed up. any shots at what is going wrong?? >3. Does anyone else have problems with keypad mode being lost after > spawning or posting? I use MG, and when I return to NEWS, my > KP7 is 7, etc. I suspect an SMG$ call may be necessary on return. > Comments? I'm interested in any comments as well! >4. In NNTP_FEED.C, there is a NNTP_MAX_OFFER (??) definition of 500 items > to send at one time. I often will have many more. Is there a reason > it is set so low? To limit the connect time for any single session - make it higher if you are on a local net, or on a high bandwidth trunk to the NNTP feed node. cheers, Geoff
gih900@csc.anu.oz (Geoff Huston) (01/23/90)
In article <9001191517.AA14344@uunet.UU.NET>, munnari!anu.anu.oz.au!gih900@CSC.DNET (Geoff Huston) writes: > Here's my solution:... > > NNTP_SERVER.C > > /* file names - change this line */ > #define NEWSBATCH "NEWS_MANAGER:NNTP_%s_%X.BATCH" > > /* new procedure */ > > static char timestr[14]; > > static > char *time_str() > { > int ctime; > struct tm *stm; > > time(&ctime); > stm = localtime(&ctime); > sprintf(timestr,"%02d%02d%02d%02d%02d%02d", > stm->tm_year,stm->tm_mon,stm->tm_mday,stm->tm_hour,stm->tm_min,stm->tm_sec); > return(timestr); > } > /* ...... */ > > /* char batch[] was previously declared as a local var to add_item */ > > static char batch[FILE_STRLEN] = ""; > > static > add_item(fn,mode,msgbuf,stm) > char *fn; > int mode; > char *msgbuf; > int stm; > { > FILE *fpr, > *fpw; > char line[BUFF_STRLEN], > batch[FILE_STRLEN]; the above two lines are WRONG!! that should be: char line[BUFF_STRLEN]; i.e. batch is NOT a local variable! sorry bout that - cheers, Geoff