Hi Mitch,
I understand your troubleshooting logic and agree with you completely.
I went through your steps as listed and each file was created without
errors. It's just that when my complete command is placed within the
.tn5250rc file that the shell seems to be interpreting something
differently that would be expected.
Hmmm... that's an interesting tidbit! It works when done manually...
lp5250d uses the popen() API to launch the output command. You might
try "man popen" to see if there are any caveats on your particular
system... On my system (which is FreeBSD, not Linux) the man page says
that popen will start a new /bin/sh shell and pass the command to it via
the -c switch. Therefore, whatever command-line you code has to be
compatible with /bin/sh. But, of course, I don't know if your system
works the same.
Also, depending on how lp5250d is invoked, it may not have the same PATH
that you have. This might contribute to the problem... maybe it's not
finding something that it needs?
Perhaps the easiest fix is to write a shell script that runs all of the
steps, then invoke the shell script from the .tn5250rc file? That way,
you can use #! at the top of the script to control which shell it runs
under, you can insert extra diagnostics into it (such as logging the
PATH it uses, logging errors, etc, to a file in /tmp or something like
that) and you can even set the PATH to be used... Then test it from
the command-line as well as from lp5250d, and hopefully get everything
working.
It also makes it easier to code additional printers, since you don't
have to repeat the whole (rather complex) command-line, you can just run
the script.
tiff {
host = systemi.example.com
env.DEVNAME=TIFF
env.IBMMSGQNAME=QSYSOPR
env.IBMMSGQLIB=*LIBL
env.IBMMFRTYPMDL=*WSCST
env.IBMWSCSTNAME=QWPTIFFG4
env.IBMWSCSTLIB=*LIBL
outputcommand=scs2ascii>/home/myuserid/test.tiff
}
Yeah... I want to chew my foot off just thinking about having to learn
the process you just described. ;) As I stated in my original post, I
know very little about the iSeries OS but I do hope to get more involved
in the future.
Okay, here's a bit of background.
The name "System i" is a generic name intended to refer to whole family
of servers, including AS/400, AS/400e, iSeries and i5 machines. Most
System i machines run an operating system called OS/400 in older
releases, and renamed to i5/OS in newer releases. It's the same OS
whatever you call it. The System i is also capable of running a
"virtualized" environment where many operating systems can run
simultaneously. Kinda like running something like VMWare or QEMU on
Linux, except that the machine is designed to run it from the ground up,
so the performance penalities aren't so severe. In that environment,
the System i can run Windows, Linux, and AIX operating systems, each in
it's own "Logical Partition" (or LPAR for short). Some people use this
feature, some people don't.
Since you're using lp5250d and tn5250, I'm assuming that your concerned
with i5/OS (or OS/400) and not with LPAR stuff.
i5/OS has strongly typed disk objects. For example, on a Linux system
you might refer to every disk object as a "file". You might say that a
program is stored on disk as a "file" and a picture (like a TIFF) is
stored in a "file". On i5/OS, objects are more specific than that.
There are programs, files, service programs, libraries, output queues,
device descriptions, and many other types of disk objects. In i5/OS
terminology, if you refer to a "file" you're specifically referring to
something that's used to read/write data. You'd never refer to a
program as a "file". The generic term for any thing on disk is
"object". So if you don't want to be specific about something being a
file, or program, or device, etc, you just refer to it as a "disk
object" or "object".
When a program generates a printout, it writes it to a special kind of
file called a "print file". The print file specifies the formatting of
the document. For older documents, it contains only a basic set of
information, what font to use, whether it's portrait or landscape, where
to spool it, what the page dimensions are, etc. For newer documents,
you can put a lot more detail in the print file, such as where to print
things on the page, individual fonts for different parts of the page,
graphics to be printed in the page, barcodes, etc... all specified in
the print file.
When the program runs and writes the report to the print file, the
system will generate a file in the spool, and queue it to be printed
when the printer is available. The data in the spool is almost always
written in one of two formats... *SCS and *AFPDS. These are the "old,
rather flat, plain-text format" (SCS) and the newer, more graphically
rich format (AFPDS). These are the only two formats that the system
understands. The advantage of normalizing to these formats is that
users can see more about the spooled files (another special type of
file) while their in the spool. They can view the contents of the
documents, see how many pages there are, change the printed page range,
etc... they can do all of this because the system understands the format
of the file.
When the printer is ready for the documents, a program called a "print
writer" (though, many refer to it as "the writer") copies the data from
the spool, optionally transforms it to the printer's language, and sends
it on to the printer. When you're working with a printer that doesn't
understand SCS or AFPDS, you pretty much have to transform it
somehow... Either you have to have software/hardware on the printer
side of things that can convert the SCS or AFPDS to the printers
language, or it has to be done in software on i5/OS (i.e. a print driver
that's run by the print writer)
lp5250d has some limited software that can handle the transformation on
the PC side of things. scs2ascii converts SCS documents (but not AFPDS
documents) to plain ASCII text. That means that you lose most of it's
formatting as defined in the print file, because plain ASCII text only
has CR, LF, TABS and FF as control characters, it doesn't have much
else. scs2pdf converts to PDF format, which has a lot more controls --
and makes scs2pdf a much more complex program. scs2ps is a quick
proof-of-concept program that hasn't seen much testing, development or
use, so is very limited. There's no software in lp5250d that
understands AFPDS documents.
But, if you want the more advanced features of the operating system, you
can tell the print writer to transform the document from SCS or AFPDS to
the printer's language. This way, lp5250d doesn't need to do it. In
that scenario, you enable something that IBM calls "Host Print
Transform" in the print writer.
How does the print writer know the attributes of the printer it's
sending to, and how does it know whether to perform host print transform
(HPT) or not? There's another disk object called a "Device Description"
(or "DEVD" for short) that contains information about each device on the
system, how it's connected to the system, etc. The system also has the
ability to auto-configure devices (though, this can be turned off). In
the most typical scenario, the devices from lp5250d and tn5250 should be
auto-configured. Since all of the devices we use are "virtual devices"
(meaning that they're not actual hardware devices connected directly to
the System i, but rather are software devices created by computer
programs) you can enable auto-creation of virtual devices by setting the
QAUTOVRT system value without affecting anything else -- but... I'm
going off on a tangent.
When auto-creation of devices is enabled, the system can take hints from
the software that's connecting to it -- in this case, tn5250/lp5250d, to
describe what sort of device is connecting. Let's go back to my sample
.tn5250rc file for a TIFF image:
tiff {
host = systemi.example.com
env.DEVNAME=TIFF
env.IBMMSGQNAME=QSYSOPR
env.IBMMSGQLIB=*LIBL
env.IBMMFRTYPMDL=*WSCST
env.IBMWSCSTNAME=QWPTIFFG4
env.IBMWSCSTLIB=*LIBL
outputcommand=scs2ascii>/home/myuserid/test.tiff
}
All of the variables that start with "env" are not actually understood by TN5250/LP5250D. Instead, they're passed along to the System i as telnet "environment variables". This is how we specify hints for the device description creation on the system i.
env.DEVNAME tells the system what we want the device's name to be.
env.IBMMSGQNAME and env.IBMMSGQLIB tells the system where to send messages related to printouts, such as "change forms" or "an error occurred while printing", etc. In this case, I've told it to send to the QSYSOPR message queue which is a generic place for messages intended for the system operator. It's kinda like sending a message to /var/log/messages on a Unix system. (or at least, that's what we use on FreeBSD)
the env.IBMMFRTYPMDL tells the system which manufacturer, type & model to use for host print transform. In this case, I've told it to use *WSCST which is short for "workstation customization". It's a way of saying "I'm not going to tell you the printer manufacturer, instead, I've created a custom driver I want you to use".
The env.IBMWSCSTNAME and env.IBMWSCSTLIB tell it the object name and library of the custom driver. In this case, I've specified QWPTIFFG4 which is an IBM-supplied custom driver for creating TIFF/G4 output. Unless you're running a very old system, this should automatically be on your system, it's included with the base OS.
The special value *LIBL means "library list", which is analogous to the PATH that's used on Unix and Windows systems. It's a list of libraries (which are like directories -- NOT like libraries on Linux) to search for the object to be used. So I've told it to use the library list to locate the QSYSOPR message queue, an the QWPTIFFG4 program, which should be a no-brainer, since it's part of the operating system, and therefore is always in the library list. (Much in the same way that /bin is always in the Linux PATH... knock on wood)
So.. it's that simple, I've told lp5250d to give these hints to the operating system. The OS will create a device description that specifies that the printer understands TIFF/G4 format. When the print writer takes data from the spool, it'll transform it from SCS/AFPDS to TIFF/G4 format and send that to lp5250d. Perhaps strangely, it still escapes that TIFF/G4 code inside the SCS data stream (in "transparent data" tags), so you still need to use scs2ascii to extract it... I then save it to a TIFF file in my home directory.
So there's some significant value to using this transform technique... first, it understands AFPDS with all of it's graphic capabilities, and second, it allows each individual program on the System i to control it's output independently of the others.
But, if all of your documents are SCS documents (which are pretty much plain text, anyway... you can set a font, and you can set things like portrait/landscape, but whatever you set applies to the whole document, the whole document is in the same font, etc). It might be more convenient to strip out the formatting via scs2ascii, and then do a separate transformation on the Linux box, that way you can set all of the settings in ONE PLACE instead of in many individual print files for each individual program. If that makes sense.
Anyway, hope this description is useful.
midrange.com
