RE: Reading QMHRCVPM data returned

["Holden Tommy" <Tommy.Holden@xxxxxxxxxxxxxxxxx>]

QSYSINC was done nicely...i know it must have been difficult trying to
figure out unique names for all of those bytes provided, etc fields.
But I do hope that an update will be coming for those copybooks some
time in the future... 


Thanks,
Tommy Holden


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Bruce Vining
Sent: Friday, May 18, 2007 10:01 AM
To: RPG programming on the AS400 / iSeries
Subject: 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.