excelXP on mainframe

[deleted_user]

Hi

our SAS9 is installed (9.1.3 sp4) on zOS(v 1.8) with an early version of the excelXP tagset. There seems to be a problem implementing the latest (1.7) release of excleXP. Around line 423 of the proc template code, the first "eval " statement is being rejected.
Has anyone been successful pushing the update to a zOS mainframe?

Peter C

[JackHamilton]

We use (SAS 9.1.3, v1.70, 06/05/07) on z/OS, SAS 9.1.3, without problems.

[deleted_user]

thank you Jack

It is reassuring to know that it will work once we get version 1.7 installed.

However, installing the new proc template code for v1.7 is where I have a problem.

( note that the proc template code for the original install, available by drilling down through sashelp.tmplmst in the ODStemplates window, also fails for me )

Customer support are also trying to help.

Peter C

[deleted_user]

thought follow up on this might be helpful...

We have found that we need to run the proc template code with system option noNLScompatMode
Inconveniently, applying that change in general would require all legacy code to change from using £ (UK pound symbol) to $ - As this symbol appears for all character formats we didn't want to go there, just yet 😉
Fortunately, we can compile the tagset into an itemstore in a permanent SAS library using NOnlsCompatMode option. With only one eccentricity(so far) we can use the new tagesets.excelXP in NLScompatMode by concatenating that library in the ODS path, like: [pre] ods path sasuser.templat(update) odsXLib.templat(read) sashelp.tmplmst(read); [/pre]

The one remaining eccentricity: all numeric columns are being presented with the tag instead of a tag, as in [pre]112.5[/pre]

Hopefully Customer Support can solve this as quickly as the NLS problem !

Peter.C

[deleted_user]

a follow up.
(this issue affects use of excelXP on z/OS mainframe in NLS with LOCALE=ENGLISH_UNITEDKINGDOM. I don't know about other "locale".

The track at technical support has closed accepting a defect to be resolved in SAS.92.
The effect is that numeric variables (like age, height and weight in sashelp.class) are tagged as "string" instead of "number". At excel it looks ok, but no formulae referring to these cells will see numbers without conversion. Manual conversion is no problem with data volumes like sashelp.class, but the client's application uses many tables, sometimes with many rows and columns. It is impractical to visit all the "numbers as strings" and convert them in excel.
The merits of tagsets.excelXP are so attractive, nothing is a better substitute and we have had to make a work-around.
The workaround (so far) passes through the xml seeking one identifiable pattern and replacing "string" with "number".
The work-around is tested only for the output results of the procs we use. It is not likely to be successful for all reporting procedures.

I look forward to eliminating this work-around and the dependencies it requires.

I hope you are not adversely affected by this issue.

PeterC

[deleted_user]

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

[ajacobs]

Peter,

After the SAS Global Forum I received a solution from Mickael Bouedo: Start SAS with NONLSCOMPATMODE LOCALE=NL_BE. This works fine for most of the templates. Only for excelxp we still have problems with tagattr and numeric fields. Could you please explain in detail how you have downloaded the tagsets. When I go to http://support.sas.com/rnd/base/ods/odsmarkup/index.html, I see the [], $....
If I compile with your params then I receive again the errors.

Thanks.

[deleted_user]

Albert

on my pgm.editor window my include of the ftp of the download of the proc template code looked strange, but compiled correctly.

Previously, when I "corrected" the code until it looked OK, I got a compile problem or the generated xml was "wrong" for excel.
Mickael provided instructions like :
1 obtain download of the tagset code
2 start mainframe session in open_ed-1047 encoding (with system options NOnlsCompatMode encoding= "open_ed-1047" defined on command line or config file )
3 into pgm.ed, include the proc template code. If this is in 1047 code set, a straight include is OK. If the proc template code file is in the code set for your NLS locale, then use command line command
===> inc 'proc template code file' encoding= ebcdic1146
(I used ebcdic1146 because that is my native locale encoding. I expect your encoding is different. Discover what with %put %sysfunc( getoption( encoding)); )
4 submit that code

Do these further details help?

PeterC

[ajacobs]

Peter,

The support at SAS Global Forum 2008 was really a breakthrough for the use of all the markup templates, not only EXCELXP. This means that we can use a lot of new features en reports for our SAS/Intrnet applications on mainframe. Attending SAS Global Forum only for this is already worthwhile.
We were already waiting more than a year for this solution.

Mickael has sent me other solutions, but yours works also.

The abend with Excelxp tagset is because of our PRX functions.
In 9.1.3 these prx functions do not work very well with encodings other than the compiler encoding which is Ebcdic1047 (or Open_ed-1047).
This problem has been fixed in 9.2

The only workaround in 9.1.3 in order to use this tagset from a session encoding different than 1047, Open_ed-1148 in your case, is to used a 1047 compiled tagset.

Here the steps in order to get a 1047 compiled tagset:

1) upload a compile the tagset using sas/Connect.
On the pc, start SAS with the LOCALE option set to en_US
-LOCALE en_US

On the Mainframe, start the remote session to remote submit the tagset pgm with the following options:
nonlscompatmode
locale=en_US
encoding=Open_ed-1047


Assign a new library that will contains the 1047 compiled tagset:
libname t1047 "mynew.library.lib" ;

Update the tagset source code and change the following line

define tagset Tagsets.ExcelXP / store = t1047.templat ;
define tagset tagsets.config_debug / store = t1047.templat;

Remote submit the tagset pgm.


2) Test the 1047 compiled tagset from a 1148 SAS Session.
From your SAS session on MVS, using Open_ed-1048,

you have to assign a libname to the library that contains the 1047 compiled tagsets.
libname t1047 "mynew.library.lib" ;

and then, you have to update the ODS path to pick up first the 1047 compiled tagset
ods path t1047.templat(read) sashelp.tmplmst(read);

Thanks.
Albert

[deleted_user]

Hi guys,
can someone email me the excltags.tpl to use on mainframe ([email protected]) ??
If i upload the one (http://support.sas.com/rnd/base/ods/odsmarkup/excltags_june2007.tpl) to an mainframe file with lrecl=180 (because there are very long lines) i keep getting following errors when i use it:
ERROR: No pattern to process.
ERROR: No pattern to process.
ERROR: No pattern to process.
ERROR: The regular expression passed to the function PRXPARSE contains a syntax
ERROR: The regular expression passed to the function PRXPARSE contains a syntax
ERROR: The regular expression passed to the function PRXPARSE contains a syntax

Kind regards,
Herman

[deleted_user]

if you cannot wait for SAS9.2, you will need to try to apply the work-around as described earlier. In summary, you need to compile the proc template code that builds tagsets.excelxp, in encoding open_ed-1047.
I would suggest that you should compile this into its own SAS library.
Then before your use of excelXP, use this code[pre] libname XLods 'your.special library' disp= shr ;
ods path(prepend) XLods.templat(read) ; [/pre] Then it will use your version in preference to others.

PeterC

[deleted_user]

Dear all,
after putting the excltags.tpl on the mainframe and starting a SAS session with options('nonlscompatmode locale=en_US encoding=Open_ed-1047')
i still get these errors when submitting the template:

21 ] 07-*/
22 define event changes;
23 start:
24 set $changelog[] '-';
-
79
25 set $changelog[] '.v1.72, 06/09/07';
-
79
26 set $changelog[] 'Added set from $mvar
-
79
26 ] routines,
ERROR 79-322: Expecting a /.


WHAT GOES WRONG ??

GreetZ,
Herman

[Peter_C]

because of the type of error you are getting, I think that when you include the code into your program editor, you need to use the encoding= option to indicate the encoding of your copy of the "tpl file".

good luck
PeterC