PrestoSoft Community

Where I used to work, we used Beyond Compare. Where I am now, they have Exam Diff (I think Pro, but I'll check tomorrow).

We used/use software called Mainframe Express that creates EBCDIC files based on a special layout that's "hidden" in a proprietary catalog.
At my previous job, I had already written a plug-in for BC that could analyze the catalog and extract and convert the data (*.DAT files) from EBCDIC to ANSI. All works fine.

Now I am playing with doing the same thing in Exam Diff. I've "almost" got it working, but I'm obviously missing something rather trivial. I'll start with the various screen captures. (2 of them failed to attach, so I'll append them in a reply to this append).

One is obviously the settings for the plug-in in Exam Diff. One thing that not's obvious - at the moment, I'm hard-coding the output file for the conversion as being c:\temp\temp.txt. As the temp_txt_created capture shows, this is created by my code. Should I be setting it to something else on the settings panel ?

Two of the other captures show the "half-way" messages shown by Exam Diff as a result of my settings being incorrect ??

The exam diff results shown capture shows what is shown in the resulting ED window.

Finally, the temp_txt_created capture shows that my program HAS created an output file, but somehow, ED doesn't realize that it needs to read this file into memory.

Can someone help point me in the right direction.

BTW. Is there some sort of setting in the arguments that can indicate whether the plug-in is being called for the first or second file ?

Thank you (I'll continue experimenting in the meantime to see if I can get to a solution).

Reading through my first append, I thought I'd clarify my first append.

Basically:-

• should I use an output file parm in the ED plugin settings?

• whether I do or don't, how does ED know the name of the output file?

• how do I get ED to recognize/read in the file created by my plug-in

I'm sure the answer is REALLY trivial, but so far it eludes me.

One final (?) append. I removed the output file on the options settings, so now I have arguments = $INPUTFILEPATH only.

I'm now seeing the attached capture. So .... how do I point at the file that ED should be reading?

Thought I'd include one extra screen capture (this was found in C:\Users\Michael\AppData\Local\Temp).
Seems to show that SOMETHING is being created/used, albeit with no content.
I should mention, maybe, that my plug-in READS the input file, converts from EBCDIC to ANSI and WRITES the resulting conversion to an OUTPUT file.

The EDP Help screen for plugins suggests that if you just provide $INPUTFILEPATH then the plugin needs to write its output to stdout; does your one do that? Presuambly EDP then captures that using file redirection (so you needn't ever know the name of any of the output files).

I don't think a plugin that writes to a fixed-name output file is any use, because presumably the plugin will be run twice, once for each of the files being compared, so you'd need two output files.

Thanks Jeremy - I'll test tonight and let you know.

Okay, have tested a bit more at home, and this is what I'm seeing. First of all, I realize/appreciate that the following comments are a bit "apples and pears" (no pun intended based on ED's icon).

In Beyond Compare, I specify the plug-in in the following manner

H:\A_MS_exe\BC_CONVERT_MFE_FILE.exe %n %s %t

where %n %s and %t are defined as

%s source file
%t target file
%n original file

When I then run Beyond Compare and trace the input parms, the BC startup parms are shown in the attached screen capture. Note how the third parm (target file) is some sort of temporary file (I haven't defined it in any way)

With ED, I have ONLY specified (rightly or wrongly) $INPUTFILEPATH . The resulting parms are shown in the second capture. Note that when I added an output file as $INPUTFILEPATH, $OUTPUTFILEPATH (with or without the comma), NO output filename was passed to my plug-in.

I have tried sending the output to STDOUT, but it doesn't SEEM to be getting picked up and used. Any suggestions as to how to proceed gratefully accepted. Is there a way of tracing what is written to STDOUT that I'm not aware of ?

I'm not sure, maybe I missed it, but what are your plug-in's command line parameters? EDP can accommodate both stdout and file output form a plug-in app.

Basically, anything you like. The SIMPLEST would be to be able to specify an output file that ED then picks up and reads in and shows.

What seems to be the problem is that I can't seem to specify some sort of output file as an argument that is then picked up in ED the same way it is in BC.

Can you provide an example of your command line and execution (console window)?

Hmmm, not sure what you mean there.

The EXE is compiled Rexx on the PC. A (hopefully) similar Rexx script looks like this:- The screen capture (SC) shows how I called the EXE from a DOS window (using test1 argument1 argument2) and the results written
to STDOUT. (The double ended arrow ISN'T supposed to be there, not sure where it came from)

Assuming that test1 is the app (executable file), what are argument1 and argument2? I was hoping for a real world example, with actual, presumably, file names and the output.

I remembered having seen EBCDIC somewhere in EDP, even if I never used EBCDIC in my last 40 years of computer use...
EBCDIC is indeed handled, but only in the binary compare.

I can't seem to specify some sort of output file as an argument that is then picked up in ED the same way it is in BC.

"specify some sort of output file"? Don't!
Use the default. That's all.
I don't see where the difficulty lies: simply read a line from the input file, transcode it and write it to the default device (stdout: usually the screen).
If I'll have a little spare time I'll write it myself.

In screenshot: BC_startup_parms.jpg
the BC plugin has 3 file paths as parms, and for reasons that make no sense to me the first and second of them look the same.

You also suggest that the BC plugin is used like: H:\A_MS_exe\BC_CONVERT_MFE_FILE.exe %n %s %t
where %n %s and %t are defined as %s source file %t target file %n original file

- so does that mean the BC plugin gets handed both of the files that are being compared? If not, what did source/target/original mean?

But in: Exam_diff_plug_in_settings.jpg
you show settings with only two filepaths?

I would have expected either the new plugin to take a single filepath as its sole argument, read and process that file, and write a converted file to sysout, OR it to take two filepaths as arguments, then read the first one, convert it, and write output to the second one.


Surely (in EDP) a plugin only processes a single file at a time?

Surely (in EDP) a plugin only processes a single file at a time?

You can actually use the opposite file path as a plug-in argument: $OPPOSITEFILEPATH.

> You can actually use the opposite file path as a plug-in argument: $OPPOSITEFILEPATH.

So, in that situation would EDP call the plugin twice, the first time for: lefthandfile vv righthandfile, and then for: rh vv lh?
Or just once?