11 replies to this topic

[JC Jones]

Version 5.0, green screen, RH Linux OS

We have a problem selecting records from a PRO-ISAM file using SEL-(ANYTHING) when not assigning all keys for a single specific record select. The file has 4 keys, and if we assign all 4 keys and use SEL-ONLY the single record is retrieved fine. We need to retrieve all records with only the first 2 keys matching but for some reason with this particular file we get no reads at all when only the first two keys are defined before the SEL-XXXX statment.

The following examples are in an update function with 3 LU's, the first 2 LU's are getting the information needed from other files needed to access (and subsequently filter the retrieved records) from this file. Everything works perfectly until the 3rd LU retrieves no records unless it's forced to retrieve a single specific record. The following code is in the Default Logic for the 3rd LU.

For example:
This works perfectly and retrieves the specific record requested:
IM.TTYPE = "S"
IM.ITREF = " 250192"
IM.ITSEQ = "002"
IM.TFLAG = ""
SEL-ONLY(IM.TFLAG)

Any of the following retrieve absolutely no records (no after read logic hit):
IM.TTYPE = "S"
IM.ITREF = " 250192"
SEL-ONLY(IM.ITREF)

IM.TTYPE = "S"
IM.ITREF = " 250192"
SEL-PARTIAL(IM.ITREF)

IM.TTYPE = "S"
IM.ITREF = " 250192"
IM.ITSEQ = "0"
SEL-ONLY(IM.ITSEQ)

IM.TTYPE = "S"
IM.ITREF = " 250192"
IM.ITSEQ = "001"
IM.TFLAG = ""
$END_KEY = @COMP + IM.TTYPE + IM.ITREF + "999"
SEL-RANGE($END_KEY)

This is the only file that has this problem, we use the set one or more keys and use SEL-ONLY on the last key set all the time and never have any problems.

The definition of the file is attached - any ideas as to what the problem with this file may be?

We have checked the file for corruption and it's clean, we've checked the file for size limit and and it's well within the defined file size.

Thanks,
JC Jones

Attached Files

•  imhist.txt   4.4KB   175 downloads

[Abstract Typist]

One-time flag?...

[JC Jones]

One-time flag?...

Thanks for the quick reply

I thought maybe I had a "Duh!" moment, and actually had to check...

Anyway, the One-time flag is set to "N". Attached is the documentation for the function, it's a really simple function and we've put an additional SEL-ONLY on the first file for debugging so we are only looking for information on a single record (which has several records on the 2nd LU and also several records on the 3rd LU).

JC Jones

Attached Files

•  imihdu.txt   5.77KB   142 downloads

[Ted Happ]

Why are you adding blanks in front of IM.ITREF? Is it LFB (right justified)?

[JC Jones]

Why are you adding blanks in front of IM.ITREF? Is it LFB (right justified)?

Yes, IM.ITREF is LFB and a length of 7, the particular type of record we are looking for has the Invoice Number in the IM.ITREF field and the Invoice Number is only between 1 and 6 characters.

I know that this function *should* work, and when testing the 3rd LU to make sure it isn't a problem with it somehow by using a completely different file with 4 keys, it will read correctly. The 3rd LU simply doesn't select anything to read unless all 4 keys are assigned before the SEL-ONLY. One of the strangest thing I've come across with PROIV yet.

Also, there are not any other functions anywhere in our system that I can find that access the IM.HIST file without using all 4 keys. I was hoping that somebody would see something that I'm missing as to why this problem is occuring.

JC Jones

[andykay]

Yes, IM.ITREF is LFB and a length of 7, the particular type of record we are looking for has the Invoice Number in the IM.ITREF field and the Invoice Number is only between 1 and 6 characters.

JC,

Is the IM.ITREF field name used in any other file? The reason I ask is that you seem animately sure that the IM.ITREF field is LFB, but the file definition you attached says otherwise.

001...K...IM.TTYPE....1
002...K...IM.ITREF.....7
003...K...IM.ITSEQ....3...LFZ
004...K...IM.TFLAG....1

AK

[andykay]

JC,

Could you post the file definition of the file with the Invoice field that gets placed into the IM.ITREF field, and the LS DEF for the function that actually creates the IM.HIST record.

AK

[Shaun Rudland]

File definition is Auto-Sequence, but the last key part is not the sequence. Shouldn't it be ?

[George Macken]

Hi

I agree with Shaun on the Auto-Seq Flag as the probable cause

Additionally,
Is this a new file definition in your Application ?
Is it used successfully in other functions ?
You can used iskeys to view the keys of records in the table ?
run ischk to verfiy the table is OK

Copy the File Def to create ANOther File DEF that does not have the Auto-Seq flag set, that this File DEF also points at IMHIST as the Alternate (** do not physically file ***) - then use this file def in your function and it may then work.

TGIF

George

[Abstract Typist]

This is a Pro-ISAM file right?
What size is it?
What recordsize was it created with?
How many records are in it?
What happens if you try to use iskeys to display the range of keys in question (-s and -e options)?

[Abstract Typist]

Hey, JC Jones!

Did you figure this problem out then?
Just interested in what it was

[Lewis Mccabe]

File definition is Auto-Sequence, but the last key part is not the sequence. Shouldn't it be ?

Yes the last key must be the sequence part of the key. Additionally, make sure you set all the key variables to the file prior to the sequence number and init the sequence number in logic in of the LS/cycle - such as:

VAR1 = '123'
VAR2 = '345'
SEQ_VAR = ''
SEL-ONLY(VAR2)

When using auto sequence files with screens and the screen is set as paging screen, the logic in should not contain SEL-XXX. Just set the non sequence portion of the key, and init the sequence portion.

HTH.

Lew