All I found are very expensive tools. I can't believe taht the COBOL-community doesn't have free tools to access directy the information in the vision files. Please, I need your help.
This post might be more appropriate in the AcuCorp:AcuCOBOL-GT forum, but...
The Vision file system is proprietary. AcuCorp has chosen, for their own reasons, to keep it a closed system and not publish any specifications or API. Good decision or bad, it's their decision.
Proprietary file systems are one of the factors developers have to consider when choosing a development platform.
Perhaps I am coming late to the party but I don't understand the question. What problem are you trying to solve? I work in an AcuCobol based shop. We may be able to help.
I am looking for a tool (in unix or windows) to export the data from AcuCOBOL files into ASCII, better into MS SQL 2000. I have an old version of AcuODBC, but it doesn't work properly.
In order to make AcuODBC work properly, you need the FD's and the compiler. If you don't have the FD's you're SOL. Do you have the utilities that come with the runtime? Vutil will export a file to sequential (ASCII). The command is: vutil -unload -t source-file dest-file. This will create a fixed length text file of the data, with line-feeds as the record terminator. Good Luck.
It seems to me, that the problems I having are not with the ODBC driver, because some files after the export using the ODBC are ok and anothers are not. I think the problem may be with the XFD's files (may be they are corrupted or not updated). So, if it is the problem, how can we recreate the XFD's file?
Re-creating XFD's is easy if you have the tools. As I mentioned before, you must have the FD and the compiler. Compile any program that does IO on the file that you want an XFD for. Set the switch to create XFD's in the compile command string, or in AcuBench if you are using it. The switch to create XFD's depends on the compiler version. In older command line versions (like 2.4 on Unix) the switch is -Zx. You specify the directory for the XFD's to be placed in with the -Zf switch. If you are unfamiliar with the compiler options enter ccbl -help on the command line for a list of the options avaialable. Or, look in the documentation. The AcuCobol development system is very well documented. If you are working on an older system it would be well worth the time spent to find the manuals. Let me know what version you're using and what tools you have (or don't have).
Yes, we do have the vutil tools and I think we have all the rest of the tools.
What do you mean by "you must have the FD"?
Supouse I have only a vision-file CUSTOMER without any cobol-application either FDX. How can I recreate the XFD, if it is posible of course?
I have a extend5 CD from AcuCorp for Unix with the AcuCOBOL-GL. There are TAR-archives for differentes Unix-system. I will try to play with this CD.
By "you must have the FD" I believe the other person was meaning that merely having the data file does you no good, unless you know the layout of the various data elements - example, the first 8 characters are the Customer number, the next 20 are the Customer name, the next 20 are the Customer address-1, etc..... If you don't know what the layout is, then you're not getting much benefit from just a string of data. The data record layout is contained in the COBOL FD entry (File Description, which precedes the Record description in a COBOL program).
Do you have the source module for a COBOL program which created the file, or maintains the file, or even lists the file. That source code will contain the record layout. However, remember your basic COBOL training, if the programmer used a COPYBOOK to contain the description of the record (and ALL good programmers would!), then you will need to find the source module for that COPYBOOK.
I hope I haven't lost you.
Once you've found the layout of the record, then the use of vutil to create a sequential ASCII version of the file will get you started. But again, remember in COBOL, there are many ways that data may be represented - display, binary, packed, editted, etc...... so a 20 may represent SPACE if the field is display [pic x(20)], such as the Customer Name, but it could be part of a number in a binary or packed field, such as Customer YTD Sales field [pic s9(7)v99 comp].
The use of ODBC's would be very helpful, because the XFD (Extended File Description) basically becomes a "map" of the data file, so that if you wanted to pull the file into EXCEL for example, the data element names would then automatically become your column headers. You can also filter out just the data elements you want and not have to load each entire record into your table.
I hope this helps you.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.