EXPORT2 enhancement request

[jgrillout]

I apologize for creating this new thread. I didn't find the response to a previous post I made where I got the impression one of responders is a programmer that wrote the IMPORT2 program.

I'd like to know if the EXPORT2 program could be enhanced to export the COBOL source to a text file . I don't understand why I don't get a text file output from EXPORT2. TRSSOS can PRINT and LIST the file and and there are no control characters. EXPORT2 creates a file that has control codes. The files in this share contain the IMD file that has the COBOL source, A LIST and PRINT of ACCTFILE.DS. and EXPORT2 output of ACCTFILE.DS.txt

https://u.pcloud.link/publink/show?code=kZj9WUVZQ76IC12Q0mhtTqctqR8AsLiEOdpk

Here is the command I entered to export the file

trs80gp.exe -m2 -frehd -hx -d1 m2-trsdos-util.dmk -d2 XFER.IMD -d3 70050121.IMD -iw Date -i "06/27/2023\r\rEXPORT2 -ne ACCTFILE/DS:3

 

[gp2000]

I did write the Model 2 part of EXPORT2 and IMPORT2.

In this particular case you don't want to use the -n option as it will cause problems. Not that it matters as it appears that EXPORT2 has some kind of bug when it comes to variable record length files. The first 256 bytes of the output file is fine but then it just keeps repeating the same 256 byte block instead of advancing in the file.

Probably some mistake on my part in handling the variable length record files. I can't even recall if I found any variable length record files when I was developing the program.

Clearly the bug needs to be fixed. Not so sure if I should directly support the COBOL interpretation of the variable length records where each one is a line in a text file. I imagine it is up to each individual application to decide how to use the feature.

Once EXPORT2 is fixed then an external program can easily convert the COBOL variable record length file to a text file. Here's a little C program which will do the job.

#include <stdio.h>

int main(int argc, char *argv[])
{
    if (argc != 2) {
        printf("usage: var variable-record-length-file\n");
        return 1;
    }

    FILE *fp = fopen(argv[1], "rb");
    if (!fp) {
        printf("Could open open '%s'\n", argv[1]);
        return 2;
    }
    for (;;) {
        int len = fgetc(fp);
        if (len == EOF)
            break;

        for (; len > 1; len--)
            printf("%c", fgetc(fp));

        printf("\n");
    }

    return 0;
}

 

[jgrillout]

gp2000 thank you for both of your replies to my posts today. This is a great forum. I appreciate you sharing your expertise.

 

[gp2000]

I believe I've fixed EXPORT2 so that it outputs variable length record files correctly. You'll still need to unpack the records into text file lines yourself but at least all the data will be there.

Just use "EXPORT2 FILE/EXT" for variable length record ("V") files.

For completeness I'll be adding a "-v" option to IMPORT2 so variable length files can be imported. But not right now.

 

[jgrillout]

I believe I've fixed EXPORT2 so that it outputs variable length record files correctly. You'll still need to unpack the records into text file lines yourself but at least all the data will be there.

Just use "EXPORT2 FILE/EXT" for variable length record ("V") files.

For completeness I'll be adding a "-v" option to IMPORT2 so variable length files can be imported. But not right now.

Well, that was fast.
I'm not sure what you mean by unpack the text lines. Is that what the sample c++ program is for? i downloaded and inserted your new version in drive 1. I ran EXPORT2. I can see the text. What are the non printable characters? For example, I see 4 hex 07 characters.

 

[jgrillout]

Well, that was fast.
I'm not sure what you mean by unpack the text lines. Is that what the sample c++ program is for? i downloaded and inserted your new version in drive 1. I ran EXPORT2. I can see the text. What are the non printable characters? For example, I see 4 hex 07 characters.

Well, that was fast.
I'm not sure what you mean by unpack the text lines. Is that what the sample c++ program is for? i downloaded and inserted your new version in drive 1. I ran EXPORT2. I can see the text. What are the non printable characters? For example, I see 4 hex 07 characters.

 

[gp2000]

Well, that was fast.
I'm not sure what you mean by unpack the text lines. Is that what the sample c++ program is for? i downloaded and inserted your new version in drive 1. I ran EXPORT2. I can see the text. What are the non printable characters? For example, I see 4 hex 07 characters.

Yes, that's what the C++ program is for. You'll note that those $07 characters are all followed by 6 character program lines and then another byte indicating the length of the next line. Of course, for longer lines the lengths get into the ASCII range so they don't pop out as much. For example, a $3F (length 63) will appear in front of a 62 character line but shows up as a "?" in ASCII.

You could, of course, do the unpacking with any programming language. The procedure is pretty straightforward. I can upload a compiled version of the program if you like.

 

[jgrillout]

Yes, that's what the C++ program is for. You'll note that those $07 characters are all followed by 6 character program lines and then another byte indicating the length of the next line. Of course, for longer lines the lengths get into the ASCII range so they don't pop out as much. For example, a $3F (length 63) will appear in front of a 62 character line but shows up as a "?" in ASCII.

You could, of course, do the unpacking with any programming language. The procedure is pretty straightforward. I can upload a compiled version of the program if you like

your c++ code works like a charm! Thanks so much

 

[jgrillout]

Yes, that's what the C++ program is for. You'll note that those $07 characters are all followed by 6 character program lines and then another byte indicating the length of the next line. Of course, for longer lines the lengths get into the ASCII range so they don't pop out as much. For example, a $3F (length 63) will appear in front of a 62 character line but shows up as a "?" in ASCII.

You could, of course, do the unpacking with any programming language. The procedure is pretty straightforward. I can upload a compiled version of the program if you like.

regarding EXPORT2, I'd like to be able to specify an hostfile path. These attempts didn't work
EXPORT2 -e ACCTNO/WS:3 C:\TRS-II\IMDs\70050121\SOURCE\ACCTNO.WS
Error: File not found
TRSDOS READY
EXPORT2 ACCTNO/WS:3 C:\TRS-II\IMDs\70050121\SOURCE
Error: File not found
TRSDOS READY
EXPORT2 ACCTNO/WS:3 C:\TRS-II\IMDs\70050121\SOURCE\ACCTNO.WS
Error: File not found
TRSDOS READY
EXPORT2 ACCTNO/WS:3 SOURCE\ACCTNO.WS
Error: File not found
TRSDOS READY
PRINT ACCTNO/WS:3
TRSDOS READY

 

[gp2000]

This looks to be a bug I introduced in the emulator when I made FreHD support act more like the real device. Which sounds kinda lame but it was fairly complicated what with keeping a shadow copy of the directory tree shared with the emulator so that consistent 8.3 short file names would be presented. And also fake sector numbers for file contents.

Since this was broken post 2.4.5 you can use that or an earlier version to do your exporting. Older versions can be downloaded via the links in the on-line release notes:

http://48k.ca/trs80gp-release-notes.html

You will, of course, want to use the latest export2 and not the built-in one.

Meanwhile, I'll be fixing this bug for the next trs80gp release.

 

[jgrillout]

This looks to be a bug I introduced in the emulator when I made FreHD support act more like the real device. Which sounds kinda lame but it was fairly complicated what with keeping a shadow copy of the directory tree shared with the emulator so that consistent 8.3 short file names would be presented. And also fake sector numbers for file contents.

Since this was broken post 2.4.5 you can use that or an earlier version to do your exporting. Older versions can be downloaded via the links in the on-line release notes:

http://48k.ca/trs80gp-release-notes.html

You will, of course, want to use the latest export2 and not the built-in one.

Meanwhile, I'll be fixing this bug for the next trs80gp release.

OK thanks. It's not that big of a deal presently and would be nice to have whenever you can find the time. I really appreciate your response to my requests and questions. Maybe I will be able to meet you in person at a vintage event.