DOCA (was: VRPG And/Or Java)

Phil,

In a message dated 97-08-29 17:46:47 EDT, you write:

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

Oh now, from what I remember of C there was an AWFUL lot of nasty OPEN and
I/O code required that made me wonder why I needed an operating system!  I
also seem to recall that simple OPEN and CHAIN commands in RPG required FAR
less code than did C.  If C is so similar, why did SSA replace all occurances
of the CHAIN statement with single-record SQL FETCH's in release 6.0 of BPCS?

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

VERY simplistically.

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

But, unless specifically stated, the I and D specs are NOT library-specific.

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

How do you figure RPG?  RPG doesn't support the double quotes at all.  I
always used them (double quotes) in BASIC to differentiate character strings
from other functions using single quotes on print-outs.  It took me MONTHS to
quit using them in RPG when I came back...

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

It's hard for me to ignore AS/Set, personally.  I am greatly distressed that,
despite years of effort, your company decided to drop support of AS/Set.  I
am also annoyed that, after years of promises, UDK (UNIX Development Kernel,
a BIG AS/Set selling point) never became available to the general public
(although I hear that the latter is no big loss).  THIS was supposed to
provide platform transparency.

I was willing to drop all of my previous prejudices when SSA bought
SoftWright UK and promised a CORBA-compliant BPCS (despite the fact that ODW
was announced PRIOR to the purchase of SoftWright).  Now we have BPCS 6.0.x,
which performs poorly and most of which (beyond accounting and ORD modules)
uses the ODO screen scraper for client-based applications.  I also understand
that the source code for ORD500 is not provided because it is written NOT in
ODW, but a C variant because ODW was not yet "ready for prime time".

Please excuse my frustration, but I cannot help but feel sorry for the folks
at the Fall '95 AS/Set User Group meeting that had just purchased the AS/Set
product for the development of applications and had to listen to Mr. Shakir
proclaim that "your AS/Set will NOT port to DOCA".  I also feel sorry for Mr.
Jim Franch, who had bought all of this "hook, line, and sinker" and had to
explain during '95 that SQL single-record FETCH's were as efficient as a
CHAIN on the AS/400, only to retract during Fall '96.  What the He-- IS DOCA?
 SSA presented it as a language and a paradigm initially, but NOW it appears
to be ODW which, during a recent demo that I saw, looks an AWFUL lot like a
working version of  the old IWS (the GUI version of AS/Set that NEVER
worked).  Sorry, I'll quit venting now...

JMHO,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
(Between Raleigh and Research Triangle Park)
E-Mail:  DAsmussen@AOL.COM

"There is no greater loan than a sympathetic ear." -- Frank Tyger
+---
| 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
+---