xfer problems sco-sun

[Bill Vermillion]

On Fri, Apr 02, 2004 at 10:19:24AM -0800, Bill Campbell thus spoke:
> On Thu, Apr 01, 2004, Jean-Pierre A. Radley wrote:
> >Bill Vermillion propounded (on Thu, Apr 01, 2004 at 08:18:23PM -0500):
> ...
> >| Just split the each record into two pieces, swap the heard, and add
> >| the rest.  I did something similar a very long time ago before the
> >| xfer program existed.  As I recall it's just the first 20 bytes
> >| that need to be swapped.

> >Would that it were that simple: it's the twenty byte header at the
> >beginning *of each record* that needs bytes swapped.

> Complicated by the fact that the FP key and data records are
> fixed length with no \n line-feed delimiter so one has to
> read fixed length. I did this with a C program years before
> learning perl where it would probably be only a bit more than a
> one-liner.

I personally find it easier to work with fixed length files - that
are true fixed length. MS seems to think fixed length means fixed
length plus cr/nl or other terminator.  And in some versions of
this, if the last field is pure ascii/text, the trailing spaces are
eliminated before adding the record terminator.  They didn't seem
to understand the definition of fixed length.  And since their OS
implementations can't seem to handle long streams they wound up
adding the terminators.  I guess you could call their format
'usually fixed length'.  One cure to make sure they stay fixed
is to make the last field numeric.

I had to have the MF people export the data to my FP app with 
the last field defines a 99999 ?? [I think that was it - the
programming was in Links which I think was a front end to COBOL
on a Burroughs A-10 - which was essentially a Unix system at it's
heart - derived from the Sperry machines after the merger and
acquisition of Arete.

> More fun though was a FP customer running on a Radio Shack
> Model 16 where disk problems created shifts in the filepro
> files where the key and data files would get out of sequence
> (e.g. all fields past a certain record would be shifted one
> byte to the left or some such, changing repeatedly through the
> files). Naturally the key and data files didn't shift at the
> same places (and there weren't any backups of course :-).

I remember having to fix some of those too.

Bill
-- 
Bill Vermillion - bv @ wjv . com