ฝัง
- เผยแพร่เมื่อ 15 มิ.ย. 2024
- what is a mainframe? how does it work? what does it do? what is the user interface of a mainframe?
This video shows the following:
1. what is a mainframe
2. what are they used for
3. what is the user intface today and how was it before
4. what are terminals
5. how programmers interact wit the mainframe with the example of IBM's MVS 3.8
6. What mainframes cannot be used for.
This video is about 20 minutes long.
Our community FB page is at moshixchannel
Join our Discord channel to get support, help and discuss mainframe topics:
/ discord - วิทยาศาสตร์และเทคโนโลยี
When I first started working in computing back in 1975, I was working late one night in a Honeywell data center in Atlanta. I started talking with a guy working on another system. When I mentioned being from Nashville, he said he worked on the installation of the Univac I at Life and Casualty Insurance. I laughed and told him I saw it being removed in 1972. It was so obsolete that they broke it up with sledgehammers and threw the pieces out of a second story window into dump trucks. It was vacuum tube circuitry and literally nothing was salvageable. Even the keypunch machines were non-standard, using round holes instead of rectangular. I spent my career working on small and mid-range systems, e.g. IBM Ststem/3, Honeywell Level-62, Wang VS, and IBM RS/6000. Yep, I was one of those guys who contributed to the Y2K crisis writing COBOL.
Ouch. A computer broken up with the sledgehammer. Hurts
moshix Yes, it was hard to watch, and I wasn’t even in the industry yet. I was working part-time at radio station WLAC, owned by Life & Casualty. I misspoke. The chief engineer of the radio station did salvage some huge capacitors from the computer’s power supply, but all the rest went out the window. I spent the first half of my 34 years in IT writing some of those billions of lines of COBOL you talked about. The second half was more interesting, more enjoyable, and much more productive. I wound up writing BASIC code for Pick D3 and later Unidata. Who knew you could do so much with so little. The BASIC was intermingled with a 4GL called SB+. That was on the RS/6000 hardware and its successor. But I’ve left it all behind me. I retired in 2009 and, except for a bit of web site work for a club I belong to, I haven’t written a single line of code since.
Thank you. Pick !! I always wanted to see how it works.
moshix I’ve always said that Pick and its derivatives are the best kept secret in the IT business. It’s all because Dick Pick saw himself as a programmer, not a business man. Very few Pick licenses were sold directly to end users. Most were through value-added resellers who had developed an application suite using Pick. There are thousands of small businesses out there even today that have a multi-value database like Pick at its heart, but the users sitting at terminals don’t realize it. That’s how I got exposed to it. We gave up on homegrown software and bought a package called the “Advanced Distribution System” from a reseller called Prelude Systems. But we didn’t want to be complete slaves to them, so we bought a development license for both the Pick/D3 and the SB+. That was in 1995. We went live with it after many custom modifications in mid-1996. I retired in 2009, but the least I heard they were still using it, after more than 20 years. Not a small shop, either. We were a $100 million in annual sales, with 7 locations across the U.S. and about 300 users.
The magic of Pick and its kin is the extreme flexibility and economical usage of resources. Small machines can support a lot of users. Everything in the database is variable-length and delimited with hashed access. It is very fast and much easier to use than SQL. It does require a bit of planning when estimating file sizes as the anticipated number of records becomes part of the hashing algorithm. It doesn’t hurt to over-estimate a bit, but an undersized estimate can adversely affect access speed. And best of all, the native programming language is what most folks 40 or over learned in CS101, good old BASIC...on steroids. I used to tinker with MS QuickBASIC and always longed for an ISAM file system like COBOL had. Pick BASIC answered my prayers and then some. If you ever get to spend some time on a multi-value system, I can almost guarantee you will fall in love with it.
Round holes were standard for Univac.....
Best video on Mainframe in TH-cam so far. Best of luck and share your knowledge with us by this kind of video.
Thanks !!
I'm a senior dev at a State agency, and I've been given the task of helping the State migrate off it's mainframe and it's AS/400...a job that I THORUGHLY enjoy. Obviously, mainframes aren't something one can (generally) get easy access to, so I've spent a lot of my career trying to get my keyboard into one. I'm not a COBOL dev, so the opportunities were...limited. Now though, I've been having a BLAST going through the roughly 24 million lines of code and mapping it all out. In order to help get myself a little better at ease, I've installed the Hercules emulator with TK-4 on my Linux server, and have been hammering at it for hours on end.
I honestly have NO idea what I would do without your channel. You are THE resource for those of us out there that need to dive into mainframes in a realistic way. It's a totally foreign environment for most folks nowadays, and realized I didn't even know how to do basic things like scroll to the next page in something like RPF. It's quite fun learning, and it feels like what learning programming was to me when I first started years ago.
I could ramble for hours, but at any rate, please keep the content coming! I'm soaking it all in like a sponge....
Wow. Jake, sir, thank you ! I am humbled
Mainframe is a different beast. I started in IT back in the 90's as an IBM mainframe console operator. These people simply watched the systems
to ensure that they were up an running, there were no outstanding tape mounts, performing start/stop of batch processing applications on the off
shifts for backups... etc. Back in the 90's there really was no automation for such tasks and that meant that you had a person onsite 24/7 because
if you didn't the systems WILL crash. And these machines/operating systems were surprisingly easy to crash. You had something called a
master console and it has message buffers. If you don't keep up with outstanding messages in the master console buffer - the system crashes.
So the main portion of responsibilities for a console operator was to simply watch system consoles. Imagine a monitor that just has scrolling
lines of gibberish. Every once in a while a message pops up in a different color, floats to the top as the messages scroll by and then just
sits there. That's a message that you, the console operator, has to reply to and it'll sit there until the end of time and/or what's called
an IPL (Initial Program Load which is mainframe-speak for an OS reboot) if it's not answered. Now when I say gibberish I mean it. We had a
section of our command center dedicated to manuals. And one of the sets of manuals was dedicated entirely to system console messages. I was a
console operator for around 8 years and these systems could produce a message I'd never seen before for every day of those 8 years.
Mainframes are also terrible at keeping time and every year we'd have to perform IPLs for every LPAR (Logical Partition - mainframe-speak for
each separate instance of the operating system running on a given processor. Think virtual machine.) for spring and fall time change. And since
these LPARs were dedicated to customers in different timezone you had to plan around each timezone in order to IPL the system at the right time.
It was a nightmare. Then along came something known as sysplex. Sysplex allowed LPARs to share common resources (software, hardware... etc).
this added another very interesting wrinkle to the time keeping issue in that each LPAR had to be in synch with every other LPAR in the sysplex
for system time. This was challenging in that making a manual change to the time of an LPAR in order to sync it up with the others meant that
you had to do so in micro second quantities. If you took a bigger bite without doing a system reset the system would crash and possibly bring
down the entire sysplex. Things are much easier now as automation packages have been developed that handle most of these tasks for you. That and
physical tape storage is a thing of the past now which is good because tape required it's own team to be onsite as well to handle both tape
mounts and vaulting for all mainframe tape - and there was a lot of tape involved with our environment due to its size.
You pretty much nailed it. Thanks
No. Thank you for all your great mainframe content.
I'm always happy when I can read someone's actual experience/story :D Thank you!
If the mainframe was running DB2, how many number of clients and transactions per second could it handle back then?
I started as a tape librarian on an IBM/Amdahl shop that took up an entire floor of a high-rise for the machine room
We currently run an IBM I Power 8 running AS/400. It’s a workhorse. Heavy unit more then one person is needed to rack it.
Thanks. I have been playing for years with the thought of buying an AS/400 system to learn. But I just don’t have the time.
It won't rust, won't bust, won't collect dust, and it's a base for trust!
I love how he shows the archaic 3090-200! I cut my teeth on 3090-600J/MVS-XA and MVS ESA 4.2. Currently working with z/OS 2.3.x.
There is nothing that works like a mainframe system. The tenets for this architecture are Speed/Availability/Stability/Security. To use the system no real GUI is necessary, as we have the most versatile and configurable environment for a workstation, TSO with ISPF/PDF. Customer front-ends are generally run under CICS and a database backend.
You can deliver a bale of bricks in an hour by using one Ox, or in 2 months using 50,000 chickens.
Hear hear
Nice trip down memory lane. I started working for IBM back in the 60s... first in hardware as a CE (IBM’s term for a service rep... Customer Engineer), then later moved into software, Loved those old days servicing mainframes!
When I used to work for Walmart, I had remote access to the IBM mainframe and I would log in to explore every now and then. It was surreal. I never had to program it, but every now and then my team would be “hired” to write mainframe jobs. I was never put on those projects, but I could have been at any time.
I was always a curious kid and loved to know how things worked. This channel is a god sent because you have such valuable content!! I am learning so much! Thank you for your dedication in helping curious people like myself to continue learning from experienced people like yourself!!
I was a mainframe operator at Eddie Bauer for 18 years. I actually loved it.
They ran MVS?
@@moshixmainframechannel yes we had a z90. We ran four LPARS. Testing, production, 220(testing but ran the onlines). We would IPL The online LPAR once a week. Testing lpar almost every day. We would do a complex wide Opart of all of them once a month that includes production production would be IPL only once a month since we needed it all the time the lines which controlled CICS DB2, and a few other functions would be done once a week the complex wide was Intimidating to me because everything had to come back up perfectly, but we owned our own mainframe. We did not rent one and a remote facility. It was all in the house.
I have to wonder if the supermarket I work at connects into one of these to manage inventory. We still have an old IBM computer in the stockroom from probably the 90s that's in active use running something that looks like this. Thing's an absolute dinosaur and I love it.
Can you send a photo of it? I will then tell you what it is
@@moshixmainframechannel I wish I could, but unfortunately it's inside a cabinet that's locked when no one is actually doing something on it, and I'm not in that department so I'm not usually in the room when that's happening.
When I was studying at university - it was 10 years ago or so - we used a computer from 1980s connected to specialized hardware for measuring optical properties of LCD displays. The computer loaded all software from 5.25 inch diskettes, and drew results on a plotter.
I have a video of it in operation on my YT channel - but I don't really know what computer model it was. Definitely bigger than typical PC, smaller than a mainframe.
Aah u refreshed cobol divisions in my brain again used to be a cobol programmer for mainframes thanks for the video
Me also. I was an Application Programmer for the Australian government. We had a couple of IBM mainframes. Most of the software was IBM and DB2.
@cwmapp cool stuff, ain’t it ?
As someone who works in HPC (and has installed supercomputers) it is *staggering* how many people think a mainframe and a supercomputer are the same thing.
Also I think it would be useful to make the distinction between a traditional mainframe and a modern server farm.
You’re right
@@moshixmainframechannel I watched a bunch of your videos the past few days. Very interesting. I have a bit of an IT background and am a tech enthusiast/power user but I got to admit mainframes have always been a bit of a mystery to me. Nowadays I actually do work at an airline and yes we use a piece of mainframe software called “Sabre” to do reservations. In recent years we’ve prettied it up a bit with a custom GUI windows front end to give a bit of a nicer point and click interface, but it’s just a wrapper for the basic green screen application.
how is it not except for the business/research usecase distinction?
To me the Supercomputer like the Cray is the souped up version of the Pony Car. It’s the AC Shelby of the cars. And the mainframe is the actual AC British sports car!
I used to be a programmer in a bank in France. I was a PACBASE programmer.
It took me about 6 long months to learn the job. But then it got very easy.
The reason I quit is I was bored. I was only working about 2 hours a day. I wasn’t assigned enough work by the management. If I asked for more work, it was bothering my manager. Lots of reporting too. I spent about half an hour a day listing the work I had performed.
If COBOL is disappearing, it’s not because it’s old and seemingly not user friendly. It’s because the work environment in a bank or government isn’t very efficient. The hierarchy, the red tape, and people who were offered a programmer job when their former job disappeared because of IT (and they suck at programming). All that, along with the ugly inferface makes COBOL look outdated, when in reality it’s a great language for accounting, and there will never be anything better.
I cannot disagree with you. You are 100% right.
Except that cobol failed at being what it aimed to be, that being a programming language that business people could easily write
Sure it does make accounting easier, but in many other circumstances C or C++ (and nowadays maybe even rust) will do a better job at the task at hand in a vast majority of situations. Pair that with the fact that these languages make more sense to the programmer as they weren't designed with some other group of people in mind and it becomes quite obvious why cobol has largely fallen out of style
Yep that sums it up. You can see the results of the "you are being made redundant, but don't worry, I've got a job for you in programming and its easy and just like office administration" approach to things all over the place. The hopeful thing is that it seems we've finally turned a corner in that regard. The code that was the result of all of that is now too difficult for ordinary programmers to grok, let alone accounts and office admins and the like. So we are back to ground zero where you need electrical engineers and real (not glorified administrator) systems programmers to get anything done.
COBOL is a great language for "business", which means it should stay on Windows where it belongs these days and as far away from mainframes as possible. Things were much better before IBM sold out to the COBOL folks and pushed FORTRAN people into the Unix world, but they've made a decent effort to make up for that over the years.
@@oggilein1 None of this is the actual problem. As somebody experienced in setting fire to ugly old COBOL code that should have been killed 30 years ago, the one constant is the use of global state across (large) module boundaries (some mistakenly refer to this as simply the use of GOTOs, but its more than just the use of that instruction or similar instructions, its the actual use of global state that makes it unmaintainable, and this problem can exist without ever using GOTOs). There is nothing else that even comes close to how awful that particular issue is. Its got nothing to do with the COBOL language itself, and everything to do with the incompetence of the people that programmed it (there is in fact assembler code of an even earlier origin that mostly avoids a lot of these issues, it is an issue of a particular set of people, not even "nobody knew better back then"). In most cases, they had never received even the tiniest bit of formal computer science, electrical engineering, or mathematics instruction and it shows in how they structure their programs. You could easily write a similarly demented program in C. If you hadn't already been trained not too, it would probably be the default, as it is for old COBOL programmers when told they need to write C code. Think of what would happen if you handed a clueless 8 year old child a C compiler and set them loose with some hard deadlines or else they are out on the streets. That's basically what actually happened.
The only experience I ever have had with mainframes was 3270 terminal emulation many years ago.
We used this method so blind people could access the mainframe with screen reading software.
The thing I remember most was the unprotected fields, so if you typed in the wrong place, you got the dreaded X SYSTEM message which had to be cleared.
Worked on mainframe computers near 30 years did lots of network stuff as well. The first beast I worked with filled 2/3 of a three floor building, channel cables thicker than broom handles, the huge power supply and all of the network equipment was in the basement. By the time I moved to mostly networking the mainframe had shrunk to the size of a big household fridge and the channel cables were fiber. I was always doing the show and tell with visiting dignitaries, used to take them into the computer room and turn off the lights lol I'd point out that the red light they see is the on off switch. Everyone always thought computers all had massive banks of flashing lights. We used to keep an old hard drive as a demo unit, it was so big an heavy we had to move them with small hand operated fork lifts! Lol it was only 256 mb
Great introduction to the mainframe, for the newbies!
COBOL run in any computers depending on your compiler PC, Windows, UNIX, AS400 and Mainframe it access RDMS, VSAM, Flat Files Text, It can Link other object ASM, C, etc to perform SQL, and Communication such as TCPIP etc, this is the reason why it is unstoppable. In addition it is easy to read and structured English like self documentation line of codes not spaghetti type of codes other almost unreadable. Well we have so many object oriented languages and Web development tools we can use that as a front end it added more flexibility and nice presentation of the system from end to end process.
This is a very interesting and informative video. Thank you for taking the time to make it.
You’re welcome !!
hahahaha very entertaining beginning! Wow this is what i was looking for a couple of days ago. I was looking specifically for z/OS and from a programmer's perspective.
This is very cool stuff Moshix. I also was programming mainframes in the 80s. RPG II, RPG III, COBOL, CICS. We used punchcards too.
Thank you !
Brought back a lot of memories. I started on the big iron when I began with computers back in the 1980s. Some day I will run Herc on my laptop just to reminisce.
“Never trust a computer you can lift.”
Terrific explanation, thanks
Very cool explanation. It seems you're passionate and I can feel it inspiring me (even though this isn't my thing) good for you
Thank you !
Here is a story about one local retail store here in Finland (they sell computers/phones, household machines and all kind of electronic devices). The sellers have windows computers on which they run a terminal emulation application which is (I guess) connected to a mainframe. A year ago or so, when I showed surprise at that, the seller told me: "they tried to replace it with a new system (with "real" user interface with popup windows and so on) some while ago, but it was freezing/crashing all the time, that after 1 day or so when the system did not stabilize (and thus lot of sales were lost at that day because the sellers did not get the transactions to complete, and customers left the shop pissed off), management scrapped it, and so we are back to the good old 80x25 ascii terminals." As said, I think that was a year ago. When I bought a new dish washer last week, they were still using that ancient sales program in a terminal console emulator program :)
Mainframe always works. Nice story. Thanks
I was introduced to computers in 1980, entering data to a Data General Nova3 with two 40Mb discs the size of a dishwasher. Company changes hands and we're using IBM/ System36. I had the only IBM PC running a 3270 emulator, so I could write S/36 Basic and IBM basic (from my PC's motherboard) which I could use to talk to the only non-networked printer. Lot's of fun. Mainframe experience would have been great.
A job I went for in the 90s, before I got my current one, would have involved working on applications that provide Windows based GUIs to banking software running on mainframes. Essentially, the application would provide the interface, and appear as a serial terminal to the mainframe, interpreting buttons and menu selections as commands for the terminal, and reading the terminal output, presenting it in the correct format on the screen, with (assuming the application did it's job correctly) the user having no idea they were talking to a mainframe, and not the local computer.
Yes very typical. Not serial terminals, however.
And I believe a lot of banks were still using the mainframes installed in the 60s and 70s well into the 2000s, after all if you spend millions on a computer, you want it to last as long as possible, but the old terminals required training (which was potentially expensive) and really didn't create the image of a modern, up to date, forward looking bank, so of course the banks wanted graphical user interfaces.
@@stuartcastle2814 no. That’s not true. Banks change their mainframes every 2-3 years. Money is not a problem for banks. If banks fail, they know the governments will bail them out.
I was hoping for an office space clip. Finally got one at the end.
WOW. What a trip. I had my first computer course on an RCA 301 in machine language in 1969, hands on push button octal to activate the card reader. Then onto IBM 360's with Fortran, Assembler, COBOL, PL/1(my favorite), APL, JCL, ALGOL, etc. Compiler writing, operating systems, etc; with Norm Chomsky, Donald Knuth, Allen Turing, and other heavies as my references. I could program in my dreams while asleep and while awake at times a "Window" would open up and the correct code would assemble ,and yes they worked. In short, I love High Tech, Math, AI, etc.
I know the "window" feeling ! Thanks for writing
I'm an old systems guy from the banking world, so I'd just make a couple of points. Client/Server stuff was there, just not on the mainframe, per se. By the 80's all the ATM's and the apps running in the branches were c/s. So were airline reservation systems. The key to a lot of that was the communications controllers, which is part of what I was programming. Connected to mainframes, but communicating over a network (POTS and modems) to other controllers "out there" and back to us. That was all IBM's System Network Architecture (SNA) stuff. We were distributed systems via that network, but it was s l o w... Also, some of those big metal cabinets in the computer room videos were memory units and things like drive controllers and other communication controllers. Enjoyed your video!
True. However, nowadays client/server is understood to be based on TCP/IP instead of other protocols. Otherwise you could say that a card reader in the 1960s was really a client attached to an IBM 704 server :-)
Yep. TCP/IP took over the old SNA networks. We were still dealing with Acks and Nacks, but the addressing was pretty fixed, hard-coded in the sysgens... lol
Fun Fact.
The second highest use (traffic) of the internet (ie packets traversing it) is CICS. Being very nearly as high as Web traffic.
Great trip down memory lane. Very well explained and nice to see it in action again. For me, a mainframe is synonymous with an IBM 360/370/380/390 or IBM Z Series running OS/360.. Z/OS with CICS or IMS TP (transaction processing) monitors for the online (end user stuff), JES 2/3 for the batch jobs and TSO (time sharing option) with ISPF/PDF for the programmers, operations and analysis environment. All communication via 3270 terminals (physical or emulated). All application software in Cobol (although there was Assembler and PL/I too).
As a Comp Sci grad who deliberately went towards IBM mainframes to find out how the business world used computers (at that time) I found the architecture fascinating and beautifully organised for efficient processing of, as you say, records based data processing. It's always amused me how so many people, many of whom are Comp Sci grads, do not get mainframes. The lessons have not been learnt.
You talk of 'not having a file system', I may have misheard, it is certainly different from today's OSes. The main difference was that datasets (i.e. files) were organised by their names alone - there was no hierarchical directory structure. However a dataset name could be up to 44 characters long with a number of periods to separate the substrings in meaningful ways to imply test/production, departments, applications etc. 44 characters was usually enough if you had well thought out naming conventions. Access to a dataset by name was quite different in that it used a globally accessible index called a Catalog which identified which disk volume the dataset resided on. This was critical given that the mainframe had access to acres (literally) of storage across thousands of volumes. This catalog lookup was quite slow if not cached, (tens of milliseconds I recall), but the main use of data sets was via the batch jobs where programs and utilities explicitly pointed at a relatively small number of catalogued datasets so it wasn't an issue. It was possible to have uncatalogued datasets where you needed to know which disk volume it was on too. Most batch jobs also used temporary datasets that passed information from one part of a job to the next part (job step) and for the streamed input/output (Job spool) and since these were uncatalogued there was no catalog look up delays.
Another unique organising principle of datasets is the option to have a partitioned dataset (PDS) where a single dataset is actually a one level hierarchy of members each of which has it's own short name (used to be up to 8 chars) and can be efficiently accessed via a private index within the PDS. Typically used to store readonly data that was accessible to multiple simultaneous processes, so each member in the partitioned dataset would be a source file or program executable or config information (control cards, yeah!!). Many of these PDSes would have many thousands of members and because it was shareable across the system the catalog lookup to the PDS would have very likely been cached. In fact the equivalent to the PATH in Windows was a globally accessed structure called the LinkList which was a concatenation of all the PDSes that had the executables in them to allow the system tasks to find executables and their were a lot of those. You might have 100 PDSes in a LinkList each one having thousands of executable members. To make the member access fast there was another global index that was heavily cached called a LinkList Look-aside. Needless to say the content of the LinkList members was cached too in memory areas that were accessible to all processes.
The point about these unique features is that it allowed the storage of many applications to be well organised on one machine in one OS instance and all run together which justified the high cost of the hardware and the upfront company investment in defining, policing and enforcing standards and security processes and structures.
I'll just mention one other aspect:
Mainframes were designed to be Operable i.e. can you control what's going on (operator consoles, tools for resouce utilisation, transaction throughput and latency), what's going to happen next (job and task scheduling), what's going wrong (alerts, error messages, core dumps) etc. I'm not saying that's unique, but the way it was done, its thoroughness was. For example every system level error message had a unique identifier (XXXnnnnL) telling the subsystem, error number, error level that was published in a manual that had in some cases hundreds of words explaining what each message meant with all the edge cases for additional return codes and reason codes. Thousands of documented error messages across many manuals all several inches thick. For me, this is approach is mature and appropriate for a running a large business IT function.
Thank you for that walk down memory lane. Mainframe was also my first job post-degree.
Have an IEFBR14 from me :-)
"Most batch jobs also used temporary datasets that passed information from one part of a job to the next part "
Though I code in other things now, that's a lesson I learned - especially now that storage is so cheap - if the job abends somewhere, log what it was doing and its step so that you can rerun from STEPnn when it's fixed.
I notice that non-mainframers don't do this so much.
All my manuals (in storage) were destroyed by water damage. I don't know why I kept them. It's still sad, though.
@@peterbrown6224
I rolled out a Restart system I designed in our batch suite (many jobs with many steps in each across many programs) that stored the key of the current record being processed in a DB2 table. When a program was started it would check the status in the table, and if restarting (following an abend) would read the input file(s) until it reached the restart record. IIRC (it was over 25 years ago) the output files from the failed run were appended on the restart. There was fun with JCL, dataset dispositions and GDGs with that and sometimes the Operators didn't follow our operations manual to the letter on the restart. C'est la vie.
To be fair to modern system designs, there is a lot of queue based batch processing going on (or at least the patterns are well known).
I'll take that IEFBR14, thank you, although I did sometimes use IDCAMS too. Did you know that the name comes from the assembler instruction, Branch to register 14, the return address? IOW do nothing which is the purpose of the utility (as you know). People may wonder why you would execute a program that did nothing. It was very useful in JCL to pre or post process datasets in batch jobs using dataset disposition processing to delete or allocate datasets.
@@drigans2065 To my shame, yes the origin of branch to 14 was known to me, even pre-Google, and I used it for the operations that you describe, I think. Is the storage I'm expecting around? Let's have a quick snoop before we start.
When I moved to Unix, I was horrified to see the sloppy coding and documentation. And that was just mine :-)
Perhaps one of the differences was that as a MF programmer, you'd have a review with someone from the dreaded Production Control who'd approach your job like a sysop with a really bad hangover at the end of a twelve-hour shift. It took a few of these humiliating sessions to get the hang of writing Prod code.
Now, I just say that it compiled and it's signed off.
> However a dataset name could be up to 44 characters long with a number of periods to separate the substrings in meaningful ways to imply test/production, departments, applications etc. 44 characters was usually enough if you had well thought out naming conventions
They've reinvented that now, and called it 'object' storage.
They still haven't got rid of the 'padding of of the data to make it fit' though.
How does it feels to work as Mainframe Programmer for last 25 years! Yes I started working in Mainframe - MVS 370/XA back in 1998. I happen to work in OS/360 , which mostly had Assembly Language Programs to be converted to VS COBOL II (The most recent version in those days). I can't forget the days, I got to learn the BALR, USING sequence in Assembly Language programming! The worst, yet struggling to understand the WXTRN in Assembler! It is easy at surface, but the depth is UNKWN!
This basically was an answer to my prayer. I just wanted to know because I want to have my own mainframe lab. I’m into just knowing things and when I can make it work I feel greater value for living in this stupid society with people who have more anxiety about if the printer needs ink or not.
Great video! Always wanted to know the difference between a mainframe, supercomputers and personal computers!
Keep on your fantastic work! I wrote a 3d renderer for 8bit computers in a Basic recently. I have the vague idea to combine a supercomputer with a commodore plus/4 doing 3d images. Maybe you can show the way how i can do this.
Wow. Very nice. Maybe you can make a video or a web page about it ?
@@moshixmainframechannel Yes of course. I play around with that cray emulator, but i have no idea how to communicate between a homecomputer and a supercomputer/mainframe. Here the video m.th-cam.com/video/Zo7tMpFoxLY/w-d-xo.html
Great Video... well explained and entertaining intro...
Thanks !
Yup (for the web interface)CICS is a give away to some degree as the green screens that's what we called the system often.
What @Moshix is telling is 100% used to work for EDS supporting as I studied Software Engineering, and had to support the Engineers for when Abends occurred and get the program dumps to them. As a Developer myself I was able to write software to automate the process and made alerts practically instant instead of waiting for the call from out of state to tell us that the program Abended. And as it was processing Financial Data, it of course was good stuff to make the process that much better. Screen scraping via terminal scanning, good times! But it worked and beautifully! I have no idea what it saved the company or anything, but it was fun to do! XD
And it's folks that keep good knowledge like this going and exciting that propagate the Deep Resonance of tech if you will. I have several "vintage" systems I used to know a lucky bloke who had an operable VAX in his basement! His house was a museum of computers however, but still!
For the love of tech - subscribed! ^_^
But I ain't one to gossip... .
This is great, thanks.
Wonderfull video. I started to work on a 4361 followed by a 4381 and delivering to customers with up to 6 3090s. Also in the Siemens /370 world. We used VM/370 running iccf an dosvse plus an osvs2 as cms. CICS IMS IDMS and of course printers including AFP.
I like your videos to recall.
Thanks a lot. I remember the 3090s very well. Impressive machines
@@moshixmainframechannel when i started the first time the 4361 by power on button, I was pretty impressed by the increase of the speed visible on the 3287 console, followed by the brutal increasing of noice. After ipl-ing the VMs CP, it was the feeling, to have awoken a dinosaur. Never observe the power consumption ;-)
As a simple industrial proces controller programmer I love this craftsmanship. Well done to show your knowledge to the world
Thank you for watching !
Awesome video about mainframe! If I can name one to improve, may be the BGM. It feels a bit distracting.
Wow .... I think I still have my FORTRAN text book from my first computer class. Didn't realize it was possibly considered the "first" or one of programming languages.
Yes indeed. FORTRAN was the first programming language
Very good!
i had to use that same marist university mainframe for my assembler language class
Mainframe components are closely integrated. They don't have miles of cable like in a server farm. The longer the wire, the slower the transfer of data.
Ummm no.
That 3090 shown in the video had miles of bus and tag copper cables under the floor to connect it to it's CUs (Control Units).
Mainframes are fast because they 'offload' work to dedicated control units.
The Mainframe doesn't store data, it doesn't know how to, it has a control unit to do that. It hands the data stream off to the control unit, and the control unit stores the data.
The Mainframe doesn't/didn't do communication, it has control units to do that, it hands the datastream off to a control unit (used to be FEP but now OSA) which does communication, which handles all the communication protocol and physical layer stuff. Which is part of why it can support so many comms protocols.
Yay, best intro ever :-D
Thanks !!
Great video,
BTW please tell me more about IBM Linux One, how much does it cost?
New about a million for a more basic version
My Compaq-486 that I used in my office in 1994 had 16 MB of memory. It just barely handled Windows NT.
My Radio Shack TRS-80 that I used in my office in 1982 had 8KB of memory. It just barely handled a typical BASIC app that I typed in myself.
Mainframe will never die! Long live Mainframe!
Everything that is alive must one day die
You could have shown how card decks became virtualised and that’s what we have in the programming editor. As did printer and card punch output. The other thing is that the 3270 terminal is more like a browser in that there are fields filled in locally whereas a dumb terminal again now virtualised attached to a UNIX like OS is more character based which has much higher overhead
All true!
The IBM 3270 terminal is a *block-oriented terminal* or block mode terminal, a type of computer terminal that communicates with its host in blocks of data, as opposed to a character-oriented terminal that communicates with its host one character at a time. Block-oriented terminals typically incorporate a buffer which stores one screen or more of data, and also stores data attributes, indicating not only appearance (color, brightness, blinking, etc.) but also marks the data as being enterable by the terminal operator vs. protected against entry, as allowing the entry of only numeric information vs. allowing any characters, etc. In a typical application the host sends the terminal a preformatted panel containing both static data and fields into which data may be entered. The terminal operator keys data, such as updates in a database entry, into the appropriate fields. When entry is complete (or ENTER or PF key pressed on 3270's), a block of data, usually just the data entered by the operator (modified data), is sent to the host in one transmission. Block-oriented terminals cause less system load on the host and less network traffic than character-oriented terminals. They also appear more responsive to the user, especially over slow connections, since editing within a field is done locally rather than depending on echoing from the host system.
when i will retire, i will buy a second hand mainframe and i will spend my life having fun with it.
Can you set me up with a user id on it?
And then it is the small matte of CADAM. Most car and aircraft manufacturers ran all their CAD in a Sys/360 env (AT some time)
The meaning of the word "mainframe" has evolved over the years. Now it typically just means "big".
If you look carefully at the photo of the IBM 3090 at the beginning of the video you can see the actual processor is that "X" shaped box closest to the camera. Most of the other boxes are storage devices. But if you open up the covers and look inside the 3090 you will see that the electronics is packaged in multiple "frames". So if an engineer is looking for a particular component he might be directed to find it in "frame A" or "frame "B" etc. This packaging technique was used back through s/370 and s/360 and earlier generations (and by other manufacturers too). A big s/360 processor might have a lot of these frames spread across multiple physical boxes. So the term "mainframe" began by meaning "The Main Frame" ... probably the one with most of the actual central processor logic. I/O devices were connected using secondary processors called "channels" and each channel occupied its own "frame". Then memory would be in other frames. Etc.
An analogy with a desktop PC might be to label each add-on PCI card as frame A,B,C etc then the memory might be frame D,E,F, and the main-frame would be the actual CPU chip. The motherboard would be a rats nest of cables under the floor connecting the frames together. Okay this is a dodgy analogy, but these old machines used a lot of components which had to be packaged somehow.
Hahaha scara faggio. Cockroach in Italian. Thanks for the elucidation. Good stuff
I Wonder i believe Princeton ran a Cray (running Crays version of UNIX) as a host for The researchers X Windows terminals
Ah Cray's. Supercomputers with style. I loved them. Now everyone just makes bland boxey shaped things.
The best regards... Benjamin
If possible, Can you please elaborate about What is Mainframe modernization and what is migrated to cloud ? and how it helps?
Never really found a good answer to this very good question.
Quantum computing and AI will make the rebirth of the mainframe.
Okay !
Quantum is a dead end with out vast advances in ECC....
Interesting video. I was wondering specifically about games for mainframe computers, were any more of them made after video games went commercial in the 1970s? I figured there would at least be tech demos of future games for PCs made here and there, and/or more advanced simulations for military and educational use.
20:10 Although I guess this answers my question, they moved on to super computers.
Correct
I had no idea that mainframes and supercomputers were two different machines!
Thanks for watching !
I worked on a 3090 in early 90s, and worked on a system 38 in the 80s.
Me too !
I worked at IBM and I built them.
In Montpellier?
Nice explanation however Mainframes and current client/server hosts are pretty much the same thing, it has come full circle. IBM P series "frames" host virtual servers and mimic mainframes. That initial view of the data center, that computing power can be housed in one IBM P series frame.
Thanks for clarifying
What also came full circle is containers and VMs, where mainframe has had LPARs for ages and if I recall correctly also live migrations of operating system and / or jobs across physical hardware.
Actually live migration in the mainframe world came way after we did it with Xen.
@@moshixmainframechannel ah, myth busted 😀, thanks
Innovation has been leading in the x86 world since the 90s
Curious about whether the OS in the mainframe compiles those batch jobs into native machine code or runs an interpreter to execute them like scripts?
Compiles into binary object
@@moshixmainframechannel is it possible to dump the compiled binaries? Curious about the ISA mainframes are employed.
Why not ?
@@tommymairo8964 The ISA seems to be well documented, there is even an open source emulator for IBM Mainframes (Hercules) and I think QEMU is also able to emulate at least some of it. The problem is getting software that you can run on it and figuring out what to do with them. MVS seems like a completely different beast than anything I've used so far. Trying to run old Unix versions (like v6 or v7) is hard enough even for long time Linux users (if you're brave enough, get SIMH and give it a try) and even VMS on VAX probably isn't alien enough compared to MVS.
Man, I understand why they limited the color monitors based on the cost, but to limit them by seniority is stupid. When I was working at Andersen Insulting in the early 90's, the came out with a primitive form of email, but it was restricted to team leaders and up. So short sighted.
Hahaha Anderson Insulting. 😃
Elegant: English-like language as opposed to mathematical-like language.
Thanks !
Today all that equipment has been reduced to 3-4 refrigerator sized cabinets
Yes. Or less
You mean one micro sd card
@@TRguy58 That will be next.
Fun with Fortran:
Write a Fortran program that passes a literal number (for example 5) to a Fortran sub-program as a paremeter.
Write a Fortran sub-program that changes that parameter to a different number (for example, 8).
Have the calling program print the literal 5 after the call.
You're welcome :-p
Fun
terminal emulators (of various limitations) where around since at least the mid-ish 80s. connection options where seriously limited, usually due to cost, until the later 90s (and I can't remember what got you into SNA from a PC anymore). I still miss setting up Rumba macros :)
True. I didn’t say they weren’t.
i worked in a bank in 1998/2000.
the internal employees had a pc with rumba. external consultant like me had an old wyse amber-screen terminal 😊
Guys, do you recommend work with mainframe in this days?
Yes
There is still a demand for COBOL programmers - to work on the legacy programs, often 40+ years old (the programs, not the programmers (those are routinely 60+)). And oh, they make loads of money, since mainframe programmers are pretty scarce.
True
Do any other companies besides IBM currently make mainframes? Everything I see about mainframes is associated with IBM. Seems like they own the market.
Fujitsu and Siemens
@@moshixmainframechannel and Unisys?
@@moshixmainframechannel Do we have more about Siemens ? screenshots ? workings ? just curious
HP Superdome
@@Johan-ez5wo Siemens Nixdorf was bought by Fujitsu. Their mainframe product family is named BS2000 and is mostly deployed in European (particularly German) companies.
www.fujitsu.com/fts/products/computing/servers/mainframe/bs2000/
You could probably buy a mainframe from, oh, thirty years ago for the price of a motorcycle. But when you want to run that mainframe, your electrical bill is going to bankrupt you. On day one.
Ok. I will follow your advice
Can one use SQL on a COBOL program running on a mainframe?
Yes
SEQUEL (SQL) were designed for The mainframe. ORACLE, INGRES and Sybase came a fair bit later.
IBM invented RDBMS "SQL" (Microsoft's SQL is just a name). DB2 (original DB/2 I think) is mostly what is used now. I've never use IMS or other IBM databases. Oracle, SAP and other Databases also are very popular -there is a DB2 wikipedia page: en.wikipedia.org/wiki/IBM_Db2_Family
Yes, there is embedded SQL in a COBOL program. I have converted COBOL programs to Oracle PL/SQL packages.
Databases are one of mainframe's most common uses. "You can write Db2 programs in assembler language, C, C++, COBOL, Fortran, PL/I, or REXX. These programs can access a local or remote Db2 subsystem and can execute static or dynamic SQL statements." - Db2 for z/OS. And yes, I'm pretty sure you can even use SQL in Java as well. If you couldn't, the mainframe's use would be somewhat more limited, wouldn't it? Since so much (organized) data lives in databases.
What do you know about a 9672 server? Or a 2084? How much is one and do you want to buy one?
I have a 2084 already thanks
@@moshixmainframechannel how much is one worth?
you make mainframes sound sexy . . .
They are !
They are, honestly. They get the jobs done. You need a group of system specialist to have them tuned, but I think that you get a lot of work done rather easily. I miss working on big iron. Let me see - we had 16 MB and around 25 GB of DASD storage (we ran hospital data for most of Denmark and payment for practitioners) with thousands of simultaneous users. We programmed in PL/1 (much preferred to COBOL) on an IMS dtabase. Then we shifted to Natural and Adabas - that was not an improvement. We could make very nice user interfaces but it resembled programmning a Commodore 64 (we had only 32 KB and all global variables).
I studied Cobol in the 70's on a Wang and decided to stick to hardware instead software 🙃
Hardware is very cool stuff
I love using CRT-3270 emulators to interface with mainframes 🤓
feels like I'm in the matrix
Yes it’s fun to use 3270
Are there any other companies who are known for manufacturing mainframes? It seems like a market that was dominated by IBM.
Unisys only sells their mainframes OS on emulators these days. Honeywell also. Fujitsu still sells real hardware but its ibm compatible
When I learned that the IBM had ported Linux OS to to their mainframes,
I was sure that a mainframe is no difference from a micro as far as programming is concerned.
Processing speed is what makes all the difference.
I think the biggest difference is reliability, not speed. From what I've read, supposedly mainframe does a lot of error checking in hardware (or in the microcode? I don't know), so you don't have to do as much of it in software.
For example: what if a stray cosmic ray messes up your data in the middle of a computation and you get a wrong result? You either write your software in a way that you let's you check if there was some corruption in the middle of a transaction or have the hardware do it in parallel on more than one execution unit, compare results and try again or move to a different piece of hardware if a discrepancy is found. (This is what I gathered from stuff I read about a long time ago, it may be outdated or completely wrong.)
I think this is still a big deal for hardware designed to run in space, like satellites, probes, space stations, rockets and so on. But on desktops it's still hard to even get simple ECC memory to this day (thanks, Intel).
@@gcolombelli yes, spacecraft by default use ECC memory.
Maybe some lowest end satellites built for educational purposes don't, and use common microcontrollers instead. But because cost of a microcontroller with ECC memory starts from tens of dollars (produced mainly for automotive market), they're commonly used even in the least expensive satellites.
one day when all the colbol programmers die out, we'll be looking at this video to figure out how to maintain the global financial system
Hahahaha yes
I cut my teeth on VM370, Assembler 360 and, COBOL. I think the global financial system may die before us. 😂
Intro music is from Purple Motion - Satellite One: th-cam.com/video/_3B2kAxdV9Y/w-d-xo.html
True
It took me 10+ years to get to know why the "Terminal Emulator" in Linux is called Terminal Emulator... 😀
Other: It's interesting to see that many concepts and terms originated earlier than the "DOS" era. This video is very valuable to see the computing world before the "hippie" computers appeared and a bit more understandable why they thought they needed to defeat IBM.
Linux has a package called terminfo that adds support for hundreds of different terminal protocols through the tput command
Modern distros don't install it by default
A lot of mainframes used IBM 3270 terminal on a block mode while minicomputers and early micros used character mode terminal like the ADM3s, HZ1500, VT100 and VT220
As long as they don’t dump the entire mainframe onto our backs.
Haha
I always confused mainframes as being synonymous with servers.
You’re not wrong
a mainframe is basically a server with extremely wide throughput i guess. @@moshixmainframechannel
@@10siWhiz basically, often virtualising other operating systems like Linux and windows as well
There is so lower case on mainframes!!!
(Though most programmers find it a pain to use and so set CAPS ON in their ISPF profiles, otherwise they accidentally type lower case in JCL and Bad Things will happen)
Ok.
@@moshixmainframechannel Yep, just look up EBCDIC, the character set used by IBM.
@Hungry Guy. Your problems with caps lies with OS and ISPF. If you use VM, you need neither JCL nor ISPF. I used VM from 1980 to 2012 and it was not a problem for me.
This is so frigging long ago, but my first experience programming on the Sperry Univac 1143 with the EXEC 8 OS, program source code was written in upper case. I don't think it was because key punch machines were still used then but the facility was not ready to expand mass storage for use the ANSI standard character set. Mass storage was very expensive back then and large files were often written to tape.
Nice
Hello, good video, it reminded me of the 80-90s that I was working with Mainframe with silly terminals with green letters, but with a lot of productivity, we had more than 200 users and those terminals spread throughout the city. I assure the skeptics that no current PC can process millions of transactions per minute. The truth is that IBM made one of the best computers for those times and even today, this type of architecture was born forever.
I would like to work in that environment again, as I am a COBOL developer and I have known that many companies are looking for a specialist in this language, but I cannot find any reference,
Could you recommend me some. Thank you.
Banks still have a lot of mainframe
I wonder how people even begin programming on mainframes nowadays. The hardware and software seem so completely alien and access to development tools/environment probably isn't as simple as any other mainstream language.
most of government still uses mainframes heavily, as much of the code was written way back in the day. most of the modern interface is through middleware applications.
Probably true
more in the line of ... Erich Bloch, Fred Brooks, Jr. Bob Evans and to some extent .. Geene Amdahl, .... but as we all know we all stand on the shoulders of giants.. and of course all the little ants .. who's names will never appear in a patent
Where I worked, we started to make that change in the early 90s, around the time of the 486s which made it faster to process data on desktops rather than through SQL on DB/2 (this is for data analytics).
The middleware at the time was extremely cumbersome, and PC software was still primitive.
That was a challenging time. You had the data, you could not transfer backwards and forwards elegantly.
Not just government. I know of more than one private company whos actual code is running on mainframe, with pretty graphical in the middle front ends for the user interface. I can quite literally provide you a link to a big car company where you can configure the car to your personal specification, which will then be passed back into the decades old mainframe application for processing. The big banks do the same, pretty modern graphical interface (on phones now too), feeding from/to a mainframe backend application.
Can you please explain me the kinds of terminal???
Any 3270 emulator
No sir i am trying to say that how many type of terminal are there not that one
@@nomanbaluchi2576 there are about 6 basic rules and dozens do variations of those
Thank you sir
Noman, In the earliest days after card-based systems, people connected up a variety of typewriter-like terminals, and even audio response machines to give spoken responses to the user of the typewriter. Visual Display Units were very expensive to start with, and anyone who got one was the envy of colleagues. Also, in many countries the speed of lines was unimaginably slow by modern standards: to fill the sort of display screen you can see at the airport took best part of ten seconds to transmit from the mainframe to the device, and no other traffic could go up or down that wire till the whole message had been sent. The first and seismic cutover, from batch-dominated systems to online-dominated systems, was limited as much by cost of VDUs and TP lines as anything else. It also changed the nature of the mainframe internally. Now, instead of running batched jobs in a predictable schedule, users in different departments were wanting "their" applications to be available all the time, and there was a long period from the early 70's where the most limiting factor was the amount of memory needed to handle this. Once the VDU prices came down with mass production, the use of the other types of device quickly disappeared. The concurrency requirement also led to the development of software to make it easier to handle multiple concurrent applications accessing the same data with integrity, and to provide standard ways to apply security checks. The second seismic change was from directly attached terminals to Internet access. In some ways, the mainframe went on as before, with a layer of code on the PC effectively offering an immediately interactive conversation, the results of which could be sent to the mainframe to be mapped onto the inputs expected by the programs written for the VDU's datastreams. To enable the continued use of existing programs with no change, emulator code was written to run on the PC. which you could use in a window to run traditional business applications while you did other things in other windows. Moshix showed a number of examples of this usage in the video. Obviously, security became even more tricky, as now in theory anyone with any PC could access the system. Also the capacity management techniques used to ensure that a new application didn't saturate the system largely ceased to work - you could hardly do a phased implementation, adding a few members of the public at a time. This is still very evident when you see reports of a website crashing - the first time the UK Inland Revenue allowed us to file our tax returns online, they were naive enough to think that people would do it in plenty of time. In practice, so many people tried to do it on the last day that the system was totally overrun. Even a mainframe is a finite resource.
Is there any career or future in this field: Mainframes?
I think so
Yes. Whilst the numbers of us have dwindled over time, the number of mainframes hasn't. Despite predictions from lots of people who all thought they knew how to compute better. Mainframes are alive and well.
I think the closest feel for an average user to a ceasing mainframe are USSD codes
Ok
@6:00 IBM 7094
@10:00 3279 CRT display
I wrote a prime number sieve program in FORTRAN in about 1969 and generated about 64,000 IIRC. Limited in size due to using an in memory array. Run on the IBM S/360 model 44 seen in my icon/avatar. 256K bytes of RAM.
It seems like all the commenters here are a!ready familiar with mainframes......just sayin' :-)
Just a point on the memory: the note on the 16mg 1 cpu and what could be done with the number of concurrent connected users, etc. is one of the reasons Technomancers such as myself are so disappointed at the wasted potential of what the PC has failed to yield from its opulent glut of assets. For example my fully armed and operational battle station, boasts 16 physical cores 32 hyper, and 128GB of ram, and several terabytes of SSD (that's no moving parts) "disk"\\memory storage. If it utilized it at anywhere near the efficiency of the mainframe with the peripheral cards and such handling anything aux. that the CPU might normally have needed to handle sort of like a co-processor (Amiga style) then think of the powers of the Mainframe and the Supercomputer in the package of the home computer (thus the child of the mini\\micro-computer) ie the computers of now. We practically have it But, the OS and to be fair the architectural flows are not setup for the the Mainframe element, though the super computer is kind of there by old world standards. New world standards based on the GPU and CUDA cores, no, but make that adjustment in the cpu motherboard design and integrate the compute cores in accordingly, and you have the the new Supermainframe which could even be an all-in-one PC depending on how stripped down you make it for cost. This has possibly been thought of and I'm late to the party, if so, please ignore, but I've not seen\\heard of it specifically - but to be fair I wasn't paying close attention either. -_^ However, if they sold that as a general PC I would own one!
But, I ain't one to gossip... .
Gees I hope your code is easier to read and understand than your comments ;)
@@xavytex Nope, it's even worse - self modifying.
But you ain't hear that from me!
wooooooooooooooowwwwwwwww fantastic
What’s the difference of a mainframe, server, and a mainframe server?
Power consumption
CATIA too
The word mainframe was used 86 times in this video.
Ok
Did you include the Title in that count?
Thanks for the video. I could do without the angels singing in the background :)
Who would you want to sing instead ?
@@moshixmainframechannel nobody
How do I learn mainframe ?any school ?
Yes. The moshix mainframe channel on TH-cam school
Udemy and IBM have courses.
Technically speaking, what is the actual difference between a data center or cluster and a mainframe? The cpu processing power, the I/O hardware, performance? What actually is it that makes mainframe a mainframe?
You highlighted the major differences between the mainframe OS and an ordinary OS, so how does a mainframe with Linux compare to a Linux server or even workstation? You get all the "modern" tools, like filesystems, grep, C, C++, maybe even python, right?
Any particular example, imaginary or not of the kind of workload that a Linux mainframe can do but a powerful "normal", server with dozens of cores and hundreds of GB memory, does not?
edit:whitespace
The mainframe is one computer and one operating system instance. If you put hundreds of servers into a data center then you have hundreds of OS instances to manage. the biggest x86 server will have maybe 3 terabytes of RAM. An average modern mainframe has hundreds of TB of RAM and many hundreds of processors. They are just different things
Mainframes are all about throughput. They can do massive I/O for fast transaction processing. They are not about CPU power like super computers are. And mainframes are also about reliability. They have an extremely high resilience against HW failure by redundancy.
@@moshixmainframechannel What if all of the servers are virtualized?
Then I guess they are virtual ...
@@justinmirfield8997 They're still lots of different servers.
Drink every time he says mainframe
Hahahaha
how can we able to learn this
Watch this channel