FIND viewname WITH descriptor SORTED BY field2

Hello all!

Last weekend we did an upgrade from NAT611@Solaris to NAT639@Solaris.

Some programs are not stowable any more. It’s seems like NAT639 changed in interpretation of SORTED-BY-fields.

For example take the following code:

define data local
01 sample1 view of sag-tours-e-cruise
02 cruise-id
02 charter-yacht-type
find sample1 with cruise-id > 0 sorted by charter-yacht-type
display *ISN sample1

charter-yacht-type is not a descriptor. You can stow this program under NAT611, but you can’t under NAT639. Why? Is there any Parameter to change this behaviour?

Yesterday I opened up an empower incident. I thought I’ll get a quick answer - because I don’t think this is a rare problem… any ideas?



Hi Mathias,
I have no idea when this changed - it’s pretty hard to get hold of the documentation - releasenotes for 6.2 nowadays :wink:

But the easy workaround is to mark these fields as “Non-descriptor” in the DDM.

Actually I think this compiler-change makes pretty good sense since a unintended use of the sorted by might REALLY put adabas to work !


Hi Finn!

You’re right of course. This would be a possible workaround. But before we change dozens of codelines, I want to know if there is a compiler option or something like that.

If not, we have to search for all SORTED-Statements and check, whether they are using descriptor fields or not. That’s a bit time-consuming. Maybe a catall would help for searching… OK, let’s see…

BTW: A natural-611-stowed program runs under NAT639 without any problems. It really seems to be a compiler-change.


Hi Matthias
I would definitely let the compiler do the checking.
Perhaps make a copy of the relevant libs into a local SPOD and do a CATALL if you don’t want to change the timestamps?!
Then do a multi-column sort on the compiler-errors+sourceline in the result-window(CTRL+CLICK on the relevant columns - if you didn’t know that trick already;-).
This should give you a much quicker look at the “sorted by” statements with problems.

Hi Finn!

Finally I got an answer from SAG.

So I have to say: You are completely right!

Thanks for your hint, but I’m on Solaris using a simple terminal session.


Meanwhile we did a catall.

Here the next change from NAT6.1.1 --> NAT6.3.9.
It’s just one byte. Guess what byte? :wink:

define data local
1 #a20 (A20)
1 #a10 (A10)
input #a20 #a10
if #a10 = " "
  reinput "enter value" mark * #a10

Did that really compile under 6.1.1 ?!
I mean a space between * and variable in a reinput makes no sense in any version - or have you really discovered a new (old) bug in 6.1.1 :wink:

Yes, it does.
It’s compilable on NAT 6.1.1 for Windows and for Solaris. But the catall-Error-List shows more than this error. Let’s see…


That space in the REINPUT is acceptable on the mainframe, too, under 4.2.3 and 4.2.5.

he-he - interesting undocumented features :wink:

  • just found that even the MF Natural 4.2.7 compiler supports the blank after “*” !

On the other hand I looked up in the oldest doc. I could find (Nat2.1.2 from the days I started with Natural) where there is no documentation of this feature.



reinput "enter value" mark* #a10

–> works only on NAT 6.1.1

reinput "enter value" mark*#a10

–> works on NAT 6.1.1 and 6.3.9

Today I realized: There’s a new catall option to do a check only. Very good.

Next differece between Nat 6.1.1 and Nat 6.3.9: The internal date/time-checks are more restrictive now.

define data local
01 #a20    (A20) /* e.g. for superdescriptor
01 redefine  #a20
02 #a16     (A16)
02 #d       (D)
if #d < *DATX /* NAT1305 here

This code runs on Nat 6.1.1 without error but throws a runtime error on Nat 6.3.9.
I think that’s OK.

I guess this is one of the reason for the often used standard of defining superdescriptor keys as B20 instead of A20 !?

Yes, it is. But predict builds a DDM with A20. That’s odd.

OK, the programmer can use a B20 anyway…