× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: is nmi translator off limits?
  • From: "Leif Svalgaard" <leif@xxxxxxxx>
  • Date: Thu, 10 May 2001 23:17:03 -0500

===> even if you are programming to the OPM using MI, there is
a translation of the result to NMI which is then given to
CREATE MODULE for generation of the RISC-instructions.
 
Leif,
 
I am alluding to the 2 step process that a programmer has to execute to create an ile program. 1st step is create the module, 2nd step is create the program.
This lengthens the learning process of a new programmer, increases the chances for bugs, ups the complexity all around.
And for what reason? Increased execution speed? Performance can be improved without increasing complexity by just shipping faster hardware.
The much needed and relatively well done improvements in rpg that came with ile did not require a new programming model or a link edit.
 
===> fads come and go. Silver bullets shine and then tarnish.
When the S/38 and the AS/400 came out, the OPM model of
dynamic program calls (the CALLX instruction) was touted as
a brilliant innovation, making link-edits obsolete, allowing dynamic
replacement of modules (actually the ultimate in modular
programming). Then IBM discovered C, and the BINDER,
and link-edited, bound programs were the holy grail.Said to
faciliate 'modular programming' of all things!
Then IBM discovered Java, and dynamic binding was the rage and
a great innovation, etc, etc, etc. Then 'IBM is ready for Linux" and
maybe we are back in C-land.
The pendulum swings back and forth, and the clueless swing with it.
 
The ILE program model is incredibly complex. Some mandated by
the segmented nature of the 'single-level store', but most of it
unneeded, clearly bearing the marks of the 'second system syndrome'
that Fred Brooks talked about.
 
Quoting dr. Frank again:
"Figure 9.5 shows how these components fit together to create
an activation group. To summarize, we can say each process
in the aS/400 has a PAWA. Within this PAWA id the PAGP and
two or more ACTGRPs. Each ACTGRP has a PACB that contains
multiple MBVs, an ActGrp directory, a PRT, a heap list, one or more
heap spaces, auto storage segments, and static storage segments.
Now, isn't that perfectly clear?"
 
Even Frank knows that something isn't quite right here, hence the
almost apologetic quip about 'perfectly clear'. Sigh.
 
-------
Hurry up with the nmi chapter of your book! Write faster!!
===> working on it... 
 
 

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.