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



Sorry, my e-mail client got confused with my previous e-mail, and it got screwed up in the middle. Let me try to continue where I left off...

On 1/23/2013 8:08 AM, Scott Klement wrote:
Also, make sure you use O_TEXTDATA when you want the API to perform
translation. O_TEXTDATA means that your data is text (i.e. the bytes
you write correspond to letters in a code page somewhere -- they're not
just arbitrary bytes) and O_TEXT_CREAT, which means you want to enable
translation even if the file does not exist. (Otherwise, it assumes the
file should match what's in your program, since you're creating it from
your program.)


So if you did this, it assumes that the file should be created with the same CCSID as your program. And your program can either specify a CCSID, or default to it's job CCSID -- this is done because the assumption is that your data is in that CCSID:

f = open( '/path/to/file.txt'
: O_CREAT + O_CCSID + O_WRONLY + O_TEXTDATA
: mode-here
: ccsid here );

The O_CCSID tells it to use CCSIDs instead of code pages (which really should be the default -- but, you know how IBM is... never take a risk on backward compatibility -- so without O_CCSID it works based on code page, which is uglier)

O_CREAT tells it you want to create a file if it does not exist. This does not preclude using an existing file if one is there, however. (There's another flag, O_EXCL that can be used to give an error if the file already exists) If the file already exists, the system will assume the existing file's CCSID is correct. If not, it assumes the specified CCSID or job CCSID.

O_TEXTDATA tells the API that it's text. So each code point (such as x'3c' in your example) signifies a text character rather than a binary value. When translating between character encodings, this is crucial, because it will change the underlying numbers to correspond to another encoding. For example, x'F1' in EBCDIC would be translated to x'31' in ASCII. Completely different binary values, but the same text character (The number 1)

In V5R2 we got this better feature called O_TEXT_CREAT that allows us to specify both the file and program CCSIDs at once. You can now create a file with a different CCSID than the program's CCSID right within your program, in a single call to open(). I highly recommend using this feature for any new programs.

f = open( '/path/to/file.txt'
: O_CREAT + O_CCSID + O_WRONLY + O_TEXTDATA + O_TEXT_CREAT
: mode-here
: file ccsid here
: program ccsid here );

In order to specify O_TEXT_CREAT, you must also specify O_CREAT, O_TEXTDATA, and one of either O_CCSID/O_CODEPAGE (though, I would always use O_CCSID)

So for example, if I wanted to use UTF-8 (Which is probably the best CCSID to use for PC compatible files, unless you have a specific requirement for something else) then you'd do this:

f = open( '/path/to/whatever'
: O_CREAT + O_CCSID + O_WRONLY + O_TEXTDATA
+ O_TEXT_CREAT + O_INHERITMODE
: 0
: 1208
: 0 );

Now I added a few tricky things here. One is that I added O_INHERITMODE. Mode, of course, is authorities that people will get to a newly created file. Personally, I don't like hard-coding authorities inside my programs, I want to create the directory structure with a given authority, and then let the programs "inherit" the authority from that directory structure. This is what O_INHERITMODE does, it tells it to use whatever the parent directory is set up for. That's why the 3rd parameter, "mode", is set to 0. When I specify O_INHERITMODE, the 3rd parameter is ignored.

The 4th parameter, 1208, is the CCSID for UTF-8. Here I'm specifying the CCSID of the file (not the program's data) so when data is written to the file it's converted to 1208. When it's read from the file, it's converted from 1208. If the system sees a code point like x'3C', it's thinking "this is code point 3C from ccsid 1208"

The 5th parameter is where you tell it the CCSID of your program's data. Again, you can specify a number here. For example, if I know my program's data is in CCSID 37 (popular EBCDIC in USA and many other western countries) I could hard-code a 37 for this parameter. The question is... do I really want to hard-code something?

Every job on the system already has a CCSID associated with it. So unless your program is doing something differently from what your overall job config is set up for, I find it's usually more inuitive to use the "default" for the job. To do that, simply specify 0 as the 5th parameter. Zero means "default" in this context.

So -- hopefully I've given you a lot of stuff to think about and absorb.

Maybe this helps you (or someone) understand the mechanics a little better.




On 1/23/2013 7:33 AM, Michael Schutte wrote:
>Thanks for the suggestion Jan. The file did create as 1252. However it
>didn't resolve the issue with weird symbol and the truncation of another
>symbol.
>
>Talked with my boss and said that since the Bill Of Lading Prints with a
>blank " ", then I can put in code to do the same thing. Anybody have a
>suggestion? I was thinking that maybe using %XLATE rather than reading
>each character in the string.
>
>D nonDisplayChars...
>D C
> x'0001020304050607080910111213..39'
>D replacewith C x'4040404040404040404040404...40'
>
> mystring = %xLate(nonDisplayChars:replacewith:mystring);
>
>
>Thoughts?
>
>
>On Wed, Jan 23, 2013 at 2:39 AM, Jan Grove Vejlstrup<jgv@xxxxxxxx> wrote:
>
>>Hi Michael
>>
>>Try to use this:
>>
>> if unlink(ifsPathName) < 0;
>> // handle error here
>>endif;
>>
>> fd = open(ifsPathName
>> : O_TEXT_CREAT+O_WRONLY+O_CCSID+O_CREAT+O_TEXTDATA
>> : S_IWUSR+S_IRUSR+S_IRGRP+S_IROTH
>> : 1252
>> : 0);
>>if fd < 0;
>> // handle error here
>>endif;
>>
>>This will create a file tagged with CCSID 1252 (MS Windows, Latin-1).
>>Please note, that the CCSID for this code page with euro is 5348.
>>Details here:
>>http://www-01.ibm.com/software/globalization/ccsid/ccsid1252.html
>>
>>If you convert an existing file, please check the CCSID of the file
>>(dspfd, dspffd) and the CCSID of your job (dspjob option(*dfna)).
>>
>>Best regards
>>
>>Jan
>>
>>Am 22.01.2013 23:04, schrieb Booth Martin:
>>> c eval fd = open('/ifstest/somefile.txt':
>>> c O_CREAT+O_WRONLY+O_CODEPAGE:
>>> c mode: 819)
>>>
>>>I don't intend to accidentally mislead. The above is a copy & paste
>>>from Scott Klement's web page I referenced earlier. My assumption is
>>>that Scott got "mode:" where he wanted it. However I am not expert in
>>>any way and can not make the case for or against. I am only reporting.
>>>
>>>On 1/22/2013 3:33 PM, Michael Schutte wrote:
>>>>Quick question though...
>>>>
>>>>I've seen twice now before the CCSID there's this parm that you are
>>passing
>>>>called mode What is this value?
>>>>
>>>>On Tue, Jan 22, 2013 at 4:10 PM, Booth Martin<booth@xxxxxxxxxxxx>
>>wrote:
>>>>
>>>>>open(FileName:O_CREAT+O_TRUNC+O_WRONLY:
>>>>> S_IRUSR + S_IWUSR + S_IRGRP+O_CODEPAGE: mode: 1252);
>>>>>
>>
>>--
>>This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
>>To post a message email:MIDRANGE-L@xxxxxxxxxxxx
>>To subscribe, unsubscribe, or change list options,
>>visit:http://lists.midrange.com/mailman/listinfo/midrange-l
>>or email:MIDRANGE-L-request@xxxxxxxxxxxx
>>Before posting, please take a moment to review the archives
>>athttp://archive.midrange.com/midrange-l.
>>
>>
-- This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options, visit:
http://lists.midrange.com/mailman/listinfo/midrange-l or email:
MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to
review the archives at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.