HDTenEightyP/NetNews huggingface dataset:
From: "Warren Spencer (613) 541-7068" <EV2WS1%MISX01@KINGSTON.ARPC.ALCAN.CA>
Subject: Re: Ingres/VMS  application crashes: Why?
Organization: National Radio Astronomy Observatory
Date: Tue, 29 Sep 1992 19:22:00 GMT


>Usually, the message is "IMPROPERLY HANDLED CONDITION", and someone a
>while back suggested the cause to be a corrupted stack from bad source
>code.  I am looking for suggestions as to the cause.
>-----------------------------------------------------------------------

>Improperly Handled Condition, image exit forced.  Signal arguments

>NUMBER=00000005          STACK CONTENTS
>NAME=0000000C            80245040
>     00000001            00000002
>     46206E6F            7FEB1114
>     80000010            7FEB10FC
>                         00000004
>                         7FEB1B94
>                         00000001
>                         65756575
>                         03c00004
>                         00000000

>REGISTER DUMP

>R0=03C00000 	R1=46206e6f	R2=00000000	R3=00000000
>R4=FFFF00AA	R5=001A1A50	R6=001098C8	R7=0000012C
>R8=7FEB1186	R9=00009F20	R10=00009C30	R11=0000AB30
>AP=7FEB10B0	FP=7FEB1070	SP=7FEB10EC	PC=80000010
>PSL=03C00004

>-----------------------------------------------------------------------
>System-F-ACCUIO, access violation, reason, mash=05 virtual
>address=304142, pc-000c04e8, PSL=03C00000.  Please contact your
>Technical Support representative %System-F-Abort.

>Bruce Momjian                          |  830 Blythe Avenue
>root%candle.uucp@bts.com               |  Drexel Hill, Pennsylvania 19026 

Hi Bruce,

The three low-order bits of Reason Mask (in your case, 05), indicate why, in VMS 
or hardware terms, the image was terminated.  They indicate things like trying 
to write to code space, accessing data space outside your own, and stack 
overflow.  I do not recall the exact meanings, but if you consult the System 
Messages and Recovery Procedures manual on "ACCVIO" in the VMS documentation, 
you will find the explanation there.

A detailed link map should tell you what exists and the PC location (000c04e8), 
and this may provide additional clues.

The virtual address have indicated (304142) is six instead of eight characters.  
Is this value correct?  This value often provides significant clues as to what 
is going on.

As a last resort, you might try writing a VMS condition handler that traps the 
signalled condition.  Such a handler could spit out more detailed debugging 
information.  Condition Handlers are covered in the System Services 
documentation, but they are fairly complicated.  Hope this helps...

Warren Spencer
Ingres Specialist
InCAD Corporation
Ottawa, Ontario
(613) 723-5452


Newsgroups: comp.databases.ingres
From: corman@Ingres.COM (Anthony Corman)
Subject: Re: Ingres Null Indicator Un-documented Feature
Reply-To: corman@Ingres.COM (Anthony Corman)
Organization: Ask Computer Systems Inc., Ingres Division, Alameda CA 94501
Date: 30 Sep 92 15:30:21 GMT

In article <00961564272EF4A0.20400470@kaiser.spk.wa.us> mfgsys!birdsall@kaiser.spk.wa.us writes:
>
>   WARNING!! Ingres undocumented feature - NULL Indicator variables:
>
>      I recently discovered, and Ingres has verified, that contrary to Ingres
>   documentation, indicator variables can assume values other than '0' for
>   NOT NULL and '-1' for NULL. In particular, if one tries to write a char or 
>   varchar into a target shorter than the source length, the indicator variable
>   will contain the schema value of the source column instead of '0' for NOT
>   NULL... [stuff deleted]

Please note that this *is* documented: refer to page 3-15 of the INGRES SQL
Reference Manual, 'Indicator Variables and Character Data Retrieval.' On
page 3-12 there's a bulleted list that says:

"Indicator variables enable an application to perform the
following functions:

o Detect when a null value is retrieved

o Assign a null value to a table column, form field, or table field
  column

o Detect character string truncation"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
From: richard@asis.unimelb.EDU.AU (Richard Begg)
Newsgroups: comp.databases.ingres
Subject: Re: Reportwriter parameters
Date: 30 Sep 92 02:45:25 GMT

sfc@tpghq.com (Steve Caswell) writes:

|Please include more specifics, such as operating system type, version, etc.
|Many operating systems impose command line length limits.  For example, the
|VMS command line (and in fact the VMS input line) length is limited to 255
|characters.  This may be the limit you are bumping into.

Sorry about the lack of info.  Firstly we are running ingres 6.4/02 on a
Solbourne unix box under the eqivalent of SunOS 4.1.?

Reportwriter is being called directly from a exec call in C, although the
problem can be reproduced from a shell prompt.  It is not a problem
with the command line parameters as a whole, but rather with the length
of an individual parameter.

e.g. report <database> <report> "(param='...long string over 256 chars...')"
     will cause an error if the parameter is too long as the trailing (')
     appears to be truncated, causing the parser some grief.

whereas:
     report <database> <report> "(param1='... string < 256 chars ...' 
                                  param2='... string < 256 chars ...' 
				  ... etc ... )"
     will work just fine.

--
Richard Begg (richard@asis.unimelb.edu.au)
Admin Systems and Info Services - University of Melbourne.
Newsgroups: comp.databases.ingres
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: cloning a database
Organization: 
Date: Tue, 29 Sep 1992 20:03:53 GMT

In article <1992Sep29.135401.7778@news.columbia.edu>, 
alan@curta.cc.columbia.edu (Alan Crosswell) writes:
> Is there any way to use a checkpoint of a database to clone it?  I want to
> avoid having to do an unloaddb and reload of a large database which I want
> to clone into a test copy.  Given that I've already taken a checkpoint of
> my db, it seems natural to want to just use that tar file to populate the 
> clone rather than copying all those tables out again....

I think this can be done.  I think I've even done it (or things like it)
under VMS, but never UNIX, but the principles should be the same.  The
only caveat is to be _very_ careful to put the files in the right
directory.  But if you have the system privileges necessary to do this,
you better know what you're doing, right?

The following applies to INGRES release 6.0 through 6.4.

Try creating a new, empty database with the new name, owner, and
location(s).  Now shut down INGRES and use the tar file to populate the
data directory for the new database with everything _except_ the
configuration file (aaaaaaaa.cnf in the primary data directory for the
new database).  I.e., overwrite all the *.t00 file that are already
there for the empty database.

Bring up INGRES again.  You should now be able to access the new
database.

If you changed the dba or the locations then you may have to update
several system catalogs, and this is where it gets tricky and messy. 
Use the +U (better) or the +Y switch to do this.  Example:

		$ sql "+U" -unew_dba new_db
		update iirelation set relowner = 'new_dba' 
			where relowner = 'old_dba' \g

You may also have to change the dba name in the system catalogs that
hold database procedures, rules, and events; and front-end objects.  
Use the base tables for the views that constitute the standard catalog
interface, and not the standard catalogs themselves.  The standard
catalogs are documented in an appendix to the SQL Reference Manual.  For
example, "help view iiprocedures" reveals that "iiprocedure is the base
table.  Check these at least: iirelation.relowner, iiprocedure.dbp_owner, 
iirule.rule_owner, iirule.rule_dbp_owner, and iievent.event_owner. 
There may be others.

For the front-end objects, check these system catalogs and columns:
ii_objects.object_owner, ii_qbfnames.relowner,
ii_abfdependencies.abfdef_owner, and ii_sequence_values.sequence_owner. 
There may be others.  You'll also have to manually change the permits on
the front-end system catalogs (do "help permit ii_objects"), since these
permits are not stored as simple text in the database but also in
compiled form.

Good luck.  Let us know if it works.

--Mark Jaeger				internet: cs_mj@gsbvax.uchicago.edu
Graduate School of Business		yellnet:  (312) 702-0328
University of Chicago			faxnet:   (312) 702-0233
Disclaimer: My opinions are my own and not those of my employer.
Ich bin ein Virus.  Mach' mit und kopiere mich in Deine .signature.
From: mitchell@oac3.hsc.uth.tmc.edu (Philip Mitchell)
Newsgroups: comp.databases.ingres
Subject: Re: Multiple Ingres 6.3 servers on a Sequent
Date: 5 Oct 1992 21:34:38 GMT
Organization: UT Health Science Center Houston

In article <1992Oct5.194819.7766@sequent.com> map@sequent.com (Michael Perry) writes:
>
>Typically I recommend no more than N-1 servers where N=cpus online.

Gosh, I sure hope that's just for multiprocessor machines.  Otherwise I 
should be running 0 servers for my single processor. ;-)



-- 

   Phil Mitchell                                 Office of Academic Computing
   UT Health Science Center          6431 Fannin MSB 4.022, Houston, TX 77030
   voice: (713) 794-1189              internet: mitchell@oac.hsc.uth.tmc.edu
Newsgroups: comp.databases.ingres
From: melkor!valandil!mal (Michael A Leo)
Subject: Data presentation using X and Ingres
Organization: National Radio Astronomy Observatory
Date: Fri, 2 Oct 1992 16:11:26 GMT


Hi,

  We currently use the Ingres database engine to store and manage access
to data for our network management application.

  We use a curses like package (Vermont Views) to present data to the user,
as the Ingres text interface was not flexible enough to do what we needed
at the time.

  Some of our customers are finally getting workstations, X-terminals, and 
PCs.  These customers now want our data to be presented graphically.

  They do NOT want a graphical application. They just want a few people 
to be able to view data on charts, graphs, etc. in color on
X-based display.  They would also like to be able to print.

  They still want the application to be text based, as 99% of the users
will NOT access it from workstations.

  We are looking for solutions that would allow us to present our current
data graphically, in color, on an X-windows device, and allow us to print
this graphical data, on PaintJets, color Postcript printers, etc.

  We know about Ingres Windows/4GL, but are not interested in it because of
performance, cost, and licensing.

  Also, we are not certain W4GL is the optimal solution for graphics-based
presentation.  W4GL seems more geared toward GUI application development.
We need to run the X client on our database server, and do not want the 
extra baggage W4GL requires.

  Optimally, we would like an agreement similiar to that we have with
Vermont Views.  We pay a flat fee for the development kit on our development
workstations, and ship as many copies of the developed code without
additional cost.

  The package does not need to work directly with Ingres, but it would be 
nice.  We are a C development shop and already use various toolkits to 
get some of what W4GL offers, so another X toolkit doesn't bother us.

  If anyone is using any packages currently, or knows of any good packages
out there, please contact me at:

       Mike Leo
       mike.leo@adc.com
       (612) 936-8305

  My mail header is hosed, so do NOT use the "reply" function of your mailer.

Thank you.
Newsgroups: comp.databases.ingres
From: Tom Blythe <TJB@MATH.AMS.ORG>
Subject: Re: QUEL query language
Organization: National Radio Astronomy Observatory
Date: Mon, 5 Oct 1992 12:46:31 GMT

thompson@stars.gsfc.nasa.gov writes:

>I do know that C.J. Date has a very readable book out on Ingres QUEL.  I
>believe it's just called "Ingres".

The full title is:  A Guide to Ingres, C.J.Date, Addision-Wesley.
Published in 1987. ISBN: 0-201-06006-X

----------------------------------------------------------------------
Tom Blythe                               TJB@MATH.AMS.ORG
American Mathematical Society            (401) 455-4015
PO Box 6248, 201 Charles St.
Providence, RI 02940
----------------------------------------------------------------------

Newsgroups: comp.databases.ingres
From: s1110238@giaeb.cc.monash.edu.au (Lee Hollingworth)
Subject: Re: Embedded SQL
Keywords: C
Organization: Monash University, Melb., Australia.
Date: Sat, 3 Oct 1992 10:27:05 GMT

As a computer science student I have been given an assignment requiring embedded
SQL using either Cobol or C as the host language.

We have been given some sample code for use with Cobol, but nothing has been
made available yet for C.  Being an impatient soul, I was wondering if some
kind Ingres programmer could e-mail a "typical" example of some C code with
embedded SQL.

I am a reasonable C programmer, but need advise regarding the actual includes
(if required) and the EXEC SQL statements...

Lee Hollingworth
s1110238@giaeb.cc.monash.edu.au
From: pampel@hitkw09.pki-nbg.philips.de (Holger Pampel)
Newsgroups: comp.databases.ingres
Subject: -I flag for esqlc preprocessor
Keywords: ESQLC, include, directories, header files
Date: 1 Oct 92 07:12:05 GMT

Hi, there,

working on a big project with a source code repository and different domains
for developping and integration, we found it important to have the -I flag
functionality for the esqlc preprocessor on the EXEC SQL INCLUDE-files
as supported by all (?) C and C++ compilers.

INGRES recommends to use the unsupported -h flag, which should do the job.
Neither the INGRES hot line people nor we could make it work.
(Only the existence of the specified directory seems to be tested, but it is
not used.)

Any recommendations or workarounds (we use INGRES 6.4/01 on HP-UX 08.02).

Thanks & E-mail directly, I'll post a summary.
Holger Pampel
_________________________________________________________________________
Philips Kommunikations Industrie AG	Telefon / Phone: +49-911-526-6043
Abteilung / Departement LN		Fax:		 +49-911-526-3678
Thurn-und-Taxis-Strasse 10		E-Mail: pampel@pki-nbg.philips.de
D-W 8500 Nuernberg
		    "There's never enough time to finish a job but there's
			always enough time to correct it afterwards ..."
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Newsgroups: comp.databases.ingres
Subject: Re: Ingres Null Indicator Un-documented Feature
Date: 30 Sep 92 21:26:30 GMT

In article <1992Sep30.131427.8180@tpghq.com>, sfc@tpghq.com (Steve Caswell) 
writes:
> Undocumented? I don't think so.  Try page 3-15 of the INGRES/SQL Reference
> Manual, Release 6.4, December 1991, and I quote:
> 
> "When INGRES retrieves a character string into a host variable too small to
> hold the string, INGRES truncates the data.  ... If the host variable
> has an associated indicator variable, then the indicator is set to the
> original length of the data.

Granted it's there if you read far enough, but see also p. 3-13 of the
same manual:

    If the value retrieved is not a null, then the indicator variable is
    set to 0 and the value is assigned to the host variable.

I agree with Steve that it's unfair to say that the behavior is
completely undocumented, but I think it's also _fair_ to say that the
documenation could be beefed up somewhat.  E.g., make an explicit
statement about how to test for null versus not null (indicator is -1
versus not -1); or add a section call "How to Use Null Indicators in
Applications".  

I also think it's misleading to call it an "indicator" variable.  I was
certainly misled at first and failed to realize that this "indicator"
could take on more than just two different values.

--Mark Jaeger				internet: cs_mj@gsbvax.uchicago.edu
Graduate School of Business		yellnet:  (312) 702-0328
University of Chicago			faxnet:   (312) 702-0233
From: curt@emory.edu (Curt Stauffer)
Newsgroups: comp.databases.ingres
Subject: Selecting Ingres - Would you do it again?
Date: 6 Oct 92 13:11:15 GMT
Article-I.D.: emory.curt.29.718377075
Organization: Emory University

Emory University is looking for a UNIX database as part of a right-
sizing initiative. We would like to know what tools you are using to
develop applications to use with Ingres. What has your experience
been with this database and these tools? If you were going to choose a
UNIX database today, would you buy Ingres again? Why or why not?

Please reply to the following e-mail address rather than posting a
followup article.

Thank you in advance,
Curt
--
Curt Stauffer
Emory University Information Systems
Atlanta, GA
curt@emoryu1 (Bitnet)
curt@emory.edu (Internet)
From: map@sequent.com (Michael Perry)
Newsgroups: comp.databases.ingres
Subject: Re: Multiple Ingres 6.3 servers on a Sequent
Date: 5 Oct 92 19:48:19 GMT
Article-I.D.: sequent.1992Oct5.194819.7766
Organization: Sequent Computer Systems Inc.

In article <ncourdy.718039747@Endor> ncourdy@endor.sim.es.com (Nabil Courdy) writes:
>We are running Ingres 6.3 on a 2-CPU Sequent/2000.  The system is configured
>to run with 2 Ingres servers (fast_commit, write_behind, and shared_chache).
>Lately we noticed a significant degradation in performance.  It is taking up
>to 30 seconds to enter the sql terminal monitor.  As a test, I started a 3rd
>ingres server and dedicated it to the development databases using the -dblist
>server parameter. Other parameters are (fast_commit,write_behind, and 
>sole_server).  Performance does not seem to have improved.  The log file is
>only at 13% usage when we notice the degradation.  Tables are structured and
>optimized and there are no overflow pages.  Does anyone have any clues please ?
>Also the 3rd server has no iislave processes associated with it (Why?)
>
>Thanks, Nabil
>-------------

Nabil,

Typically I recommend no more than N-1 servers where N=cpus online.
There are many reasons for this but the main reason is that you
need to allow system process in there to get some work done.  Also,
with all cpus busy with server requests IIGCN doesn't get much CPU
time and makes connects take a LONG time.  This may be your problem.

Drop back to 1 ingres server and see what happens.  If you're on a Model
"D" board you should be able to get a good amount of connections running
before you'd need a 2nd server; Model "E" is even more powerful.

Let me know if this helps you...

Mike
---

Mike Perry
Regional Tech Support Specialist - Sequent
map@sequent.com
Newsgroups: comp.databases.ingres
From: SHARPIE%NETMON@ISUVAX.IASTATE.EDU (Sharpie)
Subject: INGRES job in Iowa
Reply-To: netmon: :sharpie@isuvax.iastate.edu
Organization: Iowa State University, Ames, IA.
Date: Fri, 2 Oct 1992 19:56:13 GMT

Qualifications for the Computer Specialist Position

Required for the Position:
	 1. Minimum 3 Years Experience in database application development
	    and support using INGRES on a VAX/VMS platform.
	 2. Experience using INGRES Vision Pro and INGRES Knowledge
	    Management tools.
	 3. Minimum 3 Years programming in C language on a VAX/VMS platform.
	 4. Minimum 2 Years programming in FORTRAN on a VAX/VMS platform.
	 5. Proficiency using DCL for a VAX/VMS platform.
	 6. Excellent communications skills (oral and written) and ability to
	    function well as a team player.
	 7. Minimum 3 Years full-time related work experience post-school.

Desired but not required:
	 8. College degree in Computer Science, Computer Engineering or 
	    related degree.
	 9. Experience with large-scale and/or real-time applications.
	10. Experience with Software Quality Assurance and/or Software
	    Engineering concepts and techniques.
	11. Nuclear Industry Experience
	12. Experience with Radiation Protection principles, practices and 
	    computer applications.
	13. Experience with PC applications and networks.
	14. Experience with VAX/VMS system management, DEC networks, VAX
	    clusters, DECWindows or X-Windows environments, UNIX, SNA
	    Gateways and multi-platform applications (IBM Mainframe, VMS and
	    UNIX mini-computers and PCs).
	15. Project management experience.

Iowa Electric offers an excellent work environment and benefits package. 
Successful candidates will be subject to a background security investigation,
pre-employment and random drug testing.  Candidates should submit their resume
and salary history to:  

		Iowa Electric Light and Power Company
		Duane Arnold Energy Center
		Attn:  Human Resources 
		3277 DAEC Road
		Palo, Iowa  52324 - 9783
	
    		  Affirmative Action / Equal Opportunity Employer	
Newsgroups: comp.databases.ingres,comp.unix.programmer
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: Catching division by zero
Organization: 
Date: Thu, 1 Oct 1992 20:35:22 GMT

In article <1992Oct1.085857.5512@visionware.co.uk>, chris@visionware.co.uk 
(Chris Davies) writes:
> I'm using C with embedded SQL (Ingres 6.4/01 on Sun4 SunOS 4.1.2).
> 
> The problem I've got is that Ingres doesn't warn me when I get an
> integer division by zero error in a SELECT statement, it just returns
> 0.  (The floating point stuff returns 0.Inf - an IEEE representation of
> infinity.  Yuk!)
> 
> For example, "SELECT 1/0" shows this problem (you can try it in sql or
> isql too).
> 
> After speaking with a member of Ingres Technical Support, who logged an
> enhancement request for me, they pointed out the '-xw' flag for the sql
> and isql terminal monitor applications.  (This flag terminates queries
> with /0 and generates an error - just like I would have expected in the
> first place.)
> 
> Now for the question.  Can anyone explain to me _how this flag works,
> and if so, how could I go about implementing this kind of error
> handling in my code?

Why not just use the signal() call with SIGFPE?  Supposedly this signal
is generated by arithmetic exceptions, such as divide by zero.

The signal() function declares a handler of your choosing.  When the cpu
tries to execute 1/0, it generates some sort of interrupt.  The OS's
interrupt handler figures out if you've declared your own, and if so
then calls it.  Your handler can choose whether to ignore the problem
(and continue); to replace the (nonsense) answer with a better one; or
to exit (the default).

--Mark Jaeger				internet: cs_mj@gsbvax.uchicago.edu
Graduate School of Business		yellnet:  (312) 702-0328
University of Chicago			faxnet:   (312) 702-0233
Disclaimer: My opinions are my own and not those of my employer.
Ich bin ein Virus.  Mach' mit und kopiere mich in Deine .signature.

Newsgroups: comp.databases.ingres