You would have to read the DirXML-DriverConfig attribute from the Driver object (Use the auto GCV to get the DN).  May have to B64 decode it.  You coudl use the Document token but I find it just as easy to use Source Attribute.

Then XPATH out the item you want.

No tokens.

Interestingly enough in a driver shim, the built in classes support easily reading driver parameters but not GCVs.  Which is why the gcv-ref Syntax type exists for GCV/Driver Settings I think.  You specify it once, as a Driver Config, then in the GCV you point at that, so change it once, changes it in two places so to speak.  Then it is easy to read in either place.

Thanks for the great explanation!  May be more hassle then it's worth for what I wanted to do.

Also thanks for the gcv-ref explanation.  I often wondered why the heck sometimes the values would be in two places.  I didn't understand what the purpose was!

Matt

That is the part of the docs, everyone leaves out.  They tell you a list of things you can do. Rarely do they tell why you should do this vs that, and how it works, or why this setting exists.

I wish that info was more available for every product.

When a driver shim is started, the engine calls https://www.netiq.com/documentation/identity-manager-developer/driver-developer-kit/javadocs/com/novell/nds/dirxml/driver/DriverShim.html#init-com.novell.nds.dirxml.driver.XmlDocument- and sends the contents of DirXML-ShimConfigInfo. 

If you have settings that are required by both a shim and in policy, then specify it as GCV and reference it it in the driver configuration using gcv-ref. The engine will then inject the values before initializing a shim.

To read DirXML-ShimConfigInfo (or any other stream attribute that contains XML) in policy use

<do-set-local-variable name="shimConfigInfo" scope="driver">
	<arg-node-set>
		<token-document>
			<arg-string>
				<token-text xml:space="preserve">vnd.nds.stream:</token-text>
				<token-text xml:space="preserve">/</token-text>
				<token-parse-dn dest-dn-delims="00,/+=*\" dest-dn-format="custom"
					src-dn-format="slash">
					<token-global-variable name="dirxml.auto.driverdn" />
				</token-parse-dn>
				<token-text xml:space="preserve">#</token-text>
				<token-text xml:space="preserve">DirXML-ShimConfigInfo</token-text>
			</arg-string>
		</token-document>
	</arg-node-set>
</do-set-local-variable>

Norbert Klasen  What would the difference between using Source Attribute at the same attribute vs the Document token?  Might have to B64 decode it, but otherwise seems a simpler task than remembering the custom parse DN pattern. 

Geoffrey, I have personally just learnt the custom parse DN pattern. Why reinvent the wheel when the vendor has already provided a decent one for you.

From memory, using the document approach is significantly less "verbose" in the trace than using the source attribute.
Arguably, the DirXML-Script is longer though. (has always irritated me that using token-global-variable is overly verbose and less efficient compared to the tilde expansion alternative, unless you need node-set context that is) 

Wondering if token-document is more efficient internally regarding code that is called. When policy execution goes awry, the engine normally reports the problematic policy using the vnd.nds.stream DN syntax, so maybe that is ultimately the native format used by the engine.

I have made great use of gcv-ref in many drivers I have worked on in the past.

One driver that really suits gcv-ref is the scripting driver, where so much of the logic can potentially be handled in the "custom shim" that one has to write scripts to handle. I found myself often requiring contextual information in said scripts that might need to change depending on the environment. So I made GCVs for these parameters, referenced them as gcv-ref in driver params and then could easily access the same info from within the scripts I wrote.

In more recent times, the scripting driver incorporated the ability for scripts to "query back" to the IDVault and read GCVs directly, but that is slower than accessing the same information that the scripting driver automatically caches locally during driver startup.

gcv-refs can be a bit tricky if using driver packages though.

Can you clarify the packaging issues please?

Has been many years since I dabbled in that specific space, had sort of hoped that it had been solved in the intervening years.

Relates back to the issue of properly implemented base packages and the necessity of keeping them as streamlined as possible.

Cannot recall all the details but there were challenges with the way the package stylesheets worked, either prompts or upgrades.

My plan was to have a series of add-on packages that each included the GCV and also updated the Driver Parameters with a matching gcv-ref entry.

Discovered that this was far trickier than I thought it would be. That updating driver parameters was only possible using the package prompt stylesheets from the base driver package.

So, every time one wanted to add a new GCV and gcv-ref pair, for say a new optional feature, one had to issue a corresponding base package update also.

I believe a real world example of this kind of issue is mentioned here in this thread.
Azure AD Driver error Global Configuration Value 'drv.team.user.owner' not found

Another bug I vaguely recall was that the base package stylesheet kept on adding the same GCV ref entry to the driver parameters on every upgrade.

That makes sense that to update the driver config, you need a base package, and a prompt resource. Annoying I agree.  BUt not fixed as far as I know.