Re: packed data -- C400-L

On Tue, 11 Jun 2002, Simon Coulter wrote:

> I knew my comments would darg out the Unix and C gear-heads.  "Don't insult
> my language! It's perfect"  Hah!

Well, I don't know if I'm a C gear head.  Insults are no fun, but trying
to find better ways to do things is.  Debating the shortcomings of
languages is good, and it livens up this list :)

> >Here is an example of how C can be rather RPG-like when doing database
> >work.  This sample code is from a customer maintainance program I wrote
> >for linux, mysql, and gtk.
>
> You can't be serious!
>       1/ You are using SQL for your database access thus adding support
> to my argument.  I suggested that Phil use embedded SQL because C's basic
> character support is unsuitable.

Yes, I did use SQL.  I wasn't really trying to say not to.  I agree with
you that using SQL makes things easier.

>       2/ You aren't using fixed length data at all.  You are using
> pointers to strings and are relying on SQL to do the work of removing
> nulls,  padding with blanks, or whatever other formatting is required to
> map C strings to database fields.  Again you are proving my case rather
> than refuting it.

I don't want to use fixed length fields.  That wasn't the point.
Personally I think fixed length fields are the wrong thing to use.  Why
would anyone want to limit the size of a field?  C has a problem with
types like int as int can overflow.  RPG has problems with all fields that
are not *varlen as they can overflow (meaning truncated, not the stack).

>       3/ You example is only superficially RPG-like.  Once you start
> looking at what it is really doing it is nothing like RPG at all (nor COBOL
> nor PL/1 nor anything else with proper field support.

Right.  I would have to change the language to make it more RPG like.
Superficially is good enough.  To make it more RPG like would require
externally described files, the RPG cycle, etc.  I already have RPG if I
need those things.  One strength of RPG is that it is easy to copy the
contents of one variable to another.  My example demonstrated how this is
possible in C.

Now if you wanted to do record formats and read files a record at a time
you could do this with structs and then read a specified number of bytes.
Of course you would probably make some kind of function to do it.  You
would also have to add some kind of index to the file to do keyed i/o.
You would wrap this up in some function as well.  In the end you would
have something midway between RPG's read or chain and the standard SQL
APIs.  So just use SQL.  The fact that you use SQL doesn't mean that the
language is unsuitable for database work.  It is just another API to
access files.

> >          customer.cuname = customerrow[2];
>
> >As you can see it works just like eval statements in RPG, no strncpy
> >required.  I can even use constants without having to use sprintf, as in:
> >
> >     customer.cuname = "My Company Name";
> >
> >This is far better than fixed length fields, a la RPG.
>
> This isn't the same at all.  It merely looks similar!  You are simply
> assigning pointers.  You are not copying data or working with a proper
> record format.  You are only messing with pointers and relying on the SQL
> library to format and map what the pointer references into whatever is
> required by the underlying database.  Oh, and you are also only using
> character data.  Let's see you use a proper record format instead of simply
> a collection of pointers, and let's see you use SQL DECIMAL and NUMERIC
> data types for arithmetic while you're at it.

And is there something wrong with not copying data?  To me it seems like a
good thing (better performance).  And what do you mean by "a proper record
format"?  What does a proper record format have that makes it proper?

My example does only deal with strings.  But I don't see a problem with
numeric data types.  Perhaps you could show me?

> My issue with C regarding fixed-length fields is all about the compiler not
> doing what a compiler should.  If I declare a field of 10 characters:

I agree that C allows you to wreck the stack by not doing bounds checking.
But I don't want to use fixed length fields.  Now using variable length
fields doesn't free me from having to do bounds checking.  I just don't
care that C doesn't support fixed length fields.  It doesn't matter.
Fixed length fields only have disadvantaged compared to variable length
fields (now THAT statement is overly broad - I mean that I personally
don't see advantages to fixed length fields.  Prove me wrong).

> For that specific example there is no difference but there is a great deal
> of difference between an int and a decimal 3,3 and a float.  Having a
> choice of data types allows me to choose the most appropriate.  Having
> decimal data types allows me to ACCURATELY handle currency as well as
> reasonably large (30,0) and reasonably small (30,30) numbers.

Please give an example where int is not just as good as decimal(4,0) or
float is not as good as decimal(3,3).  I would have to pull out the
manuals to see how big of a number you can express with C.  Please give an
example of how currency cannot be handled accurately using data types
other than decimal(X,Y) (an example of going beyond the expressable limits
of a data type does not count).

> >But consider the stupidest numeric support on OS/400:  packed *and* not
> >packed.  They mean the same thing.  A packed 9,2 number is just as good as
> >a decimal 9,2 number.
>
> They're not the same thing at all.  A ZONED number (your not-packed number)
> gives me a displayable number on which I can also perform arithmetic.  By
> displayable I mean on a screen or printout.  To do that in C requires

Packed data could be displayable.  Think about it.  All anything needs to
know is that a certain field is a number.  Then show that number.  Packed,
zoned (I was having some kind of block and just couldn't remember that
word, thanks) it doesn't matter.

> >But having both sure screws things up when they are passed around between
> >commands, CL, and RPG.
>
> This is simply silly.  This is not an issue with PACKED and ZONED but an

You are right, this is simply silly.  Silly that packed and zoned don't
behave the same.  Either get rid of one of them or make them behave the
same way.  A number is a number is a number.  It doesn't matter if it is a
passing by reference issue.  RPG internally changes zoned to packed for
arithmetic, do the same here.

> >Even RPG programs screw things up when they are programmed defined.
>
> Why?  If the file is program defined then the definition is up to the
> programmer not RPG.  What do you mean by this?

What I meant is that RPG allows the programmer to screw up just like C
does.  So neither language prevents programmer mistakes (though each
language has different protections and short comings).  Of course this is
kind of obvious so maybe it was dumb to say it :)

> >There should only be one numeric fixed length type: either packed or not
> >packed, I don't care, but just one. Everything on the system should know
> >that a number is a number.
>
> PACKED and ZONED exist for historical reasons.  A single numeric data type
> might be nice.  But does that mean you would also drop integer and floating
> point data types?  Or do you really mean you can't grasp the difference
> between ZONED and PACKED and would like that choice reduced to one thus we
> would still have at least 3 numeric data types (PACKED, INTEGER, FLOAT) and
> what about the odd BINARY data type used by the database?

I understand the differences (working with a lot of old s/36 programs sort
of forces that on you).  I think that the differences shouldn't matter;
i.e. there should be one type that means "decimal(X,Y)".  That can mean
that there exists both packed and zoned and they behave exactly the same
or it can mean that there is just one of them.

James Rich
james@eaerich.com