|
|
Post by George on Jun 28, 2021 13:23:28 GMT -5
I have no incidents to report. I don't count those that I get when switching from normal to Debug mode, since the insertion of break point SVC calls effectively 'breaks' the Assembler code routines that do the hash counts.
So no, no ideas. No changes have been made (no need).
You got me.
George
|
|
|
|
Post by George on Jun 28, 2021 14:28:43 GMT -5
Don't know Robert. But you and I are both aware that you have historically been 'picked on'. No explanation, but it is a royal PITA since they're proving to be impossible to pin down.
George
|
|
|
|
Post by George on Jun 30, 2021 8:32:46 GMT -5
Robert: STATE SAVE has handled all this crap for years.
Like performing all the normal PRESERVE logic to a temp copy of the line before all the HASH stuff is done.
And handling AUTOxx and re-inserting FF characters for page processing.
And handling X/NX and U/NU filtering that may be being performed by the underlying SAVE function.
Oh, and throw in possible RECFM F padding/truncation as well.
So yes, the Profile settings are critical, if you're bouncing around different file types, CLIP sessions, doing CREATE/REPLACE/SAVEAS etc. I'm sure there might be some path that end up confusing things.
As to Macros, SPFLite itself reads the macro file and the data is passed to thinBasic as a string buffer, thinBasic does not touch the actual .MACRO file, it doesn't even know its name. When SPFLite reads the macro file it is done as a simple ANSI file read, no Profile is used since the file must be a nice simple normal ANSI file.
George
|
|
|
|
Post by George on Jun 30, 2021 12:13:54 GMT -5
Robert:
OK, zeroing in on something. And right now it does appear to be some Profile related error when doing CREATE/REPLACE/SAVEAS from one file type to another, and specifically right now, the PRESERVE option.
Stay tuned.
George
|
|
|
|
Post by George on Jun 30, 2021 14:31:44 GMT -5
Robert: This has been an infuriating day, nothing is logically making sense. I'm close to saying "Sorry, STATE is dead", I just can't cope with beating my head against the wall any longer.
Stuff works perfectly with small (8-12 line) files, but fails with larger (150+ line) files. And all larger files do is have loops that last longer.
George
|
|
|
|
Post by George on Jul 1, 2021 8:28:26 GMT -5
Well of course there's always the possibility of something else being overlooked, the fact you've seen it again proves that.
The trick is to know where to go back in and look again. As I've said before, reading / reviewing code that's working 99.9% of the time is a waste of time.
George
|
|
|
|
Post by George on Jul 1, 2021 12:17:24 GMT -5
Robert: Well after another morning of head bashing, I think this STATE thing might have an answer.
1. Doing SAVEAS/CREATE/REPLACE where the Profile changes was definitely a problem. I corrected that and these commands will now do a temp swap of Profiles so the output file is done with the proper valid Profile in place. That should have fixed things up.
2. Testing though, I was still getting failures opening the newly created file. After ridiculous amounts of tracing I spotted it.
3. MINLEN
Scenario:
Do a CREATE from a normal, MINLEN=0 Profile of a file with some null lines. The STATE file is created with a HASH based on the loaded file contents being written out. This HASH is perfectly valid, it does indeed match the file perfectly.
Load the file now using the Profile with MINLEN=5. The file is read and loaded into memory, during which the MINLEN is applied. Then the STATE file is processed. First thing it does is compare the HASH in the STATE file to the file in memory, so it hashes the in-memory file.
And fails because the null line hashed when the file was saved, is now 5 blanks. So of course the HASH fails, the memory file really isn't the same.
I guess I'll have to add this MINLEN adjustment into the routine that does the PRESERVE, AUTOxx, AUTOCAPS and RECFM=F adjusting before the HASH is computed.
Another case where reasding/reviewing code trying to 'spot the error' would never have found it.
Now to go rip out all the debugging/trace code.
George
|
|
