Tuesday, May 13, 2008

A wonderful product called Image Focus for z/OS




IMAGE Focus is a software product from NewEra Software, Inc. It uses proprietary technology to track changes to operating system parameters, and provides the ability to do a ’Virtual IPL’ of a z/OS image to ensure that a real IPL will not encounter invalid parameters.


Image Focus runs as a started task under z/OS. It works by providing a series of “inspectors”. These inspectors - OS-Inspector, Sysplex-Inspector, JES-Inspector and VTAM-Inspector - perform the actual checking of each component.

IMAGE Focus is composed of three components, each of which may be optionally installed and operated independently of the others. These components are:

Recovery : The IMAGE Focus recovery started task is designed to maintain its own independent communications subsystem and provides ISPF application support to a single locally-attached non-SNA 3270 console. This provides the ability to logon, check, and fix problems when VTAM, JES, or TSO are unavailable at IPL time. This potentially avoids the need to perform unnecessary IPLs following the discovery of a problem; that is, an installation may “forward” fix problems found early in the IPL process.


Multi-user : When installed as a VTAM application to support multiple simultaneous users, IMAGE Focus maintains a multi-user started task. This provides the ability for users to logon using their external security product controlled userids and perform checking, browsing, and editing of system parameters.


Background : The IMAGE Focus background started task reports IPL changes that would result in future IPL


failures to a designated user or group through the TSO Broadcast Facility or via E-mail. These notices are sent at intervals controlled by IMAGE Focus, or optionally by the installation’s job scheduling package.


The checking process starts with the LOADxx member whose value is entered by the user, or as a variable if run in batch. It checks that IPL text exists on the IPL volume and that the SYS1.NUCLEUS data set can be opened. It processes each PARMLIB and PROCLIB member for syntactical correctness and related data sets for referential integrity and attribute characteristics. This process may be run in the foreground by a user, in batch, or on a continuous basis. During this continuous inspection, the inspector will determine if there are any problems with system definitions, warn of potential failures, and compile reports on suspect components. These reports identify errors in critical data sets, document their locations, and catalog the data sets that may prevent a successful future IPL.

This checking extends to JES, VTAM and TCP/IP and the product provides the ability to create installation-specific checking routines over and above those supplied.
The product provides a “what if” option that includes support for new releases of the operating system. This allows the user to plug existing IPL parameters into the next version of z/OS and check that they are still viable.


Key Features

The Image FOCUS Core, IFOCORE, includes the following:


• Operating System Inspection - Supporting all releases of MVS and z/OS through V1R8, evaluates operating system configuration components for weaknesses that will cause IPL failure.

• Dynamic Element Inspection - Pinpoints changes in the LnkLst, LpaLst and ApfLst that have not been updated in the system configuration.

• System Component Inspection - Allows for the inspection of individual system components. Within the Operating System, for example, individual z/OS Parmlib Members maybe inspected.

• New z/OS Release Analysis - Isolates areas in your current operating system configuration that will need to change in order to become functional when used with a new release of z/OS.

• Controlled Image Monitoring - Fully automates the interval inspection of Controlled Images and the reporting of results.

• Blueprinting & Change Detection - Blueprints the z/OS configuration for Controlled Images, detecting and reporting changes

• Subsystem Recovery - Provides access to ISPF system repair functions when TSO is not available. This Image FOCUS Core function is often called 'NOTSO".

Thursday, May 8, 2008

z/OS Catalog fault finding and fixing

This page describes how to use raw IDCAMS to investigate and fix catalog problems. It is usually easier to use a maintenance product for this. The shortcuts below will take you to specific points on the page.

Listing catalog information
The ICF catalog structure is complex, so if you have a problem, the first thing to work out is exactly which component is broken. Typically you'll be passed a problem ticket from someone who cannot access his data. Start by querying the catalog status for an affected file, by using the listcat command. The easiest way is to pick up a file list from ISPF option 3.4, then type the following line command against a file.

LISTCAT ENT(/) ALL

Here's a tip which you probably know already. You'll find yourself using the listcat command all the time. Shortcut it by sticking the following clist into a command library in your logon procedure. Type TSO LISTA to find an appropriate library. Add the clist as member name LC.

PROC 1 MEMBER
LISTC ENT(&MEMBER) ALL
EXIT CODE(0)

Now when you want to list the catalog entry for a dataset, all you need to do is type LC against it. The LISTCAT output tells you; which catalog the dataset entry is in, which volume the catalog thinks the dataset is on, and SMS class information. You get a lot more detail for VSAM datasets.

Checking the physical condition of a Catalog
If you are getting a lot of problems in the same catalog, then it is possible you have a physical error on the catalog dataset (it is just a VSAM KSDS). Physical errors often cause the catalog backups to fail too. If you use LISTCAT ENT(/) ALL against a catalog, it will tell you which master catalog it is in, which volume it is on, and a list of all the aliases which point to it. To see the full VSAM information, you need to use listcat ent(/) catalog(/) all
To check the physical status of the catalog, run the following IDCAMS statements in batch

EXAMINE NAME( -
CATALOG.ICFUSER.VOL001 - ) -
INDEXTEST DATATEST -
ERRORLIMIT(50)

and hopefully you see the output

IDC01700I INDEXTEST BEGINS
IDC01724I INDEXTEST COMPLETE - NO ERRORS DETECTED
IDC01701I DATATEST BEGINS
IDC01709I DATATEST COMPLETE - NO ERRORS DETECTED

If the examine reports problems, then you might have to recover the catalog, as described on the next page. However, before you start to recover, try an IDCAMS verify first, as it might just be that the file was not closed properly. The syntax is

VERIFY DATASET(catalog.name)

However, if you have a catalog maintenance product onsite, it will have functions to allow you to fix physical catalog errors. The maintenance product section has more details.

Checking the logical Catalog condition
The following IDCAMS command will check that the dataset entries in a catalog are complete. For example, it will check that VSAM truenames are associated with a cluster record.
DIAGNOSE ICFCATALOG -
INDATASET(CATALOG.ICFUSER.VOL001) -
LIST

and you should see
IDC01360I THE FOLLOWING ENTRIES HAD NO ERRORS:
followed by a list of all the entries

If your diagnose runs clean, but you still get catalog errors, try refreshing the catalog buffers using the console command
F CATALOG,CLOSE(catalog.name)


The following command will check out the logical structure of a VVDS

//DD1 DD DISP=SHR,DSN=SYS1.VVDS.VVOL001
//SYSIN DD *
DIAGNOSE VVDS -
INFILE(DD1) -
LIST

All the previous two commands do is check out that a single catalog entity is correct. What you need, is to ensure all the catalog components are consistent.

//DD1 DD DISP=SHR,DSN=SYS1.VVDS.VVOL001
//SYSIN DD *
DIAGNOSE ICFCATALOG -
INDATASET(Catalog.name) -
COMPAREDD(DD1)

This will check that the entries in a catalog are consistent with those in one VVDS. It does not check out the entries in all the other VVDS datasets. To find out which VVDSs are referenced by a catalog, use the command
listcat level(sys1.vvds) catalog(CATALOG.ICFUSER.TSG)

Two errors are possible. If the VVDS contains datasets, but there are no catalog entries for them, create them by using
DEFINE CLUSTER (NAME(SYS1.VVDS.Vvolser) VOLUME(volser)-
NONINDEXED RECATALOG) -
CATALOG(catalog.name)

If the Catalog contains entries, but they are not in the VVDS and don't physically exist, use

DELETE SYS1.VVDS.Vvolser NOSCRATCH CATALOG(catalog.name)

The next command will validate a VVDS against a catalog

//DD1 DD DISP=SHR,DSN=SYS1.VVDS.VVOL001
//SYSIN DD *
DIAGNOSE VVDS -
INFILE(DD1) -
COMPAREDS(Catalog.name)

If you end up with a missing VSAM Volume Record (VVR) for one component of a VSAM file, then do a delete / noscratch at the cluster level first to clean things up. That leaves all the components uncatalogued. Then do a define without the recatalog parameter, specifying the correct volumes and allocated space for the file you are fixing. So in the IDCAMS statement below, change the dataset name, volumes and space as appropriate.
DEFINE CLUSTER -
(NAME(OPROD.TEST)) -
DATA (NAME(OPROD.TEST.DATA) VOL(V3003F) TRK(3,1) ) -
INDEX (NAME(OPROD.TEST.INDEX) VOL(V30038) TRK(1,1) )

IBM removed support for VSAM parameters IMBED and REPLICATE some time ago. They must be removed from all catalogs before you install z/OS 1.8 or they will cause abends.
The number of processing strings is quite critical to catalog performance as they control the number of possible parallel read requests. The default value is 2, but this is too low. Consider changing your strings 5 or 7, depending on how busy it is. You will also need the correct number of data and index buffers. 5 data buffers and 7 index buffers are about right for 5 strings. If you define more buffers than this you are probably just wasting storage.

Extended Catalog Sharing can improve performance between LPARs as this puts the VVDS information into the coupling facility. This was problematical at first but seems to be stable now.
You may also get response time problems in a shared environment if you are converting hardware reserves to dataset enqueues with CA-MIM. Consider using GRS in a STAR configuration instead.

Tuesday, May 6, 2008

z/OS VSAM Recovery

VSAM files are typically used by on-line transaction based applications. VSAM files used by a DBMS can use the DBMS forward recovery process. VSAM files driven by CICS need traditional backup methods that involve bringing the systems down at some point overnight, then copying the data off to tape. If the file gets deleted or corrupted, then all transactions made since the backup are lost. This is unacceptable to businesses today, so VSAM updates are often recorded in transaction logs, so the file can be rolled forward to the point of failure. Recovery usually involves a restore from the latest backup, then a rollforward through the logs. These processes are discussed below.

Basic Recovery from backup

DFDSS recovery
Any successful depends on a good backup first. With DFDSS, it is probably best to specify the parameters SELECTMulti(first) and Sphere to get good VSAM backups. Selectmulti(first) means that if this is the first portion of a multi-volume dataset, then DFDSS will go out and find all the other portions and dump them together. An alternative is Selectmulti(any), which means that if the volume contains any portion of a multi-volume file, DFDSS will find and backup the complete file. This can be expensive if you have a lot of multi-volume files spread over lots of disks, as you will end up taking multiple backups of each file. Sphere means dump all portions of a VSAM file, including alternate indexes and paths.

If you do the backup correctly, you should be able to just do a standard dataset restore specifying the VSAM cluster name, as long as you also specify SPHERE to get all the associated AIX clusters and paths back too. If the cluster was dumped without SPHERE, then you need to restore any Alternate Indexes as seperate clusters, and build the paths with IDCAMS commands.

FDRABR recovery
FDRABR will handle single volume VSAM files easily. you simply select the file you want to restore using the base cluster name. FDRABR will then restore all parts of the file, including alternative indexes, but FDRABR will not restore paths. You need to do that yourself using IDCAMS. The command is

DEFINE PATH ( NAME(aix.cluster.name.PATH) )

Multi-volume restores are a bit harder. If you have multi-volume datasets, its your responsibility to make sure that all the volumes are dumped at the same time, so all the parts are consistent. If the backup is ok, then a restore should be as simple as
RESTORE TYPE=ABR,DYNTAPE,DSNENQ=USE
SELECT DSN=cluster.name
FDRABR should then go away, work out which volume backups it needs, dynamically mount the tapes, dynamically mount the output volumes, and restore the cluster. You need the same number of output volumes as the original file, with sufficient space on each. FDRABR restores each part of the file as a physical sequential, with a temporary volser ####Vx. Once it restores the last part, it catalogs the file up correctly as VSAM, with the correct volsers.

If the restore fails, then the 'VSAM special considerations' section of the FDR manual will assist.

VSAM Forward Recovery
If you record all updates to a VSAM file in a seperate log, and timestamp those updates, then you can use a technique called 'Forward Recovery' to get the file back to any point in time. CICS, the IBM transaction monitor, records transaction logs. If you use raw VSAM and want to recover to a point in time, you may need a third party product to provide logging facilities. The basic requirements for VSAM forward recovery are -
A Recovery Point, which is a time at which you took a full backup of all your VSAM datasets using one of the techniques above. This provides you with a backup copy of the whole file, which you should take at regular intervals, daily or possibly weekly.
A Journal, which is a chronologically ordered list of all the changes made to datasets since a Recovery Point. The Journals (or Logs) will only contain updates made to the file. You can write CICS journals to disk or tape, and write to a single file, or flip between files. Single files are easier to maintain, but will fill up quickly if there is a lot of update activity. Journal management is used to keep track of multiple files, and present them to the recovery program in the right order.
Forward recovery is a two stage process. First the dataset is backed out to the position it was in at the recovery point by restoring backup copies. Secondly all dataset changes that have been journalled since the recovery point are applied.

Fixing VSAM file components
To delete a VSAM file, you just delete the cluster entry, and all the components are deleted with it. You can either do this with an IDCAMS DELETE job, or simply type DEL against the VSAM cluster name on a 3.4 listing (this is explained in the Z/OS utility section)

If you have VSAM components without a cluster, then you can catalog them up using an IDCAMS RECATALOG command as below. You need to know the volumes the the uncatalogued components are held on
DEFINE CLUSTER -
(NAME(PIN.MVSOLZAX.ZMG) -
RECATALOG) -
DATA (NAME(PIN.MVSOLZAX.ZMG.DATA) VOLUMES(DV000E) ) - INDEX (NAME(PIN.MVSOLZAX.ZMG.INDEX) VOLUMES(DV003B) )

Alternatively you can delete the uncatalogued components using IDCAMS statements like

//DD1 DD VOL=SER=DV000E,DISP=SHR,UNIT=DISK
//DD2 DD VOL=SER=DV003B,DISP=SHR,UNIT=DISK
//SYSIN DD *
DELETE PIN.MVSOLZAX.ZMG.DATA - VVR FILE(DD1) -
CATALOG(CATALOG.ICFUSER.USER4)
DELETE PIN.MVSOLZAX.ZMG.INDEX - VVR FILE(DD2) -
CATALOG(CATALOG.ICFUSER.USER4)

The TRUENAME is a Catalog record that relates a VSAM component to its cluster. Sometimes, usually after a failed attempt to delete a VSAM file, you can be left with an orphaned truename record in the catalog. If this happens you cannot recreate the file, you will get duplicate name failures if you try. The answer is to use IDCAMS DELETE with the TRUENAME parameter as below.
DELETE PIN.MVSOLZAX.ZMG.DATA - TRUENAME

Monday, May 5, 2008

z/OS VSAM Striping

VSAM striping can be used to improve the performance of datasets that cannot cope with the IO rate from a single volume. In general, VSAM datasets with a high random access pattern benefited from being spread over several volumes. Aa an example, I once had a problem DB2 database that was very heavily accessed and really suffered from poor performance. This was fixed by making it go multi-volume. However, this is not the same as Striping. Striping means that each control interval in the file is written to another disk, so the dataset is spread evenly over several volumes. True striping is considered to improve sequential performance. RAID disks stripe datasets over physical volumes at hardware level, but this still appears as one logical volume to z/OS, as z/Os will still schedule one IO at a time to it. PAV aliases fixed that problem as they permit multiple concurrent IOs to one logical volume, so maybe striping is not as useful as it was. Be aware that if you use PAV, VSAM striping may make performance worse. However, if you want striping, this is how you do it.
Striping will only work for VSAM files that are allocated in Extended Format. To do this, the dataset must be SMS managed and be allocated with a dataclass that has a 'Data Set Name Type' of 'EXT'. Striping is not supported for Alternate Indexes or VSAM files using RLS. You specify that you want striping on a Storage Class. There are two different ways to do this, using Sustained Data Rate (SDR) or Guaranteed Space with an SDR greater than 0.
SDR: within the storage class definition set the 'Sustained Data Rate' parameter to a value that should be a multiple of four. The system will then divide that number by four to determine the number of stripes to use. For example, if you set SDR to 16, the system allocates 4 stripes (assuming you use 3390 format disks).
Guaranteed Space: If you set SDR > 0 and set the Guaranteed Space parameter to 'Y' then the system will use as many stripes as the number of volumes or units that you specify in your dataset allocation. VOLUMES(* * * *) or UNIT=(3390,4) should both allocate four stripes. Note that SMS may allocate fewer stripes if it does not have enough volumes with the right characteristics to support your request.
If you define a storageclass called 'STRIPED', then to allocated a striped file, you either code STORCLAS(STRIPED) in your IDCAMS allocation, or pick a dataset pattern and put a clause in your STORCLAS ACS routine so datasets matching that pattern get the STRIPED storage class. To convert a file to striped, rename the old file and all its components, re-allocate the original file with a STRIPED storage class, then IDCAMS REPRO the data from the old file to the new one.

Thursday, May 1, 2008

Bangalore : The rising divorce rate in the IT sector


The Information Technology boom in Bangalore is not unknown. However, everything comes with a price. Statistics reveal that in 2006 alone, 1,246 cases of divorce pertaining to those in the IT sector have landed in the matrimonial courts in Bangalore. Financial freedom, lack of time at home, erratic working hours, work pressure, financial security and stress are being seen as the main reasons for this fiasco. The worrying factor is that the number of divorce cases pertaining to those in the IT sector has seen a steady rise since 2003. In 2003, the number of cases from the IT sector was 283 while in 2004 it went upto 526. Statistics available show that in 2005 the figure went up to 946 and in 2006 the figure was 1,246.


The year 2007 has not been too kind. The statistics available till June 2007 state that the number of divorce cases from the IT sector is 828 already. Experts state that the figure is likely to increase by the end of the year. What is more shocking is that divorce cases from the IT sector seem to be contributing to the number in a big way.

Wednesday, April 30, 2008

Do mainframes have a future in India?




This is one debate that has raged on for years is the mainframe dead, and is client/server king? Events like 9/11, which demonstrated the need for fault-tolerant computing, have re-ignited the relevance of this debate. Stanley Glancy finds out more on the current market trends for these technologies.


The advent of minicomputers in the seventies and desktop PCs in the eighties was expected to ring the death knell for mainframes, which were considered to be large, inflexible, expensive and difficult to use. Desktops were not only inexpensive, but could also be connected through a network to a central server, enabling organisations to store huge amounts of data. But doomsayers were proved wrong when despite stiff competition, the mainframe continued to maintain a steady growth rate. And in the current scenario, where organisations (after 9/11) have increased spend on storage solutions, there is a trend which indicates that mainframes may gain a bigger share in the IT budgets of CIOs.


Kishore Modak feels that Linux has been the main engine for the growth of the mainframe market in India

For instance, other than traditional mainframe users like the banking-financial services sector and manufacturing behemoths, even unlikely candidates like universities and the travel industry have been choosing mainframes over newer technologies. Says V L Mehta, director of IT at Mukand Engineers, “More than 70 percent of the world’s data still resides on mainframes. The market is growing in terms of revamping the older mainframes and adding new features and software to the oldies. Also, the new mainframes are smaller, cheaper, more powerful and e-business ready, so the market is growing steadily.”

Though these are small encouraging trends, the picture is not completely clear. For instance, a Meta Group report states that mainframes won’t be able to match the price and performance improvements (close to 35 percent a year) of Intel-based servers, which are emerging with mainframe-like capabilities. In India too, very few mainframes have been purchased and installed in the past 3-4 years. But this has been due to policy issues rather than technology choices. India missed an era of mainframe and legacy systems due to the absence of global IT majors in the country from the late seventies till the early nineties. Barring large government organisations and public sector companies, mainframes were not seen anywhere else. The mainframe market grew in the late nineties during the Y2K scare, and many companies seized the opportunity. Agrees Kishore Modak, country manager for the zSeries Enterprise Systems Group at IBM India, the only global mainframe vendor to have a presence here, “IBM exited India in the seventies and returned only in the nineties. This gap of close to 20 years put a dampener on the adoption of mainframes here. Awareness about mainframes is only now picking up. The industry is realising the importance of converting mission-critical and large volume applications from distributed processing back to centralised processing for better control and management, disaster recovery, security and business continuity.” According to market sources, IBM’s mainframe business has been growing at a steady 12-15 percent per quarter.

The impact of client/server

One reason for the slow adoption of mainframes has been the advent of client/server architecture. Client/server technology with its myriad attractions was expected to dry up the market for mainframes. Not only was this technology capable of storing macroscopic amounts of data, it was also flexible, extremely easy to handle, and comparatively inexpensive. But while many organisations did adopt client/server systems, very few actually gave up the mainframe. Most companies have managed to achieve a perfect blend of the two technologies to meet their computing needs. However, smaller organisations, due to the huge cost associated with maintaining mainframes, have migrated to client/server systems.


The high cost of owning a mainframe was also expected to influence corporate decisions to opt for client/server technology. Though this has certainly made client/server an attractive proposal to many, companies desirous of using IT for strategic purposes do not mind the added cost of a mainframe. Mainframe loyalists say that there is also a myth about the cost advantage of client/server over mainframes. Explains Modak, “A single mainframe can reduce the cost of maintaining hundreds of servers. The cost difference seems high when you compare the price of a single server with that of a mainframe. But people have to look at it from the point of view of a total data centre. Only then will they realise that the actual cost difference is not much.”

The IBM zSeries, for example, enables server consolidation by handling the workload of hundreds of servers. It not only provides organisations with a lower total cost of ownership—through consolidation of Unix, Windows NT, and Linux applications to Linux on zSeries—but is also an application development platform for large customers. Further, fault tolerance is built into all mainframes, reducing downtime to the bare minimum. Another problem which customers face with client/server systems is that unlike mainframes these systems often come from different suppliers, and the various components may not be integrated or adapted to the user company’s needs. This issue is minimised by a mainframe.

Sectors

Verticals currently using mainframes include stock exchanges and depositories, utilities, airlines, railways, armed forces, e-business portals with heavy traffic, oil-sector PSUs, manufacturing giants, the travel industry, banks and financial institutions. These industries cannot do without mainframes since they run mission-critical applications that require high security and reliability. They also have huge databases, which can be managed only by a mainframe.

The banking segment has traditionally been a heavy mainframe user. But with many banks migrating to client/server, this sector has seen a sharp decline in mainframe usage. Says Modak, “It is true that many of the smaller banks with fewer branches have opted for client/server, but most of the larger banks remain loyal customers. There has actually been increasing demand from banks for mainframe technology—especially after 9/11—for managing their disaster recovery needs; this is because the quality of service offered by mainframes is very mission-critical oriented.” The Reserve Bank of India, one of IBM’s largest customers in the banking segment, is also one of the most intensive mainframe users in India.

Usage of mainframes has also increased in the airline industry with Indian Airlines running mission-critical applications on IBM’s zSeries. Even universities have shown a keen interest in training students on mainframes.

Another vertical that is a heavy user of mainframes is what is popularly known as the computer-related services industry. Elaborates Modak, “The software development industry has been a key focus area for us as we expect to see strong growth in this sector. IT giants like Wipro and Infosys do their development work here in India due to the cost/benefit factor. Since they deal with terabytes of data and also run mission-critical applications, a mainframe is the safest bet. Not only does it offer a favourable cost/benefit ratio, it also provides high reliability and security required in large-scale processing work, which no other currently-available technology can provide.”


More than 70 percent of the world’s data still resides on mainframes, says V l mehta
Benefits Return on investment (RoI) and total cost of ownership (TCO) are the key factors organisations look at before installing something as expensive as a mainframe. But according to Mehta, RoI is a very relative issue and such comparisons cannot give a real picture unless it is case-specific. Says he, “RoI and expensive are relative terms and depend on what one is looking for in terms of mission criticality of a business application. Of course, if one can get the same solution at a cheaper price one should go for it.”

Compared to client/server, mainframes do work out cheaper in the long run. A study conducted by LinuxWorld on the subject states that running one IBM mainframe uses less power than running 750 Sun or PC servers. This would be a real benefit, however trivial, next to the cost of the Linux and VM (virtual machine) licenses, if the mainframe could handle the same load. Another benefit is that the mainframe allows partitioning of resources to run different applications simultaneously. Using partitioning software, a mainframe can be split into several independent computers that share the same hardware. IBM has demonstrated the running of tens of thousands of Linux computers on a single mainframe. Mainframes also offer easy access to open source and Internet-related applications.

Linux

But which catalyst will provide the necessary boost for the growth of the mainframe market in India? Replies Modak, “The main engine for growth has been the adoption of Linux. Customers have discovered that Linux provides a favourable TCO and gives them flexibility in management of costs.” But there are various conflicting reports on whether Linux will actually help IBM grow its mainframe business. A report published by the Meta Group says that though mainframes running Linux have some advantages in the short run, in another 4-5 years these advantages will be irrelevant as Unix and Windows 2000-based systems flesh out increasingly robust, mainframe-like management capabilities—partitioning, workload management, reconfiguration and prioritisation. This will make users think twice about the premium they would have to pay for mainframes.

However, a Giga Group report thinks otherwise. According to Giga, mainframe technology is beyond the first phase of adoption, and has already made deep inroads into the financial services sector. While it’s true that other technologies have been trying to bridge the gap, IBM has not been sitting idle. The company has been making substantial investments in research and development.

IBM’s introduction of the z800 makes it possible to run Linux as a single operating system, ensuring ease-of-use. This, plus its ability to run hundreds of applications together makes it attractive to many organisations. Says Modak, “Earlier there were a lot of applications in the open space but you couldn’t run them on mainframes. We had specific applications available only on the mainframe. But Linux has changed that by offering higher uptime. A whole host of applications are now being made available through Linux.” Companies are under pressure to optimise their existing IT investments. This, plus other factors like availability of lower-cost systems, increasing support for Linux applications, and newer workloads from IBM, are expected to drive the growth of mainframe technology. Giga also predicts that more companies will use zSeries Linux environments for application serving combined with back-end database serving residing in a zSeries z/OS environment.

Conclusion

While it is difficult to predict the general future of mainframes, in India it may be a different scenario altogether. IBM may be able to gain a stronger foothold in the Indian market with its cost-effective Linux-based mainframes. Also, unlike earlier mainframes, the current set of machines are easier to handle and occupy less real estate—which may swing the tide in IBM’s favour.
Most analysts believe that while small organisations will continue to prefer client/server based architectures, sectors like telecom and the government will continue to favour mainframes.

Labels: , ,

IBM System z10 Enterprise Class


At a glance

The IBM System z10 EC is a world-class enterprise server designed to meet your business needs. The System z10 EC is built on the inherent strengths of the IBM System z platform and is designed to deliver new technologies and virtualization that provide improvements in price/performance for key new workloads. The System z10 EC further extends System z leadership in key capabilities with the delivery of expanded scalability for growth and large-scale consolidation, improved security and availability to reduce risk, and just-in-time capacity deployment, helping to respond to changing business requirements. The System z10 EC delivers:
# Improved total system capacity in a 64-way server, offering increased levels of performance and scalability to help enable new business growth.

# z10 quad-core 4.4 GHz processor chips that can help improve the execution of CPU-intensive workloads.

# Up to 1.5 terabytes of available real memory per server for growing application needs (with up to 1 TB real memory per LPAR).

# Increased scalability with 36 available subcapacity settings.

# Just-in-time deployment of capacity resources which can improve flexibility when making temporary or permanent changes. Activation can be further simplified and automated using z/OS® Capacity Provisioning (available on z/OS V1.9 with PTF and on z/OS V1.10, when available).

# New temporary capacity offering Capacity for Planned Event (CPE), a variation of Capacity Back Up (CBU). CPE can be used when capacity is unallocated, but available, and is needed for a short-term event.

# A new 16 GB fixed Hardware System Area (HSA) which is managed separately from customer memory. This fixed HSA is designed to improve availability by avoiding outages.

# Memory and books that are interconnected with a point-to-point symmetric multi processor (SMP) network running with an InfiniBand host bus bandwidth at 6 GBps designed to deliver improved performance.

# The new InfiniBand Coupling Links (planned to be available second quarter 2008) with a link data rate of 6 GBps, designed to provide a high-speed solution and increased distance (150 meters) compared to ICB-4 (10 meters).

# The new OSA-Express3 10 GbE LR (planned to be available second quarter 2008) with double the port density, increased throughput, and reduced latency.

# HiperSockets improvements with Multiple Write Facility for increased performance and Layer 2 support to host IP and non-IP workloads.

# Encryption accelerator provided on quad-core chip, which is designed to provide high-speed cryptography for protecting data in storage. CP Assist for Cryptographic Function (CPACF) offers more protection and security options with Advanced Encryption Standard (AES) 192 and 256 and stronger hash algorithm with Secure Hash Algorithm (SHA-512 and SHA-384).

# HiperDispatch for improved efficiencies between hardware and the z/OS operating system (z/OS 1.7 and above).

# Hardware decimal floating point unit on each core on the Processor Unit (PU), which can aid in decimal floating point calculations and is designed to deliver performance improvements and precision in execution.

# Large page support (1 megabyte pages).

# Up to 336 FICON™ Express4 channels.

# Fiber Quick Connect (FQC), a fiber harness integrated in the System z10 EC frame for a 'quick' connect to ESCON® and FICON LX channels.

# Support for IBM Systems Director Active Energy Manager (AEM) for Linux™ on System z for a single view of actual energy usage across multiple heterogeneous IBM platforms within the infrastructure. AEM V3.1 is a key component of IBM's Cool Blue portfolio within Project Big Green.1

# The IBM System z9 Enterprise Class (z9 EC) and System z9 Business Class (z9 BC) servers are the last servers to support participation in the same Parallel Sysplex with IBM eServer zSeries 900 (z90), IBM eServer zSeries 800 (z800), and older System/390 Parallel Enterprise Server systems.


Overview

The System z10 EC is a marriage of evolution and revolution, building on the inherent strengths of the System z™ platform, delivering new technologies and virtualization that are designed to offer improvements in price / performance for key workloads as well as enabling a new range of solutions. The z10 EC further extends the leadership of System z in key capabilities with the delivery of expanded scalability for growth and large-scale consolidation, availability to help reduce risk and improve flexibility to respond to changing business requirements, and improved security. The z10 EC is at the core of the enhanced System z platform that is designed to deliver technologies that business needs today along with a foundation to drive future business growth.
With a modular book design, the z10 EC E64 is designed to provide up to 1.7 times the total system capacity of the z9 EC Model S54 and up to three times the available memory of the z9 EC. Significant steps have been taken in the area of server availability in the z10 EC design. Preplanning requirements are minimized by delivering a fixed, reserved Hardware System Area (HSA) and new capabilities intended to allow you to seamlessly create logical partitions (LPARs), include logical subsystems, change logical processor definitions in an LPAR, and add cryptographic capabilities for an LPAR without a power-on reset.

z10 EC introduces just-in-time deployment of capacity resources designed to provide more flexibility to dynamically change capacity when business requirements change. You are no longer limited by one offering configuration; instead you can define one or more flexible configurations that can be used to solve multiple temporary situations. You can now have multiple configurations active at once and the configurations themselves are flexible so you can activate only what is needed from your defined configuration. As long as your total z10 EC infrastructure can support the maximums that are defined, they can be delivered. A significant change is the ability to add permanent capacity to the server when you are in a temporary state. The combination of these updates can change the way you think about on demand capacity.
New integrated clear-key encryption security features on z10 EC include support for a higher advanced encryption standard and more secure hashing algorithms. Performing these functions in hardware is designed to contribute to improved performance.

Integrated on the z10 EC processor unit is a Hardware Decimal Floating Point unit to accelerate decimal floating point transactions. This function is designed to markedly improve performance for decimal floating point operations which offer increased precision compared to binary floating point operations. This is expected to be particularly useful for the calculations involved in many financial transactions.

New innovations on the z10 EC are designed to give needed capacity and memory along with the just-in-time management of resources. Advanced virtualization technologies aid in server consolidation, satisfying high I/O requests and dynamic provisioning of new servers.