topic Re: sas7bitm file migration from 32 to 64 bits sas version in ODS and Base Reporting

sas7bitm file migration from 32 to 64 bits sas version

Andre — Wed, 06 Aug 2014 13:09:25 GMT

It is already stated that the sas7bitm template catalogs are not compatible from 32 bits version to 64 bits version.

You have to examinate their contents and save them one by one to an external file BEFORE the migration

with a suffix as you like .sas .tpl or .txt

libname tpl "d:\My SAS Files\tpl";

ods path show;

ods path(prepend) tpl.tabtpl(update);

proc template;source biol.patientH

/file="d:\My SAS Files\tpl\biolpatientH.tpl"

store=tpl.tabtpl;

run;

But as i was trying many other code to test for my book in 2010, i am only thinking now that

in fact you have different kind of sas7bitm files.

In matter of ods, you have also ods document files

My question rise now evident: Does anybody know if those document files

issued from this kind of code under sas windows 32bits, are readable under sas 64 bits versions

libname worka "d:\tabsas\";

title ;footnote;

ods document name=WORKA.PREMDOCu(write);

proc tabulate data=sashelp.PRDSALE contents="Les ventes";

by COUNTRY;

var PREDICT;

class PRODTYPE;

table PRODTYPE all,

PREDICT*(min mean max)/contents="par type de produits";

run;

ods select Gplot;

goptions dev=javaimg ftext="Swiss" keymap=winansi xpixels=750 ypixels=400 ;*1000 trop;

proc gplot data=sashelp.steel;

symbol1 value=star interpol=join ;

axis1 label=('Fer/métal');

axis2 label=('Evolution en million de tonnes');

plot steel * date /des="Export en MKtonnes" vaxis=axis1 haxis=axis2;

run;

quit;

proc sort data=sashelp.heart out=heart; by sex;run;

ods select ExtremeObs;

proc univariate data=heart;

by Sex;

var cholesterol;

run;

ods document close;

the result is a premdocu.sas7bitm file !!!

Can this file be copied to a sas 64 bits system under windows?

Where is the answer in the documentation?

What are the ways to migrate it?

I suppose there is another answer than those for the template stores.

Andre

Rem: i hope that SAS is constructing a global answer for what are not catalogs in matter of ods (all the sas7bitm files?)

[a minima a global save of all the templates of the sasuser.templat store under n txt files]

and indeed if possible for reading a forgoten sas 32bits catalog (other than macro one) under sas 64bits

Re: sas7bitm file migration from 32 to 64 bits sas version

Ksharp — Thu, 07 Aug 2014 13:35:40 GMT

Hi Andre,

Not sure. Did you try proc cport + proc cimport to migrate it from 32-bit to 64-bit ?

BTW, Have you retired ? and have a visit to San Francisco, California ?

Xia Keshan

Re: sas7bitm file migration from 32 to 64 bits sas version

jakarman — Thu, 07 Aug 2014 15:15:17 GMT

There are now ways to migrate a sas7bitm version dataset. The reasons:

- The 32-bit to 64-bit machine conversion is also often changing the internal used pointers from 32-bit to 64-bit.

The effect of that is the datastructure is diferent.

- There can be sas version dependent settings. in your sasuser you also find a sas7bitm. It is the SAS-registry.

It is very nice to have issues from people copying that file between releases. Suppose they would do that with the Windows registry.

Catalogs. Under the restriction needed licenses are available.

They can be converted 32-bit 64-bit. Using SAS/connect is supporting both directions.

With 9.4 there is a promise that Utf8 / latins1 connections are also supported.

Cport/Cimport. Is only working in one direction. (catalogs/datasets only). It does not support the utf8/latin differences (also missing with 9.4).

Proc migrate. That one is bundling the mentioned procedures, not offering really a different thing.

Ods document. Check whether it are just zip-files http://support.sas.com/resources/papers/proceedings09/018-2009.pdf that is for ods packages

In that case the windows suffix is just misleading as it is a zipfile.

Seeing this one https://support.sas.com/resources/papers/proceedings12/273-2012.pdf with all functionality that possibility is less likely

Re: sas7bitm file migration from 32 to 64 bits sas version

Tim_SAS — Thu, 07 Aug 2014 19:46:44 GMT

Jaap Karman wrote:

Check whether it are just zip-files http://support.sas.com/resources/papers/proceedings09/018-2009.pdf that is for ods packages

In that case the windows suffix is just misleading as it is a zipfile.

The .sas7bitm format is used by the SAS registry, ODS documents, and ODS template stores. It is not a zip file format.

Re: sas7bitm file migration from 32 to 64 bits sas version

jakarman — Thu, 07 Aug 2014 19:58:01 GMT

Yes Time already found (the remark less likely). The more important question is would that file be usable doing a binary filetransfer (when that is possible).

Re: sas7bitm file migration from 32 to 64 bits sas version

Andre — Fri, 08 Aug 2014 09:23:40 GMT

Jaap

[Dank u well voor uw antwoord]

In the sas foundation world

Regstry.files are related to sas session and can be repaired or copied :

here in our institute, on a linux red hat server people are regularly replacing their sasuser in a x11 connection when they are blocked by a forgotten quote and due to the fact that the "interrupt button" of the session management induces a damaged sas profile mention at restart. Copying a model is a solution but inside the same system and bitness.

About the transportation of the sas7bitm template itemstore

under 64 bit the warning is saying "is not a template store! It will be ignored"

after a ods path(prepend) note.templat(read) statement.

BUT we know how to save them even it is a pitty that Sas Institute has not developped a single proc kit to save

all the templates of a sasuser or personnal store.

about the sas7bitm document itemstore

i tried a list/levels=all; and a replay; on a 64bit version of sas of the file

with this creation content on the 32 bits version

libname note "d:\tabsas";

title ; footnote;

ods document name=note.derndoc(write);

ods graphics /width=17 cm;

proc print data=Sashelp.steel(obs=2);

run;

title "Exportation de l'acier avec vline";

proc sgplot data=Sashelp.steel;

vline date / response=steel markers markerattrs=(symbol=star) ;

yaxis label="Fer/Metal" values=(2,3,4,5,6,7,8,9,10) ;

xaxis label='Evolution en million de tonnes' values=(1936 to 1980 by 2) ;

run;

title "Exportation de l'acier avec series";

proc sgplot data=Sashelp.steel;

series x=date y=steel /markers markerattrs=(symbol=circle) ;

yaxis label="Fer/Metal" values=(2,3,4,5,6,7,8,9,10) grid ;

xaxis label='Evolution en million de tonnes' ;

run;

ods document close;

under 64 bits

ods rtf file="d:\notes\test\docrtf.rtf" style=ocean;

ods graphics/ width=10 cm;

proc document name=note.derndoc;

list/levels=all;

replay ;

run;quit;

ods rtf close;

the results is no error or warning but empty documents!

Packages are working upon ods results/outputs and package templates are not templates in a package

Conclusion : explore DOCUMENT only if you like it AND after being under 64bits

or keep trace of all what you have done carefully under 32bits in code files.

Finally but outside the ods scope

you are refering in matter of catalog "Using SAS/connect is supporting both directions"

My experience with sas connect is from sas windows client session to a linux server with sas.

Have you tried or do you know some existing text showing how to establishing a sas connect session

between 1) 2 pc with foundation one with sas 64bits and the other with sas 32bits

2) or between two version of sas on a same pc W7 64bits one 9.3.2 32 bits version and a 9.4.1 64bit version.

What are the Windows and SAS prerequisites on the like 'server' pc(32 bits) in case 1)

I need examples or reports about this manner of doing migration to evaluate the charge in comparison of proc cport

or the cntlin= and cntlout= couple.

TIA

Andre

Re: sas7bitm file migration from 32 to 64 bits sas version

jakarman — Fri, 08 Aug 2014 12:09:31 GMT

Andre (vdR?),

Document store: Agreed on the Document conclusion. sas7bitm files are dedicated to the OS/SASversion/bitness.

SAS/connect: Worker extensively connecting unix (AIX) mainframe (z/Os) Windows (server/desktop) with release migrations needing silent updating several versions the same time.

I had multiple SAS version(s) running on the same machine(s).

The only prereq's are:

1/ that you are having SAS/connect licensed and

2/ that you can start processes running as a service in some way.

With SAS/Connect you are needing to define a starting script for the associated SAS version with a unique port. That is understanding configuration.

Having both versions installed only one van be active on the same association (double click) but you can start any of them using a script.

The variation is the SASCMD options in the Spawner: Communications Access Methods for SAS/CONNECT(R) 9.4 and SAS/SHARE(R) 9.4

With very old SAS versions this was not available the only other way to change/vary that was using a sas-connectscript that would do the typing of the command at the correct moment (rlink file). By that it also possible to change sas options.

It still works on that old principals like a typewriter: Make a connection port call, ask for the protocol/login, open up something for information, reply with a port for port/port communications.
New is that xml-spec file. With that all settings oft the spawner are retrieved from the sas metadata. Actually proposing every appserver-contect getting his own dedicated spawner (and port).

When you are going for Utf8 (common used Dekstop/html) than go for a 9.4 approach. The utf8 functionality to connect is new with 9.4.

That conversion is still not possible with a cport/cimport approach (UE experienced notes).

Having the spawners running (tested is the simple way using SAS-base) the next step can be connecting them in a scripted way. then noconnectwait/nocwait options are belonging to that.

The advantage of having it scripted is that you can connect server-processes directly without all being dragged to a desktop.

The scripted approach will also work when using Eguide. Eguide is working like a SAS/connect session as both with miss a direct keyboard/screen connection.

The only restriction to have this run is not activating parallel processing (Eguide 5.1 and up) for the code-node.

The missing of keyboard/screen is that there are no popups possible from the server-process. The will blow up the session/proces.

When the connection is running you can do RLS up and downloads. All data catalogmembers are machine/version/bitness translated between the related machines.

That is it is translated in both directions. As long as newer functionality is not used in code it will work on both sides. (macro's sas-code scl all of that).

The cport/cimport has an embedded validation you can only import it at a newer SAS version not older. Most frustrated by even checking the hotfix level of the SAS-version.
When some person has build data uploads/downloads with (s)ftp using that you have a version upgrade lockin. Neither of the side-s can get migrated without getting that blocked.

Re: sas7bitm file migration from 32 to 64 bits sas version

jakarman — Fri, 08 Aug 2014 14:27:23 GMT

Andre, your manuals 1-2 are nice. Very good and up to date. A pitty it is base/foundation only I am missing the BI/DI service (metadata WS SP).

The Statistical part are updated to last ones, must be a lot of work.
The SAS/connect usage is not kept as up to date as all other topics. Pag 76 vol-1 is mentioning that old rlink using tcpunic.scr approach.

Re: sas7bitm file migration from 32 to 64 bits sas version

Andre — Fri, 08 Aug 2014 14:57:30 GMT

Thanks Jaap

this why i was searching sample and text upon the sas connect subject

to establish and maintain a serial of proc upload.

Andre