I am calling an RPGLE program via CGI. The RPGLE program calls a few procedures of a service program that is bound to it.
Most of the time, the program works fine but some times it throws below error, saying it cannot resolve the service program object.
MCH3401 - Cannot resolve to object MYSRVPGM. Type and Subtype X'0203'
Authority X'0000'
Note: I did not change anything in the code or library list and the program is always invoked in the same environment
Assuming the CGI is always invoked with the same library list...
And that the *SRVPGM wasn't deleted (and subsequently recreated) when the CGI program was invoked...
Then such strange run-time errors might be cause by a parameter mismatch corrupting memory.
Check the parms being used to call any programs or procedures, not just the MYSRVPGM procedures.
Specifically, if you've got local duplicates of prototypes, meaning instead of /COPY'ing the PR into both the caller and callee, you've coded the PR separately in both caller and callee.
Also anyplace where you're using a non-prototyped call.
Related
How to get the name of the calling program from within an asynchronous remote function call (aRFC) ?
CALL FUNCTION 'BAPI_MATERIAL_SAVEREPLICA' STARTING NEW TASK lv_taskname
DESTINATION IN GROUP DEFAULT
The called BAPI triggers a user exit that I need to disable for this particular calling program. However, the local part of the stack is lost after the RFC and the name of the calling program on the local system is unknown.
The closest solution I could think of was disabling the user exit when the calling program is SAPMSSY1 (RFC calls), but that it not as accurate.
Maybe the parameter CALLER_PROGRAM of the function module RFC_GET_ATTRIBUTES. I'm not sure it works in all kinds of RFC calls.
Can We initialize Win sock in DLL_DETACH ? actulay i want to send some data when a process get terminated(DLL_DETACH)
DLL_DETACH is actually DLL_PROCESS_DETACH.
It is possible (i don't think that's any mechanism to prevent it) but it's not recommended.
WSAStartup lies in ws2_32.dll. Here's a fragment from DllMain official doc (Remarks section):
Calling functions that require DLLs other than Kernel32.dll may result in problems that are difficult to diagnose. For example, calling User, Shell, and COM functions can cause access violation errors, because some functions load other system components. Conversely, calling functions such as these during termination can cause access violation errors because the corresponding component may already have been unloaded or uninitialized.
Also, from WSAStartup official doc (same Remarks section):
The WSAStartup function typically leads to protocol-specific helper DLLs being loaded. As a result, the WSAStartup function should not be called from the DllMain function in a application DLL. This can potentially cause deadlocks. For more information, please see the DLL Main Function.
As an alternative sending the data (including the overhead of initializing the socket engine, creating the connection, and uninitializing the socket engine) could be achieved at the end of main (WinMain).
Calling WSAStartup() in DllMain() will result in a deadlock due to the loader lock. WSAStartup() can result in DLLs being loaded.
A better solution would be to install a service that can do the sending for. Talk to the service from DllMain() using your preferred interprocess comms method (shared memory, named pipes, etc).
When calling a 32 bit COM component method registered in sysWOW64 fails with an error message:
"type mismatch in method OleVarToLsVal, Unknown found, Unknown
expected"
Its win7 64 bit, but the Notes client is installed by default as a 32 bit application. The code looks like:
dim c as Variant
dim n as Variant
set c = createobject("MSWC.counters")
n = c.Get("xx")
When debugging the call, the object is set and testable with "isObject(c)", (although you can't inspect each method/property in detail in LotusScript debug).
The method is supposed to return a primitive long. I've tried setting n as long, clng-ing the values, cstr-ing the values, the parameter, strconv the parameter, using a variable for the parameter, all to no avail.
The exact same code run by WScript VBS host (in syswow64) runs the code as expected.
So, does anybody know:
If Notes 9 COM value marshalling is working for any components?
Is Notes 9 COM set to recognize the 'wow64' alternate 32 bit registry
Are there some COM related marshalling settings somewhere in the registry I can check (if so what/where are they)?
Is there some setting to tell Notes to use 32 bit components (like IIS 32bit compatibility option)
Is there anything I need to do or could do in the main OS to 'redirect or configure' COM
Or is Notes just broken again and nobody cares?
Any help appreciated - Thanks.
The easiest and probably most productive way to solve this would be to open a PMR with IBM. They should be able to answer this quite quickly.
Well, 7 years on (and seriously obsolete!) just an update for anybody looking for an answer... There are a couple of Notes settings needed and not all COM/Active-X componenets or data types are supported by LotusScript, so even if Notes is setup correctly, you still may not be able to acces/use any specific component or some methods in the component.
The user must be allowed to run unrestricted agents/code in the 'Sign or run unrestricted methods and operations:' in the security section of the server(s) document.
The Notes client execution control list ('ECL') must allow access to 'External programs' either by default or to the code-signer. An ECL warning box will ask the user to continue if the external access has not been granted.
If you try to execute an unsupported method or unsupported data type, then further errors will be issued either by LotusScript or COM/Active-X error reporting. The Notes developer help file for 'CreateObject' gives a bit more detail about unsupported data types:
LotusScript does not support identifying arguments for OLE methods or properties by name rather than by the order in which they appear, nor does LotusScript support using an OLE name by itself (without an explicit property) to identify a default property.
Results are unspecified for arguments to OLE methods and properties of type boolean, byte, and date that are passed by reference. LotusScript does not support these data types.
Relying on the 'default property' to access a default method is a common mistake and requires you to pay extra attention to the component details. It is easy to assume the component is not working, but in fact you're just not using it properly.
One way to test this is to try to open a common object available on all Windows machines (maybe others?) maybe 'FileSystemObject' (FSO) or VbScript 'regExp' component. If these work, you can build on that. Getting the 32/64bit registration correct for your client install is another element to test/get right.
For my issues, I suspect that I was using unsupported methods or data types and having used COM/Active-X in Notes occasionally, its all worked ok in general.
I'm trying to upload a file from a server directory to the SAP CRM System (attachment to an Opportunity), therefore I am using the method create_with_file of the cl_crm_documents class.
To call this method I am using a RFC-Function created by myself.
If I test my RFC-Function within the Function Builder, everything works fine.
If I execute the RFC from a external System (in my case MS-Outlook) an error occurs: "Exception: RFC callback server not available".
I started the debugger and the program runs about half way through (So the connection works):
The create_with_file calls a couple of functions until the RFC_START_PROGRAM function is called. The error occurs exactly at this line.
Does anybody know why the error occurs only if I call the function remotely? How to solve this?
I don't have access to a CRM system, but this is what's probably happening: The class you use tries to perform some action on the front-end PC using the SAP GUI. For this, it performs an RFC call back or the SAP GUI. This works fine as long as you are using the function builder because there's a GUI connection available. Once you use some other means to invoke the function module, the GUI is no longer there and the program won't work. I'd suggest you check the code to see whether there is some parameter or customization that allows you to suppress the RFC call...
I have some VB.NET code that creates a TransactionScope instance:
LoggingUtility.LogDebug("UpdateCallTable", "SatComCallDataImporter", "About to associate call data with contracts")
Using ts = New TransactionScope()
LoggingUtility.LogDebug("UpdateCallTable", "SatComCallDataImporter", "Getting all unimported SatCom calls")
My application is throwing an exception on the call to the creation of a new TransactionScope, with "Object reference not set to an instance of an object.". The exception isn't thrown on my development machine or my test machine; only on the customers production machine, and I have no idea why. I've placed debug lines immediately before and after this line so I'm positive it is this line causing the problem.
A have used TransactionScopes throughout the application and this is the only place throwing the exception on the client machine.
"About to associate call data with contracts" gets written to the log and the next log entry is the "Object reference not set to an instance of an object".
Code works fine if I move it out of a transaction.
I've been struggling with this for 4 days now and have got no closer.
Perhaps you have an issue with MSDTC?
I'd lean more towards a coding error though, because the TransactionScope object should be initialised and non null, but it will be indicating an error.
Perhaps showing us the code might help us further?
UPDATE: I've had experience with logging engines failing to log the line before an exception, which is sometimes caused by release mode reordering, or the routine doesn't flush actively and the app crashes nastily before it can complete.
I would suggest placing a logging line directly after you using() statement to assert that the TransactionScope is not null. Given the way you have used the code, it is IMPOSSIBLE for the result of that code to return null, the constructor must throw an exception if the constructor fails, otherwise you have a non null transaction scope.
Perhaps a little more code and this test might help some more?