IBM System 38 (1984) [pdf]
cs.washington.edu
cs.washington.edu
I was the worst data entry person. I have dysgraphia, cannot touch type, and am a world class champion of bad spelling. Not a good combination for transcribing acuities from intraocular lens follow ups.
My supervisor was on vacation and the manager needed a report for the FDA so, eager to help, I set about trying to convince paradox (a 4GL) to give me what was required.
I got the report to print but the sorting was all wrong. It was in date order and not grouped by model. Finally, by looking through the in-line help system (1992, no googling), I figured it out and got the report to my manager.
His reaction was not what I expected; he looked exceedingly perplexed.
"Something wrong?"
"It's grouped!", he replied.
"Isn't that the way it should be?", I responded.
He then proceeded to explain two things; he had been asking for the report this way for months, and I was going to be terminated that day.
The best part was that, unbeknownst to me, they were shipping the S/38 from Virginia and needed an operator to work from 12 noon till 3 am and—instead of being fired—I was just about to be offered a new job!
and—instead of being fired—I was just about to be offered a new job!(I once had to rebuild a partition table by hand using nothing but DEBUG.COM and Peter Norton's book..)
I created "REBOOT.COM" and then had our master control application call it on command. The hardest part was working out how to programmatically reboot the PC - for some reason the mainframe guys couldn't work out that a simple "JMP FFFF" was all we needed. Scored points that day. :)
I miss the days when solutions could be that tight. You could have written that .com file with a hex editor back then. Now an ELF header and symbol table is bigger than edit.com
So we all got used to using COPY CON: C:\REBOOT.COM and some sort of Alt-key combo for "JMP FFFF", which defeats me since I haven't thought about it in 30 years or so .. but yeah. It was the last manual-install we did as an admin/dev team, as the reboot was needed so that we could finally add "Remotely administer Workstation Base Image" to the master control program/.BAT file and save ourselves endless late nights. ;)
I recall writing REBOOT.COM myself by using EDIT.COM and writing two bytes (0xCD 0x18 by typing Alt-205 Alt-24, if I recall right) and saving it. That executes interrupt 0x18 which should start the BASIC interpreter in the ROM. But most PCs didn't have one, so instead it rebooted. I discovered this by experimentation :-)
http://www.redbooks.ibm.com/redbooks/pdfs/sg247460.pdf
Additionally there are WPARs as well which are essentially application/workload management containers :-)
https://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/s...
System/3 => System 32 => System 36 => System 38 => AS/400 => iSeries.
But I definitely think we make many, many advances in computing that get washed away by the mass-market mechanics required to get things out there in a way that satisfies the bean counters.
I remember being able to freeze/defrost process on MIPS Risc/OS back in the day .. I even used it as part of my development/test process, since security policies in the computer rooms I was working in the 80's meant that some systems (operational) were not allowed to have compilers - the only way I could test my new build was to run the process, freeze it to disk, send it over to the test-ops machines, and defrost them. I did this so often that it just became commonplace - yet the ability to do this just faded during the 90's when I moved to other environment. I still can't do this easily on any of our existing systems, although there's cryopid and company - but it strike me as amusing that these sorts of capabilities are being touted as new and ground-breaking. More often than not, the discoveries of a unicorn comp-sci grad who just spent 5 years on themselves seem to be re-inventing things they were ignoring all the while were standard, in the rush to push the past aside and no longer deal with dinosaurs.
Its a funny business we're in. I look forward to the next cycle of devo/evo-lution.
Those early home desktops were not the most potent of computers. Remember that there was a distinction made between PCs and workstations.
Thus i fear many that grew up with a PC in the home ended up with something akin to mental blinders.
And by the time they hit higher educational tiers the labs etc had transitions to using PCs on networks rather than terminals tied to a big iron.
Many a recent discovery in science have been thanks to someone glancing over the mental partitions between fields of study and going "hey, i recognize that. We have a decade old solution for it".
They have amazing features in their OS's, for sure, but no amount of marketing budget makes up for "I can throw this on my PC in some fashion that I can learn about those features."
Heck, MS has been using their personal computing market share in their business sales pitches. This in the form of "total cost of ownership". More specifically that people will be accustomed to MS interfaces from their home use, and so less training is needed as new employees.
DragonFly BSD has had kernel-level checkpointing through sys_checkpoint(2) since 2005, but it has limitations with multithreaded programs.
For my part, I treat my Docker files as my own little server-farm, and production is of course managed else-wise, so its all just an amusing analog of how things worked 'in the good old days' ..
Cryopid on Linux looked interesting for a while, but I guess its not really relevant as a feature in this age of hardware. In the good old days, it was necessary to checkpoint to get out of the way of the other jobs the computing facility had to perform .. endless tapes of checkpoints, hanging on the wall, waiting to be spooled, re-spooled, etc.
I know that the RCA Spectra series had virtual memory in the 70's. The Spectra series was a 360 clone with the same instruction set. RCA developed virtual memory and converted their TSOS (Time Sharing Operating System) to VMOS. Univac bought the Spectra line and converted VMOS to VS/9. I worked for Univac at the time.
Virtual memory may have been used earlier by the Scientific Data Systems (SDS) Sigma series, later bought by Xerox. I was once a peripheral device to a Sigma, hooked up for an ECG.
So my first major gig was a startup called Telemed located first in Park Ridge then in Chicago, in an office building at the end of runway 27 L. We built this system of collecting ECG data over the phone line in three-channel FM, converted to digital and then processed by Sigma 5! Sounds like the same system that you were hooked up to. How about that.
The Sigma5 didn't have virtual memory, but the Sigma 7 did. But this was well after both Burroughs and IBM had commercial offerings.
The Sigma series was produced by Scientific Data Systems, later bought by Xerox. Made Max Plaevsky the largest Xerox until Xerox bought University Microfilms.
Heck, thinking about it i kinda get the feeling that a x86 server rack is a breadboarded big iron.
The deployed base is very large and across a great many industries because of resilience, ease of programming, minimal support staff required, and simply because with most big systems it just works. Its not flawless but db2 is far easier to manage than oracle and the iSeries we have operate with much smaller staffs than the AIX/Oracle setups.
Overall the biggest failing is IBM's lack of direction. They tend to push systems which generate the biggest kickback and such, usually meaning their AIX fare.
No matter how many times efforts were put in place to move off the i or even z it just came down to, it works, its modern, and for businesses having something you know is many times better than going with the newest thing.
Thinking back, I think those "systems" (as IBM referred to them) were pretty cool. You could upgrade any part of it, including the central processing units without taking it down, which is pretty remarkable even today. As I recall a "reboot" was referred to as IPL (Initial Program Load) and you only did those when IBM said it was necessary - those things never crashed.
And HTML came before XML.
Another nice thing was getting copies of the Adobe PostScript books (I think we got all 3 of the Red, Blue and Green books) - these came with OpenWindows for NeWS.
As far as IPL's I can't remember a more breathtaking moment when I had to IPL the system and it would come up successfully. And the more horrific event when the 10" floppy used to IPL went bad. LOL, good times.......
http://homes.cs.washington.edu/~levy/capabook/
I remember reading this chapter in the mid 80's when I was starting to develop business software for this minicomputer. The System/38 hardware and OS were not well understood outside of IBM, and Levy's book gave me some sense of what was going on under the hood to make the system secure.
While industrial Lisps may or may not be "functional" compared to today's view of the topic, these implementations were at least based around first-class functions.
I once saw a Smalltalk which used the 286 MMU like this. Each Smalltalk object had its own segment descriptor, effectively exploiting the MMU as a fast and cheap way to implement the object pointer table. The Smalltalk garbage collector could move things around behind the scenes and everything still worked, there being no pointers to update.
Of course, with segment sizes limited to 64kB and a limit of (I think?) 2^13 different segments it wouldn't scale to modern machines, but it was still pretty nifty for a 16-bit system. It's a shame it never got used to its full potential.
Haskell type classes are no different than interfaces, at least conceptually.
Lisp had FLAVOURS, CLOS.
The O in OCaml is actually Objective to imply its support for objects, as its predecessor Caml Light did not have it.
Ruby, PHP, NodeJS, Apache...it's all there. [Zend](http://www.zend.com/en/solutions/modernize-ibm-i) has a completely supported PHP platform on the i. [PowerRuby](http://www.powerruby.com/) has Rails and DB2 support.
Check out www.youngiprofessionals.com for more
[1]: https://stackoverflow.com/questions/tagged/ibm-midrange
Our local IBM reps said that IBM refused to release an Assembler for the S/38, keeping the internals a big secret.
I once wrote an XMODEM crc16 routine in MI because I didn't have the C compiler available and I couldn't get RPG to calculate it fast enough to saturate the modem line.
[1]: http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_71/a...
To add the 2nd frame onto a S/38 - the L-shaped frame on the left, held more I/O cards and I think four more 62ED disk drives (64MB each, IIRC) - there were data cables that ran from the far corner of the 2nd frame to the extreme lower right corner of the card cage in the main unit. The cables ran through every cable channel and card gate in the system, and if the weren't run exactly the way IBM wanted them to be run, they'd come up about a half an inch short and you'd have to re-run them again.
Miserable? Nah. Good times.