| Author |
reading COMP-3 data on UNIX using microfocus
|
|
|
| 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 UNIX environment ( Solaris
8.1).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:
Successfully reads the non-COMP data.
COMP-3 data is read as a junk.
The variable declaration in my cobol program is as follows:
fs-abc S9(8) COMP-3.
fs-xyz 9(2).
FILLER X(73).
I created a structure file using the DATA FILE EDITOR 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.
| |
|
| In article <1180874176.462134.117810@x35g2000prf.googlegroups.com>,
kimi <mraghu83@gmail.com> wrote:
[snip]
> 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 UNIX environment ( Solaris
>8.1).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:
> Successfully reads the non-COMP data.
> COMP-3 data is read as a junk.
Ding! Consider what happens when you ftp from one platform to another
while translating EBCDIC to ASCII. The transfer knows nothing about
fields, just about byte-by-byte translation.
>
> The variable declaration in my cobol program is as follows:
> fs-abc S9(8) COMP-3.
> fs-xyz 9(2).
> FILLER X(73).
See above about 'the transfer knows nothing about fields'.
DD
| |
|
|
docdw...@panix.com () wrote:
> In article <1180874176.462134.117810@x35g2000prf.googlegroups.com>,
> kimi <mraghu83@gmail.com> wrote:
>
> [snip]
>
>
> Ding! Consider what happens when you ftp from one platform to another
> while translating EBCDIC to ASCII. The transfer knows nothing about
> fields, just about byte-by-byte translation.
>
>
> See above about 'the transfer knows nothing about fields'.
>
> DD
Can you pls be more elaborate??
| |
|
|
docdw...@panix.com () wrote:
> In article <1180874176.462134.117810@x35g2000prf.googlegroups.com>,
> kimi <mraghu83@gmail.com> wrote:
>
> [snip]
>
>
> Ding! Consider what happens when you ftp from one platform to another
> while translating EBCDIC to ASCII. The transfer knows nothing about
> fields, just about byte-by-byte translation.
>
>
> See above about 'the transfer knows nothing about fields'.
>
> DD
Can you pls be more elaborate??
| |
| Louis Krupp 2007-06-03, 6:55 pm |
| kimi wrote:
> docdw...@panix.com () wrote:
>
> Can you pls be more elaborate??
>
Suppose your record were declared
01 rec.
05 n pic 9(2) comp-3.
05 s pic x(1).
Suppose, in the original EBCDIC, n had the value 81, and s had the value
'a'. This is actually stored as hexadecimal '8181'.
When ftp translates this to ASCII, it does it a byte at a time, and
translates all EBCDIC a's to ASCII a's, so that now it is stored as
hexadecimal '6161'. s is fine, but n is now 61.
The best way to fix this is to copy the EBCDIC data to a record in which
n is declared "pic 9(2) display" and then ftp the file to your UNIX system.
Louis
| |
| Michael Mattias 2007-06-03, 6:55 pm |
| Didn't I answer this last w ? Let me see if I still have that in the
'sent items' folder...
Damn, I THOUGHT so... it's below.
Also see this reference on character set cnversion with COBOL-produced data
at my website:
http://www.talsystems.com/tsihome_h...oads/C2IEEE.htm
--
Michael C. Mattias
Tal Systems Inc.
Racine WI
mmattias@talsystems.com
----- Original Message -----
From: "Michael Mattias" <mmattias@talsystems.com>
Newsgroups: comp.lang.cobol
Sent: Thursday, May 24, 2007 7:11 AM
Subject: Re: FTPing COMP-3 data from mainframe to UNIX
>
> The BINARY mode transfer is the correct mode to use, and it should be
> working. I do this all the time.
>
> I will guess you are running into EBCDIC/ASCII issues. When you transfer
> ASCII, *all* the data in each record are converted to ASCII, but that
> should not be done with COMP-3 data, explaining your problem with those
> fields. When you transfer BINARY, *none* of the data are converted to
> ASCII, which means the COMP-3 data are still readable but the DISPLAY data
> are not (still use EBCDIC) ; meaning you can read COMP-3 but not the
> display.
>
> What you need to due is EITHER
> - Make all the data in the record DISPLAY format and transfer ASCII
> OR
> - Convert all display data to ASCII on the mainframe (leaving the COMP-3
> fields alone) and transfer BINARY.
>
> And, you should probably confirm with your system administrators that the
> system is configured to do as I suspect: convert EBCDIC to ASCII when mode
> is ASCII and 'do nothing' when the mode is BINARY. I'm pretty sure this is
> the case, but it never hurts to check.
| |
| William M. Klein 2007-06-03, 6:55 pm |
| See the variety of answers given last w to this same question.
--
Bill Klein
wmklein <at> ix.netcom.com
"kimi" <mraghu83@gmail.com> wrote in message
news:1180874176.462134.117810@x35g2000prf.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 UNIX environment ( Solaris
> 8.1).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:
> Successfully reads the non-COMP data.
> COMP-3 data is read as a junk.
>
> The variable declaration in my cobol program is as follows:
> fs-abc S9(8) COMP-3.
> fs-xyz 9(2).
> FILLER X(73).
>
> I created a structure file using the DATA FILE EDITOR 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.
>
| |
|
| In article <1180880523.344921.270380@g37g2000prf.googlegroups.com>,
kimi <mraghu83@gmail.com> wrote:
>
>docdw...@panix.com () wrote:
[snip]
[color=darkred]
>
>Can you pls be more elaborate??
I'd not say I'm being so plain that I'd be  with the Amish... what
is it that you find too sparse or terse? What do you find missing from
the recent discussion of this very same matter in this very group?
DD
| |
|
| On Jun 3, 7:43 pm, Louis Krupp <lkr...@pssw.nospam.com.invalid> wrote:
> kimi wrote:
>
>
>
>
>
>
>
>
> Suppose your record were declared
>
> 01 rec.
> 05 n pic 9(2) comp-3.
> 05 s pic x(1).
>
> Suppose, in the original EBCDIC, n had the value 81, and s had the value
> 'a'. This is actually stored as hexadecimal '8181'.
>
> When ftp translates this to ASCII, it does it a byte at a time, and
> translates all EBCDIC a's to ASCII a's, so that now it is stored as
> hexadecimal '6161'. s is fine, but n is now 61.
>
> The best way to fix this is to copy the EBCDIC data to a record in which
> n is declared "pic 9(2) display" and then ftp the file to your UNIX system.
>
> Louis- Hide quoted text -
>
> - Show quoted text -
yeah we have tried this solution. It seems to be working .
But we are looking for a solution on UNIX environment itself.
To be specific we are looking for a solution through microfocus
commands.
I wanted to know if any command can do the job for me in microfocus??
I read somewhere that if you use microfocus u dont have to make any
modifications to the program , u can just run the application and it
works.
| |
|
| On Jun 5, 9:50 am, "William M. Klein" <wmkl...@nospam.netcom.com>
wrote:
> Micro Focus *does* (at least on Windows) have tools that will "intelligently"
> convert files from EBCDIC to ASCII. You need to provide the tools with the
> exact layout of the file - and if it has any redefinitions, then you need to be
> able to "predict" which redefinition is used.
>
> You, then, down-load the file in "binary" and convert only the "character" data
> from EBCDIC to ASCII.
>
> For more information on this Micro Focus utility, go to:
>
> http://supportline.microfocus.com/d...30/mx30indx.htm
>
> Find the book
> "Administrators Guide" and open it up
>
> Select
> Chapter 4: File Conversion Utilities
>
> and look at the information on:
> "MDECONV"
>
> * * * * * *
>
> To the best of my knowledge, this is NOT a part of any of the Unix products.
> However, if you contacted your Micro Focus sales, marketing, or technical
> support people, they might be able to tell you how you could acquire (purchase?)
> a copy for use with the Unix product.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com"kimi" <mragh...@gmail.com> wrote in message
>
> news:1180947696.994841.323310@i13g2000prf.googlegroups.com...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> - Show quoted text -
Thanks for your valuable inputs guys.
the MDECONV utility which you are referring to is available in
MAINFRAME EXPRESS, but we are using
SERVER EXPRESS 4.0..
I was thinking if running the cobol application in EBCDIC mode would
work..
ie. First I FTP the data file in binary mode and then change the mode
for running the application
from ASCII to EBCDIC..
There is a compiler option called "CHARSET" which can be used to
change it from ASCII to EBCDIC.
I wanted to know if anybod can give me inputs on how to use it exactly
in the command line..
Also, pls let me know if this idea is valid or not??
| |
| Lovelin 2007-06-05, 7:55 am |
| When you FTP files from EBDIC on a mainframe to ASCII. Comp-3 data
will be lost. Try to make it Display format. Comp-3 values are not
transalated correctly on the mainframe to PC conversion.
| |
|
| In article <1181028442.232060.80620@o5g2000hsb.googlegroups.com>,
kimi <mraghu83@gmail.com> wrote:
[snip]
>Thanks for your valuable inputs guys.
You're quite welcome; it might be helpful were you to respond with
something along the lines of 'I have tried (method) and the result was
(condition)'... see below.
>the MDECONV utility which you are referring to is available in
>MAINFRAME EXPRESS, but we are using
>SERVER EXPRESS 4.0..
>I was thinking if running the cobol application in EBCDIC mode would
>work..
>ie. First I FTP the data file in binary mode and then change the mode
>for running the application
>from ASCII to EBCDIC..
>There is a compiler option called "CHARSET" which can be used to
>change it from ASCII to EBCDIC.
What an interesting idea. What has happened when you tried such an
approach?'
>I wanted to know if anybod can give me inputs on how to use it exactly
>in the command line..
Documentation for command-line switches can be found both online and in
the physical manuals; have you checked Appendix E?
>Also, pls let me know if this idea is valid or not??
It certainly seems to be an interesting solution. What prevents you from
attempting to apply it in your Test environment?
DD
| |
|
| On Jun 5, 5:14 pm, "Michael Mattias" <mmatt...@talsystems.com> wrote:
> <docdw...@panix.com> wrote in messagenews:f43jqj$4ig$1@reader2.panix.com...
>
>
> Apparently he/she never listened to Yoda: "There is no try. Do; or do not."
>
> MCM
I did try this i get the same response as i got before.
ie. as i said when i ftp it in binary and run the application i am
able to read the COMP-3 data but the non COMP-3 data is still read as
junk.
I used the following command while compiling the program:
cob filename.cbl -C"CHARSET(EBCDIC)"
then i did run the application using the command
cobrun -F filename.int
no difference in the response.I wanted to make sure if the manner in
which i am using the CHARSET directive is right??
| |
|
| In article <atc9i.6480$u56.1762@newssvr22.news.prodigy.net>,
Michael Mattias <mmattias@talsystems.com> wrote:
><docdwarf@panix.com> wrote in message news:f43jqj$4ig$1@reader2.panix.com...
>
>
>Apparently he/she never listened to Yoda: "There is no try. Do; or do not."
What a thought... base your strategies on fictional extraterrestrials!
'Well, I *wanted* to bring it into Test... but there was this lump of
Kryptonite blocking the path...'
('Do or do not' is a rather succinct, geometric way to view the
universe... and, some would say, much more neat than all the messiness
involved with 'coming into existence'. I recall reading Newton when I was
a Kollidj-Kid and finding out that all of this 'calculus' stuff was based,
in part, on the assertion that during the coming-to-be the 'that which
could be said' about a point, a line and a curve were the same... put
things into a right different light, it did.)
DD
| |
|
| In article <1181046878.863892.222020@q66g2000hsg.googlegroups.com>,
kimi <mraghu83@gmail.com> wrote:
>On Jun 5, 5:14 pm, "Michael Mattias" <mmatt...@talsystems.com> wrote:
>
>I did try this i get the same response as i got before.
>ie. as i said when i ftp it in binary and run the application i am
>able to read the COMP-3 data but the non COMP-3 data is still read as
>junk.
Thanks much for this information... it is good to get a bit of feedback
every once in a while.
>
> I used the following command while compiling the program:
>cob filename.cbl -C"CHARSET(EBCDIC)"
>
>then i did run the application using the command
>cobrun -F filename.int
>
>no difference in the response.I wanted to make sure if the manner in
>which i am using the CHARSET directive is right??
I believe you can check that by looking at the compile's listing; that
should tell you which options are in effect. If you have access to the
..int files you may want to try the -A switch and query a few fields to see
what they really contain.
DD
| |
| Michael Mattias 2007-06-05, 7:55 am |
| <docdwarf@panix.com> wrote in message news:f43lff$n7u$1@reader2.panix.com...
> What a thought... base your strategies on fictional extraterrestrials!
If it ain't broke....
| |
|
| In article <p_c9i.6481$u56.1878@newssvr22.news.prodigy.net>,
Michael Mattias <mmattias@talsystems.com> wrote:
><docdwarf@panix.com> wrote in message news:f43lff$n7u$1@reader2.panix.com...
>
>If it ain't broke....
.... then it hasn't been properly stress-tested.
DD
| |
|
| On Jun 5, 5:46 pm, docdw...@panix.com () wrote:
> In article <1181046878.863892.222...@q66g2000hsg.googlegroups.com>,
>
>
>
>
>
> kimi <mragh...@gmail.com> wrote:
>
>
>
>
>
> Thanks much for this information... it is good to get a bit of feedback
> every once in a while.
>
>
>
>
>
>
> I believe you can check that by looking at the compile's listing; that
> should tell you which options are in effect. If you have access to the
> .int files you may want to try the -A switch and query a few fields to see
> what they really contain.
>
> DD- Hide quoted text -
>
> - Show quoted text -
I do have access to .int files... I did check the contents of file
using the data file editor using formatted mode; I can perfectly view
the contents of the file.
I did try the -A option, it gives no different result...The CHARSET
directive is very much effective...
| |
|
| In article <1181049309.725181.147700@m36g2000hse.googlegroups.com>,
kimi <mraghu83@gmail.com> wrote:
>On Jun 5, 5:46 pm, docdw...@panix.com () wrote:
[snip]
[color=darkred]
>
>I do have access to .int files... I did check the contents of file
>using the data file editor using formatted mode; I can perfectly view
>the contents of the file.
>I did try the -A option, it gives no different result...The CHARSET
>directive is very much effective...
Well, now you have some data... perhaps it might be time to relate them,
the one to the other.
You attempted to apply CHARSET"EBCDIC" and the results of the run were
unsatisfactory.
You verified that CHARSET"EBCDIC" was, in fact, 'very much effective' and
the results were unsatisfactory.
So... if you succeeded in applying a change to your program's compile
options and the program does not do what you want it to do after this
change has been made... what might be concluded about the change?
DD
| |
| Dan van Ginhoven 2007-06-05, 9:55 pm |
| Hi!
A simple solution to the problem is
* On the mainframe write a simple cobol program that reads the file and
rewrites it to a new file where all fields are in display format.
* FTP the file to Unix with ascci conversion
* On Unix create a simple cobol program that reads the ASCII file and
rewrites the file in the desired format.
MFC Cobol Variable and fix files have an internal MFC format on Unix.
They should not be used with standard line sequential utilities like vi,
grep, wc and so forth. A line sequential file (record delimiter = x'0A' )
can not contain binary data lika comp and comp-3.
/dg
| |
| William M. Klein 2007-06-06, 3:55 am |
| I am tired of the thread. If you
1) Download in binary
2) compile with CHARSET(EBCDIC)
3) run the program,
It will "run correctly" in EBCDIC mode - but remember that means that not only
you INPUT but also YOUR OUTPUT will be EBCDIC. Depending on what makes you
think the program isn't "working right" - this is a likely cause.
You might want to consider using the CODESET clause for your output file - but
if it has any COMP data, things still won't work.
Have you contacted your Micro Focus rep as I previously suggested and asked if
you could purchase a copy of MDECONV?
If not, then you need to create your own separate program (either on the
mainframe or the PC) to convert your data to display (as you have been told by
every responder on the list) and process the data that way.
NOTE WELL:
Running with CHARSET(EBCDIC) means that everything is done in EBCDIC -
including comparisons key handling etc..
--
Bill Klein
wmklein <at> ix.netcom.com
"kimi" <mraghu83@gmail.com> wrote in message
news:1181049309.725181.147700@m36g2000hse.googlegroups.com...
> On Jun 5, 5:46 pm, docdw...@panix.com () wrote:
>
> I do have access to .int files... I did check the contents of file
> using the data file editor using formatted mode; I can perfectly view
> the contents of the file.
> I did try the -A option, it gives no different result...The CHARSET
> directive is very much effective...
>
| |
| jwest@datacenterinc.com 2007-06-08, 6:55 pm |
| On Jun 3, 7:36 am, kimi <mragh...@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 UNIX environment ( Solaris
> 8.1).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:
> Successfully reads the non-COMP data.
> COMP-3 data is read as a junk.
>
> The variable declaration in my cobol program is as follows:
> fs-abc S9(8) COMP-3.
> fs-xyz 9(2).
> FILLER X(73).
>
> I created a structure file using the DATA FILE EDITOR 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.
| |
| jwest@datacenterinc.com 2007-06-08, 6:55 pm |
|
Your best option whenever dealing with packed data (comp fields) is to
FTP the file in a binary mode. Then code your program so that the file
is accessed in both an ASCII as well as and EBCDIC mode. Access the
packed fields from your ASCII file and the EBCDIC fields from your
translated file. Just be certain you use the correct field. Here's a
sample program.
$set foldcallname"LOWER"
$set list
identification division.
program-id. tst000.
* author. jwest.
* date-written. 6-8-2007.
*
environment division.
configuration section.
source-computer. unix.
object-computer. unix.
special-names. ebcdic-data is ebcdic.
*
input-output section.
select tstx-file assign to "TSTFIL".
select tst-file assign to "TSTFIL".
*
data division.
file section.
fd tstx-file
code-set is ebcdic-data.
01 tstx-record.
03 tstx-field-01 pic x(001).
03 tstx-field-02 pic s9(003) comp-3.
*
fd tst-file.
01 tst-record.
03 tst-field-01 pic x(001).
03 tst-field-02 pic s9(003) comp-3.
*
working-storage section.
*
01 ws-work-fields.
03 ws-rec-count pic 9(06).
*
procedure division.
*
mainline.
open input tstx-file.
open input tst-file.
perform 1000-process-tst thru
1090-process-tst-exit.
close tstx-file.
close tst-file.
display "Number of records processed: "ws-rec-count.
stop run.
*
1000-process-tst.
move zeros to ws-rec-count.
*
1010-next-record.
read tst-file
at end
go to 1090-process-tst-exit.
read tstx-file
at end
display "Invalid 'EOF' - Should never get here"
stop 900
go to 1090-process-tst-exit.
perform 1030-display-record.
add 1 to ws-rec-count.
go to 1010-next-record.
*
1030-display-record.
exhibit named tstx-field-01.
exhibit named tst-field-02.
stop 500.
*
1090-process-tst-exit.
exit.
| |
| William M. Klein 2007-06-08, 6:55 pm |
| Some compiler MIGHT allow this, but the Standard rules of the CODE-SET clause
state that it may ONLY be used for files with all DISPLAY data (not COMP-?).
--
Bill Klein
wmklein <at> ix.netcom.com
<jwest@datacenterinc.com> wrote in message
news:1181320887.419116.318570@p47g2000hsd.googlegroups.com...
>
> Your best option whenever dealing with packed data (comp fields) is to
> FTP the file in a binary mode. Then code your program so that the file
> is accessed in both an ASCII as well as and EBCDIC mode. Access the
> packed fields from your ASCII file and the EBCDIC fields from your
> translated file. Just be certain you use the correct field. Here's a
> sample program.
>
> $set foldcallname"LOWER"
> $set list
> identification division.
> program-id. tst000.
> * author. jwest.
> * date-written. 6-8-2007.
> *
> environment division.
> configuration section.
> source-computer. unix.
> object-computer. unix.
> special-names. ebcdic-data is ebcdic.
> *
> input-output section.
> select tstx-file assign to "TSTFIL".
> select tst-file assign to "TSTFIL".
> *
> data division.
> file section.
> fd tstx-file
> code-set is ebcdic-data.
> 01 tstx-record.
> 03 tstx-field-01 pic x(001).
> 03 tstx-field-02 pic s9(003) comp-3.
> *
> fd tst-file.
> 01 tst-record.
> 03 tst-field-01 pic x(001).
> 03 tst-field-02 pic s9(003) comp-3.
> *
> working-storage section.
> *
> 01 ws-work-fields.
> 03 ws-rec-count pic 9(06).
> *
> procedure division.
> *
> mainline.
> open input tstx-file.
> open input tst-file.
>
> perform 1000-process-tst thru
> 1090-process-tst-exit.
>
> close tstx-file.
> close tst-file.
>
> display "Number of records processed: "ws-rec-count.
>
> stop run.
> *
> 1000-process-tst.
> move zeros to ws-rec-count.
> *
> 1010-next-record.
> read tst-file
> at end
> go to 1090-process-tst-exit.
>
> read tstx-file
> at end
> display "Invalid 'EOF' - Should never get here"
> stop 900
> go to 1090-process-tst-exit.
>
> perform 1030-display-record.
>
> add 1 to ws-rec-count.
>
> go to 1010-next-record.
> *
> 1030-display-record.
> exhibit named tstx-field-01.
> exhibit named tst-field-02.
> stop 500.
> *
> 1090-process-tst-exit.
> exit.
>
| |
|
|
|
|
|
|
|
|
|
|
|
|