R: WTOR message routing
I think it's possible coding an asm interface pointing to a particular console-name or console-id (WTOR) and giving this interface to the cobol programmer. She/he will have to change the accept cobol statement using the call to the new assembler routine. I'm not really sure, I should have tried before answering ... But I've not enough time at the moment ... Sorry for this :-) Hope this helps. Best regards. -Messaggio originale- Da: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Per conto di Laine, Rogers Inviato: sabato 13 ottobre 2007 21.05 A: IBM-MAIN@BAMA.UA.EDU Oggetto: WTOR message routing We have two lpars (SYS SYSB) defined in a sysplex running z/os 1.7 We have a Cobol program that runs on the SYSB that issues a two line message from the WTOR. This two line message only appears on the SYSB console along with the reply message. Cool... The reply message also appears on SYSA console since it is in the sysplex. So my question is.. How can I get the two line message to appear on SYSA so the operators know what the outstanding reply is for? The computer operators only monitor the SYSA console. Any ideas or suggestions would be appreciate. Rogers Confidentiality Notice: This E-Mail transmission (and/or the documents accompanying it) may contain information belonging to the sender which is confidential, privileged and/or exempt from disclosure under applicable law. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this E-Mail transmission in error, please immediately notify us by return E-Mail or telephone to arrange for return of its contents including any documents. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU Utilization by GRS
On Fri, 12 Oct 2007 15:05:32 -0400, Lizette Koehler [EMAIL PROTECTED] wrote: -snip/edit- I forgot to add we share all dasd. So everything can see everything. 5 LPAR Parallel Sysplex (2 Prod/2 Devl/1 Sysprog). 2 Physical boxes, and one ICF on each box. z9 has 3 LPARs, 1 Prod, 1 Devl, 1 Sysprog z890 has 2 LPARS, 1 Prod, 1 Devl One is a z9 (3 engines) and the other a z890 (3 engines). GRS=STAR. One master cat and one sysres set. Share all dasd. In Star mode, GRS uses up CPU in proportion to the demands on the function. If no ENQ/DEQ/GQSCAN/ISGQUERY requests arrive, there is very little 'background noise' to drive any CPU utilization. Things to look for in a spike situation: A burst of contention for global resources: - To resolve, the systems involved need to send XCF signals to a contention managing system (for that resource, designated by XES - visible in a dump) and is followed up by activity in the GRS Contention Notification system (visible from D GRS) to signal monitoring software of the event (ENF51). A burst of global GQSCAN/ISGQUERY activity: - Depending on the kind of GQSCAN, a large number of XCF signals will be exchanged between systems and then the requesting system will parse and build the results. A burst of global ENQ activity in a system with 'slow' response time from the CF: - By default, lock requests are issued synchronously to the CF (over time, XES will watch behaviors to determine if requests should be converted to asynchronous), so XES 'spins' the CPU in the requesting address space (GRS) waiting for the results from the CF request. If these times are relatively long, it will appear that the system is spending additional time in GRS. Scott Fagen Enterprise Systems Management -- 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: CPU Utilization by GRS
Lizette, As Scott mentioned, when running in star mode, you may see a CPU spike on the GRS contention notifying system (CNS) when there is a resource contention in the sysplex and the CNS has to issue ENF 51. Try checking whether the system you noticed the CPU spike on is the CNS using a D GRS command. If it is in fact the CNS, you may choose to assign the role a CNS to a different system in the sysplex. You can do that using the SETGRS CNS= command (introduced in z/OS V1R8 i believe). Gil. On 10/12/07, Lizette Koehler [EMAIL PROTECTED] wrote: We are STAR with 5 LPARS (2 Prod/2 Devl/1 Sysprog) 2 Physical boxes, and one ICF on each box. One is a z9 (3 engines) and the other a z890 (3 engines). z9 has 3 LPARs, 1 Prod, 1 Devl, 1 Sysprog z890 has 2 LPARS, 1 Prod, 1 Devl Lizette -- 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: CPU Utilization by GRS
As Lizette wrote: As Scott mentioned, when running in star mode, you may see a CPU spike on the GRS contention notifying system (CNS) when there is a resource contention in the sysplex and the CNS has to issue ENF 51. Is this the case of getting a XES contention response back from XES? (I would assume XES uses its own IXCLOnnn XCF group to resolve FALSE contentions.). I assume the resolution to XES contentions on the GRS Star lock structure appear under the SYSGRSnn XCF group. The above, of course, you can measure using the RMF XCF Report (from 74-2 raw SMF in MY case). BTW I've always thought the IXCLOnnn group name to be particularly USELESS and unmnemonic. Likewise the member names - Mnnn. Imagine the (frequently-observed) case where there are several lock structures - GRS Star, several DB2 Data Sharing Group LOCK1 structures etc. How to tell them apart and to tell which DB2 or IRLM or whatever is generating traffic and to whom? Martin (who's trying to apply some of the principles of DB2 / IRLM Lock Management to a different but possibly analogous GRS Star) Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: IBM's Next Generation Mainframe Processor
This has been a pretty well kept secret, at least in IBM circles. Many did not know of its existence. The '6' comes from its sharing of a lot of engineering with the P6 processor. The designer of the P6 also is the designer of the Z6, at least at the processor level. It was very quietly announced at the HOTCHIPS conference in August. They made the presentation, but were not allowed to talk to the press. It seems engineering was ready before marketing was ready. I was hoping there would be a big splash on it, but so far it is pretty quiet. These comments are from personal knowledge, not from BMC. I don't want anyone to think BMC had advance information. Chris Blaicher -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Post Sent: Saturday, October 13, 2007 12:12 PM To: [EMAIL PROTECTED] Subject: IBM's Next Generation Mainframe Processor If you haven't already seen this, it's worth a look. It's a presentation by Charles Webb of IBM on the next IBM mainframe processor, the z6. (Don't ask me where 6 came from.) The thing that stood out for me was the 4GHz processor speed, but of course there's lots of other very good stuff as well. http://www2.hursley.ibm.com/decimal/IBM-z6-mainframe-microprocessor-Webb .pdf Mark Post -- 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
FW: IBM's Next Generation Mainframe Processor
This has been a pretty well kept secret, at least in IBM circles. Many did not know of its existence. Giggle. Snort! Online since July 2005: http://web.archive.org/web/*/http://www.isham-research.co.uk/mainframe_2008.html (I have to admit I was taken aback that I posted that so long ago.) 17? -- 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
Healthcheck CHECK(IBMCS,CSVTAM_CSM_STG_LIMIT)
CHECK(IBMCS,CSVTAM_CSM_STG_LIMIT) START TIME: 10/11/2007 14:54:56.822133 CHECK DATE: 20050901 CHECK SEVERITY: LOW CHECK PARM: MAXECSA(100M),MAXFIX(100M) ISTH001I CSM FIXED storage max 120M satisfies the owner specified limit of 100M * Low Severity Exception * ISTH002E CSM ECSA storage max 92638K is less than owner specified value 100M Explanation: The Health Checker for z/OS check identified in the preceding Health Checker message determined that the value specified for the maximum CSM storage of the type specified as defined in the CSM Parmlib member IVTPRM00 is less than the minimum value specified for the check. An OWNER specified value is the default value specified within z/OS Communications Server. An INSTALLATION specified value is the value set by overriding the default value using the IBM Health Checker for z/OS MODIFY command or specifying an override value in the HZSPRMxx PARMLIB member. See Health Checker for z/OS User's Guide, chapter 'Managing Checks' for a description of how to override installation parameters. The preceding message might be HZS0001I, HZS0002E, HZS0003E, or HZS0004I depending on the SEVERITY and WTOTYPE attributes of the check. See the 'IBM Health Checker for z/OS HZS messages' chapter of the IBM Health Checker for z/OS User's Guide for more information on these messages. System Action: The system continues processing. However, eventual action might need to be taken to prevent a critical depletion of CSM storage resources. Operator Response: Contact the system programmer. System Programmer Response: The default values in IVTPRM00 are 100M for both FIXED and ECSA. However, IBM suggests that they initially be coded at 120M MAX ECSA and 120M MAX FIXED. Monitor the system for one week with DISPLAY CSM command to determine peak usage. Adjust IVTPRM00 MAX ECSA and MAX FIXED values to 1.5 times the highest value indicated in the DISPLAY CSM outputs. You must adjust your IEASYSxx CSA parameter to include the additional amounts of ECSA that CSM will be using. It is recommended that the CSA parameter in IEASYSxx be at least 20% more than the ECSA value specified for CSM use in IVTPRM00. Problem Determination: Not Applicable Source: z/OS Communication Server Reference Documentation: n/a Automation: n/a Check Reason: CHECK CSM MAXECSA AND MAXFIX ND TIME: 10/11/2007 14:54:56.911942 STATUS: EXCEPTION-LOW 1. A D CSM show D CSM IEE305I DCOMMAND INVALID 2. A D NET,CSM shows D NET,CSM IVT5508I DISPLAY ACCEPTED IVT5529I PROCESSING DISPLAY CSM COMMAND - OWNERID NOT SPECIFIED IVT5530I BUFFER BUFFER IVT5531I SIZE SOURCEINUSE FREE TOTAL IVT5532I -- IVT5533I4K ECSA 556K 148K 704K IVT5533I 16K ECSA 0M 256K 256K IVT5533I 32K ECSA64K 448K 512K IVT5533I 60K ECSA 0M 240K
Re: Datasets that shouldn't be made multi volume
Warning Will Robinson. (SMS CDS, COMMDS), (HSM CDS, journal, PDA, LOG, editlog) , DFPSHCD, TSO and ISPF generated datasets, even if PS (have to look for the fine print), PAGE, SAR Databases, catalogs, just to name a few. You really need to do your home work so as not to get bit on the behind. Terry Traylor charlesSCHWAB TIS Mainframe Storage Management Remedy Queue: tis-hs-mstg (602) 977-5154 WARNING: All email sent to or from this address will be received by the Charles Schwab corporate e-mail system and is subject to archival and review by someone other than the recipient. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of gsg Sent: Friday, October 12, 2007 3:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Datasets that shouldn't be made multi volume What datasets should not be multi-volume? We currently only assign specific datasets a dataclas and everything else defaults to null. We are thinking of creating a default dataclas that will make everything multivolume. Any recommendations will be greatly appreciated. TIA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WTOR message routing
Rogers, WTORs should be queued like any other message. Off the top of my head I can think of a few things you can do/check. If the console on SYSA has MASTER authority than the WTOR should show up in the response to a D R,R,CN=(ALL) command. You could also change the attributes of the console on SYSA (MSCOPE, ROUT) so that it would receive and display the message when it was issued. Peter Fatzinger z/OS Core Components Development and Service -- 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
New NTP (Network Time Protocol) Client Support for System z9 Servers
Big news for IBM-MAINers, I suspect, since this topic has been a hot one here recently IBM introduced Server Time Protocol (STP) as a replacement for the Sysplex Timers (9037s), to move that functionality into the System z itself and eliminate a separate hardware device. STP, an orderable mainframe feature, helps simplify mainframe deployment. STP has a function called ETS (External Time Source). Up until now, the only choice for ETS is a modem dial-out mechanism to contact an external time server in order to obtain accurate time-of-day information. This feature works quite well and is extremely hard to spoof, but many customers were asking for other ETS alternatives that did not require a telephone line and modem. Now IBM has introduced NTP (Network Time Protocol) Client support for ETS on System z9 servers. In theory, any standard NTP server is now eligible to be the time source for System z. In practice, you'll want to make sure that the external time source is known and trusted to provide accurate time-of-day information. For example, you might wish to use a device which obtains time-of-day information from the GPS system (government-run satellites) or from broadcast time references such as WWV and then passes that information via NTP to your mainframe. There are several manufacturers of such devices. For more details on this new functionality, along with a link to a redpaper with additional technical information, please visit: http://www-03.ibm.com/systems/z/pso/stp/ntp.html Please note that System z can already act as an NTP server, with either z/OS (and its SNTPD feature, in z/OS 1.4 and above) or Linux on z. So you can quite easily configure a unified time source for your enterprise. Apologies if you're already aware of this announcement. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- 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
