Rocket® COBOL

Hi,I have found a changes in behaviour with the sql disconnect function between native COBOL (using ODBC) and .NET COBOL (using ADO) and was wondering whether these are deliberate or notScenario: I have a primary SQL connection ‘MAIN’ which is used for the majority of processing. However I have two other connections ‘ADMIN’ and ‘ALTERNATE’ which are used to perform elevated functions (ADMIN) or functions which I want disconnected from main (ALTERNATE)In native COBOL when I disconnected from one of these secondary connections it automatically reverted to the MAIN connection however in .NET COBOL this is not the case and I am finding I need to issue a ‘set connection’ .Also in native COBOL when the connection is closed it physically kills the connection to SQL - i.e. the SPID is no longer active. In NET COBOL whilst the connection is logically closed I see that the SPID still exists in SQL.  Are these changes deliberate? Peter 

Let’s address  the AI-lephant in the roomHi everyone, Welcome to our monthly Rocket ACUCOBOL newsletter. This edition tackles the biggest question of the month (or maybe even the year): How is GenAI changing ACUCOBOL modernization?Code Translations vs. Modernization:What’s the difference This week, COBOL made headlines again as the debate around AI‑generated COBOL resurfaced. The market reaction and the conversations online point to one thing: change is no longer coming. It’s here.Though after more than 5,000 successful COBOL and ACUCOBOL modernization projects across all the industries, we’ve learned one lesson that matters now more than ever:Code translation is not the same as software modernization. And confusing the two can put enterprises at real risk. Code Translation Is Useful. But Language Isn’t the ProblemMany AI companies promise rapid “COBOL modernization,” but what they’re really talking about is syntax translation. And while COBOL is a straightforward language (ask any COB

Our Cobol apps run natively on a Linux host with just local logging files, and I was wondering if there is any documentation on emitting (Opentelemetry) traces to an external collector (via network).If not natively supported, maybe people have some other ideas how to bridge the gap? Maybe building some integration via “Consolidated Tracing Facility” (CTF)?Thanks for any idea!Tung

This pertains to the use of external filehandlers, where my COBOL class is compiled with CALLFH"abcdef", which in tern needs to call fh/aaaaaa.dll which exists in the sub folder fh.The COBOL has :CALL “fh/aaaaaa” using ………During animation I debug the class, debug abcdef, but when it gets to the CALL “fh/aaaaaa” it doesn’t raise an exception but doesn’t execute the code either.I can see from procmon that the assembly was indeed loaded as well as the .pdb but just ignored almost as though it was looking for the programid but that didn’t match.Is this not supported?Is there an COBOL .NET  replacement for COBPATH ?Neil 

​​​​​​I am currently launching a Python script from RM/COBOL with CALL SYSTEM. Seems there is some overhead associated with SYSTEM, I am looking for a more efficient method.  Are there any alternatives recommended? 

I am trying to call non-static Java methods from an executable file since static methods work fine in this environment.  I can accomplish this using cobjrun but it seems like the $java$ is not resolved correctly without cobjrun.I have tried adding all mf*.jar from the VisualCobol/lib directory into my CLASSPATH before execution but always get a load error similar to the following:Load error : file '$java$JavaCalculator'error code: 198, pc=0, call=1, seg=0198     Load failure Here are the files that show the failure:natcobol.cbl       $set ooctrl(+p-f)       program-id. natcobol.       class-control.          claJavacalled is class "$java$JavaCalculator".      * The above maps the Java class 'JavaCalculator' to the COBOL class name 'claJavacalled'       working-storage section.        copy "javatypes.cpy".           01 hCla            object reference.           01 l1              jlong value 10.           01 l2              jlong value 5.           01 retl            jlong.           0

We would like to open a PDF file in the program and extract an attachment (in this case, an XML file) from this PDF file.Is there a way to do this?

Hi,I am posting this question on behalf of a customer, to ensure it goes to the relevant forum and a place they they can see the post. Once I post this I'll share the link with the customer and ask to reply/comment here also.They ask:Does somebody know how to translate the following C#-Lambda-Command to Visual Cobol ?Example (the second last line):private void FlexGrid_Load(object sender, EventArgs e){string conn = Util.GetConnectionString();var ds = new DataSet();string[] tables = "Customers, Orders".Split(',');foreach (string tableName in tables){Util.FillTable(ds, tableName, conn);}// Defining relation between master and detail gridds.Relations.Add("Customers_Orders",ds.Tables["Customers"].Columns["CustomerID"],ds.Tables["Orders"].Columns["CustomerID"]);flexGrid.DataSource = ds;flexGrid.DataMember = "Customers";flexGrid.RowDetailProvider = (g, r) => new C1FlexGridRowDetail();flexGrid.AreRowDetailsFrozen = false;}}They have used the C# to COBOL convertor website but the code that

Currently our ACUCOBOL (compiler v.10.3.1) print modules use WIN$PRINT to create PDF files using locally installed PDFCreator (on the user’s Windows machine) and -P SPOOLER.  We are looking for an alternate solution which will enable us to use a PDF printer installed on the Linux server instead.  All the options we’ve explored so far, incl. cupspdf; C$PDF and -P PDF involve extensive code changes or loss of predefined formatting.  Is there a solution available which will allow us to do the conversion with minimal code impact?

Good morning.I'd like someone to explain how the cobutf8 utility works to see if we can use it in our company.We work with Microfocus Visual COBOL 8.0 for Eclipse (Unix/Linux).The database is Informix, and a few years ago we migrated to the UTF-8 locale.The OS has LANG=es_ES.UTF-8.However, some integrations with other companies require files with a fixed position structure. We've found that with UTF-8 encoding, there's a left shift for each UTF-8 character written. Currently, we've added calls to iconv before each move to the file variable, but that's very cumbersome when the file has many fields.

The following code crashes when it is executed within Visual Studio 2022: CALL GetCurrentDirectory  USING BY VALUE     PC-PATH-LENGTHBY REFERENCE CURRENT-PC-DIRECTORYRETURNING iRetEND-CALL.it fails with the error message: 173     Called program file not found in drive/directory: GetCurrentDirectoryAI updated the PATH variable to include the folders where the COBOL runtime exists. So why does it not find the Windows API function? Is this a limitation of the PE version or some other property to build has not been set correctly? Any help is appreciated. Kevin

Hi ,we works with Micro Focus Visual cobol 8.0 for Eclipse on linux/UnixWe have a program  with a file that we defines so:file-control.     select prevcob    assign to wk-prevcob     organization is line sequential.data division.file section.fd prevcob.01  reg-prevcob               pic x(185).and a working variable that defines the file structure as follows:01 wk-reg-prevcob-pru.    10 prevcob-nombre-pru            pic x(40)      value spaces.    10 prevcob-impdivisa-pru         pic 9(16)v99   value 0.    10 resto                         pic x(127).We define a cusor that obtains data from a database with UTF-8 locales in Informix and passes it to the variables of the working (the host variable are defined like pic x(300) and pic s9(16)v9(2))move clinombr                    to prevcob-nombre-prumove srvimpdivi                  to prevcob-impdivisa-pru we write the file as follws:write reg-prevcob from wk-reg-prevcob-pruThe problem is that when field prevcob-nombre-pru contains a utf8 ch

Is there any documentation on help in converting from Fujitsu COBOL to Visual COBOL? 

After installing the Visual COBOL PE, a took a utility program written in Fujitsu COBOL, to see how much of the source would or would not compile. There were few lines of code in the utility program that did not compile and I changed and/or deleted them so as the original source compiled successfully. However, the source included the COPY WINDOWS statement and that is where the majority of the errors occurred when compiled the windows.cpy file! My first thought was that the original source was to blame. I subsequently took the COBOL source template  file that is created when a new project is started. Below is the contents of that file:         identification division.       program-id. Program1.       environment division.       configuration section.       data division.       working-storage section.       COPY WINDOWS. *> pick up Windows defines       procedure division.           goback.       end program Program1. The above code produced the same errors in the windows.cpy file.

I have requested to download Visual COBOL Personal Edition, but I have not received an email or reply to download Visual COBOL Personal Edition. What should I do so that I can download Visual COBOL Personal Edition?

I am attempting to pass binary data from AcuCOBOL to a .NET method using a COMSAFEARRAY.  For example, the buffer parameter in the below .NET method:public int addRow(byte[] buffer);I am receiving a COM error when I call this method passing the COMSAFEARRAY.   If I use other data types like “string”, I do not have the error. Does anyone have any suggestions of how to pass data from acuCOBOL as a .NET byte array?

I got a new Windows 11 workstation, and moved my AcuCobol software over and reinstalled it.   It’s been running fine for the past 3 weeks.  But now when I try to compile with ccbl32.exe, I get an error:“D:\Program Files (x86)\Micro Focus\extend 10.4.1\AcuGT\bin\zlib.dll is not designed to run on Windows ….”With the help of Windows COPilot, I tried all sorts of test and security changes, but it still does not work.  Apparently  zlib.dll is on the list of DLLs with known vulnerabilities.Is there updated 10.4.1 that have been properly signed, or do I have to go to Extend 10.5 ? 

Recently went to Window 11 64-bit system on a new computer.I have a program that writes and read Outlook emails, which began giving me errors.I used to executed "C:\Program Files (x86)\Micro Focus\extend 10.4.1\AcuGT\bin\wrun32.exe” which was the 32-bit version.   So i switched to  "C:\Program Files\Micro Focus\extend 10.4.1\AcuGT\bin\wrun32.exe” and the problem went away.   YAAAA.So my software uses the old MSCAL.OCX Calendar control.  Well it turns out it’s a 32-bit program, and WILL NOT EXECUTE using the 64-Bit version.    Anyway interesting to note the both in "C:\Program Files\Micro Focus\...” and C:\Program Files (x86)\Micro Focus\….” the runtimes are named WRUN32.    Shouldn’t the one of them be named WRUN64  ?Any thoughts ?? 

I’m very pleased to announce the availability of RM/COBOL® 12.21.This latest AMC product release enables our COBOL developers to build, deploy and modernize existing RM/COBOL applications using the latest technologies and operating environments.Key Release Highlights include:Support added for a 64-bit Relativity Designer and Relativity DBA. Support added for a 64-bit Relativity Data Manager on Windows. Relativity Designer enhancement RMNet support for redirectionFor a full list of product updates, please see the product release notes. This latest release of RM/COBOL is now available for order within Sales Force.  Existing on-maintenance customers may also download the latest version from the Rocket Software Customer Community.  RM/COBOL 12.21 provides important maintenance updates for critical COBOL business systems and carries with it our commitment of continued support for RM/COBOL users and their core business applications.If you have any questions about this product release, please