× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.