|
-----Original Message-----
From: Christopher A. Libby [mailto:clibby@mainepublicservice.com]
Sent: Friday, August 17, 2001 10:33 AM
To: rpg400-l@midrange.com
Subject: RE: Softcoding Print-file attributesWell, this could work. However, the majority of the users printing the letters are PC illeterate. If we could follow the method below and then print it from the user's printer, this would be acceptable.-Chris---------------------------------------------------------
Christopher A. Libby, Programmer/Analyst
Maine Public Service Company (www.mainepublicservice.com)
clibby@mainepublicservice.com (207) 768-5811 ext. 2210-----Original Message-----
From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]On Behalf Of Peter Connell
Sent: Thursday, August 16, 2001 5:01 PM
To: 'rpg400-l@midrange.com'
Subject: RE: Softcoding Print-file attributesLibby,We had an analogous problem where the client required an Office type document that contained elements whose value must be retrieved from standard DB2/400 database files. We developed a more comprehensive solution as follows.The client supplied an MS Word template document in RTF format where the any fields that must be dynamically assigned were enclosed in brackets preceded with a dollar sign, eg $(FLDNAM), and any repetitive blocks within the document were separated by a line that uniquely labelled the block using a similar syntax but with square brackets $[LABEL1]. This document was stored in an IFS directory.Since an the RTF format is humanly readable, including the formatting protocol, then it is possible to write an RPGLE program that can read the template directly from the IFS, processing each block within the document as it goes. The content read is written out to a new file in the IFS with an RTF extension replacing fields named $(FLDNAME) on the way. Lines such as database transactions would be identified by a $[LABEL] block so the these would be processed in a loop function.The new RTF document can then be printed on a compatible printer or emailed in our case. We used this method to produce both summary reports and statements.Creating a service program of procedures to handle the I/O for the RTF template in the IFS meant that the method can be generic and easily deployed among different business applications where the client can determine the presentation of the Office document and the developer merely develops the code to populate the document.Cheers, PeterThis communication is confidential and may be legally privileged. If it is not addressed to you, you are on notice of its status. Please immediately contact us at our cost and destroy it. Please do not use, disclose, copy, distribute or retain any of it without our authority - to do so could be a breach of confidence. Thank you for your co-operation. Please contact us on (09) 356 5800 if you need assistance.-----Original Message-----
From: Christopher A. Libby [mailto:clibby@mainepublicservice.com]
Sent: Friday, August 17, 2001 12:47 AM
To: RPG400-L@midrange. com
Subject: Softcoding Print-file attributesWe're looking at a quick and dirty replacement for our Office documents we use to send information to our customers (disconnect letters, etc.). Here is what we are planning: Print the office document, then use CPYSPLF to covert from stream to a database member. We have a RPG program which will read the database member in, use a replace function to fill in keywords such as %date%, then output to a printer file. We then would use a CL to override the RPG to a specific database member for whatever letter we want to produce.The one problem we seem to be running into is that certain letters have attributes such a bold or underline, which we are legally required to format this way. Is there a way I can 'softcode' bold or underline starts and ends directly into my database member, or create a replace function to change '%BOLD%' to the boldface code?Thanks for your help!-Chris---------------------------------------------------------
Christopher A. Libby, Programmer/Analyst
Maine Public Service Company (www.mainepublicservice.com)
clibby@mainepublicservice.com (207) 768-5811 ext. 2210
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.