Re: Free Download Cobol For Windows 7 32-bit Torrent
Taichi Reilly
I am diving into the world of COBOL and have written a simple program that compiles and runs as intended from my KDE Plasma command line using open-cobol (cobc). I have seen a few sites mention that COBOL is quite portable and does not require multiple compilations, but when I try to run the same output program on Windows 10 (ie 32-bit), the system states that the program is a 16-bit application and thus cannot run.
Your program is likely already a 64bit executable (depending on your actual OS, otherwise its 32bit), but it is definitely no Windows binary (and because Windows doesn't recognize it, it just guesses this is a 16bit executable).
COBOL itself is portable, even between different compilers (if you restrict yourself to "standard" COBOL or use only the extensions that the compilers used share), but you need "some" native parts in any case.As a well known example take Java or .NET: the "runtime" is a native binary, which executes the java (or msil) byte code.
The easiest option for your case: take a compatible compiler and recompile your COBOL source for this platform on this platform.I'd suggesting the successor of OpenCOBOL: GnuCOBOL, using the official windows binaries.
Quick aside, the normal way we have this configured in the current setup of VS 2019, VC 7, instant client 19 32-bit is to make a copy of the file orasql19.dll as orasql8.dll this enabled things to work without the need of any extra configuration. Even though the normal recommendation is using a procedure pointer or the initcall directive.
Moving to client 19.18 but 64-bit the results are a bit different. At connect we get SQLCODE -1 which should be unique constraint violated, but when running the tests with connection trace activated we can see that no attempt to connect to the remote server is made. The error is internal to the client. A clue is in the error message which is "ORA-00001: unique constraint (%s.%s) violated" i.e an incomplete error message
I'm unable to come up with any additional test and will submit at much wordier entry as a support case. But I cannot help to be curious about if anyone else has tried this and found a workable solution.
Someone at MF really should write a white paper about how to configure visual cobol and pro*cobol/instant client ON WINDOWS since today the information is spread out in different forum posts and knowledge base articles. With a lot of it being quite old or for unix/linux. Not the most fun of subjects but one that needs some love and a document that is current.
In Procedure division:
move "PATH" to EnvName
display EnvName upon environment-name
accept EnvVal from environment-value *> After this statement EnVVal will contain the value of PATH at the runtime
display EnvVal
This has really been extensively tested on our side with no success which is why we've opened a case to see MF's opinion on this, plus posting here to see if someone has managed to put together a recipe for VS2022/VC8/Instant Client that actually works.
It wasn't clear to me from your response if you checked the value of PATH just before the EXEC SQL CONNECT (using the DISPLAY/ACCEPT code above). For certain with the 173 errors, some module in the oracle client is not being resolved or the correct one is not being picked up.
I just set up a Windows 10 VM environment using the same versions of everything as you are, using the Oracle Instant Client 19 for 64-bit and I when I use the set procedure-poiinter method it works and when I use the copy to orasql8.dll method it also works.
Support say they have this working and you have this working. This tells me were doing something wrong but since there isn't any official documentation from Micro Focus about how to set up Visual Cobol and Pro*Cobol using Instant Client on Windows there is nothing to compare to. This is my biggest complaint about the entire experience, trying to find forum posts and old knowledge base articles that discuss parts of the solution and often with much older versions of the products.
I have no idea how many VC users are using Pro*cobol and at the same time looking at using the latest versions. Perhaps you should just stay on something old that works. Again, the lack of documentation is probably an indication of the number of users.
One fun difference in all this is that if we start a VC command prompt, set our environment variables, and run.exe the int file created in VS2022/VS8 from the prompt the program works. But try to debug it... and no
If it works when you run your program from a VC command prompt, it may be worth setting COBSW=+A before running, or executing run (+A) your .int program. That will dynamically attach the debugger to your running program.
I have not looked thru documentation to see if there is any specific documentation for VC/VS 2022 and Oracle Instant Client.
I imagine if there was, from an execution and debugging standpoint it wouldn't be any different than any other customer library or 3rd party library...i.e. ensure the directory of the library is on the PATH and there are no conflicts on the PATH that take precedent in your and your environment. That seems to be the issue here and the process you are going through now is seeing where these conflicts could be coming from.
Can you verify the complete value of PATH is correct using ACCEPT/DISPLAY ENVIONMENT-NAME ENVIRONMENT-VALUE as I suggested above. The fact that you can run from the command line suggests the environment is different than it is when using the IDE.
But when I revisited the 32-bit solution there is a difference. With PATH system-wide containing the two directories for a 32-bit instant client and TNS_ADMIN set system wide as well. No variables in the Application/Environment tab.
Adding a PATH variable with the instantclient directories to Application/Environment solves that particular problem but the PATH you get isn't exactly what you expect. The first dir in the PATH above is missing for instance.
(3) Simplest db sign-in? In our Windows production environment we have (a) standalone machines, (b) server/client and (c) servers with users connecting with RDT. Is it easier to use built-in windows automatic security or have a specific MySQL username and password which is then specified in the programs. Simplifying deployment is my aim.
The default project type for native projects is x86 which is 32-bit. This means that the ODBC DSN that you need to use must also be 32-bit. You can create this using the ODBC Datasource Administrator (32-bit) which can be found under the start menu Micro Focus Visual COBOL->Data Tools-->Data Connections group.
The version of the ODBC driver that you use depends on the type of data you wish to access in your program, If you are storing data as Unicode characters, (2 byte characters) then you would need to use the Unicode version of the driver and access these fields using PIC N host variables. If you are using single byte ANSI characters (PC character set) only then you can use the ANSI driver and return the data into PIC X host variables.
Is anyone running COBOL programs on DOSBOX ? I have downloaded and set up DOSBOX to run an old copy of MF COBOL, which sets up and compiles the various progs perfectly. ( Windows 7 32 bit sys ). However when I come to run the programs ( which read from / write to files in the same mounted C:\ folder), no input data is found (all spaces) and no output data is written to any of the files. I'm probably missing something really simple, in assigning these files, so if anyone can help or point me in the right direction I'd be be extremely grateful..... as I'm on the point point of binning windows 7 and going back to good old XP !! Many thanks.
I'm actually a little surprised you have a DOS program that will run in Windows XP but not in 32-bit Windows 7. 64-bit Windows 7 can't run DOS programs at all, but I was not aware that 32-bit Windows 7 had substantially different capabilities when it came to DOS programs.
Hi Jorpho. Many thanks for your reply. I had previously gone down the VMware route but apparently my PC was not equipped with the right visualisation, so that was a non-starter and I assumed that was the case for all virtual environments. Which is why I tried DOSBOX. However, after reading your reply I had another search and managed to download XP mode from Microsoft, and after spending most of today setting it all up, changing to the right paths and libraries etc etc ..... BINGO ! It still needs tweaking a bit but, in essence, it's all running beautifully.
So, many thanks for your help and for taking the time to reply - you've cheered up a senior citizen no end. Problem Solved.
VX/COBOL is a full-featured VMS / OpenVMS COBOL to ANSI COBOL Compiler/Transpiler. VX/COBOL allows VMS / OpenVMS COBOL source code to be compiled on Linux and multiple host machines. The application can be maintained in the original COBOL language or can be switched over to Linux ANSI COBOL Development Environments. VX/COBOL will convert 100% of supported VMS / OpenVMS COBOL syntax and Semantics to working COBOL (Fujitsu or Micro Focus).
Many of our Cobol clients have indicated that they wanted to see "Less Words" more "Examples" so, we've tried to strike a balance between Examples and keeping this site "Google Mobile [Responsive] Friendly"
This processing can happen as part of the build process: continue developing and maintaining the original VMS / OpenVMS COBOL sources, leverage expertise of current developers, without disrupting the current development environment.
Current sources, directory layout, and logical controls for development, testing, and production are retained. Provide production Linux deployment of native executables and applications built from current VMS / OpenVMS sources.
VX/COBOL is so complete that entire IT departments continue to develop on VMS / OpenVMS COBOL and get release after release into production, at the same time, when each release is "pushed" the CI VX/COBOL : Translated all the COBOL from scratch, compiles all the cobol, links all the cobol, then run autoamted test sutes. The migration to Linux is simplh "part of the VMS / OpenVMS Development Cycle".
7fc3f7cf58