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



Interesting! I see no pointers at all in this code.

So... that update exists in procedure SetRepText, although this sample
doesn't have subprocedures; is that right? (Just making sure.)

If the program is failing on an UPDATE, sounds like it's time to remove the
*NODEBUGIO option and step through with debug again, noting exactly which
field of the update causes the failure. That's what I'd do. Then I'd try
to work backward to see how that field is special.

Random ponderables: Do we have nulls involved? Is there something unusual
about this record? Is this the first update, or were there some successful
updates beforehand? What were the column additions you made with SQL?
What's special about them? Does the problem persist if you replace your
ALTER TABLE with DDS that describes the additional columns (CHGPF to
implement)? If you try to do this same UPDATE with an SQL statement (and
the appropriate WHERE, etc.) in STRSQL session, what happens?

At least now I see why you say this is strangeness.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"This is the most extraordinary collection of talent, of human knowledge,
that has ever been gathered together at the White House -- with the possible
exception of when Thomas Jefferson dined here alone."
-- John F. Kennedy (to Nobel Prize winners)


For this type of error, one would need source code, and perhaps the
job log.
Also, please re-read the second half of your post. Something got
messed up
within and it makes no sense.

There is nothing proven to be bizarre below. Looks like a pointer is
not
re-initialized correctly but beyond that, gotta see that code.

Dennis Lovelady

Dennis,

To finish that bad sentence at the end: when I took the call to
QDBRTVFD out, it ran fine.

here's the relevant code: statement 00000045 in the joblog is the
"UPDATE" statement, and I've stepped through the code in debug and
that's where it bombs.

h dftactgrp(*no) actgrp(*caller) option(*nodebugio)

Fpgmreferr2UF e k disk

d ApiError ds
d AeBytPrv 10i 0 Inz( %Size(ApiError))
d AeBytAvl 10i 0 Inz
d AeExcpId 7a
d 1a
d AeExcpDta 128a

d RfFilNamQ s 20a
d RfFilNamRtnQ s 20a
d RfFmtNam s 8a
d RfFilOvr s 1a Inz( '0' )
d RfFilRcd s 10a
d RfFilSys s 10a Inz( '*LCL' )
d RfFmtTyp s 10a Inz( '*EXT' )

d RfFilInf ds 4096
d RfFilInfPrv 10i 0 OverLay(RfFilInf:5)
d Inz( %Size(RfFilInf))
d lvlchkbit 1A OverLay(RfFilInf:10)
d levelID 13A OverLay(RfFilInf:81)

d $libFile ds
d $reffile 10
d $reflib 10

d $attr s 10a

c PGMVER setll PGMREFERR2
c read PGMREFERR2

c dow not %eof(PGMREFERR2)

c call 'CLRTVOBJ'
c parm WHFNAM $reffile
c parm WHOTYP $reftype
c parm '*LIBL' $reflib
c parm $attr
c end

c if $attr = 'PF' or $attr = 'LF'
c eval RfFilNamQ = $libFile
c eval RfFilRcd = WHRFNM
c eval RfFmtNam = 'FILD0200'

c call 'QDBRTVFD'
c parm RfFilInf
c parm RfFilInfPrv
c parm RfFilNamRtnQ
c parm RfFmtNam
c parm RfFilNamQ
c parm RfFilRcd
c parm RfFilOvr
c parm RfFilSys
c parm RfFmtTyp
c parm ApiError

c eval FILFMT = levelID
c update QWHDRPPR

c read PGMREFERR2
c enddo

c eval *inlr = *on
c return

Joblog:

MCH3601 Escape 40 07/02/10 18:32:14.498256 QRNXIE QSYS *STMT QRNXIE
QSYS *STMT
From module . . . . . . . . : QRNXMSG
From procedure. . . . . . . : SetRepText
Statement . . . . . . . . . : 45
To module . . . . . . . . . : QRNXMSG
To procedure. . . . . . . . : SetRepText
Statement . . . . . . . . . : 45
Message . . . . : Pointer not set for location referenced.
Cause . . . . . : A pointer was used, either directly or as a
basing
pointer, that has not been set to an address.
CPF9999 Escape 40 07/02/10 18:32:14.498464 QMHUNMSG *N VFYPTFDB3
TMWTOOLS *STMT
To module . . . . . . . . . : VFYPTFDB3
To procedure. . . . . . . . : VFYPTFDB3
Statement . . . . . . . . . : 214
Message . . . . : Function check. MCH3601 unmonitored by QRNXIE
at statement
0000000045, instruction X'0000'.
Cause . . . . . : An escape exception message was sent to a
program which
did not monitor for that message. The full name of the program to
which the
unmonitored message was sent is QRNXIE QRNXMSG SetRepText. At the
time the
message was sent the program was stopped at higher level language
statement
number(s) 0000000045. If more than one statement number is shown,
the
program was a bound program. Optimization does not allow a single
statement
number to be determined. If *N is shown as a value, it means the
actual
value was not available. Recovery . . . : See the low level
messages
previously listed to locate the cause of the function check.
Correct any
errors, and then try the request again.
MCH3601 Escape 40 07/02/10 18:32:14.498504 < allProgram 000B24
QRNXIE QSYS *STMT
From Program. . . . . . . . : AiUpcallProgram
To module . . . . . . . . . : QRNXERR
To procedure. . . . . . . . : ReceiveMessage
Statement . . . . . . . . . : 7
Message . . . . : Pointer not set for location referenced.
Cause . . . . . : A pointer was used, either directly or as a
basing
pointer, that has not been set to an address.
MCH3601 Escape 40 07/02/10 18:32:14.498600 < allProgram 000B24
QRNXIE QSYS *STMT
From Program. . . . . . . . : AiUpcallProgram
To module . . . . . . . . . : QRNXMSG
To procedure. . . . . . . . : SignalException
Statement . . . . . . . . . : 21
Message . . . . : Pointer not set for location referenced.
Cause . . . . . : A pointer was used, either directly or as a
basing
pointer, that has not been set to an address.
CEE3201 Diagnostic 10 07/02/10 18:32:14.499064 QLEAWI QSYS *STMT
QRNXIE QSYS *STMT
From module . . . . . . . . : QLEDEH
From procedure. . . . . . . : Q LE leDefaultEh
Statement . . . . . . . . . : 75
To module . . . . . . . . . : QRNXERR
To procedure. . . . . . . . : _QRNX_UNEXP
Statement . . . . . . . . . : 11
Message . . . . : Exception recursion detected.
Cause . . . . . : An unhandled exception occurred in an exception
handler.
Recovery . . . : Do not let an exception that occurs in your
exception
handler go unhandled.
CEE9901 Escape 30 07/02/10 18:32:14.499160 QLEAWI QSYS *STMT QUOCMD
QSYS 03B3
From module . . . . . . . . : QLETOOL
From procedure. . . . . . . : Q LE AWIRaise
Statement . . . . . . . . . : 184
Message . . . . : Application error. *N unmonitored by *N at
statement *N,
instruction X'4000'.
Cause . . . . . : The application ended abnormally because an
exception
occurred and was not handled. The name of the program to which the
unhandled exception is sent is *N *N . The program was stopped at
the
high-level language statement number(s) *N at the time the
message was sent.
If more than one statement number is shown, the program is an
optimized ILE
program. Optimization does not allow a single statement number to
be
determined. If *N is shown as a value, it means the real value was
not
available. Recovery . . . : See the low level messages previously
listed
to locate the cause of the exception. Correct any errors, and
then try the
request again.

Original post:
meanwhile back at the ranch.... bizarre stuff below:

I'm testing this program that calls the QDBRTVFD api (retrieve
database file description) and updates a file with info retrieved
from
the API.

It loops through reading records from an UF file - calls the API,
updates the record.

After the second read, second call to the API (which didn't error
out), the second update bombs with the following errors:

Pointer not set for location referenced.
Function check. MCH3601 unmonitored by QRNXIE at statement
0000000045,
  instruction X'0000'.
Pointer not set for location referenced.
Pointer not set for location referenced.
Exception recursion detected.
Application error.  *N unmonitored by *N at statement *N,
instruction
  X'4000'.
Application error.  *N unmonitored by *N at statement *N,
instruction
  X'4000'.

secondary text on the MCH3601:
Message . . . . :   Function check. MCH3601 unmonitored by QRNXIE at
statement
  0000000045, instruction X'0000'.
Cause . . . . . :   An escape exception message was sent to a
program
which
  did not monitor for that message. The full name of the program to
which the
  unmonitored message was sent is QRNXIE QRNXMSG SetRepText. At the
time the
  message was sent the program was stopped at higher level language
statement
  number(s) 0000000045. If more than one statement number is shown,
the
  program was a bound program. Optimization does not allow a single
statement
  number to be determined. If *N is shown as a value, it means the
actual
  value was not available.

If I take the call to the API out, it

the only things I do in this program that are out of the ordinary:

I run a CHGLIBL command several times during this job
The file I'm updating is a DSPPGMREF *outfile that I've used SQL to
add fields to the end of.

Any ideas?




On Fri, Jul 2, 2010 at 1:51 PM, rick baird <rick.baird@xxxxxxxxx>
wrote:
hey all,

has anyone retrieved the format level ID for a display file record
using an API?

for database files, I use QDBRTVFD format FILD0200, but it doesn't
work for display files.

I looked and looked for that info in the doc for QDFRTVFD api, but
I
don't see it.

I know it's out there - you can see the info at the bottom of
DSPFD
dspfname.

thanks,

Rick

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.