Old COBOL app move to new server

We have an old ProLiant ML370 server (10-15 years old) running SCO (version yet to be confirmed), with a single bespoke Cobol app. The server is failing and I need to get the app up and running on new hardware or cloud.

I've supported ProLiant servers running Windows for many years but have almost no knowledge of SCO/Linux/Unix, let alone Cobol.

I'd be grateful for an idea of where to start here. I need to know what I need to be aiming for, e.g. will I likely be able to run the old Cobol app on a modern flavour of Unix or will I need to stick to the original SCO version? How much work is likely to be involved in getting the app working?

The app is an old green screen terminal style, accessed via telnet and terminals.

Do you have the cobol source code?

An idea might be to use for example VMWare and perform a P2V and put it in a VM.

Someone in this link apparently did that in a situation that may be similar to yours..
https://communities.vmware.com/docs/DOC-18673

Or perhaps migrate to a different Cobol that runs on Linux?

We are trying to track down the developer. Its very likely the source code will be on the server though, which I should get access to tomorrow. How can I identify the source code?

---------- Post updated at 10:48 PM ---------- Previous update was at 10:38 PM ----------

Thanks, I'll read through that thread now. Migration to Linux sounds good to me, I just don't know the feasibility and would need some advice. I wonder if anyone can suggest the best forum for questions relating to Cobol?

I have moved both RM cobol and Microfocus cobol to GNUcobol on Linux. Alternatively you could run a regular install of openserver 6.0 on recent hardware.

---------- Post updated at 09:49 PM ---------- Previous update was at 09:11 PM ----------

You can determine the version of SCO by

 #uname -X 

and show any patches etc by

 #custom 

MicroFocus cobol is usually installed in /opt/lib/cobol, and there should be a /usr/bin/cobrun. The source code usually has a .cbl extension, and the executables either .int or .gnt. If you have the full compiler installation, you should also have a /usr/bin/cobol, and a /usr/bin/anim. MF cobol is copy protected so you need the original license code in order to move it to a new disk. For RM cobol, there should be a /usr/rmcobol directory, and a /usr/bin/runcob or runcob85.

OK, so here are the server details...

# uname -X

System = SCO_SV
Node = ******
Release = 3.2v5.0.6
KernelID = 2000-07-27
Machine =>PenIII
BusType = ISA
Serial = ******
Users = 15-user
OEM# = 0
Origin# = 1
NumCPU = 1

and...

# custom

Compaq Extended Feature Supplement (ver 5.48a)
SCO OpenServer Enterprise System (ver 5.0.6j)
SCO SendMail (ver 8.11.0)
SCO Skunkware 2000 (ver 2000.1)
RS506A: Release Supplement for SCO OpenServer Release 5.0.6 (ver rs5
RS506A: Software Manager Supplement (ver rs506a)

And the Cobol installation...

/usr/rmcobol
/usr/bin/runcobol

There is a separate folder in the developer�s name full of .cob files which I presume is the source?

And there is a folder that looks as thought it contains the app and data.

So if you had to purchase a server for this and migrate the app, what OS and Cobol route would you go? My initial thought would be to keep things as similar as possible and stick with OpenServer and RMCobol, unless there is any advantage to move away from it?

Unfortunately, the .cob files are compiled files that can be used with a runtime system.
To determine if you have the source code can you select one of the .cob files and, supposing that you have an ARX100.cob, do, signed on as root

find / -name "ARX100*" -print

If you find any files that match, then presumably these are the source code.
If you do not have the source code, then your options are limited to a VMware install, or a normal install of 506 on suitable hardware.
Suitable hardware being an I3-I7 system with an SSD disk, as long as the motherboard was manufactured in 2012 or earlier.

---------- Post updated at 08:58 PM ---------- Previous update was at 08:27 PM ----------

If you want to use later hardware, then you have to upgrade to Openserver 6.0.0.
If you find that you do have the source code, then you could migrate the application to Linux, my preference is Opensuse, as it seems to have the same look and feel as SCO. Converting to GNUcobol requires about 1 hour of conversion effort per Cobol program.

Even if you find that you don't have the source code, you may be able to purchase a suitable run time system from Microfocus, the current owners of RM Cobol, and move the application either to Windows or Linux.

Thanks for all you help jgt.

Hopefully I've now found the source in a folder called "s", with most of the files having a ".c" extension.

I'll discuss the options with the decision-makers.

One last question if you don't mind. When you say a pre-2012 motherboard, what technology should or shouldn't it have? And any specific reason for the SSD?

Hi.

If you are dragging over data from the old environment, you may be interested in some free utilities at freestuff from UV Software

If you like the free stuff and need more for conversion, see the home page at Vancouver Utilities for Unix, Linux,& Windows for the commercial software.

In particular, the conversion aids may be of use: CNVaids.doc - Mainframe JCL/COBOL/DATA Conversion Aids [libcnv]

I have downloaded the free items, and where I tried them, they worked. However, I don't have any projects that need such tools right now. I have no connection with UVSoftware other than exchanging a few emails with the developer.

Best wishes ... cheers, drl

Disclaimer: I have not used or installed 506 for at least 15 years.
For the most part I have used Intel mother boards. I had no problem installing 600 using DH61DL boards until version 206. At one point in 2012 I had 5 of these boards, some 203,204 and 205. When I tried to install 600 on the 206 version, the screen looks like this.

There is a patch for this, that replaces the boot cd for 600, and just loads a kernel, and starts custom. From there, the operating system is installed using the regular cd. I have not tried this with either 507 or 506.
As far as I know there is not an AHCI driver for 506 so the mother board bios has to support the sata controller in compatible ide mode.
I have been using the Intel XPI9400PT network card, but it is no longer available from Intel. It is available from addoncomputer.com.

Hello Mobble.
Reading your post's i see that your OS is Openserver 5.0.6
and Cobol system is RmCobol85. I am a cobol developer
since 1980 and ex Hp / Sco reseller and system administrator.

My problem was the same and Openserver 6 was unwanted.

My solution (for myself and all my customer) is to migrate
Os, Apps and Data to a virtualized environment using Virtualbox
(but with Wmplayer is the same).

Unlucky the SCO filesystem (Htfs) has no support or driver for
Windows/Linux, so the only way to migrate data and apps is FTP.

More, Virtualbox runs Openserver 5.0.7 very fine (5.0.6 is well know
to have a lot of bugs) but the original Cd is required to do a new
installation over the virtual hard-disk (and the license key, of curse).

I create a new VM (generic unix/linux) with 2 GB ram (this depend on
your hardware and how many users will login to the virtual server,
usually 4/8 gb are good). Virtual Hard disk kind IDE.

Starting from original Sco CD the OS was installed, then activated
(with original license key)

Sco Login (graphical desktop) disabled , only text console (as root: scologin disable)

Using FTP all Apps/Data/Homes directory copied from real server
to virtual machine.

More: instead of copy all into the virtual disk, you can map a Linux
folder with NFS into SCO, be aware that SCO 5 only support NFS V.3

Sco 5.0.7 give good support to usb, can format and mount pendrive
(for data migration and backup), and Usb Tape Drive.
Printers configured all as LPD queue

At end my customers with Putty Telnet open the same old login as
always. They don't see any difference between old real server and
the new one virtualized.

Simply, well working, at lowest cost.

Enjoy.

Bye

I can suggest you to take a VMWare Converter or any other similar tool and take a backup from your server as a first thing to do.

You can deploy it then, and try to recreate your Cobol app environment then without any rush.

If you try to do that without original server or it's virtual copy then you didn't have any right to mistake