[HN Gopher] Inside an IBM/Motorola mainframe controller chip fro...
___________________________________________________________________
Inside an IBM/Motorola mainframe controller chip from 1981
Author : todsacerdoti
Score : 127 points
Date : 2024-07-16 17:27 UTC (1 days ago)
(HTM) web link (www.righto.com)
(TXT) w3m dump (www.righto.com)
| kens wrote:
| Author here if anyone has questions...
| java-man wrote:
| Thank you for your work, every article brightens my day!
|
| Every time I look at the chips from 70s and 80s, I notice how
| huge the features are. Was that determined by the current
| stepper technology at the time, or by the fact that people drew
| the early designs by hand?
|
| Or am I totally wrong and the chips are always at the limit of
| the contemporary technology?
| kens wrote:
| The feature size on chips has steadily shrunk from 10 um for
| the Intel 8008 to a few nanometers nowadays. The feature size
| is determined by the limits of contemporary technology, which
| steadily improves as described by Moore's Law. Many different
| technological aspects need to improve to shrink the features,
| from the design techniques to the optics to the chemical
| processes.
| Pet_Ant wrote:
| 10 is 10,000 nm. "3nm" apparently has a "gate pitch" of 48
| nm _, that is 0.5% of the size!
|
| _ I don 't know that "gate pitch" is the correct metric,
| but I do know that modern marketing nodes don't correspond
| to reality so this is my crude attempt at trying to bring
| it to physical reality. Not sure if I did it correctly.
| bobmcnamara wrote:
| > Or am I totally wrong and the chips are always at the limit
| of the contemporary technology?
|
| I can chime in here. There are many things that determine the
| feature size.
|
| There is the process limit, yes, and if your needs are simple
| digital logic, that's often going to be the density limit.
|
| But if you need NOR flash, there's a stability limit around
| 40nm process node. You can use smaller transistors for
| everything else, but soon the NOR is most of the chip.
|
| But what if you need a 1 Amp FET in your PMIC? Well, that
| won't shrink with process node at all, so maybe a cheaper
| process node is better to use.
|
| It really depends.
| java-man wrote:
| Yes, I was referring to 70's and 80's. Even today, I think,
| there are applications where 150 nm process is perfectly
| fine - RFID, transportation cards etc.
|
| If you look at the 74 TTL series dies, they look almost
| primitive. But perhaps these were one of the first attempts
| at ICs, so it is expected.
|
| When did transition from hand-drawn to computer-generated
| designs happen?
| greenyoda wrote:
| > If you look at the 74 TTL series dies, they look almost
| primitive. But perhaps these were one of the first
| attempts at ICs...
|
| TTL wasn't the first attempt at ICs. Before TTL, there
| was RTL:
|
| https://en.wikipedia.org/wiki/Resistor%E2%80%93transistor
| _lo...
| bonzini wrote:
| Around the mid 80s, for example the 386 was the first x86
| processor to largely use standard cells.
|
| It seems appropriate to cite Ken's blog post on the
| topic: https://www.righto.com/2024/01/intel-386-standard-
| cells.html
| CamperBob2 wrote:
| _But what if you need a 1 Amp FET in your PMIC?_
|
| You use lots of very small FETs in parallel (and derate the
| living bejesus out of the SOA curves, because there's no
| chance that they'll all run at the same temperature.)
| kragen wrote:
| i mean in effect a hexfet _is_ a lot of very small fets
| in parallel
|
| nice thing about fets, hotspots don't hog current, so you
| don't have to derate the living bejesus out of the soa
| curves
| CamperBob2 wrote:
| Huh? Almost all modern power FETs have positive tempcos.
| The resulting hotspots (actually hot _transistors_ ) are
| the reason for the SOA curves, and the reason why most
| modern power FETs don't do well in linear applications.
| kragen wrote:
| interesting, i didn't realize that had happened
| renewedrebecca wrote:
| Really appreciate the work you do on documenting these chips.
| It's awesome to see how the stuff I only worked with from the
| programming side works at the hardware level.
| kens wrote:
| Thank you to you and all the others in this thread for your
| positive comments. I almost didn't write about this chip
| because it is so obscure, so it is encouraging that people
| are reading it.
| anyfoo wrote:
| In some ways, the obscurity makes it even more interesting.
| That's of course not to say that I didn't enjoy your
| articles about popular chips like the Z80 or any x86
| variant as well, I really do. One is interesting because
| you get fantastic insight into the chips you've been using
| for so long, the other because it's a glimpse into an
| unfamiliar world.
| kaladin_1 wrote:
| Thanks a lot for the work you do in documenting these chips.
|
| I am a software engineer that mostly sell fullstack skills.
| After reading your article on the chip that powers Montreal
| subway, I developed an interest in chip architectures.
|
| I just finished these two books, The Soul of a New Machine by
| Tracy Kidder and Hackers by Steven Levy, they are historical
| books on computer design.
|
| If you have other good reads that a web dev can use in testing
| the waters I would appreciate.
| abraae wrote:
| The Mythical Man Month by Fred Brooks is always worth a read.
| It's now an ancient tome (e.g talk of how much storage space
| comments take up) but there is a lot of wisdom there and it
| certainly ticks the historical box. It's one of the only
| books I re-read regularly.
| jdougan wrote:
| I also reread MMM from time to time. Also Peopleware and
| Yourdon's Death March.
| kragen wrote:
| if you want to understand chip architectures, work through
| _the elements of computing systems_ (aka _nand to tetris_ ).
| it walks you through implementing your own cpu, gate by gate,
| plus an operating system, compiler, and tetris game, in a way
| tested to successfully fit inside of a single-semester
| undergraduate class. their hardware designs are pretty weird
| (their hdl looks nothing like any hdl you can actually
| synthesize hardware from, their descriptions of how gates
| work are oversimplified, and their instruction set
| architecture is pretty similar to the eclipse that kidder was
| writing about but completely unlike any current design) but
| that isn't really important
|
| after completing the work in that book and raising investment
| capital for your company, you can honestly call yourself a
| fullstack engineer
|
| -- arm --
|
| the best architecture to _write_ assembly for is the arm--the
| original one, not thumb, which is a bit of a pain--and arm is
| also only slightly more complex _to build_ than the fake-ass
| architecture in nand2tetris, and quite a bit faster. if you
| already know any assembly language, including the nand2tetris
| one, the best introduction to arm might not actually be any
| current tutorial but rather the vlsi arm3 datasheet from
| 01990 https://www.chiark.greenend.org.uk/~theom/riscos/docs/A
| RM3-d... which has a summary of the instruction set on p.1-7
| (9/56) and a fully complete description on pp.3-12 to 3-43
| (19/56 to 34/56)
|
| as you probably know, the vast majority of the cpus around
| you run the arm instruction set or its thumb variant,
| although amd64 and aarch64 (arm64) are also significant. the
| current arm architecture reference manual describes all the
| new instructions that have been added since arm3, as well as
| thumb, which makes it enormous and intimidating, with a very
| low signal-to-noise ratio
|
| if you _don 't_ know any assembly, the three best actual
| tutorials for arm that i've found are
| https://www.coranac.com/tonc/text/asm.htm (aimed at the
| gameboy advance), https://devblogs.microsoft.com/oldnewthing/
| 20210531-00/?p=10... (aimed at windows 10, thumb-only), and
| https://azeria-labs.com/writing-arm-assembly-part-1/ (aimed
| at crackers). these are all much longer than the relevant
| part of the arm3 datasheet but will guide you through how to
| actually use the things
|
| -- teensy programs --
|
| perhaps the best introduction to writing assembly language
| _in general_ on current systems is https://www.muppetlabs.com
| /~breadbox/software/tiny/teensy.ht..., which is not really
| focused on assembly at all, but on understanding how the
| interface between the operating system (i386 linux in this
| case) and user programs work, which just happens to be at the
| assembly-language level
|
| it's also a lot more fun to read than any of these except
| maybe kidder and levy
|
| -- risc-v --
|
| the risc-v architecture is very similar to arm but simpler;
| however, it's a little more of a pain to program, and there
| aren't any high-performance implementations of it out there,
| something that's likely to change in the next few years. the
| part of the risc-v manual https://riscv.org/wp-
| content/uploads/2019/12/riscv-spec-2019... that corresponds
| to the part of the arm3 manual i recommended above is chapter
| 2, rv32i base integer instruction set, pp.13-29. this
| reflects an additional 30 years of computer architecture
| lessons from arm and its successors, and a lot of those
| lessons are helpfully explained in the italic notes in the
| text. geohot livecoded a full implementation of risc-v in
| verilog on his twitch stream a few years ago, so you can
| literally implement risc-v in an afternoon:
| https://github.com/geohot/twitchcore
|
| gcc can compile to risc-v and generates decent code, and
| linux can run on it, but the risc-v that linux runs on is
| quite a bit hairier to implement than the rv32i isa; you have
| to implement the risc-v privileged isa
|
| -- if what you're interested in is how _varied_ cpu
| architectures can be --
|
| probably risc-v and arm won't do it for you
|
| the nand2tetris 'hack' is pretty weird, and very similar not
| only to the dirty genitals nova, but also to chuck thacker's
| 'tiny computer for teaching' https://www.cl.cam.ac.uk/teachin
| g/1112/ECAD+Arch/files/Thack... which is two pages of vhdl
|
| weird in a different direction is the tera mta, which has 128
| hardware threads and context-switches every clock cycle; the
| 11C/ padauk pmc251 microcontroller does the same thing (but
| with only two threads; padauk sells parts with up to four
| threads)
|
| the tera mta was designed to compete in the vector
| supercomputer field originally defined by the cray-1, which
| had a very different architecture; the convex
| https://news.ycombinator.com/item?id=40979684 was very
| similar to the cray-1
|
| in a sense, though, the cray wasn't really the first
| supercomputer; the cdc 6600, also designed by seymour cray,
| was, and it was arguably the first risc, in 01964
|
| unlike all of these, the burroughs 5500 architecture had no
| registers, just a stack, and that's what smalltalk, java, and
| c# are based on
|
| the 12-bit pdp-8 was the first really mass-produced computer,
| with over 50000 units sold, and its architecture is
| interestingly different from all of these, too; intersil
| produced a 4000-gate single-chip version, and the family was
| popular enough that there are pdp-8 hobbyists even today
|
| most current numerical computation is being done on gpus, and
| i don't know what to recommend as reading material on gpus,
| which have bizarrely different instruction set architectures
| that use a model called 'simt', single instruction, multiple
| thread. if anyone does, let me know
|
| finally, chuck moore's line of two-stack processors based on
| forth are a sadly underdeveloped branch of the genealogical
| tree; koopman's _stack computers: the new wave_ https://users
| .ece.cmu.edu/~koopman/stack_computers/index.htm... goes into
| their historical development a bit. they had some significant
| success in the 80s (the novix nc4000 and the harris rtx2000)
| but the later members of the family (the sh-boom, the mup21,
| the stillborn f21, the intellasys seaforth 40c18, and the
| greenarrays ga4 and ga144 chips) have no real users, in part
| due to malfeasance--after losing a protracted lawsuit with
| moore, intellasys head dan leckrone now goes by 'mac
| leckrone', perhaps as a result
|
| there are lots of other interestingly different instruction
| set architectures out there: s/360, 6502, amd64, pic16, the
| erim cytocomputer, the thinking machines cm4, the em-4
| dataflow machine, the maxim maxq, the as/400, webassembly,
| vulkan spir-v, the hp 9825 desk calculator, saturn (used in
| the hp 48gx), etc.
|
| i hope this is helpful!
| kaladin_1 wrote:
| Thanks a lot, I appreciate the effort required to write in
| detail. I will work through it.
|
| I could not find your email in your HN bio. I wonder if you
| have any public "queue " people can send interesting things
| they are working on and perhaps seek for guidance/opinion.
|
| Edit: found loads of emails here,
| http://canonical.org/~kragen/about/ :)
| sillywalk wrote:
| I'm not sure if it's quite what you're looking for, but
| _Inside the Machine_ by Jon "Hannibal" Stokes of Ars
| Technica has a good overview of computer architecture in
| general, plus detailed looks at some different processors.
|
| From the Introduction:
|
| "Inside the Machine is an introduction to computers that is
| intended to fill the gap that exists between classic but more
| challenging introductions to computer architecture, like John
| L. Hennessy's and David A. Patterson's popular textbooks, and
| the growing mass of works that are simply too basic for
| motivated non-specialist readers. Readers with some
| experience using computers and with even the most minimal
| scripting or programming experience should finish Inside the
| Machine with a thorough and advanced understanding of the
| high-level organization of modern computers. Should they so
| choose, such readers would then be well equipped to tackle
| more advanced works like the aforementioned classics, either
| on their own or as part of formal curriculum."
| mrgaro wrote:
| Thanks Master Ken for doing these awesome posts and
| participating in the Marc's youtube channel! Both amazing
| content!
| throaway12345 wrote:
| I really love these updates. I really appreciate your articles
| and they've made me go into a deep dive into the history of
| microchips and IC design in general.
|
| How did you get into this in the first place? From your blog I
| gather that you used to be in software (or still are).
| kens wrote:
| How did I get into this? It started when I saw the simulation
| of the 6502 processor from the Visual6502 team [1]. It was
| very cool, but totally mysterious. I realized that even
| though I was a programmer and understood the "full stack", I
| had no idea how a processor chip actually worked. (I'd taken
| computer architecture courses but there's still a big jump to
| physical transistors on a chip.)
|
| I started looking at the 6502's circuits and one thing led to
| another and here I am today, reverse-engineering obscure
| chips with a microscope :-)
|
| [1] http://www.visual6502.org/JSSim/index.html
| throaway12345 wrote:
| Hehehe. Maybe some day if somebody asks me "how did you get
| into ICs?" I'll have to answer "well, I kept reading Ken
| Shirriff's blog..."
|
| Also, what type of microscope do you use?
| kens wrote:
| I use an AmScope ME300TZB-2L-10M metallurgical microscope
| that I got for cheap on eBay. My friends all have cooler
| microscopes :-)
| PaulHoule wrote:
| I was lucky to get to use an IBM 3090 (close to the peak of the
| bipolar mainframe) with the Computer Explorers troop that met at
| New Hampshire Insurance.
|
| We used VM/CMS where VM was a virtual machine monitor and CMS was
| a single-user OS that felt a lot like CP/M or MS-DOS. (I
| understand CP/M was inspired by CMS) If you have a lot of
| developers, they all get their own OS and normally they would
| store their files on "minidisc" images.
|
| Even though the experience wouldn't seem too foreign to somebody
| who works on the command line today, the I/O was not character
| based but instead buffered the way the article describes.
| Applications were built around a model where you program fields
| on the terminal which get submitted when somebody hits the send
| button such as the XEDIT text editor
|
| https://www.ibm.com/docs/en/zvm/7.3?topic=zvm-cms-file-edito...
|
| which was functionally similar to the TECO editor you'd see on
| DEC minicomputers but quite different in implementation. (e.g.
| 1970's mainframe apps were similar to 1990's web form
| applications)
|
| Since we had Digital right across the border in Massachusetts,
| schools and children's museums in my area where saturated with
| PDP-8, PDP-11 and VAX machines. The computer club (which met at
| the physics clasroom) at my high school inherited an old PDP-8
| when the school got a VAX, it was an unusual system that they
| were planning to ship to a newspaper that didn't buy it in the
| end which had terminals that used an ordinary serial connection
| but could be programmed to behave like the 3270, we didn't have
| any software that used that feature until I got out the manuals
| and wrote a BASIC program that would send the control sequences
| for that mode.
| anyfoo wrote:
| If you want unfamiliar, try MVS on IBM s/370 mainframes.
| Version 3.8j (from the early 80s) is readily available, and
| runs great on the Hercules emulator:
| https://www.jaymoseley.com/hercules/installMVS/iMVSintroV8.h...
|
| It made me realize just how many fundamental things that I
| completely took for granted in the "modern" computing world,
| were ultimately just concepts derived from UNIX (even for OSes
| that you'd think have little relation to it at all), and how
| there were (and in some capacity still are) very, very
| different worlds out there.
| PaulHoule wrote:
| In the 1980s a clear case of this was that MS-DOS 2.0 had
| system calls for file operations that basically worked like
| Unix whereas MS-DOS 1's filesystem API looked like CP/M.
|
| It's an interesting story that IBM really struggled to
| develop an OS which was "universal" the way the "360" was
| supposed to be universal. The answer they came to was VM
| which would let you run different OSes for your batch jobs,
| interactive sessions, transaction managers, databases, etc.
| Contrast that to Unix, VAX/VMS or Windows NT where you can
| run all those things under one OS. In 1970 though, IBM had no
| idea how to do that.
|
| Note today a Z installation is very likely to have Linux in
| the mix
|
| https://www.ibm.com/z/linux
|
| so it is no problem running your POSIX app together with
| traditional mainframe apps. Also there is a Java runtime
|
| https://www.ibm.com/docs/en/zos-basic-skills?topic=zos-java
|
| so you can host your Java apps.
| anyfoo wrote:
| > In the 1980s a clear case of this was that MS-DOS 2.0 had
| system calls for file operations that basically worked like
| Unix whereas MS-DOS 1's filesystem API looked like CP/M.
|
| I honestly don't think that's a good example. On the
| contrary, I think it actually obscures what I mean, and
| would lead the casual reader to assume that things were
| actually much less different than they actually were.
|
| Both MS-DOS and CP/M still had the very clear and almost
| identical concept of a "file" in the first place. I don't
| know if CP/M (and in turn CMS) was inspired by UNIX in that
| way, or whether the "file" concept came from a different
| common ancestor, but it's worth repeating that MVS has more
| or less _nothing_ like that "file" concept.
|
| MVS had "datasets" and "partitioned datasets", which I
| often see people relating to "files" and "directories"
| through a lens colored by today's computing world. But if
| you start using it, you quickly realize that the semblance
| is actual pretty minimal. (If you use the 1980s MVS 3.8j,
| that is.)
|
| Both datasets and partitioned datasets require you to do
| things that even the simplest of filesystems (e.g. FAT12
| for MS-DOS) do on their own and completely transparently to
| the user (or even developer). And moreover,
| datasets/members are usually (not always) organized as
| "records", sometimes indexed, sometimes even indexed in a
| key-value manner. This goes so fundamentally with the
| system that it _goes down into the hardware_ , i.e. the
| disk itself understands the concept of indices, record
| lengths and even keyed records with associated values. MS-
| DOS, CP/M, and practically all modern systems, instead see
| "files" as a stream of bytes/words/octets or whatever.
|
| A lot of this has been abstracted away and "pulled" into
| the modern and familiar "file" concept the closer you get
| to z/OS, but that's what MVS back then was like.
|
| A C64 with its 1541 is closer to old school MVS than MS-DOS
| and CP/M both are, because an 1541 supports both
| "sequential" files (byte streams) and "relative" files
| (indexed record sets), and because it provides relatively
| high level interface to circumvent that altogether and work
| with the disk ("volume" in MVS parlance) more directly.
| There's even a "user defined" file type. However,
| altogether the 1541 is closer to MS-DOS and CP/M again,
| because usually (not always!) you leave the block
| allocation to the system itself. Like you _always_ do in a
| modern system and MS-DOS or CP /M, there is basically no
| sane way around it (at best you can slightly "tweak" it).
|
| That's not even touching on what "batch processing", and
| associated job control languages and reader/printer/puncher
| queues, mean in practice.
|
| It's so alien to the world of nowadays.
| sillywalk wrote:
| > This goes so fundamentally with the system that it goes
| down into the hardware, i.e. the disk itself understands
| the concept of indices, record lengths and even keyed
| records with associated values.
|
| Interesting, so the disk controller firmware understood
| records / data sets?
|
| I believe Filesystems with files that could be record-
| oriented in addition to bytestreams were also common e.g.
| VMS had RMS on Files-11; the MPE file system was record-
| oriented until it got POSIX with MPE/IX. Tandem NonStop's
| Enscribe filesystem also has different types of record-
| oriented files in addition to unstructured files.
|
| I assume it was a logical transition for businesses
| transferring from punch-cards or just plain paper
| "records" to digital ones.
| anyfoo wrote:
| > Interesting, so the disk controller firmware understood
| records / data sets?
|
| Yep. The disk was addressed by record in a fundamental
| manner: https://en.wikipedia.org/wiki/Count_key_data
|
| An offshoot of this is that the Hercules mainframe
| emulator reflects that in its disk image format, which
| unlike other common disk image formats is not just an
| opaque stream of bytes/words.
|
| > I assume it was a logical transition for businesses
| transferring from punch-cards or just plain paper
| "records" to digital ones.
|
| Yeah, that is a sensible assumption. In general, MVS's
| "not-filesystem" world looks in a lot of ways like an
| intermediary between paper records/tapes and actual
| filesystems.
| skissane wrote:
| > Yep. The disk was addressed by record in a fundamental
| manner: https://en.wikipedia.org/wiki/Count_key_data
|
| Well, mainstream hard disks (what IBM calls "FBA") are
| also addressed by record in a fundamental manner. It is
| just that the records (sectors) are fixed length-often
| hard disks support a small selection of sector sizes
| (e.g. 512, 520, 524 or 528 byte sectors for older 512
| byte sector HDDs; 4096, 4112, 4160, or 4224 byte sectors
| for the newer 4096 byte sector HDDs; the extended sector
| sizes are designed for use by RAID, or by certain obscure
| operating systems that require them, e.g. IBM AS/400
| systems)
|
| Floppies were closer to IBM mainframe hard disks than
| standard FBA hard disks are. Floppies can have tracks
| with sectors of different sizes, and even a mix of
| different sector sizes on a single track; IBM standard
| floppies (used by PCs) have two different types of
| sectors, normal and deleted (albeit almost nobody ever
| used deleted sectors); standard PC floppy controllers
| have commands to do searches of sectors (the SCAN
| commands-but little software ever used them, and by the
| 1990s some FDCs were even omitting support for them to
| reduce complexity).
|
| And although z/OS still requires CKD (actually ECKD) hard
| disks, newer software (e.g. VSAM, PDSE, HFS, zFS) largely
| doesn't use the key field (hardware keys), instead
| implementing keys in software (which turns out to be
| faster). However, the hardware keys are still required
| because they are an essential part of the on-disk
| structure of the IBM VTOC dataset filesystem.
|
| Actually, the Linux kernel contains support for the IBM
| VTOC dataset filesystem. [0] Except as far as Linux is
| concerned, it is not a filesystem, it is a partition
| table format. [1]
|
| I think part of the point of this, is if you have a mixed
| z/OS and z/Linux environment, you can store your z/Linux
| filesystems inside a VTOC filesystem. Then, if you end up
| accessing one of your z/Linux filesystem volumes from
| z/OS, people will see it contains a Linux filesystem
| dataset and leave it alone - as opposed to thinking "oh,
| this volume is corrupt, I better format it!" because z/OS
| can't read it
|
| > In general, MVS's "not-filesystem" world looks in a lot
| of ways like an intermediary between paper records/tapes
| and actual filesystems.
|
| I think the traditional MVS filesystem really is a
| filesystem. Sure, it is weird by contemporary mainstream
| standards. But by the standards of historical
| mainframe/minicomputer filesystems, less so.
|
| [0] https://github.com/torvalds/linux/blob/v6.10/arch/s39
| 0/inclu...
|
| [1] https://github.com/torvalds/linux/blob/v6.10/block/pa
| rtition...
| inkyoto wrote:
| > I don't know if CP/M (and in turn CMS) was inspired by
| UNIX in that way, or whether the "file" concept came from
| a different common ancestor, [...]
|
| CP/M drew heavily on DEC operating system designs,
| notably RSX-11M - it even had PIP as a file
| <<manipulation>> command as well as the device naming and
| management commands (e.g. ASSIGN). Perhaps something
| else. MS-DOS 1 has descended from CP/M whereas MS-DOS 2
| diverged from it and borrowed from UNIX .
|
| > [...] but it's worth repeating that MVS has more or
| less nothing like that "file" concept.
|
| Ironically, the today's blame that [nearly] everything is
| a file and a stream of bytes in UNIX is the root cause of
| all evil was the major _liberating_ innovation and a
| productivity boost that UNIX has offered to the world.
| Whenever somebody mentions that stderr should be a stream
| of typed objects or alike, I cringe and shudder as people
| do not realise how the typed things couple the typed
| object consumer with the typed object producer, a major
| bane of computing of old days.
|
| The world was a different place back then, and the idea
| of having a personal computer of any sort was either
| preposterous or a product of distant future set science
| fiction.
|
| So, the I/O on mainframes and minicomputers was heavily
| skewed towards the business oriented tasks, business
| automation and business productivity enhacements.
| Databases had not entered the world yet, either, and as
| they were still incubating in research departments of IBM
| et al, and the record oriented I/O was pretty much the
| mainstream. Conceptually, it was the overengineered
| Berkely DB so to speak baked into the kernel and the
| hardware, so it was not possible to _just_ open a file as
| it was not, well, a file. In fact, I have an opened PDF
| on my laptop titled <<IAS /RSX-11M I/O Operations
| Reference Manual>> that has 262 pages in total and has
| _45 pages_ in Chapter 2 dedicated to the description of
| how to prepare a _file control block_ alone required just
| to open a file. I will take an open(2) UNIX one-liner any
| time over that, thanks.
| anyfoo wrote:
| I think those things are largely orthogonal, though.
| Opening a file can be simple, while not everything having
| to be a file.
|
| So, having the concept of files at all (and simple to
| open ones, to boot) is of course much better than MVS
| datasets, which barely abstracted the storage hardware at
| all for you. But on the other end of this, that does not
| mean everything has to be a file, as UNIX popularized.
|
| To be clear, I am never defending MVS. We've come a long
| way from that, and that's good. I may however want to
| defend AS/400, which is far away from UNIX in the other
| direction, and so in a lot of ways the polar opposite of
| MVS. However, I haven't actually worked with it enough to
| know whether it's awesome seeming concepts actually hold
| up in real life. (Though I've at least frequently heard
| how incredibly rock solid and dependable AS/400s are.)
| rahen wrote:
| > CP/M drew heavily on DEC operating system designs,
| notably RSX-11M
|
| It mostly feels like a single-user version of TOPS-10,
| which Kildall initially used to write CP/M. OS-8 and
| RT-11 also borrow heavily from it, making it basically
| the common ancestor of anything that feels "DOS".
| myself248 wrote:
| Yet even Microsoft tried to shove something like that
| into the PC world, whether it was the OFS effort during
| Cairo development, up to WinFS that actually appeared in
| a developer's release of Longhorn.
|
| And even more recently, there've been efforts to expose a
| native key:value interface on SSDs, to let the drive
| controller handle the abstraction of the underlying flash
| cells.
|
| I'm not well-enough versed in this stuff to understand
| how similar these things are to what you're talking
| about, however. Very much appreciate any clue you feel
| like offering.
| kragen wrote:
| > _Both MS-DOS and CP /M still had the very clear and
| almost identical concept of a "file" in the first place._
|
| ms-dos files (after 2.0) were sequences of bytes; cp/m's
| were sequences of 128-byte 'records', which is why old
| text files pad out to a multiple of 128 bytes with ^z
| characters. ms-dos (after 2.0) supported using the same
| 'file' system calls to read and write bytestream devices
| like paper tape readers and the console; cp/m had special
| system calls to read and write those (though pip did have
| special-case device names). see
| https://www.seasip.info/Cpm/bdos.html
|
| that is, this
|
| > _CP /M (...) instead see[s] "files" as a stream of
| bytes/words/octets or whatever._
|
| is not correct; cp/m has no system calls for reading or
| writing bytes or words to or from a file. nor octets,
| which is french for what ms-dos and cp/m call 'bytes'
|
| admittedly filesystems with more than two types of files
| (ms-dos 2+ has two: directories and regular files) are
| _more_ different from cp /m
| anyfoo wrote:
| Granted, I wasn't aware. But unless you also have to tell
| CP/M how many cylinders and/or tracks you want to
| allocate for your ,,file" upfront, and how large the
| (single!) extent should be should that allocation be
| exceeded, as well as having to _separately_ enter your
| file into a catalogue (instead of every file on disk
| implying at least one directory entry, multiple for
| filesystems that support hard links), then CP /M and MS-
| DOS files are still very similar to each other.
|
| Also, it sounds to me like those 128 byte records were
| still very much sequential. That is, 128 bytes may have
| been the smallest unit that you can extend a file by, but
| after that it's still a consecutive stream of bytes.
| (Happy to get told that I'm wrong.) With MVS, the
| ,,files" can be fundamentally indexed by record number,
| or even by key, _and it will even be organized like that
| by the disk hardware itself_.
| kragen wrote:
| yes, exactly right, except that it's not a consecutive
| stream of bytes, it's a consecutive stream of 128-byte
| records; all access to files in cp/m is by record number,
| not byte number
| adrian_b wrote:
| While octet is used in French, it is also used in many
| other languages and it is preferred in the English
| versions of many international standards, especially in
| those about communication protocols, instead of the
| ambiguous "byte".
| kragen wrote:
| it was ambiguous in 01967
| kens wrote:
| Yes, looking at IBM stuff is like being in a parallel
| universe where everything you take for granted is slightly
| off. You have token-ring instead of Ethernet, you have SNA
| (or something) instead of TCP/IP. Characters are EBCDIC, not
| ASCII. Terminals are connected with coax, not RS-232. For
| hardware, chips are packaged in metal instead of plastic.
| Circuit boards are a weird grid. Even the terminology and
| schematic symbols are different: if it looks like an AND
| gate, it's an OR gate.
| whartung wrote:
| From the "If I could" files, I would have liked to spent 5
| years on an AS/400, trying to make it work for whatever
| company I was working for.
|
| The best way to learn this stuff is simply apply it, trying
| to solve problems.
|
| Going from a High School PET to a College CDC NOS/VM Cyber
| 730 to a RSTS/E PDP 11/70 was very education cross section
| of computing that really opened my eyes. If I had gone to
| school only a few years later, it would have been all PCs,
| all the time, and I would have missed that little
| fascinating window.
|
| But I never got to go hands on with an IBM or an AS/400,
| and I think that would have been interesting before diving
| into the Unix world.
| PaulHoule wrote:
| The OS for the AS/400 is really remarkable as a "path not
| taken" by the industry and remarkably advanced. Many of
| the OO architecture ideas that became popular with Java
| were baked into the OS
|
| https://en.wikipedia.org/wiki/IBM_AS/400
|
| and of course it started out with a virtual machine in
| the late 1970s.
| anyfoo wrote:
| Yes, AS/400 / IBM i is the other IBM OS I like to play
| with (I have an actual AS/400e at home), and in a lot of
| ways I consider it to be the polar opposite of MVS on the
| mainframe:
|
| Where MVS seems to be missing very simple abstractions
| that I took for granted, AS/400 abstracts _way more_ than
| I 'm used to, differently, and most importantly far away
| from the very, very "file-centric" view of today's
| systems that was derived from UNIX. It indeed shows you
| what computing could have been, had AS/400 been more open
| and had those ideas spread farther.
|
| Before I got to know AS/400, I thought UNIX was great,
| and that it rightfully took over computing. Now, not so
| much, and I've started to see how detrimental the
| "everything is a file" concept that UNIX brought into the
| world actually was to computing in general.
| skissane wrote:
| > Many of the OO architecture ideas that became popular
| with Java were baked into the OS
|
| I disagree. OS/400 has this weird version of "OO" in
| which (1) there is no inheritance (although the concept
| has been partially tacked on in a non-generic way by
| having a "subtype" attribute on certain object types),
| (2) the set of classes is closed and only IBM can define
| new ones.
|
| That's a long way from what "OO" normally means. Not bad
| for a system designed in the 1970s (1988's AS/400 was
| just a "version 2" of 1978's System/38, and a lot of this
| stuff was largely unchanged from its forebear.) But
| AS/400 fans have this marked tendency to make the system
| sound more advanced and cutting-edge than it actually
| was. Don't get me wrong, the use of capability-based
| addressing is still something that is at the research-
| level on mainstream architectures (see CHERI) - but the
| OO stuff is a lot less impressive than it sounds at
| first. Like someone in the 70s had a quick look at
| Smalltalk and came away with a rather incomplete
| understanding of it.
|
| > and of course it started out with a virtual machine in
| the late 1970s.
|
| If you consider UCSD Pascal, BCPL Ocode - far from a
| unique idea in the 1970s. It is just that many of those
| other ideas ended up being technological dead-ends, hence
| many people aren't aware of them. I suppose ultimately
| AS/400 is slowly turning into a dead-end too, it has just
| taken a lot longer. I wouldn't be surprised if in a few
| more years IBM sells off IBM i, just like they've done
| with VSE
| PaulHoule wrote:
| I'll say this. There is more than one side to "object
| orientation".
|
| A better comparison would be between the AS/400
| architecture and Microsoft's COM. That is, you can write
| COM components just fine in C as long as you speak
| Hungarian. This kind of system extends "objects" across
| space (distributed, across address spaces, between
| libraries and application) and time (persistence) and the
| important thing is, I think, the infrastructure to do
| that and not particular ideas such as inheritance.
|
| When I started coding Java in 1995 (before 1.0) it was
| pretty obvious that you could build frameworks that could
| that kind of extension over space and time and I did a
| lot of thinking about how you'd build a database that was
| built to support an OO language. Remember serialization
| didn't come along until Java 1.1 and than an RMI were
| still really bad and really cool ideas built on top of
| them often went nowhere, see
|
| https://en.wikipedia.org/wiki/Tuple_space#JavaSpaces
|
| there was the CORBA fiasco too. What's funny is that it
| just took years to build systems that expressed that
| potential and most of them are pretty lightweight like
| what Hazelcast used to be (distributed data structures
| like IBM's 1990s coupling facility but so easy... Not
| knocking the current Hazelcast, you can probably do what
| I used to with it but I know they've added a lot of new
| stuff to it that I've never used) Or the whole Jackson
| thing where you can turn objects to JSON without a lot of
| ceremony.
|
| The more I think about it, objects have different amounts
| of "reification". A Java object has an 8-16 byte header
| to support garbage collection, locks and all sort of
| stuff. That's an awful lot of overhead for a small object
| like a complex number type so they are doing all the work
| on value types to make a smaller kind of object. If
| objects are going to live a bigger life across space and
| time those objects could get further reification, adding
| what it takes to support that lifetime.
|
| I worked on something in Python that brought together the
| worlds of MOF, OWL and Python that was similar to the
| meta-object facility
|
| https://ai.eecs.umich.edu//people/dreeves/misc/lispdoc/mo
| p/i...
|
| where there is a concept of classes and instances that
| build on top of the base language so you can more or less
| work with meta-objects as if they were Python objects but
| with all sorts of additional affordances.
| kragen wrote:
| > _From the "If I could" files, I would have liked to
| spent 5 years on an AS/400,_
|
| pub400.com still exists and probably will for 5 more
| years. not sure to what extent you can make it work for a
| company but you can at least do learning projects on it
| axiolite wrote:
| Ethernet (OSA cards) and Fibre Channel (FICON cards) are
| standard on z Mainframes these days. TCP/IP is standard on
| z/OS, CP (z/VM), AIX and Linux. Terminal emulators connect
| over TCP/IP, not RS-232 or coax. etc.
|
| But still today:
|
| - The character set for most OSes (not Linux) is EBCDIC.
|
| - The terminal is form-based (like a web page, but with
| invisible input fields) rather than character based.
|
| - You ALWAYS have to have key punch and card reader devices
| defined (even on Linux).
|
| - z/OS needs proprietary FICON (not plain fibre channel)
| connections to emulated ECKD disks (not block based) on one
| of just a few SANs that support it.
|
| - VSE still needs a TCP/IP stack (one of two 3rd party
| vendors) purchased separately.
|
| - You need several x86 computers (HMC and two support
| elements) to manage or even boot-up a mainframe.
|
| - You have to painstakingly configure virtual to physical
| device address mappings (IOCDS) before you can boot-up
| anything.
|
| And more.
| skissane wrote:
| > - You ALWAYS have to have key punch and card reader
| devices defined (even on Linux).
|
| Linux doesn't actually support _physical_ card readers
| /punches, only paravirtualized readers/punches under z/VM
| (implemented using DIAG hypervisor call interface). [0]
| And that's because paravirtualized card devices are
| heavily used under z/VM for IPC (inter-VM communication),
| although there are alternatives (IUCV, TCP/IP). So if you
| aren't running under z/VM, Linux can't use
| readers/punches, because the hypervisor interface isn't
| there. And even under z/VM, Linux will work fine without
| them, because they are mainly used for sending data
| between Linux and other mainframe operating systems such
| as CMS and RSCS, and maybe you aren't interested in that.
| And if somehow you managed to connect a real card reader
| or punch to your mainframe (you'd need to chain together
| a bus/tag to ESCON bridge with an ESCON to FICON bridge),
| bare metal Linux would have no idea how to talk to it,
| because it doesn't support real card devices, only
| paravirtualized ones. Linux under z/VM _might_ be able to
| do so, by relying on the hypervisor's card device driver.
|
| [0] Have a look at https://github.com/torvalds/linux/blob
| /v6.10/drivers/s390/ch... - if it encounters a _real_
| card reader /punch, it is hardcoded to return
| -EOPNOTSUPP. Actually it looks like it does use CCWs to
| write to punches, but it relies on DIAG for reading from
| card readers and device discovery. And due to that code,
| even if it is generating the correct CCWs to write to a
| physical punch (I don't know), it would refuse to do so.
| skissane wrote:
| > Linux under z/VM might be able to do so, by relying on
| the hypervisor's card device driver.
|
| Actually thinking more about the code I linked, I don't
| think this would work - even if the z/VM hypervisor (CP)
| still knows how to talk to physical card devices (maybe
| the code has bitrotted, or maybe IBM has removed it as
| legacy cruft) - the DIAG interface would report it as a
| physical/real device, and hence that Linux kernel driver
| would refuse to talk to it
| dboreham wrote:
| I'd forgotten about the weird grid. Good times.
| formerly_proven wrote:
| Probably the most expensive proto-board looking thing
| around.
| nsguy wrote:
| I've used a 3090 and some of the predecessors and VM/CMS. The
| "monitor" was called CP (control program) IIRC.
|
| XEDIT was a great editor. There was also Rexx (and previously
| EXEC and EXEC/2) as the system's programming language that you
| could use to customize virtually every aspect of the editor and
| automated tasks. Rexx had integration with the editor and also
| integrated with the OS there were lots of these small
| integration points that let you do really powerful stuff.
| Applications like email were implemented on top of the basic OS
| and editor. A very unique and powerful architecture (mirrored
| to some degree in OS/2 later).
|
| The ecosystem was incredible. The virtualization support in the
| CPU let you run a complete multi-user system with each user
| having a visualized CPU within one virtual CPU. I.e. it was
| "fully" virtualized. What's more incredible is that a lot of
| these pieces, like the OS, were all written in assembly. Super
| robust. Super clean. Amazing documentation for everything. As
| top notch engineering as it gets.
|
| The full screen terminal (e.g. 327X) were part of the
| architecture, delegating a lot of the interaction to the
| terminal. Interesting enough you could poll the terminals for
| input which we've used for writing some games. A friend of mine
| wrote a library for doing that. There were also colour/graphics
| terminals like the 3279 and could be programmed e.g. with a
| library called GDDM.
|
| EDIT: - https://en.wikipedia.org/wiki/VM_(operating_system)
|
| Another interesting bit is that IBM shipped the full source
| code for everything (I think this was by default). They also
| had a shared bug reporting system (anyone remember what that
| was called?).
| PaulHoule wrote:
| Right. It was really common for sites in the 1970s to compile
| their own OS so they could set the configuration. This was
| how you told it which devices where attached on which ports.
| ngcc_hk wrote:
| "compile their own OS"??? I thought SYSGEN is necessary. At
| least in 1990s when I supported these machines as OS (and
| later DB2) supports.
|
| I suspect it is in general necessary even to these days,
| but whether they will start with MVS 3.8 and gradually
| build up to whatever machine we are onto, I am not sure.
| ngcc_hk wrote:
| I do not know you can do that as I think the 3270 block mode
| always did that. Might be CICS can do that but I wonder ... I
| only support block mode.
|
| It would be interesting whether yo can release to six pack VM
| for us to try. We use 370 C to do gaming currently, ... does
| it allow this interaction I wonder.
| travismcpeak wrote:
| This is really cool! How do you accomplish your research? I'm
| assuming IBM has some corporate records, but didn't realize
| they'd be this complete.
| kens wrote:
| We haven't been able to get old information from IBM; either
| they discarded it or don't make it available. There are lots of
| old manuals on bitsavers, which is a treasure for historical
| computer research. It is worrisome how much preservation
| depends on the efforts of a single person.
|
| https://bitsavers.org/pdf/ibm/
| anyfoo wrote:
| One of my hobbies is writing period-correct stuff for s/370
| and MVS, and, yep, bitsavers is where it's at. Weird thought
| that if that person didn't go through the effort, the
| information would be near-unobtainable.
| epc wrote:
| This might be a bit morbid but consider contacting estate
| sales agents in the Poughkeepsie and Rochester areas? The
| last generation of hard core mainframe employees are all
| nearing retirement or have retired and as they and their
| families deal with the detritus of their careers may just be
| throwing away stuff. A lot of the print books ceased mid
| 1990s, in favor of BookManager files and eventually PDFs.
| codedokode wrote:
| Talking about chips, does anyone know what was the feature size
| in classical DIP-package chips like 4000, 7400, 74LS, 74HC, 74AC
| series? I googled around, but for example this Wikipedia article
| [1] has information only on CPUs, but not on simple logic chips.
|
| [1] https://en.wikipedia.org/wiki/Transistor_count
| kens wrote:
| I looked at a random 7400-series die and I think the feature
| size is about 5 um. (The width of the thinnest metal and
| silicon features.) Bipolar chips have different construction
| from a MOS processor, so the features aren't directly
| comparable, but this should give you a rough idea.
| bregma wrote:
| I imagine a 7400 TTL quad NAND gate would have... 16
| transistors?
| codedokode wrote:
| I was curious about feature size (e.g. wire width). The
| number of transistors can actually be found in some
| datasheets (don't remember exactly which manufacturer
| published it though).
| GeorgeTirebiter wrote:
| A 2-input TTL NAND gate usually consists of 5 transistors:
|
| Two multi-emitter transistors (counted as two separate
| transistors here) One phase splitter transistor. One pull-
| down transistor. One output transistor.
|
| The multi-emitter transistors are easy to make on-chip and
| are a clever way of getting two inputs into one 'device'.
| For a 7400 that was 4 sections x 5 transistors per section
| = 20 transistors, total.
|
| NAND was the fundamental block in TTL; in the earlier RTL,
| NOR was the fundamental block - and used only 2
| transistors, but needed resistors for the inputs and as the
| load pull-up. Power hungry and slow as a result.
| kragen wrote:
| shouldn't you count the input clamping diodes as
| transistors
| kmeisthax wrote:
| Y'know, that thing about how IBM terminals are really form
| display machines instead of character streamers actually put
| something in context for me. Over a decade ago I interviewed at
| multiple companies whose business included adapting text-based
| interfaces for the Web. One was MUMPS[0], the other AS/400[1]. My
| thought was that they were writing shittons of text parsing code
| for each screen, but had I been hired and trained for the role I
| would have learned that HTML forms are poorly reimplemented IBM
| terminals and time is a flat circle.
|
| [0] "AS/400, but it's a hacked-together line of business program
| turned hospital OS written when Microsoft Access was still in di-
| a-pers."
|
| No, I don't know if MUMPS actually presents forms in terminal
| buffered I/O or not.
|
| [1] "Microsoft Access, but it's an enterprise grade server OS
| written when Windows NT was still in di-a-pers."
| axiolite wrote:
| > HTML forms are poorly reimplemented IBM terminals
|
| In HTML forms you can SEE where the input fields are. You don't
| have to "PROTECT" the HTML document from warping. You don't
| have to hit a special key when an HTML document is larger than
| your screen.
|
| And IBM manages to get credit for ALL the early computer
| technologies just because they're still around. Other block-
| oriented terminals certainly existed, and I'm glad they didn't
| catch-on...
| akira2501 wrote:
| > you can SEE where the input fields are
|
| There was always type="hidden" then they added CSS for extra
| spice.
|
| > You don't have to "PROTECT" the HTML document from warping.
|
| Input elements have 'readonly' and 'disabled' and most other
| elements can have 'contenteditable'.
|
| > You don't have to hit a special key when an HTML document
| is larger than your screen.
|
| Page Down?
| jerrysievert wrote:
| you fully missed a bullet not working with MUMPS. my favorite
| "issue" when dealing with MUMPS was failure to run in
| production because a line wrapped into a second 4k "page".
|
| that pretty much all medical records go through MUMPS scares
| the hell out of me after spending time moving broken web
| products off of MUMPS.
| gumby wrote:
| You can run GNU MUMPS, written by Harlan Stenn who now
| maintains NTP
| skissane wrote:
| I'm not exactly sure what "GNU MUMPS" is. Harlan Stenn is
| the author of PFCS MUMPS, which is a closed source package.
| Maybe it was open source under that name at one point, but
| if that's true, I think that must have been a long time
| ago.
|
| If you are looking at an open source MUMPS, the most
| popular are GT.M [0] and its fork YottaDB. [1] GT.M is
| heavily used in production by FIS Profile banking software.
| (FIS was originally Fidelity's banking software division,
| but was spun out.) Several of GT.M's core developers left
| FIS and started their own company to develop the YottaDB
| fork. Both GT.M and YottaDB are AGPL, although earlier
| versions of GT.M were GPLv3, and before that GPLv2.
|
| Another open source option is Kevin O'Kane's MUMPS
| implementation [2] (mostly GPLv2 or LGPL). O'Kane's MUMPS
| is less polished, more of a research/hobby project than
| production-grade code. But may be a more approachable code
| base if you are looking to tinker with it as opposed to
| using it to run a bank or a hospital. The Vista EHR
| (developed by US Veteran Affairs) [4] can be run on GT.M,
| although in production I believe VA mainly uses the
| proprietary InterSystems Cache. [5] As software developed
| by the US government, the core of Vista is public domain,
| although there are also a number of externally modified
| versions distributed under various open source licenses.
|
| [0] https://en.wikipedia.org/wiki/GT.M
|
| [1] https://github.com/YottaDB/YDB
|
| [2] https://www.cs.uni.edu/~okane/
|
| [3] https://www.hardhats.org/projects/New/InstallVistAOnGTM
| .html
|
| [4] https://en.wikipedia.org/wiki/VistA
|
| [5] https://en.wikipedia.org/wiki/InterSystems_Cach%C3%A9
| p_l wrote:
| Lots of MUMPS use in financial system these days.
| bitwize wrote:
| The partnership between IBM and Motorola is something I find
| intriguing. And I'm not just talking about PowerPC. In the 80s --
| long before Hercules -- IBM developed a "mainframe on a card"
| solution for use in IBM PCs. For a CPU, they commissioned
| Motorola to build a special 68000 CPU with different microcode
| that implemented a large subset of the System/370 instruction
| set. Any instructions that could not be implemented with this
| custom-schmustom architecture would trap, and be decoded and
| emulated by a regular 68000 that ran in tandem with the custom
| one. The resulting architecture was able to run mainframe
| operating systems and applications very well, providing mainframe
| developers a benchside testing solution that allowed them to run
| software still in development without tying up resources on the
| actual mainframe (which needed to have as much CPU time as
| possible committed to production workloads in order to be
| profitable to run).
|
| Still probably cost an arm and a leg, though. The cards weren't
| sold on their own, but installed inside a PC under the names
| Personal Computer XT/370 or AT/370:
|
| https://en.wikipedia.org/wiki/PC-based_IBM_mainframe-compati...
| sillywalk wrote:
| I remember reading about that, from the Chipletter in 2022[0]:
|
| "The XT/370, with a hard drive, could be purchased for as
| little as $8085. This compares with a basic PC/XT with 256K RAM
| for $4395 and adds a lot more functionality."
|
| ...
|
| "So what was the PC XT/370? Put simply, it was a PC XT (the
| original IBM PC with a hard disk drive) with three additional
| cards:
|
| PC/370-P : A card with one modified 68000, one standard 68000
| and lots of logic chips.
|
| PC/370-M : A card with 512 kilobytes of memory.
|
| PC/370 EM: Providing the ability to emulate an IBM 3270
| terminal.
|
| The XT/370 then became three machines in one:
|
| An IBM PC/XT.
|
| An IBM 3270 terminal that could be used to access a System/370
| mainframe.
|
| A machine capable of running some System/370 software."
|
| [0] https://thechipletter.substack.com/p/motorola-intel-ibm-
| make...
| segmondy wrote:
| "IBM's vintage mainframes were extremely underpowered compared to
| modern computers; a System/370 mainframe ran well under 1 million
| instructions per second, while a modern laptop executes billions
| of instructions per second. But these mainframes could support
| rooms full of users, while my 2017 laptop can barely handle one
| person"
|
| Software has gotten complex, folks were running BBS with multiple
| users 30+ years ago on 286 computers. First multi user machine I
| used was 386 BSD supporting 50-100 students at once. 486 machines
| were supporting thousand of users at once. A cheap under $500
| server can probably handle 5k hackernew users at once without
| missing a beat. Love the article, but don't blame the hardware,
| hardware has grown, software has just grown faster with so much
| waste as well.
| DaoVeles wrote:
| There are many factors that feed into the software complexity.
|
| Added abstraction for ease of development, added demands of
| some software functions that are not so immediately apparent
| and the endless needs for ever higher security on software.
|
| It is most points 1 and 3 that are the biggest issue. If we
| could code low level and didn't have to worry so much about
| folks trying to bust into various systems - the performance
| would be astounding.
| mbreese wrote:
| I think the authors point was that even though the mainframe
| was underpowered from a raw performance point of view, it
| augmented that performance with accessory units and processors.
| By offloading as much of the non-core functions (I/O) as
| possible, the machines themselves would be able to process as
| much data as possible without waiting for input.
|
| So while software has gotten more complex/bloated and hardware
| ludicrously fast, we still are waiting for input, IO, network,
| etc.
|
| I think of it as the old school mainframe engineers knew every
| trick to eke out every ounce of performance. And they used all
| of the tricks. We've sadly lost a lot of those tricks because
| our hardware is so fast, we can ignore the performance losses.
| DaoVeles wrote:
| As an aside, I have seen some folks get incredible boot times
| simply by eliminating all devices wait times or loading
| things concurrently. Looking at game consoles is a good
| example of cold booting speeds but even they are much slower
| than even a decade or two back.
| protocolture wrote:
| Uh thats sad. I processed one a similar IBM controller unit when
| I worked in recycling. I tried for 2 weeks to first figure out
| what the heck it was, and then secondly find a home for it that
| wasnt scrap.
|
| Ultimately, it was gutted and converted into a mobile
| workstation.
| Steve44 wrote:
| Slightly off topic and not sure if this is allowed but I've a
| copy of MVS JCL by Doug Lowe and rather than dump it I'd be more
| than happy to send it free of charge to anyone in the UK.
|
| It's in excellent condition other than a bit of staining on the
| outer rear cover
|
| https://www.amazon.co.uk/MVS-JCL-370-XA-JES/dp/0911625852
|
| I worked with them for a year or so at an insurance company and
| particularly liked some of the feature of the ISPF editor. You
| could hide rows then perform actions on the remaining columns,
| quirky but very handy when you needed it!
| xxmarkuski wrote:
| I'm interested in toying around with IBMs current mainframe
| offerings and found news articles from 2022 about IBM offering
| mainframs in the cloud as an experiment. I setup an IBM cloud
| account and looked around at th offered services, but could not
| find services related to mainframes. Probably need to be a
| premium customer.
| skissane wrote:
| Anyone can easily get a quote from IBM Cloud for a hosted z/OS
| mainframe development system:
|
| 1. Go to https://cloud.ibm.com/vpc-ext/provision/vs
|
| 2. Make sure you select a Geography and Data Centre which
| supports z/OS. I know North America > Dallas > Dallas 2 does.
| Whereas Europe > Frankfurt > Frankfurt 2 doesn't. I haven't
| checked the others.
|
| 3. Scroll down to the "Image" section and select "Change image"
|
| 4. In the popup, you should see two button-like tabs. The
| default is "Intel x86s architecture", the other is "IBM Z,
| LinuxOne s390x architecture". Make sure you pick the s390x. If
| you don't see s390x as an option, it is probably not supported
| in your selected DC, go back to step (2) above
|
| 5. Select your desired z/OS version. Currently they offer z/OS
| 3.1 and z/OS 2.5. Let's just go with 3.1 - select the radio
| button.
|
| 6. Click "Save" at the bottom of the "Select Image" dialog
|
| 7. Now the screen will reclaculate, and you'll get a quote.
|
| Mine is, US$1,874.76 a month before the "sustained usage
| discount". US$1,693.06 a month afterwards. That's with very
| minimal CPU/storage/memory/networking/etc, you might actually
| need to increase those numbers to get a usable environment.
|
| And, if you are happy paying IBM US$20K+ a year, I imagine IBM
| will be happy to take your money. Some IBM sales rep will
| probably even be calling you trying to upsell.
| sillywalk wrote:
| IBM does offer the Z Development and Test Environment which is
| an emulated mainframe for a normal x86 computer. It's $5,980.00
| / year. It looks like there is some sort of free trial, and
| there was a learner's edition.
|
| https://www.ibm.com/products/z-development-test-environment
| skissane wrote:
| I've heard on the grapevine that IBM 3274 uses an IBM proprietary
| microcontroller architecture known as "universal controller" (UC)
| - https://bitsavers.org/pdf/ibm/microcontroller/universal_cont...
| - but not sure how true that actually is. In the absence of
| written documentation-which probably exists somewhere... but
| nobody has scanned it and posted it online-this stuff is often
| just people relying on their decades old memories, and sometimes
| things get garbled with time. Or some people may even have been
| confused to begin with.
___________________________________________________________________
(page generated 2024-07-17 23:14 UTC)