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

Cobol call from Ezt - Variable length limitation


IBM Mainframe Forums -> CA Products
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Mahesh Krishnamoorthi

New User


Joined: 13 Oct 2015
Posts: 4
Location: USA

PostPosted: Mon Oct 19, 2015 9:09 pm
Reply with quote

Hello,

I have a Cobol subroutine that has a linkage section declared with a total length of 150000 bytes through an array.
01 LS-MAINVARIABLE.
05 LS-ARRAY OCCURS 0 TO 250 TIMES DEPENDING ON LS-SUB.
10 LS-VARIABLEA PIC X(600).

I am trying to call this subroutine from an eztrieve and its equivalent eztrieve declaration is

LS-MAINVARIABLE W 150000 A
LS-ARRAY LS-MAINVARIABLE 600 A OCCURS 250
LS-VARAIABLEA LS-ARRAY 600 A

This is a problem because eztrieve does not allow variable declarations to exceed 32K. Is there anyway I can overcome this? The only other option I have is to recode the eztrieve to a cobol program
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Mon Oct 19, 2015 9:53 pm
Reply with quote

Can you show the error messages you are getting. I can't remember any such restriction.
Back to top
View user's profile Send private message
Mahesh Krishnamoorthi

New User


Joined: 13 Oct 2015
Posts: 4
Location: USA

PostPosted: Mon Oct 19, 2015 10:05 pm
Reply with quote

Bill, here you go

*******B097 LENGTH INVALID FOR TYPE - A
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Mon Oct 19, 2015 10:57 pm
Reply with quote

Code:
LS-ARRAY W 600 A OCCURS 250
Back to top
View user's profile Send private message
Mahesh Krishnamoorthi

New User


Joined: 13 Oct 2015
Posts: 4
Location: USA

PostPosted: Tue Oct 20, 2015 12:28 am
Reply with quote

I should have been more precise. I get this error for the declaration of LS-MAINVARIABLE. This variable has other subvariables too under it and the only variable that the COBOL will accept in the linkage is LS-MAINVARIABLE
A more detailed example is as follows

01 LS-MAINVARIABLE.
05 LS-ARGUMENT1 PIC X(10).
05 LS-ARGUMENT2 PIC X(10).
05 LS-ARRAY OCCURS 0 TO 250 TIMES DEPENDING ON LS-SUB.
10 LS-VARIABLEA PIC X(600).

Equivalent Ezt -
LS-MAINVARIABLE W 150020 A
LS-ARGUMENT1 LS-MAINVARIABLE 10 A
LS-ARGUMENT2 LS-MAINVARIABLE +10 10 A
LS-ARRAY LS-MAINVARIABLE +20 600 A OCCURS 250
LS-VARAIABLEA LS-ARRAY 600 A
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue Oct 20, 2015 4:18 am
Reply with quote

Well, that's a problem then.

Easytrieve Plus was originally written in the early 1980s or so. I guess you're on 6.4 or something around there. I don't know if 11, the "next" version, has a larger limit.

I'd define six groups of data, your non-table part, and then your table in five pieces of 50 each (30,000 bytes).

I'd write a new COBOL program that took seven parameters, these six plus the count.

The new COBOL program would put together the structure you want for the original COBOL program in WORKING-STORAGE, using the relevant items from the LINKAGE SECTION. Then CALL the original COBOL program with the correct structure from WORKING-STORAGE (and anything else needed).

You could ask CA Support to see if they can suggest anything.
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen

PostPosted: Wed Oct 21, 2015 11:32 am
Reply with quote

Code:

ABPLENGTH  W    4 B VALUE 6291456 . * TOTAL LENGTH OF ABPAREA
ABPAREA     W  512 A OCCURS 12288 INDEX SUBA


Never had a problem with before mentioned definition.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Wed Oct 21, 2015 12:23 pm
Reply with quote

Yes, Peter.

However, the structure is not solely an occurs, so for the "overlay redefinition" style you need a big initial item to contain the multiple items. The big initial item is limited to 32k.

There's no need to split into five (I should have stuck to my original on that) but I can't see how to do it (reasonably) without splitting it.

Code:
A W 1 OCCURS 150000
B A W 10


Doesn't work, as far as I remember.
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen

PostPosted: Wed Oct 21, 2015 12:34 pm
Reply with quote

Sure Bill, that's why I used this solution. And concerning the "overlay redefinition", that followed the main definition. I found it not necessary to show that too.

What is important that is that EZT allocates the total amount of storage, and with some subtle indexing/subscripting you can just walk through that chunk of storage.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Wed Oct 21, 2015 1:32 pm
Reply with quote

So, define the storage with OCCURS (with one more than needed) and an INDEX, doing the length of the OCCURS as 600 for convenience, can do the redefinition of that for the two tens, then offset the index by 20 from the otherwise "normal" calculation.

Document it well, for the definition and the use.

It will work, because of the way Easytrieve Plus gets the programmer to calculate the value of an index. I can't think that it would easily break in a new version of Easytrieve Plus.

However, that's not to say I like it, which is why I'd prefer CA Support to have suggested it...

All it takes is some idiot to look at the index calculation and say "that add of 20 is wrong" and then because they knew it was wrong, they don't connect to it when the program no longer works (subtly or otherwise).

On the other hand, that's pretty much always true to an extent with Easytrieve Plus's indexes, because it is down to the programmer to calculate them.

If the OCCURS can be separated from the rest of the data in the COBOL program, then do it that way.

If not, consider the intermediate COBOL program (only need one OCCURS of 250, not five of 50 as I suggested earlier). This will be "transparent" to anyone looking at the program.

Else, Peter's suggestion. It will work, perform better (if that is important for the volume of data in your task) but not be transparent. However, since you didn't come up with that yourself, Mahesh, make really sure that you and everyone there understands it and documents it well, exactly and correctly.

Then, if it screws up at some point, you have no-one to blame but yourselves.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Wed Oct 21, 2015 2:32 pm
Reply with quote

Of course, you could "hide" the access in a macro (or more). That'd make me happier :-)
Back to top
View user's profile Send private message
Mahesh Krishnamoorthi

New User


Joined: 13 Oct 2015
Posts: 4
Location: USA

PostPosted: Thu Oct 22, 2015 5:29 am
Reply with quote

Bill Woodger wrote:
So, define the storage with OCCURS (with one more than needed) and an INDEX, doing the length of the OCCURS as 600 for convenience, can do the redefinition of that for the two tens, then offset the index by 20 from the otherwise "normal" calculation.


I must admit I don't quite understand this. What variable will I pass on to the COBOL? I still need that "big initial item" declared to use to pass to the COBOL, right?
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Thu Oct 22, 2015 11:45 am
Reply with quote

Yes, the big initial item will be 251 * 600. Slightly larger, but doesn't matter at all.

The first 20 bytes of the first OCCURS of 600 will contain your two 10-byte items. Then the first 580 bytes of the first actual entry. The second OCCURS will contain the last 20 bytes of the first actual entry and the first 580 bytes of the the second actual entry. Exactly how the COBOL program wants to see the data.

When you calculate the INDEX to reference the data in your Easytrieve Plus program, you don't use a data-name as a subscript, but you use the INDEX defined with the OCCURS. When you calculate the value of the index you add 20 to it. That's how you get the offsetting in the actually defined OCCURS. The OCCURS define the storage, and you use them slightly differently to store and reference the data.
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 -> CA Products

 


Similar Topics
Topic Forum Replies
No new posts How to split large record length file... DFSORT/ICETOOL 10
No new posts Replace each space in cobol string wi... COBOL Programming 3
No new posts PARSE Syntax for not fix length word ... JCL & VSAM 7
No new posts Extracting Variable decimal numbers f... DFSORT/ICETOOL 17
No new posts COBOL -Linkage Section-Case Sensitive COBOL Programming 1
Search our Forums:

Back to Top