Re: packed data -- C400-L

Hello Jevgeni,

I wasn't going to respond to this but I can't help myself.

You wrote:
>I've been carefully reading this discussion, and cannot withstanding
>adding my comment.
>I cannot agree, that C is not appropriate for this kind of programming.
>I cannot agree with Simon saying that you are only comfortable with C if
>it is your first language.

I don't expect everyone to agree with my view.  However, your disagreeing
doesn't make my view any less correct.

>I started programming in 1977, when there was almost no C (at least in
>USSR), so I did a lot with FORTRAN and PL/I.
>I feel fine programming C, never missing these stupid data types like
>fixed char and a like, when you wait, that compiler does something behalf
>of you.

OK, you don't miss fixed-length data types.  That means you  must fill your
code with constant lengths or lots of sizeof() statements.  For example:

        memcpy( screenFld, databaseFld, sizeof(dataBaseFld) );

What do you do if screenFld is a different size from dataBaseFld?  Which
field do you choose for sizeof()?  (The smaller one of course.)  What if
the relationship changes such that databaseFld is initially smaller than
screenFld but due to database changes becomes larger?  I must find all the
sizeof() references and change them to the other field -- or write truly
ugly code using the ternary or conditional operator such as:

memcpy( screenFld, databaseFld,
        (sizeof(dataBaseFld) < sizeof(screenFld)) ? sizeof(dataBaseFld) :
sizeof(screenFld) );

My view is that the compiler should handle that for me thus allowing me to
concentrate on the real task which is writing the application.

>Personally I write "classical" AS/400 applications - screens, databases
>and alike on C for the last 3 years - add-ons to our banking system.

Then you are doing things the hard way.  Handling screens and database is
much easier in RPG or COBOL or anything other than C.  The fact that you
are comfortable doing this says more about YOUR ability than anything about
the suitability of C.

>What is really missing is good books. I really understand all these
>problems like fixed char without zero termination read from PF, mess with
>packeed decimals and so on.

There are plenty of books on C.  Most of them are not good because they
don't cover advanced topics that are actually needed in serious
applications.  There are very few books (good or bad) on C for the AS/400
primarily because there are better application languages than C available
on the AS/400.

>But C is not guilty, even ILE-C/400 is not guilty.

C *is* guilty -- and therefore the designers of C -- because the language
doesn't support basic data types necessary for a business application.  It
doesn't matter that a programmer can force C to work in an application
environment.  C is unsuited to that role because it lacks basic data types
and basic checking of bounds etc. that allows a programmer to concentrate
on the business task instead of the programming task.

>I could never understand why C/400 got this "orphan" status on AS/400,
>when it is (OK, ++) the OS/400 language.

I do not understand what you mean with this statement.  C is an orphan on
the AS/400 because it is not suited to the tasks midrange programmers
perform every day.

>My friends, who found 3 days to get basic RPG skills tell me, that is very
>easy, but why the .... I should spend time and add one more stupid pigeon
>language to these, I used in my life.

As a programmer you should know more than one programming language because
that will allow you to use the most appropriate language for the task
rather than shoehorning every problem into the only language you know.
There is an old saying that every problem is a nail to the man who has only
a hammer.  Familiarity with multiple languages often allows you to see
different solutions to a particular problem.  You will find that equivalent
skill in C and RPG will allow you write the same program much faster in RPG
than in C.  The same is true of any true high-level language.  C is not a
high-level language because it forces the programmer to think too much
about the bits and bytes rather than concentrate on the application.

>There is absolutely no problem accessing data bases via "_R" functions.
>We did some experiments with embedded SQL, but refused of it. I think,
>that it is better to plan and do what you want to do, than to rely on some
>mystical SQL optimizer.

The _R functions in themselves work quite well but they are not part of C.
They are an add-on provided by Toronto to compensate for one of C's
shortcomings -- namely the view that all I/O is a stream.  The _R functions
still require a programmer to fake fixed-length data by using copy
functions (such as memcpy or strncpy) that take a length parameter and the
programmer is responsible for setting these lengths correctly.  My view is
that the compiler already knows the lengths of these fields and so should
handle the length for me.

Record I/O is good for single record read/update or write processing.  SQL
is better for set processing.  The trick is to use the correct tool for the
job.   My contention is that C is the wrong tool for business (i.e.
database) programming.

>This is, by the way, basic C ideology - rely on yourself, no safety net.
>If you like this approach, use it. If not - it is not your language....

Ah, so why don't you write your own compiler, and your own operating system
while your at it?  Why should every C programmer have to write the same
basic support functions over and over?   Fixed-length fields are extremely
common in business applications so it is reasonable to expect a business
compiler to provide intrinsic support for them.  The fact that C doesn't
provide that support marks it as unsuitable for the task.  Being unsuitable
doesn't stop you from using it, it just means it is a bad choice.  I could
write a weather forcasting system in RPG, or a Fourier transform in COBOL,
but they would be unsuitable languages for the task.

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  / \
--------------------------------------------------------------------