2

We have an S/390 mainframe at my new job that’s been running COBOL applications since the late 90’s. The mainframe is getting old enough that we need to migrate to a newer system. We’re a small enough business that we can’t warrant spending the money to upgrade to new mainframe hardware and the program logic has been a constant work in progress for 30+ years, so it has a lot of functional value. I’ve been considering moving the functionality to a Linux machine and using something like OpenCOBOL to recompile as an executable binary instead of trying to rewrite it in a newer language. I haven’t messed with a mainframe enough to have any clue how or where to access this information and the gentleman that wrote all of the programs is unfortunately no longer with us. I’ve read that SSH is an option, but I’m not even sure how to get the ball rolling on that with a mainframe. I use Linux on a fairly regular basis, so I’m familiar with SSH, but from my understanding those mainframes aren’t a simple OS that you can merely connect to and navigate the file system to retrieve data like we can in modern operating systems. Can anyone give me some pointers to get a sense of direction for accessing the source code for the COBOL programs? Are there default locations that they are stored, etc.? They’re somewhat simple programs that don’t use any DB2 functionality and will hopefully compile on a different system with relatively minimal debugging and fixes. I’m certain that I’ve left out necessary information that would help getting an answer to this question, and I can provide any additional information that is needed to help you all help me. I suspect that SSH isn’t enabled by default, but maybe I’m wrong there too. Any assistance is greatly appreciated. Thanks everyone!

NateBrink
  • 103
  • 8
  • 1
    The question is rather broad since it goes down to the very basics of the mainframe OS. Maybe you best have a look at this redbook: http://www.redbooks.ibm.com/abstracts/sg246366.html - especially chapter 5 for a first overview. – piet.t Aug 24 '18 at 06:20
  • 1
    I'd very strongly suggest talking to a seller/reseller who knows something about mainframes and can help you. There are a variety of different ways you could upgrade your machine, and/or move the programs to a hosted environment, where you can keep the qualities of service you have now, for little cost. Moving things off of the mainframe tends to have a variety of negative consequences for the business, and often doesn't go well. Much more to the point, you need to get someone in-house who understands the mainframe. I'm assuming there's someone there who IPLs and applies service? – Kevin McKenzie Aug 24 '18 at 13:17
  • 2
    This topic would probably be more appropriate on Superuser.com – Hogstrom Aug 24 '18 at 13:22
  • I've only got the sources unloaded with FTP (try text mode, if possible, if the data doesn't look correct use binary mode and `iconv` to transfer the data), but was given the credentials - do you have a sysprog that handles the machine and its administration)? I'd say it heavily depends what you do with the mainframe, if it is only COBOL and a JCL to start it that no one touches you may can get it working fast, otherwise there will be more check when moving of the mainframe. – Simon Sobisch Aug 24 '18 at 17:23
  • 1
    As there is no risk in trying to compile the sources with GnuCOBOL I'd give this at least a try, you only loose minimal time for trying (for questions/bug reports use the GnuCOBOL discussion boards or mailing lists). If you downloaded the sources you may run a "complete" compilation: `cobc -std=ibm-strict -fmax-errors=9999999 -v -Wall *`. For questions about how to get the sources from the mainframe I suggest to ask at superuser.com or serverfault.com. – Simon Sobisch Aug 24 '18 at 17:30
  • There are competitively priced mainframe options, such as the new rack-sized z14R. However, someone/some organization needs to step in and assess what you currently have (you mention OS/390, so I suspect you are extremely back-level both in hardware and operating system), your current DASD (are they IBM DS7xxx or DS8xxxx units, or traditional controller/DASD strings). Any porting of code is going to be a long project, no matter which way you go. – zarchasmpgmr Aug 24 '18 at 21:09

4 Answers4

4

There is no default location where source code is stored on z/OS (it is z/OS you're talking about, right?). Source code is usually stored in PDS data sets. The naming of those depends on the installation, i.e. the company, and whether or not any software like Endevor, ChangeMan, etc. is being used to maintain the sources.

Since this is old z/OS (OS/390) COBOL code, chances are the code is making use of OS specifics such as record level I/O, VSAM data sets, etc. These are the parts that will not work on a non-z/OS platform without major rewrite. So, you will need to look into the sources.

SSH is available on z/OS, but it needs to be configured and enabled. You need to check with your z/OS sysprog. FTP, and NFS are other options, but again, they need to be configured and enabled.

Transfering the sources is the least of your problems, I'd say.

Hogstrom
  • 3,581
  • 2
  • 9
  • 25
phunsoft
  • 2,674
  • 1
  • 11
  • 22
  • Just in case you want to further extend your answer: if the load module was complied/linked with ChangeMan ZMF, then you can simply BROWSE the load module, and find the ChangeMan ZMF "package Id" and "SSI" (a kind of timestamp), to go hunting for the change package where the source was complied/linked into the load module you're looking at ... and even the compile/link listing from back in the days when all that happened. BTW, ChangeMan ZMF exists since about 1990 (when I first started providing technical support for it). – Pierre.Vriens Sep 12 '18 at 21:46
4

Although not a programming question I'll provide some guidance I think might help you.

First, this is a business decision about where to invest.

  • Do we upgrade the system to a newer model and upgrade some software and acquire the skills to keep the system running? (System Programming, OS upgrade and cost of migration, newer platform (used z13 could be an economical option, storage systems to support the mainframe)
  • Migration of existing workloads to other platforms. (Cost to migrate code, sizing of performance needs, new technologies to replace existing access methods like VSAM or dare I say ISAM if the applications are old enough)
  • Status Quo ... leave things where they are and keep the lights on

In evaluating any option you have to assess the risk to the business and what would a disruption cost? IMHO, its less about a technology like SSH or COBOL on Linux but requires some serious assessment of the current state, the acceptable to be scenarios and the cost of pursuing one of those options.

My comments are not intended to instill fear but provide a framework of how do I approach analyzing a challenge of this magnitude.

Hogstrom
  • 3,581
  • 2
  • 9
  • 25
1

I have to agree with the prior two answers, but have some additional suggestions. This is a business decision what to do on the system.

Finding the program to understand what it does is the first requirement. Since you know what program is running that may be the name of the source file. That you will need to find. The source file probably will be in some library manager, the first place to look is in the ISPF menu system. There will be an option for the library manager you are using if you are using one. Based on your description you may be using something called SCLM which would should up, or you might see Librarian or Panvalet. You will need to get into ISPF by connecting using a 3270 connection emulator. Once you find the file, using FTP or SFTP may be the best, or your emulator may just provide a transfer mechanism. You will need to find the related files as well, which should also be defined in the library manager.

Once you have the file, you will need to figure out what it uses as mentioned above, it will be working with some kind of data file, and that will be the biggest part to deal with.

If it is a batch program it is probably part of a schedule, and there are other programs also running that you will need to find and figure out how they fit together.

Once you have an understanding of all the parts then you can work to make the right business decision as to how this should be run. You may want to upgrade, you may want to look to getting z/OS as a cloud service if you don't want to upgrade but you want the function. Or it may be a simple program you could move. That will be much easier to figure out once you have the details.

Rosalind Radcliffe
  • 111
  • 2
0

You say the program logic has changing for 30+ years. Was it only one person making all the changes ? Would anyone on the team have some idea about the PDS's that the user had access to ? That might be one of the places to look for. As the previous answers suggested , most shops would have store the source code in some kind of config mgmt tool like SCLM or panvelet. If you have access to the load code, there are utilities that can be used to inspect the load member to get a CSECT listing which would have the names of the obj members that make up that load.You can check with your mainframe admins. That can get you the source code file names. We use SSH from USS in our shop to move code from a HFS folder to gitlab. I have also used plain FTP to just transfer source code files to my workstation . But yes, first you have to find where it is stored.

HEX
  • 83
  • 1
  • 9