> Does anyone know how to send a true type font (binary physical file or IFS
> file) to a TCP attached printer natively, without using third party products
> or additional licensed programs or writing their own programs.

Why this restriction?   I could write a very simple ILE RPG program in
2 minutes that would solve the problem.


> Using the CPYF font.ttf  *PRINT might work with the right overrides or *PRTF
> but I am fuzzy on this.

I don't see how.  CPYF copies DB2/400 file, not a stream file.  I suppose
you could try converting the file...  Still, you wouldn't want *PRINT,
that converts the data to text...


> This really old DOS PC coomand works using a binary copy:
> COPY /B selectfont.bin \\myserver\myprinter
> COPY /B font.ttf \\myserver\myprinter
> COPY /B makeperm.bin \\myserver\myprinter

This code looks to be a workaround for the fact that some MS-DOS software
doesn't send font information to a printer. Frankly, this is an ugly hack
in the first place.  Why do you want to perpetuate it?

Wouldn't it make more sense to create a WSCST object that sends the font
so that the font can be selected using the regular FONT keyword in DDS?

> the cp command in QSHELL does not seem to be able to address iSeries printer
> devices or queues for output? can they?
> I would use an environment variable QIBM_QSH_CMD_OUTPUT('DEV=PRT01')
> If that was legal.
> I would be nice if this would work;
> addenvvar QIBM_QSH_CMD_OUTPUT('FILE=qsys.lib/qusrsys/qsysprt.file')

No.  That would NOT be nice.  First of all, and environment variable is
just that -- a variable.  Let's not add sub-variables inside a variable!!

For example, this is the QShell command to set the variable, as it is now:

   QIBM_QSH_CMD_OUTPUT=Y

You seem to be suggesting making the following into valid syntax:

   QIBM_QSH_CMD_OUTPUT=FILE=qsys.lib/qusrsys.lib/qsysprt.file

I'm sorry, YUCK.  If you must do this with environment variables (which is
illogical to me, to say the least) at least create a new variable, rather
than trying to stuff multiple sub-variables into a single variable.

However, I'd submit that a better future enhancement would be to allow
QShell commands to redirect into a printer file.  For example:

cat my_file.txt > /qsys.lib/mylib.lib/myprtf.file

Or, for your situation, if you wanted to send binary data to a printer,
you'd do this:

cat -c selectfont.bin > /qsys.lib/mylib.lib/myusrasc.file

Where "myusrasc.file" was created with CRTPRTF DEVTYPE(*USERASCII).  The
-c switch to cat prevents it from converting the data to text, and the
DEVTYPE(*USERASCII) tells the system to send the data to the printer as-is
without any sort of interpretation, transformation, modification, etc.

Hopefully I was clear... the above code will NOT work, it's intended as a
suggestion for a future release of QShell.

What you MIGHT be able to do is use the "cat -c" utility that I displayed
above to a PF, and then use CPYF to go from the PF to the PRTF.  Do *NOT*
however, use *PRINT on the CPYF.  Instead, do something like:

   CRTPF MYLIB/MYPF RCDLEN(132)
   QSH CMD('cat -c selectfont.bin > /qsys.lib/mylib.lib/mypf.file/mypf.mbr')
   OVRPRTF FILE(QSYSPRT) DEVTYPE(*USERASCII) CTLCHAR(*NONE)
   CPYF FROMFILE(MYPF) TOFILE(QSYSPRT) FROMRCD(1)
   DLTOVR QSYSPRT

I havent tried that code, but it might work... worth a try, unless you
think it's too much like writing a program.

> How can I do this on a V5R2 modern machine without finishing the RPG
> program I am writing to do it?

If you ARE going to write a program, though, you should use the IFS APIs
to read the stream file in binary mode and copy the data directly to a
userascii printer... again, userascii means that the system will send it
as-is.

I wouldn't try to incorporate that into another program, but rather make
it a standalone program that can be used to copy any stream file in binary
mode to a printer.  Then it can be used in CL programs or QShell programs
(depending on your requirements and how you design the program) as needed.

Personally, though, I'd vote for creating a WSCST object.



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.