Re: iasxwr00
Take a look at SRS, available at: http://www.cbttape.org/ftp/adhoc/srs130.zip This is the SAPI sample code that Bob Shannon referred to, but it will do what you need (including the separator records) out of the box without any changes. On Fri, 19 Aug 2011 16:52:14 -0400, techie well wisher techi...@gmail.com wrote: All, Is there a replacement program for iasxwr00 ? I know this is an old program, heard it is also deprecated. Any new prog that does the same function (moving selective spool output files to a datasets preferably with single line separator ) Regards, WW -- 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: Health Checker questions
On Wed, 10 Dec 2008 10:24:42 +0100, R.S. [EMAIL PROTECTED] wrote: From end-user point of view you delete check by P and undelete by E action character in SDSF. As simple as H for deactivate and A for activate. The manual does not explain the difference. The only topic related to check deletion is some explanation why the check can be undeleted automagically. That procedure only works for local checks that support delete/refresh. If you try it on a remote check - for example CHECK(IBMUSS,USS_PARMLIB) - the deleted check will not be 'undeleted' on a refresh (SDSF E). The Health Checker for z/OS Users Guide contains a lot of information about how checks are expected to react to different commands/circumstances. Bottom line: If you want to get rid of the check forever (or at least for the life of the IPL), use DELETE; if you just want to stop the check from running for awhile, use DEACTIVATE. Dave Danner CA, Inc. -- 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: Health Checker questions
On Tue, 9 Dec 2008 13:53:31 +0100, R.S. [EMAIL PROTECTED] wrote: Peter Relson wrote: I can activate a check that was deactivated as well as I can undelete check that was deleted. That is not necessarily true. Well... This is want I wanted to learn more about. That's why I asked the question. When is the above untrue ? The only way to undelete a deleted REMOTE check would be to re-drive the check owner's HZSADDCK code. A lot of times that might be possible (or practical). Dave Danner CA, Inc. -- 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: Batch job to perform sftp transfer
On Fri, 22 Feb 2008 11:17:13 -0500, Jon Brock [EMAIL PROTECTED] wrote: Ideally, I would like to be able to set up a batch job that can be run under scheduler control to transmit this file when it is generated. If I am reading the correct information, though, it is not possible to do this in batch mode using ID/password authentication. Can anyone say whether this is correct? Am I going to need to get the remote server to add our keys to their setup? Yes, you are correct. You have to run ssh-keygen on the local system (to generate public and private keys) and have the admin on the remote server load the public key to his authorized_keys directory. This is all discussed in Chapter 5 (see p. 30-31) of z/OS IBM Ported Tools for z/OS Users Guide (SA22-7985-04). HTH...Dave -- 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: OA21346 for JES2 Dynamic Exit support - status??
On Fri, 7 Dec 2007 12:16:01 -0600, Tom Schmidt [EMAIL PROTECTED] wrote: Does anyone have any idea when the APAR for JES2 Dynamic Exit reload support (OA21346) is likely to close? Today's status display (from IBMLink) is quite anemic (no projected close date at all; which seems odd to me). I was under the impression that it was supposed to be released into the wild before now. I've been waiting for this too! I just heard from my IBM contact that: The APAR will be closing 'any day now', definitely before the end of the year. Apparently, it was slowed down getting all of the documentation finished. -- 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: Problems with checks IXGLOGR_*
On Mon, 26 Nov 2007 04:52:01 -0600, Jorge Garcia [EMAIL PROTECTED]
wrote:
We have offloaded the logrec logstream and now it's 2% full but when
we refresh the check the exception continues though we have refreshed
the structure.
Sorry for the late reply... What Jorge describes has been a known problem
with the IBMIXGLOGR checks from the beginning that I and others have
complained about. Apar OA22255 (which just closed on Friday) will improve
the situation somewhat. From the apar:
System logger health checks have been enhanced to allow parameters to
update the checks behavior.
The 'TIME(mm/dd/ hh:mm:ss)' parameter allows installations to set a time
to report from. Conditions before the inputted time will be suppressed.
The 'ALL' parameter, which is the default, will allow the previous behavior and
show up to the most recent 16 conditions for the system logger health
checks.
Unfortunately, due to a restriction in the HC infrastructure, you can't simply
pass a parameter of 'REFRESH'. The check developer suggested this: create a
HZSPRMxx parmlib member like:
UPDATE CHECK(IBMIXGLOGR,*)
PARM('TIME(MON/DAY/YR4 HR:MIN:SEC)')
Then issue the command: F HZSPROC,ADD,PARMLIB=xx. This should clear all
outstanding exceptions.
I believe that my friends at IBM are aware of the 'REFRESH' requirement so
hopefully this will be a future HC enhancement.
--
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: zOS Maintenance Best Practices
On Fri, 7 Dec 2007 10:48:29 -0600, Patrick Lyon [EMAIL PROTECTED] wrote: If you are a SHARE member, the last conference had an excellent session on maintenance best practices. z/OS Maintenance Best Practices - The Rationale Behind the Recommendations You can get it here: http://shareew.prod.web.sba.com/client_files/callpapers/attach/SHARE_in_San _Diego/S2829GD105741.pdf It's open to anyone. You don't need a SHARE ID. -- 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
z/OS 1.9 bug impacts SRS (and probably other SAPI apps)
If you are going to z/OS 1.9, be aware of JES2 apar OA22889. Symptoms in SRS include not selecting all spool data (typically multiple SYSOUT data sets within the same JOE) and S0C4 abends in module HASCSAPI. Other SAPI applications (like VPS) are likely affected as well. The apar is still open, but a zap is available from level 2. This problem only exists at z/OS 1.9. -- 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: Scotts new role
On Sat, 3 Nov 2007 18:09:43 -0500, Ed Gould [EMAIL PROTECTED] wrote: How could you respect anyone that worked for CA? I don't know (or care) about his reasoning for going to work for the evil empire, that is his prerogative. Sure there were some people way back when who got bought out by CA and didn't have a choice. They have my sympathies but to leave a company and essentially sell their name to the evil empire (and not even announce it) tells me quite a bit about their themselves. Ed questioning Scott's judgment is laughable - kind of like Homer Simpson questioning Einstein (sorry Homer). Scott had some very good reasons for making this move and he was under no obligation to announce it to anyone - certainly not here. CA isn't the same Evil Empire that Ed grew to know and hate 20 years ago. They've changed a lot since then, mostly for the better. The quality of some of the people they've hired recently is evidence of that. -- 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 Supported JES2 Dynamic Exit Reload
On Wed, 31 Oct 2007 16:23:48 -0500, Mark Zelden [EMAIL PROTECTED] wrote: Do you know if it is part of 1.9 base? No, it's not in the base for 1.9. Hopefully the apar will close soon. To see what the externals will (probably) look like, check out the end of this presentation: http://shareew.prod.web.sba.com/client_files/callpapers/attach/SHARE_in_San _Diego/S2667DD134925.pdf Should put Bob Break out of the dynamic exit business :-) -- 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: Running with SQA/ESQA 100% CHECK(IBMVSM,VSM_SQA_THRESHOLD) doesn't allow that as normal
On Thu, 6 Sep 2007 09:34:00 -0400, Knutson, Sam [EMAIL PROTECTED] wrote: I am curious how many other folks disable the Health Checker for z/OS check CHECK(IBMVSM,VSM_SQA_THRESHOLD) because they normally run with SQA or ESQA allocated at more than 100% converting some CSA/ECSA. Sam, We set the parm to 'SQA(80%),ESQA(99%)' and the severity to LOW which just causes the exception to be logged without alerting anyone. In talking to VSM about OA15758, I made a similar observation about overflow being common (especially for ESQA). I'd like to turn off the ESQA check and just run the SQA check. -Dave -- 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
JES2 Dynamic Exits
In the JES2 Latest Status session today, John Hutchinson announced that JES2 will (finally!) support adding/deleting/refreshing user exits dynamically. This support will be added to z/OS 1.8 and higher via apar OA21346. If you're at SHARE this week, Dynamic Exits will be discussed in greater detail at: JES2 and SDSF z/OS 1.9 Preview - Tue 9:30 JES2 Short Subjects (User Experiences) - Thu 1:30 These presentations will also be available on the SHARE web site. -- 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: Jes spool deletion question
On Mon, 30 Jul 2007 13:05:33 -0500, Melissa Perry [EMAIL PROTECTED] wrote: I have issued a $P SPOOLX against 2 spool volumesthey are draining. When I issue $DJQ,SPOOL=(VOLUME=SPOOL1,PERCENT0), I see the following jobs .. those jobs are really not there...how do I get rid of the volume or the jobs. When I do a $dj'myjob' nothing appears. Thanks $DJQ,SPOOL=(VOLUME=SPOOL1,PERCENT0) $HASP890 JOB(U432) 312 $HASP890 JOB(U432) STATUS=(AWAITING OUTPUT $HASP890PRIORITY=1,SYSAFF=(ANY) $HASP890SPOOL=(VOLUMES=(SPOOL1, $HASP890PERCENT=0.0030) The jobs were HELD prior to completing output processing. Most likely $HJ () was issued while the jobs were executing. Try releasing the jobs $AJ(). They should then appear on the hard copy queue where you can purge them which will allow the spool volumes to drain. -- 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: JCTJSUID
On Wed, 27 Jun 2007 08:50:44 -0500, Steve Emson [EMAIL PROTECTED] TCS.COM wrote: Given the JES2 installation exits manual, exit 53, point of processing section, says The JCT has been initialized with the JES2 and installation defaults; in addition, those fields of the JCT that correspond to JOB statement parameters other than accounting field parameters have been set. I was expecting to find the value of USER= to be stored in JCTJSUID is this wrong field? I think you mean 'JCTJUSID'. This is uninitialized in exit 53 on my system (z/OS 1.8, TSS 9.0) too. However, JCTNOUSR *is* correctly set to the submitting userid. By the time exit 6 gets called, JCTJUSID will definitely be filled in. -- 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: CA-TopSecret SP1 (and above) CICS SIGNON Problem
On Mon, 18 Jun 2007 13:05:51 -0400, Lizette Koehler [EMAIL PROTECTED] wrote: Does anyone know if this affects any version of z/OS/CICS/TSS or is this specific to a certain combination of z/OS/TSS/CICS? Neither IBM or CA seem to show any specific software levels other than TSS 9 at SP1/2 We were told by CA that the problem was introduced by apar QO86841 on TSS R9.0. Apparently, any release of z/OS or CICS could be impacted. Fortunately, the timing window (we think) where this could occur was from 06:02:59 on 06/16/2007 to 01:08:19 on 06/17/2007, so the problem is over for now. The next time the TOD clock will align with the TSS code bug is 20:46:05 on 01/05/2008. So you have some time to install the fix (QO89178) if you haven't already done so. -- 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: CICS AEXZ abend outage for zOS 1.8/Top Secret 9.0 users.
We used this zap to circumvent the problem: NAME CAKSSIGN CAKSSIGN VER 056E 4780,B5C6 REP 056E 4700 -- 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: JES2 Exit 5 on z/OS 1.7
On Thu, 8 Mar 2007 08:19:30 -0600, Joe Mscisz [EMAIL PROTECTED] wrote: Has anyone experienced problems assembling JES2 Exit 5 on 1.7? Is SYS1.MODGEN included in your SYSLIB concatenation? -- 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: Duplicate jobs running concurrently in z/OS 1.8
Could be OA18916 ? I would open a PMR and send a console dump of JES2 to IBM. -- 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: JES2 MTTR
On Sat, 3 Mar 2007 08:48:43 -0500, Knutson, Sam [EMAIL PROTECTED] wrote: JES2 SPOOL addressing uses 4 byte MTTR where M is SPOOL extent number TT is track address (up to 64K) R is record number This is referenced in a number of JES2 documents but you most recently see it discussed related to large sequential data set support for JES2 SPOOL. http://publib.boulder.ibm.com/infocenter/ieduasst/stgv1r0/topic/com.ibm. iea.zos/zos/1.7/Installation/MigrationConsiderations.pdf?dmuid=200612312 22730831109 This changes slightly in z/OS 1.7 with SPOOLDEF LARGEDS=ALLOWED or LARGEDS=ALWAYS. Four bits are borrowed (more like stolen) from the record number field and given to the track address. So it becomes more like MTTtr. From the JES2 z/OS 1.7 Migration Considerations book that Sam referenced: JES2 uses 4 byte MTTRs to address records on SPOOL. Using this scheme, we can address up to 64K tracks with 255 records per track. But JES2 formats the tracks with much less than 255 records per track. On a 3390 with the recommended buffer size of 3992 bytes, JES2 used 12 records per track. This implies that we can use some of the bits from the “R” value to supplement the TT value. By borrowing 4 bits, we can get 20 bits or 1M tracks. -- 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: Heads Up: JES2 Warning - Don't $P Spool Volumes
On Mon, 5 Mar 2007 16:24:25 -0600, Brian Peterson [EMAIL PROTECTED] wrote: Short version: If you are z/OS JES2 1.7 or above, don't drain spool volumes. APARs OA17249 and OA20195 (new, see additional related symptoms within the APAR text) describe problems which can occur if you $P a spool volume which is not known to be empty. I believe that OA20195 only affects volumes with extents 8 and higher. If you have the fix for OA17249 installed (Aug. 2006) you *should* be OK to drain volumes with extents 0-7. -- 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: TSO Rexx and SDSF
On Tue, 27 Feb 2007 07:25:42 -0500, Lizette Koehler [EMAIL PROTECTED] wrote: I have heard a rumor that in z/OS V1.9 there is to be a TSO REXX interface to SDSF (or vise versa). I did not see anything in the presentations at Share in Tampa and was wondering if anyone had anymore details. Actually, Bill Keller briefly discussed this in his SDSF Recent Changes presentation: http://shareew.prod.web.sba.com/client_files/callpapers/attach/SHARE_in_Tam pa_Bay/S2671BK113816.pdf See charts 13-15. You can expect a lot more detail about this at the next SHARE in San Diego. -Dave -- 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: NF APAR OA15539 for Health Checker
On Fri, 23 Feb 2007 12:46:21 -0600, Mark Zelden [EMAIL PROTECTED] wrote: So has anyone turned this trap on? Did you notice a performance hit? and Why not just change the bleepin' default? We turned it ON coincident with the z/OS 1.8 roll out and have not experienced any noticeable performance degradation. It does seem like a good thing to enable since the type of corruption it prevents might not be detected until hours or days later. A version of the check actually shipped in the base 1.8 code. As I said in the SHARE pitch, it was poorly written and confusing. OA15539 cleans up the 1.8 version of the check and ships it for older releases. I tested a ++APAR version of this and the exception messages look much better. There is still a timing issue at IPL though, and if you start the HC SUB=MSTR, you will have to DELETE the check (or make it INACTIVE) in order to avoid getting an exception. As many IBMers know, I certainly agree with Mark that defaults should not be flagged as exceptions. Instead the default should be changed to the best practice setting. In talking with VSAM L2, I think there's a good chance that the index trap will default to ON in the future. On Sun, 25 Feb 2007 17:45:10 -0500, Bob Rutledge [EMAIL PROTECTED] wrote: Before this discussion, did anyone even know this trap had existed for three years or was I the only ignorant soul? Unless apar OA03570 caught your eye in Jan. 2004 (I assume the PTFs had ++DOC holds) I don't know how you would have known about this. I sure didn't. So in that respect, the health check has value in that it makes people aware of the trap. -Dave -- 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
SDSF REXX API
Anyone else notice this buried in the V1.9 announcement? SDSF is being enhanced to add the capability to provide access to SDSF functions through REXX variables. The variables will be loaded with data from the SDSF panels, enabling scripts to access the data programmatically. The data can also be changed; this provides a capability similar to action characters and overtyping. A REXX API to SDSF functions could be pretty cool. I can think of a lot of applications. We could finally trash all those batch jobs that screen scrape panels. And if overtypes and action characters were supported...hmmm. -- 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: MII/GRS Resource Names
On Thu, 21 Sep 2006 09:00:59 -0500, Joe jeffries [EMAIL PROTECTED] wrote: Hi folks, Quick question. Can GRS Resource names be specified manually. IE. If a dataset has the same name on 2 systems in the same sysplex that don't share catalogs, can the resource name of 1 be changed without changing the Dataset name? If you have MII you can simply EXEMPT the data set which will cause MII to not serialize the ENQ for that data set: F miiproc,EXEMPT QNAME=SYSDSN RNAME=special.dsn To go back to serializing the ENQ: F miiproc,EXEMPT GLOBAL QNAME=SYSDSN RNAME=special.dsn -- 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: Read jes spool file before job ends
On Thu, 14 Sep 2006 07:06:44 -0700, Steve Pordash [EMAIL PROTECTED] wrote: Hi David, Thanks for your response! I shouldn't say that it failed, the called returned with I believe a return code 4 that means (I think) no data to process. SAPI (SSI 79) can only 'see' spool data that has gone thru output processing. So, (with the exception of FREE=CLOSE and dynamically allocated SYSOUT files) it CANNOT access data from running jobs. (Hence your RC=4). You can however use the Spool Browse service to get at almost any type of spool data set, including those open in running address spaces. See APPENDIX 1.2.4 of the JES2 Init and Tuning guide for more info. Tom Wasik also did a very good presentation on this and other topics - Exploiting New JES2 Interfaces - at SHARE in New York (Summer 2004). Good Luck...Dave -- 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: SDSF in Batch
On Mon, 17 Jul 2006 11:06:03 -0400, Dean Montevago [EMAIL PROTECTED] wrote: Hi, I'm running the following commands in batch: PRE ** DA On the output I am only getting a portion of the tasks running on the system (no CICS, not all the DB2's, etc.). Assuming you don't have any other filters active and you're authorized to see everything, try this: PRE ** DA ++ALL -- 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: Over my head in a JES exit
On Fri, 31 Mar 2006 11:10:23 -0600, Rugen, Len [EMAIL PROTECTED] wrote: I'm moving from z/OS 1.4 to 1.7 and the code for EXIT3 won't assemble. It looks like a lot of things were removed from $RDRWORK, this exit refers to RDWSAVE1 which appears to be one of the things removed. Before I dig deeper, does anyone have any hints on what changed? I'm afraid you're going to have to dig deeper to successfully convert to 1.7. Even if you can get your exit(s) to assemble, there is a good chance it won't work correctly (if at all). There are many changes introduced in 1.7 and each reader exit will require a careful review. In some cases, you'll have to code a second exit to retain the same functionality you had prior to 1.7. Start with the Exit Migration Guide which you can find here: http://www.ibm.com/servers/eserver/zseries/zos/installation/zos17_jes2_migra tion.html As to your specific problem, fields that used to reside in the reader work area ($RDRWORK) have been moved to the new Job Receiver Work Area ($JRW). This topic is covered in the Exit Migration Guide. Good Luck! -- 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 CPU consumption HIGH dramatic relief by adding .FORNSSI *NONE to MPFLSTXX
On Mon, 17 Oct 2005 13:41:00 -0400, Knutson, Sam [EMAIL PROTECTED] wrote: We are currently at R4 still working on migrating to R6. We expect some further relief from OA09229 once z/OS R6 is fully implemented on all systems in the Sysplex but we got considerable immediate relief by a very small change. OA08482/UA14743 were already APPLIED on all R4 LPARs so we added .FORNSSI *NONE to MPFLSTXX and set this active dynamically. We automate messages on the local system where they are issued so we took the recommended action and suppressed broadcast to foreign subsystems and I have not found any problems as a result. This provided over an 80% reduction from the previous levels of CONSOLE CPU use during our peak WLC charging hours! Sam, After you get Console Restructure with OA09229 installed can you try turning off .FORNSSI *NONE and reporting what you see? Mr. Fagen can correct me if I'm wrong, but I thought .FORNSSI was pretty much just a band- aid solution until the more robust redesign in OA09229 was available. If you still see an appreciable difference between turning .FORNSSI on and off after OA09229 I'd certainly like to know about that. Thanks, Dave -- 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: Query: CA-MIM ENQ Processing Mode
On Thu, 22 Sep 2005 20:11:14 -0500, Glenn Miller [EMAIL PROTECTED] wrote: I'm curious how other shops are 'configured'. We currently use the CA-MII ( Multi-Image Integrity ) and CA-MIA ( Multi-Image Allocation ) products. We are having a discussion/issue regarding the ENQ Processing Mode of CA-MII, which can be either 'SELECT' or 'ALLSYSTEMS. Currently, we use the 'SELECT' ENQ Processing mode of CA-MII. If you have the CA-MII product, which mode do you use, 'SELECT' or 'ALLSYSTEMS? We converted to PROCESS=ALLSYSTEMS several years ago. I believe that CA strongly recommends it, but I suspect the majority of MII customers are still PROCESS=SELECT (ALLSYSTEMS is certainly NOT required in parallel sysplex). Really, the only negatives to ALLSYSTEMS are that it requires a global MII restart to implement and that all RESERVES are converted to global ENQs unless GDIF=NO is specified for the RESERVE's QNAME. We'd prefer to keep the RESERVE unless we specifically ask to convert it. That was my only concern going in, but we haven't experienced any negative repercussions converting RESERVEs we weren't expecting. The GRS Monitor can help identify SYSTEMS ENQs that MIM is not processing. Also, if you do this make sure you have SET GDIF COUNT=SYSTEMS and issue DISPLAY COUNTS commands before and after the change. I was amazed at the number of SYSTEMS ENQs we were not serializing because we didn't specifically code them in the QNAME list. I sleep a lot better at night now. I can't think of many valid reasons for running with PROCESS=SELECT. You're certainly setting yourself up for trouble if some new component/product/application comes along issuing SYSTEMS ENQs expecting them to be serialized. Dave -- 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: Couple of questions on JES2 output handling
On Thu, 30 Jun 2005 15:52:05 +0100, Perryman, Brian [EMAIL PROTECTED] wrote: I want some types of STC to have their output immediately purged, assuming they complete successfully If by complete successfully you mean don't abend or get a JCL error, then a conditionally purged sysout class will work fine. However, if the STC ends with a bad return code in any job step, it will still purge. I have a JES2 exit 40 that implements conditionally purged processing by return code. If any job step ends with a return code higher than 4, the output is kept, otherwise it is purged. If you want a copy, shoot me an email. The second question then, is there a way in JES or RACF that will let me stop non-production users writing to certain output classes? If you can identify non-production users by looking at fields in the PDDB, exit 40 can also be used to change the sysout class for bogus requestors to a class that doesn't get archived. Dave Danner -- 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
