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 <a href=http://www.gumbo.com/>Report Designer</A>. 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, <font color=blue>"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."</font> 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.

[David Abramowitz]

Bob Hamilton wrote: Newer electro static and laser things just use the same raster so there is no 'overprinting'. T'aint necessarily so. I get the overprinting bold effect on certain printers configured as *SCS 3812. I don't get it at all from laser *IPDS printers. Dave

[Guest.Visitor]

Sandy, I don't see why this should be an issue. Around here, programmers are generally free to select whether to use internal or external printer files. External is mandatory only when special effects are required. I would recommend you assign this new guy to develop a limited number of reports using internal printer files. He has to learn! For the rest of the staff, you have to encourage them to use the new technology. Just take thing easy. Sooner or later, they will catch up.

[Guest.Visitor]

This is not by 'overprinting' . bobh

[bibarnes@yahoo.com]

I started out with the old System 3 Mod 10, 12, & 15. So reports were done with IBM report layout forms. It was a large pain in the derrier to make changes. I currently use RLU and have gotten used to it. I can usually create a report in less time with EPF (external print files) than with IPF. We have some reports that get emailed and are by division and district. With the EPF I designed the output once and then double define the print file renaming the formats. The new person needs a 'tood adjustment. Every shop is different and all can be changed if it's done right. He can show the advantages and accept the dictates of management or he can find a shop where he can be in charge and set standards himself. My recommendation would be for you to "bite the bullet" and learn EFP. It is definetly worth the effort. Bill Barnes (old guy)

[David Abramowitz]

Perhaps I wasn't clear. On the "O" specs, I specify 0 0 for lines to space before and after. I then print an identical line, spacing 1 after. To me this is overprinting. Dave

[Guest.Visitor]

I use both internal & external but it depends on the need and requirement. Internal - one advantage here is that you can easily print an entire array by placing its name in the O specs. Nice for those reports where there are lots of numeric bucket columns. External PRTF's would require a seperate redefined field for ach array element. External - great for Barcode printing ! Also for speical printing it works nicely. I have an employee label program that prints on a special size avery paper so the PRTF parms have speical width and length. You can't do that internally. RLU is terrible, but I put up with it. Very clumsy to use IMHO. I wish there were a more GUI way to do this directly. I would not limit myself or anyone else to what they can do. Why not let both the external vs. internal people share the knowledge ! Learning something new just might ignight some now ideas no one ever thought of before.

[dchristie]

"I wish there were a more GUI way to do this directly." I thought I heard that CODE/400 has Printer file support. Haven't seen it yet but maybe someone else who has can comment on printer file support in CODE/400. Thanks

[Guest.Visitor]

I've never worked in a company that mandated one way or the other. So I've always followed my own guideline of externally defining every file. Not just printer files, but also screen, ICF, and database files. The biggest benefit being that WYSIWYG tools could be used to define the interfaces. The next biggest benefit being that a change to the interface did not necessarily force a change to the program. For those of you who define printer files internally, do you, or would you define screen, ICF, or database files that way too? Nathan.

[David Abramowitz]

Nathan Andelin asked: For those of you who define printer files internally, do you, or would you define screen, ICF, or database files that way too? I haven't used ICF for many years, so I couldn't answer that one. For screen files, I have an excellent tool that generates the DDS. Most screen files have less than four formats, and are easy to maintain externally. Almost all DB files have only one format. Those that have more are multiformat LFs, and are a small minority. PRTFs OTOH usually have twenty or more formats. Some as many as fourty. They can not be reused from program to program like DBFs or ICF. Since they are germaine to a specific program, I see nothing wrong with internalizing the function in most cases. My own personal exception is as follows: I externalize PRTFs for anything on special forms. There are a variety of reasons for doing this. Many print features are only available in an externalized PRTF. The corollary is that if I had to change fonts or CPI on the same page in a standard form report, I would have to externalize that report also. Dave

[S.Mildenberger]

Yes, Code/400 has the Code Designer which is a GUI for both display files and printer files. I haven't used very much for printer files but I just now opened one and it looks like it would be pretty easy to use. I have used the Designer with display files and like it much better than SDA. I think everyone should be using Code/400 and it's tools for all their development, for me it is a much more productive environment. Scott Mildenberger

[Guest.Visitor]

We use external printer files when the document requires special printing, like a postal bar code, and controlling the font size. Can postal bar codes be printed by internally described printer files?

[Guest.Visitor]

George, I can't vouch for postal bar codes, but I have written barcodes (UPC, CODE39) into internally described files. It takes special driveers (in our case anyway) for the printer and I had to put in all kinds of kooky characters to begin the print, set height, width, etc. Stuff like the ` ~ ^ } { and all kinds of non sensical stuff. IMO, stick with the external print file for barcoding. -bret