while running cobol prog in Fujitsu COBOL 3.0 an error is occuring saying that F3BIPRCT.dll is not found. what can be the problem.
Can you track down F3BIPRCT.dll? If so, make sure the directory it is in, is in your PATH variable.
Related
I am trying to use the Dafny-to-Python compiler that is suggested in Dafny's reference (25.7.7): http://dafny.org/dafny/DafnyRef/DafnyRef.html#2577-python
However, I cannot run the first step for it in the terminal: dafny build --target:py A.dfy, since I get the error: Dafny: Error: unknown switch: --target. I use Use /help for available options as they suggest, but have no idea on how to solve.
Just in case, I also attempted using the old version of the command (see 25.8.11. in the same reference): dafny Hello.dfy -compileTarget:py but then got message Dafny: Error: Invalid argument "py" to option compileTarget.
Any idea? Note that the authors themselves clearly state that The Dafny-to-Python compiler is still under development.
PS: I usually use Dafny in Visual Studio and not in the terminal, so maybe I lack some kind of library or something.
Neither the new CLI nor the Python compiler are supported by the very outdated version of Dafny you are using. You are presumably not using the correct VS Code extension, so I would start there. As of today, this should install 3.10.0 at /Users/$USER/.vscode/extensions/dafny-lang.ide-vscode-3.0.3/out/resources/3.10.0/github/dafny/Dafny.dll. To see how to use the dll, try hitting F5 with a Dafny file opened in VS Code. The Python compiler is complete and passes all tests these days.
I have the "wonderful" task of maintaining a legacy program that I didn't write. The Cobol program runs in a z/OS 2.2 environment and is compiled with IBM Enterprise Cobol 5.2. For debugging I would like to compile the program with the option CBL LIST, TEST (EJPD, SOURCE). Unfortunately, my source code has more than 999999 lines, so there is an error when compiling.
Is there a way to circumvent the limitation of the number of lines or is there only a way to split the program?
The 999999 limit on number of lines has been present since at least VS COBOL II, released in the mid-1980s. It's also present in Enterprise COBOL 6.3, the latest version prior to the compiler as of this update.
Perhaps someone is having you on, presenting you with uncompilable source. This is a compiler limit, and as #SaggingRufus has indicated, the solution would be to break the program up into multiple modules.
I would contend that a million+ lines of source code is incomprehensible.
Other mechanisms available to you include evaluating the code, looking for statements that span multiple lines for no good reason...
MOVE
A
TO
B
...is just silly.
As an aside, maintaining code you didn't write is part of the job. It used to be normal to put the new employees through a period of maintaining the existing code base to get them familiar with shop standards, etc.
Depending on the JES version, I believe you can you the WARNING parameter which would look something like this
//JOB10 JOB 1234,ME,LINES=(999999,WARNING)
This tells the system to continue even if the line limit is hit and only issue a warning.
Alternatively, you could output this compile listing to a file rather than a SYSOUT. Then the line limit would not apply
Also keep in a mind the having that many line in the JES spool is not a good thing, so I would recommend going the file route.
I'm interested in playing around with the MaxSAT/MaxSMT c example (specifically, maxsat.c) provided on the z3 (Microsoft Research) website. Using Visual Studio 2010, I eventually got the example to compile (using a fresh install of z3 4.0). However, I can't get any of my (SMT 2.0) models to run using them. Further, I cannot get the example posted in this question to work either.
In the first case, my compiled program crashes when it tries to call Z3_get_smtlib_num_formulas in get_hard_constraints of the file. I don't know why, instead, I get the standard windows 7 "this program has stopped working" popup.
In the second case, it reports unsupported ;benchmark.
In order to help me to get this work, I was wondering if
(a) Has anyone had similar issues when compiling this code, and if so, how did you resolve them?
or
(b) How can I debug either compilation of the file (assuming it is correct)? Namely, can someone enumerate the correct libraries (and library versions - e.g., z3 4.0?) to include in the compiler options to get this example working?
In either case, information on the error reported in the second case would also be appreciated: what does it mean exactly? The keyword was not valid? That the SMT input is the wrong version? Or something else?
Thanks.
The MaxSAT example has not been updated to SMTLIB 2.0 yet. It uses the function Z3_parse_smtlib_file to parse the input, which means that it supports only SMTLIB 1.0 at the moment.
This example is distributed alongside Z3, i.e., you should have received a copy in Z3-4.0/examples/maxsat/, which also contains compilation and execution scripts.
Compilation should be straight-forward by running build.cmd in a Visual Studio Command Prompt, or build.sh on Linux.
We need to get data out of an older accounting system. We have received a dll that gives us access to the data we need. It includes a type library that we have imported.
If we run our test application from the same directory as the accounting system, everything works fine. If we try to run our application from a different directory, we get the following error:
Dynamically Bound RTS
Runtime DLL 'OOPS', version 3.1, entry point oops
not recorded in registry, not found or incompatible with requirements
of dynamically bound COBOL program. Dynamic binding of RTS requires:
Runtime DLL 'OOLSM', at least Version 3.1
Can anybody provide some helpful information on this?
Are we supposed to have some kind of cobol runtime in our directory? Or in the path? Or registered in the registry?
Thanks,
-Vegar
Updates:
Setting the system %path% to include the path to the accounting system seems to do the trick. Including it as a user variable did not have the same effect for some reason.
What Cobol are you using?
I had done this for year with Microfocus NetExpress 3.1, and all works just fine.
I write COBOL DLL to access COBOL data files, and also write Delphi DLL to add new features to old COBOL systens.
And yes, I use to set the runtime path, that is environment variable called COBDIR, there are others,but usually %PATH% and %COBDIR%is enough.
If you give more detais about what COBOL compiler are you using, and how is the dll interface that you are calling, will me ore easy to help you.
And maybe "Dependence Walker" can help you to identify what run time files are missing, if it is.
http://www.dependencywalker.com/
If it works from the accounting app's directory, but not a different one, the first thing I'd try is adding that directory to your path.
Unless it is already loaded into memory, Windows looks for DLL's that a program is requesting in every location listed in its PATH environment variable, and also in the directory the application is located within.
I may have this completely wrong, but my understanding is that the --standalone compiler option tells the compiler to include the F# core and other dependencies in the exe, so that you can run it on another machine without installing any 'runtime'.
However, I can't get this to work in the CTP - it doesn't even seem to change the size of the output file (docs I've read say about 1M extra).
"Google may know, but if it does, it ain't telling, or I'm not looking in the right place"
UPDATE:
It seems to work with latest CTP update 1.9.6.2
UPDATE2:
I have since experienced another error:
FSC(0,0): error FS0191: could not resolve assembly Microsoft.Build.Utilities.
If you get errors like this when trying to compile --standalone, you need to explicitly include them as references in your project.
Answer from MS:
There is a CTP update 1.9.6.2 that fixed some --standalone bugs.
I'm reinstalling now...
UPDATE:
Works for me - so the my accepted answer is download CTP update 1.9.6.2.
F# manual: Statically linking the F# library using "--standalone"
Did you try to run peverify.exe utility?
This has been a pet hatred of mine for a long time (it has been broken in every CTP release ever including the latest 1.9.6.16 May 2009 release). The "solution" is essentially to write your own build system that is not broken.
This is a real problem for me because I have accumulated hundreds of great F# programs that I would like to put on our site but it takes hours to build each one into a standalone executable.