Sometimes you need to do complex things with your prints, and PJL is one way to get it done. But how do you incorporate a PJL script into an i job stream?

As explained in my previous TechTip, Printer Job Language (PJL) allows you to control how the printer reacts to jobs you submit. Now the truth is that many printers will automatically figure out what the heck is going on, but not all will. As you try to use many different types of printers to carry out your assignments, you may find yourself in need of the ability to tell the stupid printer what to do. A good example might be if you wanted to add a copier to print output from the IBM i.

In the first installment of this topic, you found out how I feel about printers in general, what PJL is and when it can be used (when you are connected via TCP/IP), and how to construct a PJL script to recognize the Printer Control Language (PCL) that's being used to describe the print job you're screwing around with.

What I want to talk about now is what happens after you write the PJL script. It's not like it just works. Oh, no, that would be too simple. Instead, you need to go through a number of steps to get it loaded into the i and be effective.

Workstation Customizable Object

It's amazing how many things in the technical world can be identified by three-digit acronyms. Why three digits? Does it relate to baseball (three bases, three strikes and you're out, three sets of three innings in a game)? Is it religious or mystical? Or is it just that four words would be too much to remember and two is too few to say anything meaningful?

Whatever the reason, the starting point is to create a Workstation Customizable Object (WCO) in which we insert the hex values of the PJL script we created last month. And you create a WCO using the (big surprise) CRTWSCST command. The twist here is that you don't just create this; you have to create it from a source file.

And where do you get the source file? Well, you can create it yourself, but doing so is a task beyond the scope of this tip. Or you can choose one of the source files that have been set up on the i. To see what's out there, you would use the RTVWSCST command. To use this, enter this command:

            RTVWSCST *TRANSFORM

Then hit F4 to prompt.

The next parm you need to enter is the Manufacturer Type and Model, entered as one string with an asterisk (*) in front of it. So, if you wanted to look at IBM4232s you would key in this:

*IBM4232

But don't hit Enter yet. If you're not sure what models and manufacturers are available, you can hit F4 on this field and see a list.

The last thing you need to enter is the member name of the file where you want the source data to go. It should be in a QTXTSRC file, but it can go into whatever member and library you would like.

Now you can hit Enter, and when you look at the text source file you have created, you will see the source you need for the WCO.

Converting Your PJL Script to Hex

We're getting closer to being able to do this. The next step is to take the PJL script that we created in the first part of this article and convert it to hex.

That's right. The WCO will not take regular ASCII; it must be in hex format. Fortunately, there are several ways to do this.

One is to just key in the hex equivalents of all of the characters in your JPL script. Admittedly, that's not the most fun way.

Another option is to use a hex translation website like www.asciitohex.com, which lets you key in an ASCII set of characters and convert that to hex in one fell swoop. This would be my choice.

Once you have the hex version of your PJL script, you're ready for the final step.

Inserting the Hex PJL Script into the WCO

The next step is pretty simple. All you have to do is find the INITPRT section of the file (probably about halfway down), take the hex version of the script, and insert it in place of what is currently in the DATA parm. Save the file, and you're ready for the next step as the source file has now been created.

Once the source is set, you can use the CRTWSCST command to create the WSCST object based on the source file.

If you're creating a new printer definition, then you attach this to the printer by using the following parms.

TRANSFORM(*YES)

MFRTYPMDL(*WSCST)

WSCST(libl/source file)

These commands will ensure that Host Print Transform (HPT) is turned on to convert the IBM print data streams to PCL, that the manufacturer type and model is set by the WSCST, and that the system knows where to get the actual WSCST object. If you're changing an existing printer, you'll have to end the writer (ENDWTR), vary off the printer (VRYCFG), and use CHGDEVPRT to set the parms above.

This same type of setup can be used not only to change the print control language for various jobs, but also to activate punch or staple.

Drawbacks

So PJL is pretty cool, eh?

Well, yes and no. It does allow you to do some pretty advanced functions that you can't do with a straight OVRPRTF or CHGSPLFA command. But it does have its drawbacks.

Probably the most significant is that you can have only one WSCST object associated with a given printer. So, if you want to be able to staple only, or punch only, or staple and punch both, then you really need three separate WSCST objects along with three separate print devices. Not exactly an ideal situation. And, if you have any bugs in your PJL script, they'll prevent the whole script from running, so you want to test carefully.

But as I said, it does allow you to do some pretty advanced things, and it might be just what you need to do a particularly pesky print job.