I am doing evaluation to see if Micro Focus Visual COBOL for Visual Studio can be used to replace the native COBOL development using IBM TSO environment within my company.

I had download a trial version of Visual COBOL for Visual Studio (2019 version), and watched the six Webinar videos on OOP in the Micro Focus resource link. I managed to use the same test data on my desktop with no issues.

I am sure the questions that I have in mind had been asked by someone else before, it will be much appreciated if someone out there can direct me to some previous Q&A links related to my questions.

Most of the COBOL programs my company use are for BATCH process: These programs are developed using IBM TSO environment, and some had been in use for decades; they are run on predefined schedules on IBM Mainframe computers; they use lots of INPUT and OUTPUT files; they access to IBM DB2 relational database for all sort of data manipulations.

My questions are:

Can Visual COBOL for Visual Studio create executables that can be run on an IBM mainframe computer? And can the converted program be mixed in predefined batch schedules with other COBOL executables developed in native COBOL using IBM TSO environment. (that could happen if conversion is planned for multiple phases).

How executables 'Published' by Visual COBOL for Visual Studio handle INPUT and OUTPUT files?  

How Visual COBOL for Visual Studio reference COPYBOOKs?

Can Visual COBOL for Visual Studio access IBM DB2 relational database?

Can I just copy and paste an existing native COBOL program into Visual COBOL for Visual Studio and compile it, or the program has to go thru a conversion process before it can be compiled?

Thank you in advance for anyone who can help. This is my first post, and hope that I post it in the right place.

Best Regards from Stan222

Hello Stan,

Good to hear you are  evaluating Visual COBOL. I will answer some of your questions below. You might also be interested in the Micro focus Enterprise Developer product. This is a companion product to Visual COBOL and as well as having all the features Visual COBOL offers for both Visual Studio and Eclipse it also comes with all the support to allow IBM mainframe developers to develop and test applications off the mainframe and have them behave in exactly the same way as they would if being tested on z/OS. So this includes support for COBOL, PL/I and Assembler, JES, CICS, IMS TM, IMS DB and a DB2 Emulation. We also provide a mainframe access component to allow to integrate directly with the mainframe whether it is developing on the host from a modern IDE or having access to remote data or a graphical UI for quickly transferring source and data down to the Windows environment.

We are just in the process of launching a trial version of Enterprise Developer (Eclipse or Visual Studio) which will be available in the next 2 weeks or so through the Microsoft Azure market place. This will give you access to Enterprise Developer and the free essentials web based training we provide to get you started.

To answer your specific questions

Can Visual COBOL for Visual Studio create executables that can be run on an IBM mainframe computer? And can the converted program be mixed in predefined batch schedules with other COBOL executables developed in native COBOL using IBM TSO environment. (that could happen if conversion is planned for multiple phases).

Micro Focus response : No this is not the case. Executable created under Visual COBOL or Enterprise Developer can run on all our support (Windows, Linux and UNIX) platforms – this does include LinuxOne but you cannot take a built executable under a Micro focus environment and run this back on z/OS. You can however debug and test this under the Micro Focus environment and have it behave in exactly the same way when it executes as it would do on the host but you would need to move this back to the mainframe and recompile there for pre-prod testing and deployment.

Alternatively with our Enterprise Server product we do provide a production server that allows you to move mainframe workload onto an alternative platform or the cloud. We have many customers worldwide that have done this successful alreadty

How executables 'Published' by Visual COBOL for Visual Studio handle INPUT and OUTPUT files?  

Micro Focus Response : We might need a little more information here but if you are using Enterprise Developer then this provide support for the JES environment so you can execute applications using JCL and we have an emulation of a mainframe catalog

How Visual COBOL for Visual Studio reference COPYBOOKs?

Micro focus Response :  This might also depend on the context but within Visual Studio for both Visual COBOL and Enterprise Developer you can specify a dependency path where the Micro Focus compiler searches for copy books referenced in the program. This could be in the project directory on a search path where you maintain a central copy of shared copybooks or with Enterprise Developer on the mainframe with an SCCM system if you have the product configured that way.

Within the editor once the copybooks have been located (part of a background parse process) then these can edited inline or as separate artefacts

Can Visual COBOL for Visual Studio access IBM DB2 relational database?

Micro focus Response :  You would need the Enterprise Developer product for this. It comes with its own very compatible DB2 emulation for Windows which allows you to maintain and access DB2 data locally (unloaded from the mainframe and reloaded into the Enterprise Emulation) so you can test as developer in isolation. Alternatively you can access DB2 remotely on the mainframe from the Enterprise Developer IDE.

Can I just copy and paste an existing native COBOL program into Visual COBOL for Visual Studio and compile it, or the program has to go thru a conversion process before it can be compiled?

Micro focus Response :  No conversion process would normally be required outside of the conversion to an ASCII code page when you move this from the mainframe. This would normally be handled by FTP for example if you use this to move sources to and from the mainframe. Obviously if there are copybooks you will need to have those available if you are not accessing these directly on the host. There are some exceptions – if for example you have EBCDIC literals in your code then these can cause some issues.

However with Enterprise Developer using the mainframe access components you can very easy drag and drop sources and copy books directly into the IDE from the mainframe and it will handle all the conversion process for you. You can even open the source module directly on the mainframe through the Eclipse based IDE. So you get all the benefits of modern development tools but without having to bring the source module down to the Windows platform.

Hopefully that provides you answers to your questions and would be happy to have a follow up call if you would like to find out more.

Eddie Houghton

Micro Focus Product Management

Eddie,

Thank you very much for your reply. I really appreciate it.

Does the Enterprise Developer for Visual Studio already include Visual COBOL for Visual Studio in it? Or I need both Visual COBOL for Visual Studio and Enterprise Developer for Visual Studio install on my desktop to work?

If the answer is I need both software installed on my desktop to work, by the time I can get my hand on the trial version of the Enterprise Developer for Visual Studio, my trial period for Visual COBOL for Visual Studio will expire (or about to expire), since I had it downloaded and installed on 9/23/2019. Is there a way I can extend my trial period for Visual COBOL for Visual Studio?

You brought up a very interesting point. Let's assume that we will move some mainframe workload onto the "cloud". Would the COBOL programs developed using Visual COBOL for Visual Studio be directly executed (or ran) in the "cloud" (alternate platform) environment? Can these COBOL programs access our DB2 relational database reside on our own IBM computers at run time (not just during development or testing)?

Best Regards from Stan222

Hi Stan,

Think of Enterprise Developer as a superset of Visual COBOL - it has the same functionality as Visual COBOL but also includes all of the mainframe system support to allow to develop and test IBM Mainframe applications. You will only need Enterprise Developer on your machine rather than having both Visual COBOL and Enterprise Developer. So you could run an Enterprise Developer trail after the Visual COBOL one expires.

In terms of the running the COBOL applications in the cloud but accessing DB2 Data remotely - yes you could do this using the some of IBM tooling to remotely access DB2 on the mainframe with the COBOL applications running a Micro Focus server environment. This would probably warrant a conversation though as accessing data remotely in this way would clearly have performance penalty.

Hope that helps.

Thanks

Hi Stan,

Think of Enterprise Developer as a superset of Visual COBOL - it has the same functionality as Visual COBOL but also includes all of the mainframe system support to allow to develop and test IBM Mainframe applications. You will only need Enterprise Developer on your machine rather than having both Visual COBOL and Enterprise Developer. So you could run an Enterprise Developer trail after the Visual COBOL one expires.

In terms of the running the COBOL applications in the cloud but accessing DB2 Data remotely - yes you could do this using the some of IBM tooling to remotely access DB2 on the mainframe with the COBOL applications running a Micro Focus server environment. This would probably warrant a conversation though as accessing data remotely in this way would clearly have performance penalty.

Hope that helps.

Thanks

Since my last post, I created a few console applications using Visual COBOL for Visual Studio, tested out a few things, such as: include copybook from an external folder, call SOAP webservices (developed by VB.net) for simple type return values, and for dataset return values. All worked well.

Eddie Houghton in a previous reply mentioned that there will be a trial version of the Micro Focus Enterprise Developer product available soon. I wonder if there is a DATE set for the release of this trial version?

Also what type of systems are required to install this trial version Enterprise Developer product?

Here are what I think I will be interested to do:

1. Migrate a few batch COBOL programs we currently run on IBM z/OS to Visual COBOL and run them as batch in the Enterprise Developer environment.

2. We currently have two DB2 database environments. One runs on IBM z/OS, and the other runs on DB2 LUW. I would like to see if the migrated programs can access to these two DB2 database platforms.

3. These batch programs will read from input (sequential) files, and output to (sequential) files.

Should I be using Visual COBOL for Eclipse (instead of for Visual Studio) since I will be testing the batch process?

Best regards from Stan

Just following up on this note as I'm in a similar position and have questions on the mainframe data files.  If the data file received by the developers are in EBCDIC and RDW format (variable) is there a way to convert them on the PC to ASCII I tried using the Data Convert tool but its not functioning correctly

Thanks

Just following up on this note as I'm in a similar position and have questions on the mainframe data files.  If the data file received by the developers are in EBCDIC and RDW format (variable) is there a way to convert them on the PC to ASCII I tried using the Data Convert tool but its not functioning correctly

Thanks

I found this source code in an old file.

Identification Division.
**************************************************************
*
Program-ID. Ebc2Asc.
*
Configuration Section.
*
Special-Names.
EBC is EBCDIC.
*
**************************************************************
Input-Output Section.
**************************************************************

File-Control.

select Input-File assign to "EBCDIC.DAT"
organization is sequential.

select Output-File assign to "ASCII.DAT"
organization is sequential.

**************************************************************
Data Division.
**************************************************************

File Section.

FD Input-File
code-set is EBC.
01 Input-Record pic x(40).

FD Output-File.
01 Output-Record pic x(40).

Working-Storage Section.

01 Ws-Eof-Input pic x(01).
88 Eof-Input value "Y".

**************************************************************
Procedure Division.
**************************************************************

0000-Main.
move "N" to Ws-Eof-Input.
open input Input-File.
open output Output-file.
perform 1000-Read-Record.
perform 2000-Process-Record
until Eof-Input.

close Output-File.
close Input-File.
stop run.

1000-Read-Record.
read Input-File
at end move "Y" to Ws-Eof-Input.

2000-Process-Record.
move Input-Record to Output-Record.
write Output-Record.
perform 1000-Read-Record.

I tried this code on the RDW file and its giving me an exception on the Read that its opening in the wrong mode.

18 Read part record error: EOF before EOR or file open in wrong mode: EBCDIC.DAT.

Yes I do have the Copy book for the file layout too.

Thanks

It's 30 years ago that I moved a load of EBCDIC to ascii I wrote a whole lot of bespoke programs then to take into account comp-3 and comp fields.

Hello All,

Its been awhile since I've worked with COBOL so excuse the dumb question on COMP-3 conversion here but I've searched and cannot find out why this is happening.

My File is EBCDIC

I read the record successfully and move the data to my layout.  The field is defined as

10 STMT-SALES-AMT    PIC S9(19)V99 COMP-3.

My WS section I have a field defined as 

01 WS-CONVERT-BINARY.
10 WS-NINETEEN-TWO PIC -9(19).99.

My Output field is

10 STMT-DTL-SALES-AMT PIC X(23).

My logic is as follows

MOVE STMT-SALES-AMT TO
WS-NINETEEN-TWO.
MOVE WS-NINETEEN-TWO to STMT-DTL-SALES-AMT.

This displays when printed 0000001867=83<00000.00 in my file it should display 0000000000000018878.04 

Thanks

I might be a bit rusty but you have moved a comp-3 to a displayable field why then move it to a pic x field. Just use the pic -9(19).99.

Hi

Yes I tried that too and its still giving me the same crazy output.   Am I missing a setting within Visual COBOL or something.

Thanks

I tried this out using the following:

$set sourceformat(free) charset(ebcdic)
01.
10 STMT-SALES-AMT PIC S9(19)V99 COMP-3 value 18878.04.

01 WS-CONVERT-BINARY.
10 WS-NINETEEN-TWO PIC -9(19).99.

01.
10 STMT-DTL-SALES-AMT PIC X(23).

MOVE STMT-SALES-AMT TO WS-NINETEEN-TWO.
display ws-nineteen-two
MOVE WS-NINETEEN-TWO to STMT-DTL-SALES-AMT.
display stmt-dtl-sales-amt

The DISPLAY statement seemed to produce the expected output.  I tried this both compiling to native code, and to .NET.  Maybe your original program does something a bit more complicated?

Hi

Interested to know where you do that setting Im using the Microsoft Visual Studio Community 2019 and the Visual COBOL Personal Edition

I changed some settings and got this  0000001887804Ü00000.00  vs.  0000000000000018878.04

COBOL dialect: COBOL for OS/390

Added this to the code

Special-Names.
Alphabet EBC is EBCDIC.

FD Input-File
code-set is EBC.
01 Input-Record pic x(1020).

If you're using the COBOL for OS/390 dialect, then charset(ebcdic) is set up automatically.  The effect is that all PIC X data etc. is held in memory as EBCDIC characters rather than ASCII.  You do not then need to specify:
Special-Names.
Alphabet EBC is EBCDIC.

I'm not sure how you get the result that you report in your most recent email, but probably we would need to see a complete program to understand what's going on.

Hi Guys,

I tried changing a few items but the output is still not correct for the COMP-3 values I've attached the source and project with some data to see if you guys can figure whats happening

Thanks

It looks like the input data doesn't align correctly with the record structure.  Everything is ok up to the comp-3 item IN-STMT-DTL-SALES-AMT, but doing a quick watch on that field (after reading the record) and flipping to hex mode I see: H"0000001887804C00000000".  The value 1887804C should be aligned on the right side of the field. 

Actually, I just realized this is because null characters are being stripped by default on line sequential input.  To stop this from happening, you can either create a configuration file (extfh.cfg) with the following contents:

[XFH-DEFAULT]
INSERTNULL=OFF

...or you can set the -N run time switch when running the program.

It looks like the input data doesn't align correctly with the record structure.  Everything is ok up to the comp-3 item IN-STMT-DTL-SALES-AMT, but doing a quick watch on that field (after reading the record) and flipping to hex mode I see: H"0000001887804C00000000".  The value 1887804C should be aligned on the right side of the field. 

Actually, I just realized this is because null characters are being stripped by default on line sequential input.  To stop this from happening, you can either create a configuration file (extfh.cfg) with the following contents:

[XFH-DEFAULT]
INSERTNULL=OFF

...or you can set the -N run time switch when running the program.

Thank You for your help I managed to get it working

Just out of interest how many records are the in the file?