Re: JCL RESTART= when using Nested Procs
>MVS/ESA V3 (1988) implemented all those JCL enhancements like nested PROCs Old dog? New tricks? Of course, I haven't had to really do substantial JCL coding since the early 1980's. Live & learn (even if it is 20 years later). It's amazing how hard it is to keep up, especially with stuff outside your direct responsibilities! When in doubt. PANIC!! -- 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: JCL RESTART= when using Nested Procs
MVS/ESA V3 (1988) implemented all those JCL enhancements like nested PROCs, SET, IF-THEN-ELSE, INCLUDE, JCLLIB, and promoted many DCB subparameters to independent parameters. Peter Hunkeler CREDIT SUISSE -- 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: IPL & VIPA Issues
On Thu, 3 Aug 2006 08:03:48 +0100, Mark Wilson <[EMAIL PROTECTED]> wrote: >After the normal scheduled re-IPL of the LPAR we could not connect using the VIPA, but could use the physical addresses that relate to the OSA ports. > >Reloading the TCP/IP stack didn't fix the problem and eventually we had to close TCP/IP and inactivate the SNA major nodes (that use the OSA) to enable the OSA chps to be varied OFF/ON. > >This fixed the problem. I've run into a similar problem. I use OSPF via OMPROUTE (using a Stub Area) to enable my Static VIPA. The VTAM displays of the OSA TRLEs looked good, the TCPIP device displays showed my VIPA and OSA devices were OK. However, OMPROUTE showed that it had trouble connecting to the rest of its neighbors. We found out later that 1 (out of 2) OSAs was flaky. Once that was addressed, OMPROUTE initialized properly. BTW, during this problem, just like you, we could connect to z/OS using the physical IP address of the the working OSA interface. You may want to check the log or messages in your OMPROUTE (or OROUTED) during your incident. Ed R. -- 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: IEFACTRT
On Aug 3, 2006, at 4:49 PM, Scott Barry wrote: Consider that job-end statistics (if the output is captured or reviewed by the submitter) only represents a portion of what would normally be a chargeback bill/ invoice/receipt (okay, or call it cost allocation or recovery). Also, how will a DB2 DDF (remote) customer get their bill or a CICS transaction user, etc. -- these typically involve tables mapping USERIDs to a related owner/group? Considering the cost of DASD and tape storage (local/vault, reel, real, virtual, high-capacity), how will these resources be tallied and communicated to the appropriate department/cost_center or resource consumer? CPU normalization, rates, and possibly surcharge/discount logic may need to be maintained, depending on the chargeback algorithm and IT chargeback methodology intended to be used for any given system/customer. Support for "new rates" with effective dates and other comprehensive logic should likely be considered, if the reported charges are to be considered credible, especially when transitioning between fiscal calendar cycles. Better to consider generating a consolidated resource consumer report, at day's end (or otherwise), and accumulate the various resource buckets/areas, in a back-end system that post-processes the various SMF and other system logs. Some that come to mind are SMF type 30 (address space activity for batch, TSO, STC, OMVS/USS, and maybe APPC), type 6 (output/ print), type 101 (DB2), type 110 (CICS/CMF), IMS log (or BMC's Patrol / IMF), other DBMS tools (IDMS, M204, Datacom, Supra), and DASD (IBM DCOLLECT snapshot), tape (tape mgmt catalog snapshot) focusing on long-term data storage. -SNIP Scott, There *USED* to be a package (called QCM) that did all this and quite a bit more 20 or more years ago. I believe it was written by Glen Chatfield(sp?) of Duquesne systems in Pittsburg. If there was something to account for QCM could produce *VALID* numbers. Like chargeback for paging and even IO timings for anything in the system. IIRC we had a user who disputed the numbers and brought in a hardware monitor to "verify" (contest?) the numbers. The difference was so insignificant that the user coughed up the $$ without admitting defeat. Unfortunately the cost for the product was not cheap and I think that is what lead to the demise of the company. BTW they developed SDSI (now called MIM) on our systems. They also offered a product called STAM which allowed tape drives to be shared among systems. This was in the 70's and perhaps early 80's. When (at the early stages) their software caused any of our systems to crash they were always the first one to step up to the plate with research and debugging that even our local PSR was impressed with. Ed -- 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: JCL RESTART= when using Nested Procs
Ted MacNEIL wrote: Nested JCL procs can be quite useful I started this job as a JCL jockey in 1981. When did nested PROCs become available? The last time I tried, I got a JCL error. I believe it was MVS/ESA V4. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: JCL RESTART= when using Nested Procs
In a recent note, Ted MacNEIL said: > Date: Thu, 3 Aug 2006 23:39:28 + > > >Nested JCL procs can be quite useful > > I started this job as a JCL jockey in 1981. > When did nested PROCs become available? > The last time I tried, I got a JCL error. > They're described in: Title: MVS/ESA SP V5 JCL Reference Document Number: GC28-1479-00 Build Date: 04/22/94 19:09:39 Build Version: 1.2 ... as far back as I can search in publibz. Almost half your career, at least. But back before then, my JCL mentor told me, also, that PROCs couldn't be nested, and that it was unlikely to happen because there'd be no way to implement referbacks to statements in nested PROCs. He underestimated IBM's resourcefulness. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Incomplete Implementation of Nested Procs (was: JCL RESTART= ...)
In a recent note, John Mattson said: > Date: Thu, 3 Aug 2006 16:15:56 -0700 > > Nested JCL procs can be quite useful, but RESTART= seems to only allow > JOBSTEP.PROCSTEP and when you are doing nested procs, this is just not > enough. You would need something like JOBSTEP.NESTPROC.PROCSTEP or > JOBSTEP.NESTPROC1.NESTPROC2.NESTPROC3.PROCSTEP and so on. Looking at the > JCL manual, it appears that there is just no way to do such a restart for > nested procs if the step you want is WITHIN a nested proc. Anyone have > any way of getting around this? My scheduling program seems to deal with > it properly, but using the scheduler for my testing is a bit cumbersome. > Likewise, from: #4.4 "z/OS V1R5.0 MVS JCL Reference" 4.4 Backward References The following statements cannot be referenced: [ ... ] * Nested procedure statements Why? Seems like another case if IBM's missing the point when implementing a Requirement. Surely, the objective of the Requirement for nested JCL PROCs was not that nested PROCs should provide all the capabilities of first-level procs _except_ backward references, RESTART, (others ... ?). Should I browse V1R7.0 to see if there's any improvement? -- gil -- StorageTek INFORMATION made POWERFUL -- 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: Started Tasks
All Started Tasks (STC) are started through Master JCL to the internal reader. JES receives the task and it starts. So, check out what's in MSTRJCL and those are the referenced libraries. (Most people leave this alone.) The default is SYS1.PROCLIB on the system where the task was started. (You could have different PROCLIBs on each system but that invites trouble.) Rob Weiss z/SWITA and z/Series I/T Security and Privacy Consultant IBM Software Group Sales IBM Mainframe Discussion List wrote on 08/03/2006 01:20:45 PM: > We are z/OS V1R4. I have a question about CA's started tasks. CAS9 & > CAL7 (CA-ELEVEN) will not start unless they are in SYS1.PROCLIB. These > procs reside in a proclib that is in the concatenation of JES2, but are > not in the proclib concatenation of MSTRJCL00. My question is how do > these proc's know the difference of which library they are started from. > Is CAS9 forcing these to come from SYS1.PROCLIB or forcing them to come > from the MSTRJCLxx concatenation? > > Any help would be appreciated. -- 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: JCL RESTART= when using Nested Procs
>Nested JCL procs can be quite useful I started this job as a JCL jockey in 1981. When did nested PROCs become available? The last time I tried, I got a JCL error. When in doubt. PANIC!! -- 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
JCL RESTART= when using Nested Procs
Nested JCL procs can be quite useful, but RESTART= seems to only allow JOBSTEP.PROCSTEP and when you are doing nested procs, this is just not enough. You would need something like JOBSTEP.NESTPROC.PROCSTEP or JOBSTEP.NESTPROC1.NESTPROC2.NESTPROC3.PROCSTEP and so on. Looking at the JCL manual, it appears that there is just no way to do such a restart for nested procs if the step you want is WITHIN a nested proc. Anyone have any way of getting around this? My scheduling program seems to deal with it properly, but using the scheduler for my testing is a bit cumbersome. -- 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: PDS I/O ERROR
In a message dated 8/3/2006 5:30:30 P.M. Central Standard Time, [EMAIL PROTECTED] writes: The free PDS command has a VERIFY option that will do this. Search the archives using VERIFY and PDS as keywords to find some more detailed posts. >> Yep, used it hundreds of times. Might be somebody did a GENER instead of a COPY(from the x'4040's. Also IEHLIST with LISTVTOC might point to pointer problems on the pack. And a DIAGNOSE against the PACK and VTOC might be in order. -- 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: PDS I/O ERROR
The free PDS command has a VERIFY option that will do this. Search the archives using VERIFY and PDS as keywords to find some more detailed posts. http://www.cbttape.org/freepds.htm You can grab file 035 for a load library that includes a current version of PDS. Best Regards, Sam -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Claudio Sent: Thursday, August 03, 2006 6:08 PM To: IBM-MAIN@BAMA.UA.EDU Subject: PDS I/O ERROR I have I loadlib that when I try to compress it I got the following error message: IEB1021E 1E28,D,INPUT ,READ ,NO RECORD FOUND,039219,BSAM IEB1022I I/O ERROR ONDDN= VOL= DSN= IEB1023I COPYMOD READ MEMBER= TTR=X'029617' MBBCCHHR=X'4040 I then deleted member "" and run it again. The same error for another member. What I need to know is if there is any utility that is able to give me a list of all members in error. Any clue ? Thanks in advance Claudio This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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
VSMLOC against PVT
The doc indicates that "All addresses are associated with the current address space" Which address space is that when PASN/=HASN ? -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
PDS I/O ERROR
I have I loadlib that when I try to compress it I got the following error message: IEB1021E 1E28,D,INPUT ,READ ,NO RECORD FOUND,039219,BSAM IEB1022I I/O ERROR ONDDN= VOL= DSN= IEB1023I COPYMOD READ MEMBER= TTR=X'029617' MBBCCHHR=X'4040 I then deleted member "" and run it again. The same error for another member. What I need to know is if there is any utility that is able to give me a list of all members in error. Any clue ? Thanks in advance Claudio -- 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: z/OS 1.7 Last ServerPac Order Date?
On Thu, 2006-08-03 at 10:33 -0400, Ken Porowski wrote: > Anyone know what will be the cutoff date for ordering z/OS 1.7 > ServerPac. > I imagine it will be fairly soon as 1.8 is coming out. I'd advise getting on your bike Ken - especially if you are currently at 1.4. I insisted the order be placed prior to going on leave in late June - it has yet to be processed. And yes I am on the case every couple of days. It should be noted we haven't the opportunity to order serverpacs online in the PacBasin. 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: IEFACTRT
Consider that job-end statistics (if the output is captured or reviewed by the submitter) only represents a portion of what would normally be a chargeback bill/invoice/receipt (okay, or call it cost allocation or recovery). Also, how will a DB2 DDF (remote) customer get their bill or a CICS transaction user, etc. -- these typically involve tables mapping USERIDs to a related owner/group? Considering the cost of DASD and tape storage (local/vault, reel, real, virtual, high-capacity), how will these resources be tallied and communicated to the appropriate department/cost_center or resource consumer? CPU normalization, rates, and possibly surcharge/discount logic may need to be maintained, depending on the chargeback algorithm and IT chargeback methodology intended to be used for any given system/customer. Support for "new rates" with effective dates and other comprehensive logic should likely be considered, if the reported charges are to be considered credible, especially when transitioning between fiscal calendar cycles. Better to consider generating a consolidated resource consumer report, at day's end (or otherwise), and accumulate the various resource buckets/areas, in a back-end system that post-processes the various SMF and other system logs. Some that come to mind are SMF type 30 (address space activity for batch, TSO, STC, OMVS/USS, and maybe APPC), type 6 (output/print), type 101 (DB2), type 110 (CICS/CMF), IMS log (or BMC's Patrol / IMF), other DBMS tools (IDMS, M204, Datacom, Supra), and DASD (IBM DCOLLECT snapshot), tape (tape mgmt catalog snapshot) focusing on long-term data storage. Given the possibilities of unknowns, it's best to get management's expectations well-documented, evolve that information along with technical/business considerations into an explanation and/or position paper, so all involved parties understand what's at stake before valuable staff resources are expended. Sincerely, Scott Barry SBBWorks, Inc. Date: Thu, 3 Aug 2006 12:00:24 -0400 From: Anne Crabtree <[EMAIL PROTECTED]> Subject: IEFACTRT Does anyone have an example of IEFACTRT using type 30 and doing chargeback that they would be willing to share? -- 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
Working on mainframes not just for old fogies
http://www.networkworld.com/news/2006/073106-mainframes-new- generation.html Working on mainframes not just for old fogies A new generation of developers rises to the occasion. -- 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: OA17292 Data Loss with VSAM LSR Hiperspace
Here is the text from IBMLINK APAR Identifier .. OA17292 Last Changed 06/08/03 HIPERSPACE BUFFERS ARE NOT INVALIDATED AFTER IMS NOTIFY Symptom .. IN INCORROUT Status ... OPEN Severity ... 1 Date Closed . Component .. 5695DF106 Duplicate of Reported Release . 1K0 Fixed Release Component Name DFSMS VSAM MEDA Special Notice HIPER Current Target Date ..06/08/02 Flags SCP ... Platform PERVASIVE DATALOSS Status Detail: DESIGN/CODE - APAR solution is being designed and coded. PE PTF List: PTF List: Tentative Affected Releases and Current Relief Available: Release 1K0 : Relief is available in the form of: AA17292 Parent APAR: Child APAR list: ERROR DESCRIPTION: IMS issues a macro interface to VSAM to invalidate a particular buffer in the LSR buffer pool. If the buffer resides in a hiperspace buffer, it is not invalidated and can lead to lost updates if that address space later uses that downlevel copy of the buffer. The external symptoms can be 'pointer checker' errors, ABENU0852 and ABEND0849. The problem only affects IMS applications using IRLM Notify that have hiperspace buffers in the LSR pool. It does not affect those IMS users of cross invalidate using the coupling facility. IMS is the only user of this function. No other VSAM users are affected. ADDITIONAL SYMPTOMS: ABEND0C4 in IDA019XV msgDFS629I PSW AT ERROR = 077C2000 82D79960 SYS1 msgDFS629I MODID = UNKNOWN EPA = UNKNOWN SYS1 LOCAL FIX: Remove hiperspace buffers from the LSR pool definition. To do this, look in the IMS startup parms under DFSVSAMP DD or the DFSVSMxx member.Remove any HSO,HSR, HSn subparms from VSRBF= control statments. Dave Jousma Principal Systems Programmer [EMAIL PROTECTED] 616.653.8429 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: Thursday, August 03, 2006 2:52 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Heads Up: OA17292 Data Loss with VSAM LSR Hiperspace Did that answer originate from DFSMS support? or CICS Support? -jc- This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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: Started Tasks
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Mark Steely > Sent: Thursday, August 03, 2006 2:21 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Started Tasks > > > We are z/OS V1R4. I have a question about CA's started tasks. CAS9 & > CAL7 (CA-ELEVEN) will not start unless they are in SYS1.PROCLIB. These > procs reside in a proclib that is in the concatenation of > JES2, but are > not in the proclib concatenation of MSTRJCL00. My question is how do > these proc's know the difference of which library they are > started from. > Is CAS9 forcing these to come from SYS1.PROCLIB or forcing > them to come > from the MSTRJCLxx concatenation? > > Any help would be appreciated. > > Thank You The problem is that CAS9 and CAL7 are defined as "sub systems", like JES2. When a START command is issued, the command processor compares the name of the started task with the names of the subsystems. If the name being started matches a subsystem name, then the command processor implicitly adds a ,SUB=MSTR to start the JCL under the master subsystem. You can get around this by issuing the commands as follows: S CAS9,SUB=JES2 S CAL7,SUB=JES2 to force the command processor to give the START command to JES2 instead of MSTR. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
RES: CA7 Slowdown after 1.7 implementation
Mr Rhodes, How is your MASDEF statment defined in JES2PARM ? Atenciosamente / Regards / Saludos Banco Bradesco S/A 4254/DPCD Alphaville Suporte Técnico - Software Básico Mainframes Ituriel do Nascimento Neto Tel: 55 11 4197-2021 Fax: 55 11 4197-2814 >Has anyone had any issues with CA7 since moving to 1.7. We have 14 >sysplex's and only have this problem in one. The one having the problem is >the largest with the heaviest volume. We believe this is due to the JES >internal reader changes made in 1.7. We have increased the dispatch >priority of the task to FE(sysstc) and still during extremely heavy >processing we see 5 minutes time frame of jobs moving thru the CA7 queues >before hitting the input queue. We see know indicated waits on anything >but CPU. We were recently on a 1.7 migration call with IBM and one >customer asked IBM this question. The reps from IBM were not aware of this >problem but did say they would follow up with this customer but did not >indicate who this customer was during the call. AVISO LEGAL Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. +**+ LEGAL ADVICE This message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. -- 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: Started Tasks
From "JCL Reference" (at 1.7) Without a SUB= keyword on the START command, the operating system will create the started task under the primary job entry subsystem (JES2 or JES3) unless the task itself is a subsystem, that is, it is either defined in the member IEFSSNxx of SYS1.PARMLIB, or dynamically by the SETSSI command or IEFSSI macro. (A subsystem, unless requested to start under the primary JES subsystem by setting flag SSCTUPSS in the SSCVT, starts under the master subsystem, MSTR.) Bob Mark Steely wrote: We are z/OS V1R4. I have a question about CA's started tasks. CAS9 & CAL7 (CA-ELEVEN) will not start unless they are in SYS1.PROCLIB. These procs reside in a proclib that is in the concatenation of JES2, but are not in the proclib concatenation of MSTRJCL00. My question is how do these proc's know the difference of which library they are started from. Is CAS9 forcing these to come from SYS1.PROCLIB or forcing them to come from the MSTRJCLxx 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: Started Tasks
If they are started 'SUB-MSTR' then they must be in the MSTJCL concatination. JES doesn't get involved in processing for 'SUB=MSTR'. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Steely Sent: Thursday, August 03, 2006 3:21 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Started Tasks We are z/OS V1R4. I have a question about CA's started tasks. CAS9 & CAL7 (CA-ELEVEN) will not start unless they are in SYS1.PROCLIB. These procs reside in a proclib that is in the concatenation of JES2, but are not in the proclib concatenation of MSTRJCL00. My question is how do these proc's know the difference of which library they are started from. Is CAS9 forcing these to come from SYS1.PROCLIB or forcing them to come from the MSTRJCLxx concatenation? Any help would be appreciated. Thank You -- 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 - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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
Started Tasks
We are z/OS V1R4. I have a question about CA's started tasks. CAS9 & CAL7 (CA-ELEVEN) will not start unless they are in SYS1.PROCLIB. These procs reside in a proclib that is in the concatenation of JES2, but are not in the proclib concatenation of MSTRJCL00. My question is how do these proc's know the difference of which library they are started from. Is CAS9 forcing these to come from SYS1.PROCLIB or forcing them to come from the MSTRJCLxx concatenation? Any help would be appreciated. Thank You -- 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: OA17292 Data Loss with VSAM LSR Hiperspace
On Thu, 3 Aug 2006 12:00:27 -0500, Brian Peterson <[EMAIL PROTECTED]> wrote: >The APAR text mentions IMS as being exposed. The defect, however, is >within VSAM. I do not know if other VSAM LSR exploiters (such as CICS) are >affected. I have asked that question. > That APAR says this (at least it does now): === The problem only affects IMS applications using IRLM Notify that have hiperspace buffers in the LSR pool. It does not affect those IMS users of cross invalidate using the coupling facility. IMS is the only user of this function. No other VSAM users are affected. === Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: HFS files for IBM program products
You don't need to use /usr/lpp/ for your mountpoint. Products have either configuration files or startup parms that point to the directory for the product. You can crate a productname directory with mountpoint directories for each of the versions and have your parms point to that directory. We do that for all of our non-root products. It works and allows quick upgrade/backoff paths. We alos use symbolic links a lot. They can make life a lot easier. Less moving parts to change. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Patrick O'Keefe Sent: Thursday, August 03, 2006 2:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: HFS files for IBM program products On Thu, 3 Aug 2006 13:08:47 -0500, Tom Marchant <[EMAIL PROTECTED]> wrote: >... >>Symbolic links so that /usr/lpp// can point into >>different HFSs? > >I'm not sure what you hope to achieve with a symbolic link. You can >mount the HFS at /usr/lpp/. >... My understanding of this is a bit shakey , but this is for the migration process that exists at my shop. Software upgrades are migrated from test LPARs to development LPARs to production LPARs. I think I would be expected to maintain 3 HFSs for the product (for production and 2 levels of mainteenance, I guess). /usr/lpp// would point into one of the 3 HFSs; a different HFS for each type of LPAR. That doesn't address the need to switch back and forth between 2 maintenance levels since the resolved path is tied to the LPAR, but I guess I could dynamically change the value of the symbolic link if I needed to drop back to the previous level. This technique does not allow for execution of multiple levels of the product on the same LPAR, but neither does anything using /usr/lpp//. Pat O'Keefe -- 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 - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: HFS files for IBM program products
On Thu, 3 Aug 2006 13:00:20 -0500, Brian Peterson <[EMAIL PROTECTED]> wrote: >... >Then, in my z/OS root HFS (I'm simplistic and am not using shared HFS), I >create a directory in /usr/lpp/ for the product. In this case, it >was /usr/lpp/db2/. We mount the cloned target HFS at >mountpoint /usr/lpp/db2 and the product gets the "default" and "expected" >path to the executable HFS code/files. >... We do use shared HFS, but I don't think that changes much. In my case I would have the old product in z/OS ROOT HFS pointed to by /usr/lpp/netview/v5r1/ and a new level of the product in its own HFS pointed to by /usr/lpp/netview/v5r2/. I guess I could mount and unmount the new HFS as needed during implementation ... Except that I don't think I will be allowed to do that on our development and production LPARs. :-( Pat O'Keefe -- 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: OA17292 Data Loss with VSAM LSR Hiperspace
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Brian Peterson > On Thu, 3 Aug 2006 12:00:27 -0500, Brian Peterson wrote: > > > I do not know if other VSAM LSR exploiters (such as CICS) > >are affected. I have asked that question. > > The question's answer is "IMS and VSAM only are exposed. > CICS is not." Did that answer originate from DFSMS support? or CICS Support? -jc- -- 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: HFS files for IBM program products
On Thu, 3 Aug 2006 13:08:47 -0500, Tom Marchant <[EMAIL PROTECTED]> wrote: >... >>Symbolic links so that /usr/lpp// can point into different >>HFSs? > >I'm not sure what you hope to achieve with a symbolic link. You can mount >the HFS at /usr/lpp/. >... My understanding of this is a bit shakey , but this is for the migration process that exists at my shop. Software upgrades are migrated from test LPARs to development LPARs to production LPARs. I think I would be expected to maintain 3 HFSs for the product (for production and 2 levels of mainteenance, I guess). /usr/lpp// would point into one of the 3 HFSs; a different HFS for each type of LPAR. That doesn't address the need to switch back and forth between 2 maintenance levels since the resolved path is tied to the LPAR, but I guess I could dynamically change the value of the symbolic link if I needed to drop back to the previous level. This technique does not allow for execution of multiple levels of the product on the same LPAR, but neither does anything using /usr/lpp//. Pat O'Keefe -- 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: WTO Question
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Comstock Sent: Thursday, August 03, 2006 1:03 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: WTO Question Yes, I came across it last week. In z/OS MVS Programming: Assembler Services Reference, Volume 2 (IARR2V-XCTLX), (pdf file name: iea2a961.pdf; IBM form number: SA22-7607-09) on the write up for WTO, p. 825: "Be aware of the following when coding the WTO macro: * MCSFLAG=REG0 is not supported on z/OS V1R7 and higher. * You should clear register zero. . . ." I didn't follow up, as my need to use the macro in the moment went away. But I remember being surprised. Kind regards, -Steve Comstock Thanks. I knew I'd seen it. Regards, Steve Thompson -- 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: Data set ENQueues and DEQueues in Jobs
RET=NONE is the same as RET= parameter omitted. IBM Mainframe Discussion List wrote on 08/03/2006 02:20:20 PM: > > If there are others with a SHARED ENQ, attempting a RET=CHNG will > > either put you into a wait (possibly triggering a deadly embrace if > > you hold another SHR or EXC ENQ that some other task wants to go to > > EXC status on) or return a failure RC and require you to recover by > > attempting it again. > Actually, RET=CHNG will always return with a return code (0 or other). > The RET= parm implies this. The only way to wait is an ENQ with no > RET=, which obviously will not do the CHNG. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- 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: HFS files for IBM program products
Most of the execs that IBM distributes (xxxMKDIR, etc) allow you to prefix the install path with a higher level directory name. We use /maint/ so that the actual directory that these products point to is /maint/usr/lpp/. We then mount an HFS at that point to receive the maintenance. As far as implementing the new version of an existing product, we have a symbolic link in /usr/lpp/ called product that points to a directory on the root called product (/usr/lpp/product -> /product. The product directory has subdirectories for each product and each subdirectory has version identifiers (/product/db2/v8 /product/db2/v7) at each of these subdirectories we mount the correct version of the product. When someone wants to use the product they point their startup scripts or configuration files to point to the correct directory. It sounds complex but it has saved us a ton of problems and allows us to mount the version root directory as read only which can prevent folks from inadvertantly (or not) overlaying our running system code. If you have access to the SHARE archives there are several presentations on this subject (one of them mine from the Nashville SHARE). Good luck! Jon Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Patrick O'Keefe Sent: Thursday, August 03, 2006 1:43 PM To: IBM-MAIN@BAMA.UA.EDU Subject: HFS files for IBM program products IBM program products apparently have packaging rules for Unix libraries stating that the path to these libraries will be /usr/lpp//. How do shops handle this when they install program products (like PrintServe, DB2, NetView, etc.) in other than their main MVS SMP zones. In particular, how do shops handle maintenance or new releases when both old and new copies of the products needs to be executed simultaneously? Symbolic links so that /usr/lpp// can point into different HFSs? Temporary installation into something other than /usr/lpp//? Some other technique? That 2nd technique was sometimes used at my last shop, but apparently some products use hard-coded paths /usr/lpp//.../. Is that common, standard practice in MVS program products? To have the paths to Unix libraries hard-coded and not overridable by installations? I probably asked a question similar to this about a year ago, but couldn't find it in the archive. Pat O'Keefe -- 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 - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: CA7 Slowdown after 1.7 implementation
In the Plex we are having issues we are stil 3.3. In our other environments we are half 3.3 and half V11 with z/OS 1.7 in all environments. I just want to point out to everyone the only place we have seen this is in our heaviest processing environment at the time of peak production. -- 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: Data set ENQueues and DEQueues in Jobs
If there are others with a SHARED ENQ, attempting a RET=CHNG will either put you into a wait (possibly triggering a deadly embrace if you hold another SHR or EXC ENQ that some other task wants to go to EXC status on) or return a failure RC and require you to recover by attempting it again. Actually, RET=CHNG will always return with a return code (0 or other). The RET= parm implies this. The only way to wait is an ENQ with no RET=, which obviously will not do the CHNG. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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: HFS files for IBM program products
On Thu, 3 Aug 2006 12:42:51 -0500, Patrick O'Keefe <[EMAIL PROTECTED]> wrote: >IBM program products apparently have packaging rules for Unix libraries >stating that the path to these libraries will be /usr/lpp//. >How do shops handle this when they install program products (like >PrintServe, DB2, NetView, etc.) in other than their main MVS SMP zones. >In particular, how do shops handle maintenance or new releases when both >old and new copies of the products needs to be executed simultaneously? > >Symbolic links so that /usr/lpp// can point into different >HFSs? I'm not sure what you hope to achieve with a symbolic link. You can mount the HFS at /usr/lpp/. Tom Marchant -- 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: WTO Question
Thompson, Steve (SCI TW) wrote: I was doing some work on an issue here and thought I read that as of z/OS 1.7 you must clear R0 prior to a WTO and use CONNECT instead. Did anyone else see that little comment somewhere or something like it? I've searched every 1.7 PDF I have on my hard drive for z/OS 1.7 macros and I can't find it, and yet my "tickler" notes from that evening about a week ago... Regards, Steve Thompson Yes, I came across it last week. In z/OS MVS Programming: Assembler Services Reference, Volume 2 (IARR2V-XCTLX), (pdf file name: iea2a961.pdf; IBM form number: SA22-7607-09) on the write up for WTO, p. 825: "Be aware of the following when coding the WTO macro: * MCSFLAG=REG0 is not supported on z/OS V1R7 and higher. * You should clear register zero. . . ." I didn't follow up, as my need to use the macro in the moment went away. But I remember being surprised. Kind regards, -Steve Comstock -- 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: HFS files for IBM program products
I certainly don't know how "everyone else" does this, but here's what we do: For non-z/OS-root products, I help the installer modify the xxxMKDIR and xxxISMKD programs, such that the product will SMP/E install into a separate and distinct HFS. Lets say a product wants to have a DDDEF PATH similar to the following: '/usr/lpp/db2810_msys/IBM/' I have the SMP/E installer use the following path in the DDDEF: /u/userid/db2smpe/db2810_msys/IBM/ In this case, /u/userid is the home directory for the user, and db2smpe is a director within the user's home HFS. Then, on the db2smpe mount point, we mount a HFS data set associated with the product. We run the xxxMKDIR/xxISMKD rexx programs - appropriately modified - and proceed with product installation. The aforementioned HFS mounted at /u/userid/db2smpe is then treated just like any other target zone data set, and is cloned along with the rest of the target zone data sets to deploy the software from environment to environment. Then, in my z/OS root HFS (I'm simplistic and am not using shared HFS), I create a directory in /usr/lpp/ for the product. In this case, it was /usr/lpp/db2/. We mount the cloned target HFS at mountpoint /usr/lpp/db2 and the product gets the "default" and "expected" path to the executable HFS code/files. Finally, I update BPXPRMxx to automatically mount the desired product HFS data sets at their respective mount points. For product rollout, the product clone procedure includes steps to unmount and mount the old/new HFS file systems, just as they have always deleted / redefined target zone executable data sets. I have never investigated whether a unix symbolic link could also be used to assist or replace the above process. As a unix neophyte, I really didn't know how to do that. Brian On Thu, 3 Aug 2006 12:42:51 -0500, Patrick O'Keefe <[EMAIL PROTECTED]> wrote: >IBM program products apparently have packaging rules for Unix libraries >stating that the path to these libraries will be /usr/lpp//. >How do shops handle this when they install program products (like >PrintServe, DB2, NetView, etc.) in other than their main MVS SMP zones. >In particular, how do shops handle maintenance or new releases when both >old and new copies of the products needs to be executed simultaneously? > >Symbolic links so that /usr/lpp// can point into different >HFSs? Temporary installation into something other than >/usr/lpp//? Some other technique? > >That 2nd technique was sometimes used at my last shop, but apparently >some products use hard-coded paths /usr/lpp//.../. Is >that common, standard practice in MVS program products? To have the >paths to Unix libraries hard-coded and not overridable by installations? > > >I probably asked a question similar to this about a year ago, but couldn't >find it in the archive. > >Pat O'Keefe -- 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: WTO Question
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant Sent: Thursday, August 03, 2006 12:56 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: WTO Question seems to me that if there was such a new requirement, a lot of old code would be broken Quite right. -- 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: WTO Question
On Thu, 3 Aug 2006 13:44:24 -0400, Thompson, Steve (SCI TW) <[EMAIL PROTECTED]> wrote: >-Original Message- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On >Behalf Of Kirk Talman >Sent: Thursday, August 03, 2006 12:39 PM >To: IBM-MAIN@BAMA.UA.EDU >Subject: Re: WTO Question > >Left hand/right hand? > > > >I wish it were that simple. It was a comment about 1.7 and beyond and >the use of Gen Reg 0. I'm trying to find it to see what its impact is to >us. > seems to me that if there was such a new requirement, a lot of old code would be broken -- 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: WTO Question
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kirk Talman Sent: Thursday, August 03, 2006 12:39 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: WTO Question Left hand/right hand? I wish it were that simple. It was a comment about 1.7 and beyond and the use of Gen Reg 0. I'm trying to find it to see what its impact is to us. Regards, Steve Thompson -- 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
HFS files for IBM program products
IBM program products apparently have packaging rules for Unix libraries stating that the path to these libraries will be /usr/lpp//. How do shops handle this when they install program products (like PrintServe, DB2, NetView, etc.) in other than their main MVS SMP zones. In particular, how do shops handle maintenance or new releases when both old and new copies of the products needs to be executed simultaneously? Symbolic links so that /usr/lpp// can point into different HFSs? Temporary installation into something other than /usr/lpp//? Some other technique? That 2nd technique was sometimes used at my last shop, but apparently some products use hard-coded paths /usr/lpp//.../. Is that common, standard practice in MVS program products? To have the paths to Unix libraries hard-coded and not overridable by installations? I probably asked a question similar to this about a year ago, but couldn't find it in the archive. Pat O'Keefe -- 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: CA7 Slowdown after 1.7 implementation
Casey, We are running CA7 v3.3, level 0412 (SP6). In fact, we moved to this version for z/OS 1.7 compatibility. This Monday morning we'll be upgrading the partition where CA7 runs from z/OS 1.5 to 1.7. Will let you know how it looks. In the meantime, what version and level of CA7 are you running? Thanks. Ed Micucci ~ On Thu, 3 Aug 2006 08:58:56 -0500, Casey Rhodes <[EMAIL PROTECTED]> wrote: >Has anyone had any issues with CA7 since moving to 1.7. We have 14 >sysplex's and only have this problem in one. The one having the problem is >the largest with the heaviest volume. We believe this is due to the JES >internal reader changes made in 1.7. We have increased the dispatch >priority of the task to FE(sysstc) and still during extremely heavy >processing we see 5 minutes time frame of jobs moving thru the CA7 queues >before hitting the input queue. We see know indicated waits on anything >but CPU. We were recently on a 1.7 migration call with IBM and one >customer asked IBM this question. The reps from IBM were not aware of this >problem but did say they would follow up with this customer but did not >indicate who this customer was during the call. > >-- >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: WTO Question
Left hand/right hand? 33.1.4 Input Register Information Before issuing the WTO macro, the caller does not have to place any information into any register unless using it in register notation for a particular parameter, or using it as a base register. 33.1.5 Output Register Information When control returns to the caller, the general purpose registers (GPRs) contain: Register Contents 0 Used as a work register by the system. 1 Message identification number if the macro completed normally. You can use this number to delete the message when it is no longer needed. If you are using the CONNECT parameter to connect WTO messages, store this value in the 4-byte CONNECT field and set register 0 to zero before issuing the next WTO. Otherwise, register 1 is used as a work register by the system. 2-13 Unchanged. 14 Used as a work register by the system. 15 Return code. IBM Mainframe Discussion List wrote on 08/03/2006 01:16:44 PM: > I was doing some work on an issue here and thought I read that as of > z/OS 1.7 you must clear R0 prior to a WTO and use CONNECT instead. > Did anyone else see that little comment somewhere or something like it? > I've searched every 1.7 PDF I have on my hard drive for z/OS 1.7 macros > and I can't find it, and yet my "tickler" notes from that evening about > a week ago... - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- 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: OA17292 Data Loss with VSAM LSR Hiperspace
The question's answer is "IMS and VSAM only are exposed. CICS is not." Brian On Thu, 3 Aug 2006 12:00:27 -0500, Brian Peterson <[EMAIL PROTECTED]> wrote: > I do not know if other VSAM LSR exploiters (such as CICS) are >affected. I have asked that question. > -- 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
WTO Question
I was doing some work on an issue here and thought I read that as of z/OS 1.7 you must clear R0 prior to a WTO and use CONNECT instead. Did anyone else see that little comment somewhere or something like it? I've searched every 1.7 PDF I have on my hard drive for z/OS 1.7 macros and I can't find it, and yet my "tickler" notes from that evening about a week ago... Regards, Steve Thompson -- 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
LPAR Underload Concern
Hal -- It really depends on whether or not the defined capacity actually kicks in and begins to limit the LPAR with a soft-cap. If the 4 hour average goes above 4 MSUs the cap will be enforced. You can have much larger peaks without the cap, it depends on the duration of the peaks. The real question is how many MSUs is that LPAR using on a regular and on a 4 hour rolling average basis. When the soft cap is on, the system will run as if it was out of CPU resource. Your WLM will determine which service classes are impacted based on your goals. Best regards, Al -- Al Sherkow, I/S Management Strategies, Ltd. Consulting Expertise on Capacity Planning, Performance Tuning, WLC, LPARs, IRD and LCS Software Seminars on IBM SW Pricing, LPARs, and IRD Voice: +1 414 332-3062 Web: www.sherkow.com -- 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: OA17104 if you have zIIP support installed
JBB772S is GA and the APARs are all available for viewing in IBMLink. I think that there are IBMers circling the globe suggesting that customers install the zIIP Web Deliverable, because the Web Deliverable - even on a non-zIIP machine - delivers the *instrumentation* necessary to determine the potential value of a zIIP in a given customer environment. That's not to say I don't have any friendsI'd like to think I do! Brian On Thu, 3 Aug 2006 06:40:02 -0700, Edward Jaffe wrote: >Do you have an IBM information that calls you when something like this >becomes available, or are you actually experiencing these issues? Why >would you install zIIP support if you don't have a zIIP processor? -- 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
Heads Up: OA17292 Data Loss with VSAM LSR Hiperspace
Here's another interesting problem. OA17292 is an APAR against VSAM which describes a failure to correctly invalidate buffers stored in the hiperspace cache, which can result in downlevel data replacing current data and thus is flagged DATALOSS. The APAR text mentions IMS as being exposed. The defect, however, is within VSAM. I do not know if other VSAM LSR exploiters (such as CICS) are affected. I have asked that question. Interestingly, one of the APAR symptoms is errors flagged by an IMS pointer checker utility. I am unaware of a "pointer checker" for CICS VSAM files, so I do not know how one would know of data loss in a non-IMS environment. Keep in mind what I know about CICS (or IMS for that matter) I could easily write upon the head of a pin Brian -- 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: Test tools, was: Strobe equivalents
Beate, Compuware have a wide range of products for all your test management needs (one bright example, the Strobe in the title of this thread). Please feel free to contact me offline, or your local friendly Compuware rep, to discuss this further. ciao! Aurora Emanuela Dell'Anno Compuware Ltd. Systems Engineer, Mainframe pre-Sales ___ email: [EMAIL PROTECTED] tel. : +44 (0)1753 444331 cell.: +44 (0)7779 881331 ___ No trees were killed in the sending of this message. However - a large number of electrons were terribly inconvenienced. -Original Message- From: Beate Kawelke [mailto:[EMAIL PROTECTED] Sent: 01 August 2006 08:58 Subject: Test tools, was: Strobe equivalents Wow, this list is cool ! We are currently looking for tools to help us manage test scenarios - up to now to no avail. We would like to define test scenarios and also manage the data / processes. For example, a test scenario would consist of some user input in ISPF panels, a server request, a result being displayed, a dataset being created. After a major change to our software, we would run that scenario (as automated as possible) and check if the results are the same. Anybody got input on that ? Regards, Beate The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. -- 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: SVC Dumps and DB2
Lizette, DASD-wise, not sure if you've looked already, but the DB2 V8 Installation Guide has dump data set size storage requirements in Chapter 2. IBM support notes that "... summary data in dumps is usually enough to diagnose most problems". Lock Lyon Compuware Corp Lizette Koehler <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 08/03/2006 08:31 AM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject SVC Dumps and DB2 Does anyone know if there is a way to reduce the amount of information DB2 feels it needs to dump when it requests an SVC Dump? We had MAXSPACE set at 4500M and it still was not enough. I do have the Dump Data sets SMS managed and STRIPPED (extended format) so that part should not be a problem. Or is there a way to calculate how much MAXSPACE will be needed by DB2? 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
LPAR Underload Concern.
We have a z/os.e and z/os basic sysplex. We have moved all of our work except TSO and the job scheduler to z/os.e. The only reason the scheduler has not moved is the TSO interface. Now the z/os LPAR is soft capped at 4 MSU and seems to have plenty of headroom. In my earlier years, I seem to recall some issues with 'under load'. More, I worry about a MAS with an LPAR that is asleep most of the time. Do I need to worry? If so, what should I do? Thanks all. NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
IEFACTRT
Does anyone have an example of IEFACTRT using type 30 and doing chargeback that they would be willing to share? -- 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: Spreading Batch Work Across LPARS
On Thu, 3 Aug 2006 09:52:41 -0400, Mark Jacobs wrote: >On Thursday 03 August 2006 09:36, Edward Jaffe wrote: > >> You make your bed. Then you lie in it. ;-) >> >The resistance is from a different group in the datacenter that likes to hand >tune things > >> Seriously, there are definitely certain types of workloads that don't do >> well with WLM-managed batch initiators. (For example, a workload that >> requires guaranteed immediate initiation -- so called "hot" batch -- or >> one that depends on over-initiation or fixed initiator limits.) But, for >> most batch workloads, it's just fine. It's easy to try as well. (One >> command can switch a JES2 job class to/from WLM management.) > >They don't want to do what they don't want to do. Mark, I developed a design for another site locally that allowed workload to be leveled by using ThruPut Manager's limiting agents and a small started task that queried WLM periodically to see how busy each image was at the various importance levels and then it would readjust the limiting agents availability to push subsequent batch job starts to various JES2 members accordingly. (The importance levels there could identify categories of work very easily and could therefore immediately clue it in on whether the CPU busy was due to onlines, production batch, or other loved-or-unloved- ones.) The overload was tiny (a couple or three CPU minutes per day) and it accomplished the goal nicely. But I'm not going to suggest it to your site since they want to hand tune and that was automated. It even inserted the agents dynamically so there were no JCL changes needed. (It still is running there, as far as I know; Mark D., please chime in to correct or agree as appropriate.) The folks at ThruPut Manager support/development will certainly work with you on the issue. They have an alternative design that they seemed to like, but it wouldn't have worked at the site I mentioned. Maybe it will work for you? -- Tom Schmidt Madison, WI -- 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: Spreading Batch Work Across LPARS
Hi Mark, You might also consider to join the tm-discuss list and posting this question there. I know there are some folks who hang out there that don't monitor IBM-MAIN because of the volume. The form to join is in the customer center on the MVS Solutions web site. http://www.mvssol.com/customers/TECH_Form_TMDiscuss.htm http://www.mvssol.com Join the ThruPut Manager Discussion List The ThruPut Manager discussion list is a restricted e-mail list available only to registered ThruPut Manager customers and MVS Solutions staff. It is intended to give customers a simple way to communicate with other customers about their use of ThruPut Manager. For example, you might ask what changes people made to their procedures and their JAL when they implemented VTS drives. All replies go automatically to the list so the information can be shared by all members. Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 "Think big, act bold, start simple, grow fast..." -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Jacobs Sent: Thursday, August 03, 2006 7:48 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Spreading Batch Work Across LPARS We have two lpars that perform the vast majority of our batch work. CA7 runs on one of these lpars and most of the CA7 submitted jobs are picked up by the JES2 on that system. This leaves the other system almost empty of batch work while the first system is being over loaded. What are some of our options to spread the workload across both systems on an equal basis. zOS 1.4. JES2 managed batch. Thruput manager is available. Thanks. -- Mark Jacobs Time Customer Service Tampa, FL This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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: CA7 Slowdown after 1.7 implementation
> Has anyone had any issues with CA7 since moving to 1.7. <<>> > We were recently on a 1.7 migration call with IBM and one > customer asked IBM this question. The reps from IBM were not aware of this > problem but did say they would follow up with this customer but did not > indicate who this customer was during the call. IBM brought this to our attention and we are looking into it with that customer. There is nothing to report so far. If anything comes out of this it will be passed along to CA7 customers asap and (no doubt) it will show up here on rumor central too :-) 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: CA7 Slowdown after 1.7 implementation
We did not notice any slowdowns after installing 1.7 in two lpars each with their own CA7 (release 3.3) Alan Schwartz Assurant Shared Business Services Lead Systems Programmer Phone: 651-361-4758 Fax: 651-361-5625 Casey Rhodes <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 08/03/2006 08:58 AM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject CA7 Slowdown after 1.7 implementation Has anyone had any issues with CA7 since moving to 1.7. We have 14 sysplex's and only have this problem in one. The one having the problem is the largest with the heaviest volume. We believe this is due to the JES internal reader changes made in 1.7. We have increased the dispatch priority of the task to FE(sysstc) and still during extremely heavy processing we see 5 minutes time frame of jobs moving thru the CA7 queues before hitting the input queue. We see know indicated waits on anything but CPU. We were recently on a 1.7 migration call with IBM and one customer asked IBM this question. The reps from IBM were not aware of this problem but did say they would follow up with this customer but did not indicate who this customer was during the call. ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ** -- 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: CA7 Slowdown after 1.7 implementation
Casey, May I ask what release of CA7 you are on? Ed Micucci -- 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: OA17104 if you have zIIP support installed
In a message dated 8/3/2006 8:40:20 A.M. Central Standard Time, [EMAIL PROTECTED] writes: becomes available, or are you actually experiencing these issues? Why would you install zIIP support if you don't have a zIIP processor? >> Lacking Plug 'n Play what choices are there? Install zIIP without requisites or install requisites and then the zIIP. For new hardware I've always chosen they latter except where ACTion or EC HOLDs specify otherwise. -- 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: z/OS 1.7 Last ServerPac Order Date?
On Thu, 3 Aug 2006 10:55:40 -0400, Mark Jacobs <[EMAIL PROTECTED]> wrote: >On Thursday 03 August 2006 10:33, Ken Porowski wrote: >> Anyone know what will be the cutoff date for ordering z/OS 1.7 >> ServerPac. >> I imagine it will be fairly soon as 1.8 is coming out. >> >> Thanks >> >> Ken Porowski >> AVP Systems Software >> CIT Group >> E: [EMAIL PROTECTED] > >I have not heard an official date but based on past experience the last 1.7 >orders will be accepted about 2 weeks before zOS 1.8 is available for >ordering. >-- > >Mark Jacobs >Time Customer Service >Tampa, FL > Projected date is September. http://www-03.ibm.com/servers/eserver/zseries/zos/support/zos_eos_dates.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: CA7 Slowdown after 1.7 implementation
Well, I hopefully will be able to answer this sometime next week. Our plan is a Monday morning z/OS 1.5 to 1.7 upgrade on our last production (2 of them ) image where CA-7 just happens to be running. Nothing in test but then again this is one of those that might be hard to see in test. At 09:58 AM 8/3/2006, you wrote: Has anyone had any issues with CA7 since moving to 1.7. We have 14 sysplex's and only have this problem in one. The one having the problem is the largest with the heaviest volume. We believe this is due to the JES internal reader changes made in 1.7. We have increased the dispatch priority of the task to FE(sysstc) and still during extremely heavy processing we see 5 minutes time frame of jobs moving thru the CA7 queues before hitting the input queue. We see know indicated waits on anything but CPU. We were recently on a 1.7 migration call with IBM and one customer asked IBM this question. The reps from IBM were not aware of this problem but did say they would follow up with this customer but did not indicate who this customer was during the call. -- 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 Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/Sysarc Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 [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
Re: CA7 Slowdown after 1.7 implementation
I definitely will be interested in this one since we will be starting our rollout of z/OS 1.7 on August 13. We also run CA-7. ___ Jim Petersen MVS - Lead Systems Engineer Home Depot Technology Center 1300 Park Center Drive, Austin, TX 78753 www.homedepot.com email: [EMAIL PROTECTED] 512-977-2615 direct 512-977-2930 fax 210-859-9887 cell This message may contain confidential information. The information contained in this message and any attachments are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any disclosure, copying, distribution or other use of the contents of this message is strictly prohibited. If you have received this email in error, please notify the sender immediately by email and delete all copies of this message -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Casey Rhodes Sent: Thursday, August 03, 2006 8:59 AM To: IBM-MAIN@BAMA.UA.EDU Subject: CA7 Slowdown after 1.7 implementation Has anyone had any issues with CA7 since moving to 1.7. We have 14 sysplex's and only have this problem in one. The one having the problem is the largest with the heaviest volume. We believe this is due to the JES internal reader changes made in 1.7. We have increased the dispatch priority of the task to FE(sysstc) and still during extremely heavy processing we see 5 minutes time frame of jobs moving thru the CA7 queues before hitting the input queue. We see know indicated waits on anything but CPU. We were recently on a 1.7 migration call with IBM and one customer asked IBM this question. The reps from IBM were not aware of this problem but did say they would follow up with this customer but did not indicate who this customer was during the call. -- 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: Heads Up: OA17104 if you have zIIP support installed
For PROJECTCPU - to see how much you can actually save if you had a zIIP lying around... (Although we just got a zIIP and a zAAP to see how our products fare on it. My stuff's working. :-) Later, Ray -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Thursday August 03 2006 06:40 Brian Peterson wrote: > IF > > you have JBB77S2 (z/OS 1.6) or JBB772S (z/OS 1.7) zIIP Web Deliverable > installed, > > AND > > if you have crypto, > > THEN > > you WILL want the fix for OA17104. > > Without OA17104's fix, when you shut down your ICSF started task, > apparently z/OS dispatching queue damage occurs resulting in a spin loop. > > This APAR has yet to hit the ZOSV1R7 BCPZIIP PSP Bucket. > Do you have an IBM information that calls you when something like this becomes available, or are you actually experiencing these issues? Why would you install zIIP support if you don't have a zIIP processor? -- 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: z/OS 1.7 Last ServerPac Order Date?
On Thursday 03 August 2006 10:33, Ken Porowski wrote: > Anyone know what will be the cutoff date for ordering z/OS 1.7 > ServerPac. > I imagine it will be fairly soon as 1.8 is coming out. > > Thanks > > Ken Porowski > AVP Systems Software > CIT Group > E: [EMAIL PROTECTED] I have not heard an official date but based on past experience the last 1.7 orders will be accepted about 2 weeks before zOS 1.8 is available for ordering. -- Mark Jacobs Time Customer Service Tampa, FL - b.i.b.a.w.y.l.o. and i.w.w.y.t.b.w. Brian Smith to his wife Maureen To Sail Beyond the Sunset -- 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: Spreading Batch Work Across LPARS
John Eells wrote: Install z/OS R8 when available and use WLM-manage inits? From the R8 preview announcement: "JES2 will be designed to help balance workload in a multi-access spool configuration within a sysplex by controlling the number of WLM-managed initiators in use on each system." (G, D, & R!) Unlike JES3, JES2 job scheduling is not cooperative between members and IBM has been trying to fix the resulting imbalances for a long, long time. They hoped that WLM might provide the solution. So far, it hasn't. When WLM-managed batch initiators first arrived in OS/390 V2R4, JES2 borrowed the JES3 concept of TLIMIT, to limit the number of jobs that can be simultaneously active in the class at a JESplex level. (JES2 calls this XEQCOUNT.) Not good enough. Since then, they've tried to make WLM better at balancing the sizes of the initiator pools on each system. Still not good enough. Now, in z/OS 1.8, JES2 borrows the JES3 concept of MLIMIT, to limit the number of jobs that can be simultaneously active in the class at a member level. (I believe z/OS 1.8 JES2 calls this XEQMEMBER.) Will that be good enough? They can futz with the various limits all they want. It won't make JES2 members perform cooperative job scheduling! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: Spreading Batch Work Across LPARS
Sounds to me that someone is scared that you will automate a process and eliminate their need to be in the company. We've told folks here as we automate our processes that there are still other things to learn to guarantee keeping a job. Example: we added an ATL to the mainframe and are putting HSM and DR backups into it. The process to eject tapes is in place and runs daily. The reduced load on the operator will result in one less resource per shift on the weekends, saving the company some bucks. SLAs alone ought to keep us driving for better methods. Daniel McLaughlin ZOS Systems Programmer Crawford & Company PH: 770 621 3256 * Victory is won not in miles but in inches. Win a little now, hold your ground, and later, win a little more." ? Louis L'Amour -- 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: Spreading Batch Work Across LPARS
"Mark Jacobs" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > On Thursday 03 August 2006 09:36, Edward Jaffe wrote: > > > You make your bed. Then you lie in it. ;-) > > > The resistance is from a different group in the datacenter that likes to hand > tune things > > > Seriously, there are definitely certain types of workloads that don't do > > well with WLM-managed batch initiators. (For example, a workload that > > requires guaranteed immediate initiation -- so called "hot" batch -- or > > one that depends on over-initiation or fixed initiator limits.) But, for > > most batch workloads, it's just fine. It's easy to try as well. (One > > command can switch a JES2 job class to/from WLM management.) > > They don't want to do what they don't want to do. > -- > Well, than you could answer that you cannot do what they want you to achieve, if they won't let you use modern techniques. The abandoned their abacus, didn't they? Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** -- 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.7 Last ServerPac Order Date?
Anyone know what will be the cutoff date for ordering z/OS 1.7 ServerPac. I imagine it will be fairly soon as 1.8 is coming out. Thanks Ken Porowski AVP Systems Software CIT Group E: [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
Re: Heads Up: OA17104 if you have zIIP support installed
On Thu, 3 Aug 2006 06:43:09 -0700, Edward Jaffe <[EMAIL PROTECTED]> wrote: >Edward Jaffe wrote: >> Do you have an IBM information that calls you when something like this >> becomes available, or are you actually experiencing these issues? Why >> would you install zIIP support if you don't have a zIIP processor? > >Typing too fast. I meant to ask, "Do you have an IBM _informant_ that >calls you when ..." > In our case, sometimes it's our SE that gets notification (can't tell you how that process works) and lets us know about things like this prior to us finding out from current HOLDDATA & SMP/E Reports, Red Alerts, or the grape vine AKA IBM-MAIN. :-) One might install zIIP support even if they don't have a zIIP processor if they were planning on getting one. Also, the zIIP might only be on a couple of LPARs but by virtue of sharing the sysres, the code would be on all the LPARs. In our case, we have the code and have LPARs running CSF that don't or won't have zIIPs. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: WhaT do these dates mean?
"John D. Slayton" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > In the M20TEST consoleor when Iselect that in the TN3270 > consoles...I get this: > > 06.215 AUG 03 09.43.22 PAGE 1 > > > > > > What does the 06.215 mean??? I knoewthe the 06 means the YEAR and I > know all the rest but about the "215" What does that mean??? Let me > guess...DOes it mean the number of days since Jan 1, 2006??? Am I > correct or wrong... > > Just here to verifySo tomorrow it will be 216Am I right??? > > thanks > That's it, it is the Julian date format and used often in (mainframe) IT. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** -- 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
CA7 Slowdown after 1.7 implementation
Has anyone had any issues with CA7 since moving to 1.7. We have 14 sysplex's and only have this problem in one. The one having the problem is the largest with the heaviest volume. We believe this is due to the JES internal reader changes made in 1.7. We have increased the dispatch priority of the task to FE(sysstc) and still during extremely heavy processing we see 5 minutes time frame of jobs moving thru the CA7 queues before hitting the input queue. We see know indicated waits on anything but CPU. We were recently on a 1.7 migration call with IBM and one customer asked IBM this question. The reps from IBM were not aware of this problem but did say they would follow up with this customer but did not indicate who this customer was during the call. -- 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: Spreading Batch Work Across LPARS
On Thursday 03 August 2006 09:36, Edward Jaffe wrote: > You make your bed. Then you lie in it. ;-) > The resistance is from a different group in the datacenter that likes to hand tune things > Seriously, there are definitely certain types of workloads that don't do > well with WLM-managed batch initiators. (For example, a workload that > requires guaranteed immediate initiation -- so called "hot" batch -- or > one that depends on over-initiation or fixed initiator limits.) But, for > most batch workloads, it's just fine. It's easy to try as well. (One > command can switch a JES2 job class to/from WLM management.) They don't want to do what they don't want to do. -- Mark Jacobs Time Customer Service Tampa, FL - b.i.b.a.w.y.l.o. and i.w.w.y.t.b.w. Brian Smith to his wife Maureen To Sail Beyond the Sunset -- 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: OA17104 if you have zIIP support installed
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of John Eells > Sent: Thursday, August 03, 2006 8:41 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Heads Up: OA17104 if you have zIIP support installed > > Well, we're a bit reluctant to turn up the clock speed. We'd > have to pay them more per hour that way. > > -- > John Eells Well, I wonder if some insane PC person could figure out how to put a z9BC into LN2 and overclock it? I guess that would void the warranty, right? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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: OA17104 if you have zIIP support installed
Edward Jaffe wrote: Do you have an IBM information that calls you when something like this becomes available, or are you actually experiencing these issues? Why would you install zIIP support if you don't have a zIIP processor? Typing too fast. I meant to ask, "Do you have an IBM _informant_ that calls you when ..." -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: OA17104 if you have zIIP support installed
[EMAIL PROTECTED] wrote: In a message dated 8/3/2006 7:57:20 A.M. Central Standard Time, [EMAIL PROTECTED] writes: somewhat later than that. Ya gotta give the guys in Boulder that maintain the PSPs a *little* time...!) > Or a faster processor??? Well, we're a bit reluctant to turn up the clock speed. We'd have to pay them more per hour that way. -- John Eells z/OS Technical Marketing IBM Poughkeepsie [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
Re: Heads Up: OA17104 if you have zIIP support installed
Brian Peterson wrote: IF you have JBB77S2 (z/OS 1.6) or JBB772S (z/OS 1.7) zIIP Web Deliverable installed, AND if you have crypto, THEN you WILL want the fix for OA17104. Without OA17104's fix, when you shut down your ICSF started task, apparently z/OS dispatching queue damage occurs resulting in a spin loop. This APAR has yet to hit the ZOSV1R7 BCPZIIP PSP Bucket. Do you have an IBM information that calls you when something like this becomes available, or are you actually experiencing these issues? Why would you install zIIP support if you don't have a zIIP processor? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: Spreading Batch Work Across LPARS
Mark Jacobs wrote: We have two lpars that perform the vast majority of our batch work. CA7 runs on one of these lpars and most of the CA7 submitted jobs are picked up by the JES2 on that system. This leaves the other system almost empty of batch work while the first system is being over loaded. What are some of our options to spread the workload across both systems on an equal basis. zOS 1.4. JES2 managed batch. Thruput manager is available. Thanks. Install z/OS R8 when available and use WLM-manage inits? From the R8 preview announcement: "JES2 will be designed to help balance workload in a multi-access spool configuration within a sysplex by controlling the number of WLM-managed initiators in use on each system." (G, D, & R!) -- John Eells z/OS Technical Marketing IBM Poughkeepsie [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
Re: CPU usage for paging
Ted MacNEIL writes: >The OP was asking for advice on how to determine the CPU requirement for paging. >NOT, a sales pitch, which is ALL you seem to do! I was trying to advise the OP on how to spend less money with my employer, actually. Although yes, I admit, I was trying to sell him on shipping me his z800. Guilty on that count. - - - - - 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
Re: Spreading Batch Work Across LPARS
Mark Jacobs wrote: On Thursday 03 August 2006 08:23, Edward Jaffe wrote: Mark Jacobs wrote: What are some of our options to spread the workload across both systems on an equal basis. In spite of it's selfish behavior, which can't be changed, a JES2 member will always stop initiating work when no initiators are left to be populated. Therefore, if you limit the number of available initiators on the overworked system, the other system will pick up the slack. We still want both systems to have about the same number of batch jobs running so limiting initiators on one systems isn't a good solution, Then limit the number of initiators on *both* systems! zOS 1.4. JES2 managed batch. Thruput manager is available. You might consider the use of WLM-managed batch initiators. Beginning with z/OS V1R4, it more aggressively "trims" the initiator pool on overworked systems. There is strong resistance to WLM batch. You make your bed. Then you lie in it. ;-) Seriously, there are definitely certain types of workloads that don't do well with WLM-managed batch initiators. (For example, a workload that requires guaranteed immediate initiation -- so called "hot" batch -- or one that depends on over-initiation or fixed initiator limits.) But, for most batch workloads, it's just fine. It's easy to try as well. (One command can switch a JES2 job class to/from WLM management.) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: Data set ENQueues and DEQueues in Jobs
On 2 Aug 2006 18:46:04 -0700, in bit.listserv.ibm-main you wrote: >At 12:22 -0400 on 08/01/2006, Wayne Driscoll wrote about Re: Data set >ENQueues and DEQueues in Jobs: > >>I could see how a downgrade would be useful. For instance: I have a >>resource shared. Now I need to update the resource, so I perform an >>S->E. Now, I want to allow others to see the update, but I don't want >>to allow an exclusive user to lock me out of the resource, so a E->S >>change would allow this to happen. > >Even more importantly, as I've noted in prior messages in this >thread, the capability to do a E->S downgrade would fix the current >"Design Flaw" in the Initiator where if you follow a Job Step that >has DISP=OLD/MOD for a Dataset with DISP=SHR Job Steps, these >subsequent Job Steps keep the exclusive ENQ until the Job is over (or >there are no more steps using the dataset). Support for E->S >downgrade would allow other jobs to take off once the last >DISP=OLD/MOD step is done and the first DISP=SHR step starts. I was under the impression that the initiator was able to downgrade from NEW/OLD/MOD to SHR between steps. -- 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: Spreading Batch Work Across LPARS
On Thu, 2006-08-03 at 08:56 -0400, Mark Jacobs wrote: > > You might consider the use of WLM-managed batch initiators. Beginning > > with z/OS V1R4, it more aggressively "trims" the initiator pool on > > overworked systems. > > There is strong resistance to WLM batch. u - I bit my tongue earlier, If you have multiple, non-homogenous CECs in a 'plex, you *really* don't want to be toying with WLM managed inits at z/OS 1.4. I'm waiting on my 1.7 shipment, at which point I will revisit this, but our experience with this was a total bloody disaster. As always, YMMV - better I hope. 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: Heads Up: OA17104 if you have zIIP support installed
In a message dated 8/3/2006 7:57:20 A.M. Central Standard Time, [EMAIL PROTECTED] writes: somewhat later than that. Ya gotta give the guys in Boulder that maintain the PSPs a *little* time...!) >> Or a faster processor??? -- 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: Spreading Batch Work Across LPARS
On Thu, 3 Aug 2006 08:56:53 -0400, Mark Jacobs <[EMAIL PROTECTED]> wrote: >On Thursday 03 August 2006 08:23, Edward Jaffe wrote: >> >> You might consider the use of WLM-managed batch initiators. Beginning >> with z/OS V1R4, it more aggressively "trims" the initiator pool on >> overworked systems. > >There is strong resistance to WLM batch. >-- Why? It's really easy to try. If you are over-initiated, you might find that your throughput increases. What kind of goals do you have for your production batch? Tom Marchant -- 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: RES: compress a proclib
On Thu, 3 Aug 2006 09:00:56 -0300, Ituriel do Nascimento Neto <[EMAIL PROTECTED]> wrote: >I've always compressed a PROCLIB with IEBCOPY (DISP=SHR) and never had a >problem. >But there is another possible solution : > >1) Remove PROC00 from JES2 PROC and substitue it by PROCLIB statment in >JES2PARM >like sample below > >PROCLIB(PROC00) DD(001)=(DSNAME=SYS1.PROCLIB ),UNCONDITIONAL >PROCLIB(PROC00) DD(002)=(DSNAME=SYS2.PROCLIB ),UNCONDITIONAL >PROCLIB(PROC00) DD(003)=(DSNAME=SYS3.PROCLIB ),UNCONDITIONAL >PROCLIB(PROC00) DD(004)=(DSNAME=SYS4.PROCLIB ),UNCONDITIONAL > >2) Let's assume SYS3.PROCLIB gets full. Create another proclib >(SYSX.PROCLIB) >and copy SYS3.PROCLIB into it. > >3) Substitute SYS3.PROCLIB by SYSX.PROCLIB issueing the command >$TPROCLIB(PROC00),DD(003)=(DSNAME=SYSX.PROCLIB). > >4) Realloc a new SYS3.PROCLIB (or use PDS86 to enlarge it) and copy >SYSX.PROCLIB >back. > >5) Substitute SYSX.PROCLIB by SYS3.PROCLIB (same command above) > > Looks a bit like swapping out a LNKLST lib... but it doesn't have to be that complicated! With dynamic proclibs you can compress them (DISP=SHR or OLD is better since that will stop JCLLIB access) and then just issue $TPROCLIB(*) or RO *ALL,$TPROCLIB(*) if other systems in the sysplex share the same proclib. We do have to compress PROCLIBs occasionally. The above procedure is what I have been using since dynamic proclib support and have never run into a problem. I have also used it to fix the "compress problem" when I get calls from another support group that has compressed their proclib and starts seeing "strange results". BTW, all our "production" PROCLIBs were swapped out to PDSE long before dynamic proclib support to avoid these compress issues. These PROCLIBs were constantly updated and needed to be compressed on a regular basis. One other note... if you compress a PROCLIB allocated to *MASTER* (MSTJCLxx) and a proc is started with SUB=MSTR, you're SOL until you IPL if you run into "strange results". There is no refresh trick. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: SVC Dumps and DB2
We use 6000M without any issues. Thanks. John Eatherly Or is there a way to calculate how much MAXSPACE will be needed by DB2? -- 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: compress a proclib
Bruce, That's how I remember it also. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Bruce Hewson > Sent: Thursday, 3 August 2006 1:18 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: compress a proclib > > Actually, because JES2 normally does not have a ENQueue on its PROCLIBS, > you should be able to compress it with DISP=OLD. That will stop any I/O > errors for JCLLIBs. > > Regards > Bruce Hewson > > -- > 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: Spreading Batch Work Across LPARS
On Thursday 03 August 2006 08:08, Dave Thorn wrote: > 1. A new init class configuration, where class 'a' is on one LPAR and not > the other. Extending this to multiple classes would force work to one LPAR > or the other depending on a job's class. We (for historical reasons) have one production job class (with exceptions for special users). This job class has 20-30 initiators available on each system. > 2. WLM Scheduling Environments. Run some applications on one LPAR, other > applications on the other. I just thought of something that might work. > 3. I don't have Thruput Manager but it sounds pretty flexible; maybe they > have something that can do this easier than #1 and 2 above. To be looked at. Thanks -- Mark Jacobs Time Customer Service Tampa, FL - b.i.b.a.w.y.l.o. and i.w.w.y.t.b.w. Brian Smith to his wife Maureen To Sail Beyond the Sunset -- 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: Spreading Batch Work Across LPARS
On Thursday 03 August 2006 08:23, Edward Jaffe wrote: > Mark Jacobs wrote: > > We have two lpars that perform the vast majority of our batch work. CA7 > > runs on one of these lpars and most of the CA7 submitted jobs are picked > > up by the JES2 on that system. This leaves the other system almost empty > > of batch work while the first system is being over loaded. > > That's just how JES2 works. The member holding the checkpoint always > attempts to schedule all available work. I've discussed this phenomenon > many times. > I know. They know. They still want it fixed. > > What are some of our options to spread the workload across both systems > > on an equal basis. > > In spite of it's selfish behavior, which can't be changed, a JES2 member > will always stop initiating work when no initiators are left to be > populated. Therefore, if you limit the number of available initiators on > the overworked system, the other system will pick up the slack. We still want both systems to have about the same number of batch jobs running so limiting initiators on one systems isn't a good solution, > > > zOS 1.4. JES2 managed batch. Thruput manager is available. > > You might consider the use of WLM-managed batch initiators. Beginning > with z/OS V1R4, it more aggressively "trims" the initiator pool on > overworked systems. There is strong resistance to WLM batch. -- Mark Jacobs Time Customer Service Tampa, FL - b.i.b.a.w.y.l.o. and i.w.w.y.t.b.w. Brian Smith to his wife Maureen To Sail Beyond the Sunset -- 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: OA17104 if you have zIIP support installed
Brian Peterson wrote: Without OA17104's fix, when you shut down your ICSF started task, apparently z/OS dispatching queue damage occurs resulting in a spin loop. This APAR has yet to hit the ZOSV1R7 BCPZIIP PSP Bucket. Not sure what time it was added, but it's in the bucket now. Also, I'll note that OA17104 is marked HIPER. (The PTFs didn't close until 1229 yesterday afternoon, and the change team likely sent the update for the PSP to Boulder somewhat later than that. Ya gotta give the guys in Boulder that maintain the PSPs a *little* time...!) -- John Eells z/OS Technical Marketing IBM Poughkeepsie [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
Re: compress a proclib
Thanks for your comments. I compressed the proclib in place at a very low activity time on the system. -- 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: Spreading Batch Work Across LPARS
>From old brain cells... I know we used JES Route cards with CA-7 (and now with Control-M). I think ThruPut Manager has "routable" resources as well, but I've never used them. I think TPM might be able to route, but like I said in the first note, my somewhat dated experience was MAS, and seemed to be easier. On Edward's JES checkpoint holder affinity point; I don't think our workload would have ever exposed that, but I do seem to recall that if you submitted a job from TSO, it "tended" to run on the same system that submitted it. Maybe that's why My life is sure easier on one physical processor, one production LPAR and all RAID disk. I DO NOT miss the old 3380 HDA failures -- 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
SVC Dumps and DB2
Does anyone know if there is a way to reduce the amount of information DB2 feels it needs to dump when it requests an SVC Dump? We had MAXSPACE set at 4500M and it still was not enough. I do have the Dump Data sets SMS managed and STRIPPED (extended format) so that part should not be a problem. Or is there a way to calculate how much MAXSPACE will be needed by DB2? 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: Spreading Batch Work Across LPARS
What is the overall CPU usage? If the REAL system is "overloaded", then splitting work between LPAR's won't help. There is only 100% of the real CPU. Is your JES MAS across all LPARs? That was the last "LPAR" sharing environment I used, but it was across multiple physical processors. We run almost all of our batch jobs in the same class but use Thruput Manager agents and limits to manage work and assign WLM service class. If I opened up the same class on a MAS'ed LPAR and set the TM limits appropriately, work would move to that MAS as JES selected it. For example, I allow the following job limits on one LPAR: 10 "express" (WLM Express) 20 "Normal" (WLM Normal) 10 "slack" (WLM Discretionary) 13 "big cpu" But only 25 "total" jobs, but some "system" jobs such as db log dumps are exempt from that limit. When we had a second system in the MAS, I could set TM limits for 10 express jobs and 2 slack jobs for the 2nd system. Jobs in those categories could run on either system. Of course, other "resources" dictate otherwise, a job bound to IMSPROD would be limited to that LPAR. -- 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: Spreading Batch Work Across LPARS
I thought that CA-7 had a way, or was it JES with a route card, to schedule work on plexed systems? Daniel McLaughlin ZOS Systems Programmer Crawford & Company PH: 770 621 3256 * Victory is won not in miles but in inches. Win a little now, hold your ground, and later, win a little more." ? Louis L'Amour -- 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: Spreading Batch Work Across LPARS
Mark Jacobs wrote: We have two lpars that perform the vast majority of our batch work. CA7 runs on one of these lpars and most of the CA7 submitted jobs are picked up by the JES2 on that system. This leaves the other system almost empty of batch work while the first system is being over loaded. That's just how JES2 works. The member holding the checkpoint always attempts to schedule all available work. I've discussed this phenomenon many times. What are some of our options to spread the workload across both systems on an equal basis. In spite of it's selfish behavior, which can't be changed, a JES2 member will always stop initiating work when no initiators are left to be populated. Therefore, if you limit the number of available initiators on the overworked system, the other system will pick up the slack. zOS 1.4. JES2 managed batch. Thruput manager is available. You might consider the use of WLM-managed batch initiators. Beginning with z/OS V1R4, it more aggressively "trims" the initiator pool on overworked systems. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: Spreading Batch Work Across LPARS
"Mark Jacobs" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > We have two lpars that perform the vast majority of our batch work. CA7 runs > on one of these lpars and most of the CA7 submitted jobs are picked up by the > JES2 on that system. This leaves the other system almost empty of batch work > while the first system is being over loaded. > > What are some of our options to spread the workload across both systems on an > equal basis. > > zOS 1.4. JES2 managed batch. Thruput manager is available. > > Thanks. > -- If you are in a Sysplex: WLM Managed Initiators. 1.4 has enhancements to WLM managed initiators, that makes it intelligently manage your batch. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** -- 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: Spreading Batch Work Across LPARS
1. A new init class configuration, where class 'a' is on one LPAR and not the other. Extending this to multiple classes would force work to one LPAR or the other depending on a job's class. 2. WLM Scheduling Environments. Run some applications on one LPAR, other applications on the other. 3. I don't have Thruput Manager but it sounds pretty flexible; maybe they have something that can do this easier than #1 and 2 above. __ Dave Thorn * Senior Technology Analyst * SunGard Computer Services * 600 Laurel Oak Road, Voorhees, NJ, 08043 Tel 856 566-5412 * Mobile 609 781-0353 * Fax 856 566-3656 CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this e-mail in error, please notify the sender and delete this e-mail from your system. Mark Jacobs <[EMAIL PROTECTED] SERV.COM> To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List <[EMAIL PROTECTED] Subject .EDU> Spreading Batch Work Across LPARS 08/03/2006 07:48 AM Please respond to IBM Mainframe Discussion List <[EMAIL PROTECTED] .EDU> We have two lpars that perform the vast majority of our batch work. CA7 runs on one of these lpars and most of the CA7 submitted jobs are picked up by the JES2 on that system. This leaves the other system almost empty of batch work while the first system is being over loaded. What are some of our options to spread the workload across both systems on an equal basis. zOS 1.4. JES2 managed batch. Thruput manager is available. -- 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
RES: compress a proclib
I've always compressed a PROCLIB with IEBCOPY (DISP=SHR) and never had a problem. But there is another possible solution : 1) Remove PROC00 from JES2 PROC and substitue it by PROCLIB statment in JES2PARM like sample below PROCLIB(PROC00) DD(001)=(DSNAME=SYS1.PROCLIB ),UNCONDITIONAL PROCLIB(PROC00) DD(002)=(DSNAME=SYS2.PROCLIB ),UNCONDITIONAL PROCLIB(PROC00) DD(003)=(DSNAME=SYS3.PROCLIB ),UNCONDITIONAL PROCLIB(PROC00) DD(004)=(DSNAME=SYS4.PROCLIB ),UNCONDITIONAL 2) Let's assume SYS3.PROCLIB gets full. Create another proclib (SYSX.PROCLIB) and copy SYS3.PROCLIB into it. 3) Substitute SYS3.PROCLIB by SYSX.PROCLIB issueing the command $TPROCLIB(PROC00),DD(003)=(DSNAME=SYSX.PROCLIB). 4) Realloc a new SYS3.PROCLIB (or use PDS86 to enlarge it) and copy SYSX.PROCLIB back. 5) Substitute SYSX.PROCLIB by SYS3.PROCLIB (same command above) Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto Banco Bradesco S/A 4254/DPCD Alphaville Suporte Técnico - Software Básico Mainframes Tel: 55 11 4197-2021 Fax: 55 11 4197-2814 AVISO LEGAL Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. +**+ LEGAL ADVICE This message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. -- 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
Spreading Batch Work Across LPARS
We have two lpars that perform the vast majority of our batch work. CA7 runs on one of these lpars and most of the CA7 submitted jobs are picked up by the JES2 on that system. This leaves the other system almost empty of batch work while the first system is being over loaded. What are some of our options to spread the workload across both systems on an equal basis. zOS 1.4. JES2 managed batch. Thruput manager is available. Thanks. -- Mark Jacobs Time Customer Service Tampa, FL - b.i.b.a.w.y.l.o. and i.w.w.y.t.b.w. Brian Smith to his wife Maureen To Sail Beyond the Sunset -- 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: PCOMM Macro Doesn't Work First Time
I didn't follow this thread, so please pardon me if this has been said before. In case you know some text that will always appear on the screen you're waiting for, you can code something like this in your macro: [wait app] wait 10 seconds until "TN3270 - Mainframe Telnet Server" goto macroend on timeout [wait inp inh] ... ... :macroend exit This sequence waits for the quoted text to appear on the screen and then waits for the keyboard to unlock. If the text does not appear whithin the timelimit (10s), then the macro will stop. Peter Hunkeler CREDIT SUISSE -- 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: PCOMM Macro Doesn't Work First Time
Ulrich Boche wrote: I've recorded a macro in PCOMM 5.8 for ELF (Express Logon Feature) purposes. The macro and the whole ELF stuff are working fine; however the macro always fails on the first connection attempt after starting the PCOMM window. If I disconnect and connect again, the macro is working fine, so apparently it is a timing problem. Here is the macro: [wait app] [wait inp inh] "l tso Just for the record, in case anyone else runs into this problem: I've found out that the following macro command sequence is working in all conditions: [wait sys] [wait app] [wait inp inh] "l tso ... -- Ulrich Boche SVA GmbH, Germany IBM Premier Business Partner -- 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: Data set ENQueues and DEQueues in Jobs
<- snip -> Are you sure that a single volume can't be known by two different names? Consider: surely it's possible to rename a volume (the verb "clip" comes to mind). Can one system dismount and rename a volume while it remains mounted on another system, then remount it by the new name while the other system still knows it by the old name? <- snip -> Oh yes. Just replace "dismount" and "remount" with "vary offline" and "vary online" respectively. Zaromil -- 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
