Skip to content.

TalkBMC

Sections
You are here: Home » Blogs » Ron Michael » Open for Mainframe

Open for Mainframe Open for Mainframe

Document Actions
Open development technology discussions for mainframe and distributed systems.
Never thought about it until recently.

 Today is Earth day in the U.S. and for once, I'm celebrating it by wearing an Earth day logo t-shirt my daughter bought. I've never thought about it before. Yes, I have thought about recycling, but I find no convenient means to do so. The local trash company just picks up the dumpster and from what I've gathered dumps it in a landfill. I find a certain concern about the amount of plastic bottles that go into such fills, but have never bothered to worry about it before. My friend recently said wouldn't it be great if companies took back the products they sell and faciliate the recycling for their customers.  While on the way into work today, I'm reminded of how I don't like the traffic jam on the I-10 Freeway and all the cars idling while inching forward. I find myself daydreaming of electric cars without emitting CO2 and other pollutants. I've got an electrical background and know that computers can control cars and make more efficient use of transportation to help avoid gridlock. Recently, my co-worker showed me about an idea called http://www.taxi2000.com after I had discussed my ideas over lunch and about the need to get more electric from solar and wind energy. I even joked during that luncheon that a large parcel company is more efficient at transporting parcels than we are by individually maintaining gasoline cars and driving them. Yes, I'm sure these ideas of mine are not shared by others. Yet, I'm encouraged at the number of corporations and people who are deciding not to wait for the future, but to bring the technology, the innovations, and the profit of it here today. It seems a great way to kick-start the economy by investing in its infrastructure. As I walked into the lobby this morning, the property management company handed me a recycle bag that had Earth Day 2008 on it. So forgive me for penning this blog of my personal opinions, but what a great way for companies to be good corporate citizens and to help remind us, we can all do our part however small.  



_____
tags:
Tuesday, April 22, 2008  |  Permalink |  Comments (0)
Consolidation is a great way to also move toward better application reliability.
Of course, everyone knows that cost savings is the driving force in Green IT initiatives.  

Most managers are aware of acquiring technology that is designed to be more robust and reliable as part of their IT strategy.  In that analysis, we depend on many factors in making our decision. We might even look on the manufacturer's Mean Time To Failure (MTTF) specifications along with our experience with that vendor's products before choosing products.  

     Here are two studies on hard drive failures presented in the Proceedings of the 5th USENIX Conference on File and Storage Technologies(FAST'07) that might change your commonly held beliefs: 

http://www.cs.cmu.edu/~bianca/fast07.pdf 

http://research.google.com/archive/disk_failures.pdf   

      The google study of a large disk population showed a lack of correlation of failure rates related to higher utilization of ATA drives or operating temperatures. The Carnegie Mellon Study showed that failures were much higher than MTTF alone would suggest. Additionally, that SCSI, Fiber, ATA had similar rates of failure.  

      Historically, failures have been excepted as the normal operation in IT. Therefore, contingency plans have been formally to informally use to repair/replace equipment and plan for DR events. Redundancy in storage like RAID technology is now a given requirement in most shops. This accepted technology contrasts to when disk failures plagued IT on all platforms and usually meant an inadvertent downtime to applications. However, some may not realize that higher number of servers can actually lower your up-time and reliability than improve it. Here is what I mean by that.  When applications are spread out over many servers, there is a greater chance for a failure to bring down that application. Many years ago, there was a push to get anapplication away from central computing to a distributed environment, perhaps for better control of the IT service requests and to simplify the change management approvals to upgrade their own system. This artificial fencing of applications by residing on separate servers and now even more servers intertwined to support larger applications actually began to create unintentional consequences.    

      What became apparent was the need to have physical computing resources abstracted away from the application. The mainframe years ago with virtualizations and continuing to evolve it's own reliability through redundancies and managing hardware components lead the way on processor designs. Having the system able to manage its failures is critical to large applications or even a large number of them in a consolidation project. Yes, it was true that distributed environment lead the way on RAID technology, and together, you can have a more monolithic computing environment where you can have the best of both worlds. In such large consolidations that include the mainframe you can have failures that wont bring down the application. Yet, it would be naive to just look at hardware cost in the TCO without considering the cost to maintain the equipment and the personnel required to maintain it. It is very obvious that 3000 servers requires more work and personnel cost associated to them than 100 larger ones or just moving to a few mainframes. Also, the cost of failure should be included in as well. So, green technology is about lower all associated costs and keeping a better up-time along the way. Today for Linux and z/OS, you can have z/Series processors all the way up to an IBM z10 Model E64 maximum configured where IBM compares its performance to 1500 x86 servers. For Unix, Sun Sparc M9000 is sold as more mainframe like with its RAS. These are but a few examples.   

     It is becoming clear for many a datacenter that the right mix of platforms where consolidation will lead to enhanced manageability and reliability is what going green is about. Yes, it's the environmental thing, but it is also a green you can save in your wallet. 



_____
tags:
Thursday, April 10, 2008  |  Permalink |  Comments (0)
The battle of Titans continues....

It's interesting to watch the clash of Unix and Mainframers. Lots of press on IBM's new z10 mainframe with up to 64 central processors and 1.5TB of memory. However, the Unix camp responds with chants of Sun Sparc M9000 with 64 dual processors and 2TB of memory.

What I find interesting is that IBM claims their z10 is like 1500 x86 servers and Sun claims their M9000 is mainframe like in RAS (reliability, availability, and serviceability). Similar to the mythological battle with Cronus, the two different camps of administrators and managers who, like the Titans, divide on their familiar boundaries and claim that one is too expensive and its days are past and the other's claim that they are not as mature yet.

Personally, I'm glad I'm in the middle with this blog. I agree with both camps perspectives. Yes, mainframes have been traditionally expensive and reliable. The R&D that went into them and their years of maturity in processor evolution shows. And Yes, the other Vendors have not been idle either and they make just that point when they compare themselves to a mainframe as they develop their platforms on other chipsets.

Yet, the full story is not just the processor, but the technology and marriage of the OS to its platform.  I will not pit open source Solaris 10 against z/OS even though you could do that and make a good case of each to their respective platforms. What I like about open source OSes like Unix and Linux is the amount of effort and wide range of system products being offered to this growing platform. And what I like about z/OS beyond its reliability and security features is the new efforts to incorporate and expand its limitations with respect to storage and the applications areas where Unix and Linux have done well in.

As I mentioned before, I will not join the Titans to claim who is the best for I don't want to be banished to Tartarus. Instead, I'm glad to see that Cronus can accept open source and promote green, and I applaud Zeus for accepting some of his father's advice (In my humble opinion). Now if only the rest of the Titan-admins could get along. 



_____
tags:
Wednesday, March 26, 2008  |  Permalink |  Comments (0)
This is a chance for the distributed folks to see what a mainframe operating system like z/OS is like.

The history of this OS dates back to through names like OS/390, MVS ESA, MVS XA,  and continuing back toward MVT etc: http://en.wikipedia.org/wiki/OS/360  The important features we will be looking at today is describing the batch processing side of this OS as we continue to process this web request to restore a user's dataset.

First the term dataset refers to a collection of data but is similar to files on the distributed side and can have more complex internal structure. A single sequential file is common on both platforms. However, z/OS supports partitioned files with a directory of files within the same file. Each file is called a member of the partitioned dataset. For our purpose, we will only be dealing with sequential written files since this is what the FTP created.

Catalogs are an important feature of z/OS and their purpose is locating datasets. In the distributed systems, many OSes use pathing to locate a file on disk. Typically, you need to know which disk and what path.  In z/OS, datasets generally reside on DASD (disk) volumes or tape. The catalog basically contains the dataset name, the device type,  the volume serial number, and some system management class indicators.

The device type or commonly called unit type can have the more esoteric names like disk or tape or more device model specific names like 3390-3. Volume serial name or commonly called volser is the device's name when mounted on the system. The nice thing about a catalog is that you can find the dataset by just knowing it's name. Therefore, these need to be unique names. Other datasets named the same will not be cataloged in this specific catalog. It is possible to catalog them in other catalogs and refer to these catalogs, but this practice is not as common. z/OS allows the dataset name to be a string of 44 characters. Typical naming convention is a maximum of 8 characters separated by periods that form levels. The first set of characters is a level typically called the high level qualifier (HLQ) and can be the name of a userid or a system name for example. The common structure of catalogs are such that the master catalog will contain entries for the system datasets and have alias entries for the HLQ that point to other user catalogs that contain the entries of the user datasets.

The FTP from the web application created on a DASD volume the sequential dataset which contains the character Y, a blank space and the dataset name to be restored for the user. This cataloged dataset name is userid.mvs.request, where userid is the login id the user supplied with a password. This dataset name created by FTP is comprised of the chars "mvs.request" as supplied by the variable in submitter.php and the default current remote directory in the FTP session. If we included the function call ftp_chdir($conn,"sys3") in the submitter.php we could have created a "sys3.mvs.request" dataset instead, and provided this user had the security rights to do so.  A centralized process might want the web app to include a timestamp in the name of the dataset and place them all under a specific level (remote directory) so that it may use this as a processing queue. In our educational example, we will poll for updates to our user's specific named dataset.   

Centralized processes can be an auto operator (program instead of a human submitting requests to do some command or start a batch job) or use a  homegrown routine that periodically runs batch processing. Batch processing is accomplished by submitting a job to be run in the background (asynchronously from the actions of a user in a foreground process). This is facilitated by an address space (task) and tasks (threads) called JES2 (Job Entry Subsystem). This process allows jobs ( a series of programs to run in a batch or command like process) to be queued and run by initiators (scheduling units). The jobs will process their datasets and if any printout (print) is required, it will be spooled (saved on disk) for later scheduling to available requested printers. Users may submit request to JES2 from their foreground session like TSO (Time sharing option with typically text menu panels ISPF) or it can come from a terminal session in an online environment for databases and transaction processing. These jobs need to be formatted in a language that the JES system understands and is called JCL (job control language).

Here is a look at the required JCL to restore this dataset:

//jobname job

//step1 exec pgm=restore

//input dd dsn=userid.mvs.restore,disp=shr

It has one job step and is to execute the program called restore. This program will read the input file named userid.mvs.restore which contains the user's requested dataset name, retrieve the appropriate backup information, and begin the restore.

The job is comprised of the job statement, the exec statement, and any optional dd (data definition) statements. In the dd statement the parameter disp=shr refers to the dataset disposition is share. It can have shared access and kept (not deleted) afterwards.

We could show a real world example of how to use IBM's DFSMShsm or dss products. However, I did not want to include any vendor specific programs and their methods of backup and restore with their JCL requirements just to keep this simple. For this exercise, lets say the system programmer wrote a program that will read the input file and look up its internal kept catalog of backups and retrieve the correct one for the restore. It will do this by dynamically allocating any units of tape or DASD volumes it needs to retrieve the backup. So therefore no dd statement is needed to pre-allocate these devices.

Just like in distributed systems that use AT command in Windows or CHRON is UNIX, JES has automatic command functions (timer functions) that can be used to issue a command that will poll for the user request.  You can use an auto-operator program to work similarly or you could have the web application notify the mainframe programs that an event (request) has occurred. In our case the dataset is just re-written by the web application and it is up to a polling program on z/OS that the system programmer wrote to see that a Y was specified as a new request and then submit the JES2 job above for processing the request.

As you can see there are many ways you can implement a restore task process along with the specific control information that would be needed to fully integrate the web application and the processing requirements on the mainframe. Of course as I indicated before, this exercise was an attempt to help bridge the gaps between these two platforms by showing an example of a two platform application. Perhaps you can think of a much better web application need.

 Once upon a time, system programmers like me actually did write features for their OS. Today many will find that these features are part of products ready to install and implement. What I like about open source is the same reason why we liked "home growing" features we needed. Yes, the two platforms are different. However, the needs are the same by IT facilitating their user community and both teams' love to get their hands on the mechanics of IT.

I hope I kept this short as an introduction as I tried not to bog you down with too many acronyms etc. Keep in touch....



_____
tags:
Friday, March 07, 2008  |  Permalink |  Comments (0)
An introduction to a short web application for mainframers.

Okay, it's rodeo time here in Houston, Texas, or perhaps it's because my child likes Spider-girl, and I'm too old to enjoy comic heroes. So forgive me on the title of this article as Web Spiders crawl the web to add content for their search directories, and they just might find a mainframe hosting a web page these days. Here at BMC, we use a Linux on the mainframe to provide support to our R&D users by hosting a intranet web based portal that they can use to manage their own z/Linuxes.

Below is an example of how open source can be implemented on a mainframe by showing an example of a Linux  webserver setup that might create an intranet web portal interface for MVS users to submit requests for dataset restore. Of course, this will be kept brief for demonstration purposes. Keep in mind that more coding could be needed for security and other installation needs. In future posts, I can show how to handle that. Finally, I also ask for leeway in showing an example of how you might write an application bearing in mind that most people would not do it this way. So lets use this example for education value only.

On z/OS (MVS) you could use Unix System Services, the base IBM http server, and Websphere application server's J2EE to help create your portal. However, I will introduce you to open source products like Apache and PHP. This will enable you to engage the distributed people on technology that they are familiar with as well. Apache is an excellent open source webserver and is available as an installable package on the s390(31bit) and s390x(64bit) Linux distros. Of these Linuxes, a free downloadable distro is CentOS Linux, a version similar to Redhat, or you can use the commerical products like Redhat Enterprise or Novell SuSE SLES Linux for example.

If you are using a new z series Linux install, make sure that enough disk space is available. Typical installs are about 3GB,so a DASD 3390-mod6 with 6677 cylinders is recommended to provide enough free space for the Linux. If you are new to installing z/Linux, you can use Redhat's or SuSE's installation manuals for S390 Z series. I will also show an example of a z/Linux install in a future post. Now is a great time to get a few Linux friends involved.

During the install of the z/Linux, you can specify the configuration as a webserver or you can specifically request that all the related packages are installed.  It is recommended that you also install the PHP packages and use this scripting language to write the web application. Specifically, you will need the php5 and php5-ftp package for this example to work. Once the Linux is installed and is brought back up, an Apache webserver is easy to setup in Linux. The default html web directory in SuSE SLES is /srv/www/htdocs unless you change this in the /etc/apache2 directory. If you write code then you might want to output (tail command) the /var/log/apache2/*error_log files if your application is having problems.

To activate the webserver issue these commands (SuSE SLES):

chkconfig apache2 on
service apache2 start

We will place in the html web directory a few files: Lets create a HTML form page with a submit key and a php script as the submit routine to write this to a file and ftp to MVS. MVS will then check to see if a updated request file is present and submit a JES2 dataset restore job for the user.

Lets remote desktop to the zLinux to create the files. If you are new to Linux, but familiar with windows, you can install an X client/server product like Hummingbird's exceed or open source types like http://sourceforge.net/projects/xming for your desktop. Then install putty http://www.putty.org/  for SSH connections. Before you connect to the Linux with putty SSH, check the Forward X11 option.  Then connect to your z/Linux. Here you will be able to start a graphics user interface(GUI) to the Linux desktop known as  KDE or GNOME (which ever was installed with z/Linux). To start KDE type "startkde". For GNOME, type "gnome-session". Of course if you have a Linux desktop you already have X server and you can follow the same for Forward X11 and SSH a connection. From there, you can navigate the menus to pull up a GEDIT or KEDIT editor to allow you to create these files in the HTML directory.

Brief form page, form.html:

<html><body><p>Submit Dataset Restore Request to MVS </p>
<form method="POST" action="submitter.php">
<table> <tr><td>Dataset:</td><td><input type="text" name="dataset" size="44"></td></tr><tr><td>Userid:</td><td><input type="text" name="username" size="8"></td></tr><tr><td>Password:</td><td><input type="password" name="password" size="8"></td></tr>
</table>
<input type="submit" value="Submit" name="submit">
<input type="submit" value="Cancel" name="cancel">
</form></body></html>

This above code will display a html form which the user supplies the requested dataset, a MVS userid, and password. The input type of password instead of text will hide the password while typing.  

 Submitter.php:
<?
#if not cancel then proceed
if (isset($_REQUEST['cancel'])) {
#issue error message
header("Location: http://".$_SERVER['HTTP_HOST']."/cancel.html");
exit;}
#get form values
$rdata = $_REQUEST['dataset'] ;
$user=$_REQUEST['username'];
$pass=$_REQUEST['password'];
#store request file
$rfile = "/tmp/reqfile.txt";
$fh = fopen($rfile, 'w');
$nl = "\n"; /* lets create the newline byte for the file */
$flag = "y"; /* this flag is to signal MVS to process */
$strdata = $flag . ' ' . $rdata . $nl;
fwrite($fh, $strdata);
fclose($fh);
#begin ftp process
$mvs="yourmvs.company.com";
$dest="mvs.request";
$conn = ftp_connect($mvs);
#login to ftp at mvs
ftp_login($conn, $user, $pass);
ftp_put($conn, $dest, $rfile, FTP_ASCII);
ftp_close($conn);
#give user confirmation
header("Location: http://".$_SERVER['HTTP_HOST']."/reqdone.html");
?>

As you can see from this code that if the requestor pressed the cancel button then he will get the cancel.html page. The values from the form are set to local variables and the dataset value is written to a request file on Linux along with a flag charactor for the routine on MVS to process this request. This routine then ftp's the temp file over to MVS and displays the confirmation html page. Keep in mind that this is a brief example and that this code can not handle multiple web user requests for restores and failures within the file and ftp operations. Also not shown are the two files "cancel.html" and "reqdone.html" that display a simple message. For more code examples and reference of PHP, refer to www.php.net Additionally, many references are available on the net about html form pages and table html tags.  

For those that are already familiar with this side of the technology, I will pen the next post for the distributed folks to understand a little about z/OS (MVS) operating environment as this request gets picked up and processed by that system's batch job processing for the dataset restore request of this mainframe user.



_____
tags:
Tuesday, March 04, 2008  |  Permalink |  Comments (0)
When you aren't too productive.

I was just installing Redhat Enterprise Linux 5.1 for S390x (64bit mainframe) platform. I did my usual custom configurations for the install to DASD and everything was looking good when I went to lunch. Anaconda was installing packages. Got back and Anaconda gui was gone, and the SSH session ended. The messages from the Linux starter system said you may safely reboot.... Great, I'll get this system up in no time. I went to IPL the volume and ZIPL loaded Linux and bam! PSW disabled wait code. Mmm. A root issue?

I tried the above install scenario again. This time, while watching and just as the post processing of the Anaconda install should have started, bam the gui went away, the SSH connection was terminated, and the starter Linux system went on like before about safely reboot...

I tried to IPL this volume and Bam! Right away, I got a PSW disabled wait even before the loader. Ah ha, ZIPL didn't work I said. I'll just manually ZIPL it.

I used another z/VM userid and mounted this volume to this Linux and discovered I was missing zipl.conf and other files. What the hey?

So I said what is up with Anaconda? 

Trying another logic path, I let everything default during the install. Anaconda did its thing all the way to post processing and running ZIPL (bootloader) with the nice message screen: installation complete with reboot button. And yes, the system booted just fine.

So, another go around found that Anaconda later chokes when I had changed up the DASD partitioning and LVM configuration from the default. 

However, for any newbie who might have been following some cookbook method of installing new Linuxes on the mainframe that involves their company installation standard and not the vendor's, you don't want to confuse them with bad QA on a release. 

Buyer beware, it could happen on any platform or OS vendor. My posts are about trying to make s390 platform Linux just about as easy as any other platform once you know how. In future posts, I will do just that with chapter dives into how to setup Linux on the mainframe for those that are new to this.



_____
tags:
Wednesday, February 20, 2008  |  Permalink |  Comments (0)
Some things are just better together.

Mmmm.... Of course that’s a complete dramatization, but you get the point.   

   

As I indicated in my last post, virtualization is a requirement for many reasons. Today's System z mainframe has it built in. Each machine has a type 1 Hypervisor built in to transform physical resources into virtual ones. Infact, System P and I models are equipped with Hypervisor technology as well.  Also virtualizations of memory, etc has been around in operating systems for years. Yes, z/VM, a virtual machine OS, facilitates z/Linux installations. But, how? Why wouldn't I just want want to use a PR/SM setup instead? The answer is related to how many Linux machines do you need as well as other considerations we will be discussing in this article.   

    

PR/SM (Processor Resource/Systems Manager) of course is derived from VM technology and is included with your z series processor. By creating Logical partitions, it also allows these LPARS to share processor and I/O resources by using MIF (Multiple Image Facility) and MCSS (multiple channel subsystem). These components allow I/O channel paths and subsets of devices attached to those paths to be shared between LPARS. PR/SM has improved over the years and allows for dynamic LPAR; the ability to add and delete processors, memory, and I/O between LPARS while they are still active.  

   

So why not just use this instead of paying of z/VM? This answer can be related to the trade off of managing a variety of LPAR (logical partition) configurations. You need to get the right mix of LPARs and massage them so that they will not have underutilized resources allocated to them. There is also a current limit in PR/SM of 60 LPARS.   

   

One of the reasons for virtualization I indicated earlier was if you want to drive up resource utilizations. Of course you could make OS images more application complex by consolidating. This had been done before on Mainframes. Yet, there were many reasons for moving applications to other machines. In the old days of MVS, you might have had a problem with IMS and DB2 co-existing well in shared memory. The distributed environment was also moving applications to their own servers with regard to change control or machine stability. Ultimately, this drove up the number of underutilized machines. With larger number of servers being used, there begins a boundary where one type 1 Hypervisor VM (PR/SM) or another one like z/VM may be more appropriate to a given shop.  

   

Here is but a few of Z/VM's advantages: 

   

  • More VM: Hundreds of VMs can be run under one z/VM. The number of VMs that you can run is limited only by the amount of system resources available. 
  • Starts everything: Either in System Config file or using the System userid for startup "autolog1", the VM administrator can define resources and start the Linuxes. 
  • Dynamic reallocation: Using execs, PROP, or Performance Toolkit, the VM administrator can have a wide range of on-demand allocation of resources as needed including setting the share priorities of the Linuxes as well as monitoring and reporting. 
  •  Over-allocation: Because of virtualization of memory for example, the over-allocation of resources is handled by z/VM as paging. 
  • Upgrade in place: With shared resources like disks, Linux upgrades can be easily handled by add/replace with larger or more disks. 
  • Vswitch controller: z/VM's TCP/IP stack initializes the OSA-Express device and continues communication as guest host couples to the virtual switch. In the event of OSA failures, the Linuxes can be isolated from the recovery that z/VM provides with the TCP/IP stack as this controller switches to alternate OSA. Recoveries can be even be more robust with controller failures being replaced by another controller. Starting with z/VM 5.3 there is support for IEEE 802.3ad Link Aggregation, Vswitch management (SNMP), native VLAN, improved diagnostics with Diagnose x'26c', etc.  

   

At the IBM Infocenter, they write, "virtualization can improve IT resource utilization by allowing system administrators to access and manage resources across a homogenous and heterogeneous environment."  In short, depending on your installation, virtualization is a given and PR/SM may be just fine. However, z/VM may be just the ticket for those shops that would like to take advantage of many of its features. As a Linux administrator and z/VM offering the ability to have any volume available to any Linux, mmmm tasty in deed.  I will talk more about that in latter posts.  Stay in Touch....   



_____
tags:
Friday, February 15, 2008  |  Permalink |  Comments (1)
Virtualization is a requirement.

I'm glad to see a conscious develop that more people are tuning into. The green environmental movements is a worthy effort and in line with the evolution of our civilization that it would be expected of us to eventually learn to recycle and harmonize with our major spaceship "Mother Earth".
 
Okay that is far as I need to take that. Yes, recent press releases from vendors like VMware and IBM are also on that bandwagon about how machine virtualization and server consolidation will reduce power and cooling costs, free up datacenter space, etc at costs of 50% or better. 

For example, at LinuxWorld Aug 2007 IBM announces its Big Green Linux initiative by wanting to also consolidate 3900 of its servers to 30 z series mainframes. Even for us, at BMC, we are also committed to virtualization on our servers and our products: http://www.bmc.com/products/products_services_detail/0,,0_0_48168368,00.html
 
However, for those that aren't motivated by "flower power", these vendors are on the right track in terms of TCO and controlling IT costs. It too is an evolution in datacenter management, and inevitable that more datacenters will utilize this technology in the future as it will very much be the mainstay of how IT is used.
 
How do I know this? Well for me, history is a guide. The mainframe evolved this way as well. It was not sufficient to just partition memory and a processor to run a task and then let it become idle until another task came about. It soon became apparent that higher utilizations of computing platforms as it relates to the expense to provide them challenged the vendors and customers to engineer capacity in a meaningful way. Ah, then the hardware eventually got cheaper due to Moore's law and everyone forgot about these early lessons. So I stand confident that as corporations look to lower the computing cost and other cost containment strategies that open technologies and virtualizations are not going to be periphery items, but instead mainstream. 
 
I will talk more about z/VM as it facilitates z/Linux on my next post, and yes, it too is a bit "leafy".



_____
tags:
Wednesday, February 13, 2008  |  Permalink |  Comments (0)
This document is intended for the Linux administrator on other platforms that may not be familiar with some of the specific utilities that zlinux has to faciliate its use on the mainframe.

I will start with the IBM utilities: zipl and chccwdev.

 

zipl command

zipl is easy to remember as (Z)linux intial program load (IPL) or booting.

It basically is a loader with configuration files.

The config file is located /etc/zipl.conf, and when you run the zipl executable, it creates a bootmap file in

/boot/zipl/bootmap (default target file).

The config file as used by Novell SuSE SLES10.

[defaultboot]
defaultmenu = menu

:menu
target = /boot/zipl
timeout = 10
prompt = 1
1 = ipl
2 = failsafe
default = 1

###Don't change this comment - YaST2 identifier: Original name: ipl###
[ipl]
target = /boot/zipl
image = /boot/image
ramdisk = /boot/initrd,0x1000000
parameters = "root=/dev/dasda1 TERM=dumb dasd=201-20F,192"

[failsafe]
target = /boot/zipl
image = /boot/image
ramdisk = /boot/initrd,0x1000000
parameters = "root=/dev/dasda1 TERM=dumb"

If your familar with grub or lilo then this seems straight forward.

The parameter values is where the user specifies what dasd device addresses he will be using and what device the root can be found among other parms that can be specified.

The important thing to understand is that you need to configure this properly so that have access to your devices. I will discuss distro specifics to zipl but also here is some references to others who also have discussed some of these distro specific issues. Linux for S/390 - mkinitrd and cloning notes

A typical command when cloning is to change root and run zipl on the mounted copy of the system to prepare that volume for future IPL:

chroot /mnt/new zipl

Basically, you update zipl.conf with your needed parms and run zipl:

  • update /etc/zipl.conf

parameters="dasd=0201-020F,0191 root=/dev/dasda1"

  • and exec zipl

Here is a list of typical procedures for some some distros:

on SLES8:

  • mk_initrd
  • update /etc/zipl.conf

ramdisk=/boot/initrd parameters="dasd=201-20F,0191,01B4-01BF root=/dev/dasda1 initrd

  • zipl

on RHEL3:

  • update /etc/modules.conf

options dasd_mod dasd=201-20F,191,01B4-01BF

  • cd /boot
  • mkinitrd -f initrd-2.4.21-4.EL.img 2.4.21-4.EL
  • update /etc/zipl.conf

ramdisk=/boot/initrd-2.4.21-4.EL.img parameters="root=/dev/dasda1 initrd"

  • zipl

on SLES9:

  • chccwdev -e <devno>
  • chccwdev -e 202

To have at initial boot:

  • mk_initrd
  • zipl

on RHEL4:

  • update /etc/modprobe.conf

options dasd_mod dasd=201-20F,191,01B4-01BF

  • cd /boot
  • mkinitrd -f initrd-2.6.8-1.528.2.10.img 2.6.8-1.528.2.10
  • update /etc/zipl.conf

ramdisk=/boot/initrd-2.6.8-1.528.2.10.img parameters="root=/dev/dasda1 initrd"

  • zipl

Of course, the above may no longer apply to your specifics so your mileage will vary.

Redhat for example, generally required the modprobe.conf to be updated in addition to zipl.conf. Whereas, Novell/SuSE SLES needed only zipl.conf to be updated to read the dasd parms. Also as indicated above, the following is necessary only if you specify kernel parameter INITRD in Redhat (below, like above is only an example of a specific kernel level). 

  • mkinitrd /boot/initrd-2.6.9-22.EL1.img 2.6.9-22.EL
  • mv initrd-2.6.9-22.EL1.img initrd-2.6.9-22.EL.img

 

chccwdev command

This is a nice command that allows you to take a device online or offline to zlinux. Under z/VM you can attach a disk device and the use this command to bring it online and then mount the filesystem to linux or prepare one if needed.

Command Syntax:

chccwdev -d xxx to remove a device (take offline)

chccwdev -e xxx to add a device (bring online)

Verify device status by

cat /proc/dasd/devices (reference: SuSE sles10)

 

My next post will discuss some of the great features that z/VM creates for the zLinux administrator.

For example, you can setup the ability to mount other zLinux machine's volumes to your zlinux and fix them in the event that you can not bring up the other zLinux.

Additionally in future posts, I will discuss other utilities available that allow zlinux to converse with other z/VM guests directly using a device driver and a command called hcp.

Stay in touch.



_____
tags:
Friday, February 08, 2008  |  Permalink |  Comments (0)
About me and why I'm writing this blog.
Open for Mainframe

What do I mean by that? Yes, I have to admit I’m playing on the words a bit.

The obvious play on words is “open for business.” However, I also mean “open source” and other “open” references. I guess I have a passion to say open development has made a big difference to the entire software market and mainframe is not insulated from it. Long ago pundits within the mainframe community talked about proprietary quality related to the cost in development would win over “homegrown” or other references to open source. However, now twenty years later, I would beg to differ on that opinion. Open source community has shown commitment and quality.

The World has Changed

I felt lucky. On one hand, I had over 30 years in mainframe, and yet on the other, I also had distributed computing experience dating back to the early Intel processors.  Back then, we were tinkering with IEEE S-100 bus, then the products started coming: Osborne’s 1, Job’s Apple I, commodore 64, IBM PC, TRS80, etc.  Having both hardware and software programming experience, I was happy to join the others on platforms that the common man could own.  I was in my twenties and working as a system programmer writing assembler code and learning about MVS operating systems.  I had already come up through the ranks as operator and programmer on smaller systems like IBM System/3. Now, I was making a living working in million dollar shops. We were reading memory dumps and writing OS exits for security and usability.  However, for me and my pals, we liked to hobby with the Intel 8088 and writing assembler code for it. Before that, the Intel 8048 chip only had 64 bytes of RAM memory of which 32 was reserved for the registers. The instruction set was lacking. With an adder and complement, you had to write your own routines to do subtraction, multiply, divide, convert to decimal or binary. All the things we took for granted on a CISC mainframe, these earliest little machines required basic microcode. So the Intel 8088 was a great start for those commercial personal computers that used them. (Note: There were other companies like Motorola that had 6800 processor chips that was competing with Intel in these new products). At that time, we never imagined the degree that these little machines would eventually have in the market place.

Work at BMC

Back in 2000, I started at BMC as a mainframe MVS system programmer. Yet, I wanted to get back to doing work I had done earlier, as a consultant, building Compaq servers and supporting Windows NT production environments. Later at BMC, I would eventually meet and work for my manager, Steve Carl, [Adventures in Linux]. It was Steve, who steered me toward Linux and open source. I have to admit, I like it.

Reason for this blog

Yes, the world has changed. I guess I’m older and finding that few if any want to learn about the mainframe these days. Yet many of the technology that was developed for it are being used today by distributed systems. Virtual machines is but one of these technologies. Having had my feet in both worlds, I feel I could share with my reader both what the mainframe did do and what it failed to do.

So what is Open for Mainframe about?

I’m going to pen about z/Linux and z/VM to start off with technical information on these topics. I want to include what the mainframe has to offer and give details into this world for those who would like to learn more about it. Additionally, I was motivated by others here at BMC to talk about their ideas of green technology that the mainframe offers. For example, many have realized that VMware and larger servers with SAN based storage offers cost savings in datacenter size and environmental requirements. These are also the tenets of the mainframe. I want to generate interest in this and show that the mainframe is a viable platform. And finally, for those who are within the mainframe community, I want to bring more information on how open source can help them.



_____
tags:
Wednesday, February 06, 2008  |  Permalink |  Comments (0)
Ron Michael

Subscribe to Ron's blog Subscribe to Ron's blog

Ron Michael's Bio

Open for Mainframe
« July 2008 »
Su Mo Tu We Th Fr Sa
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
 

Powered by Plone

This site conforms to the following standards: