|
View previous topic :: View next topic
|
| Author |
Message |
Amb
New User
Joined: 12 Mar 2010
Posts: 64
Location: India
|
|
|
|
I am new to CICS and I have the following code in my COBOL program:
| Code: |
EXEC CICS LOAD
PROGRAM('BCE208OT')
SET(ADDRESS OF LKBE-TABLE)
HOLD
END-EXEC |
and program BCE208BT is as follows:
| Code: |
BCE208OT CSECT
DC C'****** START OF KBE TABLE ******'
DS F NUMBER OF TABLE ENTRIES
KBETABLE DS 200CL40 200 40 BYTE ENTRIES
DC C'****** END OF KBE TABLE ******'
END |
I want to know is it necessary to write BCE208BT in assembler.
Can BCE208BT be written in COBOL? If yes, how? |
|
| Back to top |
|
 |
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Quote: |
I want to know is it necessary to write BCE208BT in assembler.
|
yes
| Quote: |
Can BCE208BT be written in COBOL? If yes, how?
|
can't |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
now, an analysis of BCE208BT needs to be done.
how is it used in your program?
is it used by other programs?
Since it can not be updated,
and contains no data,
it appears to be a hold-over from older cics where storage was a premium.
depending upon how it is used, it could be replaced by- an internal cobol table (internal to your cobol program)
- getmain
|
|
| Back to top |
|
|
Amb
New User
Joined: 12 Mar 2010
Posts: 64
Location: India
|
|
|
|
Thanks for the quick response.
I just wanted to know if we can write a COBOL program in the program parameter of the EXEC CICS LOAD statement
So can I conclude that BCE208BT Program in EXEC CICS LOAD statement should be written in assembler only. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Quote: |
I just wanted to know if we can write a COBOL program in the program parameter of the EXEC CICS LOAD statement
|
a quick look of the manual would tell you, that that is correct.
there is more than 1 reason to LOAD a program, or load anything.
if the purpose is to load an assembler table via the LOAD API, then yes,
the user-prepared table needs to be written in assembler.
you need to read the manual before making too many conclusions. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
How does the number of entries in the CSECT get populated?
This will not yield itself as Threadsafe.
If you change -
| Code: |
BCE208OT CSECT
DC C'****** START OF KBE TABLE ******'
DS F NUMBER OF TABLE ENTRIES
KBETABLE DS 200CL40 200 40 BYTE ENTRIES
DC C'****** END OF KBE TABLE ******'
END
|
to -
| Code: |
BCE208OT CSECT
DC C'****** START OF KBE TABLE ******'
DC A(KBETABLN/40) NUMBER OF TABLE ENTRIES
KBETABLE DS 200CL40 200 40 BYTE ENTRIES
KBETABLN EQU *-KBETABLE LENGTH OF TABLE-RELATED STG
DC C'****** END OF KBE TABLE ******'
END
|
Then, the fullword will always be correct after Assembly and will resolve to 200.
Is there a particular reason why there are static literals surrounding the table information?
I trust the DSECT (COBOL LINKAGE COPYBOOK) are defined for these?
But, they don't make any sense, unless they're used as eyecatcher's....
Bill |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
I see that you're issuing a LOAD PROGRAM HOLD. Are you using HOLD because you're then loading the 200 entries with data?
Note that when you use HOLD, the table becomes permanent in memory, unless you issue a RELEASE PROGRAM.
How do other programs/tasks know whether the table has been loaded or is in the process of being loaded? You can really cause some serious EUDSA shortages if many other tasks issue a HOLD as well.
Then, you'll having many copies of this table in memory.
There's a better way to make the table core-resident and that's to use a PLT-PI program, which issues a START of a TRANSID and then this transid is invoked when CICS receive control and loads the table with data in background.
In the PPT entry, have your Tech Support personnel define this table as core-resident.
It will be a better use of resources....
Bill |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1205
Location: Dublin, Ireland
|
|
|
|
| Quote: |
How do other programs/tasks know whether the table has been loaded or is in the process of being loaded? You can really cause some serious EUDSA shortages if many other tasks issue a HOLD as well.
Then, you'll having many copies of this table in memory.
|
This would apply where the program is defined with RELOAD=YES. With RELOAD=NO, once the program has been loaded, subsequent EXEC CICS LOADs will return the memory address of the already-loaded program.
Garry. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
| Quote: |
This would apply where the program is defined with RELOAD=YES. With RELOAD=NO, once the program has been loaded, subsequent EXEC CICS LOADs will return the memory address of the already-loaded program.
Garry. |
Yes, should have elaborated on this more....
Bill |
|
| Back to top |
|
|
Earl Haigh
Active User
Joined: 25 Jul 2006
Posts: 475
|
|
|
|
FYI:
it is possible to write a cobol program to load the assembler table
and access its values.
The how requires understanding the layout of the assember table
and maybe a good CICS contract programmer to write it.
 |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
FYI
| The Topic Starter Originally wrote: |
I want to know is it necessary to write BCE208BT in assembler.
Can BCE208BT be written in COBOL? If yes, how?
|
The TS already has a COBOL program loading an Assembler Table.
He wants to know if the table, to be loaded by the CICS LOAD API,
can be written in COBOL...... |
|
| Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
Truth be known, in a prior life I actually DID encounter one situation in which a CICS program did a CICS LOAD(xxxx) of a table where xxxx was a COBOL program. The "actual" data for the table, however was offset from the load point by some 200+ bytes. Reason? the stuff inherent in a COBOL module that exists prior to the actual WORKING-STORAGE data in the executable module.
Of course, every time the COBOL table program was recompiled, even if just to change an argument or result value, the offset had to be determined anew due to compiler differences, and the COPYBOOK for the table used by the CICS program had to be changed to reflect the new offset, followed by a recompile of the CICS program as well.
Needless to say, I re-wrote the table module in Assembler so that the table always started at offset zero. Then the COPYBOOK only had to be updated for layout changes.
That need to redetermine the offset in a COBOL table is why LOADed tables should be written in assembler and not COBOL. |
|
| Back to top |
|
|
|
|
