Re: Drop hardware maintenance contract
My 0.02$: If you decide to drop service contract then you should look for alternative service provider. IBM is not monopolist in servicing IBM hardware. The same apply to HDS, EMC, STK. Sometimes it is worth to purchase spare equipment in advance. If your tape drive fails you can simply swap the device. Fast and inexpensive. Failed device can be fixed or another device is to be bought. Last but not least: spare devices should be cheaper than service fee. z/800 is available for peanuts, like 3590 drives. Such approach requires more attention from user, but it can be *much* cheaper. -- 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 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- 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: Drop hardware maintenance contract
Timothy Sipples wrote: And, as someone already alluded to, off maintenance means you're last in the queue. So, for example, if there's an earthquake -- I've heard they happen in California -- that shakes some parts silly, you'll be dead last in line for repair. Which is entirely fair, of course, but something to be aware of. While I agree that service contract is definitely better for good sleep, the argument above is miss. I'm pretty sure that in case of real earthquake no service provider will be able to meet fix times. BTW: I vaguely remain that earthaquakes are valid excuses for SLA. Last but not least: sometimes customers do not believe in service fix times, but treat the contract as kind of insurance, defense, I took care excuse. I'm aware of contracts in Poland with fix time 4h, when travel time of CE is at least 2,5h... Both parties (provider and customer) are aware of that. I'm also aware of fix time 24h contract and real fix time 9 months g. IBM 3494. -- 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 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- 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
Anyone using TSO/E Exit IKJEFLN2 from FILE 183 of CBT-Tape?
All, subject says it all: Is anyone using GSF's TSO/E Exit IKJEFLN2 that is availabel from CBT-Tape File 183? Is it safe to install it (-- somehow stable)? I don't care if it sometimes doesn't work, but it should not crash my system Bye, Michael -- 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: z/Linux
-Original Message- From: IBM Mainframe Discussion List On Behalf Of gsg I've been hearing alot about z/Linux and am wondering what are some good references for learning. Basically, I'm looking for a z/Linux for dummies book. Any help will be greatly appreciated. Better than a book: [EMAIL PROTECTED] Send your subscription message to [EMAIL PROTECTED]. -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
Re: Anyone using TSO/E Exit IKJEFLN2 from FILE 183 of CBT-Tape?
Michael, In 2000, I wrote IKJEFLN2 which worked fine until 2002 when it started to have serious RACF problems with OPERCMDS, due to a default processing option in z/OS. This problem was discussed several times on IBM-MAIN. In 2003, I wrote a commercial version of IKJEFLN2 which bypasses the RACF problem and allows TSO users to reconnect to their session or cancel it; it's described here: http://gsf-soft.com/Products/IKJEFLN2.shtml You can test the IKJEFLN2 product using a load-module which will work until the end of the year and is available here: http://gsf-soft.com/Download/08444-ikjefln2.xmit.zip Installation info: http://gsf-soft.com/Documents/RECEIVE-XMIT.shtml If you like what the IKJEFLN2 product does for you, your company can buy a license which is very inexpensive. Just let me know. -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ On Tuesday 09 December 2008 13:09, Michael Knigge wrote: All, subject says it all: Is anyone using GSF's TSO/E Exit IKJEFLN2 that is availabel from CBT-Tape File 183? Is it safe to install it (-- somehow stable)? I don't care if it sometimes doesn't work, but it should not crash my system Bye, Michael -- 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: Health Checker questions
I can activate a check that was deactivated as well as I can undelete check that was deleted. That is not necessarily true. Peter Relson z/OS Core Technology Design -- 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: lbdsoftware
I don't think there is any problem. They are probably being blocked by their companys firewall. I have the same issue...can't get to your web site from behind company firewall, but I can get to it fine from in front of it. -- 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: /*PRIORITY change without JCL change
Try (watch the wrap): http://www-03.ibm.com/servers/resources/servers_eserver_zseries_zos_wlm_ pdf_cmgbatch_pdf_wlm_goal_based_initiator_management.pdf http://www-03.ibm.com/servers/resources/servers_eserver_zseries_zos_wlm_ pdf_wlminits_pdf_wlminitsjm.pdf and http://www-03.ibm.com/servers/resources/servers_eserver_zseries_zos_wlm_ pdf_velocity_pdf_velocity.pdf for more detail. The JES2 classification rules should not classify work into common Service Classes between WLM Managed and JES managed inits. An appropriately aggressive goal may allow you to do what you want to do, but since WLM managed inits are sensitive to non-WLM managed work, the goal may need to be highly aggressive in order to accomplish your purpose. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Mattson Sent: Monday, December 08, 2008 8:40 PM To: IBM-MAIN@bama.ua.edu Subject: Re: /*PRIORITY change without JCL change I have been doing RTFM on Jes Init Tune Guide and find myself back in a quandry. My original purpose was to get an ever changing list of, overnight batch, critical path,jobs priority access to initiators without changing their JCL manually. But here is what I read in the Guide about WLM inits Batch jobs that are part of a critical path, such as the overnight ?batch window? should remain in JES managed job classes. Alignment of initiator mode and service classes: All jobs with the same service class should be managed by the same type of initiation. For example, if job classes A and B are both assigned to the HOTBATCH service class, and JOBCLASS(A) is MODE=WLM, while JOBCLASS(B) is MODE=JES, workload management will have a very difficult time managing the goals of the HOTBATCH service class without managing class B jobs. Queue delay measurements: If you have large job execution queues, the queue delay can dominate the response time or velocity. This may cause the system to not address other delays because it would not significantly affect the performance index (PI). Response time does not include TYPRUN=HOLD or JCLHOLD delays, but does include the following: Operational delays (jobs or job class held by operator command) System or resource affinity delay Scheduling delay because of class limits, duplicate jobnames Time waiting for an Initiator What I currently have is a lot of jobs waiting for a class Q initiator, and I want to get my loved ones to the init first. It looks like using WLM to get my priority jobs to the initiator faster may totally mess up WLM's calculations because it will start measuring all of that Waiting for Init Time. I think this puts me back at where I started. Perhaps what I need is an Exit which can read a list of Jobs and raise their Input Queue Priority. Can anyone suggest the best exit for this? Brian Westerman [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 12/03/2008 11:31 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Expire Date: 12/08/2010 To IBM-MAIN@bama.ua.edu cc Subject Re: /*PRIORITY change without JCL change You could write it as either a JES input exit (or text) or an SMF exit, either will work fine. There are several samples on the CBT tape that you can use as a start, but none that I'm aware of that do exactly what you want. Why not use JES's WLM options instead? Brian -- 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 -- 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: Tape Space Issue
Perhaps I am confused. The output dataset is E18823.TDB.SYSPROG.SYMD.CAVHPROT.CLUS The VSAM data set that is to be exported is TDB.SYSPROG.SYMD.CAVHPROT.CLUS The error message indicates no space for IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET TDB.SYSPROG.SYMD.CAVHPROT.CLUS Which matches the EXPORT statement and not the //RECEIVE JCL statement. Since his output dataset HLQ is E18823 I do not think that the allocation error is on the RECEIVE DD statement. That is unless I am missing something. It looks to me that the EXPORT entryname is looking for a NEW dataset and that the cluster does not exist. So why would an EXPORT entryname get an IGD17045I error message on the entryname that is trying to be exported? Would the IGD17045I message flag an input file when the error is on the outfile dataset? Lizette Check your SMS parameters. Is this output dataset being converted to a DASD file by SMS ?? Howard Rifkind wrote: Hello, Can anyone tell me what I'm missing on the JCL below. Job keeps asking for a space parameter. //STEP1 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //RECEIVE DD DSNAME=E18823.TDB.SYSPROG.SYMD.CAVHPROT.CLUS, //DISP=(NEW,CATLG,DELETE), //UNIT=HCRT, //VOL=(,RETAIN,,1), //LABEL=(1,SL), //DCB=(BLKSIZE=20400,LRECL=2040,RECFM=FB) //SYSIN DD * EXPORT- TDB.SYSPROG.SYMD.CAVHPROT.CLUS - OUTFILE(RECEIVE) - TEMPORARY /* IEF344I E18823X STEP1 RECEIVE - ALLOCATION FAILED DUE TO DATA FACILITY SYSTEM IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET TDB.SYSPROG.SYMD.CAVHPROT.CLUS -- 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: Is there a programmer's list
On Mon, 8 Dec 2008 22:47:08 -, Michael Munro [EMAIL PROTECTED] wrote: Can anyone recommend a list for programming under zOS, preferably for assembler programmers. http://listserv.uga.edu/cgi-bin/wa?SUBED1=asm370A=1 http://www.z390.org/z390_Mainframe_Assemble_Coding_Contest.htm Cheers, Jantje. -- 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
IBM Link Down?
Can anybody get into IBM link? I think it is down. Jerry -- 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: IBM Link Down?
A message was sent out by Mark Fyffe that it is down. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jerry Fuchs Sent: Tuesday, December 09, 2008 9:07 AM To: IBM-MAIN@bama.ua.edu Subject: IBM Link Down? Can anybody get into IBM link? I think it is down. Jerry -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: IBM Link Down?
web ibmlink is down.green screen still working details below. IBM LINK Sev 1 Ticket # :- 37807598 BUSINESS IMPACT: Users are unable to access the IBMLink application via URL www.ibm.com/ibmlink. IBMLink is an application enabling platform which provides common services including authentication through Web Identity and entitlement, to various presales, post sales and business partner applications. Support is engaged and is investigating the issue. Further updates will be provided as changes occur - Original Message - From: Jerry Fuchs [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@bama.ua.edu Sent: Tuesday, December 09, 2008 9:07 AM Subject: IBM Link Down? Can anybody get into IBM link? I think it is down. Jerry -- 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: Drop hardware maintenance contract
And, as someone already alluded to, off maintenance means you're last in the queue. So, for example, if there's an earthquake -- I've heard they happen in California -- that shakes some parts silly, you'll be dead last in line for repair. Which is entirely fair, of course, but something to be aware of. In certain cases you may be able to cover a maintenance gap by turning it into a Disaster Recovery (DR) problem. This assumes of course you have DR, and that it works, and that the DR terms and conditions are appropriate, and, and, etc., etc. As a rough initial guess, start by assuming that your primary data center is destroyed along with all the IT workers inside (and at least half the ones outside, who are busy trying to find out if their relatives are OK), then see what happens in your thought exercise -- or, better yet, in your full dress rehearsal. Yes, do be careful about off maintenance and residual value. The former negatively impacts the latter.) Try to find a good and productive home for the z800. For example, do you have a community college that could conduct vocational training -- and benefit your local economy? (You have at least one at quick check: Sacramento City College. And they have degree programs in Computer Information Sciences.) IBM would be delighted to support that, and such a transfer would be much more rewarding to the city (and far more visionary) than any residual you'd get, especially an off maintenance residual. Think about this as cheap insurance as well. If you ever have to resurrect a program, or a tape, or whatever, your old machine will be nearby over at SCC (but incredibly useful to them), and you can reactivate commercial licensing if need be. You can get more details on the System z Academic Initiative (and contacts) here: http://www.ibm.com/university/scholars/products/zseries Another great option is Sacramento State, which is trying to develop their enterprise computing curriculum. I'm sure Professor Du Zhang would be absolutely thrilled if you would contact him to discuss the possibility of transferring the z800 (and storage and tape) there. Click on Participating Schools, and you can find his e-mail address. Or, better yet, give him a phone call -- he's local! Anyway, this *should* be a relatively easy sell. (I bet the mayor wouldn't mind a newspaper story or two about a city donation to Sacramento State or SCC, to train students for high-tech enterprise computing jobs.) Everybody wins, including especially the city's economy. Am I naive? I sure hope not. Good luck! - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: [EMAIL PROTECTED] -- 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: IBM Link Down?
Yes, a SEV 1 problem is open. (Sigh.) On Tue, 9 Dec 2008, Jerry Fuchs wrote: Can anybody get into IBM link? I think it is down. Jerry -- 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: IBM Link Down?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Jerry Fuchs Can anybody get into IBM link? I think it is down. Unable from Chicago -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
Re: IBM Link Down?
Try http://www-01.ibm.com/support/advsrch.wss?rs=0loc=en_US Gets you most of the S S information (no ETR,) No sign on required. HTH, snip Subject: IBM Link Down? Can anybody get into IBM link? I think it is down. /snip -- 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: IBM Link Down?
Not if you use the green screen option, it's not. Thanks, George Rodriguez Specialist, Systems Programmer Network Technical Services (561) 357-7652 (office) (561) 707-3496 (mobil) School District of Palm Beach County 3348 Forest Hill Blvd. Room B-332 West Palm Beach, FL. 33406-5869 Rated A by the Florida Department of Education 2005, 2006, 2007 2008 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Staller, Allan Sent: Tuesday, December 09, 2008 9:14 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IBM Link Down? Try http://www-01.ibm.com/support/advsrch.wss?rs=0loc=en_US Gets you most of the S S information (no ETR,) No sign on required. HTH, snip Subject: IBM Link Down? Can anybody get into IBM link? I think it is down. /snip -- 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 - Under Florida law, e-mail addresses are public records. If you do not want your e-mail address released in response to a public records request, do not send electronic mail to this entity. Instead, contact this office by phone or in writing. -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Jim Mulder wrote: There is one incorrect thing in the APAR text - VSM development (and as designer and developer for this change, that includes me) has *not* at this time decided to restore the pre-release 1.10 behavior as the default to prevent impact to the unsuspecting program or user. The APAR will create a DIAGxx TRAPS NAME(NameToBeDetermined) which will be documented and, if specified, will cause VSM to revert to the pre-release 1.10 behavior, exactly the same way as the undocumented NUCLABEL ENABLE(IGVGPVTN) mentioned in the APAR description. The lesson here is that, if a change has been observed to cause unexpected surprise wrong behaviors in some IBM components during testing, then similar problems should be expected after deployment. A documented fall-back Chicken Switch should be provided. I think the proposed, documented DIAG TRAP is a great way to go. The reason the change to GETMAIN Behavior in z/OS 1.10 is undocumented is that there is no documentation to change. GETMAIN in z/OS 1.10 continues to behave as documented. All previously documented rules of GETMAIN continue to apply to z/OS 1.10. And, if IBM, ISV, and customer in-house developers would use IgvInitGetmain and IgvInitFreemain on their test/development systems--as we do--nobody would have experienced this issue to begin with. Of course, it's hard to fault someone for not using an undocumented feature. These TRAPs have been around since OS/390 V2R6. They work. Perhaps it's time they were documented, too! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: z10 power problem notification
Sorry, but I just don't see a problem. A fan failed and the machine phoned home. I think you posted that clearly visible red flags were set. A process failed (bad phone number) but a backup process worked. No SLA's were missed. I could be wrong. But I think I was told that when a part is called out, it is ordered automatically and begins its journey even as the on duty CE is paged. If that is so, then no time was lost. My CE tells me that sounding audible alarms every time a problem is noted would drive folks nuts and the email alerts would be thicker than spam because most alerts are transient and not really indicative of anything. Besides, you'd have to expose the family jewels to the corporate LAN cesspool. It would seem to me that the root problem was that the primary notification process was never tested. I think all you have to do is manually drive a test hardware PMR via the HMC and ask the support center to call. Of course, a backup number in the PMR text might be helpful. As critical as the phone home process is, why isn't such testing commonplace? My $0.02 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Skip Robinson Sent: Friday, December 05, 2008 5:05 PM To: IBM-MAIN@bama.ua.edu Subject: Re: z10 power problem notification This is a consolidated reply to those who posted in this thread. To clarify and answer some questions. -- The z10 successfully called home for one failed fan. -- Support Center had a bad phone number for us. Their records have since been corrected. -- Support Center also notified our primary CE, who came in the following morning to find out what was up. -- A replacement part had to be ordered from No. Calif., so final resolution occurred maybe 16 hours after first failure. -- I opened a software question-type ETR because even our CE thought there should have been an MVS message. -- After some research, Level 2 concluded that was no specific message for this event, but see below. -- Level 2 suggested that an automation product like SA could use API to the HMC. An exercise left to the customer. -- Also the possibility of SMTP traps from HMC to somewhere useful. Another homework exercise for idle hands. -- Everyone agrees that IWM063I gets issued whenever CPU speed changes either up or down, planned or unplanned. It seems to boil down to What did MVS know and when did she know it? In the course of my ETR, Level 2 found two hardware-related messages: IEA272I ETR SERVICE IS REQUESTED. REASON CODE=037 (Non-severe fan failure detected.) CBR3578I One of the fans in library xxx has failed. In the first case, the 9037 is famous for blasting sinister messages across the MVS console whenever a sysplex timer hiccups. In the second case, the OS apparently gets notified in response to I/O to a tape library. Neither message is relevant to the CEC fan but both illustrate that the hardware *could* notify the OS, an action that would then enable automation software to raise holy h*ll if the customer so chooses. In our case we can probably get away with alerting on IWM063I because we seldom if ever add or remove CPUs in production. My final argument is this. The customer has paid for a certain level of MSUs. The customer has configured the enterprise on that MSUs expectation. Loss of MSUs at a bad time could result in missed client SLAs. (That did not happen in our case BTW.) Given the potential severity of this problem and the risk that it could suddenly get a whole lot worse--loss of another fan with the turbo blower already activated--I contend that the hardware should provide built-in notification at the OS message level, at which point the customer can take whatever further action is deemed appropriate. The world-class z platform should not make continuous operation dependent on fickle dialing fingers or the whimsy of Ma Bell's mood swings. Not in 2008. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] -- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to
Re: IBM Link Down?
It is back up Jerry -- 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: EKM, JAVA and Tape Encryption
Here are the messages. I removed the comment cards. This is from the Start of
the EKM STC until it terminates.
Lizette
JVMJZBL2004N Log level has been set to: T
JVMJZBL2999T - JzosVM()
JVMJZBL1001N JZOS batch Launcher Version: 2.0.0 2007-02-12
JVMJZBL1002N Copyright (C) IBM Corp. 2005. All rights reserved.
JVMJZBL2999T - JzosVM()
JVMJZBL2999T - run()
JVMJZBL1029I Region requested = 0K, Actual below/above limit = 9M / 1699M
JVMJZBL2999T - adoptEnvironment()
JVMJZBL2999T - spawnChild()
JVMJZBL1036D Spawned child shell process with PID: 689
JVMJZBL2999T - spawnChild()
JVMJZBL2999T Writing shell script to child's stdin:
JVMJZBL2999T PATH=/bin:/EKM/ekmserv:/usr/lpp/java/J5.0/bin/classic
JVMJZBL2999T PATH=$PATH:/usr/lpp/java/J5.0/bin:/usr/lpp/java/J5.0/bin/j9vm
JVMJZBL2999T export PATH
JVMJZBL2999T if Ý -z $STEPLIB ¨ tty -s;
JVMJZBL2999T then
JVMJZBL2999T export STEPLIB=none
JVMJZBL2999T exec sh -L
JVMJZBL2999T fi
JVMJZBL2999T TZ=GMT0
JVMJZBL2999T export TZ
JVMJZBL2999T LANG=C
JVMJZBL2999T export LANG
JVMJZBL2999T readonly LOGNAME
JVMJZBL2999T LIBPATH=/lib:/usr/lib:/usr/lpp/java/J5.0/lib
JVMJZBL2999T LIBPATH=$LIBPATH:/usr/lib:/usr/lpp/java/J5.0/lib/security
JVMJZBL2999T LIBPATH=$LIBPATH=/usr/lpp/java/J5.0/lib/ext
JVMJZBL2999T LIBPATH=$LIBPATH=/usr/lpp/java/J5.0/bin/classic
JVMJZBL2999T export LIBPATH
JVMJZBL2999T
JVMJZBL2999T export EKM_HOME=/usr/lpp/java/J5.0/lib/ext
JVMJZBL2999T export JAVA_HOME=/usr/lpp/java/J5.0
JVMJZBL2999T export
CLASSPATH=.:${JAVA_HOME}/bin:${EKM_HOME}:${JAVA_HOME}/bin/j9vm
JVMJZBL2999T export
JZOS_HOME=${JAVA_HOME}/bin/classic:${JAVA_HOME}/bin/j9vm
JVMJZBL2999T
JVMJZBL2999T export =KeyManagerConfig.properties.JCERACFKS
JVMJZBL2999T export =com.ibm.keymanager.EKMServer
JVMJZBL2999T export JZOS_MAIN_ARGS=$ $
JVMJZBL2999T
JVMJZBL2999T IJO=-Djava.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider
JVMJZBL2999T
JVMJZBL2999T export IBM_JAVA_OPTIONS=$IJO
JVMJZBL2999T
JVMJZBL2999T export JAVA_DUMP_HEAP=false
JVMJZBL2999T export JAVA_PROPAGATE=NO
JVMJZBL2999T export IBM_JAVA_ZOS_TDUMP=NO
JVMJZBL2999T env
JVMJZBL2999T
Re: EKM, JAVA and Tape Encryption
It looks to me like your JAVA_HOME directory wasn't specified correctly,
since you are getting a message that the JVM dll can't be loaded.
You seem to have JAVA_HOME set to /usr/lpp/java/J5.0. Is there really a
Java SDK installed there?
Kirk Wolf
Dovetailed Technologies
On Tue, Dec 9, 2008 at 9:55 AM, Lizette Koehler [EMAIL PROTECTED]wrote:
Here are the messages. I removed the comment cards. This is from the
Start of the EKM STC until it terminates.
Lizette
JVMJZBL2004N Log level has been set to: T
JVMJZBL2999T - JzosVM()
JVMJZBL1001N JZOS batch Launcher Version: 2.0.0 2007-02-12
JVMJZBL1002N Copyright (C) IBM Corp. 2005. All rights reserved.
JVMJZBL2999T - JzosVM()
JVMJZBL2999T - run()
JVMJZBL1029I Region requested = 0K, Actual below/above limit = 9M / 1699M
JVMJZBL2999T - adoptEnvironment()
JVMJZBL2999T - spawnChild()
JVMJZBL1036D Spawned child shell process with PID: 689
JVMJZBL2999T - spawnChild()
JVMJZBL2999T Writing shell script to child's stdin:
JVMJZBL2999T PATH=/bin:/EKM/ekmserv:/usr/lpp/java/J5.0/bin/classic
JVMJZBL2999T PATH=$PATH:/usr/lpp/java/J5.0/bin:/usr/lpp/java/J5.0/bin/j9vm
JVMJZBL2999T export PATH
JVMJZBL2999T if Ý -z $STEPLIB ¨ tty -s;
JVMJZBL2999T then
JVMJZBL2999T export STEPLIB=none
JVMJZBL2999T exec sh -L
JVMJZBL2999T fi
JVMJZBL2999T TZ=GMT0
JVMJZBL2999T export TZ
JVMJZBL2999T LANG=C
JVMJZBL2999T export LANG
JVMJZBL2999T readonly LOGNAME
JVMJZBL2999T LIBPATH=/lib:/usr/lib:/usr/lpp/java/J5.0/lib
JVMJZBL2999T LIBPATH=$LIBPATH:/usr/lib:/usr/lpp/java/J5.0/lib/security
JVMJZBL2999T LIBPATH=$LIBPATH=/usr/lpp/java/J5.0/lib/ext
JVMJZBL2999T LIBPATH=$LIBPATH=/usr/lpp/java/J5.0/bin/classic
JVMJZBL2999T export LIBPATH
JVMJZBL2999T
JVMJZBL2999T export EKM_HOME=/usr/lpp/java/J5.0/lib/ext
JVMJZBL2999T export JAVA_HOME=/usr/lpp/java/J5.0
JVMJZBL2999T export
CLASSPATH=.:${JAVA_HOME}/bin:${EKM_HOME}:${JAVA_HOME}/bin/j9vm
JVMJZBL2999T export
JZOS_HOME=${JAVA_HOME}/bin/classic:${JAVA_HOME}/bin/j9vm
JVMJZBL2999T
JVMJZBL2999T export =KeyManagerConfig.properties.JCERACFKS
JVMJZBL2999T export =com.ibm.keymanager.EKMServer
JVMJZBL2999T export JZOS_MAIN_ARGS=$ $
JVMJZBL2999T
JVMJZBL2999T
IJO=-Djava.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider
JVMJZBL2999T
JVMJZBL2999T export IBM_JAVA_OPTIONS=$IJO
JVMJZBL2999T
JVMJZBL2999T export JAVA_DUMP_HEAP=false
JVMJZBL2999T export JAVA_PROPAGATE=NO
JVMJZBL2999T export IBM_JAVA_ZOS_TDUMP=NO
JVMJZBL2999T env
JVMJZBL2999T config.drivetable.file.url =
FILE:/EKM/ekmetc/DIC3_filedrive.table
JVMJZBL2999T config.keystore.file = safkeyring:///ITSOring
JVMJZBL2999T config.keystore.provider = IBMJCE
JVMJZBL2999T config.keystore.type = JCERACFKS
JVMJZBL2999T drive.acceptUnknownDrives = true
JVMJZBL2999T drive.default.alias1 = EKMServer
JVMJZBL2999T drive.default.alias2 = EKMServer
JVMJZBL2999T sync.type = all
JVMJZBL2999T Admin.ssl.keystore.name = safkeyring:///ITSOring
JVMJZBL2999T Admin.ssl.truststore.name = safkeyring:///ITSOring
JVMJZBL2999T Audit.event.outcome = success,failure
JVMJZBL2999T Audit.event.types = all
JVMJZBL2999T Audit.eventQueue.max = 0
JVMJZBL2999T Audit.handler.file.directory = /EKM/ekmlog
JVMJZBL2999T Audit.handler.file.name = DIC3_audit.log
JVMJZBL2999T Audit.handler.file.size = 1
JVMJZBL2999T Audit.metadata.file.cachecount = 100
JVMJZBL2999T Audit.metadata.file.name = /EKM/ekmetc/DIC3_metafile.xml
JVMJZBL2999T Audit.metadata.file.size = 1024
JVMJZBL2999T TransportListener.ssl.port = 1443
JVMJZBL2999T TransportListener.tcp.port = 3801
JVMJZBL1005I Output from DD:STDENV config shell script:
JVMJZBL2999T JZOS_MAIN_ARGS=com.ibm.keymanager.EKMServer
KeyManagerConfig.properties.JCERACFKS
JVMJZBL2999T JAVA_PROPAGATE=NO
JVMJZBL2999T
PATH=/bin:/EKM/ekmserv:/usr/lpp/java/J5.0/bin/classic:/usr/lpp/java/J5.0/bin:/usr/lpp/java/J5.0/bin/j9vm
JVMJZBL2999T =KeyManagerConfig.properties.JCERACFKS
JVMJZBL2999T IBM_JAVA_ZOS_TDUMP=NO
JVMJZBL2999T
JZOS_HOME=/usr/lpp/java/J5.0/bin/classic:/usr/lpp/java/J5.0/bin/j9vm
JVMJZBL2999T
IBM_JAVA_OPTIONS=-Djava.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider
JVMJZBL2999T _BPX_SPAWN_SCRIPT=YES
JVMJZBL2999T _=/bin/env
JVMJZBL2999T
CLASSPATH=.:/usr/lpp/java/J5.0/bin:/usr/lpp/java/J5.0/lib/ext:/usr/lpp/java/J5.0/bin/j9vm
JVMJZBL2999T LANG=C
JVMJZBL2999T
LIBPATH=/lib:/usr/lib:/usr/lpp/java/J5.0/lib:/usr/lib:/usr/lpp/java/J5.0/lib/security=/usr/lpp/java/J5.0/li
b/ext=/usr/lpp/java/J5.0/bin/classic
JVMJZBL2999T _BPX_SHAREAS=YES
JVMJZBL2999T JAVA_DUMP_HEAP=false
JVMJZBL2999T =com.ibm.keymanager.EKMServer
JVMJZBL2999T JAVA_HOME=/usr/lpp/java/J5.0
JVMJZBL2999T TZ=GMT0
JVMJZBL2999T EKM_HOME=/usr/lpp/java/J5.0/lib/ext
JVMJZBL2999T config.drivetable.file.url: FSUM7351 not found
JVMJZBL2999T config.keystore.file: FSUM7351 not found
JVMJZBL2999T config.keystore.provider: FSUM7351 not found
JVMJZBL2999T config.keystore.type: FSUM7351 not found
JVMJZBL2999T drive.acceptUnknownDrives:
Re: Z10 using zos 1.7
I read the announcement snippet kindly posted by Marian, but I did not see a 'requirement'. That is, z/os 1.7 could be expected to run just fine, just not be able to exploit some z/10 features. Can we get some clarification? We are very dependent on some hardware, specifically ICF. Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of ??? ?? ??? Sent: Saturday, December 06, 2008 11:27 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Z10 using zos 1.7 According to the z10 BC announcement you have to install something called the IBM Lifecycle Extension for z/OS V1.7 (5637-A01) in order to run z/OS 1.7 in a z10 BC. This is a charged feature. Gadi NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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: EKM, JAVA and Tape Encryption
No wait... I see something else that is wrong.
You seem to have the following lines in your STDENV config file:
LIBPATH=/lib:/usr/lib:/usr/lpp/java/J5.0/lib
LIBPATH=$LIBPATH:/usr/lib:/usr/lpp/java/J5.0/lib/security
LIBPATH=$LIBPATH=/usr/lpp/java/J5.0/lib/ext
LIIBPATH=$LIBPATH=/usr/lpp/java/J5.0/bin/classic
The last two of these lines have equals signs where there should be colons.
It should be:
LIBPATH=/lib:/usr/lib:/usr/lpp/java/J5.0/lib
LIBPATH=$LIBPATH:/usr/lib:/usr/lpp/java/J5.0/lib/security
LIBPATH=$LIBPATH:/usr/lpp/java/J5.0/lib/ext
LIIBPATH=$LIBPATH:/usr/lpp/java/J5.0/bin/classic
Kirk Wolf
Dovetailed Technologies
On Tue, Dec 9, 2008 at 10:06 AM, Kirk Wolf [EMAIL PROTECTED] wrote:
It looks to me like your JAVA_HOME directory wasn't specified correctly,
since you are getting a message that the JVM dll can't be loaded.
You seem to have JAVA_HOME set to /usr/lpp/java/J5.0. Is there really a
Java SDK installed there?
Kirk Wolf
Dovetailed Technologies
On Tue, Dec 9, 2008 at 9:55 AM, Lizette Koehler [EMAIL PROTECTED]wrote:
Here are the messages. I removed the comment cards. This is from the
Start of the EKM STC until it terminates.
Lizette
JVMJZBL2004N Log level has been set to: T
JVMJZBL2999T - JzosVM()
JVMJZBL1001N JZOS batch Launcher Version: 2.0.0 2007-02-12
JVMJZBL1002N Copyright (C) IBM Corp. 2005. All rights reserved.
JVMJZBL2999T - JzosVM()
JVMJZBL2999T - run()
JVMJZBL1029I Region requested = 0K, Actual below/above limit = 9M / 1699M
JVMJZBL2999T - adoptEnvironment()
JVMJZBL2999T - spawnChild()
JVMJZBL1036D Spawned child shell process with PID: 689
JVMJZBL2999T - spawnChild()
JVMJZBL2999T Writing shell script to child's stdin:
JVMJZBL2999T PATH=/bin:/EKM/ekmserv:/usr/lpp/java/J5.0/bin/classic
JVMJZBL2999T PATH=$PATH:/usr/lpp/java/J5.0/bin:/usr/lpp/java/J5.0/bin/j9vm
JVMJZBL2999T export PATH
JVMJZBL2999T if Ý -z $STEPLIB ¨ tty -s;
JVMJZBL2999T then
JVMJZBL2999T export STEPLIB=none
JVMJZBL2999T exec sh -L
JVMJZBL2999T fi
JVMJZBL2999T TZ=GMT0
JVMJZBL2999T export TZ
JVMJZBL2999T LANG=C
JVMJZBL2999T export LANG
JVMJZBL2999T readonly LOGNAME
JVMJZBL2999T LIBPATH=/lib:/usr/lib:/usr/lpp/java/J5.0/lib
JVMJZBL2999T LIBPATH=$LIBPATH:/usr/lib:/usr/lpp/java/J5.0/lib/security
JVMJZBL2999T LIBPATH=$LIBPATH=/usr/lpp/java/J5.0/lib/ext
JVMJZBL2999T LIBPATH=$LIBPATH=/usr/lpp/java/J5.0/bin/classic
JVMJZBL2999T export LIBPATH
JVMJZBL2999T
JVMJZBL2999T export EKM_HOME=/usr/lpp/java/J5.0/lib/ext
JVMJZBL2999T export JAVA_HOME=/usr/lpp/java/J5.0
JVMJZBL2999T export
CLASSPATH=.:${JAVA_HOME}/bin:${EKM_HOME}:${JAVA_HOME}/bin/j9vm
JVMJZBL2999T export
JZOS_HOME=${JAVA_HOME}/bin/classic:${JAVA_HOME}/bin/j9vm
JVMJZBL2999T
JVMJZBL2999T export =KeyManagerConfig.properties.JCERACFKS
JVMJZBL2999T export =com.ibm.keymanager.EKMServer
JVMJZBL2999T export JZOS_MAIN_ARGS=$ $
JVMJZBL2999T
JVMJZBL2999T
IJO=-Djava.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider
JVMJZBL2999T
JVMJZBL2999T export IBM_JAVA_OPTIONS=$IJO
JVMJZBL2999T
JVMJZBL2999T export JAVA_DUMP_HEAP=false
JVMJZBL2999T export JAVA_PROPAGATE=NO
JVMJZBL2999T export IBM_JAVA_ZOS_TDUMP=NO
JVMJZBL2999T env
JVMJZBL2999T config.drivetable.file.url =
FILE:/EKM/ekmetc/DIC3_filedrive.table
JVMJZBL2999T config.keystore.file = safkeyring:///ITSOring
JVMJZBL2999T config.keystore.provider = IBMJCE
JVMJZBL2999T config.keystore.type = JCERACFKS
JVMJZBL2999T drive.acceptUnknownDrives = true
JVMJZBL2999T drive.default.alias1 = EKMServer
JVMJZBL2999T drive.default.alias2 = EKMServer
JVMJZBL2999T sync.type = all
JVMJZBL2999T Admin.ssl.keystore.name = safkeyring:///ITSOring
JVMJZBL2999T Admin.ssl.truststore.name = safkeyring:///ITSOring
JVMJZBL2999T Audit.event.outcome = success,failure
JVMJZBL2999T Audit.event.types = all
JVMJZBL2999T Audit.eventQueue.max = 0
JVMJZBL2999T Audit.handler.file.directory = /EKM/ekmlog
JVMJZBL2999T Audit.handler.file.name = DIC3_audit.log
JVMJZBL2999T Audit.handler.file.size = 1
JVMJZBL2999T Audit.metadata.file.cachecount = 100
JVMJZBL2999T Audit.metadata.file.name = /EKM/ekmetc/DIC3_metafile.xml
JVMJZBL2999T Audit.metadata.file.size = 1024
JVMJZBL2999T TransportListener.ssl.port = 1443
JVMJZBL2999T TransportListener.tcp.port = 3801
JVMJZBL1005I Output from DD:STDENV config shell script:
JVMJZBL2999T JZOS_MAIN_ARGS=com.ibm.keymanager.EKMServer
KeyManagerConfig.properties.JCERACFKS
JVMJZBL2999T JAVA_PROPAGATE=NO
JVMJZBL2999T
PATH=/bin:/EKM/ekmserv:/usr/lpp/java/J5.0/bin/classic:/usr/lpp/java/J5.0/bin:/usr/lpp/java/J5.0/bin/j9vm
JVMJZBL2999T =KeyManagerConfig.properties.JCERACFKS
JVMJZBL2999T IBM_JAVA_ZOS_TDUMP=NO
JVMJZBL2999T
JZOS_HOME=/usr/lpp/java/J5.0/bin/classic:/usr/lpp/java/J5.0/bin/j9vm
JVMJZBL2999T
IBM_JAVA_OPTIONS=-Djava.protocol.handler.pkgs=com.ibm.crypto.hdwrCCA.provider
JVMJZBL2999T _BPX_SPAWN_SCRIPT=YES
JVMJZBL2999T _=/bin/env
JVMJZBL2999T
Re: z10 power problem notification
On Tue, 9 Dec 2008 09:28:48 -0600, Hal Merritt [EMAIL PROTECTED] wrote: Sorry, but I just don't see a problem. A fan failed and the machine phoned home. I think you posted that clearly visible red flags were set. A process failed (bad phone number) but a backup process worked. No SLA's were missed. I know i'll get flak for this outburst but i guess I need to react : I really think we are not deserving our platform . In an SLA you may have also have the amount of the bill. A simple and free IBM director is able to signal by mail or SMS any fan failure or any voltage change or loop on a processor core on any of the hundred servers in the computer rooms. But when a Z10 loses a fan in a computer room and phones IBM, and it is not treated ass a sev1 and the bill jumps and the customer is unhappy , we manage to find reasons to say it is OK. As far as i am concerned this is wrong Anytime a multi millions dollar machine cannot do what my server racks can't do It is wrong. Not only technically but because we are being laughed at ! Although i agree that the mixup in the phone numbers was a problem, it is just noise as far as i am concerned. Bruno Sugliani zxnetconsult(at)free(dot)fr http://zxnetconsult.free.fr -- 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: EKM, JAVA and Tape Encryption
In addition to what others have said, check the permissions on directory paths to the various files. Also, you have EKM_HOME as the ext directory under java. Is that correct, or should it be in your EKM directory. Larry Gray -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Tuesday, December 09, 2008 10:56 AM To: IBM-MAIN@bama.ua.edu Subject: Re: EKM, JAVA and Tape Encryption Here are the messages. I removed the comment cards. This is from the Start of the EKM STC until it terminates. Lizette I am trying to setup my EMK Profile for JAVA. I keep getting errors on teh Audit. statements. Mostly FSUM7351 not Found. Java is mounted (J1.5), EKM paths are mounted. Not sure what is missing. As always, seeing the failing command and exact/complete error message would help in answering the question. -- 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 NOTICE: All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you. -- 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: Drop hardware maintenance contract
Thanks all for the information on hardware maintenance, thoughts, and insightful suggestions on disposal. I will certainly miss this community. Best Regards, Peggy -- 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: PK67193 and z/OS 1.9
FTP is now mission critical in some z/os shops. Here is a good place, I would think. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Monday, December 08, 2008 12:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: PK67193 and z/OS 1.9 ..snip Is this concern more appropriate for IBMTCP-L or MVS-OE? Dave Gibney Information Technology Services Washington State Univsersity NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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: EKM, JAVA and Tape Encryption
Lizett, it leaves in a /EKMETC filesystem (or usually, it does) in accordance to EKM installation manual. _ Paolo Cacciari IBM Italia S.p.A. Business Continuity and Resiliency Services, IBM Global Services - South Region, EMEA Via Darwin 85, 20019 Settimo Milanese(MI) ? Italy - MISET001 From: Lizette Koehler [EMAIL PROTECTED] To: IBM-MAIN@bama.ua.edu Date: 09/12/2008 17.58 Subject: Re: EKM, JAVA and Tape Encryption Where does com.ibm.keymanager.EKMServer live? What directory? Lizette In addition to what others have said, check the permissions on directory paths to the various files. Also, you have EKM_HOME as the ext directory under java. Is that correct, or should it be in your EKM directory. Larry Gray -- 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 IBM Italia S.p.A. Sede Legale: Circonvallazione Idroscalo - 20090 Segrate (MI) Cap. Soc. euro 361.550.000 C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153 Società con Azionista Unico Società soggetta all?attività di direzione e coordinamento di International Business Machines Corporation (Salvo che sia diversamente indicato sopra / Unless stated otherwise above) -- 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: z10 power problem notification
Interesting perspective. See below for my thoughts. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruno Sugliani Sent: Tuesday, December 09, 2008 10:21 AM To: IBM-MAIN@bama.ua.edu Subject: Re: z10 power problem notification On Tue, 9 Dec 2008 09:28:48 -0600, Hal Merritt [EMAIL PROTECTED] wrote: Sorry, but I just don't see a problem. A fan failed and the machine phoned home. I think you posted that clearly visible red flags were set. A process failed (bad phone number) but a backup process worked. No SLA's were missed. I know i'll get flak for this outburst but i guess I need to react : I really think we are not deserving our platform . In an SLA you may have also have the amount of the bill. A simple and free IBM director is able to signal by mail or SMS any fan failure or any voltage change or loop on a processor core on any of the hundred servers in the computer rooms. --But does it automatically order the parts and dispatch the CE? Does it have escalation if some part of the process fails? Has it been around for decades? But when a Z10 loses a fan in a computer room and phones IBM, and it is not treated ass a sev1 and the bill jumps and the customer is unhappy , we manage to find reasons to say it is OK. --Loss of a single fan almost always means little more than other fans work a little harder. Since there was no business impact, there is no sev 1. I do have to admit I was a little disappointed that the loss of a single fan caused degradation. As far as i am concerned this is wrong Anytime a multi millions dollar machine cannot do what my server racks can't do It is wrong. -- z10 BC's go for a couple hundred K$. Not mega$. The z10 not only did the job, but did it reasonably well. By the way, there -is- an email notification feature on the z. Interesting that so few see the need to activate it. Not only technically but because we are being laughed at ! --Most server folks I know are constantly annoyed to find out their wonderful new hardware features still fall pretty short of the native z offerings. Although i agree that the mixup in the phone numbers was a problem, it is just noise as far as i am concerned. --Perhaps. But the system overcame issues and still worked. And a lot more could have gone wrong and it would have still worked. Pretty impressive, I'd say. Bruno Sugliani zxnetconsult(at)free(dot)fr http://zxnetconsult.free.fr -- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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: z10 power problem notification
On Tue, 9 Dec 2008 10:20:50 -0600, Bruno Sugliani [EMAIL PROTECTED] wrote: ... when a Z10 loses a fan in a computer room and phones IBM, and it is not treated ass a sev1 Sev 1? For a fan? I don't think so. If the loss of the fan had caused the z10 to power off, *that* would have been a sev 1. -- Tom Marchant -- 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: PK67193 and z/OS 1.9
Just to finish my interest in this issue for the time being. Over on IBMTCP-L, I learned that Bluezone's free FTP client works with z/OS native SSL FTP. This is good enough for us now. I still think that requiring configuring and activating Policy Agent so that AT-TLS can be used is not the best answer from IBM on this issue, but I have higher priority work to do RIGHT now. I also think that the FileZilla strict adherence to a revised RFC clause, without providing an option to turn it off, is shortsighted, verging on excessive open-source arrogance. But, again, my users can again do their job, I have an OS upgrade to do, and we will now tell folks about the Bluezone client. Dave Gibney Information Technology Services Washington State Univsersity -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt Sent: Tuesday, December 09, 2008 8:43 AM To: IBM-MAIN@bama.ua.edu Subject: Re: PK67193 and z/OS 1.9 FTP is now mission critical in some z/os shops. Here is a good place, I would think. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Monday, December 08, 2008 12:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: PK67193 and z/OS 1.9 ..snip Is this concern more appropriate for IBMTCP-L or MVS-OE? Dave Gibney Information Technology Services Washington State Univsersity NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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: Health Checker questions
On Tue, 9 Dec 2008 13:53:31 +0100, R.S. [EMAIL PROTECTED] wrote: Peter Relson wrote: I can activate a check that was deactivated as well as I can undelete check that was deleted. That is not necessarily true. Well... This is want I wanted to learn more about. That's why I asked the question. When is the above untrue ? The only way to undelete a deleted REMOTE check would be to re-drive the check owner's HZSADDCK code. A lot of times that might be possible (or practical). Dave Danner CA, Inc. -- 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: z10 power problem notification
On Tue, 9 Dec 2008 12:06:07 -0600, Tom Marchant [EMAIL PROTECTED] wrote: On Tue, 9 Dec 2008 10:20:50 -0600, Bruno Sugliani [EMAIL PROTECTED] wrote: ... when a Z10 loses a fan in a computer room and phones IBM, and it is not treated ass a sev1 Sev 1? For a fan? I don't think so. If the loss of the fan had caused the z10 to power off, *that* would have been a sev 1. -- Tom Marchant Agree 100% I had put and the bill increases in my sentrence I did not mean that it should be flagged as a sev 1 What i meant is that if there is a danger that the bill increases or the goals are not met, there should be an alert somehow. Al Sherkow explained very well the situation: http://www.sherkow.com/updates/20081014cooling.html But i am convinced that we should warn before instead of adding automation mechanism after. But mainly we should not be content with it. Bruno Sugliani zxnetconsult(at)free(dot)fr -- 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: EKM, JAVA and Tape Encryption (Mostly Resolved)
Thanks everyone so much. My paths, libpaths and minor little JAVA JZOS configuration issues are resolved. I am not off to get my environmentals parms up to snuff and I should be good to go. Lizette -- 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: Interesting CS Course Syllabus
On 23 Nov 2008 14:35:51 -0800, in bit.listserv.ibm-main you wrote: On Sun, 23 Nov 2008 17:00:38 -0400, Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: The symbol of the OS/360 project. Google for without a paddle and you will see the (vulgar) derivation. Thank you I knew the expression but did not know it was the symbol of the OS/360 project It became so after IBM stopped support for OS360. Thus the OS360 community became their own support group. Paddle your own canoe or you were up the creek without a paddle. We also had one hour courses on various topics by people from the Marine Corps training center at Quantico. They knew how to teach. I still see some people posting who were on that project. The Michmods tape of the project preceded the CBT tape. Bruno Sugliani zxnetconsult(at)free(dot)fr Clark Morris -- 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: z10 power problem notification
We're in the process of automating response to the WLM message. Sending out the town crier and so forth. A couple of clarifications: -- Although we did not happen to miss any SLAs in this event, just a few days afterwards we entered 'month end processing', when this normally busy z10 goes bananas. That would have been a very sorry time for this to have happened because every MSU counts around the clock for several days. -- The internal hardware diagnosis that accompanied the fan failure called out the wrong part. An on-site replacement part was installed the next morning, but the fan still did not work because a different component had also failed. That's why we had to order the part from the SF Bay area. I'm told that internal hardware diagnosis will be corrected for this case. -- There was considerable discussion among managers when word got out that we had had a hardware failure. Along with the usual miscommunication in such instances. And we techs were in the dark. Not a great situation to be in. Not a great way to run an enterprise. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Bruno Sugliani [EMAIL PROTECTED] .FR To Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List [EMAIL PROTECTED] Subject .edu Re: z10 power problem notification 12/09/2008 10:46 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .edu On Tue, 9 Dec 2008 12:06:07 -0600, Tom Marchant [EMAIL PROTECTED] wrote: On Tue, 9 Dec 2008 10:20:50 -0600, Bruno Sugliani [EMAIL PROTECTED] wrote: ... when a Z10 loses a fan in a computer room and phones IBM, and it is not treated ass a sev1 Sev 1? For a fan? I don't think so. If the loss of the fan had caused the z10 to power off, *that* would have been a sev 1. -- Tom Marchant Agree 100% I had put and the bill increases in my sentrence I did not mean that it should be flagged as a sev 1 What i meant is that if there is a danger that the bill increases or the goals are not met, there should be an alert somehow. Al Sherkow explained very well the situation: http://www.sherkow.com/updates/20081014cooling.html But i am convinced that we should warn before instead of adding automation mechanism after. But mainly we should not be content with it. Bruno Sugliani -- 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
DFRMM return to Scratch Pool
Most of our tapes move to the scratch pool correctly but I have a few that will not move and stay in the Pending Release mode. I have tried numerous options like Confirm Action, Confirm Scratch and resetting the Expiration Date. All of the tapes are not cataloged and Expiration Dates have past. If the tape has multiple files on it I verified that all the files are not cataloged. Current status is: Availability . . . : PENDING RELEASE Release actions: Return to SCRATCH pool . : YES Actions pending: Return to SCRATCH pool . : YES Expiration date . . . . . : 2008/339 I must be missing something, anybody got any ideas as to why they will not move to the scratch pool? Y last resort is to delete and re-add them to RMM. Bob This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you. -- 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: DFRMM return to Scratch Pool
Hello Bob, Do any of these volumes have the Initialize Volume = YES or Replace Volume = YES in the Actions pending? -- 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
TAPE to TAPE across Sysplex local or remote
Hi, What tools and techniques are you using to move large tape (VTS normally) resident data sets from one Sysplex to another? We are creating our third Sysplex and see that in this case we are going to have data sets which are routinely created on tape in one that need to be moved to another. These two Sysplex may someday be geographically separated and we don't want to use a solution like export to a tape cart and go stick it in a different ATL. All transfers are z/OS to z/OS only. IBM z/OS FTP and CA-XCOM are already deployed in these LPARs but there is discussion as to weather we need a different approach for tape data sets. So what do you do? We have some IBM consultants pushing MQ http://www-01.ibm.com/software/integration/wmq/filetransfer/index.html http://www-01.ibm.com/software/websphere/products/appintegration/hiddenrisk/ Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 (cell) 301.996.1318 Think big, act bold, start simple, grow fast... This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 12/09/2008 10:30:32 AM: Jim Mulder wrote: The lesson here is that, if a change has been observed to cause unexpected surprise wrong behaviors in some IBM components during testing, then similar problems should be expected after deployment. A documented fall-back Chicken Switch should be provided. I think the proposed, documented DIAG TRAP is a great way to go. None of the wrong behaviors in some IBM components were unexpected or surprising. They were the kinds of things I anticipated. And I expected some similar problems after deployment. That is why there was an undocumented fall-back Chicken Switch provided, designed so that a documented TRAPS could be added for 2 lines of code if subsequent experience dictated. So far, the number of problems that I have heard about has been less that I anticipated. However, some of the ESP customers have requested a documented switch and so the APAR will be providing that. I discussed the issue of documenting vs. not documenting the switch with a number of people during development, and there was no strong consensus at that time (although there are some pretty strong opinions now),so I decided to not document initially, with the option to reevaluate after further experience. And, if IBM, ISV, and customer in-house developers would use IgvInitGetmain and IgvInitFreemain on their test/development systems--as we do--nobody would have experienced this issue to begin with. Of course, it's hard to fault someone for not using an undocumented feature. These TRAPs have been around since OS/390 V2R6. They work. Perhaps it's time they were documented, too! I have considered that many times over the years since OS/390 V2R6, and considered it again for z/OS V1R10. That would have been a convenient time, since the TRAPS keyword was being added to the documentation for the first time (with a small subset of the trap names being documented). And then just a few months ago, an ISV using IgvInitGetmain encountered a problem with the CICS's IPCS VERBEXIT. CICS development has estimated that a complete fix for this in all the dump formatters is probably well over a thousand lines of code given that the DFHPD640 load module comprises circa 200 modules. So the plan is to not fix this in the service stream, and instead try to prioritize it into the development plan. Now, if IgvInitGetmain was formally documented, would CICS had as much flexibilty in deciding how do deal with this? I don't know, but that is an example of the kind of thing that has to be considered when deciding when to document some of the TRAPS. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: DFRMM return to Scratch Pool
Hale, Bob [EMAIL PROTECTED] wrote in message news: [EMAIL PROTECTED]... Most of our tapes move to the scratch pool correctly but I have a few that will not move and stay in the Pending Release mode. I have tried numerous options like Confirm Action, Confirm Scratch and resetting the Expiration Date. All of the tapes are not cataloged and Expiration Dates have past. If the tape has multiple files on it I verified that all the files are not cataloged. = Take a look at the loan location on the display of the volume and also check to see if there are any movement activity pending. Also, you may want to check to see what VRS governs the volume. Ernie. -- 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: Drop hardware maintenance contract
I wrote: And, as someone already alluded to, off maintenance means you're last in the queue. So, for example, if there's an earthquake -- I've heard they happen in California -- that shakes some parts silly, you'll be dead last in line for repair. Which is entirely fair, of course, but something to be aware of. Radoslaw Skorupka wrote: While I agree that service contract is definitely better for good sleep, the argument above is miss. I'm pretty sure that in case of real earthquake no service provider will be able to meet fix times. BTW: I vaguely remain that earthaquakes are valid excuses for SLA. Please read my comments again. I didn't say anything about meeting repair SLAs or not, i.e. how fast the repair queue gets emptied. What I said was that if you don't have a maintenance contract you will be last in line in the repair queue. That's unquestionably true, and being last in line matters most when the queue is deep. One entirely predictable way the queue could get very deep in Sacramento, California, is if (or rather, when) there's a major earthquake. To elaborate slightly, this is exactly the sort of scenario where critical government functions should be restored to service first, not last. So, in my opinion, going off maintenance is a non-trivial risk. (It's unquestionably non-zero.) However, I do not know all the details and cannot assess all the risks remotely. I referred to one way those risks could be mitigated at least somewhat: good DR., - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: [EMAIL PROTECTED] -- 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
is out of the office.
I will be out of the office starting 12/09/2008 and will not return until 12/11/2008. I will be out of the office on Wednesday, December 10th. I will return on Thursday, December 11th. Thanks. ** The information contained in this communication is confidential, private, proprietary, or otherwise privileged and is intended only for the use of the addressee. Unauthorized use, disclosure, distribution or copying is strictly prohibited and may be unlawful. If you have received this communication in error, please notify the sender immediately at (312)653-6000 in Illinois; (800)835-8699 in New Mexico; (918)560-3500 in Oklahoma; or (972)766-6900 in Texas. ** -- 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: Interesting APAR OA27291 an undocumented change to GETMAIN Behavior in z/OS 1.10
Jim, as I stated in our problem record, the change to GETMAIN caused us downtime which is unacceptable in a business environment. Even though the interface to GETMAIN didn't change and, if programmers correctly initialized their workareas there wouldn't be a problem, the REALITY is that not all programmers initialize their storage, and not all source code is available for us to determine if there will be a problem (and to fix it if there is), I don't dispute any of the above. I have been specializing in problem diagnosis on MVS for almost 30 years, and am quite familiar with the realities of many classes of program bugs, including uninitialized storage. And while I am not aware of us losing any of the source code of MVS, we have had plenty of issues with trying to locate source code for old testcases and tools. so we, and many other installations will not be able to go forward with this change. Based on my experience so far, I think that many installations will not be able. is an exageration. However, that is only my opinion, and most certainly not a fact, and I will not be shocked if subsequent experience proves otherwise. Given the downtime consequences and the time required to diagnose the problem your installation encountered, your opinion is understandable, and only time will tell the extent to which either opinion proves to be correct. From a business standpoint, the dangers far outweigh the benefits. One instance of downtime in our production environment would cost too many dollars and would require us to back off the upgrade. Having no experience in being responsible for your production environment (or anyone else's), I am not qualified to offer an opinion on this subject. Any change to the way a major interface works SHOULD be documented whether the developer thinks that it will cause a problem or not. There is a lot of old code still running in production and installations need to know when things change. As I have said in another post, the developer did in fact think that this change would cause some latent program defects to become immediate problems, and that did not affect the question of documentation. The documentation issue is, where should we document a change to undocumented behavior, and what exactly should we say about it? It has been suggested that the Migration book would be an appropriate place to say something, and we are working on that. Exactly what to say remains problematic. I spent over two weeks of very intense debugging on this problem. In the interest of finding a silver lining for that cloud, consider that the problem you encountered was a program running in key 0 interpreting residual storage contents as an address, and overlaying key 0 storage. Consider the possibility that a malicious unauthorized program could find a way to arrange things so that the residual storage contained an address of something interesting in such a way that the resulting overlay would allow the malicious program to circumvent your installation's security controls. In that case you may have spent two very productive weeks uncovering a system integrity exposure so that it could be fixed. I am not saying this in jest. We take these things very seriously. That could have been avoided if we had been informed of the change at the T3. That was an unintentional oversight. We made a presentation to the ISVs who attended the Spring 2008 Technical Disclosure Meeting, and in my dotage, I confused that with IBM Level 2 education and T3. The Level 2 folks understandably shared your discontent. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: z10 power problem notification
Skip Robinson wrote: ...but the fan still did not work because a different component had also failed That clears up a mystery for me, thanks Skip. The z10 design should require a concurrent *double* component failure before arriving at a processor speed reduction (for heat control). It sounds like that's exactly what happened. :-( I'm curious, do you have any more details on what you decided to do as a consequence? What sort of new alerting and/or automation are you adding for that particular console message? (What do you feel will work best for you?, basically.) Thanks. By the way, someone raised the question about SCRT reports and Variable Workload License Charge billing. Please remember that I don't speak for IBM, only for myself, so check your contracts. However, apparently an event like this could result in some strange SCRT data during the interval. (And that strange data could extend into a Parallel Sysplex if the affected system is a member.) I would just point everyone to the SCRT User Guide, page 180, which describes the correct process for amending an SCRT report if there is an unusual situation. It would seem that a hardware failure resulting in a processor speed reduction (and associated reported MSU oddities) would certainly qualify as unusual. (In fact, page 180 specifically mentions disaster recovery.) You can find the SCRT User Guide here: http://www.ibm.com/servers/eserver/zseries/swprice/scrt/ In case the page numbers drift over time, look for the section entitled Incorrect billing -- unusual situations where customers must provide alternate MSU values. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: [EMAIL PROTECTED] -- 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
