关于CCSID的问题

xuguopeng

2台机器上，同样的USRPRF
Language identifier . . . . . . . . . . . . . . . :   CHS   
Country identifier  . . . . . . . . . . . . . . . :   CN   
Coded character set identifier  . . . . . . . . . :   65535
Default coded character set identifier  . . . . . :   935   

Source file的CCSID为935

可一台机器上编译出的PF的CCSID是935
另一台机器上编译出来的PF的CCSID是836

为什么？？

hanyu

是同一源成员吗？

srcctz

跟你作业的LANGID有关。
有可能在两台服务器上，你的作业设置的LANGID不一致。
可以通过CHGJOB LANGID() 来进行重新设置

spritewoo

其实836 同935是一样的，
当pf中field的类型为O时，field的ccsid=935
当pf中field的类型为A时，field的ccsid=836
as400中的ccsid是field level的！
而当pf中field的类型为O时，field的ccsid=937
则pf中field的类型为A时，field的ccsid=其他
一般系统的ccsid=65535
为了更好的使用简体中文，user profile ccsid = 935
这样pf创建后O型字段(DBCS)=935
在与pc交换数据时（下载）不会出现乱码！

hanyu

spritewoo 说的是对的，你的两个源成员是不一样的，其中没有O型字段的那一个编译后是836。

xuguopeng

原帖由 "spritewoo" 发表：
其实836 同935是一样的，
当pf中field的类型为O时，field的ccsid=935
当pf中field的类型为A时，field的ccsid=836
as400中的ccsid是field level的！
而当pf中field的类型为O时，field的ccsid=937
则pf中field的?.........

USRPRF的CCSID是65535的时候，我不明白PF的CCSID为什么是937？？应该是65535才对吧？

我们在定义PF字段的时候都不写类型的

例如：
0017.00      A            ABABCD         5          TEXT(' 单位代码 ')

如果USRPRF的CCSID是935，如果按上面的写法，PF的CCSID会是836

如果指定字段为O型，CCSID是935


因为我们是使用SYNON这个开发工具，他所创建的PF中（代码都是象上面写的那种，没有定义字段类型），USRPRF的CCSID为65535，编译出的PF的CCSID就是937。 如果USRPRF的CCSID为935，那编译出的PF的CCSID就是836

我现在想要的就是编译出来的PF的CCSID无论是65535或935都可以

别的都不是我想要的，有解决的办法么？？

hanyu

0017.00 A ABABCD 5 TEXT(' 单位代码 ')
不写类型，小数点位置没有，表示缺省为字符型。
836 是和935 配套的ccsid，区别只是有无O型字符。

xuguopeng

原帖由 "hanyu" 发表：
0017.00 A ABABCD 5 TEXT(' 单位代码 ')
不写类型，小数点位置没有，表示缺省为字符型。
836 是和935 配套的ccsid，区别只是有无O型字符。

这个我现在已经明白了，但是我不懂的是如果USRPRF的CCSID是65535

为什么编译出的PF的CCSID是937？？？

难道937是和65535配对的？？ 不是吧，937是繁体吧？？

zzzddd

O的关系，935是dbcs的，836是sbcs的，每中文的自然就是836咯！

xuguopeng

关键是如果把USRPRF的CCSID改为935，在SYNON里会出现乱码，而且编译存在的PF会出错，连SRC都产生不出来

如果USRPRF的CCSID是65535，编译出的PF的CCSID却是937

哪怕产生的PF的CCSID是65535也行啊