On Thu, 26 Apr 2007 15:13:37 -0300, in bit.listserv.ibm-main Clark
Morris <[EMAIL PROTECTED]> wrote:

On 26 Apr 2007 08:45:03 -0700, [EMAIL PROTECTED] (Edward Jaffe)
wrote:

>Clark Morris wrote:
>> The frustrating thing is that there is no compiler switch to tell most
>> of the compilers that these instructions can be used because the
>> target is known.  ISV's normally have to hang back on using these
>> instructions because the target processor may not have the
>> instruction.
>>   
>
>ARCH
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cbcug150/2.3.15.5
>
>TUNE
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cbcug150/2.3.15.94

Now would it make a difference in COBOL performance if COBOL had those
options and if so why doesn't it.  Of course the abysmal performance
of TRUNC(BIN) was due to incredibly bad programming decisions (convert
to and from decimal for the actual arithmetic).  And then there is the
ridiculous IEEE to hex floating point conversion done for Java
interface even though there is a CLEAN way to define IEEE floating
point using the 2002 standard.
>
>ISVs do indeed have to "hang back". And, so do IBM developers. The life 
>saver is knows as an "Architectural Level Set". Some customers don't 
>like them because they tend to obsolete affordable hardware processor 
>models. But, IBM and ISV developers like them because they allow use of 
>the new facilities. For example, IBM no longer supports anything less 
>than z/OS 1.6. And, z/OS 1.6 requires z/Architecture. This means that 
>IBM developers can use z/Architecture instructions for _all_ new code 
>targeted for z/OS without the need for dual-path, bifurcated, or "lowest 
>common denominator" instruction paths. The same holds true for any ISV 
>that follows IBM's support schedule.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to