[archive] AcuCobol tips & tricks

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

A little disclaimer: the following examples require a C compiler. Also, this is some serious hacking...do at your own risk! However, it is a good example of how to take advantage of subclassing to extend the runtime. Also please note this technique is used for dragging and dropping files onto a AcuCobol window, not a more general drag and drop approach. It also has some specific limitations, which may impact the usablity. This technique will be most useful for those of you (like me) who are still extending character mode applications.

The win32 API provides file drag and drop support which does not rely on COM but is more similar to clipboard management. When a user drops drags files and drops them unto a window, windows fires a WM_DROPFILES message at the application and sets up a special buffer which contains the names of the dropped files. The application can then take action based on those names. There is also a special flag for each window which indicates that it can be a target for dropped files.

The AcuCobol runtime normally ignores WM_DROPFILES events and is never a target for dropping. Armed with a C compiler, turning a window on as a drop target is easy.

C command:

__declspec(dllexport) void _cdecl EnableFileDrop(HANDLE* hWnd)
{
DragAcceptFiles(*hWnd, true);
}

to turn on and
DragAcceptFiles(*hWnd, false);
to turn off.

Cobol Command:

[working storage]
01 Window-Handle unsigned-int [or PIC 9(9) COMP-5]..thanks gforseth

[procedure division]
inquire window system handle in Window-Handle.
call "EnableFileDrop" using Window-Handle.

That's the easy part...after enabling your window for dropping files, you have to subclass the window you would like to drop files on so it will respond to the WM_DROPFILES event. This is easy if you only need to sublass one window at one time.

Here is the code I wrote to do that (note: this is a simplified version...if you need to subclass multiple windows, you need to set up a table of handlers).

Following is the message handler that we are going to install into our AcuCobol window. This takes a message passed to a window we are subclssing and gives a change to intercept the messages and deal with them specially. Note that this is not an exported method in the .dll

LRESULT CALLBACK CobolMessageHandler(
HWND hWnd, // handle to window
UINT Msg, // message identifier
WPARAM wParam, // first message parameter
LPARAM lParam // second message parameter
)
{
register int ii;

switch (Msg)
{
case WM_DROPFILES:
SetupFileDrop((HANDLE) wParam);

}

LRESULT lr = CallWindowProc(
g_WindowProc, // pointer to previous procedure
hWnd, // handle to window
Msg, // message
wParam, // first message parameter
lParam); // second message parameter


return lr;
}

void* g_WindowProc;


Here is our sublassing method that we will call from a COBOL program:
__declspec(dllexport) void _cdecl SubClass(HANDLE* hWind)
{
// register the winow procedure into the handler table.
WNDPROC proc = &CobolMessageHandler;
g_WindowProc = (WNDPROC) SetWindowLong(*hWind, GWL_WNDPROC, (LONG) proc);
}

Here is the COBOL command to call this method:

inquire window system handle in Window-Handle.
call "SubClass" using Window-Handle.

Here is the file drop routine, SetupFileDrop that responds to the fril drop message.

void SetupFileDrop(HANDLE hDropFile)
{
SetForegroundWindow(hAcuWnd);

DWORD dwRowLength = MAX_PATH 1;
char cFileRecord[MAX_PATH 1];
cFileRecord[MAX_PATH] = 0;

DWORD dwBuf = 0;

int iNumFiles = DragQueryFile(hDropFile, 0xFFFFFFFF, 0, 0);

if (iNumFiles > 0)
{
dwBuf = CreateBuffer(&dwRowLength);
for (int ii=0; ii
{
memset(cFileRecord, ' ', MAX_PATH);
DragQueryFile(hDropFile, ii, cFileRecord, MAX_PATH);
int iStrLen = strlen(cFileRecord);
cFileRecord[iStrLen] = ' ';

AddRow((void**) &dwBuf, cFileRecord);
}
}

Argument arg;

arg.a_address = (char*) &dwBuf;
arg.a_length = sizeof(dwBuf);
arg.a_type = 14;

int i = cobol("DropFiles", 1, &arg);
}

CreateBuffer and AddRow are dynamic memory routines that I have written. An alternative method of passing the reults back to the COBOL side of things is left an exercise to the user (I pass them through an array handle in the parameter list).

cobol is the AcuCorp supplied method of calling cobol routines from C. The "DropFiles" program uses W$KeyBuf to hit a ke(usually a termiantion key) which can then be interpreted by a regular COBOL program. The overall system may seem complex, but it works! One complication is that if you are dropping to specfic targets into the screen, the SetForegroundWindow command has strange interactions which may cause W$Mouse to return the wrong coordinates when droped over a graphical screen object. Also, sublcassing the main application window sometimes can supress unhandled runtime generated error messages from appearing properly in Extend6 (not in Extend5)...so you are warned.

It is a good practice to restore the original event handler before completely closing down a window...this is also left an exercise to the reader. Subclassing is an important technique to other types of runtime hacking, one of which I will soon be posting to this forum, so if you are adventourous type, have at it! Just remember it is not supported by AcuCorp, me, or anybody :)

Merlin

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

A little disclaimer: the following examples require a C compiler. Also, this is some serious hacking...do at your own risk! However, it is a good example of how to take advantage of subclassing to extend the runtime. Also please note this technique is used for dragging and dropping files onto a AcuCobol window, not a more general drag and drop approach. It also has some specific limitations, which may impact the usablity. This technique will be most useful for those of you (like me) who are still extending character mode applications.

The win32 API provides file drag and drop support which does not rely on COM but is more similar to clipboard management. When a user drops drags files and drops them unto a window, windows fires a WM_DROPFILES message at the application and sets up a special buffer which contains the names of the dropped files. The application can then take action based on those names. There is also a special flag for each window which indicates that it can be a target for dropped files.

The AcuCobol runtime normally ignores WM_DROPFILES events and is never a target for dropping. Armed with a C compiler, turning a window on as a drop target is easy.

C command:

__declspec(dllexport) void _cdecl EnableFileDrop(HANDLE* hWnd)
{
DragAcceptFiles(*hWnd, true);
}

to turn on and
DragAcceptFiles(*hWnd, false);
to turn off.

Cobol Command:

[working storage]
01 Window-Handle unsigned-int [or PIC 9(9) COMP-5]..thanks gforseth

[procedure division]
inquire window system handle in Window-Handle.
call "EnableFileDrop" using Window-Handle.

That's the easy part...after enabling your window for dropping files, you have to subclass the window you would like to drop files on so it will respond to the WM_DROPFILES event. This is easy if you only need to sublass one window at one time.

Here is the code I wrote to do that (note: this is a simplified version...if you need to subclass multiple windows, you need to set up a table of handlers).

Following is the message handler that we are going to install into our AcuCobol window. This takes a message passed to a window we are subclssing and gives a change to intercept the messages and deal with them specially. Note that this is not an exported method in the .dll

LRESULT CALLBACK CobolMessageHandler(
HWND hWnd, // handle to window
UINT Msg, // message identifier
WPARAM wParam, // first message parameter
LPARAM lParam // second message parameter
)
{
register int ii;

switch (Msg)
{
case WM_DROPFILES:
SetupFileDrop((HANDLE) wParam);

}

LRESULT lr = CallWindowProc(
g_WindowProc, // pointer to previous procedure
hWnd, // handle to window
Msg, // message
wParam, // first message parameter
lParam); // second message parameter


return lr;
}

void* g_WindowProc;


Here is our sublassing method that we will call from a COBOL program:
__declspec(dllexport) void _cdecl SubClass(HANDLE* hWind)
{
// register the winow procedure into the handler table.
WNDPROC proc = &CobolMessageHandler;
g_WindowProc = (WNDPROC) SetWindowLong(*hWind, GWL_WNDPROC, (LONG) proc);
}

Here is the COBOL command to call this method:

inquire window system handle in Window-Handle.
call "SubClass" using Window-Handle.

Here is the file drop routine, SetupFileDrop that responds to the fril drop message.

void SetupFileDrop(HANDLE hDropFile)
{
SetForegroundWindow(hAcuWnd);

DWORD dwRowLength = MAX_PATH 1;
char cFileRecord[MAX_PATH 1];
cFileRecord[MAX_PATH] = 0;

DWORD dwBuf = 0;

int iNumFiles = DragQueryFile(hDropFile, 0xFFFFFFFF, 0, 0);

if (iNumFiles > 0)
{
dwBuf = CreateBuffer(&dwRowLength);
for (int ii=0; ii
{
memset(cFileRecord, ' ', MAX_PATH);
DragQueryFile(hDropFile, ii, cFileRecord, MAX_PATH);
int iStrLen = strlen(cFileRecord);
cFileRecord[iStrLen] = ' ';

AddRow((void**) &dwBuf, cFileRecord);
}
}

Argument arg;

arg.a_address = (char*) &dwBuf;
arg.a_length = sizeof(dwBuf);
arg.a_type = 14;

int i = cobol("DropFiles", 1, &arg);
}

CreateBuffer and AddRow are dynamic memory routines that I have written. An alternative method of passing the reults back to the COBOL side of things is left an exercise to the user (I pass them through an array handle in the parameter list).

cobol is the AcuCorp supplied method of calling cobol routines from C. The "DropFiles" program uses W$KeyBuf to hit a ke(usually a termiantion key) which can then be interpreted by a regular COBOL program. The overall system may seem complex, but it works! One complication is that if you are dropping to specfic targets into the screen, the SetForegroundWindow command has strange interactions which may cause W$Mouse to return the wrong coordinates when droped over a graphical screen object. Also, sublcassing the main application window sometimes can supress unhandled runtime generated error messages from appearing properly in Extend6 (not in Extend5)...so you are warned.

It is a good practice to restore the original event handler before completely closing down a window...this is also left an exercise to the reader. Subclassing is an important technique to other types of runtime hacking, one of which I will soon be posting to this forum, so if you are adventourous type, have at it! Just remember it is not supported by AcuCorp, me, or anybody :)

Merlin

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

A little disclaimer: the following examples require a C compiler. Also, this is some serious hacking...do at your own risk! However, it is a good example of how to take advantage of subclassing to extend the runtime. Also please note this technique is used for dragging and dropping files onto a AcuCobol window, not a more general drag and drop approach. It also has some specific limitations, which may impact the usablity. This technique will be most useful for those of you (like me) who are still extending character mode applications.

The win32 API provides file drag and drop support which does not rely on COM but is more similar to clipboard management. When a user drops drags files and drops them unto a window, windows fires a WM_DROPFILES message at the application and sets up a special buffer which contains the names of the dropped files. The application can then take action based on those names. There is also a special flag for each window which indicates that it can be a target for dropped files.

The AcuCobol runtime normally ignores WM_DROPFILES events and is never a target for dropping. Armed with a C compiler, turning a window on as a drop target is easy.

C command:

__declspec(dllexport) void _cdecl EnableFileDrop(HANDLE* hWnd)
{
DragAcceptFiles(*hWnd, true);
}

to turn on and
DragAcceptFiles(*hWnd, false);
to turn off.

Cobol Command:

[working storage]
01 Window-Handle unsigned-int [or PIC 9(9) COMP-5]..thanks gforseth

[procedure division]
inquire window system handle in Window-Handle.
call "EnableFileDrop" using Window-Handle.

That's the easy part...after enabling your window for dropping files, you have to subclass the window you would like to drop files on so it will respond to the WM_DROPFILES event. This is easy if you only need to sublass one window at one time.

Here is the code I wrote to do that (note: this is a simplified version...if you need to subclass multiple windows, you need to set up a table of handlers).

Following is the message handler that we are going to install into our AcuCobol window. This takes a message passed to a window we are subclssing and gives a change to intercept the messages and deal with them specially. Note that this is not an exported method in the .dll

LRESULT CALLBACK CobolMessageHandler(
HWND hWnd, // handle to window
UINT Msg, // message identifier
WPARAM wParam, // first message parameter
LPARAM lParam // second message parameter
)
{
register int ii;

switch (Msg)
{
case WM_DROPFILES:
SetupFileDrop((HANDLE) wParam);

}

LRESULT lr = CallWindowProc(
g_WindowProc, // pointer to previous procedure
hWnd, // handle to window
Msg, // message
wParam, // first message parameter
lParam); // second message parameter


return lr;
}

void* g_WindowProc;


Here is our sublassing method that we will call from a COBOL program:
__declspec(dllexport) void _cdecl SubClass(HANDLE* hWind)
{
// register the winow procedure into the handler table.
WNDPROC proc = &CobolMessageHandler;
g_WindowProc = (WNDPROC) SetWindowLong(*hWind, GWL_WNDPROC, (LONG) proc);
}

Here is the COBOL command to call this method:

inquire window system handle in Window-Handle.
call "SubClass" using Window-Handle.

Here is the file drop routine, SetupFileDrop that responds to the fril drop message.

void SetupFileDrop(HANDLE hDropFile)
{
SetForegroundWindow(hAcuWnd);

DWORD dwRowLength = MAX_PATH 1;
char cFileRecord[MAX_PATH 1];
cFileRecord[MAX_PATH] = 0;

DWORD dwBuf = 0;

int iNumFiles = DragQueryFile(hDropFile, 0xFFFFFFFF, 0, 0);

if (iNumFiles > 0)
{
dwBuf = CreateBuffer(&dwRowLength);
for (int ii=0; ii
{
memset(cFileRecord, ' ', MAX_PATH);
DragQueryFile(hDropFile, ii, cFileRecord, MAX_PATH);
int iStrLen = strlen(cFileRecord);
cFileRecord[iStrLen] = ' ';

AddRow((void**) &dwBuf, cFileRecord);
}
}

Argument arg;

arg.a_address = (char*) &dwBuf;
arg.a_length = sizeof(dwBuf);
arg.a_type = 14;

int i = cobol("DropFiles", 1, &arg);
}

CreateBuffer and AddRow are dynamic memory routines that I have written. An alternative method of passing the reults back to the COBOL side of things is left an exercise to the user (I pass them through an array handle in the parameter list).

cobol is the AcuCorp supplied method of calling cobol routines from C. The "DropFiles" program uses W$KeyBuf to hit a ke(usually a termiantion key) which can then be interpreted by a regular COBOL program. The overall system may seem complex, but it works! One complication is that if you are dropping to specfic targets into the screen, the SetForegroundWindow command has strange interactions which may cause W$Mouse to return the wrong coordinates when droped over a graphical screen object. Also, sublcassing the main application window sometimes can supress unhandled runtime generated error messages from appearing properly in Extend6 (not in Extend5)...so you are warned.

It is a good practice to restore the original event handler before completely closing down a window...this is also left an exercise to the reader. Subclassing is an important technique to other types of runtime hacking, one of which I will soon be posting to this forum, so if you are adventourous type, have at it! Just remember it is not supported by AcuCorp, me, or anybody :)

Merlin

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

Originally posted by DanM
I hope Gisle, or another engineer, does a presentation on .NET and Acucorp support of it at the San Diego conference.

Complete .net integration with AcuCobol would be too amazing for words. However AcuCobol remains a (mostly) cross-platform system. It's really two systems: the legacy cross platform compiler with a AcuBench project manager thrown in, and the Windows centric VisualBasicy RAD platform that is centered around AcuBench. The latter is a proprietary model that will not fit well into .net's sphere of operation. I think a more incremental approach such as being able to interop with .net assemblies similar to the way COM works would be more realistic. This could theoretically include of a .net based data system similar to Acu4GL but based on ado.net technology.

I think it will actually be easier to port COBOL legacy applications to the .net platform than AcuBench heavy applications, since .net is a RAD environment with a totally different organization and design.

Merlin

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

I don't see complete integration happening, ie. fujitsu .net cobol. What I want is the ability to have seamless and dynamic use of all .net components and all types and classes in the .net framework from the Acucobol compiler and runtime. No more DEF files. This may mean the runtime and thin-client having to natively use .net gui controls and .net event handling.
There is really no need for Acucobol to become another .NET language, it just needs to use the .net framework and CLR as seamlessly as possible. Managed C should make this possible, the rest is grunt work. I know, easy to say, harder to do! :D

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

Wow, we really ran into some activity here.
My compliments for the subclassing to activate drag and drop. Quite nice indeed.
There is also a less risky way to do this, although a bit cheating as well. I know of a case in which they use the Microsoft RichTextBox control as a target for drag and drop, by doing that they were also able to sustain the link to the source, e.g. if you had marked and copied a region in excel, you could drag and drop it onto the RichTextBox component inside the ACUCOBOL-GT application. Quite impressive when the numbers behind in the Excel application changed, so would the chart in the component in the Acu APP.

Another one I have seen, they use the subclassing method to be able to provide their logo as a background to the master window. That is, they capture all paint messages making sure that their logo appears solid.

At any rate, I do very much second MerlinM's position on COM. It is such a well of opportunities, just a couple of hours work away. Considering the fact (like it or not) that most businesses on Windows today, also have a copy of Microsoft Office, it is very tempting to make use of the vast opportunities there is to enhance ones own application in the direction of CRM by using COM as the glue to pull the synergy from Office and your own application.

If you add to this the flexibility provided with Thin Client and Distributed COM (DCOM), then you are really on the information highway, or what says about a scenario like this:

ACUCOBOL-GT application running on a Linux box. Interface is the Thin Client on a Win98, this then activates a mail merge with MS Word on a third computer Win2000 using DCOM. Now isn't that n-tier... No need to suppress the fact that I was extremely proud to demo this at one occasion. No terminal server, no citrix, no mapping, no this no that, but TC.

Now, the big catch here is of course the lack of sample programs and instruction from the angle of ACUCOBOL-GT. There is still a way to go, but I am pleased to say that the number of examples on how to interface ActiveX and COM components from ACUCOBOL-GT grows and grows for every day.

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

Wow, we really ran into some activity here.
My compliments for the subclassing to activate drag and drop. Quite nice indeed.
There is also a less risky way to do this, although a bit cheating as well. I know of a case in which they use the Microsoft RichTextBox control as a target for drag and drop, by doing that they were also able to sustain the link to the source, e.g. if you had marked and copied a region in excel, you could drag and drop it onto the RichTextBox component inside the ACUCOBOL-GT application. Quite impressive when the numbers behind in the Excel application changed, so would the chart in the component in the Acu APP.

Another one I have seen, they use the subclassing method to be able to provide their logo as a background to the master window. That is, they capture all paint messages making sure that their logo appears solid.

At any rate, I do very much second MerlinM's position on COM. It is such a well of opportunities, just a couple of hours work away. Considering the fact (like it or not) that most businesses on Windows today, also have a copy of Microsoft Office, it is very tempting to make use of the vast opportunities there is to enhance ones own application in the direction of CRM by using COM as the glue to pull the synergy from Office and your own application.

If you add to this the flexibility provided with Thin Client and Distributed COM (DCOM), then you are really on the information highway, or what says about a scenario like this:

ACUCOBOL-GT application running on a Linux box. Interface is the Thin Client on a Win98, this then activates a mail merge with MS Word on a third computer Win2000 using DCOM. Now isn't that n-tier... No need to suppress the fact that I was extremely proud to demo this at one occasion. No terminal server, no citrix, no mapping, no this no that, but TC.

Now, the big catch here is of course the lack of sample programs and instruction from the angle of ACUCOBOL-GT. There is still a way to go, but I am pleased to say that the number of examples on how to interface ActiveX and COM components from ACUCOBOL-GT grows and grows for every day.

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

Wow, we really ran into some activity here.
My compliments for the subclassing to activate drag and drop. Quite nice indeed.
There is also a less risky way to do this, although a bit cheating as well. I know of a case in which they use the Microsoft RichTextBox control as a target for drag and drop, by doing that they were also able to sustain the link to the source, e.g. if you had marked and copied a region in excel, you could drag and drop it onto the RichTextBox component inside the ACUCOBOL-GT application. Quite impressive when the numbers behind in the Excel application changed, so would the chart in the component in the Acu APP.

Another one I have seen, they use the subclassing method to be able to provide their logo as a background to the master window. That is, they capture all paint messages making sure that their logo appears solid.

At any rate, I do very much second MerlinM's position on COM. It is such a well of opportunities, just a couple of hours work away. Considering the fact (like it or not) that most businesses on Windows today, also have a copy of Microsoft Office, it is very tempting to make use of the vast opportunities there is to enhance ones own application in the direction of CRM by using COM as the glue to pull the synergy from Office and your own application.

If you add to this the flexibility provided with Thin Client and Distributed COM (DCOM), then you are really on the information highway, or what says about a scenario like this:

ACUCOBOL-GT application running on a Linux box. Interface is the Thin Client on a Win98, this then activates a mail merge with MS Word on a third computer Win2000 using DCOM. Now isn't that n-tier... No need to suppress the fact that I was extremely proud to demo this at one occasion. No terminal server, no citrix, no mapping, no this no that, but TC.

Now, the big catch here is of course the lack of sample programs and instruction from the angle of ACUCOBOL-GT. There is still a way to go, but I am pleased to say that the number of examples on how to interface ActiveX and COM components from ACUCOBOL-GT grows and grows for every day.

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

I understand you guys are excited about .net. And yes, we are working on it. And as you are expecting, our first aim is to be a "user" of it.

The strategy we have is to provide the least possible effort for you. Which means, if you know how to do COM programming in ACUCOBOL-GT, well, there you go with .net too. With minor additions, adjustments, the syntax is going to be pretty much the same as with ActiveX, COM.
So, the message is clear, an investment in ActiveX/COM syntax is an investment in .net.

And no, the .def file is not going away, as Danm point out, we *could* do it, but with a significant penalty to compilation time.

Of course, the program for the upcoming developers conference in San Diego has not been set yet, but let us put it this way: I would be surprised if .net isn't mentioned there.

Speaking of .net, one small digression. It was mentioned that eventually .net would rule at the expense of COM, which is probably true, but in that context a slightly amusing fact:

The first roll out of .net libraries from Microsoft has for the most been just a wrapper of existing COM components. In the long run they will probably be substituted from bottom up, but as for the time beeing...

Also note, that one may in fact access the AcuGT Automation server from .net, albeit not a native .net interface, .net allows to connect to COM objects, and as such it provides a bridge.

Gisle

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

Originally posted by gforseth
The first roll out of .net libraries from Microsoft has for the most been just a wrapper of existing COM components. In the long run they will probably be substituted from bottom up, but as for the time being...

The first native .net library will probably come out with longhorn in '05 or '06. Even then it run legacy COM support. What will be really interesting is the longhorn file system which supposedly is a relational system.

Merlin

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

What will be really interesting is the longhorn file system which supposedly is a relational system.

WinFS in longhorn is apparently based on SQL server technology. I'm really curious to see what additional functionality this offers and how performance is affected. I wonder, for instance, how Vision files will perform in this file system. Better, worse, same? I also wonder if file i/o within LAN's will improve. Windows read/write file sharing, as it exists today, is brittle at best.

Longhorn will change things for sure. For the worse or better, I suppose, will be based on the rest of the industry catching up.

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

What will be really interesting is the longhorn file system which supposedly is a relational system.

WinFS in longhorn is apparently based on SQL server technology. I'm really curious to see what additional functionality this offers and how performance is affected. I wonder, for instance, how Vision files will perform in this file system. Better, worse, same? I also wonder if file i/o within LAN's will improve. Windows read/write file sharing, as it exists today, is brittle at best.

Longhorn will change things for sure. For the worse or better, I suppose, will be based on the rest of the industry catching up.

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

What will be really interesting is the longhorn file system which supposedly is a relational system.

WinFS in longhorn is apparently based on SQL server technology. I'm really curious to see what additional functionality this offers and how performance is affected. I wonder, for instance, how Vision files will perform in this file system. Better, worse, same? I also wonder if file i/o within LAN's will improve. Windows read/write file sharing, as it exists today, is brittle at best.

Longhorn will change things for sure. For the worse or better, I suppose, will be based on the rest of the industry catching up.

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

And no, the .def file is not going away, as Danm point out, we *could* do it, but with a significant penalty to compilation time.

Oh well, guess I can't have everything.
:D
I'm curious, for the runtime to interact properly with a .net type, will the runtime need to be a .net managed assembly? Will there be a seperate .net runtime or will there still be one windows runtime that interacts with a mix of COM and .NET components?

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

Originally posted by Micr4517
I am sure interested to have some info.

This is a pet project of mine that I'm pretty proud of. As of yet it's an unfinished work, but it is functional and all the difficult parts have been completed. The last remaining major part is to write a dispatch table so I have a real file system instead of slipping in the back door with the C$REDIRECT interface. What I can tell you is that I have successfully hosted a legacy application with tons of old code. My project is similar in scope and function to the Acu4GL line of products (which I would highly recommend to any user interested in integrating SQL into a legacy COBOL application). My work currently supports only PostgreSQL, but it is written to be portable and could work over most high end SQL servers.

The basic mechanism is that file I/O operations are mapped through the C$REDIRECT interface to a special handler (written in C) that converts the file operation to a SQL statement. This SQL statement is a prepared statement on the server which was generated when the file was 'opened' on the cobol side. In other words, when you open a file, some special code runs that creates a number of prepared statements on the SQL server that allow it to behave like a traditional COBOL file system, responding to START, READ, etc. statements. This is made possible by the XFD files that the AcuGT compiler generates when it compiles COBOL programs.

For example, if you have a file
FD My-File.

01 My-File-Record.
05 P-Key
10 F1 pic x(4).
10 F2 pic x(4).
10 F3 pic x(4).

and inside a COBOL program you issue

start My-File key not

followed by

read My-File next record

The C$REDIRECT routine passes this to a driver that issues:

select * from My-File where (F1 >= [F1]) and (F1 >= [F1] or F2 > [F2]) and (F1 > [F1] or F2 > [F2] or F3 >= [F3]) order by F1, F2, F3 limit 1

and converts the result of the select statement back to a COBOL record.

The fields in brackets are the data which was inside the record when the start was issued. There were a lot of subtle quirks in how that SQL statement was generated which took some time to puzzle out.

These statements can replace or augment normal file operations. For example, you could have a COBOL write statement write to both a SQL server and a Vision File. Or, you could import data from a SQL server just by reading data from the server as if it was a COBOL file. Views on the server can also be accessed, and are treated like relative files (views have generally have no key information). The performance is quite good, similar to Vision over a driver share (but slower than AcuServer). The biggest change is record locking...records are never locked except when inside a transaction and then they are always locked, even by looking at them. Multiple locks per file are always able to be acquired.

Merlin

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

Originally posted by DanM

I'm curious, for the runtime to interact properly with a .net type, will the runtime need to be a .net managed assembly?

No.

Originally posted by DanM

Will there be a seperate .net runtime or will there still be one windows runtime that interacts with a mix of COM and .NET components?

There will be one.

Gisle

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

Originally posted by DanM

I'm curious, for the runtime to interact properly with a .net type, will the runtime need to be a .net managed assembly?

No.

Originally posted by DanM

Will there be a seperate .net runtime or will there still be one windows runtime that interacts with a mix of COM and .NET components?

There will be one.

Gisle

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

Originally posted by DanM

I'm curious, for the runtime to interact properly with a .net type, will the runtime need to be a .net managed assembly?

No.

Originally posted by DanM

Will there be a seperate .net runtime or will there still be one windows runtime that interacts with a mix of COM and .NET components?

There will be one.

Gisle

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

MerlinM, that sounds pretty interesting.

I wish I would have had C$REDIRECT and XFD's (or Acu4GL) about 10 or 12 years ago.

Back then (it may even be more than 12 years ago), we were using Austec ACE Cobol on Unix and wanted to store our data in a SQL database. I wrote an embedded SQL for ACE Cobol to read and write data from an Informix database and we ripped out practically all Cobol indexed file I/O and replaced it with CALLs to the embedded SQL engine.

A few years later we moved to Acucobol (version 1.4 if I recall) and I ported my embedded SQL interface over to it. Later I added a native Oracle interface in addition to Informix, so our programs could use either Informix or Oracle - you just chose the appropriate Acucobol runtime (which had the embedded SQL code compiled in).

Then around '95, I rewrote the interface to use ODBC so now it can work with just about any ODBC compliant database under Windows or Unix, using unixODBC.

My wish is that Acucorp would allow the sub85 interface (which my embedded SQL uses) to be in a DLL like you can have now with the sub.c interface. My embedded SQL needs to be able to allow a variable number of arguments in a CALL and be able to determine the size of each item and I can't find that out with the sub.c interface. I would love to not have to rebuild runtimes under Windows.

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

Originally posted by JoeD
My embedded SQL needs to be able to allow a variable number of arguments in a CALL and be able to determine the size of each item and I can't find that out with the sub.c interface. I would love to not have to rebuild runtimes under Windows.

I assume then your program has sytax like

call "ESQL" using a, b, c

passing variable length arguments to a C program where ESQL is a procedure in a DLL.

Have you conisidered writing a COBOL 'interface' program to front end your C routine which counts your run time parameters, length before calling the appropriate C routine? I have used this technique in some places to create simulated 'overloaded' C functions in other places.

Merlin

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

This is a pet project of mine that I'm pretty proud of. As of yet it's an unfinished work, but it is functional and all the difficult parts have been completed. The last remaining major part is to write a dispatch table so I have a real file system instead of slipping in the back door with the C$REDIRECT interface. What I can tell you is that I have successfully hosted a legacy application with tons of old code. My project is similar in scope and function to the Acu4GL line of products (which I would highly recommend to any user interested in integrating SQL into a legacy COBOL application). My work currently supports only PostgreSQL, but it is written to be portable and could work over most high end SQL servers.

The basic mechanism is that file I/O operations are mapped through the C$REDIRECT interface to a special handler (written in C) that converts the file operation to a SQL statement. This SQL statement is a prepared statement on the server which was generated when the file was 'opened' on the cobol side. In other words, when you open a file, some special code runs that creates a number of prepared statements on the SQL server that allow it to behave like a traditional COBOL file system, responding to START, READ, etc. statements. This is made possible by the XFD files that the AcuGT compiler generates when it compiles COBOL programs.

For example, if you have a file
FD My-File.

01 My-File-Record.
05 P-Key
10 F1 pic x(4).
10 F2 pic x(4).
10 F3 pic x(4).

and inside a COBOL program you issue

start My-File key not

followed by

read My-File next record

The C$REDIRECT routine passes this to a driver that issues:

select * from My-File where (F1 >= [F1]) and (F1 >= [F1] or F2 > [F2]) and (F1 > [F1] or F2 > [F2] or F3 >= [F3]) order by F1, F2, F3 limit 1

and converts the result of the select statement back to a COBOL record.

The fields in brackets are the data which was inside the record when the start was issued. There were a lot of subtle quirks in how that SQL statement was generated which took some time to puzzle out.

These statements can replace or augment normal file operations. For example, you could have a COBOL write statement write to both a SQL server and a Vision File. Or, you could import data from a SQL server just by reading data from the server as if it was a COBOL file. Views on the server can also be accessed, and are treated like relative files (views have generally have no key information). The performance is quite good, similar to Vision over a driver share (but slower than AcuServer). The biggest change is record locking...records are never locked except when inside a transaction and then they are always locked, even by looking at them. Multiple locks per file are always able to be acquired.

Merlin

Hi,

DO you have an example of this code that you could send me, I have been trying to use the C$REDIRECT routine, but it seems to be a bit flakey and very slow, I am tryin gto setup a logging file for all INDEXED file IO's and perhaps later on implementing this into an SQL Database via remapping the XFD's

Regards

Scott

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

This is a pet project of mine that I'm pretty proud of. As of yet it's an unfinished work, but it is functional and all the difficult parts have been completed. The last remaining major part is to write a dispatch table so I have a real file system instead of slipping in the back door with the C$REDIRECT interface. What I can tell you is that I have successfully hosted a legacy application with tons of old code. My project is similar in scope and function to the Acu4GL line of products (which I would highly recommend to any user interested in integrating SQL into a legacy COBOL application). My work currently supports only PostgreSQL, but it is written to be portable and could work over most high end SQL servers.

The basic mechanism is that file I/O operations are mapped through the C$REDIRECT interface to a special handler (written in C) that converts the file operation to a SQL statement. This SQL statement is a prepared statement on the server which was generated when the file was 'opened' on the cobol side. In other words, when you open a file, some special code runs that creates a number of prepared statements on the SQL server that allow it to behave like a traditional COBOL file system, responding to START, READ, etc. statements. This is made possible by the XFD files that the AcuGT compiler generates when it compiles COBOL programs.

For example, if you have a file
FD My-File.

01 My-File-Record.
05 P-Key
10 F1 pic x(4).
10 F2 pic x(4).
10 F3 pic x(4).

and inside a COBOL program you issue

start My-File key not

followed by

read My-File next record

The C$REDIRECT routine passes this to a driver that issues:

select * from My-File where (F1 >= [F1]) and (F1 >= [F1] or F2 > [F2]) and (F1 > [F1] or F2 > [F2] or F3 >= [F3]) order by F1, F2, F3 limit 1

and converts the result of the select statement back to a COBOL record.

The fields in brackets are the data which was inside the record when the start was issued. There were a lot of subtle quirks in how that SQL statement was generated which took some time to puzzle out.

These statements can replace or augment normal file operations. For example, you could have a COBOL write statement write to both a SQL server and a Vision File. Or, you could import data from a SQL server just by reading data from the server as if it was a COBOL file. Views on the server can also be accessed, and are treated like relative files (views have generally have no key information). The performance is quite good, similar to Vision over a driver share (but slower than AcuServer). The biggest change is record locking...records are never locked except when inside a transaction and then they are always locked, even by looking at them. Multiple locks per file are always able to be acquired.

Merlin

Hi,

DO you have an example of this code that you could send me, I have been trying to use the C$REDIRECT routine, but it seems to be a bit flakey and very slow, I am tryin gto setup a logging file for all INDEXED file IO's and perhaps later on implementing this into an SQL Database via remapping the XFD's

Regards

Scott

[Migrated content. Thread originally posted on 29 October 2003]

Here is a little collection of the things I've figured out, if you are curious about them, buzz me here in the forum and I'll explain how I did it:

general
a generalized background threaded search
highlight background color for current cell in a screen section
using C$Redirect, create logger which logs file I/O to a special file (Vision)
using I$IO, a DTS program which converts from your vision file to another source like (sql database)
random number generator
advanced date parsing, manipulation functions
match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

subclassing
implement file drag/drop to AcuCobol floating windows
floating forms that hover over your AcuCobol form (and move with the main form)

VC
smart dynamic memory allocation (array manager, qsort, no more sort files!)
convert vision file system I/O statements to SQL statements
File I/O driver for PostgreSQL
C program that parses XFD files
C program that generates FD, SL from SQL table

Delphi/C Builder
call Delphi graphical progress bar for progress.
call Delphi form from a AcuCobol application (as a floating window)
use Delphi Report Generator (Ace Reporter) from a Cobol program
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

This is a pet project of mine that I'm pretty proud of. As of yet it's an unfinished work, but it is functional and all the difficult parts have been completed. The last remaining major part is to write a dispatch table so I have a real file system instead of slipping in the back door with the C$REDIRECT interface. What I can tell you is that I have successfully hosted a legacy application with tons of old code. My project is similar in scope and function to the Acu4GL line of products (which I would highly recommend to any user interested in integrating SQL into a legacy COBOL application). My work currently supports only PostgreSQL, but it is written to be portable and could work over most high end SQL servers.

The basic mechanism is that file I/O operations are mapped through the C$REDIRECT interface to a special handler (written in C) that converts the file operation to a SQL statement. This SQL statement is a prepared statement on the server which was generated when the file was 'opened' on the cobol side. In other words, when you open a file, some special code runs that creates a number of prepared statements on the SQL server that allow it to behave like a traditional COBOL file system, responding to START, READ, etc. statements. This is made possible by the XFD files that the AcuGT compiler generates when it compiles COBOL programs.

For example, if you have a file
FD My-File.

01 My-File-Record.
05 P-Key
10 F1 pic x(4).
10 F2 pic x(4).
10 F3 pic x(4).

and inside a COBOL program you issue

start My-File key not

followed by

read My-File next record

The C$REDIRECT routine passes this to a driver that issues:

select * from My-File where (F1 >= [F1]) and (F1 >= [F1] or F2 > [F2]) and (F1 > [F1] or F2 > [F2] or F3 >= [F3]) order by F1, F2, F3 limit 1

and converts the result of the select statement back to a COBOL record.

The fields in brackets are the data which was inside the record when the start was issued. There were a lot of subtle quirks in how that SQL statement was generated which took some time to puzzle out.

These statements can replace or augment normal file operations. For example, you could have a COBOL write statement write to both a SQL server and a Vision File. Or, you could import data from a SQL server just by reading data from the server as if it was a COBOL file. Views on the server can also be accessed, and are treated like relative files (views have generally have no key information). The performance is quite good, similar to Vision over a driver share (but slower than AcuServer). The biggest change is record locking...records are never locked except when inside a transaction and then they are always locked, even by looking at them. Multiple locks per file are always able to be acquired.

Merlin

Hi,

DO you have an example of this code that you could send me, I have been trying to use the C$REDIRECT routine, but it seems to be a bit flakey and very slow, I am tryin gto setup a logging file for all INDEXED file IO's and perhaps later on implementing this into an SQL Database via remapping the XFD's

Regards

Scott