RE: Reading QMHRCVPM data returned

The names are "interesting" also due to the lack of Qualified names way
back when. The names are generated in a way that you can combine any
number of QSYSINC includes into the same RPG application and compile
without worry of name collisions across different APIs. You just can't
imagine how many Bytes_Returned, Bytes_Available fields for instance are
found across the various APIs and API formats :)

Between 10 character names and the need for simple name uniqueness across
the compilation unit, the names are indeed interesting. It is my hope in
the future that IBM would provide ILE RPG includes that provide for long
names, qualified names, based structures, constants, prototypes, and many
other items that are now available to the RPG developer. This of course
would also need to be done in an upward compatible fashion for existing
QSYSINC users and hopefully with a reasonably easy transition plan.

As for the definition of variable length storage, likeds references are a
nice way to use the QSYSINC provided definitions and still add your own
storage definitions within the same data structure. In a similiar manner
COBOL typedefs provide the needed flexibility for QSYSINC usage and user
customization of storage allocations.

Bruce Vining (speaking only for himself)




Vernon Hamberg <vhamberg@xxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
05/18/2007 07:50 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: Reading QMHRCVPM data returned






The QSYSINC includes for RPG and RPGLE are almost all auto-generated
from the corresponding C includes. Bruce Vining said at COMMON that
he does that conversion with a utility he has. Hence the
"interesting" names - the utility probably had to accomodate shorter
names in RPG at one time, so it truncates and adds a number - look at
all the QRSR01 QRSR02 or whatever for reserved field names.

The benefit of using the includes is, they usually keep up with
releases - we're not perfect, even IBM.

There is another issue with includes - they have only the fixed
portions - there are tricks with pointers in C and probably in RPG IV
to /copy the include and add variable-length for the rest.

Regards
Vern

At 11:15 AM 5/17/2007, you wrote:

Two rules when using QSYSINC/QRPGLESRC source in your own applications:

1) The data structures suck, so write your own, more readable version.
2) If you're using QSYSINC/QRPGLESRC, see rule 1.


To make your code work, change the DS line for your RCVM02000000

structure by

adding a length of 2000 for the data structure. Your code will work for

now.

-Bob Cozzi
www.i5PodCast.com
Ask your manager to watch i5 TV



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx

[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On

Behalf Of Coyle, Stephen F.
Sent: Thursday, May 17, 2007 10:37 AM
To: RPG400-L@xxxxxxxxxxxx
Subject: Reading QMHRCVPM data returned

Hi All,
I'm having a situation when reading the varying length data returned
from the QMHRCVPM API. The format I'm using, RCVM0200, is copied in from
QSysInc/QRpgleSrc,QMHRCVPM.

DQMHM020000 DS Qmh
Rcvpm RCVM0200
D QMHBRTN02 1 4B 0 Bytes Returned
.
D QMHLDRTN00 153 156B 0 Length Data
Returned
.
D QMHLHAVL00 173 176B 0 Length Help
Available
D*QMHMT06 177 177 Varying length
D*QMHSSAGE00 178 178 Varying length
D*QMHMH00 179 179 Varying length

When attempting to scan the message replacement data,
%Scan( 'Manager': %Subst( QMHM020000: 177 : QMHLDRTN00 ))


The compiler justifiably says that the start position,177, is greater
than the variable length, 176. The text in the QSysInc copy member also
states
D*NOTE: The following type definition only defines the fixed
D* portion of the format. Any varying length field will
D* have to be defined by the user.

The thing is, the production program that is coded like this is working
fine. It was compiled at V4R5M0, but it won't compile now at V5R3M0.
It looks like a hole has been fixed since V4R5 but I really don't know.

Anyway, does this mean the QSysInc copy members cannot be used and I'll
have to redefine them in my own copy members? Or is there a better way?
I was thinking of copying the member and changing the QMHM020000 data
structure length to match my prototype receiver variable, like so:

DQMHM020000 DS 1024 Qmh Rcvpm
RCVM0200

D RcvPgmMessage Pr ExtPgm('QMHRCVPM')
D MsgData 1024A Options(*VarSize)
D MsgDataLen 10I 0 Const
D FormatName 8A Const
D CallStEntry 10A Const
D CallStCount 10I 0 Const
D MsgType 10A Const
D MsgKey 4A Const
D WaitTime 10I 0 Const
D MsgAction 10A Const
D APIErrorDS Like( QUsEC )

Any suggestions on how others would do this are appreciated. I'd like to
continue to use QSysInc if possible.

Thanks...
- Steve

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