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' '
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
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.
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:
LATEST COMMENTS
MC Press Online