AcuCobol tips & tricks

[MerlinM]

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 <-- useful for key generation
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 <--PostgreSQL emulates vision file system (about the same speed as vision over a drive share).
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 <--prints bar codes!
use Delphi to manage the clipboard
bind Vision files to Delphi data aware components (including grids)

[SRFish]

a generalized background threaded search

random number generator <-- useful for key generation

advanced date parsing, manipulation functions

match the color of the Acucorp Treeview item to the backgroud color of the Treeview (looks much better!)

floating forms that hover over your AcuCobol form (and move with the main form)

Thanks

[MerlinM]

Do you have a C compiler? If so, which one(s)? Some of these examples require a C compiler (especially subclassing) and others will be easier.

I'll start up with a little discussion about calling dlls from the AcuCobol runtime then post the examples every couple of days when I can scrounge the time.

Also, I should have mentioned it, but my assumption is that you are working on MS Windows platform. I'm not sure if these approaches will work on other platforms or not (can you call .so objects on a *nix platform as you can for .dlls in windows?).

It's AcuCorp's Visual BasicIsh method of calling dll methods that makes extending the runtime so easy. Otherwise, you have to be able to recompile the runtime, which also requires a C compiler. This works great, and is slightly faster than dll calling methods, but I perfer not to do it because:

1. It's not as modular
2. Requires VC++ compiler (on windows)
3. Forces you to use the release version of the vendor suplied libraries. In other words, if you are relying on a bug fix or other custom behavior that AcuCorp may have provided in the form of a special version of the library, you will not be able to recompile without losing the vendor supplied changes.
4. Working with dlls is just plain easier.

The main issue with calling dll methods is that passing improper parameters can cause an access violation which will crash the runtime. There are a couple of general techniques to avoid this which is very important if you work on a large project with several developers.

Paramater Safety Trick #1 use copybook.
Trading coding elegance for safety, this approach will usually pass parameters in a structure to a C routine. Remember to becmoe familar with how your C compiler aligns variables and to deal with your non terminated stings.

Your copy book will look something like:
01 Function-Params.
05 Param-1 unsigned-int
05 Param-2 pic x(32).

Your function call will look something like:

move val-1 to Param-1.
move string-2 to Param-2.
inspect Param-2 replacing spaces by low-values <-- can be done on the C side
call "MyFunc" using Function-Params.

Paramater Safety Trick #2 use front end program.
Trading speed for safety, this involves writing a Cobol front end program which will in turn call your C program. Using the system methods C$NARG and C$Paramsize, you can check the parameters before calling the real routine. This is my perferred approach. Another nifty trick is you can use this method to 'overload' your functions by varying the paramcount to call different routines. You can also terminate your nulls here (by convention) if desired.

Now you can
call "MyFunc" using val-1, string-2.

This is just a little backgrounder to help you with some of the examples that are about to follow. In some cases, you can apply a pure COBOL approach by using the Win32 API (which is exposed via the system dlls) to make system calls.

[MerlinM]

As you may have noticed, setting the background color of a treeview in the runtime does not set the background color of the treeview items. Depending on your color set up, this may not get you the color you want.

Here is the Win32 API command to set a treeview's background color:

SendMessage(hHandle, TVM_SETBKCOLOR, 0, dwColor);

If you fire this at your treeview you will indeed find it sets everything to a matching background color.

dwColor is the 32 bit color value to set. Use the RGB() macro to set it up from the red, green, and blue values or hard code it.

In COBOL, each time you display your screen section (or your treeview), use the following code (this is just one way to do it):

inquire My-Treeview system handle in TV-Handle.
call "SetBackColor" using TV-Handle, TV-Color.

call "SetBackColor" using TV-Handle, TV-Color.

TV-Handle is usage unsigned-int.
TV-Color is also unsigned-int...either hard code the value or calcualte it from the Red, Green, and Blue Values.

"SetBackColor" is a dll method I created (with my C compiler) which has exactly one line:

__declspec(dllexport) void _cdecl SetBackColor(HANDLE* pHandle, DWORD* pColor)
{
SendMessage(*pHandle, TVM_SETBKCOLOR, 0, *pColor);
}

I have to dereference the pointers because the default calling convention is by reference. I perfer to do it this way to avoid forcing the other programs to use 'by value' syntax in the call.


This particular function is possible to do without using a C compiler. You can make the SendMessage call directly to the Win32 API from COBOL. This has been documented elsewhere in the forum, so check it out there :)

Everytime you redisplay your treeview (or screen section), you have to re-call this method.

Hope this helps (more to follow),
Merlin

[SRFish]

Yes I am working on MS Windows platform and yes I can get a C++ compiler if need be, though I am not profitient in C++.

When you say it forces me to use the release version of the vendor suplied libraries, I am not sure what you mean. Are you suggesting that we rebuild AcuCobol dll's?

[MerlinM]

Originally posted by SRFish
When you say it forces me to use the release version of the vendor suplied libraries, I am not sure what you mean. Are you suggesting that we rebuild AcuCobol dll's?

At my company we had a situation where our application relied on some non standard behavior in one of the older versions of the AcuCobol runtime. AcuCorp graciously compiled a version of the runtime which was based on the current version but also had our custom behavior. However, they did not give us the library files necessary to rebuild the runtime ourselves. Becuase of that, at our company we tend not to rebuild the runtime so we are not dependant on the released versions of the .lib files.

Merlin

[SRFish]

Originally posted by MerlinM
At my company we had a situation where our application relied on some non standard behavior in one of the older versions of the AcuCobol runtime. AcuCorp graciously compiled a version of the runtime which was based on the current version but also had our custom behavior. However, they did not give us the library files necessary to rebuild the runtime ourselves. Becuase of that, at our company we tend not to rebuild the runtime so we are not dependant on the released versions of the .lib files.

Merlin

Thanks for the clarification. We don't rebuild the runtime either. That limits us to a perticular version which we do not want to do. We would rather use seperate dll's and use the call function or make use of ActiveX controls.

[Micr4517]

I could used some good info about the drag and drop


Thank you!

[Micr4517]

I am sure interested to have some info.

[gforseth]

Thanks so much to MerlinM for his contributions to the forum, I do however have some comments.

There is no such thing as "Visual BasicIsh" method of calling DLLs.

There are two ways one may link to libraries in Windows, those are static link and dynamic link. The latter which is using those libraries with the extension DLL (Dynamic Linked Library). This technology is not founded in VB, it is not even founded in Windows, but were first introduced in Windows in version 2.0 providing as a means to reduce the load on memory.
A DLL is in fact from the OS perspective considered a normal executable, with the one major exception that it cannot "live on its own". It's only way of loading is through an application.

It is true that using DLLs does not require a VC++ compiler. Even so, if you were doing a static link with a .obj or .lib file it does not have to be Visual C++. It may as well be Borland Delphi, Borland C++ Builder, Visual Basic. All of these also support static linking, as ACUCOBOL-GT does it. ACUCOBOL-GT for Windows is built with Visual C++, but that doesn't mean it is the only language supporting static link.

If you want to learn more about DLLs, sign up for the training on January 19th.

One may as well keep in mind that the entire Windows API and thus also its functions are not object oriented, so we are speaking C, not C++.

All languages that do a dynamic load, be it Visual C++, Visual Basic, ACUCOBOL-GT, Borland Delphi uses an API function named LoadLibrary to load the DLL. This provides the smooth gate to use functions and features on demand.

With the services of the Windows API and COM, there is very little, that you cannot do from ACUCOBOL-GT, in most cases, no need for a C compiler.

A couple of things I would like to mention regarding your examples:

! Do remember that most of the Windows API utilizes the pascal
calling convention, e.g. you must:
SET ENVIRONMENT "DLL-CONVENTION" TO 1.
This because the runtime is default to the cdecl parameter passing convention.

! Do remember that the datatypes signed-int, unsigned-int are COBOL datatypes, e.g. they are not native to the platform. Thus, you cannot use them directly on the Windows API. If you choose to go by these datatypes, you will need to compile your applications using the compilerswitches: -Dw32 -Dl4. So the compiler provides the correct size and alignment. I myself prefer to use PIC 9(9) COMP-5 for this, avoiding the need for compiler switches.

! Also note that all Windows API functions are not necessarily using a 32 bit integer, some use 16bit integer, some even a byte.

If you want to learn more about Windows data types and their counterparts in ACUCOBOL-GT or how to interface API functions, check out the training in San Diego on january 19th.

Regarding your Treeview background color example. For those interested in this, the RGB macro he refers to, is a C construct. If you look in the sample directory of your ACUCOBOL-GT installation, you will find the program GraphPrn.cbl, in which there is a CALC-COLORREF section. This will show you how to construct a color with this kind of data. And, btw, COLORREF is really a DWORD, hence, a PIC 9(9) COMP-5 will transport your data back and forth safely.

[SRFish]

Originally posted by gforseth
.....If you want to learn more about Windows data types and their counterparts in ACUCOBOL-GT or how to interface API functions, check out the training in San Diego on january 19th.


For those of us who will not be able to get to San Diego it would be very valuable to have a list of Windows data types and their counterparts in ACUCOBOL-GT. Could this list be made available on this forum?:cool:

[gforseth]

QUOTE-START
For those of us who will not be able to get to San Diego it would be very valuable to have a list of Windows data types and their counterparts in ACUCOBOL-GT. Could this list be made available on this forum?
QUOTE-END

I am very tempted to say that is your punishment for not attending... But I suppose I am soft at heart :-)

Here is the most common ones:

WINDOWS, ACUCOBOL-GT
DWORD, PIC 9(9) COMP-5.
LONG, PIC S9(9) COMP-5.
ULONG, PIC 9(9) COMP-5.
WORD, PIC 9(4) COMP-5.
BYTE, PIC X.
LPxxx, PIC 9(9) COMP-5.

Where xxx in LPxxx is any variable. The clue here is that the LP is an abbreviation for Long Pointer. In Windows Long Pointers (LP) is in fact a DWORD, thus PIC 9(9) COMP-5.

Having said this, there is still a lot to learn, so if you are thinking about serious Windows API programming, you should think twice before you let such an opportunity pass. There is a lot of information and not at least sample code of both simple and extensive use of the Windows API included in this training, which will not be released for general availability outside of this training.

[SRFish]

Thank you gforseth. It is a start and a very helpful one at that. Agreed that there is lot to learn so perhaps I shall endevour to attend this kind of training another time.

[gforseth]

I see that you are from UK, check with the UK office if they are planning any such event in Europe for the future. It will be in English no matter where it is held anyway (well, except of Scandinavia perhaps :-) ).

[MerlinM]

Originally posted by gforseth
Thanks so much to MerlinM for his contributions to the forum, I do however have some comments.

There is no such thing as "Visual BasicIsh" method of calling DLLs.

[...]



All true...(the term Visual BasicIsh specifically referred to the easy syntax of loading the libarary and calling functions). Also, I had forgotten to match up the alignment of integer's, etc...It's important to note that step.

AcuCobol has an extremely elegant method of COM interop (in fact,' VisualBasicIsh')...:) Personally, having come from a Delphi (actaully, C++ Builder) background, I'm no COM expert. I think over the next several years microsoft will de-prioritize COM wrt .net so I tend to spend my free time on that platform. Certainly though, COM is an excellent way to extend AcuCobol. I am hoping to attend the Advanced Windows training course, there is probably a lot of good information there.

[DanM]

Merlin, your right, COM will go the way of the dinosaur soon, but not immediately. .NET components are much more standardized, robust, elegant, type-safe and descriptive. I've been doing .NET development with C# and VB.NET and I have to say that creating and reusing .NET components written in any .NET langugage is a breeze. You can even debug .NET components written in a different .NET language!

It will be very interesting to see how much support Acucorp adds to the runtime for the .NET CLR and framework. I hope, for instance, there will be no more need for DEF files! .NET components have so much metadata in them that their properties should be easily retrieved during compile, or with acubench, during design.

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

[MerlinM]

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<iNumFiles; 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

[MerlinM]

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

[DanM]

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

[gforseth]

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.

[gforseth]

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

[MerlinM]

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

[DanM]

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.

[DanM]

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?

[MerlinM]

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 < P-Key

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

[gforseth]

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

[JoeD]

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.

[MerlinM]

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

[Scott]

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 < P-Key

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