execute procedure ima_set_vnode_domain;
select outbound_current from ima_gcc_info;

The latter is a bit more involved as there is no IMA table registered that exposes the relevant information. Browsing ima_mib_objects using:

select distinct(instance) from ima_mib_objects where instance like '%gcc%'

gives a nice list of GCC related entries we can query:

* select distinct(instance) from ima_mib_objects where instance like '%gcc%'g
Executing . . .
??????????????????????????????????????????????????????????????????
?instance                                                        ?
??????????????????????????????????????????????????????????????????
?exp.gcf.gcc.conn                                                ?
?exp.gcf.gcc.conn.al_flags                                       ?
?exp.gcf.gcc.conn.al_proto_lvl                                   ?
?exp.gcf.gcc.conn.flags                                          ?
?exp.gcf.gcc.conn.gca_assoc_id                                   ?
?exp.gcf.gcc.conn.inbound                                        ?
?exp.gcf.gcc.conn.lcl_addr.node                                  ?
?exp.gcf.gcc.conn.lcl_addr.port                                  ?
?exp.gcf.gcc.conn.lcl_addr.protocol                              ?
?exp.gcf.gcc.conn.pl_flags                                       ?
?exp.gcf.gcc.conn.pl_proto_lvl                                   ?
?exp.gcf.gcc.conn.rmt_addr.node                                  ?
?exp.gcf.gcc.conn.rmt_addr.port                                  ?
?exp.gcf.gcc.conn.rmt_addr.protocol                              ?
?exp.gcf.gcc.conn.sl_flags                                       ?
?exp.gcf.gcc.conn.sl_proto_lvl                                   ?
?exp.gcf.gcc.conn.target                                         ?
?exp.gcf.gcc.conn.tl_flags                                       ?
?exp.gcf.gcc.conn.tl_lcl_id                                      ?
?exp.gcf.gcc.conn.tl_proto_lvl                                   ?
?exp.gcf.gcc.conn.tl_rmt_id                                      ?
?exp.gcf.gcc.conn.trg_addr.node                                  ?
?exp.gcf.gcc.conn.trg_addr.port                                  ?
?exp.gcf.gcc.conn.trg_addr.protocol                              ?
?exp.gcf.gcc.conn.userid                                         ?
?exp.gcf.gcc.conn_count                                          ?
?exp.gcf.gcc.data_in                                             ?
?exp.gcf.gcc.data_out                                            ?
?exp.gcf.gcc.ib_conn_count                                       ?
?exp.gcf.gcc.ib_encrypt_mech                                     ?
?exp.gcf.gcc.ib_encrypt_mode                                     ?
?exp.gcf.gcc.ib_max                                              ?
?exp.gcf.gcc.msgs_in                                             ?
?exp.gcf.gcc.msgs_out                                            ?
?exp.gcf.gcc.ob_conn_count                                       ?
?exp.gcf.gcc.ob_encrypt_mech                                     ?
?exp.gcf.gcc.ob_encrypt_mode                                     ?
?exp.gcf.gcc.ob_max                                              ?
?exp.gcf.gcc.pl_proto_lvl                                        ?
?exp.gcf.gcc.protocol                                            ?
?exp.gcf.gcc.protocol.addr                                       ?
?exp.gcf.gcc.protocol.host                                       ?
?exp.gcf.gcc.protocol.port                                       ?
?exp.gcf.gcc.registry                                            ?
?exp.gcf.gcc.registry.addr                                       ?
?exp.gcf.gcc.registry.host                                       ?
?exp.gcf.gcc.registry.port                                       ?
?exp.gcf.gcc.registry_mode                                       ?
?exp.gcf.gcc.trace_level                                         ?
??????????????????????????????????????????????????????????????????
(49 rows)

The lcl_addr and rmt_addr entries look useful so let’s create a table with the node and port sub-fields:

drop table ima_gcc_sessions;
register table ima_gcc_sessions (
        net_server                  varchar(64) not null not default
    is 'SERVER',
  local_node         varchar(20) not null not default
    is 'exp.gcf.gcc.conn.lcl_addr.node',
  local_port         varchar(20) not null not default
    is 'exp.gcf.gcc.conn.lcl_addr.port',
  remote_node         varchar(20) not null not default
    is 'exp.gcf.gcc.conn.rmt_addr.node',
  remote_port         varchar(20) not null not default
    is 'exp.gcf.gcc.conn.rmt_addr.port',
  inbound         varchar(20) not null not default
    is 'exp.gcf.gcc.conn.inbound'
) as import from 'tables'
with dbms = IMA,
structure = sortkeyed,
key = (net_server);

So to get a list of outbound server connections we can now use the following SQL:

select * from ima_gcc_sessions where inbound='N'

Giving:

* select * from ima_gcc_sessions where inbound='N'g
Executing . . .
???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
?net_server                                                      ?local_node          ?local_port          ?remote_node         ?remote_port         ?inbound             ?
???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
?esva-ubuntu::/@52970                                            ?192.168.10.20       ?50064               ?10.100.10.178       ?21064               ?N                   ?
?esva-ubuntu::/@52970                                            ?192.168.10.20       ?49331               ?192.168.10.20       ?27008               ?N                   ?
???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
(2 rows)
continue
*

Note In order to query the IMA tables for Ingres/NET related information you must execute the procedure ima_set_vnode_domain:

execute procedure ima_set_vnode_domain;

A belated happy new year / feliz año nuevo to you all

now to do some Python

• Fix #656 – getProcedureName() returns a non-NULL terminated procedure name
• Fix #653 – Update s.date dynamically for each release
• Fix #651 – Add support for building a Ruby Gem
• Fix #555 – SEGV when fetcing LOB data
• Fix #565 – Compilation errors with Redhat ES 5.4 (x86-64)

This new release can be obtained from ingres.com or via one of the following links:

• README
• Windows Binaries
• Source code

Alternatively you can checkout this release from our external source code repository:

svn checkout http://code.ingres.com/ingres/drivers/ruby/tags/ingres-ruby-1.4.1

See http://community.ingres.com/wiki/Connectivity_Drivers_Source_Code for more information on working with our external source repository.

Issues specific to the Ingres ActiveRecord adapter and Ruby driver can be posted on the Ingres forum http://community.ingres.com/forum/ruby-driver-ruby-rails-adapter/. Users with an active support contract can raise an issue through their local support centre or Service Desk. You can find more information on using the Ingres Ruby driver and ActiveRecord bindings at http://community.ingres.com/wiki/Ruby. For online technical assistance for other Ingres products or components, and a complete list of locations, primary service hours, and telephone numbers, contact technical support at http://ingres.com/support.

http://docs.ingres.com/Ingres/9.3/Database%20Administrator%20Guide/largedataloadswsetnologgingstatement.htm

has become

http://docs.ingres.com/ingres/9.3/database-administrator-guide/1757-large-data-loads-with-the-set-nologging-statement

To get the URL for the first required some navigation of the documentation index, via the tree or via the search engine. Since Google is used by many people as their home page, even to search for facebook.com it makes more sense that the documentation is more accessible from Google, Bing et. al.

One of the downsides with the new docs.ingres.com site is the use of screen real-estate. The main ingres.com properties have their content squeezed in to 980px which is ok in the 1990 world of “This website supports 1024×786″ resolutions. However in this day and age I would make the supposition that 1280×1024 would be more common, something that’s borne out by Valve Software’s monthly hardware survey. With the increasing trend towards wide-screen displays in laptops as well as desktop displays a 1440×900 resolution will become more common.

With this in mind I’ve put together a couple of hacks that when used with Google Chrome or the Firefox Greasemonkey addon – increases the amount of space used for the content to 60% of the width of the browser window. To install, click on the relevant link for your browser – note that the Greasemonkey script can be used with Google Chrome (from 4.0 onwards).

• Google Chrome – http://planetingres.org/~grant/bigdocs/bigdocs.crx
• Firefox with Greasemonkey – http://planetingres.org/~grant/bigdocs/bigdocs.ingres.com.user.js

Once installed go to any docs.ingres.com page and after the page finishes loading the content area will be super-sized. If there’s any interest I’ll look into to how the page can be rendered full size without having to expand on screen.

[grant@usrc-git T1]$ sudo rpm -ihv ingres-32bit-T1-10.1.0-00.x86_64.rpm ingres-dbms-T1-10.1.0-00.x86_64.rpm ingres-odbc-T1-10.1.0-00.x86_64.rpm
ingres-T1-10.1.0-00.x86_64.rpm ingres-net-T1-10.1.0-00.x86_64.rpm
[sudo] password for grant:
Preparing...                ###########################################[100%]
    1:ingres-T1               ###########################################[ 20%]
    2:ingres-32bit-T1        ###########################################[ 40%]
    3:ingres-dbms-T1       ###########################################[ 60%]
    4:ingres-odbc-T1        ###########################################[ 80%]
    5:ingres-net-T1          ###########################################[100%]
Building the password validation program 'ingvalidpw'.
Executable successfully installed.
[grant@usrc-git T1]$ sudo -u ingres -i
Release                     Running Script II_SYSTEM
-------------------------------------------------------------------------------
II 10.1.0 (a64.lnx/100)NPTL    N    loadII /opt/Ingres/IngresII
II 10.1.0 (a64.lnx/00)NPTL     N    loadT1 /opt/Ingres/IngresT1
[ingres@usrc-git ~]$ loadT1
[ingres@usrc-git ~]$ ingstart
Ingres/ingstart
No Ingres servers have been configured to start up.
[ingres@usrc-git ~]$ iipmhost
localhost
[ingres@usrc-git ~]$ ingprenv
II_INSTALLATION=T1
II_HOSTNAME=localhost
II_SHADOW_PWD=/opt/Ingres/IngresT1/ingres/bin/ingvalidpw
[ingres@usrc-git ~]$ cat /opt/Ingres/IngresT1/ingres/files/install.log
Installing Terminal Monitor utility files...
[ingres@usrc-git ~]$

Prior to Ingres 10.1, the RPM install scripts would perform the post-laydown configuration. As of 10.1 this is no longer the case as you can see from the output above. The 10.1 RPMs only lay down the files and do minimal configuration, which sets up the symbol table as per the output from ingprenv. Ingres now gets configured when started as a service for the first time:

[grant@usrc-git T1]$ sudo service ingresT1 start
Ingres, instance T1 has not been setup
Running setup for Ingres 10.1.0-00...
	Running setup for dbms...                                        OK
	Running setup for net...                                         OK
	Running iisusupp32...                                            OK
	Running iisudbms...                                              OK
	Running iisuc2...                                                OK
	Running iisutux...                                               OK
	Running iisuodbc...                                              OK
	Running iisubr...                                                OK
	Running iisudas...                                               OK
Starting Ingres, instance T1:                              [  OK  ]
[grant@usrc-git T1]$

Leaving us with a configured and running installation.

Ingres are broadcasting live webinars for Ingres VectorWise, starting this week. The first is entitled ‘Welcome to Ingres VectorWise”

Join our Ingres System Engineers as they share a high-level overview of the Ingres VectorWise technology including a demonstration of the product. Find out more about this new feature and to understand how to increase the performance of your analytic workloads using Ingres VectorWise with your existing hardware.

Duration will be approximately 40 mins.

Presenter: Joel Brunger
Date: Friday, July 8, 2010
Time: 10am ET / 2pm GMT / 3pm BST / 4pm CET
Register – http://info.ingres.com/g/?BGGYOVT4OJ

Presenter: Mary Schulte
Date: Friday, July 8, 2010
Time: 4pm PT / 11pm GMT / 9 am EST (July 9)
Register – http://info.ingres.com/g/?PCGJ51KY29

Presenter: Stephane Padique (Presentation will be in French/En français)
Date: Vendredi, July 23, 2010
Time: 1pm GMT / 2pm BST / 3pm CET
Register – http://info.ingres.com/g/?UX1J8X7Y71

- Update the unit tests to be more independent
- Add support for the Ingres BOOLEAN type
- Add ingres_fetch_assoc()
- Allow for a 0 offset in all ingres field functions
- Update build scripts for OpenVMS CSWS PHP 2.0
- Fix bug 17556 – Handle errors for non-result returning statements
- Fix bug 16960 – SEGV when fetching the results from a row producing procedure
- Fix bug 16990 – SEGV when executing a database procedure
- Fix bug 17510 – Fix php_ii_set_connect_options so they work as documented
- Fix bug 17302 – _close_statement is unable to free active statements
- Fix bug 17207 – Under certain conditions the driver can SEGV when doing cleaning up
- Fix bug 17198 – Unable to close non-result statements
- Fix bug 17092 – SIGBUS when fetching data on 64-bit Solaris
- IIapi_getDescriptor() should only be called for SELECT statements
- Fix bug 16752 – Send all string values as IIAPI_VCH_TYPE

You can download the source code from http://pecl.php.net/get/ingres or install directly from the command line using the command:

sudo pecl install ingres-2.2.2

Pre-built Windows binaries are available from ESD for PHP 5.1.6, 5.2.13 and 5.3.2. An OpenVMS binary for CSWS PHP 2.0 will be updated today. You can raise questions/problems via the Ingres Community Forums, the project home page or via Service Desk.

$ sql iidbdb
INGRES TERMINAL MONITOR Copyright 2010 Ingres Corporation
Ingres Linux Version II 10.0.0 (int.lnx/2863)NPTL login
Thu Apr 29 08:46:38 2010
continue
*

to:

$ sql iidbdb
INGRES TERMINAL MONITOR Copyright 2010 Ingres Corporation
Ingres Linux Version II 10.0.0 (int.lnx/2903)NPTL login
Thu Apr 29 09:16:40 2010
Enter g to execute commands, "help helpg" for help, q to quit
continue
*

No more ninja skills needed for executing a query or to escape from the terminal monitor.

grep -v "IIapi_wait|Dispatch" api.log

Turning this into:

!IIapi_initAPI: initializing API.
!IIapi_initialize: INGRES API initialized, envHndl = 090F9308
!IIapi_initialize: startup API
!IIapi_initialize: version = 6
!IIapi_initialize: INGRES API initialized, envHndl = 09078018
!IIapi_connect: connect to DBMS Server
!IIapi_connect: envHndl = 09078018, connHndl = 00000000, tranHndl= 00000000
!IIapi_connect: target = @server,tcp_ip,ii[user:secret]::dbname
!IIapi_thread(-1226205472): allocated local storage 091A5E78
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_setEnvParam: set environment parameter
!IIapi_setEnvParam: envHndl = 09078018
!IIapi_setEnvParam: paramID = 24.
!IIapi_autocommit: set autocommit state
!IIapi_autocommit: connHndl = 091A5960, tranHndl = 00000000
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_query: starting a query
!IIapi_query: connHndl = 091A5960, tranHndl = 091A69B8, queryType = 0
!IIapi_query: queryText = set session with description='hello'
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_close: closing a query
!IIapi_close: stmtHndl = 091A8070
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_query: starting a query
!IIapi_query: connHndl = 091A5960, tranHndl = 091A69B8, queryType = 0
!IIapi_query: queryText = set lockmode session where readlock=nolock
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_close: closing a query
!IIapi_close: stmtHndl = 091A6580
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_cancel: cancelling a query
!IIapi_cancel: invalid handle
!IIapi_appCallback: request completed, status = INVALID_HANDLE
!IIapi_close: closing a query
!IIapi_close: invalid statement handle
!IIapi_appCallback: request completed, status = INVALID_HANDLE
!IIapi_autocommit: set autocommit state
!IIapi_autocommit: connHndl = 091A5960, tranHndl = 091A69B8
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_disconnect: disconnecting a connection
!IIapi_disconnect: connHndl = 091A5960
!IIapi_appCallback: request completed, status = SUCCESS
!IIapi_releaseEnv: Release Environment
!IIapi_releaseEnv: envHndl = 09078018
!IIapi_terminate: shutdown API
!IIapi_releaseEnv: Release Environment
!IIapi_releaseEnv: envHndl = 090F9308
!IIapi_terminate: shutdown API
!IIapi_termAPI: shutting down API completely.
!IIapi_termAPI: API shutdown.

A lot simpler to read – Now I can see that a bad statement handle has been passed to IIapi_cancel() and IIapi_close(). Now I know what the problem is it’s time to find where the statement handle is coming from.

[1] It should be noted that you cannot always discount IIapi_wait() calls. A number of years ago I hit a weird timing issue due to a missing IIapi_wait() call.