IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

What is the usage of LOAD command in CICS


IBM Mainframe Forums -> CICS
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
raghav08
Currently Banned

New User


Joined: 03 Jun 2008
Posts: 94
Location: Bangalore

PostPosted: Wed Jul 16, 2008 12:52 pm
Reply with quote

Hi,

What is the usage of LOAD command in CICS? in what circumstance we need to use this. Please expalin in detail.
Back to top
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Wed Jul 16, 2008 1:00 pm
Reply with quote

You can use EXEC CICS LOAD to load a program or user-table module into memory, or to find the address of a module. There is an option to make the module RESIDENT which might be of use if you don't want the PPT entry to specify residence.

Regards,
Garry.
Back to top
View user's profile Send private message
raghav08
Currently Banned

New User


Joined: 03 Jun 2008
Posts: 94
Location: Bangalore

PostPosted: Wed Jul 16, 2008 1:14 pm
Reply with quote

Garry,

Could you please post a piece of code which having LOAD command, and just brief the usage of this code. Because would like to know the usage while developing the CICS application program.
Back to top
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Wed Jul 16, 2008 1:41 pm
Reply with quote

Hi Rai,

This code snippet demonstrates LOAD of a program which is an application table and makes it resident. The table entries are defined in DPT_TABLE_ITEM and are not updated. The table would mtypically be static as changes would require recoding of the table module.

Code:

   DCL SOME_INDEX                  BIN FIXED(31) INIT(1); 
   DCL TAB_PTR, DPT_PTR            POINTER;

   DCL 1       DPT_TABLE_ITEM      BASED(DPT_PTR),
              3   DPT_ID             CHAR(3),
              3   DPT_NAME           CHAR(20),               
                       .
                       .
              3   DPT_END            CHAR(0);
 

   /* determine the index somehow...   */
   SOME_INDEX = 2;
 
   /*  Load Table as resident - if not already loaded.  In any case, */
   /*  get the table's address...                                                   */

   EXEC CICS LOAD PROGRAM ('TABNAME') SET (TAB_PTR) HOLD;

   WRK_OFFSET = LENGTH(DPT_TABLE_ITEM) * SOME_INDEX;
   DPT_PTR = POINTERADD(TAB_PTR,WRK_OFFSET);

   /*  can now access details of the table entry      */




There are multiple entries in the program/table called TABNAME and it is necessary to calculate the offset into each. This could be done by looping through the table looking for a match. You could also map to the next entry by setting
Code:

 DPT_PTR = ADDR(DPT_END);


Regards,
Garry.
Back to top
View user's profile Send private message
raghav08
Currently Banned

New User


Joined: 03 Jun 2008
Posts: 94
Location: Bangalore

PostPosted: Wed Jul 16, 2008 2:36 pm
Reply with quote

Thanks Garry.
Back to top
View user's profile Send private message
raghav08
Currently Banned

New User


Joined: 03 Jun 2008
Posts: 94
Location: Bangalore

PostPosted: Wed Jul 16, 2008 3:00 pm
Reply with quote

Garry,

I have question for you.

Suppose the table DPT_TABLE_ITEM is loaded at task no.1 and your application program gave the control back to CICS. In task no.2 once again your program received the control back, during this can i access the table using the pointer which was loaded during the task no.1?

Basically i would like to know, using LOAD command can we access the data like DFHCOMMAREA?
Back to top
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Wed Jul 16, 2008 3:28 pm
Reply with quote

Rai,

The way LOAD works is that it sets the pointer to the address of the loaded program.

If the program is not already loaded, then the program is loaded and the address is set in the PPT and returned to the task. If the program is already loaded, the address in the PPT is returned to the task. In this way, any number of tasks can access the same copy of the loaded program.

It is possible to update the in-memory table but this is not recommended as the changes are not reflected back to the original load module or its source and so are lost if/when the program is re-loaded. If the program is not loaded with HOLD, re-loading can be random, being dependent on CICS memory management.

Regards,
Garry.
Back to top
View user's profile Send private message
raghav08
Currently Banned

New User


Joined: 03 Jun 2008
Posts: 94
Location: Bangalore

PostPosted: Wed Jul 16, 2008 3:57 pm
Reply with quote

Garry,

To some extend i understood the concept of the LOAD. Correct in thinking that, If I load a application program using LOAD command the advantage is reduce system overhead on load and unload.


I saw a statement in our manual "To load program/table/map from the CICS DFHRPL concatenation library into the main storage"

Here DFHRPL does represents a macro to define the program in PPT?
Back to top
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Wed Jul 16, 2008 4:22 pm
Reply with quote

Quote:
If I load a application program using LOAD command the advantage is reduce system overhead on load and unload.

The overhead is only reduced if you specify HOLD. This is the same as making the program RESIDENT in the PPT. Both have the effect of keeping the program in storage once loaded.

Quote:
"To load program/table/map from the CICS DFHRPL concatenation library into the main storage"


DFHRPL is not a macro. If you look at the CIC execution JCL you will see ddname DFHRPL . This specifies the (concatenation of) load libraries where CICS expects application programs to be stored. This is separate from STEPLIB which is where CICS's own load modules are found.

CICS Program Control locates programs in the DFHRPL library/ies whenever a program is required. This may be from CICS starting a task or a task issuing EXEC CICS LINK, EXEC CICS XCTL, EXEC CICS LOAD .

Tasks/Programs are defined in the PCT/PPT using the online CEDA transaction or the offline DFHCSDUP utility.

Regards
Garry.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Wed Jul 16, 2008 4:30 pm
Reply with quote

I acept the need to 'LOAD' tables, etc.

But I don't see any advantage to loading an executable module before xctl/link. If there was, the documentation would indicate that one should.
Back to top
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Wed Jul 16, 2008 4:39 pm
Reply with quote

Dick,

What I meant to convey is that CICS itself will load the module, if needed, whenever a LINK, XCTL or LOAD is performed. Certainly having to perform a LOAD before a LOAD would be amusing! Which comes first, the LOAD or the LOAD?

icon_rolleyes.gif

Garry
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Wed Jul 16, 2008 4:47 pm
Reply with quote

Garry,

I was responding to this:
Quote:
Garry,

To some extend i understood the concept of the LOAD. Correct in thinking that, If I load a application program using LOAD command the advantage is reduce system overhead on load and unload.


I saw a statement in our manual "To load program/table/map from the CICS DFHRPL concatenation library into the main storage"

Here DFHRPL does represents a macro to define the program in PPT?


I interpreted the comments of the OP to mean that he figured he could reduce the time to xctl/link.

If the OP meant other than what he said, I misinterpreted his miss-statement.
Back to top
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Wed Jul 16, 2008 4:50 pm
Reply with quote

Apologies, obviously replies are overlapping.....

Cheers,
Garry.
Back to top
View user's profile Send private message
raghav08
Currently Banned

New User


Joined: 03 Jun 2008
Posts: 94
Location: Bangalore

PostPosted: Wed Jul 16, 2008 5:07 pm
Reply with quote

Garry,

Yes I could see the DD name DFHRPL in my CICS job which concatenated with many load libraies.

Mean while please clarify me on NEW COPY. Whenever we do NEW COPY on CICS application program, internally the new version of load module copied to load library under DD name DFHRPL?
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Wed Jul 16, 2008 5:19 pm
Reply with quote

raghav08,

my sympathy goes out to you, having to work in a one man shop, no one to ask, no one to talk to.

you keep asking very basic questions. The new copy has been covered previously.

CICS maintains its 'LOAD Library' in core (memory). A new copy simply reloads the module from the application load library (which changed when you compiled/linked your module) into CICS core.


This is a link to IBM's document server listing about every cics doc that they have: publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/FINDBOOK?filter=CICS&SUBMIT=Find

you could also visit the redbook site: www.redbooks.ibm.com/redbooks.nsf/redbooks/
to find (and then download and READ).
Back to top
View user's profile Send private message
raghav08
Currently Banned

New User


Joined: 03 Jun 2008
Posts: 94
Location: Bangalore

PostPosted: Wed Jul 16, 2008 5:36 pm
Reply with quote

dbzTHEdinosauer,

Till now I knew that NEWCOPY will copy the new version of link edited load module of application program to CICS load libray, question i have is To which CICS load libary?

The load library under DD name DFHRPL? this what i want to confirm. My apologies, I'm not looking for what's the functionality of NEWCOPY.
Back to top
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Wed Jul 16, 2008 5:44 pm
Reply with quote

Quote:
Till now I knew that NEWCOPY will copy the new version of link edited load module of application program to CICS load libray,


Til now you have been wrong. NEWCOPY will copy the new version of the module FROM the first library in the DFHRPL concatenation.

It's the linkedit that puts the new version IN the load library.


As dbzTHEdinosaur says, this is very basic.


Regards,
Garry.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Wed Jul 16, 2008 5:49 pm
Reply with quote

Quote:
NEWCOPY will copy the new version of the module FROM the first library in the DFHRPL concatenation.
More precisely, NEWCOPY updates the internal CICS pointer to the program from the first library in the DFHRPL concatenation that contains the load module. If there's more than one copy of the load module in the DFHRPL concatenation libraries, the ones in the later libraries are ignored. If the load module only exists in the 17th library concatenated to DFHRPL, that's the one used for the NEWCOPY.
Back to top
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Wed Jul 16, 2008 5:57 pm
Reply with quote

Quote:
...that's the one used for the NEWCOPY.

hmmmmmm....

NEWCOPY invalidates the address in the PPT (internal CICS pointer) so that, when the program is next required, CICS finds it missing from storage and THEN searches the DFHRPL concatenation, selecting the first module of that name found.....

Garry
Back to top
View user's profile Send private message
raghav08
Currently Banned

New User


Joined: 03 Jun 2008
Posts: 94
Location: Bangalore

PostPosted: Wed Jul 16, 2008 6:13 pm
Reply with quote

Quote:
It's the linkedit that puts the new version IN the load library.


Garry,

Thanks for your posting.

Correct in thinking that,

1) When I changed the CICS program and link edited in TSO region, the new load module will reside in the first load library of DFHRPL

2) When I do NEWCOPY, the new load module copied FROM first libray of DFHRPL "TO" which load libray? [/quote]
Back to top
View user's profile Send private message
Earl Haigh

Active User


Joined: 25 Jul 2006
Posts: 475

PostPosted: Wed Jul 16, 2008 8:03 pm
Reply with quote

raghav08

all this is pretty basic stuff. It sounds like your experience is
very limited working with mainframe environments. Someone posted earlier, you are a 1 man shop.

If thats true, then you need to ask your management to send
you to some IBM training classes.
Back to top
View user's profile Send private message
raghav08
Currently Banned

New User


Joined: 03 Jun 2008
Posts: 94
Location: Bangalore

PostPosted: Thu Jul 17, 2008 11:04 am
Reply with quote

Earl Haigh,

Yes My mainframe experience is limited and My question could be basic, If you know the right answer please post it else stop the nuisance
Back to top
View user's profile Send private message
Garry Carroll

Senior Member


Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland

PostPosted: Thu Jul 17, 2008 12:32 pm
Reply with quote

Quote:
If you know the right answer please post it else stop the nuisance


That's hardly the approach to win friends & influence people.

Garry.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Jul 17, 2008 1:08 pm
Reply with quote

Not only that, the word nuisance is not used correctly in the sentence. either 'stop causing nuisance' or 'stop being a nuisance'. You probably meant stop being a nuisance (pest).

The linkedit job has a dd statement which will tell you which of the concatenated libraries in the DFHRPL reference your job will put your executable.

Look at the JCL for your linkedit step, look at the JCL for the cics started task (both can be viewed in SDSF - or whatever spool utility you have).

If your loadlib is first in the cics concatenation, no problems. but if there are others above in the cics concatenation, you need to BROWSE those libraries to insure that a memeber of the same name as your program does not exist.

unless you have your own bootleg jcl to compile/linkedit, your systems people should have provided you with jcl that would avoid the 'same member' problem.

I went to the effort to provide the above info, because unless you are having a problem with getting your corrected module into cics, NO ONE CARES ABOUT THIS CONCATENATION, WHERE IS WHAT CRAP unless you are a systems programmer! And someone whose fundamental knowledge of MF's is barebones at best, seems to make no effort to elevate his level of knowledge on his own and expects others to take their time to do it for him, becomes a nuisance.
Back to top
View user's profile Send private message
raghav08
Currently Banned

New User


Joined: 03 Jun 2008
Posts: 94
Location: Bangalore

PostPosted: Thu Jul 17, 2008 1:32 pm
Reply with quote

dbzTHEdinosauer,

You provided me pretty good information. I could see the the link edit load library, the same exist in the CICS jcl as well (but it's not first one).

Thanks dude.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> CICS Goto page 1, 2  Next

 


Similar Topics
Topic Forum Replies
No new posts RACF - Rebuild SETROPTS command which... All Other Mainframe Topics 3
No new posts Using API Gateway from CICS program CICS 0
No new posts Load new table with Old unload - DB2 DB2 6
No new posts Routing command Address SDSF to other... TSO/ISPF 2
No new posts How to load to DB2 with column level ... DB2 6
Search our Forums:

Back to Top