× 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, Scott Klement wrote:

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

Maybe using some mechanism similar to:

FILENAME=cat /dev/urandom

Obviously windows doesn't have /dev/urandom, but I think the same could be
done.  lp5250d creates a filename that has some random characters in it.

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

Yes, I was just making those up since I have no idea what constitutes a
command line argument in windows.  Isn't something like DOS switches?

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

The input file would not be specified since lp5250d would be creating a
file with a random name anyway.  when lp5250d starts scs2* it would modify
the command line to include the input filename.

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

By attach do you mean "put the functions in scs2pdf.c into lp5250-win.c"?

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

Again, I don't know how things really get printed in windows, so I was
mostly just seeing what might work.  AFAICT every windows application has
to know how to control the printer;  there isn't a way to say "print this
file" without starting some app to do the printing for you.

> > 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?

I didn't know redirection worked on windows.

James Rich
james@eaerich.com



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.