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.
midrange.com
