By design, the Y-valve attaches no semantics to a connect string, but
merely passes the connection string and database parameter block to the
providers (called subsystems in pre-Vulcan lingo) until one responds
with a successful attachment. Over time, this mechanism has gotten
rather muddled with the Y-valve. Rather than polling the subsystems,
the FB2 Y-valve is now trying to anticipate what subsystems may or may
not do, sometimes expanding the connection string, sometimes not, and
sometimes looking up the string in the aliases table. This works, to
the degree that it does work, only because the Y-valve is written with
full knowledge of what subsystems are present and what they do.
However, it doesn't scale with an open ended set of providers, and it
can get us into serious trouble if the Y-valve gets it wrong. The XNet
remote protocol handler, for examples, expands unqualified file names on
the client side. If the connection string is a name know to a server
side provider, this will fail.

The Vulcan Y-valve, unlike the FB2 equivalent, makes no attempt to
expand anything. XNet, in particular, adds the current working
directory to database parameter block and passes the connect string sans
"ipc#" to the server. If and when this hit the engine, the file name
expansion code extracts the working directory from the database
parameter block, performing the same expansion as the client would
have. I haven't made a full archeological study, but I suspect that it
once worked this was as well, maybe even recently. Maybe it would make
sense to add the same logic to the TCP protocol handler if it recognizes
the node name as "localhost". While straightforward (a flag in the Port
object controls whether the working directory is added to the dpb), it
means that the semantics of "localhost::foo.fdb" and "myhost:foo.fdb"
would be different. On the other hand, it would provide a local connect
with the same filename semantics as XNet, a significant plus.

I don't see any immediate problem with the FB2 Y-valve. It works and
will probably evaporate after the merge. But people should stop
thinking of Y-valve base filename expansions.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376