Accounting woes for HCX/UX 3.0

[was-John McMillan]

In article <8675 at alice.UUCP> debra at alice.UUCP () writes:
>In article <207 at h.cs.wvu.wvnet.edu> fuhrman at 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