Mainframe, MVS and zOS Discussion

Hi,

Forone of the programs I am in a situation where the program I'm writing needs to wait for 5 seconds , after it processes an input transaction and before it proceeds to process the next input transaction. The program would run 24x7, so performing a complicated arithmetic expression a number of time, which would take a lot of CPU does not sound like a good idea. Is there a way to make the program wait with minimum use of CPU resources for this specified period of time? I've been told to write a assembler program and call it from the COBOL program.

Is this a CICS or batch program? If CICS you could start the transaction with an interval. If batch, this is a SPECTACULARLY BAD DESIGN. Batch programs should NEVER wait -- you are tying up system resources with such a design. And there is no facility in COBOL to do such a wait (which SHOULD be a hint as to how bad the design is); you would have to use an assembler subprogram for this.

Exactly what is the reason for the waiting? Five seconds? That's a loooonnnngggg..... time. Someone writing a book, and your program needs to know who did the murder?

Robert Sample wrote: Is this a CICS or batch program? If CICS you could start the transaction with an interval. If batch, this is a SPECTACULARLY BAD DESIGN. Batch programs should NEVER wait -- you are tying up system resources with such a design. And there is no facility in COBOL to do such a wait (which SHOULD be a hint as to how bad the design is); you would have to use an assembler subprogram for this.

It's CICS Program and not a COBOL batch program.

I've also read while searching for it that it is usually a bad design when we use wait in COBOL batch program but why it is so? And when it is bad why does assembler allowed to do it, as you said COBOL doesn't have anything for this directly.

Assembler allows you to do pretty much anything, whether or not it is good to do.

When a COBOL batch program starts, it requires system resources -- an initiator, JES control blocks, memory, operating system control blocks, etc -- and when the COBOL batch program waits, these resources are tied up even during the wait. Since the system has limited resources, having too many people doing this type of program could cause ABENDs from the lack of available system resources, and could require an IPL during working hours to recover system resources.

Furthermore, there almost NEVER is a good reason to do a wait -- in batch or CICS. Proper system design usually alleviates the "requirement" to wait -- for example, if the transaction is waiting for another system to provide data, using a TD queue with a trigger level of 1 could be a solution that does not require a wait.

Thanks Robert and William. I did some reading online about it and one of the place it was written like this in support of wait and it confuses me whether or not wait is a good option in COBOL batch or COBOL-CICS:

maybe you want to switch the CICS dump data sets or perhaps start an online transaction. In such cases, you want the batch job to wait a bit before starting a later step that might depend on the outcome of the CICS action. So you put a step in your batch job that waits 30 seconds, which gives CICS time to complete your request.

Ihave supported a COBOL program that runs as an "infinite loop" task. It will keep on reading an ESDS VSAM in a CICS region, captures interesting data and submits it to a different CICS region. In case end-of-file on the input reached, there's no sense in wasting CPU cycles (or channel activity) by opening, reading, and closing the file again immediately. So the COBOL program waits 5 seconds before looking for new data. On the other hand, some of this kind of stuff might be better handled by posting and waiting on ECB's.

Well the last sentence of your quote indicates there's some question about whether or not such waits are a good idea or not.

I cannot think of ANY circumstances in which a wait would be good -- in CICS or batch. As stated earlier, batch COBOL has no facilities to implement a wait, so either an assembler subprogram has to be used or the batch program burns CPU time doing nothing. While it is waiting, the batch job continues to accumulate CPU time, use system resources, and behave in ways the system doesn't expect batch jobs to act. At best, you're misapplying system concepts to make something that shouldn't be allowed to work; at worst, you may well be impacting the entire system (batch jobs, started tasks, OMVS processes, CICS regions, and TSO users).

Although the CICS API supports waiting, it is still not a good idea. It is better to do an interval start on the transaction and end the current one so that CICS can continue to process transactions. When you wait, your transaction is not ending (if it is associated with a terminal that terminal cannot be used for anything else), which means the program continues to use the storage, accumulate CPU time, and generally holding on to resources that are freed at transaction end.

Not everything you read on the internet is true.

Oh. Wait. I just... well, here, is obviously an exception.

Not everything you read on the internet is true.

Oh. Wait. I just... well, here, is obviously an exception.

LOL

If you need to use a delay, even after the negative comments, investigate the use of CEEDLY -- LE does support a delay function; you'll have to call it from COBOL.

There is also an LE version which does milliseconds for the delay interval. Check the manuals for the specifics.