RE: [MI400] Debugging MI code

["jt" <jt@xxxxxx>]

Simon et al,

I have a fair number of hang-ups with C and C++, as well as Java/RPG.

For example, I do NOT care for data-casting.  I would like, rather than
overloading on procedures and qualified data structures, overloaded data.
Iow, I would like a compiler that automajically allows a numeric
quantity-type of data element to be available as both a subfield and
standalone field, and available for display/print (eventually /voice?)
presentation as edited left-justified, edited right justified and also
available for arithmetic.  *MAPVAL is great for display/print files, but
insufficient imo.

It's been a while (25 years?) since I did a thorough investigation and
comparison of programming languages.

But my basic question is whether MI is going to continue to be relegated as
an less-than-close-to-fully-supported language.  Iow, there is (at least)
one very pragmatic reason to stick with C, which is it'd be harder for IBM
to neuter than what it's done with MI and RPG.

| -----Original Message-----
| From: mi400-bounces@xxxxxxxxxxxx [mailto:mi400-bounces@xxxxxxxxxxxx]On
| Behalf Of Simon Coulter
| Sent: Tuesday, March 02, 2004 3:39 PM

| On Wednesday, March 3, 2004, at 02:29  AM, James H. H. Lampert wrote:
|
| > Yes, and since it makes no allowances for the way C handles character
| > strings (which, I freely admit, is more than a little bit meschuga, but
| > PL/I would be my language of choice), you try to look at a character
| > string variable, and you've got to go through all sorts of rigmarole to
| > do it.
|
| PL/1 is my choice too.
|
| While I'm not defending the the ILE debugger it is much easier to use
| once you realise that it tries to behave like the underlying language
| therefore it does make allowances for C's admittedly crappy idea of
| strings.
|
| Since C has no concept of character variables (if you discount the
| stupid idea that a char is numeric data type) and uses null-terminated
| arrays to represent them, and that in C arrays and pointers are the
| same thing (another stupid idea), then the debugger's contortions are
| understandable.
|
| To reference the contents of a characters string in C you must either
| use array subscripting or pointer de-referencing.  Thus:
|       EVAL    *string
| in the debugger will do exactly what *string does in C, that is
| de-reference the pointer and access the first character. So too,
|       EVAL    *string:s
| will treat the stuff pointed to by string as a null-terminated string
| (because of the :s) and show all characters up to the first null
| (x'00). This behaviour seems to be what a C programmer would expect.
|
| Since it is common for programmers to make errors the debugger will
| only show the first 30 bytes of a C-style string--in case there isn't a
| null. You wouldn't want the debugger to attempt to dump all storage
| from the pointer address in the hope that a null might appear would
| you? Thus:
|       EVAL *string:s 100
| will show the all characters up to the first null, or the first 100
| bytes of whatever string points to if a null is not encountered, in
| character form.
|       EVAL *string:x 100 will show the first 100 bytes regardless of any
| nulls in hexadecimal output.
|
| There is also the :f form which will display formatted strings by
| evaluating embedded directives like \n.
|
| Using the affinity between pointers and arrays allows you to also do
| things like:
|       EVAL    string[0]
| which is equivalent to
|       EVAL    *string
| or
|       EVAL    string[10]
| which is equivalent to
|       EVAL    *(string+10)
| Again this seems to be what a C programmer would expect.
|
| The one missing thing is displaying array ranges. In non-C source you
| can do:
|       EVAL    array(10..20)
| to display the array elements 10 to 20 inclusive. I haven't found any
| way to do the same in the ILE debugger. EVAL  array[10.20] results in
| "Syntax error occurred".
|
| Regards,
| Simon Coulter.
| ---------------------------------------------------------------------
| Arterial Software
| IBM Tower
| Level 3, 60 City Road
| Southgate Victoria 3006
| Australia
| http://www.arterialsoftware.com
| +61 3 9421 5911 (Phone)
| +61 3 9428 3729 (Fax)