Re: packed data

Hello James,

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

You wrote:

>> C is fine for bits and bytes but it sucks for database work -- you might
>> want to consider embedded SQL or the SQL CLI instead.

>This is not really true.  Just like the statement you made about K&R doing
>the world a disservice by developing C is not true.  Come on, all
>languages suck.  The moronic way RPG does MODs is an example, as well as
>its rotten way of doing pointers.  Shell programming and OCL has a
>sometimes bewildering syntax and CL can't do anything decent with
>variables.

You are correct that most languages have some flaws and I agree that RPG
MODS are horrible by requiring the use of OCCUR to specify the index.  What
we should have been given was a structured array like PL/1.  However there
is nothing wrong with RPGs use of pointers.  Of course I can see how a C
person might want typed pointers but they are simply a pain in the arse and
only of use when you control the underlying structure referenced by the
pointer.  The typed pointer requirement usually boils down to the
'elegance' of using pointer++ instead of the 'less elegant' pointer +=
sizeof(struct) when walking through arrays of structures and thus is a
specious argument.  I will agree that being able to define a typed pointer
on a prototype and having the compiler to check that on the call is a bonus
and somethign that RPG could benefit from.

>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.
        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.
        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.

<===== Code example deleted =======>

>          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.

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:

        char field[10];

I should not be able to reference the 11th byte of that field.  If I copy
too much data into that field the compiler should either complain or copy
only as much as will fit.  After all it knows how long I declared the
field.  The problem here is that C treats arrays and pointers in a similar
fashion and thus field is really a pointer to 10 bytes of storage.  That
means specifying field[i] and *(field+i) are the same and that means that
specifying *(field+10) is the same as specifying field[10], which is the
11th element for those of you not paying attention, and since I have now
exceeded the bounds of the array I expect the compiler or the runtime to
complain but C tolerates that behaviour because it doesn't really
understand arrays -- just pointers!

If I explicitly declare a pointer then I can accept that I could use that
pointer to reference storage not 'owned' by the pointer because by
declaring a pointer I am telling the compiler that I know what I'm doing.
However when I have declared an array I expect the compiler to do bounds
checking.  I also expect a compiler to distinguish between a 10 element
array of 1 byte elements and a field 10 bytes long.  C does none of these
basic things.  Why not?  Becasue K&R were lazy and expected programmers to
build this sort of thing on top of the language.  Thus every programmer has
to invent the sort of constructs that should be in any halfway decent
compiler.  For example, instead of using proper var-chars for variable
character data we got the null-terminated string kludge and a number of
different ways of doing the same thing (check out the various strxxx
functions) with subtle differences because the initial implementation
didn't fit someone elses requirements.  I could go on but I shan't ....

>You also mentioned C's poor support for numeric types.  I guess you mean
>not supporting fixed lenth numbers, like decimal(9,2).  I guess this could
>be a problem (though I don't really see any reason why a very simple
>solution could not be found.  Seriously, who cares if your number is 3,0
>or int as long as you don't overflow your storage type?).

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.

>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
conversion to a string to display it and conversion from string to
calculate with it.  Using printf() with %d or similar is just converting to
a string.  Using ZONED means no programmatic conversion -- although RPG
will convert to packed during any arithmetic because that's how it likes to
work but the programmer doesn't have to worry about that.

>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
issue with passing by reference.  The same problem of mismatched parameters
occurs with character data too (and in C as well).  Of course, idiot
programmers who don't understand what is occurring get bitten by this but
there are more things in C to trap the unwary than in RPG (or COBOL or PL/1
or Smalltalk for that matter) -- hence the plethora of lint filters to
point out bad C coding practices.

>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?

>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?

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------