MVSFORUMS.com :: View topic - Multiple instances of same program execution

Multiple instances of same program execution

through

[^/[Print]\]

MVSFORUMS.com -> Application Programming

#1: Multiple instances of same program execution Author: LaluMon,

Posted: Sun May 25, 2003 11:36 pm
—
Hello,

This may be a stupid question, but I am confused.

I have a COBOL program which internally builds a working storage two dimensional array of table data and at the end of execution, writes relevant data from this table to an output DASD dataset.

Okay, I have six instances of this program running at the same time. The program has one input dataset and one output dataset, and all the input datasets are different for the six instances of the program execution.

My confusion, was since each instance of execution will be creating/building its own internal temporary table data, should I be concerned about the multiple instances running at the same time? I was thinking I need not worry about this and the 6 output datasets will reflect the correct data only. But I am not sure of this. My program attributes are RENT, RES.

I just want to make sure of my understanding through this forum. Also, if this turns out to be I definitely need not worry, can you please point out also from MVS internals perspective, why there is no need for concern.

Regards!

#2: Author: warp5, Location: Germany

Posted: Mon May 26, 2003 1:03 am
—
First, I assume there is a batch job (and not CICS) running your program. Looking at a job, you will find that each job runs in its own address space, so there can be no interplay between the jobs. Besides, if you used the same sequential output dataset name only one job could run at a time.

#3: Author: slade, Location: Edison, NJ USA

Posted: Mon May 26, 2003 1:15 am
—
Hi Mon,

It may depend on what you mean by an "instance of execution". Is each "instance" a CALL, LINK, or ATTACH? Is it 6 jobs executed concurrently?

In any event, the tables are probably insulated. If they're running as separate JOBS, Warp5 is right on. If they're concurrently invoked from a common program in one execution, each subpgm ("instance") will use it's own unique base address for the table.

BTW, what's the status of your previous problem? I posted a suggestion, but didn't get a reply. Wazzup?

Regards, Jack.

#4: Author: LaluMon,

Posted: Mon May 26, 2003 8:56 am
—
Slade and Warp, Thanks for confirming on this.

Yes, it is a Batch job. And each instance is a ATTACH instruction. Also, yes it is 6 jobs running concurrently and separately.

Slade, didnot mean to ignore the other post. Please see that I have responded now and will update that thread again later.

Regards
Lalu!

#5: Author: slade, Location: Edison, NJ USA

Posted: Mon May 26, 2003 8:54 pm
—
Hi Mon,

I hope I've got this straight. You have six concurrent jobs executing the same subpgm via an ATTACH macro. This common subpgm was compiled and linked with the RES/RENT attributes.

You've got a lot going on, but I think the RENT and ATTACH are the most relevant. As I recall (it's been awhile since my sysprog days) invoking the subpgm via ATTACH creates a unique TCB for each invocation of the subpgm. The RENT attribute creates code to "GETMAIN" the WS for each subpgm TCB. One of these WS are used by each TCB to execute its own version of the subpgm. I'm not sure if a seperate WS is created for each subpgm TCB or only the changed data is maintained for each TCB.

In any case, it's irrelevant to your situation because, in either case, each version of the subpgm has acquired and maintained its own table.

Regards, Jack.

#6: Author: LaluMon,

Posted: Mon May 26, 2003 10:49 pm
—
Thanks Slade! It really helped my understanding of the concept !

Regards, LaluMon!

MVSFORUMS.com -> Application Programming

output generated using printer-friendly topic mod. All times are GMT - 5 Hours

Page 1 of 1