|
>> And IBM Rochester LABs also developed "FreeStanding C", which got released as a PRPQ called "System/C", Time frame is correct, but System/C was a Toronto product largely written (if I recall correctly) by Mike Wulkan. >> and ILE C/400 was first released under V2R3. RPG IV was also originally scheduled for this release but for a variety of reasons I won't get into didn't make it. Probably a good thing on the whole since the design was revised in the interim and the result was a better compiler. It did however cause RPG IV to get lumped into V3R1 which many people avoided for a long time because of reliability issues. I still think this had more than a little to do with the language's relatively slow adoption rate in the early days. >> Hence, none of these concepts like "binding" or "linking" of separately compiled "modules" was really "new" under OS/400 Agreed, the S/34 and S/36 both linked (but it was well hidden to most programmers) but what it did do was combine the dynamic call process with the faster bound calls. >> For example, how hard would it really have been to add ......... so that OPM MI programs could simply issue a call to a "bound procedure", etc.? Too hard given the other capabilities that were required of the architecture. I don't recall the details but the original approach was very much along these lines. It wasn't abandoned just because we wanted to do more coding. Don't forget that at the time there were still some SAA things going on (and subsequently COM) and the Common Execution Environment (CEE) was still an objective. For those who didn't realize it, this is where the CEExxxxx APIs come from -they are supposed to be cross platform. Another aspect that played into the whole ILE issue was the desire to get away from generating MI. The W-code gives far greater scope for optimization than MI or so I'm told. MI is just too "lumpy". By switching to a cross platform intermediate, optimization techniques can be shared and the way is open to using cross-compilers. For example the new C and C++ compilers. Even plain ole RPG programs can benefit significantly from the new optimization techniques. Jon Paris Partner400 > -----Original Message----- > From: mi400-admin@midrange.com [mailto:mi400-admin@midrange.com]On > Behalf Of mi400-request@midrange.com > Sent: Wednesday, July 03, 2002 1:00 PM > To: mi400@midrange.com > Subject: MI400 digest, Vol 1 #173 - 7 msgs > > > Send MI400 mailing list submissions to > mi400@midrange.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.midrange.com/cgi-bin/listinfo/mi400 > or, via email, send a message with subject or body 'help' to > mi400-request@midrange.com > > You can reach the person managing the list at > mi400-admin@midrange.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of MI400 digest..." > > > Today's Topics: > > 1. Re: Error accessing pdm default space (Bobby.Hicks@ccc-michigan.com) > 2. Re: Error accessing pdm default space (Bobby.Hicks@ccc-michigan.com) > 3. Re: Error accessing pdm default space (Leif Svalgaard) > 4. Re: Error accessing pdm default space (Leif Svalgaard) > 5. Re: MI as the MI language of the as400. (Leif Svalgaard) > 6. RE: MI as the MI language of the as400. (Njål Fisketjøn) > 7. Re: MI as the MI language of the as400. (Leif Svalgaard) > > --__--__-- > > Message: 1 > Subject: Re: [MI400] Error accessing pdm default space > To: mi400@midrange.com > From: Bobby.Hicks@ccc-michigan.com > Date: Wed, 3 Jul 2002 09:14:53 -0400 > Reply-To: mi400@midrange.com > > > My code did have a SETSPPFP following the RSLVSP. It reads: > > /*--Point to beginning of associated space */ > SETSPPFP .Profile_Data,.ProfileDfn; > > > Bobby. > > Robert Hicks > Combinatorics Consulting Company > Tel.: (248) 347 - 7222, ext. 222 > Fax: (248) 347 - 7227 > Email: Robert.Hicks@ccc-michigan.com > > > > > > "Leif Svalgaard" > <leif@leif.org> To: > <mi400@midrange.com> > Sent by: cc: > mi400-admin@midra Subject: Re: > [MI400] Error accessing pdm default space > nge.com > > > 07/03/02 09:03 AM > Please respond to > mi400 > > > > > > > From: Leif Svalgaard <leif@leif.org> > > From: <Bobby.Hicks@ccc-michigan.com> > > > The error is on the RSLSVP instruction. Basically I wanted to get PDM > > > option defaults. The code is as follows: > > > CPYBLA Object_Type,X'0EC4'; > > > CPYBLAP Object_Name,Profile,' '; > > > RSLVSP .ProfileDfn,Object,.Library,*; > > you are resolving a SYSTEM pointer, not a SPACE pointer, so you > > need to have an extra step to get a space pointer from the system > > pointer. I just tried your little snippet and get: "cannot resolve to > > <profile>". > > as Gene points out you must follow the RSLVSP by a SETSPPFP > to get a space pointer from the system pointer. The error must be > on that instruction not the RSLVP. > > _______________________________________________ > This is the MI Programming on the AS400 / iSeries (MI400) mailing list > To post a message email: MI400@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/mi400 > or email: MI400-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/mi400. > > > > > > > --__--__-- > > Message: 2 > Subject: Re: [MI400] Error accessing pdm default space > To: mi400@midrange.com > From: Bobby.Hicks@ccc-michigan.com > Date: Wed, 3 Jul 2002 09:15:25 -0400 > Reply-To: mi400@midrange.com > > > How do I use the FNDINXEN instruction? > > > Bobby. > > Robert Hicks > Combinatorics Consulting Company > Tel.: (248) 347 - 7222, ext. 222 > Fax: (248) 347 - 7227 > Email: Robert.Hicks@ccc-michigan.com > > > > > > Gene_Gaunt@Review > Works.com To: > mi400@midrange.com > Sent by: cc: > mi400-admin@midra Subject: Re: > [MI400] Error accessing pdm default space > nge.com > > > 07/03/02 09:09 AM > Please respond to > mi400 > > > > > > > > By the way, to get information from an X'0EC4' object, use FNDINXEN, not > SETSPPFP. > > _______________________________________________ > This is the MI Programming on the AS400 / iSeries (MI400) mailing list > To post a message email: MI400@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/mi400 > or email: MI400-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/mi400. > > > > > > > --__--__-- > > Message: 3 > From: "Leif Svalgaard" <leif@leif.org> > To: <mi400@midrange.com> > Subject: Re: [MI400] Error accessing pdm default space > Date: Wed, 3 Jul 2002 08:16:10 -0500 > Reply-To: mi400@midrange.com > > From: <Gene_Gaunt@ReviewWorks.com> > > By the way, to get information from an X'0EC4' object, use FNDINXEN, not > > SETSPPFP. > > maybe DMPSYSOBJ first to get an idea of key structure and layout first. > FNDINXEN kind of needs this information, right? > > > > --__--__-- > > Message: 4 > From: "Leif Svalgaard" <leif@leif.org> > To: <mi400@midrange.com> > Subject: Re: [MI400] Error accessing pdm default space > Date: Wed, 3 Jul 2002 08:20:56 -0500 > Reply-To: mi400@midrange.com > > Bobby, I'm sending you chapter 25 from by eBook. > It deals with Machine Indexes. > > From: <Bobby.Hicks@ccc-michigan.com> > > How do I use the FNDINXEN instruction? > > > > --__--__-- > > Message: 5 > From: "Leif Svalgaard" <leif@leif.org> > To: <mi400@midrange.com> > Subject: Re: [MI400] MI as the MI language of the as400. > Date: Wed, 3 Jul 2002 10:29:59 -0500 > Reply-To: mi400@midrange.com > > Just a few "final remarks" on this whole ILE vs OPM debate... > (parting shots?) > > Who says there was no such thing as a "linker" or "binder" on > OS/400 prior to ILE? > > It may be of interest to note that there were several 3rd party > products, notably ASNA's Diploma/C, that provided the ability > to separately compile separate C routines, and then "bind" them > together into a single, larger, composite *PGM object, all within > the confines of the OPM world, as it then existed (circa 1991). > > How did they do that? ASNA just wrote their own C compiler, > which generated "intermediate" text files (containing MI source), > and they wrote their own "linker" or "binder" that could be used > to combine the separate "text" files into a single larger composite > program. I believe ASNA also had a special syntax that allowed > you to "embed" MI assembler statements right in the middle of > your C programs... > > IBM ToroLabs also came up with APTA - the "Application > Performance Tuning Aid," that allowed you to "bind" together > multiple separately-compiled EPM *PGMs into a single, larger > EPM "bound" *PGM (you could even combine Pascal and C > *PGMs into one bound *PGM), turning CALLX into CALLI > to improve performance. (Remember this was on the old IMPI > machines, where CALLX was much slower...) IBM originally > developed APTA for "internal use only" but eventually made > it available to IBM business partners, etc., circa 1992 -- APTA > was used to build much of the infrastructure for ILE, which > was largely written in C, and so the EPM C/400 compiler was > used to "bootstrap" ILE/C. > > And IBM Rochester LABs also developed "FreeStanding C", > which got released as a PRPQ called "System/C", circa 1993, > that basically did much of what ASNA's Diploma/C did -- you > compile small C routines separately, and then bind them all into > a single *PGM object. But, System/C had no "I/O" library -- > the intent was to use System/C for "systems programming" for > the kind of things that used to require writing in MI assembler. > In fact, System/C introduced the idea of "embedding" MI > instructions as "built-in" functions. And, System/C also had its > own "binder" to combine the intermediate objects into a single > large OPM *PGM. > > By the way, OS/400 V2R3 actually was the first release that > supported and used ILE internally, and ILE C/400 was first > released under V2R3. This is because V2R3 was used as the > "bootstrap" release, and so, the (then new) ILE C/400 compiler > was used under OS/400 V2R3 to develop ILE RPG-IV and > ILE COBOL compilers for the eventual V3R1 and V3R6 > releases. Now, V2R3 was still an IMPI-only CISC release, > so there was no "magic" translator yet; all the OPM *PGMs > still ran "natively" as they had always done. It was not until > you got to V3R6 that the "magic" translator comes into play... > > Hence, none of these concepts like "binding" or "linking" of > separately compiled "modules" was really "new" under OS/400, > and this may lend some credence to the earlier remarks about a > "Second System Effect" from Brooks' "Mythical Man Month". > > My main "gripe" with ILE and the way it was implemented is that > IBM made an (artificial) "division" between OPM and NPM (ILE), > and made it difficult to "share" and easily "cross" that boundary > (at least, in the OPM-to-NPM direction). > > For example, OPM programs are converted by the "Magic" (MX) > translator to run on RISC machines, and in a sense, they become > "quasi"-ILE programs, but they MUST run in the "*DEFAULT" > activation group, which is really a "compatibility mode" for OPM > programs to run in (while "real" ILE programs can run in any > activation group, either "named" or *CALLER, etc.) > > It seems too bad IBM decided not to truly integrate the OPM > and ILE "worlds" into one. For example, how hard would it > really have been to add CALLPP, CALLBP, etc. instructions > (for ILE) into the OPM MI, and perhaps a "special" resolve > instruction to resolve to an "entry point" within a bound ILE > *SRVPGM, so that OPM MI programs could simply issue > a call to a "bound procedure", etc.? I think this functionality > would address most, if not all, of the various "requirements" > that have been debated here over the past several days/weeks, > or even going back to some of the "threads" from last July. > > ("More sins are committed in the name of compatibility" > in Computer Science, alas.) > > Final thoughts: > ========== > A curious thing is, after IBM made this huge investment in ILE, > with a "binder", etc., it turns out that the RISC-based AS/400 > or iSeries machines are SO fast that there is no longer a large > "penalty" for using full "Dynamic Call", so, late-bound, dynamic > CALLX is just "not so bad" any more. And consider also how > many modern languages (like Java) seem to be returning to this > concept of dynamically loading on demand; makes you wonder... > > This may have been one reason why it took so long for vendors > and users to begin converting from the old RPG/400 to the new > ILE RPG-IV... the old RPG/400 code runs "pretty darn fast" on > the new RISC-based AS/400s, so, "If it ain't broke, why fix it?". > It was only after Y2K was behind us, and RPG-IV started adding > more "compelling" features, that people started converting to it, > en masse... > > > > > --__--__-- > > Message: 6 > From: "Njål Fisketjøn" <n.f@figu.no> > To: <mi400@midrange.com> > Subject: RE: [MI400] MI as the MI language of the as400. > Date: Wed, 3 Jul 2002 18:38:41 +0200 > Reply-To: mi400@midrange.com > > Leif Svalgaard wrote: > > > It seems too bad IBM decided not to truly integrate the OPM > > and ILE "worlds" into one. For example, how hard would it > > really have been to add CALLPP, CALLBP, etc. instructions > > (for ILE) into the OPM MI, and perhaps a "special" resolve > > instruction to resolve to an "entry point" within a bound ILE > > *SRVPGM, so that OPM MI programs could simply issue > > a call to a "bound procedure", etc.? I think this functionality > > would address most, if not all, of the various "requirements" > > that have been debated here over the past several days/weeks, > > or even going back to some of the "threads" from last July. > > Do you mean like this? > > > The Call Service Program Procedure (QZRUCLSP) API allows an > unbound call to an ILE procedure exported by a service program. > > The name of the service program and the name of the exported > procedure are passed in as parameters. This API runs in the > caller's activation group. If the specified service program > also runs in the caller's activation group, it will run in the > same group. All dependent service programs are activated and all > initialization of the newly activated service programs is done. > > Since the QZRUCLSP API has no way to determine the parameters > that the called procedure expects, the layout of those parameters > must be described by the caller in a "parameter > format" array. > > All of the parameter values given to this API to be subsequently > passed to the procedure are passed by reference. > > This API does not support calling procedures that have been > defined using "#pragma argopt." > > > --__--__-- > > Message: 7 > From: "Leif Svalgaard" <leif@leif.org> > To: <mi400@midrange.com> > Subject: Re: [MI400] MI as the MI language of the as400. > Date: Wed, 3 Jul 2002 11:52:35 -0500 > Reply-To: mi400@midrange.com > > From: Nj=E5l Fisketj=F8n <n.f@figu.no> > > Leif Svalgaard wrote: > > > It seems too bad IBM decided not to truly integrate the OPM > > > and ILE "worlds" into one" from last July. > > > > Do you mean like this? > > The Call Service Program Procedure (QZRUCLSP) API allows an > unbound call = > to > an ILE procedure exported by a service program. > > > > yes, but directly, not through this clumsy interface. > I could also write my own "glue" program to do the same, but > it is still clumsy. > > > > --__--__-- > > _______________________________________________ > This is the MI Programming on the AS400 / iSeries (MI400) digest list > To post a message email: MI400@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/mi400 > or email: MI400-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/mi400. > > > > End of MI400 Digest >
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
