Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Behaviour of OCCURS DEPENDING ON
Goto page 1, 2  Next
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
cybertaurean

New User


Joined: 22 Dec 2008
Posts: 85
Location: US

PostPosted: Fri Sep 16, 2011 7:56 pm    Post subject: Behaviour of OCCURS DEPENDING ON
Reply with quote

Hi All,

Came across this interesting find related to OCCURS DEPENDING ON (still testing to find its various behaviours).

I have a data structure defined as -


Code:
01 WS-ARRAY-1.                                     
   05 WS-ARR0 OCCURS 1 TO 10 TIMES DEPENDING ON WS-H
                                   INDEXED BY WS-0.
      10 WS-ARR00                 PIC X(1).         
   05 WS-TEMP-1.                                   
      10 WS-TEMP-2                PIC X(1).         
      10 WS-TEMP-3.                                 
         15 WS-TEMP-4             PIC X(1).         


I passed a value of 06 through SYSIN in the module to WS-H (now the array would have 6 occurences) and filled them with '*' (code below)

Code:
MOVE '1' TO WS-TEMP-2
MOVE '2' TO WS-TEMP-4
PERFORM                                     
VARYING WS-0 FROM 1 BY 1                   
  UNTIL WS-0 > WS-H                         
        MOVE '*'          TO WS-ARR00 (WS-0)
END-PERFORM


On displaying the variables, I get the following result -

Code
Code:
DISPLAY 'VALUE AT CURRENT POSITION : ' WS-ARR00 (WS-0)
DISPLAY 'WS-ARRAY-1 : ' WS-ARRAY-1


Output:
Code:
VALUE AT CURRENT POSITION : 1
WS-ARRAY-1 : ******12


WS-0 being at the 7th position (the array has just 6) after the PERFORM VARYING probably referred to the variable WS-TEMP-2 which has a values of '1' (Strange or the obvious?)

Next I moved 10 to the DEPENDING variable WS-H and 'Q' to WS-ARR00 (10) -

Code:
Code:
MOVE 10 TO WS-H                   
MOVE 'Q' TO WS-ARR00 (10)         
DISPLAY 'WS-ARRAY-1 : ' WS-ARRAY-1
DISPLAY 'WS-TEMP-2 : ' WS-TEMP-2   
DISPLAY 'WS-TEMP-4 : ' WS-TEMP-4


Output:
Code:
WS-ARRAY-1 : ******12 Q
WS-TEMP-2 :           
WS-TEMP-4 :           


giving me the following result (the array actually went over and referred to the subsequent fields (:O). But that's not my issue, the fields lost their original values ('1' and '2') -

I went on to bringing the DEPENDING variable WS-H back to zero (some kind of INITIALIZATION huh? They don't allow INITIALIZE or REDEFINE on variable blocks. The compiler would complain) -

Code:
Code:
MOVE 0 TO WS-H                     
DISPLAY 'WS-ARRAY-1 : ' WS-ARRAY-1
DISPLAY 'WS-TEMP-2 : ' WS-TEMP-2   
DISPLAY 'WS-TEMP-4 : ' WS-TEMP-4


Output:
Code:
WS-ARRAY-1 : **
WS-TEMP-2 : * 
WS-TEMP-4 : * 


Can anyone tell me what happened above? I felt it should have been '12' since all the blocks allocated for the array are nullified and the parent variable reference should have printed out '12' (if they are there). OK! let's assume they are gone at this point since the array "overran" them.

Now we start the rebuild of the array from 1 to 11 occurrence. I am listing out the changes in values one by 1 in code/output sequences -

Code:
Code:
MOVE 1 TO WS-H                     
DISPLAY 'WS-ARRAY-1 : ' WS-ARRAY-1
DISPLAY 'WS-TEMP-2 : ' WS-TEMP-2   
DISPLAY 'WS-TEMP-4 : ' WS-TEMP-4


Output:
Code:
WS-ARRAY-1 : ***
WS-TEMP-2 : *   
WS-TEMP-4 : *   


Code:
Code:
MOVE 2 TO WS-H                     
DISPLAY 'WS-ARRAY-1 : ' WS-ARRAY-1
DISPLAY 'WS-TEMP-2 : ' WS-TEMP-2   
DISPLAY 'WS-TEMP-4 : ' WS-TEMP-4


Output:
Code:
WS-ARRAY-1 : ****
WS-TEMP-2 : *   
WS-TEMP-4 : *   


Code:
Code:
MOVE 3 TO WS-H                     
DISPLAY 'WS-ARRAY-1 : ' WS-ARRAY-1
DISPLAY 'WS-TEMP-2 : ' WS-TEMP-2   
DISPLAY 'WS-TEMP-4 : ' WS-TEMP-4


Output:
Code:
WS-ARRAY-1 : *****
WS-TEMP-2 : *     
WS-TEMP-4 : *     


Code:
Code:
MOVE 4 TO WS-H                     
DISPLAY 'WS-ARRAY-1 : ' WS-ARRAY-1
DISPLAY 'WS-TEMP-2 : ' WS-TEMP-2   
DISPLAY 'WS-TEMP-4 : ' WS-TEMP-4


Output:
Code:
WS-ARRAY-1 : ******
WS-TEMP-2 : *     
WS-TEMP-4 : *     


Code:
Code:
MOVE 5 TO WS-H                     
DISPLAY 'WS-ARRAY-1 : ' WS-ARRAY-1
DISPLAY 'WS-TEMP-2 : ' WS-TEMP-2   
DISPLAY 'WS-TEMP-4 : ' WS-TEMP-4


Output:
Code:
WS-ARRAY-1 : ******1
WS-TEMP-2 : *       
WS-TEMP-4 : 1       


Look above!!! The "lost" variables seem to be re-emerging (from bottom-up icon_smile.gif)!!!

Code:
Code:
MOVE 6 TO WS-H                     
DISPLAY 'WS-ARRAY-1 : ' WS-ARRAY-1
DISPLAY 'WS-TEMP-2 : ' WS-TEMP-2   
DISPLAY 'WS-TEMP-4 : ' WS-TEMP-4


Output:
Code:
WS-ARRAY-1 : ******12
WS-TEMP-2 : 1       
WS-TEMP-4 : 2       


Now we back to normal self. How things were at the start of the program... All variables with their correct values! Moving on...

Code:
Code:
MOVE 7 TO WS-H                     
DISPLAY 'WS-ARRAY-1 : ' WS-ARRAY-1
DISPLAY 'WS-TEMP-2 : ' WS-TEMP-2   
DISPLAY 'WS-TEMP-4 : ' WS-TEMP-4


Output:
Code:
WS-ARRAY-1 : ******12
WS-TEMP-2 : 2       
WS-TEMP-4 :         


They start disappearing again...

Code:
Code:
MOVE 8 TO WS-H                     
DISPLAY 'WS-ARRAY-1 : ' WS-ARRAY-1
DISPLAY 'WS-TEMP-2 : ' WS-TEMP-2   
DISPLAY 'WS-TEMP-4 : ' WS-TEMP-4


Output:
Code:
WS-ARRAY-1 : ******12 Q
WS-TEMP-2 :           
WS-TEMP-4 : Q         


Code:
Code:
MOVE 9 TO WS-H                     
DISPLAY 'WS-ARRAY-1 : ' WS-ARRAY-1
DISPLAY 'WS-TEMP-2 : ' WS-TEMP-2   
DISPLAY 'WS-TEMP-4 : ' WS-TEMP-4


Output:
Code:
WS-ARRAY-1 : ******12 Q
WS-TEMP-2 : Q         
WS-TEMP-4 :           


Code:
Code:
MOVE 10 TO WS-H                     
DISPLAY 'WS-ARRAY-1 : ' WS-ARRAY-1
DISPLAY 'WS-TEMP-2 : ' WS-TEMP-2   
DISPLAY 'WS-TEMP-4 : ' WS-TEMP-4


Output:
Code:
WS-ARRAY-1 : ******12 Q
WS-TEMP-2 :           
WS-TEMP-4 :           


Code:
Code:
MOVE 11 TO WS-H                     
DISPLAY 'WS-ARRAY-1 : ' WS-ARRAY-1
DISPLAY 'WS-TEMP-2 : ' WS-TEMP-2   
DISPLAY 'WS-TEMP-4 : ' WS-TEMP-4


Output:
Code:
WS-ARRAY-1 : ******12 Q
WS-TEMP-2 :           
WS-TEMP-4 :           


Given the limitations on the array 'OCCURS 1 TO 10 TIMES', I'm surprised how the last case even worked?

Could someone take a look and explain how the allocation happened in the above execution (Note: All these are from a single run of a program)

Regards,
C.T.
Back to top
View user's profile Send private message

dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Fri Sep 16, 2011 8:16 pm    Post subject:
Reply with quote

no need to look.

occurs depending on only has an affect when you
  • issue a move from the table to another area
  • SEARCH ALL
  • SEARCH


all you have managed to prove is that SSRANGE(OFF) is in effect
and when you exceeded 10 occurances, you over-wrote storage following the table.

and this gobbelty-gook that you provided as code,
is only snippets,
and there is no way to follow the execution.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Fri Sep 16, 2011 8:20 pm    Post subject:
Reply with quote

Without studying your examples in detail, there are a couple of things you need to be aware of:

1. When using WORKING-STORAGE, a table defined with OCCURS DEPENDING ON will use exactly the same amount of memory as a table defined just with OCCURS. COBOL allocates memory for the table based on the maximum number of occurrences, so the memory is always there.

2. Unless you have the SSRANGE option turned on while doing the compile, COBOL does not check nor otherwise limit your table subscripts in any way.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Fri Sep 16, 2011 9:05 pm    Post subject: Reply to: Behaviour of OCCURS DEPENDING ON
Reply with quote

Consult the manuals.

There was also a topic a few weeks ago here, try to find that. Some file layout with ODO but minus the value. Also one to pick out CITY/STATE/ZIP from address lines. Read, try to understand with aid of manual, let us know any questions you have.

There is also some ODO in the Junk Buster :-)

Although you can define the data like that, it is your responsibility, not that of the compiler, to preserve the correct values of fields after the occurs depending on but not subordinate to it.

When you put 11 in your odo, and you don't have SSRANGE, you poked yourself into the next piece of storage, as has been said.
Back to top
View user's profile Send private message
cybertaurean

New User


Joined: 22 Dec 2008
Posts: 85
Location: US

PostPosted: Fri Sep 16, 2011 10:33 pm    Post subject:
Reply with quote

@dbz: that's the entire code read one after the another. there is no additional stuff. i had written this "gobblety-gook" to test the behavior of OCCURS DEPENDING ON. It's better to explain it step by step rather than trying to attach the entire (doesn't make sense in this case, since it's the entire code shown here)

and about the SSRANGE option been turned off, I do understand. However there is a catch when it comes to overwriting the subsequent working storage.... It doesn't if the subsequent working storage starts under a new level... see below -

Declaration (the one that would get overwritten):

Code:
01 WS-ARRAY-1.                                     
   05 WS-ARR0 OCCURS 1 TO 10 TIMES DEPENDING ON WS-H
                                   INDEXED BY WS-0.
      10 WS-ARR00                 PIC X(1).         
   05 WS-TEMP-1.                                   
      10 WS-TEMP-2                PIC X(1).         
      10 WS-TEMP-3.                                 
         15 WS-TEMP-4             PIC X(1).



Declaration (the one the would not get overwritten):

Code:
01 WS-ARRAY-1.                                     
   05 WS-ARR0 OCCURS 1 TO 10 TIMES DEPENDING ON WS-H
                                   INDEXED BY WS-0.
      10 WS-ARR00                 PIC X(1).         
01 WS-TEMP-1.                                   
   05 WS-TEMP-2                PIC X(1).         
   05 WS-TEMP-3.                                 
      10 WS-TEMP-4             PIC X(1).


In the latter, a new level was started and believe me (I have tested it), it will not go over to the subsequent working storage.

@robert: the real difference comes into picture when you split the data into chunks using LENGTH OF. This helps a lot in cases where you have variable amount of data involved. One example to explain the case (which was used in splitting and transmitting data as segments to MQ) -

var_block <-- some block that contains variable data driven by another DEPENDING ON variable... say i

now LENGTH OF used on var_block with i = 10 and i = 20 will give different lengths.

len = LENGTH OF var_block

Assuming length of one segment = 32K = seg_max_len

divide len by seg_max_len giving msg_segs remainder

if remainder > 0
add +1 to msg_segs

And it's been a treat to watch the code perform so well... I had a structure that would take around 43 segments in case of a structure without DEPENDING ON and what shall I say, it reduced to 1 - 2 segments with OCCURS DEPENDING ON. I agree that the allocation is done with the maximum, but if you couple that with the above logic, it does real good.

I will definitely look into the SSRANGE part (somehow that missed mind icon_sad.gif

@Bill: Been consulting the manuals always icon_smile.gif and will do that again. Will check with friends, check online, do whatever it takes...

about the preserving data part, I found a workaround by introducing a new level for the subsequent variables (like mentioned above).

Just wanted to know how this allocation gets done.

Thanks all for your time... Waiting for more coders to take a peek

Regards,
C.T.
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Fri Sep 16, 2011 10:57 pm    Post subject:
Reply with quote

Hello,

Suggest you look at the addresses/displacements of the data that is shown by the compile.
Back to top
View user's profile Send private message
cybertaurean

New User


Joined: 22 Dec 2008
Posts: 85
Location: US

PostPosted: Fri Sep 16, 2011 11:00 pm    Post subject:
Reply with quote

@dick: sure... let me try that! thanks!!! icon_smile.gif
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Fri Sep 16, 2011 11:04 pm    Post subject:
Reply with quote

Quote:
However there is a catch when it comes to overwriting the subsequent working storage.... It doesn't if the subsequent working storage starts under a new level.
This merely means you have a LOT of reading ahead of you -- start with page 1 of the COBOL Language Refernce manual and continue through the appendices; then start with page 1 of the COBOL Programming Guide manual and continue through the appendices. Both manuals can be found via the Manuals link at the top of this page. To show you just how wrong you are, here's the code:
Code:
       77  WS-H                        PIC S9(02) VALUE 10.
       01  WS-ARRAY-1.
           05  WS-ARR0                 OCCURS 1 TO 10 TIMES
                                       DEPENDING ON WS-H
                                       INDEXED BY WS-0.
               10 WS-ARR00             PIC X(1).
       01  WS-TEMP-1.
           05  WS-TEMP-2               PIC X(1) VALUE 'Y'.
           05  WS-TEMP-3.
               10 WS-TEMP-4            PIC X(1) VALUE 'Z'.
       01  WS-END                      PIC X(08) VALUE 'END'.
       PROCEDURE DIVISION                  .
       PARA-1.
           DISPLAY 'INITIAL'.
           DISPLAY 'WS-H       >' WS-H       '<'.
           DISPLAY 'WS-ARRAY-1 >' WS-ARRAY-1 '<'.
           DISPLAY 'WS-TEMP-1  >' WS-TEMP-1  '<'.
           DISPLAY 'WS-END     >' WS-END     '<'.

           PERFORM
               VARYING WS-0 FROM 1 BY 1
                 UNTIL WS-0 > 23
               MOVE 'A'                TO  WS-ARR00 (WS-0)
           END-PERFORM.

           DISPLAY 'AFTER MOVES'.
           DISPLAY 'WS-H       >' WS-H       '<'.
           DISPLAY 'WS-ARRAY-1 >' WS-ARRAY-1 '<'.
           DISPLAY 'WS-TEMP-1  >' WS-TEMP-1  '<'.
           DISPLAY 'WS-END     >' WS-END     '<'.
which produces output of
Code:
 INITIAL
 WS-H       >1{<
 WS-ARRAY-1 >..........<
 WS-TEMP-1  >YZ<
 WS-END     >END     <
 AFTER MOVES
 WS-H       >1{<
 WS-ARRAY-1 >AAAAAAAAAA<
 WS-TEMP-1  >AA<
 WS-END     >END     <
When you can explain why your code does not overlay WS-TEMP-1 and my code does, you will have learned something.
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Fri Sep 16, 2011 11:15 pm    Post subject:
Reply with quote

i will only bother to say,
learn about memory allocation for level-01 vs level-02 thru level-49.

learn that and you will not be tempted make yet another post
which shows your lack of knowledge.

and stop trying to learn basics thru observation.
fundamentals need to be learned by understanding everything.
observing causes you to make to assumptions.
Back to top
View user's profile Send private message
cybertaurean

New User


Joined: 22 Dec 2008
Posts: 85
Location: US

PostPosted: Fri Sep 16, 2011 11:26 pm    Post subject:
Reply with quote

@robert: In your example, why didn't the remaining 13 bytes not overwrite WS-END?

@dbz: tried searching for memory allocation for level-01 v/s level-02 thru level-49. Any links?
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Fri Sep 16, 2011 11:38 pm    Post subject:
Reply with quote

From section 5.3.16 of the COBOL Language Reference manual, available via the Manuals link at the top of THIS page:
Quote:
In the file section, the compiler assumes that all level-01 records that contain SYNCHRONIZED items are aligned on doubleword boundaries in the buffer. You must provide the necessary slack bytes between records to ensure alignment when there are multiple records in a block.

In the working-storage section, the compiler aligns all level-01 entries on a doubleword boundary.

For the purposes of aligning binary items in the linkage section, all level-01 items are assumed to begin on doubleword boundaries. Therefore, if you issue a CALL statement, such operands of any USING phrase within it must be aligned correspondingly.
Since WS-ARRAY-1 starts on a doubleword boundary, and it is 10 bytes long, there are 6 slack bytes between the last byte of WS-ARRAY-1 and the first byte of WS-TEMP-1 -- which must begin on a doubleword boundary since it is a level 01 variable. Since WS-TEMP-1 is 2 bytes long, there are also 6 slack bytes between the last byte of WS-TEMP-1 and the first byte of WS-END. 10 bytes plus 6 slack bytes plus 2 bytes plus 6 slack bytes is 24 bytes -- hence the memory overlay stops before the beginning of WS-END and it is not affected. This is what I meant when I said you need to learn something -- the same thing Dick has said. If my loop had run to 500 or 5000 instead of 23, I probably would have gotten a sytem abend -- S0C1 or S0C4 most likely -- once the overlay started wiping out program instructions.
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Fri Sep 16, 2011 11:40 pm    Post subject:
Reply with quote

Hello,

Quote:
@robert: In your example, why didn't the remaining 13 bytes not overwrite WS-END?
To learn about this was your "assignment". . .

Quote:
@dbz: tried searching for memory allocation for level-01 v/s level-02 thru level-49. Any links?
This (and very much more) is in the documentation.

Surely, you cannot have actually read these so quickly. . .
Back to top
View user's profile Send private message
cybertaurean

New User


Joined: 22 Dec 2008
Posts: 85
Location: US

PostPosted: Fri Sep 16, 2011 11:59 pm    Post subject:
Reply with quote

@robert and dick: thanks so much! let me dig in to this section...
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Sat Sep 17, 2011 12:06 am    Post subject:
Reply with quote

cybertaurean wrote:
@robert and dick: thanks so much! let me dig in to this section...


guess he told me.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Sat Sep 17, 2011 12:07 am    Post subject:
Reply with quote

Dick I guess 30-odd years of COBOL experience don't count for much these days, does it? icon_biggrin.gif
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Sat Sep 17, 2011 12:18 am    Post subject:
Reply with quote

not when the info is delivered sans all the sugar and honey coating the pc (politically correct) generation expects.

(which obviously tends to motivate me to add more lemon the next time.)
Back to top
View user's profile Send private message
cybertaurean

New User


Joined: 22 Dec 2008
Posts: 85
Location: US

PostPosted: Sat Sep 17, 2011 12:19 am    Post subject:
Reply with quote

@dbz: lol... I thanked you too... You have any reason to think you wouldn't be thanked ;)

@robert: only change is constant icon_biggrin.gif... and 30 years of COBOL!!! WOW!!!
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Sat Sep 17, 2011 4:21 am    Post subject:
Reply with quote

dbzTHEdinosauer wrote:
[...]
and stop trying to learn basics thru observation.
fundamentals need to be learned by understanding everything.
observing causes you to make to assumptions.


Cybertaurean,

You have to really take this to heart. Take time to understand how the assumption you made was wrong, and how all the time you were observing the wrong thing.

You started off setting your ODO number to 6. Then you moved "1" and "2" to your fields following the ODO. You displayed the "array" and the two fields. You then tried with 7 for the ODO number, and started to "loose" the data. Yet all the time, the 1 and the 2 are staring at you from the screen, in the display of array.

The only thing that changes for those following fields is the start position of those following fields. The data stays slap-bang where you put it originally. That is why you "see" it again when you set the length of the ODO back to 6.

You "assumed" that when you displayed the other fields, they should show you the value. They didn't, so you "assumed" the data was somehow lost. If you cut the assumptions, complete the observation (there's the damn stuff, why's that) and consult the manual, you get the answers.

To preserve the value of the 1 and 2, you have to

Code:
Save values of all fields which are part of the same 01 and which follow (ie are not subordinate to) the ODO.
Change the value of the ODO number.
Replace the values of the fields you saved.


If you add that logic to your code, you will retain the "1" and "2" values where you think they should be and not just leave then where you last put them.

I didn't know LENGTH OF would give different values for an ODO group. Why not? Because I already know the length, it is the ODO number multiplied by the length of the field which is occurring. In plaace of already knowing the length, you have put LENGTH OF through some excrutiating stuff to get what you already know.

Again you missed the "obvious". This time it worked anyway. But you then use the assumption you have made about this to somehow support what you have been saying about your new discovery.

There happen to have been a number of discussions ODO. In this forum. It is worth your while to locate them and understand them. Everything you have done above is covered, even with the ODO length as zero, your remaining question from above. Try to get to the stage where you can explain it to us.

If you want to "see" the slack bytes, look at the DMAP (notice the offsets), look at a dump, or use the Junk Buster.
Back to top
View user's profile Send private message
cybertaurean

New User


Joined: 22 Dec 2008
Posts: 85
Location: US

PostPosted: Sat Sep 17, 2011 6:53 pm    Post subject:
Reply with quote

That's a lot of information, Bill. And I'm really * x (Lim x-> inf.) grateful for that. Gotta learn a lot from the Manual.

PS: I guess they have Redbook versions for the manual, r8? Let me check icon_smile.gif. Thanks again!!!
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Sun Sep 18, 2011 9:55 am    Post subject:
Reply with quote

Hello,

At the top of the page is a link to "IBM Manuals. At the top of the list are COBOL manuals. Use the Language Reference and Programming Guide for your release of the compiler.

Suggest you bookmark or download the manuals that you will use regularly.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts $AJ behaviour when $PXEQ is in effect. vasanthz JCL & VSAM 2 Thu Feb 18, 2016 3:51 am
No new posts Add Trailing Zeroes depending upon th... Rohit Umarjikar DFSORT/ICETOOL 3 Fri Oct 23, 2015 1:47 am
No new posts Doubt on GETMAIN, FREEMAIN behaviour Arunkumar Chandrasekaran CICS 3 Sun Aug 30, 2015 9:22 pm
No new posts Multiple OCCURS depending on in same ... muralirajansm COBOL Programming 6 Fri Aug 21, 2015 4:23 pm
No new posts 3-D Table with nested DEPENDING ON Cl... VivekKhanna COBOL Programming 5 Sat Aug 08, 2015 11:18 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us