For the archives.... Someone just wrote me about this post from June 2007 and I realized I never followed up in IBM-MAIN.
On Fri, 29 Jun 2007 09:54:00 -0500, Mark Zelden <[EMAIL PROTECTED]> wrote: >On Fri, 29 Jun 2007 09:47:20 -0400, Petersen, Jim ><[EMAIL PROTECTED]> wrote: > >>Wonder if anyone else has experienced this. We just rolled out z/OS >>1.8 to our 1st two Test/Dev LPARs and we have encountered a problem. >>Our DB2 folks were copying a PDSE loadlib and got an IGW message in the >>IEBCOPY followed by recursive S0C4 and S0C1 abends. Essentially, until >>this is resolved, we are stopped dead in our tracks from rolling out >>z/OS 1.8 any further. >> > >Nope. But we rolled out to our biggest development environment this >past weekend. Even though we have several production LPARs running >1.8, this was the one I was most concerned about. Turns out I was right. >We have 2 open LE issues. One is an abend in a PL/I 2.3 program running >in CICS TS 2.3 (also failed in 3.1). Since it was holding up testing of a >regulatory change due to go in this weekend, I almost had to back out >on Tuesday. We were able to STEPLIB to the z/OS 1.6 version of >SCEERUN and use that in DFHRPL to get around the problem. IBM has >since provided a test fix that will get tested today. No APAR number yet, >but there will be one. > This first problem dragged on for a while between IBM LE and CICS support and eventually we found the problem to be caused by an ISV software product (eXpeditor). The vendor had a fix for the problem already but we didn't have it applied. >The other is a LE U4094 reason 18 in a DB2 program in batch. Still haven't >proved it's not an application issue, but the app folks say that pointing >to the production version of the program gets the same failure and this >worked last week. Unfortunately, there is no DB2 data sharing involved >here, so we can't run this on another LPAR in the sysplex that is still 1.6. > >We are still working on getting more diagnostic information for IBM (running >tests with changes to LE options) for the U4094 reason 18. > This was an application problem - actually a JCL problem. One of those cases where a hole was probably closed in LE. The abending program had defined an output file as VB LRECL=6110, BLKSIZE=6144. The output records were actually 458 bytes but the JCL had the DCB coded as DCB=(RECFM=F,LRECL=456,BLKSIZE=456). The programmer fixed the JCL to resolve the problem. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
