>Don't you mean "that's my main objection to the way a particular vendor has implemented his keys"?
Many more than one vendor! >I understand that your experience with keys has been less than ideal. But, >there are vendors out there who design keys so that: Only two (soon to be three), so far. >a) A warning message is displayed long before a key expires. Not many, in my experience. >b) A new key is sent to you long before a key expires. Since when? We've always had to ask! Even SYNCSORT. >c) The keys can be entered in a flat file (i.e. nothing to >compile/link/refresh etc). Only one vendor, so far. And, we are only in the evaluation phase, so it's not in production, yet. >d) Multiple keys can be stored so that new keys can be entered way ahead of >time. None of our vendors; including the one we are evaluating. >It takes 2 minutes to enter a key in a flat file. It's not a big deal. Have you ever heard of the large bureacracy called 'Change Control'? The most ironic aspect of IT. The number one responsibility of C/C is to slow down the rate of change. The number one task of IT is to facilitate change. >In an ideal world, it would be nice not to bother with keys. This analagy is weak and irrelevant to the discussion at hand. Computers are not garages. Software products are not cars! - Too busy driving to stop for gas! ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
