Tools to eliminate JCL

sakthisiga · New User Joined: 11 Jun 2009 Posts: 60 Location: Chennai

Hi everyone,

Can anyone please tell me the tools that eliminate the JCL and used to post the jobs directly into MVS.

enrico-sorichetti · Posted: Mon Jul 13, 2009 3:25 pm

<HOLY> <DEITY> where did You get such idea

Anuj Dhawan · Posted: Mon Jul 13, 2009 5:28 pm

dick scherrer · Posted: Tue Jul 14, 2009 12:24 am

Hello,

expat · Posted: Tue Jul 14, 2009 12:49 am

Please explain the possibility of how the operating system will execute a batch job without JCL.

WOW, I echo Enrico's astoundment. Or was a colleague playing a joke on you ???

mtaylor · Posted: Tue Jul 14, 2009 8:54 am

Isn't there a TSO 'run' command that will execute a load module? That could conceivably qualify for what the op is asking if it exists.... Although 'job' indicates there's more than one program involved.

From some online tso tutorial. I've never used these maybe someone else has:

call load and execute the specified load module.
loadgo load and execute program.
run compile, load, and execute program.

expat · Posted: Tue Jul 14, 2009 2:01 pm

Yes, that may be one way to answer the OP, but it does rather limit any other use of the terminal session.

dick scherrer · Posted: Tue Jul 14, 2009 7:56 pm

Hello,

If Sakthivel were to present better info about some specifics rather than only mentioning a general desire to "eliminate the JCL", someone might be able to provide a more usable reply. . .

Marso · Posted: Tue Jul 14, 2009 8:23 pm

With REXX you can execute programs without using jcls, that could be what Sakthivel means.
or it could be REXX again, where the jcl is "hidden" as a skeleton and a job can be submitted without you seeing a single line of jcl.

More info definitely needed...

sakthisiga · New User Joined: 11 Jun 2009 Posts: 60 Location: Chennai

Thank you all for your kindly reply..

Anuj Dhawan · Posted: Mon Jul 20, 2009 5:26 pm

You're welcome. But what's the final choice you "pick" from here?

Alex Bruzzone · New User Joined: 18 Aug 2010 Posts: 4 Location: Ottawa

I work for a large Canadian Government Agency and I have implemented JCL generators for the maintenance of DB2 and IDMS databases.

There is always the choice for an organization to purchase a tool that will "hide" the real processes (JCL) behind some fancy window full of buttons you can click on.

Instead, I develop generators of JCL, that way database administrators can look at and review the JCL. When the generator is put to work nothing really changes other than the elimination of the tediousness of the repetitive work.

For instance, my JCL generator for IDMS reads the PUNCHed Segment definitions and DB table to create the JCL. That way nothing is ever missed. A few years back we had a big crash with our IDMS databases. At the time all the JCL was being done by hand. Errors were made in the JCL and of course that delayed the recovery which took 9 days. Now JCL for any IDMS maintenance can be done in seconds.

For DB2 I have implemented a JCL generator for moving data from one database to another using DSN1COPY. Anyone who has used DSN1COPY would know how tedious it is to build this JCL. Special DBIDs and OBIDs need to be collected and placed in the JCL. The problem is that if the numbers are wrong, you don't discover it until you try to access the data in the target DB.

For all the JCL (and COBOL) generators I use a tool that I also developed which uses sparse dynamic arrays to pass the data to populate skeletons. It works very well and I have successfully used it for all my projects. It's all done using COBOL.

There is merit in developing in-house tools. Usually tools that are purchased require a change in the way the organization operates.
In-house tools can be made very easy to use.

The following JCL creates all the DSN1COPY JCL for a MSTR DB2 database which will move the data from Production to its testing environment using a backup (COPY) from September 19, 2010:

mtaylor · Posted: Sun Oct 03, 2010 8:53 pm

JOL was intended to be a JCL replacement, it never gained wide spread adoption. The developer made a new release some time ago:

newsgroups.derkeiler.com/Archive/Comp/bit.listserv.ibm-main/2010-03/msg01010.html

I think the chances of any organization with non trivial, 40+ year old mainframe applications migrating off of JCL are essentially zero. JCL is ugly and difficult for beginners, but it's well understood and entrenched. Really it's pretty good at what it does.

Pete Wilson · Posted: Tue Oct 12, 2010 7:33 pm

VSAM was supposed to replace JCl and we all know how far that got.

Anuj Dhawan · Posted: Tue Oct 12, 2010 7:58 pm

Okay, pardon my ignorance and my little experience - but I read the similar statement on other board too. I'm confused, how VSAM could replace JCL - one is access method and other is "control language"!

Sys Edwin · New User Joined: 18 Oct 2010 Posts: 7 Location: Canada