Linda chosen Chairman of IDMS User Association

At the annual meeting of the Board of Directors of the IDMS User Association in Las Vegas, in conjunction with CA World, Linda Casey, Managing Member of Run Right was selected to succeed Terry Schwartz as Chairman of the IUA Board.

Terry continues to remain a member of the Board, and Run Right salutes his contributions as Chairman during his tenure.

Linda, currently chair of the IAU Education sub-committee, is thrilled and honored to be selected to lead the Board, and looks forward to working with the Board, the IDMS user community, and CA Technologies to continue to bring value to the greater IDMS community.

Instructor Presence and Persona Important in the Virtual World

The landscape of learning is changing, from a pure face to face classroom environment to one that exists in both the virtual and physical worlds. How can instructors, trained to teach in the traditional face to face classroom adjust to online learning? Are the skills they use today in the physical classroom easily transferable to online learning? Or is the pedagogy so different, that a complete retraining is necessary? Do we really need instructors, or as some believe, can we rely only on technology to teach students in the future?

Online learning is on the rise in the United States, with nearly twenty percent of college students enrolled in at least one online course. Technology supplies the central meeting place where interactions, socialization and learning can occur. It does not, however, create these interactions. The instructor plays this pivotal role. This is no different than traditional face to face learning where one would look at the building and the classrooms within and say, “There, that’s all we need, no instructor necessary.”

The skills and roles traditional instructors use in face to face environments, where the learning is teacher-centered, are different than those in online learning. Learning online is more learner-centered with the roles instructors play changing to facilitator, social director, program manager and technologist. Students experience their instructors in these various roles through course design, course content and communications. The impact of instructor presence and persona in the online world is profound. Without effective instructor presence and persona online, students are left adrift in a world of isolation and disconnection.

So how can instructors create a rich interactive environment where students feel connected and engaged in the learning? Let’s look at three student/instructor/technology intersections and how they impact interaction, social presence and ultimately knowledge construction. The first intersection is the structure of the online material, as it is laid out in the learning management system. A well laid out class gives structure to the learning and portrays the instructor as competent, caring, invested and organized. It has the ability to reduce learner anxiety and increase student satisfaction. The second intersection is in instructor introduction and initial student connection. In the absence of a physical instructor, instructors must establish a sense of “being”. This initial introduction gives students an insight into who will be guiding their learning experience and in the end, providing assessment of their work. These interactions help shape how engaged and invested the instructor is in their learning. The third intersection is with discussion boards. From a technological perspective, they are simply a communication tool that allows for conversations to be threaded in chronological order and for postings to be grouped by subtopic. The presence of a discussion board alone does not create interactions of a social or learning nature, but rather these interactions spring from the assignments and exercises created and facilitated by the instructor within this tool, as well as the participation of the students. Instructors should take a middle ground when facilitating online discussions for maximum student interaction, neither dominating the conversation as expert lecturer nor at the other extreme, absent and distant. As facilitators, instructors work to deepen the learning and enrich the experience of students. Since the goal is learner-centered learning, the facilitating techniques should promote interaction amongst students, encouraging discussion through positive, timely feedback, prompting, open-ended questions to deepen the discussion, and gentle redirection when the discussion begins to go off-track. This stance moves the instructor to more of a co-learner position.

Teaching online can be challenging for those facing a transition from the face to face paradigm. Traits such as shyness or stage fright may no longer be an issue online. Instructors with great physical classroom presence may struggle when interactions move to the virtual world. There is no guarantee that an effective face to face instructor will succeed online just as there is no guarantee that an ineffective face to face instructor will not. The online environment is vastly different, but with proper training, insight and care, the chances for success increase. For some, this may be their first real teacher education, which serves everyone in the long run. We see that technology is not the do-all/end-all, but rather the framework that supports the learning. It is instead the learning environment created by the instructor that promotes learning: how the instructor builds this world matters, how they behave in it matters, how the students perceive them in it matters. Just as with face to face teaching, teacher presence and persona matters, and in a world where physicality is missing, it is even more important.

$.O.$. – squeezing dollars out of the mainframe in hard times

Women and Children First!

The already leaking IT Financial ship has hit the iceberg of recession, and we’re bow-down and sinking fast.  Things were bad enough during the “good times”, when companies made money and just wanted to squeeze IT a bit so they could make even more money… now almost everybody is having serious revenue shortfalls, and cutting expense becomes a matter of corporate survival, not mere greed.

We are past the point of arguing whether we should be using wooden lifeboats or inflatable rafts… you use whatever is handy that can get the job done before it’s too late.

The point of this rant: if high on your survival agenda is saving mainframe costs, you need to take a hard look at what your projected NET savings are (savings – costs to implement), and how soon you expect to achieve those savings.  Without debating the actual, realizable savings one might achieve in mass migrating existing applications from the mainframe to an alternate platform (the most likely topic for my next epistle), the point remains large migration efforts almost certainly will take more time than you have right now.  You need savings this year and maybe next, not a 5-year ROI project.  The solutions you should be looking at today need to have both a quick return and a manageable upfront investment.

You have available a few generic approaches to either reduce the size of your mainframe, or (more likely) stave off that next upgrade for as long as you can:

• Peak Management
• Demand Management
• Application Tuning
• Workload Relocation

Note: all of these approaches assume someone or some group in your organization has the information and tools necessary to understand what is being done, when, why, and by whom in your mainframe workload.  This information is critical in order to intelligently drive a CPU reduction project.

• Peak Management: you need to size your mainframe to handle the peak load.  Analogy: how big a freeway do you need if everybody in the city drives to work at exactly 8am every day?  If you are using 1,000 MIPs from 8am to 5pm, but the machine sits idle for the remainder of the day, you have a huge opportunity.  What can you do to adjust the workload to level out the peaks (to have people stagger their commute)?  User-driven workload (online transactions, etc.) is difficult to control, but scheduled (batch) workload provides opportunities.  Have you analyzed what work is being done during your peak processing periods, and can you move some of it to your slack periods?  Bulldoze the workload peaks into the valleys.

• Demand Management: are your users doing things they really don’t need to do?  Analogy: are teenagers cruising Main Street repetitively every Friday night?  Can you identify (by application and requestor) significant workloads that appear to be subject to negotiation or control?  Is that daily report really needed daily?  Could it be made into a weekly?  Focus on those things running during the peak periods.

• Application Tuning: are (parts of) some applications just pigs?  Can you identify what transactions and batch jobs are major CPU consumers?  Are any of them worth a performance code review?  Do any of them appear candidates for Demand Management?  Again, focus on those things running during the peak periods. 

All the above efforts should be well within the capabilities of a seasoned IT department, given some priority-setting and appropriate project leadership.  All of them most shops do from time to time, but not always as a focused effort.  This may be the time for a focused effort.  Pull a team together and task them with holding back the tide.  In medium to large environments every month you can defer an upgrade can save hundreds of thousands of dollars in CPU-related charges.  The payback can be both large and quickly achieved, especially if aggressive workload management has not been the norm in your shop. 

As many of the decisions to be made relate to application and usage-specific questions, engagement of in-house staff is almost always required, but project leadership and direction could come from an external consultant, if no in-house resource is available. 

What follows is a more of a medium-term option, but one with both the potential for significant CPU savings.  It also has some side benefits as well.

• Workload Relocation: are there some workloads, or portions thereof, that can be moved to a less expensive platform?  The “mass migration” scenario I discarded as a short-term option at the beginning of this article is the extreme example; there are other, faster ways to move some workload off the mainframe.  What if instead of moving entire applications, we move only that functionality which can be moved easily and with minimal disruption.  The mainframe (and IDMS) architecture stands second to none in being able to deliver stable and well performing transaction-based applications.  However; the mainframe has no particular advantage in a reporting or data warehousing application.  The proliferation of reporting tools and relational databases of all shape and hue on distributed platforms provides reporting capabilities that are equal to or superior to what the mainframe can provide.  What is hard is getting them to work cheaply against mainframe data.  As long as the data remains on the mainframe, it takes mainframe cycles to support reporting requests from other platforms.

This has led to a well-understood and widely embraced approach of creating a clone of selected mainframe data on a distributed platform, to support reporting/retrieval processes.  Creating these second copies can be done by using a commercial product, or through in-house developed methods (sometimes requiring application modifications).

Back to our dilemma: you need a quick hit.  Off-the-shelf can be implemented much much quicker that trying to create a unique in-house solution. Several robust commercial products exist which allow mainframe databases, such as IDMS, to be replicated to these other, cheaper platforms.  These products can be implemented generally without any changes to existing mainframe application code. Since many shops already have end-user reporting tools that are used against relational data, providing access to replicated mainframe data may actually be viewed as an enhancement by the end-user community.

The catch is; you need to pick a product and spend some money.  So if you choose to look into this option, and as you look at products, consider these questions:

• What workload will you be able to offload?  Will it be enough to make this worthwhile?
• How soon can you implement and offload work?  How long before I recoup my investment?
• What overhead does a particular replication product add to the mainframe?  This eats into your offload savings.
• Any product limitations?  What can’t it do that I need it to do?  What changes do I have to make to existing mainframe applications or environments?
• Any additional functionality in the product you may need for future projects?  If I buy it for simple replication now, what future needs might I have that I need to think about as I commit to a given product?
• Any additional benefits to the company from creating a replicated data store?   What benefits can I show the business community from having a local relational copy of mainframe data?  Can I allow local applications to access this data?

Bottom line: shops looking to quickly reduce CPU usage, or even just slow the upgrade cycle, should place immediate focus on managing workload and user demand, and tuning those application components which are significant contributors to peak usage.  Beyond that one should take a serious look at what specific workloads might be quickly and easily offloaded; either through data replication or other means.

A word from our sponsor: Run Right, LLC would be happy to discuss how we can assist you in putting together a “Save Some Cycles” initiative, including any or all of the above major categories.  For report offloading, we can recommend a partner who has what we feel is the most technically sound approach to IDMS replication we’ve seen.  Give us a call.

Our blog

Welcome to the Run Right, LLC blog. 

We hope to keep you entertained and informed with periodic missives we think you might enjoy.

As I write this first blog entry, Linda is in Las Vegas attending the IUA meetings as part of CA World.  Once she returns in a few days I expect she will post an entry or two on what transpired there.

We hope to use this blog to both entertain and educate, and also as a place where we can vent about some of the nonsense we all occasionally see in today’s corporate IT.  We have our opinions!

Our hot buttons generally center around a few items:

• IT failing to communicate adequately with the business (you have to get them engaged!)
• IT failing to listen to the business (they don’t talk our language, we need to listen, not just hear)
• IT, with help from the business, making poor choices with the IT investment
• IT failing to communicate with other portions of IT (development vs. operations vs. system folk)

I’m sure we’ll have plenty of tinder to light some interesting flames; hopefully shedding not only heat but light.

Speak to you soon;

Don