Sun/STK Holddata No Longer Included With Cumulative Maintenance
Mark Zelden
For those of you that use Sun/STK mainframe software and download
maintenance from SunSolve, this post is for you.
This morning I downloaded current maintenance from SunSolve for five
Sun/STK products. The process is similar to the way it has been for
many years going back to the STK CRC web site. However, I noticed
that the cumulative maintenance zip files did not include a HOLDDATA
file as they did in the past. I had to go out for each product and do
separate searches for HOLDDATA (the "pre-canned search criteria"
links from the CRC-like Sun web page did not work for this) and
download them. One of the HOLDDATA files was from 2008, so I wasn't
even sure it was current.
I opened a case with Sun/STK support and after they spoke with a
colleague they confirmed that I wasn't doing anything wrong and this
was a change that Sun/STK engineering made. When I asked why
they would do such a ridiculous thing (which the support person agreed
with me about), the answer was "well, the HOLDDATA doesn't change
that often so they are no longer including it".
What?? Obviously the engineering group doesn't understand SMP/E nor what
the word "cumulative" means. To me, this is just an accident waiting to
happen as someone will miss HOLDDATA and install a PE PTF.
I left the issue open and they are going to forward it to back line support,
but I also plan on bringing up this issue with our Sun/STK rep. If you
use SunSolve for maintenance and agree with me, then the more complaints
Sun/STK gets, the more likely they are to change the process back to the
way it used to be.
Thanks for listening.
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Paul Gilmartin
we try to be responsive to customers.
On Tue, 5 Jan 2010 11:24:41 -0600, Mark Zelden wrote:
>
>I opened a case with Sun/STK support and after they spoke with a
>colleague they confirmed that I wasn't doing anything wrong and this
>was a change that Sun/STK engineering made. When I asked why
>they would do such a ridiculous thing (which the support person agreed
>with me about), the answer was "well, the HOLDDATA doesn't change
>that often so they are no longer including it".
>
It's only a little more complicated than that. Correct that the
HOLDDATA change less frequently than the PTF bodies, but the
concerns were:
o Issuing HOLDDATA is not syncronized with our test cycle which
drives our cumulative maintenance releases. We'd like our
customers to RECEIVE the freshest HOLDDATA before APPLYING
any PTFs (residue of the ancient "Phone for bucket" tradition.)
o It's our understanding that many customers age corrective
service on the shelf before APPLYing -- let their peers be
early adopters. Such customers would need to download HOLDDATA
separately after ageing the PTFs (unless they were naive enough
to be satisfied with stale HOLDDATA).
It would help the first of these cases, but not the second, if
we reissued the cumulative maintenance whenever there were new
HOLDDATA (infrequently, as you note, but the churning is still
unpleasant).
I've discussed this earlier with my manager; I have another idea,
perhaps more, that I haven't discussed with him. If you don't
have his contact info, email me off-list.
I'd welcome input from other customers, either here or privately.
Don't confine yourself narrowly to the issue Mark raised; use
your imagination. (Like any vendor, we promise nothing but to
listen.)
Thanks,
gil
Mark Zelden
>I rarely discuss my employer here (see my neutral sig), but
>we try to be responsive to customers.
>
>On Tue, 5 Jan 2010 11:24:41 -0600, Mark Zelden wrote:
>>
>>I opened a case with Sun/STK support and after they spoke with a
>>colleague they confirmed that I wasn't doing anything wrong and this
>>was a change that Sun/STK engineering made. When I asked why
>>they would do such a ridiculous thing (which the support person agreed
>>with me about), the answer was "well, the HOLDDATA doesn't change
>>that often so they are no longer including it".
>>
>It's only a little more complicated than that. Correct that the
>HOLDDATA change less frequently than the PTF bodies, but the
>concerns were:
>
>o Issuing HOLDDATA is not syncronized with our test cycle which
> drives our cumulative maintenance releases. We'd like our
> customers to RECEIVE the freshest HOLDDATA before APPLYING
> any PTFs (residue of the ancient "Phone for bucket" tradition.)
>
A good reason to also maintain the separate HOLDDATA download. Those
of us with good SMP/E maintenance habits download current
HOLDDATA before APPLY if the maintenance has aged (i.e., already
received and sitting in the global zone / SMPPTS).
>o It's our understanding that many customers age corrective
> service on the shelf before APPLYing -- let their peers be
> early adopters. Such customers would need to download HOLDDATA
> separately after ageing the PTFs (unless they were naive enough
> to be satisfied with stale HOLDDATA).
>
See above. Exactly what good citizens do with IBM maintenance. But
IBM always includes current HOLDDATA with their z/OS maintenance
regardless - so if you even order a single PTF, you get the current
holddata with it.
>It would help the first of these cases, but not the second, if
>we reissued the cumulative maintenance whenever there were new
>HOLDDATA (infrequently, as you note, but the churning is still
>unpleasant).
>
It would. How often is it re-issued now? Every time a new HIPER comes
out or on a scheduled basis? I started downloads this morning due to
some HIPERs that came out in mid December. I haven't looked if those
most current HIPERs were part of the files are not. If not, then I would
ask, if you don't regenerate the cum files for new HIPERs, what is the
difference if you don't do it for new HOLDDATA. If you do, and it changes
infrequently as you indicated, how much extra work is it to regenerate the
cum files if the HOLDDATA does change? Either way not including it
at all with the cumulative maintenance seems like a bad idea IMHO.
>I've discussed this earlier with my manager; I have another idea,
>perhaps more, that I haven't discussed with him. If you don't
>have his contact info, email me off-list.
>
I don't. But since I've already raised this issue with local support,
maybe I should wait before contacting him/her directly. If you want to
forward my information, he/she can contact me offline also
to discuss this (as you can also).
>I'd welcome input from other customers, either here or privately.
>Don't confine yourself narrowly to the issue Mark raised; use
>your imagination. (Like any vendor, we promise nothing but to
>listen.)
>
It would have been nice to notify the customer prior to making a change
like this or perhaps even soliciting feedback to see what the customer
base though of the idea.
Regards,
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
Jakubek, Jan
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
It's only a little more complicated than that. Correct that the
HOLDDATA change less frequently than the PTF bodies, but the concerns
were:
o Issuing HOLDDATA is not syncronized with our test cycle which
drives our cumulative maintenance releases. We'd like our
customers to RECEIVE the freshest HOLDDATA before APPLYING
any PTFs (residue of the ancient "Phone for bucket" tradition.)
o It's our understanding that many customers age corrective
service on the shelf before APPLYing -- let their peers be
early adopters. Such customers would need to download HOLDDATA
separately after ageing the PTFs (unless they were naive enough
to be satisfied with stale HOLDDATA).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
I'd suggest adopting IBM z/OS software gold standard to address this:
- Merge all z/OS platform software HOLDDATA into a single file.
- Allow HOLDDATA retrieval via FTP "anonymous" user (to bypass manual
retrieval).
Hth...
Gibney, Dave
> From: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] On
> Behalf Of Jakubek, Jan
> Sent: Tuesday, January 05, 2010 10:29 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: Sun/STK Holddata No Longer Included With Cumulative
> Maintenance
>
> gil wrote:
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> It's only a little more complicated than that. Correct that the
> HOLDDATA change less frequently than the PTF bodies, but the concerns
> were:
>
> o Issuing HOLDDATA is not syncronized with our test cycle which
> drives our cumulative maintenance releases. We'd like our
> customers to RECEIVE the freshest HOLDDATA before APPLYING
> any PTFs (residue of the ancient "Phone for bucket" tradition.)
>
> o It's our understanding that many customers age corrective
> service on the shelf before APPLYing -- let their peers be
> early adopters. Such customers would need to download HOLDDATA
> separately after ageing the PTFs (unless they were naive enough
> to be satisfied with stale HOLDDATA)
I run a:
RECEIVE SYSMODS HOLDDATA
ORDER(ORDERSERVER(ORDSRVR)
CONTENT(ALL))
DELETEPKG.
Almost every day. I would every day, but I haven't automated the
scheduling of this yet.
My "aging" is to do a selective APPLY by RSU + HIPER,etc.
How hard is it to always include whatever HOLDDATA there is?
Dave Gibney
Information Technology Services
Washington State University
Shmuel Metz , Seymour J.
at 11:54 AM, Paul Gilmartin <PaulGB...@AIM.COM> said:
>o Issuing HOLDDATA is not syncronized with our test cycle which
> drives our cumulative maintenance releases.
Do you build your cum service with the then current HOLDDATA? If not, why
not.
>o It's our understanding that many customers age corrective
> service on the shelf before APPLYing -- let their peers be
> early adopters. Such customers would need to download HOLDDATA
> separately after ageing the PTFs (unless they were naive enough
> to be satisfied with stale HOLDDATA).
Protect your customers, but don't hobble them.
>It would help the first of these cases, but not the second, if we
>reissued the cumulative maintenance whenever there were new HOLDDATA
I wouldn't expect, or want that, although there might be a case for
rebuilding the cum service when a fix for a PE became available.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)