Monday, August 11, 2014

System Programmers Versus the Dreaded Application Programmer: It's the Application Programmer's Fault

by Brenda J. Christie

Whose Fault Is It Anyway?

Today's post has its genesis in an article which appeared in Enterprise System Media entitled, "Reducing the Potential for CICS Storage Violations."  It's all about that, but it doesn't miss the opportunity to blame those careless application programmers for sloppy code which can bring an entire CICS region down with the dreaded SOc4.    And yes, there are sloppy application programmers out there just like there are sloppy system programmers out there as well.

The article traces the handling of storage violations (S0c4) from the early days of CICS to the CICS/ESA architecture.  It does a decent job of explaining how storage violations can occur, most likely through Getmain instructions or runaway indexes, and in the process lays the responsibility for causing storage violations on the shoulders of application developers.  For example, an application programmer could write a piece of code that executes a Getmain to load a commonly used routine into memory and then perform some actions passing parameters back and forth.  A sloppy application programmer could neglect to code a Freemain for the temp storage once the routine was no longer needed.  However, the most likely scenario would entail creating and using an index and then referencing an address outside the scope of the index. When I say referencing, I mean writing to an address outside the index scope which would overwrite an address potentially used by CICS or some other user application.  The result could be an S0c4, storage violation.  This could have considerable consequences in a production environment, resulting in outages, loss of data, and possibly money.  I think the system programmers dislike the difficulty of debugging the problem more so than outages, loss of data and/or  money.  How many system programmers still read HEX and EBCDIC?  Are there any real system programmers left?

The article also describes how the advent of CICS/ESA has ameliorated storage violations.  It explains that prior to CICS/ESA, the critical control blocks were actually embedded within the same space as the user application and CICS so that a storage violation had the potential to corrupt not only the user program, but other user programs and CICS itself.  Looking back at this configuration it seems ridiculous to have embedded the links to next-executable instruction, links to tasks keeping CICS running within the same space.  But then, we call it evolution for a reason.

The Crumble Zone

With CICS./ESA the critical addressing control blocks were moved outside the application user space and in doing so, reduced the likelihood that an application programmer could inadvertently bring down CICS with a faulty index.  IBM actually came up with a fairly sophisticated Concept:  The Crumble Zone.  The Crumble Zone is an 8-byte storage area which contains the concatenation of a task's task number and a 1-byte literal which indicates the type of storage which follows.  The Crumble Zone also proceeds the user data/application so that the user data is encased by a Crumble Zone on either side.  Something like a strait-jacket.  Maybe that's what the system programmers had in mind.

The article ends by discussing some other improvements IBM has developed in CICS/ESA 4.1 to prevent storage violations.  These include CICS storage protection as well as transaction isolation which confines the task to its own storage and certain shared storage areas while preventing it from accessing task-related storage for other user tasks.  Read more about it here.

Guess Which Team I'm On?

Bye for now,

Brenda J. Christie

Friday, August 1, 2014

Useful Advice on Using Public Computers

by Brenda J. Christie

Interesting article from ZDNet regarding the perils of using public computers, things to check out before using, and a possible way to prevent yourself from becoming a victim of identify theft.  Read it here and also here.

Brenda J. christie

Tuesday, July 22, 2014

Elasticity in the Mainframe Environment

By Brenda J. Christie

This week's Enterprise Systems Media feature article centered around the concept of "elasticity," a nice buzzword that really means flexibility.  Or in project management speak, it is called "resource balancing."  However, the article, "IT Sense: Elastic Storage" talks about the difficulty of assessing the availability of a resource due to a lack of standardization within the environment itself.

The article begins by discussing the desirability of having all human resources ideally active in order to minimize paying for a resource that is not being used.  The idea is to be able to use software to monitor output and then re-allocate idle or under utilized resources to a task which could use more resources.

The article then moves from discussing human resource utilization into discussing detecting available capacity within the storage arena, and attributes failure to do so to the fact that not all storage is created equally, and configurations vary due to cost and capability.  In essence, it says the concept of Elasticity is not viable.

Well, I have to disagree with that tenet.  To compensate for the differences in storage, meters could be attached to the storage devices to capture output levels.  Given the existence of pre-defined benchmarks as to optimum throughput, it would be possible to tell whether a device is at, under, or over capacity.  Assuming all the meters are somehow connected to one control device, it should be relatively easy to tell which storage device needs more work and what the new optimal configurations should be.  Not rocket science.

Indeed, industries outside IT have already conquered this problem.  Witness MotorsAtWork.  As part of my work in property management, I have seen meters used in commercial energy consumption monitoring and performance tuning and will post a follow-up link to an article highlighting such successes.

Brenda J. Christie

Engaging the Stakeholder

by Brenda J. Christie

Years ago there used to be this breed of IT professional who essentially espoused the philosophy of "if you build it, they will come."  They got a whiff of what the business said it needed, came up with a solution immediately, and then off to the races they charged.  Using the Waterfall methodology, designing, testing and producing the deliverable usually took months, after which the stakeholder said, "But that's not what I wanted."  Everyone was disappointed.

Fortunately, thanks to the advent of Agile and the whole concept of collaboration, those types of results are, hopefully, infrequent.  Not that Waterfall was the culprit.  After all, any tool is only as good as the person using it.  I'll use my experience as an example.  

How I approach stakeholders, whether using Waterfall or Agile, is to listen to them and try to understand them.  However, it would be a crap shoot, by which I mean risky, to think that would be sufficient.  In creating the BRD, I usually use process diagrams, I'll create a mock application using Access or SQL Server or something similar to imitate the behavior of what the application is intended to do.  I'll use Word or Excel to create a report if that's part of the deliverable.  

Then I'll sit down with the Stakeholder to have a dialog, i.e., 2-way conversation on whether, I got it right. Obviously this is can be an iterative process and quite different from the decades ago type who acted like Samuel L.Jackson's character in Rules of Engagement.

Fortunately for me, my approach was successful 99% of the time, and I stayed, and continue to be, gainfully employed.

But why engage Stakeholders at all?

Well, as I mentioned above, it's a good idea to engage stakeholders because it contributes to continued employment.  It also aids in eliciting the project requirements.  Opening up a dialog with stakeholders also has the potential to reveal what the stakeholder expects to gain from the project, whether there is a limitation to using the deliverable (i.e., an obstacle to overcome), what the stakeholder's motivation may be with regards to the project, and by extension, whether the stakeholder is even on your side.

To a large extent, engaging the stakeholder can often take different forms.  Some prefer one-on-ones, some will participate in round table discussions, some will participate in conference calls, and some only want to participate via email.

However they participate, stakeholders have the potential to make or break a project.  Some pack more influence than others, and this is a distinction that needs to be made early on.  However, this distinction can only be made by contact with stakeholders.  They are real whether we choose to acknowledge them or not.

Brenda J. Christie

Tuesday, June 10, 2014

On Diversity In The Technology Field

by Brenda J. Christie

Another great article, Diversity isn't a Google Problem, holds as its premise the scarcity of minorities in the technology field, being due to laziness and comfort with familiarity.  Written by Shane Paul Neil, and appearing in Technorati, the article holds that such scarcity is indeed, industry-wide and not limited to Google.

I find this trend both interesting and dismaying but maintain that it is more the outcome of the commoditization of Information Technology, wherein much like Investment Banking, too many people want in because of the potential payoff.

This contrasts quite starkly to prior periods, including the decades where I worked as a developer and project manager.  In prior decades it was more for the love of technology and its capabilities than money. Not that the salaries were anything to dismiss.  However, salaries were no where near the compensation levels Google is known to pay its employees.

Notwithstanding compensation, prior periods were altogether different.  I worked along side many diverse groups, both from an ethnic and religious perspective.  I do believe that in spite of these differences, love of technology was the glue that held us all together.

It is sad that money has once again separated us.  It is probably an unfortunate byproduct of the commoditization of Information Technology.  

Brenda J. Christie

Continuance of the Mainframe Evolution

by Brenda J. Christie

Read some interesting articles recently depicting how the mainframe, and its supporting tools, continues to proliferate, indeed, to far corners of the world.  All articles referenced appeared in Enterprise Systems Media.

One article, IBM CICS Tools , blew my mind with discussion of a CICS Cloud, and capturing data (presumably to sell to marketing companies) all while lowering TCO, total cost of ownership thru reduction of batch cycles, cross-site workload balancing and support for dynamic mobile workload configuration.

These all may just be staid and true concepts marketed under current terminology, but I was impressed.  Although I did not see much of what went on behind the CICS Systems Programmer's curtain while in the mainframe world, my recollections of discussions I did have do not include tools as those discussed in this article.

Another article which brought back memories, is the one on Attachmate's extension of its terminal emulation product to work on smartphones and tablets.  It was a huge jump to move away from the Wylbur environment to terminal emulation.  This move to be able to access the mainframe from a smartphone or tablet is equally monumental, although I do have concerns about security and introducing vulnerabilities inherent in smartphones/tablets due to their relative youth, into the mainframe.  Quite naturally, Attachmate wants to reassure prospective customers that its security is up to par.  Being hard to kill, the IBM mainframe will most likely be proactive and defend itself, nonetheless.

Finally, there was also a piece, China Needs a Mainframe, which discusses China's love affair with the IBM mainframe, and how it let IBM into China to conduct business.  Predictably, the recent Snowden and other revelations have dampened that honeymoon with the Chinese now advocating to buy local mainframes

All great articles, and definitely worth the read.

Brenda J. Christie

Thursday, May 1, 2014

Inc.'s Top 10 Project Management Apps - Swiggle

by Brenda J. Christie

Just joined Sqwiggle.  You get a free 14 day trial to use video and audio conferencing, a floating toolbar which includes a chat room, email, invite or catch the attention of team members.  There is a whiteboard where documents can be shared.  I logged on using the Chrome browser.  It seems to only support Chrome, which given Microsoft's recent security vulnerabilities in Internet Explorer, might not be such a bad thing.  

One thing I'm curious about is the security of documents uploaded.  Will have to do some research and see if I find any comments on what Sqwiggle does with uploaded documents.

This seems very similar to Skype, LiveMeeting and several other web-based collaboration.  Will kick the tires a bit more and see how they really compare and report back here.


Brenda J. Christie