On Jan 15, 2008, at 9:12 AM, Mark Zelden wrote:
I should know better than to respond to one of your posts... but I
already did.
This will be my last response to you on this subject. Sometimes I
find it
hard to
believe you were actually a sysprog.
On Mon, 14 Jan 2008 23:23:37 -0600, Ed Gould
<[EMAIL PROTECTED]> wrote:
Mark, I dislike to disagree with you but here is just (one) of the
time consuming issues I have run into with accepting PTFS. Maybe its
time to go PDSE with them (as much as I dislike it). But more often
than not (especially with product) that the dlib needs to have more
directory blocks than it has. You must manually increase them and
then restart the accept.
Eh? Unless the apply has added elements there should be no reason
to increase directory blocks. That does happen (more so in the past),
but there is usually holddata to let you know the space requirement
changes (at least there should be). If you read the holddata for
APPLY (which is critical), then you can increase the dlib space /
dir at
that point. At least that is what I do. Either way... it's
still a poor
excuse
not to run ACCEPT.
I have never seen a hold like you refer to. Is this new? In the
install docs (which I do not see usually) it might be documented but
not a ++HOLD
I always read ALL holddata as I have been burnt by it in the past.
You also *MUST* look at the listing for
every little non zero return code. Some times 4 is OK and sometimes
its not . In any case it is time consuming. The last thing that I run
into quite a bit is any assemblies that are done must be triple
checked to make sure the correct macro's are picked up. I sort of
wish SMPe would use an alternate set for syslib for accepts.
You do have to look at output. I guess that does mean doing some
of that
four letter word that starts with "W". But honestly, I can't remember
the last time I ran into an RC4 not being ok on ACCEPT.
How would the macros get picked up? Unless you have you SYSLIB
concatenation wrong. Assemblies can happen during accept.. but most
products / maintenance is not packaged that way these days.
Again I have been burned because an accept got a RC 4 (one of two
reason module or assemblies) It's been a while but IIRC SDSF (for one
and maybe JES2 its been awhile on that one) I have also run into
issues (partly my fault but also partly IBM's fault) for not telling
about a macro library needs to be added to the syslib concatenation
There tends to be new products in a servpac that need to be added in
either the DDDEFS or the syslib concatenation that are frankly not
well documented, IMO. If you do this all day long you eventually get
used to it but the typical sysprog might do 2 servpacs a year and
there tends to be a lot of info that is stuffed down your gullet
during the process and this is one of them that is either glossed or
not gone over in specifics (at least the last time I looked). They
may have added the info but not that I saw.
2. The proverbial it worked last year before you put the
maintenance
on just go back the point and run my job.
?? Accept doesn't affect the running system / tgt libs.
I guess I didn't put it distinctly enough. I know it does NOT affect
TGT libraries. But I was trying to say (and apparently
unsuccessfully) it does not work on the CURRENT system. In order to
make it work the manager tells you you *MUST* back off the apply (for
the modules not all) it can get dicey telling a manager that you
can't go back because a fix has been accepted, especially if the job
is extremely important. If you start talking about a separate LPAR
etc they go through the roof what they want is results not excuses
and trying to tell them it can't be done is like nailing a coffin
shut and your inside it. Managers don't like "no" and no amount of
excuse(s) is/are acceptable. The PC world can get away with it we
can't and don't you dare even bring up the PC world issue either
(they are gods gift to corporations).
Which is why you don't ACCEPT until after you have been running on
the current set (or copy of) target libraries for some period of time.
That period of time depends on the product, shop, personal preference
as to when you feel "comfortable" or just prior to the next APPLY run.
The point is... you should do it!! I guess some of those sysprogs
I mentioned
in my last post that live by "don't ever accept" learned it from you.
BTW, there is such a thing as backups. If you back up your
target libs (or copies) even if you don't have an SMP/E environment
to RESTORE a PTF that causes you grief, you can still restore a backup
copy of the library. Also, for "MVS", I often clone the DLIB zone
along with
the target zone but admit I haven't done that at this shop (5 years
now)
but haven't run into a problem because of that either. For other
products (ISV) there are usually installation standards that have the
install set of libraries all under 1 or 2 HLQs (some shops use a
different
HLQ for the SMP/E related data sets from the TGT/DLIBs). I always
run a backup to tape by HLQ prior to maintenance cycles.
Because of politics of the company I worked for there was always a
need for the possibilities to go back. As I said before management
were extremely cheap and no excuses were allowed. I did take backups
before/after each process but again keeping the backups became a
political hassle and it was a no win situation. None of the other
products that we had were as complex as IBM and the number of
libraries involved were in the hundreds. We kept the system libraries
as separate as possible from the OEM libraries. We also did not allow
release dependent OEM products on our system so that kept the number
of libraries down to an acceptable level. We had a simple naming
convention and the explanation was kept simple just for that reason.
I am sorry you do not like discussing things but there is your
reality and there is my reality and I had to work in mine.
Its like working for a KING and telling him he has no clothes, if you
do your dead and if you don't your dead. Pick the lesser of two evils.
Enough of this discussion.
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
