I18N(Internationalization)

Hi,
 We are doing I18N for AS/400 appplication (CL and RPG programs). I would
like to know if we have non-english OS/400 can we have object names (Like
profile names, Lib names, Pgm names, Device names etc) in non-english? OR
only the textual portion will be only in non english?
 Pass some lights on this.
 Ravi

 On 10/5/05, midrange-l-request@xxxxxxxxxxxx <
midrange-l-request@xxxxxxxxxxxx> wrote:
>
> Send MIDRANGE-L mailing list submissions to
> midrange-l@xxxxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or, via email, send a message with subject or body 'help' to
> midrange-l-request@xxxxxxxxxxxx
>
> You can reach the person managing the list at
> midrange-l-owner@xxxxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MIDRANGE-L digest..."
>
>
> *** NOTE: When replying to this digest message, PLEASE remove all text
> unrelated to your reply and change the subject line so it is meaningful.
>
> Today's Topics:
>
> 1. RE: OVRDBF and SQL (Jim Wiant)
> 2. RE: OVRDBF and SQL (Fleming, Greg (ED))
> 3. RE: QYPS_* Environment Variables (Jim Wiant)
> 4. RE: OVRDBF and SQL (Fleming, Greg (ED))
> 5. RE: OVRDBF and SQL (rob@xxxxxxxxx)
> 6. V5R2 Field Encryption (Joe Giusto)
> 7. Re: Debugging service pgm - eval vs F11 (Pete Hall)
> 8. RE: Debugging service pgm - eval vs F11 (Peter Dow (ML))
> 9. RE: Debugging service pgm - eval vs F11 (Scott Klement)
>
>
> ----------------------------------------------------------------------
>
> message: 1
> date: Wed, 5 Oct 2005 10:27:52 +1300
> from: "Jim Wiant" <Jim.Wiant@xxxxxxxxxxxxxxxx>
> subject: RE: OVRDBF and SQL
>
> And now that I read the whole message thoroughly, my answer doesn't work
> - I was thinking only of the RPG issues not the SQL issues... sorry
> about that.
>
> It's still a good technique though ;-)
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Fleming, Greg (ED)
> Sent: Wednesday, 5 October 2005 10:03
> To: midrange-L@xxxxxxxxxxxx
> Subject: OVRDBF and SQL
>
>
> I'm writing an SQLRPG program to insert data into one of three identical
> files, depending on which brand the data is from.
>
> When searching the archives, I see that OVRDBF has been suggested as an
> option for dealing with multi-member files, and thought it might work in
> my situation as well.
>
> I generally like to use QCmdExc to do my OvrDBF's when dealing with RPG,
> then open the file. But in SQL, I don't even declare the file on the F
> specs, so open/close doesn't seem to apply.
>
> Will this work, or do I have to do my Override in a CL or calling RPG
> program. Or, should I declare the file and open it before I run the SQL
> ?
>
> Here's what I've got. It works when the override is not necessary, but
> when I pass in one of the "alternate" files, I get no data in any of
> them.
>
> H/copy GnSrc4,HSPEC
> HDftActGrp(*No)
> *
> FISCDET IF E K DISK
> *
> D MAIN PR EXTPGM('MK320PR')
> D Comp 3
> D FileName 10
> D MAIN PI
> D P#Comp 3
> D P#File 10
> *
> D QCmdExc PR EXTPGM('QCMDEXC')
> D Command 400
> D Length 15 5
> *
> D W#Start S 7 0
> D W#Comp S 3 0
> D W#Replace S 1
> D WKCmd S 400
> D WKCmdLen S 15 5 INZ(400)
> *
> *
> /Free
> // Get Start Date
> W#Comp = %Int(P#Comp);
> Chain (W#Comp:'COGN':'PHSW') ISCDET;
> If %Found(ISCDET);
> W#Start = %Int(%Trim(CDDATA));
> EndIf;
>
> // Get Replace/Append Flag (Replace = 1, Append = 0)
> Chain (W#Comp:'COGA':'PHSW') ISCDET;
> If %Found(ISCDET);
> W#Replace = %Trim(CDDATA);
> EndIf;
>
> //Clear File
> WKCmd = 'CLRPFM FILE(' + %Trim(P#File) + ')';
> QCmdExc(WKCmd:WKCmdLen);
>
> //Override File
> If P#File <> 'MKPHSW';
> WKCmd = 'OVRDBF File(MKPHSW) ToFile(P#File)';
> QCmdExc(WKCmd:WKCmdLen);
> EndIf;
> /End-Free
> *
> *
> C/Exec SQL
> C+ Set Option Commit = *None
> C/End-Exec
> C
> C If W#Replace = '1'
> C/Exec SQL
> C+ Insert into MKPHSW
> C+ select CYCOMP, CYVJCF,
> C+ Case When CYIYDY = 0
> C+ Then '0001-01-01'
> C+ Else
> C+ substr(char(CYIYDY + 19000000),1,4) || '-' ||
> C+ substr(char(CYIYDY + 19000000),5,2) || '-' ||
> C+ substr(char(CYIYDY + 19000000),7,2)
> C+ End,
> C+ CYJYNB, CYFQNQ, EYQDCD
> C+ from CSSFND a INNER JOIN mssrc b
> C+ on a.CYCOMP = b.EYCOMP and a.CYVJCF = b.EYSJCD
> C+ where CYcomp = :W#Comp and CYIYDY >= :W#Start
> C/End-Exec
> C Else
> C/Exec SQL
> C+ Insert Into MKPHSW
> C+ select ZCCOMP, ZCSRCD, ZCMLDT, ZCCUST, ZCINDV, EYQDCD
> C+ from MKPH2W a INNER JOIN MSSRC b
> C+ on a.ZCCOMP = b.EYCOMP and a.ZCSRCD = b.EYSJCD
> C+ where ZCCOMP = :W#Comp
> C/End-Exec
> C EndIf
> C
> /Free
> If P#File <> 'MKPHSW';
> WKCmd = 'DltOvr FILE(MKPHSW)';
> QCmdExc(WKCmd:WKCmdLen);
> EndIf;
> *InLR = *On;
> /End-Free
>
>
> Thanks.
>
> Greg Fleming
>
> Programmer/Analyst
>
> Everglades Direct, Inc.
>
>
>
>
> --
> 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.
>
> ######################################################################
> This message was scanned for compliance with Foodstuffs email policies
> ######################################################################
> This message has been sent from Foodstuffs (Auckland) Limited
> ("Foodstuffs").
>
> The information contained in this message and or attachments
> is intended only for the person or entity to which it is
> addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other
> use of, or taking of any action in reliance upon, this
> information by persons or entities other than the intended
> recipient is prohibited. If you received this in error,
> please contact the sender and delete the material from any
> system and destroy any copies.
>
> The views and opinions expressed in this message may be those
> of the individual and not necessarily those of Foodstuffs,
> and are not given or endorsed by it.
>
> Please note that this communication does not designate an
> information system for the purposes of the Electronic
> Transactions Act 2002.
>
>
>
> ------------------------------
>
> message: 2
> date: Tue, 4 Oct 2005 17:41:28 -0400
> from: "Fleming, Greg \(ED\)" <GFLEMING@xxxxxxxxxxxxxxxxxxxx>
> subject: RE: OVRDBF and SQL
>
> Thanks Jim
>
> I do use that technique in my RPG code, and was trying to emulate it
> here.
> Seems my problem was more in my typing than my design, as Rob pointed
> out.
>
> G
>
> >-----Original Message-----
> >From: midrange-l-bounces@xxxxxxxxxxxx
> >[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Wiant
> >Sent: Tuesday, October 04, 2005 5:28 PM
> >To: Midrange Systems Technical Discussion
> >Subject: RE: OVRDBF and SQL
> >
> >
> >And now that I read the whole message thoroughly, my answer
> >doesn't work
> >- I was thinking only of the RPG issues not the SQL issues...
> >sorry about that.
> >
> >It's still a good technique though ;-)
> >
>
>
>
> ------------------------------
>
> message: 3
> date: Wed, 5 Oct 2005 10:45:06 +1300
> from: "Jim Wiant" <Jim.Wiant@xxxxxxxxxxxxxxxx>
> subject: RE: QYPS_* Environment Variables
>
> Thanks a lot for the information. It was exactly what I needed.
>
> 'Cheers
>
> James P. Wiant
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Ingvaldson, Scott
> Sent: Wednesday, 5 October 2005 9:54
> To: midrange-l@xxxxxxxxxxxx
> Subject: RE: QYPS_* Environment Variables
>
>
> Yes, these are Management Central related variables, however the trace
> variables are QYPS_TRACE and QYPSJ_TRACE. We only have these (the
> variables you are seeing) on our V5R2 system, which is our MGTC server.
> Our V5R3 system does not have them.
>
> I do think they're new, I don't remember noticing these last year when I
> did have to run MGTC traces. I see several of these variables listed in
> V5R3 PTF cover letters.
>
> Regards,
>
> Scott Ingvaldson
> iSeries System Administrator
> GuideOne Insurance Group
>
>
> -----Original Message-----
> date: Wed, 5 Oct 2005 08:45:33 +1300
> from: "Jim Wiant" <Jim.Wiant@xxxxxxxxxxxxxxxx>
> subject: QYPS_* Environment Variables
>
> I've noticed some environment variables on one of our boxes that I can't
> explain the origin of. Example variables are:
>
> QYPS_MAXPTF_SIZE
> QYPS_MAX_SOCKETS
> QYPS_SOCKETTIMEOUT
>
> All the variables I question of QYPS as a prefix. I found a reference to
> 'Collecting Management Central Traces' on the IBM site, and specifically
> the programs QYPSJSVR and QYPSSRV. Are these variables related to these
> jobs?
>
> Thanks for any help
>
> James P. Wiant
>
> --
> 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.
>
>
> ######################################################################
> This message was scanned for compliance with Foodstuffs email policies
> ######################################################################
> This message has been sent from Foodstuffs (Auckland) Limited
> ("Foodstuffs").
>
> The information contained in this message and or attachments
> is intended only for the person or entity to which it is
> addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other
> use of, or taking of any action in reliance upon, this
> information by persons or entities other than the intended
> recipient is prohibited. If you received this in error,
> please contact the sender and delete the material from any
> system and destroy any copies.
>
> The views and opinions expressed in this message may be those
> of the individual and not necessarily those of Foodstuffs,
> and are not given or endorsed by it.
>
> Please note that this communication does not designate an
> information system for the purposes of the Electronic
> Transactions Act 2002.
>
>
>
> ------------------------------
>
> message: 4
> date: Tue, 4 Oct 2005 17:48:21 -0400
> from: "Fleming, Greg \(ED\)" <GFLEMING@xxxxxxxxxxxxxxxxxxxx>
> subject: RE: OVRDBF and SQL
>
> Rob,
>
> I was looking at that (saw a reference in the archives, and looked it up
> in Paul Conte's excellent tome).
>
> I can see how it works for an multi-member file, but I'm not sure how to
> use it in my case, since I am passing in a completely different file
> name as a parameter. The SQL Reference tells me the alias name can't be
> the name of an existing file, and the compiler won't let me use a
> variable as the file name, eg:
>
> Create Alias MKPHSW
> For :P#File
>
> So how do I get SQL output normally directed to MKPHSW to output to the
> value found in P#File instead ?
>
> Thanks
>
> Greg
>
> >-----Original Message-----
> >From: midrange-l-bounces@xxxxxxxxxxxx
> >[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
> >Sent: Tuesday, October 04, 2005 5:22 PM
> >To: Midrange Systems Technical Discussion
> >Subject: Re: OVRDBF and SQL
> >
> >
> >See also
> >CREATE ALIAS
> >
> >Rob Berendt
> >--
> >Group Dekko Services, LLC
> >Dept 01.073
> >PO Box 2000
> >Dock 108
> >6928N 400E
> >Kendallville, IN 46755
> >http://www.dekko.com
> >
>
>
>
> ------------------------------
>
> message: 5
> date: Tue, 4 Oct 2005 17:06:45 -0500
> from: rob@xxxxxxxxx
> subject: RE: OVRDBF and SQL
>
> Bummer about that variable restriction.
>
> SqlStmt='Create Alias MKPHSW For ' + P#File;
>
> exec sql prepare stmt1 from :SqlStmt;
> exec sql execute stmt1;
>
> or maybe
> exec sql execute immediate :SqlStmt;
>
> I wonder if you can use parameter markers?
> SqlStmt='Create Alias MKPHSW For ?';
> exec sql prepare stmt1 from :SqlStmt;
> exec sql execute stmt1 using :P#File;
>
> Then again, if you wanted to chuck the alias, you could probably do the
> whole sql statement this way.
>
> Rob Berendt
> --
> Group Dekko Services, LLC
> Dept 01.073
> PO Box 2000
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> "Fleming, Greg \(ED\)" <GFLEMING@xxxxxxxxxxxxxxxxxxxx>
> Sent by: midrange-l-bounces@xxxxxxxxxxxx
> 10/04/2005 04:48 PM
> Please respond to
> Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
>
>
> To
> "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
> cc
>
> Fax to
>
> Subject
> RE: OVRDBF and SQL
>
>
>
>
>
>
> Rob,
>
> I was looking at that (saw a reference in the archives, and looked it up
> in Paul Conte's excellent tome).
>
> I can see how it works for an multi-member file, but I'm not sure how to
> use it in my case, since I am passing in a completely different file
> name as a parameter. The SQL Reference tells me the alias name can't be
> the name of an existing file, and the compiler won't let me use a
> variable as the file name, eg:
>
> Create Alias MKPHSW
> For :P#File
>
> So how do I get SQL output normally directed to MKPHSW to output to the
> value found in P#File instead ?
>
> Thanks
>
> Greg
>
> >-----Original Message-----
> >From: midrange-l-bounces@xxxxxxxxxxxx
> >[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
> >Sent: Tuesday, October 04, 2005 5:22 PM
> >To: Midrange Systems Technical Discussion
> >Subject: Re: OVRDBF and SQL
> >
> >
> >See also
> >CREATE ALIAS
> >
> >Rob Berendt
> >--
> >Group Dekko Services, LLC
> >Dept 01.073
> >PO Box 2000
> >Dock 108
> >6928N 400E
> >Kendallville, IN 46755
> >http://www.dekko.com
> >
>
> --
> 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.
>
>
>
>
> ------------------------------
>
> message: 6
> date: Tue, 4 Oct 2005 18:22:47 -0400
> from: "Joe Giusto" <midrange@xxxxxxxxxxxx>
> subject: V5R2 Field Encryption
>
> I read in the archives
> (http://archive.midrange.com/midrange-l/200506/msg01321.html) that field
> encryption is available at V5R3.
> Is it also possible to do this V5R2?
>
> TIA
>
>
>
> ------------------------------
>
> message: 7
> date: Tue, 04 Oct 2005 17:31:42 -0500
> from: Pete Hall <pbhall@xxxxxxxxxxxxx>
> subject: Re: Debugging service pgm - eval vs F11
>
> Try "eval subfieldname of structurename". Sometimes that's worked for
> me. Debug seems to have difficulty resolving some of the newer rpg
> constructs.
>
> --
>
> Pete Hall
> pbhall@xxxxxxxxxxxxx
> http://www.pbhall.us/
>
>
>
> Peter Dow (ML) wrote:
>
> >Hi Eric,
> >
> >Yes, it is a DS subfield that didn't get initialized, but it's a global
> DS,
> >and the error occurred in a subroutine, not a subprocedure, and that's
> >what's puzzling. I fixed the initialization problem, but I don't
> understand
> >why debug couldn't find it when I used the EVAL command, but could find
> it
> >when I used F11.
> >
> >There is one subprocedure in the program, but it does not reference the
> >field in question.
> >
> >Peter Dow
> >Dow Software Services, Inc.
> >www.dowsoftware.com <http://www.dowsoftware.com>
> >909 793-9050 voice
> >909 793-4480 fax
> >
> >
> >
> >>-----Original Message-----
> >>[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of DeLong, Eric
> >>
> >>
> >
> >
> >
> >>That looks like a local DS subfield that never got initialized.
> >>By default,
> >>data structures are initialized to blanks (hex '40'). In this case, your
> >>FLD field is defined as packed decimal. Since it seems to be local to a
> >>procedure, debug has trouble knowing where to look for the
> >>storage for this
> >>field.
> >>
> >>
> >
> >--
> >No virus found in this outgoing message.
> >Checked by AVG Anti-Virus.
> >Version: 7.0.344 / Virus Database: 267.11.9/118 - Release Date: 10/3/2005
> >
> >
> >
> >
>
>
> ------------------------------
>
> message: 8
> date: Tue, 4 Oct 2005 15:40:01 -0700
> from: "Peter Dow \(ML\)" <maillist@xxxxxxxxxxxxxxx>
> subject: RE: Debugging service pgm - eval vs F11
>
> Hi Pete,
>
> Well, it wasn't a qualified data structure, and the debugger's F11 routine
> didn't have any problem resolving it, but if I have time to recreate the
> problem, I'll give that a try. Thanks for the suggestion.
>
> Peter Dow
> Dow Software Services, Inc.
> www.dowsoftware.com <http://www.dowsoftware.com>
> 909 793-9050 voice
> 909 793-4480 fax
>
> > -----Original Message-----
> > [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Pete Hall
> > Try "eval subfieldname of structurename". Sometimes that's worked for
> > me. Debug seems to have difficulty resolving some of the newer rpg
> > constructs.
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.9/118 - Release Date: 10/3/2005
>
>
>
>
> ------------------------------
>
> message: 9
> date: Tue, 4 Oct 2005 18:14:05 -0500 (CDT)
> from: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
> subject: RE: Debugging service pgm - eval vs F11
>
>
> > OTOH, you are correct that I started debug after the program crashed. In
> my
> > experience, that has never made a difference in being able to view the
> > values of fields used by the program with the debugger EVAL command vs
> F11.
>
> I don't know why F11 works and EVAL doesn't. And I don't really
> understand what's going on under the covers.
>
> It's just been my experience that when a program crashes, it becomes
> difficult to view (or change) the contents of variables. It sounds like
> you've had the exact opposite experience :) I haven't explored it
> further than that, my solution has been to set a breakpoint on the line
> that I know it'll crash on, and then run the program again and reproduce
> the problem. This way, it'll hit the breakpoint before it crashes, and I
> can see everything that's going on.
>
>
> ------------------------------
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) digest 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.
>
>
>
> End of MIDRANGE-L Digest, Vol 4, Issue 1925
> *******************************************
>



--
Thanks
Ravi