|
On 2/24/08, Mark S. Waterbury <mark.s.waterbury@xxxxxxx> wrote:
Steve:
Let's examine each of these supposed "limiting features" in i5/OS:
"no managed code" -- i5/OS, OS/400 and even CPF have always
had the equivalent of "managed code" -- it's called "MI" or "TIMI".
You cannot create "native" IMPI or PowerPC instruction streams and
execute them under OS/400 or i5/OS using documented interfaces.
more like the JVM in terms of the intent of my usage. the specific
feature I have in mind is the object encapsulation of program
variables and the use of references to access those variables. The
programmer working with a framework or better, OS, that integrates
managed code has a huge advantage over the less fortunate.
"10 character object names" -- You can use very long
procedure names in modules and service programs. Once you add a
*MODULE or *SRVPGM to a binding directory, you never need to
directly refer to the 10-character name of those modules or service
programs. When ILE programs are bound to *SRVPGMs, the service
programs are loaded and activated automatically, as needed.
right, and a majority of shops dont use service programs because of
their complexity and the danger of the signature violation and worse,
export mismatch when hardcoding the signature.
Also, with DB2/400, you can use much longer names for tables and
views (and DB2/400 generates the i5/OS 10-character names for the
underlying *FILE objects automatically).
stored procedures as seen on the network, from an odbc client such as
crystal reports, only see the 10 character name.
You can also use field
names much longer than 10 characters in DB2/400 tables and views.
having two names for fields and files is arguably worse than a single
name. short names are a problem for programmers.
"segment space limits" -- as originally architected, MI space
objects are limited to 16 megabytes maximum size. OS/400 or i5/OS
regularly uses multiple MI objects to create many of the OS/400 or
i5/OS objects we are familiar with.
You can use more than one *USRSPC object to create your own very
large "persistent heap" to contain complex data structures whose
total size is much larger than 16 megabytes.
linking spaces like this is the equivalent of GOTOs in program code.
bad practice. another problem with this linkage method is you cant use
CRTDUPOBJ and SAVOBJ to refer to your single linked object.
You can
store pointers in one *USRSPC that point into other user spaces, and
vice versa.
pointers are invalidated when a space is restored onto the system.
Also, if you must have access to a very large contiguous memory
space, OS/400 has supported teraspace since V4R4, which supports up
to several terabytes of contiguous temporary address space.
which brings us back to the inferior Linux and Windows model where you
use one set of data structures in a running program and another set
when storing your data structures to permanent, shared storage.
better to increase the pointer size to 64 bytes so you can have an 8
byte offset and 8 byte segment. just do something so the programmer
does not have to work with so many low level details if they want to
take advantage of what SLS has to offer. The 16meg limitation must be
a hinderance to those IBMers who work on the OS and use spaces.
"outdated ILE" -- ILE now provides something that resembles
what you call "reflection" with the QBNRPII API in V6R1, also
available as PTFs for V5R3 and V5R4. i5/OS's.
good to know, thanks. is the interface information sufficient so
that procedure prototypes are not needed by the RPG compiler? if so,
the replacement of the /COPY with a "using service_program_name" in
RPG would have been a great feature in v6r1.
ILE is a runtime environment. ILE
supports structured exception handling.. You say ILE does not
support object-oriented programming, but that is really up to each
language compiler and its runtime routines. IBM supports C++ as an
ILE language, and C++ is a fully object-oriented language. And i5/OS
V6R1 ILE can now activate *SRVPGMs "on demand" rather than
activating all referenced *SRVPGMs when the first ILE *PGM that
references them is activated. ILE has a very advanced binder (or
linker) -- you can bind multiple *MODULEs to create a *PGM or
*SRVPGM (with CRTPGM and CRTSRVPGM), and you can replace one or more
*MODULEs in existing *PGMs or *SRVPGMs (with UPDPGM and UPDSRVPGM)."modern"?)
You can even control the ILE signatures that are generated by using
optional binder language source statements. (Because ILE has been
around for 14 years, is that why you think it is not
details, details, details. the .NET programmer does not have to know
any of this. There is no need for binding source and signatures. Use
the Power6 processor to its potential and find the procedure being
called at runtime in the library list of the job. Similar to the
external program call, one of the many great innovations of the
original S/38.
-Steve
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
