View previous topic :: View next topic
|
Author |
Message |
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
chatterjesis wrote: |
Hi Don,
By wrong version what do you mean?
is it related to my cobol version?or something else.
I have pasted exactly what I am executing.....not sure why its not working?
what do you suggest now? |
I was questioning your results because not all of your DISPLAY output is consistent with the code you provided. In the latest example you gave us, PARM-LENGTH is shown as 00010 (5 digits rather than 4). The other reason I am questioning it is that two of us have now replicated your code (as you provided it) and we are not getting the same results. It is very unlikely that your mainframe is behaving differently than ours, which makes human error much more likely.
I would also like to suggest that when you show us your DISPLAY output, you also show it in HEX format. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Show us JCL, code, and output all from one run -- so we know exactly what you did and the results you got. |
|
Back to top |
|
|
Jose Mateo
Active User
Joined: 29 Oct 2010 Posts: 121 Location: Puerto Rico
|
|
|
|
Good day to all,
Put a 'X' in column 73 (continuation) on the exec line in the JCL and try it again. |
|
Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
|
|
|
|
Quote: |
Put a 'X' in column 73 (continuation) on the exec line in the JCL and try it again |
Why? Continuation marks occur in cc72 and should not be needed in this case - there is no over-run from line 1 of the exec statement to line 2. |
|
Back to top |
|
|
Jose Mateo
Active User
Joined: 29 Oct 2010 Posts: 121 Location: Puerto Rico
|
|
|
|
Thank you Mr. Clouston for correcting me (JCL is not one of my strong points) and my suggestion was a trail & error thing to see if it corrected the situation.
Chatterjesis, is this EXEC is it within a PROC? if it is then it might be that the EXEC PROC has a parm which nullify any other parm in the proc. |
|
Back to top |
|
|
chatterjesis
New User
Joined: 31 Aug 2008 Posts: 31 Location: hyderabad
|
|
|
|
Hi,
Thanks to all for the kind reply.
Here is the JCL
Code: |
//STEP1 EXEC PGM=DISPARM,
// PARM='MYDDNME'
//STEPLIB DD ..........
//IN1 DD DSN=infile,
// DISP=OLD
//OUT1 DD DSN=outfile,DISP=MOD
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//CEEDUMP DD SYSOUT=*
|
Cobol code:
Code: |
WORKING-STORAGE SECTION.
01 MESSAGE-TEXT.
05 FILLER PIC X(10) VALUE 'TABLE : '.
05 WS-PARM-DATA PIC X(100).
05 FILLER PIC X(10) VALUE 'COUNT : '.
05 WS-COUNT PIC 9(5) VALUE 0.
01 WS-LENGTH PIC 9(3).
77 WS002-FILE-STATUS PIC X(2) VALUE SPACES.
77 WS001-FILE-STATUS PIC X(2) VALUE SPACES.
01 EOF PIC X(5) VALUE 'FALSE'.
01 FILE-REC PIC X(130).
LINKAGE SECTION.
01 PARM-BUFFER.
05 PARM-LENGTH pic S9(4) BINARY.
05 PARM-DATA pic X(100).
PROCEDURE DIVISION USING PARM-BUFFER.
INITIAL-PARA.
INITIALIZE WS-PARM-DATA.
PARA-1.
DISPLAY 'PARM-LENGTH: ' PARM-LENGTH.
DISPLAY 'PARM-DATA IS: ' PARM-DATA (1 :
PARM-LENGTH).
MOVE PARM-LENGTH TO WS-LENGTH .
DISPLAY ' WS-LENGTH: ' WS-LENGTH .
MOVE SPACES TO WS-PARM-DATA .
MOVE PARM-DATA (1 : PARM-LENGTH)
TO WS-PARM-DATA .
DISPLAY 'WS-PARM-DATA: ' WS-PARM-DATA.
PARA-2.
OPEN EXTEND FILE2.
OPEN INPUT TRANS-FILE.
READ TRANS-FILE AT END MOVE 'TRUE' TO EOF
IF WS001-FILE-STATUS = 00
DISPLAY "File READ STARTED."
CONTINUE
ELSE
DISPLAY "WS-ERROR While reading file"
END-IF.
PERFORM UNTIL EOF = 'TRUE'
ADD 1 to WS-COUNT
READ TRANS-FILE AT END MOVE 'TRUE' TO EOF
END-READ
END-PERFORM.
MOVE MESSAGE-TEXT TO FILE-REC
WRITE FILE2-DET FROM FILE-REC
IF WS002-FILE-STATUS = 00
DISPLAY "File WRITTEN SUCCESSFULLY."
CONTINUE
ELSE
DISPLAY "WS-ERROR While WRITING file"
END-IF.
CLOSE FILE2.
STOP RUN.
|
output:
Code: |
PARM-LENGTH: 00010
PARM-DATA IS:
WS-LENGTH: 010
WS-PARM-DATA:
File WRITTEN SUCCESSFULLY.
******************************** BOTTOM OF DATA *
|
All of them are from one run. |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
Why is PARM-LENGTH being displayed as 5 digits instead of 4? |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Don,
Perhaps (maybe) depending on the TRUNC compile option or maybe not?
Signed-Halfwords have a maximum value of decimal 32767.
In any case, I think we're all still perplexed as to why this entire exercise isn't working correctly....
Bill |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
You're right Bill. When I changed my test pgm to use TRUNC(BIN) it DISPLAYs PARM-LENGTH as 5 digits.
However, that had no influence on the test results; my program still works as expected. |
|
Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009 Posts: 293 Location: U.S.A.
|
|
|
|
My first question would be: Is the program doing the displays being invoked DIRECTLY from the JCL, or is it being called by another program? |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
Ronald Burr wrote: |
My first question would be: Is the program doing the displays being invoked DIRECTLY from the JCL, or is it being called by another program? |
Excellent question. I've been assuming that it is the top level module because that's usually the only program that you'd pass a PARM to. |
|
Back to top |
|
|
chatterjesis
New User
Joined: 31 Aug 2008 Posts: 31 Location: hyderabad
|
|
|
|
@Ronald
The JCL directly calls the program...and displays could be seen in SYSOUT |
|
Back to top |
|
|
mmwife
Super Moderator
Joined: 30 May 2003 Posts: 1592
|
|
|
|
Oops. Deleted by sender. |
|
Back to top |
|
|
chatterjesis
New User
Joined: 31 Aug 2008 Posts: 31 Location: hyderabad
|
|
|
|
Hi all,
Thanks a lot for your help!!!
The problem got resolved.
I was doing compilation in changeman with CICS option Y.
may be that was the reason PARM was not passing correctly |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Oy Vey
Bill |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
That is disappointing. I was hoping that it would be something interesting. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
I realise this has already gone on longer than it should. But the following should work, without recourse to "reference modification".
Code: |
LINKAGE SECTION.
01 PARM-BUFFER.
05 PARM-LENGTH pic S9(4) COMP.
05 PARM-DATA.
10 FILLER PIC X
OCCURS 1 TO 100 TIMES
DEPENDING ON PARM-LENGTH.
PROCEDURE DIVISION USING PARM-BUFFER.
PARA-1.
DISPLAY PARM-DATA.
DISPLAY PARM-LENGTH.
MOVE PARM-DATA TO WS-PARM-DATA.
|
I removed the spurious "INITIALISE", which was also a couple of times mimicked by "MOVE SPACES". There is no point in moving something to a field, and then immediately moving something else. In this instance it is hardly a case of saving CPU time, but some poor prog at some time is going to look at the code and wonder "what's all this abaht?"
Robert got it right, no "reference modification" at all needed on WS-PARM-DATA, even in the examples with "reference modification" for the source field. |
|
Back to top |
|
|
|