Re: reasons for using started task or batch job
Kees - You can exploit the use of system symbolic in batch using an IEFUJV exit. We have been doing this for several years. Frank. GSG Systems Engineering -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP - SPLXM Sent: Monday, August 13, 2012 2:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: reasons for using started task or batch job Besides the reasons for STC or job from the past, there is one important difference from the 'modern' area: STCs can fully use system symbols while jobs cannot (or hardly). Kees. Pommier, Rex R. rex.pomm...@cnasurety.com wrote in message news:3ebf9c9d119fd847b3a096c515a018f69486c...@surfsdvmp35.cnasurety.net ... Hi List, I'm sure this has been discussed but I can't find it in the archives (probably due to my inability to narrow the search down). What would be the reason(s) for starting long-running tasks like CICS as a started task or a batch job? My foggy brain seems to remember there being issues with running multi-step started tasks, and something about there not being as much data gathered (performance, diagnostics, that kind of stuff) for a started task versus a batch job. Any pointers to limitations or other info one way or the other would be appreciated. Thanks. Rex The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: reasons for using started task or batch job
Berry: We had an STC that processed sysouts (some off the wall product that may not be around now). If we didn't suppress the type 30's (I think its been a while). Whenever we would bring it down it would literally cause the SMF address space to run at 100 per cent cpu for hours writing out type 30's records. It took me weeks to figure it out. Even trying to take a dump of SMF address space was fun. I took a SALONE and did some hunting and looking around and found type 30's were the culprit. We needed them for accounting. Trying to dump (IFSMFDMP) the smf datasets was hopeless when this was happening. We had to schedule extra OT for the operators and they weren't happy. Ed Our operators hated being there as they couldn't leave until the system came down On Aug 14, 2012, at 11:39 AM, Barry Merrill wrote: Except for the existence of SMF 30 EXCP segments based on SMFPRMxx options, (i.e., whether they exist in the Step term and Job term records, where they cause problems for long running STCs, causing virtual storage exhaustion, or whether they are only in the Interval records, so they are still counted, and which is recommended for long running STCs), I'm not aware of any other differences in the SMF data created for a batch job versus a started task. Can someone educate me if there are other differences in data? I have a very old note that says that running a task as a Started Task rather than as a JOB bypasses some validity checking, but that if all of the STEPLIB datasets are Authorized, that same validity checking is bypassed for a JOB. But I have no more details nor any proof, now. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: reasons for using started task or batch job
The problem you describe was found by Dianne Eppestein at Southwestern Bell in 1987 in 19xx and Bill Richardson at IBM SMF created the DDCONS=NO option that eliminated the CPU time when there were tens of thousands of DD segments at step termination. But the same problem would impact any long-running asid, batch job or started task, that created many DD segments. From MXG Newsletters: In 1987, Diane Eppestine at Southwestern Bell saw that whenever their SAR job (a SYSOUT processing subsystem) was cancelled, the CPU went to 100% busy for 30-60 minutes. Instruction traces found the loop was in DD Consolidation. SAR dynamically allocates a DD for each SYSOUT file it processes; by the end of the week that step had over 75,000 DD entries! DD consolidation reads the first DD segment, scans the remaining 74,999 segments for a match, reads the second and scans the remaining 74,998 for a match, etc. etc., etc., all at DPRTY=FE! In response to Diane's discovery, Bill Richardson, IBM SMF Development, subsequently provided a new SMF option, DDCONS(NO), specified in SYS1.PARMLIB(SMFPRMxx), so that you can disable this very unwise (in my opinion) algorithm, and thereby eliminate its wasted CPITCBTM and CPISRBTM CPU time. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Tuesday, August 14, 2012 7:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: reasons for using started task or batch job Berry: We had an STC that processed sysouts (some off the wall product that may not be around now). If we didn't suppress the type 30's (I think its been a while). Whenever we would bring it down it would literally cause the SMF address space to run at 100 per cent cpu for hours writing out type 30's records. It took me weeks to figure it out. Even trying to take a dump of SMF address space was fun. I took a SALONE and did some hunting and looking around and found type 30's were the culprit. We needed them for accounting. Trying to dump (IFSMFDMP) the smf datasets was hopeless when this was happening. We had to schedule extra OT for the operators and they weren't happy. Ed Our operators hated being there as they couldn't leave until the system came down On Aug 14, 2012, at 11:39 AM, Barry Merrill wrote: Except for the existence of SMF 30 EXCP segments based on SMFPRMxx options, (i.e., whether they exist in the Step term and Job term records, where they cause problems for long running STCs, causing virtual storage exhaustion, or whether they are only in the Interval records, so they are still counted, and which is recommended for long running STCs), I'm not aware of any other differences in the SMF data created for a batch job versus a started task. Can someone educate me if there are other differences in data? I have a very old note that says that running a task as a Started Task rather than as a JOB bypasses some validity checking, but that if all of the STEPLIB datasets are Authorized, that same validity checking is bypassed for a JOB. But I have no more details nor any proof, now. Barry Merrill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: reasons for using started task or batch job
Besides the reasons for STC or job from the past, there is one important difference from the 'modern' area: STCs can fully use system symbols while jobs cannot (or hardly). Kees. Pommier, Rex R. rex.pomm...@cnasurety.com wrote in message news:3ebf9c9d119fd847b3a096c515a018f69486c...@surfsdvmp35.cnasurety.net ... Hi List, I'm sure this has been discussed but I can't find it in the archives (probably due to my inability to narrow the search down). What would be the reason(s) for starting long-running tasks like CICS as a started task or a batch job? My foggy brain seems to remember there being issues with running multi-step started tasks, and something about there not being as much data gathered (performance, diagnostics, that kind of stuff) for a started task versus a batch job. Any pointers to limitations or other info one way or the other would be appreciated. Thanks. Rex The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: reasons for using started task or batch job
In 3ebf9c9d119fd847b3a096c515a018f69486c...@surfsdvmp35.cnasurety.net, on 08/10/2012 at 03:50 PM, Pommier, Rex R. rex.pomm...@cnasurety.com said: What would be the reason(s) for starting long-running tasks like CICS as a started task or a batch job? START doesn't tie up an initiator, and there's one less jobstep task in the address space. My foggy brain seems to remember there being issues with running multi-step started tasks, If you require an entry in the PPT, the same restrictions apply for a started task and a batch job. and something about there not being as much data gathered There used to be an SMF restriction, but these days it's under parmlib control. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: reasons for using started task or batch job
John Regarding your paranoia - pay-back time for false accusations of ranting! - over the PPT: Some STCs must still be single step, such as ... anything running a program in the PPT. The best policy here would be actually to read up on what is said about multiple/single steps in the description of the attributes of a PPT entry as covered by the description of the PPT statement of the SCHEDxx member in the z/OS MVS Initialization and Tuning Reference manual: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E2C1/76.6 Out of infinite kindness, I present the pointers here: quote ... For NODSI, the job must be a one-step job. If the job is not a one-step job, NODSI is nullified and the system issues message IEF188I. All other properties remain in effect. ... For SYST, the program must be a one-step job started by a START or MOUNT command. If these conditions are not met, SYST is nullified and the system issues message IEF188I. All other properties remain in effect. If procedures are multistep or if NOSYST is specified, TIME=1440 may be required to prevent timeout. ... /quote As I have mentioned on a few occasions in IBM-MAIN in posts which have clearly been ignored, long ago in the days when I education/test systems, I encountered the irritating multiple step restriction caused by the SYST attribute. With the aid of the PPT statement of the SCHEDxx member of SYS1.PARMLIB, I simply denuded the infected program name of the SYST attribute and was happily able to run VTAM (ISTINM01), NetView(DSIMNT or BNJLINTX) and the address space corresponding to the IP component of Communications Server - TCP/IP for MVS at the time - (EZBTCPIP) as multiple steps without issue. (What a shame they are childless!) One - perhaps the only one - of my objectives was to enable the introduction of an IEFBR14 step at the beginning of the procedure in order to ensure[1] that trace and dump data sets from any previous executions of the procedures were deleted - by the use of DISP=(MOD,DELETE). I was then able to allocate them as DISP=NEW data sets with minimal primary space allocation - keeping the limited DASD space at the disposal of my multiple systems all neat and tidy. I appreciate that the considerations relating to my education/test environment do not apply to a production environment but, if the design of an application would suit multiple steps in the procedure, being put off because the PPT table CSECT, IEFSDPPT (module IEFSD060), entry for the program name happens to have the SYST attribute set should *not* be an inhibitor.[2] There is one consideration when SYST is removed which is that the EXEC statement associated with the previously infected program will now need TIME=1440 - or the equivalent. Perhaps some shops ran a process as a job just in order to run multiple steps which were procs. It is certain that actually reading the manual would have been more productive in the long run - but there's no accounting for folk! In the past, an STC had to be a single PROC. How far into the past would that be? I used to play fast and loose with the SYST attribute from around the late 1980s IMMSMC. - [1] I've just read a post where the word insure was used when it was ensure that made sense of what appeared to be being said. Is this yet another case of folk between the shining seas evolving the originally English language? From Googling: - ensure: Make certain that (something) shall occur or be the case. - insure: Provide insurance coverage [2] I did ask about whether there might be some disadvantages undocumented in the description of the SYST attribute in the z/OS MVS Initialization and Tuning Reference manual in IBM-MAIN some time ago. There were a few replies but no evidence of hidden dangers was forthcoming. Archive reference (Search on Subject Contains: SYST, Author's Address: Mason): Subject: SYST From: Chris Mason Date: Sat, 25 Feb 2006 16:58:39 +0100 Hm! Having made sure that I could refer folk to my SYST thread, I couldn't resist reminding myself of the responses. It turns out that some character going by the name of John McKown responded. Now, who would that be, I wonder? - Chris Mason On Fri, 10 Aug 2012 11:05:28 -0500, McKown, John john.mck...@healthmarkets.com wrote: What you have said was true in the past, about jobs having more data in SMF than STCs sometimes did. Some STCs must still be single step, such as an external writer or anything running a program in the PPT. This is not true of CICS. We run multi-step CICS regions as started jobs (not tasks) as our standard. Perhaps some shops ran a process as a job just in order to run multiple steps which were procs. In the past, an STC had to be a single PROC. Also, with STC (started procs), all the STCs ran with the same, generated, pseudo-JOB card. Some shops wanted to run with different job accounting parameters, for billing purposed. They either had to do some
Re: reasons for using started task or batch job
What you have said was true in the past, about jobs having more data in SMF than STCs sometimes did. Some STCs must still be single step, such as an external writer or anything running a program in the PPT. This is not true of CICS. We run multi-step CICS regions as started jobs (not tasks) as our standard. Perhaps some shops ran a process as a job just in order to run multiple steps which were procs. In the past, an STC had to be a single PROC. Also, with STC (started procs), all the STCs ran with the same, generated, pseudo-JOB card. Some shops wanted to run with different job accounting parameters, for billing purposed. They either had to do some fancy exit programming, or ran as a batch job. But with started jobs, you can now run an STC as a started job (complete with JOB card with all parameters except CLASS=) with multiple EXEC PROC= steps. Also, you can now nest PROCs and so have an STC be a PROC, but that that PROC can run the other PROCs required in order. We run CICS as a started job. I changed to this on the first release of z/OS in which it was available. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex R. Sent: Friday, August 10, 2012 10:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: reasons for using started task or batch job Hi List, I'm sure this has been discussed but I can't find it in the archives (probably due to my inability to narrow the search down). What would be the reason(s) for starting long-running tasks like CICS as a started task or a batch job? My foggy brain seems to remember there being issues with running multi-step started tasks, and something about there not being as much data gathered (performance, diagnostics, that kind of stuff) for a started task versus a batch job. Any pointers to limitations or other info one way or the other would be appreciated. Thanks. Rex The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
