[benetti-marco]

Problem

New SQL jobs did not reflect the connection's current library. The library list passed to Mapepire is built as [config.currentLibrary, ...config.libraryList], but the JDBC driver never uses the first entry as current library: it only adds it to the library list. As a result, every job kept the user profile's CURLIB:

• with a current library configured, the job had the profile's library instead of the configured one;
• with no current library configured, the job had the profile's library instead of none.

Unqualified objects could therefore be resolved or created in the wrong library.

Changes

• src/connection/manager.ts: jobs built from the connection settings now run CHGCURLIB CURLIB(<library>) right after connecting, or CHGCURLIB CURLIB(*CRTDFT) when no current library is configured. newJob() takes an optional currentLibrary parameter for this.
  • The command runs as CALL QSYS2.QCMDEXC('...') instead of isClCommand: true. CL commands sent through Mapepire fail with SQL0104 Token ,0 was not valid on jobs using , as decimal separator.
  • If the command fails, the job is closed and newJob() rejects with the reason, so no job is left running with the wrong current library.
  • New SQLJobManager.getRecreatedCurrentLibrary(), which picks the current library for a job recreated with new options. Only the first name of the first library entry is used, since the library list editor also accepts space-separated names while CHGCURLIB takes a single library (QIWS QGPL would otherwise produce an invalid CURLIB(QIWS QGPL) and leave no job after the old one is closed).
• src/connection/extendedSQLJob.ts: new appliedCurrentLibrary property, which records the current library set on the job.
• src/views/jobManager/jobManagerView.ts: recreating a job from Edit Connection Properties keeps this behavior through getRecreatedCurrentLibrary(), using the (possibly edited) first library or *CRTDFT. The error notification now includes the underlying message.
• src/views/jobManager/statusBar.ts: the tooltip shows the applied current library as the first entry.
• Saved configurations and jobs created with explicit options are not affected.

Tests

New cases in Job manager tests (src/testing/manager.ts), checked against QSYS2.LIBRARY_LIST_INFO:

• current library cleared with *CRTDFT, also with the comma decimal separator;
• current library set to a named library;
• explicit options leave the current library unchanged, compared against a baseline job without a library override;
• a default job follows the connection's current library, with or without one configured (the connection's startup configuration is temporarily removed and restored afterwards);
• getRecreatedCurrentLibrary() for comma- and space-separated libraries, an empty first entry, no library list and jobs with explicit options;
• recreating a job with space-separated libraries (QIWS QGPL) sets QIWS as current library.

All pass on IBM i, including with QIWS as the connection's current library and QGPL, QTEMP as library list.

[Copilot]

🟡 Changes recommended

Reset failures can leave jobs using the wrong current library, and custom configurations can receive a misleading tooltip label.

2 open issues

• Handle failed library reset before registering the new job · New
• Show *CRTDFT only when the library reset actually succeeds · New

What changed in this PR

This PR aligns new SQL jobs with connection settings by clearing the server-assigned current library when no current library is configured.

Changes:

• Runs CHGCURLIB CURLIB(*CRTDFT) for jobs using connection-derived libraries with an empty current library.
• Displays empty library entries as *CRTDFT in the status bar tooltip.

File	Description
src/​views/​jobManager/​statusBar.ts	Adds the *CRTDFT tooltip label for empty library entries.
src/​connection/​manager.ts	Resets the current library during default job initialization.

_{Review effort: Balanced}

[benetti-marco]

Thanks, both points addressed:

• The result of CHGCURLIB CURLIB(*CRTDFT) is now checked; if it fails (or throws), the new job is closed and newJob() rejects instead of registering a job with the wrong current library.
• The job now tracks whether the reset succeeded (currentLibraryCleared), and the tooltip shows *CRTDFT only for that job's first entry. Explicit configurations with an empty first entry keep showing it as-is.

[Copilot]

🔵 Needs a closer look

Recreating a job after unrelated property edits loses the cleared-current-library setting and restores the server default.

No open issues 🎉

1 previously missed issue

In code that hasn't changed since last review

Preserve cleared current library when recreating default jobs

src/​connection/​manager.ts:59

After starting a default job with no current library, applying an unrelated setting in Edit Connection Settings recreates it through JobManager.newJob(newOptions) (jobManagerView.ts:121). Supplying those options leaves resetCurrentLibrary false, even though the library list still begins with an empty string, so the replacement job silently inherits the profile's CURLIB again. Please preserve the existing job's cleared-current-library intent through this recreation path when the library setting is unchanged, while retaining the exemption for independent custom configurations.

2 resolved since last review

• Show *CRTDFT only when the library reset actually succeeds
• Handle failed library reset before registering the new job

_{Review effort: Balanced}

[benetti-marco]

Addressed the latest review comment, plus an issue found while testing it.

Preserve the cleared current library when recreating a job

Applying changes from Edit Connection Settings recreates the job through newJob(newOptions). Because the options are passed explicitly, the reset was skipped and the new job got the profile's CURLIB back.

• newJob() now takes an optional clearCurrentLibrary parameter.
• The edit path passes it when the previous job had its current library cleared and the first library entry is still empty. The form turns [undefined, ...] into ['', ...], so an unchanged list still matches.
• Independent custom configurations are still exempt, since their jobs never have currentLibraryCleared set.

Run CHGCURLIB through QCMDEXC

While testing the recreation path, the reset failed with:

SQL0104 – Token ,0 was not valid. Valid tokens: ) ,

This happens when the job uses , as decimal separator. CL commands run with isClCommand: true go through SQL that Mapepire builds internally, and that SQL contains ,0 with no space after the comma, which is read as a numeric literal in comma-separator mode. Every CL command run this way fails on such jobs, so this predates this PR. Here, though, it would have broken job creation entirely: with no current library and a default job config using a comma separator, even the first job would fail and get closed.

The reset now runs as CALL QSYS2.QCMDEXC('CHGCURLIB CURLIB(*CRTDFT)'). It has a single argument, so it works with either separator.

Better error reporting

When a job can't be recreated after editing its properties, the notification now includes the underlying error instead of only "Failed to start new job with updated properties."

Tested on IBM i

• Connection with no current library, default job: no current library, tooltip shows *CRTDFT.
• Same job, then changing the decimal separator to comma from Edit Connection Settings: job recreated, current library still cleared.
• Connection with a current library set: unchanged behavior.

[Copilot]

🟢 Approval recommended

The changes are narrowly scoped, with only an optional regression-test recommendation remaining and no identified blocking issues.

1 open issue

• Add regression tests for resetting the current library · New

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Space-separated library edits can prevent job recreation, and two regression tests can fail under valid profile or startup configurations.

4 open issues

• Assertion does not verify unchanged current library · New
• Startup library configuration is not cleared before testing fallback · New
• Split space-separated library names before setting current library · New
• Add regression tests for resetting the current library

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

No blocking issues remain in these focused changes; regression coverage is included, though IBM i tests were not independently executed.

1 open issue

• Add regression tests for resetting the current library

3 resolved since last review

• Split space-separated library names before setting current library
• Startup library configuration is not cleared before testing fallback
• Assertion does not verify unchanged current library

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

The remaining feedback concerns a minor tooltip display issue, not job initialization or current-library behavior.

1 open issue

• Add regression tests for resetting the current library

1 previously missed issue

In code that hasn't changed since last review

Preserve all libraries when replacing the applied current library

src/​views/​jobManager/​statusBar.ts:49

For the supported space-separated input libraries: ['QIWS QGPL'] (also exercised by the new recreation test), this replaces the entire entry with QIWS, so QGPL disappears from the tooltip even though it remains configured on the job. Split each entry into individual library names before replacing the first token with the applied current library, so the tooltip retains the complete list.

_{Review effort: Balanced}

[benetti-marco]

Addressed the latest review:

• Tooltip with space-separated libraries: library entries are now split into individual names before the first one is replaced with the applied current library, so QIWS QGPL shows both libraries (statusBar.ts).
• Regression tests for resetting the current library: already covered in Job manager tests (src/testing/manager.ts):
  • Current library can be cleared and Current library can be cleared with comma decimal separator reset it with *CRTDFT;
  • Default job follows the connection current library checks the reset when no current library is configured;
  • Recreated job current library checks that recreating a job with an empty first entry resets it to *CRTDFT.

All tests pass on IBM i.

[Copilot]

🔵 Needs a closer look

The initialization CALL prevents read-only default jobs without a library override from starting.

1 open issue

• Add regression tests for resetting the current library

1 previously missed issue

In code that hasn't changed since last review

Initialize current library before enforcing read-only access

src/​connection/​manager.ts:62

When the default job properties specify access: 'read only' without a library override, this new CALL is rejected and job creation fails, including when clearing the current library with *CRTDFT. That access mode permits only SELECT statements (src/views/jobManager/editJob/otherTab.ts:80–84). Initialize the current library through a mechanism compatible with read-only access, or before applying that restriction, while preserving read-only access for subsequent queries.

_{Review effort: Balanced}

[benetti-marco]

Addressed the read-only access issue:

• Jobs with access: 'read only' now skip CHGCURLIB. That mode only allows SELECT statements, so any CL command (which always goes through a CALL) would be rejected, and the property applies to the whole connection, so it can't be relaxed just for initialization. These jobs keep the user profile's current library and appliedCurrentLibrary stays undefined, so the tooltip shows the configured library list as is. Since a read-only job can't create objects, the wrong-library creation issue this PR fixes doesn't apply to it.
• New test Read only jobs start without setting the current library in src/testing/manager.ts.

All Job manager tests pass on IBM i.

[Copilot]

🟢 Approval recommended

The focused initialization and recreation changes have regression coverage and no identified blocking issues; IBM i integration tests were not rerun here.

1 open issue

• Add regression tests for resetting the current library

_{Review effort: Balanced}