Cobol - Retiring a job from CA-7.

Author

Retiring a job from CA-7.

arrbee

2006-04-27, 3:55 am

Hi,

Can any of you please explain me what are all the things one must
consider or practice to retire a job from CA-7 job scheduler? What care
should be taken?

Forgive me if this topic is not covered in this forum.

Thanks for your time.

2006-04-27, 3:55 am

In article <1146124655.874355.49980@g10g2000cwb.googlegroups.com>,
arrbee <arrbee@gmail.com> wrote:
>Hi,
>
>Can any of you please explain me what are all the things one must
>consider or practice to retire a job from CA-7 job scheduler? What care
>should be taken?

Care should be taken to hire someone with the skills requisite for doing
this sort of work.

DD

arrbee

2006-04-27, 3:55 am

Wow....that is great. Thanks.

2006-04-27, 7:55 am

In article <1146128442.345806.322610@g10g2000cwb.googlegroups.com>,
arrbee <arrbee@gmail.com> wrote:
>Wow....that is great. Thanks.

Any time... it's worth at least double what you've been asked to pay for
it, too!

DD

Arnold Trembley

2006-04-28, 3:55 am

arrbee wrote:
> Hi,
>
> Can any of you please explain me what are all the things one must
> consider or practice to retire a job from CA-7 job scheduler? What care
> should be taken?
>
> Forgive me if this topic is not covered in this forum.
>
> Thanks for your time.

I assume you mean changing job schedules so that a particular job is
no longer executed. While this is not a COBOL issue, many COBOL
programmers must deal with job schedules that run their batch COBOL
program. We used to have CA-7 and now have TWS/OPC. Seems to me in
TWS we can mark a job "NOEX", which means it remains in the schedule
as if it were still being executed, but it is not executed.

This is something I have frequently done, although I have to ask the
operations staff to make the actual schedule changes, since I don't
have authority to update job schedules.

You need to determine what jobs are triggered by the job you are
removing. If you intend to remove job A, but Job A's successful
completion triggers job B to run, you must arrange some other trigger
to get Job B to run.

The more difficult problem is to determine if any output files created
by Job A are used elsewhere. For this I generally run ISRSUPC scans
or Endevor scans against prod proclibs and jcllibs. But a huge
complication is that sometimes JCL symbolics can obsure the true
dataset name. You need to make sure that no other jobs need any of
the output files produced by Job A.

Then I just tell operations, "please remove Job A from all schedules
where it is currently executed". Depending on your shop standards,
there may be bureaucratic paperwork to fill out.

You should always have a backout plan, so if any problems occur you
can restore Job A to the scheduler and also make up any missed work.

I hope that helps.

--
http://arnold.trembley.home.att.net/

arrbee

2006-04-28, 3:55 am

Thanks for the details Arnold.

Hugh Candlin

2006-04-28, 3:55 am

"arrbee" <arrbee@gmail.com> wrote in message
news:1146124655.874355.49980@g10g2000cwb.googlegroups.com...
> Hi,
>
> Can any of you please explain me what are all the things one must
> consider or practice to retire a job from CA-7 job scheduler? What care
> should be taken?
>
Whatever you come up with, it probably will not be enough.
This is a process where you really cannot ask too many questions,
yet you probably won't ask enough, no matter how good you are.

Trust me.

The major steps seem to be fairly straightforward at first.

1 Identify jobs that this job is dependent upon.
2 Identify jobs that are dependent upon this job.
3 Identify flat files that are created by this job,
and determine if, and if so where, they need
to be created/catalogued in the future.
4 Identify flat files that are updated by this job,
and determine if, and if so where, they need
to be updated in the future.
5 Identify flat files that are deleted by this job,
and determine if, and if so where, they need
to be deleted/uncatalogued in the future.
6 Identify databases that are updated by this job,
and determine if, and if so where, they need
to be updated in the future.
7 Identify the reports produced, obtain their
distribution lists, and get the users to either
sign off on their discontinuation,
or affirm their continued need, in which case
you need to relocate that process to another job.

That's the easy parts. [I'm probably still a little
shell-shocked from the last time I shoehorned
on one of these projects, so I probably left
out an essential cog or three, but, never fear,
you should discover them during integration testing.]

Now you need to look at ALL of the jobs
that are dependent on this job completing,
and determine where you will relocate
essential file processing and database updates,
based on everything that you have learned
during your analysis.

Then [shudder], based upon the job restructuring
and reorganization that you have determined to be necessary,
you need to determine the new dependencies,
..
If there is one step in this process that will trip you up,
that is it.

Trust me.

Care should also be taken to communicate
your intention to all of the IT staff, secure
in the knowledge that someone is almost certain
to know of a fact that will become a showstopper
if you overlook it. Dare I say "when" instead?

Care should also be taken to communicate the proposed change
to the user community, as there may be surprising uses being made
of the outputs from that job that are not widely known within IT,
if at all. Do not forget to check with Audit and Legal.

Did I mention, do NOT forget to check with Audit and Legal.

Trust me.

You will of course work VERY closely with
the Master Scheduler at all times during this process.

He or she MAY get a little testy with you at the disruption
that you are introducing when you do, but that will pale
in comparison if you do NOT work very closely
with the Master Scheduler during this process.

Master Schedulers do not like surprises,
particularly ones which come with deadlines attached.

Trust me.

Clark Morris

2006-04-28, 6:55 pm

On Fri, 28 Apr 2006 04:31:01 GMT, Arnold Trembley
<arnold.trembley@worldnet.att.net> wrote:

>
>
>arrbee wrote:
>
>I assume you mean changing job schedules so that a particular job is
>no longer executed. While this is not a COBOL issue, many COBOL
>programmers must deal with job schedules that run their batch COBOL
>program. We used to have CA-7 and now have TWS/OPC. Seems to me in
>TWS we can mark a job "NOEX", which means it remains in the schedule
>as if it were still being executed, but it is not executed.
>
>This is something I have frequently done, although I have to ask the
>operations staff to make the actual schedule changes, since I don't
>have authority to update job schedules.
>
>You need to determine what jobs are triggered by the job you are
>removing. If you intend to remove job A, but Job A's successful
>completion triggers job B to run, you must arrange some other trigger
>to get Job B to run.
>
>The more difficult problem is to determine if any output files created
>by Job A are used elsewhere. For this I generally run ISRSUPC scans
>or Endevor scans against prod proclibs and jcllibs. But a huge
>complication is that sometimes JCL symbolics can obsure the true
>dataset name. You need to make sure that no other jobs need any of
>the output files produced by Job A.

In the IBM MVS / OS390 / z/OS world, I would check the appropriate SMF
(Systems management facility) records to see what permanent files the
job creates or modifies and the database records to see if it does any
updating of any database. I would then check all jobs that use these
files and databases. I understand the Unix environments may not have
equivalent logging. I don't know what logging is done by the Unisys
environments.

As a side question are there any mainframe vendors left beside IBM and
Unisys. Bull inherited the Honeywell and GE side of the fence but I
haven't heard anything about them.
>
>Then I just tell operations, "please remove Job A from all schedules
>where it is currently executed". Depending on your shop standards,
>there may be bureaucratic paperwork to fill out.
>
>You should always have a backout plan, so if any problems occur you
>can restore Job A to the scheduler and also make up any missed work.
>
>I hope that helps.

Sponsored Links