Hi Jack,

I am experiencing a BASIC error #17 with A-Shell 7.0.1770.3 on Debian 12. The BASIC error occurs at location counter 62F1B in the below code.

I tried unsuccessfully to reproduce in a smaller test program thinking it might be related to the OUTPUTONLY changes, but was unsuccessful. The code works as expected on running an earlier version of A-Shell. I can try something else if you have a suggestion or send the LSX as well.

Thanks,
John Andreasen
Diversified Data Software

I suspect the error is actually on the next line. Is it a file access operation?

Cancel that - error 17 is file not found, so it almost certainly applies to the OPEN. The ashlog.log file should list the actual fspec, which should give us a clue. I'm guessing that the latest change to make :OUTPUTONLY inheritable may be affecting the fn'fileunique_get_filename$() function so that it isn't returning a value?

Here is what the ashlog shows. I did add a trace and it indicates the function is returning a value, but without the ppn: r_file$=[DSK30:TSKAAB.000]
19-Mar-25 19:05:15 [p1265488-2]<CU22:EDIORDIMP:62f1b> Trapped Basic Error #17 (File not found) at location counter &h62F1B, last proc/func: Fn'NextCh<
19-Mar-25 19:05:15 [p1265488-2]<CU22:EDIORDIMP:62f1b> Call stack trace, from program CU22 :
From loc de0a, Xcall EDIORDIMP
From loc ae6b5, Call Proc() @8b9af
From loc 8ba5b, Call Proc() @9067a
From loc 909f8, Call Proc() @8d882
From loc 8d8ca, Func() @8d930
From loc 8d98c, Call Proc() @64d3e
From loc 6507f, Func() @64972
From loc 64c59, Func() @643d7
From loc 647e2, Func() @657ef
From loc 658dc, Func() @62e5c
19-Mar-25 19:05:18 [p1265488-2]<CU22:EDIORDIMP:62f1b> System Error Log: C errno:2, last instr:0x1b, cwd:DSK5:[160,1], host OS error:2, DDB error:3, mode:2, chan:2033
19-Mar-25 19:05:18 [p1265488-2]<CU22:EDIORDIMP:62f1b> >>No such file or directory (/var/data/harris/ashell/vm/miame/dsk30/160001/tskaab.000)
19-Mar-25 19:05:18 [p1265488-2]<CU22:EDIORDIMP:658db> Trapped Basic Error #17 (File not found) at location counter &h658DB, last proc/func: Fn'NextCh<
19-Mar-25 19:05:18 [p1265488-2]<CU22:EDIORDIMP:658db> Call stack trace, from program CU22 :
From loc de0a, Xcall EDIORDIMP
From loc ae6b5, Call Proc() @8b9af
From loc 8ba5b, Call Proc() @9067a
From loc 909f8, Call Proc() @8d882
From loc 8d8ca, Func() @8d930
From loc 8d98c, Call Proc() @64d3e
From loc 6507f, Func() @64972
From loc 64c59, Func() @643d7
From loc 647e2, Func() @657ef

I will do some further testing with the function.

I have been able to reproduce the issue in a smaller program. It looks like it is an issue related to an XCALL REGEX in Fn'To'Amos(). The way the parameters are specified to Fn'To'Amos() makes a difference. Our version is slightly different than the SOS library version. Is it alright if I send you a LSX to look at?

Yes please. I was going to suggest that it was probably due to some detail in your Fn'To'Amos() function, which is the only logical place where it seems possible that the device and PPN parts of the path translation could be handled separately.

I'm unable (as yet) to explain why this seems to be new, as none of the related logic seems to have been changed recently. The issue has to do with dynamic string parameters (which have always been a bit complicated to handle as parameters due to a legacy attribute of the way parameter passing involves pointers to data, which in the case of dynamic strings, may move during assignments.)

Until I can figure it out, the simple fix is to change the parameters to your Fn'To'Amos() function to be fixed strings (s260 or T_NATIVEPATH) would be sufficient, e.g.

Although switching to fixed length strings does require more stack space, it is more CPU efficient (not that either one will be noticeable in this case!)

After some further analysis, I realized that the dynamic strings aren't really the cause of the problem -- they were actually obscuring the problem! The real problem is here:

The dir$ variable is being used for both the subject and the first sub-match return parameter. The problem there is that the internal procedure for retrieving the sub-matches works by copying them from the subject variable using offsets that are returned by the core regex function. So once the first sub-match gets copied to the dir$ parameter, that parameter gets truncated, resulting in the second sub-match not returning anything.

It might not be a problem if the sub-matches weren't immediately adjacent to each other, but in this case, truncating the output for the dir$ match clobbered the memory that was subsequently referenced to get the ppn$ sub-match.

In the case of dynamic strings, the memory handling of the strings will depend on a variety of factors relating to the prior activity with other dynamic string variables in the same scope. So my suggested workaround only worked by chance. And changing the dir$ parameter from a dynamic string to a static string only makes it worse.

I'm going to add a fail-safe to XCALL REGEX to check for this scenario and if found, to make a second copy of the subject string so that it can't be modified by returning sub-matches in to the same variable. Short of that, the real fix for this problem is to use a separate variable for the sub-matches, i.e. don't use dir$ for both the subject and a sub-match.

Note that this restriction probably doesn't apply to many (or even any) other XCALLs; it's just a quirk of the REGEX algorithm.

The 7.0.1770.4 update should resolve this issue...

ash-7.0.1770.4-el7-upd.tz
ash-7.0.1770.4-el7-x86_64-upd.tz
ash-7.0.1770.4-d12-x86_64-upd.tz
ash70notes.txt