RE: Prototype Definitions

IBM Fixed the Operational Description and CEEDOD issue when a data structure
is passed on a character parameter. Not sure if it was in V5R1 or V5R3...
but they have told me they fixed it. Of course this was well after they
originally told me it wasn't "their problem" but Rochester's problem. <g>

-Bob Cozzi
www.RPGxTools.com
RPG xTools - Enjoy programming again.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Mike Pantzopoulos - (H/O)
Sent: Friday, October 07, 2005 12:14 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Prototype Definitions

Thank you very much Birgitta.

I'm playing with Bob Cozzi's code from a midrange article
(http://archive.midrange.com/rpg400-l/200301/msg00283.html) and then
I'll map what I've learnt into my own code. 
It seems that Bob's example was designed to show hot it fails when a DS
is used as a parameter (exactly the situtaion I want to use), but it
worked on my machine. Probably because we're on V5.3. Othe searches have
documented that the problem was fized for V5.3. 
 
Your answer was quite comprehensive and covered a lot of the subtle
differences between similar sounding keywords that have been confusing
me.

One thing I'm curious about - I went to the IBM InfoCentre and searched
for CEEDOD and I was taken to the Alphabetical List of APIs.
Unfortunately they are in the order of API Description and not name. As
I don't know what the descriptor of CEEDOD is I can't find the
documentation! Is there a way of finding the API documentation by the
name of the API??

Thank You for your patience. 

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of HauserSSS
Sent: Friday, 7 October 2005 2:59 PM
To: RPG programming on the AS400 / iSeries
Subject: AW: Prototype Definitions


Hi Mike,

the API must be used if your parameter is input/output.
(As far as I remember clearly I added somewhere in my answer ... if not
defined with VALUE or CONST) If your parameter is input only you can add
the keyword CONST that works for programs or procedures or VALUE that
works only for procedures.

If you use VALUE a new field with the expected format and the expected
length and passed to the called procedure. This duplicate can be changed
in the called procedure but the new value will never be returned to the
caller.

If you use CONST the current parameter definition and the expected
definition are compared. If they are identical a pointer to the original
parameter field is passed to the called procedure (or program). If they
are different a temporary field with the expected definition is created
(like with value), but only a pointer to this new field is passed to the
called procedure. Because it is not possible to determine if the
incomming pointer is from the original parameter field or a temporary
parameter field, it is not allowed to change this parameter field in the
called procedure (you will get a compile error).

If you use one of these keywords you don't need options(*VARSIZE).

Birgitta


-----Ursprungliche Nachricht-----
Von: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]Im Auftrag von Mike Pantzopoulos -
(H/O)
Gesendet: Freitag, 7. Oktober 2005 01:01
An: RPG programming on the AS400 / iSeries
Betreff: 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.