|
View previous topic :: View next topic
|
| Author |
Message |
shijug2000
New User
Joined: 31 Jan 2007
Posts: 3
Location: india
|
|
|
|
While reading from an IMS HIDAM database using Get Next call, Some of the records are getting lost.
The program is running as BMP. PROCOPT used in PSB is 'GOT'. Database is brought up with an Access Mode of 'RO'. The problem usually occurs after a huge insert/update to database. Database is kept up through the week days and it will be brought down on weekends while reorganization is done. The records those are getting missed in one run of the program seems to get read in the subsequent runs. There are no other programs which updates this database during the same window.
If we run the same program on the copy of the database in test region, None of the records are getting missed.
The program is written in such a way to handle all status code other than Spaces and GB.
seeking suggestions ..... |
|
| Back to top |
|
 |
Bitneuker
CICS Moderator
Joined: 07 Nov 2005
Posts: 1104
Location: The Netherlands at Hole 19
|
|
|
|
| Any locks during buildup? Command code Q without DEQ? |
|
| Back to top |
|
|
shijug2000
New User
Joined: 31 Jan 2007
Posts: 3
Location: india
|
|
|
|
George,
Thanks for your quick response.
The database is brought up by a JCL which is scheduled weekly.
The JCL is having only "/sta DB Database-Name,access=RO", in it. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Might it be possible that the "test" is "complete" as it was loaded en-mass as opposed to production only being able to see what has been written to disk?
In some environments, online updates are "buffered" and are available to online processes, but batch processes will not see them until they are written to disk. |
|
| Back to top |
|
|
shijug2000
New User
Joined: 31 Jan 2007
Posts: 3
Location: india
|
|
|
|
Inserts/Updates to the concerned database is done through a Batch process, Not online (To elaborate, The changes entered thru online will be stored in a change database and This will be updated/added into the actual database by a batch job, depending on the effective date given).
After the Inserts/Update, an image copy will be created, on which I had done the testing.
A few hours after this, The extract Job will run, in which, some of the records will be getting lost.
This is not a one time issue. this occurs whenever we have large Number of inserts/Updates to database.
I have a question... Is there any option/setting in IMS that will suppress the Status Code 'GG'?
Thanks for the help... |
|
| Back to top |
|
|
Bitneuker
CICS Moderator
Joined: 07 Nov 2005
Posts: 1104
Location: The Netherlands at Hole 19
|
|
|
|
From the good manual following the link in my signature:
| Quote: |
GG
Explanation:
DL/I returns this status code if the segment being retrieved contains an invalid pointer and the application program has a processing option of GOT or GON. (Processing options are explained under PROCOPT in the discussion of program specification block generation in IMS Version 9: Utilities Reference: System.) This can occur when update activity in the database is going on concurrently with your program's processing.
DFSVSMxx option PPUR=Y can be used to prevent this status if it was received when running a PROCOPT=GOx transaction accessing HALDB partitions and a partition is found to be unavailable due to a database command in progress.
For call-level programs:
The PCB key feedback length and area will be based on the last segment that satisfied the call. Your position is at the beginning of the database.
For command-level programs:
If your request specified KEYFEEDBACK, the DIBKFBL will contain the length of the key of the last segment that satisfied the command. Your position is at the beginning of the database.
Rather than having an abnormal termination occur, this status code is returned to the application program that issued the EXEC DLI command.
Programmer response:
Continue processing with another segment or terminate the program. The request that resulted in the GG status code might be successful if you issue it again.
|
|
|
| Back to top |
|
|
|
|
