Data Access: Why Not Use the Best?
I’ve been in mainframe technology long enough to have played a role in its evolution, from tape to sequential files to VSAM to IMS to DB2. During these evolutionary steps, I was responsible for modernizing applications to exploit the most modern technology for better data access. When we wrote new applications, we would start with the latest and greatest at the time.
Obviously converting from tape to a sequential file is a big improvement. It’s faster for one thing. The conversion was relatively easy, mostly changing the file declaration and the associated JCL. Moving to VSAM was harder, but offered much better searching. These program changes were necessary to move away from sequential logic and step up to the requirements of online processing. Then came the databases for better data access. Migrating to databases required a lot of work, but with that investment of time and energy came big advantages in data access. The data could be stored more efficiently, but the far greater advantage was enhancing applications to have effective query capabilities. I was amazed at all that I could do with the power of queries. Once I started down that path, I never went back. Today’s applications have been converted to databases whenever the power of queries is needed. In this digital day and age, it’s increasingly rare to find application requirements where a VSAM file is acceptable.
So why would any vendor tools handcuff themselves with VSAM and ignore the efficiency and power of data access provided by DB2? Let me give you a recent example of what can happen when using application development tools that are prisoners of outdated file systems and processes. Here at Compuware we converted from CA Endevor to ISPW for our Source Code Management. Endevor is designed on the limits of VSAM while ISPW is designed to exploit the benefits of DB2. There were times I thought, oh, that’s the back end, how can it matter? But it does. Having now used ISPW versus Endevor, you quickly appreciate the benefits of its modern architecture. You quickly begin to value the improvements in efficiency, performance and power you get with a database. And, you quickly come to the conclusion, why did I let myself fall into the day-to-day trap of tolerating the loss of productivity from a Source Code Management that is a prisoner of the past?
Why not take a look at Compuware’s ISPW with a modern architecture that aligns with how you do business today and not be shackled to the past?
Read my other posts in the “Why Not Use the Best?” blog series
- Balancing Complexity and Flexibility: Why Not Use the Best?
- Exit Strategies: Why Not Use the Best?
- Compile Skeletons: Why Not Use the Best?
- Impact Analysis: Why Not Use the Best?
- Waterfall to Agile SCM Conversion: Why Not Use the Best?
Latest posts by Mark Schettenhelm (see all)
- Planning Better for Failure: How Mainframe Error Messages Impact CX - December 12, 2017
- What Makes ISPF So Scary? Five Reasons to Banish the ‘Green Screen’ - October 31, 2017
- Ten Cross-platform and Mainframe DevOps Tools You Need Today - August 7, 2017