Mar 4, 2008
Why Migrate Legacy Impact Print to AFP Impact Print?
Hello and welcome to AFP Tech, a new column here at OutputLinks. This column will deal with the technical and implementation aspects of AFP. This column is for the person who, ultimately, needs to make this stuff work and so we heartily welcome your comments, questions, or suggestions for topics of interest for future articles. Your humble columnists are Paul Kiel & Dave Webber, each with decades of real world HVTO experience.
The problem
Today there is a situation that is so common you could almost call it an epidemic, yet it remains mostly ignored in HVTO discussions. It’s hidden, almost covert, and yet so wide spread you could say that the only way to be sure you won’t deal with it sometime in the future is because you’ve already dealt with it sometime in the past. This is the scenario: You’re getting a new mainframe but it’s discovered that new central processing units do not come standard with S/370 channel adapters. Sure, you can order them if you really want them – for several tens of thousands of dollars. Do you really need channel adapters? If you don’t get them, how are you going to drive your S/370 attached impact printers? You’ve got AFP installed and running, but you’re driving laser printers with it. The stuff that’s printing on your channel attached impacts are multipart forms, odd sized forms, labels – output that would be difficult or impossible to move off impact printers which is why it’s still there. You seem to be faced with one of three options: Do you spend lots of money (in the form of hardware) on S/370 channel adapters?; Do you spend lots of money (in the form of resources) to migrate all that output to laser, if it’s even possible to migrate it in the first place?; Do you spend lots of money (in the form of hardware, software, training and resources) to bring up a software solution (with licensing fees, a new user interface and associated training for your operators) to drive LAN attached impact printers (new HW costs)?
Fortunately, there is another option for z/OS AFP shops that may be the best overall solution – migrating legacy impact print to AFP impact print. With appropriate planning (which is where this article comes in) the migration is relatively straightforward and the financials can be appealing.
Why even consider this?
Before we get into the migration aspect let’s spend a little time on why migrating to AFP impact printing might be the right choice in the first place. Most channel attached impact printers were installed when they were the workhorses of the datacenter and they handled the vast majority of the production output. Since then, however, much of that output has migrated somewhere else so you’ve got far more printer than you need. Additionally, this class of printer typically carries hefty monthly maintenance charges. Now consider this – replace your channel attached impact with a LAN attached AFP impact of lower speed, or consolidate multiple channel attached impacts into a single AFP impact: You avoid the pricey S/370 channel adapters on your new processor; The maintenance charges on the old printers will likely offset the purchase of the new ones; There’s no new software to purchase, install, and train your operators on.
Introducing Line-Mode Migration
What’s this about no new software you ask? Amazing but true if you are running PSF for z/OS version 3.2 or later. Friends, let us introduce you to Line Mode Migration (LMM, yet another TLA (Three Letter Acronym) brought to you by – who else? – IBM). “The Line-Mode Migration function can be used to print line-mode jobs on PSF-driven 64xx and 65xx printers in the same manner as jobs previously printed on a JES-driven line-mode printer”. LMM was announced July of 2000 (follow this link for details: http://www-01.ibm.com/common/ssi/index.wss?DocURL=http://www-01.ibm.com/common/ssi/rep_ca/8/897/ENUS200-228/index.html&InfoType=AN&InfoSubType=CA&InfoDesc=Announcement+Letters&panelurl=index.wss%3Fbuttonpressed%3DNAV002PT090&paneltext=Announcement+letter+search ) LMM is implemented in PSF exit 8. You’ll find the details to enable LMM in the PSF Customization Guide (chapter 25 in the PSF version 3 documentation ( http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi?CTY=US&FNC=SRX&PBL=S544-5622-04 ) ; chapter 27 in the PSF version 4 documentation ( http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi?CTY=US&FNC=SRX&PBL=S550-0427-00 )).
The promise of LMM is to move your impact printing output to AFP with no changes whatsoever. Just stop sending your data to the old printer and send it to the new one. No application changes. Custom FCBs? No problem. LMM, performing the HVTO world’s imitation of caterpillar to butterfly, eats the FCB attached to your job coughs up a functionally equivalent pagedef on the fly. Additionally, LMM determines the correct page length from the FCB and changes the setting on your AFP impact automatically.
Heads up
It may sound like you can turn on LMM and take the rest of the day off, but there are a few gotchas you need to lookout for:
LMM only works with FCBs: If your job calls a pagedef LMM is disabled. Unfortunately, you need not have a pagedef coded in your job’s JCL to have a pagedef invoked. Here’s why:
Let’s say you’ve got several forms that require 8 LPI. Long ago, somebody created an FCB and for these forms and called it STD8. Later, you installed AFP laser printers and some, but not all, of these jobs migrated to the new lasers. You needed an equivalent pagedef and you discovered that, happily, if you named your new pagedef STD8 also you didn’t need to change any of your JCL. If your JCL has an FCB=STD8 coded and you send it to your JES impact, JES dutifully grabs STD8 from the FCB library but if you send a job with FCB=STD8 to a PSF printer, PSF will use the pagedef (not the FCB) named STD8 from the pagedef library. You get ease of migration and the possibility of one printer backing up the other all at once.
Now you’re trying to send a job with FCB=STD8 to an AFP impact printer. PSF, still being PSF, sees the FCB=STD8 and instead of grabbing the FCB grabs the pagedef (pagedefs are supported on AFP impact printers), which disables LMM. The most likely symptom that you will see in this scenario is that the page length will not be set correctly on the impact printer (LMM sets the page length if it’s running; a pagedef doesn’t set the page length).
How do you resolve this? Probably the most straightforward way is to code a formdef to set the page length and add them to the JCL for the jobs that have FCBs with identically named pagedefs. Another way would be to place all pagedefs with the same name as an FCB into a separate library, then edit the PSF startup proc for your impact printer and leave this library out of the pagedef library concatenation list.
Newly Live Parameters: The facts, friends, are these: Your current print driver (JES) is fairly dumb, but that’s fine since it hangs out with printers that are even dumber. Many parameters on the OUTPUT JCL cards are simply ignored by this pair because they don’t have a clue what to do with them. But now you’ve installed a print driver (PSF) and a printer that are members of Mensa wing of HVTO. Every parameter that was ignored before is suddenly acted upon and you can end up with output is anything from slightly wrong to completely absurd. Additionally, PSF has a prioritized search order for parameters, so even though the parameter may not exist in your job’s JCL it might exist somewhere else and be acted on just the same.
Let’s take an example. You’ve got your new AFP impact printer installed. You create a PSF startup proc for it by copying the one you use for your IP4000 and making a few changes. You’ve turned on LMM and sent some data but your output prints at 12 CPI instead of 10 CPI. You check the JCL for the job and you can’t find anything that could cause this situation. What’s going on?
Most likely, the IP4000 startup proc has a default font specified that is causing the problem. The easiest way to fix this is to set a UCS=0 or UCS=GT10 in the JES printer definition. You may need to make other adjustments to the JES printer definition, the startup proc, and occasionally a job’s JCL, depending on your installation. Remember, if you decide to add a pagedef and formdef to your job to resolve your problem you disable LMM and are responsible for setting the correct forms length.
Enormously Misaligned Forms: A hundred years ago when that legacy application came on-line it was discovered that, for whatever reason, the data wasn’t even close to landing on the right spots on the preprinted forms. Somebody then made the decision to fix the output with the print operators instead of with the application programmers. Ever since that day the print operators have been dutifully putting this form in and sliding it too far to one side or too far up or down by several inches. Now you’re smart AFP printer wants to put the data on the page where the application says it should go, not where it really should go.
You’ve got two ways to fix this: Either track down the clay tablets upon which the original source code was carved and make the appropriate updates (the hard way) or, code up a formdef and pagedef for your output (the easy way) but, again, you must be careful to set the forms length since LMM won’t be running.
The plan
Armed with the above information, do the following:
· To avoid accidentally invoking pagedefs: Take a look at your FCB libraries and pagedef libraries and look for identically named objects (remember, the P1 pagedef prefix is ignored) then either code up formdefs as necessary and add them to appropriate jobs or shuffle the offending pagedefs into their own library and do not concatenate that library in the impact printer’s PSF startup proc.
· To avoid strange output from newly live parameters: Carefully scan the PSF startup proc for the impact printer looking for anything that meddles with LPI, CPI, chars, etc… The most common offenders are the JES parameters of CHARS, UCS, and FCB.
· To avoid being surprised by enormously misaligned forms: Take a walk down to the datacenter and spend some time with the channel attached printers and the printer operators. Check these printers for homemade alignment marks labeled with form names (for example, you see a piece of tape on the printer with a form name and a line drawn several inches away from the printer’s top of form mark). Ask operations to explain anything you find and flag these forms as problems. You’ll probably need to create a pagedef and formdef for each.
Start your testing
Once you’ve taken the above steps then turned on LMM and start sending your output to your new AFP impact printers. You’ll find that you’ve already taken care of most of your issues before they happened.
Summary
There are plenty of mainframes that have S/370 channel attachments for only one reason – legacy print. To avoid the expense of these channel adapters, datacenters entertain several different alternatives, one of the most viable but least talked about is migrating legacy impact print to AFP impact print. Implementing AFP impact print can help your company avoid S/370 channel features on the new processors; replace older impact printers with newer AFP impact printers; and avoid new software, a new user interface and training for the operators.
The cornerstone of any migration to AFP impact print in z/OS shops should be LMM. Although LMM may not handle the entire migration, with proper planning a significant percentage of the workload can be moved easily and quickly. Additionally, any jobs that aren’t candidates for LMM can be identified early in the project and custom pagedefs and formdefs can be created well in advance of any deadline, helping to bring your migration effort to completion on time and within budget.
Need additional information on what you’ve just read? Got a question in some other area of AFP technical support? Do you have some AFP trick you’d like to share with the world? Is there a topic you’d like to see us cover? Just drop us a line at AFPTech@OutputLinks.com.