Externally Described Printer Files vs Internally Described Printer Files

[Guest.Visitor]

Many of are existing programs currently utilize Internally Described Printer Files (O-Spec). We have one new individual that we have hired that only knows and would only like to utilize Externally Described Printer Files. I am trying to get input from individual which is really the best way to go. I realize everyone has there own style and techniques, but being the Programming Supervisor, my Director and I are trying to set one standard. The individual for Externally Described Printer Files uses the benefits of being able to bold and underline headings, where you can't in Internally Described Printer Files. He also says it is faster to create an external file, and that interal file are just "old technology and he should not be subjected to "old technology" The individuals for Internally Described Printer Files say it is much faster to debug and analyze as it is all in one place(the program), and you are not using indicators like the external printer file. They feel that they can create an internal file just as fast as and external. Also, are their any performance issues to consider. Thanks for your input. Sandy.

[Guest.Visitor]

At the risk of sounding crass, hire people more attuned to the shop standards, whatever they are. I also prefer printer files but have worked on projects run by RPG0 folks and they wouldn't know how to deal with printer files. bobh

[Guest.Visitor]

Sandy, I come from a s/34 and s/36 background and had 10 years of internal printer and data files. I find the externally defined dds to be more efficient in coding and also in using file editors such as DBU, FEU, WRKDBF, Etc. Also, if you don't have these utilities, you can use STRDFU and using option 5, the system will build a default DFU for that file, with columns, etc. (No, I don't reccomend DFU for applications...) If the choice is made to adopt external files (and I favor that choice), I would put two people on the project. One who knows internally described specs and the person who only wants to use externally described dds. This way they communicate (hopefully) and both learn the other method. (I am assuming the new guy does not know internal descriptions as well.) I would NOT start converting all programs to external dds. Rather, I would set a cut off date that gives everybody time to learn dds (if needed) and then use external files from that point on. Printer files are a different beast. Since you can have overlapping fields conditioned by indicators and such, it may have a little more impact on the learning curve. If you don't use overlapping fields, the command keys and such can still be a little confusing using PRTF dds. I would suggest that the new guy write a simple report with two level breaks and a grand total that use a PRTF. This will serve as an example and possibly template for future development. In the mean time however, I would stick to my guns and enforce the standard of internal files. This kind of weeds out those who can follow from those who can't. If you modify your standards to allow internal OR external then okay, but you can't have a "cowboy" attitude where anything goes. -bret

[Guest.Visitor]

Sandy, I agree with Bret that it sounds like the new guy does not now how to use the internal described output specs. His comment about bold and underline make that obvious. Both can be accomplished by using zero spacing, to create overprinting. At our shop we have stuck with the internal descriptions. We try to have very few listings, opting instead for screens. For us it did not offer enough up-swing...for now at least. Kevin Silbernagel

[Guest.Visitor]

Sandy, I still have to maintaine programs with internally defined printer files. As I convert a program over to RPG/IV, I try to also convert its internal printer file to external (DDS). I do find that internal printer files are much faster to create. If I am asked to create a one time report or one on a tight schedule, I use internal printer files. It is important that both programs learn internal/external printer files. I speak from the point of view of a one man department. William...

[dchristie]

After many years of doing both types, I would have to say that I would encourage external printer files only. There is just no comparison when doing maintenance. If you want to be productive for both internal and external, get Report Designer. How many times have you had to do a simple task as adding a new field? With internal, you have to almost get out the printer layout sheets and design the report again, unless your shop is really good and have a copy stored. With external this takes but a few minutes. Another example is that with using either Report Designer or (here it comes) RLU, you can identify any fields that overlap. I personally like the attitude of your new programmer, and especially yours for considering his recommendations. I hope this does not start yet another discussion on how programmers should not have an opinion. Thanks

[Guest.Visitor]

With some printers you don't get bold if you overprint. I've seen several questions on forums recently asking why overprinting won't work with printer xyz. I know nothing about printers, but I read somewhere recently that older printers detected an overprint and shifted something (the paper?) over a tiny bit to give the bold effect.

[Guest.Visitor]

Other things you may want to consider is the extra control you get with External Printer Files. One of the things that is nice is being able to change where a report goes without changing the CL overrides and then recompiling. Another nice feature is the names of the spool flles themselves. Every spool file in an ouput queue has a different name. Making it very easy on the operators when report need to go to a special printer due to width or such. I have worked with RLU and there is no way a complex report can be created faster with O specs. Being able to see the lay visually really speeds things up for complex report. That is my .02.

[Guest.Visitor]

Old impact printers used hammers and whapped it twice depending on the machine order. Newer electro static and laser things just use the same raster so there is no 'overprinting' . bobh

[D.Handy]

Barbara, "I know nothing about printers, but I read somewhere recently that older printers detected an overprint and shifted something (the paper?) over a tiny bit to give the bold effect." I think on older impact line printers (with the spinning print belt), the combination of small timing differences in the hammer strike plus just the additional ink from a second imprint tended to give a "bold" effect. Much like overstriking on an old manual typewriter. (Showing my age here... Dot-matrix printers (especially bi-directional ones) also had enough tolerance in the timing of pin firing that multiple passes simulated a bold effect. Many dot-matrix printers also had a "bold" setting which, when enabled, caused a second pass with the pin firings intentionally shifted by one dot as the head(s) traversed the paper. I think a few printers also retained the last print line buffer long enough to compare with the next one, and when the paper was not advanced (eg CR without LF) but print columns repeated the same character, it would intentionally alter the pin firing timing by one dot (part of a dot?) width to help make the characters thicker. Overstriking to produce a bold effect doesn't work with page printers (e.g. laser printers) which create an entire page in memory. Each pass would generate the exact same pixels to receive toner, so you don't get ink spread from overstriking or any shift. Laser fonts with a bold variant just use the font definition to denote which pixels get toner. If a font does not have a bold variant but you instruct the printer to print in bold, it shifts the "cursor position" minutely and repeats the character while building the page image. Perhaps some page printers contain logic to detect "overstriking" with an identical character, and automagically shift the characters to simulate bold. However I don't remember reading about it in my HP Technical Reference manual (which is admittedly dated). Doug PS - Some page printers also could physically shift the paper slightly in the output bin, but that was to ease job separation for an operator. It had nothing to do with page content.