Subject: Sybase FAQ: 11/16 - section 10.1
Date: 1 Sep 1997 06:07:14 GMT
Summary: Info about SQL Server, bcp, isql and other goodies
Posting-Frequency: monthly

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

   
   
                            Q10.1.1: TECHNICAL NEWS
                                       
 Volume 3, Number 2
May, 1994

   
     _________________________________________________________________
   
   
   
   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:
   John Blair, James Gath, Karen Hogoboom, Jeff Lichtman, Steve Olson,
   Benjamin von Ullrich, Elton Wildermuth, Sybase Engineering, Sybase
   Tech Support Send comments and suggestions to:
   SYBASE Technical News
   6475 Christie Avenue
   Emeryville, CA 94608
   
   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. Keep this newsletter
   with your SYBASE Troubleshooting Guide. 
   
Get Certified!

   
   
   A new program has been recently announced which will allow Sybase
   customers, employees, partners and others to demonstrate official
   competence in the SYBASE architecture and product set. The Certified
   SYBASE Professional (CSP) Program is targeted at client/server
   architects, designers, developers, systems and database administrators
   and support engineers. The first CSP certification is the Certified
   Sybase DBA. This certification program will be beta tested in North
   America and the UK in January. Other likely certifications will
   include Open Interfaces Developer, Application Developer and
   Architect. Professional Services is working with Customer Services and
   Support to ensure that Sybase offers a single integrated certification
   program for both development and support professionals. For more
   information contact Wendy Washington at Sybase, 510-922-0959, and ask
   for the CSP Brochure. 
   
Troubleshooting Guide Update

   
   
   Troubleshooting Guide Goes Online
   
   The new version of the Sybase Troubleshooting Guide is on its way! It
   includes over 60 new error messages, as well as new and revised
   material on many Sybase products. Due to the increasing amount of
   information, it now comes in two volumes: a Server volumen, and a
   Tools and Connectivity volume.
   
   The new Troubleshooting Guide will be available in both paper and
   electronic form. Both volumes will be included on the AnswerBase
   CD-ROM support product. The Server volume will be included on the
   first SyBooks CD-ROM publications product. Both AnswerBase and SyBooks
   CDs will be available in Q3/Q4.
   
   Mass updates of future versions of the Troubleshooting Guide will be
   provided free of charge in AnswerBase and SyBooks formats. Paper
   manuals will still be available for purchase (or print your own from
   the electronic version!).
   
   Getting Your Troubleshooting Guide Feedback
   
   The goal of the Sybase Troubleshooting Guide is to help you better use
   (and support) Sybase products, and to do so more self-sufficiently. To
   accomplish this, we need your feedback. To this end, a mail alias
   called tsg has been established. The intention of this alias is to
   allow Sybase customers and employees to comment on the Troubleshooting
   Guide by mailing tsg@sybase.com with:
     * Corrections
     * Requests for specific additions
     * Additions (i.e., written material)
     * Comments about which sections are particularly helpful
     * Comments about which sections are not clear
     * Any other input you might have
       
       tsg will not be a forum for answering questions best taken to
       Technical Support, but will be your chance to make the
       Troubleshooting Guide more useful for everyone who uses it.
       
       The next issue of the Troubleshooting Guide will be slightly
       different from previous issues. It will come in two volumes, a
       Server volume, and a Connectivity volume, and will be released in
       both hardcopy and electronic versions (Answerbase and SyBooks).
       Sybase Support Publications is considering releasing future issues
       of the Troubleshooting Guide only in electronic format; customers
       are requested to mail tsg@sybase.com to give us feedback on this
       topic.
       
   
   
803 Error Installing from CD-ROM

   
   
   Numerous customers have called about receiving 803 errors when they
   try to install SYBASE products from CD-ROM. Here are the complete
   instructions for such installations; please disseminate this
   information as widely as you wish.
   
   Step 1: Login as root.
   Step 2: Mount the CD as a filesystem in a UNIX machine. The exact
   mount
   
   command differs between platforms. In the following examples,
     * /dev/sr0 stands for your CD-ROM device name.
     * /cdrom is a local directory you have created.
     * mount usually exists in the /etc directory. You may have to cd
       
       /etc before you can issue the command. Sun 4
       
       # mount -rt hsfs /dev/sr0 /cdrom Sun_SVR4 (Solaris)
       
       # mount -o ro -F hsfs /dev/sr0 /cdrom _DEC AXP OSF_
       
       # mount -rt cdfs -o noversion /dev/sr0 /cdrom Be sure that the
       directory is writable by the world, and large enough for the
       install to complete! Don't forget to log out as root before
       continuing installation. SYBASE software should be installed by
       the sybase user in order for permissions to be set correctly. Step
       3: After you have mounted the CD, go to the directory in which it
       
       is mounted. Step 4: Run sybload -D, which is the disk-install
       version:
       
       % cd /cdrom % ls sybload sybimage % ./sybload -D sybload is an
       executable; sybimage is the global file containing the suite of
       products. sybload will prompt you for the file used for disk
       installation. Step 5: Give it the name /cdrom/sybimage. From there
       onward, the
       
       process is the same as installation from tape.
       
   
   
Hanging, Sleeping, and the "Zombie" Process

   
   
   What are the different states of SLEEP? When all processes are shown
   as SLEEPING by sp_who except the one which issued the sp_who command,
   how can a user tell the difference between hanging versus running
   processes? What is a "zombie" process and how can it be dealt with?
   
   Definitions
   
   In pre-4.9.2 SQL Servers, the output of sp_who could be difficult to
   interpret. Processes showed only one type of SLEEP status, "sleeping".
   In System 10, and 4.9.2 Rollup 2115 and above, sp_who shows four types
   of sleep along with the other possible statuses:

Value           Meaning
-----           -------
infected        The server erred with a stack trace, and the process
                got an error that would normally kill it. The process
                is infected instead of killed.

background      This process is in the background.

recv sleep      The process is waiting for input from the client.

send sleep      The process is waiting for a write to the client to complete.

alarm sleep     The process is waiting for an alarm (usually means the
                process is waiting for a waitfor command to complete).

lock sleep      The process is waiting for a lock to be granted.

sleeping        The process is waiting for something not listed above.
                This is "normal" sleep.

runnable        The process is not waiting for anything, and is ready
                to run, but is not the currently running process.

running         The process is currently running (in a multiprocessing
                system, there can be more than one such process).

stopped         The process is stopped. In ancient history (before
                version 4.0.1), all processes stopped during a
                checkpoint. Now the only time a process is in the
                stopped state is when someone is using the kill command
                on it.

bad status      There is a bad value for the status of this process.

   
   
   In uniprocessor hardware there can be only one process RUNNING and all
   other processes are either SLEEPING or RUNNABLE. The next RUNNABLE
   process gets scheduled to run after sp_who finishes. Processes sleep
   for certain events like disk I/O, network I/O, alarm, etc. If all the
   threads are shown as SLEEPING, at least one of them will become
   RUNNABLE after an event on which the thread is waiting.
   
   On a multi-processor machine, if more than one SQL Server engine is
   started, you can see more than one thread in the RUNNING state. The
   number of processes running can not exceed the number of SQL engines
   running.
   
   It is not possible to find out from sp_who output which client process
   is hung waiting for Server response. But it is possible to find out if
   any process (i.e. thread) is blocked by another by looking at the
   "blk" field of sp_who. For more details please refer to the Commands
   Reference Manual.
   
   Before System 10 -- Night of the Zombie Process
   
   Pre-System 10 SQL Servers can end up with "zombie" (unkillable
   hanging) processes if the event on which a thread is sleeping never
   happens. In this case, the thread does not run and cannot be killed.
   This anomaly existed right from the first release of 4.0 SQL Server
   until a recent Rollup of 4.9.2 (2115 and above).
   
   The problem is that the SQL Server scheduler is non-preemptive. This
   means that tasks cannot be put to sleep or woken up arbitrarily by the
   SQL Server scheduler; all task context switching is done voluntarily
   by running tasks.
   
   Pre-System 10 SQL Servers handle attention through a signal handler
   set up to catch OUT-OF-BAND data which sets a status bit in the PSS
   (Process Status Structure). This is an asynchronous event. For
   example: a task is about to go to sleep waiting for input, but the
   client cancels the query with dbcancel(). If the signal handler sets
   the bit between the time the task is going to sleep and the time it is
   actually put to sleep, then the server task sleeps forever waiting for
   the client to send some data, and the client sleeps waiting for the
   server to acknowledge the cancel request. This is the well-known
   "dbcancel problem." Another source of trouble can be a DBMS task in
   the Server which is sleeping on a network I/O from a client that just
   isn't there any more (maybe because somebody rebooted the PC on which
   the front end was running).
   
   This kind of task cannot be killed because:
     * The task must be in RUNNABLE state so that the scheduler can
       
       kill the task the next time it runs.
     * The task cannot be preempted because its state is unknown.
       
   
   
   To complicate the above scenario, if the eternally-sleeping task
   started a transaction, it may potentially hold locks on different
   pages. The only solution for older versions is to reboot the SQL
   Server.
   
   A Wooden Stake for the Zombie Process
   
   As of the 10.0 SQL Server, and 4.9.2 SQL Server Rollup 2115 and above,
   zombie processes can now be killed. The new kill command not only sets
   the bit in the PSS as it used to, but also wakes up the task if it
   determines that the task is sleeping in one of four states:
     * waiting to receive something from the client, a common state
       
       _(RECV SLEEP)_
     * waiting for a send to be completed by the network service task
       
       _(SEND SLEEP)_
     * waiting on an alarm because user did a waitfor delay command
       
       _(ALARM SLEEP)_
     * waiting on a lock (resource, logical, semaphore, etc.) (LOCK
       SLEEP)
       
   
   
   This means that any task can be cleaned up properly as if an exception
   has occurred while the task was running, provided the task is in one
   of the RECV, SEND, LOCK and ALARM sleep states. The new kill command
   can kill infected processes as well, also a new feature.
   
   The kill command can almost instantaneously kill a task that is
   sleeping on any one of the events except the fifth state: normal sleep
   (where the task is waiting for a resource to post network or disk
   I/O). This was true for older versions of SQL Server, and is still
   true. The reason for this is that all sleeps except "normal sleep"
   have well-known and well-understood backout paths; however, tasks
   sleeping on resources have a variety of different backout paths.
   
   The new kill command will:
     * set the "kill yourself" bit on the task
     * wake up the task normally
     * put the task into the runnable queue
       
       When the scheduler is ready to run the task it finds the "kill
       yourself" bit and aborts the task. For tasks that are in normal
       sleep or for running tasks, the new kill command acts exactly as
       the old kill command: it sets the kill bit in the PSS and it is up
       to the task to wake up and test the bit and decide to kill itself.
       Note that this means that the new kill command may not have an
       effect on all tasks.
       
   
   
   NOTE! If a killed task is in the midst of a transaction, the entire
   transaction will abort. All resource cleanup will occur in the task
   backout path so that no inconsistent resources are left hanging around
   that might cause the SQL Server to hang in a hibernating state and
   eventually have to be rebooted.
   
   There were regressions, caused by the new kill command's original
   implementation, which could cause the server to hang (bug 51270) or
   not completely kill the process under certain conditions (bug 48964).
   These bugs were fixed as of Rollup 2359, and can be ordered from Tech
   Support.
   
   This fix is not available on the SQL Server NLM release for Netware.
   Instead, Netware sites must use a different method for avoiding zombie
   processes.
   
   How to Eliminate Zombie Processes on SQL Server NLM
   
   To eliminate Zombie processes from the Novell SQL Server:
    1. Download from Compuserv, from the NOVLIB forum (Currently in
       
       forum 1) the STRTLI.EXE file.
    2. Execute the file STRTLI.EXE - this expands to 8 NLMs and 2
       
       documents. The NLMs are: STREAMS.NLM, TLI.NLM, SPXS.NLM,
       SPXLISFIX.NLM, SPXFSFIX.NLM, SPXSIX2.NLM, IPXS.NLM, and
       PATCHMAN.NLM. The documents are: STRTLI.DOC and PCHMN230.DOC.
    3. STRTLI.DOC contains instructions on how to load the files. Load
       
       4.2.2 of the NLM SQL Server first, then the new files from Novell.
       If you load SNLMINST after loading the new files, you will have
       written over several of the new files and will need to reload
       them.
       
   
   
DECnet Errors and Hanging Processes

   
   
   This past spring, a customer running the 4.8 version of SQL Server for
   VMS encountered a problem with hanging/sleeping server processes left
   after network/router errors caused disconnects. A change in the AST
   networking strategy for DECnet solved this problem (bug 40459 on VMS,
   bug 38156 on AXP).
   
   The behavior exhibited was that users would switch off their PC front
   ends without properly logging out of connections to the SQL Server.
   The Server would not deassign the channel and delete the mailbox on
   error exit from its connection accepting system call. The customer's
   router and the design of the client application caused so many errors
   that the Server ran out of I/O channels.
   
   Sybase Engineering modified the VMS SQL Server so that it now
   deassigns the channel and deletes the mailbox after rejecting the
   connection. This change, originally made in the System 10 release of
   SQL Server, was back-ported to the 4.9.x codeline and is available as
   part of the latest Rollup. 
   
The Problem of Null Column Names

   
   
   How does one refer, if at all, to an undefined column name resulting
   from a select into of a built-in function? In 10.0 SQL Servers, NULL
   column names are not allowed (see last issue's Special Supplement). In
   earlier SQL Servers, when a name is defined as NULL in syscolumns the
   following situation ensues:

        1> select title_id, title, price, convert(varchar(30), total_sales)
        2> into scratchdb..titletab
        3> from pubs2..titles group by title_id, convert(varchar(30),
        total_sales)
        4> go
        (18 rows affected)

   
   
   This creates a table with four columns, one with no name. Attempts to
   use the null name fail.

        1> use scratchdb
        2> go
        1> create clustered index x on titletab (title_id, "")
        2> with ignore_dup_row
        3> go
        Msg 102, Level 15, State 1:
        Server `SYBASE', Line 1:
        Incorrect syntax near ` `.
        1> select convert (varbinary, name) from syscolumns where
        id=object_id("ben")
        2> go
         --------------------------------------------------
         0x636173656e756d
         0x6c6f675f6964
         0x74696d65696e
         NULL
        (4 rows affected)

   
   
   In order to get around this problem, you may use sp_rename in an
   intuitive way, to get rid of the NULL column name as follows:

        1> sp_rename "titletab.", request_status
        2> go
        Column name has been changed.
        return status = 0)

   
   
"Too Many Open Files" on Solaris

   
   
   If you have a Sun_SVR4 (Solaris) SQL Server that reports the error
   "Too many open files" from a kernel subsystem, you will need to change
   the maximum number of file descriptors per process (NOFILES kernel
   parameter on most systems). There are two ways to reset this value:
    1. Modify your RUNSERVER script as follows, depending on your shell:
       
       sh or ksh RUNSERVER script: ulimit -n ## csh RUNSERVER script:
       limit descriptors ##
       
   
   
   where ## = the new value for file descriptors
   
   2. Run a program which calls setrlimit() to increase the

      maximum number of file descriptors and then invoke a process
      which requires a large number of fd's (file descriptors).

   
   
   Here are a sample program and makefile called set_nofiles.c to show
   you how to do this.
    1. Build the executable by typing the command (assuming you
       
       named the makefule set_nofiles.mk): make -f set_nofiles.mk
    2. Run the executable by giving it the name of any program
       
       to run along with its command line options, for example:
       set_nofiles foobar x. You can have it run startserver -fRUNSERVER
       or the dataserver program.
       
   
   
   You must run the ulimit/limit or makefule commands as root in order to
   set the maximum number of file descriptors > 1024.
   
   Note: This Procedure is Documented Under System-10 SAG Supplement for
   
   SunOS Release 5.x (SVR4) Page 4-1.
   
   ***************source for
   set_nofiles.c**************************************
   
   /* set_nofiles.c, set_nofiles, Customer Service group, 07/02/93 /*
   routine to increase the maximum number of file descriptors per process
   /* Copyright (c) 1993, Sybase, Inc., Burlington, MA 01760 /* All
   Rights Reserved /*
   /* TITLE: set_nofiles
   /*
   _/* START-HISTORY:_
   /*
   /* 02 Jul 93 edit 0 - Lance Andersen. /* Initial coding.
   /*
   _/* END-HISTORY_
   /*
   _/* START-DESCRIPTION:_
   /*
   /* set_nofiles is a program which can be run to execute the RUNSERVER
   /* file (or any other executable) in order to increase in number of /*
   file descriptors available per process inorder to avoid the OS /*
   error EMFILE (Too many open files): /* To use this program:
   /* Build as follows:
   /* cc set_nofiles.c -o set_nofiles
   /*
   /* While logged in as root, set the following ownership and
   permissions: /* chmod u+s set_nofiles
   /* chown root set_nofiles
   /*
   /* To execute:
   /* set_nofiles command
   /*
   /* When set_nofile executes, it will set the max file descriptors to
   the /* value defined by the MAX_FD #define. The program will run under
   root /* ownership while file descriptors are being changed and then
   ownership /* will revert back to the user who invoked the program (in
   order to /* prevent security breaches).
   
   _/* END-DESCRIPTION_
   /*
   _/* START-DESIGN:_
   /*
   _/* END-DESIGN_
   /*
   _/* START-FUTURES:_
   /*
   _/* END-FUTURES_
   /*
   _/* START-CODE:_
   */
   
   /*
   **********************************************************************
   */ /* Define OS include files */ /*
   **********************************************************************
   */
   
   #include <stdio.h>
   #include <ulimit.h>
   #include <sys/time.h>
   #include <sys/resource.h>
   #include <sys/types.h>
   #include <errno.h>
   
   /*
   **********************************************************************
   */ /* Define constants */ /*
   **********************************************************************
   */
   
   #define MAX_FD 3000 /* set max number of fd's per process (NOFILES) */
   
   
   main(argc, argv)

int argc;             /* Number of arguments */
char **argv;         /* arguments */

   
   
   {
   
   struct rlimit rlim; /* soft & hard resource limits */

        /* ****************************************************************** *
/
        /* Set the maximum and current value for fd's per procesess (NOFILES) *
/
        /* ****************************************************************** *
/

        rlim.rlim_max= MAX_FD;      /* hard limit */
        rlim.rlim_cur= MAX_FD;      /* soft limit */

        if(setrlimit(RLIMIT_NOFILE, &rlim)==-1)
        {

                /* Oops, we failed, print error msg and OS error number */

                fprintf(stderr,
                "OS error %d encountered while changing RLIMIT_NOFILE to %d\n",
                errno,MAX_FD);

                exit(-1);
        }

        /* ****************************************************************** *
/
        /* reset the uid to the user who invoked the program so that the      *
/
        /* process does not run as root.                                      *
/
        /* ****************************************************************** *
/

        setuid( getuid() );

        /* ****************************************************************** *
/
        /* Now execute our program passing required arguments                 *
/
        /* ****************************************************************** *
/

        if(argc >1)
                execv(*++argv, argv);
        else
                fprintf(stderr,"Warning, no argument passed to set_nofiles\n");

}     /* END -- MAIN */
     * Now the makefile *******
       
   
   
   # set_nofiles.mk
   #
   # Makefile to create set_nofiles command # Note: to run the install
   portion, you must be logged in as root
   
   _DEFAULT_CFLAGS=_
   _LIBRARIES= _
   CFLAGS= -c $(DEFAULT_CFLAGS) $(EFFLAGS) _INCLUDE= _
   
   OBJECT = set_nofiles.o
   
   BUILD_NAME=set_nofiles
   INSTALL_DIR=$(HOME)/bin
   OWNER=root
   
   #
   # Default rule to delete, build and install set_nofiles #
   all: clean build install
   
   #
   # Build the binary
   #
   build : $(OBJECT)
   
   $(CC) $(OBJECT) $(LIBRARIES) -o $(BUILD_NAME)
   
   #
   # build the binaries
   #
   
   $(OBJECT): $(OBJECT:.o=.c)
   
   $(CC) $(INCLUDE) $(CFLAGS) $<
   
   #
   # Remove all object files
   #
   clean:
   
   rm -f $(OBJECT) $(BUILD_NAME)
   
   #
   # install the product
   #
   install:
   
   cp $(BUILD_NAME) $(INSTALL_DIR)/$(BUILD_NAME); cd $(INSTALL_DIR);
   chown $(OWNER) $(BUILD_NAME); chmod u+s $(BUILD_NAME)
     _________________________________________________________________
   
   
   
Specifying TCP Port in System 10 for Solaris

   
   
   A customer installing Sybase 10.0 on Sun_SVR4 (Solaris) ran into an
   odd problem. With an original specification of TCP port 2000 for the
   SYBASE Server process, the installation failed. When the port number
   was changed to 2025, as shown in the example in the Install Guide, the
   installation worked fine. The manual suggests that any port not
   currently used between 1024 and 65535 can be specified -- what caused
   this failure?
   
   It appears that 2000 was listed in /etc/services. Round numbers like
   2000, 6000, etc. are often used for network services. We recommend,
   therefore, that you avoid using round numbers for your port numbers. 
   
Solaris 2.3, Intimate Shared Memory, and Server EBFs Revisited

   
   
   Sun Support has been passing along information to our mutual customer
   base that either EBF 2592 or EBF 2594 are required, along with their
   patch 101318-35+, to prevent certain system panics. As a result,
   customers are calling Sybase Technical Support and requesting one of
   these EBFs. Further, the 10.0.1 Server Release Notes claim that our
   customers will need EBF 2594 and Sun's patch to prevent Sun OS panics
   while running SQL Server. This article will clarify the issue and make
   some important amendments to Sun Support's information.
   
   The majority of customers will not encounter a problem after
   installing only the Solaris patch. Most customers' Servers will boot
   and run just fine. Customers who have memory configured to a value
   near (or greater than) the physical memory on the machine may
   experience problems. Generally speaking, very few customers fall into
   this group, and those that do would probably be better off configuring
   memory to a level that Intimate Shared Memory can again be used and
   the old Server booted successfully (see Summary notes).
   
   First, a word on Sybase's EBFs. There will be no EBF 2592 for 4.9.2.
   The reason is that ISM use is not a feature of our 4.9.2 Server. The
   only way ISM can be used is if the system forces all user applications
   to use ISM. If that is the case, and the Sun patch has been applied,
   the Server simply will not boot. In that case, disable this Solaris
   kernel feature.
   
   This is not the default behavior, and will only be an issue for
   customers who have modified a system startup file to enable this
   feature.
   
   In a future 4.9.2 Rollup, we may add support for ISM use via this
   Solaris feature. However, since this is a product enhancement rather
   than a bug, there will be no one-off EBF.
   
   The EBF for 10.0.1 will be EBF 2917, not EBF 2594 as was reported in
   the 10.0.1 Release Notes.
   
   Here are answers to some common questions about this issue, followed
   by a summary.
   
   Common Questions and Answers
   
   Q: What is ISM and why is it important?
    1. ISM (Intimate Shared Memory) is an enhancement in Solaris 2.X
       which allows multiple processes to share certain low level data
       structures in the Solaris Virtual Memory (VM) system. These data
       structures are not normally shared and are used for
       virtual-to-physical address translation. These translation
       mappings are loaded into the hardware Memory Management Unit (MMU)
       as required. Sharing these data structures means that less loading
       and unloading of the MMU will be required during a context switch.
       
       
       Depending on the number of engines which are running and the
       overall system load, not having to load and unload the MMU can
       have a considerable positive impact on performance.
       
       One other benefit of using ISM is that the virtual memory is
       actually locked into physical memory by the operating system. This
       means that the Server has true control over what is in memory when
       doing memory management. It also means that a user starting up an
       editor or compiler won't steal memory from the Server resulting in
       the operating system throwing the Server memory pages out to the
       system swap space. Again, this can have a considerable positive
       impact on Server performance.
    2. I assumed that as long as the Server would start up (with the Sun
       patch installed), we would see no more panics, regardless of
       whether or not the EBF is installed. Is that correct?
    3. If you have the Sun patch installed, this particular panic
       condition will not occur. User applications such as our Server
       aren't an issue. Our EBF is only required to allow for the change
       in the shmat() system call behavior to allow the Server to boot.
    4. Do you foresee any major system performance issues involved with
       the _EBF?_
    5. No. There may be two extra shmat() system calls at Server boot
       time, the performance affect of which is negligible and only a
       one-time occurrence. Of course, the Server may not use ISM in some
       instances which will affect performance. For example, right now
       the OS is letting you use ISM even when it can't lock down the
       memory. It shouldn't do that because the system will later panic
       when it tries to unlock the pages. However, you do get the
       benefits of ISM at the cost of system panics. With Sun's fix, you
       won't be using ISM as the system will be able to detect that it
       can't lock down the memory. This could have a very visible impact
       on performance. It is preferable to configure the Server to use an
       amount of memory which will allow for ISM use. No Server EBF is
       required in this case.
    6. We have received and installed a patch from Sun 101318-35+ which
       is supposed to fix Sun's half of the problem. The engineer with
       whom I spoke said that the Sun patch would not stop the panics. He
       said that only applying a Sybase EBF or changing an ISM
       configuration parameter would stop panics.
    7. This is incorrect. No user application can panic an OS. All our
       EBF will do is to allow the Server to boot.The ISM parameter the
       engineer referred to probably simply turns off ISM use altogether.
    8. The Sun engineer said that the ISM configuration change would slow
       Sybase performance appreciably and that another customer
       experiencing the same bug had chosen not to make the change.
    9. The only performance implication is that the Server won't use ISM
       if the Solaris kernel cannot lock down the memory as it needs to
       in order to prevent a later system panic.
       
       It's a simple question of resources. SQL Server 10.0 can use an OS
       feature such as ISM if the OS can supply the resource. Whether or
       not the OS can supply the resource depends on how the Server is
       configured. That is, you can't configure the Server to use 256MB
       of memory on a machine with only 128MB of physical memory and
       expect it to use ISM. If the Server won't start after installing
       the Sun fix with a given memory configuration value, then decide
       whether you want to decrease the memory to the point at which it
       will still use ISM, or if you want to skip the use of ISM
       altogether. If you choose the first option, you can use the stock
       Server and Sun's patch and your system shouldn't panic unless
       there are other Solaris bugs showing up. If you choose the second
       option, then you probably need EBF 2594 (or 2917, depending on
       your Server version).
       
       You should certainly decide whether you want to use ISM or not and
       configure memory usage accordingly. Sybase Technical Support
       recommends configuring memory to a point where ISM can be used so
       that the Server truly has control of paging activity.
       
   
   
   Summary
   
   In all cases, customers should install version 35 or later of Sun
   patch 101318. If you are running version 4.9.2 of SQL Server, you must
   not force ISM use through the Solaris kernel. If you are running a
   System 10 Server and want to use ISM, you must configure the Server to
   use an amount of memory that the Solaris kernel can lock into physical
   memory. No EBF is needed in this case. If you would rather skip ISM
   use and want to configure the Server memory to a value too large to be
   locked down by the Solaris kernel, then you'll need EBF 2594 or 2917.
   
   Generally speaking, it is preferable to configure the Server to use
   ISM memory rather than running either EBF. If the non-EBF Server will
   not boot after installing the Sun patch, the sp_configure value for
   memory is set too high. To allow for ISM use and get the Server to
   boot, configure the Server to use memory equal to 90 percent of the
   physical memory in the machine. If the Server still will not boot,
   decrease the requested memory in 10 percent increments until the
   Server will boot. 
   
Important Differences in Interfaces File, TLI vs.Sockets

   
   
   Customers who receive the Release Bulletin for Solaris 2.x (SunOS
   5.x), under the section 2.4 "Installation Compatibility" find the
   following information:
   
   2.4.3. Migration from SunOS 4.x(BSD) to SunOS 5.x(SVR4) Avoid sharing
   interfaces files among servers and clients running on different
   operating systems. If your SQL Server and all of the machines on your
   network formerly ran on SunOS 4.x, the migration of some of the
   machines to run on SunOS 5.x creates a heterogeneous network
   environment.
   
   The executable files created on SunOS 4.x will not run on SunOS 5.x,
   and file locations and formats will be different. When you create an
   interfaces file entry for a SQL Server running on SunOS 5.x, the
   interfaces file is written in TLI format, and any existing entries in
   the SQL Server's interfaces file are converted to this format. This
   article will explain some of the implications of this Release Bulletin
   entry.
   
   On Sun4 the interfaces file entries look like this:
   
   #
   _SQLSRV_SUN4_

        query tcp sun-ether barracuda 3060
>       tcp sun-ether barracuda 3060
        console tcp sun-ether barracuda 3061

   
   
   On Solaris, they look like this:
   
   #
   _SQLSRV_SOL_

        query tli tcp /dev/tcp \x00020bf482d6dcb8
        master tli tcp /dev/tcp \x00020bf482d6dcb8
        console tli tcp /dev/tcp \x00020bf582d6dcb8

   
   
   The hex translates as follows:
   
   \x | xxxxxxxx | xxxxxxxx | 0000000000000000
   
   | port # | network node address | trailing zeros (optional)
   
   In the above example, then, the port number would be 8383 (8384 for
   console) and the network node address would be 193.749.884.72.
   
   The conversion from "old" format to "new" or TLI format is done
   automatically by sybinit. It even saves a copy of the old file. Bear
   in mind that sybinit converts all the entries in the interfaces file,
   so don't try to share the interfaces file between the "old" and the
   "new" formats by making two entries in the file. The solution is to
   have separate interfaces files as indicated below.
   
   This is likely to be an issue only for customers that currently have a
   homogeneous environment of all SunOS 4 (Solaris 1) when they upgrade
   some hosts to SunOS 5 (Solaris 2). This upgrade will give such
   customers a heterogeneous network environment. In other words, the
   executable files from SunOS 4 will not run on SunOS 5, the locations
   of files probably will be different, and the file formats probably
   will also be different. You should be aware of this regardless of
   applications you plan to run. This may also be noticed more from the
   Client side than from the Server side.
   
   For the Server side it should not be a problem. The installation and
   conversion of interfaces file from SunOS 4 to SunOS 5 will be handled
   by sybinit. The new format for specifying host addresses for TLI is
   common on SVR4-based systems. If you have upgraded a host to SunOS 5,
   you will already be familiar with this method for specifying
   addresses.
   
   If client workstations are not being upgraded to SunOS 5 at the same
   time, client workstations must continue to execute SunOS 4 binaries
   and also use the old-style interfaces file. When client workstations
   are upgraded to SunOS 5, they will need to use the new-style
   interfaces file along with their new binary executables. 
   
Backup Server: Load from a Single Device of a Striped Dump

   
   
   Backup Server customers may wonder if it is possible to do a striped
   dump but then load from a single device. The answer is "yes", but only
   when the dump is to tape or floppy devices and those devices are
   local.
   
   Specific steps to do this are:
    1. Install the first tape to load and execute:
       
       load database <dbname> from `/dev/nrst0'
    2. Follow the prompts when Backup Server asks for subsequent
       
       mounts, issuing sp_volchanged as appropriate.
       
   
   
   sp_volchanged must be issued from a separate server login than the one
   doing the dump or load. SQL Server is not set up to pause in the
   middle of command execution, so the sp_volchanged command (which is a
   separate command) must be issued by a separate server session.
   
   Stripes may be loaded in any order, but if any stripe spans volumes,
   the volumes of that stripe must be loaded in sequential order. 
   
Backup Server Dump Tracking and Naming Strategies

   
   
   Different sites use different strategies for tracking dumps on a
   particular piece of media. One perfectly valid way is to put known
   labels on a group of tapes, and recycle them over time. If you do full
   dumps once a week, with transaction dumps in between, you could call
   them "xxx.monday", "xxx.tuesday", etc.
   
   How would you choose a particular dump to load? Use the file=name
   qualifier on the load command. Even if you choose not to name files
   when dumping, Backup Server prints the name of the file it mounts at
   each dump. Customers can (and should) write them down for future
   reference. You know which file to specify for the load because you
   have a convention for naming files, and/or wrote down the name that
   Backup Server printed. Here is a possible method:
    1. On dump, input the following:
       
       dump database foo to `/dev/nrst0' file='foo.dump'
    2. Input the following to load:
       
       load database foo from `/dev/nrst0' file='foo.dump'
       
   
   
   Subsequent transaction files will be "foo.x.1", "foo.x.2", etc. (where
   the "x" stands for "xact"). 
   
The Dangers of dump transaction with no_log

   
   
   In the Commands Reference Manual, under dump transaction with no_log,
   there is a warning message stating that you should only use this
   command as a last resort. But what exactly does "last resort" mean?
   What happens when you use the command? What should you use instead?
   And finally, if this command is so bad, why does Sybase provide it?
   
   Sybase Technical Support recommends that you dump your transaction log
   regularly. You must determine the dump schedule by the amount of
   logged activity your databases get, and how large your databases are.
   Some sites dump transaction monthly; some sites dump transaction
   nightly.
   
   _NOTE!_
   If you are running SQL Server 10.0, you may use sp_thresholdaction to
   dump tran automatically before space becomes critical; additionally,
   the Backup Server now ensures that tasks will not hang while dumps are
   in progress. Please see your SQL Server Reference Manual for more
   details. The remainder of this article applies only to sites running
   pre-System 10 versions of SQL Server.
   
   If you never dump transaction, the transaction log eventually fills
   up. SQL Server uses the log for recovery purposes. When the log fills,
   the server stops allowing transactions to go through, because it can
   no longer write to the log, and the server cannot recover unrecorded
   transactions. Inserts, updates and deletes hang. At this point, you
   can't even run most of the dump tran commands, because SQL Server logs
   these as well!
   
   This is the "last resort" situation that dump transaction with no_log
   was designed for. This command removes the inactive portion of the
   log, freeing up log space and letting database changes proceed, by
   writing no log records itself. This is why no_log runs when other dump
   tran commands can't.
   
   But think for a moment about the environment in which dump transaction
   with no_log is designed to run. All the changes being made to the
   database are hung. No transactions are occurring. So dump transaction
   with no_log does no concurrency checking. If you use dump transaction
   with no_log while changes are being made to the database, you run the
   risk of corrupting the database. Most often, these are reflected as
   813 or 605 errors.
   
   To remove the inactive portion of the transaction log while changes
   are being made to the database, use dump transaction with
   truncate_only. This command is written to the transaction log, and it
   also does the necessary concurrency checking.
   
   Both of these commands have warnings associated with them, which can
   be found in the Commands Reference Manual. Be sure that you understand
   the warnings and the instructions that accompany them before you use
   either command.
   
   Sybase provides dump transaction with no_log to handle a very specific
   emergency situation. To help ensure the integrity of your database,
   you should use it only as a "last resort". 
   
Hiding the isql sa Password from a ps Command

   
   
   How do you run isql scripts without having to specify the -Ppasswd
   option on the command line? Because the command line is visible from
   the ps command, running isql -Ppasswd is a security breach. In newer
   versions of SQL Server, we delete the password from the command line
   by copying it into an internal buffer and setting the password in argv
   to all blanks. Unfortunately, this technique does not work for all
   versions of UNIX; some versions of UNIX give the program a copy of
   argv, but display the original version in the ps output. Even on Sun,
   our method of blanking out the password on the command line does not
   provide security. If one uses the -c option with ps, it will print the
   original command line, not the copy that was given to the program. ps
   -e will show the password if it has been saved as an environment
   variable.
   
   There are two possible solutions to this problem, one for batched and
   another for non-batched sessions, both requiring that the isql
   password be saved in an external file.
   
   Method 1: Non-batched Sessions:
    1. Save the password in a file that is readable only by the owner,
       
       as follows (you need type this one time only, from the command
       line):
       
       cat > scratchfile mypassword ^D chmod og-rwx,u+rw scratchfile
    2. Run the session from the command line, or as a shell script:
       
       isql -Uusername <<EOSQL `cat $passwdfile` use db go select ... 
       
  .
   . go _EOSQL_
       
   
   
   isql will prompt for a password. The "<<EOSQL" tells the script to use
   all lines that follow as input to the isql command up to, but not
   including the line that begins with "EOSQL".
   
   Method 2: Batched Sessions:
    1. Create the scratch file as described above, and set the
       
       protections. Then run all scripts as follows:
       
       cat scratchfile | isql -Uuser -i script-file-name
       
   
   
   These methods should be secure enough for the majority of users, as
   they have the following properties:
     * The password never appears on the command line, which always seems
       to be open to security breach.
     * The location of the password will be known to anyone using ps, but
       they cannot see it because the file permissions have been set
       against them.
     * Users can run as many scripts as they like without typing their
       password for each script. All they must do is to follow the second
       method for all script executions.
     * The password is kept in a scratch file, privately controlled by
       the programmer using that method.
     * The programmer can change the password easily because it is
       changed in one file only.
     * The password is not hard-coded into script files which are shared
       by an entire organization.
       
   
   
Indexing Null Columns = Poor Performance

   
   
   Using an index on a column consisting of all (or mostly) NULLs causes
   very poor performance.
   
   Suppose you have a table with 638K rows x 200 bytes with an index on
   an int column which is all NULL values. A select in this table, using
   the index on the NULL column, takes over four minutes to say that no
   value in this column matches the where clause. If you change just one
   value from a NULL to a number, select takes only three milliseconds to
   return, although inserts (and updates) still take exceedingly long.
   This only happens with a clustered index on this column; if the index
   is nonclustered, it seems to run fine.
   A clustered index on over 600K rows of NULLs means that it is all on
   overflow pages. These are sequentially scanned, since they are all the
   same value. The long insert time is spent deciding where in the sea of
   NULLs to put the next row. Any design that uses a clustered index on a
   mostly NULL column should be reconsidered. 
   
When an Index "Covers" a Query

   
   
   Customers have asked if SQL Server will use an index to satisfy a
   query if all the columns requested by the query are contained in that
   index, rather than reading the columns from the data table.
   
   As of the 4.9.2 release, a non-clustered index will be used when all
   the columns of the table referenced in the query are in that index. In
   such an instance, the index is said to "cover" the query. What this
   means is that before the 4.9.2 release, an index would only be used
   with a qualifying clause (such as a WHERE clause). This example is
   from a production 4.9.1 version of SQL Server:

        1> select au_lname from authors
        2> where au_lname = "Ringer"
        3> go
        STEP 1
        The type of query is SELECT
        FROM TABLE
        authors
        Nested iteration
        Index : aunmind
        1> select au_lname from authors
        2> go
        STEP 1
        The type of query is SELECT
        FROM TABLE
        authors
        Nested iteration
        Table Scan

   
   
   Since 4.9.2, even a simple SELECT FROM table will use the index if the
   SELECT is from an indexed column, as in this example from a production
   4.9.2 version of SQL Server:

        1> select au_lname from authors
        2> go
        STEP 1
        The type of query is SELECT
        FROM TABLE
        authors
        Nested iteration
        Index : aunmind

   
   
   4.9.1 SQL Server EBFs above 1690, that bring the Server to the 4.9.2
   level, also have this feature.
   
   If there is more than one index that covers a query, the smallest will
   be used. Also, since a non-clustered index has at the bottom of its
   tree one index row for each data row, the index will also be used for
   a simple SELECT COUNT(*) FROM enormous_table query. 
   
How to Generate Sequential Keys for Table Key Columns

   
   
   Many customers wish to generate sequential, unique keys for a key
   column in a particular table. The objective is simple, to be sure each
   key is unique. This implies the following:
     * The key must be updated by each user accessing it.
     * The table containing the key must be locked during update, so
       
       that no duplicates may occur. In System 10, you can both create
       new tables with the new IDENTITY column, and add the IDENTITY
       column to existing tables. The next issue of this newsletter will
       explain this new column in more detail. For Server releases before
       System 10, there are a number of possible methods for generating
       sequential keys; this article will illustrate only one of the
       possible options.
       
       The basic idea here is to use one table as the storage area for
       the sequential key as it is generated and modified. This key can
       then be selected into a key column in the appropriate table.
       
       For example, first create the storage table, which will contain
       one column and one row:
       
       1> create table KeyStorage (NextKey int) 2> go 1> insert
       KeyStorage values (0) 2> go (1 row affected) Here is a sample
       table that will be the eventual destination of the keys.
       
       1> create table foo (key int, text char(5)) 2> go First, we update
       the stored key, conveniently locking it against other users in the
       process:
       
       1> begin tran 2> go 1> update KeyStorage set NextKey = NextKey + 1
       2> go (1 row affected) A simple check shows the table is now
       locked (this list has been edited slightly to save space -- many
       other locks may exist):
       
       1> sp_lock 2> go spid locktype table_id page dbname
         _____________________________________________________________
       
       1 Ex_page 5 894 master ... 1 Ex_table 640005311 0 foo (26 rows
       affected, return status = 0) 1> select object_name(640005311) 2>
       go
         _____________________________________________________________
       
       KeyStorage (1 row affected)
       
   
   
   Now you can select the new key safely, and insert it into the target
   table:

        1> declare @newkey int
        2> select @newkey = NextKey from KeyStorage
        3> insert foo values (@newkey, `test')
        4> go
        (1 row affected)

   
   
   Remember to commit tran!
   You can test to be sure the insert worked:

        1> select * from foo
        2> go
        key                     text
        -----------             -----
        1                       test
        (1 row affected)

   
   
   You can generate the new key by stored procedure, thus giving at least
   reasonable assurance that the key continues to be incremented by one.
   Put the begin transaction statement in the stored procedure -- SQL
   Server will remind you that you must commit the transaction "by hand":

        1> create procedure get_newkey as
        2> begin tran
        3> update KeyStorage set NextKey = NextKey + 1
        4> go
        1> exec get_newkey
        2> go
        Msg 266, Level 16, State 1:
        Server `REL492_SUN4', Line 1:
        Transaction count after EXECUTE indicates that a COMMIT or
        ROLLBACK TRAN is missing. Previous count = 0, Current count = 1.
        (return status = 0)
        1> declare @newkey int
        2> select @newkey = NextKey from KeyStorage
        3> insert foo values (@newkey, `test2')
        4> go
        (1 row affected)
        (1 row affected)
        1> commit tran
        2> go
        1> select * from foo
        2> go
        key                     text
        -----------             -----
        1                       test
        2                       test2
        (2 rows affected)

   
   
   Other portions of this method may be automated as desired by the more
   meticulous DBA, but the basic method remains simple and
   straightforward. 
   
Timestamps Will Roll Over

   
   
   Tech Support customers asked us, "Is the value of a timestamp
   guaranteed to be monotonically increasing within a database?"
   
   These customers wanted to use a timestamp field to identify rows that
   have changed since the last time they looked, with a where clause like
   where timestamp > @previous_timestamp.
   
   The wanted just to add a timestamp field to their existing tables, so
   that SQL Server would maintain the values, and they wouldn't have to
   change any of their own code to identify newly inserted/updated rows.
   (Deleted rows would need to be treated differently.)
   
   The answer is that the timestamp is not guaranteed to increase
   indefinitely. A timestamp is a 56-bit integer that will eventually
   roll over, though it takes a very long time to do so. The only numbers
   that won't roll over are ones with unbounded storage; there is no such
   datatype in SQL Server.
   However, Sybase does guarantee that if the row has changed, the
   timestamp will differ from the one in the cached copy of the row. 
   
SQL Monitor Client/Server and SQL Server Compatibility

   
   
   The following table is a compatibility matrix for various SQL Monitor
   Client, SQL Monitor Server and SYBASE SQL Server versions.

SQL Monitor Client       |  SQL Monitor Server  |  SYBASE SQL Server
UNIX -- sqlmon           |                      |
PC -- servmon.exe        |       monserver      |      dataserver
=================================================================
any UNIX version 10.0.1  |         4.9.1        |  4.9.1 or 4.9.2
-----------------------------------------------------------------
any UNIX version 10.0.2* |         4.9.1        |  4.9.1 or 4.9.2
-----------------------------------------------------------------
PC version 10.1.0        |         4.9.1        |  4.9.1 or 4.9.2
-----------------------------------------------------------------
PC version 10.1.2*       |         4.9.1        |  4.9.1 or 4.9.2
-----------------------------------------------------------------
any UNIX version 10.0.1, |        10.0.0        | 4.9.1, 4.9.2 or 10.0.0
                  10.0.2
        (monserver 10.0.0 can monitor a 4.9.x SQL Server but must have
        a SQL Server 10.0.0 directory installed)
-----------------------------------------------------------------
PC version 10.1.0        |  10.0.0 for Sun4,    | 4.9.1, 4.9.2, or 10.0.0
                         |  Solaris, NCR, AIX   |
                (this row not certified but can connect)
        (monserver 10.0.0 can monitor a 4.9.x SQL Server but must have
        a SQL Server 10.0.0 directory installed)

   
     _________________________________________________________________
   
   PC version 10.1.0, 10.1.2| 10.0.0 EBF 2714, | 4.9.1., 4.9.2, or 10.0.0

                         |      HP only         |
(this client will now connect)                  |
-----------------------------------------------------------------
PC version 10.1.2*       | 10.0.0 for Sun4,     | 4.9.1, 4.9.2, or 10.0.0
                         | Solaris, NCR, AIX    |
-----------------------------------------------------------------
any UNIX version 10.0.1, |        10.0.1*       | 10.0.1*
                  10.0.2 |                      |
-----------------------------------------------------------------
PC version 10.1.2        |        10.0.1*       | 10.0.1*
     * = available Q2, '94
       
   
   
   The current PC SQL Monitor Client is not certified against any 10.0.0
   SQL Monitor Servers. There are pieces of data that are unmonitorable
   with this configuration, for example the Device I/O and Network
   Traffic graphs in the Performance Summary and Performance Trends
   windows will display `0'. The PC SQL Monitor Client 10.1.2 (due in May
   1994) addresses this and will be certified against 10.0.0 Monitor
   Servers.
   
   The version of Monitor Server should go hand in hand with the version
   of SQL Server. If you need to monitor a 10.0.1 SQL Server, get a
   10.0.1 Monitor Server; use a 4.9.1 Monitor Server to monitor a 4.9.x
   SQL Server.
     * HP Monitor Server 10.0.0 EBF 2714 enables PC clients to
       
       connect successfully to it.
     * Solaris Monitor Server 10.0.0 EBF 2715 enables re-starting
       
       of the Monitor Server while remote client connections are still
       connected to it.
     * AIX Monitor Server 4.9.1 EBF 2496 corrects a problem
       
       resulting in 100% CPU usage.
     * HP Monitor Client 10.0.1 EBF 2507 eliminates dependency on
       libC.sl.
       
   
   
   The following table shows combinations that will not work, nor are
   they intended to:
   
   SQL Monitor Server | SYBASE SQL Server
     _________________________________________________________________
   
   
   
   4.9.1 | 10.0.0 (this combination may work, but is not certified)
     _________________________________________________________________
   
   
   
   4.9.1 | 10.0.1
     _________________________________________________________________
   
   
   
   10.0.1 | 10.0.1
     _________________________________________________________________
   
   
   
   10.0.1 | 4.9.x or 10.0.0 
   
SQL Monitor Memory Allocation

   
   
   SQL Monitor Client, upon initial start-up, may cause a noticeable
   strain on heavily loaded SQL Servers or SQL Servers configured for
   large size. The strain is due to the client trying to construct the
   Memory Allocation Chart that occurs by default on UNIX clients and
   upon request on PC clients.
   
   New connections to the SQL Server may hang, currently running tasks
   may temporarily hang, and the SQL Monitor Server may automatically
   shut down, on the assumption that the SQL Server has also shut down.
   See the following information to prevent this automatic shutdown.
   
   If this strain is noticeable and unacceptable, then request that the
   Memory Allocation Chart not be created.
     * For UNIX clients: invoke sqlmon with the -nomem flag on the
       
       command line.
     * For PC clients: do not select the Obtain memory allocation
       
       check box option.
       
   
   
   Additional Command Line Options for UNIX & VMS
   
   To prevent SQL Monitor Server from automatically shutting down, the
   time interval that the SQL Monitor Server checks to see if the SQL
   Server is active needs to be increased. The default configuration is
   120 seconds. To change the interval, you must use an undocumented
   monserver command line parameter (which is supported, and will be
   documented in upcoming releases of the manual).
     * For UNIX, the parameter is -L<config file>, where <config
       
       file> is a file in the current directory that contains only this
       line:
       
       heartbeat_interval nn where nn is a value in seconds.
     * For VMS, the parameter is /localconfig=<config_file> where
       
       <config_file> would have the same line in it:
       
       heartbeat_interval nn
       
   
   
   For example, to start up a SQL Monitor Server that will poll every 10
   minutes for the presence of its SQL Server, the UNIX command is:

        monserver -Usa -Ppassword -MMON_1001 -SSYB_1001 -n5 -0 \
        -Lmonserver_config_file &
where monserver_config_file has the following line in it:
        heartbeat_interval 600

   
   
   One drawback to using a large time interval is that when the SQL
   Server actually does shut down, the SQL Monitor Server will remain
   running longer, and will be holding onto the SQL Server's shared
   memory segment. You may need to shutdown SQL Monitor Server manually
   in order to start SQL Server again. 
   
Net-Gateway Security

   
   
   Administrators considering the issue of Net-Gateway Security must ask
   themselves two questions:
   
   First, do I want to pass some flavor of userid and/or password to the
   Mainframe? And second, if so, which userid and password should be
   passed?
   
   First of all, you can pass a userid and/or password to the mainframe
   over Net Gateway via the sgw_addrpc stored procedure:
   
   exec sgw_addrpc rpc_name, tran_id, remote_lu, security
   
   The security parameter has one of these three values:
     * none -- no userid or password will be passed to CICS.
     * userid -- userid only will be passed to CICS.

        NOTE! If you specify userid and you are running the Net-Gateway
        on OS/2, be aware of the interaction with OS/2's Communication
        Manager. Examine the NFG file (in the \cm\appn subdirectory)
        that describes your network to the Communication Manager; check
        the DEFINE_PARTNER_LU entry corresponding to your host and be
        sure that the configuration allows CONV_SECURITY_VERIFICATION
        with the right remote LU.

o       both -- both userid and password will be passed to CICS.

   
   
   So, having chosen userid or both under the security parameter, you are
   ready to decide which userid (and, optionally, which password) is to
   be passed. There are three possible choices, two associated with user
   login, and one with transaction grouping. Notice the syntax of the
   following procedures:

        exec sgw_addlog login,                  <-- source-1
        pwd,                                    <-- source-1
        host_login,                             <-- source-2
        host_pwd,                               <-- source-2
        tran_group, con_group, gwctrl
        exec sgw_addtrngrp tran_group,
        group_login,                            <-- source-3
        group_pwd,                              <-- source-3
        langrpc, langpwdlevel
        exec sgw_addrpctogrp tran_group,
        rpc_name, rpcpwdlevel

   
   
   Method 1: Taking userid/pwd from "source-1"
   
   If the Net-Gateway is started with the -O flag ("security Override"),
   the identifying information passed to the mainframe will be taken from
   the login and pwd columns of the user's Net-Gateway login record. That
   is, the identification by which the user logged onto the Net-Gateway
   (or upstream SQL Server, if any) will be propagated to CICS.
   
   Notice that all discussion involving "transaction grouping" or
   "connection grouping" -- that is, the security enforcement machinery
   of Net-Gateway itself -- becomes irrelevant when the security override
   is in effect. All security enforcement is deferred downstream to the
   mainframe (and upstream to the SQL Server, if any).
   
   Method 2: Taking userid/pwd from "source-2"
   
   If the Net-Gateway is started without the security override flag, each
   user must be associated with a "Transaction Group" in order to execute
   any RPCs on the Net-Gateway. The transaction group is tied to the user
   via sgw_addlog.
   
   RPCs are tied to the transaction group via sgw_addrpctogrp. Specify
   user as the rpcpwdlevel when you add an RPC to the transaction group,
   if you wish to pass on the values in the host_login and host_pwd
   columns from the user's login record as userid and password.
   
   Method 3: Taking userid/pwd from "source-3"
   
   Specify "group" as the rpcpwdlevel when you add an RPC to the
   transaction group, if you wish to pass on the values in the host_login
   and host_pwd columns from the user's login record as userid and
   password.
   
   Special Case: The Language RPC
   
   The Language RPC is executed whenever a user request is not an
   explicit RPC request. none, user, or group must be specified as the
   langpwdlevel when the Language RPC is associated with a transaction
   group via the sgw_addtrngrp stored procedure. 
   
Omni SQL Server and RMS Locking Strategy

   
   
   It is important for customers to understand the manner in which Omni
   SQL Server accesses RMS files, since often Omni SQL Server is used in
   an environment where other processes are accessing the same files Omni
   SQL Server is expected to access.
   
   When Omni SQL Server requires access to an RMS file, Omni SQL Server
   must first determine which access and share modes to use before it can
   open the file. Two separate attempts are made by Omni SQL Server
   before an open failure is reported. The first attempt is performed
   with all RMS access and share modes enabled, as follows:

        access = FAB$M_SHRGET | FAB$M_SHRPUT | FAB$M_SHRDEL | FAB$M_SHRUPD;
        share = FAB$M_GET | FAB$M_PUT | FAB$M_UPD | FAB$M_DEL | FAB$M_TRN;

   
   
   If the file cannot be opened using these access modes, then a second
   attempt is performed with the following access and share modes
   enabled:

        access = FAB$M_GET;
        share = FAB$M_SHRGET;

   
   
   If this access mode fails, then the open attempt will fail and Omni
   SQL Server will not be able to use the file.
   
   (In the above statements, access corresponds to an element in an RMS
   data structure called the File Access Block, or FAB. The element is
   named fab$b_fac. share corresponds to the element named fab$b_shr in
   the FAB).
   
   Once a successful open request has been performed on a file, the
   access and share modes are cached in memory so that the second time
   the file is opened, Omni SQL Server will not have to establish them
   again.
   
   It should be noted that this has nothing to do with the configuration
   parameter read regardless. This parameter determines Omni SQL Server
   behavior after a file has been opened, and an Omni SQL Server thread
   is attempting to read a record from that file. If read regardless is
   enabled (set to `1'), then Omni SQL Server will be able to read a
   record even if it is locked for exclusive use by another VMS process.
   Please refer to the Omni SQL Server System Administration Guide,
   Chapter 6, for a discussion of this configuration parameter. 
   
Bugs Fixed in Latest Rollup for 4.9.2 SQL Server

   
   
   The following is a list of bugs which have been fixed in recent EBF
   Rollups for the 4.9.2 SQL Server. (The EBF# at the top of each list is
   for the Sun4 platform.)
   The current EBF Rollups available now are: Platform | Rollup Number
     _________________________________________________________________
   

Sun4               |      2825
HP 9000 Series 800 |      2826
IBM RS6000         |      2827
NCR SVR4           |      2828
VMS                |      2829
Sun SVR4           |      2830
AXP VMS 1.5        |      2831

   
   
   Previous Rollups, released since the previous issue of Sybase
   Technical Newsletter, are specified in the tables below and consist
   of: Platform | Rollup Number
     _________________________________________________________________
   

Sun4               |      2359, 2560
HP 9000 Series 800 |      2360, 2561
IBM RS6000         |      2361, 2561
NCR SVR4           |      2362, 2563
VMS                |      2363, 2564
Sun SVR4           |      2364, 2565
AXP VMS 1.5        |      2365, 2566

   
   
   This list is not inclusive; only the fixes new and specific to this
   release, and introduced since the last publication in Sybase Technical
   Newsletter, are included. Some bugs which do not visibly affect
   product behavior have been omitted from this list for clarity. This
   information is also available on Insight and the OpenLine Sybase
   Compuserve forum.
   
   Bug Fixes New to Rollup 2359-2365
   
   Bug#
   Description
   51270
   `Process infected with 11' error can occur when using kill for a
   process which has a status of `send sleep'. 51269
   Error: 5150, Severity:16, State:1, occurs during attempts to switch
   from a failed mirrored device to good secondary device. 50912
   If a table contains at least 2 BIT-type columns and at least 1
   NULL-able column, the SQL Server will fail to send the table's log
   information to the Replication Server.
   50543
   If a server process dies when it has created a worktable, and locks
   have not been acquired on the worktable yet, the server can generate a
   stack trace and shut down.
   50263
   RPC causes multiple IO's thru one socket. This was causing corruption
   of the TDS stream.
   50111
   Writetext fails with 1127/1129 errors.
   50075
   When using isnull(rtrim(""),"TEST") we just get the first letter "T"
   instead of "TEST". This problem has been reproduced on System 10 GA
   50029
   Any correlated subquery containing a min or a max aggregate in the
   inner subquery on a binary or char type fixed column will not return
   correct rows when doing a join using the same table in the outer and
   inner query.
   49958
   Error 804 occurs when a non-sa user who belongs to a group that has
   been granted CREATE DATABASE permission issues create database
   command.
   49790
   System stored procedure, sp_spaceused, returns an arithmetic overflow
   on large tables, for example: 600000 rows, 70 meg. 49734
   Group by with lower on varchar column values returns an incorrect
   number of rows.
   49295
   Process infected with 11 error during null text update. The update
   statement will cause Segmentation violation 49294
   If the table has text column and a unique nonclustered index, then the
   direct mode update to that text field will result in 644 error. 49177
   A regression produced by bugfix 44623 broke `disk remirror'. 49082
   Error 8402 when using a union and a view that references another view
   on another database.
   49065
   When run, sp_reportstats receives: "Msg 232, Level 16 State 11: server
   `server name', Procedure `sp_reportstats', Line 67: Arithmetic
   overflow error for type varchar, value=0.003090. Arithmetic overflow
   occurred." 49011
   When a POLLNVAL error is received, the polling fd is not removed and
   this can result in continuous errors being sent to the errorlog for
   the same fd.
   49005
   Server does not prevent a raw mirror device from being used to mirror
   two primary devices.
   49002
   When a non-clustered index is chosen for a temp table, index name is
   not getting printed in the `showplan' output. 48964
   Kill command does not work for tasks that are not sleeping under one
   of the valid conditions. The old semantics allowed these processes to
   get killed provided they woke up.
   48882
   @@rowcount does not have correct value for an update statement when
   the update involves a join, and @@rowcount is referenced upon entering
   an update trigger. The value is much higher than the actual number of
   rows updated.
   48505
   Frequent POLLERRs are reported in the errorlog. Error handling needs
   to be enhanced inorder to explain cause of error. 48273
   Msg 611 "Attempt made to end a transaction that is idle or in the
   middle of an update" when an attempt to create a temp table (from
   within a stored procedure) aborts on an interrupt. Happens for alter
   table which involves temp table from within a sproc. 48169
   After a LOAD TRANS is performed, the value of the generation ID of the
   log records sent to the Replication Server should be preserved and not
   reset to zero.
   48034
   When dropping and recreating the temp table, any store procedure using
   that table will not be able to find it during opt/compile time and
   thus using the default values for number of rows and columns. Bug:
   Range table must be updated to the new tmp_def_id. 47989
   Certain queries take significantly longer to compile under 4.9.1/4.9.2
   compared with production 4.8, as a result of many more join strategies
   being considered.
   47984
   Server can kill process or otherwise mishandle connection if cancel is
   received while sending data to client.
   47909
   Speed up communication with a remote server (at the expense of i
   ncreased network traffic) by setting the TCP_NODELAY flag. This fix is
   only applicable to operating systems using sockets, not TLI. 47826
   Buildmaster -m now requires -s option also. If it is not given,
   installmaster cannot run because it cannot alter master db on master
   device.
   47694
   During weekly dump to disk file, dump database task hangs. No errors
   are reported.
   47614
   When the PROBE process is invoked from a task running on a
   single-engine server which is both participating in, and is the commit
   server for, a distributed transaction, then the server may go 100% CPU
   bound and all user activity on the server will hang. 47361
   Server stacktraces on the qry 1)create table t(a float) 2)select
   str(avg(a)) from t. This because we are adding an implicit conversion
   node between two same type of nodes (FLT8). This happens for `real'
   datatype also.
   47354
   When 512 error is raised and a dynamic index has been built, the
   current process is infected with 11, errors 605/6103 are raised during
   the rollback in tempdb. Any further attempt to access the tempdb page
   listed in the 605 error will return an 813 error. 47300
   After receiving an 823 error (IO error) on a disk read, 605 errors
   occur thereafter whenever the same page is accessed. 47298
   Certain doubly-nested subqueries can result in the thread being
   infected.
   47294
   Grant/revoke fails with stack trace and kills process when the same
   user is included twice in the user list. e.g., grant execute on sproc
   to user1, user1. Server should be more friendly to user than killing
   him & dumping ugly stack to errorlog.
   47129
   noobhandler has a forever loop which can fail to terminate if ioctl
   doesn't return the expected value. We should also check for no data on
   the socket.
   46896
   Group by on 16 columns and distinct expression in the select list on
   17th column causes error 415 to be raised 46629
   Upgrading from 1225 to 1614, get more logical read on worktable for
   the same query. Applies to OR strategy when only one row qualifies.
   46059
   When a create index deadlocks, the descriptor information (doampg,
   first, root) may not be restored properly, leading to 605 errors.
   44635
   If a table exists with multiple bit columns, and an update trigger is
   tied to one of the bit columns, an update to any of the bit columns
   will cause the trigger to be fired.
   44598
   Getting Msg 806 and stack traces when doing "commit tran". 44129
   Bugid 24506 has caused regression by raising 157 error even for
   standard queries
   43990
   If enough objects are created in a d.b. to cause the root page of
   index ncsysobjects to split, and then sp_dboption for autotrunc log is
   issued against that d.b., and the server is rebooted before checkpoint
   in d.b., dropping objects results in 644 errs. 43427
   Getting Msg 1265 followed by Msg 804 and stack trace when trying to
   delete or update tables with non-clustered indexes. 42459
   An application using two dbprocs concurrently can become blocked
   eventhough the two tasks hold compatible locks. sp_lock will show that
   the second task is blocked by a (compatible) lock held by the first
   task.
   41886
   Msg 8412 and stacktraces when using "create table" and "select for
   browse" statements in the same batch..
   37006
   Message 5704 is getting printed even if the client and server
   character-sets are same and they don't need char-set conversion. This
   should be suppressed in those situations. 36524
   Sysindexes First entry is not accurate. 33871
   smalldatetime does not accept format <num> <sep> <num> <sep> etc. that
   datetime does, in an implicit convert. gets syntax error. 32183
   "the statement ""create clustered index index_name on table (column)
   with sorted_data, allow_dup_row"" generates error 1508 and does not
   create the index when a duplicate row is encountered" 31915
   A select query with union having a compute list at the end gives Msg
   411.
   27640
   Queries containing correlated subqueries other that IN or ANY that
   appear under an OR get incorrect results if there are no matching rows
   from the outer query.
   27452
   SELECT INTO from a user table to a temporary table that converts a
   character column datatype to a tinyint datatype results in an "intn -
   length 1" datatype which is incorrect. It should be a tinyint. 17271
   An aggregate query that does an `exists' subquery will sometimes
   return the wrong answer if there are duplicates. 13495
   In many cases, we process subqueries as joins where it gives the wrong
   answer. Existence checks should not be done as joins - they return
   dups where they should not, and the construction OR x in (select a
   from b) will not work when b is empty.
   
   Bug Fixes New to Rollup 2560-66
   Bug#
   Description
   53601
   I/O errors can lead to infected processes or erroneous 821 errors.
   53118
   Allow for load to continue with a warning message if the dump was done
   prior to bugfix #52181, stop the load otherwise. 52943
   Modification to bugfix #51454 to handle str(-0.483700,10,2) correctly
   on hp800, ncr_svr4, avms & vms platforms. 52850
   Recompiling a stored procedure which creates a table results in a 3703
   error with stack trace.
   52530
   On tli based platforms, clients can hang after receipt of a POLLERR,
   POLLNVAL or POLLHUP on any connected socket. It is also possible that
   no new logins will be accepted.
   52447
   Update Message #277 to reflect bugfix 19418. 52406
   During OAM cleanup, pages being unlinked and deallocated are not
   unkept resulting in 803 errors, stack traces & the need for a server
   reboot. 52332
   gets message kernel: nrpacket: t_rcv(). no message currently
   available. The site handler hangs and no further rpcs can be made.
   52181
   4308 errors(State: 4), intermittently occur when doing a load
   transaction or load database. This can only happen if the dump was
   made when the server was very active.
   52179
   A server panic (ulowncheck) occurs if a load transaction is done while
   running the diagserver.
   52060
   When recompiling a system stored procedure while in a user database,
   the sysdepends table in the user database gets updated instead of the
   sysdepends table in the master database. 51959
   Site handler tasks may hang under heavy RPC load between Open Server
   and SQL Server. This can result in all logical connections hanging.
   51946
   Modification to bugfix #51454 to handle str(float) correctly. 51893
   If the SQL/LTI thread has reached the end of the log and is sleeping
   waiting for more log records to be written, a timeslice error will
   occur if the SQL/LTI client receives a network attention. 51892
   The VMS implimentation of the SQL Server's Replication Server Support
   Facility (RSSF) does not correctly set the internal SQL Server bitmap
   which indicates to the RSSF which log records should be sent to the
   Replication Server.
   51804
   Correct stack trace produced by calling a stored procedure which
   performs a select from a view based on a database in another database.
   51725
   A space in an image column of a `bcp' file causes a NULL to be
   inserted into the table. Subsequent deletion of row(s) from that table
   will result in 605 errors. The deletion operation should be done
   before the update to the text/image column.
   51701
   The process that holds the update page lock also holds an ex_page
   lock. This is sets up a deadlock case.
   51595
   Modifications to datetime.h to include some ot the new defines.
   Required for bugfix #51191.
   51508
   If the server process dies when executing a query with an OR that
   creates a worktable, a stack trace occurs and the server shuts down.
   51454
   The str() function has been re-written to give percission of upto 6
   decimal places.
   51240
   Return status from optlookip() was not correctly checked. As a result,
   the parser was considering anything after the constant token as an
   option.
   51215
   In rollup 1790, certain kinds of aggregate subqueries, with one or
   more views, may generate a different access plan. Typically, table
   scans are generated inspite of a useful index being present.
   Performance of such queries can be very slow.
   51191
   Modify millisecond arithmetic from 1/300th of a second precision to
   1/1000th of a second.
   51174
   SQL Server error 513 can occur upon Domain rule checking. This will
   Only occur if there is an implicit server datatype convertion between
   the datatype to insert and the datatype for the column referenced
   within the table.
   51072
   Timeslice errors will occansionaly occur while compiling and executing
   queries. A typical stack trace will have s_mustrecompile in the stack
   frame.
   50911
   Unbalanced transactions occur in the syslogs table at times when a
   stored procedure is recompiled. This can cause the replication of the
   database via the replication server to fail. 50786
   When estimating the cost for join density, we want to exclude NULL
   values if any keys in the set is NULL. This will make the selectivity
   much smaller for a table that has a lot of NULL key-rows and thus
   optimizer will use index instead of table scan. 50783
   Correct several 821 & 605 error situations by saving page hdr before
   calling bufpagedestroy().
   50781
   Errors 226, 277 & 266 have been reported when running a stored
   procedure that calls another one which has been dropped then
   recreated.
   50499
   Initialize the "victim" when using trace LOCKM,4. 49653
   Network checking delays can occur on heavily used servers even if the
   platform supports SIGPOLL notification. 49505
   Fix to do proper `round'ing when the number of integral digis in
   numeric_expr is equal to the negative of the number specified in the
   integral_expr (eg. round(5550.00, -3)). 49010
   REUSEADDR should not be set in nopen(), as we are not specifying the
   local address for the new endpoint; it is being chosen for us by the
   network provider.
   49009
   The event handling code after the t_accept() in nopen() is flawed. It
   doesn't recognize when the currently active connection request has
   disconnected and can thus result in issuance of a t_accept which won't
   be successfull.
   49008
   The event handling code after the t_listen() in nopen() is flawed. It
   incorrectly assumes that a disconnect event will clear the currently
   alloc'd T_CALL struct which results in another t_alloc, wasting the
   initial con_req and T_CALL struct.
   49007
   The errors reported within nopen() are not clear and cause alarm at
   customer sites without lending insight into the problem. 48886
   When processing connection requests, no further polling should occur
   on a given listener endpoint until all current connection requests
   have been satisfied.
   48197
   When the server multiplies a negative floating point number to a
   floating point zero, it evaluates to a negative floating point zero
   and stores it in the row. Subsequently, all qualifier with positive or
   negative floating point zero fails to select row 47615
   A large sproc contains a syntax error towards the end (missing , on
   2nd to last field in insert statement) isql fails to report any errors
   and does not create the sproc
   47301
   The linger option is not set on client sockets resulting in loss of
   data if the server closes the connection before the client has
   finished receiving sent data.
   44329
   With a very heavy update load on the system, it is possible for alll
   processes accessing a particular database to hang on disk i/o. This
   may occur more frequently if the DB has the `trunc. log on chkpt'
   option turned on.
   43595
   Certain selects with subqueries can result in infected processes.
   39688
   Correct 203 error (sysdatabases not found) when `ins_syn_sql is run.
   36963
   If `select *' is present in both aggregate subqueries participating in
   an OR clause, the we seem to combine both of them together even if
   they reference different tables. This produces incorrect results in
   some situations.
   
   Bug Fixes New to Rollup 2825-31
   Bug#
   Description
   54191
   Temporary tables are not automatically dropped when a stored procedure
   returns. This may cause 2714 errors.
   54126
   When the SQL Server re-uses some structures it is possible that Msg.
   7134 errors may occur.
   53896
   The upgrade application needs to be modified to not perform the
   upgrade of the `upgrade version' to `493' until the actual maintenance
   modifications are made.
   53699
   Added missing or modified error messages to upgrade.c as reported in
   bug 52666. Included: 305,595,596,2778,2780,6108,6227,8010,7719,
   17965,17966. Also verified 9119,9139,9141,9123,9138,9137,4403. 53603
   Errorlog gets "kernel: nrpacket: t_rcv(), No message currently
   available"
   53563
   [REPSRV] Add comments to `include/trace.h' which document existing
   LTUTIL trace flags.
   53494
   This problem is observed for triggers getting renormalized immediately
   after load database which results in the updating of sysprocedures
   being done in the same user transaction 53492
   Cannot print the stack of a sleeping process. 53356
   SQL queries using text/image column in a where clause which is part of
   an OR clause can cause 7134 or 804 errors. Example: select id from
   table1,table2 where txtcol not like "% " or intcol not null. 53234
   The SQL Server unexpectedly unreserves the database's LTCONTEXT while
   the LTM is still actively scanning the database's log. A 9120 SQL
   Server error will be generated causing the LTM to shutdown. 53163
   select col1, diff1 = sum(datediff(dd,col2,@var1)), diff2 =
   sum(datediff(dd,col2,@var2)) from tab group by col1" produces the same
   value for both of the sums when run from a stored procedure. Also
   sometimes fails for adhoc queries.
   53068
   Certain XACTs generate duplicate key errors when applied to the
   replicant SQL Server (via the Replication Server) even though the same
   XACT did not generate duplicate key errors when originally applied to
   the primary SQL Server.
   53053
   Exceptions generated while within the RPC relay code could cause a
   signal 10 in the user process. This was most noticeable in the
   handling of the attention signals (CTRL/C).
   52870
   os_create_keyfile should have enhanced error messages to better
   explain what "Segment {segmentname} is in use" means. It should better
   reflect a conflict that could involve removing these files if the
   server is not currently running due to an
   52705
   In file instmsgs.ebf, for message 6227 there is a typo in line which
   drops message from german catalog. It has been written as 6627. 52704
   When a st.proc references a view, and the view/underlying table is
   dropped and recreated, executing the st.proc can result in wrong
   columns being returned.
   52695
   Server crashes due to stack corruption and stack guardword corrupted
   message while trying to do select into a table from a view whose
   underlying table is dropped and recreated with different schema. 52666
   Provide new 277 error message text for upgrade. 52651
   The SIGURG & SIGIO is set for all processes within the same process
   group instead of just the server process. 52629
   During update of a text col if error 7105 is raised we print
   "TEXT/IMAGE page 0 does not have a next page, although it should"
   based on pnextpg field. We should rather print the page # which has
   the problem (broken text chain).
   52371
   Attention packets received while processing multiple connection
   requests can lead to the scheduler process becoming infected. Stack
   trace output shows signal 11 occuring in nmskget called from
   nrecvattn.
   52268
   insert into table1 select string from table2 order by table2.column
   inserts bogus characters into table1 when there is a clustered index
   on table2.column
   52199
   Improper synchronization of cancel processing with outstanding I/O's
   could result in channel closure before I/O completion. 52190
   1129 errors may occur due to a MP window in page allocation. 52129
   Assuming procedure proc1 call proc2 and view view1 is built on view2.
   when ownership chain is not broken, explicit revokation on proc2 will
   raise error 229 when user executes proc1, while after explicit
   revokation on view2 user can still select on view1. 52059
   Data translation for type float between certain platforms (depending
   on byte-swapping) is done incorrectly and gives unexpected results.
   52030
   Dumping database to disk can be aborted with "dbsspacket, write
   interrupted system call" message.
   51785
   When using a order by or a group by clause that creates a work table
   and the query has an assignment to a local variable the server crashed
   and kills the session.
   51712
   MP Configurations use clock interrupt to periodically wakeup secondary
   engines to find work. However, since clock interrupts are tied to
   actual CPU time consumed, secondary CPU's which are idle are not woken
   up as often as required.
   51389
   When a smalldatetime is used in a rule, the rule may work incorrectly,
   by either reporting a rule violation when there should not be, or not
   reporting when there should be.
   51287
   Incorrect arguments are passed to ex_callprint routine to report error
   7220 "Site `%s' not found in interfaces file." resulting in cryptic
   message "Error: 72, Severity: 20, State: 11". Error 502 must have the
   same problem.
   47467
   With an empty table that has an index on a char column, if the sort
   order is changed on the server and then dbcc reindex is run, an error
   is received on the subsequent select indicating that the index is
   suspect. If table has a row then all is fine 47049
   Share memory segment sizes on IBM AIX 3.2 are limited to 256MB, this
   limits the maximum size of memory that Sybase can use on a machine.
   45962
   If an insert or update query that has a subquery which can return
   null, the query inserts or updates columns that are not supposed to
   have null.
   41730
   "kernel: nspacket: send, Invalid argument" messages in the errorlog.
   34889
   821 error is not useful, and renders server unusable. 821 often occurs
   after 605 errors and prevents other user processes from obtaining a
   free page.
   26285
   Trigger attempts to query inserted/deleted table for textdata using a
   builtin "datalength" leading to a 605 error. This is no corruption but
   the user connection gets disconnected.
   22150
   Correlated subqueries returning count(*) do not return values where
   the count is zero.

                                    Q10.1.2
                                       
Technical News Volume 3, Number 3 August, 1994

   
   
   Document ID 50005-1-0300-03
   
   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. Keep this newsletter
   with your SYBASE Troubleshooting Guides. All issues of the Sybase
   Technical News and the Troubleshooting Guides are included on the
   AnswerBase CD.
   
IN THIS ISSUE

     * Technical Support News/Features
          + Communicating with Technical News Staff 
          + How to Get the SYBASE Technical News 
          + Technical Support Customer Satisfaction Survey
     * SQL Server
          + Avoiding Server Catastrophe 
          + Changing Sort Order Manually When sybinit Fails
          + sysdevices `status' Control Bits 
          + Use Database Hanging After Upgrade
          + Float and Money Display Methods 
          + Disk Mirroring Clarification 
          + Limitation on RPCs Called from Threshold Procedures
          + Backup Server Context Allocation Errors 
          + TLI Address Translation Addendum 
          + OpenVMS Mount from CD-ROM 
          + Sybase Compatibility with RAID 
          + SYBASE Async I/O and RAID 
          + Certification Issues 
          + bcp Programming and Paging 
     * Connectivity / Tools / PC
          + SQL Monitor Server and ceventbuf
          + SQL Monitor Cheat Sheet 
          + Special Notes for PC Users - SQL Monitor Client 
          + SQL Monitor Incompatibility Table 
          + Corrections to NetWare Installation Manual 
          + Recommended list of NLMs to Load for NetWare 3.11
          + Recommended List of NLMs to Load for NetWare 3.12
          + Correction to NetWare "Zombie" Article 
          + Changes in PC Open Client/C Packaging 
     * Certification and Bug Reports
          + Bug 54192/34245 - Optimizer 
          + The Nature of the Bug 
          + Bug 55721 - sp_estspace 
          + Bug 56619 - sp_columns 
            
   
     _________________________________________________________________
   
  Communicating with Technical News Staff
  
   There is now a mail alias through which both customers and Sybase
   employees may contact the Sybase Technical News team. Send mail to
   technews@sybase.com to make suggestions or to submit articles. At
   present, due to legal issues, we are only accepting article
   submissions from Sybase employees; however, we welcome ideas for
   articles from everyone.
   
   The tsg alias, announced in Volume 3 Number 2, is a similar channel
   set up for the Troubleshooting Guide. Customers and employees can
   comment on the Troubleshooting Guide with corrections, additions, and
   other input. As with the tsg alias, technews is not a place to mail
   questions that would better be asked of Technical Support. Please call
   1-800-8-SYBASE to contact Technical Support.
   
  How to Get the SYBASE Technical News
  
   
   
   The SYBASE Technical News is automatically distributed to all
   registered Sybase support contacts. If you are one of your company's
   registered support contacts, and you do not receive this newsletter
   directly, please call Customer Service at 1-800-8-SYBASE to correct
   this.
   
   Whether or not you are a Sybase support contact, if you would like to
   receive your SYBASE Technical News in text format by email, send mail
   to technews@sybase.com to be added to the automatic distribution list.
   You will receive your newsletter by email at the same time as copies
   are distributed to comp.databases.sybase and the Sybase OpenLine forum
   of CompuServe.
   
   If you would like to receive hard copy of the SYBASE Technical News
   and are not a registered support contact, you may order it from Sybase
   Customer Fulfillment, as you do other documents. U.S. and Canadian
   customers may call 1-800-685-8225 or fax 1-617-229-9845. International
   customers with a U.S license agreement may use the fax number; all
   other international customers should contact their Sybase subsidiary
   or local distributor. Ask for document ID 50005-1-0300-03 (this
   issue). Document ID numbers for future issues will change by volume
   and issue number, for example:
     * 50005-1-0300-04 is volume 3 number 4
     * 50005-1-0400-01 is volume 4 number 1
       
   
   
   Back issues prior to Volume 3 are not currently available; indeed,
   much Technical News information is volatile in nature, and items
   printed in very old issues may well be out of date.
   
  Technical Support Customer Satisfaction Survey
  
   
   
   Since August 1993, Customer Service and Support (CS&S) has been
   sending monthly case closure satisfaction surveys to customers who
   have used Technical Support services. About 23 percent of these
   customers have responded to the surveys, and we appreciate your
   willingness to do so. Some of the responses have included questions
   about what we are doing with your feedback and suggestions. We will
   try to answer those questions in this article.
   
   Your ratings from the questions asked are entered and tabulated at the
   end of each month. We then compile statistical reports to give us a
   general picture of how we are doing relative to each of the service
   attributes addressed in the survey. We also distribute the returned
   surveys to a review team comprised of Technical Support Engineers, who
   review each month's returns for consistent and critical narrative
   comments. These comments give us additional data about attributes
   addressed in the survey, and provide data about attributes that we do
   not specifically address. The combined general picture and narrative
   comment data is used by the review team to recommend specific
   corrective actions to CS&S management. Some of the recommendations
   made by the review team are taken directly from suggestions given in
   the survey responses. CS&S management reviews and prioritizes the
   recommendations and acts on the according to their priority. We have
   already begun to implement improvements based on those
   recommendations.
   
   The statistical reports indicate that 80 percent of you are generally
   satisfied with the support that you receive. We are pleased, because
   this is significantly better than we were doing a year ago. However,
   your written comments identify areas where we can and will further
   improve our support to you.
   
   In future issues of this newsletter, we will be providing more
   specific information on actions we are taking in response to your
   feedback, so stay tuned. In the meantime, please keep the feedback and
   suggestions coming.
   
  Avoiding Server Catastrophe
  
   
   
   Server catastrophe is the inability to recover from a database failure
   in a timely manner or the inability to recover at all. If your
   business relies on your SQL Server being operational, then you must be
   prepared for situations in which your database, your major tables, or
   your entire Server fail.
   
   Familiarize yourself with the backup and restore commands and
   procedures for your SQL Server. The documentation provided with your
   SYBASE software is a good starting point. In particular, make sure
   that you read chapters within the System Administration Guide
   concerning the use of dbcc commands and procedures for recovering a
   lost master device or lost master database.
   
   This article contains a checklist of some important precautions that
   should be taken in order to avoid a server catastrophe.
   
   SQL Server is a large and sophisticated piece of software. It is not
   within the scope of this article to describe all possible failure
   scenarios. However, we hope to help you avoid some of the most common
   failures that have been reported to the Sybase Technical Support
   Response Team (the team responsible for handling the most urgent
   customer SQL Server problems).
   
    Checklist
     * Can you rebuild your master database from scratch
     * Can you rebuild your user databases from scratch
     * Can you rebuild your largest index in each database
     * Can you be certain that your backups are good
     * Would your backups be useful in the event of a failure
     * Will your system automatically warn you of problems
     * Are your devices mirrored
       
   
   
   If you answered "no" to any of the questions above or you are
   uncertain of the answer or uncertain as to the reason for their
   importance, then you are at risk of experiencing a Server catastrophe.
   
   
   The following sections of this article will help you to answer "yes"
   to all of the questions listed above. They will also go some way in
   describing why you should be able to answer "yes" to every question.
   
    Can you rebuild your master database from scratch
    
   
   
   There is a large quantity of important information stored in your
   master database including information about the master database
   itself! There are also many ways to lose your master database and the
   backups that you have kept so carefully. As an example, consider this
   real-life scenario:
   
   You have just spent the entire day (12 hours) creating new databases
   for your developers. Among other things, this procedure involved
   setting up devices, logins, passwords, and a number of modifications
   to the sp_configure parameters. You dutifully back up all of your work
   by doing a database dump of your master database, then leave for home.
   When you return the following morning, you discover two things: (1)
   your System Administrator accidently repartitioned the disk on which
   your master device was created, and (2) the tape on which you stored
   last night's backup was overwritten by the same person because he
   "couldn't find another tape to use."
   
   Keep up-to-date hard copies of the following tables:
     * sysdatabases
     * sysusages
     * sysdevices
     * syslogins
       
   
   
   It's also a good idea to use the bcp utility to keep on-line copies of
   these tables. Be sure to use the -c option of bcp; the resulting
   output is human-readable. An additional reason to use the -c option is
   that the output can sometimes be reloaded straight into a freshly
   created master database, but you will need to delete some rows before
   using bcp to reinsert the information, and this can only be done to
   output generated under the -c option. These rows are:
     * syslogins: row for the sa login
     * sysdatabases: rows for master, model, tempdb, sybsystemprocs
     * sysusages: rows for master, model, tempdb
     * sysdevices: the row for master device
       
   
   
   Keep a hard copy of your sp_configure parameters (and, optionally, the
   output from buildmaster -yall). This is usually not critical, but a
   hard copy could save you lots of headaches when you try to regain the
   optimized performance you spent hours attaining.
   
    Can you rebuild your user databases from scratch
    
    Can you rebuild your largest index in each database
    
   
   
   Some seemingly simple errors can be corrected only by dropping and
   re-creating objects or dropping and re-creating your entire database.
   Plan for it.
   
      Issue #1 - size of database
      
   
   
   If your database is too large to back up effectively, consider going
   to the expense of setting up a "hot backup" server. As soon as a dump
   tran is completed on your production server, it is immediately loaded
   onto a duplicate server via a load tran. If your production server
   fails, your "hot backup" server immediately becomes your production
   server. Ideally, your "hot backup" server should be located on a
   separate machine.
   
   Sybase's Replication Server is also a option in this situation. With
   Replication Server, you have the added benefit of automated backups.
   
      Issue #2 - size of objects within database
      
   
   
   Try to ensure that none of your tables are so large that you would not
   have time to re-create/restore it before your users demanded that the
   system be available.
   
   If your current database design includes any table so large that you
   can't rebuild it before the next business period, you might consider
   breaking it into separate tables based on some part of the information
   already being stored in one or more of the table columns. This may not
   be feasible for some installations, but we strongly recommend that you
   look for information within the table that is static and that, with
   some redesign, can be isolated. Once the static information is
   isolated, backing up that information is a one-time issue. When
   failure occurs, it will happen in a much smaller table and can be
   handled much more easily.
   
      Issue #3 - disk space
      
   
   
   Ideally, you should have enough free disk space that you could
   replicate your largest database. This may be necessary in situations
   where a failing device makes it impossible to produce a good database
   dump, but you need to retrieve as much of the information within the
   database as possible. The fastest solution could be to create a new
   database and use the select into command to move the information from
   the original database to the new database. The original database can
   then be dropped and the new database renamed, using the sp_renamedb
   stored procedure.
   
   At the very minimum, it is desirable to have enough free space within
   each of your databases to rebuild your largest index (see your System
   Administration Guide for details on how to calculate this space).
   
      Can you be certain that your backups are good
      
   
   
   Your backups are not useful if they contain corruption.
   
   For performance reasons, consistency checks are not performed during
   the dump of a database. A database dump can appear to have completed
   successfully, and still contain corruption. The corruption won't
   become apparent until you do a load database.
   
   Make sure that you perform dbcc checks regularly. Ideally, you should
   be checking your entire database immediately before each backup. dbcc
   checks should contain all of the following checks:
     * dbcc checkdb(database_name)
     * dbcc checkalloc(database_name)
     * dbcc checkcatalog(database_name)
       
   
   
   Reviewing the output of your dbcc checks can also be automated to some
   degree (see "Scanning the Error Log Automatically" below).
   
   If your database is too large to be checked before each backup,
   consider using one of the following methods:
    1. Perform dbcc checktable and dbcc tablealloc instead of dbcc
       checkdb and dbcc checkalloc, respectively. Identify tables that
       are more volatile than others and check those tables more
       frequently.
    2. Perform dbcc checks on a duplicate database. This could be either
       a "hot backup" server or a one-off copy of the database.
    3. If an individual table is too large for regular checking, consider
       redesigning your database. It is likely that much of the contents
       of your table consists of static information. Isolate static
       information; you will not be able to check once and then ignore it
       completely - hardware errors may corrupt your static information -
       but you can perform dbcc checks and backups much less often on
       that information.
       
    Would your backups be useful in the event of a failure
    
   
   
   When their systems fail, some customers are not able to load their
   backups because they would lose all work done between completion of
   the backup and the time of failure. These customers are not backing up
   often enough.
   
   You will need to do backup as often as it takes to be able to say, "I
   can afford to lose the data. I always have a backup that I can load
   and then continue operations normally".
   
   Doing regular transaction dumps and saving the output will help to
   ensure that you can use your backups to restore your system to an
   up-to-the-minute condition. Discarding even one transaction dump will
   guarantee that you cannot.
   
    Will your system automatically warn you of problems
    
   
   
   The most obvious means of checking for server problems is by scanning
   the error log visually, but there are methods that are easier and less
   error prone. On most systems you can pipe your error log through a
   filter to detect exception messages. This is not a Sybase supplied
   feature, but is not a difficult thing to do (see "Scanning the Error
   Log Automatically" below).
   
   Some corruptions, if fixed immediately, will cause few problems. It's
   the corruption that is allowed to fester for long periods of time that
   leads to a situation where recovery is difficult.
   
    Are your devices mirrored
    
   
   
   Mirroring your devices can help to ensure that recovery from some
   types of system failure will take seconds or minutes instead of hours
   or days.
   
   A disk fragment cannot be dropped from a Sybase database. A disk
   fragment cannot be rebuilt separately from the rest of the database.
   If one of your devices fails and you have not mirrored that device,
   you will be forced to drop and recreate that entire database. Can you
   afford to have your users wait that long Most probably, it would be
   far less expensive to maintain mirrored devices.
   
    Scanning the Error Log Automatically
    
   
   
   Following is an example of a UNIX C shell script that might be used to
   form part of an "early warning system". You might also wish to add
   some code to ensure that the DBA is not alerted for certain common or
   informational messages that appear in your error log (hint: use the -v
   option of the grep or egrep utility).
   
   Example:


#!/bin/csh
# file: scan_log
# author: Greg Klinder # Sybase, Inc.
#
# purpose: A C shell script for warning the Database Administrator # about pote
ntial problems with the Sybase SQL Server.
#
# The reliability of this script for alerting the DBA to potential # server pro
blems depends entirely on the contents of the WORRIES
# file. This file contains a list of regular expressions which,
# hopefully, can be used to correctly identify *most* serious
# errors that might appear in the error log.

set DBA_ALIAS=(ourdba@oursite.com otherdba@theirsite.com)
set ERRORLOG=/usr/sybase/install/errorlog
set FERR_FILE=/tmp/filtered_err set WORRIES=/usr/ourdba/regexp

# -------------------------------------------------------------
# Check to see whether temporary file exists. If so, remove it.
# -------------------------------------------------------------

if (-f ${FERR_FILE} ) then rm ${FERR_FILE} endif

# ---------------------------------------------------------
# Filter out all messages within the errorlog that might be
# of concern to the database administrator. Save them to a
# temporary file.
# ---------------------------------------------------------

if (-f ${WORRIES} && -f ${ERRORLOG} ) then
        egrep -f ${WORRIES} ${ERRORLOG} >${FERR_FILE}
else
        echo ${ERRORLOG} | mail -s "scan of server error log failed"
        ${DBA_ALIAS}
        exit 1
endif

# -----------------------------------------------------------
# If the temporary file is not empty, then we know that there
# are messages within the errorlog that should be examined.
# Alert the database administrator(s) by email.
# -----------------------------------------------------------
if ( ! -z ${FERR_FILE} ) then
        mail -s "problems in error log ${ERRORLOG}" ${DBA_ALIAS}
        <${FERR_FILE}
endif

   
   
   Here is an example of what you might put in the WORRIES file:

        WARNING:
        WARNING -
        Error:
        Msg

    Most Commonly Made Serious Mistakes
     * Using dump tran ... with no_log in some situations can cause
       corruptions. Whenever possible, use dump tran ... with
       truncate_only instead. If the log is 100 percent full and
       truncate_only produces an 1105 error, then use no_log.
     * Doing dump tran ... with truncate_only or dump tran ... with
       no_log will render all subsequent dump tran useless. Each dump
       tran is only as good as the previous one.
     * Backing up your SYBASE devices at operating system level is
       useless unless the backup was done while SQL Server was down and
       you plan to restore all devices simultaneously. Additionally,
       OS-level device backup is not supported.
     * Your server will not be very forgiving when it comes to mismatches
       between the contents of the sysusages table at the time of dump
       database and the contents of the sysusages table at the time of
       load database. In Servers before System 10, you will get 2558
       errors from dbcc checkalloc; in SQL Server 10.0, the load will
       change sysusages and you may not find the output useful.
     * By dropping a user database, recreating it, and then loading the
       most recent dump, you will still be missing all of the information
       generated when you used the sp_extendsegment stored procedure (the
       information is stored in the sysusages table in master, not in any
       tables within the user database). You will need to repeat all of
       the sp_extendsegment commands. If you neglect to do so, you may
       end up with occurrences of the 1105 error. If you created
       user-defined segments, you must recreate them before you attempt
       to reload.
     * In general, we recommend that you put the log for any user
       database on its own device.
       
      Syntax Change for RAISERROR
      
   
   
   Under the old raiserror syntax, it is very difficult to distinguish
   where the parameters for the message string end and where the Extended
   Error Data (EED) arguments begin. They are distinguishable only by the
   presence or absence of a comma. A new syntax change planned for an
   upcoming System 10 SQL Server Rollup results in an error message that
   is more readable and more easily maintained by customers and Technical
   Support staff.
   
   The old syntax was:

raiserror error_number
        [{format_string | @local_variable}] [, arg_list]
        [extended_value = extended_value [{extended_value
        = extended_value}...]]

   
   
   The new syntax is:


raiserror error_number
        [{format_string | @local_variable}] [, arg_list}
        [with errordata restricted_select_list]

   
   
   where restricted_select_list can follow the standard select_list
   syntax rules as mentioned in the raiserror section of Volume 1 of the
   SQL Server Reference Manual, with the restriction that no from, where,
   or other select clauses can be included. This means that wildcard
   characters cannot be used.
   
   Use of EED, as described in the SQL Server Reference Manual, will stay
   the same. The third example in the examples section of that manual
   should now read:


        3. raiserror 20100 "Login must be at least 5
                characters long" with errordata "column" = "login",
                "server" = @@servername

   
   
   According to the new syntax, the following variants of raiserror are
   allowed, have been exercised, and are verified as functional:

        raiserror 25001
        raiserror 25001 "formatted string"
        raiserror 25001 @variable
        raiserror 25001 "formatted string %1!","foo"
        raiserror 25001 @variable,"foo"
        raiserror 25001 "formatted string %1! with %2!","foo",@bar with
                errordata ExtendedValue=5,"ExtVal"="Extval",3+4
        raiserror 25001 @variable,"foo",@bar with errordata
                ExtendedValue=5,"ExtVal"="ExtVal",3+4
        raiserror 25001,"foo"
        raiserror 25001,"foo",@bar
        raiserror 25001,"foo",@bar with errordata ExtendedValue=5
        raiserror 25001,"foo",@bar with errordata
                ExtendedValue=5,"ExtVal"="Extval",3+4
        raiserror 25001 with errordata ExtendedValue=5
        raiserror 25001 with ExtendedValue=5,"ExtVal"="ExtVal",3+4

   
   
   This change will be effective with a Rollup scheduled for release
   later in 1994. When inquiring for the status of this Rollup, mention
   bug # 51600.
   
  Changing Sort Order Manually When sybinit Fails
  
   
   
   During a new install of SQL Server 10.0.1 for HP9000/800, some
   customers have encountered a bug, 56745, when attempting to change the
   default sort order from binary to dictionary case insensitive in
   sybinit. The following errors are raised:


        CONNECTIVITY ERROR: Error sending SQL to server `SYBASE'
        SERVER ERROR: `sp_configure default sortorder id' failed.

   
   
   If you encounter this problem, you must change the sort order manually
   according to the following method. The example below demonstrates
   conversion of the sort order from binary to nocase under the roman8
   character set. The available sort orders for a character set may be
   found in $SYBASE/charset/charset_name, where charset_name is the name
   of your character set. For example:


        cd $SYBASE/charsets
        alder% ls -C
        ascii_8 cp437 cp850 eucjis iso_1 mac roman8 sjis
        alder% ls -C roman8
        binary.srt      dictionary.srt          nocase.srt
        charset.loc     noaccents.srt           nocasepref.srt

   
   
   The available sort orders have a .srt filename extension.
   
   The steps to change the sort order are:
    1. At the isql prompt, execute the command dump tran master with
       truncate_only. Make sure you have some space available in master
       so that you will not have problems rebuilding the system table
       indexes. If space is tight then alter database master before
       proceeding further.
    2. Shut down the SQL Server.
    3. If your SYBASE devices are on UNIX file systems, issue three sync
       commands at the shell prompt so that the OS buffer cache gets
       flushed.
    4. Reboot the SQL Server in single-user mode.
    5. Execute the following commands in isql:

        1> select name, id, type from syscharsets
        2> go
   
       
       Your output should look something like this:


name                                    id      type
------------------------------          ---     ------
ascii_8                                 0       1001
roman8                                  4       1001
nocase_roman8                           22      2001
bin_roman8                              50      2001

   
       
       If you see "nocase_roman8" then type:


        1> sp_reconfigure `default sortorder id', 22
        2> go
        1> reconfigure with override
   
       
       If you do not see "nocase_roman8"' then:
          + Exit isql
          + Execute this command from the shell prompt:
            $SYBASE/bin/charset -Usa -Ppassword -Sservername nocase.srt
            roman8  Go into isql and type:

        1> sp_reconfigure `default sortorder id', 22
        2> go

        1> reconfigure with override
    6. Shut down the SQL Server
    7. If your SYBASE devices are on UNIX file systems, issue three sync
       commands at the shell prompt so that the OS buffer cache gets
       flushed.
    8. Reboot the SQL Server. This will rebuild the system indexes and
       shut down SQL Server automatically.
    9. Reboot the SQL Server again.
       
   
   
   At this point the Server should be configured for nocase for the
   roman8 sort order. Verify this by looking at the errorlog after the
   boot.
   
   You will need to run sp_indsuspect against each database to see if
   there are any indexes that must be rebuilt because of the sort order
   change. Please refer to Chapter 17 of your System Administration Guide
   for instructions.
   
  sysdevices `status' Control Bits
  
   
   
   The status column in the sysdevices table is a bit map indicating the
   type of device, default, and mirror status. The status control bits
   are:


Decimal         Hex     Status

1               0x01    Default disk
2               0x02    Physical disk
4               0x04    Logical disk
8               0x08    Skip header
16              0x10    Dump device
32              0x20    Serial writes
64              0x40    Device mirrored
128             0x80    Reads mirrored
256             0x100   Secondary mirror side only
512             0x200   Mirror enabled
1024            0x400   Device information in configuration area
2048            0x800   Mirror disabled

   
   
   Examples: A value of 2275 (0x8E3) in the status column of sysdevices
   means that the device is:

        2048    0x800   Mirror disabled
        128     0x080   Reads mirrored
        64      0x040   Device mirrored
        32      0x020   Serial writes
        2       0x002   Physical disk
        1       0x001   Default disk

   
   
   A value of 2242 in the status column of sysdevices represents the
   following:

        2048    0x800   Mirror disabled
        128     0x080   Reads mirrored
        64      0x040   Device mirrored
        2       0x002   Physical disk

   
   
   Bug fix 31027 introduced the new status bit value 2048.
   
  Use Database Hanging After Upgrade
  
   
   
   A few customers are experiencing intermittent hanging after upgrading
   to 10.0 SQL Server when they execute a use database command. No bug
   has yet been assigned to this behavior, because so far the problem is
   intermittent enough that we have not been able to reproduce it either
   at the customers' sites or in Technical Support. To avoid the
   possibility of this problem occurring, make sure that the
   configuration value for open databases is at least equal to the number
   of actual databases present on your SQL Server. You can change this
   value with sp_configure; refer to Chapter 12 of your System
   Administration Guide for further details.
   
  Float and Money Display Methods
  
   
   
   Occasionally, a customer may want to display more than the default six
   significant digits to the right of the decimal point of a float or
   money value. One method that a customer might find intuitive, select
   convert (char(20), floatcol), does not work. However, as of the 4.9.1
   release of SQL Server, there is a way to display more digits. Using
   the str function documented in the Commands Reference Manual, you can
   display more digits like this:

        select str(floatcol, length1, length2) from table

   
   
   length1 is the total number of characters to return, including the
   decimal point, blank spaces, and digits to the right and left of the
   decimal. length2 is the number of digits to the right of the decimal
   point. For example, the command:


        select str(discount,14,11) from pubs2..salesdetail
        where title_id = `PC1035' and ord_num = `124152'

   
   
   will return the string 50.500000000000. The function adds extra zeros
   to the end of the number as padding if there are fewer than the
   requested number of digits to the right of the decimal point.
   
  Disk Mirroring Clarification
  
   
   
   The System Administration Guide for SQL Server release 4.9.2 contains
   the following statement:
   
     "... SQL Server reads from the disk where the last I/O was `closest'
     to the current read request.
     
   
   
   This statement is not in the System Administration Guide for release
   10.0, leading to the frequently asked question, "Is this true for
   System 10 Has it ever been true How could this work"
   
   In fact, this feature was planned for release 4.8, but was never
   implemented, due to the differences in hardware from platform to
   platform. The plan was mentioned in some marketing documents, and
   slipped into pre-System 10 System Administration Guide manuals. The
   System 10 System Administration Guide corrects this erroneous
   information.
   
  Limitation on RPCs Called from Threshold Procedures
  
   
   
   Threshold procedures in System 10 can make remote procedure calls to a
   remote Server, but only if it that Server is an Open Server. A remote
   procedure called from a threshold procedure cannot reside on a SQL
   Server.
   
   The reason is that a valid user/password combination must be provided
   to the remote SQL Server. SQL Server no longer stores passwords in
   plain text; rather, it encrypts them with a one-way algorithm. A
   threshold procedure executes with the user ID (uid) of the user that
   called sp_addthreshold, not the uid of the user that caused the
   threshold to be exceeded. The calling server is unable to provide the
   called server with a valid user/password combination, as it cannot
   decrypt the encrypted version of the password kept in syslogins for
   that uid.
   
   Remote Open Servers, which do not use this user/password mechanism,
   can execute RPCs from threshold procedures.
   
  Backup Server Context Allocation Errors
  
   
   
   Sybase Technical Support gets many calls from customers who see the
   following messages:

        Backup Server: 1.20.4.1: CS_CONTEXT allocation failed
        Backup Server: 1.15.4.1: UNRECOVERABLE CONDITION: ALL
        SESSIONS WILL TERMINATE ABNORMALLY. THE BACKUP SERVER
        MUST EXIT

   
   
   This error indicates that the context allocation routine failed when
   it tried to load localization files. One or more of the following
   problems may have caused these errors:
     * The SYBASE environment variable may be incorrectly set.
     * The LANG environment variable may be set to "C" (the default),
       which does not exist in your locales.dat file.
       
   
   
   There are two ways to correct this second situation:
     * the UNIX command unsetenv LANG, or
     * Add the following line to your $SYBASE/locales/locales.dat file:

        locale = C, us_english, iso_1

  TLI Address Translation Addendum
  
   
   
   In Volume 3, Issue 2 of SYBASE Technical News, a section on TLI
   network addressing incompletely explains the translation of the
   hexadecimal address number. This is the actual translation of the
   following example:

        \x000207d082d6330d0000000000000000
     * \x is the hex indicator
     * 0002 is the address family
     * 07d0 is the port number
     * 82d6330d is the network node (IP) address
       
   
   
   The optional trailing zeros are present in this example.
   
   The address family identifies the format of the network address. "2"
   means "internetwork" (UDP, TCP, and so on). The entire set of families
   is given in /usr/include/sys/socket.h. For example, DECnet is 12;
   AppleTalk is 16. This does not mean that a machine supports all of
   these protocols; it simply identifies the format of the address.
   
   While the byte order of the port number and network address is defined
   in some specifications for IP address (and does not vary from platform
   to platform), the byte order of the "address family" is not fixed.
   Some machines with the opposite byte order from the Sun4 (DEC and
   Intel machines) may have 0200 rather than 0002 (the bytes are
   swapped).
   
  OpenVMS Mount from CD-ROM
  
   
   
   In Volume 3, Issue 2 of the SYBASE Technical News, we described how to
   avoid 803 errors when installing from CD-ROM by ensuring that you use
   the correct mount command. As of the System 10 release of SQL Server,
   distribution of software by CD-ROM is available for OpenVMS as well as
   OSF. The mount command is:

        mount device_name sybase cdrom

   
   
   Please refer to Volume 3, Issue 2 of the SYBASE Technical News for
   further information about the 803 error.
   
  Sybase Compatibility with RAID
  
   
   
   There has been some confusion about whether Sybase software works with
   RAID disk technology. This issue has two sides:
     * Will the software's asynchronous I/O code work with RAID disks
     * Has Sybase certified products on a platform using RAID disks
       
  SYBASE Async I/O and RAID
  
   
   
   The way SQL Server uses asynchronous I/O on the AT&T (NCR) platform,
   for example, is simply to use supplied system calls to issue an
   asynchronous I/O request. Then it polls for the I/O completion in a
   prescribed manner; if an I/O error is returned, the SQL Server reports
   and corrects for it. You configure, with disk init, the device to
   which the I/O is actually done; it is usually also a device entry in
   /dev.
   
   From the SQL Server's perspective, there is a device file (/dev/xxxx)
   that it can open and to which it can direct I/O requests. The SQL
   Server has no knowledge of the type of device that is represented by
   the device entry in /dev. It could be a single partition of a disk or
   some other abstraction such as a RAID disk. As with any device,
   buffered I/O may cause complications for data recovery.
   
  Certification Issues
  
   
   
   After an operating system vendor, such as SunSoft, tests and certifies
   its new hardware devices for a new OS version, Sybase tests SQL Server
   to ensure that it is compatible with the new OS. If a RAID device is
   supported by the OS as a standard disk device, then SQL Server will
   support the RAID disk subsystem, since SQL Server is certified against
   the OS rather than against the disk subsystem. It is not possible to
   recommend one RAID system over another, since the results are system
   and application dependent.
   
  bcp Programming and Paging
  
   
   
   Using bcp_init, bcp_bind, and bcp_done in a 3GL program can cause each
   row to be started on a new page, even though the row might not be a
   full page in length. If your function to load the data into the
   database is called for each row until EOF, and in that same function
   are bcp_init, bcp_bind(s), and bcp_done, you may see this problem.
   
   This is because having initialization (bcp_init) occur each time a row
   is to be added causes each row to be stored on a new page. This is not
   documented in the OpenClient/DB-Lib Reference Manual.
   
   Instead of using all three calls in the same function, run bcp_init
   and bcp_done outside the function that does the bcp_bind(s). Be aware
   that now either all the data is sent when bcp_done is executed, or
   nothing is sent if the program crashes before bcp_done.
   
  SQL Monitor Server and ceventbuf
  
   
   
   Although it is documented only in the "Special Considerations" section
   of the SQL Monitor Server Supplement, changing the ceventbuf value on
   the SQL Server is a required step in setting up the SQL Monitor
   Server.
   
   It is important that you heed the information regarding ceventbuf
   values in the SQL Monitor Server Supplement; there is an algorithm
   listed there that will help you calculate the size to which you should
   set your ceventbuf value. The default ceventbuf value for SQL Server
   is 100; we suggest a minimum of 2000 for ceventbuf in order to use SQL
   Monitor. Changing this value is required by SQL Monitor, not by SQL
   Server.
   
   For windows that depend on the event buffer size (see the SQL Monitor
   Server Supplement for this information), we recommend a low sample
   interval for SQL Monitor Client of 5-10 seconds.
   
  SQL Monitor Cheat Sheet
  
   
   
   The order in which to start the three processes involved in monitoring
   your SQL Server is: 1) SQL Server, 2) SQL Monitor Server, 3) SQL
   Monitor Client. If SQL Server is rebooted, then both the SQL Monitor
   Server and Client must be rebooted. The process details are:
    1. Start the SQL Server as user "sybase". Use the -M flag to specify
       the lo cation of the server_name.krg file. (See the SQL Server
       Installation Guide for y our platform.) For example:

        setenv SYBASE /usr/local/system10
        setenv DSLISTEN SYBASE10
        $SYBASE/bin/dataserver -d/sun4db/system10db/SYBASE10_master.dat \
        -e$SYBASE/install/errorlog_SYBASE10 -M$SYBASE &

    2. Start up the SQL Monitor Server as the same "sybase" user, on the
       same host machine, with no spaces between the flag and the flag's
       value. Using the -i flag, point to an interfaces file that has
       both the SQL Server entry and the SQL Monitor Server entry;
       specify the same location of the SQL Server .krg memory file using
       the -m flag. Be sure to start SQL Monitor Server on the same
       machine as SQL Server because SQL Monitor Server has to access the
       same shared memory region.


        $SYBASE/bin/monserver -MMON10_SYBASE10 -SSYBASE10 \
        -Usa -Ppassword -i$SYBASE/interfaces \
        -l$SYBASE/install/MON10_SYBASE10.LOG -n -m$SYBASE -O &
   
       
       The two flags, -M and -m have different meanings. See the SQL
       Monitor Server Supplement for complete start-up instructions
    3. Start the client as any user, on any client machine, using spaces
       between each flag and its value. The -i flag must point to an
       interfaces file that has both the SQL Monitor Server entry and the
       corresponding SQL Server entry that was passed on the monserver
       command line. The SQL Server name must be the same name that
       appears in the interfaces file (or .INI for PCs). It cannot be an
       entry that has the same host and port number but a different SQL
       Server name. (See the SQL Monitor Release Reference Manual for
       complete start-up instructions)

        UNIX:

        /usr/directory/bin/sqlmon -M MON10_SYBASE10 \
        -U sa -P password -I\x11/usr/directory/interfaces &

        PC:

        C:\SERVMON\SERVMON.EXE

   
       
       The Sybase-supplied sqldl.dll library is installed in
       \WINDOWS\SYSTEM with SQL Monitor version 10.1.0 for Windows, but
       in \SERVMON with SQL Monitor version 10.1.2 for Windows.
       
       A user must have sa_role privilege to access release 10.0 or
       10.0.1 SQL Monitor Server or SQL Server. Use the following command
       to grant that privilege to a user: exec sp_role `grant', sa_role,
       `username'
       
  Special Notes for PC Users - SQL Monitor Client
  
   
   
   SQL Monitor Client opens up two network connections for each open
   window: one to SQL Monitor Server and one to SQL Server. PC users will
   be affected most and will need to configure their network software to
   handle more network connections.
   
   For example, if you are using FTP's PC/TCP, with its default
   configuration of six network connections, this limit will be reached
   with three SQL Monitor windows. An attempt to open a fourth window
   will result in an error:


        SERVMON Cannot access Server - retry after closing an
        existing Monitor Window

   
   
   You may also see the above error message when the number of open
   connections for the SQL Monitor Server has been exceeded. In that
   case, you must restart the SQL Monitor Server with a larger -n value.
   
   Please refer to your network documentation for specific information on
   how to increase your network connections. To continue the FTP PC/TCP
   example, you must edit the "tcp-connection=" entry in the [pctcp
   kernel] section of the \PCTCP\PCTCP.INI file and then reboot your PC.
   
  SQL Monitor Incompatibility Table
  
   
   
   In Volume 3, Issue 2 of the SYBASE Technical News, we published a
   table of uncertified combinations of SQL Server and SQL Monitor Server
   that contained a typographical error. Here is the corrected table:

        SQL Monitor Server      SYBASE SQL Server

        4.9.1                   10.0.0

        (this combination may work, but is not certified)

        4.9.1                   10.0.1
        10.0.0                  10.0.1
        10.0.1                  4.9.x or 10.0.0

  Corrections to NetWare Installation Manual
  
   
   
   According to the SQL Server Installation Guide for Novell NetWare, the
   first step of the installation process is to update the NetWare
   operating system NLMs. This step is necessary if the NetWare NLMs that
   are currently running, prior to installation, are older then the NLM
   versions listed in the Release Bulletin.
   
   This step is not required if you have more recent NetWare NLMs. This
   includes the newer versions of NetWare 3.12 and 4.01.
   
   When SQL Server 4.2.2 for NetWare was released in March 1993, most
   customers were installing on NetWare 3.11. When Sybase came out with
   this version, Sybase included more current versions of the NetWare
   NLMs on the distributed diskettes so that customers could easily
   upgrade to 4.2.2 without having to track down the correct NetWare
   NLMs.
   
   Today, one year later, the NetWare NLMs have gone through many
   revisions, and the NetWare NLMs on the Sybase diskettes are no longer
   the most current. Therefore, you should skip that updating step so as
   not to override the newer NLMs.
   
   The recommended installation steps should begin with the section
   entitled "Step Two: Start SQL Server Installation."
   
   After the SQL Server is installed and configured, we recommend you
   copy over the most recent Sybase Rollup (Rollup 3183 as of July 1,
   1994), and download the following files from Compuserve to bring your
   NetWare fileserver up to the latest NetWare NLM versions. The tables
   which follow the lists of files show the specific NLMs to download for
   each NetWare version.
   
  Recommended list of NLMs to Load for NetWare 3.11
  
   
   
   Download these files from CompuServe:
     * STRLI2.exe (novlib forum)
     * LIBUP2.exe (novlib forum)
     * DFS108.exe (novlib forum)


DIR Listing Information                 MODULES List

NLM Name        Size    Date            Module          Date

sys:\system directory:

clib            328,124 2/24/94         3.12f           2/24/93
mathlib          12,458 2/24/94 or      3.12f           2/24/93
mathlibc         16,832 2/24/94         3.12f           2/24/93
a3112            11,371 1/7/94          4.00a            1/7/94
after311         14,411 1/7/94          4.00a            1/7/94
streams          53,566 7/20/93         3.12            7/20/93
spxs             24,145 9/14/93         3.12a           9/14/93
tli              12,474 9/14/93         3.12a           9/14/93
ipxs              8,149 8/10/93         3.12a           8/10/93
spxddfix          1,636 9/20/93         1.00            9/20/93
spxfix2           1,599 8/20/93         2.10            8/20/93
spxfsfix          1,155 8/20/93         2.10            8/20/93
spxlisfx          1,016 8/20/93         1.10            8/20/93
xmdfix            1,496 9/15/92         1.02            9/15/92
patchman          9,632 2/04/93         2.30             2/4/93
directfs         16,740 7/14/93         1.08            7/14/93
sybstubs            901 n/a             4.22            3/16/93

sys:\sybase\nlms directory

sqlsrvr       1,192,998 n/a             4.22            1/18/94

  Recommended List of NLMs to Load for NetWare 3.12
  
   
   
   Download these files from CompuServe:
     * STRLI2.exe (novlib forum)
     * LIBUP2.exe (novlib forum)
     * DFS108.exe (novlib forum)
     * 312IT1.exe (nsd forum)


DIR Listing Information MODULES Listing

NLM Name        Size    Date            Module          Date

sys:\system directory:

clib            328,124  2/24/94        3.12f           2/24/93
mathlib          12,458  2/24/94 or     3.12            2/24/93
mathlibc         16,832  2/24/94        3.12f           2/24/93
a3112            11,371   1/7/94        4.00a            1/7/94
after311         14,411   1/7/94        4.00a            1/7/94
streams          53,566  7/20/93        3.12            7/20/93
spxs             24,145  9/14/93        3.12a           9/14/93
tli              12,474  9/14/93        3.12a           9/14/93
ipxs              8,149  8/10/93        3.12a           8/10/93
spxddfix          1,254  9/20/93        1.00            9/20/93
pm312             8,909 11/11/93        1.11           11/11/93
directfs         16,740  7/14/93        1.08            7/14/93
sybstubs            901  n/a            4.22            3/16/93

sys:\sybase\nlms directory:

sqlsrvr 1,192,998 n/a 422 1/18/94

   
   
   These files are as of March 1994; NetWare NLMs will continually need
   to be updated, and we recommend monitoring CompuServe for any release
   notices.
   
   Please refer to the *.txt files included with the downloaded files
   from CompuServe for detailed information on the purpose of each
   NetWare NLM.
   
  Correction to NetWare "Zombie" Article
  
   
   
   As the above article shows, the name of STRTLI.EXE has been changed to
   STRLI2.EXE. This file is one of the files recommended for download to
   forestall the appearance of "zombie" processes on the SQL Server NLM.
   We apologize for any confusion this may have caused.
   
  Changes in PC Open Client/C Packaging
  
   
   
   Customers will shortly be seeing a change in the way Open Client/C
   release 10.0.1 is packaged for MS-DOS, Windows, OS/2, and Windows NT.
   The new packaging includes all System 10 Net-Libraries. This
   eliminates the need to order a separate package of Net-Libraries for
   each platform and brings packaging for PC platforms in line with the
   existing method of packaging for UNIX and OpenVMS platforms.
   
   All repackaging should be complete before the desktop mass-shipment
   scheduled for maintenance release 10.0.3 and after completion and
   release of DB-Library release 10.0.1 for each platform. The 10.0.3
   maintenance release and mass update, and the final production release
   of DB-Library 10.0.1 are scheduled for Q4 of 1994.
   
  Bug 54192/34245 - Optimizer
  
   
   
   In the latest 4.9.2 SQL Server Rollup, the query optimizer looks at
   the new multi-column densities only if a special trace flag is set; in
   SQL Server release 10.0, the optimizer always looks at the new
   multi-column densities.
   
   A fix for bug 34245 in the 4.9.2 SQL Server addressed an optimizer
   problem with multi-column joins by providing multiple densities for
   multi-column indexes. Prior to this fix, the join selectivity
   (proportion of the table to be scanned for each outer row) was
   estimated by a number referred to as the join's "density": the average
   proportion of duplicates in the index. The density took the entire
   index key into account, regardless of whether the query was joining on
   the entire index key or a subset of the index key columns.
   
   This fix for bug 34245 greatly improved performance for some
   queries-those for which the optimizer had previously selected very
   costly indexes because of the density limitation. On the other hand,
   the fix did occasionally cause the optimizer to generate some
   potentially less effective plans. A new bug was entered for this
   problem, 54192, which makes the multiple-density feature available
   only if the SQL Server is started with trace flag 321.
   
   Customers upgrading to System 10 should be aware that trace flag 321
   is not a part of System 10, and that they may encounter the problems
   for which bug 54192 was entered. Following are an explanation and
   suggestions to work around the problem.
   
  The Nature of the Bug
  
   
   
   Customers doing queries with one or more joins may now see that an
   index is much less selective on the join columns of some or all
   indexes. This can result in the index not being used, and an alternate
   plan being chosen such as using a different index, choosing a
   different join order, or reformatting to a work table.
   
   In some cases, the new plan can be slower than a previously chosen
   plan, often as the result of "join skew". Join skew occurs when the
   optimizer does not know the specific values that will be joined at run
   time, and must use an estimate for the average number of rows that
   will join to a typical value. If the actual number of rows that join
   is significantly less than the average number used by the optimizer,
   then the new plan may not be as fast as the plan chosen before this
   fix.
   
   The resolution to these problems is to determine which indexes are
   demonstrating very poor join selectivity, and modify the schema to
   include indexes that have good join selectivity on the joining columns
   of the query. For example, using this schema:

        create index idx on tab (col1,col2,col3,col4)

   
   
   this index will have four sets of densities, on:

        col1
        col1,col2
        col1,col2,col3
        col1,col2,col3,col4

   
   
   For a query joining on col1, col3, and col4, a density of (col1)will
   be used to estimate join selectivity for tab. If col1 has 100 percent
   density (all duplicates), the join selectivity will be very poor, and
   the optimizer will not select this index even though (col3,col4) may
   be very selective.
   
   Modify the schema as follows:

        create index idx_c3c4 on tab (c1,c3,c4,c2)

   
   
   This way, for a query joining on col1,col3,col4 the density of
   (col1,col3,col4) will be used to estimate join selectivity for tab.
   Regardless of the poor join selectivity of (col1), the index will be
   regarded as highly selective by the optimizer because (col1,col3,col4)
   is very selective.
   
  Bug 55721 - sp_estspace
  
   
   
   A customer discovered that entering a different value for iosec in
   sp_estspace has no impact on the time_mins value. For example


        1> sp_estspace titles,10000,50,
        2> "title,notes",0,10000

   
   
   returns a value of 13 in the time_mins column. Changing the iosec
   value to 25:


        1> sp_estspace titles,10000,50,
        2> "title,notes",25,10000

   
   
   causes no change in the time_mins column. This is because when iosec
   is initially declared, it is set to 30. The solution is to delete that
   line in the code. A new version of sp_estspace, included in the
   comp.databases.sybase FAQ on Usenet news, contains this correction.
   
  Bug 56619 - sp_columns
  
   
   
   Bug 56619 was recently reported in SQL Server 10.0.1, for the case in
   which sp_columns does not report on columns with user-defined
   datatypes. Customers who encounter this bug can contact Technical
   Support for a new script to create sp_columns; additionally, the
   script is available on the OpenLine forum of CompuServe (GO SYBASE).
   Isolate the create sp_columns script from the installmaster script
   provided with 10.0.1 and make the following changes:
     * Remove the line AND t.name = d.type_name
     * Replace it with AND t.type = d.ss_dtype
       
   
   
   This line appears in the sp_columns definition, just below this
   comment:
   
   We need an equality with sybsystemprocs.dbo.spt_datatype_info here so
   that there is only one qualified row returned from
   sybsystemprocs.dbo.spt_datatype_info.
   
   Drop sp_columns and run the new script.
   
   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.
   
   (C) 1994, Sybase, Inc. All Rights Reserved. SYBASE is a trademark of
   Sybase, Inc. registered in the U.S. Patent and Trademark office and in
   other countries. SQL Server, Open Client, Open Server, Backup Server,
   SQL Monitor Client, and SQL Monitor Server are trademarks of sybase,
   Inc. Other company and product names may be trademarks of the
   respective company with which they are associated.
   
    Staff
     * Principal Editor: Leigh Ann Hussey
     * Contributing Writers:
          + Donna Sams-Nyirendah
          + Greg Klinder
          + Ray Rankins
          + Aimee Grimes
          + Marc Sugiyama
          + Cris Gutierrez
          + Bob Perry
          + John Blair
          + Guy Moore
          + Danielle Scherer
          + Marian Macartney
          + Gary Sturgeon
          + Bret Halford
          + Sybase Engineering
            
   
   
   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.

                                    Q10.1.3
                                       
Technical News Volume 3, Number 4 November, 1994

   Document ID: 50005-01-0300-04
   
   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. Keep this newsletter
   with your SYBASE Troubleshooting Guides. All issues of the Sybase
   Technical News and the Troubleshooting Guides are included on the
   AnswerBase CD.
   
IN THIS ISSUE

     * Distribution Changes for Technical News 
     * Technical News by E-Mail Update 
     * OpenLine Update 
     * 1105 Errors on Boot 
     * Large SQL Server Upgrade Fails with Timeout 
     * Variable Database Object Names and Parsing Issues 
     * Threshold Management with @@thresh_hysteresis 
     * Methods for Monitoring Space 
     * Dead/Infected Processes and the Stack Trace 
     * sp_columns Script on CompuServe 
     * AIX: isql Connect to Backup Server Hangs 
     * HP: installasync80 and SAM Problems 
     * HP: Swap Space and Memory 
     * AT&T (NCR): 1605 and "Illegal Calling Sequence"
     * Solaris: Sunlink, "Master Network Listeners Failed"
     * VMS: MTI 4mm HSC Tape Drive No Longer Supported 
     * bcp: Determining Data Logged 
     * DB-Library: dbcursoropen() Returns NULL 
     * dbcursoropen(dbproc,"select type from pubs2..titles,...)
     * DB-Library: dbclose() and File Descriptors 
     * Embedded SQL: Target of INTO Clause
     * Embedded SQL: EXEC PROC Enhancement 
     * Embedded SQL/COBOL: Memory Leak in libcobct.a 
     * Mainframe Access Products: Latest EBFs 
     * Server Documentation Bugs Fixed 
     * Connectivity Documentation Bugs Fixed
     * Latest Server Certification Report
     * Bugs Fixed in 10.0.2 SQL Server Release
     * Bugs Fixed in Latest Connectivity Maintenance Releases
       
  Distribution Changes for Technical News
  
   Beginning with Volume 4 Number 1, the SYBASE Technical News will be
   sent to you on the quarterly AnswerBase CD. You may print as many
   copies as you need for your site. To find and print the SYBASE
   Technical News from AnswerBase, follow these steps:
    1. Do a Full-Text Query (under the "Search" menu) on the following
       string (include the angle brackets in your string): <title
       Technical News> This will, incidentally, provide you with all the
       issues of the SYBASE Technical News that have been published to
       date.
    2. Double-click on the title you want to open, or select it and click
       "Open".
    3. From the File menu, choose Print.
       
   
   
   The SYBASE Technical News is automatically distributed to all
   registered Sybase support contacts. If you are one of your company's
   registered support contacts and you do not receive the AnswerBase CD
   directly, please call Customer Service at 1-800-SYBASE to correct
   this.
   
   The SYBASE Technical News will continue to be distributed to
   comp.databases.sybase, the Sybase OpenLine forum of CompuServe, and
   the automatic e-mail distribution list.
   
  Technical News by E-Mail Update
  
   Whether or not you are a Sybase support contact, if you would like to
   receive your SYBASE Technical News in text format by e-mail, send mail
   to technews@sybase.com. We will add you to the automatic distribution
   list and you will receive your letter by e-mail at the same time that
   copies are distributed to the other online services.
   
   With over 200 subscribers added since August, the e-mail subscription
   program to SYBASE Technical News is a great success! However, for the
   moment, list administration is still handled by a human being, not a
   program. What this means to you, the customer, is that in order to
   subscribe successfully to the SYBASE Technical News e-mail
   distribution list, you must send, in the body of your letter, a valid
   e-mail address.
   
   If you subscribed since the last issue was printed and have not
   received an e-mail acknowledgment, send your request again, with a
   valid e-mail address. We have had the acknowledgment bounce from
   several addresses because the address was not valid, and those
   addresses have been removed from the list.
   
  OpenLine Update
  
   Sybase OpenLine has 24 sections now. We are accepting proposals for
   other new sections. If you have a suggestion or know of a Sybase
   product or service that should be supported on OpenLine, contact
   Chandra Krishnan (72662, 1331).
   
   The new International Sybase User Group (ISUG) private section goes
   live in October for ISUG members only. You may communicate online with
   other ISUG members and the ISUG Board of Directors, receive ISUG
   benefits and benefit information online, talk with Sybase, and much
   more. Specific details will be sent out to all ISUG members in
   October. Susie Cabral, User Group Program Manager, is the section
   manager and Teresa Larson, ISUG Electronic Media Chair, is the
   moderator. You can contact Susie at 510-922-4422 (voice), 510-922-0882
   (fax), or susie.cabral@sybase.com (e-mail).
   
   The Open Solutions section is being revamped. Please contact Tom
   Barrett, the section manager, for more details at 510-922-8534 or
   tom.barrett@sybase.com (e-mail).
   
   The OpenLine CompuServe forum is available to Sybase customers who are
   also CompuServe subscribers. More than 12,000 users have joined the
   forum, and more than 17,000 messages have been posted in the forum.
   For a full description of the items and activities available through
   the Sybase OpenLine Forum, call your sales representative or Customer
   Service at 1-800-8-SYBASE and ask for the OpenLine collateral. This
   collateral will be mass-mailed in Europe and included in all outgoing
   shipments worldwide.
   
  1105 Errors on Boot
  
   Problem: Customers who have upgraded from 4.9.x or previous releases
   of SQL Server-> to release 10.x may run into a situation where, every
   time SQL Server is rebooted, some database reports an 1105 error (no
   space in segment) with state 4. Recovery reports "can't write
   checkpoint record" for this database. Checking the segments, you may
   discover that a few of the segments contain a value other than NULL
   for the unreservedpgs column in sysusages.
   
   Explanation: State 4 indicates that the error was produced by the
   threshold manager in response to a "log almost full" condition. This
   happens because the SQL Server recovers the database before counting
   the free space in it and therefore is depending on whatever numbers
   are present in memory. The numbers in memory are random because
   unreservedpgs is NULL for most disk pieces in the database. The values
   are NULL for those disk pieces because unreservedpgs was added during
   the upgrade to System 10 and (for whatever reason) the values were not
   initialized during the upgrade.
   
   To solve this problem, you must change the NULL values in
   unreservedpgs to non-NULL values. The threshold manager itself cannot
   change them because changes to the unreservedpgs column of sysusages
   are not logged (to prevent updates from filling the log); therefore,
   it can't change the size of the column.
   
   Action: To fix this problem, take the following steps:
    1. Allow updates to system catalogs:

        1> sp_configure allow, 1
        2> go
        1> reconfigure with override
        2> go
    2. Check the number of rows where unreservedpgs has a NULL value:


        1> select count(1)
        2> from sysusages
        3> where unreservedpgs is null
        4> go
    3. Update the unreservedpgs column to give it a value of 0 in place
       of the NULL value.

        1> begin transaction
        2> update sysusages
        3> set unreservedpgs = 0
        4> where unreservedpgs is null
        5> go
    4. Inspect the results! If the "rows affected" message matches the
       count returned in step 2, then:

        1> commit tran
        2> go
   
       
       Otherwise, roll back the transaction and try again.
    5. When everything works as you intend, disallow updates to system
       catalogs:

        1> sp_configure allow, 0
        2> go
        1> reconfigure
        2> go

   
   
   This should resolve the problem.
   
  Large SQL Server Upgrade Fails with Timeout
  
   
   
   Question: When upgrading an extremely large SQL Server (multi GBs) to
   release 10.x, if the SQL Server requires more than 9 minutes to go
   through recovery, the upgrade script fails with an error that the SQL
   Server is not responding. The typical recovery time for a large SQL
   Server is more than 9 minutes. I have to rerun sybinit; how do I keep
   this from happening again
   
   Answer: This problem can be avoided by increasing the TIMEOUTCOUNT
   parameter in the upgrade100 script to a larger number. The upgrade100
   script is in the upgrade subdirectory of your SYBASE home directory.
   This will increase the number of times the script will check to see if
   the SQL Server is running before aborting the upgrade with an error.
   The line in the file looks like this:

        TIMEOUTCOUNT=108        # try the check 108 times (9 minutes)

   
   
   The value of TIMEOUTCOUNT should be set to the number of minutes you
   want to allow for recovery, times 12. So, for example, to increase the
   check time to 15 minutes, increase the TIMEOUTCOUNT value to 180. You
   can then rerun the upgrade through sybinit.
   
  Variable Database Object Names and Parsing Issues
  
   
   
   Question: I can use a variable for the database name in a dump tran,
   so why can't I use one as a table name in select
   
   Answer: This is because of the way our parser, variables, and
   protection scheme were implemented. When the parser encounters a
   variable in the batch, it temporarily assigns that variable to an
   element of the query tree that is the explicit NULL, which gets
   created as the initial target when variables are declared. It does
   this even when the variable has been previously declared and has had a
   value assigned to it, because assigning values happens during
   execution, not during parsing.
   
   Protection checking, however, happens in between parsing and
   optimization. Thus, a table name represented by a variable has no
   value when it comes time to check protections. Attempting to check
   protections causes an access violation because of the null pointer in
   the variable's value.
   
   In order to allow variables as table names, protection checks would
   have to be deferred until execution time. This has been done for
   Backup Server-> in order to allow variables to be used as database
   names in the dump/load commands. We don't do this for table names
   because it would change the way stored procedures work: normally, a
   procedure has whatever privileges its creator had at the time of its
   creation, but if protection checks are deferred to execution time,
   those checks get only get the privileges of the person running the
   procedure.
   
   Question: It's supposed to be legal to use variables for database
   names, so why don't I see the result of the print statement in this
   example


        1> set flushmessage on
        2> declare @dbname varchar(30)
        3> select @dbname="pubs2"
        4> print @dbname
        5> select count(*) from @dbname.dbo.sysobjects
        6> go

        Msg 102, Level 15, State 1:
        Server `REL1001_SUN4', Line 5:
        Incorrect syntax near `@dbname'.

   
   
   Answer: Your SQL contained a parse error, so the batch was never
   executed. Steps in executing a query are:
    1. Read the batch.
    2. Parse the batch.
    3. Optimize the batch.
    4. Execute the batch.
       
   
   
   Any failing step ends processing of the query.
   
  Threshold Management with @@thresh_hysteresis
  
   Question: The SQL Server Reference Manual Volume 2 (for release 10.x)
   section on sp_addthreshold reads: "When you add a threshold, it must
   be at least 2 times @@thresh_hysteresis pages from the next closest
   threshold." Why is this
   
   Answer: The "2 times" number is arbitrary. Any number greater than
   @@thresh_hysteresis would do the same job. Why must the distance be
   greater than @@thresh_hysteresis Because there must be a "buffer zone"
   above the hysteresis cutoff of a threshold and below the next
   threshold above it.
   
   If two thresholds are closer together than the buffer zone, and:
     * The higher threshold is "inactive" (that is, it has fired and is
       now waiting to cross its hysteresis distance before being
       reactivated),
     * Space in the database is rising, and
     * The free space has just gone above the inactive threshold,
       
   
   
   Then it is impossible to determine the correct action. The three
   possibilities are: to reactivate the lower threshold (which never
   actually fired), to fire the higher threshold (which shouldn't fire
   because its hysteresis distance hasn't been exceeded), or to do
   nothing.
   
   This "buffer zone" works out to a minimum of 128 pages-1/4MB on most
   systems.
   
  Methods for Monitoring Space
  
   Question: What is the best way to monitor space in 10.x
   
   Answer: There are four possible answers to this question, depending on
   what you want to monitor (devices, databases, segments, and so on).
    1. To monitor space on a device, execute the following query:


        select "free pages"=
        sum(curunreservedpgs(dbid,lstart,unreservedpgs))
        from sysusages u, sysdevices d
        where u.vstart between d.low and d.high
        and d.name = "this device name"

    2. To monitor space in a database on a device, add this line to the
       above query:

        and u.dbid = db_id("my database name")
    3. To monitor space in a database, use:

        select "free pages"=
        sum(curunreservedpgs(dbid,lstart,unreservedpgs))
        from sysusages
        where dbid = db_id("my database name")
    4. If you want a display for one database organized by segments, use:

        select name, "free pages"=
        curunreservedpgs(dbid,lstart,unreservedpgs))
        from sysusages u, test..syssegments s
        where u.dbid = db_id("test")
        and u.segmap & power(2,s.segment) != 0
        order by s.name

   
   
   The stored procedures sp_helpdb and sp_helpsegment also give you space
   information. sp_helpdb gives you free space per database fragment, and
   sp_helpsegment gives you free space per segment.
   
  Dead/Infected Processes and the Stack Trace
  
   Question: Your SQL client dies and prints the message: "DBPROCESS dead
   or not enabled." You investigate a little further and find, the
   message "Current process infected" in the SQL Server error log. The
   server itself may have shut down without warning. What just happened,
   and how can you make your server healthy again
   
   Answer: The "current process infected" message is a very general
   message that indicates the occurrence of a serious error that the
   server couldn't identify or handle in a more elegant fashion. To
   handle the error, the server "infects" the responsible user process to
   remove it from the internal queues. The three most common versions of
   this message are "infected with Signal 10" which means the server
   encountered a bus error, "infected with Signal 11" for a segment
   violation, and "timeslice" which indicates a runaway user process. In
   some cases, the server will also do a shutdown, but usually only the
   user process is killed.
   
   The root cause can be transient memory corruption, compiled object
   (procedure, view, trigger, and so on) corruption, or a bug in SQL
   Server or the operating system.
   
   The SYBASE error log will usually contain the "current process
   infected" message followed by a stacktrace. Sometimes the stack trace
   is nonexistent or truncated to only a line or two, but usually it runs
   between 10 and 25 lines. Here is a sample from the error log:


        kernel: current process (0xab0004) infected with Signal 11
        kernel: pc: 0x177d5c bcopy (0x1b6000,0x454680,0x100,0x1d,0x6bd06f,0x58b
2e0
        kernel: ************************************
        kernel: SQL causing error: update ipaddress
        kernel: curdb = 5 pstat = 0x10100 lasterror = 0
        kernel: preverror = 0 curcmd = 197 program = isql
        kernel: 0x14809c ucbacktrace(0xab0004, 0x1, 0x41cf40, 0x0, 0x41e7d4, 0x
54cd48)
        kernel: 0x700c terminate_process(0x0, 0xffffffff, 0x5f2d80, 0x0, 0x96,
0x0)
...
        kernel: 0x160818 _coldstart(0x6, 0x0, 0xc6cb0, 0x0, 0x0, 0x0)
        kernel: end of stack trace, spid 8, kpid 11206660, suid 6

   
   
   Time-slice errors occur because SQL Server does its own process
   management, giving each user process CPU time in small slices. There
   are two server parameters for this, ctimemax and ctimeslice.
   ctimeslice is the recommended maximum time that a process should run
   before yielding, ctimemax is the absolute maximum amount of time a
   process can run without yielding before SQL Server infects it.
   ctimemax is usually set to 200 milliseconds (or 1500 milliseconds on
   pre-4.9.x SQL Servers), although the exact setting doesn't matter. If
   the server does infect a process that exceeds ctimemax, the message
   "kernel timeslice -201 current process infected" appears in the log
   (indicating that the process ran for 201 milliseconds) followed by a
   stack trace.
   
   Raising the ctimemax value can sometime alleviate the problem (that
   is, if the process is not truly runaway, but just requires 347
   milliseconds to complete, raising ctimemax to 400 will give it time to
   complete and all will be well). However, because of the possibility of
   further complications, this should be considered a temporary
   workaround and should be done only under the direction of Technical
   Support.
   
   One particular type of time-slice error sometimes occurs at sites that
   use remote servers. When a remote procedure call is made to the remote
   server, the local server gets a time-slice error. The stack trace
   indicates a call to the system function gethostbyname(), which reads
   the /etc/hosts file to find the IP address of the specified computer.
   If the /etc/hosts file is very long, gethostbyname() can take longer
   than ctimemax to return, and SQL Server will infect the process. One
   solution to this is to edit the /etc/hosts file and place the names of
   the desired hosts near the beginning, which helps ensure that
   gethostbyname() will return in a timely fashion.
   
   There is usually little you can do to directly solve these problems
   except to call Technical Support and send in your error log. Our first
   step is to compare your stack trace with known bugs reported in
   previous cases. Often, incoming stack trace cases can be identified
   and already have a fix available. If the stack trace does not match a
   known problem and is recurring, Technical Support will work with you
   to try to create a reproducible case that can be submitted for a bug
   fix. Often, however, the trace is spurious (as in the case of memory
   corruption) and never recurs.
   
  sp_columns Script on CompuServe
  
   
   
   Please note that the fix for the sp_columns problem (mentioned in
   volume 3 number 3) is in the customer-only section (Library 15,
   OpenLine Technical) on CompuServe.
   
   CompuServe members do not have access to this section without
   application and approval.
   
   To gain access to this library, you must fill out a form located in
   Library 1 (General Technical) and return it to the person indicated on
   the form. After validation, which takes about one business day, you
   will be given access to Library 15.
   
   If you are planning to download the sp_columns file as a fix, please
   be aware that there is a lag time for account validation before you
   will have access. If you cannot wait, please get the new script
   directly from your Technical Support engineer.
   
  AIX: isql Connect to Backup Server Hangs
  
   
   
   Problem: Sybase Technical Support recently had several cases in which
   a customer with System 10 upgraded to AIX version 3.2.5. Despite the
   fact that they installed the recommended patches per certifications,
   any dump or load command, for either a database or a transaction log,
   to any media, would hang. Backup Server was up and running, and sp_who
   showed the dump/load process in a state of RECV SLEEP. Testing
   revealed that this error occurred with releases 10.0, 10.01P1, and
   10.01P2.
   
   Explanation: Socket connections were not being provided to the Backup
   Server as expected. In cooperation with IBM, Sybase Technical Support
   determined that additional patches from IBM are required. The
   following table lists the patches installed, along with a brief
   description of what each patch addresses:


Patch Number    Description


U432 635        Addresses system crash

U432 692        Object directory missing objects and memory usage
                accounting overflows

U432 696        Same as 692

U432 699        Same as 692

U432 713        Fixes C2X (X.25) adapter to available state

U432 839        System crash on auto start / add missing fields to
                crash / crash print missing

U432 841        CSX (X.25) won't execute polling inside quotes

U432 875        Copy to raw logical volume will exit if write fails

U432 877        Watchdog set to 10 seconds

U432 949        errpt -t truncates labels to 10 columns

U432 973        tli: t_listen does not set tno data. This is the patch
                that Sybase Technical Support thinks made the real
                difference for the hanging isql problem.

  HP: installasync80 and SAM Problems
  
   
   
   Problem: If you use installasync80 to rebuild your HP-UX 9.04 kernel,
   and then use SAM to change a kernel parameter, SAM rebuilds the kernel
   and reboots the system, losing the changes made by installasync80.
   
   Explanation: Hewlett-Packard has informed us that the SAM utility does
   not see the changes made by the installasync80 script, and
   asynchronous I/O is not a documented feature of HP-UX. To avoid
   problems, re-run installasync80 after each time you use SAM.
   
  HP: Swap Space and Memory
  
   
   
   Problem: You can't start SQL Server on a Hewlett-Packard machine when
   you have turned off Pseudo-Swap by setting the swapmem_on kernel
   parameter to false.
   
   Explanation: SQL Server uses lockable memory, and there is not enough.
   You cannot increase lockable memory via the unlockable_mem kernel
   parameter because swapmem_on, if set to true, automatically sets
   lockable memory to 75 percent of available memory, thus overriding the
   unlockable_mem parameter. Setting swapmem_on to true enables what
   Hewlett-Packard calls "Pseudo-Swap", which allows an effective
   swap-reserve space equal to all of the traditional swap plus 75
   percent of available memory. This works well as long as swapping
   activity does not exceed real swap space. If real swap space is
   exceeded, performance falls off drastically. The reason SQL Server can
   get the needed shared memory segments with swapmem_on set is because
   of this Pseudo-Swap feature. When you set swapmem_on to false, there
   is no longer enough swap space to reserve the shared memory segments,
   but the lockable memory is close to its maximum possible value.
   
   Solution: You want 75 percent of total available memory to equal 95
   percent of actual physical memory. One solution is to add a small
   (1GB) third-party disk drive to your machine. This will allow enough
   reserve swap space to handle the requirements of the dataserver.
   Increasing the 75 percent side of the equation with the added disk
   drive should increase the 95 percent side so that swapping never
   happens and memory is never written to that disk drive. Monitor the
   machine to ensure that you do not use so much memory in shared memory
   segments that it causes swapping to occur. Also monitor physical
   memory utilization and do not push it above 95 percent.
   
  AT&T (NCR): 1605 and "Illegal Calling Sequence"
  
   
   
   If you encounter an "Illegal Called/Calling Sequence" message along
   with the 1605 error in the Sybase error log, AT&T (NCR) recommends
   that you install TCP patch PTCP201-F. Make sure that you are running
   the most recent 2.01 version of TCP, currently 2.01.01.08.
   
   You can contact your AT&T (NCR) representative for detailed
   information about this patch.
   
  Solaris: Sunlink, "Master Network Listeners Failed"
  
   
   
   Problem: You tried to install SQL Server on top of Sunlink Token
   Interface/Sbus (TRI/S) 3.0 firmware and saw the following sequence in
   your error log:


        00:94/06/14 14:39:39.66 server  Number of buffers in buffer cache: 1584
.
        00:94/06/14 14:39:39.66 server  Number of proc buffers allocated: 396.
        00:94/06/14 14:39:39.66 server  Number of blocks left for proc headers:
 341.
        00:94/06/14 14:39:39.66 server  Opening Master Database ...
        00:94/06/14 14:39:39.70 server  Loading SQL Server's default sort order
 and character set
        00:94/06/14 14:39:39.94 kernel  ninit:0: listener type: master
        00:94/06/14 14:39:39.94 kernel  ninit:0: listener endpoint:/dev/tcp
        00:94/06/14 14:39:39.94 kernel  ninit:0: listener raw address: cx000280
03bf0d00320000000000000000
        00:94/06/14 14:39:39.94 kernel  ninit:0: transport provider: T_COTS_ORD
        00:94/06/14 14:39:39.94 kernel  ninit: t_bind, No Error
        00:94/06/14 14:39:39.94 kernel  ninitconn_free: t_close,fd =5, Illegal
file descriptor
        00:94/06/14 14:39:39.94 kernel  ninit: All master network listeners hav
e failed. Shutting down.
        00:94/06/14 14:39:39.94 kernel  ueshutdown: exiting

   
   
   Solution: Here is a workaround that will enable you to install and
   start SQL Server on the Token Ring. You must disable the Token Ring
   capabilities so that you can start SQL Server, and then restart the
   Token Ring, as follows:
    1. Log in as "root" and then execute the command ifconfig tr0 down to
       disconnect the TRI/S from SunOS.
    2. Install SQL Server, making sure that the port selected is an even
       number greater than 1020.
    3. Connect the Token Ring board back to the operating system by using
       the command ifconfig tr0 netmask tcp/ip address -trailers up. You
       must have trailers up as it is used in the LLC packet
       encapsulation.
    4. Start SQL Server.
       
   
   
   On Solaris, SYBASE supports TLI as the network API with a TCP/IP
   network protocol by using the /dev/tcp network type device. This is
   done by using the standard TLI calls. Furthermore, the mechanism that
   SQL Server uses to attach port numbers is dynamic, which is part of
   standard TLI interface. This means that the your network architecture
   must support this implementation. You can use different low-level
   architecture, such as X25 protocol or Token Ring or Ethernet links,
   but you must configure the network to support standard TLI calls.
   
  VMS: MTI 4mm HSC Tape Drive No Longer Supported
  
   
   
   Problem: If you use the MTI 4mm HSC tape drive you will experience
   problems using SQL Server 10.0.2. A VMS DATAOVERUN error is returned
   at load time.
   
   Explanation: The 10.0.2 Backup Server has been modified to increase
   dump/load performance. This was accomplished by changing the I/O
   strategy to the archive device from fixed 2K to varying length I/O up
   to 54K.
   
   While testing this new strategy in-house, Sybase Engineering
   discovered a bug with a 4mm device made by the third party vendor
   Micro Technology (MTI). You can work around it by dumping the database
   using the BLOCKSIZE=2048 parameter. However, performance will be poor.
   
   
   As a result, Sybase cannot support the MTI 4mm HSC tape drive; in
   fact, the manufacturer, MTI, no longer supports it. Sybase does
   support 4mm drives on DEC; testing has been successful with the DEC
   4mm (rlz06) tape drive.
   
  bcp: Determining Data Logged
  
   
   
   Question: Sybase Technical Support recently received a call from a
   customer who was bulk copying 1 million rows of data, 885 bytes each,
   with no indexes or triggers (so fast bcp was being used), resulting in
   about 21MB of data being logged. The customer thought this was
   unusually high and that there might be a bug. However, this is normal
   behavior, even for fast bcp.
   
   Answer: Most of the added records (except for the physical
   begin/commit tran) are records having to do with changing the column
   sysindexes.last; this logging is done to track the allocation of pages
   and which is the last page, so that SQL Server can roll back an
   incomplete bcp if the machine crashes or if a shutdown occurs in the
   middle of the bcp. This accounts for the growth in syslogs.
   
   Adding 2000 rows to a table causes syslogs to grow by about 43 pages.
   Adding 1 million rows would be about 21500 (43MB) pages of log, which
   is higher than the customer's figure, but the 21500 figure is only an
   estimate.
   
  DB-Library: dbcursoropen() Returns NULL
  
   
   
   Problem: Opening a cursor in the 10.0 release of Open Client
   DB-Library->/C with the following statement:
   
  dbcursoropen(dbproc,"select type from pubs2..titles,...)
  
   
   
   results in a return of NULL values. On Sun4/OS4, SQL Server crashes
   with a stack trace; on RS6000 the cursor-open attempt just fails.
   Changing the database context to pubs2 and then opening the cursor
   without the full table address succeeded. This was logged as bug
   53143.
   
   Solution: The use of table aliases and full table-name recognition has
   been added to DB-Library cursors. It is available with the latest
   one-off EBF for DB-Library (#3197 for RS6000, # 3198 for Sun4, #3199
   for HP9800) and will be included in subsequent rollups.
   
  DB-Library: dbclose() and File Descriptors
  
   
   
   Question: File descriptors appear not to be reused when I try to
   re-establish a SQL Server connection. Does DB-Library close a file
   descriptor when a connection is broken or does dbclose() have to be
   called, regardless
   
   Answer: DB-Library marks a DBPROCESS DBDEAD when a connection goes
   bad. You should call dbclose() to close out the file descriptor.
   
  Embedded SQL: Target of INTO Clause
  
   
   
   Problem: According to the Open Client Embedded SQL Programmer's Guide,
   the target of an into clause can be either a table, as in
   Transact-SQL, or a list of host variables. However, users of the
   10.0.1 release of Embedded SQL-> attempting the following command:

        EXEC SQL select * into table1 from table2
        or
        EXEC SQL select * into #table1 from table2

   
   
   receive the following run-time error message:

        **SQLCODE=(-25006)
        ** SQL Server Error
        ** Unexpected CS_ROW_RESULT received.

   
   
   Solution: This behavior was determined to be a bug, numbered 54619,
   and has been fixed. The fix will be available to customers in a future
   Rollup.
   
  Embedded SQL: EXEC PROC Enhancement
  
   
   
   In releases prior to 10.0.2, it was not possible to execute a stored
   procedure that returned data rows in Embedded SQL. As of 10.0.2,
   however, the EXEC PROC statement has been enhanced to allow a single
   select statement in the procedure.
   
   You can declare a procedure:


        create procedure myproc (@p1 int, @p2 out) as
        select c1, c2 from t1 where c3 > @p1
        select @p2 = count(*) from t1 where c3 <= @p1

   
   
   and then use Embedded SQL to execute it:


        exec sql exec :retval = myproc (:hv1, :hv2 out)
        into :hv3, :hv4;

   
   
   The same rules apply to the into hv-list clause in this example as
   apply to a straight select statement -if you select more than one row,
   you must have array host variables or you will get a cardinality
   error.
   
   The latest Embedded SQL EBFs support this feature (feature # 56616),
   and it will be in the 10.0.2 Rollup.
   
  Embedded SQL/COBOL: Memory Leak in libcobct.a
  
   
   
   Users of the 10.0 or 10.0.1 release of the Embedded SQL/COBOL
   precompiler may encounter this problem: a program runs successfully
   for more than 100,000 rows of cursor processing and then begins to
   fail. This is a known bug involving a memory leak in libcobct.a (the
   COBOL interface to Client-Library and CS-Library, in the veneer
   layer). The latest precompiler EBF fixes this problem (starting with
   EBF 2887). The EBF is from the 10.0.1 P2 mass ship code line, and you
   need the 10.0.1 SQL Server to run it.
   
   On UNIX, you can check for memory leaks by using ps -v to examine your
   program's memory size; if it keeps growing, you may have a leak.
   
  Mainframe Access Products: Latest EBFs
  
   
   
   Here is the latest list of available rollup Mainframe Access Products
   (MAP->) EBFs as of 11/14/94. This list replaces all previous lists. Be
   sure to read the important notes after it. Mainframe Access Product
   Catalog # Rel. 2.x EBF # Rel. 3.0 EBF # Open Client(tm)/Mainframe for
   CICS/LU6.2 19320 2932 N/A Open Server/Mainframe for CICS/LU6.2 19300
   2218 3528 Open Server/Mainframe for CICS/TCP_IP 19350 N/A 3529 Open
   Server/Mainframe for IMS/LU6.2 19315 N/A 3527 OmniSQL Access
   Module(tm) for DB2 (CICS/LU6.2) 19311 1971 3961 OmniSQL Access Module
   for CICS/TCP_IP 19360 N/A 3962 OmniSQL Access Module for IMS/LU6.2
   19370 N/A 3526
     * Open Client/Mainframe is at release 2.0, and is supported for
       CICS/LU6.2 only.
     * Open Server/Mainframe is at release 3.0 and is supported for
       CICS/LU6.2, CICS/TCP-IP, and IMS/LU6.2.
     * OmniSQL Access Module (OSAM) for DB2 is currently at release 10.1.
       4.
     * All mainframe products currently in release require use of the
       product Net-Gateway(tm), thus the references to Net-Gateway EBFs
       required for OS/MF or OC/MF or OSAM to perform correctly.
     * All Trinzic (InfoHub) customers need the latest 3.0 Net-Gateway
       and Open\x11Server/CICS EBF.
     * Some Open Client/CICS customers using EBF 2932 or below may need
       the latest Net-Gateway EBF for their particular platform; it
       contains a SQL Server name-length fix.
       
   
   
   Here is the latest list of all available rollup Net-Gateway EBFs as of
   11/14/94:

Net-Gateway
Platform        Catalog #       Rel. 2.x EBF #  Rel. 3.0 EBF #

HP9000/800      17700           N/A             3518
OS/2            16230           3882            3.0 GA
RS6000          12670           3887            3517
Solaris         12950           N/A             3772
SunOS           18600           3843            3516

    MAP Notes
    
   
   
   EBF 3961 (available now) replaces two EBFs, 3830 (which was
   mass-shipped) and 3524 (whose shipping was stopped); it will mass-ship
   soon. EBF 3962 will also mass-ship soon, to replace EBF 3525. EBFs
   3528, and 3529 mass shipped to all licensed customers around the week
   of 10 October 1994. Please make sure you have these EBFs and plan to
   install them with your 3.0 MAP products soon. All EBFs have been
   through complete QA and regression testing and constitute the latest
   maintenance codeline for 3.0/10.1 MAP customers.
   
   If you received EBF 3830 or 3524, you should not install them, but
   instead, wait for 3961.
   
   Please note that these Mainframe EBFs now ship automatically as part
   of any new product order. They do not ship automatically for trial
   licenses.
   
   The following errors have been corrected with current or upcoming
   EBFs:
    1. With EBF 3050 or 3051 applied (OSAM/DB2 CICS only), the following
       occurs:
       
       If a query selects more than 2 decimal columns, the third and
       subsequent column of DB2 decimal types are not sent to the client.
       The problem occurs with decimal columns defined using NOT NULL or
       NOT NULL WITH DEFAULT. There doesn't seem to be a problem with
       decimal columns defined as "nullable" (the default). Fixed on EBFs
       3528 and 3529.
    2. For customers using PL/I only, EBFs 3005 and 3006 have a syntax
       error in the INCLUDE library member SYGWPLI that causes a compile
       error. Fixed on EBFs 3528 and 3529.
       
       The SYGWPLI source in question: DECLARE TDS_INPUTVALUE FIXED
       BIN(31) INIT(0) STATIC; TDS_RETURNVALUE FIXED BIN(31) INIT(1)
       STATIC; Should read: DECLARE TDS_INPUTVALUE FIXED BIN(31) INIT(0)
       STATIC, TDS_RETURNVALUE FIXED BIN(31) INIT(1) STATIC;
       
       The semicolon ending TDS_INPUTVALUE is replaced with a comma.
    3. In EBFs 3005 and 3006, the commentary header in the INCLUDE
       library member SYGWPLI, and the commentary header in the MACLIB
       library member SYGWASM, read "Rel 2.0". In fact, this is the
       latest Rel. 3.0. Fixed on EBFs 3528 and 3529.
    4. All MAP EBFs now support RPC parameters that are greater than 32K
       but less than 64K, without needing the latest Net-Gateway EBFs.
    5. All MAP EBFs now support RPC parameters greater than 64K, if you
       also have the latest Net-Gateway EBF 3516 or higher, depending on
       your platform, and if you use the new Net-Gateway start-up option
       -E to enable this support. The new OS/2 GA about to be released
       has this support built in.
    6. VS/COBOL (old COBOL) programs no longer abend (new problem with
       MAP release 3.0).
    7. Open Server/Mainframe for CICS applications can run with the 3.0
       stub without having to relink.
       
    Net-Gateway Notes
     * A release 2.x Net-Gateway can run with a CICS LU6.2 MAP product at
       the 3.0 or 10.1 release level, but it cannot utilize any new
       functionality. For migration purposes, always upgrade the
       mainframe code first, then the Net-Gateway.
     * The new 3.0 Net-Gateway EBFs include:
          + memory leaks fixed;
          + group password no longer displayed;
          + new -C start-up option to roll lowercase userid/passwords
            into uppercase before sending to mainframe;
     * The new 2.0 Net-Gateway EBFs include:
     * group password no longer displayed;
     * new -C start-up option, as described above;
     * sygc gateway control program fixed.
       
  Server Documentation Bugs Fixed
  
   
   
   4.9.2 SQL Server documentation bug #46986, clarifying the use of
   sp_logdevice, has been fixed for the 10.0 release. If a database log
   is on a log-only segment and you execute the command sp_logdevice
   mydb, newlogdev, nothing moves, and you end up with two log devices.
   The current documentation clarifies that if you used the log on option
   of create database to put the log on its own segment, you must use
   sp_extendsegment to increase the size of the log segment.
   
   Also fixed is 10.0 SQL Server documentation bug #54342 pertaining to
   sp_rename in the SQL Server Reference Manual. It is now specified that
   if the object to be renamed is an index, the object name must be in
   the form table.indexname. Please make a note of these corrections
   until you receive the revised documentation.
   
  Connectivity Documentation Bugs Fixed
  
   
   
   Here are some recent documentation bug fixes for 10.0 documents:
   
    DB-Library Reference Manual
    
   
   
   Bug #, Description
   
   59529
          Found in release 10.0; may apply earlier. In the dbfcmd
          section, in the table "dbfcmd Conversions", the entry "char"
          should read "char* (null-terminated string)".
          
   49039, 54084
          (Duplicate bugs) BCP_SETL Between releases 4.x and 10.0, the
          BCP_SETL macro became bcp_setl in the reference manual. The
          macro name itself was not changed.
          
   53814
          10.0. Two-Phase Commit Service (Chapter 4). SQL Server 10.0 is
          not compatible with pre-10.0 probe versions. This is not stated
          in early copies of the 10.0 reference manual, however, a note
          has been added to the section entitled "The Probe Process" in
          the latest revision of the 10.0 reference manual, dated August
          5 1994.
          
   59918
          In Table 2-29 ("Common Errors" for dberrhandle()), the error
          handler cannot return INT_CONTINUE for "timeout on login"
          errors as indicated in footnote c. When you return
          INT_CONTINUE, DB-Library does a check; if the error was other
          than SYBETIME, DB-Library prints an informational message, then
          treats it as though INT_EXIT was returned. The footnote still
          applies to SYBETIME errors.
          
    Common Libraries Reference Manual (release 10.0.x)
    
   
   
   Bug #, Description
   
   61570, 57794
          cs_set_convert, "Parameters" section, "func": Parameter "func"
          is a pointer to a CS_CONV_FUNC variable. In the explanation,
          both uses of the "func" should be "*func". "*func" is the
          address of the custom conversion routine. Note that
          CS_CONV_FUNC is itself a pointer to a function. See code sample
          following this table.
          
   61793
          cs_convert "Parameters" section: (Under srcfmt) maxlength: The
          length of the data in the srcdata buffer. This field is ignored
          for fixed-length source datatypes.
          
          srcdata - A pointer to the source data. To indicate that the
          source data represents a null value, pass srcdata as NULL. If
          srcdata is NULL, the null-substitution value for the datatype
          indicated by destfmt is placed in *destdata.
          
          The simplest way to use cs_set_convert is to declare a program
          variable as a CS_CONV_FUNC type, and then pass the address of
          the variable to cs_set_convert. Here is some sample code:
          

/*
** This code assumes that MyEncrypt is a custom conversion routine
** defined according to the documented guidelines.  In this case,
** MyEncrypt converts from the CS_CHAR to the user-defined type
** indicated by ENCRYPT_TYPE. This fragment installs MyEncrypt.
*/
CS_CONV_FUNC                    myfunc;
myfunc = MyEncrypt;
if (cs_set_convert(cp, CS_SET, CS_CHAR_TYPE,ENCRYPT_TYPE,
                                &myfunc) != CS_SUCCEED)
{
        fprintf(stdout, "cs_set_convert(ENCRYPT_TYPE failed!\n");
        (CS_VOID)ct_exit(cp, CS_UNUSED);
        (CS_VOID)cs_ctx_drop(cp);
        exit(1);
}

    Open Client/Server Supplemen
    
   
   
   The 10.0 UNIX version of the Client/Server Supplement has an error in
   Appendix A, in the reference pages for the cpre and cobpre utilities.
   The -g flag was incorrectly left in the syntax statement for these
   utilities. The -g flag is no longer supported and should be deleted
   from the syntax statement.
   
  Latest Server Certification Report
  
   
   
   The latest SQL Server Certification Report is available on the
   CompuServe OpenLine Sybase forum and will be available with the next
   AnswerBase release (due in February of 1995).
   
  Bugs Fixed in 10.0.2 SQL Server Release
  
   
   
   This is a list of selected bugs in the 10.0.1 release of SQL Server
   that have been fixed in the 10.0.2 maintenance release. We encourage
   you to upgrade to 10.0.2 as soon as you receive that release!
   
   Bug #, Description
   
   51229
          Can't dump data from a data device that exists on a device
          defined as a hard link to a raw partition created by the UNIX
          command ln. dump database fails with the message "Backup
          Server: 4.56.2.1: device validation error: couldn't validate
          tape drive characteristics for drive %s: invalid argument."
          
   55379
          If the dump device and the database device are both character
          special devices, dump fails with vague errors like
          "Multibuffering subprocess died." On the OS console, you will
          see errors like "get_membuf: shmget, Invalid argument."
          
   46958
          Views can't be created on tables with more than 46 columns.
          create view returns without error, but the view does not appear
          in sysobjects.
          
   49012
          After a dump and a load, a table with an identity field gets
          its identity value starting from 1 again, instead of continuing
          from the last generated value.
          
   50703
          A query involving divide by zero gets error 3621 and is
          aborted, even when arithabort option is set to off; hence, no
          result is generated from the query. For example: select 10/0,
          name from sysusers returns 0 rows.
          
   50932
          Subqueries and aggregates that require an initial "bylist
          projection" step can be processed inefficiently, and, in some
          cases, can return the wrong results. This is due to creating a
          cross product internally or adding qualifications for this
          setup.
          
   50946
          select isnull(column,10) from table where column is
          numeric(5,0) with identity will give the following message:
          "Illegal precision returned from SQL Server." (General case is
          a select isnull(54321.9865,5.6781).)
          
   51723
          sp_addsegment accepts dbname as a parameter, but performs
          sanity checks and adds the segment to the current database,
          whether or not it is the one named.
          
   51815
          sybsystemprocs is treated as a required database for SQL Server
          recovery, and will prevent recovery if the procs device becomes
          unavailable.
          
   51979
          Updating a column that has a rule or check constraint causes
          the "infected with 11" message, and the connection is broken.
          
   52294
          Optimizer can choose a table scan over a unique index when the
          index is on a numeric column and the column is compared to
          constant or dissimilar precision column in join.
          
   52558
          Defining a cursor using a statement like declare cursor_name
          cursor for select field from table where field like @pattern
          for read only gets DBPROCESS DEAD and stack trace with signal
          11. The pattern has to be some declared variable.
          
   52636
          Getting a 225 error ("Referenced object %s dropped during query
          optimization") when using a procedure to insert data into a
          table with constraints. The table is defined in another
          database.
          
   52669
          With unnamed constraints, given an alter table...drop
          constraint statement, the constraint appears to drop, but
          actually remains in place. This seems to happen only where
          table name lengths are >= 10 characters.
          
   52936
          Incorrectly placed decimal in select list of query causes SQL
          Server to stack trace with "current process infected with 11."
          Repeating this can cause SQL Server to hang.
          
   53028
          SQL Server crashes with 8211 error when running client cursor
          that generates too many work table IDs. It might happen with
          any kind of cursor.
          
   53080
          Executing a stored procedure with auditing turned on as an RPC
          results in DBPROCESS DEAD OR NOT ENABLED message and
          termination of connection.
          
   53273
          create table x (i int nul); insert x values (null+null) results
          in infection with 11 and stack trace.
          
   53373
          A table with multiple referential constraints does not enforce
          the latter constraints in the case where a NULL happens to be
          inserted in any column of the first constraint.
          
   53772
          Running a simple ESQL/C query using host variables gives stack
          trace. For example: declare cursor idlo for select logon_id
          from table where logon_id > :logon_id
          
   54367
          Creating a stored procedure that accesses a temporary table
          created by a parent-level procedure (see SQL Server 10.0 System
          Administration Guide pg. 13-12), the data is inaccessible to
          the child-level procedure; rows are affected, but the data is
          "invisible".
          
   55813
          SQL Server process seg faults (infected with 11) in appnd_log()
          and leaves behind a semaphore lock; the process holding the
          lock does not show up in sp_who. sp_lock shows a non-existent
          process.
          
   55862
          Deleting rows from a table containing text data via a
          multi-table join may result in 1129 error and subsequent 2540
          errors. This is the same as 21529 and 50353 in 4.0.1 and 4.9.x.
          
   56127
          Range levels are incorrect when a subquery selects from a view.
          
   56186
          A query that selects into a temporary table but fails with a
          303 error causes a temporary table to be left in tempdb. It
          cannot be dropped without directly updating system tables.
          
   56226
          3307 errors occur when an error such as a duplicate key occurs
          while inserting into a temporary table with a unique index.
          
   56540
          sp_lock: on a system with thousands of locks in use,
          overflowing the temporary buffer used to insert into syslocks
          can also result in stack corruption and subsequent seg fault
          (infected with 11 message).
          
   57238
          Stored procedure containing create table with primary key
          clause generates 2620 and stack trace when executed for the
          third time (happens with temporary tables and user tables).
          
   57340
          convert function produces incorrect results if its argument is
          the result of an aggregate that evaluates to NULL. The result
          is garbled.
          
   57590
          Executing a stored procedure via RPC, with auditing enabled,
          results in DBPROCESS DEAD and lost isql connection. Error log
          shows infected with 11 in prot_search function. Refer to bug
          53080, a previous version of this problem.
          
   57694
          sp_columns incorrectly reports a precision of NULL for char,
          varchar, and other types. This is a regression of 4.9
          functionality, in which the length of the field was reported
          when the precision in spt_datatype_info was NULL.
          
   58138
          ctrl-c (^c) behavior is random. It is sometimes ignored and
          sometimes causes core dump.
          
   58332
          dbcc checkdb(dbname, skip_ncindex) fails with 603 error if the
          database has more than 16 tables with clustered indexes in
          them.
          
   58563
          sp_columns incorrectly returns datatype, precision, etc.,
          causing Microsoft ODBC driver to indicate errors. Also, a
          duplicate key in spt_datatype_info can cause sp_columns to
          return two rows for a column, resulting in ODBC errors.
          
   59436
          When chained transaction mode is on, there is a possibility
          that a bogus ENDXACT record with xactid(0,0) could be written.
          This would lead to 605 error during recovery.
          
  Bugs Fixed in Latest Connectivity Maintenance Releases
  
   The following tables contain a selection of bugs fixed for the 10.0.2
   maintenance release of Sybase connectivity products. This is not a
   comprehensive list; the complete list is available on the Sybase forum
   on CompuServe.
   
    Bugs Fixed in Open Client/Open Server Common Libraries 10.0.2
    
   
   
   Bug #, Description
   
   56638
          The MACROs _MSC_VER and __STDC__ are not consistently protected
          by #if defined() in csconfig.h. This causes warnings when the
          compiler doesn't define the macros.
          
   50044
          cs_objects(CLEAR) when fnlen = CS_UNUSED, lnlen = CS_WILDCARD,
          type = CS_CONNECTION, threadlen = CS_UNUSED, scopelen =
          CS_UNUSED does not remove all connections.
          
   46893
          comn_chartonum-if CS_SRC_VALUE is specified for
          precision/scale, the leading zeros of the converted
          (dest->array) are not stripped after the conversion, which
          usually results in the CS_NUMERIC having a value of 0.000.
          
    Bugs Fixed in Open Client Client-Library 10.0.2
    
   
   
   Bug #, Description
   
   61407
          blk_sendrow used a static variable, causing it not to be
          thread-safe. Multiple client blk_sendrow sent another client's
          row to the SQL Server, causing database corruption
          
   58019
          RPC return parameter of type NUMERIC or DECIMAL always returns
          0.
          
   57450
          Password encryption causes ct_connect() to hang.
          
   53793
          When statistics io/time is on, ct_send core dumps.
          
   57732
          Client-Library application crashes because of memory
          corruption.
          
   58008
          Client-Library reports an internal state machine error when an
          update is done on a table with timestamp and a trigger.
          
   53508
          Fetching between multiple cursors can cause assertions after
          one of the cursors gets to end-of-data. If this end-of-data
          cursor does not call ct_results() immediately after
          ct_fetch()->END_DATA, an assertion occurs when another cursor
          fetches.
          
    Bugs Fixed in Open Client DB-Library 10.0.2
    
   Bug #, Description
   
   59551
          Memory leak in isql.
          
   58703
          Memory leak when dbopen() fails.
          
   58576
          bcp crashes when copying in numeric columns in character
          format.
          
   58103
          Memory leak in the DB-Library cursor code. The memory allocated
          during cursor operation never gets released.
          
   54965
          bcp (and isql) crashes if a character set is specified and a
          larger-than-default packet size is specified.
          
   57333
          When there is holdlock in select statement, dbcursoropen fails
          with `incorrect syntax near keyword holdlock'.
          
   53604
          DB-Library hangs in an Open Server for AT&T (NCR), RS6000, HP,
          and Solaris platforms due to not being set up properly for
          signals.
          
   53815
          When a table has a composite primary key, repeated calls to
          dbcursorfetch() produce incorrect result sets. Some rows are
          missed and others are repeated.
          
   58138
          ctrl-c (^c) behavior is random. It is either ignored or
          sometimes causes core dump.
          
    Bugs Fixed in Embedded SQL/C 10.0.2
    
   Bug #, Description
   
   52939
          sqlca.sqlerrd[2] should be set to rowcount on a successful
          fetch.
          
   53129
          -G beginning of .sql script should drop the procedure it is
          about to create if it exists- otherwise, developer has to drop
          it manually each time a file is precompiled.
          
   53255
          char * host variables used as descriptor names cause ASSERT
          (M_INTERNA L_ERROR) in cdgsvs.c line 156.
          
   53798
          When selecting into an array, the number of the row selected is
          not returned in the sqlca.
          
   54506
          The get descriptor always returns 0 (even for the "nullable"
          column).
          
   54619
          Using EXEC SQL SELECT... INTO TABLE gives error "-25006
          Unexpected CS _ROW_RESULT received."
          
   55190
          -G and open cursor (static). If there is any static dml
          statement (which we generate a stored procedure for) in the
          source file between the CURSOR DECLARE statement and the CURSOR
          OPEN statement, the wrong procedure number is generated for the
          OPEN.
          
   55761
          Use of the :indvar = INDICATOR clause of the get descriptor
          statement does not work- indvar is not referenced in the
          generated code.
          
   56351
          -G and NUMERIC datatypes-the generated procedure parameters do
          not have a precision/scale in their declaration. The default
          precision an d scale you get in this case is (18,0).
          
   56616
          Add an into clause to the exec stproc statement so you can have
          1 result set in a user-defined stored procedure.
          
   56732
          Indicators are not supported with host variable in the
          parameter list of an EXEC_PROCEDURE statement.
          
   59448
          ESQL/C raises a syntax error if you de-reference a structure
          pointer's element. If the host variable is a structure, a.b is
          legal syntax, but if it is a pointer to a structure, a->b is
          not legal.
          
   59814
          paraming a 0-length null terminated string host variable to SQL
          Server used to be interpreted as a single space in 4.0.4;
          however, it is interpreted as a NULL value in 10.0. Make the
          10.0 ESQL behavior the same as 4.0.4
          
   61469
          PREPARE and ALLOCATE DESCRIPTOR each allocate a connection
          every time they are called, but DROP PREPARE/DESCRIPTOR does
          not free this connection. Results in big memory leak.
          
    Bugs Fixed in Embedded SQL/COBOL 10.0.2
    
   Bug #, Description
   
   49210
          PIC strings for number type variables without "s" are not
          accepted. For example: 01 max-1000 pic 9(3)v9(2)
          
   53129
          -G beginning of .sql script should drop the procedure it is
          about to create if it exists- otherwise, the developer has to
          manually drop it each time a file is precompiled.
          
   53236
          The pic, usage, sign, synchronized, justified, blank, and value
          clauses can be specified in any order in standard DOBOL-cobpre
          requires them in the order listed above.
          
   53678
          ESQL/COBOL does not support "level 88" condition names.
          Precompiler should gobble and ignore everything following 88,
          up to the end of that declaration (terminating period, ignoring
          periods in decimal literals, etc.).
          
   53798
          When selecting into an array, the number of the row selected is
          not returned in the sqlca.
          
   54322
          -b (no re-bind) option is broken. If you use -b no binds are
          done. The cursor fetch appears to work, but no values are moved
          into host variables.
          
   54619
          Using EXEC SQL SELECT... INTO TABLE give error "-25006
          Unexpected CS _ROW_RESULT received."
          
   55297
          You get "M_INTERNAL_ERROR, Fatal Internal Error at Line
          162...symtab/littype.c" error when you use SQL Server to do
          syntax checking at precompile time, and you have an
          ESQL-statement with COBOL host variables as input parameters.
          
   56351
          -G and NUMERIC datatypes-the generated procedure parameters do
          not have a precision/scale in their declaration. Default
          precision and scale in this case is (18,0).
          
   56616
          Add an into clause to the exec stproc statement so that you can
          have one result set in a user-defined stored procedure.
          
   56732
          Indicators are not supported with the host variable in the
          parameter list of an EXEC_PROCEDURE statement.
          
   60105
          Dynamic execute USING SQL DESCRIPTOR always sends a NULL
          regardless of how DATA was set.
          
   61469
          PREPARE and ALLOCATE DESCRIPTOR each allocate a connection
          every time they're called, but DROP PREPARE/DESCRIPTOR does not
          free this connection. Results in big memory leak.
          
   61755
          Fetch into arrays for money and float datatypes doesn't work
          when occurs is > 1.
          
   62007
          4.0.4 allowed underscores in host variable names. This was
          dropped in 10.0. We've put it back for compatibility reasons.
          
   62102
          CS-DATETIME and CS-DATETIME4 ESQL/COBOL declarations are
          incorrectly treated as STRING_TYPE variables in cobpre logic.
          This causes the precompiler to raise the M_SCALAR_CHAR error if
          an application attempts to use the declarations in an ESQL
          statement.
          
    Bugs Fixed in Open Server Library 10.0.2
    
   Bug #, Description
   
   55984
          Re-entrant malloc problem... when accepting client connections
          at interrupt level, t_open() is called which mallocs space. If
          user is doing malloc we crash. 53416
          
          On the VAX/VMS platform, Open Server does not use the KEEPALIVE
          feature when communicating via TCP/IP. Hence, OMNI cannot
          detect PC connections that have been abnormally disconnected.
          
   57146
          Open Server doesn't send the parameters associated with the
          cursors.
          
   53799
          Increases the maximum number of RPC parameters to 32768 to
          greater than 255.
          
   58285
          Open Server crashes with segmentation fault when
          srv_lockmutex() is called inside stop handler.
          
   58734
          srv_dbg_stack() API always returns the stack of the current
          thread instead of the srvproc argument passed to it.
          
   52555
          If an attention comes in, there is no way to wake up a srvproc
          sleeping on a message queue without killing the srvproc.
          
   53862
          SRV_IODEAD isn't upward compatible. In 202, SRV_IODEAD returns
          TRUE for non-client threads, but in 10.0, it returns CS_FALSE.
          
   53172
          sp_serverinfo does not format the image information returned to
          the client correctly for either 1- or 2-byte character
          definitions.
          
   61612
          ct_cancel() to an Open Server does not work when it is in pass
          through mode. Open Server gets a fatal 16300 (SRV_EBADTOKEN)
          error.
          
   61785
          The srv_event was issued on a thread that is not event-driven.
          The Open Server does not do any error checking, regardless of
          whether or not the thread has a message queue associated with
          it.
          
   
     _________________________________________________________________
   
  Staff
     * Principal Editor: Leigh Ann Hussey
     * Contributing Writers:
          + Lance Andersen
          + Perry Bent
          + Dave Clegg
          + William Green
          + Bret Halford
          + Gerald Soulos
          + Elton Wildermuth
          + Anderson Consulting
          + Sybase Engineering
            
   
   
   Send comments and suggestions to:
   
   SYBASE Technical News
   6475 Christie Avenue
   Emeryville, CA 94608 USA
   
   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.
   
        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 ]
