home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!swrinde!emory!emory!not-for-mail
- From: obelix.informix.com!johnl@emory.mathcs.emory.edu (Jonathan Leffler)
- Newsgroups: comp.databases.informix
- Subject: Re: Negative PIDS, and SE/Online questions
- Date: 12 Jan 1993 07:48:03 -0500
- Organization: Mailing List Gateway
- Lines: 71
- Sender: walt@mathcs.emory.edu
- Distribution: world
- Message-ID: <1iuem3INNci9@emory.mathcs.emory.edu>
- Reply-To: obelix.informix.com!johnl@emory.mathcs.emory.edu (Jonathan Leffler)
- NNTP-Posting-Host: emory.mathcs.emory.edu
- X-Informix-List-ID: <list.1773>
-
- >From: uunet!enuucp.eas.asu.edu!anasaz!qip.naomi (Naomi Walker)
- >Subject: Negative PIDS, and SE/Online questions
- >To: informix-list@rmy.emory.edu (Informix List)
- >Date: Mon, 11 Jan 93 10:04:59 MST
- >X-Informix-List-Id: <list.1769>
-
- >Question #1
- >The following is an excerpt from the Informix error log on a Pyramid
- >MIS-S server, runing 4.1 UC1 Online and 4.1 UC1 ESQL/C. I've seen these
- >negative pid's and funky user numbers before, and sloughed them off as
- >programming boo-boos. All I really know is that we had a scheduled reboot
- >of this machine, for another reason. Anyone seen this negative pid and
- >user id before or have any comments?
- >
- >Fri Jan 8 00:00:16 1993
- >23:12:45 Shutdown Mode
- >23:12:56 Process Aborted Abnormally: pid=-1541 user=1002 us=11001fd8 flags=1
- >23:12:56 Process Aborted Abnormally: pid=-21712 user=-25536 us=1100211c flags=1
- >23:12:56 Process Aborted Abnormally: pid=-18047 user=-25536 us=11002704 flags=1
- >23:12:56 Process Aborted Abnormally: pid=-8545 user=-21525 us=110028b4 flags=1
- >23:12:56 Process Aborted Abnormally: pid=-23189 user=21708 us=11002920 flags=1
- >23:12:56 Process Aborted Abnormally: pid=-24163 user=-25536 us=11002cec flags=1
-
- I'm guessing, but there are operating systems which use 16-bit PIDs
- whereas Unix always used to use 15-bit PIDs. If the Pyramid does use
- 16-bit PIDs, then it is a simple formatting problem. Similar
- considerations apply to user IDs. Could there be a user with UID = 40000?
- If so, then they were responsible for the lines user=-25536.
-
- >Question #2
- >My next question is about SE. I am very familiar with all the Informix
- >tools available to me when using Online. I am not familiar with SE.
- >In general, are the same or equivalent tools available when using the
- >standard engine (tbcheck)? How about all the sql statements, like
- >$ SET EXPLAIN ON/OFF, and $ ALTER TABLE to change things like lock modes
- >and next extent?
-
- SE and OnLine have very different sets of tools, mainly because SE uses
- ordinary Unix files to store its data and these can therefore be backed up
- using standard Unix facilities.
-
- There is a direct equivalent to tbcheck called bcheck, but bcheck is
- considerably less powerful than tbcheck. There are no equivalents for the
- other tb-utilities (tbinit, tbtape, tbspaces, tbload, tbunload, tbstat,
- tbmode, tblog, tbparams). The db-utilities (dbexport, dbimport, dbschema
- and dbload) are provided with both OnLine and SE.
-
- SQL statements are essentially compatible -- the differences are those
- imposed by the limitations of SE. SE does not support VARCHAR or blob
- (BYTE, TEXT) types. It does not have tablespaces, so you can't declare
- that a table should be created in a particular tablespace, but instead, you
- can specify the basename of the C-ISAM file which will hold the table. You
- cannot specify lock mode or extent sizes because the concepts do not apply
- to SE. Similarly, you cannot specify isolation level, nor can you set lock
- mode to wait with timeout.
-
- However, SET EXPLAIN and ALTER table (within the constraints about types
- listed above) are both available in both OnLine and SE.
-
- There are also a few extra commands which are only available in SE. For
- example, CHECK TABLE and REPAIR TABLE run bcheck on the named table.
- ROLLFORWARD DATABASE only applies to SE. CREATE AUDIT and DROP AUDIT only
- apply to SE.
-
- There are extra limitations on the DDL statements (CREATE/DROP Object) in
- SE as they cannot be part of a transaction (or, more precisely, cannot be
- rolled back even if they are part of a transaction). This also affects the
- behaviour of constraint checking and referential integrity checking.
-
- Yours,
- Jonathan Leffler (johnl@obelix.informix.com) #include <disclaimer.h>
-