Steve,
I don't disagree with the intent of anything on your list of desired enhancements. But I also don't see how your list supports the earlier assertion that "IBM i has not been fundementally improved for the last 10 yrs.". I believe there have been fundamental improvements, like some of those I referenced earlier, though there is obviously also room for more improvements by IBM :) My problem is someone as knowledgeable as you are about the system making such a blanket (and negative) statement on a very broadly read list. (Though I assure you I wouldn't have a problem with a blanket statement such as "IBM i is the best kept secret in the industry" lol)
As I mentioned, I don't disagree with the intent of items in your list. I would suggest however a more generalized approach. As an example, you mention application access to the associated space of an object. I suspect (but could be wrong which is the exposure of being too specific) that what you're after is the ability to have user data associated with an object, saved/restored/duplicated with the object, but you don't really care about the actual implementation. In the past users for instance wanted to associate application related data to a user profile. IBM came out with the User Application APIs which allows user data to be associated with a *USRPRF, saved and restored with the profile, etc but I don't believe is actually using the *USRPRF associated space as a backing store. With a more general statement of need (not describing implementation other than as a suggestion) perhaps a solution might be to allow a user to create a composite object which can define a
set of objects to be treated as a single entity for save/restore/duplicate/etc. Please note that I'm throwing this out as a possible alternative implementation that potentially could satisfy your need, I'm not suggesting in any way that I'm aware of any work currently being done in this area.
Along the same lines, your description of service program enhancements threw me for a second. I don't agree with "reflect completely their contents" (and I suspect you didn't really mean "completely") but certainly agree with the desired objective "not have to include the PR definitions".
And while I hesitate to bring this up... I've also wondered in the past what you are after with user spaces greater than 16MB. It's a very specific implementation you have in mind, and I would certainly like to see such an enhancement, I've never understood why it had to be user spaces. If the goal is persistent and shared storage of large amounts of binary data, I would think that a stream file would suffice. But as I know you're familiar with IFS I'm left wondering what the real application need is.
Regards,
Bruce
Steve Richter <stephenrichter@xxxxxxxxx> wrote:
On 4/11/08, Bruce Vining wrote:
Steve,
IBM i has not been fundementally improved for the last 10 yrs.
What do you consider to be a "fundamental improvement"? LPAR for instance was 1999, I believe (though I admit I'm a bit shaky on this one) IASP was 1999, PASE was 2000,... Database support for BLOB, CLOB, datalinks, UDF,etc is in the last ten years, ... The 8-byte pointer support (again a little shaky on this) in 2004...
my list includes:
ILE service programs reflect completely their contents. to the extent
that an RPG pgm does not have to "include" the PR definitions of the
procedures it uses. just the names of the srvpgms it is "using".
the associated space of an object feature of the system should be
available to appl programmers. I assume that when an object is saved,
restored or duplicated, all the associated spaces are acted on also.
complete the pre compiler feature of the system. the mapping between
debugger views and precompiler output seemed shaky when I tried to
work with the pre compiler and debugger APIs. Variable names, for
example, cant be mapped between views. I think this is the reason SQL
procedure debugging is so problematic.
better integrate sql procedures into the ILE world. CL modules should
be able to call sql procedures with parameters and then reference the
returned result set as an object in the program.
basically mimic what .NET provides the Windows programmer. Where all
programs adhere to a common language infrastructure, and modules
written in different languages can be used interchangeably. What
would be neat about this is if the referenced object memory model of
the JVM or .NET could be extended to the permanent object aspect of
the SLS. Where an object newed up in one program could be passed by
reference thru a data queue to another job or node on the network.
long object names. Why has this not been implemented yet? Is the idea
of storing a binary, non ebcdic character value in the 10 char name
field, which points to a central object name table, too simplistic?
Just replace all the IBM i code which reads the 10 char name with a
call to a procedure that does a name lookup.
extend logclpgm(*yes) logging to optionally include commands not
currently logged. also optionally log the values of cl variables.
journal all changes on the system, by default. this is probably
something the system already has, it just needs good 3rd party
management software to make it all accessible. What is intriguing is
being able to recreate the state of a job at various points in time.
Would be great for problem determination.
The theme being the IBM hardware people have done great work the last
10 yrs. If upper level IBM mgmt is as short sighted and fixated on
short term profits as some say, this has not stopped them from
developing great products. The Ian Jarman software group has to be
just as creative and resourceful.
-Steve
midrange.com
