Re: [LINUX5250] Porting scs2* to windows

[Scott Klement <klemscot@xxxxxxxxxxxx>]

On Tue, 19 Mar 2002, James Rich wrote:
>
> Would porting to windows be easier if the following could be done:
>
> 1.  lp5250d always writes the SCS stream received from the iSeries to a
> temporary file, say c:\tn5250\tmp\lp5250d123.scs

Yes, but it would need to do something to make sure that if two copies of
lp5250d are running, they don't both try to use the same temp file.

> 2.  After writing to the temp file is complete, lp5250d calls the
> appropriate conversion program with the temp file name as an argument and
> the destination file name as another argument, something like:
>
> scs2ascii --infile=c:\tn5250\tmp\lp5250d123.scs
> --outfile=c:\tn5250\tmp\lp5250d123.txt

That would work, but:

     1) I'd use the same style command-line arguments that you use
            in tn5250 and lp5250d, for consistency.

     2) This would make the configuration a lot more complicated
            because you'd have to specify all of the arguments in
            your outputcommand= config keyword for lp5250d.   It
            would make sense to those of us who know how it works,
            but seem unnecessarily convoluted to everyone else.

In any case, it seems unnecessary.  You'd still need a way to get
the data to the printer.  Sure, I could write my own "lpr" command for
Windows, but that wouldn't be intuitive to your average Windows user.

I'd rather make the lp5250d command under Windows able to attach to
the scs2pdf routines, or the scs2ps or scs2ascii as needed, and then
receive the data back and write it wherever I want.

Then I could bring up the standard Windows dialog box to prompt
the user for a file, or printer, etc. if I wanted to.

>
> 3.  scs2* work basically unchanged from what they are now, except that
> they can read from a file in addition to stdin and output to a file in
> addition to stdout.

We could do that with redirection, couldn't we?

>
> 4.  After scs2* is done, lp5250d deletes the temporary file
>

Unless it crashes :)

> I have no idea if these suggestions are any good, or if performance would
> be any better or worse than using a pipe.  I also have no idea how to do
> step 2 on windows (how do you pass arguments to programs on windows?).

The same way you do on Unix systems, except that in a Windows program
you receive a pointer to the entire command string instead of having it
seperated into argument vectors.   But the routines to parse it out are
already written and active in the Windows port.

> But if these steps are possible I think they would make porting far easier
> since scs2* would be basically unchanged.
>

Easier, yes.  :)