Subject: | |
From: | |
Reply To: | |
Date: | Mon, 20 Nov 1995 20:32:03 GMT |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
Steve Elmer ([log in to unmask]) wrote:
: Larry Byler ([log in to unmask]) wrote:
[...]
: : I have used FLABELINFO to detect a bytestream file *before opening it*,
: : so that I can use HPFOPEN option 77 during the actual open. I know that
: : works.
: I wouldn't recommend this. Usually, you should either open bytestream or
: not depending on how you want your application to be structured. That's
: the whole reason for the emulators in the first place. The primary
: exception to this is utilities that need to understand both views in the
: same program (i.e. MOVER, tar, ...).
Steve makes a valid point, which I omitted for the sake of brevity. In
my case (network printing), the file in question has been specified as
an ENV file, and we want the *result* of processing this file to be a
data bytestream sent to the printer without spooler-generated pen and
paper motion codes, and also without embedded spaces. We do not know the
record type of the user-specified ENV file, so we ask. If the file is
already a bytestream file, it's easy -- just open it as one and copy it to
the output. If it's in more conventional form (F, U, or V), we must process
it before sending it out. In that case, we open it without the special
(77,2) HPFOPEN option.
My earlier point was that the FLABELINFO-HPFOPEN sequence does work,
because I've used it. Clearly, other applications may derive more benefit
from using bytestream emulation.
-Larry "is the horse dead yet?" Byler-
|
|
|