Prior to fSeries version 3.4 the sequence in which a DSD’s data groups is executed was determined by the order you put them in within the DSD. It was up to the DSD designer to determine the correct order.

Since 3.4 fData automatically searches the DSD to find all dependencies between data groups and calculates the correct sequence of execution to make sure that everything a data group needs is done before it starts.

A data group may be dependent on another for many reasons:

• It has a parent data group
• It has a base (like merged or filter data groups)
• It has a placeholder that references another data group as its source or in a function
• It has a data item that references another data group in a function
• It has dependencies that are set by the data group type (e.g. an Abandon data group can now specify which data groups it affects)
• The DSD designer may even themselves specify that one data group is dependent on another

All of these are taken into account and a picture is built up of the overall dependencies within a DSD. When executed, the DSD’s data groups are executed in the best sequence to satisfy all of the requirements. If there is a loop the DSD will return no data, but you will be warned of this before saving your DSD.

If you want to check whether any of your DSDs have dependency loops, run the web page CheckDependencyLoops.aspx from your fSeries domain for a report. If you don’t have version 3.4 yet you can prepare by asking Fibonacci support for this page to be installed (it can be run before you upgrade to 3.4). The report will check all your published DSDs and list those that have dependency loops.

Not only does this automatic dependency calculation ensure that DSDs are being run in the correct order, without the person designing the DSD figuring it out, but this also makes another version 3.4 option possible: Asynchronous Data Gathering.