Re: Enterprise COBOL v3.4.1 run time issue
Dear all, Thank you for your answers. IBM recomend us so our programmers make the data validation. Please review following link below: http://www-01.ibm.com/support/docview.wss?uid=swg21238919 Best regards, K. Zafiropoulos -- 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
Re: Enterprise COBOL v3.4.1 run time issue
On Wed, 27 Aug 2008 20:36:04 -0300 Clark Morris [EMAIL PROTECTED] wrote: :I am not certain if PIC X(n) will allow sign zones on the low order :byte. PIC X allows anything. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: Enterprise COBOL v3.4.1 run time issue
On 26 Aug 2008 08:04:56 -0700, in bit.listserv.ibm-main you wrote: I Agree with the IF NOT NUMERIC. When you read data into an area, the validity of the data is not checked. The Data Truncation Option on the compiler does not check the validity of the data at runtime. It is up to the application programmer to edit the data and check the validity of that data. The IF NOT NUMERIC and IF NUMERIC is a great way to test the validity of a alphanumeric field for numeric data. The way I remember it, the programmer has to do a redefine of the field and give it a PIC X characteristic, then issue an IF NOT NUMERIC on the alphanumeric field. I am not certain if PIC X(n) will allow sign zones on the low order byte. PIC S9(n) will allow plus and minus sign zones and may disallow fields without a sign on the specified position depending on the NUMPROC option. PIC 9(n) means that all digits must be numeric. And then there are the rules for SIGN IS SEPARATE. Regards, Don -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mansell, George R. Sent: Tuesday, August 26, 2008 9:52 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Enterprise COBOL v3.4.1 run time issue Pack of FOW123 followed by zap and unpack would do this without a data exception. Only changes the zones C,D,E. Probably pic 99 == pic 99. Why not use If not numeric? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, August 26, 2008 8:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Enterprise COBOL v3.4.1 run time issue -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Monday, August 25, 2008 9:45 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Enterprise COBOL v3.4.1 run time issue On Mon, 25 Aug 2008 08:26:19 -0600, Steve Comstock wrote: K Zafirop wrote: The value passed is the arithmetic truncation of the string. For example a string 'FOW123' is passed with value '666123'. I'm confused here. How can the string 'FOW123' have a value '666123'? The string is its value. It appears as if something is doing a Pack and ignoring data errors. -- gil There is no data error possible with a PACK instruction. The programmer must validate that his input is valid before doing a PACK. Now, it is possible that the PACK instruction will create output which is not a valid packed decimal number. But that will not be detected until another decimal instruction tries to use it (such as ZAP, or AP, or SP, or ...). -- 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
Re: Enterprise COBOL v3.4.1 run time issue
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Monday, August 25, 2008 9:45 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Enterprise COBOL v3.4.1 run time issue On Mon, 25 Aug 2008 08:26:19 -0600, Steve Comstock wrote: K Zafirop wrote: The value passed is the arithmetic truncation of the string. For example a string 'FOW123' is passed with value '666123'. I'm confused here. How can the string 'FOW123' have a value '666123'? The string is its value. It appears as if something is doing a Pack and ignoring data errors. -- gil There is no data error possible with a PACK instruction. The programmer must validate that his input is valid before doing a PACK. Now, it is possible that the PACK instruction will create output which is not a valid packed decimal number. But that will not be detected until another decimal instruction tries to use it (such as ZAP, or AP, or SP, or ...). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: Enterprise COBOL v3.4.1 run time issue
Pack of FOW123 followed by zap and unpack would do this without a data exception. Only changes the zones C,D,E. Probably pic 99 == pic 99. Why not use If not numeric? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, August 26, 2008 8:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Enterprise COBOL v3.4.1 run time issue -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Monday, August 25, 2008 9:45 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Enterprise COBOL v3.4.1 run time issue On Mon, 25 Aug 2008 08:26:19 -0600, Steve Comstock wrote: K Zafirop wrote: The value passed is the arithmetic truncation of the string. For example a string 'FOW123' is passed with value '666123'. I'm confused here. How can the string 'FOW123' have a value '666123'? The string is its value. It appears as if something is doing a Pack and ignoring data errors. -- gil There is no data error possible with a PACK instruction. The programmer must validate that his input is valid before doing a PACK. Now, it is possible that the PACK instruction will create output which is not a valid packed decimal number. But that will not be detected until another decimal instruction tries to use it (such as ZAP, or AP, or SP, or ...). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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 -- NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. Thank you. == -- 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
Re: Enterprise COBOL v3.4.1 run time issue
John In my opinion the emphasis in your reply is wrong. Not only is there no checking that the source bytes are correct unpacked decimal bytes but you may very well want there to be no check performed. An example doesn't come to mind right now - perhaps someone else still interested in this topic has one - but I'm sure in the past I have used this very feature of the PACK instruction in order to achieve some programming objective. This is definitely not a bug as supposed by Paul (gil) but a potentially useful feature. As was evident in the original post, there is no checking of the input and, as you pointed out, there is no checking of the output. Another point that those who have come to the world of the 360 instruction set (and its later accretions) only recently from more rigid worlds - as I sometimes detect - is that there are a number of instructions which are documented as being made available for specific functions but which, when you dig down to what they actually do, you can see can be used in ways outside the documented function. It's now you need to recall that the instructions were created in order to be efficient using the hardware of the early 1960s, the days when memory truly was core. I used to marvel - to myself only, of course! - at just how complex the EDMK instruction was compared to others which it was possible to accept could be implemented relatively cheaply. Chris Mason On Tue, 26 Aug 2008 08:40:07 -0500, McKown, John [EMAIL PROTECTED] wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Monday, August 25, 2008 9:45 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Enterprise COBOL v3.4.1 run time issue On Mon, 25 Aug 2008 08:26:19 -0600, Steve Comstock wrote: K Zafirop wrote: The value passed is the arithmetic truncation of the string. For example a string 'FOW123' is passed with value '666123'. I'm confused here. How can the string 'FOW123' have a value '666123'? The string is its value. It appears as if something is doing a Pack and ignoring data errors. -- gil There is no data error possible with a PACK instruction. The programmer must validate that his input is valid before doing a PACK. Now, it is possible that the PACK instruction will create output which is not a valid packed decimal number. But that will not be detected until another decimal instruction tries to use it (such as ZAP, or AP, or SP, or ...). -- John McKown -- 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
Re: Enterprise COBOL v3.4.1 run time issue
I Agree with the IF NOT NUMERIC. When you read data into an area, the validity of the data is not checked. The Data Truncation Option on the compiler does not check the validity of the data at runtime. It is up to the application programmer to edit the data and check the validity of that data. The IF NOT NUMERIC and IF NUMERIC is a great way to test the validity of a alphanumeric field for numeric data. The way I remember it, the programmer has to do a redefine of the field and give it a PIC X characteristic, then issue an IF NOT NUMERIC on the alphanumeric field. Regards, Don -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mansell, George R. Sent: Tuesday, August 26, 2008 9:52 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Enterprise COBOL v3.4.1 run time issue Pack of FOW123 followed by zap and unpack would do this without a data exception. Only changes the zones C,D,E. Probably pic 99 == pic 99. Why not use If not numeric? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, August 26, 2008 8:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Enterprise COBOL v3.4.1 run time issue -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Monday, August 25, 2008 9:45 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Enterprise COBOL v3.4.1 run time issue On Mon, 25 Aug 2008 08:26:19 -0600, Steve Comstock wrote: K Zafirop wrote: The value passed is the arithmetic truncation of the string. For example a string 'FOW123' is passed with value '666123'. I'm confused here. How can the string 'FOW123' have a value '666123'? The string is its value. It appears as if something is doing a Pack and ignoring data errors. -- gil There is no data error possible with a PACK instruction. The programmer must validate that his input is valid before doing a PACK. Now, it is possible that the PACK instruction will create output which is not a valid packed decimal number. But that will not be detected until another decimal instruction tries to use it (such as ZAP, or AP, or SP, or ...). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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 -- NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. Thank you. == -- 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 - The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message
Enterprise COBOL v3.4.1 run time issue
Hi all, One of our most curious programmers noticed that when he uses READ or READ INTO statement to parse alphanumeric data, a translation is made. The value passed is the arithmetic truncation of the string. For example a string 'FOW123' is passed with value '666123'. As you can see X'F1' = C6D6E6F1F2F3. The truncation made before assigning the value to an element so, using DTR instead of DTR has no effect. Do you think this is a compiler or LE issue? Thank you in advance K. Zafiropoulos EFG EUROBANK z/OS junior System Programmer -- 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
Re: Enterprise COBOL v3.4.1 run time issue
K Zafirop wrote: Hi all, One of our most curious programmers noticed that when he uses READ or READ INTO statement to parse alphanumeric data, a translation is made. I don't believe it. READ transfers bytes of data from an external source into a memory location unchanged. The only exception I'm aware of is if you are reading ASCII tapes and have requested the translation in your DD statement. The value passed is the arithmetic truncation of the string. For example a string 'FOW123' is passed with value '666123'. I'm confused here. How can the string 'FOW123' have a value '666123'? The string is its value. Maybe you could give us some more code: * relevant portion of record layout * Select, FD, Open, and READ statement coding * How are you detecting this value As you can see X'F1' = C6D6E6F1F2F3. The truncation made before assigning the value to an element so, using DTR instead of DTR has no effect. Do you think this is a compiler or LE issue? What is DTR? Thank you in advance K. Zafiropoulos EFG EUROBANK z/OS junior System Programmer -- 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 -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.html== -- 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
Re: Enterprise COBOL v3.4.1 run time issue
DTR will test and give you a Compile time error if truncation is occurring, that is moving a 6 digit field to a 5 digit field. It will also test to see when you are moving an alphanumeric field to a numeric field. This is a compile time and not a runtime option. The value I am seeing FOW123, if you or the compiler were to move it to a binary or packed field would give you a packed decimal value of 666123. Somewhere it appears a PACK instruction is being done on this field. Without seeing the code, I can only speculate on what might have caused this. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of K Zafirop Sent: Monday, August 25, 2008 10:02 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Enterprise COBOL v3.4.1 run time issue Hi all, One of our most curious programmers noticed that when he uses READ or READ INTO statement to parse alphanumeric data, a translation is made. The value passed is the arithmetic truncation of the string. For example a string 'FOW123' is passed with value '666123'. As you can see X'F1' = C6D6E6F1F2F3. The truncation made before assigning the value to an element so, using DTR instead of DTR has no effect. Do you think this is a compiler or LE issue? Thank you in advance K. Zafiropoulos EFG EUROBANK z/OS junior System Programmer -- 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 - The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. -- 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
Re: Enterprise COBOL v3.4.1 run time issue
On Mon, 25 Aug 2008 09:02:26 -0500 K Zafirop [EMAIL PROTECTED] wrote: :Hi all, : :One of our most curious programmers noticed that when he uses READ or READ :INTO statement to parse alphanumeric data, a translation is made. The value :passed is the arithmetic truncation of the string. For example a :string 'FOW123' is passed with value '666123'. As you can see X'F1' = :C6D6E6F1F2F3. The truncation made before assigning the value to an element :so, using DTR instead of DTR has no effect. Do you think this is a compiler or :LE issue? I don't know what DTR is, but if you simply use a field as numeric data COBOL will issue a PACK followed by the rest of the operation. The field above will generate valid packed data. You can use the IF NUMERIC class test to verify the contents. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: Enterprise COBOL v3.4.1 run time issue
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of K Zafirop Sent: Monday, August 25, 2008 9:02 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Enterprise COBOL v3.4.1 run time issue Hi all, One of our most curious programmers noticed that when he uses READ or READ INTO statement to parse alphanumeric data, a translation is made. The value passed is the arithmetic truncation of the string. For example a string 'FOW123' is passed with value '666123'. As you can see X'F1' = C6D6E6F1F2F3. The truncation made before assigning the value to an element so, using DTR instead of DTR has no effect. Do you think this is a compiler or LE issue? Thank you in advance I'm a bit confused. But if you have some external datum which is character 'FOW123' and read it into a COBOL data item which is defined as PIC 9(6) USAGE DISPLAY., then what you are seeing in normal. The problem is that when you then move that data to somewhere else, the code generated does a CVD instruction. The CVD instruction pays no attention to the high order nybble of the data, except for the last byte, in which it the zone nybble is used as the sign nybble. If you want to make sure that the input is valid, then do a IF variable IS NUMERIC or IF variable IS NOT NUMERIC type test before using the datum. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: Enterprise COBOL v3.4.1 run time issue
On Mon, 25 Aug 2008 08:26:19 -0600, Steve Comstock wrote: K Zafirop wrote: The value passed is the arithmetic truncation of the string. For example a string 'FOW123' is passed with value '666123'. I'm confused here. How can the string 'FOW123' have a value '666123'? The string is its value. It appears as if something is doing a Pack and ignoring data errors. -- gil -- 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
Re: Enterprise COBOL v3.4.1 run time issue
Doubt the Read is involved. Look at the move code for this field generated by the complier. Pics? On Mon, 25 Aug 2008 08:26:19 -0600, Steve Comstock wrote: K Zafirop wrote: The value passed is the arithmetic truncation of the string. For example a string 'FOW123' is passed with value '666123'. I'm confused here. How can the string 'FOW123' have a value '666123'? The string is its value. It appears as if something is doing a Pack and ignoring data errors. -- gil -- 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 -- NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. Thank you. == -- 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
Enterprise COBOL v3.4.1 run time issue
As others have indicated, I (mostly) doubt that the READ (rather than READ INTO) is doing ANY manipulation of data. The one possible exception is if you have the 01-level under the FD defined as a numeric or edited field - and even then, I doubt that conversion takes place. (The other exception is READING ASCII tape files, but that doesn't sound like this case). Can you tell us/show us exactly how the FD and subsequent 01-level are defined? If you do that, we may be able to tell you what is happening (and why). If the 01-level is actually a group item or you find that the READ is NOT doing conversions but the READ INTO is, then let us know what the 01-level under the FD and the receiving (INTO) field look like). K Zafirop [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hi all, One of our most curious programmers noticed that when he uses READ or READ INTO statement to parse alphanumeric data, a translation is made. The value passed is the arithmetic truncation of the string. For example a string 'FOW123' is passed with value '666123'. As you can see X'F1' = C6D6E6F1F2F3. The truncation made before assigning the value to an element so, using DTR instead of DTR has no effect. Do you think this is a compiler or LE issue? Thank you in advance K. Zafiropoulos EFG EUROBANK z/OS junior System Programmer -- 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