home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / bit / listserv / netnwsl / 321 < prev    next >
Encoding:
Text File  |  1992-12-15  |  1.5 KB  |  32 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!CUNYVM.BITNET!BIGCU
  3. Message-ID: <NETNWS-L%92121517133878@VM1.NODAK.EDU>
  4. Newsgroups: bit.listserv.netnws-l
  5. Date:         Tue, 15 Dec 1992 18:03:07 EST
  6. Sender:       NETNWS-L Netnews List <NETNWS-L@NDSUVM1.BITNET>
  7. From:         Bill Gruber <BIGCU@CUNYVM.BITNET>
  8. Subject:      Re: VLIB's getting corrupted...
  9. In-Reply-To:  Message of Tue, 15 Dec 1992 11:03:48 EST from <CJS@psuvm.psu.edu>
  10. Lines: 20
  11.  
  12. On Tue, 15 Dec 1992 11:03:48 EST Christopher Sacksteder said:
  13. >I am changing VLIB EXEC to fail on an ADD request when the member name is
  14. >longer than 222.  By experimentation, this seems to be where VLIBCOMP
  15. >fails in parsing a member header (not sure why).  A limit that is easier
  16. >to identify is 256, which is the maximum sort field length for RXQSORT
  17. >(called whenever a member is added).
  18.  
  19. The funny thing about all this is that in the NETNEWS MSGIDS file the
  20. msgid is truncated to around 133 anyhow.  Is there any point to putting
  21. the long msgid into the VLIB in the first place if it is truncated in
  22. NETNEWS MSGIDS file?
  23.  
  24. Also need to point out that even though the msgid is truncated, the LRECL
  25. of that RECFM=F file continues to grow.  Our msgid file is close to
  26. 400,000 records.  Up the lrecl by 10 or so and all of a sudden we're
  27. talking another 4 meg of disk space for all that extra unused white space.
  28. (OK, it's unused black space if you are running reverse video).
  29.  
  30. Bill Gruber
  31. City University of New York Computer Center
  32.