This section details specific programming considerations when dealing with Extreme partitioned files.
The mathematical maximum number of records for an Extreme partitioned file (across all the partitions) is determined by the maximum number of partitions multiplied by the maximum number of records per partition.
The maximum number of partitions is 255.
The maximum number of records per partition is 4,294,967,294.
Good programming practices generally result in well-formed application logic. Here are examples of well-formed application logic.
A typical nested access connecting records of two files:
READ file-one BY abc FROM ‘1001’
Some processing on the *ISN(file-one)
FIND file-two WITH def = def(file-one)
Some processing on the *ISN(file-two) and perhaps also *ISN(file-one)
END-FIND
END-READ
Add a modification into this (no END
TRANSACTION is used to simplify the illustration):
READ file-one BY abc FROM ‘1001’
Some processing on the *ISN(file-one)
FIND file-two WITH def = def(file-one)
Some processing on the *ISN(file-two) and perhaps also *ISN(file-one)
UPDATE (or DELETE) *ISN(file-two)
END-FIND
UPDATE (or DELETE) *ISN(file-one)
END-READ
For the purposes of Extreme partitioned files, this logic is well-formed because the iterations deal with one record at a time, the current record.
In Natural programming this is typified by *ISN. Most application logic is programmed in this way, for no other reason than it makes sense because sensible application logic is cost-efficient to maintain. Extreme partitioned files transparently support this logic because Adabas Vista maintains in memory partition details for the most recently used record(s).
In modern applications it is quite difficult to produce poorly-formed logic simply because the language syntax used today are themselves well-formed. Natural is an excellent example of that. However there are special cases where this may be necessary or there may be very old applications (usually 3GL) that are called where the logic is not so well-formed. These situations give rise to exceptions, which means you may have to adjust the application logic to adopt Extreme partitioned files (and perhaps even Standard partitioned files).
One classic example is where an application makes use of USERISN for a file. In this situation the application can use an ISN on a command that it has previously stored, in a file or in memory, meaning the command bears no relationship to any concept of current record – a clear indication of an application not being well-formed. There may also be other circumstances where an ISN-based command is used that conflicts with what would otherwise be considered the current record.
The current implementation of Extreme partitioned files does not support these exceptional circumstances, it may therefore be necessary to make small changes to the application in these (usually) relatively few areas. If such changes are not possible then contact Software AG to discuss your requirements as it may be possible to provide APIs to support particular situations.
ISN values relating to Extreme partitioned files are transient in their nature and therefore applications must not infer any persistent meaning to such ISN values. If such persistence is applicable then refer to section Application logic that is not well-formed for additional guidelines.
Due to its transient nature, an application must not use an ISN value relating to an Extreme partitioned file as data.
When converting an Adabas file to an Extreme partitioned file, any ISNs for the file that may have been stored as data in other files will be invalidated.
ISN values relating to Extreme partitioned files that are supplied by an application must be ones that Adabas Vista itself has previously returned within the current client session and from within the same Adabas session.
The CONVISN API is not currently supported for Extreme partitioned files.