Re: Calling names - System i5

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. In CPF, OS/400 or i5/OS, you must go through a "trusted translator" to convert OPM MI or ILE NMI into the "native" instruction stream. This is very similar to what happens when Microsoft .NET compilers generate MSIL/CIL, and the .NET runtime JIT converts the CIL into equivalent native instructions (on the fly) at runtime. If you use a compiler that generates native instructions directly, that is "unmanaged code" (in Microsoft's terminology.) NOTE: you can generate and use native PowerPC RISC code within PASE, which follows AIX "rules" (or in an AIX or Linux LPAR).

"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. The 10-character names do "show up" for *PGM names, when you CALL the "main" program (e.g. from CL or a menu) to start an application, or when one program CALLs another external *PGM. 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). You can also use field names much longer than 10 characters in DB2/400 tables and views. (See: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/db2/rbafzmstlimtabs.htm )

"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. You can store pointers in one *USRSPC that point into other user spaces, and vice versa. 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.

"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 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). 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 "modern"?)

So, "Where's the beef?"

Sincerely,

Mark S. Waterbury

> Steve Richter wrote:

That just proves the car analogy does not hold. Separating i5/OS from system
i hardware is good for us. Customers will hear the "i5/OS runs on system p"
message that i5/OS now runs on multiple hardware platforms, which is what
they expect and gives them confidence they are not being locked into
overpriced hardware. Of course, as long as the deficiencies in core i5/OS
( no managed code, 10 char object names, segment space limits, outdated ILE
) are not addressed, not much of distinction can be achieved by application
developers.

-Steve