One of my most important files in FinalCalc now fails to open, with a red-zone damaging DSI error.

I will wager $100 that there is no way to fix this, and I hope I lose.

OS4.1FE on X1000.

@kilaueabart,

No backup? Look everywhere!

@kilaueabart

Have you tried blacklisting Final Calc in the compatibility prefs to force it to run on interpretive emulation?

@kilaueabart

If all else fails, use finalcalc under emulation or real Amiga to get the file back. The file should be fine, its probably just the Application that's crashing due to something changed(in AmigaOS) or an overload/leak due to the size of file

_________________
Cross-developer on Windows, OS3, OS4, Linux; Current Projects:-
Nephele Cloud App OS4
UserProfile System OS4
AmigaOneXE OS4.1.6

TaoSoftwareBlog Youtube

@kilaueabart

If it says that red zone is damaged you should increase the stack of the program as this is a sign of stack overflow.

@kilaueabart

Quote:

One of my most important files in FinalCalc now fails to open, with a red-zone damaging DSI error.

I've been using FinalCalc for incomes taxes every year since I bought it (about 2000 CE). For all versions of AOS 4.x I've noticed:

1. Nine times out of ten I will get an 80000003 DSI upon opening the first project after starting FC up.

Always the Grim Reaper catches this and I can hit the "More ..." button and then the "Ignore DSIs" button to sucessfully continue. And I never have any trouble for the rest of the session.

2. Nine times out of ten I can avoid this opening DSI if, upon starting FC I chose the Project | New menu choice first and then the Project | Open (or Load) to get the initial data sheet from the disk.

Try one of these to get the file open.

3. Final Calc is a very nice spreadsheet program. (I wish I could write one nearly as good!) The one problem it has on AOS4 is that resizing a spreadsheet window is so difficult due to it refreshing so assiduously.

I use FC on an X1000 with OS4.1 FE, on its own screen of 1920x1200 ARGB. I've not found any difference if it is put in the Compatibility Prefs DOS list or not.

Hopefully, this will help you.

Tom

@QuikSanz

It occurred to me that I might have an older version of the file in my backup of OS4.1u6.

When I found one there, a) it was apparently the same file as in FE: 24765 Bytes (or whatever Size is measured in) dated 2015-05-26, and b) the stack size change I have made in FE, doubling 2048 to 4096, applied in u6 as well.

But I gave it a try anyway, and it loaded perfectly!

I'm puzzled, but I'm going to try the u6 file in FE, just in case there's some messed up Bit making it crash in FE. In any event it looks like I could continue to use u6 if necessary.

But I WILL have a backup from now on!

And, by the way, I think I owe you $100. How do you want it?

Last edited by kilaueabart on 04-Jul-2015 at 02:38 AM.

@Rob

No, I was getting ready to try that but ended up trying out RunInUAE first.

@TheAMIgaOne

It turns out to be my 5th largest file; the larger older ones date from 1997 to 2009. But only one of the larger ones fail.

I was going to try blacklisting, but on my was I ran (hah!) it with RunInUAE. I have never had any luck with that app, and though FinalCalc pretended to come up, it was VERY hard to move the pointer to the menu, and when I tried the use the menu (or A^O) to open the file nothing happened. Nor could I quit the program!

@salass00

Doubled it from 2048 to 4096, even though without doing so I was able to open a much larger file, 185403 compared with the bad file's 24765.

@tbreeden
Quote:

... 2. Nine times out of ten I can avoid this opening DSI if, upon starting FC I chose the Project | New menu choice first and then the Project | Open (or Load) to get the initial data sheet from the disk. ...

That's interesting, and I shall try it when I get back to FE. That's a trick I used to need to use with PageStream 5.0.5.8 Pro, but only before FE came along.
Try one of these to get the file open.[/quote]

...

@kilaueabart

Quote:

Doubled it from 2048 to 4096, even though without doing so I was able to open a much larger file, 185403 compared with the bad file's 24765.

2048 is a small stack even on a 68k machine, your change will likely have made no difference as the default DOS process stack on AmigOS 4 is about 64 Kb.

bump your stack to something big, like 100k. If it still crashes then likely the program has gone inot a infinite loop.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Interesting. 2048 had always worked until I made the file one line too long. I guess that's the size the program came with.* I don't imagine I ever had a reason to shrink it.

I'm guessing that the change to 4096 is what worked, rather than finding a backup on 4.1u6. When I got back on FE I changed the name of the file there to "badmpg.sheet," but after copying the one from u6 in I tried running badmpg.sheet first, and it worked just fine!

I'm guessing now that when one changes stack size, one needs to do a machine reboot rather than just a warm reboot.

*
I just went to up it again, when it failed to run the other "bad" file, and see that I had forgotten the final "0." I previously upped it from 20480 to 40960. Next time I cold boot, it should be 100,000.

Last edited by kilaueabart on 05-Jul-2015 at 12:55 AM.
Last edited by kilaueabart on 05-Jul-2015 at 12:55 AM.