Here's what I inherited (unfortunately not simple in structure):
DICT Record: PMG.NAMED.DEFENDANT.REFER.NUMBER
0001: I
0002: IF @RECORD<3> # "Y" THEN "" ELSE IF PMG.ADD.INSURED.FLAG = "Y"
THEN PMG.ADD.INSURED.REFER.NO ELSE IF PMG.PCF.ACCT.ID # "" THEN
PMG.PCF.ACCT.ID ELSE PMG.INSURED.REFER.NUMBER
The fields that are referenced above are working fine - it's the last
field (PMG.INSURED.REFER.NUMBER) that does the subroutine calls that are
causing issues:
Record name = PMG.INSURED.REFER.NUMBER (this is an indexed field,
and is having no trouble by itself)
0001: I
0002: SUBR("PMG.INSURED.REFER.NUMBER
",PMG.CG.NOTICE.DATE,PMG.COVERAGE.CONTEXT,22)
There are 4 data files this subroutine opens using EQU BMS$.FILENAME TO
COM.FILE(nnn), then OPEN "FILENAME" TO BMS$.FILENAME. It then sets a few
variables, and then calls another subroutine:
CALL CL.GET.COVERAGE.RISK(ERR.PACKET,IARGS,OARGS)
This subroutine sets the EQU BMS$.FILENAME TO COM.FILE(nnn), then READs
records from the 4 data files to formulate values to be returned.
> SELECT CLAIMS SAVING PMG.NAMED.DEFENDANT.REFER.NUMBER - works fine.
> SELECT CLAIMS BY PMG.NAMED.DEFENDANT.REFER.NUMBER - processes for a
while, then starts kicking 'Read operation failure' errors.
These Read operation failures are also kicking when we attempt to
BUILD.INDEX on this field (the original source of finding the problem).
|---------+---------------------------------->
| | Kathleeni M Bodine |
| | <[EMAIL PROTECTED]|
| | t> |
| | Sent by: |
| | [EMAIL PROTECTED]|
| | er.u2ug.org |
| | |
| | |
| | 10/25/2004 01:31 PM |
| | Please respond to |
| | u2-users |
| | |
|---------+---------------------------------->
>---------------------------------------------------------------------------------------------------------------|
|
|
| To: <[EMAIL PROTECTED]>
|
| cc:
|
| Subject: RE: [U2] [UV] 10.1 SELECT FILE BY DICT (I-type - SUBR) causing
Read operation failure |
>---------------------------------------------------------------------------------------------------------------|
Is the dictionary use the attribute that is index and what is the
dictionary
doing that you would access the index files.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dennis Bartlett
Sent: Monday, October 25, 2004 9:04 AM
To: [EMAIL PROTECTED]
Subject: RE: [U2] [UV] 10.1 SELECT FILE BY DICT (I-type - SUBR) causing
Read
operation failure
AIX 5.2, Universe 10.1.2
We're getting exactly the same thing ... so far we've kinda eliminated all
things 'cept the index, so that was our focus today. A rebuild of the
offending index fixed the problem.
maybe that'll help?
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, 25 October, 2004 3:58 PM
To: [EMAIL PROTECTED]
Subject: [U2] [UV] 10.1 SELECT FILE BY DICT (I-type - SUBR) causing Read
operation failure
Just upgraded to AIX 5.2 and UV 10.1 and we're thinking we may be filling
some
workspace somewhere.
Here's what we have:
A DICT I-Type that calls a subroutine. This subroutine sets some
variables,
then calls another
subroutine that does READs of 3 different files to produce a value.
When we LIST FILENAME DICTITEM it processes fine, and will list out all
records with values
for this field.
When we SELECT FILENAME SAVING DICTITEM it also processes fine, and
returns
an active select
of values which we can save.
However, sorting, with SELECT FILENAME BY DICTITEM (even with SAMPLE
nnnnn)
processes to a
point, then starts kicking out 'Read operation failure' errors. Once
this
happens, we have to
log out/in of UniVerse to reset or the errors will kick right away if we
issue the command
again.
This statement worked fine at release 9.5 prior to upgrading. We
verified
the settings in
uvconfig, and tested the data files being used for any corruption - none
found.
We're needing to build an index on this field, and can't get past the
selection.
Anyone run into anything similar? Thanks!
-----------------------------------------------------------
This email and any files transmitted with it are intended only for the
person
or entity to which it is addressed and may contain confidential
and/or privileged material. If you received this email in error, please
contact the sender immediately and delete this email from your system. If
you
are not the named addressee, you should not disseminate, distribute, print,
or
copy the email, or take any action in reliance on its contents.
-------
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/
---------------------------------------------------------
GWK BEPERK/LIMITED (REG: 1997/022252/06)
POSBUS 47 PO BOX 8730
DOUGLAS
Direkteure/Directors: NB Jacobs, FJ Lawrence, J v/d S Botes,
JH Coetzee, JGD Smit, JF Jacobs, AO M|ller, JW Smit,
JP Snyman, JG Stander, JH van Dyk(MD/BD), JG Jacobs, A M|ller, M van Zyl,
Sekr/Secr: E van Niekerk.
Hierdie e-pos is onderworpe aan 'n vrywaring beskikbaar by:
http://www.gwk.co.za/DisclaimerVrywaring.asp
This e-mail is subjected to the disclaimer that can be viewed at:
http://www.gwk.co.za/DisclaimerVrywaring.asp
-------
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/
-----------------------------------------------------------
This email and any files transmitted with it are intended only for the
person or entity to which it is addressed and may contain confidential
and/or privileged material. If you received this email in error, please
contact the sender immediately and delete this email from your system. If
you are not the named addressee, you should not disseminate, distribute,
print, or copy the email, or take any action in reliance on its contents.
-------
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/
