Conference clt::cobol

I don't really have an answer for the code you posted, but rather
a suggestion for an alternate approach.  

Status code 02 means there's another duplicate in the series.
It seems like that could be exploited in the program logic.

If there are 3 duplicate key values, for example, the first
and second read will give you an 02 meaning "there's another one".
Reading the last one will return an 00.

-Wendy

    
    Sorry, not much time just now. Still, some hints:
    
    	- Please define 'does not work'. It is not at all clear from
    	  a quick reading of the topic what the code was expected to
    	  do and how it behaved differently in reality.
    	  Was there a run time error? 
    	  Or a hard loop against the first key selected perhaps?
    
    	> START TIPOSTCODE_REQ KEY IS NOT LESS THAN PR_ALT_DBKEY...
    	> PERFORM DFDA_CALL_FHS.
	> READ TIPOSTCODE_REQ ALLOWING UPDATERS KEY IS PR_ALT_DBKEY.
    	
    	If the procedure called does not perform a READ NEXT then
    	the START is entirely wasted. It establishes a current 
    	record, ready to be read, but the READ provides its own key
    	and Thus go for its own current record. They may want to
    	try to reply the KEY clause with a NEXT RECORD?
    	
    	hth,
    		Hein.
    

    

Hi All,

Thanks for your replies so far.

To explain what the customer is hoping to do:
They have an application which stores the different possible addresses for a
customer.  ie. each customer has a mailing address,
a directory address, a contact address etc.

The primary key is the Billing Id, but the program has only got access to
the "Customer Id" ( PIC S9(9) ) which has duplicates.

So, the program wants to find the address record for a particular customer id
which has a "Source indicator" of 'S' and then possibly update it (later)
if it exists or create one if it doesn't.


I have got hold of a cut down version of the program and the data file.
I have changed the program to do as Hein suggests in .2

ie.
  START TIPOSTCODE_REQ KEY IS NOT LESS THAN PR_ALT_DBKEY...
  (Check status)
  READ TIPOSTCODE_REQ NEXT RECORD ALLOWING UPDATERS.
  (Check status)
    

Here are a list of valid customer id's which have records in the file (I know
because I can see them using Powerhouse).

    customer id
      131162
      131275

The problem is:

a) If I START with customer id = 131162, the system returns 131275 as the first
record when the first READ NEXT has executed.  (What happened to 131162 ? - it
is "NOT LESS THAN" the alternate key provided).

b) If I START with customer id = 131160 (which doesn't exist) then the
system again returns 131275 as the first record, skipping over the first record
131162 which satisfies the key condition.

Conceptually, I have difficult with the term "Next Record" after a
START, since READ NEXT RECORD after a START would seem to indicate that it
would not read Current Record (!?!) which START had found, and is what I want!
Anyway, if (.2) is correct and certainly the User Manual seems to suggest that
this is the way to do it,

Either,

1. I have overlooked something obvious.

2. There is a problem with the (old) version (V4.4) of VAX COBOL which means
that it should work but doesn't.  I have not currently got access to a
current version.

3. There is possibly a mismatch between the program's view of the file and the
actual file.  I have done an ANALYZE/RMS/FDL on the file with no obvious
problems reported.  The key offsets and size seem to match the copybook view of
the file.

BTW. If I specify 
  START TIPOSTCODE_REQ KEY IS EQUAL TO PR_ALT_DBKEY...
                           ^^^^^^^^^^^
then the program doesn't find ANY of the valid records at all !
All I get is Error 23 on the START.


Any suggestions or further comment heartily welcomed.

Thanks for your interest,

Malcolm McCulloch

>I have got hold of a cut down version of the program and the data file.
>I have changed the program to do as Hein suggests in .2
>
>ie.
>  START TIPOSTCODE_REQ KEY IS NOT LESS THAN PR_ALT_DBKEY...
>  (Check status)
>  READ TIPOSTCODE_REQ NEXT RECORD ALLOWING UPDATERS.
>  (Check status)
    
    If you put together a self-contained .COB which generates the data file
    and then tries to read it, we could try that .COB on our systems with a
    supported version of VAX COBOL (V5.4) to see if you are encountering
    a bug related to one of the many bugs fixes made since VAX COBOL V4.4.
    
    Also, VAX COBOL now has a feature /CHECK=DUPLICATES to do some
    additional validation that the way DUPLICATES is set for an input data
    file ISAM keys matches the use of DUPLICATES in the declaration of the
    file in the program.

>All I get is Error 23 on the START.

which says pretty clearly that the record is not in the file, which I 
think makes all the subsequent behavior expected.

>Here are a list of valid customer id's which have records in the file (I know
>because I can see them using Powerhouse).

I'm not familiar with what Powerhouse is or how it checks, but maybe the 
record is somehow corrupted or marked for deletion.

Can you regenerate the file and retry?

If you move 131162 to a PIC S9(9) field, I think it will contain

	00013116B

The "B" represents both the sign "+" and the digit "2".
Is this the form of the data in your file?  If the customer record you're
looking for is actually

	000131162

then it is less than the key you provide, and you won't find it.
(Notice that you tell COBOL the key is the group item, so it uses
character-string compare rules, not numeric compare rules ... I think.)

What happens if you declare the key to be PIC 9(9) instead of S9(9) ?

Re .0

The COBOL code in the base note looks reasonable. What you
have shown is not wrong in the sense that it is legal COBOL.
It should do something meaningful for the user although it 
certainly appears not to require the START step. FWIW COBOL 
programmers have been using that kind of logic ever since 
Indexed files with alternate keys became available under the 
ANSI-74 COBOL standard. 

However, as Don suggests in .4, your user may be utilizing a 
bug in VAX COBOL V4.4. If this is the case, it may be very 
difficult to decypher what was originally intended. Upgrades
sometimes run into those kinds of problems. 

I would also feel more comfortable to see a complete COBOL 
program with a symptom report that it is doing "X" under VAX 
COBOL V5.4, and it is expected to be doing "Y".

Hi All,

Thanks to all for their helpful replies.

But especially to the unnamed .6 who hit the nail on the head !

The copybook definition of the alternate key was PIC S9(9).
The RMS file (through the Powerhouse definition) was expecting an unsigned 9
byte key - ie character-string comparison.

Being a simple C and Pascal programmer of many years standing, and having all
of 2 month's COBOL experience, I had no idea of the effects of using a 
Signed value.  In other languages, the only difference is top-bit set !

So, after changing the PIC S9(9) to a PIC 9(9), the program "worked" perfectly!

Anyway, the customer is pleased, I am pleased and I think I have learnt a
valuable lesson:

  "Beware using PIC Signed entities in interfaces to External objects"

Thanks to all very much,

Malcolm McCulloch