Published:
October 16 2009, 02:17 PM
|
3 Comment(s)
by
Reg Harbeck
There are some words in the English language that have a surprisingly large number of meanings, often unrelated to each other, or else connected by some obscure reference that is fading in the mists of time.
One such word is "set" which apparently has the largest number of meanings in the English language.
We have words like that in IT as well - and we certainly have TLA's that have many meanings (see http://community.ca.com/blogs/execio/archive/2008/07/04/tla.aspx and http://community.ca.com/blogs/execio/archive/2009/04/02/pci-and-other-compliance-related-tla-s.aspx).
But one word that has always fascinated me in IT is "stack".
Yes, there are many non-IT meanings of stack, both as a verb and a noun. But in IT, it is generally used as a noun.
My first encounter with "stack" was in first year university, when I learned about how information was saved for calling routines so that subroutines could safely conclude and return to the place in the program that called them. According to Wikipedia (see http://en.wikipedia.org/wiki/Call_stack), this is known as a "call stack".
Interestingly, my second encounter with "stack" was discovering that COBOL, and then even basic mainframe architecture, didn't employ stacks.
For COBOL, as I discovered the hard way when trying to program a recursive PERFORM (i.e. it called itself), the return address was stored as a vector at the end of the paragraph(s) you're PERFORMing rather than being stacked somewhere. So, if you PERFORMed a paragraph from within itself, it would overwrite that vector with the address inside that paragraph which called it, resulting in an infinite RETURN loop. It's been a while since I tried this, so perhaps this has changed in more recent versions of COBOL.
However, it has always been my contention that COBOL and mainframe BAL are twins separated at birth, they are so similar in style and approach. I think that, just like "C" was created with the PDP-11 architecture in mind, COBOL was created with the same architectural principles in mind as those that were used to create the System/360 mainframe and, consequently, its machine and assembler language.
The difference is, with the mainframe the return vector is stored in CPU register 14 or R14 (hence the ever-popular IEFBR14, the job of which is to set the return code to zero and return to caller, allowing other activities to occur that need a program to run but not actually do anything).
In any case, I'd just gotten used to the concept of stacks and their absence in certain languages and architectures when I encountered another kind of stack: TCP/IP. Having been a CICS Systems Programmer and MVS Systems Programmer, I was broadening my horizons by being a Network Systems Programmer around the time that TCP/IP was starting to flourish, even on the mainframe.
And I must tell you that trying to figure out where the "push" (putting something onto the stack) and "pop" (taking something off of the stack) were on the TCP/IP stack caused me a fair amount of confusion, until I realized that the term instead referred to the "stacked" layers of the TCP/IP protocol suite: Application, Transport, Network and Link.
Then, I joined CA and learned about software stacks.
Now, I could see how the first kind of stack was a stack because you had layers of addresses and information that you added to the top and removed from the top, just like a stack of anything else that grows and shrinks from the top.
The second kind was more of a conceptual stack of fixed layers, but, OK, it kind of looks like a stack when represented that way.
Software stacks, on the other hand, are more like a conceptual neural network in my opinion. Basically, a software stack is a group of pieces of software (applications, programs, systems, etc.) that work together to produce a result at a higher level of value than the individual pieces could.
So, an operating system that has many modules might be thought of as a stack.
And, a single vendor's software that is well-integrated and produces a high-level business value could also be seen as a stack - but only if that vendor had actually taken the time to integrate the various pieces and unite them towards a particular result.
Turns out, that's just what CA is doing with our mainframe software as part of our Mainframe 2.0 strategy: bringing together our mainframe software into a single point of business-enabling functionality (see http://ca.com/Files/TechnologyBriefs/mainframe2-roadmap_192644.pdf). Between the common interfaces, the common services, various integrations, and testing to ensure they all work well together at set levels (CARS - CA Recommended Service), the CA Mainframe Stack really is a software stack - made of individual pieces, but working together to produce a single result: helping your business run better with IT.
So now I know about three kinds of stacks that are relevant to the mainframe. And one more that is less and less so, given how environmentally "green" the mainframe environment is: smoke stacks.
And that is how it stacks up for me.
By: Reg Harbeck
Reg Harbeck is CA's Product Management Director for Mainframe Strategy. In the more than two decades since he received his Bachelor's Degree in Computer Science he has worked with operating systems, networks, security and applications on mainframes, UNIX, Linux, Windows and other platforms. Reg...
Read More..