RPG ILE Problem Calling Bound Procedure
Kevin Bogue
I'm fairly new to RPG IV & ILE, but I've been working through a lot of
problems until this one.
I am writing a CGI program that uses a good number of prototyped, bound
procedures. My thinking is to build a common set of procedures into a
service program and then bind that to any future similar programs. My CGI
program functions properly as far at the basic web i/o, and I've
successfully created and used 12+ prototyped procedures that are
consolidated into a service program for binding.
This last one is the exception. I am getting this error "RNQ0202 The call
to .... ended in error". On looking at the job log, I see just prior a
message indicating "Pointer not set for location referenced.". I don't know
what this means and I can't find any information.
The procedures is being passed a character field, and two numeric fields.
The function is to examine the character field and try to return an area
code and phone number.
I've checked the prototype definitions vs. PI, changed the type of the
numeric Parms from Zoned to Packed to Blank to Character (thinking I'd
convert it post Call). No luck.
I've written the thing over from scratch thinking I'd missed something.
I've stripped the routine of all logic except a direct assignment of a
value, hoping to see that the darned thing can be called and return a value,
no luck.
I'm calling it via CALLP (just like the other 12 working procedures I've
written). I've searched IBM PTF cover letters, but nothing jumps out at me.
Ok, here's the kicker, I coded the SAME CODE (cut 'n paste) INSIDE of the
RPG and it works.
Anybody got some suggestions?
Thanks,
Kevin
Tyler, Texas
Troy Paulson
this same problem for as long as I've been writing CGI in RPGLE. When you
say that it works when the code is in the program, do you mean that the
message isn't in the job log any more, or that it shows your web page? With
mine, the programs all work fine, but I keep getting the Pointer not set
error in my job log. If your not getting the message in the job log, I
would be very interested in seeing the code your using to call this
prototype.
"Kevin Bogue" <k_b...@hotmail.com> wrote in message
news:te14f07...@corp.supernews.com...
Kevin Bogue
Sorry I wasn't more clear. The trouble I am having is with a simple
procedure to read the contents of a text string assumed to contain a phone
number (and whatever extraneous junk the user types). It reads the string,
removing everything except digits, then puts the remaining value into either
a 7 digit numeric (phone number) and/or a 3 digit numeric (area code). The
prototype for this simply defines the procedure interface ( I may not be
using the terminology as well as I could), that is:
Prototype is:
D #CvtPhone PR
D PhoneStr 20A Options(*varsize)
D NewArea 3S 0
D NewPhone 7S 0
D ErrFlag 1A Options(*NoPass)
Procedure Interface, within the procedure itself:
(identical except PI instead of PR)
Why am I focusing on the Prototype def?, because the CALLP to the procedure
bombs (leading me to think the info on the call is bad), and I also had some
errors earlier specifically identifying non-matching parameters. As I
mentioned, I monkied around with the Prototype/PI def to no avail. Also, to
be sure it wasn't the code itself, I basically gutted the C-Specs of the
procedure, and simply assigned values to NewArea and NewPhone. Still No
Luck. I coded a dump into the program just prior to the CallP and the
values it is sending are just as I expect them to be.
Regarding the other, my CGI is working well. When I have the code in the
program (rather than in a Service Program), I do get my webpage, and I don't
get an error on the Pointer mentioned earlier. For that matter, if I don't
call this procedure, I get my webpage and otherwise things are fine.
Problem is, I anticipate using this particular procedure quite a bit (so I
want to define it outside of each program) *and* I have some similar
procedures to write (my first iteration of them had the same problem). I
haven't had any problems with the CVTDB, but I am using Mel Rothman's
"GETINPUT" procedure from this CGIDEVSAVF found somewhere in the bowels of
IBM's techstudio website.
Kevin
Tyler, Texas
"Troy Paulson" <tpau...@nsc-inc.com> wrote in message
news:bY0E6.30$ZP6.1110@client...
SJ Lennon
provided:
1) Are you sure you have bound the latest version of the code into the
service program?
2) Are you sure the library list is right and you are getting the
latest version of the service program?
3) If ErrFlag is not passed and you try to access it you will probably
get the pointer not set message. Use the %PARM bif to check how many
parms are passed and if less than 4 do not attempt to reference ErrFlag.
4) Gut the calling program that is failing, hard code the calling
parameter values, put the service program in debug and stop it at the
first C-spec and examine the passed parameters.
Sam
"Kevin Bogue" <k_b...@hotmail.com> wrote in message
news:te1aq14...@corp.supernews.com...
Njål Fisketjøn
<k_b...@hotmail.com> wrote:
>Troy,
>
>Sorry I wasn't more clear. The trouble I am having is with a simple
>procedure to read the contents of a text string assumed to contain a phone
>number (and whatever extraneous junk the user types). It reads the string,
>removing everything except digits, then puts the remaining value into either
>a 7 digit numeric (phone number) and/or a 3 digit numeric (area code). The
>prototype for this simply defines the procedure interface ( I may not be
>using the terminology as well as I could), that is:
>
>Prototype is:
>D #CvtPhone PR
>D PhoneStr 20A Options(*varsize)
>D NewArea 3S 0
>D NewPhone 7S 0
>D ErrFlag 1A Options(*NoPass)
>
Are you specifying the ErrFlag parm when calling the procedure?
If not, the code may work inside an RPG program if the ErrFlag field
is defined there.
My guess (the same as SJ Lennon's alt. 3) is that you're accessing
ErrFlag without passing it.
--
Njål Fisketjøn, FIGU DATA AS
n...@figu.no
Michael Daly
for location referenced", describes an error in the parameters passed, BUT
that error may not (and in most cases, is not) associated with the
prototype/procedure currently being called. The problem is most likely with
the call immediately preceding the one that reports the error.
I would suggest that your previous call is returning more data than what you
are allowing for, and that extra data is spilling over into the allocated
space for your current call's parameters. (I hope that makes sense to
you...it doesn't make much sense to me, and I just wrote it!!!)
In other words, check the parm list of the procedure being called just prior
to the one that fails.
Michael
"Kevin Bogue" <k_b...@hotmail.com> wrote in message
news:te14f07...@corp.supernews.com...
Kevin Bogue
the responses.
Well, you guys were right on about my referring to the ErrFlag parameter,
which I was not passing. I am embarrassed not to have caught that one. I am
of course now using %PARMS prior to using the ErrFlag parameter in any way.
At the risk of still further embarrassment, I'd like to float the rest of
the problem.
I am getting a compile error *RNF7535 on the two numeric parameters at the
CALLP to this procedure. My procedure interface is defined to accept a 20
Char String (PhoneString), a 3.0 Zoned Numeric (NewArea), a 7.0 Zoned
Numeric (NewPhone), and an optional (now properly referenced) 1 Char String
(ErrFlag). The two numerics I am sending are defined in an external data
file as Zoned Numeric, same lengths. The error message is telling me the
type of the data sent is incompatible with the data expected.
I can define, via D-Specs, two zoned numeric fields and send them to the
procedure. It them compiles and works as expected. What am I missing? Is
an External File Definition of type "S" not equivalent to a D-Spec data type
of "S"? When I search the spooled file compiler listing for occurrences of
the variables passed (the ones from the external data file), I see that they
are being picked up as zoned from the file, however later in the same
listing, they are listed as Packed ex. VARNAM P(3,0).
Many, many thanks for your time to answer.
Kevin Bogue
Tyler, Texas
<-------------->
"Njål Fisketjøn" <n...@figu.no> wrote in message
news:<t7n3et8dfekhf1e66...@4ax.com>...
Are you specifying the ErrFlag parm when calling the procedure? If not, the
code may work inside an RPG program if the ErrFlag field is defined there.
My guess (the same as SJ Lennon's alt. 3) is that you're accessing ErrFlag
without passing it.
--
Njål Fisketjøn, FIGU DATA AS
<--------------->
B Morris
less than 20 bytes long. If you change the entire
first parameter, you could corrupt data in the caller
(for example if you pass a 1-byte field, and your
procedure does something that changes the entire
PhoneStr, you will change not only the 1-byte field
in the caller, but also the 19 bytes that happen to
follow it in storage.)
In general, whenever you code OPTIONS(*anything), you
have to add code to your called program or procedure
to handle the possibility that the caller took advantage
of the option.
SJ Lennon
Looks like the same is happening with an externally defined data
structure.
If you must keep the external definiton as zoned, try passing the two
parameters by value and the I think they will be automatically converted
for you.
Sam
"Kevin Bogue" <k_b...@hotmail.com> wrote in message
news:te93m3g...@corp.supernews.com...
B Morris
changing. What's zoned in the file is zoned in the DS.
Njål Fisketjøn
<k_b...@hotmail.com> wrote:
>
>I am getting a compile error *RNF7535 on the two numeric parameters at the
>CALLP to this procedure. My procedure interface is defined to accept a 20
>Char String (PhoneString), a 3.0 Zoned Numeric (NewArea), a 7.0 Zoned
>Numeric (NewPhone), and an optional (now properly referenced) 1 Char String
>(ErrFlag). The two numerics I am sending are defined in an external data
>file as Zoned Numeric, same lengths. The error message is telling me the
>type of the data sent is incompatible with the data expected.
>
>I can define, via D-Specs, two zoned numeric fields and send them to the
>procedure. It them compiles and works as expected. What am I missing? Is
>an External File Definition of type "S" not equivalent to a D-Spec data type
>of "S"? When I search the spooled file compiler listing for occurrences of
>the variables passed (the ones from the external data file), I see that they
>are being picked up as zoned from the file, however later in the same
>listing, they are listed as Packed ex. VARNAM P(3,0).
>
>Many, many thanks for your time to answer.
>
What does the CROSSREF section display for the fields? Are there
multiple D (definitions) showing up?
Kevin Bogue
news:3AE5C6FF...@ca.ibm.com...
Before this problem, I would have agreed (external zoned numeric treated as
such in an RPG program). However, it would not seem to be so (at least in
the program I'm working on). I have a need for the external data to be
defined as Zoned, so I wrote my procedure to accept Zoned numerics. As has
been documented in this thread, this fails at compile with an error message
citing data incompatibility.
Per SJ Lennon's post, I decided to change the procedure to accept Packed
Numerics. This now works fine whenever I send Packed Numerics fields *OR*
my externally defined Zoned Numerics. Therefore, I am moving on, but I
thought this deserved a mention.
I greatly appreciate all who took time to respond.
Kevin Bogue
Tyler, Texas
Kevin Bogue
> <k_b...@hotmail.com> wrote:
> >
> >I am getting a compile error *RNF7535 on the two numeric parameters at
the
> >CALLP to this procedure. My procedure interface is defined to accept a 20
> >Char String (PhoneString), a 3.0 Zoned Numeric (NewArea), a 7.0 Zoned
> >Numeric (NewPhone), and an optional (now properly referenced) 1 Char
String
> >(ErrFlag). The two numerics I am sending are defined in an external data
> >file as Zoned Numeric, same lengths. The error message is telling me the
> >type of the data sent is incompatible with the data expected.
> >
> >I can define, via D-Specs, two zoned numeric fields and send them to the
> >procedure. It them compiles and works as expected. What am I missing?
Is
> >an External File Definition of type "S" not equivalent to a D-Spec data
type
> >of "S"? When I search the spooled file compiler listing for occurrences
of
> >the variables passed (the ones from the external data file), I see that
they
> >are being picked up as zoned from the file, however later in the same
> >listing, they are listed as Packed ex. VARNAM P(3,0).
> >
>
> multiple D (definitions) showing up?
>
Zoned. When I look at the compiler listing and search for either of the
field names defined externally, I get references to the file in a "pseudo"
I-Spec, and a "pseudo" O-Spec. (By pseudo, I mean they are inserted by the
compiler, not actually in the source member) There are no D-Spec references
to these fields (either in the original source or in the compiler
insertions). Both definitions (I/O specs) are referencing information from
the external file defining the fields. Both definitions in these specs are
Zoned, as would be expected. Specifically, the types are "S" the from-thru
length is 3 and 7 respectively. Again, all is right with the world.
Looking further down the compiler listing, the "Global Field
References"/Cross Reference section again lists the field name. Only now it
lists them as Packed, that is P(3,0) and P(7,0) respectively.
I must repeat that my programming problem is resolved (by coding the
procedure to accept Packed numerics), but the remaining question about why
is a bit nagging. Don't worry, I'll get over it.
Kevin
Tyler, Texas
Hans
> The two variables I am working with are externally defined 3.0 and 7.0
> Zoned. When I look at the compiler listing and search for either of the
> field names defined externally, I get references to the file in a "pseudo"
> I-Spec, and a "pseudo" O-Spec. (By pseudo, I mean they are inserted by the
> compiler, not actually in the source member) There are no D-Spec references
> to these fields (either in the original source or in the compiler
> insertions). Both definitions (I/O specs) are referencing information from
> the external file defining the fields. Both definitions in these specs are
> Zoned, as would be expected. Specifically, the types are "S" the from-thru
> length is 3 and 7 respectively. Again, all is right with the world.
>
> Looking further down the compiler listing, the "Global Field
> References"/Cross Reference section again lists the field name. Only now it
> lists them as Packed, that is P(3,0) and P(7,0) respectively.
>
> I must repeat that my programming problem is resolved (by coding the
> procedure to accept Packed numerics), but the remaining question about why
> is a bit nagging. Don't worry, I'll get over it.
>
> Kevin
> Tyler, Texas
Welcome to the Wonderful World of RPG!
What you are seeing is normal behavior. Understand the difference
between
external format and internal format - the two are not necessarily
related
in RPG. If a field in an externally described file is defined as
numeric,
then by default, a field with the same name gets defined internally
within
the RPG program, but defined with format packed. When RPG reads a
record,
the data is converted from external format to the internal format
defined
for the field. If you wish, you can explicitly define the field
internally
with whatever format you want, and the appropriate conversion will be
done
on input or output. If the format of the field within the RPG program
is
important (say as a procedure parameter), you should declare it
explicitly
within the program.
Cheers! Hans
bobc...@attglobal.net
Do you have EXPORT on your P spec for the procedure?
If it is stored in a *SRVPGM, did you specify EXPORT(*ALL) when using
CRTSRVPGM?
Do you use field referencing? We had hoped IBM changed the LIKE/*LIKE DEFINE
thing to actually work the way we think, in RPG IV, but it still doesn't
work, that is it works like RPGIII :(
Bob
"Kevin Bogue" <k_b...@hotmail.com> wrote in message
news:te14f07...@corp.supernews.com...