Re: IBMLINK down SEV1 ticket 34483833 due to Web Identity (logon authentication)
I just logged on. It works fine here. Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Knutson, Sam Sent: Monday, January 28, 2008 8:36 AM To: IBM-MAIN@BAMA.UA.EDU Subject: IBMLINK down SEV1 ticket 34483833 due to Web Identity (logon authentication) IBMLink cannot be accessed again :-( -- 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: IFASMFDP Abends
Tom, We just encountered a variation of your problem. In our case, a tape problem caused a return code 8, and no abend. The inputdataset had disp(old,delete,keep). The input thus was deleted. We have changed our jobstream to do condition code checking in a follow-on job step, and delete the input only if the dump step has beeen successful. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kelman, Tom Sent: Tuesday, December 18, 2007 8:35 AM To: IBM-MAIN@BAMA.UA.EDU Subject: IFASMFDP Abends I had a problem with IFASMFDP this morning that I've had previously over the years. It has always been my understand that this is just the way it is. In my daily SMF rollup I split the SMF data into multiple tape files depending on the SMF ID. One of those files had grown past the number of tape volumes allowed. Therefore the job failed with an S837-08. I fixed that by bumping up the number of volumes in the JCL. The problem is that IFASMFDP intercepts the abend and completes with a condition code of 8 instead of a true abend. Because of this the output datasets were not deleted even though DISP=(,CATLG,DELETE) was coded on the JCL. Does anyone know of a way to make IFASMFDP complete with a true abend when it occurs? Tom Kelman Commerce Bank of Kansas City (816) 760-7632 -- 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/OS PTFs
Meganen, I just applied maintenance to take us from z/OS 1.8 at RSU0704 to RSU0710 + HIPER. It came to just about 900 PTFs. I wonder if you received all the PUT maintenance available instead of just the recommend RSU levels. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Meganen Naidoo - BCX - RO JHB Sent: Thursday, November 15, 2007 9:31 AM To: IBM-MAIN@BAMA.UA.EDU Subject: z/OS PTFs Hi All, We are currently running z/OS 1.7 service level 0705 on 11 production Lpars for different clients - not in a sysplex. We just received the latest recommended and critical ptfs from Shop zSeries - 0710. The PTF's are a staggering 7524 in total. Our current fix strategy is to just smp receive all the PTF's and use the 'fix on fail' approach if we require a fix. We have a good SMPE rollout strategy - SMP dddefs point to copied system volumes and we IPL of the 'SMP applied' setetc. Our reason for not applying all the fixes is that we run many different non-IBM 3rd party products on the different lpars and are concerned that the fixes may cause problems. We would like to know what strategy's other companies use to install these system fixes. How often do you receive/apply system fixes...etc Kind Regards, Meganen Naidoo -- 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: Zos 1.7
Bill, Look at OA20748. There is no fix available for it yet, and it describes a performance problem with catalogs in ECS mode and autotuning enabled. The recommendation is to F CATALOG,DISABLE(AUTOTUNING) until a fix is available. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Carroll, William Sent: Monday, October 08, 2007 2:01 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Zos 1.7 We converted to 1.7 over the weekend, mostly good, but a couple of really weird problems. Job used to execute in 4 minutes now Takes 20...Only that one job. A couple of jobs running snap, are taking a bit longer as well. Is everybody running with the Catalog auto tune on? I am just grabbing at straws. Any insight or thoughts would be greatly appreciated. -- 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: TASID 5.14 available for download from ISPF website
I just searched on IBM's primary page at www.ibm.com. The first hit took me to http://www-306.ibm.com/software/awdtools/ispf/support/. That page, ISPF for z/OS has a link Download . TASID V5.14 tool It allowed me to download files for the tool. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Yuhas Sent: Tuesday, September 25, 2007 6:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: TASID 5.14 available for download from ISPF website I have been trying to download this level and cannot. I get to the site, choose the FTP option, and, agree to the terms and conditions box. I then get "Not Found" from "IBM_HTTP_Server/6.0.2.13 Apache/2.0.47 (Unix) Server at ftp.software.ibm.com Port 21. I contacted my colleague who supports our firewalls and he received the same error. Any ideas out there? -- 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: Listing HIPERS
That one took about 30 seconds to figure out. HOLD SYSMOD APAR ---RESOLVING SYSMOD HOLDHOLD FMID NAME NUMBERNAMESTATUS RECEIVED CLASS SYMPTOMS UA31645 AA21256 UA35069 GOOD YESPE See that there entry, UA31645? It is accepted. Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. >Does the report ERROR SYSMODS tell you if you have an error against a function or PTF that has been ACCEPTED? Many years ago if the sysmod was ACCEPTED >the PE wouldn't show. -- 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: Listing HIPERS
Ed, Joseph's question was about how to monitor HIPER fixes, not about how and when to apply maintenance. I try to always go through a current round of RSU maintenance before a product goes into production to keep it as current as possible just as Tom described. As Debbie pointed out, PSP buckets are important too, expecially because of issues other than maintenance. OOPS! Gotta run outside now and retrieve Junior before the lawn service comes to mow! John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Thursday, August 16, 2007 2:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Listing HIPERS On Aug 16, 2007, at 10:28 AM, Tergerson, John wrote: > SNIP__ > Ed, if you really have nothing better to do than look every half hour > for additional HIPER maintenance, you really need a life :) Yesterday > is current enough for me. > > John > If that is what is good for you fine, personally I would expect no less from anyone. I would also expect to monitor all new hipers for at least a week (or two) after maintenance goes on. I do have a life but maintenance is part of it and if you had a baby would you leave it out on the front lawn because you have checked the neighborhood for wolves (and found none) ? When my "baby" goes into production I am in proactive mode not reactive. I don't wait for the wolf to come to my street corner. i also monitor logrec and system dumps all the time. That is how you find things that are in the process of breaking. Saying that, not all hipers are really important. If there is one out there for a component we don't use I don't rush to put it on, the next round of IPL's is fine. But if a hiper PTF came out got lets say VSAM it would go on as fast as I can schedule it (or sooner if it breaks something). This was a lesson learned by me after 5 years of MVS sysproging I have constantly refined it over the years. Yes MVS has gotten better but lessons learned, it is almost always better to be safe than have something broke at 2AM. We don't have (anymore) mega ptf tapes thanks to better testing by IBM but coders are not perfect and mistakes do happen. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Listing HIPERS
Joseph, The 90 days worth of holddata might be correct in this case, just because your system, built in July, is less than 90 days old. There won't be a gap in the holddata. Before you run any report, retrieve current holddata into your system that covers back to the last date you retrieved holddata. Don't bother trying to read the data itself. If you run a report today, and the holddata is current, it will show what PTF errors and HIPER errors your system is known to be exposed to today. If your production date is October, then, sometime before you go to production, get the holddata current and run another report. You will undoubtedly see additional entries. Maintenance applied in the interim will possibly eliminate entries seen in the first report. Take care of the entries that look serious enough to your shop. Each report will show you what errors you are known to be exposed to and will be as current as the holddata. There are lots of other ways to receive notification of potential problems. One is this forum, another is the IBMLink Automatic Software Alert Process, another is a subscription to IBM flashes. They will give warning between your refresh of holddata. Those entries should show up in the holddata as well, and very quickly after they become known by the IBM support teams. You can also, as you asked in the first place, do your own searching and wading through results. I just don't do much of that, so I don't know how to do efficient queries that won't also potentially miss errors I would have wanted to see, and the holddata is so darned easy. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Sumi, Joseph J. (CMS/CTR) (CTR) Sent: Thursday, August 16, 2007 12:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Listing HIPERS Let me give more background. My role is management of this activity and I do not receive, apply, etc. We need to change our maint philosophy on how we handle HIPERS. IE: We build z/OS 1.8 on a test system with a July ESO but do not go production to October. I want to find out about HIPERS from July-September. They would be evaluated to make sure nothing hot is missing. We would then selectively apply HIPERS that are applicable. That's my idea right now. Are you saying that if my MVS guy received 90-days of enhanced holddata, we could look it over and selectively apply what is needed or would all 90-days worth of this maint go on? What would you (or others) do with my example scenario..? Also, going forward from October, how would you handle HIPERS that come out. Thanks. Rgrds, Joseph Sumi -- 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: Listing HIPERS
Joseph, That is the ENHANCED HOLDDATA. You don't need to read any of it, just receive it into your SMPE GLOBAL CSI. As you can see in the header, it is as current as the previous day. Make sure there are no gaps in holddata received. In your example, the file covers only the last month. You can retrieve holddata that covers the last two years. Your report will show you what applies to YOUR system at its current state. There is no need to develop complex queries and try to understand which piece of maintenance you found applies to you. Everything in the report applies to your system, and it is current. Ed, if you really have nothing better to do than look every half hour for additional HIPER maintenance, you really need a life :) Yesterday is current enough for me. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Sumi, Joseph J. (CMS/CTR) (CTR) Sent: Thursday, August 16, 2007 11:10 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Listing HIPERS What I will probably do is to have the programmers use IBMLINK ASAP and enter FMID's to track their productsI still would have thought that there was a way to put in a date range and get back a 1-line description of the HIPER PTF, FMID, Componenet, Date, Description. The Enhanced Hold Data output is ugly (or I'm pulling it incorrectly), FYI: Is this what you guys see ?? ++NULL //. ++NULL /* Enhanced HOLDDATA from 07/16/2007 to 08/15/2007 */. ++NULL /* Current updates and additional information regarding */. ++NULL /* Enhanced HOLDDATA is available on the world-wide web */. ++NULL /* at http://service.boulder.ibm.com/390holddata.html */. ++NULL //. ++ NULL. /* Enhanced Holddata from 07/16/2007 to 08/15/2007 */ ++HOLD(AKDF540) FMID(AKDF540) REASON(AA21624) ERROR DATE(07200) COMMENT(SMRTDATA(FIX(UA35557) SYMP(FUL) CHGDT(070719))) CLASS(HIPER). -- 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: Listing HIPERS
Joseph, I think the easiest way to do this is to rely on ENHANCED HOLDDATA. Make sure you have received current holddata, and then run an SMPE report: SETBOUNDARY (GLOBAL) . REPORT ERRSYSMODS ZONES( MVST100 MVST111 ) NOPUNCH . It will give you output like: HOLD SYSMOD APAR ---RESOLVING SYSMOD HOLDHOLD FMID NAME NUMBERNAMESTATUS RECEIVED CLASS SYMPTOMS --- HBB7730 HBB7730 AA06300 UA33609 HELD YESHIPER IPL,XSYS,SYSPLXDS AA16435 UA32817 GOOD YESHIPER FUL AA17009 UA32825 GOOD YESHIPER FUL AA17114 UA34633 GOOD YESHIPER IPL AA18380 UA32760 HELD YESHIPER FUL Hope that helps. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Sumi, Joseph J. (CMS/CTR) (CTR) Sent: Wednesday, August 15, 2007 1:20 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Listing HIPERS Is there an easy way to list all HIPERS for a given time frame for my licensed products z/OS and z/OS related productsor all z/OS products ? I have do IBMLINK Thanks, Joseph Sumi -- 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: SOC4 in DFSORT with DB2
George, I should have mentioned that our Abend0C4 was in IEFAB42A, or IEFAB421, depending on what you are looking at. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tergerson, John Sent: Wednesday, August 01, 2007 11:21 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SOC4 in DFSORT with DB2 George, We got an 0C4, and also a U0083 symptom using DFSORT to do reorgs on a tablespace with a lot of indexes. The DBA had set up sortnum to 160 so they would never have to compute sort work space. When they reduced it to 80, things worked fine. The tablespace with the problem was small, but has lots of indexes. Large tablespaces with fewer indexes could be reorged with larger sortnum. There are two new APARs we caused. Look at OA21854 and darn, I can't get to IBMLink to find the other, if it was even assigned yet. In our case, the large number of sortnum caused a condition that exceeded the allowable size of the TIOT. The allocation APAR is to give the user a better symptom than abend0C4 to tell the user what is wrong. The 0C4 is because the slot allocation was trying to free up was for VIO, which does not have a control block they were looking for. The DB2 APAR is to address an issue of why they were asking for an enormous number of sortwork datasets. I'll post that whenever I can find it. Asking for sortnum of 80 for most reorgs, though, gave us a welcome bypass. Hope that helps. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of George Bly Sent: Wednesday, August 01, 2007 8:22 AM To: IBM-MAIN@BAMA.UA.EDU Subject: SOC4 in DFSORT with DB2 HI All We went to DB2V8 this week. Now we are getting S0C4's in DFSORT when using DB2 utilities. I've read the informational APAR and I have it in correctly after my SyncSort libs. I am working with IBM but has anyone else run into this problem. By the way: IBMLINK went down when we first started researching the problem. It was very inconvenient to say the least. Thanks!! George -- 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: SOC4 in DFSORT with DB2
George, We got an 0C4, and also a U0083 symptom using DFSORT to do reorgs on a tablespace with a lot of indexes. The DBA had set up sortnum to 160 so they would never have to compute sort work space. When they reduced it to 80, things worked fine. The tablespace with the problem was small, but has lots of indexes. Large tablespaces with fewer indexes could be reorged with larger sortnum. There are two new APARs we caused. Look at OA21854 and darn, I can't get to IBMLink to find the other, if it was even assigned yet. In our case, the large number of sortnum caused a condition that exceeded the allowable size of the TIOT. The allocation APAR is to give the user a better symptom than abend0C4 to tell the user what is wrong. The 0C4 is because the slot allocation was trying to free up was for VIO, which does not have a control block they were looking for. The DB2 APAR is to address an issue of why they were asking for an enormous number of sortwork datasets. I'll post that whenever I can find it. Asking for sortnum of 80 for most reorgs, though, gave us a welcome bypass. Hope that helps. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of George Bly Sent: Wednesday, August 01, 2007 8:22 AM To: IBM-MAIN@BAMA.UA.EDU Subject: SOC4 in DFSORT with DB2 HI All We went to DB2V8 this week. Now we are getting S0C4's in DFSORT when using DB2 utilities. I've read the informational APAR and I have it in correctly after my SyncSort libs. I am working with IBM but has anyone else run into this problem. By the way: IBMLINK went down when we first started researching the problem. It was very inconvenient to say the least. Thanks!! George -- 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: Unit 1501 HAS NO PHYSICAL PATHS
We had the same symptom a couple of weeks. The hardware CE swapped tape units and swore he had no problem because two separate drives had the same problem that didn't go away when he swapped in a working drives that would then fail. He finally found that both drives had bad channel interface switches. Ed is right. Call service. Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Finnell Sent: Tuesday, July 17, 2007 10:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Unit 1501 HAS NO PHYSICAL PATHS In a message dated 7/17/2007 8:09:13 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: Seems like there is no physical connection, or an interface is disabled. >> DS QT,1500,16,validate Used to have an A22 and every now and then one of the controller's power supplies would fail. No errors or anything just adios. So first thing is check the green lights on the back of the unit. If they're ESCON check the connections on the front. Run EREP. Call for service. ** Get a sneak peek of the all-new AOL at http://discover.aol.com/memed/aolcom30tour -- 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: 3590-e11
APAR Identifier .. II13276 Last Changed 06/07/25 HELP FOR CBRXLCS " NO DEVICE POOLS EXIST ..." Symptom .. MS MSGIGD306IStatus ... CLOSED CAN Severity ... 4 Date Closed . 02/04/25 Component .. INFOV2LIB Duplicate of Reported Release . 001 Fixed Release Component Name V2 LIB INFO ITE Special Notice Current Target Date .. Flags SCP ... Platform Status Detail: Not Available PE PTF List: PTF List: Parent APAR: Child APAR list: ERROR DESCRIPTION: There are several variations of this error. For example, you might see: IGD330I ERROR OCCURRED DURING CBRXLCS PROCESSING- (msgIGD330I) NO DEVICE POOLS EXIST TO FULFILL REQUEST FOR TDSI SPECIFICATION IGD306I UNEXPECTED ERROR DURING CBRXLCS PROCESSING RETURN CODE 12 REASON CODE 49 (rc12 rsn49) THE MODULE THAT DETECTED THE ERROR IS IGDIDMUS SMS MODULE TRACE BACK - IDMUS IDMSU IDM00 SSIRT SYMPTOM RECORD CREATED, PROBLEM ID IS IGD00094 . With the IGD306I, you might also see: NO DEVICE POOLS EXIST TO FULFILL REQUEST FOR SPECIFIED RECORDING TECHNOLOGY. ( RETURN CODE 12 REASON CODE 66 rc12 rsn66) or NO DEVICE POOLS TO FULFILL REQUEST FOR SPECIFIED MEDIA TYPE ( RETURN CODE 12 REASON CODE 67 rc12 rsn67) . Things to check: 1) For SCRATCH allocations it is usually a problem with Data Class. Verify that the correct Data Class is being selected and that the ISMF definition is correct. . Check your job output to determine which Data Class was assigned. If it is not the correct one, check your ACS routine logic. If it is the one you expect, display the Data Class definition in ISMF and look at the recording technology and/or media type specified. Verify that the recording technology and/or media type specified is appropriate for the devices in your library(s). For instance, if you have upgraded all of your devices to a new model (3590 Model B -> 3590 Model E) and your data class still referenced the old recording technology, this could be one cause for the failure. Assigning a Data Class is optional, and if one is specified, assigning a media type and recording technology is used to direct your allocations to a particular device type within a library (or set of libraries). This is especially important if your library contains multiple device types. 2) For PRIVATE allocations, display the volume with: D SMS,VOL(volser) to determine which library the volume resides in, then display the library with: D SMS,LIB(libname),DETAIL and the drives with: LI DD,libname Make sure the ATL and drives are ONLINE and OPERATIONAL and that the DEVICE TYPE is correct . If you have just upgraded your drives to a new recording technology, (this is especially important if all of the drives in your library have been upgraded) you may need to set the Special Attribute ( READCOMPAT ) indicator in your volume records to be able to read your old PRIVATE tapes on your new drives. RMM users can build a CLIST as follows: RMM SV VOLUME(*) OWNER(*) LIMIT(*) STATUS(MASTER) - LOCATION(libname) - CLIST('RMM CHANGEVOLUME ' , ' SPECIALATTRIBUTES(RDCOMPAT) ') . To update only the TCDB, you can use IDCAMS: Example: //ALTERVOL JOB ... //STEP1EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=A //SYSINDD * ALTER VAL0001 - VOLUMEENTRY - SATTR(RDCOMPAT) /* or "ALTER 'Vvolser' VOLENT SATTR(RDCOMPAT)" TSO command. For DFSMS releases below R1F0, verify that you have the fix for APAR OW41005 as it corrects a problem with this ALTER command. . See section below on "Other 3590B to E migration issues:" . 3) For new installs or upgrade of existing drives: - Verify device type is correct in displays resulting from the following commands: . LI DD,name: example output: CBR1220I Tape drive status: DRIVE DEVICE LIBRARY ON OFFREASN LM ICL ICL MOUNT NUMTYPE NAME LI OP PT AV CATEGRY LOAD VOLUME 0BA4 3590-E LIB1 Y N N N A NONE N . DS QTAPE,drive_num,1,RDC,UCB example output: UNIT DTYPE DSTATUS CUTYPE DEVTYPE CU-SER DEV-SERIAL ACL LIBID 1200 3590L ON-NRD 3590A60 3590B1A 0113-4 0113-46559 I 15191 READ DEVICE CHARACTERISTIC 3590603590100110 4EDCB0D7CC00 (16 digits) 359060359010 (here were) (deleted to) || (fit display) || for example this byte should be x'09'
Re: zOS 1.8 and One Byte Console ID
That happened to us with a CICS V2.2 system. It was using the old master console ID. The CICS system programmer changed to a legitimate console and it worked. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Big Iron Sent: Tuesday, May 29, 2007 3:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: zOS 1.8 and One Byte Console ID I think that the tracking report should say what console ID it was trying to use. If that console ID was formerly the master console, then that would explain why it no longer has the same authority. Bill On Tue, 29 May 2007 15:05:41 -0400, Mark Jacobs <[EMAIL PROTECTED]> wrote: >Field, Alan C. wrote: >> Mark, >> >> I doubt it has anything to do with the one byte ids. Here's what the >> message book says: >> >> FAILED BY MVS >> >> The MVS console command authority was insufficient for >> this command. Either: >> >> t no security product was active for this function, >> or >> >> t a security product was active for this function, >> but it could not determine whether the command >> should be allowed or failed. >> >> >> >> Alan. >> >> >> > >I know what the book says. But; > >zOS 1,8 system up - Command fails >zOS 1.8 system down - Command works. > >Seems like a big hint to me. :-) > >-- >Mark Jacobs >Technical Services >Time Customer Service - Tampa, FL >-- >Victory in defeat, there is none higher. She didn't give up, Ben; she's >still trying to lift that stone after it has crushed her. >She's a father going down to a dull office job while cancer is >painfully eating away his insides, so as to bring home one more pay >check for the kids. She's a twelve-year-old girl trying to mother her >baby brothers and sisters because Mama had to go to Heaven. She's a >switchboard operator sticking to her job while smoke is choking her and >the fire is cutting off her escape. She's all the unsung heroes who >couldn't quite cut it but never quit.* > >Robert A. Heinlein - Stranger in a Strange Land > >*Referring to the Auguste Rodin sculpture, Caryatid Who Has Fallen >under Her Stone > -- 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: UNIT NOT JES3 Dataset attributes change upon open
Steve, Since we stopped defining all DASD to JES3, we get that message for each DASD dataset in each DD card. It is normal. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Rawlins Sent: Friday, March 09, 2007 6:15 PM To: IBM-MAIN@BAMA.UA.EDU Subject: UNIT NOT JES3 Dataset attributes change upon open What does "UNIT NOT JES3" say about dataset allocation and formatting? I am trying to understand why a started-task seems to change the attributes of a dataset when it opens. The dataset is allocated: SPACE=(CYL,(3,1),RLSE), DCB=(LRECL=0,DSORG=PS,RECFM=U,BLKSIZE=32000) But when the program opens, it seems to change to: Organization . . . : PS Record format . . . : FB Record length . . . : 80 Block size . . . . : 6080 Could the following message on the job's output have anything to do with the case? 10:43:23 IAT4401 LOCATE FOR STEP=xx DD=ddname DSN=dsn-name 10:43:23 IAT4402 UNIT=3390,VOL(S) N/A: UNIT NOT JES3 -- 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: IBMLINK DOWN ALL DAY?
I don't know where the problems are limited to, but I have been on IBMLink all day. I just logged on to ShopzSeries, and got in right away. Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -- 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: SAP using DB2 and Daylight Savings Time
Our SAP basis team will shut down the AIX application connection at 1:45 AM Sunday, and reconnect at 3:15 AM. The application will tolerate only something like a five minute difference in timers I don't know what they do to set their clocks on the application server boxes, but at 2 AM we will have automation issue SET CLOCK=3.00.00 on the z/OS LPARS (no sysplex timer, just one CEC). John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Petersen, Jim Sent: Thursday, March 08, 2007 9:41 AM To: IBM-MAIN@BAMA.UA.EDU Subject: SAP using DB2 and Daylight Savings Time I am looking for SAP users who also use DB2. How do you accomplish your time change? We are currently running LOCAL = UTC + Offset. I know on the mainframe side we are going to change the time at the Sysplex Timers. Done it for may years now at different accounts. None that have used SAP however. Where I am ignorant is the AIX/Unix Servers. How do you accomplish this time change? -- 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: ILR006E COMMON PAGE DATA SET FULL, OVERFLOWING TO PLPA DATA SET
Allan, Rob Scott's answer is probably what is happening to you. As an example, we just went through the same sort of problem. A vendor monitor was issuing getmain for some function, and never issuing freemain when finished with the storage. It built up over time to the point that the monitor had used a very large percentage of the page space. The vendor had a fix for a known problem, and, after applying the fix, we have not seen the storage leak again. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. You either have not enough local page datasets for your workload or there are one or more address spaces that are chewing up your auxiliary storage. Coupled with that you are dangerously close to full on your common page dataset. Plan of action : (1) Increase size of common page dataset (I would double the size) (2) Find out if you have some greedy address spaces that are using up all of your local page datasets (a) RMF Monitor III can tell you this - see the STORF report (b) If you don't have RMF III running - there are some freeware tools that can help (MXI for example from www.rs.com) (3) If (2) proves that there are no obvious problems - allocate some more page datasets and PAGEADD them or IPL (remember to update the IEASYSxx member) Rob Scott Rocket Software, 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: Missing fixes
Both PTFs show a status OPEN. They must be still building them. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Wednesday, February 07, 2007 3:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Missing fixes I just get held by two APARs: AK34959 and AK33471. Those APARs can be found ...under PK34595 and PK33471. I guess PKn is APAR number, and AKn is APAR fix number. Those APAR describe fixes UK21449 and UK21373 respectively. However ...I cannot download those fixes, because IBM system "Download fixes" claims they do not exist. I tried the same on ShopzSeries. UK21373 is available, UK21449 is not. I also tried to make an oredr with PK and AK numbers. Result: not found. I tried ServiceLink: both PTFs are unavailable. Any clue ??? -- Radoslaw Skorupka Lodz, Poland P.S. Both APARs are fresh, both regard MQ 5.3.1 -- 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: JDBC Driver- Problem in DB2 V7.1 PUTLVL0604
Ale, Sorry, I went too fast. The same modules exist in DSN710.SDSNLOD2. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. -Original Message- From: Tergerson, John Sent: Thursday, September 21, 2006 10:48 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: JDBC Driver- Problem in DB2 V7.1 PUTLVL0604 Ale, In our system, libdb2jcct2.so is an alias in /usr/lpp/db2/db2710/jcc/. It points to DSNAQJL1, which is in DSN810.SDSNLOD2. libdb2jcct2zos.so points to DSNAQJL2 in the same library. John >-Original Message- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ale Eba >Sent: Wednesday, September 20, 2006 3:08 PM > >Hello, > > I can't find the dll files libdb2jcct2.so and libdb2jcct2zos.so in /usr/lpp/db2/db2710/jcc/lib. In fact the files don't exist in any directory. DB2 version 7.1 was installed in 2002. All the jobs to define DDDEF entries and to make the directory were run. All PTFs related to JDBC driver are in place (APPLIED). These files are available in DB2 V8.1. > > Is there a way to create these dll files. > > Thanks > Ale -- 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: JDBC Driver- Problem in DB2 V7.1 PUTLVL0604
Ale, In our system, libdb2jcct2.so is an alias in /usr/lpp/db2/db2710/jcc/. It points to DSNAQJL1, which is in DSN810.SDSNLOD2. libdb2jcct2zos.so points to DSNAQJL2 in the same library. John Confidentiality notice: The information included in this e-mail, including any attachments, is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review, use, disclosure, distribution or similar action is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the original message immediately. >-Original Message- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ale Eba >Sent: Wednesday, September 20, 2006 3:08 PM > >Hello, > > I can't find the dll files libdb2jcct2.so and libdb2jcct2zos.so in /usr/lpp/db2/db2710/jcc/lib. In fact the files don't exist in any directory. DB2 version 7.1 was installed in 2002. All the jobs to define DDDEF entries and to make the directory were run. All PTFs related to JDBC driver are in place (APPLIED). These files are available in DB2 V8.1. > > Is there a way to create these dll files. > > Thanks > Ale -- 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: z/OS 1.6 - step-time rounding errors...
Steve, We saw this too. Look at OA06051. Don't despair. John -Original Message- From: Steve Flynn [mailto:[EMAIL PROTECTED] Sent: Friday, May 12, 2006 5:43 AM To: IBM-MAIN@BAMA.UA.EDU Subject: z/OS 1.6 - step-time rounding errors... We upgraded to zOS 1.6 last weekend. On Monday I noticed a job I'd just written was reporting some weird values for elapsed wall-clock time... 16.35.29 JOB05267 -JOBNAME STEPNAME PROCSTEPRC EXCPCPUSRB CLOCK 16.35.29 JOB05267 -CM700DSP KSL 00 769K 1.88.18 34.57 16.35.31 JOB05267 -CM700DSP ANALYSE 00244.01.00 .04 16.35.31 JOB05267 -CM700DSP EMAILSTEP0010 FLUSH 0.00.00 1439.9 That last step flushed, but appeared to take almost 24 hours to do so. I mentioned this to our sysprogs, who said my job was the only one to exhibit this problem. I've just analsysed the weeks archived syslogs, and found that about 34% of our flushed steps are showing the elapsed wall-clock time of almost 24 hours, and I've found another 10,809 ocurrences of this in the syslogs. I'm not sure if this site has modified the exit which produces this figure (I'm not a sysprog, so I'd not know where to look, even if I could understand the source when I found it). Apparenttly, they can finding nothing on teh IBM database for anything resembling this, which makes me think it's a bug in some exit we've modified at this site. Can anyone give me any clues as to where I could look to invesitigate further? -- Steve Despair - It's always darkest just before it goes pitch black... -- 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: Need quick response; display uni command syntax
D UNI,ALL will show the table active in the system. -Original Message- From: Steve Comstock [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 07, 2006 1:33 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Need quick response; display uni command syntax Colleague is teaching our COBOL Unicode class; lab is failing, indication is wrong Unicode conversion tables were installed. Went to z/OS MVS commands; under DISPLAY UNI it says to see the Unicode services doc. Went to the Unicode services doc; for DISPLAY UNI it says to see the z/OS MVS commands doc Yikes!!! Way to go IBM Anyone have full syntax options for DISPLAY UNI? kind regards, -Steve Comstock -- 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: Applicable component levels
0508 indicates the PTF was on PUT tape 0508. For UA19532, the SOURCEID in SMP will show PUT0508 and RSU0512. Radoslaw asked: > -Original Message- > From: R.S. [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 08, 2006 7:23 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Applicable component levels > BTW:I guess the F508 corresponds to 0508 in PSP bucket, column called > VOLID. > I still don't know what it is, why sometimes it is 0508 and sometimes F508. -- 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: Broken VVDS catalog entries
Shane, I have successfully used this to delet a vvds from a volume. //STEP1 EXEC PGM=IDCAMS //DD1DD VOL=SER=MVSSM3,UNIT=3390,DISP=OLD //SYSPRINT DD SYSOUT=* //SYSIN DD * ALTER - CATALOG.MASTER.ZOS - RVOL(MVSSM3) - FILE(DD1) /* John >Anyone got a link to a tool that'll delete a broken VVDS catalog entry ???. -- 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