SDA1528 – VALUES graphic data format is invalid

45 pts.
Tags:
Client Access 5.7
DSPF
iseries v5r4
Unicode
Hi,

I am working in a project where unicode enablement is required for an existing application and i am facing following issues:

1. Existing Display files use COMP, VALUES keywords with character fields e.g. VALUES('ABC' 'XYZ' etc.)

2. CL programs are using Character variable for parameter passing, retrieving fields from data areas, data queues etc.

3. Printer files are using Character fields with EDTWRD, BARCODE etc. keywords.

We are converting all Character database fields to unicode data type G and CCSID(1200), similarly all the DSPF and PRTF fields are changed to data type G but the issue is how to handle the keywords (VALUES,COMP,EDTWRD and BARCODE) in DSPFs and PRTFs. and how to handle the DBCS-Graphics data type in CL programs.

in case of DSPF, i tried to change one field of length 5, data type from A to G, usage B in Display File. original valid values "APART" and "DPART" were retained on VALUES keyword but then it shows error message "SDA1528 - VALUES graphic data format is invalid". Message (F1) help suggests "The syntax for defining values for DBCS-graphic field is as follows : the value must start with the character 'G', followed by a apostrophe (') and a Shift-Out character, followed by the double-byte data, then a Shift-In character and a apostrophe.

Any idea how to type shift-out/Shift-in control characters using my Keyboard (i am using standard Client access PC5250 for V5R3M0 ver 5.7 for windows and iSeries is V5R4).

Kindly feel free to comment and provide your inputs over the approach and any other suitable suggestions for unicode conversion of applications.

Thanks in advance...waiting for much awaited help.

Regards...Amit



Software/Hardware used:
iSeries Access for Windows V5R3M0, and IBM i-series version V5R4

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 4  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    I've been hoping Bruce Vining would see this question, but it looks like he's too busy or missed it. I'll suggest that you view possible emulator settings. See, for example, Keyboard Layout and Mapping Reference where SOSI keys are noted. Tom
    125,585 pointsBadges:
    report
  • bvining
    Tom, I missed the original question and, as I only look at the daily update, it was your comment that allowed it to show up again. Thanks. For your number 1, the COMP and VALUES keywords are not supported with Unicode tagged fields. This is documented in the Information Center here. You will need to perform the checks within your application program. Fortunately these types of checks are very straightforward to implement. Though, to jump a head a little to #2, I wonder what value there is in having the field Unicode if only the values APART and DPART are going to be allowed anyway. 2. Define the Unicode-encoded data as TYPE(*CHAR) for CL. But note that there is nothing wrong with leaving character data as EBCDIC if it's used for application control information (as opposed to being externalized to a user). If a *DTAARA (or Invoice control code on a *DSPF for that matter) can only be Y/N or A/B/D/X then what's the value of using Unicode for that particular field? Most *DTAARAs, and many of the CL variable values that I've run into, tend to be control oriented rather than externals. Note that the PARM command for command definition does support UTF16 with the CCSID keyword. But this, again, is only valid for *CHAR and *PNAME command TYPEs -- which in both cases would be defined in a CL CPP as *CHAR. (Start of vendor input) If you are working alot with Unicode/EBCDIC/ASCII data in CL you might also want to take a quick look at the Character Variable command set provided with my eXtreme CL product. Many of the character oriented commands are CCSID enabled. (End of vendor input) 3. Barcode fields are numeric or alphanumeric, editted fields are numeric. These types of fields have no need to be encoded using Unicode. Note that there is no problem using Unicode for all of the textual information in your report, just leave the barcode data as it is. Related to printing, I have a few articles coming up in SystemiNews that demonstrate the combination of Unicode, numeric editting, EAN13 barcoding, etc (though there's no date assigned yet for the publication). It sounds to me like someone is getting "carried away" with getting everything to Unicode. For some data there is simply no need or justification. Numeric fields and barcode values being two examples. I hope this helps, Bruce Vining Bruce Vining Services
    6,550 pointsBadges:
    report
  • AMT
    Hi Bruce, w.r.t your question "Though, to jump a head a little to #2, I wonder what value there is in having the field Unicode if only the values APART and DPART are going to be allowed anyway." The Display file field which is character and holds values"APART" and "DPART" as of now, if converted to Unicode may require application to add a new valid value to the list of VALUES / COMP keywords such as any value in Japenese language so that user could not enter any other value on screen other then listed ones in this field. in that case DSPF field needs to be converted to Unicode/graphics and we need to mention values in graphics format through VALUES/COMP as applicable or remove VALUES/COMP from DSPF and implement checks with in application program as suggested by you. IF we take first approach of changing field in DSPF to unicode/graphics then is there any way to type shift-out/Shift-in control characters using my Keyboard (i am using standard Client access PC5250 for V5R3M0 ver 5.7 for windows and iSeries is V5R4). Thanks for your reply and help.
    45 pointsBadges:
    report
  • bvining
    Hi, Amit While I am totally unfamiliar with your application, and so I could easily be way off base, I'm a bit concerned with your response concerning APART and DPART. I generally see the VALUES/COMP keywords associated with fields which are later used to control processing within the application program. It sounds like you might be thinking of allowing Japanese translations of these control values. If that is the case I would recommend another approach. Change the control field to a selection type prompt where the user can type in a value such as a 1 for APART, 2 for DPART, etc. These values could be defined as alphanumeric and validated using VALUES/COMP. In your program you can then either set the actual field to APART/DPART or (more work obviously) change your files to actually use the values of 1, 2, etc. To add a translation (say ABC) for APART and (say DEF) for DPART and then change the application to equate ABC and APART, DEF and DPART, etc could be done, but would be a maintenance nightmare as you added translations for Simplified Chinese, Traditional Chinese, Korean, Vietnamese, Thai, Arabic, Russian, Greek, Spanish, Hebrew, well you get the drift. Much better for this type of situation would be to provide the translations (ABC, DEF, etc) in the display file prompt text. Then the user can see their national language, select the appropriate 1, 2, etc value, and your program doesn't need to be maintained as additional national languages are added to the application (it just sees 1, 2, etc). You would simply need to make sure the user library list is set to reflect the display files which provide the appropriate translation for the current user. Again I might be mis-interpreting your intent, but providing language based entry of control fields is an area that I would avoid. Related to shift controls. Shift controls indicates that you want to use an EBCDIC 5250 emulator. In that case you need to install a System i Access for Windows DBCS PC5250 emulator. Alternatively you could use a Unicode-enabled 5250 emulator such as System i Access for Web. In that environment you would not need to use shift controls.
    6,550 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following