MVSFORUMS.com

[ds390]

I never worked in an MVS shop before, so I got this question about the common practice of implementing JCL.

In an application system, who is the biggest contributer of the JCL jobs in the system? (End User/System Operator/ Job Scheduler?), and what language environment are they envoked from (REXX, CICS?)?

Thanks for your help.

[semigeezer]

Interesting question -- I'd like to hear people's answers. I've been doing MVS for 25 years but never worked on what would be considered an application system. I've only worked on development systems. I'd suspect that schedulers would control the applications and some maintenance operations like backups, but that end users would still submit more jobs to do various install, maintenance and resource management tasks. Of course, it would vary by shop, but what are people's experiences?

[warp5]

In our shop almost all jobs are submitted from the scheduler, the operating does sometimes submit temp jobs and jobs that are not normally in the scheduler, but they are still submitted from the scheduler (and thus they are documented and the output can be reviewed). There are some exceptions, but almost the only ones who can submit jobs besides the operators are the system programmers.

[kolusu]

ds390,

our environment is pretty much similar to what warp5 has mentioned.

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu

[Bill Dennis]

Ours is probably 70/30, job scheduler vs. users on TSO/ISPF. While the scheduler handles the main production workload, there are still many jobs submitted by users.
_________________
Regards,
Bill Dennis

Disclaimer: My comments on this foorum are my own and do not represent the opinions or suggestions of any other person or business entity.

[Mervyn]

I wouldn't like to say what the proportion might be in our shop, but the vast majority of jobs would be production work, handled by the scheduler (OPC). There are, however, many jobs submitted by developers/testers/database users and so on.

Our system operators do not submit jobs manually; I'm not sure they even know how to. We have a large number of support staff, looking after storage allocation, security, general maintenance. It's a busy environment.
_________________
The day you stop learning the dinosaur becomes extinct

[warp5]

The question was for an application system. We have our development, testing and production all on one machine. Naturally, the developers and testers do submit jobs to the system, they run in a separate environment, job classes, initiators, etc. If they want anything run in the production environment it must be submitted to the operators and they run it under the schedulers control. So we do have a seperation of the environments, even if run on the same machine.

[hareshh]

Hi ds390,

In our Shop and past project with different shop we have seperate Dev & Prod environment as stated above by warp5.

Regards,
Haresh.

[vak255]

I believe, if the shedulers are used then the number of jobs trigerred will be very large.
In some shops, shedulers not used so may be the internal triggers do that job.
my vote is for shedulers.

[Cogito-Ergo-Sum]

What about the jobs that are triggerred from CICS ? Maybe, even Web ? My point is, not all jobs maybe under complete control of a job scheduler (Control-M, OPC, et al). Of course, for some, it might be a dangerous exception. But, in one particular application I worked, submitting a job to send FAX to a customer was done via CICS program. It was the rule there; not an exception.
_________________
ALL opinions are welcome.

Debugging tip:
When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
-- Sherlock Holmes.

[semigeezer]

Pardon me for resurrecting an old topic, but it got me thinking about a common design problem I see almost every day and I'd like to ask other questions about it. So... a couple of observations and then the questions.

Observation 1: It seems that most people are seeing significant numbers of jobs submitted by either systems people or schedulers, so I'm assuming that the previous discussions are about production machines more than development or test machines.

Observation 2: There is a large number of programmers that think that it is a reasonable design to have an online program (CICS, TSO, connected Workstation, web application, etc) submit a job and wait for the output. This is, of course, poor design because the job may never run because of contention for data sets or initiators, but it is becoming more common.

My interest is in development and test systems partly because that is where I work, and because I assume that production systems are more accurately tuned to the needs of the shop so that even if they are running one of these Frankenstein programs the support staff will do whatever is necessary to make sure the jobs can run.

So the questions: On your development systems:

1. Do you ever still see jobs waiting due to lack of initiators?
   
2. How many initiators are available to developers (class A or other classes designated for developer use)
   
3. Does your shop designate job classes to specific purposes or do most jobs just go in with CLASS=A?

I only ask these questions for curiosity, but I seem to be having this discussion with people several times a week now.

[dbzTHEdinosauer]

Semigeezer,

Since the amount of money the firm is going to spend on hardware defines how much development machine I am going to have to play with:

I only work for large banks,
(those which can afford enough iron to run multiple MVS's)
so that , unless major hardware problems on production machines require reallocation of hardware from the development side,
i never wait!.

designation and use of job classes depends upon the sophistication of the shop.
_________________
Dick Brenholtz
American living in Varel, Germany