MVSFORUMS.com

bade_miya · Beginner Joined: 10 Dec 2003 Posts: 110 Topics: 38

Hi all,
I dont know whether i should post this here or in the JCL forum. Anyways here is my doubt. Through REXX you can allocate dd names and can call a cobol program. Unlike as in JCL, it will run instantly. While in case of JCL some time the jobs take more time to get initiated. So is it a good practice to test your cobol programs by calling it through REXX. Is there any disadvantage for this. Why dont we specify initiators while we call cobol programs through REXX. (i mean i havent seen anywhere CLASS parameter in REXX).

Thanks
bade_miya

acevedo · Posted: Tue Oct 18, 2005 3:50 am Post subject:

'So is it a good practice to test your cobol programs by calling it through REXX. Is there any disadvantage for this'
imho, it depends on how long the step last (could be a cobol program, rexx, pl1 or any other utility) it's going to last.
if you do it in batch maybe it will be waiting for initiators but in foreground your terminal will be blocked.

'Why dont we specify initiators while we call cobol programs through REXX.' that's the case when you run your rexx in foreground mode.

hth

bade_miya · Beginner Joined: 10 Dec 2003 Posts: 110 Topics: 38

Hi acevedo,
Even for cobol programs taking less than 1 min, a JCL submitted will go into the queue if there are lots of other jobs submitted at the same time(which need more system resources). But if i call it through a REXX, it will not take any time to get invoked and the time taken by the cobol program will also be same.(i am not 100% sure about the time taken, but that was what i felt in case of small cobol programs. I havent tested it for big programs)

Thanks
bade_miya

Cogito-Ergo-Sum · Posted: Tue Oct 18, 2005 7:39 am Post subject:

Well, if you are running in foreground mode, then your session is locked. That is a disadvantage depending on the runtime of a job.
_________________
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 · Posted: Tue Oct 18, 2005 12:14 pm Post subject:

The other advantage of running it online is that you have some more debugging tools available to you such as TSO TEST or language specific tools. As Avecedo mentioned, the things to consider are 1) Does your TSO id have all the resources and authorities it needs to run the program, 2) IS the program very long running (it will lock your id while it runs) 3) is there anything special about batch that is required to run the job (that is rare), 4) Does your site allow that type of program to be run from TSO?

I mention (4) because you mentioned job classes. Job classes are used to assign certain performance characteristics to your batch jobs. For example, if a job is CPU intensive, you may be asked to run it in a class that will give it smaller timeslices so that other users and jobs can get to the CPU. Or if it is a high priority job, the class may give it higher preference. Running a job under TSO will get you the performance characteristics of a TSO user as defined by your shop. Normally, any TSO interaction (transaction) that takes more than a second or two wil go into very low priority and take a long time. That is because TSO is intended to be used for fast transactions like editing files and allocating data sets. But there is nothing wrong with running longer transactions on a TSO terminal as long as the system is set up to handle it well (and most are).

superk · Advanced Joined: 19 Dec 2002 Posts: 684 Topics: 5

I don't normally write program code, but, on the rare occasion when I do, I do everything in the foreground (compile, link-edit and run). Don't most application programmers do their development work that way?

bade_miya · Beginner Joined: 10 Dec 2003 Posts: 110 Topics: 38

Hi all,

Thank you all for your answers.
Superk, I dont know about others, but in our site we do compile, link-edit and run in background. But if some heavy job is running at the time when i submit a compile job(which will take only 1 min to execute in a normal case), i will be queued up until that heavy duty job is over. Thats why i was looking at the possibility of compiling and running the program in foreground.

The only question remaining is that, suppose when we want to call a cobol program which access DB2 or IMS from a REXX exec. In this case, can we call that cobol program from rexx in foreground mode? Has anyone done that before? If yes, please provide some inputs on how to do it.

thanks
bade_miya.