The delivery of IT services is more difficult today than ever due to several factors. First is the constant growth of data volumes that not only stress primary storage but also make backup and recovery extraordinarily difficult. This is exacerbated by users’ much higher expectations for data availability that in turn severely restrict backup windows and restore times. In addition, the expanding use of virtualization and cloud-based services give users a taste of immediacy and location-independence they lap up like hungry dogs; virtual machines can be created in minutes, and data can be accessed via the cloud rapidly from any location, with multiple devices. Mainframe systems aren’t immune to these new developments and are increasingly being asked to provide unprecedented services and service levels, particularly in terms of data availability and protection. As the business becomes accustomed to secure, scalable, efficient backup procedures and instant recovery of applications, mainframe systems must adjust.

Storage Attached Network (SAN) is an efficient solution for many storage needs, especially where hundreds of gigabytes or even many terabytes are required. Linux running on z/VM can use SAN nicely, and System z provides Fibre Channel Protocol (FCP) adapters to connect to the SAN fabric. But is it that easy? Connect it and it’s done? Not even close. From a z/VM perspective, if you have more than a handful of servers using SAN, things can get daunting quickly. This article describes some of the pain points associated with managing direct-attached SAN (not EDEVs, otherwise known as VM-emulated devices) from a z/VM perspective and how to overcome them.

My March/April column started a discussion of file archive, which we suggested might well be the real killer app this year. The simple fact is that in most businesses today, the volume of data being stored as files exceeds the volume of data being stored as transactional, or “block,” data. Given IBM’s efforts to expand the role of the mainframe to shoulder more of the workload currently hosted on x86 server platforms (its zEnterprise kit and strategy), where much of the file-based data is generated today, it seems likely that mainframers will soon confront the problem of what to do with all those pesky files.

My team of solution architects frequently design and implement z/OS disk migrations as part of storage upgrades or new implementations. After performing many migrations at small to very large installations, we’ve learned the many trials and tribulations of disk migrations along with ways to deal with the different challenges that always seem to occur.

Capacity planning today is anything but “business as usual.” Forward-thinking organizations are already redefining capacity planning as “capacity management” because performing capacity work effectively in an environment that will feature on-demand provisioning and private cloud services involves more than just looking at MIPS consumption for annual budget planning.

The August/September 2011 z/Journal article, “Understanding Persistent IU Pacing (aka Extended Distance FICON)” (available at www.mainframezone.com/operating-systems/understanding-persistent-iu-pacing-aka-extended-distance-ficon) explained the basics of Information Unit (IU) pacing and the newer persistent IU pacing mechanism. The American National Standards Institute (ANSI) T11 FC-SB3 standard was amended (FC-SB3/AM1) in January 2007 to incorporate changes made with persistent IU pacing.

“What goes around comes around” is an old saying that’s especially true for information technology, particularly for data center management philosophies. We’ve gone from centralized to distributed and back again. As far as storage connectivity goes, we’ve gone from direct-attached to networked, and, in the mainframe space, we have a recurring question, “Do I need FICON switching technology, or should I go direct-attached?” With up to 288 FICON Express8 channels supported on a System z196, why not just direct-attach the control units?

Archive and long-term data storage requirements are growing at a record pace. As a result, many businesses are wrestling with deciding whether to build their archive strategy on disk, tape, or a combination. According to IDC's June 2011 Digital Universe Study, the world's digital data is more than doubling every two years with approximately 1.8 zettabytes to be created and copied or replicated in 2011 and up to 7.9 zettabytes by 2015. In addition, individuals now generate up to 75 percent of all digital information. According to the study, the magnitude of 1.8 zettabytes of data is equivalent to:

The mainframe is alive and well and heading for the clouds, according to the latest research from BMC Software.

What is Extended Distance FICON? How does it work? What does it require for hardware support? Does it support longer distances than FICON connectivity normally accommodates? What does it mean for my architecture? Can I eliminate channel extension?