VS2013 / VC 2.2
I know how to have a Native program CALL another Native program (a traditional CALL).
I know how to have a Native program INVOKE a Managed Windows program/app (CCW/COM Interop).
What I can't figure out is how to have a Native program CALL? / INVOKE? a Managed Console program.
Would like to see an example.
Thanks
You can do the following:
01 WS-TEST pic 9(5)v9(2) value 13.5.
01 WS-NUM3 pic S9(3)V9(2) VALUE -123.45.
01 WS-TEST-2 pic 9(5).9(2) value 13.5.
01 WS-NUM3-2 pic ---9.9(2) VALUE -123.45.
display WS-TEST.
display WS-NUM3.
display WS-TEST-2
display WS-NUM3-2.
Results would be:
0001350
12345-
00013.50
-123.45
Or you can write:
01 WS-TEST pic 9(5)v9(2) value 13.5.
01 WS-NUM3 pic S9(3)V9(2) VALUE -123.45.
01 WS-TEST-2 pic 9(5).9(2).
01 WS-NUM3-2 pic ---9.9(2).
move ws-test to ws-test-2.
move ws-num3 to ws-num3-2.
display ws-test-2.
display ws-num3-2.
Results would be:
00013.50
-123.45
Thanks Ferda.Tanyeri.
But could you show me the reason ?
The reason is simple: Any numeric variable with a virtual decimal sign "v" is for calculations only. The data is stored without any decimal point position. So the value 12345 is stored just like that. The actual value depends on the programmer who determines the position of decimal point. You can define a variable as 999v99 in one program and as 99v999 in another program. When you read the data from a file in the first case it will be 123.45 in the second 12.345. THE DECIMAL POINT POSITION IS DYNAMIC AND FOR CALCULATION ONLY.
However declarations such as 9(3).9(2) or ----.99 are formatted and for display purposes. Here is the decimal point position STATIC, i.e. it is fixed.
I do strongly believe that back in 1950's and 1960's, when the cost of storage devices were extremely high, COBOL developers wanted to save every byte possible. With dynamic decimal point positioning, on every decimal value they saved one Byte. I think thats the reason why it is working this odd way.
I think Cobol should do an intelligent conversion to the display format with setting a decimal point at the correct position. Defining the variable with comp-3 gives the same result. Display of a variable defined as decimal gives a correct result. But for the moment you cannot use Cobol arithmetic verbs with decimal; you can use the Set command. I have an open support case for that.
Who have programmed in Cobol a Integration of novell now MicroFocus Groupwise (the better email/collaboration) and will Exchange his experience and source code?
thanks for you interest and help
Hi.
Recently, i code a test program as below :
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-TEST PIC 9(5)V9(2) VALUE 13.5.
01 WS-NUM3 PIC S9(3)V9(2) VALUE -123.45.
PROCEDURE DIVISION.
DISPLAY WS-TEST.
DISPLAY WS-NUM3.
STOP RUN.
When i run by ctrl + f11 then the result in console command is :
0001350
12345-
But when i run this project on OpenCobolIDE then result is correct :
00013.50
-123.45
Plz help me.
"I think Cobol should do an intelligent conversion" this may require a time machine to change the way standard COBOL operates :-) And to answer a poster from above, yes, COBOL does it like this to save every byte as storage was very very expensive way back then.
The DISPLAY verb merely dumps the data-item to the SYSOUT without and regards for data-type. It will quite happily display the bytes from a BINARY (COMP) or PACKED-DECIMAL (COMP-3) data item.
When handling numeric data in COBOL you always need to format numerics before any output whether with DISPLAY to SYSOUT, to a screen, a report file, an XML file, a CSV file, etc, etc.
A data item defined as PIC S9(5)V99 takes up 7-bytes of storage with an implied decimal point and the sign stored in the trailing high-order half bytes unless defined with a SIGN SEPARATE clause. E.g. -0.01 would be ASCII x30303030303071 (IIRC) and would display as such. To get it to display formatted move it to a formatted data item first e.g. PIC -(4)9.99.
Whilst a PIC S9(5)V99 does have an implied USAGE DISPLAY clause it should not be taken literally.
Also, it should be noted that usage display data item shouldn't really be used in mathematical operations or as subscripts. COBOL will quite happily let you do it but, to use a term from other languages, you will incur a type conversion upon each use of the data item (again this is from the old days when processor speed was at a premium and any assembler instructions you could save were worth it - but the principle still applies). So the above data item would be better stored as PIC S9(5)V99 USAGE PACKED-DECIMAL which would be 4-bytes. E.g. -0.01 would be ASCII x0000001D and should be moved to a formatted data item before output.
Chris, thanks for your reply. I will try to answer your questions and explain myself better below:
Say that I have an existing native COBOL program named TEST1 and from it I want to CALL or INVOKE a new program named TEST4. And TEST4 will be the type described below. Assume both executables will be in the same directory.
When I go into VS and say I want to create a new project and I then highlight Managed in the [Project Type] pane on the left and Console Application in the [template] pane in the middle. Then after it creates the new project (say TEST4), I go to Properties and change the Output type from Console Application to Class Library so that it will create a DLL instead of an EXE. I do this because I am under the impression that you can't really directly CALL or INVOKE an EXE from another COBOL program, it has to be a DLL if you are going to CALL it or INVOKE it. If I am wrong on this, please let me know.
The resulting "program" is not a class - it is a procedural program with some version of the Net Framework as the Target framework. The skeleton "Program1" code that it creates is a simple procedural type and not a class.
However, I can't seem to simply / directly CALL this "Managed Console" program (changed properties to a DLL) from a Native COBOL program like I would CALL a Native program (DLL) from a Native COBOL program. It falls through the CALL and doesn't even give me an exception.
I know that I can treat this situation similar to a situation where I wanted a Native COBOL program to INVOKE a Managed Windows Forms Application (which I changed the Output type to Class Library). In other words, create and bolt a Class1 onto this new program and follow the steps similar to the CCW / Com Interop examples. And then once in Class1, I would CALL "TEST4.Program1" since it was procedural. This works, although using the AssemblyName.ProgramName in the CALL is a bit new and strange.
Seems like I should be able to just simply and directly "CALL TEST4" in/from TEST1.
Clear as mud?
Thanks
Hi,
I would like to invite you to join the COBOL Analyzer forum where you'll find information on this new exciting offering from Micro Focus.
Designed for Micro Focus COBOL applications, COBOL Analyzer enables developers, analysts and management to achieve a deeper understanding of their application portfolios providing both business and technical insight.
In the forum, you'll find links to product videos, getting started tutorials and code samples.
You are also most welcome to visit our product page to explore the different resources, download your free evaluation copy and understand how COBOL Analyzer can help you deliver higher quality COBOL applications, faster!
Thanks,
Guy Sofer
Product Manager
Unfortunately in order to call a managed code .NET assembly from a native COBOL program you must go through the CCW Interop layer which involves registering the managed assembly for COM interop. If you wish to call a managed procedural program from native then you will have to create a managed wrapper class that you can instantiate and then call the managed COBOL program from this.
There is a 3rd party extension for Visual Studio that will expose managed methods as native entry points if you decorate them with the appropriate attributes but this currently does not work right out of the box for Visual COBOL. This technology can be downloaded here:
If this is something that is of interest to you let me know and perhaps we can work on getting it to work with your application..
OK, well now I know. Since we are already relatively comfortable with the CCW COM Interop approach (as we already have a number of Native COBOL programs calling managed Win Forms COBOL apps), we will just do it that way, which is the way you suggested. Thanks.
Wh have a problem in our test Environment for batch as we have several databases and the same programs executes on all of them.
As soon as one person compiles and binds a program to one database you get a -818 when trying to execute it on a different database.
This generates lots of rebinding and we would really like to get rid of this problem.
Maybe the REOPT ALWAYS option could solve it but is there another way?
Anyone who can point out the direction where to find a solution to this problem?
regards
PI
Can you explain a little more. Where is the HELLO-PAR paragraph?. In MAIN or in SUB?
HELLO-PAR is written in MAIN. And in SUB i want to use HELLO-PAR again .
No, you cannot do that. In this case you have to have MAIN, SUB1 and SUB2. Your old SUB is here SUB1 and SUB2 is a new program you have to write containing HELLO-PAR. This way the code for HELLO-PAR is written once, but can be called from MAIN and SUB1.
Thanks for your reply.
By the way, I have other example.
My project have many files (MAIN.cbl, SUB1.cbl ...) which use COBOL interact with DB2. In each file, must check error sql as below :
CHECK-SQL-ERROR-PAR.
IF (sqlcode not = 0)
DISPLAY "Error: SQL error"
DISPLAY sqlcode
END-IF.
If write this code in SUB2, how to call SUB2 and passsqlcodefrom MAIN or SUB1 ?
Place the common code required by both MAIN.cbl and SUB.cbl in a copybook and include it in each program using a COPY statement.
e.g. COPY COMMONCODE.CPY.
If the common code contains EXEC SQL statements you will need to include it rather than copy it to make it available to the SQL pre-compiler.
e.g. EXEC SQL INCLUDE COMMONCODE.CPY END-EXEC.
Hi everybody.
I have 2 files as below :
1. MAIN.cbl
2. SUB.cbl
In MAIN.cbl :
+ CALL 'SUB'.
+ PERFORM HELLO-PAR.
HELLO-PAR.
display 'HELLO EVERYBODY'.
In SUB.cbl : I want use HELLO-PAR paragraph and don't want code again it. I try to PERFORM HELLO-PAR but have error.
How do this ? Plz show me. Thanks !
MAIN.cbl:
working-storage section.
01 ws-sqlCode pic xxx.
call 'SUB2' using ws-sqlCode.
SUB1.cbl:
working-storage section.
01 ws-sqlCode pic xxx.
call 'SUB2' using ws-sqlCode.
SUB2. cbl.
linkage section.
01 sqlCode pic xxx.
procedure division using ws-sqlCode.
display 'Error, sql-code =', ws-sqlCode.
exit program.