Dependency Functions


Dependency functions are subroutines written in Caché ObjectScript or M that can be declared in order to express advanced conditions on a transfer route. Any function declared must return 1 or the transfer will fail.

Usage


1. Write your custom routine and save it in the namespace where Deltanji is installed. The routine should be named in accordance with Deltanji's routine naming conventions.

2. Specify the function in the 'dependency' field of the transfer route properties dialog in the following way: $$linelabel^%vcmzCustomRoutineName

Note: By setting the global ^%vcvc("customDependencyRoutine") to the name of your custom routine (without ^ prefix), you can specify the dependency function in the transfer route properties dialog as $$linelabel instead of $$linelabel^%vcmzCustomRoutineName

Note: Specifying a function from the pre-built dependency function routine %vc1xvf (see below) can be done using the following shorthand notation: $$%linelabel

Pre-built dependency functions


Deltanji comes packaged with a routine called %vc1xvf (on Caché / Ensemble this is an INT routine) which contains a series of useful dependency functions for you to use and modify. Note that if you do want to modify a function from this routine, you should copy the function to a new routine and make the modifications there. This will prevent the loss of any customization when Deltanji is upgraded. Remember to name any custom routines you create in accordance with the Deltanji's routine naming conventions.

The are the functions contained in %vc1xvf and a brief explanation of what each one does:

Function name / line label Explanation
AllowedAt(lcode3) Permits the transfer only if, based on system membership, the object version would be accepted at the location name passed in the lcode3 parameter.
CanActivateAt(lcode3) Permits the transfer only if the object version is permitted to activate at the location name passed in the lcode3 parameter. See the comments within the function in %vc1xvf for more information.
CannotFitAt(lcode3) Permits the transfer only if the object version would not fit at the location name passed in the lcode3 parameter.
DisallowedAt(lcode3) Permits the transfer only if, based on system membership, the object version would not be accepted at the location name passed in the lcode3 parameter.
First Prevents concurrent development by checking whether or not the transfer of the object version constitutes its first check out.
HasType(ctypes) Permits the transfer only if the object version contains at least one component of at least one of the types in the colon-delimited list passed in the ctypes parameter.
IsMaster Permits the transfer only if the object version is the master copy at the from location.
IsMasterAt(lcode3) Permits the transfer only if the object version is the master copy at the location name passed in the lcode3 parameter.
NewObject Permits the transfer only if no version of the object already at the to location.
NoCDL (Deprecated) Permits the transfer only if the object version contains no CDL components.
NoCLS Permits the transfer only if the object version contains no CLS components.
NotAt(lcode3) Similar to the 'LocationName dependency, except this function handles successor versions at single-version locations differently. See the comments within the function in %vc1xvf
NotMapped Permits the transfer only if none of the object version's CLS, INC, INT or MAC components being sourced from M-format storage are mapped in from a database other than the namespace's default one.
NotMaster Permits the transfer only if the object version is not the master copy at the from location.
NotMasterAt(lcode3) Permits the transfer only if the object version is not the master copy at the location name passed in the lcode3 parameter.
NoType(ctypes) Permits the transfer only if the object version contains no components of the type(s) in the colon-delimited list passed in the ctypes parameter.
V0 Permits the transfer only if the object version is version 0 of the object.