Re: Eight-character TSO Userid Support
Re: Eight-character TSO Userid Support One item that has not been mentioned. The 7 char TSO userid was so that when you submit batch jobs it automatically appended 1 char to make a unique jobname to execute. If your TSOID is 8 then and you submitted a batch job it would either have to have 8 char jobname, same and you'd have to logoff for it to run, or something not associated w/ your userid which would require SDSF or 3rd party spool product RACF (SAF) rules to allow you to view it. If jobname becomes 8 that impacts lots of SMF records, RACF(SAF) rules, and lets not forget the 80 character punch card limitation for those pushing for 24 char userids. I know some sites already use TSO batch job names w/o TSOID prefix, but these are still 8 char names that need to be unique. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBM's Omegamon for z/OS
Re: IBM's Omegamon for z/OS IBM did functionally stabilize one of two 3270 interfaces when products had two. In the case of most products this was the CUA in favor of the classic. All OMEGAMONs have a GUI interface which requires a distributed, zLinux for example, portal server. OMEGAMON XE for z/OS and others have made significant enhancements to the classic interface over the years. OMEGAMON XE for Mainframe Networks and Storage do not have a classic interface and therefore their CUA has been continuously improved. I'm not aware of any data in XE for Mainframe Networks that is in the GUI and not in the 3270. * -- 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: IBM's Omegamon for z/OS
Re: IBM's Omegamon for z/OS I have been advised that although OMEGAMON z/OS, CICS and DB2 classic has many updates and OMEGAMON II for Storage CUA has been updated, that OMEGAMON XE for Mainframe Networks CUA has not. The XE TEP GUI has data that is only in the TEPS for Networks as does the XE for z/OS product. In z/OS case its Plex wide data not LPAR specific data. - -- 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 Many OMEGAMON ICATs Can Run At The Same Time?
Re: How Many OMEGAMON ICATs Can Run At The Same Time? You can have an ICAT for every SMPE CSI. Normally you only do this when upgrading and replacing all the OMEGAMONs. You don't want to install each OMEGAMON into a different CSI, there are numerous common components, there would be large DASD waste as well as CPU and time installing the same fix multiple times. Also some of the OMEGAMONs run in the same address space, not possible w/ multiple loadlibs at different levels w/ common code. And ICAT registers the OMEGAMON XE agents /TEMAs with the local Management server (TEMS) this is simple if in same CSI, a multi-step manual process if in a different CSI. dromega...@yahoo.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
Implications of not having CMF or RMF - Urgent
Certainly their must be other software that is optional or other ways to reduce IBM and ISV software license charges, such as WLC or other measured usage charges. Are they taking advantage of specialty engines, zIIPs, zAAPs, IFLs? RMF is a basic part of running a system, your customer has already cut costs by running CMF. Running w/o monitors is like driving w/o an insurance policy. Running w/o basic usage collection is like driving w/ your windows painted black, because you don't know where you've been or where you are going. -- 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: TMON with OMEGAMON Comparison
OMEGAMON and distributed servers: OMEGAMON classic and OMEGAMON II 3270 applications do not require any distributed installs. OMEGAMON XE and DE use a browser to provide a single GUI for mainframe, distributed, Middleware, Systems Workload automation. This GUI is optional, but recommended, and requires a distributed server. This server can be run on Linux on zSeries (IFLs) or on Unix (AIX, HP/UX, Solaris) or Windows. As pointed out earlier MAINVIEW supports its browser and multi-system views from a z/OS based server. OMEGAMON DE includes OMEGAVIEW 3270 which allows for multiple LPAR views. But the browser interface is much more powerfull in that it allows for middleware and distributed to also be viewed for an Enterprise view of business services impact. Some customers view distributed servers as a benefit, they like to offload expensive z/OS MIPS/ MSUs to inexpensive distributed or Linux on zSeries. The Hub TEMS that many of you have on z/OS can be migrated to Linux on zSeries, Unix or Windows and still use LDAP to RACF. If you really want multi-system view and don't have or want to have a distributed box, there is sample code on IBM.com OPAL that allows the browser to directly connect to the z/OS TEMS. This code does provide multi-system views, but is not nearly as robust as the supported code in the Tivoli Enterprise Portal Server (TEPS). For those of you with TBSM, the current version also includes the Tivoli Integration Portal (TIP) which can access OMEGAMON XE data w/o the TEPS. Here is a sample web browser (no applets downloaded) SOAP application on OPAL that provides multiple subsystems on a single screen with access to any data that is in XE. This application returns multiple systems data with subsecond response. Sample application is OMEGAMON XE for z/OS via Web browser IE or Mozilla. WebITM v1.0 A Web Based Demonstration Application using IBM Tivoli Monitoring V6.1 SOAP Services, On OPAL site; http://catalog.lotus.com/wps/portal/topal/results?catalog.c=catalog.searchTerms=IBM+Tivoli+Monitoring+V6.1+SOAP+ServicesgoButton.x=0goButton.y=0catalog.catalogName=Tivoli+OPALcatalog.start=0 -- 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: TMON with OMEGAMON Comparison
Overhead concerns: RE: Did you compare the CPU *consumption* of TMON and OMEGAMON? We come from MAINVIEW and the rise in CPU consumption is tremendous. 1) OMEGAMON vs TMON - Numerous customers have migrated from TMON to OMEGAMON, on average they experience a 10% drop in CPU consumption in the CICS region. This can be measured with SMF records for entire address space, CICS shutdown stats or SMF110 average CPU for transactions. 2) OMEGAMON vs MAINVIEW - Several factors here; are you measuring internal subsystem overhead or external collector overhead. The external address space overhead is small fraction of the total overhead. You need to look at impact to subsystem plus external. The last time a customer reported this to me, we were 5% less in the CICS subsystem. We are also less in the IMS subsystem. If you are only concerned w/ external address space CPU and you are talking about OMEGAMON IMS, I suspect you have historical bottleneck enabled with DASD impact. MAINVIEW doesn't collect this and its extremely expensive. When customers disable this collection parm the external overhead is comparable to MAINVIEW. RE: What TMON can do in a handful of STC's, takes OMEGAMON 3 times as many STC's. Just too much overhead in my opinion. 1) The real concern is how much overhead the monitoring adds to the monitored subsystem, see above. CICS, IMS and DB2 monitors from all vendors increase the cpu in the subsystems, the question is who increases it less. This subsystem impact far exceeds the external address space, except for z/OS monitors. I haven't been concerned with the number of address spaces since I migrated off MVS/SP to XA. Additional address spaces have very little overhead associated with them, they provide the flexibility to have different dispatching priorities based on the criticality of the address spaces function, like if it not being dispatched could impact the monitored address space. RE: Does Omegamon/CICS support the new SMF 110 compressed format, introduced with CTS 3.2 ? Yes, OMEGAMON provided day 1 support for this. -- 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
