Find Answers

Filter Search Results
All Operating Systems:
All Products:
All Solution Types:
Ask a Question
Example: "Database could not be verified"  
Tips | Start Over | Solutions | Alerts | Patches | Defects  
Pages [Next]
CMS-XML Unable to open components or data set members on non-US code page
Any attempt to open a component or a data set member using ZMF4ECL against a 7.1.2.x ZMF Server running with a French code page (e.g. LCLCCSID =01147) is failing. The file appears to be opened in an RDz pane but contains invalid, corrupt-looking data. This may affect other regions outside the US, too.
CMS-XML Invalid syntax in UTF-8 XML results with DBCS characters
There is a situation in which syntactically incorrect XML can be generated in results when DBCS characters are present. This situation should not normally happen if the started task is configured to the correct code page ( LCLCCSID ) and the XML text contains no DBCS characters that are invalid in that code page. However, under some circumstances invalid characters can occur, even if they are user errors.
CMS-XML XML Services failing to handle Japanese DBCS characters
Sernet is failing to handle Japanese DBCS characters in the title in the correct manner. For example, take a package running in a ZMF instance with LCLCCSID =939 (Japanese code page) that has a package title containing the following data:
CMS-XML CMPONENT.BROWSE.SERVICE not converting ‘<’ and ‘>’ as expected in DBCS environment
When running the CMPONENT.BROWSE.SERVICE in a Japanese DBCS environment ( LCLCCSID =939) we do not appear to be converting the ‘less than’/‘<’ or ‘greater than’/’>’ characters in the correct manner when they reside outside shift out (SO) and shift in (SI) characters, in some situations. They are returned ‘as is’ and are not converted to their expected 'lt;’ and 'gt;’ equivalents, respectively.
CMS-XML Smart editor changes not being saved to staging datasets
When components are changed in a ZMF4ECL 8.2 smart editor session the changes are not always being saved to the staging dataset. To date this has only be reported and recreated in international configurations (e.g. French environment, LCLCCSID =1147). Hence this may be a factor in the problem.
CMS-XML Packages created under prior ZMF versions cannot be accessed under ZMF 7.1.2 server
When using a French LCLCCSID (1147) on the started task, attempts to access ‘old’ packages created under a pre-7.1 version of ZMF and migrated to a CMN ZMF 7.1.2 subsystem fail using the ZMF4ECL plugin. The .log file shows the following:
CMS-XML Automatic reconnection fails and remedial user action causes ENQ failures
Customer is running in an entirely French environment ( LCLCCSID =1145, DEFAULT_POUND = £, etc.) and using Websphere Application Server to host their web services.
CMS-XML ZMF4ECL: # symbol incorrectly converted in dataset name processing for some CCSIDs
Using ZMF4ECL 7.1.2 the crosshatch/hash/pound/etc. symbol (i.e. '#') is not being handled correctly when used in staging dataset names for some international character sets. It appears that it is always being handled as a x’7B’ character regardless of the codepage/ LCLCCSID in use.
CMS-XML Installing Base Product Web Services (zmfws.war) in International Environments
All configurations must assess the following step. 1. The LCLCCSID or CCSID parameter may need to be added to the ZMF Server started task start-up parameters.
CMS-XML REST API: Member content failing translation of national characters (L10N/I18N)
00010000 When the ZMF Server started task is running with a default LCLCCSID /CCSID (37) the REST Services test tool returns the expected data running the GET /component/browsebaseline service, identical to that displayed in TSO.
Pages [Next]

Welcome kb sso

My Recent Searches

Search Feedback

Are we answering your questions?

Additional Assistance

  • Submit a Case Online
  • FAQs