To answer your specific question (which I suspect is not your real question), you can programatically read the system primary language using the <a href=”http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/qszrtvpr.htm#HDRPVOLIN”>Retrieve Product Information</a> API QSZRTVPR.
The following CL program will display the primary language of the operating system.
Dcl &Rcv *Char 100
Dcl &LenRcv *Int Value(100)
Dcl &PrdID *Char 28 Value(‘*OPSYS *CUR 0000*CODE’)
Dcl &ErrCde *Int Value(0)
Call QSZRTVPR (&Rcv &LenRcv ‘PRDR0100′ &PrdID &ErrCde)
SndPgmMsg (%sst(&Rcv 89 4))
Though the system value QLANGID is initially set on a new install based on the primary national language version (NLV) of the system, after that point it is independent of the primary NLV.
As you can see from other responses there are also various ways to externalize text from your application logic.
<a href=”http://www.brucevining.com/”>Bruce Vining Services</a>
I am assuming that this is an interactive program and you need the descriptions on the scrren to be multilingual.
If that is the case, do not put the descriptions in the source for the DSPF.
Instead, put in fields that can be poplulate with values.
You can either store thise values in tables or arrays.
Another technique is to put them in message files and retrieve them.
This can be done with message files. A different message file would be chosen (or installed or accessed by library list or…) based on user (or system or application or…) setting. Message files are handy for interaction with display files. Each message description text can be different length up to almost the size of the display. Updates can be fairly easily done by message ID. No file I/O needs to be involved.
Note that program constants/literals might also be retrieved from the same message file that was chosen when the display message file was assigned.