Host connections

Host connections live on their own page at Settings → Host connections (/settings/host-connections), not inside a dialog, so creating one from an application never stacks a dialog on a dialog. They are shared: every application's Data source picks from the same list.

Reach and engine

Each connection has a name and a reach: direct JDBC or CoreIQ.

• A JDBC connection takes a JDBC URL. Its engine is discovered, not declared, the first time you test it.
• A CoreIQ connection starts from the CoreIQ gateway in Global Settings: its URL and default host are filled in for you and the host list loads straight away, and again whenever the URL or login changes. The refresh icon beside Host reads it again on demand. It then picks its endpoint from what CoreIQ reports, and that endpoint settles the engine: DB2 for z/OS, DB2 for i, IMS DL/I, or VSAM datasets from an OL-DS-SERVER or OL-DS-LOCAL endpoint.

Reach and engine are independent, so CoreIQ can reach DB2 for i as well as DB2 for z/OS. Only CoreIQ can reach IMS DL/I and VSAM; there is no JDBC driver for either.

Every connection takes the shared Mainframe credentials from Global Settings unless it overrides them with its own username and password. Passwords are write-only: a saved password is never sent back to the browser, and editing a connection leaves the field blank with Unchanged in it. Type a new password only to rotate it.

One host, several endpoints, one pass

A new CoreIQ connection lists every data endpoint the chosen host carries, each with the engine its type implies, and you tick the ones you want. A mainframe serving DB2, IMS and VSAM becomes three connections without typing the URL, the host or the credentials three times. Tick one and it keeps the name you type; tick several and each is named <host> · <endpoint>, because connection names are unique across the list. If one name is already taken the rest are still created, and the dialog stays open saying how many landed, with the failures still ticked.

Record writes on a VSAM endpoint

Writes to a dataset endpoint follow the CUD permissions an admin enables per endpoint in the CoreIQ admin panel: Update, Insert and Delete. OL Next has no switch of its own. When you pick a VSAM endpoint, the dialog shows the flags CoreIQ reports, for example Record writes: Update on · Insert off · Delete off. See Live host data through CoreIQ for how a session uses them.

Typing the ids by hand

When CoreIQ cannot be listed, give the host name, the host id and the endpoint id yourself and choose the engine. Choose VSAM datasets and a Dataset endpoint appears as well, OL-DS-SERVER or OL-DS-LOCAL, because nothing has reported the endpoint's type, and that type, not its name, is what CoreIQ routes a dataset on. It starts at OL-DS-SERVER, so a host that reads its own datasets has to be switched to OL-DS-LOCAL here. The other engines have one endpoint type each, so they ask nothing further.

Verify endpoint

Verify endpoint (CoreIQ rows, the row's ⋯ menu) re-reads CoreIQ and checks the row still points where it did. Re-registering a host on CoreIQ re-mints its host and endpoint ids, and a stale endpoint id does not fail: CoreIQ falls back to the first endpoint of that type, so the session quietly reads a different database. A changed host id is repaired in place, because the host name is what routes. A re-minted endpoint is found again by its name, which CoreIQ keeps across a re-registration, and re-pointed without asking. Only an endpoint whose name is gone too, or a connection saved before names were recorded, opens the editor for you to pick a replacement.

Test connection

For a CoreIQ connection, Test connection asks the endpoint for its schema list, checking the URL, the credentials, the host and the engine, then checks the host id against that host. The host name is what a statement routes to; the host id only tells CoreIQ whose stored credentials to use, so an id belonging to a different host would run this host's statements under another host's credentials, and the test names both ids and refuses. It also checks the endpoint id and names the endpoints available on that host if it does not match. A CoreIQ that does not serve a host list leaves the verdict to the schema check alone, and a wrong host name fails with Host not found. For a JDBC connection, the test opens the connection and fills in the engine from what the database reports.

The table

Reach reads CoreIQ or JDBC, Credentials reads Shared login or the connection's own username, and Used by counts the applications pointing at it, on either axis, since one application can use one connection for SQL and another for its datasets. Use New to create a connection and the row's ⋯ menu to edit or test one. Delete is disabled on a row in use, with the count as the reason.

Applications carrying database settings from before connections existed are converted the first time this page is read. A banner names how many were converted; Recheck re-reads the list to confirm none are left.