Record length is not directly stored in the database; you have to know
it for the database you're reading.  This usually takes the form of a
magic number KSIZE, which is twice NCOEFF.  It appears this number is
buried in the database, but not obviously.  IPT, which is an array of
12 arrays of 3 ints, contains the info.  Load "int IPT[12][3]" from the
file, then let KHI be such that IPT[KHI][0] is as large as possible (if
multiple such exist, let KHI be the least of them).  Let ND be 2 if KHI
is 11, or 3 otherwise.  Then NCOEFF is
IPT[KHI][0]+(ND*IPT[KHI][1]*IPT[KHI][3])-1.  asc2eph.f does not check
this; asc2eph.c does.

The format is broken in other ways, too.  The first two records are
overlaid with administrivia, but no provision is made for the case
where the administrivia block is larger than the record.  asc2eph.f
blindly assumes it fits; asc2eph.c checks, bitching if ksize is small
enough that it won't fit (asc2eph.c uses this broken format anyway, for
the sake of generating compatible data files).

The format is also broken in that multi-byte quantities must be in
machine byte order and floats/doubles must be machine format.  Various
places (mostly doc files) also have wired into them the assumption that
ints are 4 bytes and doubles are 8.  asc2eph.f blindly assumes all of
this; asc2eph.c checks sizeof(int) and sizeof(double), but does nothing
about the byte sex and float format issues, generating a file
appropriate to the machine it's running on.

	name	type		at	size	next
Record 1:
	TTL	char*6(14,3)	0	252	252
	CNAM	char*6(400)	252	2400	2652
	SS	double(3)	2652	24	2676
	NCON	int		2676	4	2680
	AU	double		2680	8	2688
	EMRAT	double		2688	8	2696
	IPT	int(3,12)	2696	144	2840
	NUMDE	int		2840	4	2844
	LPT	int(3)		2844	12	2856
Record 2:
	CVAL	double(400)	0	3200	3200
Record 3...N:
	DB	double(NCOEFF)