Note: You cannot revert back to 2.x after you upgraded to 3.2. Therefore, make sure that you have a backup before upgrading.
The Caché 3.2 utilities can be used to configure a 3.1 system. However, if you want to use a single PC client to manage 2.x and 3.2 versions of Caché, the solution is to upgrade the client to 3.2 and install the Caché 2.x utilities that are shipped with 3.2.
You should also load the Caché Studio routines on the 2.x system. This will allow you to edit routines on a 2.x system with Caché Studio.
You MUST choose one of these options. If you do not rebuild the index or change the index definition you will get:
Please keep in mind that this change only applies to indices that are Unique or PrimaryKey.
>w ##class(Person).%PurgeIndices($LB("SSNindex"))
>w ##class(Person).%BuildIndices($LB("SSNindex"))
This option is the preferred approach. The new default type for Unique and PrimaryKey indices is much better, but it does require you to rebuild the indices. But if rebuilding the index is not possible, then use Option 2 or 3.
>w $$SetEnvironment^%apiOBJ("uniqueindextype","key")
Option 2 also affects new indices that do not specify TYPE. These new indices (if
Unique or Primary), will use TYPE=key
index SSNIndex {attributes=SSN; unique;}
change it to:
index SSNIndex {attributes=SSN; unique; type=key;}
Then recompile the class. Now the class can use the existing index structure. There is no way
to specify the "type" of the index in the Caché Object Archtect, so you have to use CDL.
This means that any Views previously created through DDL must be recreated. There is no conversion for this. The sequence that should be followed to convert:
Note that view classes are not automatically recompiled if a class/table the view is based on is recompiled. The developer has to know to manually compile the view class.
The structure of the SQL Stored Procedures table has been changed. It will be necessary to manually delete the old entries from this table prior to recompiling classes. To do this, it will be necessary to kill ^oddPROC using the following syntax in each application namespace:
k ^[<impliednamespace>]oddPROCwhere impliednamespace is "^^" followed by the directory path name (or OpenVMS file specification) where the Cache.dat file resides. For example:
k ^["^^c:\cachesys\mgr\user"]oddPROC
Stored Procedures are recreated during class compilation so it is important to do this step
prior to recompiling classes.
Because pre-3.1 systems use another port number (such as 6001 for Caché 2.1), pre-3.1 clients cannot connect to a 3.2 server unless one of two changes occur:
For example, assume you have a Caché 2.1.9 server (with the Caché Direct server using port 6001) and numerous Caché Direct 2.1.9 clients that are also configured for port 6001. When you upgrade the server to Caché 3.2, it may take you a while to upgrade all the clients. Therefore, you can start a second SuperServer on port 6001 so that the clients can connect to the server while you begin the client conversion process.
You can run multiple instances of the Caché SuperServer, each on a different port. Therefore, if you need pre-3.1 clients to connect to a Caché 3.2 server on a port other than 1972, you can start up an instance of the SuperServer with the command:
JOB ServerMaster^%CMTP(port):("namespace")where port is the port number on which this Caché SuperServer will listen, and namespace is the namespace in which it runs. Omit the namespace argument if you want the SuperServer to run in the current namespace.
This example starts up the Caché SuperServer on port 6001 in the
JOB ServerMaster^%CMTP(6001):("%SYS")
You can add this JOB command to your user start-up program if you need to maintain backward
compatibility with clients that have not been changed to the 1972 port number.
Ideally, however, you should change all clients to connect on port 1972. This method of starting an additional SuperServer is intended to be a temporary solution while you migrate from the old port numbers to the new one.
Application clients must use this driver against Caché 3.2 servers. When you upgrade the clients to the ODBC 3.2 driver, you must also redefine the existing DSN configuration on the client machine. In particular, make sure that port number 1972 is used.
Therefore, Caché 3.2 systems will fail to establish a DCP connection with Caché 2.1.x systems because the 2.1.x systems use port 42502.
Use the Advanced/Network screen in the Caché Configuration Manager to set the local and remote port numbers to 42502 if you need to network to a 2.x server.
Customers with Version 2.1 Division licenses must exchange them for Version 3.2 Department licenses because the 2.1 Division license will not work with Caché 3.2. There is no charge for the exchange.
When you upgrade a Caché 2.1 server that has a Version 2.1 Division license, the upgraded server will start up in unlicensed mode. At this point, you must use the 3.2 License Wizard to change the license to a Department license. Make sure that you restart the server for the new license to take effect.
If you do not change the license, the 3.2 cconsole.log will have the entry:
V2.1 Division key requires upgrade to V3.2 Department
Both %ZSTART and %ZSTOP have these entry points:
Note that during an upgrade from 2.1.x to 3.2, the %UHALT and %USTART routines will get renamed.
However, you can use the JCONVERT utility to convert a 3.2 or 2.1.6 (or later) journal file to a common file format. This file format can then be read and applied to any Caché system with the JREAD utility.
If you wish to use these utilities, you should examine the source code, and modify it for your own purposes, as it may not do what you want in its current form.
If you install the Caché 2.x utilities, you must configure the 3.2 client to use port 6001 in order to connect to the 2.x system. To change the default 1972 port number, use the Caché Client Manager (available via the Preferred Server option in the Caché Cube).
To do so, you must run an installation program (CStudioUpd.EXE) that will install and load the Caché Studio routines on the target server, as follows:
Keep in mind that the pre-3.1 Desktop Editor is not supported on a 3.2 system.
Note: The pre- and post-load/save hooks in the Caché Studio only work against Caché 3.1 and 3.2 servers. These hooks, which are described in the Caché Programming Guide, are not implemented on Caché 2.x, DSM, or ISM servers.
To start the CMT server on a Caché 2.1 server, use this command:
JOB ServerMaster^%CMTP(port)To start the CMT server on a DSM server, use this command:
JOB ServerMaster^%CMTDP0(port)To start the CMT server on an ISM server, use this command:
JOB ServerMaster^%CMTIP0(port)port is the TCP/IP port number on which the CMT server will listen. The default port number is 1972, and is what you should use.
Add this JOB command to your ZSTU or %ZSTART start-up file so that the CMT server is started automatically.
Make sure that you save these files outside the Caché directory tree, so that the install does not overwrite them. Specifically, the installation procedure for upgrades will overwrite the Caché 2.x CacheSys\Objects directory.
If you have a given property that has no defined collation and is indexed, you must do one of the following:
The following example assumes that your classes are contained in the USER namespace. First, you export the classes.
zn "^^C:\cachesys\mgr\user"
^^c:\cachesys\mgr\user\>DO ^%GOF
All globals that are mapped to another namespace will not be saved.
^oddDEF 17 data blocks written
Write globals to file/tape for fast input to Cache
Device: C:\CLASSES.GOF
file format: ("UNW*") => <return>
Maximum media size (bytes): <return>(No maximum)
Enter a short description of the contents of this tape or file
Description: USER classes
All Globals? No => NO
Global ^oddDEF
1 item selected from
10 available globals
Global ^<return>
Use %GO or GUI Cache format to save this data.
17 blocks written in 0 minutes, 0 seconds
The second half of the procedure is to import them into the target namespace:
USER>DO DeleteAll^%apiOBJ()
USER>DO ^%GIF
Load globals from a file/tape written by %GOF
1. Skip inputting globals that exist in this directory
Your choice: 1=> 2
Device: C:\CLASSES.GOF
file format: ("UR") => <return>
File written on 06/25/1999 at 04:04PM
Description: USER classes
The global(s) included are:
*^oddDEF
Globals with a preceding asterisk ('*') already exist in this directory
What would you like to do with these globals that exist?
2. Merge input globals with the existing globals
Load this file?: Yes=> Yes
Loading globals
Merging ^oddDEF 17 blocks
The following example assumes that your classes are contained in the USER namespace. First, you export the classes. Note that the first subscript is the name of the class you want to export and that V mode (variable length records) is used on the OPEN parameters because binary data is being exported.
USER> DO ^%GOGEN
Device: C:\CLASSES.GOG Parameters: "WNS"=>WNV
Global ^oddDEF("Class1"
Global ^oddDEF("Class2"
Global ^<return>
The second half of the procedure is to import the classes into the target namespace:
deleting class Class1 ...
deleting class Class2 ...
USER>DO Delete^%apiOBJ("Class1")
done.
USER>DO Delete^%apiOBJ("Class2")
done.
USER>DO ^%GIGEN
Transfer completed
Device: C:\CLASSES.GOF Parameters: "R"=>RV
Transfer entire set of files? No=> Yes
Transferring files on Jun 28 99 at 2:06 PM
From global ^oddDEF("Class1"
To global ^oddDEF("Class1"
Transfer completed
Transferring files on Jun 28 99 at 2:06 PM
From global ^oddDEF("Class2"
To global ^oddDEF("Class2"
Done for this set of files.
Caution:
Before upgrading, make sure you save any of your own routines that are
stored in the
Because of these changes, it is highly recommended that you verify your application against 3.2 before you upgrade.
Replication does not deal reliably with replication servers that are listed as "Disabled" by the GUI Network utilities. SETs are queued up for any earlier servers in the replication list and then produce an error when attempting to queue a SET for the down server, so the SETs to the down server and any later servers in the replication list are not complete. Accordingly, disabling a server that is used for replication is not recommended.
Note: InterSystems recommends that you use shadowing to replicate your data on another computer rather than the replication technique.
If a namespace change alters the LOCK location for a global, existing locks on the global are not moved to the new location. The process still owns the lock at the old location. Explicit DELOCK requests using the same reference as the original LOCK request do not remove the lock. These locks are removed automatically on the next non-incremental LOCK, because that releases all locks owned by the job. In addition, such moved locks can be explicitly released by using an implied namespace name that references the original lock location.
Mounting directories ...
ENQ daemon failed to start because could not locate our ethernet address in the network tables
Unable to issue cluster mounts.
Skipping the following db(s):
_APPSVR$DKA200:[QA.CLUSTER]
Nothing left to mount
Therefore, you must start the network daemons with the following two commands:
DO 1^RESTART("YES")
DO ^STRTENQ()
This will allow the clusters to have a medium to talk over when the cluster daemons try to
start up.
A client using the Caché Explorer across a network may fail if the client account does not have access to all the globals in the directory.
Currently, you cannot ZSAVE % routines to a remote dataset regardless of whether that dataset is the current dataset for the process or not. Attempting to ZSAVE a % routine to a remote dataset results in a <PROTECT> error.
If you map a single subscript (as opposed to a range), the range implicitly includes any descendent nodes. Assume, for example, that you have two mappings:
("dog") -> dataset A
("dog","poodle"):("dog","shepherd") -> dataset B
The 1st line, ("dog") actually resolves to a range of the form:
("dog"):<a subscript reference which follows dog>
and the 2nd line:
("dog","poodle"): ("dog","shepherd")
is wholly within the prior mapping of ("dog").
However, if instead you had:
("dog") -> dataset A
("dog","poodle"):END -> dataset B
The second mapping would be discarded because the range it maps is not completely within
the range mapped by the first mapping. In this case, error messages would be displayed
during startup.
If you are using journaling and expect to have many local databases, it is recommended that you keep the database directory names reasonably short (such as 32 bytes or fewer). This will reduce the possibility of filling up the journal directory block. A rule of thumb for the acceptable length of a directory name is to divide 8000 by the number of databases.
On Windows 95/98 clients, PDF documents may not launch from this page. If this occurs, open the CacheSys\Docs\index.html page with a browser and then open the PDF file directly from the browser.
Note: To view PDF files, you must have Adobe Acrobat Reader 4.x installed on your machine.Also keep in mind that the HTML Help Viewer is much more restrictive than a browser. For example, it has no mechanisms for adjusting fonts, colors, or any of the other browser settings that people use and expect with HTML. If anyone needs these options when viewing a Caché HTML document, they should open the index.html file with a browser and then select the desired document.
Cannot run Help!(2)
Cannot run Tutorial!(2)
To fix the problem, use the Windows Explorer to set the .HTM and .HTML file types to
"Microsoft HTML Document 5.0" (for IE 5, for example). Also make sure that your default
Internet browser is set to MS Internet Explorer.
The jar file for Caché JDBC driver is:
CacheSys\Java\CacheJDBC.jar
You need to add this location to your class path.
The name of the driver class to instantiate in the Classforname statement is:
com.intersys.jdbc.CacheDriver
The format of the URL to use in the OpenConnection method is:
jdbc:Cache://machinename:port/namespace[/logfile]
where:
machinename = machine name (e.g., 'MYLAPTOP') or a valid IP address
port = port number (should be always set to 1972)
namespace = Caché Namespace
logfile = optional log file name (e.g., 'jdbc.log')
^["VOL",UCI"]globalor you can create a "Database" definition to use remote DDP resources under the "Databases" tab in the Caché Configuration Manager.
Some UNIX systems may run multiple write daemons. These will show up in the process list labled WRTDMN. Using more than one write daemon speeds up system performance by improving disk I/O. Caché automatically configures this on UNIX systems that support it.
Table of Contents | Chapter 1 | Chapter 2 | Chapter 3
Top of Page