× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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 ********


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.