sas7bitm file migration from 32 to 64 bits sas version

[Andre]

Hi

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

[Ksharp]

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

[jakarman]

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

[Tim_SAS]

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.

[jakarman]

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).

[Andre]

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

[jakarman]

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.     

[jakarman]

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.

[Andre]

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