TechTalk: External Printer Files vs. O-specs

RPG
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

External Printer Files vs. O-specs

From: Ted Holt To: All

I sometimes use externally defined printer files, and sometimes I use O-specs. Here is one difference I've come across. I would like you guys to take a look at this to make sure that I'm not missing something.

I was working on a change to the MAPICS purchase order (PO) print program. As it is, the QTYORD (quantity ordered) field is defined as 10 digits, three of which are decimal positions. We buy everything in whole units, so my purchasing agent asked me if I could change the PO so it wouldn't print decimal positions. He has a good reason for this. He's afraid that eventually somebody is going to get one of our POs and mistake the decimal point for a comma. It would be bad for one of our suppliers to interpret 15.000 (fifteen) as 15,000 (fifteen thousand), for example.

I could, of course, redefine QTYORD as 7,0, and that's probably what I'll wind up doing; but my first impulse was to do what I'd do if the MAPICS program used O-specs. I'd overlay the last four positions of QTYORD with blanks as shown in 1.

I could, of course, redefine QTYORD as 7,0, and that's probably what I'll wind up doing; but my first impulse was to do what I'd do if the MAPICS program used O-specs. I'd overlay the last four positions of QTYORD with blanks as shown in Figure 1.

This has the advantage that I wouldn't have to monkey around with the calculations.

So I tried that with the printer DDS (2).

So I tried that with the printer DDS (Figure 2).

Of course, the decimal point and digits still printed, since QTYORD prints, and then blanks print over it.

I'm not bringing this up to start a debate over printer DDS versus O-specs. I'm just mentioning that it's a difference that I'd never thought about. As far as I can tell, there is no way to do in DDS what I've done in the O-specs given above. True?

From: Art Tostaine To: Ted Holt

I had the same type of problem on my Purchase Order print, except that we wanted to print the decimals if they were there, or just print the whole number if they weren't. With externally described printer files, I defined two output fields-one as 9.4, and one as 5.0. I used an indicator (yeccch!) to decide which one to print in the DDS.

From: Ted Holt To: Art Tostaine

I don't know what your code looks like, but the printer files in MAPICS are chock full of indicators. It's hard for me to find an indicator they haven't already used; and if I do find an unused indicator, I have no guarantee they won't decide to start using it in a future release.

For several years now, I've avoided using indicators at the field level in Output specs, so I'm also avoiding them in externally defined printer files. I wish the fine folks in the MAPICS programming department in Atlanta shared my philosophy.

From: Ernie Malaga To: Ted Holt

One solution would be to define a(7 0) field in the printer file and Z-ADD QTYORD to it before WRITEing the record.

From: Ted Holt To: Ernie Malaga

That's what I wound up doing. I would have liked to have avoided that, since it meant I had to modify and recompile the RPG program in addition to the printer file. Had I been able to overlay the decimal positions with blanks, I would only have had to modify and recompile the printer file.

From: Ernie Malaga To: Ted Holt

Could you create another record format in the printer file, almost identical to the record you're now using? It seems to me that then you could make the decision in the RPG program about which version of the record format to use. This would save you from having to deal with any indicators.

From: Ted Holt To: Ernie Malaga

That would have involved even more modification to the RPG program. There are six printer files in the program. Two of them are real; the other four have to be overridden to the two real ones. This means that lots of record formats are renamed in the continuation F-specs. I would still have had about the same number of modifications in the C-specs.

The simplest thing was what you suggested. I only had to modify a few lines of DDS in the printer file and add a few lines to the RPG program (Z-ADDs, as you mentioned). I didn't have to fool with any indicators.


TechTalk: External Printer Files vs. O-specs

Figure 1 Overlaying an Output Field With O-Specs

 ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+ O QTYORD 58 O 58 ' ' 
TechTalk: External Printer Files vs. O-specs

Figure 2 Attempting to Overlay Output With DDS

 ... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+ A QTYORD 10 3 47EDTCDE(P) A 55' ' 
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  •  

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: