Xref: utzoo comp.unix.questions:10951 comp.unix.wizards:13898
Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-lcc!ames!husc6!rutgers!att!mtunb!jcm
From: jcm@mtunb.ATT.COM (was-John McMillan)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: Accounting woes for HCX/UX 3.0
Summary: Read /usr/include/sys/acct.h
Keywords: comp_t
Message-ID: <1356@mtunb.ATT.COM>
Date: 6 Jan 89 14:31:01 GMT
References: <207@h.cs.wvu.wvnet.edu> <8675@alice.UUCP>
Reply-To: jcm@mtunb.UUCP (was-John McMillan)
Organization: AT&T ISL Middletown NJ USA
Lines: 26

In article <8675@alice.UUCP> debra@alice.UUCP () writes:
>In article <207@h.cs.wvu.wvnet.edu> fuhrman@b.coe.wvu.wvnet.edu (Cris Fuhrman) writes:
...
>>has a serious problem with the size of its data types for things like
>>KCORE minutes and stuff like that.  These values appear negative in the
>>reports (daily and monthly) for userids with large values (i.e. the values
>>overflow causing the sign bit to come on)...
...
>The kernel keeps the time in some weird format, mainly to avoid floating-
>point operations and still have fractional numbers. This format exists for
>historical reasons I believe (dating back to when float operations were
>slow, but that is still true for 286 and 386 boxes without coprocessor, so
>it still makes sense).

Those data are REPORTED in 'comp_t' form.  This is NOT a SHORT:
	typedef	ushort comp_t;		/* "floating point" */
			/* 13-bit fraction, 3-bit exponent  */
Notice: it is NOT EVEN SIGNED.  (Would you let your sibling marry
	a NEGATIVE non-signed value?)

If you really think the system does this to save FLOATING POINT arithmetic,
I've a coupla bridges for ya ;-}.  However, if you're interested in
minimizing the size of accounting records, particularly dating back to
those halcyon days when a 50 MB disk was often the sole large disk....

jc mcmillan	-- att!mtunb!jcm	-- just muttering for myself, it that