|
View previous topic :: View next topic
|
| Author |
Message |
razesh84
New User
Joined: 05 Apr 2010
Posts: 41
Location: Kolkata,India
|
|
|
|
can anyone please tell me which of the following actually happens.
1> My job has a Cobol-DB2 program.when the job is submitted mvs allocates a space to run it & loads the module in that address-space.when the module encounters first sql the control goes to another address space, where db2 is running.after that it again returns to previous address-space & continues like above.So, my cobol executed in one space & db2 in other.
2> if my job has a db2 then the memory is allocated to the address space where db2 is on(thru CAF).so in this case cobol & sql executed in the same space.if it doesnt have db2 then memory is allocated in a space where db2 is not on.
i'm not 100% sure but my vote goes to option 2.
can anyone please explicate this? |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| When a batch job is submitted, an address space is created and that job runs in that address space. There may be external links to other address spaces (such as DB2 or OMVS) but each batch job runs in its own address space. Someone else would have to supply the details of the interaction between the job's address space and DB2's address space since I don't have DB2 here, but if you submit a job it is running in its own address space. |
|
| Back to top |
|
|
razesh84
New User
Joined: 05 Apr 2010
Posts: 41
Location: Kolkata,India
|
|
|
|
thanks Robert for the reply
so in case of non db2 program there will be no interaction with other address space.when a user logged into the system a batch job gets triggered & it runs in its own AS.if the same user submits a job[non db2,ims]then will that submitted a job gets a new address space or share the address space with the TSO job.
for the db2 part lets wait for some other answers. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| so in case of non db2 program there will be no interaction with other address space |
Maybe, maybe not. . . This depends on what all the process "does".
| Quote: |
| when a user logged into the system a batch job gets triggered & it runs in its own AS. |
When a user logs into a system, all that typically happens is that the user is logged in. This does not mean that some batch job is triggered automatically. . .
| Quote: |
| if the same user submits a job[non db2,ims]then will that submitted a job gets a new address space or share the address space with the TSO job |
If a user submits a job, it will run in a batch address space. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Each TSO user gets its own address space. Each started task gets its own address space. Each submitted job gets its own address space. Do you detect a trend here?
One of the few exceptions can be Unix forked or spawned tasks, which may run in the parent address space or in a separate address space -- depending upon the site settings and the parameters used in the command.
Perhaps the most important question -- why do you care? Systems programmers need to be aware of this to adjust the system parameters to allow for enough address spaces, but applications people in general do not know how the system handles their programs (nor should they care, as long as the work is getting done). Especially since DB2 work is eligible to run on a specialized processor (aka zIIP), if one is installed at the site. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
| Back to top |
|
|
|
|
