Re: Enterprise COBOL v3.4.1 run time issue

2008-10-03 Thread K Zafirop
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

2008-08-28 Thread Binyamin Dissen
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

2008-08-27 Thread Clark Morris
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

2008-08-26 Thread McKown, John
 -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

2008-08-26 Thread Mansell, George R.
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

2008-08-26 Thread Chris Mason
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

2008-08-26 Thread Don Holstein
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

2008-08-25 Thread K Zafirop
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

2008-08-25 Thread Steve Comstock

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

2008-08-25 Thread Don Holstein
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

2008-08-25 Thread Binyamin Dissen
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

2008-08-25 Thread McKown, John
 -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

2008-08-25 Thread Paul Gilmartin
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

2008-08-25 Thread Mansell, George R.
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

2008-08-25 Thread Bill Klein
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