When I hear they specifically need COBOL programmers I scratch my head wondering why. Did they just discover a ton of bugs or is it that their current architecture is not scalable? My guess would be the latter.
I’m thinking the solution requires system architecture changes. I would like to explore what they have, and how it can be split apart to make it scalable with as little code changes as possible.
It’s call for help, not unlike a " shake the tree and what falls to your feet is what you eat" kinda thing. They’re just looking to place blame, for lack of foresight. It’s two maybe three issues at work. 1) capacity/preparation to meet demand surges; 2) Meeting the demands of a wider customer base who use devices that mainframes weren’t initially intended to share data with (cell phone tablets… etc); 3) mitigation to remove the reliance on a language which does it’s job quite well, but the talent pool is no longer easily available. IBM mainframes are fast and reliable and can be turned into viable platforms to support various mission critical workloads. Evey platform has a place in work load sharing, some are better at some things and not so good at others.
At this point it is pure speculation what the issues are.
We have to assume that the code works but volume is causing problems.
Scalability at the mainframe level using COBOL is usually not the issue.
You are running on some on the fastest machines in the world.
Think of airline reservations systems,multi-state lotteries especially when the prize becomes large. Real-time response of these extremely large systems is reliable and efficient. Lets not forget IRS and Social Security. These systems are being pounded every minute of every day and never fail and response time is immediate.
The end-user is most likely using a browser that is connected to an intermediate application server that is connected to the unemployment mainframe application server.
I would analyze throughput as follows:
First. Which version of COBOL? COBOL/VS is 16bit. COBOL/II is 31bit. Enterprise COBOL is 64bit. COBOL/VS goes back to 1968/1974. If they are still running COBOL/VS no need to go any further. That is the problem. 16 bit can only run in Storage below the line (0 MB to 16 MB). As more tasks are loaded the infamous ‘SOS(Short on Storage)’ message appears in the message log and the system locks up. Think of a laptop with 1gb/2gb. Converting to COBOL/II(31bit) circa 1985 was as simple as re-compiling in some cases. Virtual Storage above the line (16 MB to 2 GB) is available with COBOL/II. That would solve the problem. Storage above the bar (4 GB to a theoretical 16 exabytes) is available with 64bit .
Next is to detemine is if the capacity/volume is being utilized or throttled.Look at the requests arriving at mainframe application server. For argument sake lets assume they are running CICS with TCPIP sockets. 2000 sockets are supported but what is the parm set to? Default of 50? CICS sockets is handed the incoming request from TCPIP. Again how much storage/ how many sockets are allocated? What is the RUSIZE/frame size? 4Mg? End-user symptom here is clocking/no response from server. Next is the CICS sockets server iterative or concurrent? If concurrent? How Many? Are they further thottled by tranclass parm? What is the CICS max task/active max tasks? Are there non-server tasks(3270) allocated to max/active? Pseudo-conversational or conversational transactions?
Finally there is the DB. Assuming IBM technology. VSAM? IMS? DB2? How many records are being inserted? Records inserted normally go to the end of the chain. Nationally a lot of people are filing unenployment. State by state not so many records. But then again think about American Airlines, IRS and Social Security. The number of records for the worst state unemployment is miniscue compared to these systems. Check the VSAM values for CI/CA Split. Is it 50%? Is the file being reorganized? How often? How many VSAM strings/threads? Are they in hyperspace? How many tasks can schedule access to the DB at the same time?
Do the programs schedule db access at program entry and terminate db access at program exit or do they schedule just before the file i/o and terminate right after file i/o. Intent DB Scheduling? Exclusive DB access? Parallel or Serial DB access?
Just a few thoughts from a guy programming IBM mainframes in COBOL for 50 years…
ajb thank you for the level of detail you provided regarding how you would attack it as a full stack problem. We are on the same page here for sure. Identifying each bottleneck one by one. But say you fix a bunch, it may be pointless if you discover upstream that say an internet service provider is now the problem because they are unable to provision more concurrent sockets.
It’s obvious you are a full stack systems guy which is the point of my OP. It is a very complex problem that is not going to get fixed by people who are just able to code in COBOL. It’s going to require a team of guys like you,and when they hear how long its going to take to implement a real solution they will hit the ceiling.
I would be very interested to know if and/or when you will be involved in a project working towards a solution, that is if you are at all interested in getting involved 
I have done system migrations in the past and they have all gone pretty much the same way.
Just like a new bridge, you build it next to the old one without ever shutting down the existing. Once the new one is built you begin routing some of the traffic over it to make sure your structural assumptions were correct. Then finally one day all traffic is running over the new one and you can remove the old one.
The quickest one I’ve done was a PeopleSoft to Salesforce/SAP and that one took 2 1/2 years!. So regarding my OP, it’s going to take a set of people with full stack experience, not just COBOL programmers.
I agree with you
I volunteered at this site and NJ. CT’s site was not IT specific so I didn’t apply.
I doubt if anyone will call me back. Seems like the big corporations are responding.
This is an interesting article.
Maybe NJ is running a very old version of IBM VSE(DOS/360 lineage, which originated in 1965) with COBOL/68. In that case I withdraw my application.
You’re over simplifying a real big bag’o worms here hoss.
Assuming you have z/OS with some sort Firewall technologies installed ( the config tools were moved in z/OS 2.2) with IBM HTTP server. You need an HTTPS service put in place. Then you need a DMZ or two which should be controlled by your WAN/LAN group, in which case you have to get approval and tested before you even think about such nonsense. Provided you have the latest COBOL compiler installed and can secure enough onsite talent to convert legacy COBOL to say Java,Node.js and then put up a Website on z/OS. There is the problem of configuring TCP/IP and letting a bunch of novice programmers hackers turned loose inside of USS (Unix System Services) without some controls in place. Not a good idea my friend, which is why I never went as far as a casual “Viola its alive” test with Apache HTTP, Tomcat, Geronimo, and PHP on z/OS some years back. Then there is the problem of TSO editing on USS, or using some other editor, which takes some getting use too. Now your problems start mounting cause do run z/FS or just the regular file system…??. TCP/IP on z/OS while not difficult to wrap your head around, and is somewhat similar in many respects to most Unix systems I used, with some minor exceptions. These are design and engineering issues for z/OS systems personel, not something for the run of the mill Programmer/Analyst to stick his/her neck out for. It took us a full 5 years to convert from primarily a VTAM/SNA to a Secure TCP/IP environment , with all of the issues that lay in front of us. That path while a lot easier nowadays would still be full of challenges. I said all along that the problems (IMHO) are not with COBOL, they’re largely the result of oragnizations who misappropriate the talent deployment to develop systems which are compatible with today’s consumer computing devices. Capacity issues notwithstanding, COBOL is just doing the job it was intended to do, and probably doing just fine. You wanna view your Account Receivables on your cell phone go ahead, but it requires a different set of engineering principles when it comes to z/OS.
Not sure what a COBOL programmer is going to do to fix this. In all likelihood there is nobody around who understands how the system works anymore and there may be no documentation or bad documentation. I once worked in a shop where all they had for an application was a punched deck of object code. No source. No documentation, No plans to redo it. They would just occasionally reproduce the deck.
A good COBOL programmer might be able to review the code and document the processes, but even a good COBOL programmer is probably not going to be able to scale up performance without a significant investment in new equipment that will run existing code faster.
The alternative is to develop a front end application that can handle increased volume caused by more user requests, pre-process and validate data, and pace the transactions to the mainframe back end. The front end could be written in any language and would likely be a web app. Hopefully, they’re not key-punching user applications and submitting them. But these applications are so old. Who knows. Sounds like another chapter for The Mythical Man Month.
As suggested by most; there no real emergency here. Just a bunch of knuckle head managers and P/A neophytes who don’t know their way around mainframes, and for all their blind dumb luck are caught off guard with capacity restraints. Good thing COBOL can be blamed for this, else every last one of the SOB’s should be fired on the spot.
The only thing COBOL programmers can really do in this case is change the requirements and calculations. I’d be happy to help with that, but these systems were not built to deal with mass unemployment at the level we see today. I seriously doubt any state has the financial resources or will or time to change that. I’m not even sure they should. While I am a big fan of overbuilding in my own life, on this scale it doesn’t make a lot of sense to pay that kind of upkeep for aberrations like this. What they will do is muddle through and benefits will be delayed.
My best advice to applicants is to get up at 2AM and start trying to get on.
I imagine it’s that the [software] requirements have changed, which needs programmers, which are in short supply. My n00b understanding is that these systems are incredibly resilient, and, up until now, had stayed appropriately static for years. Not so any mo.
This Tweet shows the unemployment claims history. It’s a graphic demonstration of why the states are in trouble and why it will never be fixed.
I have been thinking the exact same thing! I am a retired COBOL programmer, put myself on the list, but I question that they really need develpers also!
Not in short supply, they don’t want to pay a fair wage, so out sourcing major installations was in vogue and a way to get around paying top dollar for a competent staff. Chickens have come home to roost. let’em suffer.
Like Y2K, I wonder if it is increasing the size of variables.
Lot of truth in that.