Re: OT - Shutting down an RS/6000 ?

Joe Pluta wrote:

You're absolutely right here, James.  Personally, I think the concept of
functions in subprocedures is better than dynamic calls.  And while I forget
what the name is in Unix, I'm pretty sure the concept of a shared library
(like a DLL in Windows or SRVPGM in OS/500) is available.  But as I said,
the older concept of the dynamic call is prevalent among many programmers
and was a very important feature to pre-ILE environments.

Yes, and if I'm not mistaken, the Unix/Linux term is "shared
library".  (Two weeks after first installing Linux, I made a mistake
and trashed the shared library configuration. It was a bad day,
since almost all commands in Linux use shared libraries! Later,
after reinstalling RedHat, I learned about library /sbin which
contains many common Linux commands, but using statically linked
modules instead. I could have recovered from my stupidity simply by
running command "/sbin/ldconfig"!)

However, there's still the issue of having one program call another.  One
standalone program cannot call another using a PLIST type of structure.  Is
that an issue?  Only for us old OPM dinosuars.  As the Hans's of the world
drag us kicking and screaming into the newer models, we'll probably forget
about the old PLIST entirely.

Joe: The same issues of inter-program communication affect
programming in most OS's, as far as I can tell. But again, OS/400
seems to be the odd one out in that parameter passing between
programs can indeed be bidi. The single level store probably has a
lot to do with that, since programs running in different processes
normally can't share data in memory. (Didn't this mailing list have
a debate on SLS not long ago? Yeah, SLS is nice, but clearly the
advantages are lost once you have to deal with an app that spans
multiple machines, which I've heard is done in a couple of shops.)

In other environments (not just Unix), normally, some sort of
command language is used to connect the pieces of an application
consisting of various executables (even if everything could be done
just in C). On VM/CMS, for example, REXX commonly serves that
purpose, and is very often used as a command parsing front-end to
the app. In Unix OS's, various scripting languages (like bash and
Perl and Python) serve the same purpose. The latter languages (Perl,
Python) are themselves powerful enough that entire apps can be
written more easily and quickly using just them. Inter-process
communication (if needed) can be done use queues and pipes, or
simply by capturing the stdout output from an executable.

For example, a Python program can call another program, and process
the stdout output of that other program using:

   file=popen('other-program')
   line=file.read()
   file.close()

Other related functions (like popen2) return lists of pipes that can
be used for full bidi communication between two processes. It may be
different, but it's not really very difficult given the right
programming tools.

I agree that passing parameters to program in OS/400 is a nice
model, where the same paradigm can be used for both program calls
and procedure/function calls. But then again, the use of things like
data queues is also becoming more common in OS/400 programming,
since they also have their advantages (such as inter-machine
communication).

To summarize, it's yet another case of things being different
between OS/400 and other OS's, with both having their own particular
advantages and disadvantages. OS/400 parameter passing is easier and
faster for simple cases of inter-program communication, but things
like pipes and queues are more powerful and more flexible. OS/400
systems typically have both of these options, but Unix OS's normally
include easier to use tools such as the powerful scripting languages.

As an aside, and to expand a bit further, one of the reasons Unix
apps can be portable is that they typically don't make any
assumptions regarding the internal representation of data
(packed/unpacked decimal, big-endian, little-endian, etc). Rather,
much data is stored and passed strictly in character form, which
starts to explain the popularity of (that gawd-awful language) Perl,
with it's very powerful string manipulation capabilities. In
constrast, one common nuisance in OS/400 programming is the passing
of packed decimal data between programs, which requires an exact
type match between the programs.

Oh yeah, as far as "drag us kicking and screaming into the newer
models" is concerned, I compare learning new programming languages
and new OS's to learning new human languages. Learning a new human
language is one of the hardest things you can do (for adults at
least), but it is also one of the most richly rewarding things you
can do.

;-)

Cheers! Hans