I-DESCRIPTORS
Purpose of I-Descriptors (quick introduction)
Internal Descriptors are equivalent to calculated fields in Excel. They are not physical fields inside a table -compared to what LOCAL.REF fields are- but computed fields that can be simply added in the dictionary of a table. Once added in a table’s dictionary (e.g. STANDARD.SELECTION), you can immediately use such an I-descriptor in any ENQUIRY (as an extra field or selection criteria) , as well as in any other I-descriptor from the same or different table.
Example of I-DESC: – You want to store a foreign key reference (for instance the description of a SECURITY.MASTER when you’re requesting the SECURITY.POSITION file. – You want to compute the outstanding open positions when requesting a SECURITY.MASTER ID. – etc…
J-Descriptors
A sub category of “I”-descriptors is “J-descriptors” (J for Join): it simply allow to store the definition of foreign keys. Let’s say you are requesting the ACCOUNT table, and need to get the sector of the customer owning the account. Either you make temporarily this join in the enquiry itself, or you think can be useful for multiple enquiries. So you just need to add in the ACCOUNT table dictionary a new field (“J-descriptor”) which stores permanently the definition of the “sector of the customer attached to the account”.
To do this you just add an new User field “CUST.SECTOR”, type= “J”, and definition will use following syntax:
CUSTOMER.NO>CUSTOMER>SECTOR
with:
> : indirection indicator.
CUSTOMER.NO is a local field from ACCOUNT, which will be the starting point from ACCOUNT to reach CUSTOMER (this is named a foreign key of CUSTOMER table)
CUSTOMER is the table where you’ll get the sector information (you’re making a join between ACCOUNT and CUSTOMER.
SECTOR is the attribute you want to get from the foreign table CUSTOMER.
Usage of I-descriptors
IF Usage
Conditional testing, must be associated with THEN and (optional) ELSE Example : Business context: Associate an external broker code to a transaction, that can be deducted from several criterions.
USR.FIELD.NAME. BROKER.CODE USR.TYPE....... I USR.FIELD.NO CUSTOMER; USR.FIELD.NO OWN.BOOK; USR.FIELD.NO TREAS.MIRROR.FLAG; USR.FIELD.NO IF @1 EQ "555555" THEN "0B333" ELSE "CL333"; USR.FIELD.NO IF (@3 EQ "Y" OR @2 NE "") THEN "0T333" ELSE @4
Note that each single element such as a constant or field or parameter should be declared and separated by a semi-comma ;. To re-use a pre-defined a constant, field or parameter in a function / formulae, you re-call it using @ followed by its position in the declaration. Example: @3 refers to constant, field or parameter declared in the third position e.g. after the second ;.
Multi-dimensional comparisons (IFS, EQS, GTS, MULS,…
When you manipulate multi-dimensional fields (multivalues or subvalues) also called vectors in your early math classes ;-), you can not simply use standard IF or EQ operators. T24 offers specific functions for multi-dimensional fields, equivalent to operators for single valued fields :
IF => IFS() EQ => EQS() GT => GTS() LT => LTS() * => MULS()
Example : Business context: Say you want to get signed lots from DX.REP.POSITION whereas such quantities are not signed in standard T24. Because you have to compare each multivalued “TX.BUY.SELL” fields to the “BUY” constant :
- you must take IFS() instead of IF - you must take the REUSE() function for the BUY constant in order to adapt it to the dimension of the vector. - To get minus lots when SELLs, you must replace a standard TX.LOTS * -1 formula (adapted to single valued fields) with the MULS() function.
In a schema, it gives the following vector:
TX.BUY.SELL | CONSTANT | TX.LOTS | New I-DESC |
BUY | BUY | 5 | 5 |
SELL | BUY | 8 | -8 |
BUY | BUY | 10 | 10 |
SELL | BUY | 6 | -6 |
In a STANDARD.SELECTION, you can then define a new “I_DESC” this way:
USR.FIELD.NAME. NEW.I.DESC USR.TYPE....... I USR.FIELD.NO TX.BUY.SELL; USR.FIELD.NO TX.LOTS; USR.FIELD.NO MULS(TX.LOTS,REUSE(-1)); USR.FIELD.NO IFS(EQS(@1,REUSE("BUY")),@2,@3)
Make a CALL in an I-descriptor
The first argument in an I-descriptor is by default the return parameter, thus you don’t have to fill it. Example of routine with following parameters: SUBROUTINE DX.GET.CONTRACT.DATES(RETURN.DATE, CONTRACT.CODE, MAT.PERIOD, DATE.TO.RETURN, RETURN.CODE) In the I-descriptor, RETURN.DATE parameter should be avoided. which gives:
15. 4 USR.FIELD.NAME. FIRST.NOTICE 16. 4 USR.TYPE....... I 17. 4. 1 USR.FIELD.NO CONTRACT; 17. 4. 2 USR.FIELD.NO SUBR("TRANS","DX.CONTRACT.MASTER" 17. 4. 3 USR.FIELD.NO ,@1,"FIRST.NOTICE"); 17. 4. 4 USR.FIELD.NO MATURITY.DATE; 17. 4. 5 USR.FIELD.NO "FIRST.NOTICE"; 17. 4. 6 USR.FIELD.NO SUBR("DX.GET.CONTRACT.DATES",@1,@3,@4,""); 17. 4. 7 USR.FIELD.NO IF @2 NE "" THEN @5 ELSE ""
Jbase Documentation on this topic can be reach here:
http://www.jbase.com/r5/knowledgebase/manuals/3.0/30manpages/man/sup12_I_TYPES.htm