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…