Re: Convert DB2 on z/OS to UDB on z/Linux
Yes, in many situations there is an increased "wire length." In many situations it's unavoidable. But if the goal is to reduce costs, it's very important to take proximity into account. If you cut your DB2 license fee by 30% but triple your CICS and z/OS license fees, most rational people wouldn't take that trade. If you cut your DB2 license fee by 30% but increase your CICS and z/OS license fee by 10%, then more investigation may be merited. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Java availability
On Thu, 3 Sep 2009 09:41:09 -0400, Dazzo, Matt wrote:
>Thanks Dave.
>
>Does anyone know if there is any kind of sample pgm provided by ibm that
will perform a java call from the mvs environment? Thanks Matt
>
>
>The response from the 'java -version' command is pasted below. Does
>this verify that java is not only installed but available should an
>application make a java call? I am trying to determine if I need to do
>additional configuring. Thanks Matt
>
>java version "1.6.0"
>Java(TM) SE Runtime Environment (build pmz6460sr3-20081108_01(SR3))
>IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 z/OS s390x-64
>jvmmz6460-20081107_254
>33 (JIT enabled, AOT enabled)
>J9VM - 20081105_025433_BHdSMr
>JIT - r9_20081031_1330
>GC - 20081027_AB)
>JCL - 20081106_01
>
>
You can use JZOS on your level of JDK. It's very neat. Here's a sample but
you'll have to use your version of JAVA_HOME.
//JAVA EXEC PROC=JVMPRC60,
// JAVACLS='HelloWorld'
//STDENV DD *
# This is a shell script which configures
# any environment variables for the Java JVM.
# Variables must be exported to be seen by the launcher.
. /etc/profile
export JAVA_HOME=/products/Java/V6
export PATH=/bin:"${JAVA_HOME}"/bin
LIBPATH=/lib:/usr/lib:"${JAVA_HOME}"/bin
LIBPATH="$LIBPATH":"${JAVA_HOME}"/lib/s390
LIBPATH="$LIBPATH":"${JAVA_HOME}"/lib/s390/j9vm
LIBPATH="$LIBPATH":"${JAVA_HOME}"/bin/classic
export LIBPATH="$LIBPATH":
# Customize your CLASSPATH here
APP_HOME=$JAVA_HOME
CLASSPATH=$APP_HOME:"${JAVA_HOME}"/lib:"${JAVA_HOME}"/lib/ext
# Add Application required jars to end of CLASSPATH
for i in "${APP_HOME}"/*.jar; do
CLASSPATH="$CLASSPATH":"$i"
done
export CLASSPATH="$CLASSPATH":
# Set JZOS specific options
# Use this variable to specify encoding for DD STDOUT and STDERR
#export JZOS_OUTPUT_ENCODING=Cp1047
# Use this variable to prevent JZOS from handling MVS operator commands
#export JZOS_ENABLE_MVS_COMMANDS=false
# Use this variable to supply additional arguments to main
#export JZOS_MAIN_ARGS=""
# Configure JVM options
IJO="-Xms16m -Xmx128m"
# Uncomment the following to aid in debugging "Class Not Found" problems
#IJO="$IJO -verbose:class"
# Uncomment the following if you want to run with Ascii file encoding..
#IJO="$IJO -Dfile.encoding=ISO8859-1"
export IBM_JAVA_OPTIONS="$IJO "
//
cheers
Peter
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: "file integrity verified" - do I care?
let's take some possibilities. 1. the verify succeeds - there are no hanging end of file or paritial splits or fatal errors. wha happened to the blocks that had not been written to dasd yet - well, they are gone into the bit bucket in the sky. 2. the verify succeeds - and operations is rerunning the exact same job - some of the updates are going double update - some inserts will fail as duplicate, totals have wrong values. status 97 means that a job abended and nothing has been done to recover the file. That is usually not a good thing. -- Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
"file integrity verified" - do I care?
Warning: This is another one of my "bitchy" messages complaining about things that people have been "getting along" with for many years. You have been warned, so please don't complain back to me if you think I'm concerned over nothing. Just don't read the rest of the message if this bothers you. Some Cobol programmers know about the dreaded "status 97" issue. Essentially, if a KSDS is opened for I-O and the job is cancelled before the file is successfully closed then the next time the file is opened VSAM will do an implicit VERIFY. If the VERIFY succeeds then a file status of '97' (rather than '00') is returned to the Cobol program. From what I can tell from googling, if the file *is in fact damaged* then it will not return '97' but will rather return a different file status, one that indicates the file was not succesfully opened. I've not been able to recreate the latter situation, so I'm not sure what file status that would be. All this being said, the point is that this file status of 97 is the "same" as status 00, except that status 97 indicates that not only was the file opened successfully but an implicit VERIFY was also completed successfully. The question I have is, "why do I care?" Of what benefit is it for me, as a Cobol programmer, to know this information. Should I be doing something with it? Already on the syslog do we see messages such as this: IEC161I 056-084,VSAMIO,STEP00,FILE1,,,FJS.MYKSDS,FJS.MYKSDS.DATA, 744 IEC161I CATALOG.USERCAT.PPCAT IEC161I 056-084,VSAMIO,STEP00,FILE1,,,FJS.MYKSDS,FJS.MYKSDS.INDEX, 745 IEC161I CATALOG.USERCAT.PPCAT IEC161I 062-086,VSAMIO,STEP00,FILE1,,,FJS.MYKSDS,FJS.MYKSDS.DATA, 746 IEC161I CATALOG.USERCAT.PPCAT That's fine. But is there something I should be doing? I can't think of anything. So my question now is, why should status 97 even exist? The Cobol standard says that any file status with the first of the two characters being the character '0' was a successful I/O. According to the Cobol 2002 standard (I don't have the Cobol 85 standard available): "Certain classes of I-O status values indicate fatal exception conditions. These are: any that begin with the digit 3 or 4, and any that begin with the digit 9 that the implementor defines as fatal." So in this case IBM has chosen to make status '97' not only "not fatal", but in fact absolutely successful. I am unable to determine of the standard actually allows a '9' error to be considered successful, or if it should only be a non-fatal or fatal error. Anyway, the point(!) to all of this is I would like to make a requirement to IBM Enterprise Cobol to have an option to no longer set a file status of 97 when this occurs, but rather to set the file status to 00. While it would be nice to say that we simple handle 97 the same as 00, this is not the case. We are a VSE shop migrating to z/OS, and while '97' is documented as a possibility, I can't recall a time that we ever actually got one. I have tried doing things to cause it to occur on VSE (such as canceling and flushing the job) but it never occurs. In any case I dare say 90% of our programs do not "expect" a file status of 97. So since 97 doesn't seem to be useful I am trying to make sure it never occurs. Thus the requirement. In our testing we've already run in to it several times. Yes, I realize we "should" simply change the programs to conform to the IBM compiler. But my feeling is that it's the status 97 that does not "conform" to the Cobol standard, so Enterprise Cobol should, as an option at least, be made to conform, and thus eliminate our need to conform to a non-conforming implementation. (And even if status 97 does technically conform, it's still annoying. ) Any thoughts? It is interesting to note that at the assembler level this situation appears to *not* cause the OPEN macro to set R15 to something other than 0. The VSAM feedback code (ACBERFLG?) is set to 118 (X'76'), but that is it. R15 is set to 0. With Cobol, along with the FILE STATUS code of 97 I also get: VSAM return code 0008 VSAM function code VSAM feedback code 0076 This seems to say that VSAM set R15 to 8, but the assembler program I wrote to test this shows R15=0. (I am not an assembler programmer, so I could have screwed it up. I'd be glad to post it if anyone wants to validate it.) So is the Cobol runtime "making up" this VSAM return code of 8? Hmmm... What do assembler programs generally do? Do you assume if the open returned a 0 that you're good to go? Do you ever check ACBERFLG if the I/O was successful (R15=0)? I'd be fine with the "VSAM status" codes still being set (if the program has specified to receive them) as long as the primary status code is 00. (Yes, currently the VSAM status code field is "undefined" if the primary status code is set to 00. I do
Re: How often IPL a production LPAR (any good practice)
On Thu, 3 Sep 2009 15:11:50 -0500, Chris Craddock wrote: >Yeah, yeah I know. I know. There will be spluttering replies about "software >bills, yada yada" - trust me I've heard it all. My question back is, if >you're paying for a high availability platform and not leveraging it, what >was the point? > Hear, Hear! cheers Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SWAREQ UNAUTH=YES S0C1 ?1.10?
Yes the book says 31. I finally fixed the code with LARL R3,LABEL get address for second BSM BSM R3,0 save the mode bit SAM31 , go to 31 bit mode LAR1,1608(,R4) begin SWAREQ MF=(E,...),UNAUTH=YES LAR13,0(,R13) L R15,16 L R15,296(,R15) L R15,100(,R15) L R15,88(,R15) BALR R14,R15 end SWAREQ generated code ORG *-2 prevent silly S0C1? BASRR14,R15 prevent silly S0C1? BSM 0,R3 put back original mode LABEL DS 0H Now I have to fix the fix - the returned pointer (SIOT) is now above the line. Sigh! All systems zOS 1.10 (except the sandbox(s?) on 1.11 which doesn't run this code). Thanks for helping me think the unthinkable. IBM Mainframe Discussion List wrote on 09/03/2009 04:24:36 PM: > Chris Craddock wrote: > > It wouldn't matter anyway. Neither of those changes the amode. That would > > require BASSM, or BSM or in z architecture, SAM. Is SWAREQ documented to > > allow 24-bit mode callers? (I really don't know without looking it up) > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a490/15.1.1 > AMODE=31 is required. > Edward E Jaffe - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Convert DB2 on z/OS to UDB on z/Linux
Hi Frank, I'm very much out of my depth in this area so I'm very grateful for the input I've received from you and others. Thanks! Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/SIM/simplist.htm > Date: Thu, 3 Sep 2009 14:57:00 -0600 > From: frank.swarbr...@efirstbank.com > Subject: Re: Convert DB2 on z/OS to UDB on z/Linux > To: IBM-MAIN@bama.ua.edu > > In their defense one might note that all other database clients also travel > said "long path" from the client to the database. So while z/OS -> DB2 z/OS > has it's advantage, it's not like said "longer path" is not being used > elsewhere. And if they have the database in an IFL it can use hipersockets. > Still not as fast as staying within z/OS, but faster than over a real network. > > Frank > > On 9/3/2009 at 7:22 AM, in message > , Dave Salt > wrote: >> Hi Timothy, >> >> My friend is in North America, but I'll pass your message on to him so he >> can pass it on to his management. >> >> I agree with you about "stretching the wire length", and it would certainly >> be a concern if it were me making the decision. Not just because of the >> increase in time, but also the possible points of failure. But, my friends >> management doesn't seem to have the same concern. >> >> Thanks again, >> >> Dave Salt >> >> SimpList(tm) - try it; you'll get it! >> http://www.mackinney.com/products/SIM/simplist.htm >> >> >> >> >> >> >>> Date: Thu, 3 Sep 2009 14:59:25 +0900 >>> From: timothy.sipp...@us.ibm.com >>> Subject: Re: Convert DB2 on z/OS to UDB on z/Linux >>> To: IBM-MAIN@bama.ua.edu >>> >>> Dave, >>> >>> Probably all companies (mine included) have the goal to reduce costs, made >>> more urgent in the present economic conditions. So that makes sense. >>> >>> I don't know if your friend's company is located in my part of the world >>> (Asia), but if so he should feel free to contact me offline. If he's >>> elsewhere I can probably provide a referral, if that's helpful. It's rare >>> that I don't find some reasonable cost-reducing options. My only condition >>> is that I get a shot at looking at the total business picture (or at least >>> closer to that), because the more I have to work with the more (and more >>> useful) ideas I can suggest. >>> >>> Said another way, if someone says to me, "Make my mainframe cheaper," well, >>> that's easy: unplug it and sell it on eBay. Presumably that isn't going to >>> be a very successful business strategy, however. As another example, my >>> company might figure out a way to cut the paper budget to zero, whereupon >>> none of the salespeople can write or execute contracts. Or cut the >>> telephone budget to zero, whereupon nobody can talk with any (quickly >>> former) customers. The business context is important to understand, and I'm >>> much more useful (and helpful) when the question is, "How can I make my >>> business run more efficiently?" And if part of the answer to that question >>> is, "Don't run (x) on (y)," I'll say so. >>> I think most of their programs are written in COBOL, with perhaps a, few written in Assembler, all running on z/OS. I know they use some stored procedures, but I don't know how many or what for. I'd guesstimate they have about 100 developers if that gives you some idea of size. >>> >>> OK, that's a good "feel." I assume it's a reasonably generous mix of OLTP >>> and batch as well. >>> >>> Assuming there's a magic wand that could be waved that would (with zero >>> cost/risk/time) allow these applications to run with another database, one >>> technical question I would look at carefully would be the forecasted CPU >>> increase, particularly on the application side. The present connections >>> between those applications and the database is intra-LPAR I assume, and >>> presumably that's reasonably well optimized. As you stretch the "wire >>> length" between those two tiers it'll tend to increase CPU on both sides, >>> other things being equal. So I'd want to find out how much that proximity >>> effect is. >>> >>> - - - - - >>> Timothy Sipples >>> IBM Consulting Enterprise Software Architect >>> Based in Tokyo, Serving IBM Japan / Asia-Pacific >>> E-Mail: timothy.sipp...@us.ibm.com >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >>> Search the archives at http://bama.ua.edu/archives/ibm-main.html >> _ >> New: Messenger sign-in on the MSN homepage >> http://go.microsoft.com/?linkid=9677403 >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >> Search the archi
VLF papers and SHARE stickers
For your dining and dancing pleasure. It's pretty slow but it works. You'll get an acrobat.com screen and then it underlines it while the file loads. The SHARE papers are from SHARE 72 and are a good foundation. All the other stuff is crap just lying around chaos manor. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Convert DB2 on z/OS to UDB on z/Linux
In their defense one might note that all other database clients also travel said "long path" from the client to the database. So while z/OS -> DB2 z/OS has it's advantage, it's not like said "longer path" is not being used elsewhere. And if they have the database in an IFL it can use hipersockets. Still not as fast as staying within z/OS, but faster than over a real network. Frank On 9/3/2009 at 7:22 AM, in message , Dave Salt wrote: > Hi Timothy, > > My friend is in North America, but I'll pass your message on to him so he > can pass it on to his management. > > I agree with you about "stretching the wire length", and it would certainly > be a concern if it were me making the decision. Not just because of the > increase in time, but also the possible points of failure. But, my friends > management doesn't seem to have the same concern. > > Thanks again, > > Dave Salt > > SimpList(tm) - try it; you'll get it! > http://www.mackinney.com/products/SIM/simplist.htm > > > > > > >> Date: Thu, 3 Sep 2009 14:59:25 +0900 >> From: timothy.sipp...@us.ibm.com >> Subject: Re: Convert DB2 on z/OS to UDB on z/Linux >> To: IBM-MAIN@bama.ua.edu >> >> Dave, >> >> Probably all companies (mine included) have the goal to reduce costs, made >> more urgent in the present economic conditions. So that makes sense. >> >> I don't know if your friend's company is located in my part of the world >> (Asia), but if so he should feel free to contact me offline. If he's >> elsewhere I can probably provide a referral, if that's helpful. It's rare >> that I don't find some reasonable cost-reducing options. My only condition >> is that I get a shot at looking at the total business picture (or at least >> closer to that), because the more I have to work with the more (and more >> useful) ideas I can suggest. >> >> Said another way, if someone says to me, "Make my mainframe cheaper," well, >> that's easy: unplug it and sell it on eBay. Presumably that isn't going to >> be a very successful business strategy, however. As another example, my >> company might figure out a way to cut the paper budget to zero, whereupon >> none of the salespeople can write or execute contracts. Or cut the >> telephone budget to zero, whereupon nobody can talk with any (quickly >> former) customers. The business context is important to understand, and I'm >> much more useful (and helpful) when the question is, "How can I make my >> business run more efficiently?" And if part of the answer to that question >> is, "Don't run (x) on (y)," I'll say so. >> >>>I think most of their programs are written in COBOL, with perhaps a, >>>few written in Assembler, all running on z/OS. I know they use some >>>stored procedures, but I don't know how many or what for. I'd >>>guesstimate they have about 100 developers if that gives you some >>>idea of size. >> >> OK, that's a good "feel." I assume it's a reasonably generous mix of OLTP >> and batch as well. >> >> Assuming there's a magic wand that could be waved that would (with zero >> cost/risk/time) allow these applications to run with another database, one >> technical question I would look at carefully would be the forecasted CPU >> increase, particularly on the application side. The present connections >> between those applications and the database is intra-LPAR I assume, and >> presumably that's reasonably well optimized. As you stretch the "wire >> length" between those two tiers it'll tend to increase CPU on both sides, >> other things being equal. So I'd want to find out how much that proximity >> effect is. >> >> - - - - - >> Timothy Sipples >> IBM Consulting Enterprise Software Architect >> Based in Tokyo, Serving IBM Japan / Asia-Pacific >> E-Mail: timothy.sipp...@us.ibm.com >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >> Search the archives at http://bama.ua.edu/archives/ibm-main.html > _ > New: Messenger sign-in on the MSN homepage > http://go.microsoft.com/?linkid=9677403 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html >>> The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communicatio
Re: SWAREQ UNAUTH=YES S0C1 ?1.10?
Chris Craddock wrote: It wouldn't matter anyway. Neither of those changes the amode. That would require BASSM, or BSM or in z architecture, SAM. Is SWAREQ documented to allow 24-bit mode callers? (I really don't know without looking it up) http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a490/15.1.1 AMODE=31 is required. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SWAREQ UNAUTH=YES S0C1 ?1.10?
On Thu, Sep 3, 2009 at 2:59 PM, Kirk Talman wrote: > A utility macro that issues SWAREQ UNAUTH=YES has abended w/S0C1 because > it was used in 24 bit mode. IFA says at the BALR R14,R15 but I think the > problem is the BR R14 returning. > > The macro is used in multiple places/programs. This is the first abend. > It is hard to believe the utility that abended had not been used before > this w/zOS 1.10? Has anyone else seen/heard of this? Any idea why BALR > used instead of BASR? > It wouldn't matter anyway. Neither of those changes the amode. That would require BASSM, or BSM or in z architecture, SAM. Is SWAREQ documented to allow 24-bit mode callers? (I really don't know without looking it up) -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
...well not be be a broken record, but one of the major selling features of sysplex is not making IPL-ing an image any less necessary (they are what they are) but in making them invisible (or nearly invisible) to the business. With proper configuration you can take down an image, apply maintenance and restart the image while work continues merrily along on the other images in the plex. ...and of course you can't do that if you are still operating in 1989-compatibility mode and have applications bound to specific images in the plex and/or if you don't have enough headroom to allow the remaining images to pick up the load. The really really embarrassing part about this is, z/OS on its own is not even CLOSE to a high availability system. Sorry if that bursts anybody's bubble but it isn't. So if you are still operating in 1989-compatibility mode and IPL-ing weekly or bi-weekly, then even without incurring down time or poor service from application issues the business applications on those systems are only getting something like 99.5% availability (do the math, it's easy) which is a far cry from the "five nines" that parallel sysplex is designed to allow. Yeah, yeah I know. I know. There will be spluttering replies about "software bills, yada yada" - trust me I've heard it all. My question back is, if you're paying for a high availability platform and not leveraging it, what was the point? -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SWAREQ UNAUTH=YES S0C1 ?1.10?
A utility macro that issues SWAREQ UNAUTH=YES has abended w/S0C1 because it was used in 24 bit mode. IFA says at the BALR R14,R15 but I think the problem is the BR R14 returning. The macro is used in multiple places/programs. This is the first abend. It is hard to believe the utility that abended had not been used before this w/zOS 1.10? Has anyone else seen/heard of this? Any idea why BALR used instead of BASR? - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What happens in a DS8000 Metro Mirror (PPRC-Sync) config when the relationship between a volume pair is broken?
thanks Bill. jan >- Oorspronkelijk bericht - >Van : Bill Fairchild [mailto:bi...@mainstar.com] >Verzonden : donderdag , september 3, 2009 04:03 PM >Aan : IBM-MAIN@bama.ua.edu >Onderwerp : Re: What happens in a DS8000 Metro Mirror (PPRC-Sync) config when >the relationship between a volume pair is broken? > >My comments were based on my experience with a 9390 model 6 control unit. I >don't know what the exact mapping is on a DS8000. > >Bill Fairchild > >Software Developer >Rocket Software >275 Grove Street * Newton, MA 02466-2272 * USA >Tel: +1.617.614.4503 * Mobile: +1.508.341.1715 >Email: bi...@mainstar.com >Web: www.rocketsoftware.com > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of >Jan Vanbrabant >Sent: Wednesday, September 02, 2009 2:50 PM >To: IBM-MAIN@bama.ua.edu >Subject: Re: What happens in a DS8000 Metro Mirror (PPRC-Sync) config when the >relationship between a volume pair is broken? > >Hi Bill, thanks! >Re. <later will require the copying of all 15 tracks on cylinder X. If a fully >populated EAV is ever available in beaucoup years from now, it will have 16 to >the 7th power cylinders (ca. 268 million), and it will need the same number of >bits, which is 33.5 million bytes. Maybe by then each bit will represent 1,000 >cylinders. >>> > >Is the bitmap on cylinder level, or on track level? >SG24-6787-04 DS8000 Copy Services for IBM System z (6 Februari 2009) >pag. 213 paragraph 15.2? Volumes are in the suspended state when the primary >and secondary storage subsystems cannot communicate anymore, or when the Metro >Mirror pair is suspended manually. In this state, writes to the primary volume >are not mirrored onto the secondary volume. The secondary volume becomes >out-of-sync. During this time, Metro Mirror keeps a bitmap record of the >changed tracks in the primary volume. Later, when the volumes are >re-synchronized, only the tracks that were updated will be copied. >Thruout the redbook at several places, it's always tracks who are mentioned in >relationship with the bitmap. >??? >Jan > > > > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
>I think a distiction needs to be made between "applying maintenance" and >simply changing some things. Applying SMPE maintenance to a running system >can be a very Bad Idea. I meant more along the lines of SMP/E. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 回覆：Re: 回 覆：Re: paging in rates and r eal m emory
Chris, Yes I know that. That is what I meant when I said "repeatedly paged out with a bit flick." Stolen with a bit flick would have been a more accurate description :-) Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Chris Craddock > Sent: Thursday, September 03, 2009 7:24 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] 回覆：Re: 回 覆：Re: paging in rates and r eal m emory > > 2009/9/3 Ron Hawkins > > > Tommy, > > > > > > Someone correct me if I'm wrong, but aren't unchanged pages selected for > > Page-out first? > > > > UN changed pages are simply stolen. There's no point in paging them out > since by definition they either have never been referenced, or there is a > valid copy already out on AUX. I am still less than convinced the OP has a > paging problem sufficiently large enough to stall CICS. But without looking > at his system "I know nothing". > > > CC > -- > This email might be from the > artist formerly known as CC > (or not) You be the judge. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
>Are there any IMS TM shops out there that only IPL once a month or once a >quarter? I used to work at a Canadian bank that used IMS (FF & FP), and we went as long as 6 months without IPL's in production. This was 2.10 & V3. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LLA Update
Peter, Myself and many others (refer to posts) have been caching directories of normal PDS almost to the day that "Library LookAside" replaced "Linklist LookAside." On heavy TSO systems it was common practice to put just about everything in the TSO login Proc into LLA to reduce IO rates on the SYSRES. Other posts on this thread confirm having non-Load Library directories cached by LLA is still a common function. I will agree with you that it is LLA that measures Fetch performance and loads/unloads modules into VLF or SMSPDSE addresses, but that is in addition to the directory caching function of any PDS or PDSE cached in LLA using the FREEZE function. You could say that it manages only load modules, but it also freezes and caches any directory. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Peter Relson > Sent: Thursday, September 03, 2009 7:57 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] LLA Update > > >but i'm not necessarily talking about load modules. > > >To improve performance you can put several librarys (PDS/PDSE) to be > >managed by LLA, as SYSPROC concatenation for example. That can be edited. > > LLA manages only load libraries (whether PDS or PDSE). > > You are perhaps thinking of VLF which is exploited by LLA (and others, such > as TSO/E clists) > > >But LLA does not many modules. It manages directories! > > That's an interesting, but incorrect, statement (even presuming "many" was > supposed to be "manages"). > > LLA manages the directories of load libraries as well as modules within > those libraries.. > > It is conceivable you could get away with directing LLA to manage the > directories of non-load-libraries, but that is not LLA's documented > function. > > Peter Relson > z/OS Core Technology Design > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
>I can remember the day when a weekly IPL was almost mandatory. But that was >long ago. When I started, as an operator, we had a 2-hour window every day -- the trains stopped runnin until the IPL was complete. I didn't see weekly IPL's until we went to XA a few years later -- I was out of ops by then. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 回覆：Re: paging in rates and real memory
Hal, Your 0.1 ms relies heavily on good cache hits. Page-ins are rarely good cache candidates in an LRU system. Cache miss means at a minimum there will be rotational latency delay, and transfer time from disk to cache, so there's an average of 2ms and up to 4ms of disconnect time. There is certain to be inter-volume seeking which on average is 3ms and up to 7ms. When I said an average of 3ms I was not talking about disk response time. Allowing for the fact that without any queuing, response time for a cache miss will usually have a disconnect time of 6ms or more on a 15K RPM drive. Page resolution time can better than 6ms because there can be multiple pages in a page-in IO. If the back-end of your storage is suffering any sibling pend contention for disk drives pr FCAL paths then you can expect Disconnect time to rocket up to 15ms or more very quickly. There is very little multiplexing goes on in the back-end of a storage controller. The arm on the disk drive can only service one IO at a time, and an FCAL path can only transfer data for one disk at a time. Alan Sherkow's paper "Does Your Installation Have Half-second I/O Response Time?" should be required reading for any sysprog that is tasked with doing IO performance. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Hal Merritt > Sent: Thursday, September 03, 2009 9:36 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] 回覆：Re: paging in rates and real memory > > Points well taken. > > I guess I really was talking about a state or long term average. I just pulled > 50 pps out of the air. > > But one can reasonably expect modern DASD to routinely deliver sub millisecond > response times. Indeed, of the 351 online units in my farm, only 17 were > reporting higher than 1 ms. Most were below .5 ms. > > Assuming the rest of your proposed scenario were the case, then we could > reasonably expect 4.5 seconds, not 45. > > We seem to agree that any paging at all is not good for CICS. But I submit > that it is not as deadly as it once was. > > But, again, we don't know much about the OP's environment. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Ron Hawkins > Sent: Thursday, September 03, 2009 2:43 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: 回覆：Re: paging in rates and real memory > > Hal, > > The 50/sec is measured over some interval. If it's a reasonable RMF interval > of 5 minutes, then that's 15,000 page-ins. However, let's say the page-ins > all occurred in a fraction of that time: say 60 seconds and then nothing. > That's a page-in rate of 250/sec for the CICS region. > > Assuming there's a bit of block paging in the mix, so that average time per > page-in is a generous 3ms, that's 45 seconds (3ms*15000) of page-fault time > during which CICS will stall. Not so bad averaged over five minutes, but a > heck of a long time if it was a burst of page-ins in a single minute. > > Back in the days when I had production systems running at 2000 pages a > second, my target for VTAN, CICS and MPP was a DPR of less than 5/sec using > 15 minute intervals in order to stop the phone ringing. I am not surprised > that a DPR of 50/sec may be a real problem for CICS. > > Ron > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of > > Hal Merritt > > Sent: Wednesday, September 02, 2009 11:24 AM > > To: IBM-MAIN@bama.ua.edu > > Subject: Re: [IBM-MAIN] 回覆：Re: paging in rates and real memory > > > > A demand page in rate of 50 or less should barely be noticeable. Why do > you > > think paging is causing you problems? Granted, most agree that an average > page > > rate of zero is where you want to be. But many might argue that z/os can > > deliver satisfactory service levels with paging rates near 100 or even > higher > > (assuming modern high performance DASD). > > > > To answer your question, system paging rates are determined by real > storage. > > You reduce page rates by either increasing real storage or decreasing the > > overall load. > > > > What do you mean when you say 'time out'? > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of > > Tommy Tsui > > Sent: Wednesday, September 02, 2009 4:29 AM > > To: IBM-MAIN@bama.ua.edu > > Subject: 回覆：Re: paging in rates and real memory > > > > Hi all, > > > > Some of our CICS transaction time out becuase of page in. How can I solved > > this problem? add region size or add more real memory? how to control the > > cics use the real or AUX storage? > > > > 12:10 pagin 0 > > Service -- Frame Occup.-- - Active Frames - AUX PGIN MemObj > > Jobname C Class Cr TOTAL ACTV IDLE WSET FIXED DIV SLOTS RATE Frames > > PABCCOLD B ONLCISH 77335 77335 0 77335 773 0 80689 0 > > > > 12:11 pagin 27 > > 0 Service -- Frame Occup.-- - Active Frames - AUX PGIN MemObj > >
Re: Google groups and IBM-MAIN
On Thu, 3 Sep 2009 14:12:51 -0400, Jon Brock wrote: >As long as I have temporarily left lurk mode, has anyone else begun having problems with searching IBM-MAIN posts in Google Groups? I always used it because: a) It kept some load off the archive servers; and b) It was faster anyway. These days, though, it seems as if it has forgotten all of the old posts. > >Jon > A few months ago (maybe a little longer) I noticed that I wasn't getting hits like I did in the past. I get better results by searching for the specific group: group:bit.listserv.ibm-mainwhat_I_want_to_search -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Google groups and IBM-MAIN
As long as I have temporarily left lurk mode, has anyone else begun having problems with searching IBM-MAIN posts in Google Groups? I always used it because: a) It kept some load off the archive servers; and b) It was faster anyway. These days, though, it seems as if it has forgotten all of the old posts. Jon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
(Leaving lurk mode.) I think a distiction needs to be made between "applying maintenance" and simply changing some things. Applying SMPE maintenance to a running system can be a very Bad Idea. (Not that I haven't ever done it.) Changing system parameters, load libraries, linklists, etc. is no big deal. Jon -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Thursday, September 03, 2009 1:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: How often IPL a production LPAR (any good practice) >Who says it's bad practice? A lot of people on this list! >There are many things that cannot be upgraded or maintained without an IPL, >but that doesn't make a bad practice out of those things that do not require >an IPL. No, but applying to something while it's running IS a bad practice! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
>Who says it's bad practice? A lot of people on this list! >There are many things that cannot be upgraded or maintained without an IPL, >but that doesn't make a bad practice out of those things that do not require >an IPL. No, but applying to something while it's running IS a bad practice! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Segmentation offload (was: OA25072 RESOLVE KNOWN ISSUES WITH CATALOG AUTO-TUNING)
YES (on both counts). >>> "Barrett, Dennis" 9/3/2009 11:29 AM >>> You mentioned the segmentation offload fix (for OSA cards). I'm VERY curious to know if anyone has actually worked up the courage to turn this option back on. Are the results worth the extra Zantac required just thinking about it? Dennis Barrett dbarr...@lacledegas.com -Original Message- From: Knutson, Sam [mailto:sknut...@geico.com] Sent: Wednesday, September 02, 2009 14:34 Subject: Re: OA25072 RESOLVE KNOWN ISSUES WITH CATALOG AUTO-TUNING Hi, The APAR is not flagged CATBREAKER. If this is really intended to resolve broken catalog issues it seems like it should be. If the dire symptoms you describe are being seen it seems it should be marked HIPER too. That was part of my point that this APAR has been open a LONG time to just close it and turn off the feature rather than fixing it. Even segmentation offload was eventually fixed and recommended to be enabled. The APAR text makes it sound like it was just ineffective at making an improvement or confusing. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:sknut...@geico.com (office) 301.986.3574 (cell) 301.996.1318 "Think big, act bold, start simple, grow fast..." -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Wednesday, September 02, 2009 11:32 AM To: IBM-MAIN@bama.ua.edu Subject: Re: OA25072 RESOLVE KNOWN ISSUES WITH CATALOG AUTO-TUNING - Original Message - From: "Knutson, Sam" Newsgroups: bit.listserv.ibm-main Sent: Wednesday, September 02, 2009 11:13 AM Subject: OA25072 RESOLVE KNOWN ISSUES WITH CATALOG AUTO-TUNING > http://www.ibm.com/support/docview.wss?uid=isg1OA25072 > > I have not seen any big shortcomings with Auto-Tuning here though I am > sure others have. > It seems this is throwing the baby out with the bathwater since it just > completely kills auto-tuning rather than providing a chicken switch for > customers who were unhappy. Anyone seen anything so horrible from catalog > auto-tuning you are happy IBM fired up the time machine and erased it > completely? > Sam, OA20748 has been out there for 2.5 years. IBM recommended disabling AUTOTUNING in that APAR, and I've been doing that ever since. The main problems were broken catalogs and runaway CPU in VLF. We experienced the runaway CPU problem. I'm glad you haven't had any problems, but AUTOTUNING has been BAD from day 1. Tom 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
On Thu, 3 Sep 2009 11:08:49 -0500, Steve R Wolf wrote: >We are a IMS TM shop. IMS has many dependant regions (each in it's own >address spaces). Each night we bounce the regions for DR purposes and >some twice for another purpose. Because the regions use cross memory >services the ASIDs can not be reused. We IPL every Sunday in part due to >the IMS systems (we also have a test IMS in the same system). > >We are z/OS 1.8 so we do not have the health check you mention. Is there >a way to display the available ASIDs at the end of the week to determine >how many ASIDs we would have to add to be able to IPL only once a month? > My IPLINFO, or ASIDLIST or ASIDLRX (REXX version of ASIDLIST which is assembler). Or ShowMVS. >Are there any IMS TM shops out there that only IPL once a month or once a >quarter? > What do you have for RSVNONR specified? It really doesn't cost much below the line common storage (SQA) to increase it - even by a fairly large number (say, 1000). Can you afford to give up 10-15K below the line of SQA? Search the archives for "ASVT math". Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 回覆：Re: paging in rates and real memory
Points well taken. I guess I really was talking about a state or long term average. I just pulled 50 pps out of the air. But one can reasonably expect modern DASD to routinely deliver sub millisecond response times. Indeed, of the 351 online units in my farm, only 17 were reporting higher than 1 ms. Most were below .5 ms. Assuming the rest of your proposed scenario were the case, then we could reasonably expect 4.5 seconds, not 45. We seem to agree that any paging at all is not good for CICS. But I submit that it is not as deadly as it once was. But, again, we don't know much about the OP's environment. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Thursday, September 03, 2009 2:43 AM To: IBM-MAIN@bama.ua.edu Subject: Re: 回覆：Re: paging in rates and real memory Hal, The 50/sec is measured over some interval. If it's a reasonable RMF interval of 5 minutes, then that's 15,000 page-ins. However, let's say the page-ins all occurred in a fraction of that time: say 60 seconds and then nothing. That's a page-in rate of 250/sec for the CICS region. Assuming there's a bit of block paging in the mix, so that average time per page-in is a generous 3ms, that's 45 seconds (3ms*15000) of page-fault time during which CICS will stall. Not so bad averaged over five minutes, but a heck of a long time if it was a burst of page-ins in a single minute. Back in the days when I had production systems running at 2000 pages a second, my target for VTAN, CICS and MPP was a DPR of less than 5/sec using 15 minute intervals in order to stop the phone ringing. I am not surprised that a DPR of 50/sec may be a real problem for CICS. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Hal Merritt > Sent: Wednesday, September 02, 2009 11:24 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] 回覆：Re: paging in rates and real memory > > A demand page in rate of 50 or less should barely be noticeable. Why do you > think paging is causing you problems? Granted, most agree that an average page > rate of zero is where you want to be. But many might argue that z/os can > deliver satisfactory service levels with paging rates near 100 or even higher > (assuming modern high performance DASD). > > To answer your question, system paging rates are determined by real storage. > You reduce page rates by either increasing real storage or decreasing the > overall load. > > What do you mean when you say 'time out'? > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Tommy Tsui > Sent: Wednesday, September 02, 2009 4:29 AM > To: IBM-MAIN@bama.ua.edu > Subject: 回覆：Re: paging in rates and real memory > > Hi all, > > Some of our CICS transaction time out becuase of page in. How can I solved > this problem? add region size or add more real memory? how to control the > cics use the real or AUX storage? > > 12:10 pagin 0 > Service -- Frame Occup.-- - Active Frames - AUX PGIN MemObj > Jobname C Class Cr TOTAL ACTV IDLE WSET FIXED DIV SLOTS RATE Frames > PABCCOLD B ONLCISH 77335 77335 0 77335 773 0 80689 0 > > 12:11 pagin 27 > 0 Service -- Frame Occup.-- - Active Frames - AUX PGIN MemObj > Jobname C Class Cr TOTAL ACTV IDLE WSET FIXED DIV SLOTS RATE Frames > PABCCOLD B ONLCISH 77668 77668 0 77668 773 0 80689 27 > > 12:12 pagin 33 > Service -- Frame Occup.-- - Active Frames - AUX PGIN MemObj > Jobname C Class Cr TOTAL ACTV IDLE WSET FIXED DIV SLOTS RATE Frames > PABCCOLD B ONLCISH 79661 79661 0 79661 774 0 80689 33 > > 12:13 pagin back to 6 > Service -- Frame Occup.-- - Active Frames - AUX PGIN MemObj > Jobname C Class Cr TOTAL ACTV IDLE WSET FIXED DIV SLOTS RATE Frames > PABCCOLD B ONLCISH 81324 81324 0 81324 774 0 80689 6 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -
Re: LLA Update
Thompson, Steve wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Thursday, September 03, 2009 11:01 AM To: IBM-MAIN@bama.ua.edu Subject: Re: LLA Update Peter Relson wrote: LLA manages only load libraries (whether PDS or PDSE). Is that right??? We've used it for eons to cache directories for system CLIST/REXX libraries, MACLIBs, ISPF panels, etc. Are you sure you are not confusing VLF and LLA? VLF does not cache directories. That's LLA's job. The libraries I'm talking about are referenced by CSVLLAxx, not COFVLFxx. Having said that, we do also define and use the IKJEXEC class in VLF. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LLA Update
VLF is the fella that does all that - he maintains a couple of dataspaces for each class "Cxxx" that holds control information (probably including representations of the directory entries) and "Dxxx" that contains the cached versions of the members: For example, from one of our systemns : Dspname Jobname ASID TCB SToken Scope Key FProt CurBlks MaxBlks Real CCSVLLA VLF 001F 008FF5E0 80007DC6 Single 0 No 524287 524287 22 CIGGCAS VLF 001F 008FF5E0 80004384 Single 0 No 524287 524287908 CIKJEXEC VLF 001F 008FF5E0 8000D2BA Single 0 No 524287 524287 73 CIRRACEE VLF 001F 008FF5E0 80005797 Single 0 No 524287 524287 20 CIRRGMAP VLF 001F 008FF5E0 80004B88 Single 0 No 524287 524287 19 CIRRSMAP VLF 001F 008FF5E0 80004686 Single 0 No 524287 524287 18 CIRRUMAP VLF 001F 008FF5E0 80004A87 Single 0 No 524287 524287 54 DCSVLLA VLF 001F 008FF5E0 800010020011 Single 0 No4096 4096 4079 DIGGCAS VLF 001F 008FF5E0 8B02000B Single 0 No1024 1024 1029 DIKJEXEC VLF 001F 008FF5E0 800018020071 Single 0 No 512 512 12 DIRRACEE VLF 001F 008FF5E0 8F02000F Single 0 No4096 4096 67 DIRRGMAP VLF 001F 008FF5E0 8E02000E Single 0 No4096 4096 5 DIRRSMAP VLF 001F 008FF5E0 8C02000C Single 0 No4096 4096 5 DIRRUMAP VLF 001F 008FF5E0 8D02000D Single 0 No4096 4096 19 Rob Scott Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: 03 September 2009 17:01 To: IBM-MAIN@bama.ua.edu Subject: Re: LLA Update Peter Relson wrote: > LLA manages only load libraries (whether PDS or PDSE). > Is that right??? We've used it for eons to cache directories for system CLIST/REXX libraries, MACLIBs, ISPF panels, etc. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LLA Update
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Thursday, September 03, 2009 11:01 AM To: IBM-MAIN@bama.ua.edu Subject: Re: LLA Update Peter Relson wrote: > LLA manages only load libraries (whether PDS or PDSE). > Is that right??? We've used it for eons to cache directories for system CLIST/REXX libraries, MACLIBs, ISPF panels, etc. Are you sure you are not confusing VLF and LLA? Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
We are a IMS TM shop. IMS has many dependant regions (each in it's own address spaces). Each night we bounce the regions for DR purposes and some twice for another purpose. Because the regions use cross memory services the ASIDs can not be reused. We IPL every Sunday in part due to the IMS systems (we also have a test IMS in the same system). We are z/OS 1.8 so we do not have the health check you mention. Is there a way to display the available ASIDs at the end of the week to determine how many ASIDs we would have to add to be able to IPL only once a month? Are there any IMS TM shops out there that only IPL once a month or once a quarter? Regard, Steve Wolf Rockwell Automation 414-382-4308 Mark Zelden Sent by: IBM Mainframe Discussion List 09/03/2009 08:53 AM Please respond to IBM Mainframe Discussion List To IBM-MAIN@bama.ua.edu cc Subject Re: How often IPL a production LPAR (any good practice) On Thu, 3 Sep 2009 08:04:17 -0500, Elardus Engelbrecht wrote: >Mark Zelden wrote: >>There is an issue with long running address spaces (STCs) and SMF in >regards to storage creep if you have interval detail records set. I'm not sure >if there is any CPU impact. Do you have any doc you can point to? > >Look in Health Checker for IEA_ASIDS from z/OS v1.9 and v1.10. > >Groete / Greetings >Elardus Engelbrecht > That check is for depletion of ASIDs. It has nothing to do with CPU creap for long running address spaces or the system in general. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
That must have been subsequent to March of 2001. Everyone remember the *APAR OF DEATH", OW45398? After 51 days of running OS/390 2.10 without an IPL, and all of the sudden, "What happened???" Of course, a few days later I heard the warning from Jerry Ng. But as the song "The Streak" quoted, "It was too late. Ethel (the problem) had already gotten a free shot". :-) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Hal Merritt Sent: Thursday, September 03, 2009 11:18 AM To: IBM-MAIN@bama.ua.edu Subject: Re: How often IPL a production LPAR (any good practice) I can remember the day when a weekly IPL was almost mandatory. But that was long ago. I believe the current technology is to schedule an IPL to implement z/os software changes. If there are no changes, then no IPL. You may run into misbehaving applications that suffer from storage creep, or you may need to reclaim ASID's marked unusable. I think we ran for over a year once with no noticeable issues. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tommy Tsui Sent: Wednesday, September 02, 2009 8:09 PM To: IBM-MAIN@bama.ua.edu Subject: How often IPL a production LPAR (any good practice) Hi all, Is there any concern if we didn't IPL a LPAR over three months. Is there any good practise to follow from IBM. They always replied LPAR never needs IPL because of 24 x 7. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LLA Update
Peter Relson wrote: LLA manages only load libraries (whether PDS or PDSE). Is that right??? We've used it for eons to cache directories for system CLIST/REXX libraries, MACLIBs, ISPF panels, etc. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LLA Update
On Thu, 3 Sep 2009 10:57:17 -0400, Peter Relson wrote: > >It is conceivable you could get away with directing LLA to manage the >directories of non-load-libraries, but that is not LLA's documented >function. > True. But you must be aware that many shops use LLA manage the directories of ISPF libraries in particular. It's been discussed here and on ISPF-L many times.The reasons I did it 10 years ago may not be the same as today with faster dasd, more cache etc., but here is a post of mine from 1997 that described a big benefit in doing so: http://groups.google.com/group/bit.listserv.ibm-main/msg/27c09fac79d43370?hl=en http://tinyurl.com/l75xo2 Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HyperPAV without I/O Priority Management
if we can enable HyperPAV without enabling WLM I/O priority management. We are running (z9BC, z/OS 1.9, USP V) and HyperPav seems to finally run OK without WLM I/O priority management. Of course it took forever to get VION to define the 'aliases' in their box but once they got off the dime, MVS did it's part with no trouble. Jack Kelly 202-502-2390 (Office) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Segmentation offload (was: OA25072 RESOLVE KNOWN ISSUES WITH CATALOG AUTO-TUNING)
You mentioned the segmentation offload fix (for OSA cards). I'm VERY curious to know if anyone has actually worked up the courage to turn this option back on. Are the results worth the extra Zantac required just thinking about it? Dennis Barrett dbarr...@lacledegas.com -Original Message- From: Knutson, Sam [mailto:sknut...@geico.com] Sent: Wednesday, September 02, 2009 14:34 Subject: Re: OA25072 RESOLVE KNOWN ISSUES WITH CATALOG AUTO-TUNING Hi, The APAR is not flagged CATBREAKER. If this is really intended to resolve broken catalog issues it seems like it should be. If the dire symptoms you describe are being seen it seems it should be marked HIPER too. That was part of my point that this APAR has been open a LONG time to just close it and turn off the feature rather than fixing it. Even segmentation offload was eventually fixed and recommended to be enabled. The APAR text makes it sound like it was just ineffective at making an improvement or confusing. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:sknut...@geico.com (office) 301.986.3574 (cell) 301.996.1318 "Think big, act bold, start simple, grow fast..." -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Wednesday, September 02, 2009 11:32 AM To: IBM-MAIN@bama.ua.edu Subject: Re: OA25072 RESOLVE KNOWN ISSUES WITH CATALOG AUTO-TUNING - Original Message - From: "Knutson, Sam" Newsgroups: bit.listserv.ibm-main Sent: Wednesday, September 02, 2009 11:13 AM Subject: OA25072 RESOLVE KNOWN ISSUES WITH CATALOG AUTO-TUNING > http://www.ibm.com/support/docview.wss?uid=isg1OA25072 > > I have not seen any big shortcomings with Auto-Tuning here though I am > sure others have. > It seems this is throwing the baby out with the bathwater since it just > completely kills auto-tuning rather than providing a chicken switch for > customers who were unhappy. Anyone seen anything so horrible from catalog > auto-tuning you are happy IBM fired up the time machine and erased it > completely? > Sam, OA20748 has been out there for 2.5 years. IBM recommended disabling AUTOTUNING in that APAR, and I've been doing that ever since. The main problems were broken catalogs and runaway CPU in VLF. We experienced the runaway CPU problem. I'm glad you haven't had any problems, but AUTOTUNING has been BAD from day 1. Tom 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 回覆：Re: 回 覆：Re: paging in rates and r eal m emory
On Thu, Sep 3, 2009 at 3:23 PM, Chris Craddock wrote: > 2009/9/3 Ron Hawkins > > > Tommy, > > > > > > Someone correct me if I'm wrong, but aren't unchanged pages selected for > > Page-out first? > > > > UN changed pages are simply stolen. There's no point in paging them out > since by definition they either have never been referenced, or there is a > valid copy already out on AUX. I am still less than convinced the OP has a > paging problem sufficiently large enough to stall CICS. But without looking > at his system "I know nothing". > > The OP still hasn't said what sort of time out he is getting for his CICS transactions and what makes him think the problem is down to paging. If it is a CICS timeout then presumably he is getting CICS transaction dumps. If so, what is the CICS abend code. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
I can remember the day when a weekly IPL was almost mandatory. But that was long ago. I believe the current technology is to schedule an IPL to implement z/os software changes. If there are no changes, then no IPL. You may run into misbehaving applications that suffer from storage creep, or you may need to reclaim ASID's marked unusable. I think we ran for over a year once with no noticeable issues. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tommy Tsui Sent: Wednesday, September 02, 2009 8:09 PM To: IBM-MAIN@bama.ua.edu Subject: How often IPL a production LPAR (any good practice) Hi all, Is there any concern if we didn't IPL a LPAR over three months. Is there any good practise to follow from IBM. They always replied LPAR never needs IPL because of 24 x 7. Any comment will be appreciated -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
We IPL our Production boxes once a month, Development twice a month, and our Test whenever we want. This seems to work for us. Our Production is IPLed between 00:00-06:00 on Sunday morning. Thanks. John Eatherly -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
Yeah, same with me when I worked in Manufacturing. A little different in Brokerage..Especially, with "big bucks" flowing thru networks... or Pharm, when NDA are being done and you can't IPL or make changes because of the lost of possible revenue. Regards, Scott J Ford Senior Host Developer www.identityforge.com From: Eric Bielefeld To: IBM-MAIN@bama.ua.edu Sent: Thursday, September 3, 2009 10:55:25 AM Subject: Re: How often IPL a production LPAR (any good practice) When I worked at P&H Mining, we IPL'd every Saturday. That worked very well, as at 6:00 PM they shut down all of the onlines and did backups. To shut down and IPL just added about 15 minutes. One big advantage to IPLing every week is that the operators know how to do it. They deal with it every week. When you IPL once a quarter or less, the operators forget. We were manufacturing, which isn't near as critical to keep the system up 24/7, although occasionally when the factory was really busy, we would skip the IPL because they were running the factory on the weekend also. I think IPLing more regularly keeps some things less fragmented, although I doubt if that causes any real problems. Business need, as several have said, should dictate how often you IPL. Certainly, changing releases of z/OS requires an IPL, and major maintenance should be done with an IPL. Eric Bielefeld Sr. Systems Programmer Milwaukee, Wisconsin 414-475-7434 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LLA Update
>but i'm not necessarily talking about load modules. >To improve performance you can put several librarys (PDS/PDSE) to be >managed by LLA, as SYSPROC concatenation for example. That can be edited. LLA manages only load libraries (whether PDS or PDSE). You are perhaps thinking of VLF which is exploited by LLA (and others, such as TSO/E clists) >But LLA does not many modules. It manages directories! That's an interesting, but incorrect, statement (even presuming "many" was supposed to be "manages"). LLA manages the directories of load libraries as well as modules within those libraries.. It is conceivable you could get away with directing LLA to manage the directories of non-load-libraries, but that is not LLA's documented function. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
When I worked at P&H Mining, we IPL'd every Saturday. That worked very well, as at 6:00 PM they shut down all of the onlines and did backups. To shut down and IPL just added about 15 minutes. One big advantage to IPLing every week is that the operators know how to do it. They deal with it every week. When you IPL once a quarter or less, the operators forget. We were manufacturing, which isn't near as critical to keep the system up 24/7, although occasionally when the factory was really busy, we would skip the IPL because they were running the factory on the weekend also. I think IPLing more regularly keeps some things less fragmented, although I doubt if that causes any real problems. Business need, as several have said, should dictate how often you IPL. Certainly, changing releases of z/OS requires an IPL, and major maintenance should be done with an IPL. Eric Bielefeld Sr. Systems Programmer Milwaukee, Wisconsin 414-475-7434 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Java availability
On Thu, 3 Sep 2009 09:56:31 -0400, Barkow, Eileen wrote:
>
>//S EXEC PGM=BPXBATCH,PARM='SH java /u/eileen/jsamp/HelloWorld'
>//STDOUT DD PATH='/u/eileen/stdout2',
>// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),PATHMODE=SIRWXU
>//STDERR DD PATH='/u/eileen/stderr',
>// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),PATHMODE=SIRWXU
>//
>
Lately, BPXBATCH supports allocating STDOUT and STDERR (but not
STDIN) to JES.
OTRUNC vs. OAPPEND is a matter of author's preference.
Ain't it a bummer that most sites use lower case in home
directory names, but &SYSUID (and `userid`) return upper,
so you can't do '/u/&SYSUID/stdout2' for portability?
Or that there isn't a system symbol, &HOME, akin to &SYSUID?
Or that allocation doesn't support relative path names, so
you could do PATH('./stdout2)? (Assuming, of course that
the initiator sets CWD to HOME and allocation is aware of
the caller's CWD?
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFHSM QUESTION - CHANGING PRIORITY OF RECALL REQUEST
ALTERPRI helps resolve the immediate situation. To reduce similar situations in the future, the ARCRPEXT exit can be used to prioritize requests (such as Recalls, recovers, etc). For example, a recall from a production job can be given a high priority than from a test user. Hope this helps, Chris Taylor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 回覆：Re: 回 覆：Re: paging in rates and r eal m emory
2009/9/3 Ron Hawkins > Tommy, > > > Someone correct me if I'm wrong, but aren't unchanged pages selected for > Page-out first? > UN changed pages are simply stolen. There's no point in paging them out since by definition they either have never been referenced, or there is a valid copy already out on AUX. I am still less than convinced the OP has a paging problem sufficiently large enough to stall CICS. But without looking at his system "I know nothing". CC -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
Mark Zelden wrote: >That check is for depletion of ASIDs. It has nothing to do with CPU creap for long running address spaces or the system in general. We are having problems with some software and operating system which do not release storage properly and that health check (and RMF) helps us to check for it. And this is forcing us to schedule regular IPL (to stay within this topic). You originally said 'storage creep', but I accept what you said about WLM and CPU "creep" due to expanding work queue. If you do get some SHARE info, please be kind to share if you can. Creepy, isn't it? ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What happens in a DS8000 Metro Mirror (PPRC-Sync) config when the relationship between a volume pair is broken?
My comments were based on my experience with a 9390 model 6 control unit. I don't know what the exact mapping is on a DS8000. Bill Fairchild Software Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.4503 * Mobile: +1.508.341.1715 Email: bi...@mainstar.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jan Vanbrabant Sent: Wednesday, September 02, 2009 2:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: What happens in a DS8000 Metro Mirror (PPRC-Sync) config when the relationship between a volume pair is broken? Hi Bill, thanks! Re. <<>> Is the bitmap on cylinder level, or on track level? SG24-6787-04 DS8000 Copy Services for IBM System z (6 Februari 2009) pag. 213 paragraph 15.2? Volumes are in the suspended state when the primary and secondary storage subsystems cannot communicate anymore, or when the Metro Mirror pair is suspended manually. In this state, writes to the primary volume are not mirrored onto the secondary volume. The secondary volume becomes out-of-sync. During this time, Metro Mirror keeps a bitmap record of the changed tracks in the primary volume. Later, when the volumes are re-synchronized, only the tracks that were updated will be copied. Thruout the redbook at several places, it's always tracks who are mentioned in relationship with the bitmap. ??? Jan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Java availability
Java runs under Unix services but it could be run from a MVS batch job using either BPXBATCH or better yet, JZOS. You should have a copy of HelloWorld somewhere or I could send you one. You will not be able to call a java program from a regular Cobol or other language program running directly under MVS. //S EXEC PGM=BPXBATCH,PARM='SH java /u/eileen/jsamp/HelloWorld' //STDOUT DD PATH='/u/eileen/stdout2', // PATHOPTS=(OWRONLY,OCREAT,OTRUNC),PATHMODE=SIRWXU //STDERR DD PATH='/u/eileen/stderr', // PATHOPTS=(OWRONLY,OCREAT,OTRUNC),PATHMODE=SIRWXU // -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dazzo, Matt Sent: Thursday, September 03, 2009 9:41 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Java availability Thanks Dave. Does anyone know if there is any kind of sample pgm provided by ibm that will perform a java call from the mvs environment? Thanks Matt -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jousma, David Sent: Wednesday, September 02, 2009 3:29 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Java availability Yes, Java is available, but to make it "automatically available" without fully qualified pathnames you need to add the java pathname to your PATH environment as well. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dazzo, Matt Sent: Wednesday, September 02, 2009 3:14 PM To: IBM-MAIN@bama.ua.edu Subject: Java availability The response from the 'java -version' command is pasted below. Does this verify that java is not only installed but available should an application make a java call? I am trying to determine if I need to do additional configuring. Thanks Matt java version "1.6.0" Java(TM) SE Runtime Environment (build pmz6460sr3-20081108_01(SR3)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 z/OS s390x-64 jvmmz6460-20081107_254 33 (JIT enabled, AOT enabled) J9VM - 20081105_025433_BHdSMr JIT - r9_20081031_1330 GC - 20081027_AB) JCL - 20081106_01 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
On Thu, 3 Sep 2009 08:04:17 -0500, Elardus Engelbrecht wrote: >Mark Zelden wrote: >>There is an issue with long running address spaces (STCs) and SMF in >regards to storage creep if you have interval detail records set. I'm not sure >if there is any CPU impact. Do you have any doc you can point to? > >Look in Health Checker for IEA_ASIDS from z/OS v1.9 and v1.10. > >Groete / Greetings >Elardus Engelbrecht > That check is for depletion of ASIDs. It has nothing to do with CPU creap for long running address spaces or the system in general. BTW, my comment was in relation to the operating system in general, not a specific subsystem. Although I do know of one WLM problem related to WAS and enclaves that will cause a CPU increase in WLM and that increase will not go away until you IPL. But it isn't "creep". It is due to a work queue that gets expanded and never contracts. A design change is coming to fix that and I was trying to find out at SHARE if it was part of z/OS 1.11 or not. It doesn't appear to be listed in any line items, but I am hoping the change is in there anyway. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Results of 'D OMVS,WAITERS' command changed with maintenance.
We are currently on z/OS 1.10 and are in the process of rolling out some new system maintenance on our development systems (going from about PUT0812 to PUT0905). On the LPARS that are still on the old maintenance if I issue a 'D OMVS,WAITERS' command it always shows that nothing is waiting. If I issue this command on the systems with the new maintenance there are many pages of tasks that show up under OTHER WAITING THREADS as 'IS DOING: Osi Wait'. We are not experiencing any problems, just wondering if anyone else is seeing the same thing? Thanks, Cindy Cindy Mitchell Data Center Infrastructure Services Ozmun Center 3-56B (507)284-8674 mitchell.ci...@mayo.edu _ Mayo Clinic 200 First Street S.W. Rochester, MN 55905 www.mayoclinic.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Java availability
Thanks Dave. Does anyone know if there is any kind of sample pgm provided by ibm that will perform a java call from the mvs environment? Thanks Matt -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jousma, David Sent: Wednesday, September 02, 2009 3:29 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Java availability Yes, Java is available, but to make it "automatically available" without fully qualified pathnames you need to add the java pathname to your PATH environment as well. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dazzo, Matt Sent: Wednesday, September 02, 2009 3:14 PM To: IBM-MAIN@bama.ua.edu Subject: Java availability The response from the 'java -version' command is pasted below. Does this verify that java is not only installed but available should an application make a java call? I am trying to determine if I need to do additional configuring. Thanks Matt java version "1.6.0" Java(TM) SE Runtime Environment (build pmz6460sr3-20081108_01(SR3)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 z/OS s390x-64 jvmmz6460-20081107_254 33 (JIT enabled, AOT enabled) J9VM - 20081105_025433_BHdSMr JIT - r9_20081031_1330 GC - 20081027_AB) JCL - 20081106_01 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Convert DB2 on z/OS to UDB on z/Linux
Hi Timothy, My friend is in North America, but I'll pass your message on to him so he can pass it on to his management. I agree with you about "stretching the wire length", and it would certainly be a concern if it were me making the decision. Not just because of the increase in time, but also the possible points of failure. But, my friends management doesn't seem to have the same concern. Thanks again, Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/SIM/simplist.htm > Date: Thu, 3 Sep 2009 14:59:25 +0900 > From: timothy.sipp...@us.ibm.com > Subject: Re: Convert DB2 on z/OS to UDB on z/Linux > To: IBM-MAIN@bama.ua.edu > > Dave, > > Probably all companies (mine included) have the goal to reduce costs, made > more urgent in the present economic conditions. So that makes sense. > > I don't know if your friend's company is located in my part of the world > (Asia), but if so he should feel free to contact me offline. If he's > elsewhere I can probably provide a referral, if that's helpful. It's rare > that I don't find some reasonable cost-reducing options. My only condition > is that I get a shot at looking at the total business picture (or at least > closer to that), because the more I have to work with the more (and more > useful) ideas I can suggest. > > Said another way, if someone says to me, "Make my mainframe cheaper," well, > that's easy: unplug it and sell it on eBay. Presumably that isn't going to > be a very successful business strategy, however. As another example, my > company might figure out a way to cut the paper budget to zero, whereupon > none of the salespeople can write or execute contracts. Or cut the > telephone budget to zero, whereupon nobody can talk with any (quickly > former) customers. The business context is important to understand, and I'm > much more useful (and helpful) when the question is, "How can I make my > business run more efficiently?" And if part of the answer to that question > is, "Don't run (x) on (y)," I'll say so. > >>I think most of their programs are written in COBOL, with perhaps a, >>few written in Assembler, all running on z/OS. I know they use some >>stored procedures, but I don't know how many or what for. I'd >>guesstimate they have about 100 developers if that gives you some >>idea of size. > > OK, that's a good "feel." I assume it's a reasonably generous mix of OLTP > and batch as well. > > Assuming there's a magic wand that could be waved that would (with zero > cost/risk/time) allow these applications to run with another database, one > technical question I would look at carefully would be the forecasted CPU > increase, particularly on the application side. The present connections > between those applications and the database is intra-LPAR I assume, and > presumably that's reasonably well optimized. As you stretch the "wire > length" between those two tiers it'll tend to increase CPU on both sides, > other things being equal. So I'd want to find out how much that proximity > effect is. > > - - - - - > Timothy Sipples > IBM Consulting Enterprise Software Architect > Based in Tokyo, Serving IBM Japan / Asia-Pacific > E-Mail: timothy.sipp...@us.ibm.com > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html _ New: Messenger sign-in on the MSN homepage http://go.microsoft.com/?linkid=9677403 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: paging in rates and real memory
Shut down other work is the only way that I can think of. Of course, if all you are running is this one CICS region, then you have a real problem on your hands! John McKown Systems Engineer IV IT Administrative Services Group HealthMarketsR 9151 Boulevard 26 ? N. Richland Hills ? TX 76010 (817) 255-3225 phone ? (817)-961-6183 cell john.mck...@healthmarkets.com ? www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarketsR is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. ?The Chesapeake Life Insurance CompanyR, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tommy Tsui > Sent: Wednesday, September 02, 2009 7:52 PM > To: IBM-MAIN@bama.ua.edu > Subject: 回覆：Re: 回覆：Re: paging in rates and real memory > > Hi all, > > We got 5GB in our production LPAR and some of CICS > transactions always time > out because of paging. Is there any other way to improve the > paging rate > instead of add more real memory? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.11 Toleration Maintenance Missing from FIXCAT report
As this topic has some focus, as an addendum to my original query of last week, I would be interested to know how you all review Hiper apars. I use SMP/E ORDER processing every night to get the latest PTFs (and HOLDDATA). Once per week I run some convoluted SAS process (that I inherited) which post processes REPORT ERRSYSMODS and produces a report of hipers for the last week only. I would like to replace this process (and remove my reliance on SAS). Thanks Andrew This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC.Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised and regulated by the Financial Services Authority. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
Mark Zelden wrote: >There is an issue with long running address spaces (STCs) and SMF in regards to storage creep if you have interval detail records set. I'm not sure if there is any CPU impact. Do you have any doc you can point to? Look in Health Checker for IEA_ASIDS from z/OS v1.9 and v1.10. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
On Thu, 3 Sep 2009 00:57:23 -0700, Ron Hawkins wrote: >Tommy, > >The only problem I'm aware is that there may be an increase in CPU time for >most programs and transactions the longer your system is up. I think this >was first suggested by Cheryl Watson after a study back in the late 90s, and >I confirmed that it was happening using SMF from an LPAR that had been up >and running for a few months (six months I think). I do not remember how >much increase there was. > There is an issue with long running address spaces (STCs) and SMF in regards to storage creep if you have interval detail records set. I'm not sure if there is any CPU impact. Do you have any doc you can point to? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.11 Toleration Maintenance Missing from FIXCAT report
On Wed, 2 Sep 2009 23:17:51 -0400, Robert A. Rosenberg wrote: >At 17:01 -0500 on 09/02/2009, Mark Zelden wrote about Re: z/OS 1.11 >Toleration Maintenance Missing from FIXCAT re: > >> >Usually run an apply check also. I >>>do actual Apply on an irregular basis. >>> >> >>For what purpose if you aren't planning on doing the APPLY at that >>point? What does it do for you (other than use system resources)? > >If you have run APPLY, doing an ACCEPT CHECK will warn you of any >SYSMODs that have gone bad since the APPLY so you can check into them >and possibly APPLY the fixing maintenance if available. I tend to do >this so I am aware of any ticking timebombs on my system due to >having applied something that is now on HOLD. > The better and easier way to do that for the last decade (at least) is to use REPORT ERRORSYSMODS. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.11 Toleration Maintenance Missing from FIXCAT report
If you have run APPLY, doing an ACCEPT CHECK will warn you of any SYSMODs that have gone bad since the APPLY so you can check into them and possibly APPLY the fixing maintenance if available. I tend to do this so I am aware of any ticking timebombs on my system due to having applied something that is now on HOLD. That's exactly what REPORT ERRSYSMODS is intended for -- tell you of new HIPERs and any PTFs that have gone PE since your last APPLY. Kurt Quackenbush -- IBM, SMP/E Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
HyperPAV without I/O Priority Management
Hello, We are going to enable HyperPAV in our shop (z10, z/OS 1.9, USP V) and we currently do NOT have I/O priority management enabled. Having read that HyperPAV uses IORP, we were wondering if we can enable HyperPAV without enabling WLM I/O priority management. Does anyone have any experience with this setting? Any help on this matter is appreciated, Nofar -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Ted Kotlowski is out of the office.
I will be out of the office starting 09/03/2009 and will not return until 09/09/2009. I will respond to your message when I return. If your request requires immediate attention, Please contact the MVS Technical Support Hotline at 1-866-866-4488 x12000 ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
Tommy, The only problem I'm aware is that there may be an increase in CPU time for most programs and transactions the longer your system is up. I think this was first suggested by Cheryl Watson after a study back in the late 90s, and I confirmed that it was happening using SMF from an LPAR that had been up and running for a few months (six months I think). I do not remember how much increase there was. I did hit an issue recently where I was purposely failing Storage Controllers and IO Drivers to the controller would just hang and need to be cancelled or forced off the system. After several week of this testing the CPU utilization of the LPAR had more than doubled while generating the same IO rate. We scheduled an IPL and everything was back to normal. It may worth choosing some sample workloads that run at all times of the day and track those over time to see if you are encountering any of these affects to the point that it is pushing your MSU charges up. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Tommy Tsui > Sent: Wednesday, September 02, 2009 6:09 PM > To: IBM-MAIN@bama.ua.edu > Subject: [IBM-MAIN] How often IPL a production LPAR (any good practice) > > Hi all, > > Is there any concern if we didn't IPL a LPAR over three months. Is there > any good practise to follow from IBM. They always replied LPAR never needs > IPL because of 24 x 7. > > Any comment will be appreciated > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
回覆：Re: 回覆：Re: 回 覆：Re: paging in ra tes and real m emory
Thanks all information, I will turn on "critical storage" on WLM and add additional 2G real memory to existing LPAR. Let' see any improvement 在 2009/9/3下午3:29，Ron Hawkins 寫道： Tommy, It is not just the paging rate, but also the time to satisfy those page-ins. If you have all your page datasets on the same paths and parity groups then the page-in time will be elongated by any concurrent requests you have. Someone correct me if I'm wrong, but aren't unchanged pages selected for Page-out first? If my memory is correct then any storage shortage is likely to see the pages from your CICS region repeatedly paged out with a bit flick ahead of other ASID because they are still unchanged on AUX. If you can establish if this is happening then you may be able to resolve the problem using Ted's suggestion for Memory Critical, and bouncing the CICS region to get those pages off the Locals. Failing that, realize that Paging itself is quite cache unfriendly. If you check the cache hit rates on your Locals you'll usually find a very low hit rate, so you are going down to the disk drives to satisfy the page fault. You may want to ask your storage vendor for a Flashdrive try and buy, or try FlashAccess if you have HDS. This would at least speed up resolving the Page Fault enough to prevent the timeouts. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Tommy Tsui > Sent: Wednesday, September 02, 2009 5:52 PM > To: IBM-MAIN@bama.ua.edu > Subject: [IBM-MAIN] 回覆：Re: 回覆：Re: paging in rates and real memory > > Hi all, > > We got 5GB in our production LPAR and some of CICS transactions always time > out because of paging. Is there any other way to improve the paging rate > instead of add more real memory? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 回覆：Re: paging in rates and real memory
Hal, The 50/sec is measured over some interval. If it's a reasonable RMF interval of 5 minutes, then that's 15,000 page-ins. However, let's say the page-ins all occurred in a fraction of that time: say 60 seconds and then nothing. That's a page-in rate of 250/sec for the CICS region. Assuming there's a bit of block paging in the mix, so that average time per page-in is a generous 3ms, that's 45 seconds (3ms*15000) of page-fault time during which CICS will stall. Not so bad averaged over five minutes, but a heck of a long time if it was a burst of page-ins in a single minute. Back in the days when I had production systems running at 2000 pages a second, my target for VTAN, CICS and MPP was a DPR of less than 5/sec using 15 minute intervals in order to stop the phone ringing. I am not surprised that a DPR of 50/sec may be a real problem for CICS. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Hal Merritt > Sent: Wednesday, September 02, 2009 11:24 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] 回覆：Re: paging in rates and real memory > > A demand page in rate of 50 or less should barely be noticeable. Why do you > think paging is causing you problems? Granted, most agree that an average page > rate of zero is where you want to be. But many might argue that z/os can > deliver satisfactory service levels with paging rates near 100 or even higher > (assuming modern high performance DASD). > > To answer your question, system paging rates are determined by real storage. > You reduce page rates by either increasing real storage or decreasing the > overall load. > > What do you mean when you say 'time out'? > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Tommy Tsui > Sent: Wednesday, September 02, 2009 4:29 AM > To: IBM-MAIN@bama.ua.edu > Subject: 回覆：Re: paging in rates and real memory > > Hi all, > > Some of our CICS transaction time out becuase of page in. How can I solved > this problem? add region size or add more real memory? how to control the > cics use the real or AUX storage? > > 12:10 pagin 0 > Service -- Frame Occup.-- - Active Frames - AUX PGIN MemObj > Jobname C Class Cr TOTAL ACTV IDLE WSET FIXED DIV SLOTS RATE Frames > PABCCOLD B ONLCISH 77335 77335 0 77335 773 0 80689 0 > > 12:11 pagin 27 > 0 Service -- Frame Occup.-- - Active Frames - AUX PGIN MemObj > Jobname C Class Cr TOTAL ACTV IDLE WSET FIXED DIV SLOTS RATE Frames > PABCCOLD B ONLCISH 77668 77668 0 77668 773 0 80689 27 > > 12:12 pagin 33 > Service -- Frame Occup.-- - Active Frames - AUX PGIN MemObj > Jobname C Class Cr TOTAL ACTV IDLE WSET FIXED DIV SLOTS RATE Frames > PABCCOLD B ONLCISH 79661 79661 0 79661 774 0 80689 33 > > 12:13 pagin back to 6 > Service -- Frame Occup.-- - Active Frames - AUX PGIN MemObj > Jobname C Class Cr TOTAL ACTV IDLE WSET FIXED DIV SLOTS RATE Frames > PABCCOLD B ONLCISH 81324 81324 0 81324 774 0 80689 6 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dumb Question - Credit Card Number Scanner
Ron Hawkins writes: >I'd probably dump all that and use SAS, but I'm a bigot >for powerful analysis tools. Me too, but that's probably overkill. (And, in fairness, SPSS probably as well.) But they could probably get the job done, yes. I thought of another possible option (and only slightly out of left field): if the data are in DB2 (or could be dumped there), OmniFind Text Search Server for DB2 for z/OS is available at no additional charge. That software can construct a keyword index, and I think it might be controllable enough to steer toward things that look like credit card numbers. Or at least let you search for common card issuer numbers (the first few digits). - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 回覆：Re: 回 覆：Re: paging in rates and real m emory
Tommy, It is not just the paging rate, but also the time to satisfy those page-ins. If you have all your page datasets on the same paths and parity groups then the page-in time will be elongated by any concurrent requests you have. Someone correct me if I'm wrong, but aren't unchanged pages selected for Page-out first? If my memory is correct then any storage shortage is likely to see the pages from your CICS region repeatedly paged out with a bit flick ahead of other ASID because they are still unchanged on AUX. If you can establish if this is happening then you may be able to resolve the problem using Ted's suggestion for Memory Critical, and bouncing the CICS region to get those pages off the Locals. Failing that, realize that Paging itself is quite cache unfriendly. If you check the cache hit rates on your Locals you'll usually find a very low hit rate, so you are going down to the disk drives to satisfy the page fault. You may want to ask your storage vendor for a Flashdrive try and buy, or try FlashAccess if you have HDS. This would at least speed up resolving the Page Fault enough to prevent the timeouts. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Tommy Tsui > Sent: Wednesday, September 02, 2009 5:52 PM > To: IBM-MAIN@bama.ua.edu > Subject: [IBM-MAIN] 回覆：Re: 回覆：Re: paging in rates and real memory > > Hi all, > > We got 5GB in our production LPAR and some of CICS transactions always time > out because of paging. Is there any other way to improve the paging rate > instead of add more real memory? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
Who says it's bad practice? There are many things that cannot be upgraded or maintained without an IPL, but that doesn't make a bad practice out of those things that do not require an IPL. > > Not quite true. > Since it's bad practice to apply maintenance to a running system, you need to > IPL based on your upgrade schedule. > Or, when you change hardware. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
Tommy Tsui pisze: Hi all, Is there any concern if we didn't IPL a LPAR over three months. Is there any good practise to follow from IBM. They always replied LPAR never needs IPL because of 24 x 7. Any comment will be appreciated I IPL prod LPAR every time I change machine (i.e. z9->10) or upgrade z/OS version. Ok, I rarely IPL for PTFs. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
