I using Version 6.2.1.02 (HP-UX IA64 11.31) and Natural 6.3.11
When I use the command “find number” and the clauses “AND” on more than one occasion the result is wrong, is it due to an Adabas or Natural error, is there a reported fix?
ej.
000120 FIND number ctas-tarj
000130 SP-IDTT-EST-REN-FHASTA =
000140 ‘T1V00000000’ thru ‘T1V99999999’
000150 AND sp-tip-reg-bco-prod-grupo = ‘T700E7049’
000160 AND MOT-ALTA-BOL = “N”
000170 AND mar-grab-tar = “N”
000180 AND FBAJA-BOL > 20180128
000190 display *NUMBER
000200 stop
000210 .
regards
Francisco.
I would be very surprised to learn that this is the result of an Adabas bug. It’s more likely to be an issue in your code or your expectations. What did you do to verify the result? Did it look something like this?
R.
READ CTAS-TARJ BY SP-IDTT-EST-REN-FHASTA
FROM 'T1V00000000'
TO 'T1V99999999'
WHERE SP-TIP-REG-BCO-PROD-GRUPO = 'T700E7049'
AND MOT-ALTA-BOL = "N"
AND MAR-GRAB-TAR = "N"
AND FBAJA-BOL > 20180128
END-READ
DISPLAY *COUNTER (R.)
END
First of all, thank you very much for the quick response. To clarify the subject, I can affirm that the answer obtained is wrong, since the same program but in an environment of Natural and Adabas older the answer is correct.
This is detected just after a migration of versions Natural V 6.1.1 Pl 12 and Adabas Version 3.3.3.01 (HP-UX IA64 11.23).
My suspicion is that it is due to a failure of Natural or Adabas or in some step of the migration of the migrated files. I do not have access to bug fix reports from SoftwareAG about this.
Does the READ program’s result match the old or new count?
Was your data base upgraded in place, or was a new database created and the data copied?
Any changes to null suppression within the SP-IDTT-EST-REN-FHASTA descriptor?
Perhaps an ad hoc READ PHYSICAL would help clarify the situation.
When executing the READ program the values ??coincide, when executing your program it never ends as if it were entering a loop. with the find number option the answer is almost immediate.
The database was created new and the data was exported with the utility adaord export option and imported with option import with equal utility. I change the blocking of both “ASSO” and “DATA”. Anrtes was 2k and 6k now 4k and 32k
We are sure that the response of the same program is correct in the previous environment and we know that it is incorrect in the new.
The fields of the entire base are “NULL SUPRESS” before and now.
Regards.
Francisco.
It sounds like you used the THRU option in the READ statement instead of the TO option. The READ program should not take much longer than the FIND program if you use TO and limit the view to only the fields referenced in the READ loop. The *COUNTER value should match the old or new *NUMBER value.
Also, run an ADAREP on both databases and compare the record counts for the file.
You might try doing HISTOGRAMs on the component fields from the FIND NUMBER. This might identify some potential data problems following the migration. Do the same with the original file and see if the HISTOGRAMs match.
What should *NUMBER be? If a small number, why not print out the data. That is, change the FIND NUMBER to a FIND and add a WRITE or DISPLAY to the original code.
Thank you very much for all the collaboration, in meeting of analysts and programmers
it was determined that the data exists, is but does not bring, it as we expect in the new
environment.
We resolve to capture the information in another way, since we can not
extend this topic much, again thank you very much for your collaboration,
Regards,
Francisco.
PGM Original
FIND NUMBER CTAS-TARJ SP-IDTT-EST-REN-FHASTA =
‘T1V00000000’ thru ‘T1V99999999’
AND SP-TIP-REG-BCO-PROD-GRUPO = ‘T700E7049’
AND FBAJA-BOL > 20180128
AND MOT-ALTA-BOL = ‘N’
display *NUMBER
.
PGM Modify ( solucion )
FIND NUMBER CTAS-TARJ SP-IDTT-EST-REN-FHASTA =
‘T1V00000000’ thru ‘T1V99999999’
AND FBAJA-BOL > 20180128
AND MOT-ALTA-BOL = ‘N’
RETAIN AS ‘BUSCA’
DISPLAY *NUMBER(0130)
FIND NUMBER CTAS-TARJ WITH ‘BUSCA’ AND
SP-TIP-REG-BCO-PROD-GRUPO = ‘T700E7049’
DISPLAY *NUMBER(0190)
Regards,
Francisco.
When I first saw the original program I thought, “This won’t even compile.” Natural had a long-standing limit of 3 descriptors in FIND criteria. For performance reasons, I try to limit FINDs to a single descriptor, so I was surprised that the restriction had been lifted. Perhaps it is still in play, based on your findings.