kio!spinnews!spin-hsd1-tky!nsggate.sgi.co.jp!news.nsg.sgi.com!news.corp.sgi.com!mew.corp.sgi.com!pablo
Subject: Sybase FAQ: 12/16 - section 10.2
Date: 1 Sep 1997 06:09:16 GMT
Summary: Info about SQL Server, bcp, isql and other goodies
Posting-Frequency: monthly

Archive-name: databases/sybase-faq/part12
URL: http://reality.sgi.com/pablo/Sybase_FAQ

                                    Q10.2.1
                                       
Technical News Volume 4, Number 1, February, 1995

   
   
   This issue of the SYBASE Technical News contains new information about
   your SYBASE software. If needed, duplicate this newsletter and
   distribute it to others in your organization. All issues of the SYBASE
   Technical News and the Troubleshooting Guides are included on the
   AnswerBase CD.
   
IN THIS ISSUE

     * Technical Support News/Features
          + Customer Site Visits Planned 
          + Troubleshooting Guide Update
     * SQL Server
          + Error 428 or 4408: Referential Integrity and the 16-Table
            Limit
          + The Identity Column, Definition and Purpose
          + Problems with sybload on Solaris
          + Note on Intel Pentium Floating Point Bug 
          + Problems with Backup Server and AIX 3.2.5 
          + Hazards of Copying Dumps with AIX Utilities
     * Connectivity / Tools / PC
          + Open Client/MF: Undocumented Return Code
          + PowerBuilder AutoCommit and Open Transactions
          + Stratus VOS and TCP
     * Certification and Fixed Bug Reports
          + Bug 63348 - kill on Multiprocessor Servers
          + Bug 62149 - Stored Procedure with Variable and compute Clause
            Raises Error 411
          + MAP Doc Corrections
          + Latest Rollups for SQL Server 4.9.2
          + Bugs Fixed in Latest Rollup, SQL Server 4.9.2
          + Latest Rollups for SQL Server 10.0.2
          + Bugs Fixed in Latest Rollup, SQL Server 10.x
            
Customer Site Visits Planned

   
   
   Technical Support Publications wants to learn how you use Sybase
   products and documents, so that we can give you better technical
   documentation. If you are located in the Bay Area and would be willing
   to have Sybase employees visit your workplace, send mail to
   technews@sybase.com.
   
   If a visit is arranged, a small group of writers and engineers will
   visit your site and observe how our products and documents work (or
   don't work) for you.
   
   We want to hear your concerns. We're here to help!
   
Troubleshooting Guide Update

   
   
   The format of the SQL Server Troubleshooting Guide has changed, to be
   more useful to you. The next edition will appear in two volumes, SQL
   Server Error Messages, and the SQL Server Troubleshooting Guide (for
   general troubleshooting information). Both manuals are available on
   the volume 2, number 2 AnswerBase CD (due for shipment in May). Both
   manuals will also be available in the SyBooks System 10 CD update.
   
   The Tools and Connectivity Troubleshooting Guide, last updated in
   December, makes its final appearance as a single volume in the Q2
   AnswerBase CD. Because of the diversity of products covered by this
   guide, and the expansion of some of the sections, in the future we
   will publish separate AnswerBase FAQ lists for each product. We will
   introduce this format in the Q3 AnswerBase CD.
   
Error 428 or 4408: Referential Integrity and the 16-Table Limit

   
   
   Question
   
   Update to a single table in SYBASE SQL Server release 10.x fails with
   Error 428:
   Too many table names or referential constraints in the query,
   maximum allowed table references is '16'.

   
   
   In 4.9.x, Error 4408 may be raised:
   The query and the views in it exceed the limit of 16 tables.

   
   
   Why does this happen, if I am only updating one table?
   
   Answer
   
   The limit on the number of tables any given query can touch is 16. A
   query on a table with referential constraints, that is, many primary
   and foreign keys, can refer to more tables than the limit allows. When
   you hit the limit with such a table, the update fails. For example,
   suppose there are 15 tables, named c1-c15, each one of which has one
   primary key, a reference to another table, p, and a foreign key
   constraint referring to one of 16 other tables. Each one of the tables
   c1-c15 is built like this:
   create table c1
        (ccol1 smallint, ccol2 smallint, primary key (ccol1),
        constraint pc1 foreign key (ccol2) references p (pcol1))
   go

   
   
   p is built like this:

   create table p
        (pcol1 smallint, pcol2 smallint, primary key (pcol1))
   go

   
   
   And the remaining 16 tables (p1-p16) are built like this:
   create table p1
        (pcol1 smallint, pcol2 smallint, primary key (pcol1))
   go

   
   
   Now build another table, c, that refers to all 31 other tables, like
   this:
   create table c
        (pcol1 smallint, ccol2 smallint, ccol3 smallint, ccol4 smallint,
        ccol5 smallint, ccol6 smallint, ccol7 smallint, ccol8 smallint,
        ccol9 smallint, ccol10 smallint, ccol11 smallint,
        ccol12 smallint, ccol13 smallint, ccol14 smallint,
        ccol15 smallint, ccol16 smallint, ccol17 smallint,
        primary key (pcol1),
        constraint c2p1 foreign key (ccol2) references p1 (pcol1),
        constraint c3p2 foreign key (ccol3) references p2 (pcol1),
        constraint c4p3 foreign key (ccol4) references p3 (pcol1),
        constraint c5p4 foreign key (ccol5) references p4 (pcol1),
        constraint c6p5 foreign key (ccol6) references p5 (pcol1),
        constraint c7p6 foreign key (ccol7) references p6 (pcol1),
        constraint c8p7 foreign key (ccol8) references p7 (pcol1),
        constraint c9p8 foreign key (ccol9) references p8 (pcol1),
        constraint c10p9  foreign key (ccol10) references p9  (pcol1),
        constraint c11p10 foreign key (ccol11) references p10 (pcol1),
        constraint c12p11 foreign key (ccol12) references p11 (pcol1),
        constraint c13p12 foreign key (ccol13) references p12 (pcol1),
        constraint c14p13 foreign key (ccol14) references p13 (pcol1),
        constraint c15p14 foreign key (ccol15) references p14 (pcol1),
        constraint c16p15 foreign key (ccol16) references p15 (pcol1),
        constraint c17p16 foreign key (ccol17) references p16 (pcol1))
   go

   
   
   sp_helpconstraint on p gives this output:
    name            defn
    --------------- --------------------------------------------
    pc1             c1 FOREIGN KEY (ccol2) REFERENCES p(pcol1)
    pc10            c10 FOREIGN KEY (ccol2) REFERENCES p(pcol1)
    pc11            c11 FOREIGN KEY (ccol2) REFERENCES p(pcol1)
    pc12            c12 FOREIGN KEY (ccol2) REFERENCES p(pcol1)
    pc13            c13 FOREIGN KEY (ccol2) REFERENCES p(pcol1)
    pc14            c14 FOREIGN KEY (ccol2) REFERENCES p(pcol1)
    pc15            c15 FOREIGN KEY (ccol2) REFERENCES p(pcol1)
    pc2             c2 FOREIGN KEY (ccol2) REFERENCES p(pcol1)
    pc3             c3 FOREIGN KEY (ccol2) REFERENCES p(pcol1)
    pc4             c4 FOREIGN KEY (ccol2) REFERENCES p(pcol1)
    pc5             c5 FOREIGN KEY (ccol2) REFERENCES p(pcol1)
    pc6             c6 FOREIGN KEY (ccol2) REFERENCES p(pcol1)
    pc7             c7 FOREIGN KEY (ccol2) REFERENCES p(pcol1)
    pc8             c8 FOREIGN KEY (ccol2) REFERENCES p(pcol1)
    pc9             c9 FOREIGN KEY (ccol2) REFERENCES p(pcol1)
    p_7325296431    PRIMARY KEY INDEX ( pcol1) : CLUSTERED,
    FOREIGN REFERENCE

   (16 rows affected, return status = 0)

   
   
   sp_helpconstraint on c gives this output:
    name            defn
    --------------- ----------------------------------------------
    c10p9           c FOREIGN KEY (ccol10) REFERENCES p9(pcol1)
    c11p10          c FOREIGN KEY (ccol11) REFERENCES p10(pcol1)
    c12p11          c FOREIGN KEY (ccol12) REFERENCES p11(pcol1)
    c13p12          c FOREIGN KEY (ccol13) REFERENCES p12(pcol1)
    c14p13          c FOREIGN KEY (ccol14) REFERENCES p13(pcol1)
    c15p14          c FOREIGN KEY (ccol15) REFERENCES p14(pcol1)
    c16p15          c FOREIGN KEY (ccol16) REFERENCES p15(pcol1)
    c17p16          c FOREIGN KEY (ccol17) REFERENCES p16(pcol1)
    c2p1            c FOREIGN KEY (ccol2) REFERENCES p1(pcol1)
    c3p2            c FOREIGN KEY (ccol3) REFERENCES p2(pcol1)
    c4p3            c FOREIGN KEY (ccol4) REFERENCES p3(pcol1)
    c5p4            c FOREIGN KEY (ccol5) REFERENCES p4(pcol1)
    c6p5            c FOREIGN KEY (ccol6) REFERENCES p5(pcol1)
    c7p6            c FOREIGN KEY (ccol7) REFERENCES p6(pcol1)
    c8p7            c FOREIGN KEY (ccol8) REFERENCES p7(pcol1)
    c9p8            c FOREIGN KEY (ccol9) REFERENCES p8(pcol1)
    c_3610523221    PRIMARY KEY INDEX ( pcol1) : CLUSTERED

   (17 rows affected, return status = 0)

   
   
   An attempt to insert or delete will give the following result:

   1> delete p where pcol1 = 1
   2> go

   Msg 428, Level 16, State 1:
   Line 1:
   Too many table names or referential constraints in the query,
   maximum allowed table references is '16'.

   1> insert c values (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
   14, 15, 16, 17)
   2> go

   Msg 428, Level 16, State 1:
   Line 1:
   Too many table names or referential constraints in the query,
   maximum allowed table references is '16'.

   
   
   UPDATE commands will produce similar results.
   
   An update through a view can also trigger this error if the view
   includes more than 16 tables.
   
   When setting up constraints on your tables, look at the maximum number
   of tables that might be touched by an update, insert, or delete
   statement before you set up your constraints.
   
   When setting up views, be careful not to include more than 16 tables
   in a view if you plan to update through it.
   
The Identity Column, Definition and Purpose

   
   
   Customers have for some time wanted a way to have an incrementing
   unique key column in a table.
   
   The 10.0 release of SQL Server provides this functionality with a
   unique key column; the user defines a column as IDENTITY, and it is
   updated automatically.
   
  Characteristics of the IDENTITY Property
  
   
   
   IDENTITY is a column property, like NULL or NOT NULL. Its
   characteristics are:
     * Only positive integers are allowed. The column may not contain
       zero (0) or NULL, or any fraction.
     * The column's value starts with 1 and always increments by 1 to the
       maximum value.
     * When the maximum value is reached, there is no wraparound; the
       next attempt to insert raises an error message.
     * The identity column is not updatable; upon update of a row, the
       value in its identity column does not change.
     * When you insert a new row, you need not insert an identity value;
       the identity value is automatically generated and inserted for
       you.
     * If you need unique identity column values, put a unique index on
       the identity column. Identity column values are automatically
       unique, unless you insert a value directly.
     * Gaps may occur upon system crash or shutdown with nowait. See
       "Preburn Issues" below.
     * Gaps may also exist between identity column values because of
       rollback or delete operations; identity values are not reused. In
       the example below, counter_id is the identity column in the table
       running_counter:
        1> select * from running_counter
        2> go

        counter_id  next_number
        ----------  -----------
                1            2
                2            5

        (2 rows affected)

        1> begin tran
        2> select * from running_counter
        3> insert running_counter (next_number) values (10)
        4> select * from running_counter
        5> rollback tran
        6> go

        counter_id  next_number
        ----------  -----------
                1            2
                2            5

        (2 rows affected)
        (1 row affected)

        counter_id  next_number
        ----------  -----------
                1            2
                2            5
                3           10

        (3 rows affected)

        1> insert running_counter (next_number) values (10)
        2> go

        (1 row affected)

        1> select * from running_counter
        2> go

        counter_id  next_number
        ----------  -----------
                1            2
                2            5
                4           10

        (3 rows affected)

  Setting Up Identity Columns
  
   
   
   The identity column of a table is a numeric datatype with the IDENTITY
   property. Because the numeric datatype allows for digits to the right
   of the decimal place in its definition, but the identity column does
   not, you must define the number of decimal digits as zero, as in the
   following example:
        create table sales_daily
        (stor_id   char(4)      not null,
        ord_num    numeric(10,0)identity,
        ord_amt    money       null)

   
   
   The maximum number of digits permitted for the identity column is 38.
   
   Be very careful of large identity column values. As shown in the
   following section, "Preburn Issues", large values can make for very
   large gaps. The larger your gaps, the sooner you hit your maximum
   value.
   
  Preburn Issues
  
   
   
   How does SQL Server keep track of the next value generated for the
   identity column?
   
   There is a SQL Server configuration value, set with sp_configure,
   called IDENTITY BURNING SET FACTOR, that works like this:
     * Initially, a set of n values is preburned or stored in memory.
       These values are reserved to be used up by the next n inserts.
     * Each identity column on SQL Server has its own set of preburned
       values.
     * Each insert gets its value out of the preburned set.
     * When the set is exhausted, the next set of n values is made
       available for use by the next n inserts.
       
   
   
   Note: You may wonder why this method was chosen, rather than having
   SQL Server write the maximum column value to storage and log it for
   insert. The answer is that the store-and-log method is performance
   intensive, requiring two extra writes per insert.
   
   The identity burning set factor is based on a percentage of the
   maximum value that can be held in an identity column. The default
   percentage is 0.05%, or 0.0005; however, sp_configure must contain
   integers and cannot hold decimal places. Therefore, to turn the factor
   into an integer for sp_configure, multiply it by 107. To get the
   default factor:
        0.0005 * 10**7 = 5000

   
   
   sp_configure stores the value 5000. The value for sp_configure
   identity burning set factor can be between 1 and 9,999,999.
   
   To determine the sp_configure value based on the number of values you
   wish to preburn, use the following formula:
        preburned_set/(maximum+1)=percentage
        percentage * 10**7 = identity burning set factor

   
   
   For example, given a table with an identity column containing a
   maximum of four digits, the highest value it can hold is 9999. If you
   want to preburn 10 values for that column, use the following formula:
        10/(9999+1) = .001 (.01%)
        .001 * 10**7 = 10000

   
   
   So you should configure identity burning set factor as follows:
        sp_configure "identity burning set factor", 10000
        reconfigure

   
   
   There are two major implications with this system:
     * Because it is a value set with sp_configure, the same preburn
       factor is server wide, applying to all its tables.
     * Large preburn sets can cause large gaps if there is a system
       crash.
       
  Preburn Factor is Server Wide
  
   
   
   You may have identity columns on your server with different sizes. To
   find out, given a set preburn factor, how many values will be burned
   for a given table, use the formula:
        preburned set size = (maximum + 1) * (preburning factor * 10**-7)

   
   
   For example, given the default preburning factor of 5000:
     * A table with an identity column defined as numeric(4,0) will burn
       (9999 + 1) * (5000 * 10**-7) = 5. After five insertions, a new set
       of the next five higher values is reserved to be used by the next
       five insertions.
     * A table with an identity column defined as numeric(6,0) will burn
       (999999 + 1) * (5000 * 10**-7) = 500.
       
   
   
   You can mitigate the impact of this situation somewhat if you are able
   to standardize the size of your identity columns by setting up a
   user-defined datatype to use as the datatype for identity columns, for
   example:
        sp_addtype sitekey, numeric(6,0), "identity"

   
   
   With this key in place, the example table created above would look
   like this:
        create table sales_daily
        (stor_id   char(4)     not null,
        ord_num    sitekey,
        ord_amt    money       null)

   
   
   You should determine if the needs of your particular site can support
   this method, and use it if so. Set up the datatype for your identity
   column in model to propagate it to each new database created.
   
  Large Preburn Sets Can Cause Large Gaps
  
   
   
   If there is a system crash, the larger your preburned set, the larger
   the gap in your identity values will be, because all unused, preburned
   numbers kept in memory will be lost.
   
   For example, if you define your identity column with the maximum value
   of numeric(38,0), even with the smallest possible preburn factor of 1,
   you potentially lose millions of values in a system crash.
   
   shutdown with nowait causes these values to be lost in exactly the
   same way as in a system crash. Use a regular shutdown to avoid loss.
   
   Be aware that there are also some circumstances under which dump/load
   can cause loss of identity values. Object Allocation Manager (OAM)
   pages store the page numbers of pages used, or allocated but not yet
   used, for every object. The Backup Server reads directly from the
   disk; the OAM page stores the maximum reserved identity value, while
   the maximum used value and the maximum reserved value are being
   tracked in the memory structure for the table. SQL Server writes the
   maximum used value back to the OAM page when the memory structure is
   scavenged or the server is shutdown without nowait. If the maximum
   reserved value is not the same as the maximum used value at the time
   of the dump, then the maximum reserved value gets written out and
   restored on a load, causing a loss of identity values.
   
   Sybase is currently looking at ways to correct these issues. SYBASE
   Technical News will keep you informed of any changes!
   
Problems with SYBLOAD on Solaris

   
   
   Some of our customers are having problems using the Sybase
   installation utility sybload on Sun Solaris 2.x, when installing
   products from tape. After entering all the information requested by
   sybload they get the message "permission denied" when sybload tries to
   access the tape.
   
   Some instructions were left out of the Release Bulletin SYBASE SQL
   Server Release 10.0 for SunOS Release 5.x (SVR4). This will be
   remedied. In the meantime, all new SQL Server for Solaris shipments
   include a fluorescent flyer with the missing instructions.
   
   If you are experiencing permission problems accessing the tape on
   Solaris, add the local machine's host name to the $HOME/.rhosts file
   of the user running sybload, and also to the /etc./host equivalent
   file for your site.
   
Note on Intel Pentium Floating Point Bug

   
   
   An AnswerBase TechNote, dated December 7, 1994, "Test for Intel
   Pentium Floating Point Bug," describes some Transact-SQL commands that
   can be used to demonstrate the Pentium bug. This test is valid for SQL
   Server 4.8.x, 4.9.x, and 10.0.x
   
   If the described Transact-SQL commands are executed on a 4.2.2 server,
   they will execute correctly, even if the processor has the bug. The
   bug can be detected only by using a program which takes advantage of
   floating point operations.
   
   These commands will not replicate the problem on the 4.2.2 SQL Server
   on Novell because the chip's floating point capability was not
   available at the time of the 4.2 Server release. The Pentium floating
   point problem is not an issue in the 4.2.x SQL Server release on the
   Novell platform.
   
Problems with Backup Server and AIX 3.2.5

   
   
   Question
   
   I have difficulty connecting to Backup Server 10.0.x when running on
   new RS6000 platforms preloaded with AIX 3.2.5. The symptom is that
   Backup Server seems to hang.
   
   Answer
   
   The problem may be a communication time-out. It has been fixed by IBM
   in PTF U435001, which addresses APARs IX46162 and IX44358:
     * APAR IX46162: process hang while waiting for sockbuf lock
     * APAR IX44358: fcntl does not create nonblocking sockets
       
   
   
   Since September 28, 1994, three rolled up releases of AIX 3.2.5 have
   been shipped; AIX 3.2.5.2(E1) through AIX 3.2.5.5(E4). If you have any
   of these releases you may be affected by this IBM bug.
   
   Contact IBM for fix PTF U435001 (or the current version IBM
   recommends).
   
   Note
   
   Do not confuse the problem described above with an intermittent Backup
   Server hang. If SQL Server normally connects to Backup Server, but
   periodically the connection fails, verify that you have the following
   fixes installed:
     * IBM APAR IX45257 (PTF U432973)
     * Sybase EBF 3580 (recommended)
       
   
   
   Sybase EBF 3580 is included with the 10.0.2 Backup Server.
   
Hazards of Copying Dumps with AIX Utilities

   
   
   The System Administration Guide for SYBASE SQL Server Release 10.0
   (dated September 14, 1993) reads,
   
     Dumps to a file or disk can be copied to tape for off-line storage.
     
   
   
   However, Sybase does not recommend using any UNIX operating system
   commands except tar, dd, cpio or dumps to copy files to tape.
   
   Specifically there seems to be a problem with the AIX backup utility,
   and with Logical Volume Manager (LVM) utilities like cplv and
   importlv. Using these utilities to copy dump files to tape, or to move
   data from one logical device to another, may lead to database
   corruption.
   
  Explanation
  
   
   
   LVM creates a logical device of type "copy" when you invoke cplv,
   specifying sector 0 as the control block. When you copy your data to
   the new device, sector 0 on the original device becomes sector 1 on
   the new device. If you specify a device type unknown to AIX, AIX will
   initialize sector 1. If you have installed a database on a device that
   does not have sector 0 initialized as the control block for the
   device, and use cplv to move data, SQL Server will be confused about
   the address of the control block, and you will get these errors in the
   error log:
        kernel: dconfig: unable to read primary master device
        kernel: kiconfig:  read of config block failed

   
   
   This particular error can be avoided if you do disk init with the
   vstart option to skip the first sectors, making sure to set size 1
   page smaller than normal for every block vstart is from 0:
        disk init name = "skip_dev", physname = "/dev/something",
        vdevno = ##, size = ###-1, vstart = 1

   
   
   The backup utility can also change blocks, rendering your backups
   unreadable.
   
   To avoid backup problems, use tar or dd to copy dump files to tape,
   and dd to move a dump file from one device to another.
   
Open Client/MF: Undocumented Return Code

   
   
   Open Client/Mainframe (OC/MF) for CICS can return an undocumented
   return code:
        -25 (TDS_GWLIB_FUNCTION_NOT_AVAILABLE)

   
   
   If this code is returned, it means that the transaction is requesting
   a function that is not part of the OC/MF API. The OC/MF API is a
   subset of generic Open Client; it does not include all Open Client
   calls.
   
   If you get this return code, check your application code for Open
   Client calls that are not documented in the Open Client/Mainframe
   Programmer's Guide. It contains a list of all supported functions.
   
PowerBuilder AutoCommit and Open Transactions

   
   
   SQL Server may experience problems because of long-running
   transactions started by PowerBuilder applications. These problems
   could include extended recovery times or users waiting on locks. For
   this reason, it's generally recommended when using PowerBuilder with
   SQL Server that you allow SQL Server to handle transaction management.
   
  PowerBuilder AutoCommit
  
   
   
   PowerBuilder defines information regarding a connection to a database
   in a transaction object. PowerBuilder defines a transaction object as:
   
     a non-visual object that identifies a specific database connection
     within a PowerBuilder application.
     
   
   
   In other words, a transaction object is a set of attributes defining
   the connection. An application can instantiate (define) its own
   transaction object or use the default transaction object, SQLCA.
   
   One of the transaction object attributes that causes confusion for
   Sybase users is AutoCommit. To set the AutoCommit attribute for a
   transaction object, you must define:

        transaction_object_name.AutoCommit = TRUE

        or

        transaction_object_name.AutoCommit = FALSE

   
   
   The default value for AutoCommit is "FALSE". A value of "FALSE" for
   AutoCommit means that when the connect statement is used within a
   PowerBuilder application, PowerBuilder executes a begin\x11transaction
   upon making the database connection. If AutoCommit has a value of
   "TRUE", then no transaction is started upon the completion of the
   connection to the database.
   
   The following table shows how AutoCommit affects other PowerBuilder
   statements:
   
  Table 1: Effect of AutoCommit on other PowerBuilder statements

Statement       Description

COMMIT          If AutoCommit is "FALSE", PowerBuilder will issue a
                commit transaction and then a begin transaction. If
                AutoCommit is "TRUE", an error will occur.

DISCONNECT      If AutoCommit is "FALSE", PowerBuilder will issue a
                commit transaction.

ROLLBACK        If AutoCommit is "FALSE", PowerBuilder will issue a
                rollback transaction and then a begin transaction. If
                AutoCommit is "TRUE", an error will occur.

   
   
   Having AutoCommit set to "FALSE" can result in long-running
   transactions and the possibility of locks being held that a user is
   unaware of. If you don't clearly understand the ramifications of
   setting AutoCommit to "FALSE", it's better to set it to "TRUE" and
   allow your application to use the implicit transaction management
   provided by SQL Server.
   
Stratus VOS and TCP

   
   
   Question
   
   I am running SQL Server on Stratus VOS. I find I cannot connect to
   TCP, and the following errors appear in the SYBASE errorlog:
        os_init 0 tcp connections configured.  At least 2 are required
        to run the tcp network
        Error 1602 Unable to initialize network 9

   
   
   Answer
   
   This error is generally caused by the parameter ctcpconnections being
   set incorrectly in the SQL Server configuration block. This parameter
   is only available in Stratus VOS implementations. The first default
   network type for Stratus VOS SQL Server was a proprietary type; TCP
   was added later, for greater convenience.
   
   Solution
   
   You must set ctcpconnections to 2 plus the maximum concurrent TCP
   connections to the SQL Server, as follows:
        buildmaster -ddevicename -yctcpconnections=2[+n]

   
   
   where n is your maximum concurrent TCP connections.
   
   Warning! buildmaster -y is not documented in the standard documents;
   please use it only under the direction of Sybase Technical Support.
   
Bug Reports

   
   
   The following sections describe some current bugs, and are followed by
   the full reports of bugs fixed in the latest EBFs for SQL Server 10.0
   and 4.9.2.
   
  Bug 63348 - KILL on Multiprocessor Servers
  
   
   
   The symptoms of bug 63348 are: the SQL Server seems to stop for a
   while, then suddenly becomes active again; and a task locks up until
   another task is executed, or checkpoint is run. A degradation in
   performance may be noticed for the server.
   
   The problem is caused by the use of the kill command.
   
   The problem will only occur when a thread that is running is killed.
   This can only happen on a multiprocessor server; there must be more
   than one engine. This bug affects multiprocessor servers on all
   platforms.
   
   Explanation
   
   When kill is used, the internal variable used to track the number of
   running threads is decremented by one. When kill is used on a running
   thread, this variable becomes out of sync with the actual number of
   runnable threads on the queue; the variable's count goes to zero, and
   the server incorrectly thinks there is nothing to schedule.
   
   However, as soon as something else becomes runnable (such as an extra
   request over the network, or checkpoint running), then the server
   wakes up again.
   
   Rebooting SQL Server clears the problem temporarily.
   
   The problem does not occur on single-engine servers, because on a
   single-engine server, only one thread can be running at once. If that
   thread is executing the kill, the server cannot be running another
   thread.
   
   This bug has been fixed, and the fix is being tested prior to
   incorporation in a future Rollup. If you are experiencing this bug,
   please contact Technical Support to get on the waiting list for the
   fix.
   
  Bug 62149 - Stored Procedure with Variable and COMPUTE Clause Raises Error
  411
  
   
   
   A stored procedure with an input parameter, a different declared
   variable inside the procedure, and a select query inside the procedure
   which selects the declared variable and then has a compute clause on
   the variable, gets a 411 error. For example:
        create procedure foo
        @inarg int                       /* input parameter */
        as
           declare @localarg int  /* declared variable */
           select @localarg = 1   /* that selects the decl.var. */
           select dbid, name, @localarg
           from master.dbo.sysdatabases
           order by 3, 1     /* required in conjunction with compute/*
           compute sum(@localarg) /* compute clause on the variable */
        go

        Msg 411, Level 16, State 1:
        Server 'testserver', Procedure 'foo', Line 8:
        Compute clause #1, aggregate expression #1 is not in the select list.

   
   
   All the listed parts must be present for the bug to appear:
     * If you remove the (unused) input parameter, the procedure works.
     * If you compute sum(dbid) rather than sum(variable) the procedure
       works.
       
   
   
   This bug is fixed for 4.9.2, and a port is due for 10.0.2.
   
  MAP Doc Corrections
  
   
   
   Please note the following corrections to your Mainframe Access
   Products (MAP) manuals:
   
   OmniSQL Access Module Installation and Administration for DB2-CICS
   (Doc ID 34245-01-1010-01)
   
   In Chapter 7, under "Installation Checklist", step 5 should read
   "DFHRPL concatenation" instead of "STEPLIB concatenation".
   
   OmniSQL Access Module Installation and Administration for DB2-IMS (Doc
   ID 34369-01-1010-01)
   
   In Chapter 6, under "Installation Checklist", step 8 should be put
   after steps 9-11.
   
EBF News

   
   
   The following tables list the latest Rollup numbers for SQL Server
   4.9.2 and 10.x on selected platforms, and selected bugs fixed in them.
   
  Latest Rollups for SQL Server 4.9.2

Platform                              Rollup Number
SunOS Release 4.x (BSD)               4152
HP 9000 Series 800 HP-UX              4253
IBM RISC System/6000 AIX              4154
AT&T; System 3000 UNIX SVR4 MPRAS      4155
Digital OpenVMS VAX                   4156
Sun Solaris 2.x                       4157
Digital OpenVMS Alpha 1.5             4158
Digital OpenVMS Alpha 1.0             2121

  Bugs Fixed in Latest Rollup, SQL Server 4.9.2
  
   63393
          The server crashes after the errorlog message "current process
          infected with 10". The trace information which follows shows
          that the error occurred in the routine des__hashcheck, and that
          the Resource->rdesmgr_spin spinlock is currently being held.
          
   63030
          Views get corrupted under certain conditions. Selecting from
          the corrupted view returns wrong values until the view is
          dropped and re-created. The corrupted view returns same data
          for all the columns.
          
   62149
          See full description above
          
   61902
          539 errors result in orphaned locks. Stack trace shows
          indexsplit as one of the routines called.
          
   61850
          Insert into a table with a timestamp column in a stored
          procedure causes Error 207(invalid column) for the timestamp
          column when the procedure gets renormalized. This also causes
          Error 273 for the timestamp column if you try to insert a NULL
          value for the timestamp.
          
   61168
          Certain aggregate expressions are incorrectly regarded as being
          identical. As a result, one of the expressions gets thrown
          away, and the other is used instead.
          
   60980
          SQL Server fails to perform a switch from a failed disk device
          to a good device when disk mirroring is enabled.
          
   60809
          Added support for the TCP_NODELAY option, which can be enabled
          via the 1610 trace flag. Server should be booted with `-T1610'
          to turn on this option.
          
   60122
          [REPSRV] Fix 58464 tries to reduce the restart latency time of
          the SQL/LTI log scan during a sharp increase in XACT log
          activity. However, the fix causes a 30 percent performance
          reduction with asynchronous disk I/O facilities which do `page
          hiding' (such as IBM RS6000).
          
   60099
          When attention is received while executing Remote Procedure
          Calls on another server, the endpoint is prematurely cleaned
          up. This prevents the attention from being forwarded to cancel
          the RPC on the remote server, which is left suspended.
          
   59308
          Certain insert into statements with use of union and view may
          fail with stack trace and the isql connection gets aborted.
          
   58509
          A signal 11 segment violation produced a stack trace during a
          query dealing with views.
          
   58464
          If there is a sharp increase in XACT log activity (such as from
          several large bulk copies) after a short period (5 minutes) of
          no XACT log activity, the SQL Server may delay the sending of
          the new XACT log information to the Replication Server for as
          much as 10 minutes.
          
   58411
          "if exists" generates segmentation violation when the where
          clause contains concatenation of convert with subqueries. This
          occurs during parse time.
          
   58192
          Mirroring a device onto the master device should not be
          allowed, a warning should be generated.
          
   58047
          If a temporary table is dropped and created in one batch, it's
          not accessible and not dropped even after the isql session is
          over.
          
   57989
          diagserver panics while killing SERVER tasks.
          
   57873
          Server returns duplicate rows when query has a group by clause
          and a having clause which in turn has aggregates and an or
          clause.
          
   57756
          DBCC checkalloc resets the 3604/3605 flags at the end of
          execution even if the Server was started with traceflags
          3604/3605 in the command-line.
          
   57673
          [REPSRV] The log scan thread sometimes is not awakened when
          there are records to be read in the log.
          
   57592
          Server shuts down with messages "ubfree: block 0x62a9800
          already free", "Stack overflow detected" and stack trace while
          resolving a huge stored procedure.
          
   57576
          LOAD TRAN recovery always aborts a 2-phase XACT in PREP but
          (wrongly) leaves the XEND log record in PREP. If the XEND log
          record is seen again by boot time recovery, error 3429 occurs
          if the 2-phase XACT commits after the LOAD TRAN but before
          reboot.
          
   57338
          Error 407 is raised when issuing select distinct with a view.
          ("Unable to allocate ancillary table for query
          optimization....")
          
   57273
          Server could reject previously accepted large queries with 703
          error ("Memory request failed because more than 64 pages are
          required to run the query") if the query uses explicit/implicit
          CONCAT nodes.
          
   57002
          When using a group by clause in a select statement, the
          matching of the select list and the group by list reshuffles
          the query tree too early and causes an erroneous result in
          queries whose pattern is of the kind: select col_a, col_a +
          col_b from some_table where some_selectivity_condition group by
          col_a, col_a + col_b
          
   56959
          select str(value,n,2) statement returns -0.-0 instead of -0.00
          when used on datatype float containing value `-0.0'.
          
   56927
          load database results in stack trace:
          lddb_main->lddb_fixdbosuid->update->insert->cinsert->
          datasplit->linksplit->ncrid_update->delirow->bufdirty
          
   56652
          2805 and 2812 errors with stored procedures containing compute
          clauses when multiple copies in cache being used.
          
   56635
          select substring(@@version,12,2) returns NULL.
          
   56540
          sp_lock: On a system with thousands of locks in use,
          overflowing the temporary buffer used to insert into syslocks
          also can result in process infection and stack trace.
          
   56430
          When performing outer join and qualifying inner table is NULL,
          returned values for inner table column are NULLs (when they in
          fact are not).
          
   56393
          When commiting the DEALLOC records for text-delete, a small
          window exists in which the deallocated first text-page could be
          allocated again to some other object before original
          transaction completes & locks are released.
          
   56283
          Timeslice error occurs while recovering transaction log.
          
   56185
          ex_raise from routine sort of worktable with dynamic index
          results in 1129 on the OAM page of worktable being sorted.
          Worktables not being handled as temporary tables when they
          should be.
          
   56127
          Range levels are incorrect when a subquery selects from a view.
          
   56064
          The detection of KILLYOURSELF status in the lock manager is
          disabled, until all code paths have been examined for proper
          handling of lock interrupts. Killing a task waiting on a lock
          will only succeed if the lock can be granted.
          
   56014
          A few long-running XACTs and/or a multitude of shorter XACTs
          can cause detection delays of up to 10 minutes.
          
   56013
          select from table order by... from a table that has text
          columns holds shared page locks (as if it is doing level 3
          locking) and eventually run out of locks with error 1204.
          
   55799
          Search density is not used in the case where a search value is
          in multiple steps or outside the step range, and therefore it
          should not include those values.
          
   55756
          When executing sp_dropmessage for a user who is not the
          database owner, not creator of the message and does not have
          the System Security Officer role, gets error saying "unmatching
          argument list to PRINT command".
          
   55180
          Reformatting of work table not done as a result of wrong page
          and row estimate for a temporary table created in the same
          batch and used later in a join with a user table in the same
          batch. 302 trace output shows (rows: 1 pages: 1)
          
   55017
          When a truncate table is interrupted due to an attention, the
          transactions in progress are not cleared.
          
   54952
          When lock manager trace 1204 is active, the display of a single
          chain deadlock generates time-slice errors.
          
   54471
          Inserting into a view using a select statement with a group by
          clause in which no aggregate is specified in the select list,
          causes the client to be killed and a "process infected with
          Signal 10" error is reported in the server's error log.
          
   54388
          Inserting into a very large table causes 1127 errors when
          maximum number of OAM page entries is reached.
          
   54367
          Unable to reference temporary tables created by a parent stored
          procedure in the child stored procedure. The data returned from
          the child stored procedure is corrupted.
          
   53879
          Dropping a work table using the full object name (such as
          tempdb..#tbl) doesn't free the memory associated with the
          temporary table. If a process creates and drops lots of
          temporary tables, it may eventually die with a 703 error.
          
   53837
          If you create a table with more than 8 columns, insert some
          values, revoke update on one column of the table, and then try
          to update the eighth or higher columns of the table, error 230
          is raised ("permission denied on column col9 of object
          foo...").
          
   53532
          When a PC Windows client machine is turned off while OMNI is in
          the process of a select to DB2 returning a very large result
          set, OMNI does not detect the loss of the client, disconnect
          the user, or close the thread to a Net-Gateway.
          
   52733
          Executing a procedure which declares a variable @var and
          assigns a procedure name to it and then tries to exec @var may
          result in a stack trace.
          
   52174
          Add limited conversion functionality between EUCJIS SQL Server
          and SJIS clients.
          
   51604
          The SQL/LTI thread assumes a stored procedure's EXECBEGIN log
          record is written into the same database where the sproc is
          stored. This is not true if the procedure executes from within
          a user XACT started in another database. A 9141 error will
          result.
          
   50987
          select x = null into table returned error msg `Column `x'
          specifies storage type 31, which does not currently exist.' The
          column `x' should be created with a default datatype of
          nullable int.
          
   49514
          Different presentation format (exponential) of the output (if
          big enough) from sp_spaceused.
          
   45987
          System stored procedure sp_remove_xact has a parameter @commid
          defined as a smallint, and it should be defined as an int.
          
   35593
          cmastmirror configuration value of the master device. If the
          user had done a buildmaster -r before disk remirror the server
          would not activate the mirror with the message "dopen : "" is a
          directory."
          
   33368
          An order by of a union of two select statements that contain
          text columns previously gave a 420 error (Image/Text not
          allowed in order by), although the Text/Image column was only
          in the select list.
          
   17738
          SERVER error message 4207 should read "Dump transaction is not
          allowed because a non-logged operation was performed on the
          database. Dump your database or use dump transaction with
          truncate_only until you can dump your database."
          
  Latest Rollups for SQL Server 10.0.2

Platform                           Rollup Number
SunOS Release 4.x (BSD)            4009
HP 9000 Series 800 HP-UX           4010
IBM RISC System/6000 AIX           4011
AT&T; System 3000 UNIX SVR4 MPRAS   4012
Digital OpenVMS VAX                4013
Sun Solaris 2.x                    4014
Digital OpenVMS Alpha 1.5   4015
Digital OSF/1               4019

  Bugs Fixed in Latest Rollup, SQL Server 10.x
  
   17668
          count(*) is not returning correct results in a view on three
          tables, three columns updating two columns of another table
          with the count from the view. Works when done one at a time and
          using the table directly (select into).
          
   18345
          sp_renamedb fails to change the internal dbi_dbname variable.
          This causes incorrect 3508 messages, among other possible side
          effects.
          
   19144
          When inserting from a table that allows NULL values to a table
          that is defined as not NULL, convert "sneaks" NULL values in.
          When you select distinct on the new table, the discrepancy
          shows up.
          
   25462
          Use of a table correlation name within a correlated subquery
          does not correspond to ANSI 1989 SQL standard page 46; non-use
          of table alias within an inner select statement does not revert
          table queried to that used in outer select
          
   25844
          "looping 2714s" sample stack: _kisignal sigtramp.o sigtramp.o
          _s_free _s_pop _s_cleanframe _clean_process _kill_proc
          __ex_cleanup _kisignal sigtramp.o sigtramp.o _s_free _s_pop
          _s_cleanframe _clean_process.
          
   28221
          Recovery modifications needed to avoid recompleting
          transactions from the earliest BEGIN RID record in the log to
          the checkpoint record.
          
   29069
          When updating a single column of one row on which there exists
          a unique nonclustered index, excessive number of pages are
          locked. Exact scenario using a unique clustered index will lock
          the correct number of pages.
          
   31730
          When the server is stopped, a "%SYSGEN-E-CONFIGERR, CONFIGURE
          process" error is reported on the operator's console. The
          operator's console is left in a hung state, not allowing any
          logins.
          
   32566
          When the error message for error 821 is printed, a newline
          character is missing which makes the user errorlog difficult to
          read.
          
   33151
          During iterative bcp data in sessions, seg. fault occurs with
          an incomplete stack trace and time slice results in Error 1501.
          
   33398
          Cannot use full name of temporary table to drop it in 4.8.
          Results in 3701 error: create table #CM2746 (col1 char(1)) use
          tempdb select name from sysobjects where col1 like "#CM2746%"
          drop table #CM2746____000000100077667955.
          
   33475
          Unmirroring permanently should not attempt to set affinity on
          debug engine.
          
   33726
          update tablea set tablea.fielda=tableb.fireldb where
          dbname.dbo.tablea.fieldc=dbname2.dbo.tableb.field3 - loops on
          writing to syslogs. When tables to be joined are in the same
          database, all is OK.
          
   33769
          When deadlock occurs while inserting a row on an overflow page,
          an attempt is made to unkeep a buffer twice.
          
   34124
          Attempt to drop database raises error 834. There is no error
          message associated with 834.
          
   35139
          Using bcp in on a table with index that has ignore dup key set
          may cause Errors 1129, 813, 2525, 2521, and data corruption.
          
   35287
          The Navigation Server needs to read the distribution pages for
          tables for help in optimization. Change TDS 5.0 to allow this.
          
   36404
          Procedure sybase_manager.com should include foreign symbol
          definition for `upgrade' which will allow easy execution of the
          upgrade program for phase 4 of the upgrade process. See
          Appendix A of the Installation Guide for examples of using the
          program for recovery purposes
          
   37829
          The following SQL statement produces a parse tree that is
          incorrect. In addition the syntax is illegal in ANSI. "declare
          @v1 int, @v2 int
          select @v1 order by @v2".
          
   37934
          There is a bug in installasync70. First: the asynchronous
          driver isn't shipped with 700s (HP-UX 8.07), the customer must
          get PHKL_1017. Next, the script assumes the driver ends up in
          /hpux_install - but it usually doesn't after applying patch.
          
   38574
          The sp_auditobject (and sp_auditsproc) procedures expect a
          table or view (or stored procedure/trigger) name as the first
          argument. We allow the owner.name format, but they provided
          dbname.owner.name, and the command failed later than it should
          have.
          
   39246
          Customer had a problem with isql on VMS 5.5. /colwidth did not
          work. This is a reported bug in the documentation (27341). It
          was supposed to be fixed in 4.8.0.1, but it was not fixed in
          the 4.9.1 docs. Also /separator should be /colsepa.
          
   39736
          startserver problems: an extra # on first line of script
          created for -m causes shell specification to be ignored,
          causing script to fail on platforms using csh. m_ is prefixed
          to runserver file name without regard to whether it is a full
          path or not. runserver script won't work unless the full path
          is given or script is found in PATH directory. A previous
          workaround conflicted with -m.
          
   39801
          When command text auditing is disabled, a memory structure
          isn't being cleared. Thus, the parser thinks we should be
          saving the text, and we end up segfaulting.
          
   41854
          Install sybsyntax db by running ins_syn_sql script, issue
          sp_syntax get error `server user id is not a valid user in db
          sybsyntax'. The same problem happens with ins_syn_dblib also.
          
   42132
          executing sp_clearstats and sp_reportstats by "sa" before any
          user logins are created gives error "divided by zero".
          
   42269
          shutdown SYB_BACKUP with nowait, while a dump is in progress,
          causes Backup Server to dump core.
          
   42514
          Dump of a database to 8-mm tape without the init option will
          overwrite what is on the tape. Dump should fail. The init
          option should be used to overwrite. If you dd a file to the
          tape, the dump will succeed and overwrite the file.
          
   42901
          Error 813 "logical page already hashed" after a bcp, running
          concurrently with another process, aborts.
          
   43282
          Both 491 on solaris21 and sys10beta on sunos412 show error 102
          returned when attempting to pass `+3' as int parameter to a
          stored procedure, although it succeeds in dynamic variables and
          direct inserts.
          
   43661
          Assignments of the "sybase_ts" role do not take effect in the
          same login session. This means that many diagnostic tools
          cannot be used unless the server is healthy enough to let
          someone log in twice, once to assign the role and a second time
          to use it.
          
   44275
          select "column_heading" = column_name or select column_heading
          = column_name or select column_name as column_heading works but
          select column_name as "column_heading" doesn't.
          
   44667
          shutdown with nowait of a Backup Server while a dump is in
          progress results in a Backup Server core dump with "assertion
          failed".
          
   44680
          Backup Server can not perform dump/load database when the
          database device is on a character special device. Backup Server
          returns Error 4.56.2.1
          
   45492
          Customer is getting an inexplicable 224 error when inserting
          into a table that has both a reference constraint and check
          constraints.
          
   45723
          create table, alter table then add constraint, drop constraint,
          and add constraint raises error 1923: "..table cannot have more
          than one primary key...", but there is no primary key.
          
   45837
          Identity problem: create table t1 (f1 numeric(2,0) identity)
          then create view vident as select f1 from t1, insert into
          vident values() results in stack trace with the message
          "current process(0x80008) infected with Signal 11 ... The SQL
          Server is terminating this process."
          
   
     _________________________________________________________________
   
   
   
   Disclaimer: No express or implied warranty is made by SYBASE or its
   subsidiaries with regard to any recommendations or information
   presented in SYBASE Technical News. SYBASE and its subsidiaries hereby
   disclaim any and all such warranties, including without limitation any
   implied warranty of merchantability of fitness for a particular
   purpose. In no event will SYBASE or its subsidiaries be liable for
   damages of any kind resulting from use of any recommendations or
   information provided herein, including without limitation loss of
   profits, loss or inaccuracy of data, or indirect special incidental or
   consequential damages. Each user assumes the entire risk of acting on
   or utilizing any item herein including the entire cost of all
   necessary remedies.
   
   Staff
   
   Principal Editor: Leigh Ann Hussey
   
   Contributing Writers:
   
   Brijesh Agarwal, Perry Bent, Siva Chandrasekharan, Scott Duncan, Aimee
   Grimes, Cris Gutierrez, Leigh Ann Hussey, Chandrika Krishnan, Cristina
   Nitescu, Daniel O'Rourke, Pearl Ong, Chuck Pavelka, Gerald Soulos,
   Loretta Vibberts, Robert Weaver, Elton Wildermuth, Melissa Yeary
   
   SYBASE Technical News
   6475 Christie Avenue
   Emeryville, CA 94608 USA
   
   
        For more info send email to techpubs@sybase.com
        Copyright 1995  Sybase, Inc. All Rights Reserved.
                                   Q10.2.2

                 Technical News Volume 4, Number 2, May 1995

This issue of SYBASE Technical News contains new information about your
SYBASE software. If needed, duplicate this newsletter and distribute it to
others in your organization. All issues of SYBASE Technical News and the
troubleshooting guides are included on the AnswerBase CD.

To receive this document by regular email, send name, full internet address
and customer ID to technews@sybase.com.

IN THIS ISSUE

   * Tech Support News/Features
        o How Technical Support Uses Case Survey Metrics
   * SQL Server
        o HP: Mirror Fail-Over and installasynch80
        o buildmaster -y and -r Options to Become Obsolete
        o dump transaction Fails to Truncate Log
        o How to Read dbcc checkalloc Output
        o Replication Server System Database Recovery
        o min() and max() Functionality
        o Viewing all Decimal Digits in a select from money_column
        o Dump/Load Compatibility, 10.0.1 vs. 10.0.2
   * Connectivity / Tools / PC
        o keepalive Redux
        o Setting up Borland IDE to Compile Client-Library
        o Macintosh Think-C and ct_init Routine
   * Certification and Fixed Bug Reports
        o SQL Debug Certified for DEC OSF/1
        o IPX/SPX Certification for Solaris
        o Certification Report for All Platforms
        o Bug 61483 - Duplicate Rows in syskeys

How Technical Support Uses Case Survey Metrics

Sybase Technical Support has been sending out a Technical Support Case
Closure Satisfaction Survey for 16 months (September 1993 through January
1995). In October 1994, based on feedback from customers who had responded
to the survey, we modified the survey process such that:

   * Customers receive surveys no more frequently than twice a year.
   * Customers are asked to respond about one completed case instead of
     multiple cases.
   * Customers who request it continue to receive monthly case status
     reports.

The feedback received is being used in the following manner to drive
corrective action and process improvements:

   * Returned surveys that include concerns about the handling and/or status
     of cases are regularly forwarded to Technical Support managers to
     ensure follow-up and, if required, corrective action.
   * A team of 10 to 12 Technical Support engineers met monthly for several
     months to carefully review customer narrative comments on the quality
     of our support and to document the concerns and suggestions for senior
     management review and action.
   * Documentation developers met to review customer comments on the quality
     of our documentation to determine what improvements could be made.
   * Senior managers are using the information to develop plans for support
     process improvements and are taking ownership for follow-up on these
     plans.

We want to thank all of you who have taken the time to respond to our survey
and ask that you continue. We have heard very clearly that electronic
delivery of surveys would make it easier for you to continue to respond and
we are pursuing that capability.

HP: Mirror Fail-Over and installasynch80

Question

In testing mirror fail-over on HP, I cannot get the server to switch over
when the primary device is powered off. What is the problem?

Answer

This problem has been tracked to the installasynch80 script. The mknod
command for async is in error. The incorrect command included in the script
is as follows:

 /etc/mknod /dev/async c 101 0

The command should read as follows:

 /etc/mknod /dev/async c 101 0x7

Here is the corrected section in the installasynch80 script, which you will
find in your $SYBASE/install directory:

#
# create_devices creates the async i/o devoce file
#
create_devices()
{
echo ""
echo "  We are about to create the asynchronous raw disk i/o device."
echo "  If this device already exists, it will be replaced. "

# prompt user for continuation
#
checkanswer

echo "  Creating asynchronous i/o device....."
rm -f /dev/async  /dev/asynch[0-9]*
/etc/mknod /dev/async  c  101  0x7
chmod 0660 /dev/async
chown sybase /dev/async
chgrp $GROUP /dev/async
echo ""
echo "  Async device has been created. "
}

buildmaster -y and -r Options to Become Obsolete

A new configuration interface for the next generation of SQL Servers after
System 10[TM] will render both the -y and -r command line flags to
buildmaster obsolete.

All configurable options (cdbnum, cmemsize, cfgxdes, and so on) will be
placed in a configuration file, which is in a text format.

In System 10 and earlier releases, buildmaster -y and -r are used to change
the values of options in the config block of SQL Server. They will no longer
be needed because the new configuration interface will allow users to modify
the values in a flat text config file. Also, the names in the config file
will not be cdbnum, cmemsize, and the like, but will be "number of
databases", "total memory", and so forth, rendering the information more
understandable.

If the config file cannot be booted, SQL Server will still be able to start
under the default settings (formerly the -r option) by not specifying a
configuration file.

In addition, the dynamically tunable parameters will be changed with the
sp_configure command, not when reconfigure is run.

Watch your Technical News for more information as it becomes available.

dump transaction Fails to Truncate Log

     ------------------------------------------------------------------
     WARNING! Although the following procedure has been tested
     rigorously and used at many customer sites, it uses undocumented
     and unsupported dbcc commands.
     ------------------------------------------------------------------

If you are issuing a dump transaction command and find that the log is not
being truncated, it is possible that an open transaction is preventing the
log from being cleared. This occurs because dump transaction will only
truncate the log up to, but not including, the log page that contains the
begin transaction for the oldest active transaction. You can use the
following procedure to determine the spid, suid, and time of the open
transaction (you must be the "sa" user or have the sa role to use this
procedure):

  1. Enable dbcc command output to appear on the screen:

     dbcc traceon(3604)
     go

  2. Print the oldest outstanding checkpoint record.

     dbcc log(dbid,0,0,0,-1,17,0)
     go

  3. The output from this allows you to find the ID of the oldest active
     transaction. Output will be similar to the following:

     LOG RECORDS:
       CHECKPOINT(262 ,12)
       attcnt=1 rno=3 op=17 padlen=0 xactid=(262 ,12) len=60
       status=0x0000 /* ^^^ length field */
       rows=11407892, pages=79 extents=288
       status=4096 timestamp=0x0001 0x0000811d
       active xacts:(262,3)  /* oldest active xact ID */

          -------------------------------------------------------------
          NOTE: This technique is not valid if the length field has a
          value of 52 or less. In this case, execute a checkpoint and
          try again.
          -------------------------------------------------------------

  4. Display the begin transaction record associated with the output active
     transaction ID. Note that the third and fourth parameter values of the
     following command come from the active xacts field above:

     dbcc log(dbid,1,262,3,1,0,1)
     go

     Output in the example case looks like this:

     LOG RECORDS:
       BEGINXACT(262 , 3)
       attcnt=1 rno=3 op=0 padlen=3 xactid=(262,3) len=76
       status=0x2C20
       masterid=(0,0) lastrec=(0,0) xstat=XBEG_ENDXACT
     >>>>>>  spid=5 suid=1 uid=1 masterdbid=0 mastersite=0 endstat=3
     ^ name=user_transaction    time=Sep 20 1991   1:02PM
     ^
     ^ SPID and SUID of process owning outstanding xact

  5. Get the login name that matches the suid:

     use master
     go
     select name from syslogins where suid = suid
     go

Now run sp_who to see if there is an entry that contains both the SPID and
login name obtained above. If so, follow up with the user to find out what
their transaction is and if they can exit their program or isql session or
issue a commit tran. Alternatively, you can immediately kill the process
yourself. This should terminate the process and resolve the blocking
transaction. Issuing the dump transaction command again should clear the
log.

If the log is still not being cleared, or if there is not a matching entry
in sp_who, then the user that issued the blocking begin tran is no longer
logged onto SQL Server but SQL Server is unaware of this. This occurs
primarily when a user connecting from a PC client has powered off the PC in
the middle of a transaction, has exited a third-party application by
pressing ctrl-C, or has encountered network errors on terminating the
connection to SQL Server. In this case, if kill did not work, the only
recourse is to reboot SQL Server.

If a user was not knowingly holding an open transaction, you can examine
your SQL Server error log for clues to help you diagnose why the transaction
was left open. Messages to look for include "current process infected",
"network error was encountered" (Error 1608), "host process disconnected,"
and stack traces. Sybase Technical Support can help you analyze these
errors. If you have a UNIX environment where this problem is occurring
frequently, you may want to adjust your keepalive kernel parameter to a
lower value. See your SYBASE System Administration Guide Supplement,
operating system documentation, or contact your operating system vendor for
more information on the keepalive parameter and how to set it. If your
environment consists of a number of users utilizing a single login to access
SQL Server, Sybase Technical Support can give you trace flags to help track
down the user who is causing the problem.

     ------------------------------------------------------------------
     NOTE: PowerBuilder users: When keepalive fails to clear a
     connection, it may have occurred because PowerBuilder had a
     General Protection Fault and the user simply restarted Windows.
     This leaves the LAN transport software/firmware holding the
     connection open to SQL Server. keepalive will not clear the
     connection, since the client side LAN is still holding the old
     connection. When the user starts PowerBuilder again, it will get a
     new connection to SQL Server.

     You can use sp_who or netstat to see if the old user connection is
     still active.

     The only way to clean up the connection is to turn off the PC that
     opened the connection; this resets the connection and allows
     keepalive to do the proper cleanup on the SQL Server side.
     ------------------------------------------------------------------

How to Read dbcc checkalloc Output

Question

When examining the output of a dbcc checkalloc command, I notice that only
one page seems to be used per extent on many allocation pages. Why?

Here is a sample of the output:

[...]
Alloc page 16128 (# of extent=1 used pages=1 ref pages=1)
Alloc page 16384 (# of extent=1 used pages=1 ref pages=1)
Alloc page 16640 (# of extent=1 used pages=1 ref pages=1)
[...]

Answer

An extent is a group of eight pages. Every 256th page in a database is an
allocation page, which is used to track the space being used.

The above output does not show that one page is used per extent on many
allocation units; it shows that one extent is in use and that, on that
extent, one page is allocated. That is, exactly one page is allocated out of
that group of 256 pages.

That page is, of course, the allocation page itself, which is always
allocated. The other 255 pages on each such allocation unit are available to
whatever object needs the space.

     ------------------------------------------------------------------
     NOTE: Normally an extent is owned by whatever object/index
     combination first grabs space on it. The first extent on each
     allocation unit, which controls the allocation page itself, is an
     exception: the allocation page is always allocated, but the extent
     is considered free if that page is the only one allocated.
     ------------------------------------------------------------------

Replication Server System Database Recovery

Following the recovery procedure outlined in the Replication Server
Administration Guide dated October 21, 1993, for Replication Server System
Database (RSSD) recovery could possibly put the Log Transfer Manager (LTM)
into an infinite loop.

Please substitute the following revised sections for the sections that
appear in the chapter, "Replication System Recovery" of any Replication
Server Administration Guide dated prior to March 15, 1995.

Recovering an RSSD from Dumps

The procedure you use to recover an RSSD depends on how much RSSD activity
there has been since the last RSSD dump. There are four increasingly severe
levels of RSSD failure, with corresponding recovery requirements. Use Table
1: Recovering from RSSD failures to locate the RSSD recovery procedure you
need.
                   Table 1: Recovering from RSSD failures

       Activity Since Last Dump                 Use This Procedure
 No DDL activity                      Basic RSSD Recovery Procedure
 DDL activity, but no new routes or
 subscriptions were created           Subscription Comparison Procedure
 DDL activity, but no new
 subscriptions were created           Subscription Re-Creation Procedure
 New routes were created              Deintegration/Reintegration Procedure

Basic RSSD Recovery Procedure

Use the basic RSSD recovery procedure to restore the RSSD if you have
executed no DDL commands since the last RSSD dump. DDL commands in RCL
include those for creating, altering, or deleting routes, replication
definitions, subscriptions, function strings, functions, function string
classes, or error classes.

Certain steps in this procedure are also referenced by other RSSD recovery
procedures in this article and in the Replication Server Administration
Guide.

     ------------------------------------------------------------------
     WARNING! Do not execute any DDL commands until you have completed
     this recovery procedure.
     ------------------------------------------------------------------

The current Replication Server refers to the one with the RSSD you are
recovering. An upstream Replication Server is a Replication Server that has
a direct or indirect route to the current Replication Server. A downstream
Replication Server is a Replication Server to which the current Replication
Server has a direct or indirect route.

To perform basic RSSD recovery, follow these steps:

  1. Shut down all LTMs that connect to the current Replication Server.

  2. Since its RSSD has failed, the current Replication Server is down. If
     for some reason it is not down, log into it and use the shutdown
     command to shut it down.

     -----------------------------------------------------------------------
     NOTE: Some messages may still be in the Replication Server stable
     queues. Data in those queues may be lost when you rebuild these queues
     in later steps.
     -----------------------------------------------------------------------

  3. Restore the RSSD by loading the most recent RSSD database dump and all
     transaction dumps.

  4. Restart the Replication Server in standalone mode, using the -M flag.

     You must start the Replication Server in standalone mode, because the
     stable queues are now inconsistent with the RSSD state. When the
     Replication Server starts in standalone mode, reading of the stable
     queues is not automatically activated.

  5. Log into the Replication Server, and get the generation number for the
     RSSD, using the admin get_generation command:

      admin get_generation, data_server, rssd_name

     For example, the Replication Server may return a generation number of
     100.

  6. In the Replication Server, rebuild the queues with the following
     command:

      rebuild queues

     See "Rebuilding Queues Online" in the Replication Server Administration
     Guide for a description of this process.

  7. Start all LTMs (except the RSSD LTM) that connect to the current
     Replication Server. Start in recovery mode, using the -M flag. Wait
     until each LTM logs a message that it is finished with the current log.

  8. Check the loss messages in the Replication Server log and in the logs
     of all the Replication Servers with direct routes from the current
     Replication Server.

     If all your routes were active at the time of failure, you probably
     will not experience any real data loss.

     However, loss detection may indicate real loss. Real data loss may be
     detected if the database logs were truncated at the primary databases,
     so that the rebuild process did not have enough information to recover.
     If you have real data loss, reload database logs from old dumps. See
     "Recovering from Truncated Primary Database Logs" in the Replication
     Server Administration Guide.

     See "Loss Detection After Rebuilding Stable Queues" in the Replication
     Server Administration Guide for background and details on loss
     detection.

  9. Shut down the LTMs for all primary databases managed by the current
     Replication Server.

 10. Execute the dbcc settrunc command at the SQL Server for the restored
     RSSD. Move up the LTM truncation point.

              use rssd_name
              go
              dbcc settrunc('ltm', 'ignore')
              go
              begin tran commit tran
              go 40
              dbcc settrunc('ltm', 'valid')
              go

          -------------------------------------------------------------
          Note: The go 40 command moves the SQL Server log onto the
          next page.

 11. Execute the dbcc settrunc command at the SQL Server for the restored
     RSSD to set the generation number to one higher than the number
     returned by admin get_generation in step 5.

              use rssd_name
              go
              dbcc settrunc('ltm', 'gen_id', 101)
              go

     Make a record of this generation number and of the current time, so
     that you can return to this RSSD recovery procedure, if necessary. Or,
     you can dump the database after setting the generation number.

 12. Restart the Replication Server in normal mode.

     If you performed this procedure as part of the subscription comparison
     or subscription re-creation procedure, note that the upstream RSI
     outbound queue may contain transactions bound for the RSSD of the
     current Replication Server that have already been applied by using
     rs_subcmp. If this is the case, after starting the Replication Server,
     the error log may contain warnings referring to duplicate inserts. You
     can safely ignore these warnings.

 13. Restart the LTMs for the RSSD and for user databases in normal mode. If
     you performed this procedure as part of the subscription comparison or
     subscription re-creation RSSD recovery procedure, you should expect to
     see messages regarding RSSD losses being detected in all Replication
     Servers that have routes from the current Replication Server.

Subscription Comparison Procedure

Follow this RSSD recovery procedure if you have executed some DDL commands
since the last transaction dump, but you have not created any new
subscriptions or routes. DDL commands in RCL include those for creating,
altering, or deleting routes, replication definitions, subscriptions,
function strings, functions, function string classes, or error classes.

     ------------------------------------------------------------------
     WARNING! Do not execute any DDL commands until you have completed
     this recovery procedure.
     ------------------------------------------------------------------

Following this procedure makes the failed RSSD consistent with upstream
RSSDs or consistent with the most recent database and transaction dumps (if
there is no upstream Replication Server). It then makes downstream RSSDs
consistent with the recovered RSSD.

The current Replication Server refers to the one with the RSSD you are
recovering. An upstream Replication Server is a Replication Server that has
a direct or indirect route to the current Replication Server. A downstream
Replication Server is a Replication Server to which the current Replication
Server has a direct or indirect route.

If DDL commands have been executed at the current Replication Server since
the last transaction dump, you may have to re-execute them.

To restore an RSSD with subscription comparison, follow these steps:

  1. To prepare the failed RSSD for recovery, perform steps 1-4 of "Basic
     RSSD Recovery Procedure"

  2. To prepare for recovery the RSSDs for all upstream Replication Servers,
     execute the admin quiesce_force_rsi command at each upstream
     Replication Server.

        o This step ensures that all committed transactions bound for the
          current Replication Server have been applied before you execute
          the rs_subcmp program.

        o Execute this command sequentially, starting with the Replication
          Server that is furthest upstream from the current Replication
          Server.

        o Make sure that RSSD changes have been applied, that is, that the
          RSSD DSI outbound queues are empty.

        o The Replication Server that is directly upstream from the current
          Replication Server cannot be quiesced.

  3. To prepare for recovery the RSSDs for all downstream Replication
     Servers, execute the admin quiesce_force_rsi command at each downstream
     Replication Server.

        o This step ensures that all committed transactions bound for the
          current Replication Server have been applied before you execute
          the rs_subcmp program.

        o Execute this command sequentially, starting with Replication
          Servers that are immediately downstream from the current
          Replication Server.

        o Make sure that RSSD changes have been applied, that is, that the
          RSSD DSI outbound queues are empty.

  4. Reconcile the failed RSSD with all upstream RSSDs, using the rs_subcmp
     program.

        o First execute rs_subcmp without reconciliation to get an idea of
          what operations it will perform. When you are ready to reconcile,
          use the -r flag to reconcile the replicate data with the primary
          data.

        o You must execute rs_subcmp as the maintenance user. See "Managing
          Replication Server Security" in the Replication Server
          Administration Guide for more information on the maintenance user.

        o In each instance, specify as the replicate database the failed
          RSSD.

        o In each instance, specify as the primary database the RSSD of each
          upstream Replication Server.

        o Start with the Replication Server that is furthest upstream, and
          proceed downstream for all other Replication Servers with routes
          (direct or indirect) to the current Replication Server.

        o Reconcile each of the following RSSD system tables: rs_classes,
          rs_columns, rs_databases, rs_erroractions, rs_functions,
          rs_funcstrings, rs_objects, and rs_systext.

        o When you execute rs_subcmp on replicated RSSD tables, the where
          and order by clauses of the select statement must select all rows
          to be replicated. See "Using rs_subcmp on Replicated RSSD System
          Tables" for more information.

     The failed RSSD should now be recovered.

  5. Reconcile all downstream RSSDs with the RSSD for the current
     Replication Server, which was recovered in the previous step, using the
     rs_subcmp program.

        o First execute rs_subcmp without reconciliation to get an idea of
          what operations it will perform. When you are ready to reconcile,
          use the -r flag to reconcile the replicate data with the primary
          data.

        o You must execute rs_subcmp as the maintenance user. See "Managing
          Replication Server Security" in the Replication Server
          Administration Guide for more information on the maintenance user.

        o In each instance, specify the recovered RSSD as the primary
          database.

        o In each instance, specify the RSSD of each downstream Replication
          Server as the replicate database.

        o Start with the Replication Servers that are immediately
          downstream. Then proceed downstream for all other Replication
          Servers with routes (direct or indirect) from the current
          Replication Server.

        o Reconcile each of the following RSSD system tables: rs_classes,
          rs_columns, rs_databases, rs_erroractions, rs_functions,
          rs_funcstrings, rs_objects, and rs_systext.

        o When you execute rs_subcmp on replicated RSSD tables, the where
          and order by clauses of the select statement must select all rows
          to be replicated. See "Using rs_subcmp on Replicated RSSD System
          Tables" for more information.

     All downstream RSSDs should now be fully recovered.

  6. If the recovering Replication Server is an ID Server, you must restore
     the Replication Server and database IDs in its RSSD.

        o For every Replication Server, check the rs_databases and rs_sites
          system tables for their IDs.

        o Insert the appropriate rows in the recovering RSSDs rs_idnames
          system table if they are missing.

        o Delete from the recovering RSSDs rs_idnames system table any IDs
          of databases or Replication Servers that are no longer part of the
          replication system.

        o To ensure that the rs_ids system table is consistent, execute the
          following stored procedure in the RSSD of the current Replication
          Server:

            rs_mk_rsids_consistent

  7. If the recovering Replication Server is not an ID Server, and a
     database connection was created at the recovering Replication Server
     after the last transaction dump, delete the row corresponding to that
     database connection from the rs_idnames system table in the ID Server's
     RSSD.

  8. Perform steps 5-13 of "Basic RSSD Recovery Procedure".

  9. To complete RSSD recovery, re-execute any DDL commands that have been
     executed at the current Replication Server since the last transaction
     dump.

Using rs_subcmp on Replicated RSSD System Tables

When you execute rs_subcmp on replicated RSSD tables, for the subscription
comparison and subscription re-creation RSSD recovery procedures, for each
system table, the where and order by clauses of the select statement must be
formulated to select all rows that must be replicated.

Table 2 illustrates the general form of these select statements.

             Table 2: select statements for rs_subcmp procedure

 RSSD Table Name                      select Statement

 rs_classes     select * from rs_classes where prsid in sub_select order by
                primary_keys

 rs_columns     select * from rs_columns where prsid in sub_select and
                rowtype = 1 order by primary_keys

 rs_databases   select * from rs_databases where prsid in sub_select and
                rowtype = 1 order by primary_keys

 rs_erroractionsselect * from rs_erroractions where prsid in sub_select
                order by primary_keys

 rs_funcstrings select * from rs_funcstrings where prsid in sub_select and
                rowtype = 1 order by primary_keys

 rs_functions   select * from rs_functions where prsid in sub_select and
                rowtype = 1 order by primary_keys

 rs_objects     select * from rs_objects where prsid in sub_select and
                rowtype = 1 order by primary_keys

 rs_systext     select * from rs_systext where prsid in sub_select and
                texttype in ('O', 'S') order by primary_keys

In the select statements in Table 2, sub_select represents the following
statement, which selects all site IDs that are the source Replication
Servers for the current Replication Server:

        (select source_rsid from rs_routes
          where
            (through_rsid = PRS_site_ID
        or through_rsid = RRS_site_ID)
            and
            dest_rsid = RRS_site_ID)

where PRS_site_ID is the site ID of the Replication Server managing the
primary RSSD, and RRS_site_ID is the site ID of the Replication Server
managing the replicate RSSD for the rs_subcmp operation.

For the rs_columns, rs_databases, rs_funcstrings, rs_functions, and
rs_objects system tables, if rowtype = 1, then the row is a replicated row.
Only replicated rows need be compared using rs_subcmp.

For each system table, the primary_keys are its unique indexes.

Classes and System Tables

The default function string class rs_sqlserver_function_class and the
default error class rs_sqlserver_error_class do not initially have a
designated primary site, that is, their site ID = 0.

If the recovering Replication Server was made primary for a function string
class or error class since the last transaction dump, the rs_subcmp
procedure described earlier in this section would find orphaned rows in
downstream RSSDs.

In that event, run rs_subcmp again on the rs_classes, rs_erroractions,
rs_funcstrings, and rs_systext system tables. Set prsid = 0, in order to
repopulate these tables with the necessary default settings. For example,
use the following select statement for the rs_classes table:

        select * from rs_classes where prsid = 0
          order by primary_keys

Example

Suppose you have the following Replication Server sites in your replication
system, where an arrow (-->) indicates a route. Site B is the failed site,
and there are no indirect routes.

A-->B
C-->B
C-->D
B-->E

The preceeding Replication Server sites have the following site IDs:

A = 1
B = 2
C = 3
D = 4
E = 5

In this example, to bring the RSSDs to a consistent state, you would perform
the following tasks, in the order presented, on the rs_classes,
rs_erroractions, rs_funcstrings, and rs_systext system tables.

Reconciling with Upstream RSSDs

  1. Run rs_subcmp against the above tables, specifying site B as the
     replicate and site A as the primary, with prsid = 1 in the where
     clauses. For example, the select statement for rs_columns should look
     like the following:

             select * from rs_columns where prsid in
               (select source_rsid from rs_routes
                 where
             (through_rsid = 1 or through_rsid = 2)
             and dest_rsid = 2)
                 and rowtype = 1
                 order by objid, colname

  2. Run rs_subcmp against the above tables, specifying site B as the
     replicate and site C as the primary, with prsid = 3 in the where
     clauses. For example, the select statement for rs_columns should look
     like the following:

             select * from rs_columns where prsid in
               (select source_rsid from rs_routes
                 where
             (through_rsid = 3 or through_rsid = 2)
             and dest_rsid = 2)
                 and rowtype = 1
                 order by objid, colname

Reconciling Downstream RSSDs

  1. Run rs_subcmp against the above tables, specifying site B as the
     primary and site D as the replicate, with prsid = 2 in the where
     clauses. For example, the select statement for rs_columns should look
     like the following:

             select * from rs_columns where prsid in
               (select source_rsid from rs_routes
                 where
             (through_rsid = 2 or through_rsid = 4)
             and dest_rsid = 4)
                 and rowtype = 1
                 order by objid, colname

  2. Run rs_subcmp against the above tables, specifying site B as the
     primary and site E as the replicate, with prsid = 2 in the where
     clauses. For example, the select statement for rs_columns should look
     like the following:

             select * from rs_columns where prsid in
               (select source_rsid from rs_routes
                 where
             (through_rsid = 2 or through_rsid = 5)
             and dest_rsid = 5)
                 and rowtype = 1
                 order by objid, colname

     See the Replication Server Commands Reference for more information
     about the rs_subcmp program and the RSSD system tables.

Subscription Re-Creation Procedure

Follow this RSSD recovery procedure if you have created new subscriptions
since the last transaction dump, and if you have executed some other DDL
commands, but you have not created any new routes. DDL commands in RCL
include those for creating, altering, or deleting routes, replication
definitions, subscriptions, function strings, functions, function string
classes, or error classes.

     ------------------------------------------------------------------
     WARNING! Do not execute any DDL commands until you have completed
     this recovery procedure.
     ------------------------------------------------------------------

As with the subscription comparison RSSD recovery procedure, following this
procedure makes the failed RSSD consistent with upstream RSSDs, or
consistent with the most recent database and transaction dumps (if there is
no upstream Replication Server). It then makes downstream RSSDs consistent
with the recovered RSSD.

In this procedure, however, you also either delete or re-create
subscriptions that are in a limbo state due to the loss of the RSSD.

The current Replication Server refers to the one with the RSSD you are
recovering. An upstream Replication Server is a Replication Server that has
a direct or indirect route to the current Replication Server. A downstream
Replication Server is a Replication Server to which the current Replication
Server has a direct or indirect route.

If DDL commands have been executed at the current Replication Server since
the last transaction dump, you may have to re-execute them.

To restore an RSSD that requires that lost subscriptions be re-created,
follow these steps:

  1. To prepare the failed RSSD for recovery, perform steps 1-4 of "Basic
     RSSD Recovery Procedure"

  2. To prepare for recovery the RSSDs for all upstream and downstream
     Replication Servers, perform steps 2-3 of "Subscription Comparison
     Procedure"

  3. Shut down all upstream and downstream Replication Servers affected by
     the previous step. Use the shutdown command.

  4. Restart all upstream and downstream Replication Servers in standalone
     mode, using the -M flag.

     All LTMs connecting to these Replication Servers shut down
     automatically when you restart the Replication Servers in standalone
     mode.

  5. To reconcile the failed RSSD with all upstream RSSDs, perform step 4 of
     "Subscription Comparison Procedure".

     The failed RSSD should now be recovered.

  6. To reconcile all downstream RSSDs with the RSSD for the current
     Replication Server, perform step 5 of "Subscription Comparison
     Procedure".

  7. If the recovering Replication Server is an ID Server, to restore the
     IDs in its RSSD, perform step 6 of "Subscription Comparison Procedure".

  8. If the recovering Replication Server is not an ID Server, and a
     database connection was created at the recovering Replication Server
     after the last transaction dump, perform step 7 of "Subscription
     Comparison Procedure".

  9. Query the rs_subscriptions system table for the current Replication
     Server.

        o Also query all Replication Servers with subscriptions to primary
          data managed by the current Replication Server, or with primary
          data to which the current Replication Server has subscriptions.

        o You can query the rs_subscriptions system table by using the
          rs_helpsub stored procedure.

 10. For each user subscription in the rs_subscriptions system table,
     execute the check subscription command.

        o Execute this command at the current Replication Server and at all
          Replication Servers with subscriptions to primary data managed by
          the current Replication Server, or with primary data to which the
          current Replication Server has subscriptions.

        o Subscriptions with a status other than VALID must be deleted or
          re-created, as described below.

 11. For each Replication Server that has a non-VALID subscription with the
     current Replication Server as the primary:

        o Note its subid, and delete the appropriate row from the primary
          rs_subscriptions system table.

        o Use the subid from rs_subscriptions to find the corresponding rows
          in the rs_rules system table, and also delete those rows.

     For each system table, rs_subscriptions and rs_rules:

        o If a subscription is in the primary table and not in the replicate
          table (because it was dropped), delete the subscription row from
          the primary table.

        o If a subscription is in the replicate table and not in the primary
          table, delete the subscription row from the replicate table. After
          completing the rest of this procedure, re-create the subscription,
          as described in steps 17-19.

        o If a subscription is in both the primary and replicate tables, but
          not VALID at one of the sites, delete the rows from both tables.
          After completing the rest of this procedure, re-create the
          subscription, as described in steps 17-19.

 12. For each primary Replication Server for which the current Replication
     Server has a non-VALID user subscription:

        o Note its subid, and delete the appropriate row from the primary
          rs_subscriptions system table.

        o Use the subid from rs_subscriptions to find the corresponding rows
          in the rs_rules system table, and also delete those rows.

     For each system table, rs_subscriptions and rs_rules:

        o If a subscription is in the primary table and not in the replicate
          table, delete the subscription row from the primary table. After
          completing the rest of this procedure, re-create the subscription,
          as described in steps 17-19.

        o If a subscription is in the replicate table and not in the primary
          table (because it was dropped), delete the subscription row from
          the replicate table.

        o If a subscription is in both the primary and replicate tables, but
          not VALID at one of the sites, delete the rows from both tables.
          After completing the rest of this procedure, re-create the
          subscription, as described in steps 17-19.

 13. Execute the sysadmin drop_queue command at both the primary and
     replicate Replication Server, for all existing materialization queues
     for subscriptions deleted in steps 17-19.

 14. Restart in normal mode all Replication Servers, and their LTMs, that
     had subscriptions to primary data managed by the current Replication
     Server, or with primary data to which the current Replication Server
     had subscriptions.

 15. Perform steps 5-13 of "Basic RSSD Recovery Procedure"

 16. Re-execute any DDL commands executed at the current Replication Server
     since the last transaction dump.

 17. Enable autocorrection for each replication definition.

 18. Re-create the missing subscriptions using the bulk materialization
     method.

     Use the define subscription, activate subscription, validate
     subscription, and check subscription commands for bulk materialization.

 19. For each re-created subscription, restore consistency between the
     primary and replicate data in either of two ways:

        o Drop a subscription using the drop subscription command and the
          with purge option. Then re-create the subscription.
        o Use the rs_subcmp program with the -r flag to reconcile replicate
          and primary subscription data.

See the Replication Server Commands Reference for more information about the
rs_subcmp program and the RSSD system tables.

Deintegration and Reintegration Procedure

If you created routes since the last time the RSSD was dumped, you are
required to perform the following tasks before you can finish recovering the
RSSD:

  1. Remove the current Replication Server from the replication system.

     See "Modifying a Replication System," in the Replication Server
     Administration Guide for details.

  2. Reinstall the Replication Server.

     See the Replication Server Installation Guide for complete information
     about reinstalling Replication Server.

  3. Re-create Replication Server routes and subscriptions.

     See the Replication Server Administration Guide Chapter 6, "Subscribing
     to Replicated Tables," and Chapter 7, "Managing Routes," for details.

See the Replication Server Commands Reference for more information about the
rs_subcmp program and the system tables.

min() and max() Functionality

Question

How can I find min or max of two int or float columns forall rows in a
table? Is it possible to do min or max ontwo columns at once?

Answer

It is entirely possible to do min or max on two columnsat once. Given a
table that was created as follows:

        create table MINMAX( a int, b int)

you can use the following sequence of Transact-SQL commands to get
theresults you want:

        1> select a,b,  2> "max"  = (a+b)/2.0 + abs((a-b)/2.0), 3> "min"  = (a+b)/2.0 - abs((a-b)/2.0)  4> from MINMAX  5> go    a     b     maxmin      ------

You may also add convert(int....) if necessary.

Viewing all Decimal Digits in a select frommoney_column

Question

How do I convert a money field so that an entire entry, with allfour decimal
digits, is visible?

Answer

The following example shows one way to display all the digits in asingle
string (preserving leading zeros in decimals), given a tablewith one money
column loaded as follows:

        1> insert into lvmoney2 values ($12345678901.0087)      2> insert into lvmoney2 values ($11170305027104.1195)   3> go

Structure your query like this:

        select str(floor(m1),15,0) + convert (char(4), replicate("0", 4 - datalength(convert(varchar(4), convert(int,   (10000*(m1-floor(m1))) )  ))) + convert(varchar(4),     (convert(int, (10000*(m1-floor(m1))) ) ))) from lvmoney2

The output will look like this:

        -------------------         123456789010087      111703050271041195     (2 rows affected)

For further information, see "Float and Money Display Methods" inVolume 3,
Number 3 of the SYBASE Technical News (available inAnswerBase when you do a
full-text query of the form <title technicalnews>).

Dump/Load Compatibility, 10.0.1 vs. 10.0.2

Question

Can a backup done by a release 10.0.1 Backup Server be loaded onto arelease
10.0.2 SQL Server?

Answer

There are really two issues here, but the short answer is, yes,10.0.1 dumps
are compatible with 10.0.2. The two issues are:

   * Can you to load a 10.x dump to a 10.0.2 SQL Server?
   * Can you use different versions of Backup Server and SQL Server?

Loading Dumps from 10.0 or 10.0.1 P1 SQL Server to 10.0.1 P2 or 10.0.2

If you want to load a dump from a 10.0 SQL Server or from an earlierrelease
10.0.1 SQL Server to a 10.0.1 P2 or 10.0.2 SQL Server, youmust execute a
script to update all system tables and user databasescontained in the load.
This script is necessary because of changesto the sysreferences table for
release 10.0.1 P2 or later.

     ------------------------------------------------------------------
     NOTE: Do not use the script if you are loading a dump from 10.0.1
     P2 to 10.0.2. 10.0.1 P2 is completely compatible with 10.0.2, and
     no additional steps are needed.
     ------------------------------------------------------------------

Use an editor like vi to edit the upgradesysrefperdb.sqlscript, which is
located in the $SYBASE/upgrade directory.Insert the following lines at the
beginning of the script:

        use database_name       go

where database_name is the name of the database to be updated.

After you have completed the load, execute theupgradesysrefperdb.sql script
as System Administrator:

 % isql -Usa -Ppassword -Sserver_name < $SYBASE/upgrade/upgradesysrefperdb.sql

where sa is the name of a System Administrator account,password is the
password for that account, and server_nameis the name of the 10.0.1/P2 or
later SQL Server where you loaded the database.

Repeat steps 1 and 2 for every 10.0 or earlier 10.0.1 databaseloaded on a
10.0.1/P2 or later SQL Server, including the systemdatabases.

Back up all of your databases.

Backup Server vs. SQL Server Versions

If you use a 10.0 Backup Server with a 10.0.1 SQL Server, you willget this
error message:

        Open Server Session Fatal Error: 16227.15.0: Unknown token TDS  stream received by spid

If you are using the Backup Server that is compatible with your10.0.2 SQL
Server, you should be able to load dumps from 10.0 and10.0.1. Be sure to use
the compatible Backup Server with your SQLServer: 10.0 with 10.0; 10.0.1
with 10.0.1; 10.0.2 with 10.0.2.

     ------------------------------------------------------------------
     NOTE: An exception to this is the beta SQL Server and Backup
     Server release. Changes occurred between the beta and production
     releases that render dumps made by a beta Backup Server unreadable
     to a production Backup Server. See "Error 16227.15.0" in Chapter
     3, "Backup Server", of the SYBASE SQL Server Troubleshooting Guide
     dated February 14, 1995 for more details.
     ------------------------------------------------------------------

keepalive Redux

SQL Server users who have started networking with PC clients oftenquestion
the issue of "ghost" connections and keepalive timing that cancause a server
to run out of connections rapidly.

The problem is that the PC user is used to running the PC in standalonemode.
If the user submits a query to SQL Server which takes too long tofinish, or
has made a mistake, the user is likely to reboot the PC, orclose the
application with a Ctrl-Alt-Del. The aborted process hangsaround in SQL
Server and finishes after about four hours.

While this may seem like a db_cancel problem--that is, that the querydoes
not get cancelled when the PC goes down--it is actually due toincomplete
coding in the application combined with the value to whichthe keepalive
timeout is set on the SQL Server host machine.

Ideally, an application allows the PC user to cancel the query and doesa
db_cancel when the user chooses this option. Due to aspects both
ofapplication design and of Windows itself, this is not always possible.

Network connections are always peer to peer, meaning that both sidesknow
that the other side could go away at any time. However, because ofnetwork
traffic and processing considerations, it may take some timefor a machine to
respond. This is where keepalive comes in.

The keepalive timer controls how long the machine will wait for aconnected
machine to respond; the keepalive interval controls how longthe host will
wait between pings to the remote machine; the keepalivecount controls how
many times the host will ping the remote machinebefore it gives up and
clears the connection.

The problem in the PC-to-UNIX world is that the PC expects everythingto
behave as though it is local, while UNIX expects WAN-typeconnections. What
this means is that a PC generally has keepalive hardcoded at about one
minute. A UNIX machine has a keepalive timer whosedefault setting makes more
sense in a world of WAN and low-speedconnections-somewhere around two hours.

To close the connections more quickly, you must decrease the UNIXkeepalive
timer to match that of the PC more closely. Depending onnetwork traffic
constraints, one to five minutes should be adequate.See your System
Administration Guide Supplement oroperating system documentation to find out
how to setkeepalive.

Setting Up Borland IDE to Compile Client-Library

To compile Open Client Client-Library[TM] applications under BorlandC++ for
Windows, you can either modify the Sybase-supplied samplemakefile,
borland.mak, for your program or start a new InteractiveDevelopment
Environment (IDE) project. This article explains how to dothe latter.

  1. Open a new project for the program: for example, choose Project-->New
     Project from the menu bar. Browse to where the program is located (for
     example, $SYBASE\sample\ctlib), and enter the target name (for example,
     rpc). For our sample programs, change the Target Type to EasyWin[.exe].

  2. Make sure that the Class Library and BWCC checkboxes are not selected,
     and choose OK.

  3. Choose Options-->Project. Select Directories, and make sure the
     following directories are listed:

             Include: %BORLAND%\include; %SYBASE%\include; %SYBASE%\sample\ctlib     Library: %BORLAND%\lib; %SYBASE%\lib

     Where %BORLAND% is the Borland compiler home directory and %SYBASE% is
     the Sybase home directory (this can be set up as default for the
     compiler).

  4. Highlight the topic "Compiler/Defines". In the "Defines" window, you
     must have the following:

             WIN3;CS_FORCE_PROTOTYPES

     These can be included in your header files as well. CS_FORCE_PROTOTYPES
     causes prototype functions to be generated, eliminating warning
     messages about functions being used without prototypes.

  5. Select Linker-->General and make sure that the Case sensitive link
     checkbox is selected.

  6. Choose OK to accept all of the changes to the project. It is a good
     idea to select Options-->Save and save the new project at this point.

  7. Choose View-->Project and add the following libraries:

             wcomnlib.lib    wintllib.lib    wcslib.lib      wctlib.lib

     ------------------------------------------------------------------
     NOTE: You will also need to add wblklib.lib if you areusing bulk
     copy routines.
     ------------------------------------------------------------------

For the example programs, you will also need to add exutils.c tothe project.

Macintosh Think-C and ct_init Routine

If you are running the Open Client/C Developer's Kit for Macintosh andare
having trouble with the ct_init routine failing, even thoughyour LANG
variable is set correctly and ctlib.loc isavailable, it may be because the
default project size for Think-C istoo small. The default value is 396; try
setting its value to at least4000 and compiling your application again.

Certification Reports

The following certification reports have been passed along to
SYBASETechnical News by the appropriate Sybase engineering groups.

SQL Debug Certified for DEC OSF/1

SQL Debug has been certified to work with SQL Server release 10.0.2 forDEC
OSF/1. This corrects an existing problem between SQL Debug and DECOSF/1 SQL
Server release 10.0.1 or earlier where a control-of-flowlanguage statement,
such as if...else or while, causesSQL Debug to hang.

IPX/SPX Certification for Solaris

As of the 10.0.2 release of SQL Server on Solaris 2.x, IPX/SPX iscertified
and supported. You need to apply Rollup 4222 for thiscombination to be
certified; you may order the Rollup from TechnicalSupport in the usual way.

IPX/SPX is certified at the current release level of Solaris 2.3.

Certification Report for All Platforms

<<<<<<<<

  Platform     Operating     Server    Date               Notes
            System Version
                                              Passed. Tape device is
                                              supported on all OS levels
           QIC tape device  10.01    08/94    currently supported for
                                              10.0x. OS patch required:
                                              PSCSI version 94.04.25.19

           SVR4 2.00.02                       Passed. Certified with
           (SMP)            4.9.1    04/93    WIN-TCP/IP 2.00.04. Requires
                                              ASYNCH I/O patch P2ASYNC.
           SVR4 2.00.02                       Passed. Certified with
           (UP model)       4.9.1    04/93    WIN-TCP: (i386) 02.00.04.02
           SVR4 2.01        10.0     02/94    N/A. No plans to certify.

           SVR4 2.01        4.9.1    04/93    Passed. Certified with
                                              WIN-TCP 2.00.05.
           SVR4 2.01.01 +                     Passed. Certified with
           Pentium          4.9.1    07/93    WIN-TCP 2.01.00.12

           SVR4 2.02        10.0     02/94    Passed. certified with
                                              WIN-TCP 2.01.01.08.
                                              Passed. certified with
           SVR4 2.02        4.9.2    12/93    WIN-TCP 2.01.01.08. and
                                              Rollup 2025 (built on OS
                                              2.00.01 with patched libdbt).
           SVR4 2.02 +
           pentium          10.0     02/94    Passed.
                                              Passed. Certified w/WIN-TCP
                                              2.02.00.07. OS patch PSCSI203
                                              is required for any customer
 AT&T      SVR4 2.03        10.01    08/94    planning to use the HP DAT
 (NCR)                                        4mm tape drive for
                                              backupserver.
                                              Passed. Rollup 3165 is built
                                              with a new libdbt.a so that
                                              SQL Server would work with
           SVR4 2.03        4.9.2    09/94    AT&T UNIX 2.02 and later
                                              releases without problems and
                                              make use of improved system
                                              calls.
           SVR4 2.03 +
           EISA bus         10.01    11/94    Passed.
           SVR4 2.03 +
           EISA bus         4.9.2    12/94    Passed.
                                              Passed. Bugs entered:
                                              sybinit(65591), doc(65604),
                                              connectivity(65807,65 817).
           SVR4 2.03 +                        PC Windows Net-Library EBF
           SPX/IPX          10.0.2   01/95    #4316 is required for
                                              connectivity bug #65807. PC
                                              Windows DB-Library (4.2)
                                              based clients can connect to
                                              the Unix Server.
                                              Passed. A series of patches
           SVR4 2.03.01     10.01    12/94    are needed to support EISA
                                              and MCA systems.
                                              Passed. A series of patches
           SVR4 2.03.01     4.9.2    12/94    are needed to support EISA
                                              and MCA systems.
                                              Supported. This was handled
                                              as a maintenance rollup
           AXP OpenVMS 1.5  4.9.2             release. All customers will
                                              be shipped the EBF rollup
                                              which supports AXP VMS 1.5.
           AXP OpenVMS 1.5
           + UCX            4.9.2             N/A, No plans to certify.
                                              Passed. UCX (ECO 2 or higher)
                                              is required. SQL Server must
                                              be configured for double the
           AXP OpenVMS                        bytlm. In addition, if user
           1.5+UCX 3.1      10.01    09/94    clients are put into a MUTEX
                                              state we recommend doubling
                                              the bytlm for the number of
                                              users.
                                              Passed. Network packages
           AXP OpenVMS 6.1  10.01    12/94    certified: DECnet Phase IV,
                                              UCX 3.2 and Multinet 3.3
 DEC Alpha
                                              Passed. Network packages
           AXP OpenVMS 6.1  4.9.2    01/95    certified: DECnet Phase IV,
                                              UCX 3.2 and Multinet 3.3
           OSF/1 1.3        10.00    11/93    Passed.
           OSF/1 2.0        10.01    09/94    Passed.
                                              Passed. The "b" in the OS
           OSF/1 2.0b       10.01    09/94    version indicates that the OS
                                              is for the new DEC 2100 sable
                                              machines.
           OSF/1 2.1        10.01    11/94    Supported.
                                              A new product release is
                                              required to support OSF/1
                                              3.0. It will be only sent to
           OSF/1 3.0        10.0.2   01/95    those customers who request
                                              it via the new PID issued as
                                              19555. Contact Sybase
                                              Customer Service.
           Ultrix 4.3       4.2      11/92    Passed.

 DEC RISC  Ultrix 4.3a      4.2      06/94    Passed. Requires ebf# 2005.
           Ultrix 4.4       4.2      10/94    Certified. EBF 2005 or higher
                                              required.
                                              Passed. To run UCX, SQL
                                              Server must be configured via
                                              the VMS AUTHORIZE utility for
           OpenVMS 5.4 +                      double the bytlm stated in
           UCX 3.1          10.01    08/94    the SAG Supplement. In
                                              addition the INET device
                                              emulator must be loaded
                                              before starting SQL Server.
                                              Passed. Known problem: The
           OpenVMS 5.4 +                      SQL Server runs out of AST
           Wollongong       10.01    06/94    quota. This problem has been
                                              reported against Wollongong.
           OpenVMS 5.5-2    10.0     02/94    Passed.
 DEC VAX   OpenVMS 5.5-2    4.9.1             Supported.
                                              Passed. As noted in the
                                              Release Bulletin customers
                                              must install System10 product
           OpenVMS 6.0      10.0     04/94    O/S version 5.4 before
                                              upgrading to OpenVMS 6.0.
                                              VMSINSTALL is not supported
                                              at this OS level.
                                              Passed. Network packages
           OpenVMS 6.1      10.01    01/95    certified: DECnet Phase IV,
                                              UCX 3.2 and Multinet 3.2
                                              Passed, Network packages
           OpenVMS 6.1      4.9.2             certified: DECnet Phase IV,
                                              UCX 3.2 and Multinet 3.2

           DGUX 5.4         4.2               Passed, This does not include
                                              DGUX 5.41 or 5.42
                                              Failed. We recommend upgrade
           DGUX 5.4.2       4.2      10/92    to 4.9 after upgrading O/S to
                                              DGUX 5.4.2
           DGUX 5.4.2       4.9               Passed.
           DGUX 5.4.2.01    10.0              Passed.
           DGUX 5.4R2       4.9.0S            Passed.
 Data
 General   DGUX5.4R2.1      10.0.1            Passed.
           DGUX5.4R2.1      10.0sq            Passed.
                                              Passed. Users with 4-mm and
                                              8-mm tapes must have Rollup
                                              3963 to run this combination.
           DGUX5.4R3.10     10.0.1   11/94    For 8-mm you also need DGUX
                                              patch NSQA-18785-0. See
                                              technical details in the
                                              Release Bulletin for Rollup
                                              3963.
                            4.0.1
 HP300     HP-UX 8.0        10/92
                            Passed.
           HP-UX 8.01       4.2      Passed.
           HP-UX 8.05       4.2               Passed.
           HP-UX 8.05       4.9.1             Passed.
           HP-UX 8.07       4.2      09/92    Passed.
           HP-UX 8.07       4.9               Passed.
           HP-UX 8.07       4.9.1             Passed.
           HP-UX 9.0        4.9.1             Failed.
           HP-UX 9.0.1      10.0     02/94    N/A, no plans to certify.

           HP-UX 9.0.1      4.9.1    03/93    Passed, ASYNC I/O patch
                                              PHKL_2162 is required.

 HP700     HP-UX 9.03       10.01    03/94    Passed.
                                              Passed. Requires HP700
           HP-UX 9.03       4.9.2    03/94    Asynchronous I/O patch#
                                              PHKL_3660
                                              Passed, Requires patch
                                              PHKL_4334 and patch PHKL_4269
           HP-UX 9.05       10.0.1   12/94    - Bug 64656 has been entered
                                              for 'installasync70' script
                                              incompatibility.
                                              Passed, Requires patch
                                              PHKL_4334 and patch PHKL_4269
           HP-UX 9.05       4.9.2    12/94    - Sybase Bugid 64656 has been
                                              entered for 'installasync70'
                                              script incompatibility.
           HP-UX 8.0        4.2               Passed.
           HP-UX 8.0        4.9               Passed.
           HP-UX 8.02       4.9               Passed.
           HP-UX 8.02       4.9.1             Passed.
           HP-UX 8.06       4.9               Passed.
                                              N/A, No plans for
           HP-UX 8.08 BLS                     certification because BLS
           (Secure)         4.9.1             does not support asychronous
                                              I/O.
           HP-UX 8mm tape
           device           10.0     10/94    Passed.
 HP800     HP-UX 9.0                 4.9.1    Passed.
                                              Passed. Bug #41610 reported -
           HP-UX 9.0 using                    'disk init' will only
           LVM              4.9.1    05/93    initialize Logical Volume
                                              devices %lt;= 2GB.
           HP-UX 9.04       10.0     03/94    Passed.
           HP-UX 9.04       4.9.2             Passed.

           HP-UX 9.04                         Passed. Requires Asynch I/O
           using LVM        10.01    10/94    patch PHKL_3624 & LVM Sybase
                                              Mirroring patch PHKL_4418

           HP-UX 9.04                         Passed, Requires Asynch I/O
           using LVM        4.9.2    10/94    patch PHKL_3624 & LVM Sybase
                                              Mirroring patch PHKL_4418
                                              Passed. 4mm 2GB (7206-001)
                                              has full Backup Server
                                              feature support. 4mm 4GB
                                              (7206-005) supports all
           4mm tape device  10.01    11/94    Backup Server features except
                                              the ability to write multiple
                                              file/volume dumps to a single
                                              tape. Bug #63636 has been
                                              entered to track this product
                                              enhancement.
           AIX 3.2          4.2               Passed.

           AIX 3.2.1        4.9.1             N/A, No plans for
                                              certification

           AIX 3.2.2        4.9.1             N/A, No plans for
                                              certification

           AIX 3.2.3e       4.9.1    05/93    Passed. IBM PTF U418109 is
                                              required for AIX 3.2.3e
           AIX 3.2.4        4.9.2    08/93    Passed.
                                              Passed. IBM PTFs (Patches)
           AIX 3.2.5        10.0     02/94    are required for the
                                              following IBM APARs: IX45257,
                                              IX41600, IX38605, IX43714
                                              Passed. IBM PTFs (Patches)
           AIX 3.2.5        4.9.2    12/93    are required for the
                                              following IBM APARs: IX45257,
 IBM                                          IX41600, IX38605, IX43714
 RS6000                                       Passed. IBM PTFs (Patches)
           AIX 3.2.5 +                        are required for the
           PowerPC Chip     4.9.2    12/93    following IBM APARs: IX45257,
                                              IX41600, IX38605, IX43714
                                              Passed. SQL Server EBF 4283
                                              is required. Bugs entered:
                                              sybinit(65590), doc(65603),
                                              connectivity(65807,65 817).
           AIX 3.2.5 -                        PC Windows Net-Library EBF
           SPX/IPX          10.02    01/95    #4316 is required for
                                              connectivity bug #65807. PC
                                              Windows DB-Library (4.2)
                                              based clients can connect to
                                              the UNIX SQL Server.
           AIX 3.2.X SP/1
           SP/2             10.01             Supported.
           AIX 3.2.X SP/1
           SP/2             4.9.2             Supported.
                                              No certification is planned.
                                              A new product release is
           AIX 4.1.1 (SMP)  10.0     01/95    required to support the SMP
                                              version of AIX 4.1.1, planned
                                              for a later date.
                                              Passed. This certification is
           AIX 4.1.1 (UP)   10.01    12/94    based on the uniprocessor
                                              version of the AIX 4.1.1
                                              release.
 ICL DRS
 6000      DRS/NX V7L2      10.0.0            Passed.
 Motorola  SVR4 R$V4.1      10.0.0            Passed.
 NEC       SVR4 R6.1        10.0.1            Passed.
           NetWare v 4.02   10.0.2            Supported.

           Netware 3.1.1 +                    Failed. Severe OS problems
           SFT III          4.2      05/93    were encountered during the
                                              certification.
                                              Passed. This certification
           Netware 386 v                      also includes the maintenance
           3.11             4.2               release of SQL Server 4.2.1 &
                                              4.2.2

           Netware 386 v                      Passed. Requires EBF# 2388.
           3.12             4.2.2    03/94    See release bulletin for NLMs
                                              and versions.
                                              Passed. Requires EBF #2404
           Netware 386 v                      and new CLIB.NLM versions.
           4.0.1            4.2.2    12/93    See ebf coverletter forthe
                                              CLIB.NLM version numbers and
                                              dates.

           Netware 4.0.2    4.2.2    12/94    Passed. Requires EBF 3617 or
 PC                                           higher.
           OS/2 1.2.1       4.2               Passed.
           OS/2 1.3x.x      4.2               Passed.
           OS/2 2.0         4.2               Passed. CSD 6055 recommended
           OS/2 2.1         4.2               N/A, No plans to certify.
           SCO 3.2.4        4.2               Passed.
                                              Passed. Requires Rollup 1980
                                              and SCO SLS patch UOD378a.
                                              Rollup resolves error 611
           SCO 3.2.4.2      4.2      11/93    encountered during testing.
                                              Also includes support for SCO
                                              Open Server Enterprise System
                                              Release 3.0, and SCO Open
                                              Desktop Release 3.0.
                                              Passed, The following
           Windows NT 3.5   10.01    12/94    certification test run
                                              problems have been recorded
                                              in BTS: 64109 & 64110.
 PC SCO    R3.2 V4.2        10.0.1            Passed.
           1.1 93d067       10.0.1            Passed.
 Pyramid N
           94d079           10.0.1            In Progress.
                                              Passed. Binaries built on
                                              Pyramid S/C062 will run on
 Pyramid                                      this OS version, but binaries
 Nile D067                  10.0              built on Pyramid Nile/D067
                                              are not certified to run on
                                              Pyramid ES/C062.
           1.1 93c062       10.0.1            Passed.
           1.1 93c062       4.9.1             Passed.
 Pyramid S SVR4 C034        4.9               Passed.
           SVR4 C044        4.9               Passed.
           SVR4 C062        4.9               Passed.
           5.1a 93a060      4.8               Passed.
 Pyramid T
           OSx 5.1A         4.8               Passed.
 SCO       R3.2 V4.2        10.0.0            Passed.
           DYNIX 1.2        4.8               Passed.
           DYNIX 1.4        4.8      09/92    Passed.
                                              Passed. EBF binaries built on
           DYNIX 2.0        4.8               this OS version will not run
                                              on PTX 1.4 and below.
                                              Passed, EBF binaries built on
 Sequent   DYNIX 2.0.1      4.8               PTX 2.0 and above will not
                                              run on PTX 1.4 and below.
           DYNIX 2.1        4.8               N/A, No plans to certify.
           DYNIX 2.1.0      10.0.0            Passed.
           DYNIX 2.1.0      4.8               Passed.
           DYNIX 4.0        10.0.1            Passed.
           IRIX 3.2         4.0.1             Passed.

 Silicon   IRIX 5.1         10.0              Passed.
 Graphic   IRIX 5.1.1.1     10.0.1            Passed.

           IRIX 5.2         10.0.1   07/94    Passed.
 Sony      NEWS R6.0.1      10.0.1            Passed.
           FTX 2.2.2(y)     10.01             Passed.
 Stratus   VOS 10.5         4.8               Passed.
           VOS 11.6         4.9               Passed.
 Stratus
 68K VOS   VOS 10.5         4.8               Passed.

 Stratus   FTX 2.2.2        10.0              Passed.
 FTX       FTX 2.2.2.3      10.0.1            Passed.

                                              Passed. Requires Rollup 1794
           Solaris 2.2      4.9.1    06/93    or higher and SunOS patches
                                              100999-09 and 101095-01.
           Solaris 2.3      10.00    11/93    Passed.
           Solaris 2.3      4.9.2    12/93    Passed.

           Solaris 2.3 +                      Passed. Required Sun patches:
           SPARCstor        10.0.1   12/94    102198-01 & 102199-02 for use
                                              with Sun's Volume Manager

           Solaris 2.3 +                      Passed, Required Sun patches:
           SPARCstor        4.9.2    12/94    102198-01 & 102199-02 for use
                                              with Sun's Volume Manager
                                              Passed. Requires Rollup 4222.
                                              Bugs entered: sybinit(65592),
                                              doc(65605),
                                              connectivity(65807,65 817).
           Solaris 2.3 +                      PC Windows Net-Library EBF
           SPX/IPX          10.0.2   01/95    #4316 is required for
                                              connectivity bug #65807. PC
                                              Windows DB-Library (4.2)
                                              based clients can connect to
                                              the UNIX SQL Server.
           Solaris
           2.3-A+Edition 1  10.0              N/A, No Plans to certify
           SunOS 4.1.1      4.2               Passed.
           SunOS 4.1.1      4.8               Passed.

           SunOS 4.1.1 +                      Passed. requires SunOS 4.1.1
           DBE 1.1          4.8               patch #100293 or SunDBE 1.1
                                              patch #100322.
           SunOS 4.1.1 +
           DBE 1.1          4.9      02/92    Passed.
           SunOS 4.1.2      4.0.1             Passed.
           SunOS 4.1.2      4.2               Passed.

           SunOS 4.1.2      4.8               Passed. requires SunOS 4.1.2
                                              Kernel patch #100495
 Sun4      SunOS 4.1.2 +
           DBE 1.2          4.2      08/92    Passed.
           SunOS 4.1.2 +
           DBE 1.2          4.9      02/92    Passed.
           SunOS 4.1.2 +
           DBE 1.2          4.9.1             Passed.
           SunOS 4.1.3      4.2               N/A, No plans to certify.

           SunOS 4.1.3      4.8      02/93    Failed. We recommend upgrade
                                              to the 4.9.1 server.
           SunOS 4.1.3      4.9      03/93    Passed.
                                              Passed. requires SunOS 4.1.3
           SunOS 4.1.3      4.9.1    10/92    Sun-4m Supplement patch
                                              #100743-01. Patch is for
                                              multi-processor systems only.
           SunOS 4.1.3 +                      Passed. EBF #4403 is
           DBE 1.3          10.02    02/95    required.
           SunOS 4.1.3 +
           DBE 1.3          4.9               N/A, No plans to certify.
                                              Passed. requires Sun-4m
           SunOS 4.1.3 +                      Supplemental patch
           DBE 1.3          4.9.1    04/93    #100743-01. Patch is for
                                              multi-processors and Sparc 10
                                              systems only.
                                              Passed. requires SunOS 4.1.3
           SunOS                              Sun-4m Supplement patch
           4.1.3/sparc10    4.9.1             #100743-01. Patch for
                                              multi-process systems only.
                                              Passed. The 'X' in 4.1.3X
           SunOS 4.1.3X     10.01    12/94    indicates all of the 4.1.3
                                              based releases. (eg 4.1.3c,
                                              4.1.3.u1, 4.1.3u1b, etc.)
                                              Passed. The 'X' in 4.1.3X
           SunOS 4.1.3X     4.9.2    03/94    indicates all of the 4.1.3
                                              based releases. (eg 4.1.3c,
                                              4.1.3.u1, 4.1.3.u1b).
           SVR4 Ver 1.2     10.0.1            Passed.
 Unisys 65
           SVR4 Ver 1.2     4.9.2             Passed.
 Unisys 75 Dynix 1.3.1      4.8               Passed.
 Unisys
 U6000 75  SVR4 1.3         4.8               Passed.
 Unisys
 U6000/65  SRV4 1.2         4.9.2             Passed.

Bug 61483 - Duplicate Rows in syskeys

Problem

select * from syskeys shows apparent duplicate rows. This should, intheory,
not be possible, since syskeys has a clustered index on it,which should
prevent duplicate rows. These duplicates mean that somestored procedures do
not report errors when they should.

Explanation

When an insert is done to a table on which there is a clustered index, SQL
Server does a byte-by-byte comparison of the entire row. If it finds a
duplicate row, it rejects the insert. SQL Server assumes that the complete
area between the start and the end of the data is valid. This assumption
turns out to be correct for all tables, except syskeys.

The system catalog for syskeys contains a column that can't be displayed,
which contains random or uninitialized data. It is possible for two rows
with identical data in the visible columns to differ in the contents of the
hidden column.

This problem occurs on 4.9.x, 10.0.1, and 10.0.2 SQL Servers.

Solution

You can correct this problem by running a script that exposes the column (it
is called spare1, and is a 2-byte integer column) and binds a default of
zero to it. This prevents any future occurrences; the script also corrects
any existing duplicates in syskeys.

The change made by this script will not break any of the system stored
procedures that refer to syskeys; this is because the default on the new
column ensures that any insert that does not specify the new column gets a
default value of zero.

The script also does sanity checks to see if it has already been run.

The scripts are available as Rollups for the following platforms and
releases:

         Table 4: Rollups correcting bug 61483

 Rollup Number          Platform         Release Number
 3938          SunOS Release 4.x (BSD)   10.0.2
 3939          Sun Solaris 2.x           10.0.2
 3940          HP 9000 Series 300 HP-UX  10.0.2
 3941          AT&T (NCR) System 3000    10.0.2
 3942          IBM RISC System/6000 AIX  10.0.2
 3943          DEC OSF/1                 10.0.2
 3944          SunOS Release 4.x (BSD)   4.9.2
 3945          Sun Solaris 2.x           4.9.2
 3947          HP 9000 Series 300 HP-UX  4.9.2
 3948          AT&T (NCR) System 3000    4.9.2
 3949          IBM RISC System/6000 AIX  4.9.2
These scripts are available only as controlled releases. Many customersare
not doing operations that directly involve syskeys, and SybaseEngineering
prefers that the problem be sorted out for youtransparently on upgrade to
10.0.3. If you cannot wait, however, Sybasehas provided the script as a
Rollup that you can order from TechnicalSupport.

In order to minimize confusion, the scripts are all the same and
willautomatically sort out differences between the SQL Server
releases.Release 10.0.2 will run against all 10.0.1 P2 and 10.0.2 SQL
Servers.

For Windows NT, Novell NetWare, and other PC platforms, there are norecorded
instances of this problem.
----------------------------------------------------------------------------

Disclaimer: No express or implied warranty is made by SYBASE or its
subsidiaries with regard to any recommendations or information presented in
SYBASE Technical News. SYBASE and its subsidiaries hereby disclaim any and
all such warranties, including without limitation any implied warranty of
merchantability of fitness for a particular purpose. In no event will SYBASE
or its subsidiaries be liable for damages of any kind resulting from use of
any recommendations or information provided herein, including without
limitation loss of profits, loss or inaccuracy of data, or indirect special
incidental or consequential damages. Each user assumes the entire risk of
acting on or utilizing any item herein including the entire cost of all
necessary remedies.

Staff

Principal Editor: Leigh Ann Hussey Contributing Writers:
Lance Anderson, Paul Dow, Ken Duffy, Aimee Grimes, Joseph Hui, Greg Klinder,
Andrzej Sarapuk, Gerald Soulos, Loretta Vibberts, Rob Weaver, Elton
Wildermuth

Send comments and suggestions to:

SYBASE Technical News
6475 Christie Avenue
Emeryville, CA 94608

or send mail to technews@sybase.com

Copyright 1996  Sybase, Inc. All Rights Reserved.
                                   Q10.2.3

               Technical News Volume 4, Number 3, August 1995

This issue of the SYBASE Technical News contains new information about your
SYBASE software. If needed, duplicate this newsletter and distribute it to
others in your organization. All issues of the SYBASE Technical News and the
Troubleshooting Guides are included on the AnswerBase CD.

To receive this document by regular email, send name, full internet address
and customer ID to technews@sybase.com.

IN THIS ISSUE

   * Technical Support News/Features
        o OpenLine News
        o Technical Support North American Holidays
        o Sybase Character Sets CD-ROM Available
   * SQL Server
        o Performance Tip for Inserts with Non-Unique Clustered Indexes
        o How to Read syscolumns.status
        o Patches Required to Run SQL Server 10.0.2 with DEC OSF/1 Version
          3.0
        o Additional Information for 1605 Workaround
        o DBCC LOG with truncate log set Raises Spurious 813 and 605 Errors
        o Two New HP Patches for SQL Server 10.0.1
        o Enabling Asynchronous I/O for HP-UX 10.0
        o Moving Log Off a Device
        o Query to List All Objects & Sizes on Segment
        o How to Read SQL Server Version Strings
        o Generating Templates for Non-interactive Install with ^W
        o Optimizer Frequently Asked Questions
        o Currently Supported Backup Server Devices
   * Connectivity / Tools / PC
        o MS Access Errors with Intersolv Sybase System 10 ODBC Driver
        o Workaround for non-char NULLs in OmniSQL Server
        o Dynamic Parameter Markers in Embedded SQL
   * Certification and Fixed Bug Reports
        o Bug 69427 - sp_rename Syntax
        o Bugs 31229 and 58701 - sp_addmessage
        o SQL Server 4.9.2 EBFs 4152 and 4659 and Bugs 54367 and 68128
        o Connectivity Documentation Corrections
        o Latest Rollups for SQL Server 4.9.2
        o Bugs Fixed in Latest Rollup, SQL Server 4.9.2
        o Latest Rollups for SQL Server 10.0.2
        o Bugs Fixed in Latest Rollup, SQL Server 10.x

OpenLine News

On April 5th, Sybase OpenLine on CompuServe unveiled a new section called
"EBF EXPRESS." This section allows customers with current support contracts
who have licensed Sybase PC Client products to view the latest EBF Cover
Letters and download the latest EBFs for those products. The sections
covered are:

 Status Section Number  Section Name           Description
 open   23              PC Client     Windows, DOS, OS/2 Client EBFs
 soon   22              Novell        Novell Workgroup Server EBFs
 soon   21              NT            NT Server EBFs
 planned20              UnixWare

Note: if this does not appear as a table to you, you may want to start using
the Netscape browser.

The sections are accessible by application only. Sybase OpenLine members may
download the file called ACC-23.APP in the General Technical (#1) library,
fill it out, and return it to the SysOp via CompuServe Mail. Applications
are usually processed the same day, but allow 24 to 48 hours for a response
by CompuServe Mail.

There is also a corresponding message base for EBF EXPRESS to report
problems or ask questions about the EBFs or Cover Letters.

The Sybase OpenLine Team is pleased to be able to offer a new level of
self-sufficiency to our customers through EBF EXPRESS; we have already
received very positive comments about the service!

As of April 10th, over 19,400 CompuServe members have joined the Sybase
OpenLine forum, and over 28,700 messages have been posted (a rate of about
72 per workday). There are over 1,200 technical tips and informational files
in the Sybase OpenLine libraries; over 106,900 downloads have been recorded.
Sybase OpenLine continues to be a great tool for networking with other
Sybase customers, analysts, consultants, and employees to solve customer
problems.

To join CompuServe, in the United States call (800) 848-8990; outside the
U.S., dial (+1) 614-529-1340

To join the Sybase OpenLine Forum, type:

GO SYBASE

Questions about the Sybase OpenLine forum or EBF Express may be addressed
to: Perry Bent, 73321.374@compuserve.com

Technical Support North American Holidays

Sybase Technical Support is open on all holidays and provides full service
on many holidays. On the holidays shown below, Technical Support provides
limited service. During limited-service holidays, the following Technical
Support coverage will be provided:

   * SupportPlus Preferred and Advantage Customers may log all cases;
     priority 1 and 2 cases will be worked on over the holiday.
   * 24x7 and 24x5 Support Customers may log priority 1 (down server) cases
     which will be worked on over the holiday.
   * SupportPlus Standard, Desk Top, and Regular Support Customers may
     purchase Extended-hour Technical Support for coverage over the holiday.

       Sybase Technical Support
    limited-service holidays - U.S.
               customers

       Holiday             Date
 New Year's Day       January 2
 President's Day      February 20
 Memorial Day         May 29
 Independence Day     July 4
 Labor Day            September 4
 Thanksgiving         November 23
 Christmas            December 25

       Sybase Technical Support
  limited-service holidays - Canadian
               customers

        Holiday              Date
 New Year's Day          January 2
 Good Friday             April 14
 Victoria Day            May 22
 Canada Day (observed)   June 30
 Labour Day              September 4
 Canadian Thanksgiving   October 9
 Christmas Day           December 25
 Boxing Day              December 26

Sybase Character Sets CD-ROM Available

The Sybase Character Sets CD-ROM provides new character sets and sort order
files that enable SQL Server to handle data in 26 different character sets.
This new product allows you to create applications in your local language(s)
and handle them correctly from a cultural and lexical point of view.

One or more sort order files are provided for use with each character set,
allowing you to correctly sort the data in your SYBASE database. In
addition, the character sets are compatible with the automatic character set
conversion feature available in SYBASE SQL Server(&trade;) release 10.0.2
and later.

The initial release of the Sybase Character Sets CD-ROM contains character
sets for the following regions and languages:

   * Arabic
   * Chinese (Simplified and Traditional)
   * Cyrillic (Russian and other Cyrillic-based languages)
   * Central and Eastern European
   * Greek
   * Hebrew
   * Japanese
   * Korean
   * Turkish
   * Western European

The product order number for the Sybase Character Sets CD-ROM is
10490-55-0100-41.

Frequently Asked Questions

Question: Are JLE and KLE supported?

Answer: Yes. The Sun Japanese Language Environment (JLE) and Sun Japanese
Feature Package (JFP) are supported by the eucjis character set. The Sun
Korean Language Environment (KLE) and Sun Korean Feature Package (KFP) are
supported by the eucksc character set.

Question: I thought Sybase already supported Chinese--why do I need this
product too?

Answer: The Chinese character sets provided on the Sybase Character Sets
CD-ROM provide a more robust support for both traditional and simplified
Chinese character sets than has been possible in the past using the ascii_8
character set. For example, pattern matches using the like SQL statement on
multibyte characters are now handled properly.

Question: What are the disk and RAM requirements?

Answer: The entire content of the CD-ROM is less than 6MB. A typical user
will install only a few of the character sets and sort orders, requiring
only five or six files. A small amount (one to five 2K pages) of additional
memory may be required when moving from ascii_8 to an Asian character set.
In most cases, the additional memory use is insignificant.

Question: What SQL Server versions support Sybase Character Sets?

Answer: The character sets and sort orders are supported on any System 10
server. However, code set conversions for these new character sets are only
supported in SQL Server 10.0.2 or later.

Question: What standards were used to create the character sets and sort
orders?

Answer: Character sets are standardized by organizations such as the
International Standards Organization (ISO), national bodies such as the
Arabic Standards and Metrology Organization (ASMO) and the Hellenic
Organisation for Standardization (ELOT), and software vendors. Each
character set description file references the organizational standard or
vendor standard on which it is based.

Performance Tip for Inserts with Non-Unique Clustered Indexes

In order to avoid hotspots on tables, many customers choose a clustered
index that will spread inserts across data pages, instead of adding all of
them on the last page. When this index is non-unique, you can achieve a
significant performance benefit by adding an IDENTITY column to the index
and making it unique.

Example

This example was tested using SQL Server 10.0.2 on an HP9000 E-Series
machine:

        create table nu
        (       spid            smallint        not null
        ,       something       float           not null
        )
        go
        create unique clustered index nu_ix on nu (spid, spreader)
        go

Two stored procedures were written to insert records.

        create proc insert_nu
        (       @count          int)
        as
        begin
                declare @tmp int
                select @tmp = 0
                while @tmp < @count
                begin
                        insert into nu (spid, something, padding)
                        values (@@spid, @count, " ")
                        select @tmp = @tmp + 1
                end
        end
        go

        create proc insert_u
        (       @count          int)
        as
        begin
                declare @tmp int
                select @tmp = 0
                while @tmp < @count
                begin
                        insert into u (spid, something, padding)
                        values (@@spid, @count, " ")
                        select @tmp = @tmp + 1
                end
        end
        go

Both tables were populated with 5000 records.

Test #1

One process performing 5000 inserts:

   * Non-unique index: 5 minutes, 14 seconds
   * Unique index: 12 seconds

Test #2

Two concurrent processes, each performing 5000 inserts:

   * Non-unique index:
        o Process 1: 9 minutes, 53 seconds
        o Process 2: 9 minutes, 42 seconds
   * Unique index:
        o Process 1: 20 seconds
        o Process 2: 21 seconds

How to Read syscolumns.status

Question

How is the status column used in the syscolumns table, what does it mean,
and what are its possible values?

Answer

Here is a sample of output containing syscolumns.status:

     1> select name, status from syscolumns where id=object_id("tab1")
     2> go
      name                            status
      ------------------------------  ------
      pub_id                               0
      pub_name                             8
      city                                 8
      state                                8
      bio                                  0

According to the header file that defines syscolumns:

   * Bits 0 - 2 indicate bit position in a byte (bit 0 - 7).
        o If you have bit columns in your table, as many as 8 of them will
          share the same offset, because 8 bits fit in a byte. The status
          column lets SQL Server find the actual position of those bits in
          that byte.
   * Bit 3 is set if NULL is allowed in this column.
        o If status contains an 8, this column allows NULL.
   * Bit 4 is set if there is more than one check constraint on the column.
        o If status contains a 16, this column has more than one check
          constraint. SQL Server stores the first check constraint in
          syscolumns.domain, but if there's a second one, SQL Server simply
          notes that fact by setting the status bit.

Patches Required to Run SQL Server 10.0.2 with DEC OSF/1 Version 3.0

There are two sets of official operating system patches required in order to
run SQL Server 10.0.2 for DEC OSF/1v3.0 (product ID 19555).

You must request these patches from Digital. V3.0 and V3.0b require
different sets of patches. The newly shipped V3.2 does not need any patches.

   * DEC patches for V3.0
        o OSFV30-068-2
        o OSFV30-094-1
   * DEC patches for V3.0b
        o OSFV305-068-1
        o OSFV305-094-1

     ------------------------------------------------------------------
     Note: Patch OSFV30-094-1 (for V 3.0) is required for all
     multiprocessor machines, machines running SYBASE database
     applications, and all machines using the "ITIMER_VIRTUAL" timer
     kernel feature. Without this patch various panics may occur, the
     most likely of which is: "simple_lock: time limit exceeded".

     The problem happens because multiple Asynchronous System Traps
     (AST) functions are mapped to the same bits of the AST dispatch
     field in the process control block (PCB). The fix removes the
     collision of bit usages for ASTs.

     ------------------------------------------------------------------

You must rebuild your kernel after installing these patches.

Additional Information for 1605 Workaround

Question

The SQL Server Error Messages manual describes a workaround for Error 1605
that involves an adjustment to cnsocket. After using those instructions, I
got the following error message in the SQL Server error log:

     00:95/04/13 19:58:51.91 kernel  kiconfig: configured number of
     processes (60) is insufficient for kernel disk and network
     processes (1032 needed).

What is going on here?

Answer

SQL Server administrators configure SQL Server through the sp_configure
stored procedure and the buildmaster -y mechanism. Many of the parameters in
buildmaster -y are direct copies of parameters displayed by sp_configure.
Some values in buildmaster -y are calculated (cnsocket), while others are
preset "at the factory" (cschedspins).

In certain situations, the values computed for the calculated configuration
values are incorrect and lead to errors during startup or operation of SQL
Server.

For SQL Server to accept a connection it must have:

   * An available network socket
   * An available "sybase kernel process," also called a "task"

cnsocket defines the maximum number of network sockets SQL Server may have
open at one time. This value is further constrained by the limitations of
the operating system. Each network socket requires a file descriptor from
the operating system. SQL Server automatically sets cnsocket to the maximum
number of file descriptors allowed if you try to set cnsocket to a value
greater than the maximum number of file descriptors allowed.

cnsocket is calculated as:

     cnsocket = cusrconnections + cfgsitebuf + XTRA_SOCKETS;

where

   * cusrconnections - number of configured user connections
   * cfgsitebuf - number of connections reserved for site handlers
   * XTRA_SOCKETS - extra connections for utility sorts of things (for
     example, network listeners)

cnproc defines the maximum number of SYBASE kernel tasks that can run at a
time. cnproc is calculated as:

     cnproc = cnsocket + 6 + (number of network types)

where

   * cnsocket - as calculated above
   * 6 - magic number; extra processes that do not require network
     connections (for example, checkpoint)
   * number of network types - number of network listeners

If, during SQL Server startup, cnproc is less than the expected value, you
get the error message shown above.

This means SQL Server will run out of SYBASE kernel tasks (set at 60) before
it runs out of sockets (set at about 1032).

     ------------------------------------------------------------------
     Note: The processes referred to in the SYBASE kernel message above
     refer to SYBASE SQL Server kernel processes (tasks), not operating
     system processes. Changing the operating system nproc won't solve
     the problem.

     nproc is not a configuration value in all operating systems, but
     is common enough that some may confuse it with cnproc in the
     SYBASE configuration. The operating system kernel is not the SQL
     Server kernel.
     ------------------------------------------------------------------

cnsocket and cnproc should be configured to values appropriate for the
number of concurrent connections required in your SQL Server. You are not
expected to set this value, and any calculated value that you set by hand
may be lost if you do a reconfigure command.

Adjusting cnsocket is really a workaround; using buildmaster -ycnsocket
should not actually be necessary. Sybase Technical Support has logged a bug
(#70028) to change the way the "reconfigure" code and the startup code
adjust these parameters.

SYBASE Technical News will keep you informed of any new developments in this
matter.

DBCC LOG with truncate log set Raises Spurious 813 and 605 Errors

As an addendum to the article in SYBASE Technical News, Volume 4, Number 2,
concerning dump transaction failing to truncate the log, customers should be
aware that the use of dbcc log in databases with the dboption truncate log
on checkpoint set can result in spurious 813 and 605 errors.

To avoid this, turn off truncate log on checkpoint before you run dbcc log.

Two New HP Patches for SQL Server 10.0.1

The certification report in SYBASE Technical News, Volume 4, Number 2,
reported under "HP-UX 9.0.4 using LVM with SQL Server 10.0.1," that two
patches were required. These have been superseded, as follows:

   * Patch PHKL_3624 has been superseded by PHKL_5139
   * Patch PHKL_4418 has been superseded by PHKL_5394

This change is reflected in the current certification report.

Enabling Asynchronous I/O for HP-UX 10.0

Question

I have upgraded to HP-UX 10.0, and wish to enable asynchronous I/O in order
to run SQL Server, but the installasync80 script is only for HP-UX 8 and 9.
Does a script exist for this new version, or must I configure asynchronous
I/O manually?

Answer

You need to order EBF 4605 from Sybase Technical Support. This EBF contains
both a new asynchronous I/O driver, as well as a fix for the problem of the
Backup Server not recognizing non-rewinding tape devices.

Moving Log Off a Device

Question

I need to have one of my users change the device that the log is on, but I
am not sure of the appropriate procedure.

The sysusages looks like this:

   1> select * from sysusages where dbid=db_id("user_db")
   2> go

   dbid   segmap    lstart    size     vstart    pad  unreservedpgs
   ------ --------- --------- -------- --------- ---- -------------
        7        3         0   51200   83887104  NULL         3800
        7        3     51200   20480   83963904  NULL        20480
        7        4     71680    4096   83984384  NULL         4088
        7        4     75776   10240  151006208  NULL        10240

From this it appears that the user built the database as follows:

   create database user_db on dev1 = 100,
                        dev1 = 40
                 log on dev1 = 8

(using the with override option if using System 10, since in System 10 you
cannot by default create a database with its log on a device that has data
allocation) and then gave the command:

   alter database user_db log on dev2 = 20 mb

Answer

The desired end result is not clear. If you simply want to have the log on a
separate device with no change in the amount of allocation for that
database, then follow these steps:

  1. Execute sp_dropsegment to get the log segment off dev1.
  2. Execute sp_extendsegment to put system and default segments onto the 8
     MB of dev1 previously used for the log. You need to do this, because if
     there are any pages still allocated for the log on that device, you
     will get misleading information from sp_helplog, which checks on the
     location of the log's first page.
  3. Make some changes within the database, such as an insert of some dummy
     records. This puts some log records on at least one page of dev2 which
     is now the one and only log device. Note that dev2 is a dedicated log
     device, as indicated by the segmap value of 4.
  4. Execute dump transaction with truncate_only.

Query to List All Objects and Sizes on a Segment

Question

Is there a way to list all the objects on a segment and the amount of space
they use on that segment by a query against system catalogs?

Answer

Use the following query:

   select object=o.name, 'index'= i.indid, segment=s.name,
    size=reserved_pgs(i.id, i.doampg) + reserved_pgs(i.id, i.ioampg)
   from sysobjects o, syssegments s, sysindexes i
   where o.id = i.id
     and s.segment = i.segment
   order by s.name, o.name, i.indid
   compute sum(reserved_pgs(i.id, i.doampg) + reserved_pgs(i.id, i.ioampg))
   by s.name

Size is reported by this query in pages; see the "System Functions" section
of Chapter 2, "Transact-SQL Functions", in Volume 1 of the SQL Server
Reference Manual for more details about the reserved_pgs function.

To restrict the query to a given segment or object, add that segment or
object to the where clause. Also, this query does the compute sum by
segment, not by object and segment; to change to by object and segment, add
o.name to the by clause.

     ------------------------------------------------------------------
     Note: Because syslogs (object 8) has no object allocation map
     (OAM), the system function reserved_pgs() looks for it explicitly,
     and the query as written will return double the actual size of the
     log segment. For all other objects, the size value returned by
     this query is correct.
     ------------------------------------------------------------------

How to Read SQL Server Version Strings

Question

The dataserver, backupserver, and isql binaries return version information
when executed with a -v flag. What do the different fields mean? For
example, in UNIX:

   /usr/sybase/bin/dataserver -v

   SQL Server/4.9.2/EBF 1795 Rollup/Sun_svr4/OS 5.1/1/OPT/Fri Jul 30
   20:01:16 PDT 1993

   /usr/sybase10/bin/dataserver -v

   SQL Server/10.0/P/Sun_svr4/OS 5.2/1/OPT/Thu Sep 23 12:28:52 PDT 1993

   /usr/sybase10/bin/backupserver -v

   Backup Server/10.0.2.1/P/Sun4/4.1.x/EBF 4009/OPT/Tue Nov 15 14:27:37
   PST 1994

   /usr/sybase10/bin/isql -v

   isql/10.0/P/sun_svr4/Solaris 2.2/1/Mon Aug 30 12:11:43 PDT 1993

Or on VAX:

   server :== $sybase_system:[sybase.bin]dataserver.exe
   server/version

   SQL Server/4.9.2/P/VMS/5.4-1A+/1/OPT/28-JUN-1993 18:37:38.53

Answer

The fields, in order, are:

  1. Product
  2. Release number
  3. Release type: production (P), beta, or EBF version
  4. Platform identifier
  5. Operating system version under which the binary was compiled. This
     number is hard coded; products do not look it up from your OS.
  6. "Build number"; a SYBASE internal reference only
  7. Mode: optimized or debug
  8. Compilation date and time

Generating Templates for Non-interactive Install with ^W

Question

I am installing a large number of identical release 10.x SQL Servers at my
branch offices. What is the easiest way to do this?

Answer

Once you have configured one SQL Server using an interactive sybinit
session, you may dump the attributes out to a file, which you can then edit
to suit each individual site.

Go through a full interactive configuration session using sybinit, so that
each of the nine steps on the screen are marked "Complete":

        SQL SERVER CONFIGURATION
        1.  CONFIGURE SERVER'S INTERFACES FILE ENTRY      Complete
        2.  MASTER DEVICE CONFIGURATION                   Complete
        3.  SYBSYSTEMPROCS DATABASE CONFIGURATION         Complete
        4.  SET ERRORLOG LOCATION                         Complete
        5.  CONFIGURE DEFAULT BACKUP SERVER               Complete
        6.  CONFIGURE LANGUAGES                           Complete
        7.  CONFIGURE CHARACTER SETS                      Complete
        8.  CONFIGURE SORT ORDER                          Complete
        9.  ACTIVATE AUDITING                             Complete

At this prompt:

        Enter the number of your choice and press return:

type Ctrl-w, and the prompt line will change to look like this:

Enter the number of your choice and press return: Dump out current attributes?y

"y" is the default, so just hit return, and you'll be prompted for a file
name; you can either enter a new one or accept the default.

Once you have this resource file, consult Appendix A, "sybinit Resource
Files", of the SYBASE SQL Server Installation Guide for your platform, for
information on how to use it for future, non-interactive installations. You
will need to edit some of the attributes, as the appendix instructs.

Generate a second resource file for your Backup Server(&trade;), if you wish
to handle Backup Server installation similarly.

Optimizer Frequently Asked Questions

Question

I've heard that the optimizer works out the cost, on the fly, of actually
producing the best plan, as well as the cost of getting the data. Once the
cost of actually working out the best plan becomes greater than the cost of
performing the data access from the best plan found so far, it stops
optimizing.

Therefore, if it costs the optimizer 1 CPU second to determine that a given
plan will require 1/2 CPU second, it stops optimizing, since 1 is bigger
than 1/2, even though a plan it hadn't yet analyzed might require only 1/4
CPU second.

Is this true?

Answer

The SYBASE optimizer does not work like this, though a competitor's does.
There are very good reasons not to optimize this way:

   * Queries that are in stored procedures and triggers get optimized once
     and executed many times. For example:
       1. Optimizer takes 1 second to find best query plan, which takes 0.1
          seconds to execute.
       2. Optimizer takes 1/2 second to find a sub-optimal query plan, which
          takes 1/2 second to execute. Scenario 1 will take 1.1 seconds if
          it is executed once, while scenario 2 will take 1 second. But if
          the query is in a stored procedure that is executed 1000 times,
          scenario 1 will take 101 seconds, while scenario 2 will take 500.5
          seconds.
   * The competitor's method limits the time the optimizer spends analyzing
     different query plans depending on the load on the server and the
     machine. If the machine is heavily loaded, the optimization process
     takes longer and looks at fewer query plans before giving up. Thus, the
     heavier the load, the worse the query plan, which is exactly the
     opposite of what you want.

Question

Isn't it the case that, once the number of tables in a join exceeds four,
the optimizer starts taking short cuts and will not evaluate all the
possible plans? If so, is it a good idea to write my query with the
"driving" tables first, when a query has a large number of joins?

Answer

Changing the order of the tables in the from clause will normally have no
effect on the query plan.

When you have more than four tables in the from clause, the optimizer will
optimize each subset of four tables. Then it remembers the outer table from
the best plan involving four tables, eliminates it from the set of tables in
the from clause, and optimizes the best set of four tables taken out of the
remaining tables. It continues with this until there are only four tables
remaining, at which point it optimizes those four tables normally.

For example, suppose you have a select with the following from clause:

        FROM T1, T2, T3, T4, T5, T6

The optimizer looks at all sets of four tables taken from these six tables.
The sets are:

        T1, T2, T3, T4
        T1, T2, T3, T5
        T1, T2, T3, T6
        T1, T2, T4, T5
        T1, T2, T4, T6
        T1, T2, T5, T6
        T1, T3, T4, T5
        T1, T3, T4, T6
        T1, T3, T5, T6
        T1, T4, T5, T6
        T2, T3, T4, T5
        T2, T3, T4, T6
        T2, T3, T5, T6
        T2, T4, T5, T6
        T3, T4, T5, T6

For each one of these combinations, it looks at all the join orders
(permutations). For example, the join orders for T2, T3, T5, T6 are:

        T2, T3, T5, T6
        T2, T3, T6, T5
        T2, T5, T3, T6
        T2, T5, T6, T3
        T2, T6, T3, T5
        T2, T6, T5, T3
        T3, T2, T5, T6
        T3, T2, T6, T5
        T3, T5, T2, T6
        T3, T5, T6, T2
        T3, T6, T2, T5
        T3, T6, T5, T2
        T5, T2, T3, T6
        T5, T2, T6, T3
        T5, T3, T2, T6
        T5, T3, T6, T2
        T5, T6, T2, T3
        T5, T6, T3, T2
        T6, T2, T3, T5
        T6, T2, T5, T3
        T6, T3, T2, T5
        T6, T3, T5, T2
        T6, T5, T2, T3
        T6, T5, T3, T2

The optimizer remembers the best of all the join orders, for all the
combinations. Let's say that the best join order is:

        T5, T3, T6, T2

Once the optimizer has figured this out, it remembers the outer table of
this join order (T5) as the outermost table in the whole query. It
eliminates this table from consideration as it chooses the rest of the join
order. Now it has to decide where T1, T2, T3, T4, and T6 will go in the rest
of the join order. It looks at all the combinations of four tables chosen
from these five:

        T1, T2, T3, T4
        T1, T2, T3, T6
        T1, T2, T4, T6
        T1, T3, T4, T6
        T2, T3, T4, T6

It looks at all the join orders for each of these combinations. It remembers
that T5 is the outer table in the join when it makes this decision. Let's
say that the best join order is T3, T6, T2, T4. It remembers T3 as the next
table after T5 in the join order for the entire query, and eliminates it
from consideration as it chooses the rest of the join order. The remaining
tables are:

        T1, T2, T4, T6

Now there are only four tables, so it looks at all the join orders for all
the remaining tables. Let's say the best join order is:

        T6, T2, T4, T1

This means that the join order for the entire query is:

        T5, T3, T6, T2, T4, T1

Note that the four outermost tables are not the first four tables in the
from clause. As you can see, even though the optimizer looks at the join
orders for only four tables at a time, doing this for all combinations of
four tables taken out of the from clause makes the order of tables in the
from clause irrelevant.

There is only one known circumstance in which the order of tables in the
from clause can make any difference: if the optimizer comes up with the same
cost estimate for two join orders, it will choose the first of the two join
orders that it encounters. The order of tables in the from clause affects
the order in which the optimizer evaluates the join orders, so in this one
case, table order can have an effect on the query plan.

Currently Supported Backup Server Devices

As of April 26, 1995, the following devices are supported by Backup Server:

     ------------------------------------------------------------------
     Note: this article has been removed from the Web version of
     Technical News in favor of your checking out this much more
     frequently-updated table provided by Lance Andersen.
     ------------------------------------------------------------------

MS Access Errors with Intersolv Sybase System 10 ODBC Driver

Question

I'm using the Intersolv Sybase System 10 ODBC driver with a Windows PC
client. When I try to set up a new data source, edit an existing one, or
edit a connection to a database within Microsoft Access, I get the following
error:

     The setup routines for the INTERSOLV Sybase System 10 ODBC driver could
     not be loaded. You may be low on memory and need to quit a few
     applications.

What can I do?

Answer

This error is misleading. It doesn't usually have anything to do with
memory, but instead happens when wsybset.bat has not been run. wsybset.bat
sets up the correct paths to the Sybase 10.0.x Open Client (&trade;) Dynamic
Load Libraries (DLL) wcslib.dll and wctlib.dll.

It can also happen if the path to the ODBC driver, QESYB06.dll, is not set
up. This is because when the ODBC driver gets set up, it sets a DLL name in
the odbc.ini file for the control panel application to use. Then, when
Windows tries to load the DLL, it fails if the program or any DLLs needed by
that program cannot be loaded. Lack of memory can cause this, as the message
suggests, or it can occur because Windows cannot find one or more of the
DLLs.

Windows looks for DLLs by searching the current directory, then the
WINDOWS/SYSTEM directory, and finally the path. If either the SYBASE DLL
directory or the Intersolv DLL directory is not in the path, you will see
this message.

Refer to your operating system manual for further instructions on how to set
paths.

Workaround for non-char NULLs in OmniSQL Server

Question

I have a problem with OmniSQL Server(&trade;). I'm going to DB2, but the
problem could appear for any source. Omni SQL Server, as it is based on
C-ISAM files, does not support NULLs for anything other than character
fields. So this query:

        SELECT mydatefield FROM mytable

produces correct answers, but this one:

        SELECT mydatefield FROM mytable ORDER BY ...

produces the value of "1 Jan 1900" for any NULL dates. The difference is
that OmniSQL Server is producing a worktable (in C-ISAM) to perform the
order by. Is there a workaround for this?

Answer

Yes. You must create an Open Server(&trade;) gateway that sits in front of
Omni. The client's requests are passed up to OmniSQL Server unchanged, but
any "1/1/1900" dates are changed to NULL on the way back down.

This workaround will be unnecessary when OmniCONNECT release 10.5 (formerly
known as OmniSQL Server) is available, because at that point Sybase plans to
replace C-ISAM with SQL Server-style storage structures.

The code for this Open Server is easily produced. Add the following code to
the gateway Open Server sample file, $SYBASE/sample/srvlibrary/ctosdemo.c,
to the row processing in gw_procrows() (about line 4297):

    if((fmtp[i].datatype == CS_DATETIME_TYPE) &&
       (fmtp[i].status & CS_CANBENULL       )   )
   {
    if (0==dp[i][0])
    if (0==dp[i][1])
    if (0==dp[i][2])
    if (0==dp[i][3])
    if (0==dp[i][4])
    if (0==dp[i][5])
    if (0==dp[i][6])
    if (0==dp[i][7])
     ind[i]=CS_NULLDATA;
   }
   if((fmtp[i].datatype == CS_DATETIME4_TYPE) &&
      (fmtp[i].status & CS_CANBENULL        )   )
   {
    if (0==dp[i][0])
    if (0==dp[i][1])
    if (0==dp[i][2])
    if (0==dp[i][3])
     ind[i]=CS_NULLDATA;
   }

The code could be extended in many ways, for example to perform srv_props()
for NUM_CONNECTIONS and other variables.

Note that this code does not handle NULLable numeric values.

Dynamic Parameter Markers in Embedded SQL

The following addition will shortly be appearing in the Release Bulletin for
all Embedded SQL products:

When processing an Embedded SQL query, SQL Server determines the datatype of
each dynamic parameter marker by examining the marker's context-where the
marker is used in the query. An Embedded SQL query must not contain a
dynamic parameter marker in a position that can cause SQL Server to
determine that the marker's datatype is text or image.

Bug 69427 - sp_rename Syntax

If you have both a table column and an index with the same name, and execute
the command sp_rename `table.column/index', newname, sp_rename will always
rename the column. You cannot rename the index directly in this case.

This problem, that the syntax is the same for renaming a column or index,
has been filed as bug 69427; SYBASE Technical News will keep you abreast of
its progress.

Bugs 31229 and 58701 - sp_addmessage

Two bugs have recently been reported against sp_addmessage:

Bug 31229

If you specify us_english as the language parameter to sp_addmessage, the
langid column of sysusermessage gets set to NULL. A later retrieval via
sp_getmessage without a language specified (where the session is using
us_english) fails to find the message.

The problem is that there are two legal values for langid that represent
us_english: 0 and NULL. @@langid will always return 0, while sp_addmessage
and sp_getmessage set langid to NULL if the user specified us_english
directly to the procedure.

Bug 58701

A related problem reported under bug 58701 resulted in a change to the
procedure sp_addmessage for the 10.0.2 maintenance release.

The problem is that sp_addmessage inserts a value of 0 into langid instead
of NULL when using us_english.

Apparently the change required to fix this bug has caused bug 31229 to
appear again. If a message is added with sp_addmessage and no language is
specified, later attempts to get that message with sp_getmessage will fail
with error 17202, "Message number nn does not exist in the language
language."

To work around these bugs, manually update rows in sysusermessages, setting
langid values from NULL to 0.

SQL Server release 4.9.2 - EBFs 4152 and 4659 and Bugs 54367 and 68128

Some customers have encountered problems on SQL Server 4.9.2 that can be
resolved by the fix for bug 54367. This fix has been released in two
different modes, however, which may confuse some customers. A customer who
received EBF 4152 in order to obtain the fix for bug 54367 may find the EBF
4659 seems to no longer address the problem. Here's why:

EBF 4152 (and related EBFs for non-Sun4 platforms) was a recent 4.9.2
rollup, containing a fix for bug 54367. For reasons unrelated to this bug
fix, shipment was stopped for EBF 4152.

EBF 4659 is the replacement EBF for the 4152 rollup. It also contains a fix
for bug 54367-but this fix is not identical to the fix in EBF 4152. The
difference between the two fixes is that, with EBF 4659, trace flag 299 must
be turned ON in order to activate the fix. This feature was added to EBF
4659 under the fix for bug 68128. If this trace flag is not turned on, EBF
4659 behaves just like all pre-4152 releases of the 4.9.2 codeline (except
for a few EBFs that contain a fix for bug 54367).

You should find similar behavior in the following cases:

   * EBF 4152
   * EBF 4659 with trace flag 299 turned on

At this time, there is no plan to modify the 4.9.2 codeline to apply the fix
for bug 54367 without invoking trace flag 299, because this fix also incurs
a small, but possibly significant, amount of processing overhead. Since most
customers do not require this fix, Sybase decided to make application of the
fix optional, and to put control over whether or not it is applied in the
customer's hands, with a trace flag.

     ------------------------------------------------------------------
     Note: A problem similar to bug 54367 was reported against System
     10 under bug 55952. A fix for this problem is contained in the
     10.0.2 release. An additional fix has been made recently to the
     System 10 codeline to mitigate some of the performance and
     contention problems caused by the fix for bug 55952. This problem
     and fix is reported under bug 65416. There is no 299 trace flag in
     the System 10 releases. The fixes are always active.
     ------------------------------------------------------------------

Connectivity Documentation Corrections

Embedded SQL Documentation Bugs

   * 48379: The Open Client Embedded SQL Reference Manual now indicates that
     the parameter list for the statement declare cursor for execute
     stored_procedure must be enclosed in parentheses. The correct syntax
     is:

           exec sql
             declare cursor_name cursor for
             execute procedure_name ([[@param =]:hv]
             [,[@param =]:hv]...)

   * 49230: In the Open Client Embedded SQL Reference Manual, the SET
     DESCRIPTOR example has been corrected: The lines beginning "value 1,"
     "value 2," and "value 3" were previously inverted. They now read as
     follows:

           exec sql prepare get_royalty
             from "select royalty from roysched
             where title_id = ? and lorange <= ? and
             hirange > ?";
           exec sql allocate descriptor roy_desc with max 3;
           exec sql set descriptor roy_desc
             value 1 data = :tid;
           exec sql set descriptor roy_desc
             value 2 data = :sales;
           exec sql set descriptor roy_desc
             value 3 data = :sales;
           exec sql execute get_royalty into :royalty
             using sql descriptor roy_desc;

   * 53686: In the Open Client Embedded SQL Reference Manual, a misspelled
     keyword has been corrected in two commands-declare cursor(dynamic) and
     declare cursor(static). The correct spelling is "read only" (two words,
     instead of one).

   * 57291: In Table 2-3 of the Open Client Embedded SQL Reference Manual,
     each value under the heading "CLIENT-LIBRARY CODE" has been decremented
     by one. That is, -8 is now -9; -9 is now -10, and so on. (Note: The
     values under the heading "CODE" are not affected.)
     That part of the table is now as follows:
      SYBASE-DEFINED DATATYPECLIENT-LIBRARY CODE

      smalldatetime          -9
      money                  -10
      smallmoney             -11
      text                   -3
      image                  -4
      tinyint                -8
      binary                 -5
      varbinary              -6
      longbinary             -7
      longchar               -2
   * 56472: On page 6-17 of the Open Client Embedded SQL/COBOL Guide, the
     code fragment now reads:

             exec sql include "myfile" end-exec.

     The argument "myfile" must be enclosed in quotation marks.

   * 52189: In the Open Client Embedded SQL/C Guide and Open Client Embedded
     SQL/COBOL Guide, the cancel statement has been added to the list (p.
     1-7) of Embedded SQL statements not supported in System 10.

   * 59348: In the Open Client Embedded SQL/C Guide and Open Client Embedded
     SQL/COBOL Guide, the descriptions of the sqlwarn flags (capitalized
     SQLWARN in COBOL) have been corrected.
     The sqlwarn (SQLWARN) flags are as follows:
        sqlwarn     SQLWARN
        Flag, C   Flag, Cobol                  Description
                               If blank, no warning condition of any kind
                               occurred, and all other sqlwarn flags are
      sqlwarn[0]  SQLWARN[1]   blank. If sqlwarn[0](C) or SQLWARN[1](Cobol)
                               is set to "W", one or more warning
                               conditions occurred, and at least one other
                               flag is set to "W".
                               If set to "W", the character string variable
                               that you designated in a fetch statement was
                               too short to store the statement's result
      sqlwarn[1]  SQLWARN[2]   data, so the result data was truncated. You
                               designated no indicator variable to receive
                               the original length of the data that was
                               truncated.
                               If set to "W", the input sent to SQL Server
                               contained a NULL value in an illegal
      sqlwarn[2]  SQLWARN[3]   context, such as in an expression or as an
                               input value to a table that prohibits null
                               values.
                               The number of columns in a select
      sqlwarn[3]  SQLWARN[4]   statement's result set exceeds the number of
                               host variables in the statement's into
                               clause.
      sqlwarn[4]  SQLWARN[5]   Reserved.

      sqlwarn[5]  SQLWARN[6]   SQL Server generated a conversion error
                               while attempting to execute this statement.
      sqlwarn[6]  SQLWARN[7]   Reserved.
      sqlwarn[7]  SQLWARN[8]   Reserved.

Client-Library Documentation Bugs

   * 67847: The Open Client Client-Library/C Reference Manual gives the
     following misleading and incorrect statement in the "Security Features"
     topics pages, under the heading, "Encrypted Password Security
     Handshakes":

          "Most applications are not aware of SQL Server's password
          encryption because Client-Library automatically handles it."

     The "Properties" topic page, under "Security Encryption
     (CS_SEC_ENCRYPTION", will now say:

          "Applications which require password encryption must enable
          the CS_SEC_ENCRYPTION connection property. The default is
          CS_FALSE, which disables password encryption."

     For most applications, this is all that is required for password
     encryption-Client-Library has a default handler that performs the
     encryption expected by SQL Server.

     Applications in the following categories need to define and install an
     encryption handler (in addition to setting the property) to perform
     password encryption:
        o Open Server gateways
        o Clients which connect to an Open Server application that performs
          some customized form of password encryption

     The code fragment below enables password encryption:

               CS_BOOL boolval;
               /*
               ** Enable password encryption for the connection
               ** attempt.
               */
               boolval = CS_TRUE;
               if (ct_con_props(conn, CS_SET,
                               CS_SEC_ENCRYPTION,
                               (CS_VOID *)&boolval,
                               CS_UNUSED,(CS_INT *)NULL)
                   != CS_SUCCEED)
               {
                 fprintf(stdout,
                   "ct_con_props(SEC_ENCRYPTION) failed. Exiting\n"
                         );
                 (CS_VOID)ct_con_drop(conn);
                 (CS_VOID)ct_exit(ctx, CS_FORCE_EXIT);
                 (CS_VOID)cs_ctx_drop(ctx);
                 exit(1);
               }

     An example gateway encryption handler can be found in the Open Server
     sample program ctosdemo.c.

   * 66733: The issue of dynamic SQL vs. stored procedures has been
     clarified with an example. The Open Client Client-Library/C Reference
     Manual, in the "Dynamic SQL" topic page section, "Alternatives to
     Dynamic SQL," will include the following updated information:

     Dynamic SQL and application stored procedures offer identical
     functionality except that:
        o Stored procedures offer no direct means to get a description of
          input parameter formats. Dynamic SQL allows the application to
          request a description of prepared statement input from the remote
          server.
        o Stored procedures offer no direct means to get a description of
          their output, unless you execute them and incur any side effects.
        o Stored procedures are not automatically dropped when their creator
          logs off the remote server. Prepared dynamic SQL statements
          created within a SQL Server login session are automatically
          deallocated at the end of the session.

     They offer identical functionality in that any prepared dynamic SQL
     statement can be implemented as a stored procedure which returns the
     same set of results (plus the procedure return status result). For
     example, the following dynamic SQL statement queries the pubs2..titles
     table for books of a certain type in a certain price range:

               select * from titles
                   where type = ?
                   and price between ? and ?

     Here, the dynamic SQL statement has dynamic parameter markers (?) for a
     type value and two price values. An equivalent stored procedure could
     be created as follows:

               create proc titles_type_pricerange
                 @type char(12),
                 @price1 money,
                 @price2 money
               as
                 select * from titles
                   where
                      type = @type
                      and price between @price1 and @price2

     When executed with the same input parameter values, the prepared
     statement and the stored procedure will return the same rows. In
     addition, the stored procedure will return a return status result.

   * 60116: Documentation has been added to state that Client-Library cannot
     be run in asynchronous mode inside an Open Server, only in synchronous
     or deferred mode. The Open Client Client-Library/C Reference Manual
     "Properties" topic page, under "Network I/O (CS_NETIO)," and the
     "Asynchronous Programming" topic page, will include the following
     information (The Open Server Server-Library/C Reference Manual already
     notes the fact in the "Gateway Applications" topic page):

          The CS_NETIO property cannot be set to CS_ASYNC_IO when
          Client-Library is used with Open Server. Open Server is
          multi-threaded and the thread scheduler provides concurrency
          among multiple threads.

   * 66860: Documentation has been added to show how ct_cursor can be used
     to execute a stored procedure containing only one statement, a select.
     It is not possible to get return status. The Open Client
     Client-Library/C Reference Manual, ct_cursor Reference Page, section
     "Client-Library Cursor Declare," will include the following
     information:

          Here's an example of creating a Client-Library execute
          cursor. Please note the restrictions listed below the
          example.

          The following pseudocode declares an execute cursor on the
          stored procedure title_cursor_proc:

                      ct_cursor (cmd, CS_CURSOR_DECLARE,
                          "mycursor", CS_NULLTERM,
                          "exec title_cursor_proc", CS_NULLTERM,
                          CS_UNUSED);
                      ct_send(cmd);

          In this case, the body of the cursor is the text that makes
          up the stored procedure. The stored procedure text must
          contain a single select statement only. In the example above,
          title_cursor_proc could be created as:

                    create proc title_cursor_proc as
                        select * from titles for read only

          A stored procedure used with an execute cursor must consist
          of a single select statement. The stored procedure's return
          status is not available to the client program. Output
          parameter values are also not available to the client
          program.

   * 59290: Documents now clarify that ct_options(CS_OPT_GETDATA) should not
     be used. The Open Client Client-Library/C Reference Manual, "Options"
     topic page and ct_options reference page, will include the following
     updated information:

          Don't use ct_options(CS_OPT_GETDATA). This option is for
          Sybase internal use only.

   * 70692: The Open Client Client-Library/C Reference Manual, "Properties"
     topic page, section "Cursor Status" (CS_CUR_STATUS) and ct_cmd_props()
     reference page, will include the following updated information:

          The CS_CUR_STATUS property value is either:
             o CS_CURSTAT_NONE to indicate no cursor exists on the
               command structure.
          or
             o A bit-masked status value for an existing cursor. The
               value is composed of the status bit-masks
               CS_CURSTAT_CLOSED, CS_CURSTAT_DECLARED,
               CS_CURSTAT_RDONLY, CS_CURSTAT_UPDATEABLE.
          The meanings of these are correctly described under "Cursor
          Status" in the "Properties" topic page.

          The following code fragment illustrates use of the cursor
          status property to display the status of the Client-Library
          cursor (if any) declared on a command structure:

                  #define RETURN_IF(a,b) if (a != CS_SUCCEED)\
                    { fprintf(stderr, "Error in: %s line %d\n", \
                              b, __LINE__); return a ;}
                  /*
                  ** cursor_status() -- Print status information about the
                  **   Client-Library cursor (if any) declared on a CS_COMMAND
                  **   structure.
                  **
                  ** PARAMETERS:
                  **   cmd -- an allocated CS_COMMAND structure.
                  **
                  **
                  ** RETURNS
                  **   CS_FAIL if an error occurred.
                  **   CS_SUCCEED if everything went ok.
                  */
                  CS_RETCODE
                  cursor_status(cmd)
                  CS_COMMAND *cmd;
                  {
                    CS_RETCODE ret;
                    CS_INT     cur_status;
                    CS_INT     cur_id;
                    CS_CHAR    cur_name[CS_MAX_NAME];
                    CS_CHAR    updateability[CS_MAX_NAME];
                    CS_CHAR    status_str[CS_MAX_NAME];
                    CS_INT     outlen;
                    /*
                    ** Get the cursor status property.
                    */
                    ret = ct_cmd_props(cmd, CS_GET, CS_CUR_STATUS, &cur_status,
                                       CS_UNUSED, (CS_INT *) NULL);
                    RETURN_IF(ret, "cursor_status: ct_cmd_props(CUR_STATUS)");
                    /*
                    ** Is there a cursor?
                    ** Note that CS_CURSTAT_NONE is not a bit mask, but the
                    ** other values are.
                    */
                    if (cur_status == CS_CURSTAT_NONE)
                      fprintf(stdout,
                         "cursor_status: no cursor on this command structure\n");
                    else
                    {
                      /*
                      ** A cursor exists, so check its state. Is it
                      ** declared, opened, or closed?
                      */
                      if ((cur_status & CS_CURSTAT_DECLARED)
                          == CS_CURSTAT_DECLARED)
                        strcpy(status_str, "declared");
                      if ((cur_status & CS_CURSTAT_OPEN) == CS_CURSTAT_OPEN)
                        strcpy(status_str, "open");
                      if ((cur_status & CS_CURSTAT_CLOSED) == CS_CURSTAT_CLOSED)
                        strcpy(status_str, "closed");
                      /*
                      ** Is the cursor updateable or read only?
                      */
                      if ((cur_status & CS_CURSTAT_RDONLY) == CS_CURSTAT_RDONLY)
                        strcpy(updateability, "read only");
                      else if ((cur_status & CS_CURSTAT_UPDATABLE)
                               == CS_CURSTAT_UPDATABLE)
                        strcpy(updateability, "updateable");
                      else
                        updateability[0] = '\0';
                      /*
                      ** Get the cursor id.
                      */
                      ret = ct_cmd_props(cmd, CS_GET, CS_CUR_ID, &cur_id,
                                         CS_UNUSED, (CS_INT *) NULL);
                      RETURN_IF(ret, "cursor_status: ct_cmd_props(CUR_ID)");
                      /*
                      ** Get the cursor name.
                      */
                      ret = ct_cmd_props(cmd, CS_GET, CS_CUR_NAME, cur_name,
                                         CS_MAX_NAME, &outlen);
                      RETURN_IF(ret, "cursor_status: ct_cmd_props(CUR_NAME)");
                      /*
                      ** Null terminate the name.
                      */
                      if (outlen < CS_MAX_NAME)
                        cur_name[outlen] = '\0';
                      else
                        RETURN_IF(CS_FAIL, "cursor_status: name too long");
                      /* Print it all out                                     */
                      fprintf(stdout, "Cursor '%s' (id %d) is %s and %s.\n",
                              cur_name, cur_id, updateability, status_str);
                    }
                    return CS_SUCCEED;
                  } /* cursor_status */

CS-Library Documentation Bug

   * 64520: The documentation and examples for callback error handling have
     been improved. The Common Libraries Reference Manual chapter,
     "Introducing CS-Library" and the cs_config reference page, will include
     the following information:

          Here is a CS-Library error handler:

                  /*
                  **  cslib_err_handler() - CS-Library error handler.
                  **
                  **   This routine is the CS-Library error handler used by this
                  **   application. It is called by CS-Library whenever an error
                  **   occurs. Here, we simply print the error and return.
                  **
                  **  Parameters:
                  **    context
                  **      A pointer to the context handle for context
                  **      in which the error occurred.
                  **    error_msg
                  **      The structure containing information about the
                  **      error.
                  **
                  **  Returns:
                  **      CS_SUCCEED
                  */
                  CS_RETCODE CS_PUBLIC cslib_err_handler(context, errmsg)
                  CS_CONTEXT    *context;
                  CS_CLIENTMSG  *errmsg;
                  {
                    /*
                    ** Print the error details.
                    */
                    fprintf(stdout, "CS-Library error: ");
                    fprintf(stdout, "LAYER = (%ld) ORIGIN = (%ld) ",
                            CS_LAYER(errmsg->msgnumber),
                            CS_ORIGIN(errmsg->msgnumber) );
                    fprintf(stdout, "SEVERITY = (%ld) NUMBER = (%ld)\n",
                            CS_SEVERITY(errmsg->msgnumber),
                            CS_NUMBER(errmsg->msgnumber) );
                    fprintf(stdout, "\t%s\n", errmsg->msgstring);
                    /*
                    ** Print any operating system error information.
                    */
                    if( errmsg->osstringlen > 0 )
                    {
                      fprintf(stdout, "CS-Library OS error %ld - %s.\n",
                              errmsg->osnumber, errmsg->osstring);
                    }
                    /*
                    ** All done.
                    */
                    return (CS_SUCCEED);
                  } /* cslib_err_handler */

          Here is the code to install it:

                    /*
                    ** Install the function cslib_err_handler as the
                    ** handler for CS-Library errors.
                    */
                    if (cs_config(context, CS_SET, CS_MESSAGE_CB,
                                  (CS_VOID *)cslib_err_handler,
                                  CS_UNUSED, NULL)
                        != CS_SUCCEED)
                    {
                      /* Release the context structure.      */
                      (void)cs_ctx_drop(context);
                      fprintf(stdout,
                        "Can't install CS-Lib error handler.\
                        Exiting.\n");
                      exit(1);
                    }

     The error severities are the same as those explained in the Open Client
     Client-Library/C Reference Manual, on the "Client-Library Messages"
     topic page.

Bulk Library Documentation Bugs

   * 69977: The documentation has been clarified to specify that only one
     CS_BLKDESC or one CS_COMMAND can be active on a connection at one time.
     The Common Libraries Reference Manual, blk_init reference page, will
     say:

          Multiple CS_BLKDESC and CS_COMMAND structures can be exist on
          the same connection, but only one CS_BLKDESC or CS_COMMAND
          structure can be active at once.
             o A bulk-copy operation begun with blk_init must be
               completed before the connection can be used for any
               other operation.
             o A bulk-copy operation can not be started when the
               connection is being used to initiate, send, or process
               the results of other Client-Library or Bulk-Library
               commands.

   * 69153: Documentation has been added on how Bulk Library errors are
     handled. The Common Libraries Reference Manual chapter, "Introducing
     Bulk Copy", will say:

          Bulk-Library errors are reported as Client-Library errors for
          Client-Library bulk-copy routines and as Server-Library
          errors for Server-Library bulk-copy routines. Server-Library
          routines are those routines that take a SRV_PROC pointer as
          an argument.

          Client applications should handle Bulk-Library errors by
          installing a Client-Library error handler or handle them
          inline with ct_diag(). Applications should also install a
          remote server message handler, because errors detected by the
          SQL server will be reported as server messages.

          To handle Bulk-Library errors, Open Server gateway
          applications should install a Server-Library error handler in
          addition to the handlers listed above.

EBF News

The following tables list the latest rollup numbers for SQL Server 4.9.2 and
10.x on selected platforms, and selected bugs fixed in them.

Latest Rollups for SQL Server 4.9.2

             Platform             Rollup Number
 SunOS Release 4.x (BSD)          4659
 HP 9000 Series 800 HP-UX         4660
 IBM RISC System/6000 AIX         4661
 AT&T System 3000 UNIX SVR4 MPRAS 4662
 Digital OpenVMS VAX              4663
 Sun Solaris 2.x                  4664
 Digital OpenVMS Alpha 1.5        4665
 Digital OpenVMS Alpha 1.0        2121

Bugs Fixed in Latest Rollup, SQL Server 4.9.2

This list is additive, that is, only the bugs fixed in the latest series of
rollups are included. Please see SYBASE Technical News, Volume 4, Number 1,
for the list of earlier bugs fixed.

    Bug
  Number                              Description
           Reverse the behavior of 299 trace flag (trigger recompilation of
 68128     stored procedures) for temporary table schema changes only if
           command line trace flag 299 is set.
           The "dbqual" in DB-Library returns NULL for where clause in
           browse mode, because SQL Server sends the wrong table number in
 67868     the TDS stream. This could cause data inconsistency because
           update/insert might affect the wrong rows due to a NULL where
           clause.
           Subquery in select list raises multiple results instead of
 54376     raising an error (depending on if this is deemed a legal syntax,
           docs aren't clear) that either the subquery in the select list
           is illegal or Error 512 (multiple results).

Latest Rollups for SQL Server 10.0.2

             Platform             Rollup Number
 SunOS Release 4.x (BSD)          4009
 HP 9000 Series 800 HP-UX         4010
 IBM RISC System/6000 AIX         4011
 AT&T System 3000 UNIX SVR4 MPRAS 4012
 Digital OpenVMS VAX              4013
 Sun Solaris 2.x                  4014
 Digital OpenVMS Alpha 1.5        4015
 Digital OSF/1                    4019
 NetWare                          none
 OS/2                             none
 Windows NT                       4996

Bugs Fixed in Latest Rollup, SQL Server 10.x

There has been no change in this list since SYBASE Technical News, Volume 4,
Number 1.

----------------------------------------------------------------------------

Disclaimer: No express or implied warranty is made by SYBASE or its
subsidiaries with regard to any recommendations or information presented in
SYBASE Technical News. SYBASE and its subsidiaries hereby disclaim any and
all such warranties, including without limitation any implied warranty of
merchantability of fitness for a particular purpose. In no event will SYBASE
or its subsidiaries be liable for damages of any kind resulting from use of
any recommendations or information provided herein, including without
limitation loss of profits, loss or inaccuracy of data, or indirect special
incidental or consequential damages. Each user assumes the entire risk of
acting on or utilizing any item herein including the entire cost of all
necessary remedies.

Staff

Principal Editor: Leigh Ann Hussey

Contributing Writers:

Lance Andersen, Perry Bent, Chris Curvey, Sandra Dellafiora, Jennifer Doman,
Peter Dorfman, Roy Halbreich, Dan Haywood, Marcus Jordan, Greg Klinder, Jeff
Lichtman, Rosemary Morrison, Greg Roody, Marc Sugiyama, Loretta Vibberts,
Rob Weaver, Robert Weeks, Elizabeth Whitehouse, Elton Wildermuth

For more info send email to techpubs@sybase.com
Copyright 1995  Sybase, Inc. All Rights Reserved.
                                   Q10.2.4

              Technical News Volume 4, Number 4, November 1995

This issue of SYBASE Technical News contains new information about your
SYBASE software. If needed, duplicate this newsletter and distribute it to
others in your organization. All issues of SYBASE Technical News and the
troubleshooting guides are included on the AnswerBase CD.

To receive this document by regular email, send name, full internet address
and customer ID to technews@sybase.com.

IN THIS ISSUE

   * Tech Support News/Features
        o Technical Support Holiday Schedule for Q4 `95
   * SQL Server
        o System 11 Subquery Processing Performance Improvements
        o Tuning to Prevent Time-Slice Errors
        o 605 Errors on load database master
        o System Database Recovery in System
        o Understanding sysusages.unreservedpgs
        o Understanding Spinlocks
        o Patches for Hard / Transient 605 Errors on HP
   * Connectivity / Tools / PC
        o Localization Problems and cs_ctx_alloc Failure
        o End-of-Life Plan for APT and DWB
   * Certification and Fixed Bug Reports
        o Mainframe EBF Information
        o Net-Gateway EBF Information
        o Bug 69332: Timeslice Disables Automatic Checkpoint and waitfor
          Command

Technical Support Holiday Schedule for Q4 `95

Sybase Technical Support is open on all holidays and provides full service
on many holidays. On the holidays shown below, Technical Support provides
limited service. During limited-service holidays, the following Technical
Support coverage will be provided:

   * SupportPlus Preferred and Advantage Customers may log all cases;
     priority 1 and 2 cases will be worked on over the holiday.
   * 24x7 and 24x5 Support Customers may log priority 1 (down server) cases
     which will be worked on over the holiday.
   * SupportPlus Standard, Desk Top, and Regular Support Customers may
     purchase Extended-hour Technical Support for coverage over the holiday.

       Sybase Technical Support
    limited-service holidays - U.S.
               customers

      Holiday             Date
 Labor Day          September 4
 Thanksgiving       November 23
 Christmas          December 25

       Sybase Technical Support
  limited-service holidays - Canadian
               customers

        Holiday              Date
 Labour Day              September 4
 Canadian Thanksgiving   October 9
 Christmas Day           December 25
 Boxing Day              December 26

System 11 Subquery Processing Performance Improvements

For System 11, the query processor was substantially rewritten, in order to
meet the following goals:

   * Solve subquery performance problems in System 10(TM)
   * Solve subquery correctness problems in System 10
   * Maintain compatibility with existing views and procedures

System 10 Performance Issues

System 10 used two subquery processing strategies, "inside-out" and
"unnest." In the "inside-out" strategy, SQL Server(TM) built the subquery
result set first, then joined it with the outer query. In the "unnest"
strategy, SQL Server changed the subquery to an existence join. The
following performance issues existed as a result of these strategies:

   * The "inside-out" processing strategy gave good throughput (length of
     time it takes SQL Server to get to the last row of a query), but poor
     response time (length of time it takes SQL Server to return the first
     row of a query).
   * "Inside-out" processing required two joins: one to form the subquery
     result and one for the outer result.
   * If there was a restrictive join in an outer query, the result set for a
     subquery could be bigger than necessary.
   * Internal use of the group by all clause forced an extra pass over the
     grouping table.
   * A join with a subquery result could not be optimized if the subquery
     was part of an or clause, because of the resulting cartesian product.

System 10 Correctness Issues

There were several known problems in System 10 having to do with nulls,
empty tables, and duplicates, none of which were easy to fix under the
"inside-out" system.

Problems Solved by System 11

In System 11, subqueries are now modeled as nested loops, which has the
added advantage of matching the ISO/ANSI definition of subqueries. Some
unnesting can take place, in the form of flattening to joins and
materialization. Unflattened subqueries are treated as expressions in this
system.

There is no need to build the entire subquery result set up front; subquery
results are only calculated when necessary, so that there is no more
assembling of subquery results that end up not being used. Likewise, there
is no longer a need to join subquery results back to the outer query. All of
this results in better response time.

A few other features also improve performance:

   * Quantified predicates no longer use group by all
   * Subqueries in or clauses no longer use non-optimized joins
   * Some not in and all subqueries are optimized better

Correctness problems also go away with the new system, because the
processing closely matches the ANSI-standard SQL definition.

Performance Enhancements

The new system uses several performance enhancements:

   * "Short circuiting"

     In "short circuiting," evaluation of and lists stops early if any part
     is false, and evaluation of or lists stops early if any part is true.
     where clauses are automatically shuffled to put the subquery at the
     end, forestalling unnecessary execution of subqueries. For example, the
     following query:

             select a from t
             where NOT EXISTS
               (select * from s
                where b=t.c)
             AND d=2

     is transformed to:

             select a from t
             where d=2
             AND NOT EXISTS
               (select * from s
                where b=t.c)

     In this case, the subquery will not execute for rows in t where d is
     not equal to 2.

   * Better flattening

   * More efficient materialization

   * Caching

     An in-memory cache is used for subqueries that are not flattened or
     materialized. This cache stores the result values for previous
     executions of the subquery; values in the correlation columns of
     subsequent executions are used as look-up keys for the cache. The cache
     starts off big and shrinks to the appropriate size depending on the
     cache hit rate. Caching improves performance in cases where there are
     duplicates in correlation columns, especially when the values are
     ordered.

   * Elimination of sort for distinct expression queries

     In System 10, select distinct subqueries forced SQL Server to perform a
     sort step to eliminate duplicates; in the new system, no such step is
     used. Instead, SQL Server uses a special system-internal aggregate,
     once unique, to raise an error if more than one distinct value is
     encountered. Eliminating the sort step saves time.

View materialization has been made more efficient for views containing
aggregates.

Tidbits and New Features

The following limitations have been removed:

   * distinct and group by not allowed in same query
   * Correlation column and noncorrelation column not allowed on the same
     side of an equal sign.

showplan output has been made more readable and has been enhanced to show:

   * Line numbers to help locate statements in query text
   * Subquery numbers and nesting levels for each subquery's plan
   * Type of subquery
   * Where each subquery is nested
   * Types of scans
   * Index coverage
   * Index keys used to limit scan
   * Worktable numbers
   * Clustered index name

The sort step for distinct will no longer be necessary in some cases where
there is an index on the selected columns.

Effects for the User

Some subqueries, in and exists for example, will continue to perform as they
have for you in the past. On the other hand, some subqueries, especially not
in, not exists, all, and subqueries in or clauses, will perform considerably
better. For almost all non-flattened subqueries, you will see improved
response time.

One final advantage to the new system is that it leaves more leeway for
future performance improvements. SYBASE Technical News will keep you
informed of further progress in this area as it is made.

Tuning to Prevent Time-Slice Errors

If you have stored procedures that take a long time to complete, you may
have encountered the time-slice error, where SQL Server kills the running
process, sometimes shutting down with a stack trace in the error log. In
order to prevent this from happening, you can tune certain SQL Server
configuration parameters, but there are risks involved with each along with
the benefits.

Understanding Timeslice Errors

To make the most informed decision on configuration tuning, first you have
to understand what causes timeslice errors. Each task on your system gets a
fixed period of CPU time, called a time slice. During this timeslice, the
task is expected to complete a "unit" of work and then yield the CPU.
Sometimes, the task will not complete all its work in one time slice; in
this case, if the task does not volunteer to be put to sleep so that another
task can run, SQL Server will allot it one more amount of time to complete.

SQL Server is non-preemptive, which means that if a process fails to
complete, even with the extra time allotted, SQL Server will simply kill the
process rather than putting it on hold to give another process to the CPU.
This is the time-slice error.

In SQL Server releases 4.9.x and 10.x, the time-slice value is specified by
the buildmaster parameter ctimeslice and the extra time value by the
parameter ctimemax; in System 11, the time slice and extra time values are
part of the flat configuration file mentioned elsewhere in this issue.

When Timeslice Causes SQL Server Crash

There are hard-coded yields written into some of SQL Server's own most
CPU-consuming functions. This gives the scheduler a chance to reset and give
the process another chunk of time once the process queue is empty. If the
queue is not empty, a process with a yield coded into it will yield
voluntarily and SQL Server will not kill it.

If there is no yield coded into a SQL Server function holding a spinlock,
SQL Server will write the kernel error "timeslice -201" to the error log and
kill itself, resulting in a server crash with stack trace. Sybase
Engineering can sometimes use this stack trace to determine where in the
dataserver code it would be useful to insert a yield statement. To help
Engineering in this process, if you are getting SQL Server crashing with
time-slice errors, you should collect several such stack traces so that they
can better pinpoint the best yield location.

Time-Slice Errors on User Applications

More commonly, it is a user application, stored procedure, or query that
gets the time-slice error. In this case, SQL Server kills the offending
process but does not crash.

Reading the Timeslice Error Message

While a task is running, the scheduler counts down the amount of time that
the process has been running in ticks. The number of milliseconds
represented by each tick is platform-dependent; you can check how many
milliseconds SQL Server thinks a tick is by entering the command select
@@timeticks. In SQL Server releases prior to and including 10.x, the
buildmaster parameter cclkrate defines this number. On most systems, the
value for cclkrate is rounded to the nearest 10,000. On some systems, the
value is rounded to the nearest 1,000,000, or one second.

Both ctimeslice and ctimemax (and their equivalent entries in the System 11
configuration file) are defined in ticks. A value of 1 for ctimeslice is
equivalent to 1 tick. If cclkrate is set to 100,000 ctimeslice, this means
that a process will get a timeslice of 1/tenth of second. If ctimemax is set
to 200 ticks, the process will then get another 20 seconds of time on the
CPU (100,000 milliseconds * 200 = 20 seconds).

In the time-slice error message,you will see a negative number, for example:

   00:95/07/16 01:54:08.94 kernel  timeslice -3601, current process
   infected

This is the total number of ticks that the process accumulated on the CPU
during this one "trip" before being terminated (ctimeslice + ctimemax). When
this combined value is exceeded, the timeslice error is generated,
indicating that SQL Server has infected the process preparatory to killing
it.

Parameter Tuning

From the above information, you may have deduced that if you increase
ctimeslice and ctimemax, you will experience fewer time-slice errors. This
is, in fact, the case, but there are two risks that you must take into
account before you decide to increase those values:

   * Increasing ctimeslice and ctimemax means that a process will run for
     the full time allotted without yielding, and will hold up other
     processes. The result is that, without any message to the user, SQL
     Server will come to an apparent halt for the full span of ctimeslice +
     ctimemax.
   * More seriously, increasing ctimeslice and ctimemax to fend off
     time-slice errors may mask a deeper SQL Server problem.

Bearing these in mind, then, the way to adjust the two parameters is as
follows:

For release 10.x and earlier, the buildmaster commands are:

        buildmaster -yctimeslice=value_in_ticks

        buildmaster -yctimemax=value_in_ticks

When System 11 is released, these will be the commands:

        sp_configure "time slice", value_in_milliseconds

        sp_configure "cpu grace time", value_in_milliseconds

Note that unlike the earlier parameters, these are valued in milliseconds
rather than ticks. You must have the "sa" role to change these parameters.
It is theoretically possible to set ctimemax to some very high value, say
1,000, but you must decide for yourself if the benefits of having no
timeslice errors outweigh the possible performance degradation. We recommend
that you leave these values at the default unless you are getting time-slice
errors. If you are seeing these sorts of problems, you can tinker with the
timeslice and grace time (timemax) values to find the best balance of
performance and time- slice error avoidance for your site.

605 Errors on load database master

When you attempt to load a dump of your master database and get a 605 error,
check the sysusages table. It may be that the sysusages entries for master
are different between the dump and the database into which you are loading.

Overview

If sysusages.vstart values don't match between the dump and the recieving
database, SQL Server will raise a 605 error. You can either reconstruct
sysusages through a sequence of create database and alter database commands,
or you can follow the process outlined in the "System Database Recovery"
chapter of the SQL Server Troubleshooting Guide for rebuilding the master
database when no valid dump exists.

Technical Details

For example, say that the command select * from sysusages on your SQL Server
gives the following output:

 dbid   segmap     lstart    size      vstart      pad    unreservedpgs
 ------ ---------- --------- --------- ----------- ------ -------------
      1          7         0      1536           4   NULL             0
      1          7      1536      1024        7172   NULL             0
      2          7         0      1024        2564   NULL           672
      2          4      1024       512   134217728   NULL           512
      2          7      1536       512   117441024   NULL           512
      3          7         0      1024        1540   NULL           664
      3          3      1024       512   117440512   NULL           512
      4          7         0      6144    16777216   NULL          1528
      5          7         0      5120    33554432   NULL          NULL
      5          4      5120      2560    50331648   NULL          NULL
      6          7         0      1024        3588   NULL           648
      7          7         0      1024        4612   NULL           528
      8          7         0      1024    67108864   NULL             0
      8          3      1024      3072    67109888   NULL             0
      8          4      2560      1024    83886080   NULL             0
      9          7         0      1536   100663296   NULL          1176
     10          7         0      1536        5636   NULL          1184
     11          7         0      1536   100664832   NULL          1176
(18 rows affected)

In the above output, lstart is the starting location of the logical page.
Logical pages in the database are numbered starting at 0, in an unbroken
stream. They are mapped to actual storage through the vstart values; virtual
pages are coded structures containing the device number and the page number
offset on the device. The mapping occurs like this:

  1. SQL Server, looking for a particular page number (for example, 2000),
     selects the lstart closest to but not greater than that number (say,
     1536).
  2. SQL Server subtracts the selected lstart number from the number of the
     page it is looking for; this is how far away that page is from the
     start of the disk piece where it is stored.
  3. SQL Server adds that difference to vstart, then masks off the device
     number encoded in vstart. The resulting value is the page offset from
     the actual starting address on the device.
  4. Finally, SQL Server multiplies that offset by the size of a Sybase page
     to get the location where it should actually start reading.

The device number, as already mentioned, is encoded in vstart; dividing
vstart by 2**24 gives the device number. You can use the following query to
look at all objects on the master device (device number 0):

        1> select * from sysusages
        2> where vstart/power(2,24) = 0
        3> order by vstart
        4> go

Here is an example of output from that query:

 dbid   segmap     lstart    size      vstart      pad    unreservedpgs
 ------ ---------- --------- --------- ----------- ------ -------------
      1          7         0      1536           4   NULL           208
      3          7         0      1024        1540   NULL           664
      2          7         0      1024        2564   NULL           664
      6          7         0      1024        3588   NULL           648
      7          7         0      1024        4612   NULL           528
     10          7         0      1536        5636   NULL          1184
      1          7      1536      1024        7172   NULL          1024

(7 rows affected)

sysusages shows that usage on the master device is arranged as shown in
Figure 1.:



vstart    0   4          1540    2564    3588    4612    5636       7172    8196
size      |   |    3mb    |  2mb  |  2mb  |  2mb  |  2mb  |   3mb    |  2mb  |
          .....................................................................
dbid      |   |     1     |   3   |   2   |   6   |   7   |   10     |   1   |
          |   |           |       |       |       |       |          |       |
lstart    |   | 0 - 1535  |0-1023 |0-1023 |0-1023 |0-1023 | 0 - 1535 |1536-  |
          |   |           |       |       |       |       |          |2559   |
          |...|...........|.......|.......|.......|.......|..........|.......|.
device
fragment    1       2         3       4       5       6        7         8

lstart = logical page number
                                   Fig. 1

In the master database (dbid = 1), whenever a page is requested, for example
(logical page number) 1536, sysusages is used to convert this page number's
lstart into the corresponding vstart.

        1> select vstart = vstart + 1536 - lstart
        2> from sysusages
        3> where dbid = 1
        4> and lstart <= 1536
        5> and size > 1536 - lstart
        6> go

         vstart
         -----------
                7172

Then SQL Server accesses the next 2048 bytes, starting at vstart=7172,
considering them as logical page 1536.

When you run dump database master, all allocated pages between lstart = 0
through 2559 or between vstart = 4 through 1539 and 7172 through 8195 are
copied to the dump device.

Suppose that after the dump you execute buildmaster to create new master,
model, and tempdb databases. sysusages now looks like this:

        1> select * from sysusages
        2> where vstart/power(2,24) = 0
        3> order by vstart
        4> go

 dbid   segmap     lstart    size      vstart      pad    unreservedpgs
 ------ ---------- --------- --------- ----------- ------ -------------
      1          7         0      1536           4   NULL           208
      3          7         0      1024        1540   NULL           664
      2          7         0      1024        2564   NULL           664

The layout for the master device is shown in the following figure.

vstart    0   4          1540    2564    3588
size      |   |    3mb    |  2mb  |  2mb  |
          .....................................................................
dbid      |   |     1     |   3   |   2   |
          |   |           |       |       |
lstart    |   | 0 - 1535  |0-1023 |0-1023 |
          |   |           |       |       |
          |...|...........|.......|.......|....................................

                          Fig. 2

Figure 3 shows the layout after you an alter database master to add 2MB.:

vstart    0   4          1540    2564    3588    4612
8196
size      |   |    3mb    |  2mb  |  2mb  |  2mb  |
          .....................................................................
dbid      |   |     1     |   3   |   2   |   1   |
          |   |           |       |       |       |
lstart    |   | 0 - 1535  |0-1023 |0-1023 |1536-  |
          |   |           |       |       |2559   |
          |...|...........|.......|.......|.......|............................

                         Fig. 3

Now, vstart for logical page 1536 for the master database is 3588, as shown
in the following:

        1> select vstart = vstart + 1536 - lstart
        2> from sysusages
        3> where dbid=1
        4> and lstart <= 1536
        5> and size > 1536 - lstart
        6> go

 vstart
 -----------
        3588

When you load the dump you made earlier onto master, all the pages for
master are copied from the dump device to the master device in the correct
place. However, at the same time, whatever was in sysusages before this load
is overwritten by what is in the dump. This means that the master device is
now laid out as shown in Figure 3, but sysusages shows it to be as shown in
Figure 1.

Therefore, immediately after the load, vstart for logical page 1536 for
master is 7172 which is incorrect as is clear from Figure 3.

This raises a 605 error as the load completes and recovery occurs:

Attempt to fetch logical page 1536 in database `master' belongs to object id
`0', not to object `'.

SQL Server consequently shuts down.

Action

You can confirm that the source of your 605 error is indeed the wrong vstart
for a logical page in master by booting SQL Server with trace flag 3607.
This brings up SQL Server without recovering any databases. Edit the
dataserver command line in your runserver file to add the trace flag.

   * In UNIX, the file is usually $SYBASE/install/RUN_SVR where SVR is your
     SQL Server name. Add the option -T3607 to the dataserver command line
     in your runserver file, for example:

     $SYBASE/bin/dataserver -T3607 other_qualifiers

          -------------------------------------------------------------
          Note: Be aware that the flag is invoked with -T (uppercase),
          not -t (lowercase).
          -------------------------------------------------------------

   * In OpenVMS, the file is usually
     SYBASE_SYSTEM:[SYBASE.INSTALL]RUN_servername.COM. Add the option
     /trace=3607 to the dataserver command line in your runserver file, for
     example:

             $ server :== $sybase_system:[sybase.bin]dataserver.exe
             $ server /trace=3607 /other_qualifiers

Look at sysusages, and run this query to find vstart for the offending page,
in this case page 1536:

        1> select vstart = vstart + 1536 - lstart
        2> from sysusages
        3> where dbid=1
        4> and lstart <= 1536
        5> and size > 1536 - lstart
        6> go

         vstart
         -----------
                7172

In this case, page 1536 for master was copied at the correct place, but when
SQL Server tries to access it, it calculates a wrong vstart based on the
incorrect value in sysusages and accesses 2048 bytes from the wrong location
on the master device. This causes SQL Server to raise the 605 error.

The best solution is to construct a sequence of create database and alter
database commands that create sysusages as it appears after you load your
dump of master. Based on the original output:

        1> select * from sysusages
        2> where vstart/power(2,24) = 0
        3> order by vstart
        4> go

 dbid   segmap     lstart    size      vstart      pad    unreservedpgs
 ------ ---------- --------- --------- ----------- ------ -------------
      1          7         0      1536           4   NULL           208
      3          7         0      1024        1540   NULL           664
      2          7         0      1024        2564   NULL           664
      6          7         0      1024        3588   NULL           648
      7          7         0      1024        4612   NULL           528
     10          7         0      1536        5636   NULL          1184
      1          7      1536      1024        7172   NULL          1024

(7 rows affected)

You can recreate sysusages by following these steps:

  1. Run buildmaster to get the first three rows in sysusages.
  2. Create the fourth row by creating a database of 1024 pages.
  3. Create the fifth row by creating a database of 1024 pages.
  4. Create the sixth row by creating a database of 1536 pages.
  5. Finally, alter master by 1024 pages to create the seventh row in
     sysusages.

As mentioned at the beginning of this article, instead of re-creating
sysusages, you can follow the process outlined in the "System Database
Recovery" chapter of the SQL Server Troubleshooting Guide for rebuilding the
master database when no valid dump exists.

The fact that load database master generates 605 errors if sysusages.vstart
values don't match has been registered under bug number 45426, which has not
yet been fixed.

System Database Recovery in System 10

This article supplements two sections in the "System Database Recovery"
chapter of the SQL Server Troubleshooting Guide: "Master Device Completely
Lost" and "Master Database Corrupt and SQL Server Will Not Start."

Master Device Completely Lost

If a Valid Dump of the master Database Does Not Exist

For 10.0 and Later SQL Servers

Steps 1 through 5 are fine, but step 6 should read:

     Execute sp_helpdb sybsystemprocs to make sure that the system
     database sybsystemprocs is present. If so, then proceed to step 7.
     If it is not, rebuild sybsystemprocs as follows:

       1. Execute disk init to initialize a new device for
          sybsystemprocs.
             o If you are running 10.0, the device size should be 10MB.
             o If you are running 10.0.2, the device size should be
               12MB.
             o If you running System 11, the device size should be
               16MB, unless you are on Digital UNIX (OSF), in which
               case the size should be 19MB.
       2. Execute create database sybsystemprocs, with the sizes as
          above.
       3. Run installmaster by executing the command isql -Usa
          -Ppassword < installmaster.

master Database Corrupt and SQL Server Will Not Start

If a Valid Dump of the master Database Exists

For 10.0 and Later SQL Servers

Take out step 10. There is no reason to run installmaster if you are
recovering with dumps--everything will be there.

If a Valid Dump of the master Database Does Not Exist

For 10.0 and Later SQL Servers

Steps 1 through 4 are fine, but step 5 should read:

     Execute sp_helpdb sybsystemprocs to make sure that the system
     database sybsystemprocs is present. If so, then proceed to step 7.
     If it is not, rebuild sybsystemprocs as above.

Understanding sysusages.unreservedpgs

Question

How does SQL Server use the column unreservedpgs in the sysusages table and
when is it updated?

Answer

unreservedpgs contains the count of unreserved pages for that disk piece
during the time that the database is "closed". (A database is "closed" when
SQL Server has no in-memory structure describing it. If SQL Server does have
in-memory structures, it uses them in preference to the sysusages row
because access is thousands of times faster.) sysusages.unreservedpgs is
updated in these circumstances:

   * When the database is automatically checkpointed
   * When the database changes state from "open" to "closed"

Note that the update only occurs when the database is automatically
checkpointed-a user issuing the checkpoint command won't cause it to happen;
it must be the system doing it. Because this column is only updated
occasionally, it is inaccurate most of the time. Sybase provides a built in
function for the purpose of getting the accurate number; it should be used
like this:

        select curunreservedpgs(dbid, lstart, unreservedpgs)
        from master.dbo.sysusages
        [ other clauses ]

This function is used by stored procedures such as sp_helpdb and
sp_helpsegment to display space usage.

     ------------------------------------------------------------------
     Note: This information applies only to releases 10.x and later.
     ------------------------------------------------------------------

Understanding Spinlocks

Spinlock Defined

The lowest level of synchronization in a multiprocessor SQL Server is the
spinlock. SQL Server uses the spinlock to synchronize access to the critical
data used to control semaphores, page locks, and other thread management
tasks.

     ------------------------------------------------------------------
     Note: Spinlocks and semaphores are only used in multiprocessor
     servers, since otherwise a process is not allowed to schedule out
     (or yield) while holding one.
     ------------------------------------------------------------------

In general, a spinlock works like this:

  1. A thread or engine obtains a spinlock before attempting to change data.
  2. While that thread or engine has the spinlock, if another thread or
     engine attempts to obtain the same spinlock, that thread "spins" on the
     lock until the lock is released.
  3. Once it is safe for others to access or change the data, the original
     thread releases the spinlock.

A spinlock might perform code protection or data protection. For example,
SQL Server always uses one particular spinlock for modifying a particular
object. A spinlock protecting code protects only a very small fragment of
the code, allowing it to be executed only in a single-threaded fashion.

Spinlocks are the most basic form of locking protocol, usually requiring
hardware support, an atomic instruction across the bus. Spinlocks are used
in favor of more complex semaphores or page style locks to control access to
frequently changed data structures because they are so basic; it doesn't
take long to acquire a spinlock.

Spinlocks and Server Panic

SQL Server "panics" when a thread dies holding a spinlock because the data
structure protected by the spinlock is in an unknown state. Other threads
cannot know how far the first thread got in changing the data structure
before it died. For example, suppose SQL Server needs to delete an object,
b, from a doubly linked list:

a<->b<->c

SQL Server grabs a spinlock and proceeds toward this state:

a<->c

Suppose, then, that there is a crash in the middle of the operation. The
states of the queue and the links are unknown.

a??b??c

It's hard either to undo what the crashed task was doing or to complete it.

The safest strategy is to shut down. This is because if SQL Server continues
to run with the lock held, eventually all of the other threads will block on
the held lock and the server will hang. An orderly shutdown is preferable.

A typical spinlock error in the error log will look like the following:

01:95/07/25 11:22:53.04 kernel  timeslice -1501, current process infected

     (The lock-holding process dies.)

01:95/07/25 11:22:53.11 kernel  ************************************
01:95/07/25 11:22:53.13 kernel  SQL causing error : execute master..lp_catch_wcid_user
01:95/07/25 11:22:53.13 kernel  curdb = 1 pstat = 0x10100 lasterror = 0
01:95/07/25 11:22:53.13 kernel  preverror = 0 transtate = 1
01:95/07/25 11:22:53.13 kernel  curcmd = 197 program = isql
01:95/07/25 11:22:53.15 kernel  Spinlocks held by  kpid 21626922
01:95/07/25 11:22:53.15 kernel  Spinlock Resource->rbufmgr_spin at address 102c6700 owned by
14a002a
01:95/07/25 11:22:53.15 kernel  End of spinlock display.

     (SQL Server recognizes that the process was holding a spinlock.)

01:95/07/25 11:22:53.16 kernel  Begin BackTrace .....
01:95/07/25 11:22:53.17 kernel  pc: 0x6b0368 os_backtrace+0xf8(0x6f20756c, 0x6c6f636b)
01:95/07/25 11:22:53.20 kernel  pc: 0x69f060 ucbacktrace+0xa0(0x2e65d, 0x1)
01:95/07/25 11:22:53.20 kernel  pc: 0x4344cc terminate_process+0x218(0x0, 0xffffffff)
01:95/07/25 11:22:53.20 kernel  pc: 0x6a7884 kaclkintr+0x2ec(0x1c, 0x0)
01:95/07/25 11:22:53.22 kernel  pc: 0xfb16a88 etext+0xf4417f8(0x1056c6e8, 0xfb1bf98)
01:95/07/25 11:22:53.22 kernel  end of stack trace, spid 9, kpid
21626922, suid 1
01:95/07/25 11:22:53.22 kernel  ueshutdown: exiting

     (Finally, SQL Server shuts down.)

Patches for Hard / Transient 605 Errors on HP

Customers running SQL Server under HP-UX 9.04, who have encountered hard and
transient 605 errors, should call the HP Response Center for the following
patches:

   * PHKL_3658
   * PHKL_3981
   * PHKL_4117
   * PHKL_4316
   * PHKL_4732
   * PHKL_4764
   * PHKL_4890
   * PHKL_5139 <- Includes Rollup of Async I/O patches
   * PHKL_5356 <-|
   * PHKL_5394
   * PHKL_5398 <- LVM and bad block relocation fixes
   * PHKL_5532 <-|
   * PHKL_5576

Verify with HP to make sure that you need these, but if you have fast/wide
SCSI and the A3232A or A3231A arrays, this is what you will need at least to
get your system stable.

Localization Problems and cs_ctx_alloc Failure

This article describes common problems when using Open Client(tm) in Windows
that can lead to the generic message "cs_ctx_alloc failure," and the steps
for correcting the problem. This is especially critical with any customers
using the internationalization features of Windows itself.

Open Client is based on a set of dynamic libraries, which take a modular
approach to messaging and internationalization. One of the most confusing
messages for both Technical Support and the customer is the "cs_ctx_alloc
failure." This message means that something happened when the client
libraries were trying to allocate the context for a connection.

There are a number of things that can cause this message:

  1. Improper setup of the Sybase environment.
  2. Missing or corrupted localization files.
  3. Resource allocation problems.
  4. Actual network problems.

In the first case, the problem can be as simple as the failure to have run
the WSYBSET.BAT batch file before entering Windows. It is important to make
sure that the $SYBASE system variable (at a minimum) is set to point to the
directory where the Open Client product is installed.

The location of DLLs (dynamic link libraries) is also important, since
failure to load a DLL may cause a misleading error message like the
cs_ctx_alloc error. Make sure that any DLLs (such as network software, and
Open Client) are located along the $PATH, or in the Windows system
directory.

Localization is done during context allocation, so if the localization files
are missing or corrupted, the context allocation will fail. This could be
due to improper setup of the Sybase environment (described above), an actual
installation problem, disk file corruption, or a conflict between the PC's
localization and that used by Sybase.

The localization routines look at the $SYBASE/LOCALES directory for the file
LOCALES.DAT. This file tells the localization routines which files contain
which messages for each character set and language. It also looks for a
locale name by searching the environment for the $LC_ALL environment
variable. If this environment variable is not defined, it looks for the
$LANG variable. If neither of those are defined, it looks for the Language
setting in the WIN.INI file. If none of these are set, it uses the locale
name of "default". Whatever the value is determined to be is then searched
for in the LOCALES.DAT file to determine which language and character set
are associated with it.

This seems to be the most common problem, and is usually solved by adding
the following line to either the AUTOEXEC.BAT file or the WSYBSET.BAT file:

          set LANG=enu

     ------------------------------------------------------------------
     Note: The righthand side of the equal sign must be in lower case.
     ------------------------------------------------------------------

In Europe, set LANG=enu in WSYBSET.BAT usually does the trick.

The "cs_ctx_alloc failure" occurs when the locale name that has been
determined does not exist in LOCALES.DAT. See Chapter 2 of the Open
Client/Server Supplement for Windows for more information on localization.

The other failures can normally be determined by examining the contents of
the SYBINIT.ERR file located in either your root directory, or the directory
of the executable which caused the allocation failure. It is very often a
problem with the configuration of the network software, which can require
modification of that software's initialization files.

End-of-Life Plan for APT and DWB

Sybase supports many different products on many different operating systems
and environments. Over time, we review the ongoing investments required to
continue supporting each product. We analyze market trends, our customers'
requirements as indicated in customer surveys, buying trends, and continued
use of Sybase products. We also review our overall product strategy to
ensure that we are providing the right mix of products to our customers.

Over the last few years, the trend in the market has been away from
character-based development tools such as APT Workbench(tm) and Data
Workbench We have seen demand for these products diminish as customers turn
to graphical-based tools.

As a result of our review and analysis, we have decided to end enhancement
and support for Sybase's APT, Data Workbench, and Report-Execute(tm)
products. Low demand for these products no longer justifies the investment
in new product engineering.

To help Sybase customers continue to support their applications based upon
these products and to transition to alternative development environments,
Sybase will provide the following end-of-life plan:

  1. Sybase will continue to provide full product support for five (5) years
     for APT, Data Workbench and Report Execute to customers who have
     purchased support contracts for these products. Although we will not be
     enhancing the products to take advantage of new features of SQL Server,
     we will ensure upward compatibility with future SQL Server releases. On
     June 30, 2000, we will stop accepting support calls on all APT, Data
     Workbench and Report-Execute products and will no longer provide any
     software changes.

  2. To our APT Workbench and Data Workbench customers with active support
     agreements, we are offering a special promotion. You may receive 50
     percent off the purchase price of any Sybase SQL Server or Powersoft
     product, including PowerBuilder up to the value of your APT Workbench
     and Data Workbench active licenses (based upon current list price).
     When you no longer require support for your APT, Data Workbench or
     Report-Execute products, you may request this discount by calling
     1-800-685-8225. The Sybase representative will determine your discount
     amount, and apply that amount towards the purchase of other Sybase
     products. At the time you exercise this discount option, support for
     your APT and Data Workbench products used in the calculation of the
     discount will be terminated. This promotional offer will remain in
     effect until June 30, 2000, and applies only to APT Workbench and Data
     Workbench licenses that (a) are covered by active support agreements at
     the time you take advantage of the promotional offer and (b) were
     purchased (or deployed against a secondary copy pool) prior to June 30,
     1995.

  3. We understand that you have applications that you have developed using
     APT and may need to add additional licenses as you deploy these
     applications. You will be able to purchase additional licenses for all
     APT, Data Workbench and Report-Execute products during this end-of-life
     period. However, support for these new licenses will end on June 30,
     2000, regardless of the date of purchase.

The specific products included in this end-of-support notice are:

   * APT Workbench
   * APT-Execute(tm)
   * Data Workbench (which includes Report Workbench)
   * Report Execute
   * PC APT 32-bit Deployment Toolkit
   * all APT-Libraries (for a variety of languages)
   * APT Translator for Motif (previously obsoleted)
   * APT Display for Motif (previously obsoleted)

     ------------------------------------------------------------------
     Note: This end-of-life plan does not affect the Japanese codeline:
     5.1.x.
     ------------------------------------------------------------------

We do hope that the extended period of time for support of these products
will help you in the transition from APT, Data Workbench and Report-Execute.

If you would like to take advantage of the promotional offer described
above, please call your local Sybase support group or 1-800-685-8225 (U.S.
and Canada) and a Sybase representative will be glad to help you.

The current releases of the toolset products (APT-Execute, APT Workbench,
Data Workbench and Report-Execute), versions 5.2.2 and 5.2.3 have been
available for well over a year, and Sybase is in the process of introducing
a new release, version 5.3, during Q2 and Q3 of 1995. With the availability
of releases 5.2.2, 5.2.3, and 5.3 of the toolset products, and the limited
number of customers using the older versions, Sybase can no longer provide
support for older versions.

Effective June 30, 1995, support has been discontinued for all releases of
these products that precede version 5.2.2.

When planning for the current releases of the toolset products, Sybase
reviewed the demand for these products on all supported platforms. For a
limited number of hardware platforms, demand has declined to less than 10
customers. For this reason, Sybase has no plans to provide release 5.2.2,
5.2.3 or 5.3 on the platforms listed below. Support of the last release (4.x
and 5.0) of these products provided for these platforms will continue until
June 30, 1996 and will not be available after that date. Customers are
encouraged to transfer their licenses that are covered by current support
agreements to a platform for which release 5.3 is provided. Support for
release 5.3 will continue until June 30, 2000.

This table shows the combinations of platform and release that will be
supported under current contracts until June 30, 1996:
     Platform     Operating System APT/DWB Release
 386 PC           UNIX OSF         4.0.3
 AT&T 3B2         UNIX 5.3.2       4.0.0
 Bull DPX         BOS 1.0          4.0.3
 IBM RT           AIX 2.2.1        4.0.0
 Stratus XA/2000  VOS 9.0R         4.0.2
 Stratus XA/R I860VOS 11.5         5.0.0

If you have any questions, please call your local Sybase support group or
our US corporate offices at (510) 922-3500 or 1-800-8-SYBASE (U.S. and
Canada).

Mainframe EBF Information

Here is the latest list of all AVAILABLE rollup Mainframe Access Products
EBFs as of 8/23/95. This list replaces any previous list sent. Be sure to
read the important notes at the end, especially note 1:

                 Mainframe Access Products EBFs

       MAP Product       Catalog Number version 2.x version 3.0
                                         EBF number EBF number
 Open Client/CICS/LU6.2  19320          4686        n/a
 Open Server/CICS/LU6.2  19300          2218        3528
 Open Server/CICS/TCP_IP 19350          n/a         3529
 Open Server/IMS/LU6.2   19315          n/a         4983
 OSAM/DB2/CICS/LU6.2     19311          1971        4899
 OSAM/DB2/CICS/TCP_IP    19360          n/a         4608
 OSAM/DB2/IMS/LU6.2      19370          n/a         4609

Important Notes

Please note that these Mainframe EBFs ship automatically as part of any new
product order.

  1. EBFs 4983 and 4609 will allow you to run Open Server(tm) and OSAM/DB2
     under native MVS, with no transaction manager. It is packaged as part
     of the IMS products, not as a standalone. We recommend that you run the
     Open Server API product as read only, unless you wish to code your own
     commit and rollback logic. The OmniSQL Access Module(tm) for DB2 can be
     read/write. For installation, it is a separate download file, with
     different names than IMS, and nothing shared with IMS. You need not
     actually have IMS to use it, but it must be ordered via the IMS
     products (19315 &/or 19370).
  2. All MAP(tm) EBFs now support RPC parameters >32k but <64k, without
     needing any of the latest Net-Gateway(tm) EBFs.
  3. All MAP EBFs now support RPC parameters >64K, if you also have the
     latest Net-Gateway EBF 3516 or higher, depending on your platform, and
     additionally start up Net-Gateway with the new option -E to enable this
     support. The OS/2 GA already has this support built in.
  4. Open Server for CICS 1.0 applications can run with the 3.0 stub without
     having to relink.
  5. EBFs 4899, 4608, and 4609 fix failed rollbacks in long running
     transactions when a quit or disconnect occurs. All customers doing
     replication into DB2 will need this EBF. Rollups from prior EBFs cure
     batched SQL (multiple input lines separated by semi- colons ; )
     problems encountered when a comma is part of the input line, such as
     found in names like O'Malley. This behavior is not fixed on 2.0
     codeline on top of 1971 (and there are no plans to), though a 1-off
     based on 2.0 GA was done (4607).
  6. All Trinzic (InfoHub) customers need the latest Net-Gateway and OS/CICS
     EBF.
  7. Some Open Client/CICS customers using the latest EBF will need the
     latest Net-Gateway EBF for their platform if they are using SQL Server
     names longer than 8 characters with OC/CICS (bug 57967) or are
     re-linking their applications with the new stub that contains the
     memory leak fix (bug 56162). Check the Net-Gateway cover letter to be
     sure the fix has been ported for your Net-Gateway platform.

Net-Gateway EBF Information

Here is the latest list of all rollup Net-Gateway EBFs which will become
available during August and throughout September and early October 1995.

This list replaces any previous lists sent:

                        Net-Gateway EBFs

 Net-Gateway                   version 2.x       version 3.x
  Platform  Catalog Number     EBF Number        EBF number
 HP9000/800 17700          n/a                5361 (see note 4)
 OS/2       16230          5420               4836
 RS6000     12670          5419               5401 (see note 5)
 Solaris    12950          n/a                5402 (see note 6)
 SunOS      18600          5365 (see note 7)  5400 (see note 7)

Important Notes

  1. A version 2.x Net-Gateway can run with a CICS LU6.2 MAP product at 3.0
     or 10.1 version level, but it cannot take advantage of any new
     functionality. For migration purposes, always update the mainframe code
     first, then Net-Gateway second.

  2. All Trinzic (InfoHub) customers need a 3.0 Net-Gateway EBF plus the
     latest MAP 3.0 EBF before using the product (that is, GA MAP plus
     latest valid mainframe EBF).

  3. Some Open Client/CICS customers using the latest EBF 4686 will need a
     Net-Gateway EBF if they use long SQL Server name lengths (bug 57967) or
     re-link their applications with the stub fixed for the memory leak
     problem (bug 56162); check the EBF cover letter to verify your platform
     has the fix ported.

  4. This EBF is built on HP-SNAplus patch PHNE_5329. All customers are
     required to install this HP patch in order to use EBF 5361.

  5. This EBF is built on AIX 3.2.3 and SNA Server. EBF 5401 also contains
     support for IBM's Password Expiration Manager.

  6. This EBF is built on Solaris 2.2 and Sunlink Peer-to-Peer 8.0, with
     patches 101524-01, 102146-02 and 102147-01 applied.

  7. All SunOS customers must apply base patch 100916-06, plus 100916-07 by
     contacting Sun Engineering.

General Information

The new 3.0 Net-Gateway EBFs include the following features:

   * Memory leaks fixed.
   * Group password is no longer displayed.
   * New -C Net-Gateway start-up option to roll lowercase userids and
   * passwords into uppercase before sending to mainframe.
   * RPCs >32K supported.
   * RPCs >64K supported using new -E Net-Gateway start-up option and MAP
     EBF 3525 or higher.

The new 2.0 Net-Gateway EBFs include the following features:

   * Group password is no longer displayed.
   * New -C Net-Gateway start-up option to roll lowercase userids and
     passwords into uppercase before sending to mainframe.
   * sygc gateway control program broken by previous 2.0 EBFs fixed

Bug 69332: Timeslice Disables Automatic Checkpoint and waitfor Command

     ------------------------------------------------------------------
     Note:This bug is specific to IBM RS6000.
     ------------------------------------------------------------------

Sybase Technical Support recently encountered a case where a customer's
tempdb database was filling up. The customer was able to run a manual dump
transaction in tempdb, indicating that there were no open transactions.
Further investigation revealed that the automatic checkpoint process was not
dumping tempdb, even though the process was visible through sp_who. The
customer also noticed that the waitfor command no longer worked.

The problem turned out to be a large stored procedure that tended to raise a
time slice error. Further testing showed that when any process on the
customer's server suffered a time slice error, the waitfor command and
automatic checkpoint process no longer functioned until the customer
rebooted SQL Server.

If you get a time slice error in your errorlog and subsequently get hung
processes or notice that the waitfor command and automatic checkpoint no
longer function, you may call Sybase Technical Support to get a one-off EBF
containing the fix for bug 69332. The fix for this bug has not yet been
incorporated into a Rollup, but will be in the future.
----------------------------------------------------------------------------

Disclaimer: No express or implied warranty is made by SYBASE or its
subsidiaries with regard to any recommendations or information presented in
SYBASE Technical News. SYBASE and its subsidiaries hereby disclaim any and
all such warranties, including without limitation any implied warranty of
merchantability of fitness for a particular purpose. In no event will SYBASE
or its subsidiaries be liable for damages of any kind resulting from use of
any recommendations or information provided herein, including without
limitation loss of profits, loss or inaccuracy of data, or indirect special
incidental or consequential damages. Each user assumes the entire risk of
acting on or utilizing any item herein including the entire cost of all
necessary remedies.

Staff

Principal Editor: Leigh Ann Hussey

Contributing Writers:
Sandra Dellafiora, Aimee Grimes, Louise Kirby, Jeff Lichtman, John McVicker,
Pat Mullin, Rahul Upadhyaya, Rob Weaver, James White, Elton Wildermuth

Send comments and suggestions to:

SYBASE Technical News,
6475 Christie Avenue,
Emeryville, CA 94608 USA

For more info send email to techpubs@sybase.com
Copyright 1995  Sybase, Inc. All Rights Reserved.
-- 
Pablo Sanchez              | Ph # (415) 933.3812        Fax # (415) 933.2821
pablo@sgi.com              | Pg # (800) 930.5635  -or-  pablo_p@pager.sgi.com
===============================================================================
I am accountable for my actions.   http://reality.sgi.com/pablo [ /Sybase_FAQ ]
