text files written to xtar IMD not the same when extracted

[jgrillout]

I did all my testing for creating a file with xtar and that is working fine (see good.txt) I extracted the IMD file using the in XENIX tar in the 6000 emulation.
The formatting is off and there are binary character at the bottom (see bad.txt). See cat.txt to see that it appears this way within the trs6000 when the file is printed to that screen.


I put samples on this pcloud share.
https://u.pcloud.link/publink/show?code=kZ6vzAVZ8bdL2E1opnzFLicFE6Ca8F2oGVzk

 

[gp2000]

I can put good.txt into a floppy.imd archive and back out again correctly with xtar.

When I use xtar on 7005012101.imd I find ACCTFILE.SL to be broken like bad.txt

I don't know what went wrong when xtar created the 7005012101.imd archive. Could you upload the source directory and the exact xtar command line used to create the archive?

 

[jgrillout]

I can put good.txt into a floppy.imd archive and back out again correctly with xtar.

When I use xtar on 7005012101.imd I find ACCTFILE.SL to be broken like bad.txt

I don't know what went wrong when xtar created the 7005012101.imd archive. Could you upload the source directory and the exact xtar command line used to create the archive?

Hi gp2000,
Thanks for your reply. I discovered it is not a problem with xtar. Here is a a link to a zip file for testing.
https://u.pcloud.link/publink/show?code=XZ5gLAVZJjV12GJB1S0a8T6gHJ0PCjBAMMVX
This zip file contains
exhibit1_ACCTFILE.FD - the cobol source code that contains the control characters. This is the type of file you wrote the c program to remove them.
gp2000fix.exe - that c program compiled.
test1.bat - a cmd file that runs gp2000.exe using the input file exhibit1_ACCTFILE.FD and outputs to the file FIXED_exhibit1_ACCTFILE.FD
FIXED_exhibt1_ACCTFILE.FD - the output from gp2000.exe (which is a exactly what I need)
test2.bat - a cmd file that run gp2000.exe using the input file FIXED_exhibit1_ACCTFILE.FD and outputs to file BROKE_exhibit1_ACCTFILE.FD

Ideally, a user would not be dumb and run gp2000.exe against a file that does not need to be fixed. So the output from test2.bat are the result of when user is dumb.

I guess nothing needs to be done for my purposes. I just need to avoid making this mistake. But I'd be interested in your thoughts why the clean file is distorted.


Thank You,
John

 

[gp2000]

The fixup program doesn't make any checks to confirm that the input file has variable length records in it. When you give it an ASCII text file it takes the first character of the file and uses that as the length of the record. In this particular case that is '0' which is code 48. You can see in the output file that the first character has been dropped and the next 48 characters are output which ends at the first two "00" of the 000030 line. Then a new line begins (because the record has ended) and it starts anew. Once again interpreting "0" as the length of a record.

This goes on until the end of the file when the last length goes beyond the end of the file. At this point my program should definitely report that something has gone wrong. Instead if reads the rest of the file and continues on trying to read more because of the record length. At the end of file it just gets -1 which is output as character 0xFF hence the 0xFF randomly at the end of the file.

If I make a "production" version of the program I'll at least add an error message if it needs to go beyond the end of file. And maybe a warning if the input looks like a normal ASCII file. That may still be a valid variable length record file but the odds are against it.