|
View previous topic :: View next topic
|
| Author |
Message |
sakthikumarT
New User
Joined: 09 Apr 2009
Posts: 50
Location: Bangalore
|
|
|
|
Hello everyone,
If we did any changes to the cics-cobol application program,once again,we have to install the program in the CICS region,otherwise latest
Update won't be reflect in the application program.
My question is
1) once we did changes in the application program,(after
translator and compile and linkedit is done). the load module has
been overridded. now in the cics region why we need to install it once again,Anyways its going to refer the same load module ??
(Which ia already overridded with new changes)
now my second question is
2) Where CICS will store these old load module information??
if it stores in its CICS address space, Then wastage of memory ???
for ex if i have 100 programs then all these programs information will be temporarly stored in CICS address space. it won't afftect CICS performance.?? |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
1. CICS is efficient. The first time a program is invoked, CICS goes out to the library on disk, finds the module, and loads it into memory. Every reference to the program after the first uses the copy that CICS has in memory. Changing the disk load module by doing the recompile and linkage edit (bind) can be done as much as you want. However, CICS will not be aware of the changed load module until you do a NEWCOPY on the program. The NEWCOPY tells CICS to go out to disk and fetch in a new version of the program.
2. CICS only has active load modules in memory. If you have 100 programs defined to CICS, but your system has only used 6 of them since CICS came up, then only those 6 are loaded in CICS memory. They are stored in the CICS region as part of the CICS memory area -- which is entirely separate from the user memory area your programs use.
Only IBM could tell us the impact in CICS performance -- and I suspect the impact is quite small. CICS has been running a long, long time and has had many updates over the years. IBM has probably paid much attention to making the CICS system overhead as small as possible. You are needlessly worrying about something you cannot control and cannot change. |
|
| Back to top |
|
|
cicsknow
New User
Joined: 11 Mar 2009
Posts: 28
Location: India
|
|
|
|
Thanks Robert for this information to other user.
sakthikumarT,
CICS maintaining a record of which program load in CICS memory and they point to its address space (not a load module)........
so if you change a load module it will not update in CICS record about it address....so every time you need to do a newcopy....of that last program copy.... |
|
| Back to top |
|
|
sakthikumarT
New User
Joined: 09 Apr 2009
Posts: 50
Location: Bangalore
|
|
|
|
The NEWCOPY tells CICS to go out to disk and fetch in a new version of the program
You are saying like in DASD For a same program there will be N Number of load module versions,And the cics will fetch the latest version(new version, once we installed the program in cics region) is it.?????
Could you able to tell me on which area these information will be stored?? |
|
| Back to top |
|
|
sakthikumarT
New User
Joined: 09 Apr 2009
Posts: 50
Location: Bangalore
|
|
|
|
| Quote: |
| CICS maintaining a record of which program load in CICS memory and they point to its address space (not a load module)........ |
Huh if this is the case, (fro ex: If i execute some 500 programs then the
reference for 500 programs will be made on cics Address space huh??)
Then when these refereces will be removed????? |
|
| Back to top |
|
|
cicsknow
New User
Joined: 11 Mar 2009
Posts: 28
Location: India
|
|
|
|
sakthikumarT,
I think following step will help you...
1. When reference for a program it load from library to CICS address space..and its address store into CICS system.
2. When program change and compile, so we need to infor about it to CICS system by NEWCOPY so it will take this new copy and load to address space and at that time it will change address of that program in CICS system by which it referring it...
3. It is independent to no. of program changes....
I hope this will help you....   |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
Sakthi kumar T,
How many versions of a particular load module is in a single load module library?
| Quote: |
Could you able to tell me on which area these information will be stored??
|
That is your responsibility. That is why many modern sites have repositories. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
No, there is only one version of a program in a load module at a time. The PDS member directory points to the most recent version. If the PDS is compressed, the space where the replaced members resided is reclaimed and can be used for other load modules.
| Quote: |
| Could you able to tell me on which area these information will be stored?? |
This is not clear -- are you wanting to know which area of CICS memory stores the load module? Are you wanting to know where CICS programs are defined? Are you wanting to know about the PDS member directory?
A point of terminology: address space is a specific term which means a specific thing on IBM mainframes. This meaning is not related to how CICS maintains programs in memory. An address space on z/OS can be assigned to a batch job, started task, CICS region, Unix System Services user (or forked task), TSO user, and so forth. Address spaces have shared memory for common code and private user memory.
Yes, if you execute 500 programs then all 500 will be in CICS memory. They are removed from memory when CICS comes down. However, if you execute the same transaction 500 times that is only one program, not 500 programs. Each program in this context is a unique PPT (processing program table) entry. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
Robert,
Sakthi kumar T reminds me of Mastermind.
I wonder what kind of response Sakthi kumar T will give,
besides grunting, huh? |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| LOL no way to tell, dick, no way to tell. Not sure I want to know, either! |
|
| Back to top |
|
|
MBabu
Active User
Joined: 03 Aug 2008
Posts: 400
Location: Mumbai
|
|
|
|
| The doc for CEMT SET PROGRAM PHASEIN does refer to multiple versions being loaded. It looks like CICS keeps multiple versions of a loaded module (in storage, not on disk!) and allows new access only to the latest one. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| It looks like CICS keeps multiple versions of a loaded module (in storage, not on disk!) and allows new access only to the latest one. |
From the manual, CICS keeps the old version around only as long as RESCOUNT is greater than zero. As soon as the last running transaction ends, and RESCOUNT goes to zero, the old version is deleted and the new version is used from that point forward. So CICS may keep two (not multiple) versions of a program around for a bit but it certainly doesn't mean you can do anything with them as versions -- either your transaction is using the old one (because it was running when the PHASEIN was done) or the new one (because the transaction was keyed in after the PHASEIN was done). |
|
| Back to top |
|
|
sakthikumarT
New User
Joined: 09 Apr 2009
Posts: 50
Location: Bangalore
|
|
|
|
Mr Robert,
| Quote: |
| From the manual, CICS keeps the old version around only as long as RESCOUNT is greater than zero. As soon as the last running transaction ends, and RESCOUNT goes to zero, the old version is deleted and the new version is used from that point forward. |
As you said once TRANSACTION ends RESCOUNT Goes to 0.
So automatically the older version of load module is deleted.
Now assume if i didn't Install the Program in CICS Region,Then how could it execute the program because already the reference for the older version of the load module is deleted??? (Since RECOUNT COUNT IS 0)
This time i neither grunting nor used a word "Huh"..  |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| Now assume if i didn't Install the Program in CICS Region,Then how could it execute the program because already the reference for the older version of the load module is deleted??? (Since RECOUNT COUNT IS 0) |
It sounds like you are chasing your tail. . .
If a new version/copy of the program is not installed, there should be no concern. There would be no "older" module?
Possibly i am missing something. . . |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| Now assume if i didn't Install the Program in CICS Region |
How are you going to do this? In order for the older version of the load module to be deleted, you had to have done either a NEWCOPY or PHASEIN. So you've already installed the program in CICS. You can't un-NEWCOPY a module as far as I know!
I suspect if you managed to get the region to this point, there would be an SVC DUMP and a CICS region going shutting down .... |
|
| Back to top |
|
|
sakthikumarT
New User
Joined: 09 Apr 2009
Posts: 50
Location: Bangalore
|
|
|
|
You are saying like when ever we are installing the program using (CEMT or CEDA INSTALL ) The RESCOUNT Goes to zero. so the reference to older version of load module is deleted and the newer version of the load module is Taken (either from the DFHRPL or dynamic LIBRARY concatenation, or uses an LPA-resident version, depending on the PRIVATE or SHARED options
in the CEMT)
Now my question is
1) where does the older version of LOAD MODULE gets stored..?
( like newer ones gets stored in DFHRPL or LPA........) |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
Now my question is
1) where does the older version of LOAD MODULE gets stored..?
( like newer ones gets stored in DFHRPL or LPA........)
|
I think you're confusing memory and disk space. If there is an older version around (and as I said earlier it will not be for any longer than it takes a transaction to finish), it is in CICS memory -- probably ERDSA but don't quote me on that -- just as the new version is in CICS memory. The old and new versions could have come from DFHRPL or LPA (both of which are disk areas), but once CICS has them they are running in the CICS address space under CICS control in CICS memory; at which point it does not matter where they are on disk. |
|
| Back to top |
|
|
sakthikumarT
New User
Joined: 09 Apr 2009
Posts: 50
Location: Bangalore
|
|
|
|
Yeah you are 100 % percent right They are running in the CICS address space (under CICS control in CICS memory)
as per your prevoius scrap i got the answer for the area where older load module is stored.
last doubt
Whether CICS memory will have the address of the previously executed program(for ex program : pgm1 trans id: trs1)
or the copy of the load module.
what i believe is it hold the copy of the load module for pgm1
If you clarify this,then i will shoot my last question
one more thing i would like to thank everyone whoever replied , bcz you people have spent your precious & valuable time.! also without hesitation
you guys replied.Thanks a lot. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
Whether CICS memory will have the address of the previously executed program(for ex program : pgm1 trans id: trs1)
or the copy of the load module. |
Yes. CICS maintains a pointer to the address of the program as part of the PPT for each program it knows about; the address is either invalid (meaning the program has not been loaded off disk yet) or a memory location. Starting at this memory location will be the load module loaded off disk (whether DFHRPL or LPA). The data loaded into memory is a copy of the disk data. NOTE: the address in memory is not a disk location, has nothing to do with the disk where the load module resides, but is a pointer to a CICS memory location within the CICS address space only.
When you compile and link your code, you are replacing the DFHRPL or LPA module. This has no impact on the copy of the load module that CICS has in memory; only when a NEWCOPY is done or CICS comes down and back up will it go to disk and discover the revised code. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
You're welcome - good luck
d |
|
| Back to top |
|
|
sakthikumarT
New User
Joined: 09 Apr 2009
Posts: 50
Location: Bangalore
|
|
|
|
Yeah i got it Thanks a lot.
Now my last question:
IF i execute pgm1 in CICS region,(it means that a copy of the load module for pgm1 which might be taken from (LPAR or DFHRPL) and it is stored in CICS MEMORY)
so i have pgm1,pgm2,..........pgm999,pgm100000
there will 100000 copies of load module which is available in the CICS Memory.
say if 1 lakhs different programs are running simultaneously. obviously CICS memory gets filled..? it might be a huge probelm right??
at This point of time INternally what kind of things will happen inside the CICS???
|
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
CICS can run short on memory. This is called a short-on-storage condition and in some regions is a daily occurrence (depending on how big the programs are and how many are running and whether they are 24-bit or 31-bit, among other things). CICS handles memory management and recognizes when it goes short-on-storage (and when it stops being SOS) so while I cannot say for sure, never having worked on CICS internal system software, I suspect CICS can handle excessive numbers of transactions and programs. I don't know the exact mechanisms -- you would have to discuss this issue with IBM to find out -- but there have been regions running 10,000 terminals so the capacity to handle large volumes of work is there.
| Quote: |
| at This point of time INternally what kind of things will happen inside the CICS??? icon_confused.gif |
You would have to contact CICS support at IBM to get this answered. Depending upon your support contract, you may or may not be able to get an answer. |
|
| Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA
|
|
|
|
| At one time, many moons ago, when multiple occurrences of the same program were being executed, only 1 copy of the PROCEDURE DIVISION was in memory, and each user had their own copy of WORKING STORAGE and COMMAREA of course. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Unless i missed a memo (which happens more and more often ), re-entrant code still works this way. The use count is incremented and decremented to determine if the module is currently "in use".
d |
|
| Back to top |
|
|
sakthikumarT
New User
Joined: 09 Apr 2009
Posts: 50
Location: Bangalore
|
|
|
|
Thanks Mr Robert.
Could you able give the Link for CICS SUPPORT AT IBM.? |
|
| Back to top |
|
|
|
|
