Cobol - Error with COMP-3

Author

Error with COMP-3

star6683@gmail.com

2007-09-11, 6:55 pm

hi ppl,
I have problems reading the COMP-3 data.Below is the
description of the problem.
I have a file with COMP-3 data on IBM mainframe.It is in a PS
file.
As a next step i FTP it to the windows enviornment.Also we
have microfocus server express 4.0
installed in the UNIX.
After FTPing it in ascii mode i need to run a cobol program
which can read this COMP-3 data.
To compile and run the program we are using the microfocus
compiler.
The result of running the program is as below:
"Error -163 llegal character in the numerical field"
The variable declaration in my cobol program is as follows:
03 TRID-10-10-LAST-STAT-DATE PIC 9(6) COMP-3.

I created a structure file using the Net Express record
layout and
tried to view the data in formatted mode,
I can view the right data if FTPed in binary mode.

Ultimately the aim is to read the data (COMP-3 and non-COMP
data) using the cobol program.

Kindly give me some inputs on the above problem.

Louis Krupp

2007-09-11, 6:55 pm

star6683@gmail.com wrote:
> hi ppl,
> I have problems reading the COMP-3 data.Below is the
> description of the problem.
> I have a file with COMP-3 data on IBM mainframe.It is in a PS
> file.
> As a next step i FTP it to the windows enviornment.Also we
> have microfocus server express 4.0
> installed in the UNIX.
> After FTPing it in ascii mode i need to run a cobol program
> which can read this COMP-3 data.
> To compile and run the program we are using the microfocus
> compiler.
> The result of running the program is as below:
> "Error -163 llegal character in the numerical field"
> The variable declaration in my cobol program is as follows:
> 03 TRID-10-10-LAST-STAT-DATE PIC 9(6) COMP-3.
>
> I created a structure file using the Net Express record
> layout and
> tried to view the data in formatted mode,
> I can view the right data if FTPed in binary mode.
>
> Ultimately the aim is to read the data (COMP-3 and non-COMP
> data) using the cobol program.
>
>
> Kindly give me some inputs on the above problem.
>

The IBM mainframe uses the EBCDIC character representation (as you
probably knew), and the other systems use ASCII. Alphanumeric data
(i.e., DISPLAY) is properly converted when you FTP in ASCII mode, but
that same translation destroys packed decimal data (COMP-3).

The simplest solution is to convert all of your fields to DISPLAY on the
mainframe before doing the FTP. If that's not possible, there are folks
here who will know of other ways to move the data.

Louis

William M. Klein

2007-09-11, 6:55 pm

You can search google groups for a variety of solutions to this (well known)
problem. BASICALLY, they boil down to:

1) On the mainframe, change all non-DISPLAY fields to DISPLAY (sign is
separate), then down load with conversion. (You can "re-pack" the fields and
convert to binary if required.

2) Download in Binary and use CHARSET(EBCDIC) (Micro Focus setting) on the
workstation

3) Download in binary and use an "intelligent" conversion tool (home-made or
available with SOME - not all - Micro Focus product) to convert from EBCDIC to
ASCII for "character" data and sign-fixes for packed fields.

--
Bill Klein
wmklein <at> ix.netcom.com
<star6683@gmail.com> wrote in message
news:1189519119.951558.186900@k79g2000hse.googlegroups.com...
> hi ppl,
> I have problems reading the COMP-3 data.Below is the
> description of the problem.
> I have a file with COMP-3 data on IBM mainframe.It is in a PS
> file.
> As a next step i FTP it to the windows enviornment.Also we
> have microfocus server express 4.0
> installed in the UNIX.
> After FTPing it in ascii mode i need to run a cobol program
> which can read this COMP-3 data.
> To compile and run the program we are using the microfocus
> compiler.
> The result of running the program is as below:
> "Error -163 llegal character in the numerical field"
> The variable declaration in my cobol program is as follows:
> 03 TRID-10-10-LAST-STAT-DATE PIC 9(6) COMP-3.
>
> I created a structure file using the Net Express record
> layout and
> tried to view the data in formatted mode,
> I can view the right data if FTPed in binary mode.
>
> Ultimately the aim is to read the data (COMP-3 and non-COMP
> data) using the cobol program.
>
>
> Kindly give me some inputs on the above problem.
>

Robert

2007-09-11, 9:55 pm

On Tue, 11 Sep 2007 06:58:39 -0700, star6683@gmail.com wrote:

>hi ppl,
> I have problems reading the COMP-3 data.Below is the
>description of the problem.
> I have a file with COMP-3 data on IBM mainframe.It is in a PS
>file.
> As a next step i FTP it to the windows enviornment.Also we
>have microfocus server express 4.0
> installed in the UNIX.
> After FTPing it in ascii mode i need to run a cobol program
>which can read this COMP-3 data.
> To compile and run the program we are using the microfocus
>compiler.
> The result of running the program is as below:
> "Error -163 llegal character in the numerical field"
> The variable declaration in my cobol program is as follows:
> 03 TRID-10-10-LAST-STAT-DATE PIC 9(6) COMP-3.
>
> I created a structure file using the Net Express record
>layout and
> tried to view the data in formatted mode,
> I can view the right data if FTPed in binary mode.
>
> Ultimately the aim is to read the data (COMP-3 and non-COMP
>data) using the cobol program.
>
>
> Kindly give me some inputs on the above problem.

Server Express ships with a program named DFCONV that does the conversion. The manual is
here:
http://supportline.microfocus.com/d...p1/nx31indx.htm

Robert

2007-09-11, 9:55 pm

On Tue, 11 Sep 2007 06:58:39 -0700, star6683@gmail.com wrote:

Correction: *Net* Express ships with dfconv.

Michael Mattias

2007-09-12, 7:55 am

>>hi ppl,[color=darkred]

You cannot FTP COMP[-n] or other non-DISPLAY data in ASCII mode . What's
happening is you are getting an ASCII-EBCDIC conversion on that data, which
you cannot do. Also you could get spurious control characters (eg CR, LF) in
the data stream.

There have been several threads on this exact same topic over the past six
months or so. Same solutions each time:

- FTP BINARY and handle EBCDIC-ASCII conversions on either the source or
target end
- Change the data to be FTP'd to DISPLAY format for transfer purposes, FTP
ASCII (and allow EBCDIC-ASCII conversions during transfer) and convert data
back to desired format on arrival.

General tutorial info re character sets and non-ASCII ("packed") data on my
web site
http://www.talsystems.com/tsihome_h...oads/C2IEEE.htm

--
Michael C. Mattias
Tal Systems Inc.
Racine WI
mmattias@talsystems.com

Robert

2007-09-12, 6:55 pm

Judson McClendon

2007-09-12, 6:55 pm

"Robert" <no@e.mail> wrote:
> star6683@gmail.com wrote:
>
>
> Companies that exchange thousands of files every day, those in the data warehousing
> business, have standardized on XML for every file. Even internal transfers between their
> own systems.
>
> Tell the sender you want an XML file *with schema*. If he says he can't, tell him to check
> his calendar. He'll find it's now 2007.

He will still have the same problem: comparing multiple input fields against
the database, to see what's been changed. And there's the added overhead
of decoding the XML. Coding that is not particularly trivial, unless some
flavor of function to do it is available in his environment.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Michael Mattias

2007-09-12, 6:55 pm

"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:89SFi.89736$jH3.6216@bignews6.bellsouth.net...
> "Robert" <no@e.mail> wrote:
>
> He will still have the same problem: comparing multiple input fields
> against
> the database, to see what's been changed...

Um, XML format "works" for one reason and one reason only: it is all
'display' data and the EBCDIC-ASCII conversion does not screw up the BCD and
other 'binary' data fields!

MCM

Pete Dashwood

2007-09-12, 6:55 pm

"Robert" <no@e.mail> wrote in message
news:76qfe3p98kpn36tul21e6826lgfv4nmn5g@
4ax.com...
> On Tue, 11 Sep 2007 06:58:39 -0700, star6683@gmail.com wrote:
>
>
> Companies that exchange thousands of files every day, those in the data
> warehousing
> business, have standardized on XML for every file. Even internal transfers
> between their
> own systems.
>
> Tell the sender you want an XML file *with schema*. If he says he can't,
> tell him to check
> his calendar. He'll find it's now 2007.

Speaking of XML, you might be able to help me here...

As you may be aware, VS 2005 is a very powerful, feature rich, IDE. One of
the features (which I have never got around to using), is called "Code
Snippet Manager"

Yesterday I was doing some stuff with Stream Readers on COBOL source files
and I was pretty happy with some of the C# I wrote. I thought I'd save the
TRY...CATCH block so I could re-use it next time I had a similar
requirement. I duly selected the block of code and saved it into the code
snippets folder for C#. But I couldn't get it back :-) Puzzled, I had a
look at some of the other snippets in the folder and found they were all in
XML! Mine would need to be similarly wrapped and I had no time or
inclination to look up the bloody schema for it. There was a lot of swearing
and I saved it in MyDocuments as a .TXT file... bit of a wimpy cop out, I
know, but I simply didn't have time or inclination to wade through MS Help

This is plain simple source code. Can you imagine why they require to manage
it in XML?

What am I missing here?

Pete.
--
"I used to write COBOL...now I can do anything."

Robert

2007-09-12, 6:55 pm

On Wed, 12 Sep 2007 08:50:40 -0500, "Judson McClendon" <judmc@sunvaley0.com> wrote:

>"Robert" <no@e.mail> wrote:
>
>He will still have the same problem: comparing multiple input fields against
>the database, to see what's been changed. And there's the added overhead
>of decoding the XML. Coding that is not particularly trivial, unless some
>flavor of function to do it is available in his environment.

The question said nothing about comparing to a database. If it had, the answer would be to
do it in SQL.

Decoding XML is in the 2002 Cobol Standard. When the compiler doesn't support XML, I've
used an ODBC driver.

William M. Klein

2007-09-12, 6:55 pm

And of course make certain that he knows that RW will PAY for the development
work to take "fully functional" mainframe files and convert them to XML. <G>

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message
news:76qfe3p98kpn36tul21e6826lgfv4nmn5g@
4ax.com...
> On Tue, 11 Sep 2007 06:58:39 -0700, star6683@gmail.com wrote:
>
>
> Companies that exchange thousands of files every day, those in the data
> warehousing
> business, have standardized on XML for every file. Even internal transfers
> between their
> own systems.
>
> Tell the sender you want an XML file *with schema*. If he says he can't, tell
> him to check
> his calendar. He'll find it's now 2007.

LX-i

2007-09-12, 6:55 pm

Judson McClendon wrote:
> "Robert" <no@e.mail> wrote:
>
> He will still have the same problem: comparing multiple input fields against
> the database, to see what's been changed. And there's the added overhead
> of decoding the XML. Coding that is not particularly trivial, unless some
> flavor of function to do it is available in his environment.

This isn't the same problem. :) I agree with Robert - XML is a great
way to interchange data. If bandwidth is an issue, just compress it -
plain text compresses very well.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~

GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++

"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine

Robert

2007-09-12, 9:55 pm

On Wed, 12 Sep 2007 21:59:16 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>And of course make certain that he knows that RW will PAY for the development
>work to take "fully functional" mainframe files and convert them to XML. <G>

Files are not "fully functional" when recipients have to struggle to read them, as we've
seen here dozens of times.

In the Old Days, when people said they'd received a Cobol file, I responded there is no
such thing. Cobol uses regular (flat) files that can be read by any programming language.

Now I've changed my opinion. A file containing packed decimal really IS a 'Cobol file',
because it cannot be read with common tools such as spreadsheets, database loaders, ODBC
drivers nor by programs written in Java, C#, C++, scripting languages, etc. The recipient
has to find a specialized tool, write a Cobol program or hunt down a specialized class
library. Microsoft Host Integration Server, one such specialized tool, refers to packed as
a "COBOL data type". We know it's not, but the rest of the world thinks it is.
http://msdn2.microsoft.com/en-us/library/ms964696.aspx

Pete Dashwood

2007-09-12, 9:55 pm

"Robert" <no@e.mail> wrote in message
news:3ivge35p788nmi19n15jspdi8cm7q3o23c@
4ax.com...
> On Wed, 12 Sep 2007 21:59:16 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> Files are not "fully functional" when recipients have to struggle to read
> them, as we've
> seen here dozens of times.
>
> In the Old Days, when people said they'd received a Cobol file, I
> responded there is no
> such thing. Cobol uses regular (flat) files that can be read by any
> programming language.
>
> Now I've changed my opinion. A file containing packed decimal really IS a
> 'Cobol file',
> because it cannot be read with common tools such as spreadsheets, database
> loaders, ODBC
> drivers nor by programs written in Java, C#, C++, scripting languages,
> etc. The recipient
> has to find a specialized tool, write a Cobol program or hunt down a
> specialized class
> library. Microsoft Host Integration Server, one such specialized tool,
> refers to packed as
> a "COBOL data type". We know it's not, but the rest of the world thinks it
> is.
> http://msdn2.microsoft.com/en-us/library/ms964696.aspx

Fair comment.

I've accessed packed fields from C# but, as you noted, I had to use a
special library to do it.

I see this as being kind of analogous to the advent of Relational DB (which
generally coincided with the advent of desktop computing). One of the
reasons people in the early 80s started looking askance at COBOL was because
the "file system" (ISAM/VSAM) was "closed". Need another report? Write a
COBOL program. Suddenly they found if it was on an ACCESS or DB2 database,
anything could get to it, and reports could be generated without any
knowledge of COBOL.

15 years later we had Internet forums and people were still resisting
vehemently. I pointed out at the time that opening up the corporate data
resource by migrating it to RDB might be a good thing and got rubbished for
it. (The usual, "overheads", "performance", "There's nothing wrong with what
we've got", etc.) In fact, I remember some quite venomous posts saying that
I was undermining COBOL by even suggesting it :-).

It is ironic that 25 years later I am being paid to write tools to assist
the migration from flat files to RDB... (there are still some places that
have resisted to the last.)

Packed Decimal will eventuall disappear because the reasons it was invented
have no relevance today. (I remember it being an option on early System
360s; Gene Amdahl never designed it into the system. It was implemented in
firmware, and only if you paid for the "commercial instruction set". The
idea was to make 360 a flexible system that could be sold to the commercial
and scientific communities. When competing systems like the ICL 1900 began
creaming IBM in benchmarks, they realised it was much too slow...)

Pete.
--
"I used to write COBOL...now I can do anything."

Judson McClendon

2007-09-13, 6:55 pm

"Michael Mattias" <mmattias@talsystems.com> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> Um, XML format "works" for one reason and one reason only: it is all 'display' data and the EBCDIC-ASCII conversion does not screw
> up the
> BCD and other 'binary' data fields!

I wasn't hacking XML. Just finished a .NET project using XML in doing
communications between two mainframes and a PC over the Internet.

Perhaps I was

about which thread I was in. I thought this was
the discussion of the group compare of signed fields.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

Michael Mattias

2007-09-13, 6:55 pm

"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:t9bGi.84405$pu2.50972@bignews1.bellsouth.net...
> "Michael Mattias" <mmattias@talsystems.com> wrote:
>
> I wasn't hacking XML. Just finished a .NET project using XML in doing
> communications between two mainframes and a PC over the Internet.
>
> Perhaps I was

about which thread I was in. I thought this was
> the discussion of the group compare of signed fields.

Maybe I was. I thought this was the thread about the guy having problems
moving COMP-3 data via FTP, a proposed solution for which was "don't do
that, use XML"

I'd have to do the research to be sure, but I am beginning to suspect that
sometimes these threads *both* overlap *and* wander.

MCM

Judson McClendon

2007-09-13, 6:55 pm

"Michael Mattias" <mmattias@talsystems.com> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote in message news:t9bGi.84405$pu2.50972@bignews1.bellsouth.net...
>
> Maybe I was. I thought this was the thread about the guy having problems moving COMP-3 data via FTP, a proposed solution for which
> was "don't do that, use XML"
>
> I'd have to do the research to be sure, but I am beginning to suspect that sometimes these threads *both* overlap *and* wander.

Whatever the case, I totally agree that XML is a very good way to solve the
FTP COMP-3 problem! :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."

HeyBub

2007-09-13, 6:55 pm

Judson McClendon wrote:
>
> Whatever the case, I totally agree that XML is a very good way to
> solve the FTP COMP-3 problem! :-)

COMP-3 guarantees employment.

Charles Hottel

2007-09-14, 3:55 am

"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:C8cGi.7063$JD.2133@newssvr21.news.prodigy.net...
> "Judson McClendon" <judmc@sunvaley0.com> wrote in message
> news:t9bGi.84405$pu2.50972@bignews1.bellsouth.net...
>
> Maybe I was. I thought this was the thread about the guy having problems
> moving COMP-3 data via FTP, a proposed solution for which was "don't do
> that, use XML"
>
> I'd have to do the research to be sure, but I am beginning to suspect that
> sometimes these threads *both* overlap *and* wander.
>
> MCM
>
>

You just need a little more of your favorite poison so you can wander and
weave with the threads!

Robert

2007-09-14, 3:55 am

On Thu, 13 Sep 2007 16:58:15 -0500, "HeyBub" <heybubNOSPAM@gmail.com> wrote:

>Judson McClendon wrote:
>
>COMP-3 guarantees employment.

.... and continuing sales for IBM.

Sponsored Links