OPENELB

Make an ELB’s subroutines available to executing program

WTSupported in traditional Synergy on Windows

WNSupported in Synergy .NET on Windows

USupported on UNIX

VSupported on OpenVMS

xcall OPENELB(elb_spec)

Arguments

elb_spec

The file specification of the ELB to attach to. (a)

Discussion

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=2.0.0.0, Culture=neutral, PublicKeyToken=114C5DBB1312A8BC), or a full path (e.g., C:\Windows\assembly\GAC_MSIL\Synergex.SynergyDE.synxml\2.0.0.0__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.

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]

or

$ 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.

Examples

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