Hi Chris,

I had changed that property already and had done test runs. In fm-sem, as long as no procedure division copybooks are added at the end, service run is good. Moment, COPY copybook statements are added, even with the Startup object as Main, I still get 'Service did not respond to start or control request in a timely fashion'. I am still trying to figure out which exact statement/call is causing this problem.

When I changed the Startup object to Main I can start and debug the service fine on my system, but I only have the project that you sent in for the other support case to work with.

I would recommend creating a new support case for the startup problem and attaching your failing project as it now exists so that I can investigate further.

Thanks

Thank you Chris. I will inform Fano about a new case required.

I am facing problem in running the service for the same project that I have shared in the support case. In FM-SEM when GDCPEX1 copybook is commented, service run fine but when it is included, I get the below error:

I see below error detail in Event Viewer:

Application popup: Could not load file or assembly 'file:///D:\\VCRUN\\GETVARS.dll' or one of its dependencies. The module was expected to contain an assembly manifest. : Unhandled Exception: COBOLRuntimeException
174     Imported file not found
(Could not load file or assembly 'file:///D:\\VCRUN\\GETVARS.dll' or one of its dependencies. The module was expected to contain an assembly manifest.)
 at MicroFocus.COBOL.Runtime.Common.LoadedAssembly  MicroFocus.COBOL.Runtime.BaseFinder.LoadAssembly(MicroFocus.COBOL.Runtime.Common.RunUnit runUnit,System.String assemblyName,Boolean hasEvidence)
 at System.Reflection.MethodInfo  MicroFocus.COBOL.Runtime.LoadAndSearchAssembly.FindProgram(MicroFocus.COBOL.Runtime.Common.RunUnit runUnit,MicroFocus.COBOL.Runtime.ProgramName progName)
 at Int32  MicroFocus.COBOL.Runtime.BaseFinder.Action(System.Object obj)
 at Void  MicroFocus.COBOL.Runtime.Common.PrioritizedList.Action(System.Object actionData,Boolean remove)
 at System.Reflection.MethodInfo  MicroFocus.COBOL.Runtime.ProgramFinder.FindProgram(MicroFocus.COBOL.Runtime.Common.RunUnit runUnit,MicroFocus.COBOL.Runtime.ProgramName progName)
 at System.Reflection.MethodInfo  MicroFocus.COBOL.Runtime.Common.RunUnit.GetLoadedOrNewProgram(System.String program,System.Object& instance)
 at MicroFocus.COBOL.Program.ProcedurePointer  MicroFocus.COBOL.Program.ProcedurePointer.CreateProcedurePointer(MicroFocus.COBOL.Runtime.Common.RunUnit runUnit,System.String programName)
 at MicroFocus.COBOL.Program.ProcedurePointer  MicroFocus.COBOL.Program.ProcedurePointer.GetProcedurePointer(MicroFocus.COBOL.Runtime.Common.RunUnit runUnit,System.String name)
 at System.Object  MicroFocus.COBOL.Program.Control.CallReturningObject(UInt32 callConvention,System.String program,System.Object[] parameters,MicroFocus.COBOL.Program.IObjectControl pgInstance)
 at Int64  MicroFocus.COBOL.Program.Control.Call(UInt32 callConvention,System.String program,System.Object[] parameters,MicroFocus.COBOL.Program.IObjectControl pgInstance)
 at Int32  FM-SEM.FM_SEM() in D:\\VCSOURCE\\GDCPEX1.CPY:line 73
 at Void  WindowsService9.Service1.OnStart(System.String[] args) in D:\\Kavitha\\WindowsService\\WindowsService9\\Service1.cbl:line 93
 at Void  System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(System.Object state)
 at Void  System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 at Void  System.ServiceProcess.ServiceBase.Run(System.ServiceProcess.ServiceBase[] services)
 at Void  WindowsService9.Program1.Main() in D:\\Kavitha\\WindowsService\\WindowsService9\\Program1.cbl:line 22
Inner Exception: BadImageFormatException
Could not load file or assembly 'file:///D:\\VCRUN\\GETVARS.dll' or one of its dependencies. The module was expected to contain an assembly manifest.
 at System.Reflection.RuntimeAssembly  System.Reflection.RuntimeAssembly._nLoad(System.Reflection.AssemblyName fileName,System.String codeBase,System.Security.Policy.Evidence assemblySecurity,System.Reflection.RuntimeAssembly locationHint,System.Threading.StackCrawlMark& stackMark,IntPtr pPrivHostBinder,Boolean throwOnFileNotFound,Boolean forIntrospection,Boolean suppressSecurityChecks)
 at System.Reflection.RuntimeAssembly  System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(System.Reflection.AssemblyName assemblyRef,System.Security.Policy.Evidence assemblySecurity,System.Reflection.RuntimeAssembly reqAssembly,System.Threading.StackCrawlMark& stackMark,IntPtr pPrivHostBinder,Boolean throwOnFileNotFound,Boolean forIntrospection,Boolean suppressSecurityChecks)
 at System.Reflection.RuntimeAssembly  System.Reflection.RuntimeAssembly.InternalLoadFrom(System.String assemblyFile,System.Security.Policy.Evidence securityEvidence,Byte[] hashValue,System.Configuration.Assemblies.AssemblyHashAlgorithm hashAlgorithm,Boolean forIntrospection,Boolean suppressSecurityChecks,System.Threading.StackCrawlMark& stackMark)
 at System.Reflection.Assembly  System.Reflection.Assembly.LoadFrom(System.String assemblyFile)
 at System.Reflection.Assembly  MicroFocus.COBOL.Runtime.Platform.Common.PlatformCommon.LoadFrom(System.String assemblyFile)
 at MicroFocus.COBOL.Runtime.Common.LoadedAssembly  MicroFocus.COBOL.Runtime.BaseFinder.LoadAssembly(MicroFocus.COBOL.Runtime.Common.RunUnit runUnit,System.String assemblyName,Boolean hasEvidence)

Hi Kavitha,

The project you sent in previously does not contain the programs that are required for your new test. Although there is a GETVARS.cbl in the SupportingPrograms folder it is not part of the project and there are missing copybooks for it 

Fano, is going to close the current case and create a new one for you for this new problem.

Can you please zip up your latest version of the project and attach it to the new case once you receive notification of its creation. Then I can investigate further.

Thanks 

Hi Chris,

I am posting here more detailed version in addition to what was commented on the support case. I wanted to restrict to only case related information in the support case.
I am relatively new to Visual COBOL in Windows, my experience is on Mainframe COBOL. Got moved to Visual COBOL project couple years back. Apologize if I take time to digest the information or ask any trivial questions. 

Thanks for the detailed review provided in the support case. To understand your comments better, I went through in detail about the managed vs native, 32bit vs 64 bit compilation. I got a basic understanding and have couple of questions. First, I wanted to give a brief on the project that I am working currently. It is a migration/upgradation project. Production servers with Visual COBOL exes are currently run in Windows 2012. Now, plan is to move to Windows 2022 in production. Development environment is of Windows 2016, with Visual Studio 2015, VC 4.0 to be upgraded to Windows 2022, VS 2019, VC 8.0

------
1) Migration is for the code from 2012 to 2022 Windows, 2015 to 2019 VS, VC 4.0 to 8.0. I have tested most exes in the new Windows 2022, VS 2019, VC 8.0 and they work fine. Just want to get your expert advice on if we can move and execute the exe from 2012 to 2022 Windows server as is without any intervention? I want to add, most of the code are 20 year old and were developed and built in much older Windows environments to begin with, so all of them are compiled as 32-bit then and are still being executed in production in the same manner.

------
2) There is a need to convert few processes to Windows service. For the windows service programs, in continuation to the discussion we had for the problem faced during dll call - will it work, if we add the called dll source to the windows service project so the base and the called code will be compiled, built together? I believe in this way, it is easier to test run and debug as all related code are integrated into the same project. Please let me know your thoughts.

------

Thanks & Regards,

Kavitha.

------------------------------
Kavitha Natarajan
Fidelity Information Svcs Inc
------------------------------

Hi Kavitha,

I have responded to your questions in the support case.

How you migrate your code from earlier product versions is really dependent on what those programs do and how they need to be shared. For your service programs, since the service itself is in .NET managed code, I would suggest that the called subprograms are also compiled as managed code, but if these subprograms are shared between other parts of your application that are being compiled as native code, then that might not be possible. I have attached a file called WS9new.zip to the support case that demonstrates how you might set up an all .NET managed code solution which contains multiple projects. The first project is the service itself. That should be left alone and other called programs should be placed into a separate project within the same solution. You can add a project reference to the service project that point to the subprogram project and then programs within the subprogram project can be called from the service project.

 
If the subprograms need to remain as native code, then you can call them from the service program but all of them including the FM-SEM.cbl should be packaged together in a native project that is part of the same solution. That way only the service itself is managed code and everything else will be native. The way you do this really depends on what your requirements are.

Thanks

Hi Chris,

It was long holidays here, apologize for the delay in response. 

Thanks for your detailed suggestion. I will go through all your points, get an understanding and will work on how my migration project can be planned and executed. I will get back in case of any further queries.

Thanks & Regards,

Kavitha.

Hi Chris,

I have been adding the dependent subprograms to the service project, so they are all compiled and built together to avoid runtime environment mismatch error. In one of the subprogram (native COBOL), this statement is present and do not have any issue during compile or run

    CALL X"91" USING X91-RESULT X91-FUNCTION     
                      X91-PARM             
                      RETURNING X91-RESULT.

But when this program is added to Windows service project (.NET Framework), below compile error is thrown

OO: Method/Function 'CBL_X91' does not have a RETURNING clause defined 

Can you please suggest a workaround for this issue?

Thanks,

Kavitha.

Hi Kavitha,

Please create a new thread on this forum for any new questions you may have. This thread is getting quite long, and adding new questions to it makes it harder to search for specific posts.

If you look at the documentation for the X"91" calls you will see that there is no returning clause defined. The X91-RESULT data-item is passed in as a parameter and the result will be returned in this parameter without a returning clause.

Simply remove the returning clause from the call and the compile will be successful.

Thanks

Thank you Chris!

I was having doubt - the value passed, if changed in called program will get reflected once control is back to main program (when RETURNING is not used) as we were using the value of X91-RESULT further down in the calling program. I tested this and also based on your confirmation, that the value changed in called program does get reflected in the calling program, I went ahead removing RETURNING clause. 

Any next discussion, I will open in a new thread.

Thanks & Regards,

Kavitha.