|With 6.1, PDF Capability Is "Pretty Darn Fast"!|
|Application Software - Document Management|
|Written by Steve Pitcher|
|Monday, 12 April 2010 00:00|
Amid as much highly publicized fanfare as a Tax Accountant of the Year convention, IBM quietly slips us the ability to natively generate PDF files on i.
You don't need a third-party tool, custom coding, or even InfoPrint Server. It's as simple as loading a few licensed programs and then adjusting a couple of parameters on pre-existing IBM print commands.
What Do You Need to Get Started?
In order to start generating PDF files, you have to install a few licensed program options:
All of these options are at no cost and ship with the 6.1 media. As with any product installation, I would advise you to get current with your fix packs. It wouldn't be a bad idea to install the latest Cumulative and Print Group PTF packages.
How Do You Generate a PDF?
It's very easy. So easy, in fact, that it makes you wonder why it took so long for IBM to make this feature available. I'm really sounding like a user who doesn't know what magic had to happen behind the scenes to make this feature available. A team of developers could've been on this for a long while, or perhaps there were better and more important things to do. Either way, it's too bad that IBM did not have this rudimentary capability available already.
However, I'm not going to look a gift horse in the mouth here, so thank you very kindly, Big Blue.
To generate a PDF, you can use one of the following commands:
Parameters required to generate the PDF are DEVTYPE, WSCST, and TOSTMF.
DEVTYPE (Device Type)
This parameter must be set to *AFPDS as the AFP data stream can only be used to generate a PDF.
WSCST (Workstation Customizing Object)
This parameter, when set to *NONE, means no conversion is performed and the file is sent to a stream file as an .afp file. When set to *PDF, it allows conversion of the output to PDF before it's written to a stream file.
The customizing object qualifier can be one of the following. I'm paraphrasing from the V6.1 Information Center here.
TOSTMF (To Stream File)
This parameter is the target directory or directory/name combination of your to-be-generated PDF file. If you specify just a directory, the PDF will be generated with a unique name. If you specify a directory/name, then the PDF file with the same name must not already exist in that directory. There's no ability to overwrite an existing PDF, which would be a nice option. Of course, you must have authority to write to the IFS directory. Also, you must ensure that the IFS directory exists in advance as there is no automatic creation of IFS directories. Good thing too…just imagine the file-system-management nightmare that would be.
DEVTYPE, WSCST, and TOSTMF All Together
If you have existing applications that use the OVRPRTF command (a fairly likely scenario), you could alter them to generate PDF files quite easily. A sample command would look something like this:
OVRPRTF FILE(testfile) DEVTYPE(*AFPDS) TOSTMF('/pdfdir/testfile.pdf') WSCST(*PDF)
This command will generate a new file called testfile.pdf in the pdfdir directory on the root of the IFS. It's incredibly fast, simple, and useful.
Great! But How Does It Stack Up Against InfoPrint Server?
It doesn't. Not by a long shot, and that, I'm sure, wasn't the intention. This feature just gives you the ability to generate a simple PDF and store it on the IFS. But that's not a bad thing. In fact, it's a great step forward.
InfoPrint Server is an entirely different animal. A propane torch compared to a pack of matches really, but both can serve very important but incredibly different functions. InfoPrint is an enterprise-level solution that gives you much greater control of PDF generation features, plus scheduling and distribution mechanisms, and much, much more.
What About Other Free Tools?
I've used the CVT2 tools on www.code400.com, and I have nothing but good comments about them. Actually, I put together and regularly use a custom Work with Spooled Files (WRKSPLF) screen with an additional option to convert pre-existing spooled files to PDF using some of the code on that site. Examples on Code400, and other sites as well, will show you how to do the same thing and much more (i.e., converting spooled files to HTML, converting DB2 records to many different formats, etc.).
In an age when computer systems must talk many different languages to communicate with each other, independent communities of programmers have created free tools to do these types of conversions that IBM has unfortunately dropped the ball on. Perhaps that's why this simple PDF feature has been put in place well under the technical community's radar.
This new native PDF ability is free, so I'm not complaining. Would I have IBM take it a little further? Most definitely.
We've been using the IFS in our shop for seven or eight years now. It's used as a big honkin' file server for multiple companies, departments, groups...any way you can slice it, we've done it. We have a very well-thought-out file system design that works for us, so utilizing this feature will be a snap.
What if you don't currently use the IFS? Is all output either currently stored as a spooled file or sent directly to a printer?
If you're thinking about putting PDFs on the IFS, you need to open it up to your users to go and get them. Now you need to really think about managing the IFS like any other file server.
You'll need to think about how these stream files are affecting your system. The GO CLEANUP menu may delete old spooled files, but it won't remove PDF files in a directory or a variety of directories. These files can get out of hand if not managed properly. You may want to investigate incorporating user storage quotas and a custom stream file cleanup program. Otherwise, users will never clean them up. You can take that to the bank, deposit it, and collect minimal interest on it while your system becomes a PDF graveyard.
If you use a different pre-existing file server (i.e., a Windows machine used solely for user file storage), then you could always save these PDF files to that file server instead. You can access this file server via the IFS QNTC directory in your OVRPRTF command. Assuming your file server is called "winxyz," you can change the TOSTMF parameter to access and store the PDF there, instead of the IFS. Here's an example:
OVRPRTF FILE(testfile) DEVTYPE(*AFPDS) TOSTMF('/QNTC/winxyz/pdfdir/testfile.pdf') WSCST(*PDF)
I'm not sure if accessing QNTC is supported with this command (IBM has frowned on using it in some instances and praised it in others), but I bet it would work like a charm. Unfortunately, I haven't found any documentation on it in this type of scenario.
What about security for directories you create? For instance, if you change the monthly 500-page payroll print job to go to the IFS instead of going to the IBM 6400 line printer that's behind a locked door, you'll have to mimic the function of that physical door with directory security. Plus, you have to be cognizant of the fact that PDF stands for Portable Document Format. A PDF is far easier to inadvertently distribute and lose track of than a 20-pound stack of green-bar paper.
With All That Said…
Give it a whirl! You can quickly and easily get started just to see what possibilities there are with this new function. If users like what they see but want a more feature-rich solution, you may have a business case to investigate InfoPrint Server. If you're a fan of DIY, you can do a little Web crawling and put together a custom solution that fits your needs quite quickly.
|Last Updated on Monday, 12 April 2010 00:00|