good level of support demonstrated (after attending SAS Global Forum) solved this problem!
A discussion at the Forum with the NLS demo team and others, has resulted in a proper solution for SAS9.1.3 on the mainframe (z/OS) platforms outside of USA.
It may sound simple, but somehow it didn't feel that way
We have to compile the proc template code to rebuild the tagset, not in our normal NLS environment, but in a locale with encoding open_ed-1047.
Only in that syntax environment will PRX--- functions compile correctly.
My FTP delivery of the tagset downloaded from the markup area, to the z/OS environment resulted in strange characters appearing where [] and other special characters like $ appear. However, that demonstrated that I have what is needed for the open_ed-1047 environment.
To start SAS on z/OS in 1047 when 1047 is not the normal encoding, requires a start-up option on command line or config file [pre] encoding=open_ed-1047[/pre]
When the code looks normal in an encoding other than 1047, it should be loaded into program.editor with [pre] ===> inc 'that copy of the code' encoding='open_ed-1047'[/pre]
Because the version looked strange in my normal environment, I tried [pre] ===> inc 'my copy of the code' [/pre]
Submitting that code compiles the tagset in 1047 (if the 1047 option has been used at invocation).
The tagset will be compiled to a templat itemstore in SASUSER unless alternative arrangements are made with an ODS PATH statement, before the proc template code is submitted.
Isolating the itemstore makes it easier to share/distribute.
In normal-NLS SAS sessions, using the itemstore from its own library is easily accomodated with code like[pre]libname ods1047 'our.sas.lib.nls1047' access= readonly;
ODS PATH sasuser.templat(update)
ods1047.templat(read)
sashelp.tmplmst(read) ;[/pre]
which can easily go into an autoexec.
much relief now we have numbers as numbers and not as string
thanks and appreciation to SAS.
PeterC