I am primarily a C developer. I have a sample COBOL driver that calls my C DLL in z/OS.
The COBOL driver was working fine in z/OS COBOL V4 when we used the Pre-Linker and IMPORT statements to define the API’s inside the DLL.
With COBOL V6 (and V5), the pre-linker is no longer supported (along with a myriad of other changes).
How can I get COBOL to recognize my IMPORT statements to know about the LONGMIXED API’s inside my DLL?
The COBOL call looks like:
CALL
'PBFNTerminate' USING
BY VALUE NULL-POINTER,
My COBOL program is compiled with RENT,DLL,PGMN(LM).
I tried to simply include the IMPORT statements from the DLL creation in the BINDER but they seem to be ignored. I have DYNAM(DLL),CALL as a BINDER parameter but I still get:
IEW2456E 9207 SYMBOL PBFNTerminate UNRESOLVED. MEMBER COULD NOT BE INCLUDED FROM THE DESIGNATED CALL LIBRARY.
If I run the BINDER with DYNAM(DLL),NCAL I get
IEW2454W 9203 SYMBOL PBFNTerminate UNRESOLVED. NO AUTOCALL (NCAL) SPECIFIED. NAME SPACE = 3
And then a S0C1 when I try to run.
I’m thinking there is a step or parameter I’m missing but obviously I don’t know what it is.
Side comment, the COBOL INTERLANGUAGE COMMUNICATIONS guide seems to be written pre COBOL V5 and V6: https://www.ibm.com/docs/en/cobol-zos/4.2?topic=answers-interlanguage-communication
Found the problem. At least for me, the PLKED step defaulted NOUPCASE. In the Binder I had to add CASE(MIXED) to the PARM. The the final solution was: PGM=HEWL,PARM='DYNAM(DLL),CASE(MIXED)'.
Related
I am working on making a pretty trivial change to an old existing pascal source file. I have the source code, but need to generate a new hex file with my changes.
First, I tried compiling with "Embedded Pascal", which is the program used by my predecessor. Unfortunately, it is an unregistered copy and gives the message that the file is too large for the unregistered version. Support for and even the homepage for the project has disappeared (old), so I have no idea how I would register.
I tried a couple other compilers, "Free Pascal" and "Turbo51", and they are both giving similar errors:
Filename.pas (79): Error 36: BEGIN expected.
Linkcode $2E
^
The source code begins with
Linkcode $2E
LinkData $0A // normally 8 - make room for capacitance data
Program Main; Vector LongJmp Startup_Vector; //This inserts the start to the main routine.
uses IntLib;
I'm not well-versed in Pascal or embedded programming, but as I understand it, the Linkcode and LinkData lines are required to set up the RAM as needed. Following the "Const" and "var" declarations are subroutines that indeed start with procedure... begin... end.
I realize that Pascal is a bit out of date, but we are stuck with it and our old micro. Any ideas why previously working source code with trivial changes cannot be compiled? I am willing to consider other compilers, including paid options, if any are available with decent support. I am using Windows 10 x64 processor to compile, and flashing to an Atmel 89C51RC2.
If more source code is needed for diagnosis, please let me know what in particular, as I'll need to change some proprietary information before posting. Thanks!
Statements like linkcode and linkdata are not general, but target and compiler specific. Unless you have the know-how to reengineer to a different compiler, getting the original one is best.
Thanks to all for the information. While I didn't find an exact solution here, your comments were helpful for me to understand just how compiler-specific the Pascal code was.
In the end, I was able to get into my predecessors files and transfer registration, solving the issue for now. As suggested, I think I will port to C in the future to avoid fighting all the unsupported compiler nonsense.
Ok folks this is a long one, so please bear with me. I'll preface this by stating that I am -for all intents and purposes- a noob.
I'm trying to link to a running instance of a program (ETABS) using IronPython. The program has an API and decent documentation on how one can go about hooking into the running instance (EXAMPLE). However, their examples are for Python, C#, VB.net but not IronPython.
No biggie I thought, the Marshal module can be used to hook into it. So I tried this:
from System.Runtime.InteropServices import Marshal
csiApp = Marshal.GetActiveObject("CSI.ETABS.API.ETABSObject")
SapModel=csiApp.SapModel
Unfortunately I get errors on that last line - "ETABSObject has no attribute SapModel".
And yes, I've tried running it with csiApp.SapModel() as well with the same results.
So I delved deeper into it and apparently the object needs to be cast into another type - at least that's the way its been done for the C# example (LINK). Since - to my knowledge - we can't really cast objects around in Python (and yes, I've already tried clr.Convert) I came to the conclusion that the object being returned to Ironpython is a few abstractions removed from the object that I really need. Apparently comtypes can handle this automatically in the background (seeing as the python example works flawlessly). The code block below shows the object types returned to Ironpython and to pure python respectively:
Ipy : <System.MarshalByRefObject object at 0x000000000000002B [CSI.ETABS.API.ETABSObject]>
Python with comtypes : <POINTER(cOAPI) ptr=0x2e68d17f7c8 at 2e690b36a48>
I'm working on Ironpython 2.7.3 and can't really update it (for several reasons not relevant to this post). Would love to have advice on how to fix this or on how to install comtypes on Ipy.
So I think I've found the reason why this is happening - Ironpython cannot directly use MarshalByRefObjects (source) since Reflection doesn't work on these. It seems I'll need to create a C# class which can cast this object into the one I want, compile it into a dll and load that into my Ipy code.
I'll leave this here in case someone with more knowledge has a better answer.
I am trying to load a DLL power.dll following this tutorial. However, I am getting the warnings
WARNING: ...it\faforever\fa\lua\ai\aiarchetype-managerloader.lua(48): could not load package `power' from path `E:\lua\'
WARNING: stack traceback:
WARNING: [C]: in function `require'
Unfortunately there is not more output than that. All I know is that the game I try to modify "uses uses a slightly modified version of Lua 5.0." [1] - whatever "slightly" is supposed to mean ..
The thing is that I tested this import with a Lua 5.3 standalone and it works. I can call that square() function (see tutorial) but it's not working with the game.
Of course there is a chance the they simply do not allow loading a .dll simple as that but of course I hope than it's simply just me not seeing something or missing something out.
Is there a chance that somebody could help me with this (quite specific) question?
Am I doing it right, speaking in LUA 5.0 standards:
The file which is supposed to load my DLL simply calls:
_G.LUA_PATH = "E:\\lua\\"
require("power")
At first I got an error becacuse LUA_PATH was not defined as I called require. After defining LUA_PATH the require seems to work but something else still seems to fail here ..
[1] http://supcom.wikia.com/wiki/Lua
I'd like to know if there is a way to mix C# and Obj-C code in one project. Specifically, I'd like to use Cocos2D for my UI in Obj-C and call some MonoTouch C#-Library that does some computations and get some values back. Is there a way to do this? Or maybe the other way around, i. e. building in MonoTouch and calling Cocos2D-functions?
Thanks.
The setup that you describe is possible, but the pipeline is not as smooth as it is when you do your entire project in MonoTouch. This is in fact how we bootstrapped MonoTouch: we took an existing Objective-C sample and we then replaced the bits one by one with managed code.
We dropped those samples as they bitrot.
But you can still get this done, use the mtouch's --xcode command line option to generate a sample program for you, and then copy the bits that you want from the generated template.m into your main.m. Customize the components that you want, and just start the XCode project from there.
During your development cycle, you will continue to use mtouch --xcode
Re: unknown (google):
We actually did this as described.
See this page for a quick start, but the last code segment on that page is wrong, because it's omitting the "--xcode"-parameter.
http://monotouch.net/Documentation/XCode
What you have to do to embed your Mono-EXE/DLL into an Objective-C program is to compile your source with SharpDevelop, then run mtouch with these parameters:
/Developer/MonoTouch/usr/bin/mtouch --linksdkonly --xcode=output_dir MyMonoAssembly.exe
This only works with the full version of MonoTouch. The trial does not allow to use the "--xcode"-argument . The "--linksdkonly"-argument is needed if you want mtouch to keep unreferenced classes in the compiled output, otherwise it strips unused code.
Then mtouch compiles your assembly into native ARM-code (file extension .s) and also generates a XCode template which loads the Mono-Runtime and your code inside the XCode/ObjC-program. You can now use this template right away and include your Obj-C-code or extract the runtime loading code from the "main.m"-file and insert it into your existing XCode-project. If you use an existing project you also have to copy all .exe/.dll/.s files from the xcode-output-dir that mtouch made.
Now you have your Mono-Runtime and assembly loaded in an XCode-project. To communicate with your assembly, you have to use the Mono-Embedding-API (not part of MonoTouch, but Mono). These are C-style API calls. For a good introduction see this page.
Also the Mono-Embedding-API documentation might be helpful.
What you have to do now in your Obj-C-code is to make Embedding-API calls. These steps might involve: Get the application domain, get the assembly, get the image of the assembly, locate the class you want to use, instantiate an object from that class, find methods in class, call methods on object, encapsulate method arguments in C-arrays and pass them to the method-call, get and extract method return values.
There are examples for this on the embedding-api-doc-page above.
You just have to be careful with memory consumption of your library, as the mono runtime takes some memory as well.
So this is the way from Obj-C to C#. If you want to make calls from C#/Mono into your Obj-C-program, you have to use the MonoTouch-bindings, which are described here.
You could also use pure C-method calls from the embedding/P/Invoke-API.
Hope this gets you started.
Over the weekend it emerged that someone has been porting Cocos2D to .NET, so you could also do the whole work on .NET:
http://github.com/city41/CocosNet
Cocos2D started as a Python project, that later got ported to Objective-C, and now there is an active effort to bring it to C#. It is not finished, but the author is accepting patches and might be a better way forward.
Calling Objective-C from MonoTouch definitely looks possible. See the Objective-C selector examples
What library are you calling? Perhaps there's an Objective-C equivalent.
In short: I want to monitor selected calls from an application to a DLL.
We have an old VB6 application for which we lost the source code (the company wasn't using source control back then..). This application uses a 3rd party DLL.
I want to use this DLL in a new C++ application. Unfortunately the DLL API is only partially documented, so I don't know how to call some functions. I do have the functions signature.
Since the VB6 application uses this DLL, I want to see how it calls several functions. So far I've tried or looked at -
APIHijack - requires me to write C++ code for each function. Since I only need to log the values, it seems like an overkill.
EasyHook - same as 1, but allows writing in the code in .NET language.
OllyDbg with uHooker - I still have to write code for each function, this time in Python. Also, I have to do many conversions in Python using the struct module, since most functions pass values using pointers.
Since I only need to log functions parameters I want a simple solution. Is there any automated tool, for which I could tell which functions to monitor and their signature, and then get a detailed log file?
A "static" solution (in the sense it can capture a stack trace on demand) would be Process Monitor.
A more dynamic solution would be ApiMonitor, but it may be too old to be compatible with the applications to monitor. Worth a try though.
Some more Google searching found what I was looking for: WinAPIOverride32. It allows writing text files such as:
CustomApi.dll|void NameOfFunction(long param1, double& param2);
Later on, these files can be used inside the program to log all calls to NameOfFunction. Now I just need to figure out how to log arrays and structs parameters.
Visual Studio Addin Runtime Flow here:
Runtime Flow in real time monitors and logs function calls and
function parameters in your running .NET application and shows a stack
trace tree. No instrumentation or source code required for monitoring.
If you just want to see the function interfaces of the DLL, you could try "Dependecies" (https://lucasg.github.io/Dependencies/). This is a nice remake of the DependencyWalker in as OpenSource.
This only allows you to see the dependencies of the DLL, with the corresponding function names (however, not the calling structure). Unfortunately, I don't believe it will tell you which specific functions in a DLL are being used by the calling DLL/EXE.