Unkown result in the output of a routine which use SETFILE
Moderators: chulett, rschirm, roy
Unkown result in the output of a routine which use SETFILE
Hi,
We wrote a routine with the below, where to find the total number of records. (20 records)
Cmd = 'SETFILE ' : hshdflpth : ' ' : 'hsdfile' :' OVERWRITING '
PERFORM Cmd
PERFORM 'COUNT ' : 'hsdfile'
Ans = @SYSTEM.RETURN.CODE
If i run the routine with a hashed file path and name given, the output is as below,
Arg1 = d:/ds/sam1/sample
Test Failed.
Pointer "hsdfile" established in VOC file.
20 records counted.
Result = 20
The output is shown exactly the number as 20 records. But why its shows TEST FAILED ? The same routine runs fine in one environment and shows the TEST FAILED in another environment.
Need you suggestions on the same.
Thanks in advance.
We wrote a routine with the below, where to find the total number of records. (20 records)
Cmd = 'SETFILE ' : hshdflpth : ' ' : 'hsdfile' :' OVERWRITING '
PERFORM Cmd
PERFORM 'COUNT ' : 'hsdfile'
Ans = @SYSTEM.RETURN.CODE
If i run the routine with a hashed file path and name given, the output is as below,
Arg1 = d:/ds/sam1/sample
Test Failed.
Pointer "hsdfile" established in VOC file.
20 records counted.
Result = 20
The output is shown exactly the number as 20 records. But why its shows TEST FAILED ? The same routine runs fine in one environment and shows the TEST FAILED in another environment.
Need you suggestions on the same.
Thanks in advance.
Last edited by rajiivnb on Thu Jan 25, 2007 7:52 am, edited 1 time in total.
I think that your routine contains more than you've shown, since the output line "Arg1 = d:/ds/sam1/sample" isn't part of the normal code, either. Could you change your code portion to read
to prove that the "Not Found." text is being output by the PERFORM command?
Code: Select all
PRINT 'Before'
PERFORM Cmd
PRINT 'After'
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
The "test fails" for a very obscure reason, which you can ignore.
Warning - Technical Content
The test bed uses a system variable called @SYSTEM.RETURN.CODE to indicate success or failure. 0 is success.
Query verbs (like COUNT) also use @SYSTEM.RETURN.CODE to transmit the number of records processed.
Therefore, after your COUNT, @SYSTEM.RETURN.CODE is 20, which the test bed interprets as a failure.
</Technical Content>
Warning - Technical Content
The test bed uses a system variable called @SYSTEM.RETURN.CODE to indicate success or failure. 0 is success.
Query verbs (like COUNT) also use @SYSTEM.RETURN.CODE to transmit the number of records processed.
Therefore, after your COUNT, @SYSTEM.RETURN.CODE is 20, which the test bed interprets as a failure.
</Technical Content>
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
That's a mystery. I could only ask "what's different between the two environments?" before attempting to essay an answer.
My guess would be that "d:/ds/sam1/sample" exists in one environment and not in the other, and that they've changed how the test bed detects failure (so that my previous post is no longer correct).
My guess would be that "d:/ds/sam1/sample" exists in one environment and not in the other, and that they've changed how the test bed detects failure (so that my previous post is no longer correct).
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Rajiivnb, use this routine instead and see what results you get. It works at my end
All i did was to add "@SYSTEM.RETURN.CODE = 0" at the end to tell the underlying engine that everything is ok.
Ray, is that a safe thing to do?
Code: Select all
Cmd = 'SETFILE ' : hshdflpth : ' ' : 'hsdfile' :' OVERWRITING '
PERFORM Cmd
PERFORM 'COUNT ' : 'hsdfile'
Ans = @SYSTEM.RETURN.CODE
@SYSTEM.RETURN.CODE = 0
Ray, is that a safe thing to do?
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Not really. What if there really had been a failure? The following would be preferable. Not only because it's documented (hint!).
Code: Select all
* Construct and execute SETFILE command.
Cmd = 'SETFILE ' : hshdflpth : ' ' : 'hsdfile' :' OVERWRITING '
PERFORM Cmd
* Record result of SETFILE command.
Temp = @SYSTEM.RETURN.CODE
If Temp = 0
Then
* Determine number of records in hashed file for return by function.
PERFORM 'COUNT ' : 'hsdfile'
Ans = @SYSTEM.RETURN.CODE
End
Else
Ans = @NULL ; * SETFILE failed
End
* Report status of SETFILE command to test bed.
@SYSTEM.RETURN.CODE = Temp
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.