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
 

 

COBOL Parmlist and Associated Linkage definitions

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Fri Dec 20, 2013 9:43 pm    Post subject: COBOL Parmlist and Associated Linkage definitions
Reply with quote

OK, I have a dumb question. I'm back doing applications and ran across a COBOL sub-program, with a PROCEDURE DIVISION USING, specifying several dozen parameters.

My question is this: Do the corresponding LINKAGE SECTION 01 levels need to be in the same order as specified in the USING?

FWIW, this is not an issue in Assembler and never has been. icon_smile.gif

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

don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 641
Location: Whitby, ON, Canada

PostPosted: Fri Dec 20, 2013 9:54 pm    Post subject:
Reply with quote

The order of the 01 levels in the LINKAGE section is unimportant.

By convention, they are usually coded in the same order, but it is is not necessary.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1738
Location: Bloomington, IL

PostPosted: Fri Dec 20, 2013 9:54 pm    Post subject:
Reply with quote

I would say "Yes". The fine manual states:
Quote:
The order of appearance of USING identifiers in both calling and called subprograms, or invoking methods or programs and invoked methods, determines the correspondence of single sets of data available to both. The correspondence is positional and not by name. For calling and called subprograms, corresponding identifiers must contain the same number of bytes although their data descriptions need not be the same.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Fri Dec 20, 2013 10:00 pm    Post subject: Reply to: COBOL Parmlist and Associated Linkage definitions
Reply with quote

Nope. Order is not relevant in the LINKAGE SECTION.

Many people think it is, and I've even had to entirely reverse the order of the LINKAGE SECTION definitions (and pocket a tenner) for one of these people.

Simple one-for-one from CALL ... USING ... to PROCEDURE DIVISION USING ...

Order in Linkage or Working-Storage or anywhere else is 100% irrelevant.
Back to top
View user's profile Send private message
Nic Clouston

Global Moderator


Joined: 10 May 2007
Posts: 1712
Location: UK

PostPosted: Fri Dec 20, 2013 10:02 pm    Post subject:
Reply with quote

No. The declarations could be in Working-storage section if they have not been passed down from up on high. The only sequence that matters is on the CALL statement and, in the called program, on the PROCEDURE USING statement where they must be in sequence.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Fri Dec 20, 2013 10:15 pm    Post subject: Reply to: COBOL Parmlist and Associated Linkage definitions
Reply with quote

It makes sense to me that the order is irrelevant, although colleagues here insist the orders must match.

Because they call the shots and I'm just another larvae in the pool, I'll reluctantly comply. icon_confused.gif

Regards,
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Fri Dec 20, 2013 10:17 pm    Post subject: Reply to: COBOL Parmlist and Associated Linkage definitions
Reply with quote

Don, it is not so much "by convention" as "by what people believe and are prepared to stick to as an article of faith until faced with a ridiculous level of proof and even then maybe not". In my experience.

Code:
WORKING-STORAGE SECTION. (of Caller)
01  PROGA PIC X VALUE "Z".
01  PROGB PIC X VALUE "Y".
01  PROGC PIC X VALUE "Q".


CALL "VAR" USING PROGA, PROGB, PROGC

LINKAGE SECTION. (of Called)
01  PROGC PIC X.
01  PROGA PIC X.
01  PROGB PIC X.

PROCEDURE DIVISION USING PROGB, PROGC, PROGA.


What is known as PROGA in the Caller becomes known as PROGB in the Called. B to C. C to A. They are not matched on name.

If the seventh item on the USING of the CALL is PRODMST-DELETE-FG and the seventh item on the USING of the PROCEDURE DIVISION is APPLE-PEACH-AND-PUMPKIN they are looking at the same storage, wherever and however defined.

This, from Akatsukami's manual quote, is a bald-faced lie (by the manual's contributors):

Quote:
For calling and called subprograms, corresponding identifiers must contain the same number of bytes although their data descriptions need not be the same.


Perhaps should normally would be OK. Can't be must as nothing enforces it. Must "if that's OK with you" cuts no M.... doesn't work.

* program names and data-names obfuscated for additional explicative purposes
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 Dec 20, 2013 11:10 pm    Post subject:
Reply with quote

Hello,

There may be confusion as to just What has to be in order.

The order of the fields in the USING statements needs to be in order.

It does not matter where the fields are in the WS or Linkage sections.

The call and the prodecure statements need the values in the same sequence.

Hopefully, i've not muddied the water . . .
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


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

PostPosted: Sat Dec 21, 2013 9:27 pm    Post subject:
Reply with quote

Akatsukami's manual quote is correct with the following qualification.

if the CALLing linkage area is 10 bytes and the CALLed program defines it as 20,
and the CALLed program references any of the last 10 bytes,
it can cause a SOC4, but not always.
for example if the 10 bytes in the CALLing program are the last 10 bytes of the DATA DIV, then i would expect a SOC4.

there are compiler options (i forget which)
that can enforce the length of linkage areas in the CALLed program.
turn them off, and you can reference the first byte in the CALLing program,
pass the area as 1 byte to the CALLed program,
define the linkage as 1000 bytes in the CALLed,
and thus reference all the 1000 bytes in the CALLing program in the CALLed program.

if there are only 900 bytes in the CALLing program's DATA Div and you
reference any of the last 100 in the CALLed program,
you will have a SOC4, regardless of the compiler options.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Sat Dec 21, 2013 11:03 pm    Post subject: Reply to: COBOL Parmlist and Associated Linkage definitions
Reply with quote

Quote:
For calling and called subprograms, corresponding identifiers must contain the same number of bytes although their data descriptions need not be the same.

Code:

WORKING-STORAGE SECTION.
01  LUMP PIC X.

CALL "A" USING LUMP


LINKAGE SECTION.

01  L-LUMP PIC X(100,000,000).

PROCEDURE DIVISION USING L-LUMP.

CALL "NEXTPRG" USING L-LUMP


This is utterly, absolutely and 100% guaranteed OK in every single circumstance. It is not good practice, and gives no benefit in any way (and has a performance penalty) but it will compile and run in all circumstances.

TBC...
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Sun Dec 22, 2013 6:57 am    Post subject: Reply to: COBOL Parmlist and Associated Linkage definitions
Reply with quote

If a piece of data has had storage "obtained" for it (GETMAIN, or CEEGHST for instance) then exceeding the length of the storage acquired may well get a S0C4 (I don't know if it is possible to "abut" storage already "belonging"). The S0C4 occurs as soon as you access storage which does not "belong" to your run-unit.

With items from the WORKING-STORAGE of a COBOL program, things are the same, except that those items are part of a big chunk of storage which has been allocated and is "safe" to use (as in S0C4-free).

To demonstrate this, and estimate the extent of "safe" storage for cocked-up use, here's a program, compiled with NOSSRANGE, with a subscript deliberately running wild, looking byte-per-byte from the start of a storage area.

The storage area is either the first byte of the W-S of the program, or the byte "passed" from a CALLing program.

Code:
       ID DIVISION.
       PROGRAM-ID. "WHATS0C4".
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  JUST-FOR-S0C4                       PIC X.
       01  BYTES-FROM-START-OF-STORAGE  COMP-5 PIC 9(9).
       01  ADDRESS-OF-2ND-LINKAGE       USAGE POINTER.
       01  FILLER
             REDEFINES
               ADDRESS-OF-2ND-LINKAGE.
           05  FILLER                   COMP-5 PIC 9(9).
               88  NO-LINKAGE                  VALUE ZERO.
       01  W-WHEN-COMPILED                     PIC X(8)BX(8).
       LINKAGE SECTION.
       01  FIRST-BYTE-OF-SOME-DATA.
           05  FILLER OCCURS 1.
               10  A-BYTE                      PIC X.
                                                                   
       01  L-BYTE PIC X.
           88  EXPECTED-LINKAGE-VALUE          VALUE "A".
       01  L-DUMMY-FOR-OS                      PIC X.
       PROCEDURE DIVISION               USING
                                            L-DUMMY-FOR-OS
                                            L-BYTE
                                        .
                                                                   
           MOVE WHEN-COMPILED           TO W-WHEN-COMPILED
           DISPLAY "WHATS0C4 " W-WHEN-COMPILED
                                                                   
           SET ADDRESS-OF-2ND-LINKAGE   TO ADDRESS OF L-BYTE
                                                                   
           IF NO-LINKAGE
               SET ADDRESS OF FIRST-BYTE-OF-SOME-DATA
                                        TO ADDRESS OF JUST-FOR-S0C4
               DISPLAY "STAND-ALONE"
           ELSE
              SET ADDRESS OF FIRST-BYTE-OF-SOME-DATA
                                       TO ADDRESS OF L-BYTE
              IF EXPECTED-LINKAGE-VALUE
                  DISPLAY "CALLED"
              ELSE
                  CALL "FRED"
              END-IF
          END-IF
                                                           
          PERFORM
            VARYING BYTES-FROM-START-OF-STORAGE
            FROM 1
              BY 1
            UNTIL BYTES-FROM-START-OF-STORAGE
                   GREATER THAN 999999999
              MOVE A-BYTE ( BYTES-FROM-START-OF-STORAGE )
                                      TO JUST-FOR-S0C4
              DISPLAY BYTES-FROM-START-OF-STORAGE
          END-PERFORM
                                                           
          GOBACK
          .


The program is either run as EXEC PGM=, or it is run as a CALLed program. For fun I CALLed it with two parameters, so it would use the data from the CALLing program, and with only one, mimicing the "CALL" from z/OS.
Code:

EXEC PGM= fails after                   0000048944
CALL with two items on USING fails afer 0000057136
CALL with one item on USING fails after 0000056944


It would seem that you can "safely" go some 48,000 bytes over the end of the storage which has been "passed" (no storage is passed, only addresses) and still not get a S0C4 if the data is in the WORKING-STORAGE of a COBOL program.

It would also seem that you get a slightly different amount of storage in different situations.

On the one hand this is of course bad. If something is that screwed up, it would be nice if it failed. On the other, the fact that COBOL in the language specification does not check for size (let alone type) of fields reduces the overhead. We test programs, so there are things we can live without the compiler giving us a helping hand on, if it avoids being processed billions of times once the program is in Prodcution.

So, check parameters. Check order on CALL ... USING matches order on PROCEDURE DIVISION USING. Check you have both USINGs. If there are any mismatches amongst any of that, the compiler will give no help at all through any sort of diagnostic message in any circumstance.

Going "10 bytes over" is not going to get a S0C4 for COBOL WORKING-STORAGE data "passed" through linkage.
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
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
This topic is locked: you cannot edit posts or make replies. RANDOM Function in COBOL swapnil781 COBOL Programming 2 Tue Nov 15, 2016 6:17 pm
No new posts Regarding COBOL Stored Procedure opti... selvamsrinivasan85 DB2 4 Fri Nov 04, 2016 8:57 pm
No new posts COBOL Version 6.1 Virendra Shambharkar COBOL Programming 5 Tue Nov 01, 2016 11:24 am
No new posts Cobol list of programs being called biswajit.dattagupta COBOL Programming 5 Tue Nov 01, 2016 2:10 am
No new posts Can sending 5 MB data between cobol p... Kevin Vaz CICS 12 Tue Oct 18, 2016 4:50 pm


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