All X'0D' lost during reading line sequential file using microfocus se
taoxi...@gmail.com
I'm writing a batch source to match 2 input files which is exported
from AIX DB2 giving the matched records.
All other characters are going well except X'0D':all of them get lost
when reading the input files into the program. I tried many file
handler options and runtime switches but no one worked. Any advice is
appreaciated. Thanks in advance!
Line sequential file, variable-length record.
This is the file handler I'm using now:
[XFH-DEFAULT]
STRIPSPACE=OFF
INSERTNULL=OFF
EXPANDTAB=OFF
AIX 5.3, Microfocus Server Express 5.0
Robert
Define the file as record sequential, record length 512, and parse the lines yourself. The
last short block is a little tricky.
Howard Brazee
the option of saving a text file about a dozen different ways. (Mac,
Unix, various Unicode, Windows, line-feed, form-feed).
I'm wondering if there are similar free or cheap utilities that can do
this kind of conversion on your platform.
Richard
> Hi all
>
> I'm writing a batch source to match 2 input files which is exported
> from AIX DB2 giving the matched records.
>
> All other characters are going well except X'0D':all of them get lost
> when reading the input files into the program. I tried many file
> handler options and runtime switches but no one worked. Any advice is
> appreaciated. Thanks in advance!
>
> Line sequential file, variable-length record.
LINE SEQUENTIAL is defined as being variable records where the end of
each record is indicated (on AIX) by a x'0D' character. These are
added automatically when writing and stripped off when reading.
You have specified that the file is 'line sequential' and then
complain when you get the designated behavior.
Specify the file like this:
SELECT TextFile
ASSIGN whatever
ORGANIZATION LINE SEQUENTIAL
FILE STATUS ..
.
DATA DIVISION.
FILE SECTION.
FD TextFile
RECORD VARYING FROM 0 TO 256 DEPENDING ON TSize.
01 TextLine.
03 TLc PIC X(256).
TSize will contain the record length. You can insert a x"0D" after
that or use reference modification on the compares, or just compare
lengths.
taoxi...@gmail.com
>
> - Show quoted text -
Do you mean fixed-length record sequential? The record exported from
AIX DB2 is variable-length so I think it will be even worse.
taoxi...@gmail.com
We are restricted to solving the problem within the cobol program, not
to mention the Mac editor...
Thanks anyway
taoxi...@gmail.com
I don't agree.Isn't line sequential file delimited by X'0A'?
These are the documentation I referred:
(JP)http://www.microfocus.co.jp/manuals/SE40/fhorgs.htm
(EN)http://supportline.microfocus.com/Documentation/books/sx50/
sx50indx.htm
Line Sequential Files
The primary use of line sequential files (which are also known as
"text files" or "ASCII files") is for display-only data. Most PC
editors, for example Notepad, produce line sequential files.
In a line sequential file, each record in the file is separated from
the next by a record delimiter. The record delimiter, which is the
line feed (x"0A") character, is inserted after the last non-space
character in each record. A WRITE statement removes trailing spaces
from the data record and appends the record delimiter. A READ
statement removes the record delimiter and, if necessary, pads the
data record (with trailing spaces) to the record size defined by the
program reading the data.
To define a file as line sequential, specify ORGANIZATION IS LINE
SEQUENTIAL in the SELECT clause for the file in your COBOL program,
for example:
select lineseq assign to "lineseq.dat"
organization is line sequential.
Or could you give me the documentation link saying that line
sequential file is delimited by X'0D'?
Thank you very much
Robert
A variable length record is just a string of bytes terminated by x'0D'. Line sequential
parses the records for you. You are complaining about that. Line sequential just gives you
512 bytes of raw data, allowing you to parse them yourself.
Is the problem that you don't know the length of an input line sequential record? Why do
you care? The tail end will be filled with spaces. You COULD search right to left for a
non-space, or follow Richard's instructions for getting the length.
Robert
>I don't agree.Isn't line sequential file delimited by X'0A'?
The operating system, not Cobol, specifies the line terminator. AIX and other Unix use
x'0D'. Old Macs (OS9) used 0A. Windows uses 0D0A.
A FILE is delimited by its size (in the directory), not by a character. If your textbook
says a file is terminated by 0A or 1A, it is 25 years out of date.
taoxi...@gmail.com
> On Thu, 24 Jul 2008 18:34:40 -0700 (PDT), taoxianf...@gmail.com wrote:
> >I don't agree.Isn't line sequential file delimited by X'0A'?
>
> The operating system, not Cobol, specifies the line terminator. AIX and other Unix use
> x'0D'. Old Macs (OS9) used 0A. Windows uses 0D0A.
>
> A FILE is delimited by its size (in the directory), not by a character. If your textbook
> says a file is terminated by 0A or 1A, it is 25 years out of date.
Well...seems I failed to address it clearly.Let's read MY code:
SELECT INFILE1
ORGANIZATION IS LINE SEQUENTIAL
ASSIGN TO EXTERNAL INFILE1.
FD INFILE1
DATA RECORD IS IN-REC1
RECORDING MODE V
RECORD IS VARYING IN SIZE FROM 1 TO 5000
DEPENDING ON WK-INREC1-LEN
BLOCK CONTAINS 0.
01 IN-REC1 PIC X(5000).
…………
01 WK-INREC1-LEN PIC 9(008).
1. The RECORD LENGTH will be stored into the WK-INREC1-LEN variable
automatically when executing "READ INFILE1" each time. And, believe
or
not, it's decided by X'0A' like that(the input read counter also
proves it):
1 dot for 1 byte;0D for 1 byte
......0D.....0A (record length:12)
...0D......0D....0A (record length:14)
I know the rest of IN-REC1 is filled by space (or nothing if using
SPACEFILL=OFF); I also know the method of searching for the 1st non-
space reading from right to left. BUT I DON'T NEED THEM since I have
no problem about the length of each record.
2.The doc I referred to is saying "The record delimiter, which is the
line feed (x"0A") character". I didn't mean file delimiter(EOF,X'1A'
or something else) either.
I'm just talking about RECORD DELIMITER or LINE DELIMITER and
doubting
your "AIX and other Unix use x'0D'".
3.Take the example again, my ESSENTIAL QUESTION is ALL X'0D' WERE
LOST
LIKE THIS:
input file:
......0D.....0A
...0D......0D....0A
output file:
...........0A
.............0A
IF, the record is delimited with X'0D' as you said, then how can I
get
it in the output file since it exists in the input file?
Richard
Sequential fixed length files have nothing but the data bytes, no
header or termination bytes. Defining the file as sequential with a
fixed length will allow you to read (and write) whatever bytes you
want but it will read <record size> bytes and you will get an
exception on the last record because it does not fill the record
buffer. You can have single byte sequential to avoid the last record
problem, but it may be somewhat slow.
Set up the file as sequential with single byte record and read into a
buffer in W-S until you find the record terminator.
taoxi...@gmail.com
>
> - Show quoted text -
umm...It should be an approach.Probably a bit slow. I will have a try.
Thank you very much.
William M. Klein
as the record delimiter for line sequential files. (Something that is
"operating system" and/or application dependent). Your desire is to be able to
have X"0D" *data* in LINE SEQUENTIAL files.
From a "usually reliable source" Micro Focus *does* support (allow) this. The
following is the solution that I was provided:
***
"File Handler configuration option LSRECDELIM set in EXTFH.CFG can be used to
set the record delimiter used for LSEQ files.
Syntax:
LSRECDELIM=[0A|0D0A]
Parameters:
0A The hexadecimal character x"0A" is used as the record delimiter for line
sequential files.
0D0A The hexadecimal characters x"0D0A" are used as the record delimiter for
line sequential files."
--
Bill Klein
wmklein <at> ix.netcom.com
<taoxi...@gmail.com> wrote in message
news:75979a92-6155-4583...@v39g2000pro.googlegroups.com...
Bill Gunshannon
Robert <n...@e.mail> writes:
> On Thu, 24 Jul 2008 18:34:40 -0700 (PDT), taoxi...@gmail.com wrote:
>
>>I don't agree.Isn't line sequential file delimited by X'0A'?
>
> The operating system, not Cobol, specifies the line terminator. AIX and other Unix use
> x'0D'. Old Macs (OS9) used 0A. Windows uses 0D0A.
Ummm... No... Unix has always used 0x0A and I would be very surprised if
AIX used anything different.
>
> A FILE is delimited by its size (in the directory), not by a character. If your textbook
> says a file is terminated by 0A or 1A, it is 25 years out of date.
That would depend on a number of things primary of which would be the OS.
Windows still supports FAT and FAT had two differnt kinds of text files.
One delimited by size and one that ended upon the reaching a ^Z. There
was no way I am aware of to determine which method a file used without
examining the file. This caused a lot of headaches for people writing
file transfer software as using the wrong method usually reulted in
garbage on the end of the file.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Robert
>On Jul 25, 1:05 pm, Robert <n...@e.mail> wrote:
>> On Thu, 24 Jul 2008 18:34:40 -0700 (PDT), taoxianf...@gmail.com wrote:
>> >I don't agree.Isn't line sequential file delimited by X'0A'?
>>
>> The operating system, not Cobol, specifies the line terminator. AIX and other Unix use
>> x'0D'. Old Macs (OS9) used 0A. Windows uses 0D0A.
>>
>> A FILE is delimited by its size (in the directory), not by a character. If your textbook
>> says a file is terminated by 0A or 1A, it is 25 years out of date.
>
>Well...seems I failed to address it clearly.Let's read MY code:
>
> SELECT INFILE1
> ORGANIZATION IS LINE SEQUENTIAL
> ASSIGN TO EXTERNAL INFILE1.
>
> FD INFILE1
> DATA RECORD IS IN-REC1
> RECORDING MODE V
> RECORD IS VARYING IN SIZE FROM 1 TO 5000
> DEPENDING ON WK-INREC1-LEN
> BLOCK CONTAINS 0.
> 01 IN-REC1 PIC X(5000).
>…………
> 01 WK-INREC1-LEN PIC 9(008).
Most of those FD clauses are superfluous for LINE SEQUENTIAL. You should have written
FD INFILE1 RECORD VARYING FROM 1 TO 5000 DEPENDING ON WK-INREC1-LEN.
BLOCK CONTAINS 0 is a silly mainframeism.
>1. The RECORD LENGTH will be stored into the WK-INREC1-LEN variable
>automatically when executing "READ INFILE1" each time. And, believe
>or
>not, it's decided by X'0A' like that(the input read counter also
>proves it):
>
>1 dot for 1 byte;0D for 1 byte
>......0D.....0A (record length:12)
>...0D......0D....0A (record length:14)
>I know the rest of IN-REC1 is filled by space (or nothing if using
>SPACEFILL=OFF); I also know the method of searching for the 1st non-
>space reading from right to left. BUT I DON'T NEED THEM since I have
>no problem about the length of each record.
I'm happy to see you took Richard's suggestion.
>2.The doc I referred to is saying "The record delimiter, which is the
>line feed (x"0A") character". I didn't mean file delimiter(EOF,X'1A'
>or something else) either.
>
>
>I'm just talking about RECORD DELIMITER or LINE DELIMITER and
>doubting
>your "AIX and other Unix use x'0D'".
You are correct; I got them backwards. 0A is Unix, 0D is Mac.
>3.Take the example again, my ESSENTIAL QUESTION is ALL X'0D' WERE
>LOST
>LIKE THIS:
>input file:
>......0D.....0A
>...0D......0D....0A
>
>
>output file:
>...........0A
>.............0A
>
>
>IF, the record is delimited with X'0D' as you said, then how can I
>get
>it in the output file since it exists in the input file?
The reasons are:
1. Characters less than x'20' (space) are Control Characters, not data.
They are instructions to the file system.
2. Due to non-standardization, most file systems are generalized to handle formats from
other operating systems. Most Unix programs, with the notable exception of vi, can read
Windows files terminated by 0D0A. Most Windows programs can read Unix-style files
terminated by 0A.
The discarding of your 0Ds is a side-effect of that generalization.
This assignment appears to be a 'trick question' to teach you that different operating
systems use different standards.
Now let's look at solutions. Bill Klein showed how to specialize the Micro Focus file
system to recognize only 0A. That's specific to Micro Focus, not Cobol. A Unix flavored
solution would be to run the input file through the 'tr' program before piping it into
your Cobol program, like this:
cat INFILE1 | tr "\r| "\v" | yourcobol | tr "\v" "\r" > OUTFILE1
Confusing, right? It is translating 0D (Ctrl-M = return) into 0B (Ctrl-K = vertical tab)
before your program and translating it back after.
My suggestion to parse lines yourself, recognizing only 0A, is pure Cobol. It will work
with any compiler, on any machine. To handle the last sector on Micro Focus,
1. Initialize the record area to low-values (binary zeros)
2. Read
3. If return-code - '92' *> short record
remember you are at end of file
search backward for the first non-low-value to get sector length
taoxi...@gmail.com
wrote:
> OK, I think I understand the "desire". You want to use X"0A" but *not* X"0D0A"
> as the record delimiter for line sequential files. (Something that is
> "operating system" and/or application dependent). Your desire is to be able to
> have X"0D" *data* in LINE SEQUENTIAL files.
>
> From a "usually reliable source" Micro Focus *does* support (allow) this. The
> following is the solution that I was provided:
> ***
> "File Handler configuration option LSRECDELIM set in EXTFH.CFG can be used to
> set the record delimiter used for LSEQ files.
>
> Syntax:
>
> LSRECDELIM=[0A|0D0A]
>
> Parameters:
>
> 0A The hexadecimal character x"0A" is used as the record delimiter for line
> sequential files.
>
> 0D0A The hexadecimal characters x"0D0A" are used as the record delimiter for
> line sequential files."
>
> --
> Bill Klein
>
> news:75979a92-6155-4583...@v39g2000pro.googlegroups.com...
>
>
>
> > Hi all
>
> > I'm writing a batch source to match 2 input files which is exported
> > from AIX DB2 giving the matched records.
>
> > All other characters are going well except X'0D':all of them get lost
> > when reading the input files into the program. I tried many file
> > handler options and runtime switches but no one worked. Any advice is
> > appreaciated. Thanks in advance!
>
> > Line sequential file, variable-length record.
>
> > This is the file handler I'm using now:
> > [XFH-DEFAULT]
> > STRIPSPACE=OFF
> > INSERTNULL=OFF
> > EXPANDTAB=OFF
>
>
> - Show quoted text -
Thanks for you advice. But I tried it and the result is the same. I
think the LSRECDELIM option just affect the record delimiter (0A or
0D0A) but failed to change something for a single 0D.
taoxi...@gmail.com
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
I have thought of transforming the data with shell at the beginning of
this assignment. But as I said before, I'm restricted to handle it
with in the cobol source. Maybe I should try to persuade my boss since
it would be easier with some shell script.
About parsing the line by myself, I agree that it's a "simple and
stupid" approach which fit for most situations. I will take this.
Thank you very much.
Robert
>In article <e5ji84te3em3ejs7b...@4ax.com>,
> Robert <n...@e.mail> writes:
>> On Thu, 24 Jul 2008 18:34:40 -0700 (PDT), taoxi...@gmail.com wrote:
>>
>>>I don't agree.Isn't line sequential file delimited by X'0A'?
>>
>> The operating system, not Cobol, specifies the line terminator. AIX and other Unix use
>> x'0D'. Old Macs (OS9) used 0A. Windows uses 0D0A.
>
>Ummm... No... Unix has always used 0x0A and I would be very surprised if
>AIX used anything different.
>
>>
>> A FILE is delimited by its size (in the directory), not by a character. If your textbook
>> says a file is terminated by 0A or 1A, it is 25 years out of date.
>
>That would depend on a number of things primary of which would be the OS.
>Windows still supports FAT and FAT had two differnt kinds of text files.
>One delimited by size and one that ended upon the reaching a ^Z. There
>was no way I am aware of to determine which method a file used without
>examining the file. This caused a lot of headaches for people writing
>file transfer software as using the wrong method usually reulted in
>garbage on the end of the file.
1A ceased marking end of file with MSDOS 2.0, 25 years ago. Ctrl-Z now means Undo under
Windows and Suspend Task under Unix.
William M. Klein
--
Bill Klein
wmklein <at> ix.netcom.com
<taoxi...@gmail.com> wrote in message
news:c6cb331a-8e7d-493a...@j7g2000prm.googlegroups.com...
William M. Klein
received which states,
" ...the information you are after is there but hidden away in the
documentation. The File Handler configuration option INSERTNULL allows any
character to be added to a line sequential file by adding a null character
before each character less than x"20". These then get stripped out on the read.
Again this is not documented fully in the INSERTNULL documentation but is in the
documentation for the "N run-time switch"
Therefore, it seems that a READ (with MF and Line Sequential) will ALWAYS "strip
away" characters < X"20".
--
Bill Klein
wmklein <at> ix.netcom.com
<taoxi...@gmail.com> wrote in message
news:c6cb331a-8e7d-493a...@j7g2000prm.googlegroups.com...
Bill Gunshannon
Robert <n...@e.mail> writes:
> On 25 Jul 2008 15:42:42 GMT, bill...@cs.uofs.edu (Bill Gunshannon) wrote:
>
>>In article <e5ji84te3em3ejs7b...@4ax.com>,
>> Robert <n...@e.mail> writes:
>>> On Thu, 24 Jul 2008 18:34:40 -0700 (PDT), taoxi...@gmail.com wrote:
>>>
>>>>I don't agree.Isn't line sequential file delimited by X'0A'?
>>>
>>> The operating system, not Cobol, specifies the line terminator. AIX and other Unix use
>>> x'0D'. Old Macs (OS9) used 0A. Windows uses 0D0A.
>>
>>Ummm... No... Unix has always used 0x0A and I would be very surprised if
>>AIX used anything different.
>>
>>>
>>> A FILE is delimited by its size (in the directory), not by a character. If your textbook
>>> says a file is terminated by 0A or 1A, it is 25 years out of date.
>>
>>That would depend on a number of things primary of which would be the OS.
>>Windows still supports FAT and FAT had two differnt kinds of text files.
>>One delimited by size and one that ended upon the reaching a ^Z. There
>>was no way I am aware of to determine which method a file used without
>>examining the file. This caused a lot of headaches for people writing
>>file transfer software as using the wrong method usually reulted in
>>garbage on the end of the file.
>
> 1A ceased marking end of file with MSDOS 2.0, 25 years ago.
Hardly. Ity is not a part of DOS, it is a part of FAT and that is till
with us and probably will be for quite some time still.
> Ctrl-Z now means Undo under
> Windows and Suspend Task under Unix.
That is just what certain applications do with it. Undo is not a Windows
command, it is something the various editors understand. And You Unix
example is totally dependant on the shell in use as some of them do not
support job control at all.
Try this experiment!
On your Windows Box open a window for command.com.
type "COPY CON: JUNK"
type in a few lines of text.
at some point, type ^Z (that's the control key and the letter "Z").
hit return.
Notice you are back to prompt and you now have the file JUNK containing
what you typed.
Again, this is behavior of the terminal driver but basicly it is
that driver interpreting the ^Z as EOF on CON: and terminating the copy.
I do not expect this behavior to ever go away in the MS world as long
as we have keyboards for input!!
docd...@panix.com
Robert <n...@e.mail> wrote:
>On 25 Jul 2008 15:42:42 GMT, bill...@cs.uofs.edu (Bill Gunshannon) wrote:
[snip]
>>Windows still supports FAT and FAT had two differnt kinds of text files.
>>One delimited by size and one that ended upon the reaching a ^Z. There
>>was no way I am aware of to determine which method a file used without
>>examining the file. This caused a lot of headaches for people writing
>>file transfer software as using the wrong method usually reulted in
>>garbage on the end of the file.
>
>1A ceased marking end of file with MSDOS 2.0, 25 years ago. Ctrl-Z now
>means Undo under
>Windows and Suspend Task under Unix.
Mr Wagner, here's a little experiment you might want to try on a Windows
machine:
Start ==> Run ==> cmd
copy con hexfile
this is a test <== press Enter key
^Z <== control-Z
... and see how Windows handles what you assert is an Undo.
DD
taoxi...@gmail.com
off now) in the extfh config file
and the N runtime switch(default is on).
All the other characters less than X'20' were successfully outputted
with a X'00' (null) before them.
BUT THE X'0D' STILL DISAPPEARED. I really can't believe this and I'm
getting confused why some file handler
options and runtime switches seem to be conflicting or doing the same
thing, such as:
INSERTNULL and N runtime switch
EXPANDTAB/INSERTTAB and T runtime switch
and the file handler options have higher priority.
Who can explain it?
On Jul 26, 12:22 pm, "William M. Klein" <wmkl...@nospam.netcom.com>
wrote:
> I think the additional information that you need was in another note that I
> received which states,
>
> " ...the information you are after is there but hidden away in the
> documentation. The File Handler configuration option INSERTNULL allows any
> character to be added to a line sequential file by adding a null character
> before each character less than x"20". These then get stripped out on the read.
> Again this is not documented fully in the INSERTNULL documentation but is in the
> documentation for the "N run-time switch"
>
> Therefore, it seems that a READ (with MF and Line Sequential) will ALWAYS "strip
> away" characters < X"20".
>
> --
> Bill Klein
> 0D0A) but failed to change something for a single 0D.- Hide quoted text -
Robert
>In article <5f2l849u1mjm8b5ag...@4ax.com>,
> Robert <n...@e.mail> writes:
>> On 25 Jul 2008 15:42:42 GMT, bill...@cs.uofs.edu (Bill Gunshannon) wrote:
>> 1A ceased marking end of file with MSDOS 2.0, 25 years ago.
>
>Hardly. Ity is not a part of DOS, it is a part of FAT and that is till
>with us and probably will be for quite some time still.
>
>> Ctrl-Z now means Undo under
>> Windows and Suspend Task under Unix.
>
>That is just what certain applications do with it. Undo is not a Windows
>command, it is something the various editors understand. And You Unix
>example is totally dependant on the shell in use as some of them do not
>support job control at all.
>
>Try this experiment!
>
>On your Windows Box open a window for command.com.
>type "COPY CON: JUNK"
>type in a few lines of text.
>at some point, type ^Z (that's the control key and the letter "Z").
>hit return.
>Notice you are back to prompt and you now have the file JUNK containing
>what you typed.
I did that, then looked at the file with a hex editor. There wasn't a 1A at the end. I
changed one of the characters in the middle to 1A, saved it, looked at it, 1A was still in
the middle of the line. Then I copied it and looked at the copy. 1A was still in the
middle and there was stuff after it. If 1A designated end of file, the stuff after it
would be missing. However, 'type junk' and 'copy junk con' DID terminate on the 1A.
I brought up a Unix shell -- ch -- under command.com. 'cat junk' DID stop on the 1A, but
vi showed ^Z and cp copied the stuff following and 'wc -c junk' counted all. More
baffling, 'cat junk >junk1' copied the 1A and the stuff following.
It seems 1A means end of file on the console, not on disk files.
Michael Mattias
news:u5im84d8rkk8mfioc...@4ax.com...
> On 26 Jul 2008 13:47:04 GMT, bill...@cs.uofs.edu (Bill Gunshannon) wrote:
> It seems [hex] 1A means end of file on the console, not on disk files.
It means end of file only to an application which wants it to mean end of
file.
To many ancient applications, x'1A' does mean end of file... it started with
applications first written for the CP/M operating system and early MS-DOS
applications which DID use x'1A' as an end-of-file marker. I think that
stopped with MS-DOS 2.0, but some applications still retain the logic of
"x'1A'=EOF"
(Remember using EDLIN? you could either type Ctrl+Z or use one of the
function keys (F6?) which did the same thing.)
MCM
William M. Klein
ask this questions is via supportline.
HOWEVER, the bottom-line is that if you define a file as line sequential, then
you will have problems trying to read records that include (as data) bytes with
characters less than X"20". This is documented - even if not well.
Treating the file as Record Sequential and "building" it yourself will work (as
you have indicated). However, there is also the question of HOW and WHY you
have "line sequential" files with X'0D" "data" or any other bytes with < X"20".
These may cause problems with other applications - not just Micro Focus COBOL
(as the X"1?" notes in this thread have indicated and as previous notes
discussing "tabs" have indicated.)
--
Bill Klein
wmklein <at> ix.netcom.com
<taoxi...@gmail.com> wrote in message
news:a1910703-f28b-44d8...@k36g2000pri.googlegroups.com...
HeyBub
>>
>> Set up the file as sequential with single byte record and read into a
>> buffer in W-S until you find the record terminator.- Hide quoted
>> text -
>>
>> - Show quoted text -
>
> umm...It should be an approach.Probably a bit slow. I will have a try.
>
> Thank you very much.
A "bit slow" ain't the half of it.
Fortunately, our compiler has a method of reading a file given
{starting-byte} {length of string to read}. To read the file sequentially we
do:
MOVE 0 TO START-BYTE
MOVE 32000 TO LENGTH-STRING.
PERFORM UNTIL TOO-TIRED
(read the file using START-BYTE and LENGTH-STRING)
(determine length of record - ours ends with a TAB character)
(process record)
ADD LENGTH-OF-RECORD TO START-BYTE
END-PERFORM
Richard
> "Robert" <n...@e.mail> wrote in message
>
> news:u5im84d8rkk8mfioc...@4ax.com...
>
> > It seems [hex] 1A means end of file on the console, not on disk files.
>
> It means end of file only to an application which wants it to mean end of
> file.
>
> To many ancient applications, x'1A' does mean end of file... it started with
> applications first written for the CP/M operating system and early MS-DOS
> applications which DID use x'1A' as an end-of-file marker. I think that
> stopped with MS-DOS 2.0, but some applications still retain the logic of
> "x'1A'=EOF"
>
> (Remember using EDLIN? you could either type Ctrl+Z or use one of the
> function keys (F6?) which did the same thing.)
CP/M 1.x to 2.x files only held the end of file as a sector number so
all file sizes were multiples of 128 bytes. Applications, such as text
editors filled the last sector beyond the actual data with 0x1A as a
convention.
MS-DOS, even 1.0, did have the file size in bytes but many
applications were converted from CP/M, or had versions for CP/M, and
still used 0x1A. Even edlin was originally written for CP/M.
Richard
wrote:
> If you are current on your Micro Focus support (i.e. paid up), then the place to
> ask this questions is via supportline.
>
> HOWEVER, the bottom-line is that if you define a file as line sequential, then
> you will have problems trying to read records that include (as data) bytes with
> characters less than X"20". This is documented - even if not well.
>
> Treating the file as Record Sequential and "building" it yourself will work (as
> you have indicated). However, there is also the question of HOW and WHY you
> have "line sequential" files with X'0D" "data" or any other bytes with < X"20".
> These may cause problems with other applications - not just Micro Focus COBOL
> (as the X"1?" notes in this thread have indicated and as previous notes
> discussing "tabs" have indicated.)
>
> --
> Bill Klein
> Actually I have also tried INSERTNULL=ON (default is on and I'm using
> off now) in the extfh config file
> and the N runtime switch(default is on).
> All the other characters less than X'20' were successfully outputted
> with a X'00' (null) before them.
> BUT THE X'0D' STILL DISAPPEARED. I really can't believe this and I'm
> getting confused why some file handler
> options and runtime switches seem to be conflicting or doing the same
> thing, such as:
>
> INSERTNULL and N runtime switch
> EXPANDTAB/INSERTTAB and T runtime switch
>
> and the file handler options have higher priority.
> Who can explain it?
The N and T runtime switch usage dates back to MF's Level II COBOL on
1982 and has been retained for compatability reasons in every MF Cobol
since.
taoxi...@gmail.com
support. I will try to
contact them through my boss.
I'm also wondering why these characters less than X'20' are inlcuded
in the data such as 0A,0D,09.
Take 0A for example, sometimes a db2 record is exported like that:
"xxx",1234,"...0A
..."
I have to count the quotation marks to determine if a record is
divided into several lines and
combine them together.
But at present, the most suprising point is, all the characters less
than X'20' EXCEPT X'0D'
are handled correctly. What on earch is the particularity of X'0D'?
On Jul 27, 3:26 am, "William M. Klein" <wmkl...@nospam.netcom.com>
wrote:
> If you are current on your Micro Focus support (i.e. paid up), then the place to
> ask this questions is via supportline.
>
> HOWEVER, the bottom-line is that if you define a file as line sequential, then
> you will have problems trying to read records that include (as data) bytes with
> characters less than X"20". This is documented - even if not well.
>
> Treating the file as Record Sequential and "building" it yourself will work (as
> you have indicated). However, there is also the question of HOW and WHY you
> have "line sequential" files with X'0D" "data" or any other bytes with < X"20".
> These may cause problems with other applications - not just Micro Focus COBOL
> (as the X"1?" notes in this thread have indicated and as previous notes
> discussing "tabs" have indicated.)
>
> --
> Bill Klein
> > - Show quoted text -- Hide quoted text -
taoxi...@gmail.com
handled differently
under this way?
I will have a try. Thanks.
On Jul 27, 6:07 am, "HeyBub" <hey...@NOSPAMgmail.com> wrote:
Robert
>I'm new to that project so not quite clear about the Microfocus
>support. I will try to
>contact them through my boss.
>
>I'm also wondering why these characters less than X'20' are inlcuded
>in the data such as 0A,0D,09.
>Take 0A for example, sometimes a db2 record is exported like that:
>"xxx",1234,"...0A
>..."
>I have to count the quotation marks to determine if a record is
>divided into several lines and
>combine them together.
>
>But at present, the most suprising point is, all the characters less
>than X'20' EXCEPT X'0D'
>are handled correctly. What on earth is the particularity of X'0D'?
0D is Carriage Return. It is used in the combination 0D0A on Windows. Apparently Micro
Focus simplified end of record detection by discarding 0D and looking for 0A.
DB2 is mainframe, not Unix. If your files were exported from DB2, it's not clear why 0D
appears in the middle of a record, why it needs to be preserved nor why a row would be
split across two records. This is NOT NORMAL.
X'09' is tab, which is another source of frustration. Tab is used to compress repeating
spaces, but there is NO STANDARD on how to expand tabs. Many programs assume a tab stop
every eight bytes, but spreadsheets use tab to mean Next Field, which could be any number
of bytes away. Whenever I get a file with tabs, I convert them to spaces, then line up the
resulting mess. Tabs are a Bad Idea.
taoxi...@gmail.com
simply discarded it?
I can't understand your "DB2 is mainframe, not Unix". It should be a
series of cross-platform databases though each of them may different
from each other.This is the documentation of DB2 for Unix:
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp
And the data is EXPORTed from db2 on AIX(Actually comes from mainframe
DB2 since it's a migration project).
But I have to admit the data is quite unusual.Fortunately I have
handled X'09' correctly with EXPANDTAB=OFF.
On Jul 27, 1:29 pm, Robert <n...@e.mail> wrote:
> resulting mess. Tabs are a Bad Idea.- Hide quoted text -
Michael Mattias
> On Sat, 26 Jul 2008 17:19:09 -0700 (PDT), taoxi...@gmail.com wrote:
>
> DB2 is mainframe, not Unix. If your files were exported from DB2, it's not
> clear why 0D
> appears in the middle of a record, why it needs to be preserved nor why a
> row would be
> split across two records. This is NOT NORMAL.
This gives me a thought ....
I have encountered similar problems when the data itself contained delimiter
characters.
Yes, it does make you think your logic, your compliler or your utilities are
acting naughty, when what is really happening is, "garbage in, garbage out."
Worth checking methinks.
MCM
Robert
>Do you mean it would be impossible for us to get the 0D if Micro Focus
>simply discarded it?
It's impossible when using LINE SEQUENTIAL.
>I can't understand your "DB2 is mainframe, not Unix". It should be a
>series of cross-platform databases though each of them may different
>from each other.This is the documentation of DB2 for Unix:
>http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp
For many years, DB2 on Unix was called UDB -- Universal Data Base. Evidently, IBM recently
changed the name to DB2.
>And the data is EXPORTed from db2 on AIX(Actually comes from mainframe
>DB2 since it's a migration project).
>
>But I have to admit the data is quite unusual.Fortunately I have
>handled X'09' correctly with EXPANDTAB=OFF.
Users entered tabs to make columns line up on a monospaced display. Those tabs probably
won't work the same way on your new platform. Same for the carriage returns and line
feeds.
William M. Klein
Does the DB2 table include any fields defined as Packed-Decimal or Binary
(possibly COMP, COMP-3, COMP-5)?
If so, then using Line Sequential files is almost CERTAINLY not the way to go.
Line Sequential files are INTENDED for "display" data.
(Record Sequential files are FINE for binary and packed-data).
If your original data doesn't include any binary or packed data, can you tell us
what type of field INCLUDES the X'0D" data - and what it is intended to be - as
data?
docd...@panix.com
Robert <n...@e.mail> wrote:
[snip]
>For many years, DB2 on Unix was called UDB -- Universal Data Base.
>Evidently, IBM recently
>changed the name to DB2.
Mr Wagner, you betray yourself as a COBOL programmer; I first worked with
an IBM product called DB2 on a mainframe in 1987 and the product was first
released (according to http://en.wikipedia.org/wiki/IBM_DB2 ) in 1983.
COBOL programmers, at times, seem to have... different ideas of
'recently'.
DD
Richard
> On Sun, 27 Jul 2008 01:21:51 -0700 (PDT), taoxianf...@gmail.com wrote:
> >Do you mean it would be impossible for us to get the 0D if Micro Focus
> >simply discarded it?
>
> It's impossible when using LINE SEQUENTIAL.
>
> >I can't understand your "DB2 is mainframe, not Unix". It should be a
> >series of cross-platform databases though each of them may different
> >from each other.This is the documentation of DB2 for Unix:
> >http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp
>
> For many years, DB2 on Unix was called UDB -- Universal Data Base. Evidently, IBM recently
> changed the name to DB2.
You are wrong. The name of the product is, and has been, "DB2
Universal Database" which is available on z/OS, OS/390, iSeries, AIX/
Unix/Linux and Windows. Other products are "DB2 Connect" and "DB2
Warehouse Manager".
taoxi...@gmail.com
wrote:
I know that Line Sequential files are for 'text' data.
And all the 0D comes from VARCHAR field(in several tables since I
tried several programs). So I guess(not very sure) the data contains
only Japanese characters and no binary data.As I said before, the
data's origin is mainframe DB2. But I can't determine the 0D exists in
the mainframe DB(since I can't access it), or is injected during the
data transportation to AIX DB2, or something else.
Then I'm unable to explain what it is intended to be - acautally my
boss said the 0D should have no essential meanings and it's probably
OK even being discarded. He said that the effect will be finally
evaluated at the test phase.
That' all guys. I just wanna have a rest now.
Thank you for all your patience and kindness.
Robert
In this book (published 2000), our friends in AS/400 land refer to it as UDB/400.
http://books.google.com/books?id=lqtc0c3UjIMC&pg=PA1&lpg=PA1&dq=buy+udb&source=web&ots=7JOfYeQgsE&sig=38qWI4siZc8_hxGkSAUP_RLHZ3Y&hl=en&sa=X&oi=book_result&resnum=10&ct=result#PPP1,M1
Mainframe DB2 is written in PL/S; the non-mainframe version is written in C++. Although
functionally similar, they are different code bases.
FWIW, I've never worked at a Unix shop that used DB2/UDB, and that included several AIX
shops. Wal-Mart and one other used Informix, the other ten used Oracle. I get the
impression DB2 users are clinging to their mainframe origins.
Robert
>Have you replied yet to the question:
>
>Does the DB2 table include any fields defined as Packed-Decimal or Binary
>(possibly COMP, COMP-3, COMP-5)?
There are no such DB2 types. The corresponding types are INTEGER and DECIMAL. They would
be in display format when exported by any utility.
>If your original data doesn't include any binary or packed data, can you tell us
>what type of field INCLUDES the X'0D" data - and what it is intended to be - as
>data?
Taoxianfeng's 0D and 0A are in strings -- database type VARCHAR, Cobol PIC X. We know that
because he said "I have to count the quotation marks to determine if a record is
divided into several lines and combine them together." Strings are bounded by quotes;
numbers aren't. He is saying there was a 0A in a string.
Richard
> On Sun, 27 Jul 2008 12:01:23 -0700 (PDT), Richard <rip...@azonic.co.nz> wrote:
> >On Jul 28, 3:10 am, Robert <n...@e.mail> wrote:
> >> On Sun, 27 Jul 2008 01:21:51 -0700 (PDT), taoxianf...@gmail.com wrote:
> >> >Do you mean it would be impossible for us to get the 0D if Micro Focus
> >> >simply discarded it?
>
> >> It's impossible when using LINE SEQUENTIAL.
>
> >> >I can't understand your "DB2 is mainframe, not Unix". It should be a
> >> >series of cross-platform databases though each of them may different
> >> >from each other.This is the documentation of DB2 for Unix:
> >> >http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp
>
> >> For many years, DB2 on Unix was called UDB -- Universal Data Base. Evidently, IBM recently
> >> changed the name to DB2.
>
> >You are wrong. The name of the product is, and has been, "DB2
> >Universal Database" which is available on z/OS, OS/390, iSeries, AIX/
> >Unix/Linux and Windows. Other products are "DB2 Connect" and "DB2
> >Warehouse Manager".
>
"""Preface.
... One reason for that success is the system's integrated database
management system known as DB2 Universal Database for AS/400 (UDB/
400)."""
Also AS/400 is not Unix.
William M. Klein
If you look at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dsnapj11/2.3.3
You will see that the "normal" COBOL equivalent of VARCHAR is:
10 var.
49 var_LEN PIC 9(4) USAGE COMP.
49 var_TEXT PIC X(n).
This means that the length field is stored as a bINARY field. Therefore, a
X"0D" would occur for a 13 byte VARCHAR field.
I don't know how you (your organization) is getting the data from the DB2 table,
but you need to do something to EITHER convert the binary length field to
display OR to not create (try to create) a line sequential file.
--
Bill Klein
wmklein <at> ix.netcom.com
<taoxi...@gmail.com> wrote in message
news:4f379b88-5332-46f9...@q28g2000prh.googlegroups.com...
taoxi...@gmail.com
Varchar is handled with such a structure ONLY in SQL embedded
program(.sqb,etc). The field length and real content will be stored
into it when fetching a cursor or some other way.
BUT now I'm just writing a pure cobol source matching some "special"
text file.
You can do a experiment to see how is a varchar field exported(into
DEL format) - only the characters.
I can't show my data but some records contain no 0D and some have lots
of 0D spreading the whole varchar field. They are not the binary-form
field length.
On Jul 28, 1:36 pm, "William M. Klein" <wmkl...@nospam.netcom.com>
wrote:
> I now can guess at your problem.
>
> If you look at:
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dsnapj11/2...
>
> You will see that the "normal" COBOL equivalent of VARCHAR is:
>
> 10 var.
> 49 var_LEN PIC 9(4) USAGE COMP.
> 49 var_TEXT PIC X(n).
>
> This means that the length field is stored as a bINARY field. Therefore, a
> X"0D" would occur for a 13 byte VARCHAR field.
>
> I don't know how you (your organization) is getting the data from the DB2 table,
> but you need to do something to EITHER convert the binary length field to
> display OR to not create (try to create) a line sequential file.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com<taoxianf...@gmail.com> wrote in message
> Thank you for all your patience and kindness.- Hide quoted text -
Michael Mattias
>of 0D spreading the whole varchar field. They are not the binary-form
>field length.
Well, that simpifies things. If the data contain x0D (or x0A, depending on
any available record delimiter character settings supported) you cannot get
it with a COBOL program treating the file as 'line sequential'. You'll have
to find another way, period.
MCM
HeyBub
> umm...it probably doesn't work either. Do you think X'0D' will be
> handled differently
> under this way?
>
> I will have a try. Thanks.
Sure it'll work.
INSPECT {record name} TALLYING {record-length} FOR CHARACTERS BEFORE X'0D'.
William M. Klein
contact the "owner" of the data on the mainframe. If the data itself actually
contains X"0D" (or any other X"0?" or X"1?" data), you should VERIFY with the
owner that they think this is "valid" data. Personally (especially with the
manager's comment that these can be "ignored") I am guessing that there is a
problem somewhere in the extraction and transfer process. It certainly is
POSSIBLE that this is "valid" data - but it is also possible that it is a
symptom of another problem that needs correcting.
--
Bill Klein
wmklein <at> ix.netcom.com
<taoxi...@gmail.com> wrote in message
news:a9c0db14-398e-47ef...@j22g2000hsf.googlegroups.com...
Rick Smith
<taoxi...@gmail.com> wrote in message
news:a9c0db14-398e-47ef...@j22g2000hsf.googlegroups.com...
[snip]
> BUT now I'm just writing a pure cobol source matching some "special"
> text file.
> You can do a experiment to see how is a varchar field exported(into
> DEL format) - only the characters.
> I can't show my data but some records contain no 0D and some have lots
> of 0D spreading the whole varchar field.
[snip]
A bit of research (google using: site:ibm.com db2 +aix +hex)
shows that a HEX function is available (in DB2 V9) that may be
used during EXPORT to convert the characters in the VARCHAR
column to hex display. Using this function would seem to simplifiy
the problem with having control character values as data.
Frank Swarbrick
>
>
>>I can't understand your "DB2 is mainframe, not Unix". It should be a
>>series of cross-platform databases though each of them may different
>>from each other.This is the documentation of DB2 for Unix:
>>http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp
>
> For many years, DB2 on Unix was called UDB -- Universal Data Base.
> Evidently, IBM recently
> changed the name to DB2.
DB2(R) Universal Database" (DB2 UDB) at least back as far as version 5, from
as far as I can tell.
Older names that it had were DB2/2 (for OS/2) and DB2/6000 (for RS/6000,
which I believe is the hardware that ran AIX).
Even before that (I think!) it was called OS/2 Extended Edition Database
Manager. As far as I can tell, that was the only version (of the line from
which the current DB2 for Linux, UNIX and Windows decends) that did not have
DB2 in the name.
Anyway, as of version nine (9.1) the "Universal Database" part was dropped,
and it is not IBM DB2 for Linux, UNIX and Windows.
By the way, I have an unused version of (according to the package) Database
2 OS/2 (with DB2/2 also listed on the box) Version 1.0 if anyone wants it.
:-) Just kidding. I wouldn't give it away. Too historically important!
:-)
Hmm, actually, here's a good link that I just found (after I wrote all of
the above):
http://wiki.ibmdatabasemag.com/index.php/DB2_History_--_A_Timeline
So it looks like this...
1982: SQL/DS for VSE and VM released (1)
1983: DATABASE 2 (DB2) released on MVS (2)
1987: OS/2 V1.0 Extended Edition, with relational database capabilities (3)
1988: SQL/400 for release for AS/400 (4)
1993: DB2 for OS/2 V1 (DB2/2) and DB2 for AIX V1 (DB2/6000)
1995: DB2 Common Server V2, which appears to now support Windows in addition
to OS/2 and AIX (3)
1996: Not sure what happened to version 3 and 4, but apparently we are now
at DB2 Universal Database V5 (3)
1997: DB2 for OS/390 V5 (2)
1997: DB2 Universal Database for Unix, Windows and OS/2 (3)
1998: DB2 UDB for AS/400 (4)
1999: DB2 supported on Linux. I'm assuming this is where they just started
calling it DB2 Universal Database, but that's just a guess (3)
At some point SQL/DS for VSE and VM is renamed DB2 Server for VSE and VM.
(1)
At some point the "MVS" version is renamed DB2 for z/OS (I think!). Also
for version 8 at least, the "MVS" product was "DB2 Universal Database for
z/OS". It looks like version 7 was "DB2 Universal Database for z/OS and
OS/390".
As of version nine (9.1), released in 2006, we now have DB2 for Linux, UNIX
and Windows (3).
As of version nine (9.1), released in 2007, we now have DB2 for z/OS.
I gave up on AS/400, iSeries.
(1) VSE and VM
(2) MVS / OS/390 / z/OS
(3) OS/2, AIX, Windows, UNIX, Linux
(4) AS/400, iSeries
Talk about confusing! And I'm sure I have some things wrong.
Pete Dashwood
"William M. Klein" <wmk...@nospam.netcom.com> wrote in message
news:rMmjk.347471$I42....@fe04.news.easynews.com...
> Besides the comment that Line Sequential just won't work, you really
> SHOULD contact the "owner" of the data on the mainframe.
That would be the CEO of the company, according to some recent posts in
CLC... :-)
Pete.
--
"I used to write COBOL...now I can do anything."
taoxi...@gmail.com
wrote:
> Besides the comment that Line Sequential just won't work, you really SHOULD
> contact the "owner" of the data on the mainframe. If the data itself actually
> contains X"0D" (or any other X"0?" or X"1?" data), you should VERIFY with the
> owner that they think this is "valid" data. Personally (especially with the
> manager's comment that these can be "ignored") I am guessing that there is a
> problem somewhere in the extraction and transfer process. It certainly is
> POSSIBLE that this is "valid" data - but it is also possible that it is a
> symptom of another problem that needs correcting.
>
> --
> Bill Klein
>
> - Show quoted text -
I'll take your suggestion seriously. It's really necessary for me to
check the validity of the data before writing the program and
discussing with you all.
taoxi...@gmail.com
> <taoxianf...@gmail.com> wrote in message
Well, it's really a fantastic method! All data is successfully
outputted.
There's only one more thing:
I need to import the matched data back to the table, so I'm searching
the way to convert the HEX displayed varchar column back. Would you
mind give me a bit more hint?
billious
"Robert" <n...@e.mail> wrote in message
> On Thu, 24 Jul 2008 02:40:37 -0700 (PDT), taoxi...@gmail.com wrote:
>
>>Hi all
>>
>>I'm writing a batch source to match 2 input files which is exported
>>from AIX DB2 giving the matched records.
>>
>>All other characters are going well except X'0D':all of them get lost
>>when reading the input files into the program. I tried many file
>>handler options and runtime switches but no one worked. Any advice is
>>appreaciated. Thanks in advance!
>>
>>Line sequential file, variable-length record.
>>
>>This is the file handler I'm using now:
>>[XFH-DEFAULT]
>>STRIPSPACE=OFF
>>INSERTNULL=OFF
>>EXPANDTAB=OFF
>>
>>AIX 5.3, Microfocus Server Express 5.0
>
> lines yourself. The
> last short block is a little tricky.
MOVE ALL X0D TO FD before the READ.
Old programmers' trick.
taoxi...@gmail.com
>
> - Show quoted text -
I'm sorry I still can't fully understand your meaning.But when I'm
trying like that:
FD
INFILE1
DATA RECORD IS IN-
REC1
RECORDING MODE
V
RECORD IS VARYING IN SIZE FROM 1 TO
5000
DEPENDING ON WK-INREC1-
LEN.
01 IN-REC1 PIC
X(5000).
……
READ INFILE1
……
INSPECT IN-REC1 TALLYING WK-TMP1 FOR CHARACTERS BEFORE X'0D'
The result of WM-TMP1 is 5001 added by the actual length decided by
X'0A' and EXLUDING X'0D'. For example:
...0D..0D.0A (record length is 8 including 0D but 0A)
Then the value of WM-TMP1 is 5007.(only 6 characters were counted)
........0A (record length is 8 exluding 0A)
Then the value of WM-TPM1 is 5009.(all 8 characters were counted since
no X'0D')
So that means X'0D' is discarded when READing the file and the INSPECT
always gives the maximium record length since it can't find X'0D'.
And my question by "it probably doesn't work either" means reading the
file by a given length will also discard the X'0D', though I have not
tried yet.
taoxi...@gmail.com
>
> - Show quoted text -
Move before the read? Could you explain it with more detail? Thanks a
lot.
How can I move X'0D' since I don't know where and how much of them
will be in the record?
Robert
Code Page 1252 is hex
load from filename of del modified by codepage=1252
Robert
He meant initialize the record area so the tail of the last block would be filled with
x'0D'. Spaces would be a better choice. I would do it like this:
select input-file assign to INFILE1
record sequential
file status file-status.
fd input-file.
01 input-record.
05 input-byte occurs 512 pic x.
01 file-status pic x(2).
01 pic x. 88 end-of-file value 'y' false low-value.
01 pic x. 88 last-sector value 'y' false low-value.
01 pic x. 88 in-quotes value 'y' false low-value.
01 pic x. 88 end-of-record value 'y' false-low-value.
01 sub-in pic 9(4) binary.
01 sub-out pic 9(4) binary.
01 output-record.
05 output-byte occurs 512 pic x.
set end-of-file, last-sector, in-quotes to false
open input input-file
perform read-sector
perform until end-of-file
set end-of-record to false
move spaces to output-record
move 1 to sub-out
perform until end-of-record or end-of-file
evaluate input-byte (sub-n) also true
when space also not in-quotes
move low-value to input-byte (sub-n)
when x'0A' also not in-quotes
set end-of-record to true
when quote also not in-quotes
set in-quotes to true
when quote also in-quotes
set in-quotes to false
end-evaluate
if input-byte (sub-n) not equal to low-value
move input-byte (sub-in) to output-byte (sub-out)
add 1 to sub-out
if sub-out greater than length of output-record
display 'Record too big ' output-record
call 'abort'
end-if
end-if
add 1 to sub-in
if sub-in greater than length of input-record
perform read-sector
end-if
end-perform
[do something with output-record]
end-perform
close input-file
exit program.
read-sector.
if last-sector
set end-of-file to true
else
move spaces to input-record
read input-file at end set end-of-file to true end-read
move 1 to sub-in
evaluate file-status
when '92'
set last-sector to true
when not = zero and not end-of-file
display 'Read error ' file-status
call 'abort'
end-evaluate
end-if.
taoxi...@gmail.com
>
> - Show quoted text -
The DB2 codepage is set to IBM-943 (Japanese) so a SQL2754N "cannot be
converted" error happens when trying to load data with codepage 1252.
Maybe I should change the DB codepage?
billious
LINE INPUT transfers characters from the input datastream until the next
X'0D'/X'0A' (depending on system) into the input record. Hence, X'0D' and
X'0A' should never appear in the input record.
Problem is that the transfer merely stops at the character before the
End-Of-Line (whatever it may be) - the record is not 'filled' - so any
characters from a LONGER previous record are not overwritten.
Hence, if you simply
MOVE SPACES TO INPUT-RECORD.
READ INPUT-FILE.
then the data appearing will simply be the contents of the shorter
next-record, filled with spaces.
Now whether you move SPACES or LOW-VALUES or HIGH-VALUES or ASCII-CR or
ASCII-LF or ASCII-NULL is up to you, and how you wish to process the data.
You appeared to be worried about X'0D' being absent - use ASCII-CR if that
suits your purpose. I last ran into that problem on a DEC/VMS machine, but
it was a standard problem.
Outputting such a record normally suppresses trailing-spaces, so probably
spaces would be the better idea. Depends on what you want to do overall.
I've assumed that you have a record something like
01 INPUT-RECORD.
03 INPUT-CHARS PIC X(01) OCCURS HOWEVER-MANY.
And also that you have a copybook of constants like
01 STANDARD-CONSTANTS.
03 ASCII-NULL.
05 FILLER PIC 9(02) COMP VALUE 0.
03 ASCII-LF.
05 FILLER PIC 9(02) COMP VALUE 10.
03 ASCII-CR.
05 FILLER PIC 9(02) COMP VALUE 13.
03 ASCII-DOUBLE-QUOTES.
05 FILLER PIC 9(02) COMP VALUE 34.
03 ASCII-QUOTES.
05 FILLER PIC 9(02) COMP VALUE 39.
(I do it that way - and establish other symbolic constants like this because
it is implementation-independent)
William M. Klein
news:71e6da43-8789-4de7...@34g2000hsh.googlegroups.com...
<snip>
The DB2 codepage is set to IBM-943 (Japanese) so a SQL2754N "cannot be
converted" error happens when trying to load data with codepage 1252.
Maybe I should change the DB codepage?
Is the actual mainframe data "NATIONAL" (or DBCS) data (stored in the DB2 table?
If so, then it is CERTAINLY possible that the actual DBCS/national data includes
X"OD" bytes within a double byte (or Unicode) data.
"Converting" (or handling) mainframe DBCS/National data via Micro Focus on AIX
is a VERY different issue than anything that you have mentioned up to now.
If the mainframe data is NOT DBCS or National, can you find out WHY it is
defined as "IBM-943 (Japanese)"? If it does include SOME actual Japanese data,
can you find out if it is ALL "national" - or if it is a mixture of national and
alphanumeric data.
If the mainframe data includes a combination of EBCDIC and DBCS (or Unicode)
data, then I think you need to be VERY careful of your "conversion" (export)
procedures AND you need to make certain that "conversions" in transfer to AIX
"maintains" valid data AND that you are using the proper language (NLS and
codepage) settings when processing the data with Micro Focus.
Richard
Do you think that he is running on Windows now ??
Robert
My mistake. Code page 1252 converts only to US-ASCII. Japanese explains why you couldn't
show the data here.
taoxi...@gmail.com
wrote:
> <taoxianf...@gmail.com> wrote in message
I just become despaired since it keeps involving more and more
questions...
Pete Dashwood
<taoxi...@gmail.com> wrote in message
news:51a1467d-8e2d-41ab...@w7g2000hsa.googlegroups.com...
[Pete]
I understand how you feel. I've been watching the thread, but refrained from
comment.
1. Don't give up.
2. Think about what you have gained.
You have a lot more information than you had when you first posted and you
have found out things that you didn't know.
Some of the information you received has been misleading, but that's normal
on Usenet. People here have been trying hard to help, but the statement of
the problem is not accurate. While it may be true that your x'0D' s are
being "stripped out", to most people here that is normal behaviour for a
Line Sequential file. (that's why it is happening). You didn't tell us
the file contained Japanese Language characters which could be represented
in a number of ways, and can contain x'0D' as a matter of course.
Bill's post above is simply addressing this, and he is trying to help you.
(Trust him, he is wise... :-))
Unfortunately, you still haven't been able to resolve your problem, and
pressure to do so is mounting.
Rick pointed out the possibility of being able to export the data as
character format Hex. Very useful.
So now, although it all seems very overwhelming, you are really close to a
solution. This is not the time to quit or despair... :-)
At the moment it seems that as soon as you can reconstruct the original data
stream from the Hex, you have solved the problem.
How hard can that be?
Robert suggested using a code page (unfortunately, he was a bit off the
mark, but the idea was good...)
Personally, I wouldn't even attempt to change the code page for the DB; that
is likely to upset a number of people :-).
Think some more about the Hex string. Each byte is represented by 2 hex
symbols. If you had to, you could easily write a little COBOL routine that
would give you the same byte in binary... Here's an example that is by no
means definitive, but which I'm sure you can modify for your particular
environment...
*> interface
01 two-bytes-in pic xx.
01 one-byte-out pic x.
*> reference data
01 hc pic x(16) value '01234567890ABCDEF'.
01 filler redefines hc.
12 hexchars pic x occurs 16
indexed by hc-x1.
01 hv usage comp.
12 x0 pic s9(4) value zero.
12 x1 pic s9(4) value 1.
12 x2 pic s9(4) value 2.
12 x3 pic s9(4) value 3.
12 x4 pic s9(4) value 4.
12 x5 pic s9(4) value 5.
12 x6 pic s9(4) value 6.
12 x7 pic s9(4) value 7.
12 x8 pic s9(4) value 8.
12 x9 pic s9(4) value 9.
12 xA pic s9(4) value 10.
12 xB pic s9(4) value 11.
12 xC pic s9(4) value 12.
12 xD pic s9(4) value 13.
12 xE pic s9(4) value 14.
12 xF pic s9(4) value 15.
01 filler redefines hv.
12 hexvalues pic s9(4) comp occurs 16
indexed by hv-x1.
*> work fields
01 current-byte pic x.
01 num-x pic xx.
01 num-b redefines num-x pic s9(4) comp.
01 binary-work-fields usage comp.
12 bin-work pic s9(4).
12 bin-1 pic s9(4).
12 bin-2 pic s9(4).
....
convert-hex-chars section.
chc000.
move two-bytes-in (1:1) to current-byte
perform get-binary
move bin-work to bin-1
move two-bytes-in (2:1) to current-byte
perform get-binary
move bin-work to bin-2
compute num-b = (bin-1 * 16) + bin-2
move num-x (2:1) to one-byte-out
.
chc999.
exit.
*>--------------------------
get-binary section.
gb000.
set hc-x1 to 1
search hexchars
at end
*> the HEX, isn't... drastic action needed...not shown here
when current-byte = hexchars (hc-x1)
set hv-x1 to hc-x1 *> you might need to adjust this on
MicroFocus
move hexvalue (hv-x1) to bin-work
end-search
.
gb999.
exit.
This is necessarily a little unwieldy because MicroFocus COBOL (as far as I
can ascertain) doesn't support PIC 1 for true binary (we really need to
address 4 bits here), and that means it is necessary to fudge it in 16 bit
fields.
If you build a little "machine" (like the above) it isn't too hard to push
your HEX string through it and so obtain the original binary representation
which could be anything, including National Characters, Katakana, DBCS,
whatever. (Or even just standard ASCII)
Even if you don't go this way but find another solution, never give up
because people are asking questions. Answer the ones you can, ignore the
ones you can't or respond with "I don't know"... :-)
You have invested a large amount of time and effort in this.
You are way too close to a solution to despair now :-)
taoxi...@gmail.com
>
> - Show quoted text -
You gave an excellent conclusion.
I'm really a newbie and I gained a lot from this post.
I also think the HEX scalar function is very near to the solution.
I'm busy with some other business so replying a little slowly.
I will keep trying. Thank you very much.
William M. Klein
Unicode) data in the DB2 table on the mainframe, that you will really need a LOT
of information to be able to "correctly" migrate this to AIX.
Question 1:
Do you want to convert the EBCDIC data to ASCII? If so, you may still need to
find out which EBCDIC code page (there are more than one) is being used on the
mainframe. You also won't be able to "automatically" convert the data - as you
will NOT want to use the same routine for converting the Japanese data.
Question 2:
Is the mainframe "Japanese" data in DBCS or Unicode? Do you want it to be in
Unicode? Shift-Jis, IBM DBCS, or what format on AIX? IBM mainframe COBOL (and
I think - but am not certain DB2) can handle EITHER DBCS or Unicode data. There
are differences (some minor and some major) between these. You will need to
make certain that you know which format is used on the mainframe AND which
format you are supposed to create on AIX. Again, conversions of this data will
need to happen "field by field" as you will NOT want to use the same conversion
algorithms for this data as the originally EBCDIC data.
***
On Windows (but I am not positive it is true on AIX), Micro Focus *does* provide
facilities for using mixed EBCDIC and IBM mainframe DBCS data "as if it were
native/Windows" data. This *might* be the easies method for doing your
conversion/migration work. HOWEVER, it is not recommended for "production" work
on AIX. Therefore, you would still want to convert the mainframe-style data to
AIX data (i.e. EBCDIC -> ASCII and DBCS -> Unicode) for "production" work.
P.S. This is NOT the type of migration that is usually given to a "Newbie" so I
certainly can understand your frustration. If this is an 'In-house" migration
project, then you should be able to find in-house expertise to help you. If
this is something that your organization has "contracted" to do, then I think
that someone made a commitment that they hadn't properly "sized" before bidding
on.
--
Bill Klein
wmklein <at> ix.netcom.com
<taoxi...@gmail.com> wrote in message
news:7cd6c4c1-3929-418e...@a3g2000prm.googlegroups.com...
Pete Dashwood
<taoxi...@gmail.com> wrote in message
news:7cd6c4c1-3929-418e...@a3g2000prm.googlegroups.com...
[Pete]
You are very welcome.... :-)
(I was a newbie myself once...)
Pete Dashwood
"William M. Klein" <wmk...@nospam.netcom.com> wrote in message
news:IfXjk.339886$fz6.2...@fe08.news.easynews.com...
>I just want to repeat that if you have a mixture of EBCDIC and National
>(DBCS or Unicode) data in the DB2 table on the mainframe, that you will
>really need a LOT of information to be able to "correctly" migrate this to
>AIX.
That may not be the case, Bill. There has been no suggestion that a MIXTURE
is in use.
Taoxianfeng said they are on a straight Japanese code page.
If the AIX machine can recognise the DBCS, it should all be fine. DBCS is
like Unicode (inasmuch as it comes in standard "flavours"); it's a standard
format for any platform that supports IBM's DBCS.
(I had to use it once many years ago and have never forgotten the
experience...)
Quoting from IBM:
The IBM-932 code page (Japanese) is one example of a DBCS code page in
which:
X'00' to X'7F' are single-byte codes
X'81' to X'9F' are double-byte introducer
X'A1' to X'DF' are single-byte codes
X'E0' to X'FC' are double-byte introducer
(No wonder the stripped out x'0D's are problematic... :-))
I think the problem is arising because the CONTAINER for the data is a LINE
SEQUENTIAL file, which happens to use x'0D' for a special purpose.
The data is there, because when it is HEX encoded it arrives at the AIX
machine correctly.
If the data is converted back to the original, and the AIX machine is also
running the Japanese code page, I believe everything will work correctly.
It isn't the difference in OS that is the problem, it is the transport
layer. (Rick's suggestion to HEX encode it solves this nicely.)
>
> Question 1:
> Do you want to convert the EBCDIC data to ASCII? If so, you may still
> need to find out which EBCDIC code page (there are more than one) is being
> used on the mainframe. You also won't be able to "automatically" convert
> the data - as you will NOT want to use the same routine for converting the
> Japanese data.
Assumes there is EBCDIC data. If it is all Japanese it is DBCS.
>
> Question 2:
> Is the mainframe "Japanese" data in DBCS or Unicode? Do you want it to
> be in Unicode?
Why would that matter? He just wants it to be readable on the AIX machine.
Once that is working, the niceties of DBCS vs Unicode could be explored as a
separate issue. I think this is just complicating the issue.
> IBM mainframe COBOL (and I think - but am not certain DB2) can handle
> EITHER DBCS or Unicode data. There are differences (some minor and some
> major) between these. You will need to make certain that you know which
> format is used on the mainframe AND which format you are supposed to
> create on AIX.
Surely that is covered by the code page? We have established it is Japanese
(DBCS on the mainframe, and the equivalent Japanese page on the AIX machine,
presumably.)
> Again, conversions of this data will need to happen "field by field" as
> you will NOT want to use the same conversion algorithms for this data as
> the originally EBCDIC data.
I have no idea why you would say this... :-)? Keep it simple.
>
> ***
>
> On Windows (but I am not positive it is true on AIX), Micro Focus *does*
> provide facilities for using mixed EBCDIC and IBM mainframe DBCS data "as
> if it were native/Windows" data. This *might* be the easies method for
> doing your conversion/migration work. HOWEVER, it is not recommended for
> "production" work on AIX. Therefore, you would still want to convert the
> mainframe-style data to AIX data (i.e. EBCDIC -> ASCII and DBCS ->
> Unicode) for "production" work.
>
Yes, very fair comment and right on ** IF ** we are dealing with "mixed"
encoding AND the AIX system DOESN'T support DBCS...
> P.S. This is NOT the type of migration that is usually given to a
> "Newbie" so I certainly can understand your frustration.
He has had a lot to deal with. It would be really good if this can be solved
without complicating it any more than absolutely necessary... :-)
Given that he is using Japanese code pages (DBCS) on both systems, can you
see any problem with him simply decoding the HEX encoded message?
Robert
wrote:
I think the problem is that Micro Focus does not know the input file contains DBCS codes.
It is treating the input as single-byte US-ASCII. You tell it about the codeset using the
codecomp program to create a codeset file and the MFCODESET environment variable to tell
it to use that page at execution time.
http://supportline.microfocus.com/supportline/documentation/books/sx22sp1/sx22indx.htm
Frank Swarbrick
doing a database to database load, rather than an export followed by an
import. I have only been partially paying attention, but is the goal to get
data that currently exists in DB2 for z/OS in to a DB2 AIX database? If you
have DB2 9.1 or 9.5 on AIX you should be able to do something like the
following:
DECLARE load_curs CURSOR
DATABASE <sourcedb>
USER <source_db_user_name>
USING <source_db_user_password>
FOR SELECT * FROM <source_table_name>;
LOAD FROM load_curs OF CURSOR
REPLACE INTO <dest_table_name>;
I believe this feature (the DATABASE/USER/USING clauses) is available only
in version 9. With prior versions you have to set up "data federation" on
your destination db and have nicknames for your source db tables. More
complicated, but still possible. Either way your AIX database must be able
to connect to your z/OS database. If that is not an option then this will
not work.
I have no idea if this actually meets your requirements, but it's one
possible option. No Cobol needed, and no export files needed.
Frank
Robert
wrote:
Oracle is simpler
create table <dest> as select * from <src>@<sourcedb>;
where sourcedb is defined once:
create database link <sourcedb>
connect to <user> identified by <password> using 'service handle';
If you don't have permission to create a db link, you can use the sqlplus copy command:
copy from <user>/<password>@<sourcedb> create <dest> using select * from <src>;
Pete Dashwood
"Robert" <n...@e.mail> wrote in message
news:hs8194lv6og5gvrbh...@4ax.com...
It certainly looks that way.
>You tell it about the codeset using the
> codecomp program to create a codeset file and the MFCODESET environment
> variable to tell
> it to use that page at execution time.
>
> http://supportline.microfocus.com/supportline/documentation/books/sx22sp1/sx22indx.htm
So, are you saying Robert, that if Taoxianfeng simply sets the MFCODESET EV
to point at the Japanese code page, at the time he runs his MF COBOL
program, it should work? Definitely worth a try...
Pete.
--
taoxi...@gmail.com
wrote:
>
> - 引用テキストを表示 -
Frankly speaking , I can't anwser your questions since I don't have
much experience on both mainframe and AIX.
I can only agree that this problem is not well "sized" before
commencing. It's too ridiculous and confidential to be talked about
here. Just forget it.
taoxi...@gmail.com
wrote:
Do you mean load data from mainframe DB to AIX DB directly if they can
be connected?
Yes there would be problems when migrating the data. But now what I
need to do is like that:
export 2 tables (or some fields of it);
sort the exported data by mfsort;
match the sorted file and only output the necessary records;
import the output file back to the table replacing the old ones.
The original sources are JCL and mainframe cobol which are to be
migrated to AIX shell and microfocus cobol.
I'm sorry I describe this whole image so late that maybe misleaded you
all.
Actually it also maybe possible to read the 2 tables in the cobol
program and delete the unmatched ones(almost writing a new source).
But I think it costs too much. Perhaps it's the last method we will
try.
taoxi...@gmail.com
> On Thu, 31 Jul 2008 03:05:12 +1200, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
> wrote:
>
>
>
>
>
>
>
> >"William M. Klein" <wmkl...@nospam.netcom.com> wrote in message
>
> - 引用テキストを表示 -
Thank you Robert.
I tried exporting MFCODESET ev directly then recompile and run the
program. But it gives nothing different.
(referencing the codeset No. from http://www.microfocus.com/000/20031001_003_tcm21-6159.pdf
, I used 0081,0939 and 9122)
So I'm trying to use the codecomp utility to build new mapping now.
However, I feel that it's all about ASCII and EBCDIC since the
document says "The Codecomp utility enables you to reconfigure the
_CODESET program for single-byte characters."
Robert
wrote:
Yes. Add compiler option DBCS, and pic G instead of pic X. There is also an environment
variable LANG, but it apears to be for NLS (Latin alphabet).
The manual talks about calling _CODESET to translate EBCDIC DBCS to ASCII DBCS. I'm
guessing that involves quotes, commas and other punctuation characters. If embedded 0D and
others below x'20' go away, the need for EBCDIC-ASCII translation should be evident from
viewing the output file.
Robert
>> http://supportline.microfocus.com/supportline/documentation/books/sx2...- ???????????? -
>>
>> - ????????? -
>
>Thank you Robert.
>
>I tried exporting MFCODESET ev directly then recompile and run the
>program. But it gives nothing different.
It appears that compiler option NLS is required to use a codeset at execution time. I
thought it was DBCS, but now see that applies to DBCS in source code at compile time, not
in data files at execution time.
Also, define the record with DISPLAY-1 PIC G, which tells it to allocate two bytes per
character.
>(referencing the codeset No. from http://www.microfocus.com/000/20031001_003_tcm21-6159.pdf
>, I used 0081,0939 and 9122)
>
>So I'm trying to use the codecomp utility to build new mapping now.
>
>However, I feel that it's all about ASCII and EBCDIC since the
>document says "The Codecomp utility enables you to reconfigure the
>_CODESET program for single-byte characters."
I would first try to get rid of control characters less than x'20'. If strings in the
output look like valid katakana, THEN deal with ASCII-EBCDIC. If strings are not bounded
by quotes, that would be a sure sign you need translation, the bounding character must be
an untranslated EBCDIC quote.
If you DO need to convert, see 8.11.4 function 4 here:
http://supportline.microfocus.com/supportline/documentation/books/sx22sp1/prnals.htm#s024
Robert
wrote:
>Think some more about the Hex string. Each byte is represented by 2 hex
>get-binary section.
>gb000.
> set hc-x1 to 1
> search hexchars
> at end
> *> the HEX, isn't... drastic action needed...not shown here
> when current-byte = hexchars (hc-x1)
> set hv-x1 to hc-x1 *> you might need to adjust this on
>MicroFocus
> move hexvalue (hv-x1) to bin-work
> end-search
There is a much simpler way to convert hex digits:
INSPECT current-byte CONVERTING
'0123456789ABCDEF' TO
X'000102030405060708090A0B0C0D0E0F'
Robert
The database will sort them if you say ORDERED BY.
>match the sorted file and only output the necessary records;
That's a simple database join operation. There is no need to sort the tables.
create table temp_a as
select a.* from a, b
where a.customer_id = b.customer_id;
or
create table temp_a as
select * from a
where customer_id in (select customer_id from b);
>import the output file back to the table replacing the old ones.
drop table a;
rename table temp_a to a;
>The original sources are JCL and mainframe cobol which are to be
>migrated to AIX shell and microfocus cobol.
>I'm sorry I describe this whole image so late that maybe misleaded you
>all.
>
>Actually it also maybe possible to read the 2 tables in the cobol
>program and delete the unmatched ones(almost writing a new source).
>But I think it costs too much. Perhaps it's the last method we will
>try.
You might be doing it the hard way.
William M. Klein
"PIC G" (and DISPLAY-1) are still available, but certainly NOT what I would
use for IBM mainframe "migration".
I would use PIC N and USAGE NATIONAL.
However, I would still want to see how the files are defined on the mainframe
(either for DB2 or for COBOL).
As I read the information online at:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dsnsqj11/2.9.4.4
and
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dsnugj11/2.30.2.3.9
There really are LOTS of things to know about the unloaded mainframe DB2 table.
It appears as if the original data (GRAPHIC or VARGRAPHIC) can be either DBCS or
Unicode. It also appears that what the "delimiter" is (for Unloaded delimited
files) defaults differently depending on which it is - and that the person doing
the unload can specify what to use.
If the mainframe DB2 table includes ONLY "graphic" and "vargraphic" data (no
"single byte") info, then if the unload specified a DBCS or Unicode delimiter,
then the unloaded file SHOULD be able to be handled on AIX with a Micro Focus
file in which the FD file has ONLY "PIC N" data. If the X'0D' data is part of
such characters, I think it MIGHT be handled correctly. However, the MF
documentation does seem pretty clear that it strips out all X'0D' bytes for Line
Sequential files, so I am not at all certain this would work - unless you call
the file RECORD sequential (rather than line sequential).
***
It seems to me that there needs to be a LOT of research into how the DB2 table
and unloaded file are actually defined on the mainframe before a "good" solution
can be done on the PC. The copy directly of the table would seem to allow for
"proper" processing of the table(s) on the PC without conversion issues, but
even that would require knowing how the table data is actually defined (DBCS,
Unicode, whatever).
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <n...@e.mail> wrote in message
news:v8b294lklakslrjhj...@4ax.com...
taoxi...@gmail.com
> On Wed, 30 Jul 2008 19:02:37 -0700 (PDT), taoxianf...@gmail.com wrote:
> >On 7¤ë31¤é, ¤È«e2:31, "Frank Swarbrick" <Frank.Swarbr...@efirstbank.com>
>
> - 引用テキストを表示 -
Well, I also know the basic SQL such as ORDER BY and JOIN.
But it's not me who chose to handle these data by export-match-import.
Just as I said before, it would be easier with some shell script but
it's not up to me.
docd...@panix.com
[snip]
>> You might be doing it the hard way.- 引用テキストを表示しない -
>>
>> - 引用テキストを表示 -
>
>Well, I also know the basic SQL such as ORDER BY and JOIN.
>
>But it's not me who chose to handle these data by export-match-import.
It seems that your knowledge of the tools required (COBOL and SQL) is
rather basic and the choice of solution is being dictated elsewhere.
Either you are receiving some very expensive on-the-job training or your
management deserves the results they are getting.
DD
Robert
>In article <effb0602-5b9b-44cc...@q5g2000prf.googlegroups.com>,
> <taoxi...@gmail.com> wrote:
>>On 7月31日, å?�後1:16, Robert <n...@e.mail> wrote:
>
>[snip]
>
>>> You might be doing it the hard way.- 引用テキストを表示ã?�ã?�ã?„ -
>>>
>>> - 引用テキストを表示 -
>>
>>Well, I also know the basic SQL such as ORDER BY and JOIN.
>>
>>But it's not me who chose to handle these data by export-match-import.
>
>It seems that your knowledge of the tools required (COBOL and SQL) is
>rather basic and the choice of solution is being dictated elsewhere.
>
>Either you are receiving some very expensive on-the-job training or your
>management deserves the results they are getting.
In the brave new world of contract programming, unreasonable assignments are semi-common.
I was once assigned to write a new program from scratch in a language (VB) I barely knew,
and given three days to get it done. It was a non-trivial program and there was no model I
could use as a starting point. If I hadn't gotten it done, there was an implied threat of
unemployment. I've seen worse, for example people assigned to work on huge
mission-critical mainframe assembly language programs with two weeks' training in Cobol
and no clue about assembly language on any machine. In that instance, three out of four
'failed' and were fired. The contracting company just shoveled more bodies onto the fire.
There's no time or budget for 'professionalism' in this world. You get it done, or else.
docd...@panix.com
Robert <n...@e.mail> wrote:
>On Thu, 31 Jul 2008 11:32:41 +0000 (UTC), docd...@panix.com () wrote:
>
>>In article <effb0602-5b9b-44cc...@q5g2000prf.googlegroups.com>,
>> <taoxi...@gmail.com> wrote:
>>>On 7月31日, å?�後1:16, Robert <n...@e.mail> wrote:
>>
>>[snip]
>>
>>>> You might be doing it the hard way.- 引用テキストを表示ã?�ã?�ã?„ -
>>>>
>>>> - 引用テキストを表示 -
>>>
>>>Well, I also know the basic SQL such as ORDER BY and JOIN.
>>>
>>>But it's not me who chose to handle these data by export-match-import.
>>
>>It seems that your knowledge of the tools required (COBOL and SQL) is
>>rather basic and the choice of solution is being dictated elsewhere.
>>
>>Either you are receiving some very expensive on-the-job training or your
>>management deserves the results they are getting.
>
>In the brave new world of contract programming, unreasonable assignments
>are semi-common.
Is that so, Mr Wagner? Gosh and golly gee, one learns something new every
day.
>I was once assigned to write a new program from scratch in a language
>(VB) I barely knew,
>and given three days to get it done. It was a non-trivial program and
>there was no model I
>could use as a starting point. If I hadn't gotten it done, there was an
>implied threat of
>unemployment.
In the few short decades that I've been working as a
consultant/contractor/hired gun I have been given such assignments; my
response has been to state, in writing, that I have not, at any time,
presented myself as already possessing the skills which the task appears
to require and I cannot, in good professional faith, provide the same
degree of certainty for the quality of product that will result.
In short: 'I am more than willing to give it a shot but I never said that
I have done this sort of stuff before. If it all goes kerflooie then it
all goes kerflooie.'
>I've seen worse, for example people assigned to work on huge
>mission-critical mainframe assembly language programs with two weeks'
>training in Cobol
>and no clue about assembly language on any machine. In that instance,
>three out of four
>'failed' and were fired. The contracting company just shoveled more
>bodies onto the fire.
The contracting company seems to have been aware that their status was not
threatened by supplying inferior product. If the person with
signing-authority over the contract keeps pumping out checks for
low-quality personnel then... it appears that checks keep getting signed.
>
>There's no time or budget for 'professionalism' in this world. You get
>it done, or else.
I have no idea what 'professionalism' is in your book, Mr Wagner. As
noted above I will put in writing what I have done before and what I'm
willing to do now; if the client disapproves of this... well, there's
always another job.
DD
taoxi...@gmail.com
> In article <effb0602-5b9b-44cc-a258-12880abe9...@q5g2000prf.googlegroups.com>,
>
> <taoxianf...@gmail.com> wrote:
> >On 7月31日, 午後1:16, Robert <n...@e.mail> wrote:
>
> [snip]
>
> >> You might be doing it the hard way.- 引用テキストを表示しない -
>
> >> - 引用テキストを表示 -
>
> >Well, I also know the basic SQL such as ORDER BY and JOIN.
>
> >But it's not me who chose to handle these data by export-match-import.
>
> It seems that your knowledge of the tools required (COBOL and SQL) is
> rather basic and the choice of solution is being dictated elsewhere.
>
> Either you are receiving some very expensive on-the-job training or your
> management deserves the results they are getting.
>
> DD
You got it. I'm a pure novice who just graduated from university last
year,especially compared to the ones who replied my post with decades
of experiences.
You can also evaluate me and my company as you wish. Even myself is
thinking about 2 things:
1.the organization is really stupid;
2.try to find another job.
BUT THAT'S ANOTHER QUESTION.
I just want to find a technical solution here and try to do as much as
I can. And I'm not posting with some silly questions or doing nothing
but waiting for answer.
You may guess I'm Chinese from my mail address. We have an old saying
"Do one's best and leave the rest to God's will".
William M. Klein
better on Windows than AIX, so this MAY take more work on AIX than it would on
Windows).
It seems to me that some (possibly most) of the problems come from the
"download" process of the unloaded file being created as "line sequential". My
assumption is that on the mainframe it is a DCB=RECFM=VB (i.e. "variable length
QSAM) file. If so, then it may be worth looking into the Micro Focus "VRECGEN"
facility. Run some jobs (on the mainframe and the AIX environment), it might be
possible to get a
Record Sequential - Variable Length
file on AIX - with ALL the data "as it is on the mainframe".
I am NOT saying that this is the "best" solution (or the only solution), but it
might be the easiest - if the "mandate" has come in that the file must be a DB2
unloaded file from the mainframe that is downloaded to AIX and processed there
as a file that is THEN loaded into an AIX table.
Michael Mattias
> In the brave new world of contract programming, unreasonable assignments
> are semi-common.
> I was once assigned to write a new program from scratch in a language (VB)
Pray, how on earth were you selected as the contractor?
And why on earth did you - as a professional contractor - accept such an
assignment?
> I've seen worse, for example people assigned to work on huge
> mission-critical mainframe assembly language programs with two weeks'
> training in Cobol
> and no clue about assembly language on any machine....
Worse yet: someone who does know the 'language product(s) of choice'
extremely well, but is clueless about the application.
I ran into this about ten years ago. I was doing some mapping of ANSI EDI
data (that's about 70% of what I do) for a client in Janesville WI. Part of
this mapping required an application run against an ERP system's database,
and since I was not (and still am not) familiar with the client's "language
product of choice" (Microsoft Visual BASIC) and at that time not any good
with Oracle/SQL, another contractor (from a 'major brand name consulting
firm in Wisconsin') was engaged to create that application.
I laid out for him what I wanted... simple text file containing five or six
delimited columns of data extracted from the ERP system's database, and the
conditions under which a record was to appear in that file. I would then map
that data into fully-enveloped ANSI X12 transaction sets. Simple, yes?
Well, this "consultant" ( a misuse of the word if ever there was one) took
it upon himself to try to map the data to ANSI himself. He had great
difficulty (like, that was a surprise?). But he did this without telling
anyone.
Three weeks later, the project was due; and I mean DUE. I had to tell the
client I was waiting on the required input, but once I had it I could map
the data in an afternoon. The other consultant was out that day, so I was
asked to look at his 'work product to date' and see if I could use what he
had and maybe make something out of what was done. (Did I mention, this
project was REALLY DUE?) .
DISASTER! Not only had the 'consultant' not been able to map the ANSI data,
he had not even completed the extraction of the required data from the ERP
database!
About 4:00 PM I sat down with the client's 'database guys' (employees of
client) who both knew Oracle pretty well, but did not know the application.
I showed them the text file I had orginally asked for, the tables in the
database where the data were located, and asked if they could create the
file using Oracle tools and utilities. They said they thought so .. so they
went off to play with the database, whilst I created the mapping code based
on their ability to create that input.
They succeeded in creating the data. I succeeded in creating the ANSI ASC
X12 output. The required ANSI document was sent to the partner about 8:00
PM.
Three weeks of consultant fees totally wasted by the client! I see things
like this and it drives me nuts: just like with lawyers, you get a couple of
bad apples and we ("real" consultants) ALL look bad.
If I can accomplish one thing before I go thru that final checkout line, I
will see contractors and consultants regarded as true professionals -
because we have EARNED that respect.
So, um, Robert..... let's not accept any more contractor assignments for
which are not qualified, OK?
--
Michael C. Mattias
Tal Systems Inc.
Racine WI
mmat...@talsystems.com
PS: The true happy ending: the consulting firm who supplied the other
contractor refunded all fees.
docd...@panix.com
[snip]
>> It seems that your knowledge of the tools required (COBOL and SQL) is
>> rather basic and the choice of solution is being dictated elsewhere.
>>
>> Either you are receiving some very expensive on-the-job training or your
>> management deserves the results they are getting.
>
>You got it. I'm a pure novice who just graduated from university last
>year,especially compared to the ones who replied my post with decades
>of experiences.
I have a few years in this business, myself... and I believe that what you
are doing is attempting to translate hexadecimal strings from an EBDCIC to
an ASCII encoding scheme.
This has been done easily for simple text and most punctuation marks...
but anything else can get really, *really* complex.
>You can also evaluate me and my company as you wish. Even myself is
>thinking about 2 things:
>1.the organization is really stupid;
>2.try to find another job.
In my experience:
1) All organisations say that their conditions are different than those of
all other organisations; if all organisations are different then all
organisations are the same.
2) There's always another job.
>
>BUT THAT'S ANOTHER QUESTION.
>
>I just want to find a technical solution here and try to do as much as
>I can. And I'm not posting with some silly questions or doing nothing
>but waiting for answer.
I have no argument with that whatsoever. If you've followed this group
for any time you may have noticed my tendency to ask people who post
questions and do not show any of the work they've done towards the
solution 'Please do your own job/homework'.
I don't believe I've made that request of you and I'm not about to.
>
>You may guess I'm Chinese from my mail address.
Eh? I thought you were Gmailian.
>We have an old saying
>"Do one's best and leave the rest to God's will".
Other sayings from other places include 'Trust in Allah... but tie up your
camels' and 'The gods help those who help themselves' and 'Always cut the
cards, count the change and don't sit with your back to the door'.
If your company believes that you are worthy of all this very expensive
on-the-job training they are giving you... then who are you to object? As
my Sainted Mother - may she sleep with the angels! - used to say, 'What
you carry between your ears is the hardest thing to take from you'.
DD
docd...@panix.com
William M. Klein <wmk...@nospam.netcom.com> wrote:
>Coming up with another approach entirely to the problem.
If he's allowed to to that, Mr Klein, it would seem to make life Much
Easier.
[snip]
>It seems to me that some (possibly most) of the problems come from the
>"download" process of the unloaded file being created as "line sequential".
I believe - and my memory might be as porous as usual - that the
difficulty is twofold: the data being unloaded on the mainframe contain
Japanese characters and the files are being transferred with an
EBCDIC-to-ASCII translation. Off the top of my pointy little head I'd
suggest the following test for a small sample, no more than 10,000 rows:
1) Mainframe side - use IKJEFT01 to execute SQL and SELECT the sample of
rows to an FB output file.
2) Transfer the file to the ASCII platform *as binary*.
3) Set up a MicroFocus program to read the transferred file in EBCDIC and
INSERT each record as a row into a table defined exactly as the mainframe
one is defined... using a copy of the mainframe DCLGEN would make life
much easier.
4) See what happens... get a 'smell' of the results and the time it takes
to get them. If it works the way I believe it will then one might begin
to consider ways to speed the process up so that decent amounts of data
might be handled... 60,000,000 rows and the like.
(A major, somewhat hidden, advantage to this test is that it uses methods
that are unsophisticated; as such they run less of a chance of creating
the 'I don't understand it so I won't let you do it' response.)
DD
Pete Dashwood
"Robert" <n...@e.mail> wrote in message
news:o7e29413ea3ou9hjb...@4ax.com...
Cool!
Will it work on ANY platform...?
Robert
wrote:
INSPECT .. CONVERTING and hex literals are in the 2002 Standard.
Frank Swarbrick
<j5t394p8198810n80...@4ax.com>, Robert<n...@e.mail> wrote:
>
> INSPECT .. CONVERTING and hex literals are in the 2002 Standard.
I'm guessing it should work on any Cobol that supports the 1985 standard.
For instance, Cobol for VSE. Works like a charm. Wish I had thought of it!
:-)
Frank
Frank Swarbrick
<4891F6AF.6...@efirstbank.com>,
By the way, on VSE at least this appears to be amazingly efficient.
45E0 D136 BAL 14,310(0,13) TGT TEST INFORMATION
AREA +10
GN=12 EQU *
DC4F 9000 A018 TR 0(80,9),24(10) MY-STRING
PGMLIT AT +20
Frank Swarbrick
comp.databases.ibm-db2 newsgroup? I just can't see why a Cobol solution
should be required. Since this is DB2 to DB2, there should be a DB2 only
resolution.
In my opinion, of course!
Frank
Robert
>"Robert" <n...@e.mail> wrote in message
>news:fhc3949gck3o6sp2p...@4ax.com...
>> In the brave new world of contract programming, unreasonable assignments
>> are semi-common.
>> I was once assigned to write a new program from scratch in a language (VB)
>> I barely knew...
>
>Pray, how on earth were you selected as the contractor?
The usual way -- for Cobol and SQL skills. Employers are overly selective during the
hiring phase. Once a contractor is on board, that goes out the window; the only thing that
counts is availability.
"We need this program written in three days."
"So get one of those VB programmers to write it."
"They're busy on other assignments. You're the only one available."
"But I don't know VB well enough to write it."
"If you can't do it, we'll find someone who can."
"You just said no one else was available."
"We'll hire your replacement."
>And why on earth did you - as a professional contractor - accept such an
>assignment?
They didn't ASK whether I wanted to do it. They said get it done or else.
>> I've seen worse, for example people assigned to work on huge
>> mission-critical mainframe assembly language programs with two weeks'
>> training in Cobol
>> and no clue about assembly language on any machine....
>
>Worse yet: someone who does know the 'language product(s) of choice'
>extremely well, but is clueless about the application.
Understanding the application is the analyst's job.
>I ran into this about ten years ago. I was doing some mapping of ANSI EDI
>data (that's about 70% of what I do) for a client in Janesville WI. Part of
>this mapping required an application run against an ERP system's database,
>and since I was not (and still am not) familiar with the client's "language
>product of choice" (Microsoft Visual BASIC) and at that time not any good
>with Oracle/SQL, another contractor (from a 'major brand name consulting
>firm in Wisconsin') was engaged to create that application.
>
>I laid out for him what I wanted... simple text file containing five or six
>delimited columns of data extracted from the ERP system's database, and the
>conditions under which a record was to appear in that file. I would then map
>that data into fully-enveloped ANSI X12 transaction sets. Simple, yes?
Yes. Sounds like a half-hour job.
>Well, this "consultant" ( a misuse of the word if ever there was one) took
>it upon himself to try to map the data to ANSI himself. He had great
>difficulty (like, that was a surprise?). But he did this without telling
>anyone.
That's not easy, unless he had third-party software to format EDI.
>Three weeks later, the project was due; and I mean DUE. I had to tell the
>client I was waiting on the required input, but once I had it I could map
>the data in an afternoon. The other consultant was out that day, so I was
>asked to look at his 'work product to date' and see if I could use what he
>had and maybe make something out of what was done. (Did I mention, this
>project was REALLY DUE?) .
>
>DISASTER! Not only had the 'consultant' not been able to map the ANSI data,
>he had not even completed the extraction of the required data from the ERP
>database!
>
>About 4:00 PM I sat down with the client's 'database guys' (employees of
>client) who both knew Oracle pretty well, but did not know the application.
>I showed them the text file I had orginally asked for, the tables in the
>database where the data were located, and asked if they could create the
>file using Oracle tools and utilities. They said they thought so .. so they
>went off to play with the database, whilst I created the mapping code based
>on their ability to create that input.
There's no need for tools and utilities. It can be done in straight SQL.
>They succeeded in creating the data. I succeeded in creating the ANSI ASC
>X12 output. The required ANSI document was sent to the partner about 8:00
>PM.
>
>Three weeks of consultant fees totally wasted by the client! I see things
>like this and it drives me nuts: just like with lawyers, you get a couple of
>bad apples and we ("real" consultants) ALL look bad.
Sounds like bad management. There should have been milestones. For such a simple task, two
day milestones sounds about right.
>If I can accomplish one thing before I go thru that final checkout line, I
>will see contractors and consultants regarded as true professionals -
>because we have EARNED that respect.
You're pissing into a gale force wind. The contracting scene is full of low-paid
foreigners willing to try anything, and having NO bargaining power. Clients expect low
productivity and quality. They don't care because three contractors cost less than one
'professional'. A big plus is the fact they don't talk back, don't point out management
mistakes in public (you should hear what they say in private.)
>So, um, Robert..... let's not accept any more contractor assignments for
>which are not qualified, OK?
If I refused to do taks for which I'm not qualified, I'd be looking for a new job every
month or two.
What's more difficult is following instructions to do things WRONG in an area where I'm
MORE knowledgable than the boss. This occurs often in version control, which is my
specialty. Managers often want simple-minded solutions based how they did it with flat
files before they got version control. 'All ya gotta do is copy uncontrolled files over
controlled ones. What's so hard about that?' When I diplomatically try to explain version
control was created to STOP such abuse, it's like talking to the wall. Later, when they
learn changes were overwritten, they say 'See, I told you the version control doesn't
work. We even had an expert move the code.'
taoxi...@gmail.com
wrote:
VRECGEN is the supplied on Microfocus mainframe and Net Express...at
least as I searched.
And the original system is IBM Z/OS running IBM cobol.
taoxi...@gmail.com
> In article <6b77cbd3-b3eb-40ce-957f-1a977d609...@b38g2000prf.googlegroups.com>,
You sound like a philosopher...but really hit me.
Shall we stop talking about sayings?
taoxi...@gmail.com
wrote:
Well,that's a good idea since the essential result is some records are
deleted from DB.
It also reminds that's even possible to do it with some DB2 procedure.
I just need some time to put my mind in order and conclude your posts.