Actually, the documentation I'm using is IBM server iSeries Printing VII:
Infoprint Server Implementation. Which you can find at
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/redp3752.html?Open
The explanation of the buffer space is found in section 6.8.1 on page 93.
"6.8.1 Buffer space too small
"One condition that causes the PDF mapping program to be called extra times
deals with the buffer space. The first time Infoprint Server calls the PDF
mapping program, it does not know how much space the PDF mapping program is
going to want, so it assumes a relatively smallsize. It tells you this by
passing the Length of output information buffer parameter. This parameter
is described in 6.4, “PDF mapping program input and output parameters” on
page 66.
"This field tells the PDF mapping program how much space Infoprint Server
has set aside in its buffer for information that the PDF mapping program is
going to provide. The PDF mapping program responds by telling Infoprint
Server how much space it really needs. It does this by assigning a value to
the “Length of output information available” parameter.
"If Infoprint Server realizes that it didn't give the PDF mapping program
enough space, it calls the PDF mapping program again and uses the number
that the PDF mapping program just requested. Think of the dialogue as shown
here:
"Infoprint Server: Hello PDF mapping program. I need some information about
what to do with the PDF file for customer 100. I have room for 337 bytes of
data in the output buffer.
"PDF mapping program: Sorry, that is not enough space. I need 2509 bytes.
"Infoprint Server: OK, let’s try this again. I need some information about
what to do with the PDF file for customer 100. I have room for 2509 bytes
of data in the output buffer.
"PDF mapping program: That is better. Here is the data you requested.
"Infoprint Server: Thank you. I can process the PDF file now.
"Lines 158 through 166 of the sample PDF mapping program illustrate the
logic used to handle the buffer size test."
.....
--------
A year or so back, I set up the first outque and "writer" to use
InfoPrinter Server. It uses a exit program and is working fine. It's
function was to email the spool file as a PDF based on either the email
address carried in the spool file attribute "usrdfndta" or (if that
attribute was blank) a predefined distribution list based on the value of
"usrdta" (usually the program name).
I've cloned that program and have added the necessary code to rename the
resulting PDF file. By default, the server names every pdf file
000001.pdf. Since they are being delivered in individual emails, it
works, but it still causes more user work to rename the file before they
archive it. The second goal of the cloned mapping program is to send files
directly to the IFS and directly to specific directories.
Except for the change in output string size and the loading of new fields
in the output data structure, the programs are identical. I'm at a loss
as to what isn't going right.
Paul T.
"DeLong, Eric"
<EDeLong@Sallybea
uty.com> To
Sent by: "RPG programming on the AS400 /
rpg400-l-bounces@ iSeries" <rpg400-l@xxxxxxxxxxxx>
midrange.com cc
Subject
02/07/2008 05:41 RE: Infoprint Server Parms
PM
Please respond to
RPG programming
on the AS400 /
iSeries
<rpg400-l@midrang
e.com>
Ok, I think I found the documentation... Looks like this is a "PSF/400
Mapping Exit Program"...
Heres the documentation I'm looking at:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/xpsf400email.htm
Now, looking at the "Length of output information available" description:
Length of output information available
OUTPUT; BINARY(4)
The length of the mapping exit program output information available. If
this length is less than or equal to the length of the routing tag output
information, all available information has been returned. If this length is
greater than the length of the mapping program output information, only
data up to the length provided is returned in the mapping exit program
output information buffer.
First off, when you load OutputString, make sure you do something like
OutputString = %substr(OutputDS:1:OutputLen) so that you return EXACTLY as
many bytes as the interface specified. Failing to do this could corrupt
storage used by PSF...
It does not appear that PSF is resizing OutputString, since you continue to
see parms 4 and 5 in the positions you described. If you were not using
%substr() to safely assign values to OutputString, then you may be screwing
up PSF and keeping it from operating as expected..... (WAG) I did not see
anything in the documentation that says PSF will resize OutputString, but
I'll take your word for it....
Eric
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of
Paul.Thieme@xxxxxxxxxxxxxxxxx
Sent: Thursday, February 07, 2008 3:41 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Infoprint Server Parms
Here is the base code. InputString, InputLen and OutputLen are all passed
TO the program by InfoPrint Server. OutputString and OutputInfo are
passed back by the program. (If InforPrinter Server isn't expecting a
large enough string, OutputInfo is suppose to tell it the correct size when
the program terminates early. On the next call, OutputLen will be set to
the correct size by the server and supposably it will be ready to get the
string.)
D InPutString S 722
D InPutLen S 9B 0
D OutputString S 1848
D OutputLen S 9B 0
D OutputInfo S 9B 0
D*
C *ENTRY PLIST
C PARM InputString
C PARM InputLen
C PARM OutputString
C PARM OutputLen
C PARM OutputInfo
C SetON LR
C Eval InputDS = InputString
C EVAL OutputInfo = 1848
C If OutputInfo > OutPutLen
C Return
C EndIf
The InputDS is a Data Structure with a total length of 722. As the program
ends following a normal run, OutputString is loaded from the "OutputDS"
which has a total length of 1848. I realize that I could have used the
actual data structures as the parms, but I was afraid I was missing
something and that alone was causing my overlay issue.
Using Dump opcodes, I've been able to see that positions 338-341 of
OutputString is the same memory as OutputLen and 342-345 is OutputInfo.
It shouldn't be, but it is.
Like all the rest of my errors.... I'm sure this is something silly and
I'm just over looking it.....
Thanks for the help.
(by the way, I've posted the code in the body and simply changed the font
to courier to get it to line up again. If there is a better way, please
let me know.)
Paul T.
"DeLong, Eric"
<EDeLong@Sallybea
uty.com> To
Sent by: "RPG programming on the AS400 /
rpg400-l-bounces@ iSeries" <rpg400-l@xxxxxxxxxxxx>
midrange.com cc
Subject
02/07/2008 04:20 RE: Infoprint Server Parms
PM
Please respond to
RPG programming
on the AS400 /
iSeries
<rpg400-l@midrang
e.com>
How long is your Character Output String defined? It sounds like its
defined as 337 bytes. RPG is defining static storage for this variable,
and simply telling the api to store 1848 bytes to a field defined to hold
337 causes memory coruption....
Eric
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of
Paul.Thieme@xxxxxxxxxxxxxxxxx
Sent: Thursday, February 07, 2008 8:27 AM
To: RPG programming on the AS400 / iSeries
Subject: Infoprint Server Parms
I'm having an issue with the Infoprint Server and the parms used in the
mapping program.
There are 5 parms. 1) character input string , 2) numeric length of the
character input string, 3) character output string 4) length of the
character output string that info printer server is ready to receive,
5)length of the character output string that the mapping program wants info
printer server to be ready to use.
Info printer server passes information to the mapping program. The first
thing the mapping program should do is make sure that the buffer area set
up for receiving the output string is large enough to handle the data it
will be sent (i.e. value of parm #4 is large enough). If it is less than
what the program is ready to pass back, the program will load parm #5 with
the desired size and end. Info printer server will see that the it isn't
ready to receive the full output data, adjust it's buffer, and issue the
call again. Now that the value of parm 4 is large enough, the mapping
program can continue processing and fill the output string with the desired
data.
When I run the program, the buffer is initially set to 337 but the program
will pass back 1848 character. Parm 5 is set to 1848 and the program
terminates. Infoprint Server adjusts the buffer and the mapping program is
called again. This time, parm 4 says that Infoprint Server is ready for
1848 characters.
The program functions normally and all the data is loaded into 1848
character data structure that is parm 3.
The data that is loaded into characters 338 - 345 of the output character
string (data structure) are overlaying the values for parms 4 &
5....resulting in erroneous data in those two fields. I've tracked this
down by placing multiple "dump" opcodes in the program to verify when parms
4 & 5 are being corrupted (they are loaded correctly when the program first
launches. According to the formatted dump, the pointers for the parms are
only allowing 337 characters for the third parm even though the data
structure is much larger.
The numeric fields are defined in D-specs as being free standing B(9,0) and
the two character strings are defined as named data structures to make it
easier to break the string into usable fields.
Has anyone had similar issues or might have any clue what could be causing
this?
Is there any way to control the initial buffer setting for Infoprint server
so that it will start with the correct size of 1848?
Thanks,
Paul T.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
midrange.com
