Re: VRPG And/Or Java

Ed Doxtator (by way of David Gibbs ) wrote:
> 
> I've been working in C for the last year on the AS/400 (my first
> experience of C), 

And it ain't been too bad, all in all.

> But, outside of systems work, C on the AS/400 is not much use, in my
> view.  It's difficult to write real-world applications with C.  It's much
> easier to code a simple subfile inquiry program in RPG than it is in C
> because, again, the amount of hand-holding RPG gives me over C is
> superior.

I'd disagree. Sure, The system may help you out a little when using RPG,
but you get equal support from the system for C. You have to write the
same logic in RPG as you would do in C. Subfiles are not that messy in
C, infact given the nasty things you can do with lefthand indicators in
RPG, processing subfiles in C is much easier to read (for me).

> I don't need to include the recio.h file, cos I don't NEED it!  RPG has
> built-in database handling.  (This seems trivial, but I found I missed it
> big time.)

But in RPG you have to enter the file specs, which (simplistically) is
similar to coding #include <recio.h> in C

> I don't have to worry about the silly way the C pre-compiler creates
> structures for externally-defined AS/400 records.  The pre-processor
> makes a structure name for a record format that includes the library
> name.
> Why include the library name in the structure name?  C'mon guys!
> I gotta manually search and replace all of the uses of the structure
> name if I move the file to a different library and re-compile.  That
> makes a library list useless.  If I create the structures manually by
> hand-coding them I can name the structures as I like, but that means I've
> lost all my database referencing.  Why couldn't they have just used the
> file name and record format name?

This is not quite right and is due to not using #pragma mapinc()
correctly.
The library name does indeed get included into the structure name, if
you
do not specify the 'prefix-name' parameter of #pragma mapic().
Even if this is so, it in *NO* way ties the program to this library.

Using:-

#pragma mapinc("custl2", "CUSTOMERL(C_ENTRY)", "both, key", "") 

will result in a structure named 'XXXXXXX_CUSTOMERL_C_ENTRY_key_t' where
XXXXXXX is the name of your library. Using:-

#pragma mapinc("custl2", "CUSTOMERL(C_ENTRY)",  "both, key", "", ,
"my_pfx")

will result in a structure named 'my_pfx_CUSTOMERL_C_ENTRY_key_t'

The structure *does* tie the program to the field layout of the file,
but
so can the I-specs/D-specs of RPG.

> I don't have to worry about whether or not I'm creating files in the IFS
> or in the regular AS/400 database domain, so I can examine my work files
> directly, without having to use CA/400.

Files will only be created in the IFS if you uses the HFS API's to do
so.
Using fopen() - the C file open - will open a regular AS/400 file, so
will the _Ropen - the record file support for C file open. 

> I don't need to worry about packed decimal, single quotes v. double
> quotes,

These are still an issue in RPG, CL, COBOL, MI, PL/1, (do I need to go
on ?)
not just C.

> single equals v. double equals, allocating memory, freeing
> memory, null terminating strings, arrays being zero-based, or null
> pointers.

These, granted, are different from RPGIII, but will become common-place
with ILE RPG, with the possible exception of zero-based arrays & null 
termed strings

> RPG is an applications language.  C is a system programmer's language.
>  If you're not gonna write that many system programs, why bother with C?

To quote you:

'it's useful for the sort of work that we do here (essentially, comms 
work across multiple platforms, with vast quantities of data
manipulation)
We need platform transparancy, and C gives a great deal of that to us.'
        *********************
Ignoring AS/SET, when else can you target RPG for Unix, NT/95 ?

-phil.

-- 
Phil Hall
____________________________
email . . . : hallp@ssax.com
phone(w). . : (312) 258-6319
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---