NAT0632 on a Histogram using the From/To clause

, ,
1

We have recently upgraded from Natural 3.1.6 to Natural 4.1.4. One of the new features is that the Read and Histogram have a new clause added that causes the data base loop to be satisfied at the database instead of in the program.

The syntax change is
READ file-view by descriptor FROM start-value/alt-file-view-field TO end-value/alt-file-view-field

and
HISTOGRAM file-view descriptor FROM start-value/alt-file-view-field TO end-value/alt-file-view-field

Syntactically they are supposed to be the same as using the FROM/THRU clause, the difference is that the data returned is slightly different. The FROM/THRU returns 1 record beyond the range specified so the program can terminate the processing loop. The FROM/TO only returns the requested data and the processing loop is terminated at the database and returns a 3003 response code indicating the end of file.

The problem we are running into is that the TO portion of the FROM/TO clause is being checked incorrectly during a CHECK or STOW operation and returning the NAT0632 error.

DEFINE DATA
LOCAL
1 RD-VIEW VIEW OF EMPLOYEES
2 PERSONNEL-ID
2 NAME
*
1 HIST-VIEW VIEW OF EMPLOYEES
2 PERSONNEL-ID
*
1 #UNIQUE-CNT (I4)
END-DEFINE
READ ALT-FILE-VIEW
H1.
HISTOGRAM HIST-VIEW PERSONNEL-ID FROM RD-VIEW.PERSONNEL-ID
TO RD-VIEW.PERSONNEL-ID
IF *NUMBER(H1.) = 1
ADD 1 TO #UNIQUE-CNT
END-IF
END-HISTOGRAM
END-READ
END

In this example the syntax check will give the error NAT0632 on the TO RD-VIEW.PERSONNEL-ID

If the TO is changed to THRU no error will be generated. Is anyone else having this problem?

Geoff Smith

2

Hi Geoff;

This does indeed seem to be a bug in the compiler. If you change RD-VIEW to have only one field, the program works just fine. Also, with a user defined variable, #PERS-ID as the starting and ending value, both TO and THRU work.

For some reason, the compiler is checking the FROM and TO values to see if they are from a view with but one field (a requirement for the view for the field being HISTOGRAM’ed).

If you have not done so already, this should be reported as a bug (but, since the developers Moderate this forum; they already know).

steve

3

Well observed folks, this is really a compiler bug that wasn’t found yet.
A solution is now available, with zap NA64298 for V41 and zap NA73079 for V42.

Thomas