The s/360 was not virtual in matter of frograms that much, but the cake was a lie. I mean the CPU!!! What I mean by that there was no native s/360 processor, only native instructions performed by a black box. In lowest grade mainframes that were sold contained only 8-bit 'true' CPU, but had all the address bus and data bus and instructins as the rest of the machines. This separation allowed some great things - the mainframes could evolve, but the programs would stay. There was nothing like that before mainframes. As one japanese bank manager said: some of the programs written in the 60's still run today! And then he talked something about calculating interest rates for each account was performed MANUALLY at each of the bank facilities at the end of the month all over the world before mainframes came, that it allowed booking of the tickets and rise of the credit cards.
Remember also that mainframes are transactional systems, that they perform no error, they check and correct themselves on many levels, no matter hol long it takes, only measure is how accurate that is. Typical transaction is a money transfer. It is taken from one acount and added to some other. It can not stay in between them, nor it can be added to both. There is linux under z/OS and other systems such as native Linux/390, slack390.org are already used. Check it if you are interested in this area, they may grant you a free access to that machine dedicated to linux on mainframes development. As for the interfaces, now there is so much finished drivers for the various I/O cards that you would wonder... IBM fully supports this initiative. On 11/10/07, Jon Elson <[EMAIL PROTECTED]> wrote: > Mario. wrote: > > Yest, porting EMC2 to the s/390 or z/990 consists of two parts. You > > have to separate the ordinary linux part and the realtime part. The > > realtime and I/O part may require rewriting due to the fact that for > > I/O you need to use a specific I/O card, good news is that these cards > > are highly intelligent by themselves so they could perform a variety > > of tasks. > > > Ah, yes, we could, of course, use a multiplexer channel to > handle I/O, and either hack a comm controller, or alter my FPGA > to handle bus and tag protocol. That would certainly be an > interesting project. The IBM systems architecture is quite > unlike how a PC works in many ways, most especially how the > channels are programmed by the application program to perform > I/O the way the user wants it, rather than how the system does > it, and it better be good enough for you. I wonder how much of > that is compatible with Linux. I would guess not much at all. > A massive security hole, and anybody can write a channel program > that monopolizes at least some system resources. (Yes, I know > they have the security implications under control, but it adds > complexity, and you can never be sure you have every aspect of > the hole plugged.) > > > I understand that you meant that as a joke, but these "big iron" > > computers are good for what they are good for. For terminal access > > where you can perform a infrequent high performance computation > > requiring much resources, such as is the kernel compilation. > > I learned computer programming to a substantial extent on IBM > 360 mainframes, and was always fascinated by how different the > architecture, especially the I/O channels and control units, was > from other systems. > > > > Remember, mainframes were were since the very beginning as fully > > virtualised systems, so all realtime timing and such is naturally done > > with specialised boards. > Oh, the 360 wasn't very virtual at all! It was concurrently > multi-user, but just barely. The 370's could get virtual, but > at a fairly high cost in overhead. We had some 370/135's that > would take 3-4 hours to virtual-IPL an MVS system under VM/370. > We used to laugh at that misapplication of systems. > > Jon > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
