On Jan 4, 2008, at 7:42 PM, R.S. wrote:
Ed Gould wrote:
Radoslaw:
Because????? I can recall more than a few times that a sysprog has
left
the company (many reasons) and no one can tell you what level
anything is at. All the vendors who send out object, source or
load or whatever
there is no way to determine (easily) what level the product is at.
I can recall a situation that sysprog (bad one) has cloned several
SMP/E environments and nobody knew (including him!) which one is
the correct one. I met it at leas three times.
In case of components installed from 'setup.exe' on PC *or* on
mainframe side (I described such example: TSA), SMP/E delivery is
simply pointless. The same effect can be achieved with naming a
package 'setup_ver3.21.exe'.
And your point is? once you get into ifreqs or coreqs you *BETTER*
have damn good checking internally and logic for handling different
levels of PTF's (especially) when it comes to IOS. The IOS people do
a good job updating all the modules in a PTF. Its been a few years
but I don't recall of a PTF going PE because IOS forgot to update
another module (ie forgot to include it in the original PTF). IOS
record is not perfect but it is certainly better than say DFSMS (I
don't want to say they are bad or anything just that just remember
the VSAM super PTF tapes).
Caution: I still agree SMP/E is good method to check all the
dependencies to other component levels. However:
1. It is good, because the only one.
2. When product does not have too much dependencies, it is simply
irrelevant to use SMP/E or other method. In fact, many products are
installed in completely separate CSI. In such case *no
dependencies* are checked. But we still have "easy to use" and
"very convenient" tool. I hope you feel the irony. <g>
BTW: 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.
FDR does this as well and damn well better than any other MF product
(IMO). It takes a *LOT* of knowledge to do so. This is NOT trivial to
do (either).
AS I said privately in another email IOS is *NOT* a place for the
feint of heart to do stuff like this. IOS people have done a pretty
good job in their PTF's (IMO) Most (all?) IOS is OCO and trying to
reverse engineer code would not be pretty, IMO.
Problem resolution time goes almost straight up and the lost of
productivity is substantial as all the time is spent trying to get
your hands around what the problem is. That is one of the main
benefits with SMPe , a look at one screen in the smp/e dialog
manager and you can tell exactly what level any product that is
installed with SMPe.
Exactly the same information can be obtained using other method.
Lack of SMP/E does not mean there's absolutely nothing instead.
Well if you are talking about one or two modules *MAYBE* but when it
starts getting to be more than 5 AND we are talking separate
libraries it can (and does) get to be complicated. Especially if
different levels go into different libraries. There is a module
mapping facility put out by a vendor (whose name escapes me at the
moment) that work well and you can tell at a glance what csects and
IDR information is contained in the LMOD. But again when you get into
more than one LMOD it can get semi complicated also if you are
looking at a dump there has to be a PTF (APAR) identifier in the
module so you can verify what is in memory is the one that you put
in. Another side issue is how you handle fix distribution. If you
send out complete replacement its less complicated (usually). If its
piece meal then you get into issues of relinking by hand and believe
me if a mistake is going to happen it will happen there *OR* if you
send out zaps mistakes will happen easily. I can attest to that after
hand coding zaps from SYNCSORT for 5+ years.
I have basically turned down any product that is not smp/e
maintainable and installable.
I had to install products which are bought by the company. Nobody
asked me if I like SMP/E. I cannot complain on installation method,
colour of the box, fonts used, etc. Does the product fill business
requirements - this is what I'm asked. Quality is one of the
parameters, but lack of SMP/E does not necessarily mean poor quality.
Then you aren't talking to the right people and need to get that
corrected asap. The boss should be at the forfront of getting
involved before the product arrives at the door step. He should be in
the selection committee and making that a deal stopper before you see
it.
The product in order to be sellable must be in SMP/e format. I
think you will find that it will be a requirement for most
installations.
I have *never* met such requirement. I would call it SILLY. I mean it.
You call it silly fine but you have to live with the product and who
ever comes after you. You may stay in the same company in you part of
the world forever but here in the states turn over is high and I sure
don't want to come into a shop that only an ex (or dead) sysprog
knows where all the bodies are buried. If everything is reasonably
documented ie SMPe installable then the only issue is documentation
and there is no good answer to that. The vendors doc should have been
screened by a knowledgeable (tech savy) person. The vendor can put
out a pretty plastic covered it is nothing but eye candy. A real
sysprog would pick it up and read it (or at least peruse it) and tell
you in a few minutes if the product is acceptable or not. If somebody
isn't doing that before the product is bought then someone is not
doing their job.
Yes I know there is a(re) cheap vendor(s) out there that sells
their stuff with postcards. But you get what you pay for, is my
opinion.
<irony>
Did you hear about CBT ?
Yep and refuse to touch anything on it.
</irony>
Vast majority of CBT stuff is not SMP/E installable. Does it mean
it is piece of junk ?
See above.
--
Radoslaw Skorupka
Lodz, Poland
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego
Rejestru Sdowego, nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA
(w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj
warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa
XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe
ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym
kapitale zakadowym bd w caoci opacone.
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
