RE: :( -- MI400

Hello:

I have seen the LIC Diagnostic Aids for V4 and have not been very impressed.
Your E-mail indicated "teach assembly language". There are a couple of
manuals that you could use for this purpose. You might also track down
manuals on the older System/38. However, the "definition" of MI as a
programming language should be differentiated from the "use" of MI.

It is important to distinguish between using MI to support (a) application
programming and (b) systems programming.

AS/400 MI can still be used as a tool to support application programming.
For example we need a high performance index operation to support multiple
applications that use different libraries. The MI program does it very well.
Last week we wrote an MI program to interface with the date format API and
an RPG/36 program. It works well and is very fast! Many years ago we wrote a
program to grab a specific data area with accounting information from an
automotive dealer's QTEMP library. That also worked very well and even
across release boundaries.

Systems programming, on the other hand, seems to be a dying art. It can be
something as simple as a program that dissasembles a message file or even
creates DDS specifications from an actual file. We wrote an MI program that
permits one to change the member date on source files since the restore
messes up dates.

The problem with systems programming on the AS/400 computer is that it is
not an open source machine. Therefore, systems programming comes with an
element of Risk (no pun intended!). The risk is that a new IBM PTF or
operating system release will change the internals and your beautiful MI
program will no longer work or worse, could damage the machine.

Over the past 7 years IBM has responded to this situation by creating many
supported APIs that permit an application to access various system
resources. The key word is "supported". This has permitted many applications
programmers to perform a "controlled level" of system programming without
the added risk of damaging the machine.

The amount of damage that could be caused by a programming error was
extensive. For example, on the older RISC models at V3R6, a bug existed that
could wipe out the first byte in the system entry point table (QINSEPT) if
the wrong number of parameters were returned. On a level 30 security machine
this was devastating. First, the first pointer in this table (QINSEPT) is
the system pointer to the I/O driver. The system would go down very fast. A
microcode reload wouldn't do it, you'd have to restore the operating system.
I don't even think DST could get this fixed. Those of us on level 40
security+ didn't have the problem. Of course IBM issued a correction quickly
and expanded the hardware storage protection to include the QINSEPT at all
security levels.

The As/400 has single level storage so there is some risk of damage is a
program runs in a supervisor state and decides to write binary zeros to the
used segment addresses. This will destroy not only memory but your entire
disk. It certainly will ruin your day (and night)!

I once installed a vendor program that made a copy of my system entry point
table, altered some addresses, and diverted my RPG compiler to the vendor's
programs. What would happen if this changed our RPG program to install a
virus on a client's machine?

How about writing a program to access the system values and change them at
will? While this may have a certain value to some individuals, it also will
jeopardize your computer's stability if not done properly. There are many
vendors who retrieve the system serial number to validate an application.
The problem with this occurs when a client upgrades on a week-end and the
serial number changes. Another problem occured during the world trade center
bombing and people had to bring up their applications on another computer.
Many applications didn't work. We have a CHGSRLNBR cvommand that fixes this
problem for the current IPL. We also make sure this program is NOT RELEASED
because there is potential for damage to a client's machine.

Many of us came from the systems programming environment where we had the
freedom to access operating system internals. We had to recognize that the
stability of our system was far more important to us than the joy of systems
programming and using assembly language for it. Heck, I used to write user
supervisor call programs on a S/370, issue a GETMAIN for main storage, and
update the supervisor call table myself..all without re-generating the
system nucleus! Security was a joke since we'd just set JSCBPASS to X'1' and
all passwords were bypassed for a TSO session!

Of course, one of my younger friends in those days wrote a status program
that could "change" the status of a job. He hard-wired addresses into the
program. (Why not, IBM has done it with several control blocks in the
AS/400!) Of course, when the university regenerated the system nucleus the
addresses changed and my friend's status program took out the computer every
time somebody in the department typed "STATUS"! The economic cost of this
activity for an entire week was surely considerable.

Many of us have made a significant sacrifice. We have traded the use of
assembly language to accomplish system programming for a higher level of
system stability.

Fortunately, the expansion of RPG and the access to QSYSINC and IBM's APIs
has done much to reduce the need for reliance on MI at the application and
systems programming level. Sorry guys, many of you may disagree but just
look at the number of APIs available and accessible from RPG, COBOL, or CL
to support our applications.

For example, IBM recently released a PTF that disassembles the *CMD object
into memory or an *STMF. Now we have a supported way to re-create our *CMD
object. On the other hand I was never able to get IBM to give us a way to
change the source member dates using an API.

I still love MI programming ... its just that the use for it has changed.

In summary, you might want to have some of us develop sample projects that
could be used for a semester course in MI...running in user state of course.
Now if you want to do power PC programming then that is an entirely
different thread...

Steve Glanstein
mic@aloha.com


> -----Original Message-----
> From: owner-mi400@midrange.com [mailto:owner-mi400@midrange.com]On
> Behalf Of Benjamin Budai
> Sent: Tuesday, July 04, 2000 2:36 AM
> To: mi400@midrange.com
> Subject: :(
>
>
> Hi,
>
> I'm working in part time at a university at Budapest (Hungary). We got a
> model 170 this year from IBM for educational purposes. Today a professor
> came to me and asked, wheter we could teach assembly language on the
> AS/400 instead of PCs. I had to say 'That would be nice, but IBM does not
> publish much on low level programming on the AS/400.'
> The CL and Program APIs book has something about MI. I also have
> the MI Func.
> Reference. One can learn the 'alphabet' from these books, but not the
> language. Once I asked IBM for the price of LIC Diagnosic Aids. They
> replied that this book is not orderable, because it contains IBM
> confidential information :( Maybe some people on this list could write
> and publish an e-book on MI programming :)
>
> Benjamin Budai
>
> -
> ELTE ITCS  - AS/400 rendszergazda
> Budapest 1117, Pazmany P. sitany 1/D
> HUNGARY
> +---
> | This is the MI Programmers Mailing List!
> | To submit a new message, send your mail to MI400@midrange.com.
> | To subscribe to this list send email to MI400-SUB@midrange.com.
> | To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> dr2@cssas400.com
> +---
>

+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---