> Can you tell us more about W-code? W-code is a platform independent intermediate language that is output by most of IBM's more recent compilers on multiple platforms. It is then processed by a platform specific back-end (the bit we refer to as the translator on the AS/400). There are back-ends for Win 95, OS/2, Win 3.1, etc. etc. It is much more of a 'nuts and bolts' assembler type language than the old MI. MI instructions are of the "Move Universe from A to B" type. W-code instructions are more itsy-bitsy. W-code is not a published interface, but it can be obtained by folks who want to write compilers etc. for the platform.

---

In the System API Programming guide chapter 5 contains a very brief introduction to MI programming. Here you also have all the information for a 'do it yourself' MI compiler. However for real programming you need the Functional Reference. The Functional Reference is NOT complete, in the sense that OPCODES reserved for use by IBM (system state programs) are not listed. However the opcodes that are listed are not likely to be changed in the curent millenium. I found that I can sometimes achieve an incredable performance gain by putting SELECTED parts of an application in MI. Especially manipulating Independent Indexes is much faster than using workfiles, of using Indexes with help of the appropriate API, which is incredibly slow. Also MI can be used to retrieve lots of information from a job, or from the system. For instance it can easily be seen how many pagefaults your jobs caused, or how many CPU milliseconds it used. I have used this for performance testing applications that themselves were written in RPG. A very simple MI program can even retrieve information from the system operator panel, like how your key is turned in your machine (if you still have one of those models).

---

QPROCT ("Program Operation Code Table" ??) in QSYS (type x'19DA') contains all valid MI op-codes. There's a lot of the op-codes from the S/38 days that can only be used by system domain programs, and the Create Program API won't recognize them. Database access, create program, etc. is probably considered too "dangerous" (or simply makes it too easy to violate system security or database integrity). Even IBM's compilers doesn't access the DB opcodes directly, but rather through programs QDB*. It's safer to use a HLL like RPG to access files, and use MI for the utlity/system related stuff.

---

> ...... all the compilers generate MI code if they changed MI > a lot, they would need to change all the compilers Just a couple of points. First only the _old_ compilers generate MI. All of current compilers (C, C++, CL, COBOL/400, RPG IV) generate W-code, not MI. Second, the compiler writers are protected from potential changes to MI (or more often to the control blocks etc.) by macros. Even when changes occur, by changing the macro we avoid changes in code. I agree though that MI is not likely to go away any time soon. Jon Paris - Toronto Lab

---

Do you know of any 3rd Party publications that might be useful aside from the IBM book I know of and looking at NEWS/400 articles? Like I said in my previous post, the IBM book (Machine Interface Functional Reference) really gets you nowhere.

---

Well, that struck me. :-) Not that I'm going to dive into MI after that, but it was a nice reading. As some say here : oooole tus huevos!

---

Right, but still, there are things you can do with MI at such a speed you can't do with anything else. We have been doing heavy MI development for years, and the difference is huge. However, we do system tools here, so the investment in manuals, training, and testing pays for itself. Outside the tool development, MI can help you to speed up certain critical functions of your applications... but try other languages first. There is more myth on the "release dependant" issue of MI than reality. Our software run untouched from V1R2 (yeah, I mean Version One Release Two) with the sole exception of two instructions (out of hundreds of thousands lines) that we use for speeding up system internal things, that you are not (definitely) going to use in a business application program (hey, not a surprise here: all the compilers generate MI code - if they changed MI a lot, they would need to change all the compilers - and the beauty of the AS/400 is MI - its machine independant interface). And we achieved subsecond response times in complex Client/Server transactions, for instance, thanks to the MI compiler. But MI *is* complex. You can buy the book (MI Functional Reference) from IBM, but it is not a tutorial. IBM will not help you either. There was a company (Monahon I think) that sold a MI compiler with a handbook, but I don't know if they still are on business (look for them on the NEWS/400 Sourcebook). Good MI examples appeared from time to time on AS/400 magazines as NEWS/400 and MC. You can learn a lot from inspecting the the RPG compiler output in MI. You are going to need a good interactive source debugger as well (the IBM provided debugger will not work). If you need a good one, send me a message, I know a great one. If you, in the end, start a MI programming career, welcome to the club!

---

He *doesn't* have a C compiler at his shops. ;D. That was his question. Anyway, I don't understand why someone wants to write legacy soft *on the AS* in C. Particulary on the AS, whose C compiler is really indecent and whose C++ environment requires aprox 50x (sum soft, CPU & workstations needed) investment as on any other machine. And if it isn´t legacy soft, well, why have you to recompile it for every customer? I don't know what you're doing, JimBob19, but I'm sure you have a better solution behind you as rewriting in MI code, which is machine & release dependent. Tell us some more.

---

If you can do it in C then do it in C. You can order the Machine Interface Functional Reference book from your local IBM literature service. I had this book at my previous work place and found it more than lacking. It only describes a few select system mmemonics such as MATMATR (materialize machine attributes) but certainly doesn't give you any information on how to change any settings on your /400 or even something "simple" as to create an object. (Even though they use the CRTS (create space) OP in their sample programs!) There is as certain *DTAARA in the QSYS library which contains the names of all MI mmemonics known to the system MI compiler (It starts with Q ;-) I don't remember the rest though). Just a fraction of these are documented in above mentioned publication. BTW I heard of a 3rd party MI compiler that has aside from the OPS I just mentioned lots of IBM undocumented MI OPS in it. You might want to check for that.

---

For kicks-n-giggles, I wrote an RPG that used most (all the standard) of the OPCODEs to get work done in RPG, then compiled the program with MI output it's on of the options on the compile. I then took a look at the code. And decided to skip it... Too much like JCL for me... 8-)

---

There are other problems too, for instance objects previously available via MI, can no longer be accessed as they're now in the 'System Domain' (I think it's called) and you get object violations if you go near them.

---

contact IBM, I think you can order this book. and as far as I know MI is release-dependent, opcodes may change without notice.!

---