× 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.


  • Subject: Re: More information on the 65535 CCSID
  • From: "Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>
  • Date: Wed, 06 Jan 99 11:12:18 +0100

Hello Nina,

I don't want you to get a complex but I'm correcting you again :)

>files with ccsid of 65535 are created using the crtpf, instead of dds.  so the
>file could contain anything.  why the default is to convert it to something
>unusable is beyond me..

65535 means hex data don't convert.  The default behaviour of Client Access is 
to respect that CCSID 
and not convert during the transfer.  The 'unusable' state occurs because you 
have EBCDIC code-points 
being interpreted by the PC as ASCII.  CA cannot second guess you and convert 
the data to ASCII 
because there will come a day when that's not the behaviour you want.  Also, 
fields in DDS files may 
be defined as CCSID 65535 and truly contain raw data.  You would not want them 
converted.  

It would have been nice if a more obvious way of controlling conversion were 
originally provided but 
CA behaviour is appropriate.

Regards,
Simon Coulter.

//----------------------------------------------------------
// FlyByNight Software         AS/400 Technical Specialists
// Phone: +61 3 9419 0175      Mobile: +61 0411 091 400
// Fax:   +61 3 9419 0175      E-mail: shc@flybynight.com.au
// 
// Windoze should not be open at Warp speed.
X-Mailer: Mozilla 4.04 [en] (Win95; I)
Date: Mon, 04 Jan 99 21:51:34 -0600
From: "nina jones" <ddi@datadesigninc.com>
To: MIDRANGE-L@midrange.com
Reply-To: MIDRANGE-L@midrange.com
Subject: Re: More information on the 65535 CCSID
> I'm confused.  There are some issues with the CA/400 file transfer that
> revolve around files with the CCSID of 65535.  Can anyone illuminate as to
> why?  Essentially, it seems that with R1M2 of CA/400 and the NT/95 client
> the default is to not translate this data.......at least with the PTF level
> I'm at....

files with ccsid of 65535 are created using the crtpf, instead of dds.  so the
file could contain anything.  why the default is to convert it to something
unusable is beyond me..

v3r1m3 had a property to convert this data, which makes it easier.  but what you
can do is either build a dummy dds for the file, and copy your data into it, or
key a file into the windows folder to force the conversion.  i don't have it
handy, but search dejanews, i bet it's on there a dozen or more times..  (search
for 65535 and force)

nj
begin:          vcard
fn:             nina  jones
n:              jones;nina 
org:            Data Design Inc 
adr:            2408 Tee Circle;;;Norman;Oklahoma;73069;USA
email;internet: ddi@datadesigninc.com
title:          Chief Programmer and bottle washer
tel;work:       405-321-0354
tel;fax:        405-360-9202
tel;home:       405-364-8960
note:           IBM Business Partner
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.