× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




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.  :)




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.