Hi Jack,

If you think the weird cases were over with the "pipe case", here is a new one

Generating code in LEO start to throw the following error:


It happens while executing the following command where (prg'source'folder$+gen'file'name$) is "DSV:[657,0]gstecx.gen" and file'tabctl$ is "tabctl_TSKAAB.7101" and both exist in that moment.


Guessing the culprit could be the long pathname, I changed the destination to "c:\temp\gstecx.gen" and it worked.
After I tried with "OPR:gstecx.gen" and it also worked , but wait!
The pathname is almost the same of DSV:[657,1], in fact it has one more letter


Let's try using an ersatz for DSV[657,1], look below, it also worked


At this point, just to confirm the suspicious, I tried using DSK0:[1,2] in place of OPR: , that worked before, but this time failed with the exact same error above.
So, it seems there are some problem in the transation of [p, pn] to the full path.
Let me add this is not a problem related to these last releases, not even related to 7.0 because I tried with the 6.5.1741.1c and it also failed.

It can be related with my environment, let me know what you find on your side and what else you want me to do.

To finish, I'm not stuck with this and it's saturday so, no hurry, but I'm really curious to know what's behind this

Have a nice weekend

I've seen this error in a few places, always connected with an XCALL AMOS operation, but appreciate the reminder and details, since I haven't yet managed to track it down. As you've discovered, it doesn't seem to be quite as simple as an overflow, and I've seen it much simpler filespecs than in your example. The good news is that the problem doesn't affect the operation of your program; it only affects the call stack tracing feature (used when an error occurs or when running the profiler). When the error occurs, it simply resets the stack trace (losing any details about nested calls up to that point).

I'll study it further here...
Thanks.

I think this problem is solved in 7.0.1757.1, which is available for most platforms/architectures from the distribution/download directions at:

https://www.microsabio.net/dist/70rel
ash70notes.txt

As mentioned in the release notes, the issue with the stack trace buffer was mainly relevant to the runprofiler (RUNPROF.LIT) which, as of the latest 1.1(115) version properly handles XCALL AMOS calls. (Use UPDCUR to update it.)