This post is a continuation of the post ReBoot: A CGI Allegory for Millennial Mainframers (Part 1).
Where we last left off, our Millennial Mainframer hero Bob the Guardian met with his mentor Phong to figure out how to protect Mainframe from the evil computer virus MegaByte. Phong advised Bob the following:

“There is an old README file that says you should keep your friends close and your enemies even closer…  I’ve seen that look on young sprites before.  Don’t be rash,  and don’t do anything alone!  Here in Mainframe, we stick together.”

If you stopped the episode as advised in the first post, please resume this video at 9:36.

Despite telling Phong that he would adhere to the mainframe mentality and “go back and talk to the others,” Bob immediately left to see MegaByte and “keep [his] enemies even closer.” Bob therefore lied to Phong, demonstrating that he hadn’t yet internalized the mainframe mentality of trust and cooperation. Perceiving himself as the fastest and most skilled individual in Mainframe, Bob sought to deal with MegaByte alone, assuming that cooperation with older Mainframers would slow him down or risk failure due to their “low clock speed.” Like young professionals in any field, we Millennial Mainframers run the risk of forming false preconceptions that their older colleagues are slow and inflexible, holding us back and biding their time until retirement. It is critical that we debunk these preconceptions and respect our elders in order to benefit from their mentorship and lessons learned.

When Bob got to MegaByte’s lair, he told MegaByte “I see that you’re the big circuit in town… I’ll throw my chips in with you.” Oftentimes, young people seek to “throw their chips in with” the biggest players and hottest technologies. This is shown by the popularity of mobile development in universities, the usage of new development tools like Python and Ruby on Rails, and the prevalence of books like Are You Smart Enough to Work at Google? By going after “the big circuit in town,” many young people fail to improve their competitive advantage by positioning themselves in a market niche where their knowledge, skills, and abilities shine brighter than the competition. This principle is why the decision to become a Millennial Mainframer can be so lucrative.

After making his way into MegaByte’s lair and witnessing his droid army firsthand, Bob finally learns the truth of MegaByte’s “little favor.” MegaByte wants Bob to “stabilize this tear into a portal” to let MegaByte and his army cross the network into the Super Computer. Often times, internal users of a computer environment have limited network authorization in line with an organization’s information security policy. Like MegaByte, many users many complain about specific ports being closed and their inability to access special resources. Occasionally, administrators may receive requests for “little favors” that violate organizational guidelines, like opening ports on the firewall to allow for access to torrent sites. Both Guardians and Admins must consider these requests extremely dangerous due to the possibility that they could open the door for unanticipated consequences and malicious behavior, such as letting a virus into the Super Computer.

Despite MegaByte’s false flattery and empty promise that “I won’t disappoint you,” Bob saw through the ruse, asking MegaByte “what guarantee do I have that you won’t just spread to the Super Computer and raid the Armory.” Unfortunately, he did not have the foresight to prepare for MegaByte’s Plan B: holding Bob hostage to force his way into the Super Computer using the threat of deletion. Because Bob failed to adopt a mainframe mentality and heed Phong’s advice that “in Mainframe, we stick together,” he opened the door for MegaByte to gain access to the Super Computer. Thankfully, Phong sensed that Bob “must be at MegaByte’s alone,” enabling Dot to come to Bob’s rescue. Dot’s diversion and rescue of Bob demonstrates the importance of teamwork among Mainframers, even when that involves bailing out a colleague from a situation caused by their poor judgement. While Bob’s attitude of individual initiative and “making [it] up as [he] goes along” imperiled himself and the Mainframe, Dot’s attitude of teamwork and well thought-out plans saved them both.

Just when Bob and Dot thought their were finished with MegaByte, the user targeted their local sector for a game. This shows that the chaos caused by a Virus can increase the vulnerability of a system to other threats. Within the game, MegaByte quickly hijacked the user’s account to gain network authentication to the Super Computer, forcing Bob and the other Mainframers to intercept him before reaching the portal.

Having finally internalized the importance of teamwork in a mainframe environment, Bob rallied the Mainframers to man their starfighters, “stay frosty,” and follow his lead to intercept MegaByte. By showing his willingness to take point and put himself in the most dangerous position in Alpha Squadron’s formation, Bob was able to rally the Mainframers despite his past mistakes. This paid off when Dot warned Bob to “look out!” when he was in danger of crashing into an Asteroid. Regardless of one’s technical aptitude, it is critical to have a good Wingman covering your back. In return, Bob showed his willingness to be a good Wingman by covering Dot when she radioed “cover me! I think I’ve got a shot.” Rather than trying to be a hot shot by going after the capital ship himself, Bob fell in behind Dot as her Wingman to let her take the glory, and showed genuine appreciation and gratitude for Dot by saying “cool shot.” Oftentimes, sharing the credit will get you further in the long run.

“When our assists lead to baskets, that’s us playing our best, and we begin knocking down shots” ~ Tim Duncan, San Antonio Spurs

Once Bob was open to accepting help from the other Mainframers and working together as Wingmen, he was equipped to stop MegaByte.  Dot warned Bob when MegaByte pulled a tricky maneuver to get on his tail, allowing him to destroy MegaByte’s ship.  Dot also distracted MegaByte  long enough to allow Bob to slip past him and close the portal. In return, Bob was able to use some of the “tricks” he earned from his experiences on the Super Computer to rescue Dot from MegaByte. Due to our myriad experiences studying x86 computer concepts in school, we Millennial Mainframers often have specialized expertise (in concepts such as Linux or Java) that is foreign to the average Mainframer.  These “tricks” allow us a means to add immediate value to our teams (and occasionally save our older peers’ butts as Bob did with Dot).

By working together with his fellow Mainframers to defeat MegaByte, Bob internalized the mainframe mentality. Although MegaByte will clearly remain a threat in the future, Bob rests easy knowing that “when he messes with one of us, he messes with all of us.” Even though the Super Computer has “lots of RAM, incredible capacity, and.. can access almost anything,” Bob realizes that “it sure is good to be home” in Mainframe. After all, the value of the Mainframe is ultimately not in the processors, RAS characteristics, parallel sysplex, or any other hardware or software concepts.  The value of the Mainframe lies in the discipline, planning and cooperative spirit of the Mainframers.

Posted in Uncategorized.

If you’re a millennial like me, there is a significant chance that you saw the show “ReBoot” during your childhood. Due to it’s status as the first full-length cartoon to be fully computerized, this show was quite popular during its run from 1994 until 2001. When the first episode aired to American audiences in October of 1994, the show broke records and overtook Sonic the Hedgehog as the most-watched children’s cartoon. Despite great expense, technical snags, and production delays, ReBoot demonstrated the viability of computer-generated imagery (CGI) for visual storytelling, encouraging the subsequent production of the Transformers: Beast Wars cartoon and Disney’s blockbuster Toy Story in 1995.

While ReBoot offered cool cutting-edge graphics and fun technospeak for the first children to grow up “digitally native” (and many of their parents), there is a high likelihood that the subtext of the show went over the heads of most of it’s audience. Since joining IBM and becoming a Millennial Mainframer, I had the chance to rewatch the first episode of ReBoot, whereupon I made a starting discovery:
ReBoot is an allegory for success as a Millennial Mainframer!!!! 

Allegory is a device used to present an idea, principle or meaning, which can be presented in literary form, such as a poem or novel, in musical form, such as composition or lyric, or in visual form, such as in painting or drawing. It is also seen in scriptural passage. Allegory communicates its message by means of symbolic figures, actions or symbolic representation. Allegory is generally treated as a figure of rhetoric; a rhetorical allegory is a demonstrative form of representation conveying meaning other than the words that are spoken.

This means that the characters and story lines of ReBoot are symbols used to convey the message of how to be successful as a Millennial Mainframer.

You don’t believe me???  Then watch this video and read my analysis below. Note: Stop the video at 9:36 if you want to keep pace with this blog.  The remainder of the analysis will be posted next week on May 14, 2012.
I argue that the protagonist Bob is the archetype for the modern Millennial Mainframer.  
In the opening scene of ReBoot, we hear the voice of Bob saying the following:

“I come from the net, through systems, peoples, and cities to this place… Mainframe.
My format… guardian, to mend and defend,to defend my new-found friends, their hopes and dreams, to defend them from their enemies”

Throughout the episode, Bob makes it very clear that he is new to the mainframe, reflected in the fact that he calls himself “the new Sprite in town” early in the episode and later sweet-talks his way into Megabyte’s evil lair by saying “not being from Mainframe, you’ll have to forgive me.” 
Doesn’t this sound just like us, fellow Millennial Mainframers??? We may not be “sprites,” but we’re certainly new to the mainframe. Like Bob, we came “from the net, through systems, peoples, and cities to this place… Mainframe.” Many of us came to the mainframe with significant experience on the ‘net using non-mainframe systems, and traveling to various cities to study IT concepts under people that as-likely-as-not consider the mainframe to be ‘extinct.’
Furthermore, we’re not typical 3270-lovin’ mainframers like our older peers. Many of us prefer modern GUIs over “green-screens.” If you watched the episode closely, you may have noticed that Bob is blue-skinned, while some of the more established Mainframers, like Dot Matrix, are green-skinned.  Does this remind you of anything?
In this light, the narrative of the first episode of ReBoot was a “coming-of-age” story, where the new-comer to Mainframe, Bob, defeated MegaByte by embracing his fellow Mainframers and adopting the mainframe mentality.  
Upon first arriving at Mainframe, Bob was a hot-shot.  Reflecting his past experiences at Super Computer, Bob derisively said “Low clock speed or what..” when he outran Mainframers Hack and Slash.  This reflects the fact that many IT professionals from other platforms make mistaken assumptions about the mainframe being slow and outdated.
Bob soon discovered that, like in many IT shops, the Mainframe environment in ReBoot threatened by a key stakeholder committed to the platform’s complete destruction.  In ReBoot, this is MegaByte, a power-hungry and ambitious “virus” that openly threatens Bob’s friends if he doesn’t agree to do him “a little favor.” Of course, that favor is to help him get off the mainframe and move to the super computer. Many naive CIOs believe, like MegaByte, that shifting workloads off the mainframe to a more “modern” platform will solve all of their problems.
The morning after refusing MegaByte, Bob’s casual morning routine was interrupted by a frantic call for help. Dot’s Diner was “down,” which was a disaster considering the criticality of workloads on the mainframe. Bob discovers that, unlike other platforms, the mainframe has expectations of zero downtime. Upon arriving at Dot’s Diner, Bob discovers that the downtime is due to a security breach.  The dog, Frisket, was defending the door of the Diner, but hackers circumvented this security system through non-traditional and unanticipated entry points into the system (breaking through the window). Like other administrators of multiuser computer systems, Dot failed to secure undetected backdoors.

After learning from Dot, Enzo, and the Dedicated Server that MegaByte’s goons were responsible for the attack, Bob admitted that this downtime was retaliation for his refusal to do MegaByte “a little favor.” In response, the Dedicated Server suggested “Just a little favor huh, maybe you should do it if it means we can stay online,” reflecting two common mistakes in the running of IT organizations:

  1. Over-emphasis of short-term priorities at the expense of long-term planning. While Bob could appease MegaByte in the short-term to protect his friends, this would also strengthen MegaByte as a long-term threat to the platform as a whole.
  2. A siloed perception of IT. When the Distributed Server said “we,” he was thinking about Dot’s Diner.  By over-emphasizing uptime for the Dot’s Diner workload over other aspects of the Mainframe environment, the Distributed Server’s approach potentially threatened the overall uptime of the platform.
When Bob called MegaByte‘s attack “my problem” and offered to deal with him by himself, Dot countered that “it’s everybody’s problem… This isn’t the supercomputer, around here, we Mainframers stick together…” This disagreement identifies the key difference of mainframe environments from other platforms. While someone else’s workloads running on someone else’s dedicated servers can be someone else’s problem, the shared architecture of the mainframe requires mainframers to think communally and act as a team.
Nevertheless, Bob continued to believe that he could single-handedly be the messiah of Mainframe. It was only when his attempt at working alone led to the loss of a “game” and the nullification of an entire sector that Bob finally realized he couldn’t handle the threat alone. Hurt and confused, Bob turned to Phong, a wise and experienced Mainframer, for advice. As Millennial Mainframers, it is critical that we find experienced mainframe gurus to mentor us in the ways of the mainframe mentality. Only mentors can advise us in how to deal with significant organizational or technical challenges, like the threat of workloads moving off the mainframe. After proving himself “worthy” of Phong’s advice (something that most IT professionals must do to earn the trust and respect of potential mentors), Phong told Bob the following:

“There is an old README file that says you should keep your friends close and your enemies even closer…  I’ve seen that look on young sprites before.  Don’t be rash,  and don’t do anything alone!  Here in Mainframe, we stick together.”

Bob thus learns that the key to defeating the ongoing threat to Mainframe is by listening to his Zen-like mentor Phong, working together with the other Mainframers, and adopting the mainframe mentality.

Will Bob follow Phong’s advice? Will Bob and Dot Matrix defeat MegaByte and save Mainframe?  Tune in next week on May 14, 2012 to find out.  In the meantime, let’s hear your comments.

Posted in Uncategorized.

As one of the fairly new members into the mainframe family, I originally had some hiccups understanding the basics of mainframes. And by basics, I mean the absolute basics. I wish there was someone who could tell me a story of how it all happened from start to present in the mainframe world. A dear friend and a mainframe enthusiast suggested I read a book and the book clearly solved the purpose.Hence, here is a top ten list of the coolest z/OS facts.

1.      z/OS is an awesome multitasker


Back in the days, when z/OS was developed, computers were extremely expensive. Hence the developers built z/OS in such a way that different people could use z/OS to run multiple tasks at the same time. Every task that runs on z/OS runs in an address space and each task thinks that it’s the only one running. However, behind the screen, z/OS shares resources like memory and CPU across all tasks and there could be numerous tasks running at the same time sharing these resources.

2.      z/OS handles large workloads


It sounds quite obvious that z/OS can handle large workloads. But there must be a way to decide what tasks to run first and what can wait. In other words, how do we prioritize? z/OS uses a feature called WorkLoad Manager which helps in prioritizing system, production and non-production tasks. This helps z/OS in handling large workloads making 100% use of the CPU.

3.     It’s unbelievably hard to crash z/OS


Everyone expects z/OS to keep running and running and running. So anytime when a task crashes, we can not let that crash any other part of the system. Now remember we mentioned that every task runs in its own address space. So IBM has invested a lot of time and money in making sure that when a task crashes in one address space, it does not interfere with the normal functionality of the entire system, in other words making it robust and also clean up completely where the crash occurred so we can be up and running like new. But z/OS records any crash that occurs due to a hardware or software failure, so we can get into investigation later.

4.      z/OS has the best recording


z/OS comes with its own inbuilt scribe and we call it the System Management Facility(SMF). SMF records quite a lot of information like when was the system started, what task is currently running, when was a file created, when was it last edited, who deleted it, etc,. Security audits, capacity planning and performance monitoring are some of the uses of all this information that is recorded using SMF. IBM can proudly claim that z/OS has the most extensive recording of any operating systems.

5.     You need a job entry subsystem for z/OS


z/OS can run a series of jobs at the same time without any human intervention and they are called batch jobs. Users use a language called Job Control Language (JCL) to specify instructions for a specific job or a batch job to run. Once z/OS receives instructions from a user in the form of JCL, the role of a Job Entry Subsystem (JES) is to convert the JCL instructions into machine readable form and then queues them for processing, create address spaces, make sure all the input files for the job are ready, specify where the output has to be written and any other information required to run that job. Overall, JES acts like a manager, making sure, everyone has their resources to do their job and everyone does their job diligently.

  6.      How different are z/OS files?

                   We all know about files on windows. They store our data and we can access our files through an application like notepad. In z/OS, the concept of files is quite different. In the first place, they are not even called files. They are called Datasets. Each dataset is made up of records. When you create a new dataset, you need to specify the length of each record. Some other basic information that you need to specify are where the dataset should be stored and how big of a dataset it is. We will discuss about creating datasets and all the information you need to know to create a dataset in a later post. Hang in there!

               7.      How do you talk to the Mainframes?

 

How do we interact with such humongous mainframe computers and z/OS? We have to use an application called TSO/E( Time Sharing Option Extended) to talk to the z Systems. TSO/E is very hard to use. So z/OS comes with ISPF (Interactive System Productivity Facility). ISPF gives an interactive and easier way to communicate by providing lot of inbuilt functionalities

8.     You get UNIX with z/OS

When we say, you get UNIX with z/OS, that’s really an eye wash. What you really get is a POSIX compliant UNIX Shell called UNIX Systems services (USS). Posix compliant means that we meet all requirements to call it UNIX, but it’s actually not UNIX. 

9.      z/OS has a console

In your mainframe server room, you will have operators who would monitor your system on a regular basis to make sure if the system is running without any interruptions. The way they do it is, by monitoring the console with the system news feed to see what is going on in the system, if there are any alert messages or if there is any problem that they need to be aware of. The main z/OS console is directly plugged into the mainframe, so that even if there are network issues, the console will continue to work.

10.     z/OS isn’t enough

Once we successfully setup z/OS, we now have a basic operating system. But the real functionality of a mainframe is not exhibited unless we equip our system with applications that run on z/OS for security management, performance, database management, printing, etc,.  Apart from IBM, there are also other vendors in the market who sell applications that run on z/OS to make it more efficient.

If you need more of this, I suggest reading What On Earth is a Mainframe?
The book is a very easy read with topics ranging from fundamentals of mainframe hardware to application development on z/OS.
Posted in JCL.