Re: Calling names - System i5

So assuming that the first character must be a letter, and that every other
character of the remaining 9 could be A-Z or 0-9 (there's underscores and
other "special" characters, but let's just keep it simple) - that gives a
grand total of...

2,640,558,873,378,816

...combinations of items that could reside in one library. I don't have my
limits sheet in front of me, but can that many things even exist in one
library? 2.64 quadrillion? Am I figuring this right? I guess if it is
right, I've never found the need for more than that many objects in one
library.

26*36*36*36*36*36*36*36*36*36

jch


On 2/24/08, Steve Richter <stephenrichter@xxxxxxxxx> wrote:

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

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.