Dave Salt wrote:
At the risk of being flamed (both for agreeing with what Radoslaw wrote above and also for mentioning a product I'm involved with), I have to say that SimpList works the same way. It checks dependencies at runtime, and to me this offers many advantages over using SMP/E.
These are by no means mutually exclusive functions. Many SMP/E-installed products check system dependencies dynamically at run time.
SMP/E offers organization. It's fairly simple to use, it's a standard, and available in every shop. It *can* be used to check for cross-product interdependencies. But, that is one of its lesser used functions.
SMP/E's main purpose is to install products and manage their maintenance in the form of PTFs. (What fixes do I have? What fixes do I need? If a fix doesn't work, back it off!) It provides a standard way for developers to communicate important information to the person maintaining the product (via HOLDs) such as doc updates, post-APPLY actions, restart instructions, etc. Error HOLDs can prevent erroneous fixes from being installed in the field (we all have them from time to time), etc. And, customers can now even RECEIVE new maintenance over the Internet while they sleep!
I just finished packaging a small product getting ready to go out the door this quarter. SMP/E was used without a second thought. Took about 1/2 a day to put most of it together. (Naturally, I sped things up by "borrowing" existing definitions from an already-established product with a good SMP/E track record.)
In doing so, I observed that the effort required to define a new product to SMP/E is a function of the size and complexity of the product being packaged. A small, simple product: yields a small, simple setup -- not "overkill". It's only slightly more work than tailoring all of the JCL and instructions for a non-SMP/E install.
I've defined products to PC-based installers as well. Believe me, they're NO easier to work with! The analog to not using SMP/E in the PC world is to deliver your product as a directory you unzip and then use "as is" or only after putting it on the PATH or copying a DLL here or an INI file there. Note that much PC-based freeware comes packaged that way. Why? Generating SETUP.EXE requires additional time and programmer competence.
IMHO, the real issue isn't how difficult it is to set up an SMP/E install for a product. But, rather how steep the learning curve appears to be for the developer considering doing it. If he or she has never packaged with SMP/E, it might seem like daunting "black art". There is a lot of reading and some experimentation involved to really understand and see for yourself what's happening. The first product released, with no existing definitions to copy from, will obviously take longer. Fortunately, I can say with confidence that the same holds true for every worthwhile infrastructure you develop now and in the future...
-- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ ---------------------------------------------------------------------- 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
