|
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. > >
As an Amazon Associate we earn from qualifying purchases.
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.