Xref: utzoo comp.unix.questions:10997 comp.unix.wizards:13978
Path: utzoo!utgpu!watmath!clyde!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
Keywords: comp_t
Message-ID: <1358@mtunb.ATT.COM>
Date: 9 Jan 89 15:26:31 GMT
References: <1356@mtunb.ATT.COM> <217@h.cs.wvu.wvnet.edu>
Reply-To: jcm@mtunb.UUCP (was-John McMillan)
Organization: AT&T ISL Middletown NJ USA
Lines: 53

In article <217@h.cs.wvu.wvnet.edu> fuhrman@h.cs.wvu.wvnet.edu (Cris Fuhrman,G-40B ESB,293-2190,599-1202) writes:
>From article <1356@mtunb.ATT.COM>, by jcm@mtunb.ATT.COM (was-John McMillan):
...
>Is it possible then, that the report code is not using the correct
>data type?
Again: the DATA TYPE is NOT a standard one and requires un-compressing.
The following is a 15 sec. hack that uncompresses 'comp_t' values.
This is needed for consumed times > 8191/HZ seconds or other units > 8191:

	unsigned long uncompress(v) { return((long)v&8191)<<(((v>>13)&7)*3); }
or
	floatf uncompress(v) { return (float)(v&8191)*(1<<(((v>>13)&7)*3)); }

>	      Or is it that the actual accounting records are 
>overflowing.

As I eyeball the result:
		0 <= resulting values <= 8191<<21 ~= 2**34 ~= 16000000.
Congratulations if you're consuming more than 16 GIGA-anything.
And if you're in that ballpark, use 'funcompress()'!

>		What I'm trying to say is, can I get any useful info
>at all from accounting, or is it just a waste of cpu time?

It would be ridiculous for ME to comment upon YOUR accounting software.
I hope the above 'uncompress()' routine helps you striaghten things out,
tho.

>Ok... Like I said, I'm new to unix.  I just graduated with a bs in cs, and
>I had heard a lot of hype about unix from fellow computer scientists.  Is
			nice touch --      ^^^^^^^^^^^^^^^^^^^^^^^^^^
>it likely that people developing the new versions will realize that
>50 MB sole disks are a thing of the past, and that machines are much
>faster and more capable to do things (accounting is an important thing)
>in a reasonable fashion?  I can see the hype losing it's flair.  It's
>1989.

It strikes me the ORIGINAL writers were WELL prepared for the future --
that they had an appropriate eye out for conserving resources, regardless
of disk sizes.  With time, the sizes have increased -- my PC has 190 MB --
but the lack of space never seems to be solved!

Unfortunately, software authors -- such as those writing accounting
packages -- sometimes fail to grasp fully what the $@%@* they're doing.
Even authors who were recent bs/cs graduates and scientists with
answers and philosophy to guide them (:^}).

The average accounting file is read once or twice in its life: data
compression is reasonable and appropriate here.  An error -- such as your
experience suggests exists -- is all the worse as I believe the compression
feature has been present for 15 years.

jc mcmillan	-- att!mtunb!jcm	-- muttering for himself, only