Using MI Functions and HLL's

[Guest.Visitor]

Hello everyone, Now is as good of time as any to ask a question that I've been wondering about. According to what I've read, and some COMMON seminars that I've attended, in order to call OS/400 MI functions, one has to use ILE C. ILE C is what I've been using. However, I have also noticed that other programmers have been able to use other HLLs, such as RPG IV and ILE Cobol, to call OS/400 MI functions. I was wondering if I missed something or if things have changed. Can a programmer always use RPG and Cobol to call OS/400 MI functions, or are there exceptions? If there are exceptions, what are they? What are the advantages and/or disadvantages of using MI functions over APIs. I understand that MI functions are quicker than APIs. I have also heard that IBM will maintain compatibility for it's APIs, but not neccessarily it's MI functions. Is this true? .... Just thought I'd ask and thanks in advance.

[Guest.Visitor]

RPG is a dirge. C is a symphony. REXX is bebop. Java is elevator Muzak. But assembler is J.S. Bach.

[Guest.Visitor]

On Monday, September 28, 1998, 12:14 PM, Gene Gaunt wrote: RPG is a dirge. C is a symphony. REXX is bebop. Java is elevator Muzak. But assembler is J.S. Bach. <hr><font color=blue> I have found assembler and RPG (prior to RPG IV) to be similar in structure.</p></font>

[Guest.Visitor]

On Friday, September 25, 1998, 06:53 PM, Sol Solomon wrote: ILE is the linking of modules from one or more languages into a single program. Also the ability to statically bind these different modules together which results in faster call performance. <hr> Sounds like a defintion of the linkage editor thats been running on Big Iron housed in a Dinosaur Pen for over 30 years. A cow produces 200 times more gas a day than a person.

[Guest.Visitor]

On Monday, September 28, 1998, 10:29 AM, David Abramowitz wrote: On Monday, September 28, 1998, 08:33 AM, Joe Pluta wrote: <font color=#804030> I've always felt that music in particular meshes well with the mathematical mindset of many programmers. </font> I've heard this before many times, but I never understood the connection. I've had people tell me: Oh!, your a musician, then you must be a <u>goooood</u> programmer. I smile, but I never saw why. David Abramowitz, B.M., M.M. <HR> Musicians are used to seeing repetitions, variations on a theme et c. and many of these talents translate quite easily into creating computer programs. ...... <pre> <H4> Bob Hamilton TEXAS BUSINESS SYSTEMS 736 Pinehurst Richardson, Texas 75080 <h4> </pre></h4></h4>

[Guest.Visitor]

On Monday, September 28, 1998, 11:08 AM, Mario Martinez wrote: I'm not aware of any specific math/music studies, but it's just something that have heard before. <HR> You might look in late 50s early 60s editions of IBM Systems Journal. The effect has been known and documented... See my earlier note in this thread... I am not quite as hard-nosed as the Dean who, when the University was trying to change the name of his College from College of Art and Science to College of Arts and Sciences, said: "... there is only one art and that is mathematics and only one science and that is physics; all else derives from Art and Science, specious labels to the contrary notwithstanding." ...... <pre> <H4> Bob Hamilton TEXAS BUSINESS SYSTEMS 736 Pinehurst Richardson, Texas 75080 <h4> </pre></h4></h4>

[Guest.Visitor]

To add to Mario's questions, I don't think MI involves a one-to-one conversion process like assembly language. If this is true, then why is there not an assembly language for the AS/400? Is the machine language on the AS/400 so unique that the assembler language format would not be similar to what is used on IBM mainframes and IBM-compatibles (Amdahl, UNIVAC etc.)? Unlike high-level coding, assembler language programming provides you with an understanding of how the machine actually operates on data. This understanding will enable you to program with the utmost efficiency (this may not be as important as it used to be) and to code routines that would be difficult to write in other programming languages. Many AS/400 programmers that have only programmed in a high-level language may have experienced (1) the frustration of encountering a processing error that they were unable to understand because they were unfamiliar with the machine's method of operation, and (2) the desire to learn more about how the computer actually operates on data. If this was done years ago, I believe the AS/400 would have received a lot more attention, respect and publicity etc.

[Guest.Visitor]

To write a good program you have to get rid of the bad insructions, to write a good piece of music you have to get rid of the bad notes.<hr> 12 newborns will be given to the wrong parents daily.

[Guest.Visitor]

Mario, The manual "IBM VisualAge C++ for OS/400, C Library Reference (SC09-2119-00)" defines these functions in chapter 3. It describes the why/why nots and exceptions. These functions are implemented as procedures exported from service programs supplied as part of the OS. Traditionally they would have been called from C only, but the introduction of support for procedures, pointers and the main C datatypes and parameter passing conventions in RPG means these functions are directly available from RPG. COBOL to I gather. So to use them you just do a "normal" procedure call, where you use the normal C calling conventions. And you just include the QC2LE binding directory during object creation. There have been a number of examples posted in this forum, and others. They are a published interface, so I assume they are reasonably stable. Sometimes they're quicker, sometimes they simply let you do things that you couldnt otherwise do (without resorting to C...). hth, Derek <font color="#0000CC"> On Monday, September 28, 1998, 02:48 PM, Mario Martinez wrote: Hello everyone, Now is as good of time as any to ask a question that I've been wondering about. According to what I've read, and some COMMON seminars that I've attended, in order to call OS/400 MI functions, one has to use ILE C. ILE C is what I've been using. However, I have also noticed that other programmers have been able to use other HLLs, such as RPG IV and ILE Cobol, to call OS/400 MI functions. I was wondering if I missed something or if things have changed. Can a programmer always use RPG and Cobol to call OS/400 MI functions, or are there exceptions? If there are exceptions, what are they? What are the advantages and/or disadvantages of using MI functions over APIs. I understand that MI functions are quicker than APIs. I have also heard that IBM will maintain compatibility for it's APIs, but not neccessarily it's MI functions. Is this true? </font>

[Guest.Visitor]

Derek, Your tip is starting to make a lot of sense. I'll look at that manual. The COMMON seminar and the documentation that I refered to, were from a couple of years ago. A lot can change in that time. I've noticed the examples of using MI function with RPG and/or Cobol in this forum and others. That's why I asked. Thanks for the tip.

[Guest.Visitor]

<font color="#3333CC"> On Monday, September 28, 1998, 04:35 PM, Tom Conover wrote: To write a good program you have to get rid of the bad insructions, ... </font> Tom, My feeling is that Bad Insructions should punished severely. Public floggings of GOTOs would get my support. I would however be concerned about your suggestion to just "get rid" of them. Maybe they didnt know better. Maybe they could be made to see the error of their ways. Where might it all end? Derek

[Guest.Visitor]

<font color=blue> On Tuesday, September 29, 1998, 12:27 AM, J V Thompson wrote: I compile modules out of library DEVSRC, then when tested, move live to another AS400, where the live source is kept in library PRODSRC. Anyone know of a better way around this? </font> Compile with DBGVIEW(*LIST) presuming the extra space is not too great. My presonal prefence would be to recompile the source from PRODSRC before promotion into development. Makes it easy to reconcile later if required....like Y2K. <font color blue> On Tuesday, September 29, 1998, 12:01 AM, Panida wrote: So what the programmer do is put in SRCDBGPGM parameter with the same member of the program from other library. Then we got the message CPF1912. There should not be the security problem since we grant *ALL autority to the source pf. And I think it should work since this should be the purpose of this parameter (Maybe I misunderstand). Anybody please clear me. </font> Panida, My understanding of the SRCDBGPGM is the program specified as SRCDBGPGM runs as the debugging program. (i.e. I dont think it will do what you are trying to get it to do). If you want a source view I believe you will have to move the source back to the original library, or recompile the object from the current source location.

[Guest.Visitor]

On Monday, September 28, 1998, 11:26 PM, Derek Butland wrote: Tom, My feeling is that Bad Insructions should punished severely. Public floggings of GOTOs would get my support. I would however be concerned about your suggestion to just "get rid" of them. Maybe they didnt know better. Maybe they could be made to see the error of their ways. Where might it all end? Derek <hr>"There are no bad programs, only bad programmers." will be our motto, and we'll start a home for wayward programs. Very PC-correct 8-). .... just trying to make it to the finish line ....

[Guest.Visitor]

On Monday, September 28, 1998, 04:26 PM, Tom Conover wrote: To add to Mario's questions, I don't think MI involves a one-to-one conversion process like assembly language. If this is true, then why is there not an assembly language for the AS/400? Is the machine language on the AS/400 so unique that the assembler language format would not be similar to what is used on IBM mainframes and IBM-compatibles (Amdahl, UNIVAC etc.)? Unlike high-level coding, assembler language programming provides you with an understanding of how the machine actually operates on data. This understanding will enable you to program with the utmost efficiency (this may not be as important as it used to be) and to code routines that would be difficult to write in other programming languages. Many AS/400 programmers that have only programmed in a high-level language may have experienced (1) the frustration of encountering a processing error that they were unable to understand because they were unfamiliar with the machine's method of operation, and (2) the desire to learn more about how the computer actually operates on data. If this was done years ago, I believe the AS/400 would have received a lot more attention, respect and publicity etc. Tom, It seems to me that you don't understand some of what makes the AS/400 so unique. In effect, MI **IS** the assembly language of the AS/400. The AS/400 is a **SOFTWARE** definition of a machine. Below the MI, IBM can do whatever they want. Above the MI, changes must be made very carefully. (Generally they just add stuff, never taking away stuff.) That is what allows the "seamless" transition from 48-bit IMPI to 64-bit RISC. Think about what you already know about "how the machine operates on data." EVERYTHING is a program call. EVERYTHING is microprogrammed. DB operations are calls. Device I/O operations (source/sink) are calls. Messages are calls. Just about all of it. If you desire to learn more about how the /400 works, I would suggest you buy Frank Soltis' book, "Inside the AS/400" from Duke Press. Frank is "da man" for the /400. The architecture for the /38 and /400 grew out of his doctoral thesis. I would expect this board would welcome the opportunity to understand (or to help you understand) some of these problems you reference that would be aided by a deeper understanding of the machine. I know I would. Cheers, Michael

[daly.michael@verizon.net]

On Monday, September 28, 1998, 11:26 PM, Derek Butland wrote: Tom, My feeling is that Bad Insructions should punished severely. Public floggings of GOTOs would get my support. I would however be concerned about your suggestion to just "get rid" of them. Maybe they didnt know better. Maybe they could be made to see the error of their ways. Where might it all end? Derek<hr> On Tuesday, September 29, 1998, 04:33 AM, Jo Ann Burelle wrote: "There are no bad programs, only bad programmers." will be our motto, and we'll start a home for wayward programs. Very PC-correct 8-). <hr>60 Minutes will do a story about how we are all PC and charitable on the outside, but what we are really doing at our home for wayward programs is "re-programming". We'll get arrested and stand trial for flagrant civil rights violations. It'll be a big mess. Better if we just take 'em out to the country and put 'em outta their misery.

[Guest.Visitor]

On Tuesday, September 29, 1998, 12:27 AM, J V Thompson wrote: Panida, I'm not sure I understand your problem correctly, but it sounds a lot like one I have. I compile modules out of library DEVSRC, then when tested, move live to another AS400, where the live source is kept in library PRODSRC. If ever I try to debug a program on the production machine, the debugger returns 'Source not accessible'. It does this because it's trying to find the file DEVSRC/QRPGLESRC - the file the module source was in when it was originally compiled. My fix to this has been to create library DEVSRC on the production machine, and copy the source I want to debug over from PRODSRC just prior to starting the debugger. It's a bit of a pain though, as often the problem is in some other module that I haven't copied over. Anyone know of a better way around this? John, It seems to work for programs if you do an OVRDBF FILE(QRPGLESRC) TOFILE(PRODSRC/QRPGLESRC). For service programs I haven't got a good solution. David Morris

[daly.michael@verizon.net]

On Monday, September 28, 1998, 04:26 PM, Tom Conover wrote: ...snip... If this was done years ago, I believe the AS/400 would have received a lot more attention, respect and publicity etc. ...and viruses?!? ...and competitive OS's that are as stable as Windows?!? NO THANK YOU!!! Let IBM keep their low level processes secret. It doesn't bother me one bit. One day, we'll all be heroes.

[Guest.Visitor]

Mario wrote: ...I have also heard that IBM will maintain compatibility for it's APIs, but not necessarily it's MI functions. Is this true?... In the broadest sense, AS/400 Application Programming Interfaces (APIs)are any formal interfaces that are intended to be used by application developers. As such, APIs can (and do) include callable functions, exit points, Machine Interface (MI) instructions, RPG syntax and semantics, etc. The AS/400 development group places a high value on upward compatibility of the APIs (as defined above) and goes to great effort to maintain compatibility. Any given API can however be "broken" if a sufficiently radical change is made in the underlying system. The movement to RISC, for instance, included a rework of the underlying hardware system which impacted the Performance APIs, Outfiles, Commands, Hardware Materialize MI, and others (see the V3R6 Memo to Users for additional details). In the case of incompatible changes over time it is true that MI, in part due to it's close affinity to the system, has been subject to more changes than other APIs (again see recent Memo to Users for examples). MI can however often provide greater performance than other forms of APIs, and often can access additional information -- sometimes an acceptable trade-off for possible release to release rework considerations. ...Can a programmer always use RPG and COBOL to call OS/400 MI funtions, or are there exceptions?... ILE MI is available, either directly or indirectly, to the ILE languages C, COBOL, and RPG. In the case of callable MI functions, OS/400 provides a set of *SRVPGMs which externalize many MI functions. These functions are currently documented in various C language reference manuals. In addition C and COBOL have the ability to directly access MI functions without the need to call a *SRVPGM function; in C this is via the #pragma linkage builtin, in COBOL the linkage type sys. These interfaces are documented in the MI Function Reference manual. Can any of these languages access all unblocked MI at all security levels in a manner IBM supports? Not really. Some languages, like RPG, have no formal support for system pointers; some MI instructions fail at security levels greater than 30 so users must move to callable functions like those found in the System API Reference; etc. So while MI is not the answer to all a developers needs, it does represent another set of tools which could be utilized. As with all tools though, you need to know what you're getting into; also MI support is definitely not as easy to find as, for example, CL or RPG assistance is which can be a definite consideration to some.