XCFAS overhead
Hello everybody, I've seen some weird XCFAS behavior in one of our systems recently that I'm trying to understand/explain so I need your help. This used to be a 3 way sysplex on 2 cpcs and everything was fine. The company I work for then decided to outsource it and we kind of lost control over what happens and sometimes we get some not-so-nice surprises. This started to happen on our development image last week; it's a 300mip capped system, so it normally runs at 100% lpar cpu, with a dozen of db2 ddf threads, batch jobs and tso regions. But since then, with appearly the same loads it hungs cpu constrained. Rmf mon3 showed xcfas as the primary cause of cpu wait for every application. Looking further into rmf mon3, I uncovered that isglock access rate increased by 10 times when system was slow; I also found that our sysplex turned to 11 systems with at least 6 of them with production kind of load. My conclusions are: -The capped lpar is suffering and loosing competition on sysplex resources due to it's low priority. -Some hardware/software configuration change is making this (and maybe every) image to make a lot more grs calls. And my questions are: -How adding new images would negatively impact performance on existing ones even if new images do not share files or databases with existing ones? -Can isglock structure be split over several cfs - rmf shows we have 4 cfs active - and can traffic be directed to a specific cf? (I'm almost sure that the answer is NO but I might perfectly be wrong) Thanks a lot in advance for your help, Walter Trovijo Jr. -- 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: Console Password
We are running OS/390 2.10 - we stabilized a long time ago. We have never required a console logon; but are now considering it. Any opinions or experiences on the merits? Hi Cheryl, It depends on how secure is your operating room and how your operators work. If there are several operators running dozens of lpars and issuing commands on several systems at same time you might end up with one logon being used by everyone else in the shift and loosing the control expected by using console logon. In my opinion console logon should be used whenever possible to complement operator's room physical security, but sometimes - as in the example above - it's just not practical and in that case another external controls would better replace or complement console logon; console security has much more to do with operator's organization, training and education than anything else. Walter Trovijo Jr. -- 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: DB2 + ODBC
Hi Michael, First of all I think the best forum to post this question is DB2-L, you'll get better answers there. Anyway, have you tried CURRENTSQLID DSNAOINI parm? I don't have much experience with Mainframe ODBC, here we run most old fashion cobol + static sql, but based on ODBC guide info it seems to be the way to do it. By the way DB2-L is hosted by idugdb2-l.org website. HTH, Walter Trovijo. -- 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: FTP - Put Error - EZA2590E
Hi, We've had a similar problem here in the past. Different platform, but similar symptons. In our case, we had problems ftpying to a wintel machine which in turn was writing data to another machine thru remote shared folder (MS networking); another thing was that remote machine was in a different network, so the connection was going thru routers to the other side. The solution in our case was to zip files on the mainframe before sending, because we found that problem just happens with large file. Also, take a look at apar PQ45544. http://www-1.ibm.com/support/docview.wss?uid=isg1PQ45544 HTH, Walter Trovijo Jr -- 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
