Regarding ISN Buffer limit (Adabas Vista Error : +0249).

, , ,
1

Hi All,

I have loaded one record in adabas file which has ISN value greater than 2,147,483,647.

I am receiving adabas response +0249 (Adabas Vista Error).

02 ADA-CTRL-ADDITIONS-2 X(4) …
4400
000F

ISN length is S9(9) COMP.

I need sample ISN code to put in application program’s control block. These cobol adabas programs have direct ADABAS calls for online processing.

Error +0249 information:

The partitioning field value specified in the record buffer of the A1 command is inconsistent with the partition criteria defined to the partition identified by the ISN in the Adabas control block.

Such an update requires the relocation of the ISN to another partition, which is not allowed.

Action: Review the application program. Use a delete and store as an alternative.

Record buffer is receiving output as per format buffers. Value buffer has input and search buffer has descriptor.

Incorrect -ve ISN value is same from S1,HI and A1 call. While amending it is giving +0249.

Could you please suggest what changes i need to make in record buffer or in control block as per error description to get correct isn value from adabas call.

Below structure I am sending while calling adabas from cobol program and receiving +0249.

From Natural program ISN = +2147527533 for the same record and via cobol-adabas call with below structure i am getting ISN value as -2147448637.

Do i need to change isn’s data type S9(9) COMP to any other data type. Some leads suggested to try S9(10) and 9(10) comp, but it is not working.

Could you please suggest.

02 ADA-CTRL-FILLER-1 S9(4) COMP +0000
02 ADA-CTRL-COMMAND-CODE X(2) A1
02 ADA-CTRL-COMMAND-ID X(4) ST11
02 ADA-CTRL-FILE-NUMBER S9(4) COMP +31229
02 ADA-CTRL-RESPONSE S9(4) COMP +0249
02 ADA-CTRL-ISN S9(9) COMP -2147448637
02 ADA-CTRL-ISN-LOW-LIMIT S9(9) COMP +00000000
02 ADA-CTRL-ISN-QUANTITY S9(9) COMP +00000000
02 ADA-CTRL-FORMAT-BUFF-L S9(4) COMP +0102
02 ADA-CTRL-RECORD-BUFF-L S9(4) COMP +0401
02 ADA-CTRL-SEARCH-BUFF-L S9(4) COMP +0000
02 ADA-CTRL-VALUE-BUFF-L S9(4) COMP +0000
02 ADA-CTRL-ISN-BUFF-L S9(4) COMP +0000

2

Hi,
The relevant information is the subcode x’000F’ or decimal 15 for the RSP249.
This infers the following:

  1. The A1 command is being used to update a field which is defined as the Adabas Vista Partitioning Field ie the field by which the file has been partitioned.
  2. The A1 is updating this field to a value which - based on the defined partitioning criteria (refer to the definition of this file in Vista Online Services) - will result in the record (identified by the ISN) being moved from its current partition (Adabas file) to another partition (Adabas file).
    Vista does not support such record relocation and rejects the update with a RSP249 subcode decimal 15.

Such relocations are unusual for Adabas Vista installations due to the considered choice of the Partitioning Field at implementation time.

For those installations where relocations are necessary then the normal practice is to identify these occasions and perform the following:

  • Read the full record from its current location
  • Delete the record
  • Change the record field value accordingly
  • Store the record (at which point Vista will pick out the new value and route the record to the appropriate partition based on the defined partition criteria.)

If this is your first experience of a subcode 15 - and the first experience of it within your application group - then i would recommend to bring it to the attention of your Adabas DBA who may already be familiar with the issue.

3

Thank You Geoff,

Actually calls are failing with +0249 for few records of production and for max records it is working fine.

As per existing functionality S1,HI, A1 call is amending data.

Deleting and inserting will totally change the program. Not sure client will accept it.

Could you please suggest if you know any parameter we need to pass in control block to get isn+partition number as a output-isn of adabas call.

4

Hi,
The ACBISN field is an unsigned 4 byte binary field.

The A1 should specify the same 4 byte ISN value that was returned to the S1.
You gave an example of Natural reporting an ISN of 2147527533 which is x’8000AB6D’.
So when x’8000AB6D’ is returned to the S1, the identical value x’8000AB6D’ must be supplied on the A1.

I would suggest dumping out the full ACB immediately on return from the S1 and immediately before issuing the A1 in order to confirm the binary values are indeed the same.

Perhaps the program is not correctly handling the unsigned nature of the ACBISN field and providing an incorrect ISN to the A1 which then manifests itself as a RSP249 subcode 15.

5

Thanks Geoff,

Control block is initialized before A1 call and only ISN from S1 call is saved in working-storage variable and moved to HI for hold and then passed to A1 call.

ISN value is same from S1 to HI to A1.

Natural code only client have and they told isn from natural which is +ve isn.

We have only cobol-adabas code which is returning -ve isn with different number.

ISN from S1 call is moved to HI and A1.
S1 and HI call are giving response code normal +0000 as may be because it is not updating database.

A1 call is using same ISN of S1 call output.

Control block is same in all calls only command id S1,HI and A1 is changing.

I think code fix is required from S1 call itself to get right isn in output as same is moving to HI and A1.
There is something missed in control block i guess and that’s why incorrect -ve isn is returned from cobol-adabas S1 call.