Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Red Hat Software SuSE Hardware Linux

IBM's Newest Mainframe Is All Linux 251

dcblogs writes "IBM has released a new mainframe server that doesn't include its z/OS operating system. This Enterprise Linux Server line supports Red Hat or Suse. The system is packaged with mainframe management and virtualization tools. The minimum processor configuration uses two specialty mainframe processors designed for Linux. IBM wants to go after large multicore x86 Linux servers and believes the $212,000 entry price can do it."
This discussion has been archived. No new comments can be posted.

IBM's Newest Mainframe Is All Linux

Comments Filter:
  • Re:I guess... (Score:2, Informative)

    by lsllll ( 830002 ) on Wednesday December 09, 2009 @10:50PM (#30384396)
    This is all okay with me, as long as they don't use JCL. Ayyy I hated that shit when learning assembler on the 360, but then again they never thought JCL and didn't have any books on it, which is probably why I hated it.
  • by natehoy ( 1608657 ) on Wednesday December 09, 2009 @11:00PM (#30384466) Journal

      pSeries is the new name for the previous RS/6000 AIX boxes,
      iSeries is the new name for the previous AS/400 boxes that ran OS/400,
      and zSeries is the new name for the previous mainframe line.

    the p and i boxes now run pretty much the same hardware, and both have supported Linux for some time. The iSeries has excellent virtual machine support (called "partitioning" in iSeries parlance) and can run Linux instances natively or on an installed Intel-class processor board that shares system memory and disk (DASD).

    As to why you might want to run Linux on mainframe-class hardware, reliability and scalability come to mind.

  • by Anonymous Coward on Wednesday December 09, 2009 @11:56PM (#30384770)

    In 8 years, I have had nothing but *excellent* support from IBM. Just sayin, is all...

  • Re:Grammar (Score:5, Informative)

    by SEE ( 7681 ) on Thursday December 10, 2009 @12:49AM (#30385040) Homepage

    Never mind the grammar (I can hardly believe that I'm saying that), I thought that operating systems were designed to work with the processor(s). When did it get to be the other way around?

    Lots of apps for IBM mainframes are per-processor licensed. This caused a problem for IBM in trying to sell mainframes to run hybrid workloads; the customer would say, "But those extra processors to run Apache on Linux are costing me money in licensing fees on my mainframe apps. It's cheaper for me to buy a smaller mainframe and a bunch of PCs."

    So IBM put together a bunch of processors, hardware-identical with normal mainframe processors, but including extra microcode that limits them to running Java/XML (z Application Assist Processor) or Linux (the Integrated Facility for Linux). These units don't count as processors for purposes of licensing mainframe apps, since they can't run mainframe apps.

  • Re:I guess... (Score:3, Informative)

    by TempestRose ( 1187397 ) on Thursday December 10, 2009 @12:51AM (#30385044)
    Hmm, IBM Publication GX20-1850-7 would help a little for the 370. ( Or the latest revision.... ) There must be a similar reference for the 360, no?
  • Re:Screensaver? (Score:1, Informative)

    by Anonymous Coward on Thursday December 10, 2009 @01:04AM (#30385120)

    Saying z/OS mainframe is the same as saying Windows PC. You are describing an operating system as well as the hardware it's running on.

    The processor itself is called System z.

    z/OS is an operating system. This is the one with all the JCL and batch stuff.

    z/VM is an operating system. This is the one that does all the virtualization stuff, and while not quite the original virtual environment, z/VM started out as CP/67 in the mid 60's.

  • by TheRaven64 ( 641858 ) on Thursday December 10, 2009 @07:21AM (#30386570) Journal
    Not sure about Linux, but I had a module on C and UNIX as an undergrad. It had four lectures on the UNIX shell and process model and the rest was on C. The course wasn't really enough for anyone who didn't use *NIX on their own time to become proficient.
  • Re:Grammar (Score:3, Informative)

    by TheRaven64 ( 641858 ) on Thursday December 10, 2009 @07:27AM (#30386590) Journal

    I thought that operating systems were designed to work with the processor(s). When did it get to be the other way around?

    Around 1970. A lot of minicomputer and mainframe architectures were designed after the initial work was done on the operating system. The OS was designed, then the requirements for the system architecture were extracted from that. Operating systems like MULTICS, VM/360, and VMS had architectures designed to support them, rather than the other way around.

  • by klubar ( 591384 ) on Thursday December 10, 2009 @07:31AM (#30386602) Homepage

    I did a lot of work on 370/VM and it was really a brilliant operation system... vastly ahead of its time... it created true virtual machines, with their own virtual hardware and even console/control panel. Within each VM you could run whatever (IBM or non-IBM) operating system you wanted...including another copy of VM to create more VMs... to about 10 levels deep. The implementation was flawless... and each VM was completely isolated. Othere OS have just started to catch up... but most (all?) current OSs don't virtualize the hardware as well.

    Back in the hayday of IBM... the system were well documented and incredibly reliable.

    I grew to love JCL... alas CICS always sucked.

  • EBCDIC (Score:2, Informative)

    by aixylinux ( 1287566 ) on Thursday December 10, 2009 @09:44AM (#30387364)

    The System z hardware is no more EBCDIC than you are. z/Linux uses ASCII for messages, commands, and utilities, just as z/OS uses EBCDIC. The z/Linux choices include ports of RedHat and Suse. The port does not include translating these to EBCDIC.

    Now, the old native Unix for z/OS, Unix System Services, *was* an EBCDIC Unix. Nothing ever said Unix had to be based on ASCII. Porting programs to USS was a challenge because too many programs made assumptions about the binary value of characters. Usually the fixes were simple, but sometimes the defects were hard to find. But if an assumption was made about the collating sequence, the problem was harder.

  • Re:I guess... (Score:3, Informative)

    by baegucb ( 18706 ) on Thursday December 10, 2009 @09:48AM (#30387420)

    JCL is easy. There are only what, 6 possible statements, and variations on them. And Gary Brown's JCL book has been around since at least the mid-70s iirc. []

  • by Anonymous Coward on Thursday December 10, 2009 @10:56AM (#30388056)

    If you are comparing some work you did with it 8 years ago, then your input is quite possibly worthless. Look at any technology 8 years ago, cars from 8 years ago, appliances 8 years ago. Many things have improved in the last 8 years including Linux. 2 years ago with Linux makes a difference. I would suggest a revisit is needed.

  • VM vs LPAR (Score:4, Informative)

    by cwills ( 200262 ) on Thursday December 10, 2009 @01:21PM (#30390470)
    The evolution of VM from CP/67 to z/VM has resulted in some of the virtualization function being pushed down into the hardware.

    With the introduction of XA architecture in the late 80's, IBM moved some of the virtualization technology down into the hardware, they created a new instruction, SIE - Start Interpretive Execution that could tap into this facility. This facility ended up being the heart of both LPARs and VM/XA (which grew into current z/VM). Conceptually the SIE instruction, or the LPAR facility saves the current processor context, and starts a new context. The "guest" system (or the LPAR) now runs in this new context until some condition has been met (e.g. certain timer pops, certain state changes, etc, as defined by the meta-system (z/VM or the base system managing the LPARs). The movement of this function down into hardware was a logical extension of what used to be called hardware VM assists in pre-XA days.

    Basically the base hardware provides LPARs (in fact for quite some time IBM mainframes can only run in LPAR mode, even if one has only one system image). LPARs allow sharing of the physical processors, sharing of physical I/O devices, and partitioning of physical memory. With an LPAR you cannot exceed the physical resources available, meaning that you cannot define an LPAR image with more processors then are physically available, or give an LPAR image more memory then is physically available. This is where z/VM comes in.

    z/VM provides the ability to virtualize the physical resources. You can define a VM guest with more memory then is physically available, or more processors then are physically available. In addition z/VM can provide virtualized I/O devices, or provide more fine grained partitioning of physical devices (e.g. carving a disk volume into a collecting of smaller volumes in what is called mini-disks -- which are not the same as a disk partition).

All laws are simulations of reality. -- John C. Lilly