On Jan 5, 2008, at 12:58 AM, shai hess wrote:
Dave Salt:
Totally agree with you.
Imagine how easy it to return to your old load library in case of
error and
not pray that SMP/E with the APPLY/RESTORE/ACCEPT/RECEIVE/REJECT
will work
fine for you.
As I said "SMP/E and why not" for some cases only.
Thanks,
Shai
On 1/4/08, Dave Salt <[EMAIL PROTECTED]> wrote:
From: [EMAIL PROTECTED]> I vaguely remember one of ISVs
said on the IBM-MAIN, that his > product (zDebug AFAIR) does not
need to
check dependencies in SMP/E, > because all the dependencies which
have to be
checked are checked > *during runtime*. That method is *much
better* than
SMP/E. It can be > hard to implement and not always applicable,
but it
checks *reality*, > not some entries in KSDS.
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.
Coding a product to check dependencies at runtime requires extra
effort,
but it makes the product much easier to install as SMP/E isn't
required.
Application programmers and even non-technical end users have
installed
SimpList in a matter of minutes. In addition, companies are able
to upgrade
to new operating systems or fall back to old ones or run with
mixed systems
(etc) with no concern as to which version of SimpList is being used.
I don't have anything against SMP/E and I agree there are
situations where
SMP/E makes a whole lot of sense. I just don't think it's true to
say that
SMP/E always makes sense in every situation.
Dave Salt
See the new SimpList(tm) rollover image at:
http://www.mackinney.com/products/SIM/simplist.htm
I find it interesting that two not so independent vendors agree that
SMP/e should not be used. That is a little bit self serving, IMO. In
my opinion you should be neutral and NOT expressing any opinion. (it
OK to have one just don't express it on here).
A good company lets the customers decide and goes with a majority.
The current Major software vendors all use SMP/e(it took years of
battling to get them that way THERE is a reason). The few that don't
are not worth the effort to even look at. Its one thing to have a
clist or rexx but when it comes to programming that runs in key 8 non-
authorized (maybe) anything else must be SMPE/e installable and apars
and ptfs must be in SMP/e format. I am not the only person that has
turned down products because they are not SMP/e compatible there are
other people that do so as well. It has a lot to do with shop size
the smaller you get the less "formal" products have to be. If you
set the product for a 2 person sysprog shop you can probably get away
without SMP/e, but if you aim for large you should put it in SMP/e
format, IMO.
Remember if you aim for small shop MS is out there waiting to gobble
the MF away and you will probably loose the customer to MS. You might
get an initial sale but will loose it in the near future.
Ed
----------------------------------------------------------------------
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
