Re: LPAR Capping
Ted, That's not quite right. RMF CPU busy is 1-(waittime/interval). There is no MVS Busy field: it is actually CPU Wait Time that gets accumulated and CPU busy is calculated from Wait Time. If a Logical Instruction Processor (LIP) is pre-empted, then it is not in a wait state and there is no wait time accumulated even though the LIP is doing nothing. Ron > Every time an image is pre-empted, LPAR assumes that you wanted the rest > of (or > the next) time-slice. So, it is added to the MVS Busy field. > If you are not pre-empted, then nothing is added. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z890 configuratiion question.
McKown, John wrote: We are going to add two new FICON cards to out z890. If you look at the cage, there appears to be I/O slots for them. However, when the CE went into something on the SE to determine the PCHIDs for me, he said that it indicated that there weren't any I/O slots. The z890 book that I have consistantly states that the z890 has 8 STI interfaces. So there should be a place to put the FICON cards. My question is: Does every z890 always have 8 STI interfaces, or should the z890 manual state "up to" 8 STI interfaces? BTW - the "I/O slots" that appear to be possibilities are "domain 3" according to the manual referenced below. Book: "2806 z890 Technical Introduction" SG24-6310 Thanks. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology On page 6 of SG24-6310 is states: "The z890 book supports up to 16 GB/sec of bandwidth for data communication between I/O and memory through up to eight Self-Timed Interconnect (STI) host buses." On page 16: "The logical book structure is show in the Figure 2-3 on page 17. There are up to 8 STI buses to transfer data, and each STI has a bidirectional bandwidth of 2.0 GB/sec." It seems that there are 8 STI links, but that there are 0 STI connections by default and you have to order cards in order to use them. Check out page 38 and page 41 of SG24-6310. On the announcement page: http://www-306.ibm.com/common/ssi/fcgi-bin/ssialias?infotype=an&subtype=ca&appname=Demonstration&htmlfid=897/ENUS104-117 They talk about having 0 to 8 STI's in increments of 2. It seems that there are 8 STI links, but that there are 0 STI connections by default and you have to order cards in order to use them. Check out page 38 and page 41 of SG24-6310. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
GDPS rejustified?AS
http://news.independent.co.uk/business/news/article335867.ece "It has since emerged that the blaze could not have happened at a worse time for the company. Northgate duplicates its clients' information on computers at the site. At around 7am every morning a courier would collect the data on disk to take off site for safe storage. Because the blaze happened at around 6am, before collection, a whole day's worth of data collected on behalf of clients was destroyed." Heh. After over forty-five years of mainframe operations, some a**s haven't even yet realised that automation is best. Sod the Post Office, and sod the couriers - we have enough cheap bandwidth now and enough technology to get the stuff out to a remote duplicate AS IT HAPPENS. What's with this 07:00 crap? Print the article, frame it, and stick it on the wall. "But there is a real risk of losing data. If there is no back-up, the only way to deal with it is to input the lost data again. In some cases this may not be possible." Just a little matter of getting the customer to back to the store, simulate a week's shopping, and let you swipe their card on the basis of pure trust. -- Phil Payne http://www.isham-research.co.uk +44 7833 654 800 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Assembler training / books?/
http://www.kmsitltd.co.uk/page8.html -- Phil Payne http://www.isham-research.co.uk +44 7833 654 800 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Not Responding HTTP Server
Jim Marshall wrote: We are running z/OS V1R6 with Host-on-Demand V7 running within the HTTP Server. We have noticed that the HTTP Server will just stop dispatching tasks. After a while it will return to normal and go for many hours before doing it again (already recycled it a few times). Needless to say the HOD users think the system is down, blow themselves off their session and try to get back on with CICS not knowing they left. T'is ugly. Has anyone experienced this?? We have been working with IBM Level 3 for a few days now trying to figure this out. Thanks Jim Marshall We have seen issues with the HTTP server this a couple of times. One time we found that we were seeing sudden spikes in CPU by other tasks the HTTP server was low priority. We had originally had it for testing only and when we started using it for production, nobody change the performance class. The other issue we have run into is configuring the HTTP server to do reverse lookups to reslove IP addresses to host names. HTTP server get tied up waiting for responses that may never come. However I am a bit confused. Once the user has the 3270 session up and running they should never need to have any contact with the HTTP server. They are straight Tn3270 client talking to the TN3270 server. At least that is how it is in our setup. Heck we can bounce the HTTP server and users with active HOD sessions never even know. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LPAR Capping
From: "Gil Peleg" > At first I used soft-cap. Then I noticed we encounter situations where one > LPAR is being soft-capped, while all the others are not even close to their > defined capacity. From my point of view, this is a poor allocation of > resources (which we are paying for). Obviously, If the LPAR was not > soft-capped (and not hard-capped) it could have used the free MSUs. Seems you are trying to use for the wrong reason. Why don't weightings fulfil your requirements - especially if you are prepared to use the whole box ???. Soft capping is a *financial* contortion, not a technical aid to solving allocation issues. > I would like to see some solution to allow soft-capping the entire box at a > certain amount of MSUs, and then define regular weights to the LPARs. Check the archives - Phil waxed lyrical about possible side-effects of the charging model when it was announced. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Capturing a reply id from a WTOR
> Initially, neither program was authorized. I was using the ARCRPEXT > exit, which, I believe, is not authorized(AC=0), That's a non-sequitur. The exit routine (typically) is NOT linked AC(1) because that is only relevant for job step programs. The exit routine must be loaded from an APF-authorized library, but that is primarily to ensure installation control over the software that gets control in exit points. The exit routine's "authorization" is dictated by what ever environmental state that exists when the exit is entered. Most system exits are entered in supervisor state (and key zero) and are therefore able to do anything they want. I have NO knowledge of HSM, but I would bet large that all of its exits are entered in supervisor state. If so, you have been solving a non-problem, lo these many years. > and letting Control-O > intercept the WTOR message and format the modify command.. ARCRPEXT > runs in the HSM address space Then it almost certainly is entered in sup state... but at a minimum it would be considered an authorized environment, either by JSCBAUTH being set as a result of the AC(1) job step program, or by running in a system key. > and some requests were getting through to > the local HSM, which is a badness. I changed to using a front end to > the IGX00024 exit, so I am now running authorized in the local address > space. Which address space is "the local address space"? The issuer of HRECALL? > This has some rather intriguing side effects. The first is that > I can now stack modify commands. The ARCRPEXT appears to be single > threaded. The second is that, now that I am actually authorized, I may > as well issue the modify myself, instead of having Control-O intercept it. Or you could just bag the whole idea and implement a reliable signaling mechanism between HSM and your STC. > PS. I have read your second e-mail about Pause, Release and Transfer, I > will look into their availability in 1.4(my current environment) and, if > not, play with them in 1.7(my new sandbox). Thanks for the tip. Pause/Release services first became available in (I think) OS/390 2.5, if not earlier. They are available on every currently supported release. They are also a far superior mechanism for signaling between address spaces than dinking around with WTORs and (unserialized!!) ORE chains. You may still need to provide a mechanism for queuing requests from multiple callers unless (as you surmised) the exit is naturally serialized by HSM. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Warning: PTF's require HDS microcode, which is not available until the second week of January.
At 15:40 -0600 on 12/30/2005, Dave Danner wrote about Re: Warning: PTF's require HDS microcode, which is not avai: The problem is not with SMP/E. I've been told that the internal IBM systems that generate enhanced HOLDDATA are not capable of generating ACTION, DEP, etc holds. That is interesting since if you pull the enhanced HOLD data form the Web SiteI think it has ACTION, DEP, and other non-ERROR holds in the stream. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LPAR Capping
You're right Ted. In fact, I really dont want to share CPs with the CF. However, the current soft-papping mechanism only allows to soft-cap an LPAR to a certain amount of MSUs. At first I used soft-cap. Then I noticed we encounter situations where one LPAR is being soft-capped, while all the others are not even close to their defined capacity. From my point of view, this is a poor allocation of resources (which we are paying for). Obviously, If the LPAR was not soft-capped (and not hard-capped) it could have used the free MSUs. I would like to see some solution to allow soft-capping the entire box at a certain amount of MSUs, and then define regular weights to the LPARs. That way, if an LPAR is not hard-capped it can use free MSUs (if there are any), and still not go over the defined capacity limit for the box. Maybe something similar to the way they limit CP processing power on the z/890, only controlled dynamically. Gil. On 12/31/05, Ted MacNEIL <[EMAIL PROTECTED]> wrote: > > You don't really want to share CF CP's, still. > Also, MVS Busy is a rough estimate of latent demand. > Every time an image is pre-empted, LPAR assumes that you wanted the rest > of (or > the next) time-slice. So, it is added to the MVS Busy field. > If you are not pre-empted, then nothing is added. > > Any kind of capping is going to introduce a performance penalty. > With soft-capping, you have to decide if the penalty is worth the software > savings. > If you are meeting SLA's (and saving money), don't worry, be happy! > -teD > Me? A skeptic? I trust you have proof! > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Windows .WMF Vulnerability affects Lotus Notes
_http://www.gcn.com/vol1_no1/daily-updates/37850-1.html_ (http://www.gcn.com/vol1_no1/daily-updates/37850-1.html) Thought you were going to get a nice long trouble free holiday didn't you? Unregistering SHIMGVL.DLL is only partial: _http://blogs.zdnet.com/Spyware/?p=735_ (http://blogs.zdnet.com/Spyware/?p=735) But it's Windows: _http://blogs.zdnet.com/Spyware/?p=736_ (http://blogs.zdnet.com/Spyware/?p=736) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Not Responding HTTP Server
>Has anyone experienced this?? We have been working with IBM Level 3 for a few days now trying to figure this out. I saw if a couple of years ago. In our case, HOD had fallen into the default OMVS service class (the sysprog changed the name and didn't tell me). This was multiple periods, and response became very erratic, and (sometimes) the server connection would disappear. I put it into an 'ONLINE' service class and the problem went away. -teD Me? A skeptic? I trust you have proof! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LPAR Capping
>Lately I am seeing a very large difference between the LPAR BUSY TIME PERC and the MVS BUSY TIME PERC fields in the RMF CPU Activity report. The difference is over 20% at peak hours. This was not the case before I started using "CF capping". >The CF LPAR used to guard MSUs has the highest weight on the machine. Taking under consideration the polling nature of CF LPARs, keeping the CPs busy all the time, I am starting to think this has performance implications I have overlooked before. Does this make sense? Yes. You don't really want to share CF CP's, still. Also, MVS Busy is a rough estimate of latent demand. Every time an image is pre-empted, LPAR assumes that you wanted the rest of (or the next) time-slice. So, it is added to the MVS Busy field. If you are not pre-empted, then nothing is added. Any kind of capping is going to introduce a performance penalty. With soft-capping, you have to decide if the penalty is worth the software savings. If you are meeting SLA's (and saving money), don't worry, be happy! -teD Me? A skeptic? I trust you have proof! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Myopia ...
Ron I doubt that you'll find any company in this country with more than 10 employees without workplace access.. You mean the Brits never established 'post codes' in Hong Kong - pretty slack if you ask me! :-) Oh well another year almost over -- is the time between New Year celebrations getting shorter :-) BTW - you'd think a customer with 20,000 MIPS on the floor and another 17,000 in a warehouse in HKG (waiting for a new data centre) would have some clout with IBM?? Jim S -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ron and Jenny Hawkins Sent: 31 December 2005 17:22 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Myopia ... Of course, this all assumes that customers have workplace access to the internet - not always true in some Asian Countries. Sending a URL to these customers to download info from the internet is pretty much the same as saying "this page intentionally left blank." The assumption the whole world is internet connected is somewhat stupefying. Ron P.S. - then there are the websites that won't let you download without a freaking 5 digit zip code in your address. Hong Kong doesn't have zip codes, post codes or anything that comes close. Now that's North American myopia at its worst... Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Myopia ...
Of course, this all assumes that customers have workplace access to the internet - not always true in some Asian Countries. Sending a URL to these customers to download info from the internet is pretty much the same as saying "this page intentionally left blank." The assumption the whole world is internet connected is somewhat stupefying. Ron P.S. - then there are the websites that won't let you download without a freaking 5 digit zip code in your address. Hong Kong doesn't have zip codes, post codes or anything that comes close. Now that's North American myopia at its worst... > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of ibm-main > Sent: Saturday, 31 December 2005 7:02 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Myopia ... > > > Funny thing is that I'm not sure where these decisions are being made. > Are > > the roadblocks being designed at the corporate level or at the country > level > > to protect the 'local' markets.. > > PacBasin is always last cab off the rank. > We were years behind with Link2000 - Feb 2005 before we were fully > configured. > Shopz is still trumpeting features we are unable to use - that coming from > a > fan of Shopz > > Of course, there may be local limitations added in some cases :) > > > Sadly up here they aren't' pissing off too many people as the customers > > don't know what choices are available (or should be available) to > them. > > Pity - could have some serious leverage. > > > Anyhow have a happy new year down under and go easy on the 'stubbies'... > > Quiet time for me; I'm on call - guess you'll have to wait another month > or > so for local celebrations. > > Shane ... > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
