View previous topic :: View next topic
|
Author |
Message |
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
|
|
|
|
rajendra kalepu wrote: |
The program being called contains the retsart logic for all the programs of different applications which are under my account |
Check-point restart and AMODE(24)/(31) are two different things altogether. Why do you worry about them?
When you have an application that has COBOL subprograms, some of the COBOL subprograms can be AMODE 31 and some can be AMODE 24. Actually, if your application consists of only COBOL programs, and you are using only static and dynamic calls, you - as a programmer don't really need to bother much, as each COBOL subprogram will always be entered in the proper AMODE. For example, if you are using a dynamic call from an AMODE 31 COBOL program to an AMODE 24 COBOL program, the AMODE is automatically switched unless you are using procedure pointers, function pointers, or other languages that call COBOL subprograms.
Said that and trying to read between the lines (pose) - a very raw suggestion, compile your sub-program with AMODE (31), compile your main program with AMODE (31) - execute main program and see what happens. |
|
Back to top |
|
|
rajendra kalepu
New User
Joined: 29 Jul 2011 Posts: 21 Location: India
|
|
|
|
Hi Anuj,
Thank you for the valuable info.
Here the problem is the same subprogram is used by many applications
If i try to compile the subprogram with AMODE(31) . I may not sure may be other application programs which are compiled at AMODE(24) calling this sub program will fail. Correct me if i am wrong
Let me know for more information
Thanks and regards,
Rajendra kalepu |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
|
|
|
|
rajendra kalepu wrote: |
If i try to compile the subprogram with AMODE(31) . I may not sure may be other application programs which are compiled at AMODE(24) calling this sub program will fail. Correct me if i am wrong |
To get to that answer - You need to answer couple of questions from Bill (O'Boyle) and Bill (Woodger),I'll repeat them:
1. What release of COBOL are you using?
2. Do you really need AMODE(24)/DATA(24) for sub-programs or other programs? Making them AMODE(31) will not harm you, it's 2014! |
|
Back to top |
|
|
rajendra kalepu
New User
Joined: 29 Jul 2011 Posts: 21 Location: India
|
|
|
|
Hi Anuj
1. IBM Enterprise COBOL for z/OS 4.2.0 is the version of COBOL we are using
2. Yes we cant change the AMODE for sub programs due to certain restrictions from the account
Please let me know for more information, Thanks in advance
Regards,
Rajendra |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Please give us some idea of these restrictions. As Anuj has said, this is 2014 and to have an AMODE(24) load-module is archaic at best, especially running with Enterprise COBOL 4.2.
I think what you'll find is the old "Well, we always ran it this way", which is a holdover from the OS/VS COBOL days (pre-COBOL2).
It would be best to tackle this issue now, because you'll find additional AMODE(24) restrictions in Enterprise COBOL 5.1, which is now available.
Don't get caught with your pants down.
BTW, this AMODE(24) sub-program is called by other programs? Are these callers also AMODE(24)? |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
I think you maybe in luck. Review the LE Callable Service routine CEECRHP (Create Heap), where you can request 24-Bit storage by the AMODE(31) Caller.
The only issue might be the PARMLIST created by COBOL, when calling the AMODE(24) sub-program, as it might be built from the AMODE(31) callers TGT (Working-Storage).
If the PARMLIST is created from AMODE(31) storage, when the AMODE(24) sub-program gains control, you may get a S0C4, because (under the covers), the sub-program needs to address R1 and if the address is 31-Bit, the high-order byte of the parmlist-address (at zero off R1) will be lopped-off, resulting in an invalid-address and a S0C4.
Lots of fun and games.... |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
rajendra kalepu,
Can you show the definitions of your three tables? |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Possibly this is too far afield, but could you not have 2 callable modules - 1 for 24 and the other for 31?
Personally, i'd prefer a single bit of code, but properly documented and understood, this might be a simple workaround . . . |
|
Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010 Posts: 3049 Location: NYC,USA
|
|
|
|
Raj,
Let us get to the root cause, tell us agian few things.
1) As Nic and Terry said here, can you be able to store only key values to these array's ?
2) Why would you need to store entire record and apprently all the records into working storage and getting them exausted with storage?
3) If you have input as PS file then can't your program do sequential logic processing as others do in this industry?
4) If there is a limit of 128MB designed or may be more depending upon the MODE, still why would like to reach to that limit now or in nearer future?
So I think as well as Dick also said please explain us the logic and may be restructuring the piece of code would solve the problem forever. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
the TS has stated that this program is 15 years old.
sounds as if his shop was an old DOS shop,
thus the 24 bit constraint,
and put everything on a new (semi-new)
MVS machine and let everything rip.
sounds as if they are trying to do everything on the cheap.
they probably have a billion sub-programs and the company has not made very good plans to migrate the system.
before i would start enabling 32 bit code, and dealing with the problem of calling 24 bit modules,
i would revisit the module in question.
Nic, Terry and Dick all alluded to the logic problem.
WTF does everything have to be stored?
Machine time would be better spent properly SORTing input against the proposed usage
than running indexes up and down tables searching for a hit.
If the problem is multi-hit on same input and required accumulation,
output a record for each hit
and create the accumulation with SORT.
SORT will run in 32bit environment, with nearly unlimited record count,
thus minimizing the required changes to the existing program
and forcing a one-by-one conversion in this unprepared rookie environment.
an alternate approach would be to replace this old program with a JOINKEYS sort. |
|
Back to top |
|
|
rajendra kalepu
New User
Joined: 29 Jul 2011 Posts: 21 Location: India
|
|
|
|
Hi All,
Sorry for the Late reply as i am out of station
Rohit-
You are right, Storing Key is better compared to entire record
Unfortunately since the program was written 15 years back i was just thinking whether they might have written it for a reason
The program just reads the file, stores type0, type1 and type 2 records in 3 different arrays for a particular key until new key is found, Then loads database with respective values.
Once the new key is found the array is initialized and new Key is loaded and process repeated.
I am taking each and every one of your inputs and will try to re structure it
which will give me along term solution
i will update you all on my findings and approach shortly
Thanks |
|
Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
|
|
|
|
If you are just merging data from 3 files into one record per key then maybe a JOINKEYS solution in you sort product may be the way to go? Create each record to be loaded in sort and use your COBOL program to load it. JOINKEYS would not have been available when the program was originally written so it may be worth a look. |
|
Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010 Posts: 3049 Location: NYC,USA
|
|
|
|
If you are using DB2 as a Data Base then instead of an array use a Global Temp Table and insert all the rows into it than populating Array , or as Nic and others suggested to check if JOINKEYS makes sense to get what you want bedore you invoke a COBOL program. |
|
Back to top |
|
|
|