Ideas Needed - V6R1 - Creating a PDF & storing it in the IFS
Kim
To set up my dilemna - here's what we have:
A CL program that has several OVRPRTF statements, some which include
overlays. It calls an RPG program "COMMREPORTS".
COMMREPORTS is an RPGLE program that processes commission reports for
salesmen, the output being written via an EXCEPT to an O-spec. The
RPGLE program is called once from the CL, and all commission reports
for all salesmen are processed within this one call.
The reports are then printed from the output queue & mailed to the
salesmen.
Our objective -- to go paperless.
I created a printer file (QIPDS in MYLIB) with DEVTYPE *AFPDS, and
Workstation customizing object (WSCST) of *PDF. We made a change to
the OVRPRTF statements in the CL to use the new printer file, and to
place the output in the IFS. Our OVRPRTF statement looks like this:
OVRPRTF FILE(LASER) TOFILE(MYLIB/QIPDS) LPI(8) CPI(12) OVRFLW(62) +
FONT(281) PAGRTT(90) DUPLEX(*YES) FRONTOVL(CMLIB/AGTSTMTO
0 .30) +
BACKOVL(CMLIB/AGTSTMTO 0 .30) USRDTA(COMMSTMTS) +
TOSTMF('\home\kgibson') SECURE(*YES)
This is working beautifully, placing the output into PDF format in the
IFS. The PDF looks terrific, and even contains the overlay. It was so
easy! Woohoo!
Then the questions began to arise. Here are a few examples of the
filenames that were generated from the RPG program to the above LASER
override:
LASERtfDwBt.pdf
LASER$XL11G.pdf
LASERfw46BX.pdf
These filenames don't mean anything to me. I'd like to have the
salesman number associated with the PDF report to be included in the
filename so I can tell where this file needs to go.
Can we control the name of the file and the location within the IFS
from within the RPG program? I'm not very API-savvy, and in looking at
Scott Klement's online IFS tutorial, I'm thinking that we might have
to scrap our O-specs in order to control the name of the file &
location. That's a last resort--the output and overlay is complex, and
works really well. I'd hate to have to reinvent the wheel here.
Does anyone have any ideas?
Ad
7c50e2...@m25g2000yqc.googlegroups.com:
perhaps something like
TOSTMF(�/home/kgibson/<Salesman number>.pdf�)
--
Ad,
pas de probl�me, que des solutions
Kim
> Kim <gibkn...@gmail.com> wrote in news:55dd9ddf-5e80-4f48-a5cc-
> 7c50e244c...@m25g2000yqc.googlegroups.com:
>
> - Show quoted text -
Thanks for the response, Ad.
The print override is in the CL, and I don't have the salesman numbers
when creating the override. The RPG program loops through all of the
salesman numbers, generating a commission report for each. Can I
change the print override in the RPG program? I'd need to do so before
the O-specs are written.
In the meantime, I've been reading through the InfoPrint Server for
iSeries User's Guide (G544-5775), and it looks as if a mapping program
might be an option. Quoting page 63, "Setting up Your PSF
Configuration Object":
"Do you want to specify options only available with a mapping program?
Some such options are:
– PDF file name
– Full control over PDF file’s location in the integrated file system
– cc, bcc, reply to e-mail addresses
– E-mail subject text
– Encryption of e-mailed PDF
– Files to include in the body of the e-mail or to attach to the e-
mail
– Intelligent routing of segments; that is, doing something different
with each segment
If so, specify a mapping program on the PDFMAPPGM parameter."
So do I call this mapping program prior to the EXCEPT statement?
Afterwards? Still researching.
trans am kid
this program to create all my pdf's from the i, and I can pass to it
the file name and with the various folder options, store it wherever
so if I want one folder say for sales reports, no problem, another
folder for this that or the other, no problem. And you determine the
location at the time the program runs. Neat thing is say that you have
a file with 200 invoices in it, you can put every invoice in its own
file. You can also fax and email with it. The autodoc hse runs on the
pc but you can either use it directly as a print device as I
understand it or you can run it as the recipient of a tn5250e printer
(which is what I do). So I can date them, name them, file them where I
want.
It works pretty good.
> Afterwards? Still researching.- Hide quoted text -
Ad
@r14g2000vbc.googlegroups.com:
> On Dec 17, 10:23�am, Ad <noem...@spam.com> wrote:
>> Kim <gibkn...@gmail.com> wrote in news:55dd9ddf-5e80-4f48-a5cc-
>> 7c50e244c...@m25g2000yqc.googlegroups.com:
>>
>>
>>
>>
>>
>> > Last week we upgraded our i5/OS to V6R1.
>>
>> > To set up my dilemna - here's what we have:
>>
>> > A CL program that has several OVRPRTF statements, some which include
>> > overlays. It calls an RPG program "COMMREPORTS".
>>
>> > COMMREPORTS is an RPGLE program that processes commission reports for
>> > salesmen, the output being written via an EXCEPT to an O-spec. The
>> > RPGLE program is called once from the CL, and all commission reports
>> > for all salesmen are processed within this one call.
>>
>> > The reports are then printed from the output queue & mailed to the
>> > salesmen.
>>
>> > Our objective -- to go paperless.
>>
>> > I created a printer file (QIPDS in MYLIB) with DEVTYPE *AFPDS, and
>> > Workstation customizing object (WSCST) of *PDF. We made a change to
>> > the OVRPRTF statements in the CL to use the new printer file, and to
>> > place the output in the IFS. �Our OVRPRTF statement looks like this:
>>
>> > OVRPRTF � �FILE(LASER) TOFILE(MYLIB/QIPDS) LPI(8) CPI(12) OVRFLW(62
> ) +
>> > � � � � � �FONT(281) PAGRTT(90) DUPLEX(*YES) FRONTOVL(CMLIB
>> pas de probl�me, que des solutions- Hide quoted text -
I know nothing about how it works in RPG,
in speudo code it should look like
for each salesman
ovrprtf
open prtf
print report
close prtf
The procedure you use now is included in V6R1 (5761TS1)
InfoPrint Server (5722IP1) is much more powerfull but you have to buy it.
jsev99
Just a couple of thoughts:
There's no reason why you can't move the OVRPRTF to the RPG program.
You could either create a small CL module that performed this and then
call it or just call QCMDEXC within RPG to do it. You'd have:
OVRTPRTF
do your printing here
DLTOVR *PRTF
I'm surprised your OVRPTRF actually works. As far as I'm aware,
windows is the only OS that uses backward slashes ('\') to separate
directories, all others user forward slashes ('/') so I would have
thought the "directory" you have specified was actually a filename -
unless the OS notices the error and translates that automatically? If
that is indeed the case, I'm not sure if QCMDEXC would take backward
slashes a bit more literally.
Murray Bob
If you are interested in a software solution, check out www.octotools.com
. We can easily format the outout into PDF and print, take any part
of the input file and create meaningful file names.
For example using your example, if salesman name or number is in the
body of the report we can store it by salesman, then subdirectory
contailing report name and date of report.
For invoices we can store by account as the main dir and files within
an account of invoice number and invoice date. We will interface
with IFS. We can also email out PDFs directly to each person or
account with or without PDF encryption with individual passwords.
Regards,
Murray
978-535-7676
Kim
>
> - Show quoted text -
Thanks for the responses, everyone. I think I've got the problem
solved, via a QCMDEXC call in the RPG program. I got all caught up in
reading the InfoPrint manual which goes into the PDF subsystem &
mapping programs. The QCMDEXC turned out to be a heckuva (!%#!!) lot
easier. I wasn't seeing the forest for the trees--thanks for the help,
jsev99.
BTW - I'd read somewhere (can't remember where), that in the TOSTMF
parameter either a forward or backward slash will work, but it is the
forward slash that is the proper syntax. While TOSTMF('\home\kgibson
\') was working for me, I changed it to use the correct syntax.
Thanks!
Richard Schoen
create on V6R1, check out our web site or feel free to contact me.
We have a product that can auto-distribute documents created by InfoPrint
Server or via the new OVRPRTF *AFPDS functionality.
Regards,
Richard Schoen
RJS Software Systems Inc.
"Get the information you need. Now!"
Document Management, Workflow, Report Delivery, Forms and Business
Intelligence
Email: ric...@rjssoftware.com
Web Site: http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT
"Kim" <gibk...@gmail.com> wrote in message
news:17e8e27b-8d9c-465f...@r14g2000vbc.googlegroups.com...
> pas de probl�me, que des solutions- Hide quoted text -
yl_mra
> windows is the only OS that uses backward slashes ('\') to separate
> directories, all others user forward slashes ('/') so I would have
> thought the "directory" you have specified was actually a filename -
> unless the OS notices the error and translates that automatically? If
> that is indeed the case, I'm not sure if QCMDEXC would take backward
> slashes a bit more literally.
The 'root' directory and all subdirectories, unless otherwise
designated by an IBM named subdirectory specific to a different file
system, function as PC directories in the IFS file system. So, the pdf
files are stored in a directory that behaves like a PC directory
except, as a convince to users, IFS tolerates either forward or
backward slashes. Specifying a different file system, QOpenSys, for
example puts you into a POSIX file system which follows different
rules. For example, whereas the PC file system is case insensitive,
the POSIX file system is case sensitive.
yl_mra
> FONT(281) PAGRTT(90) DUPLEX(*YES) FRONTOVL(CMLIB/AGTSTMTO
> 0 .30) +
> BACKOVL(CMLIB/AGTSTMTO 0 .30) USRDTA(COMMSTMTS) +
> TOSTMF('\home\kgibson') SECURE(*YES)
>
A couple of ideas. But first, be aware that, since you are writing to
a PC type of directory in the IFS the letters are case insensative. As
a result, you are accessing the same file whether you use capital,
lower case or mixed case letters in the file and/or directory name.
1. You could write a 2nd CL, or other, program to move (copy and
delete) all of the generated files to a directory with the name, or
encoded name, of the sales person after time the RPG program prints a
pdf file. You would pass the sales person's name to the 2nd CL program
and the program would insure that the directory existed before doing
the copy. If I were doing this, I would write the 2nd CL program as an
exit program so that the RPG program always called it but, if the exit
program did nothing, the RPG program would function as it currently
does. Then, the exit program can be slowly developed and expanded to
provide the needed and altered for other purposes later.
2. You could change the RPG program to write one file with headers/
separators between sales person's information and then, as a post
process, run a utility that separated each of the master file sections
into separately names files.
The idea of using the OVRTPRTF in the RPG program, or adding an exit
program to do it, also seems promising.
Best of luck.