Specialized IT Services focused on Data Management | Speak with Us
Author: Craig Mullins
VSAM is used "under the covers" of every DB2 for z/OS page set. VSAM is also used as the storage mechanism by some IMS databases. It is also used to store a lot of mainframe data outside the control of any DBMS. But there is a lot of confusion about what exactly VSAM is, how it can be used, and how it differs from a DBMS.
I frequently get e-mails with DB2 questions and I plan to start posting answers to some of the more common ones up here. One issue that comes up a lot is dealing with locking issues. Usually it is posed by someone who is experiencing timeouts in an online environment and they want to know how to minimize them. Here is some guidance.
I've written about this subject before, but I think it is important enough to merit another go-round. First of all, before I go any further, let's first define what I mean by a “black box.” If I plan to recommend that you prohibit them we better both understand what it is we are talking about proscribing.
Data compression for non-mainframe DB2 is quite a bit different than it is for DB2 for z/OS. In mainframe DB2, specifying COMPRESS YES on the CREATE TABLESPACE statement will cause DB2 to implement Ziv-Lempel compression for the table space in question. Data is compressed upon entry to the database and decompressed when it is read.
A continuing, lingering perception that the mainframe is dead continues on in some parts of the IT industry. It seems that we constantly hear that big IT shops are getting rid of their mainframes. But rarely do we ever hear about it after the fact. No, it is usually reported right when someone thinks that it is a good idea.
Database performance problems are not caused by magic. Indeed, all performance problems are always caused by change. That statement flies in the face of what I normally say, which is “Almost never say always or never”… but in this case, it is true.