Re: (your name here) is out of the office.
Unfortunately, I think this is down to the individuals concerned that want everyone to know that they are out of the Office. Don't they have Blackberries so that they can always be in the office? Colin 2008/7/29 Howard Brazee [EMAIL PROTECTED] I wonder if there's a way this listserver could filter these out of the office messages we keep getting. -- 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
Re: Master Start Pendings
John Benik wrote: Every morning we run a job that does an STK CDS backup. About 1/2 hour after the job starts we start seeing master start pendings on the volume which holds the primary CDS. Once the backup step starts about 45 minutes after the first start pending we then see a reserve on that volume while that step runs, but it only lasts for about 2 - 3 minutes. Once the step is done the start pendings and the reserve is gone. On occasion we have seen other times that there are start pendings but the morning one does happen everyday. -- 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 There wasn't really a question here - just stating a matter of fact. We had a similar scenario with a production and test LPAR on the same server and not in the same Syslplex. Our problem was stopping the Ops from calling us, (out of hours), when some housekeeping job or other ran while making sure that they called us if the MASTER start pending message was issued for another volume. We took a two pronged approach for this normal situation, (after all we are talking STK software here - no flames perleese!). 1. Told Ops to ignore this alert unless it occurred multiple times for the same device. Multiple being more than three times, doh! 2. Used automation to suppress the message for the specific device during the time frame when the job on the test system should have been running. Sorted! Colin -- 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
Re: Master Start Pendings
John Benik wrote: That's already done. So only STK work will get the reserve?? That's a good thing to know. But then we have the master start pending issue... I'm looking into that right now. -- 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 A couple of auxiliary memory cells kicked in on a Friday afternoon! The housekeeping was when DFHSM on the test system was backing up the volume where its RMF Monitor 3 files happened to have been allocated. Production RMF started to moan about slow response time to this volume because it was on-line to the production system. The Master Start pending message is not an issue in itself, unless the same device gets the message lots of times /and /it is affecting processing on a production system. We risked that it was very unlikely that anything on the affected volume could have any impact on production and surely something else would wake up the Ops if there really, really was something wrong that warranted calling out the lazy sleepy sysprog, i.e. me! All I meant was that for the time and effort to fire an e-mail at Ops and two minutes to write a bit of automation, we saved the OOH call misery for their helpdesk and our helpdesk and the standby person and the real misery of having to deal with the associated trouble tickets when there never was a problem in the first place! Colin -- 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
Re: restricting use of iebupdte
David Andrews wrote: On Wed, 2006-12-06 at 09:02 -0600, Randy Harris wrote: Does anyone know how IEBUPDTE can be locked down with the use of RACF? I have certain users that I do not want to allow to use IEBUPDTE. I cannot imagine why you would want to do this, or what you intend to accomplish... but your business and all that. Knock yourself out. But I will suggest that you simply tell those users not to use IEBUPDTE -- then fire the first one who does. (After Lot's wife was turned to a pillar of salt, nobody else looked back, right?) This is a management issue. You are going through significant effort to misuse the security system to plug an imaginary hole that can be easily circumvented. Just tell your employees where the line is, then audit them. Better still - tell the auditors. Let them do the dirty work. Encourage their paranoia and get them to tell the culprits that using restricted programs is a career limiting option. Colin, the grumpy old Sysprog. -- 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
Re: What do you name your Operational Datasets?
Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Horein, Steve (HAR-ORL) Thanks to all that have voiced their opinion! I certainly hope the voice of experience is heard (and is needed to be heard!) for a GREAT while longer. When I start getting a little longer in the tooth, I'll be able to contribute my voice as well. It seems I only have questions for now. I've been at this for 23+ years now, and still have more questions than answers. -jc- -- 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 Sometimes there is no correct answer - we all operate under our own set of constraints. Hopefully as we all get older there will be an ongoing supply of people who can supply experience so that the people who are asking the questions can decide, i.e. judge, for themselves what is the best way forward in their particular situation. Colin -- 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
