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



May i suggest you dowload the 'who knew you could do that ....' excellent
book for migrationg from RPGIII or RPGIV to RPGILE ?

here is the URL :
http://publib.boulder.ibm.com/iseries/v5r2/ic2928/index.htm?info/rzab6/rzab6related.htm

----- Original Message ----- 
From: "Mike Pantzopoulos - (H/O)" <mpantzopoulos@xxxxxxxxxxxxxxxx>
To: "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
Sent: Friday, October 07, 2005 1:00 AM
Subject: RE: Prototype Definitions


> That's an amazing little nugget of information Charles!
>
> I've ben using Bob Cozzi's book as it seems to be the richest in
> information (compared to Brian Meyer's, and the other one, RPG IV at
> work), and there's no mention of CONST behaving like you described. His
> description (pp 435 is:
>
>
> For procedure parameters, the value being passed is constant. It is
> considered read-only and is not changed by the called procedure.
>
>
> I have used CONST but in the context of the parameter being read-only,
> so I've been getting into the habit of using it to 'declare' parameters
> as being input.
>
> I've been trying to use the convention of declaring parameters in the
> sequence of input, inpout/output, and output rather than jumbling them
> up, and CONST seemed to be a good keyword to use to quickly identify
> input parameters, because they were forced to read-only..
>
> The reply I received from a German lady, Birgitta requires me to call an
> API to do the same thing you've just made extremely simple!
>
> Hopefully I'll get some time today to try this.
>
> All I want to do is show the RPG III developers here how powerful a
> procedure parameter list can be, and this was the last problem I had to
> solve.
>
> Thank you, thank you thank you!
>
> I don't know how we ever worked in technology before the internet!
>
> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Wilt, Charles
> Sent: Thursday, 6 October 2005 9:23 PM
> To: RPG programming on the AS400 / iSeries
> Subject: RE: Prototype Definitions
>
>
> Mike,
>
> As long as you don't need to change the values in the parameter.  Use
> the CONST keyword.
>
> With the CONST keyword specified, the compiler will allow variables or
> literals of < 256 to be passed, behind the scenes it will move the value
> to a 256 byte temporary variable for you.  That way in the called
> procedure, you'll have the full 256 bytes in which to overlay your DS.
>
> Another option is VALUE, the end results are similar but really is best
> used with small ( < 16 byte ) variables.
>
>
> HTH,
>
> Charles Wilt
> --
> iSeries Systems Administrator / Developer
> Mitsubishi Electric Automotive America
> ph: 513-573-4343
> fax: 513-398-1121
>
>
> > -----Original Message-----
> > From: rpg400-l-bounces@xxxxxxxxxxxx
> > [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Mike Pantzopoulos -
> > (H/O)
> > Sent: Thursday, October 06, 2005 1:38 AM
> > To: RPG programming on the AS400 / iSeries
> > Subject: RE: Prototype Definitions
> >
> >
> > Thanks Birgitta.
> >
> > >From my reading I was about to test the OPDESC keyword, but
> > didn't want
> > to waste any more time on it (There's never enough time to do it
> > properly or to learn new ways! That's why most RPG shops prefer RPG
> > III)
> >
> > You described my situation exactly. The procedure I was using
> > returned a
> > 256 byte field, whereas the calling program invoked the
> > procedure with a
> > parameter which was only a few bytes long. This is because the 256
> > variable was a generic value which could contain  different structure
> > under different DB accesses. I was getting decimal data
> > errors, and when
> > I debugged the flow, it was apparent that my memory was being
> > crapped on
> > immediately after the call. The *VARSIZE seemed to be the correct
> > parameter option but nothing seemed to work. It still seems to be
> > extremely tedious, having to use another API! I tried using
> > combinations
> > of BIFs to replace the return only the data expected but
> > nothing seemed
> > to work. In essence all I wanted to do was define the prototype as 256
> > (maximum) and to be able to invoke the function with a parameter which
> > was less than that without crapping all over the rest of my program
> > space. This was so I could use a DS overlay as a parameter
> > over the 256
> > byte parameter so that the sub-fields would be immediately available
> > after the call. I don't like the idea of having to do further
> > MOVEs from
> > a parameter to other fields. It should be automatic via the parameter.
> >
> > This must be a common requirement. I don't know why IBM make it so
> > difficult.
> >
> > I keep trying to convince people in my shop that RPGIV is a
> > better way,
> > and then I have to keep reworking stuff.
> >
> > Thanks for replying
> > -----Original Message-----
> > From: rpg400-l-bounces@xxxxxxxxxxxx
> > [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of HauserSSS
> > Sent: Thursday, 6 October 2005 3:21 PM
> > To: RPG programming on the AS400 / iSeries
> > Subject: AW: Prototype Definitions
> >
> >
> > Hi Mike,
> >
> > OPTIONS(*NOPASS) means you'll pass a character field with a fixed
> > length. The compiler does not check if the length of the passed field
> > is identical to the expected field length. This gives you the ability
> > to pass character fields that are shorter as the maximum length
> > defined in
> > the prototype. If neither the keyword CONST nor the keyword VALUE are
> > specified for the parameter, you have to check the incomming length of
> > the parameter in your called procedure. If less bytes as expected are
> > passed, you only can change the incomming bytes, otherwise you'll
> > override global memory!! To determine the incomming length you have to
> > add the keyword OPDESC to the Prototype and use the API CEEDOD in the
> > called procedure.
> >
> > Varying means a field with varying length is passed.
> > A varying length field has 2 preceeding bytes that contain the actual
> > length of the field. Because the length is implicitely passed with the
>
> > parameter field, no additional actions are needed in the called
> > procedure. If it is an input/output parameter you can change the
> > length of data, without overriding memory. The new length is also
> > stored in these 2 preceeding bytes.
> >
> > Even if I said, "field passed" only a pointer to the
> > parameter field is
> > passed to the called procedure, as long the keyword VALUE is not
> > specified.
> >
> > I hope this helps
> >
> > Birgitta
> >
> > -----Ursprungliche Nachricht-----
> > Von: rpg400-l-bounces@xxxxxxxxxxxx
> > [mailto:rpg400-l-bounces@xxxxxxxxxxxx]Im Auftrag von Mike Pantzopoulos
>
> > -
> > (H/O)
> > Gesendet: Donnerstag, 6. Oktober 2005 03:57
> > An: RPG programming on the AS400 / iSeries
> > Betreff: RE: Prototype Definitions
> >
> >
> > Thanks.
> > It's been driving me crazy. They seem to be saying the same thing but
> > subtle differences are deadly in the arcane art of procedures. I'm
> > sure I'll be asking more before the end of today (In Australia).
> >
> >
> >
> > -----Original Message-----
> > From: rpg400-l-bounces@xxxxxxxxxxxx
> > [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of JK
> > Sent: Thursday, 6 October 2005 11:53 AM
> > To: 'RPG programming on the AS400 / iSeries'
> > Subject: RE: Prototype Definitions
> >
> >
> > Mike,
> >
> >  The archives contain several excellent discussions on this.
> > Search for
> > 'varying varsize'. Omit the * preceding "*varying" and "*varsize"
> > because it just confuses the search engine.
> >
> > http://archive.midrange.com/rpg400-l/
> >
> > JK
> >
> >
> > > -----Original Message-----
> > > From: rpg400-l-bounces@xxxxxxxxxxxx
> > > [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
> > > On Behalf Of Mike Pantzopoulos - (H/O)
> > > Sent: Wednesday, October 05, 2005 8:36 PM
> > > To: rpg400-l@xxxxxxxxxxxx
> > > Subject: Prototype Definitions
> > >
> > > Could some kind soul please describe the difference between the
> > > following prototype definitions:
> > >
> > > *VARYING
> > > OPTIONS(*VARSIZE)
> > >
> > > Thanks heaps.
> > >
> > > Mike Pantzopoulos
> >
> > --
> > 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 email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed. If you are not the intended recipient, any use,
> > disclosure or
> > copying of this message is unauthorised. If you have received this
> > message in error, please reply using the sender's email address.
> >
> > This footnote confirms that this email message has been scanned for
> > computer viruses. EIG-Ansvar Limited does not accept liability for any
>
> > loss or damage, whether caused by our own negligence or not, that
> > results from a computer virus or defect in the transmission of this
> > email or any attached file.
> >
> > EIG-Ansvar Limited - Australia (A.B.N. 21 007 216 506)
> > Email : insure@xxxxxxxxxxxxxxxx
> >
> > Eig-Ansvar Limited - New Zealand
> > Email : insure@xxxxxxxxxxxxxxxx
> >
> > **************************************************************
> > **********
> > ****
> > *****************************
> >
> > --
> > 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.
>
> -- 
> 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 ...

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.