Fix CCSID 65535 source member CAST to use IBM i Default Job CCSID - #3388
Conversation
When a source file's SRCDTA column has CCSID 65535 (*HEX) and source dates are enabled, the SQL query now CASTs srcdta to the correct CCSID. Two bugs were present in IBMi.ts: 1. Quick-connect restored a cached jobCcsid of 65535 without re-running the ACTIVE_JOB_INFO resolution, leaving userJobCcsid permanently at 65535 across reconnects. 2. The ACTIVE_JOB_INFO fallback used a ternary that silently kept 65535 if DEFAULT_CCSID was falsy, rather than trusting the value IBM i guarantees is never 65535. IBM i CCSID hierarchy: QCCSID (system value) -> can be 65535 Job CCSID -> can be 65535 Default Job CCSID -> NEVER 65535 (IBM i guarantee) ACTIVE_JOB_INFO.DEFAULT_CCSID is the authoritative value used when the job CCSID is *HEX. extendedContent.ts now calls getCcsid() which, after the IBMi.ts fixes, always returns this resolved value.
GitHub Actions
Inactive
|
I created a test file for you to confirm that the fix works. once you confirm it does or does not help, you can delete it and revert back to 3.0.12 |
sebjulliand
left a comment
sebjulliand
left a comment
There was a problem hiding this comment.
Unless I'm wrong, one of these changes is not necessary. It's just replacing a ternary with an if, but the result is the same (but please correct me if I'm wrong).
Forcing a refresh if the cached value is 65535 is great!
| this.userJobCcsid = row?.DEFAULT_CCSID ? Number(row.DEFAULT_CCSID) : this.userJobCcsid; | ||
| if (row?.DEFAULT_CCSID) { | ||
| this.userJobCcsid = Number(row.DEFAULT_CCSID); | ||
| } |
There was a problem hiding this comment.
This doesn't seem necessary since it does what was done before 😅
There was a problem hiding this comment.
I guess it is a matter of taste. Yes, I did convert it to an 'if' because I had changed it another way that did not work as I intended, so I deleted that fragment. Leaving it in the shape it is. But if you want it back at a ternary assignment, that's okay but not necessary.
sebjulliand
added
the
bug
2 participants
Problem
Users with
QCCSID = 65535(*HEX) and source dates enabled were gettingcast(srcdta as varchar(n) CCSID 65535)in the member download SQL. Casting to CCSID 65535 is a no-op and leaves Mapepire with raw EBCDIC bytes.Root cause
Two bugs in
IBMi.ts:1. Quick-connect bypassed ACTIVE_JOB_INFO resolution
The quick-connect condition allowed a cached
jobCcsid = 65535to be restored directly, skipping theACTIVE_JOB_INFOlookup on subsequent connections.2. ACTIVE_JOB_INFO fallback silently kept 65535
The ternary left
userJobCcsidat 65535 ifDEFAULT_CCSIDwas falsy, rather than trusting the IBM i-guaranteed value.IBM i CCSID hierarchy
QCCSID (system value) and Job CCSID can both be 65535. Default Job CCSID (ACTIVE_JOB_INFO.DEFAULT_CCSID) is NEVER 65535 — it is the value IBM i uses when the job CCSID is *HEX.
Changes