Re: Dashwood
- From: "HeyBub" <heybub@xxxxxxxxxxxxxxx>
- Date: Fri, 24 Oct 2008 07:04:49 -0500
Pete Dashwood wrote:
"HeyBub" <heybub@xxxxxxxxxxxxxxx> wrote in message
news:y7ednZ_D6vmUBZ3UnZ2dnUVZ_gKdnZ2d@xxxxxxxxxxxxxxxx
Found another oddity in NEWCOBDATA:
The following copy book
NSFIRMFP.
05 NSFIRMFP-KEY PIC 9(7). *>401-425
05 NSFIRMFP-KEY-SPARE PIC X(1).
05 NSFIRMFP-DATA PIC X(500).
05 FILLER REDEFINES NSFIRMFP-DATA.
10 NSFIRMFP-VENDOR PIC X(6).
10 NSFIRMFP-PUT-PATH PIC X(120).
10 NSFIRMFP-GET-PATH PIC X(120).
10 NSFIRMFP-FTP-SERVER PIC X(50).
10 NSFIRMFP-LOGIN PIC X(12).
10 NSFIRMFP-PASSWORD PIC X(12).
10 NSFIRMFP-PUTFILE PIC X(20). *>See Note
10 NSFIRMFP-PUTFILE-EXT PIC X(3).
10 NSFIRMFP-GETFILE PIC X(20). *>See Note
10 NSFIRMFP-GETFILE-EXT PIC X(3).
*>
Generates
COBOLEngine.Version 2.0.0.06
Lvl Name Pos Len Typ Oc
1 NS 1
2 05 NSFIRMFP-KEY 1 7
3 05 NSFIRMFP-KEY-SPARE 8 1
4 05 NSFIRMFP-DATA 9 500
5 05 FILLER 9 366
6 10 NSFIRMFP-VENDOR 9 6
7 10 NSFIRMFP-PUT-PATH 15 120
8 10 NSFIRMFP-GET-PATH 135 120
9 10 NSFIRMFP-FTP-SERVER 255 50
10 10 NSFIRMFP-LOGIN 305 12
11 10 NSFIRMFP-PASSWORD 317 12
12 10 NSFIRMFP-PUTFILE 329 20
13 10 NSFIRMFP-PUTFILE-EXT 349 3
14 10 NSFIRMFP-GETFILE 352 20
15 10 NSFIRMFP-GETFILE-EXT 372 3
Record length 374
The program computed a record length of 374 bytes, but the true
length is 508 bytes. The program clearly did not honor the 4th line
[ PIC X(500) ], but instead totaled the lengths of the redefined
part. The program also did not carry over the first line [ NSFIRMP] to
the
output - probably because it does not have a level number. Instead
the program took the first two letters ["NS"] of the variable name
and, I guess, assumed that was a level...
We use this construct (no initial level number) in situations like:
01 COPY something.COB
or
01 SOME-OLD-THING.
02 COPY something.COB
depending on the situation.
Just FYI.
Jerry
Jerry,
I spent a little time looking through this and have taken some
liberties with Robert's code.
It now appears to be working correctly. It also creates a dummy 01
level in cases where a partial layout is presented to it, and handles
the case of an 01 without a level. The record byte count at the end
of the report is now accurate also.
I'll update the Web Site over the weekend and advise here when
updates are available.
(I'm not sure but I think I set the tool to look for updates every 7
days if a web connection is available... might be better to just
re-download manually.)
Thanks for the feedback,
Thank you for the tool. I've been using it and it has found a few errors in
our (hand) computed copy-book lengths. Nothing major, but an irritation
removed nonetheless.
We have a routine to print these copy books for reference and I'm modifying
this print routine to grab the corresponding NEWCOBDATA file and append it.
One fiddle is that NEWCOBDATA insists that it's output file extension be
..TXT. That is, if I specify an output file name of NSFILE1.LEN, I get
NSFILE1.LEN.TXT. It's possible for the original COBOL COPY book to use an
extension of .TXT, so you can see the impending train wreck...
It would be nice to default to .TXT, but allow the user to specifiy
something else...
.
- Follow-Ups:
- Re: Dashwood
- From: Pete Dashwood
- Re: Dashwood
- From: Pete Dashwood
- Re: Dashwood
- References:
- Ping: Dashwood
- From: HeyBub
- Re: Dashwood
- From: Pete Dashwood
- Ping: Dashwood
- Prev by Date: Re: read by which index?
- Next by Date: Re: read by which index?
- Previous by thread: Re: Dashwood
- Next by thread: Re: Dashwood
- Index(es):
Relevant Pages
|
