ewp (02/14/83)
I tried asking before but got no replies. Why do some articles have the
phrase "parse date string" in their title? Is this some inside joke, or does
some software add it?
Along the same lines, lately some messages have been ending with a notation
something like: "598 bytes 14 seconds". What gives? Does anyone know?
stumped in netland,
Ed Pawlak
ihuxb!ewprjk (02/15/83)
The "parse date string" comes from readnews when following up. Apparently, there is some overwriting of data space in there that tacks the error mess- age about "Cannot parse date string" on the end. The count of bytes in so many seconds comes right from the UUCP SYSLOG file that tracks data transmissions. How it got in the article is probably a UNIX (as opposed to NETNEWS) problem. Randy King
dmmartindale (02/17/83)
Something like "598 bytes, 14 seconds" could very well be someone's version of uucico getting confused and writing some of its logging stuff to the wrong place - a log of bytes transferred and time elapsed normally goes into /usr/spool/uucp/SYSLOG. "Parse date string" must be a bug, and it's been around a LONG time. Anyone know which of the 3 news systems it's in (A or B news or notesfiles)? Dave Martindale
mark (02/17/83)
"parse date string" is a combination of B news stretching the manual
page slightly and USG UNIX not being very robust. What happens is,
when you do a followup, it uses
mktemp("/tmp/folXXXXXX")
to create a temp file name to edit the followup in. Fine. Now, if
you happen to do a SECOND followup in the same news session, it
executes the same code. But since mktemp overwrites the argument
in place, you have
mktemp("/tmp/folA01234")
which is not documented to work. It happens to work ok in 4.1BSD,
but in USG it seems to clobber the null at the end, resulting in
the string running over into the next character string in memory,
which happens to be "Cannot parse date string". Thus, you get
something along the lines of
inews -t the real title < /tmp/folA012345Cannot parse date string
and since the shell takes out the "< /tmp/folA012345Cannot" part,
you are left with
inews -t the real title parse date string
2.10 has been changed to copy the string literal into a temporary
location and call mktemp on that temporary.essick (02/18/83)
#R:watcgl:-19600:uiucdcs:10600065:000:313 uiucdcs!essick Feb 18 11:55:00 1983 I looked through all of the notesfile source and never found a "parse date string" string. Not even really close. On the other hand, there are two instances of the string "Cannot parse date string" in the 2.8 news source. Someone must be stomping on a pointer. *sigh*. -- Ray Essick, University of Illinois.
seth (02/22/83)
#R:ihuxb:-22200:hp-cvd:7600003:000:333 hp-cvd!seth Feb 18 16:46:00 1983 I've been getting the "received x bytes y seconds" problem also. If anyone knows a solution, could you please mail me or post to the net? At least 3 sites (my two and I assume the site belonging to the base article of this response) would appreciate knowing the answer. --Seth Alford HP Corvallis Division harpo!hp-pcd!hp-cvd!seth
seth (02/23/83)
#R:ihuxb:-22200:hp-cvd:7600004:000:798 hp-cvd!seth Feb 22 15:02:00 1983 (To answer my own question...) The "received x bytes y seconds" problem may be caused by having /usr/lib/cronlog set up improperly. As I understand it, this file is supposed to log all the results of programs run by cron, including uucp or uucico. I don't know about your system, but at least on my systems when cronlog is not set up properly the "received ..." message generated by uucico ends up in files being transmitted. Again, I don't know about your system, but on mine I fixed the problem by ensuring that cronlog exists and that it is not owned by root. If there is someone else out there who knows more about this, don't hesistate to respond. And we should probably move this discussion off net.misc to a more appropriate newsgroup. --Seth Alford HP Corvallis Division hp-cvd!seth