Date Function Performance

Support for OS/VS COBOL, VS COBOL II, COBOL for OS/390 & VM and Enterprise COBOL for z/OS

Re: Date Function Performance

Postby steve-myers » Sat Mar 19, 2011 7:53 pm

Just a bit off topic. How does one say 0.01 Euro?
Global moderator
Posts: 1773
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 168 times

Re: Re: Date Function Performance


Re: Date Function Performance

Postby BillyBoyo » Sun Mar 20, 2011 1:12 am

Did you try goole? What about a new topic? :-)

The answer is, lots of things. The currency is the Euro, spelled the same, on the notes, everywhere that uses it, the note includes the spelling in Greek. Pronounced differently in different countries.

On the coins it says "cent". Usually this is lengthened to a local language word. Like centimos, for instance.
Brits call it "cent" but have their own currency.
Global moderator
Posts: 3738
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 255 times

Re: Date Function Performance

Postby BillyBoyo » Thu Mar 31, 2011 4:29 am

Well, I don't expect the TS to come back, but, for information

The DYNAM compiler option specifies that all subprograms invoked through the CALL literal statement
will be loaded dynamically at run time. This allows you to share common subprograms among several
different applications, allowing for easier maintenance of these subprograms since the application will not
have to be re-link-edited if the subprogram is changed. DYNAM also allows you to control the use of
virtual storage by giving you the ability to use a CANCEL statement to free the virtual storage used by a
subprogram when the subprogram is no longer needed. However, when using the DYNAM option, you pay
a performance penalty since the call must go through a library routine, whereas with the NODYNAM
option, the call goes directly to the subprogram. Hence, the path length is longer with DYNAM than with
Performance considerations using DYNAM with CALL literal (measuring CALL overhead only):
| On the average, for a CALL intensive application, the overhead associated with the CALL using
| DYNAM ranged from 40% slower to 100% slower than NODYNAM.
| For additional considerations using call literal and call identifier, see “Using CALLs” on page 21.
Note: This test measured only the overhead of the CALL (i.e., the subprogram did only a GOBACK);
thus, a full application that does more work in the subprograms is not degraded as much.
| (COB PG: pp 320-321, 410, 412, 429, 440, 450-453, 455-456, 673)"

Don't get too worried about this. Note the note. Even with "definitive" information, this in no way provides an answer to any performance question, in isolation. The more your sub-routine does, the less the overhead of the Dynamic call is effecting performance. Even if short, there can be many valid reasons (search the forum) for unsing Dynamic calls which are considered, taking the full view of the system into account, to outweigh performance.

If you have an issure with performance, and you are doing a lot of dynamic calls, and everyone is happy to change Dynamic to Static with whatever that entails - try it out first. Just because it performs worse, doesn't mean you'll really notice it across a complex system.
Global moderator
Posts: 3738
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 255 times


Return to IBM Cobol


  • Related topics
    Last post