On 12-Oct-2016 13:27 -0500, Dan wrote:
So, with the TR announcements yesterday/today, I found that
SYSPARTITIONSTAT (aka SYSPSTAT, aka QSYS2.PARTITION_STATISTICS) view
was enhanced to include a new PARTITION_TEXT (system name LABEL)
column, which is defined as a VARGRAPHIC(50) CCSID(1200) {<-- this
confuses the hell out of me} with a description of "Text of the
partition. Contains null if text does not exist for the partition."
Since I'm currently stuck at v7r1 and the new TRs were announced only
for v7r2&r3, I'm SOL for the time being. I'm just wondering if
anyone familiar with IBM-speak knows if this enhancement is the one
my RFE asks for. I think it does, but 1) my RFE is still in
"Submitted" status, 2) I'm not sure I can equate PARTITION_TEXT to
the member text of a source file member, and 3) what's up with
VARGRAPHIC(50) CCSID(1200)???
1) No idea about the status of the RFE.
2) The Database File Member (*MEM) [aka *MBR] is manifest as an SQL
PARTITION of a TABLE, so the Member-Text (TEXT) would equate with the
PARTITION_TEXT.
3) The CCSID(1200) and GRAPHIC data type are nothing to be concerned
with, given the job CCSID for jobs are set appropriately; e.g. as
resolved from the CCSID attribute of the User Profile, and set properly
according to the user's language environment. Since, for the past
couple decades, there is little excuse for any user remaining to have a
CCSID resolution to *HEX [aka 65535], and should instead have an
appropriate non-hex CCSID set in their User Profile (USRPRF).
With the appropriate CCSID [and keyboard and other language]
attribute having been set for a user [optionally as resolved from the
system {values; i.e. *SYSVAL}], then the effect of having done a Change
Physical File Member (CHGPFM) to modify the TEXT attribute will properly
store the character data, tagged with the job CCSID. Then when that
data is retrieved and presented, the conversion from the CCSID of the
text into CCSID(1200) and then back into the job CCSID is all implicit.
No worries on the way in, no worries on the way out; i.e. that the
CCSID(1200) is used, should be of little concern.
The following set of requests [made with the one Run SQL request]
should express how innocuous. First presenting that the data-type of the
data captured for TEXT attribute of database file columns is stored in a
field DBXTXT defined as CHAR CCSID(37) [for USEnglish systems] and
additionally with field DBXTXT2 stored as VARGRAPHIC CCSID(1200), and
then showing that data to the display which appears identical betwixt;
the notable difference being, the contrast in report column width for
both fields, whereby the Query/400 feature being used to display the
data will reserve two-bytes _per character_ on presentation of the
latter field, and to the full length of the VARiable irrespective actual
data-length:
runsql 'begin create table qtemp/ffdtx as(select dbxtxt,dbxtxt2
from qadbxlfi where dbxfil=''QADBPKG'' and dbxlib=''QSYS''
) with data; call qsys2.qcmdexc(''dspffd qtemp/ffdtx
*outfile outfile(qtemp/ffdp)''); create view qtemp/ffdv(fld,
type,ccsid)as(select whflde,whfldt,char(whcsid)from qtemp/ffdp
); call qsys2.qcmdexc(''runqry *n qtemp/ffdv''); call
qsys2.qcmdexc(''runqry *n qtemp/ffdtx''); call
qsys2.qcmdexc(''dltf qtemp/ffd*'');
end' commit(*none) naming(*sys)
/* likeness of expected output from query requests from above:
Line ....+....1....+....2....+.
External Field CCSID
Field Name Type
000001 DBXTXT A 37
000002 DBXTXT2 G 1200
****** ******** End of report
....+....1....+....2....+.. | ..5....+....6....+....7....+..<…>15.
FILE | FILE
TEXT | TEXT
SQL Package physical file | SQL Package physical file
******** End of report ******** */
If however, the job run with CCSID(*HEX) [e.g. per preceding the
RUNSQL request with a request to CHGJOB CCSID(*HEX)], per a user profile
setup that failed to establish a non-hex Job CCSID, the results of the
second report for the second [the VARGRAPHIC] column are not so pretty,
and quite literally worthless:
FILE | FILE
TEXT | TEXT
SQL Packag | ë é < & / Ä , / Å Á ø Ç ` Ë Ñ Ä / % Ã Ñ % Á
******** End of report ********
midrange.com
