DATA(31) Option in compile JCL

himanshu_gupta02 · New User Joined: 31 Jul 2006 Posts: 6

Hi Friends,

I have an urgent query. I compiled my program in test and It ran fine.
But when I compiled my program in Production; it compiled file but bombed at run time.

I assumed that default option is DATA(31). But I was told that I was supposed to use DATA(31) option in JCL at compile time to prevent this problem of memory. This is not CICS program. Its only COBOL module.

I am not sure what exactly is wrong. Please guide me. What changes I can make to make the JCL DATA(31) option free and make it default to prevent this problem in future.

enrico-sorichetti · Posted: Wed Oct 24, 2007 7:48 pm

himanshu_gupta02 · New User Joined: 31 Jul 2006 Posts: 6

My assumption was wrong. The setting is made with RENT and DATA(24) option as default.

So it took the 24 option and bombarded.
What can be done to change default settings to 31?
Any specific reason because of which this could have been chosen?

Does 24 takes less memory?

dick scherrer · Posted: Thu Oct 25, 2007 2:43 am

Hello,

I'd suggest you talk with your system support people and determine why the test and production environments are not in sync (if indeed they are not).

Your tech support people will know far more about your system than we will.

It should be a rule that everyone uses standard jcl, so if you have problems, others will have them also. If you are using some kind of "custom" jcl, i suggest you convert to standard jcl. I would not spend time modifying "your own" jcl - using the standard jcl will be far more reliable.

himanshu_gupta02 · New User Joined: 31 Jul 2006 Posts: 6

Thanks for your inputs.

I want to know what could be the technical reason for the setting DATA(24).
Some memory allocation saving or something?

enrico-sorichetti · Posted: Thu Oct 25, 2007 11:57 am

dick scherrer · Posted: Thu Oct 25, 2007 7:44 pm

Hello,

Mistermind · New User Joined: 08 Feb 2008 Posts: 46 Location: Dublin

I think DATA(24) for cobol equates to AMODE(24) for assembler.

In the days before IBM opened up 31-bit addressing for customers' use, the high-order byte of any fullword address was always unused. Many IBM assembler macros would hijack that byte to store options and use as workfields. When AMODE31 came along IBM had to issue AMODE31 versions of said macros. But there are too many of those old macros and programs, and I believe not every macro now has a clean 31-bit version available.

The assembling process should highlight these AMODE24 macros whose hijacking action will cause problems at runtime if you load above the 16MB line, accessing the last 7 bits of the high-order byte as true partition address. But not cobol compilers.