Home > Archive > Cobol > December 2006 > Fujitsu COM recordset overload?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Fujitsu COM recordset overload?
|
|
| Robin Lee 2006-12-05, 9:55 pm |
| I have a Fujitsu COBOL subsystem that seems to blow up when accessing larger amounts
of data. It's a PowerCOBOL front end with the database accesses being done by some
COBOL97 DLL's which access a MS SQL server using some ADO program code I copied from
examples posted by Frederico Fonseca.
Everything works fine when requesting a month or two of data, but errors out when
requesting 3 or 4 months of the same data. Note that the SQL statement is the same
except the values of the dates, and it functions properly outside of COBOL.
The program code looks something like this:
CONFIGURATION SECTION.
REPOSITORY.
CLASS COM-EXCEPTION AS "*COM-EXCEPTION"
CLASS COM AS "*COM".
DATA DIVISION.
WORKING-STORAGE SECTION.
01 VARIABLES.
05 ADO-CONNECTION-TYPE PIC X(8192) VALUE "ADODB.Connection".
05 ADO-RECORDSET-TYPE PIC X(8192) VALUE "ADODB.Recordset".
05 ADO-COMMAND-TYPE PIC X(8192) VALUE "ADODB.Command".
05 OBJ-CONNECTION OBJECT REFERENCE COM.
05 OBJ-RECORDSET OBJECT REFERENCE COM.
05 OBJ-COMMAND OBJECT REFERENCE COM.
05 OBJ-FIELD OBJECT REFERENCE COM occurs 10.
05 OBJ-FIELDS OBJECT REFERENCE COM.
05 OBJ-FIELDS-COUNT PIC S9(9) COMP-5 VALUE 0.
05 RECORDCOUNT PIC S9(9) COMP-5 VALUE 0.
Admittedly I am totally new to ADO and know nothing about COM. My first inclination
is to increase the sizes of the first three variables (like maybe the recordset
identifier is trying to receive too many record pointers or something like that.
The error message says "ERROR OCCURRED IN THE 'OPEN' METHOD OF THE SPECIAL CLASS
'*COM/*OLE'. SCODE=0x80020009 EXCEPTION SCODE=0x80040e21 DESCRIPTION=ODBC driver
does not support the requested properties. PGM=AR30300 ADR=10001C99"
which is pretty much what any Fujitsu program says any time an SQL statement fails.
Since it works fine with smaller chunks of data, my brute force workaround for this
would be to repeatedly access the data one month at a time and merge the various
batches programmatically. But I thought I'd ask if anyone else has encountered this
before I start to clobber working code.
| |
| Robin Lee 2006-12-11, 6:56 pm |
| Robin Lee wrote:
>
> Everything works fine when requesting a month or two of data, but errors
> out when requesting 3 or 4 months of the same data.
Update: increasing the size of the WS variables has no effect. Also changed SQL so
more summarizing is done on the server (therefore fewer transactions being sent to
client). But the server must still examine the same amount of data, and it still
bombs out at same point, leading me to think this may be something set on the
server. So I'm changing the program to make several trips to the well with a smaller
pail.
| |
|
|
Robin Lee wrote:[color=darkred]
> Robin Lee wrote:
Is there a possiblity that you are running up against an ODBC time out.
Try checking the ODBC driver you are using as well as any other third
party products in the mix and see if you have the option to increase
the time-out value.
I applaud your work around however. Sometimes you must play the hand
you are dealt.
| |
| Robin Lee 2006-12-13, 4:05 pm |
| Marty wrote:
>
> Is there a possiblity that you are running up against an ODBC time out.
Yes, I'm almost certain it's something along those lines, and currently treating it
as such.
>
> I applaud your work around however. Sometimes you must play the hand
> you are dealt.
>
Thank you. Whether or not the problem actually lies within my realm, to the users
it "looks" as though my program doesn't work, hence the work-around.
| |
| Pete Dashwood 2006-12-13, 4:06 pm |
| Robin,
I had a private mail on this bounced from your news.com address.
Please contact me privately for some stuff that may be helpful.
Pete.
TOP POST - nothing new below...
"Robin Lee" <robinlee@news.com> wrote in message
news:rbCdnZ7drM4ogOvYnZ2dnUVZ_qWdnZ2d@gi
ganews.com...
>I have a Fujitsu COBOL subsystem that seems to blow up when accessing
>larger amounts of data. It's a PowerCOBOL front end with the database
>accesses being done by some COBOL97 DLL's which access a MS SQL server
>using some ADO program code I copied from examples posted by Frederico
>Fonseca.
>
> Everything works fine when requesting a month or two of data, but errors
> out when requesting 3 or 4 months of the same data. Note that the SQL
> statement is the same except the values of the dates, and it functions
> properly outside of COBOL.
>
> The program code looks something like this:
>
> CONFIGURATION SECTION.
> REPOSITORY.
> CLASS COM-EXCEPTION AS "*COM-EXCEPTION"
> CLASS COM AS "*COM".
> DATA DIVISION.
> WORKING-STORAGE SECTION.
> 01 VARIABLES.
> 05 ADO-CONNECTION-TYPE PIC X(8192) VALUE "ADODB.Connection".
> 05 ADO-RECORDSET-TYPE PIC X(8192) VALUE "ADODB.Recordset".
> 05 ADO-COMMAND-TYPE PIC X(8192) VALUE "ADODB.Command".
> 05 OBJ-CONNECTION OBJECT REFERENCE COM.
> 05 OBJ-RECORDSET OBJECT REFERENCE COM.
> 05 OBJ-COMMAND OBJECT REFERENCE COM.
> 05 OBJ-FIELD OBJECT REFERENCE COM occurs 10.
> 05 OBJ-FIELDS OBJECT REFERENCE COM.
> 05 OBJ-FIELDS-COUNT PIC S9(9) COMP-5 VALUE 0.
> 05 RECORDCOUNT PIC S9(9) COMP-5 VALUE 0.
>
> Admittedly I am totally new to ADO and know nothing about COM. My first
> inclination is to increase the sizes of the first three variables (like
> maybe the recordset identifier is trying to receive too many record
> pointers or something like that.
>
> The error message says "ERROR OCCURRED IN THE 'OPEN' METHOD OF THE SPECIAL
> CLASS '*COM/*OLE'. SCODE=0x80020009 EXCEPTION SCODE=0x80040e21
> DESCRIPTION=ODBC driver does not support the requested properties.
> PGM=AR30300 ADR=10001C99"
> which is pretty much what any Fujitsu program says any time an SQL
> statement fails.
>
> Since it works fine with smaller chunks of data, my brute force workaround
> for this would be to repeatedly access the data one month at a time and
> merge the various batches programmatically. But I thought I'd ask if
> anyone else has encountered this before I start to clobber working code.
>
|
|
|
|
|