Kees: Your points are well worth considering. As I had mentioned in a previous comment to this string, there are products available that make it possible to do all that you require outside of (independent of) any particular scheduling environment, and they are well suited to interface seamlessly with a variety of ISV tools that are part of this environment.
Regards, Mitch -----Original Message----- From: Vernooij, CP - SPLXM <kees.verno...@klm.com> To: IBM-MAIN <IBM-MAIN@LISTSERV.UA.EDU> Sent: Mon, Oct 7, 2013 11:18 pm Subject: Re: JCL Symbol Resolution Did you consider well the pro's and con's of widely using the Contol-M features? his will tie you rigidly to this product and will cost you a lot of work if you ecide to convert to another scheduler in the future. Having learned from yncsort and PDSMAN whose features were not compatible with the corresponding BM products, we only use a few of the % features of Control-M and only in a ery controlled group of jobs. This also answers your question partly. Kees. -----Original Message----- rom: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf f Roberts, John J ent: Monday, October 07, 2013 22:03 o: IBM-MAIN@LISTSERV.UA.EDU ubject: JCL Symbol Resolution We are about to become a new BMC Control-M installation. Part of this involves hanging our JCL to reference Control-M symbols. So instead of a plain-jane JOB ard, we might have something where the accounting field is supplied as %%ACCT nd the JOB CLASS is specified as %%JC. This is all good in PROD, where these symbols are resolved from job definitions y Control-M before submission. But what about unit testing? For one, I don't want to run unit test jobs from ontrol-M, since our license will count these against our limit. And I don't ant to force our developers to edit the JCL before submission, since (a) it ould be a PITA, and (b) they would surely forget to cancel the edit, corrupting he member. What I really want is the ability for developers to perform a special "SUBMIT" rom their ISPF EDIT session, where: a) the developer is prompted to resolve the symbols before the JCL text is ritten to INTRDR, and/or b) the symbols are resolved from some configuration file before the modified CL is written to INTRDR. I think that some kind of ISPF EDIT MACRO could do this work, but I have orgotten how to do this. I am hoping that this is a common enough problem that omeone else may have developed a solution they could share. Note that I know that there are some things related to Control-M that a simple DIT Macro could not solve. Stuff like the %%IF-%%ELSE-%%ENDIF sequences and he built in functions for date calculations and character substrings. But hese are rare enough that I would be happy with a simple symbol substitution olution. I have asked our sysprogs to pose this question to BMC and CetanCorp. But I uspect that their answer will revolve around their new JCLVERIFY product. If his can work standalone without adding to our license count, that would be reat. Otherwise we will need this other solution. Also, I will need to bring this up with the supplier of our current JCL alidation utility - the product known as JED (dcmsi.com). This has one nice eature that the new JCLVERIFY lacks, the ability to display the contents of arameter members, both PDS and PANVALET. JED is also capable of validating hings like SORT and IDCAMS control statements. John ---------------------------------------------------------------------- or IBM-MAIN subscribe / signoff / archive access instructions, send email to ists...@listserv.ua.edu with the message: INFO IBM-MAIN ******************************************************* or information, services and offers, please visit our web site: ttp://www.klm.com. This e-mail and any attachment may contain confidential and rivileged material intended for the addressee only. If you are not the ddressee, you are notified that no part of the e-mail or any attachment may be isclosed, copied or distributed, and that any other action related to this -mail or attachment is strictly prohibited, and may be unlawful. If you have eceived this e-mail by error, please notify the sender immediately by return -mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its mployees shall not be liable for the incorrect or incomplete transmission of his e-mail or any attachments, nor responsible for any delay in receipt. oninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch irlines) is registered in Amstelveen, The Netherlands, with registered number 3014286 ******************************************************* --------------------------------------------------------------------- or IBM-MAIN subscribe / signoff / archive access instructions, end 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
