Re: Making a List -- MIDRANGE-L

Todd

I think one of the best discussions, of course, came from Simon Coulter
back on 2/22/2002.
If you read the below email posted by Simon,  You will see some of the
fundamental differences between OS/400 and VAX.

Thank you Simon again for the lucid point/counterpoint post.

John Carr
-------------------------------------------------------------

I've got an interesting question for some Monday morning stimuli ...
I need to create a list of what makes an AS/400 ... iSeries .... i/400
programmer unique from a VAX programmer - or vice versa.
Any ideas?
Thanks,
Todd Kidwell (Netstar)
AS/400 System Administrator
(313) 224-0578


----------------------------------------------------------

02/22/2002 06:24 PM


Hello James,

I've watched this silly debate in silence long enough.  There are some
serious errors and obvious lack of understanding in many of your comments.

>Indeed, I believe that sometimes the OS/400 way of doing things is not
>that great.

This, I think, is the fundamental problem.  You are overly enamoured of
Unix and its various derivatives.  That's what you learned, that's what you
like, that's what you would rather use.  All of which makes arguing with
you a little pointless.  Still, here I go, playing Don Quixote!

>MONMSG doesn't need to even exist.  In unix all programs return a value to
>the shell after completion, even if they end abnormally.  I've only seen
>MONMSG used to check if some error occurred.  In unix checking the exit
>value of the command run will do the same.

Presuming that the programmer actually checks the return code.  The
difference here is that return codes can be ignored simply by doing
nothing.  Exceptions cannot be implicitly ignored.  The programmer must
explicitly monitor for the exception and then choose to ignore it.

It is common practice on Unix to not check the return code 'cause the
programmer thinks "That'll never happen", 'cause Unix weenies generally
find error handling clutters up the code, and 'cause Unix weenies think
checking return codes causes performance problems.  Indeed it was common
for Unix I/O code to never check the failure of a write (for performance
reasons) 'cause there would always be enough space to write new data!  My
data is obviously not as important to the OS programmers as it is to me.

The S/38 and AS/400 are message based machines and use an exception model
to inform callers of problems.  That is much more advanced than the return
code concept used by Unix and other systems.  An advanced exception model
means that the caller CANNOT simply ignore an exception.  If they don't
handle it the OS will by bringing it to the attention of the user.  Of
course stupid programmers can still code MONMSG CPF0000 and do nothing but
that requires an explicit action on their part rather than an omission as
in the case of return codes.

Various HLLs impose their own handling on top of the exception model (RPG
converts many exceptions into an indicator setting, C converts them into
return codes, COBOL converts them into status flags, etc.) but even there
exceptions that are unmonitored will be brought to the attention of a
human.  Unchecked return codes simply disappear into the ether -- I guess
it doesn't really matter if the DB update worked or not!

Advanced programming languages like Smalltalk and Java (and others) also
use an exception model.

The entire machine uses the exception model.  SLIC sends MCH messages,
OS/400 sends CPF messages, programs products have their own messages.  They
are all using the exception model.

>Calling a program using the old OPM way is analogous to the system()
>function in C on unix.  Variables can be passed either with environment
>variables (similar to the local data area) or with arguments.  But this
>isn't really a very good way to do things, either on unix or the iSeries.

Not even close!  system(), fork(), spawn(), and their variations allow
parameters to be passed IN but there is no way to pass them OUT.  They
provide one way program-to-program communication.  If the called program
needs to give data back to the caller then it must use an external object
(e.g., file) or some communications protocol (e.g., local sockets)

Environment variables are a useful concept that I'm pleased to see
implemented on the AS/400.

>These days bound procedures are the way to go.  Bound procedures are just
>regular function calls in C and those have been around since the
>beginning.  I can think of one instance where I've used the OPM style call
>in the last two years.

I agree that bound calls for common functions are better than dynamic calls
but you're not thinking large enough.  Bound calls make no sense as the
entry into an application.  For example, an application menu displays a
list of options.  Each of those options will most likely be a dynamic
program call because making it a bound call is simply unnecessary and there
is no direct relationship between sale order entry and customer
maintenance.  Once an option has been invoked it makes sense to use bound
calls for the real work within that compnent of the application.

Dynamic program calls are very useful, and the ability to pass parameters
bi-directionally between *PGM objects is useful and not to be ignored just
because Unix doesn't support it.  That strikes me as another example of a
serious Unix failing being dressed up as an advantage.  A bit like the Unix
ability to delete a file while it is use with no effect on any processes
using that file.  The serious failing of an OS that allows open files to be
deleted, and allows programs to read and write to that deleted file just
because they have an open descriptor, and only really remove the file when
all open descriptors are closed is simply STUPID and DANGEROUS, but it is
dressed up as an advantage because I can create and open a temporary file,
delete it, and continue to use it safe in the knowledge that if my program
fails the temporary file will be cleaned up by the OS.  The rationale is
flawed, like so much of Unix, because my real, serious, business data is at
risk just to allow some small benefit for temporary file use.

You've only used dynamic calls in one instance in 2 years?  Then you are
working within very self-contained applications or your recall is slipping.

>Message files are just database files.  But I really don't use them much
>so I better not say too much.  I'm still smarting for getting single level
>storage mixed up :)

No they're not.  They are index objects.  They provide a very fexible and
powerful method of externalising message text.  They support substitution
data.  Unix has no equivalent -- print() and its variants don't cut it.
However, that sort of thing seems alien to most Unix weenies judging by the
amount of Unix code I've had to deal with that is full of:

 if ( !(fp = fopen( fn, "rb" ))) {
   printf("Error occured on file %s\n", fn);
   perror("fopen");
 }
or
 fprintf( stderr, "Bad things happened running program %s\n", p);

This shit is impossible to make NLS aware because all the messages are
imbedded in code.  Of course, with some small amount of programming effort
they could be externalised but Unix doesn't seem to have any standard way
of externalising messages.  Everybody has to do it themselves.

Mind you the AS/400 programmers who imbed

     SNDPGMMSG MSGID(CPF9898) MSGDTA("Error occurred')
or
     SNDPGMMSG MSG("Bad things happened")

are equally guilty of being stupid and shortsighted.

>Library lists are just a PATH.  Nothing new or foreign here.

In essence that's true.

>All these things are really OS/400 specific stuff, not RPG.  So not having
>them on unix would block ports of OS/400 apps because they are used so
>much.  So I agree that it is best to run your OS/400 apps on an iSeries.
>But none of these keep RPG from being a language on unix.  An RPG
>application could be written that used bash instead of CL.

Coulda, woulda, shoulda.  Without support for the OS/400 specific stuff
there would be no point using RPG on Unix.

Conversion of DDS to something Unix likes (e.g., curses, SQL DDL, etc) is
not trivial.  The simple cases of data entry screens would probably be easy
enough, the dialectic differences in SQL can be handled easily, but I'd
like to see you build subfile support into Unix such that it is transparent
to the application.

You would have to implement bi-directional parameter passing (because
although you might not have used it in 2 years, most AS/400 sites use it
constantly).

You would have to implement an exception model to handle the expectations
of the application.

Any Unix RPG compiler will be basically a superset of RPG II.  While you
could build in support for RPG IV langauge constructs quite easily,
providing all the other stuff an AS/400 application takes for granted is
not trivial.

Using a shell script to replace CL, using curses to replace display files,
using SQL to replace native I/O means a port is impossible and a conversion
is neccessary.  In that case why bother with a Unix RPG compiler and simply
convert the RPG code to C and create a native Unix application.

>Just RPG without the rest of OS/400 would be very interesting and useful
>to have on linux.  Of course the hard part would be externally described
>files.  That and trying to get anyone to use it...

It would be an interesting academic exercise to create an RPG compiler for
Unix but I doubt its usefulness.  No Unix programmer would bother to learn
RPG when they already know C and half-a-dozen scripting languages --
especially when the RPG would not be as fully featured as AS/400 native
version.

Anyone who wants an understanding of what is seriously wrong with Unix
should read The Unix-Haters Handbook (by Simson Garfinkel, Daniel Weise,
and Steven Strassmann) -- especially t.  Although I freely admit I am a
CPF/XPF bigot, I do know the AS/400 is not perfect -- but it is a bloody
sight closer than any of the competition!

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