Pinned topic Persistent Working-Storage under IMS?

OK, I know nothing about IMS :-)

But this question is a little lonely...

There are some IMS-knowledgeable people at www.ibmmainframes.com.

My blind-as-a-bat suggestion would be to acquire a lump of storage that does not get destroyed, get a pointer to that storage to the IO routine, and use that storage as the "persistent" storage.

I'm guessing you have thought of something like that, but you need to know if it is a "good under IMS" solution...

Working-Storage across "tasks" (and across run-units) is difficult to achieve.

I can imagine (at least) 3 ways to achieve this (I don't have experience with these).

1) Use something like a linear dataset (and Linkage Section) to store and retrieve data.   However, if  you are doing simultaneous reads AND write, there might well be synchronization problems

2) IBM does support multi-tasking in COBOL under IMS. See for example

 http://pic.dhe.ibm.com/infocenter/pdthelp/v1r1/index.jsp?topic=%2Fcom.ibm.entcobol.doc_3.4%2Ftpthr02.htm

Therefore, it SHOULD be possible to have a non-COBOL (Assembler) driver)( that actually starts each task.  The WS data would be persistent while the Local-Storage data would be for each instance of the program.   However, if you are talking about a common subroutine that is called by multiple  programs and transactions, I don't think this would for that.

3) Probably the "cleanest" way to do this would be to place the data that you want into an IMS (or DB2) database and then access it via normal means - both for reading and updating.  In that way standard IMS (facilities would handle the synchronization issues

Can you clarify something for me?  Are you saying that this used to work (under older version of COBOL), but it no longer works (with Enterprise COBOL)?  Or are you saying you think you could have gotten it to work with older versions of COBOL but you can't see how to make it work with Enterprise COBOL?  Because unless your MPP is a long running 'task' that handles multiple transactions (I don't know how IMS MPPs work) I don't see how you could possibly, within just COBOL "memory management" itself, get this to work.  As Bill says above, you'd have to save off the WS area to some persistant storage, and then retrieve it for the new transaction/task.

But in the end its not clear to me what you are trying to accomplish, as there (as far as I know) has never been support for persisting working-storage outside of a "COBOL run unit".  I've never heard of NOENDJOB or LRR, but they appear to me to refer to the COBOL runtime and as far as I can tell have nothing to do with COBOL working-storage. 

Just my thoughts...

Frank

"[A] program, essentially an I/O module ...  caches some very high activity data in W-S".

I saw this as a program which is called from many places to get information. The most common information is stored in W-S (perhaps originally coming from a file/db), and returned from there, otherwise the program goes off to access the file/db. A performance thing. It is all very well having something in a "buffer" somewhere so there is no physical IO, but it still occupies time, there and back, to discover that if you go through the normal file/db route and rely on it being in the buffer.

I assume that there is information that is not/connot be "hard coded" in the W-S (if it could, problem goes away).

I don't think storing the data on any file or database would serve the performance issue.

With RTEREUS a "reuable run-time environment" can be made for a COBOL program . For instance, try a COBOL Compiler exit without RTEREUS and prepare to go for lunch whilst the compile is running and the COBOL exit is constantly called/cancelled. Having made a COBOL program persistent through RTEREUS, then the W-S is persistent. But Pete points out that is is not recommended for IMS.

Perhaps I've misunderstood.

RTEREUS is (ws) intended to keep the COBOL run-time environment available.  This was intended to avoid going thru the enire run-time initialization process every time a COBOL main program was started.

At NOT time was it documented as keeping "program-specific data" persistant across run units.

The same could be said for the OS/VS COBOL NOENDJO process.

There is a "world of difference" between persistence of application data vs persistence of the COBOL run-time environment.

Having said this and knowing (somewhat)  how OS/VS COBOL used to work.  I don't remember ever doing it, but using NOENDJOB with an IMS preloaded program might actually have done what was reported.  I can almost guarantee that it was never documented as doing this.

Similarly, I could imagine that using a NORENT Enterprise COBOL program that was preloaded (IMS preload) there might be some way of tricky the system into keeping WS values across run-units.  I don't know how, and I am certain it wouldn't be supported.In fact, I just checked and RENT is required for IBM preload, so there really, REALLY, would be no way to keep WS across run-units.

As far as I remember, an IMS regions doesn't have anything similar to a CICS CWA - a place to store region-wide data. It it did, then that would be a possible solution to this issue too.

• wmklein 200000329M
• ‏2013-09-19T19:00:39Z

RTEREUS is (ws) intended to keep the COBOL run-time environment available.  This was intended to avoid going thru the enire run-time initialization process every time a COBOL main program was started.

At NOT time was it documented as keeping "program-specific data" persistant across run units.

The same could be said for the OS/VS COBOL NOENDJO process.

There is a "world of difference" between persistence of application data vs persistence of the COBOL run-time environment.

Having said this and knowing (somewhat)  how OS/VS COBOL used to work.  I don't remember ever doing it, but using NOENDJOB with an IMS preloaded program might actually have done what was reported.  I can almost guarantee that it was never documented as doing this.

Similarly, I could imagine that using a NORENT Enterprise COBOL program that was preloaded (IMS preload) there might be some way of tricky the system into keeping WS values across run-units.  I don't know how, and I am certain it wouldn't be supported.In fact, I just checked and RENT is required for IBM preload, so there really, REALLY, would be no way to keep WS across run-units.

As far as I remember, an IMS regions doesn't have anything similar to a CICS CWA - a place to store region-wide data. It it did, then that would be a possible solution to this issue too.

More...

Gentlemen!

Thank you muchly for the replies - they _are_ appreciated. Here's the non-existent documentation, Mr. Klein (I don't know how you prefer to be addressed - apologies if I've got it wrong):

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGYMG202/APPENDIX1.13.3.2?SHELF=&DT=20001004155832&CASE=

The salient bit is as follows:

In the VS COBOL II run-time environment when using the LIBKEEP run-time option, OS/VS COBOL programs compiled with ENDJOB were treated as NOENDJOB. NOENDJOB was required for preloaded OS/VS COBOL programs.

Because IBM COBOL programs and their resources (all work areas and library routines) are always deleted at termination, the way ENDJOB and NOENDJOB work in the Language Environment run-time environment allows both IBM COBOL and OS/VS COBOL programs to be treated similarly with respect to last-used state.

In the OS/VS COBOL run-time environment, ENDJOB was the strongly recommended compiler option when executing IMS transactions invoking nonpreloaded COBOL programs.

In the VS COBOL II run-time environment when using the LIBKEEP run-time option, OS/VS COBOL programs compiled with ENDJOB were treated as NOENDJOB. NOENDJOB was required for preloaded OS/VS COBOL programs.

>>> Note: When using LRR, NOENDJOB behavior is always in effect. <<<

Now, this is old - very old. But the functionality used to be there (I found other references too).

As for other things: update frequency for the table in question is measured in updates per decade - it is rock steady. The MPP regions in question are recycled daily, so no issues there. A colleague and I looked into this a bit and the COBOL runtime seems to recognize that a program is already part of the run unit if the entry point address didn't change - so might marking the module for preload do the job?

Bill (Woodger): You've hit the nail precisely on the head. Almost any other method of storing the data would be more expensive in terms of both CPU and - more significantly - programmer time than just hanging on to working-storage, as there are a goodly number of places where an idiotically-simple-to-implement  technique (bang it in the preload list) would save just *oodles* of time - at present the database is being hit with an absolutely obscene frequency. This offends my sense of propriety :-)

Marking the module for preload seems at least worth a try, so I have requested that a test be run.  

Seems very odd that a region-wide solution isn't available (I mean, I only need one - one! - fullword and I can do the rest myself). There is the IMS Scratch Pad Area (SPA) but it looks tricky to use so I don't want anything to do with it for the reasons outlined above.

Thanks again for the replies - I really am grateful. And this wandering round the (bleeding?) edge of the COBOL world is fun, too. 

Pete.

And this may be it (next topic from the one above). Does LRR apply under IMS these days?

APPENDIX1.13.3.3 When programs remain in the last-used state

A program remains in last-used state between COBOL transactions only when all the following conditions are true:

• It is an OS/VS COBOL program compiled with the NOENDJOB option or LRR is being used.
• It has been link-edited with the REUS option.
• It has been preloaded.
• It is a dynamically called subprogram or a statically called subprogram that has, itself, been called by a dynamically called subprogram.

Did you see the paragraph that says,

 "Because Enterprise COBOL programs and their resources (all work areas and library routines) are always deleted at termination, the way ENDJOB and NOENDJOB work in the Language Environment runtime environment allows both Enterprise COBOL and OS/VS COBOL programs to be treated similarly with respect to last used state."

In other words, it isn't (exactly) Enterprise COBOL that is giving you "bad" results.  It is LE itself.  If you run your existing OS/VS COBOL, NOENDJOB program under LE it will only get "persistent" last-used state in with the restricitons you listed above.

EVERY other COBOL program (OS/VS COBOL or later) will be entered in initial state (the first time it is called in a run-unit)

I know that for performance reasons, you want a different answer, but you aren't going to find one.  (This is especially true for programs compiled with RENT)

You must use some "external" facility (file, database, SPA, "monk with a quill pen" - whatever) to communicate between run-units .

Of course, there is nothing stopping you from keeping this routine,

• compiled with OS/VS COBOL (and NOENDJOB)
• preloaded
• link-edited with REUS

You will need to call in DYNAMICALLY (which has some overhead) and your CALLING program will need to use DATA(24) if you want to pass data to the subroutine.

You also need to be aware that starting with z/OS V2 (GA next week), you will get run-time warning messages for every OS/VS COBOL program that you call.  (Sort-of hints that OS/VS COBOL run-time support MAY be ended during the life of z/OS V2).

Of course, if you ever want to upgrde to Enterprise COBOL V5R1 (or lter), using an OS/VS COBL subroutine won't work.  Starting with this release, you can't have ANY mixture of Enterprise COBOL 5.1 and OS/VS COBL programs - even if they are dynamically Called.

If you are running OS/VS COBOL preloaded programs in IMS today, you may want to searchthe web for problems with an OLD user modification to the IMS routine DFSPCC20

• wmklein 200000329M
• ‏2013-09-20T13:33:49Z

Did you see the paragraph that says,

 "Because Enterprise COBOL programs and their resources (all work areas and library routines) are always deleted at termination, the way ENDJOB and NOENDJOB work in the Language Environment runtime environment allows both Enterprise COBOL and OS/VS COBOL programs to be treated similarly with respect to last used state."

In other words, it isn't (exactly) Enterprise COBOL that is giving you "bad" results.  It is LE itself.  If you run your existing OS/VS COBOL, NOENDJOB program under LE it will only get "persistent" last-used state in with the restricitons you listed above.

EVERY other COBOL program (OS/VS COBOL or later) will be entered in initial state (the first time it is called in a run-unit)

I know that for performance reasons, you want a different answer, but you aren't going to find one.  (This is especially true for programs compiled with RENT)

You must use some "external" facility (file, database, SPA, "monk with a quill pen" - whatever) to communicate between run-units .

Of course, there is nothing stopping you from keeping this routine,

• compiled with OS/VS COBOL (and NOENDJOB)
• preloaded
• link-edited with REUS

You will need to call in DYNAMICALLY (which has some overhead) and your CALLING program will need to use DATA(24) if you want to pass data to the subroutine.

You also need to be aware that starting with z/OS V2 (GA next week), you will get run-time warning messages for every OS/VS COBOL program that you call.  (Sort-of hints that OS/VS COBOL run-time support MAY be ended during the life of z/OS V2).

Of course, if you ever want to upgrde to Enterprise COBOL V5R1 (or lter), using an OS/VS COBL subroutine won't work.  Starting with this release, you can't have ANY mixture of Enterprise COBOL 5.1 and OS/VS COBL programs - even if they are dynamically Called.

If you are running OS/VS COBOL preloaded programs in IMS today, you may want to searchthe web for problems with an OLD user modification to the IMS routine DFSPCC20

More...

Um, well, yes, as a matter of fact I did see that. Let's both read it again:

A program remains in last-used state between COBOL transactions only when all the following conditions are true:

• It is an OS/VS COBOL program compiled with the NOENDJOB option or LRR is being used.
• It has been link-edited with the REUS option.
• It has been preloaded.
• It is a dynamically called subprogram or a statically called subprogram that has, itself, been called by a dynamically called subprogram.

Does my interest in LRR (or any functional equivalent under LE) now become clear? LRR is Library Routine Retention, which is a very slightly obtuse COBOL/2 runtime option and nothing to do with OS/VS COBOL at all.  And as I said in my original post, it is very unlike IBM to remove functionality completely - especially when it's so very, very useful (and thus likely to be widely used).

If it helps, the client has no OS/VS COBOL (and I wouldn't recommend going back if you pointed a gun at my head). I can be sure of that  'coz I ran an analysis of the load libraries. They compile with DYNAM, too. By definition the program I'm interested in, and any similar ones, are subprograms. As noted in an earlier post their load modules are all marked REUS (not RENT) - something I used to find odd in IMS shops. 

It all hinges on whether LE runs in a functionally equivalent mode to LRR-enabled COBOL/2 under an IMS MPP. As I can't imagine why anyone would not use LRR-or-equivalent in those circumstances (to avoid all that expensive up-and-downing with the environment) I'd like to know. I really do think it's a perfectly reasonable question. 

As ever, thanks for the reply. It all helps focus on the issue.   

• PeteInOxford 270002TGF8
• ‏2013-09-20T15:41:21Z

Um, well, yes, as a matter of fact I did see that. Let's both read it again:

A program remains in last-used state between COBOL transactions only when all the following conditions are true:

• It is an OS/VS COBOL program compiled with the NOENDJOB option or LRR is being used.
• It has been link-edited with the REUS option.
• It has been preloaded.
• It is a dynamically called subprogram or a statically called subprogram that has, itself, been called by a dynamically called subprogram.

Does my interest in LRR (or any functional equivalent under LE) now become clear? LRR is Library Routine Retention, which is a very slightly obtuse COBOL/2 runtime option and nothing to do with OS/VS COBOL at all.  And as I said in my original post, it is very unlike IBM to remove functionality completely - especially when it's so very, very useful (and thus likely to be widely used).

If it helps, the client has no OS/VS COBOL (and I wouldn't recommend going back if you pointed a gun at my head). I can be sure of that  'coz I ran an analysis of the load libraries. They compile with DYNAM, too. By definition the program I'm interested in, and any similar ones, are subprograms. As noted in an earlier post their load modules are all marked REUS (not RENT) - something I used to find odd in IMS shops. 

It all hinges on whether LE runs in a functionally equivalent mode to LRR-enabled COBOL/2 under an IMS MPP. As I can't imagine why anyone would not use LRR-or-equivalent in those circumstances (to avoid all that expensive up-and-downing with the environment) I'd like to know. I really do think it's a perfectly reasonable question. 

As ever, thanks for the reply. It all helps focus on the issue.   

More...

If a fullword will do you, perhaps here: http://pic.dhe.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.ceea300/clcusra.htm

Just realised you probably won't be able to know the address of these locations, so finding any content may not be as rapid as desired anyway.