COBOL/400 problem with DUPLICATES
Kathy
There are two AS/400s - the Dev box and the Y2K test box.
Both boxes are on the same version of OS (i.e. V4R2) and both have
up-to-date PTFs.
COBOL programs can only be compiled on the Dev box. There is no COBOL
compiler on the Y2K box. Compiled program objects are sent to the Y2K box
for testing. So we are talking about exactly the same COBOL pgm object
running on both boxes.
The file in question is a logical file with a UNIQUE key.
The program uses the 'WITH DUPLICATES' phrase in the select statement.
On the Dev box the program successfully opens the file and runs OK (which it
shouldn't - see the bottom for an excerpt from the IBM manual).
On the Y2K box the program falls over with a return code of 95 on the OPEN
statement for the file (as it should)
So I removed the WITH DUPLICATES phrase from the program, recompiled it on
the Dev box and sent a copy of the compiled object to the Y2K box. Guess
what. Now it doesn't work on the Dev box, but it does on the Y2K box (as it
should).
Any ideas as to what's up with the Dev box? The files are created in exactly
the same way, using the same DDS and creation options. I've run a DSPFD on
them both to double check and they're the same. The only difference is the
data on the two boxes but I reckon this is irrelevant, particularly
considering I can get the program to run on both boxes with different SELECT
statements.
From the IBM manual:
=======================================================
Users can indicate DUPLICATES on the RECORD KEY clause. A file status of
95 is returned after a successful open when:
The DUPLICATES phrase is specified in the COBOL program and the file
was created with UNIQUE specified in DDS.
The DUPLICATES phrase is not specified in the COBOL program and the
file was created allowing nonunique keys.
Processing files when either of these conditions exist can cause
unpredictable results.
=======================================================
Email: ka...@lunaresaltd.com
--
E-mail: ka...@lunarsealtd.com
Dan Riehl
hmmmmm....that's a weird one...I've never seen this
I can only suggest you check the file on the Y2K box again.... and
make sure that's the one the program is actually opening... (e.g.
Maybe a *LIBL problem??)
If that is not the problem.... in lieu of a "real" answer.... you can
compile the one for the Y2K box as needed.... and sent it over... than
on the prod box... keep it as needed....
I know that this will put your Y2K test box out of sync with the prod
box.... but you don't have much time to mess around... do you?
dan
On Mon, 29 Nov 1999 22:32:20 -0000, "Kathy" <ka...@lunarsealtd.com>
wrote:
Dan Riehl News/400 Technical Editor
dri...@400school.com
http://www.400school.com
Peter_Schalber
1. test your Cobol program on the dev box with a DDM file to the Y2K box.
2. test your Cobol program on the Y2K box with a DDM file to the Dev box.
3.Test your library list
4. test your library QRPLOBJ for old objects.
Peter
"Kathy" <ka...@lunarsealtd.com> wrote in message
news:81uutf$b0u$1...@news1.cableinet.co.uk...
Peter Lunde
objects with the same name as your file.
I have had this problem when a duplicate object name exists at the same
level or higher on the library list.
Sincerely,
Peter Lunde.
Kathy
After spending much time checking the library lists (which were fine),
whether there were any other objects with the same names resident on the
machines (there weren't) and going through the file and object descriptions
with fine-toothed combs (there were no differences), we decided to rebuild
the offending files on the development machine. Yes, you guessed it,
suddenly everything was Ok again.
The program was now failing on the Dev box as well as the Y2K test box (as
it should), so I was able to remove the 'WITH DUPLICATES' phrase, recompile
and successfully run the programs on all boxes. All's well that ends well,
but it still doesn't answer the mystery as to how it happened in the first
place.
One of you mentioned in your note that you had experienced problems with the
status 95 before - don't forget that when processing a logical file within a
program, all other related access paths are also checked, even if the file
isn't specified in the program. So if you are doing something to one logical
that will cause duplicates in another logical that is related to the same
physical, you may well get a status 95. Sounds confusing, so check out the
manuals for a better description of this.
Thanks again for your time and interest.
Kathy Cheung.
Ian Stewart
may have missed something here, but ... your comment about other logicals being
relevant here doesn't make sense to me.
Obviously, if some other logical stipulating unique key(s) exists over the
physical file, then any attempt to write a record to the physical could fail
with an invalid key error (regardless of which logical the write is performed
on). I think that in COBOL it would generate a "22" (invalid key) or similar
status in this situation?
The "95" status is generated at open time only, as far as I know, and only looks
at the attributes of the actual file opened, vs the attributes specified on the
SELECT statement - I can't figure how any other logical could enter into this
equation.
I noticed that there are quite different semantics for processing updates
depending on whether the DUPLICATES attribute is specified on the SELECT
statement - if it is, then the record must be retrieved before updating, and if
not, it will access and then update the record based on the key fields in the
record, without any requirement to have previously retrieved the record. The
two approaches seem to me to be significantly different, and in the latter case,
would appear to impose quite a performance overhead if implemented as stated
(i.e. if a record is first read, then rewritten, I guess two reads would occur).
A while back, I constructed a simple test to compare the performance (two
versions of the test program, the only difference being the DUPLICATES
attribute, same file, several runs of each): the results clearly showed that
specifying DUPLICATES (and ignoring the "95" status generated) performed
significantly quicker when doing a sequential update process. The DUPLICATES
attribute is an IBM extension, I guess the other behaviour is to maintain
compatibility with standard COBOL?
Has anyone had any problems when ignoring the "95" status when opening a file
with a unique keyed access path (i.e. specifying DUPLICATES on the SELECT
statement as described above)? I would expect problems doing it the other way
around (that is, no DUPLICATES attribute on the SELECT statement, but opening a
file allowing duplicates).
Personally I prefer the semantics of retrieving a record, holding a lock on it,
then updating it as RPG does, to the COBOL behaviour when DUPLICATES is not
specified. Quite apart from the performance penalty, I feel there is scope for
updating the wrong record if the keys are accidentally modified, and I wonder
whether there is any possibility of some other process getting a lock on the
record at the point where a rewrite is executed (i.e. if the record is
read/locked, then the rewrite comes along to re-read it, is the lock released
and reacquired, or is it guaranteed that the lock will be retained until the
rewrite has completed?)
-Ian.
Kathy wrote:
<snip>
> One of you mentioned in your note that you had experienced problems with the
> status 95 before - don't forget that when processing a logical file within a
> program, all other related access paths are also checked, even if the file
> isn't specified in the program. So if you are doing something to one logical
> that will cause duplicates in another logical that is related to the same
> physical, you may well get a status 95. Sounds confusing, so check out the
> manuals for a better description of this.
--
Ian Stewart
i...@incognito.co.nz