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
 

 

PARM length in linkage section

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
Sengar.80

New User


Joined: 08 Jul 2011
Posts: 10
Location: INDIA

PostPosted: Tue Jul 26, 2011 12:16 pm    Post subject: PARM length in linkage section
Reply with quote

Hi,

I would like to understand the parm length concept in the linkage section.

I know the first two bytes are used to store the length of the data passed from the JCL to COBOL program through PARM.

I have defined my linkage section as below

LINKAGE SECTION.
01 WS-PARM.
05 PARM-LEN PIC 9(4) COMP.
05 PARM-DATA PIC X(8).

In the procedure division, if I display WS-PARM and PARM-LEN, it will have value as below
CURRENCY
0008

So, first two bytes are meant for length followed by the data.

If I do not code the length in the linkage, I get the value for WS-PARM as below

CURREN

I would like to why the data got truncated at the end. Already the first two bytes are used for storing the length of the data and then followed by the PARM-DATA.

Also, I would like to know if I code the PARM-LEN after PARM-DATA as below

LINKAGE SECTION.
01 WS-PARM.
05 PARM-DATA PIC X(8).
05 PARM-LEN PIC 9(4) COMP.

In the procedure division, if I display WS-PARM and PARM-LEN, it will have value as below

CURRENCY
2050

I would like to understand how it has given my 2050 as length?

Thanks.
Back to top
View user's profile Send private message

enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10201
Location: italy

PostPosted: Tue Jul 26, 2011 12:19 pm    Post subject: Reply to: PARM length in linkage section
Reply with quote

why should we waste our time to explain why something happens when You do not follow the rules ? icon_evil.gif
Back to top
View user's profile Send private message
Sengar.80

New User


Joined: 08 Jul 2011
Posts: 10
Location: INDIA

PostPosted: Tue Jul 26, 2011 12:39 pm    Post subject:
Reply with quote

Thats fine, I will just follow the rule of first putting the length and then the data.

Thanks.
Back to top
View user's profile Send private message
Stefan

Active User


Joined: 12 Jan 2006
Posts: 110
Location: Germany

PostPosted: Tue Jul 26, 2011 1:45 pm    Post subject:
Reply with quote

Obviously you have a general misunderstanding of how data is passed between programs.

So I strongly recommend reading the general chapters of the COBOL Programming Guide and similar documents.

Here are a few aspects you should be aware of:
    - The COBOL Working Storage Section defines variables which are "owned" by your program (generally spoken).
    - The COBOL Linkage Section contains those variables which your program provides for looking at data which a calling program passes to it.
    - If you specify a value in the PARM field of an EXEC card, the operating system calls your program and passes this value to it.
    - When you have coded PROCEDURE DIVISION USING <...> these specified variables must be defined in the Linkage Section and are being used to receive the data passed by the caller (in this case the operating system itself).
    - You cannot change the way the data is getting passed by changing your definitions in the Linkage Section !!!
    - The data is always passed preceeded by a two-byte length field in binary format specifying the length of the actual data.
    - This rule does only apply when you receive data passed via the PARM field of any JCL. When you expect data being passed by another main program, the length field is not automatically generated. In this case you have to ensure data integrity by yourself.


I know that these explanations are not 100% correct, but I think it's OK for a newbee to get motivated.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


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

PostPosted: Tue Jul 26, 2011 4:00 pm    Post subject:
Reply with quote

You got CURREN instead of CURRENCY when you didn't put the length because the length is still there -- what you actually got was the first two bytes are now X'0008' instead of CU, with the rest of the data shifted 2 bytes to the right. Since your length is 8, that means the CY got shifted out of the variable.

The 2050 would be, essentially, random data -- you might run the same program a number of times and get the same values, then run it one more time and get totally different data.

If you are not willing to follow the rules as COBOL presents them in the Language Reference and Programming Guide manuals, please find another career before you damage production data.
Back to top
View user's profile Send private message
Phrzby Phil

Active Member


Joined: 31 Oct 2006
Posts: 961
Location: Richmond, Virginia

PostPosted: Tue Jul 26, 2011 5:42 pm    Post subject:
Reply with quote

I shall diverge slightly from my esteemed colleagues.

Breaking the rules to see what happens is, I think, a good way to learn, so long as you cannot damage anything.

In this case, though, you did not post your results using the code tag, so whereas it looks like you got "CURREN", I am guessing that there are actually two spaces in from of the "C", since the (halfword) length (which is really put there by the system (which is why you need to code for it)), when viewed as display characters, cannot be seen because that hex value does not correspond to any display characters.

So, if you are going to experiment, I think that's great, but be sure to observe and measure rigorously.
Back to top
View user's profile Send private message
Sengar.80

New User


Joined: 08 Jul 2011
Posts: 10
Location: INDIA

PostPosted: Tue Jul 26, 2011 6:49 pm    Post subject:
Reply with quote

Hi,

After seeing the reply from Phil, I realised that the I did not post the code tag which might be giving the wrong understanding to all.

The result came as : CURRENCY
0008

So, the first two bytes are occupied for length and then the data. But if I do not code the length,

The result came as : CURREN

Here, I got first two bytes as blank and last two bytes also blank.

My purpose was not to damage any production data but got curious to see the result that first two bytes were blank followed by data which actually got truncated with two bytes (last two bytes seems to be blank).

Thanks.
Back to top
View user's profile Send private message
Phrzby Phil

Active Member


Joined: 31 Oct 2006
Posts: 961
Location: Richmond, Virginia

PostPosted: Tue Jul 26, 2011 6:52 pm    Post subject:
Reply with quote

You still have not posted using the code tag. Hex would be nice also.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


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

PostPosted: Tue Jul 26, 2011 6:59 pm    Post subject:
Reply with quote

Quote:
The result came as : CURREN

Here, I got first two bytes as blank and last two bytes also blank.
How do you know this? Nothing you have posted indicates that you have looked at the HEXADECIMAL values for those bytes, and since there are many non-printing characters in EBCDIC that look like spaces when printed, your statement needs proof or retraction.
Back to top
View user's profile Send private message
Phrzby Phil

Active Member


Joined: 31 Oct 2006
Posts: 961
Location: Richmond, Virginia

PostPosted: Tue Jul 26, 2011 7:26 pm    Post subject:
Reply with quote

Click the code box, then paste, then click the code box.

Check results with "preview" before submitting.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7223

PostPosted: Tue Jul 26, 2011 7:29 pm    Post subject: Reply to: PARM length in linkage section
Reply with quote

Like Ph.. Phil, I think a little experimentation can aid your comprehension. As he says. it should be rigorous.

Code:
LINKAGE SECTION.
01  WS-PARM.
    05 PARM-DATA PIC X(8).
    05 PARM-LEN PIC 9(4) COMP.


I would then

Code:
DISPLAY ">" PARM-DATA "<"
DISPLAY ">" PARM-LEN "<"


OK, I wouldn't, but it is what you have done except for the ">" and "<". The purpose of these is to exactly delimit the field you are displaying. Everything "inside" the less than/greater than is actually the value being displayed.

In this case, when you look at the value in HEX, you would see 0008 followed immediately by the first part of CURRENCY.

The CY end up in the PARM-LEN. Which is binary. So, look at the hex value for CY, convert it from base 16 to base 10. Still not the right answer? Because it is also -ve.

So, define

Code:
01  W-FIELD-TO-DISPLAY-LENGTH PIC ZZZZ9-.


Move PARM-LEN to that, and display that.

Then go back to your base 16, realise it is negative in two's complement, and verify that it equals the value displayed.

Code:
LINKAGE SECTION.
01  WS-PARM.
    05 PARM-LEN PIC 9(4) COMP.
    05  LS-BINARY-OF-TWO-KEYBOARD-VALUES COMP PIC S9(4).


If you code like the above, with the move of LS-BINARY... to the ZZZZ9- field, you can run with different pairs of values available from the keyboard and practice all the hex arithmetic to get familiar with it.
Back to top
View user's profile Send private message
Sengar.80

New User


Joined: 08 Jul 2011
Posts: 10
Location: INDIA

PostPosted: Wed Jul 27, 2011 12:04 pm    Post subject:
Reply with quote

Thanks Bill for the explanation. Just adding the code result for the reference.

When the PARM-LEN coded in the linkage -

Code:
  CURRENCY
0008


When PARM-LEN not coded in the linkage -

Code:
  CURREN
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


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

PostPosted: Wed Jul 27, 2011 5:18 pm    Post subject:
Reply with quote

Code:
Code:
      LINKAGE SECTION.
      01  LS-PARMS.
          05  LS-VALUE.
              10  LS-PARM             PIC X(08).
      PROCEDURE DIVISION USING LS-PARMS   .
      PARA-1.
          DISPLAY 'LS PARM >' LS-VALUE '<'.
run with JCL of .
Code:
//STEP1    EXEC PGM=MF0192,REGION=0M,PARM='CURRENCY'
//SYSPRINT DD   SYSOUT=*
//STEPLIB  DD   DISP=SHR,DSN=TTSSRS0.COMPILES.LOADLIB
//
produces results of
Code:
 LS PARM >..CURREN<
4DE4DCDD4600CEDDCD4
032071940E08349955C
Notice that the length of X'0008' is still there -- and that is why the CY is missing, exactly as my post from Tuesday stated.
Back to top
View user's profile Send private message
Sengar.80

New User


Joined: 08 Jul 2011
Posts: 10
Location: INDIA

PostPosted: Wed Jul 27, 2011 9:39 pm    Post subject:
Reply with quote

Thats correct Robert I understood, thanks to all of you.
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
No new posts SQZ pipe delimited file with 1 column... Rick Silvers DFSORT/ICETOOL 2 Sun Nov 06, 2016 8:11 pm
No new posts Joinkeys operation when key1 and key2... Susanta DFSORT/ICETOOL 5 Wed Nov 02, 2016 5:35 pm
No new posts Format to pipe delimited with variabl... pshongal SYNCSORT 6 Wed Sep 14, 2016 2:48 pm
No new posts Using 'parm' to vary SORTOUT record v... Sysaron DFSORT/ICETOOL 13 Wed Sep 07, 2016 9:24 pm
No new posts Copy a particular column based on PAR... brindhamohan DFSORT/ICETOOL 5 Wed May 11, 2016 8:49 am


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