Open topic with navigation
WTSupported in traditional Synergy on Windows
WNSupported in Synergy .NET on Windows
USupported on UNIX
VSupported on OpenVMS
The file specification of the ELB to attach to. (a)
The OPENELB subroutine attaches to the specified ELB, making the ELB’s subroutines available to the executing program. In a single routine, you can call OPENELB for a library and then XCALL the library’s routines using XSUBR. In multiple routines, you can call OPENELB for a library, and then in a separate subroutine that is XCALLed later, you can directly execute subroutines from the library. (When a subroutine is first XCALLed, all routines that are directly XCALLed from that routine must be in libraries that are already open.)
Each call to OPENELB opens the specified ELB and any ELBs that are linked to it. If a specified ELB or any linked ELB is not found, the runtime generates a “File not found” error ($ERR_FNF).
On Windows and UNIX, the maximum number of ELBs that can be open at any one time is 256, including all ELBs that are specified on the dblink command line or linked against the specified ELBs and automatically opened when the program is started. The maximum length of elb_spec, including the directory path and/or logical, is 31 characters.
In Synergy .NET, OPENELB does not use an .elb extension. It opens .NET assemblies according to the rules for loading assemblies in the .NET Framework. Assemblies can be loaded using a partial name (e.g., Synergex.SynergyDE.synxml), a fully qualified name (e.g., Synergex.SynergyDE.synxml, Version=188.8.131.52, Culture=neutral, PublicKeyToken=114C5DBB1312A8BC), or a full path (e.g., C:\Windows\assembly\GAC_MSIL\Synergex.SynergyDE.synxml\184.108.40.206__114c5dbb1312a8bc\
Synergex.SynergyDE.synxml.dll). Microsoft’s recommended practice when loading assemblies is to use the fully qualified name when possible, to prevent versioning issues.
OPENELB is not supported for portable class libraries, Universal Windows Platform, or iOS. (Although it is available for Android, we strongly recommend against using it for this platform.)
Synergy/DE for OpenVMS uses shared executable images to implement ELBs. Elb_spec must be a filename or logical for the shared image name; do not include a device, directory, or file type field. The logical for the shared image must have the same name as the shared image and must translate to the filename and path of the shared image. For example:
xcall openelb("mysharedimage") $ define mysharedimage path:mysharedimage.exe
$ define path disk:[directory.subdirectory]
$ define mysharedimage disk:[directory.subdirectory]mysharedimage.exe
The OPENELB subroutine adds the referenced shared images to the active list of shared images for subsequent access through calls to the XSUBR subroutine. If you are using objects with virtual methods defined in a shared image, calling OPENELB with the shared image is necessary for the runtime to be able to find the virtual methods when they are called. It performs no other actions in the OpenVMS environment.
By default, OpenVMS attempts to locate the ELB in SYS$SHARE unless elb_spec is a logical. The only way to use an ELB that is not in SYS$SHARE is by assigning a logical to refer to it and using that logical name in the OPENELB subroutine.
record elb_name ,a30 ;Executable library name end_of_modlist ,d1 ;Have we reached the end of the ; list of installed modules? ; 1 yes, 0 no proc repeat begin ;From installation data base, get name ; of executable library for next module xcall nxt_module(elb_name, end_of_modlist) if end_of_modlist ;If no more modules installed, exitloop ; we're finished xcall openelb(elb_name) ;Open executable library ; for current module end xreturn end