CCSID conversion error Mapping Drive

[larry_...@hotmail.com]

I am trying to do a STRPCCMD to map a drive in a CL program. In an English session, I have no problems, but when I go from a DBCS session to PC, the "\" get modified from "5C" to "DE". (In EBCDIC "E0" to ASCII "DE".

So my idea is to key the "\" in hex. The way I am testing is by just using the PC command line. Examples:

ASCII
NET USE O: 0x5C,0x5CISERIES0x52MYSHARE
NET USE O: "0x5C,0x5C"ISERIES"0x52"MYSHARE
NET USE O: "5C5C"ISERIES"5C"MYSHARE

UNICODE
NET USE O: (u+0092)(u+0092)ISERIES(u+0092)MYSHARE

These all get me an error 67, server not found.

I have also tried the whole line in ASCII, which gets me a invalid command.

FYI: When I type the command on the PC's command line, and type (alt+5C) for the "\", the drive maps.

How can I get the PC to accept the hex code, as a character in the command? What is the correct format ?

[CRPence]

On 10/18/13 7:21 AM, larry_...@hotmail.com wrote:
> I am trying to do a STRPCCMD to map a drive in a CL program. In an
> English session, I have no problems, but when I go from a DBCS
> session to PC, the "\" get modified from "5C" to "DE". (In EBCDIC

> "E0" to ASCII "DE". <<SNIP>>

What is the output from the following?:
DSPDTAARA QUSRSYS/QINZPCSDA

What is the PC software that enables the STRPCCMD support, and what
language setup was established for\during its installation on the PC?

What is the setup for the "DBCS session" effected by the emulator,
per the output from the following?:
DSPDEVD /* of the virtual device for the emulation session */
DSPJOB /* of the job signed on at the emulated device */

If for example, that was a Korean session for each of its keyboard,
code page, character set (CHRID) for the device, and the CCSID for the
job, then the SM070000 "Backslash" character likely is *not at* 0xE0 as
alluded above, but instead at 0xB2 [CP00833 CCSID 933]. In that EBCDIC
CCSID, at 0xE0 is the "Won sign" character.

FWiW: The 0x5C is the location of the SC140000 "Won Sign" character
in some ASCII Windows mixed Korean CCSIDs, but with no apparent
backslash character; maybe that is a /trick/ that allows the systems to
properly communicate the /reverse solidus/ [aka backslash] character,
given both systems are aware. The 0xDE however, is apparently an
extended character prefix [aka lead-byte] rather than a one-byte ASCII
character; i.e. IIRC, the SB characters stop at 0x7F in a mixed CP.

--
Regards, Chuck

[larry_...@hotmail.com]

On Friday, October 18, 2013 10:21:34 AM UTC-4, larry_...@hotmail.com wrote:
> I am trying to do a STRPCCMD to map a drive in a CL program. In an English session, I have no problems, but when I go from a DBCS session to PC, the "\" get modified from "5C" to "DE". (In EBCDIC "E0" to ASCII "DE". So my idea is to key the "\" in hex. The way I am testing is by just using the PC command line. Examples: ASCII NET USE O: 0x5C,0x5CISERIES0x52MYSHARE NET USE O: "0x5C,0x5C"ISERIES"0x52"MYSHARE NET USE O: "5C5C"ISERIES"5C"MYSHARE UNICODE NET USE O: (u+0092)(u+0092)ISERIES(u+0092)MYSHARE These all get me an error 67, server not found. I have also tried the whole line in ASCII, which gets me a invalid command. FYI: When I type the command on the PC's command line, and type (alt+5C) for the "\", the drive maps. How can I get the PC to accept the hex code, as a character in the command? What is the correct format ?

DSPDTAARA QUSRSYS/QINZPCSDA


VALUE
OFFSET *...+....1....+.
0 '897 -290 JPN'

What is the PC software that enables the STRPCCMD support, and what
language setup was established for\during its installation on the PC?

My PC (Windows XP) primary language is English, and have added Japanese.

PC5250 Emulator
English session *DEVD is 3477, configured with host page 037.

Japanese session *DEVD is 5555, configured with host page 939.

At some point, I will need to do Chinese, and “maybe” Korean….

Chuck, my question is: “How can I input hex into a PC command line? And can I get it NOT to convert using STRPCCMD ?”
I can determine which language the user is using, then I can set the hex according to the language.

[CRPence]

On 10/21/13 5:38 AM, larry_...@hotmail.com wrote:
> <<SNIP>> My PC (Windows XP) primary language is English, and have

> added Japanese.
>
> PC5250 Emulator
> English session *DEVD is 3477, configured with host page 037.
>
> Japanese session *DEVD is 5555, configured with host page 939.
>
> At some point, I will need to do Chinese, and “maybe” Korean….
>

> my questions are:

> How can I input hex into a PC command line?

> Can I get it NOT to convert using STRPCCMD ?
> <<SNIP>>

IMO these are improper questions, because together they imply an
intention of not resolving the problem, but an intention of defeating
the intended function of the software. Besides, what the Windows
command shell can accept as a means to provide hex [or perhaps octal]
encoded characters in its command-strings, and if even such syntax would
be acceptable as the parameter-data of the NET USE that defines the UNC,
is probably best asked at a Microsoft Windows forum; i.e. a more
appropriate audience.

What specific version of the PC5250 is being used, both the Software
product [e.g. PCOMM or Client Access] and what software version\release
and revision\package level? There have been past fixes for Code Page
939 [kwd: CP939 also noted as HCP939 for Host Code Page 939].

For an attempt at a circumvention, try passing the hex code point
0xB2 instead of 0xE0... irrespective of the glyph that appears when
entered; i.e. ignoring that the backslash may not be the glyph in the PC
Command (PCCMD) string on the STRPCCMD request, issue that request
anyhow, to test the effect.

Also would it be possible to issue the following request from both
the English and Japanese sessions, each respectively, and then obtain
the hex string of the binary data in the output file named; i.e. the
/file/ data should *not* be reviewed as text-data, but as a string of
non-text bytes:

strpccmd pccmd('echo "\\ISERIES\MYSHARE" > 400data.eng.txt')
strpccmd pccmd('echo "\\ISERIES\MYSHARE" > 400data.jpn.txt')

--
Regards, Chuck

[larry_...@hotmail.com]

Were on V6R1, and the service level for System I Access for Windows is SI29455.

400data.jpn.txt
22 fe fe 49 53 45 52 49 45 53 fe 4d 59 53 48 41 52 45 22 20 0d 0a 00

400data.eng.txt
22 5c 5c 49 53 45 52 49 45 53 5c 4d 59 53 48 41 52 45 22 20 0d 0a 00

[CRPence]

On 10/24/13 5:51 AM, larry_...@hotmail.com wrote:
> Were on V6R1, and the service level for System I Access for Windows
> is SI29455.

Based on what I found, that is the GA\base level from the end of
2007... with no fixes, built from PC5250 Version 5.9 Level 20071109.
The latest I found was SI42423 (May 12, 2011), but the PCOMM base code
from which the "5761-XE1 V6R1M0 Cumulative Service Pack Level" "System
i Access for Windows Service Packs" are created, have changes packaged
as IBM Personal Communications Version 6.0 in CSD refreshes as recent as
(7th Dec 2011) which includes some fixes for HCP939.

The following link to a service pack readme document explains
installation of the fixpack and the steps for secondary languages too:
ftp://public.dhe.ibm.com/as400/products/clientaccess/win32/v6r1m0/servicepack/si42423/readmesp.txt

Another link that may assist with regard to the above:
ftp://public.dhe.ibm.com/as400/products/clientaccess/win32/v6r1m0/servicepack/si42423/Downloads.txt

Hopefully that code-level would include a fix for the issue.

> 400data.jpn.txt
> 22 fe fe 49 53 45 52 49 45 53 fe 4d 59 53 48 41 52 45 22 20 0d 0a 00
>
> 400data.eng.txt
> 22 5c 5c 49 53 45 52 49 45 53 5c 4d 59 53 48 41 52 45 22 20 0d 0a 00

Just as the 0xDE described as effect was unexpected, so too is 0xFE,
as the apparent effect of the translation using the Japanese setup.
Could the same ECHO be tried, but instead of typing the \ character per
normal, use the hex-input of 0xB2 in place of the backslash characters
to compose the command-string? Of course, ignoring that the glyph for
that entered character [presumably] does not appear visibly as the
backslash.

FWiW... a tidbit, though I am unsure if or how it might apply to the
above scenario... From information in an APAR SE46541 I notice that the
following utility generates the various national language tables
required for conversions if no current version exists in the assigned
directory. That cwb utility is cwbnltbl which apparently accepts two
decimal input parameters defining the from and to values [for ccsid?];
e.g. the existing conversion table 13a234b0.tbl in
"%ALLUSERSPROFILE%\Documents\IBM\Client Access" could be renamed or
deleted and the following invocation would recreate it [or, on next use
for which the table is required, it will be downloaded from the system]:
cwbnltbl 5026 13488

--
Regards, Chuck

[Jon]

... except that PC5250 doesn't use the iAWin conversion tables set by cwbnltbl ... The problem is that per https://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm?info/nls/rbagsinvariantcharset.htm the backslash is variant across EBCDIC CCSIDs. Also, in Japanese and a few other languages, the PC file path separator character is the yen sign which is displayed from the same 5C codepoint as \ in 437 or 1252 (see 5C in http://msdn.microsoft.com/en-us/goglobal/cc305152.aspx). The STRPCCMD will be built in whatever EBCDIC codepage the IBM i job is running in, then sent to the emulator via the PCO communications screen where the 5250 emulator will convert from the codepage specified when the emulation session was started to either the ANSI or OEM CP of the Windows 5250 process. So solving this in a CL program on the IBM i requires emitting a char in EBCDIC 290 that will convert to 5C -- by my calculations that'd be 5B (which in 37 will be $). Because it's a variant character you'd then need to build the same string for each different code page you may encounter, and emit the proper one based on Japanese vs Chinese vs Korean vs English. Hopefully since I'm a year late to this party it's all moooot.

Jon

On Sunday, October 27, 2013 5:51:30 PM UTC-5, CRPence wrote: