RPG subroutine with SQL

[TedHolt]

Re: RPG subroutine with SQL

Seems daft to me.. The fileds have been defined in the pi so it's just duplication and twice as much coding as the *entry / plist of legacy RPG

You are correct that having both a prototype and procedure interface in the same source member is unnecessary duplication. I suggest you put the prototype in a separate source member.

Consider program X, which several other programs call. I create a prototype of X in member X of a source physical file called PROTOTYPES. I use /include in X and in all of the callers to copy this prototype into all the programs during compilation. If the prototype does not match the procedure interface, X does not compile, so I am assured that the prototype is correct. Since all callers /include the same prototype, I have greatly reduced the chances that a caller will pass an incorrect set of parameters. With the old *ENTRY PLIST method, no such check is possible.

If you want the compiler to catch mismatched parameters, then prototyping is your friend.

Is the method I use foolproof? No. If the first two parameters, for example, of a routine are defined identically, a caller could pass the arguments in reverse order, and compilation would not catch the error.

I work in a 7.1 shop, so I do not use prototypes for internal subprocedures, i.e. the ones that function as local subroutines within a source member. I no longer use subroutines.

[danlong005]

Re: RPG subroutine with SQL

Ted's a thunder stealer! Just picking at you Ted. It is 100% correct.

While this is what I wanted to say... alas it is not what came out. Ted's explanation is much clearer to me than my own response. HA.

[Scott Klement]

Re: RPG subroutine with SQL

You are correct that having both a prototype and procedure interface in the same source member is unnecessary duplication. I suggest you put the prototype in a separate source member.

In this case, I suspect that the RPG code is only called from SQL, and never called from another RPG program. That being the case, I wouldn't put the prototype into a separate member. I only use a separate member when an RPG routine will need the prototype to call mine.

This sort of thing is, by the way, why I put in the requirement to IBM to eliminate the need for the PR when you didn't plan to use it. (This requirement resulted in not needing them in 7.1) If your program is never going to be called from another RPG program, but is only to be called from SQL, C, CL, etc, then it really doesn't make much sense to require a prototype, and IBM agreed and changed it. (Hurray!)

[kitvb1]

Re: RPG subroutine with SQL

... That is why on 7.1 the prototype is no longer needed if the procedure interface is coded in the calling program. ...

Does anyone know if there is any PTF for this for v6.1?

[B.Hauser]

Re: RPG subroutine with SQL

Prototypes are only optional for internal procedures.
For programs and exported procedures Prototypes are still required.

AFAIK there is no PTF for Release 6.1

Birgitta

[noppon_ch]

Re: RPG subroutine with SQL

* QRG7023 Severity: 40 Number: 1
Message . . . . : The Compiler cannot determine how program can
terminate. Program will loop.

*inlr = on;

[tomliotta]

Re: RPG subroutine with SQL

* QRG7023...

First, is there a question? Second, does it have anything to do with this thread? I can't see any connection.

[Barbara Morris]

Re: RPG subroutine with SQL

Prototypes are only optional for internal procedures.
For programs and exported procedures Prototypes are still required.

Here's what it says in the What's New in 7.1 section of the RPG manuals. (I'm not sure if it also says this in some other part of either the reference or the programmer's guide.)

Optional prototypes
If a program or procedure is not called by another RPG module, it is optional to specify the prototype. The prototype may be omitted for the
following types of programs and procedures:

• A program that is only intended to be used as an exit program or as the command-processing program for a command
• A program that is only intended to be called from a different programming language
• A procedure that is not exported from the module
• A procedure that is exported from the module but only intended to be called from a different programming language

Since the compiler doesn't know whether a prototype is needed, it no longer requires a prototype for a program or exported procedure. Now, it's up to RPG programmers to use prototypes correctly.

[Barbara Morris]

Re: RPG subroutine with SQL

First, is there a question? Second, does it have anything to do with this thread? I can't see any connection.

QRG7023 was mentioned in the OP.

[tomliotta]

Re: RPG subroutine with SQL

QRG7023 was mentioned in the OP.

Ah, yes. It was back there and was somewhat secondary in indicating where the actual problems were. Thanks for helping me remember to be awake when I browse through here. It helps at times.