|
View previous topic :: View next topic
|
| Author |
Message |
Sengar.80
New User
Joined: 08 Jul 2011
Posts: 10
Location: INDIA
|
|
|
|
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 |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
why should we waste our time to explain why something happens when You do not follow the rules ?  |
|
| Back to top |
|
|
Sengar.80
New User
Joined: 08 Jul 2011
Posts: 10
Location: INDIA
|
|
|
|
Thats fine, I will just follow the rule of first putting the length and then the data.
Thanks. |
|
| Back to top |
|
|
Stefan
Active User
Joined: 12 Jan 2006
Posts: 110
Location: Germany
|
|
|
|
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 |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
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 |
|
|
Sengar.80
New User
Joined: 08 Jul 2011
Posts: 10
Location: INDIA
|
|
|
|
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 |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
| You still have not posted using the code tag. Hex would be nice also. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| 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 |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
Click the code box, then paste, then click the code box.
Check results with "preview" before submitting. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
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 |
|
|
Sengar.80
New User
Joined: 08 Jul 2011
Posts: 10
Location: INDIA
|
|
|
|
Thanks Bill for the explanation. Just adding the code result for the reference.
When the PARM-LEN coded in the linkage -
When PARM-LEN not coded in the linkage -
|
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
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 |
|
|
Sengar.80
New User
Joined: 08 Jul 2011
Posts: 10
Location: INDIA
|
|
|
|
| Thats correct Robert I understood, thanks to all of you. |
|
| Back to top |
|
|
|
|
