7 ms·

Interesting. Never worked on mainframes myself, but have on Unix (and Linux) a lot. Had read some years ago that mainframes had some powerful features that we

by vram22 11y ago

Interesting. Never worked on mainframes myself, but have on Unix (and Linux) a lot. Had read some years ago that mainframes had some powerful features that were often not available on Unixes. One such feature that was available, could be HP's PRM (Process Resource Manager), which, IIRC (from my time at a HP joint venture), could ensure allocation of a guaranteed minimum percentage of system resources (such as RAM and CPU time) to a specific process (say a payroll job running at the end of the month). I remember being impressed by the concept at the time. There was also HP MC/Service Guard, but didn't have a good idea what it did, just remember the name. P.S. Had also tried out rtprio and prioc(n)tl on some Unix boxes, maybe one was an HP one, the other a SVR4. They allowed assigning (quite) higher priorities to specified processes, IIRC. P.P.S. Both those product names could have been changed by now, or been merged into bigger products, as sometimes happens. Edited to say that HP's PRM _was_ an example of a mainframe-like feature.

pjmlp 11y ago
Another one I like very much is how OS/400 works. Written originally in PL/I and Assembly, it contains a kernel level JIT. All user space applications target a general purpose abstract Assembly and they are AOT to native either at installation time or on-demand. Other mainframes had similar approaches to code portability. Sounds familiar? Another cool thing are the catalog based filesystem and OO Assembly.
- nickpsecurity 11y ago
  The JIT scheme worked well for future-proofing for decades. That means it's an approach others should consider emulating if they're not yet. Only thing I couldn't figure out, due to IBM terminology, is if the compiled output is actual microcode or just CPU instructions. Or if they both create a optimized, microcode implementation and a JIT to move things to it. Integrating DB-like functionality into the system was ahead of time. The original, System/38, had capability security in the hardware enforcing an object-based view of memory with permissible operations on different types of objects: processes, I/O, arrays, stacks, and so on. The security implications of that means I'd recommend one to a business in a heartbeat if they hadn't ditched that for POWER. https://homes.cs.washington.edu/~levy/capabook/Chapter8.pdf https://homes.cs.washington.edu/~levy/capabook/Chapter8.pdf All in all, System/38 was a very, forward-thinking and practical design that continues to prove itself year after year. If it doesn't exist, I'd like to see a Lesson's Learned report on that project and how the team decided what would be in it.
- vram22 11y ago
  Kernel level JIT? Didn't know, sounds cool. >Sounds familiar? I suppose you mean like Java and Python bytecode running on their VMs (of the language, not OS kind). I've sometimes thought, as well as heard others say, that some of the tech advancements of earlier decades haven't been "re-invented" :) yet ...
  - pjmlp 11y ago
    Actually I was thinking more about some Oberon versions that used a JIT, the way .NET is integrated into Windows, specially on the mobile since version 7. Also the way Java gets used on Android and other embedded platforms. Or the new deployment model for iDevices.
    - vram22 11y ago
      Ah, Oberon. Don't know much about it. But do somewhat remember an interesting feature of it from a BYTE or other computer mag article: You could write a subroutine once and then have it available in the whole operating system - something like that. My description might not be right but I remember thinking the feature was powerful at the time.
      - pjmlp 11y ago
        Yes, that is correct. But the original idea was from Mesa/Cedar at Xerox PARC.
        vram22 11y ago
        Didn't know, thanks. Also saw that you just posted a link to an article about Mesa on HN. Viewed it briefly. It says the Alto file system was written in "BPCL". Should that BCPL, a precursor of C? Had read a book it, by Martin Richards, IIRC, long ago. Good read. I think it had only one type - machine words. Fun to implement higher level stuff on such a base, though tedious by today's HLL standards.
        11y ago
- cbd1984 11y ago
  > Sounds familiar? Java JIT doesn't write machine code to disk. OS/400 does, and then it re-uses the machine code until it no longer exists (you move to new hardware) or the bytecode is newer (you change the program and recompile), at which point it compiles the bytecode to machine code and stores it to disk again.
  - pjmlp 11y ago
    Actually it does. You just need to look to the correct JVM. Apparently people keep forgetting Java is like C and C++. There are plenty options to choose from and OpenJDK only plays the role of reference implementation. If I am not mistaken IBM J9 is one of those JVMs.
- StillBored 11y ago
  OS/400 doesn't run on s390/zenterprise. It runs on pSeries (POWER8), which also run AIX and Linux. OS/400/IBM i (or whatever its called this week) is actually probably one of the cooler OS's still around. It should be mandatory study in any comp sci/comp eng OS classes, but sadly its not and because of that, a lot of wheels are being reinvented.
  - deleted 11y ago
    [deleted]

by vram22 11y ago

pjmlp 11y ago

Another one I like very much is how OS/400 works. Written originally in PL/I and Assembly, it contains a kernel level JIT. All user space applications target a general purpose abstract Assembly and they are AOT to native either at installation time or on-demand. Other mainframes had similar approaches to code portability. Sounds familiar? Another cool thing are the catalog based filesystem and OO Assembly.

nickpsecurity 11y ago
The JIT scheme worked well for future-proofing for decades. That means it's an approach others should consider emulating if they're not yet. Only thing I couldn't figure out, due to IBM terminology, is if the compiled output is actual microcode or just CPU instructions. Or if they both create a optimized, microcode implementation and a JIT to move things to it. Integrating DB-like functionality into the system was ahead of time. The original, System/38, had capability security in the hardware enforcing an object-based view of memory with permissible operations on different types of objects: processes, I/O, arrays, stacks, and so on. The security implications of that means I'd recommend one to a business in a heartbeat if they hadn't ditched that for POWER. https://homes.cs.washington.edu/~levy/capabook/Chapter8.pdf https://homes.cs.washington.edu/~levy/capabook/Chapter8.pdf All in all, System/38 was a very, forward-thinking and practical design that continues to prove itself year after year. If it doesn't exist, I'd like to see a Lesson's Learned report on that project and how the team decided what would be in it.
vram22 11y ago
Kernel level JIT? Didn't know, sounds cool. >Sounds familiar? I suppose you mean like Java and Python bytecode running on their VMs (of the language, not OS kind). I've sometimes thought, as well as heard others say, that some of the tech advancements of earlier decades haven't been "re-invented" :) yet ...
- pjmlp 11y ago
  Actually I was thinking more about some Oberon versions that used a JIT, the way .NET is integrated into Windows, specially on the mobile since version 7. Also the way Java gets used on Android and other embedded platforms. Or the new deployment model for iDevices.
  - vram22 11y ago
    Ah, Oberon. Don't know much about it. But do somewhat remember an interesting feature of it from a BYTE or other computer mag article: You could write a subroutine once and then have it available in the whole operating system - something like that. My description might not be right but I remember thinking the feature was powerful at the time.
    - pjmlp 11y ago
      Yes, that is correct. But the original idea was from Mesa/Cedar at Xerox PARC.
      - vram22 11y ago
        Didn't know, thanks. Also saw that you just posted a link to an article about Mesa on HN. Viewed it briefly. It says the Alto file system was written in "BPCL". Should that BCPL, a precursor of C? Had read a book it, by Martin Richards, IIRC, long ago. Good read. I think it had only one type - machine words. Fun to implement higher level stuff on such a base, though tedious by today's HLL standards.
        11y ago
cbd1984 11y ago
> Sounds familiar? Java JIT doesn't write machine code to disk. OS/400 does, and then it re-uses the machine code until it no longer exists (you move to new hardware) or the bytecode is newer (you change the program and recompile), at which point it compiles the bytecode to machine code and stores it to disk again.
- pjmlp 11y ago
  Actually it does. You just need to look to the correct JVM. Apparently people keep forgetting Java is like C and C++. There are plenty options to choose from and OpenJDK only plays the role of reference implementation. If I am not mistaken IBM J9 is one of those JVMs.
StillBored 11y ago
OS/400 doesn't run on s390/zenterprise. It runs on pSeries (POWER8), which also run AIX and Linux. OS/400/IBM i (or whatever its called this week) is actually probably one of the cooler OS's still around. It should be mandatory study in any comp sci/comp eng OS classes, but sadly its not and because of that, a lot of wheels are being reinvented.
- deleted 11y ago
  [deleted]