Home > Archive > Cobol > October 2007 > netcobol question
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| tleaders...gmail.com 2007-10-11, 6:55 pm |
| I am using NetCOBOL for .NET version V2.0L10.
When I run this program
IDENTIFICATION DIVISION.
PROGRAM-ID. TST-TEMP.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
DATA DIVISION.
FILE SECTION.
WORKING-STORAGE SECTION.
01 DATA-GROUP.
05 DG-ALPHA PIC X(10).
05 DG-NUM PIC S9(9) COMP-3.
05 DG-NUM2 PIC 9(3).
PROCEDURE DIVISION.
START-IT-ALL.
DISPLAY "TESTING MOVE SPACES".
MOVE SPACES TO DATA-GROUP.
IF DG-NUM = 0
DISPLAY "NUM IS 0"
ELSE
DISPLAY "NUM IS NOT 0"
END-IF.
IF DG-NUM2 = 0
DISPLAY "NUM2 IS 0"
ELSE
DISPLAY "NUM2 IS NOT 0"
END-IF.
IF DG-ALPHA = SPACES
DISPLAY "ALPHA IS SPACES "
ELSE
DISPLAY "ALPHA IS NOT SPACES"
END-IF.
DISPLAY "TESTING INITIALIZE".
INITIALIZE DATA-GROUP.
IF DG-NUM = 0
DISPLAY "NUM IS 0"
ELSE
DISPLAY "NUM IS NOT 0"
END-IF.
IF DG-NUM2 = 0
DISPLAY "NUM2 IS 0"
ELSE
DISPLAY "NUM2 IS NOT 0"
END-IF.
IF DG-ALPHA = SPACES
DISPLAY "ALPHA IS SPACES "
ELSE
DISPLAY "ALPHA IS NOT SPACES"
END-IF.
PROG-END.
STOP RUN.
I get this output
TESTING MOVE SPACES
NUM IS NOT 0
NUM2 IS NOT 0
ALPHA IS SPACES
TESTING INITIALIZE
NUM IS 0
NUM2 IS 0
ALPHA IS SPACES
Here is my problem. When I move spaces to a group level item I would
expect that the numeric display item to test as zero, and the numeric
comp item not to test as zero. This is the result that I would expect.
NUM IS NOT 0
NUM2 IS 0
ALPHA IS SPACES
Is there a control setting / flag that I missed in the documentation?
Thanks in advance for your help.
Tom
| |
| Doug Miller 2007-10-11, 6:55 pm |
| In article <1192112346.309248.85020@r29g2000hsg.googlegroups.com>, "tleaders...gmail.com" <tleaders@gmail.com> wrote:
>I get this output
>
>TESTING MOVE SPACES
>NUM IS NOT 0
>NUM2 IS NOT 0
>ALPHA IS SPACES
>TESTING INITIALIZE
>NUM IS 0
>NUM2 IS 0
>ALPHA IS SPACES
Which of course is *exactly* what is expected.
>Here is my problem. When I move spaces to a group level item I would
>expect that the numeric display item to test as zero, and the numeric
>comp item not to test as zero.
Indeed, that is your problem: that you are expecting things to happen, that
the Cobol standard explicitly says will *not* happen. What you *should* expect
is that the program will do exactly what you told it to do: MOVE SPACES to the
group item. Which, of course, is just what it did.
> This is the result that I would expect.
>NUM IS NOT 0
>NUM2 IS 0
>ALPHA IS SPACES
Why would you expect that? You told it to move spaces. It moved spaces. Spaces
and zeros are not the same. If you want spaces in the alphanumeric items, and
zeros in the numeric ones, use INITIALIZE. That's what it's for. And your
testing shows, unsurprisingly, that it works for that purpose just as
expected.
>
>Is there a control setting / flag that I missed in the documentation?
What you missed in the documentation is the description of the way a MOVE to a
group item behaves -- and, possibly, the description of INITIALIZE, too: I'll
bet that under that heading, your documentation explains exactly how the
behavior of INITIALIZE differs from the behavior of a group MOVE.
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Robert 2007-10-11, 6:55 pm |
| On Thu, 11 Oct 2007 14:19:06 -0000, "tleaders...gmail.com" <tleaders@gmail.com> wrote:
>I am using NetCOBOL for .NET version V2.0L10.
>
> 01 DATA-GROUP.
> 05 DG-ALPHA PIC X(10).
> 05 DG-NUM PIC S9(9) COMP-3.
> 05 DG-NUM2 PIC 9(3).
>
> PROCEDURE DIVISION.
> START-IT-ALL.
> DISPLAY "TESTING MOVE SPACES".
> MOVE SPACES TO DATA-GROUP.
>
> DISPLAY "TESTING INITIALIZE".
> INITIALIZE DATA-GROUP.
>
>I get this output
>
>TESTING MOVE SPACES
>NUM IS NOT 0
>NUM2 IS NOT 0
>ALPHA IS SPACES
>TESTING INITIALIZE
>NUM IS 0
>NUM2 IS 0
>ALPHA IS SPACES
>
>
>Here is my problem. When I move spaces to a group level item I would
>expect that the numeric display item to test as zero, and the numeric
>comp item not to test as zero. This is the result that I would expect.
>NUM IS NOT 0
>NUM2 IS 0
>ALPHA IS SPACES
>
>Is there a control setting / flag that I missed in the documentation?
The option you're looking for is SPZERO and run-time switch -F.
If you want a fast way to initialize DATA-GROUP, create another structure just like it
(perhaps using typedef for both), INITIALIZE the second structure once, do a group move to
initialize DATA-GROUP.
| |
| Judson McClendon 2007-10-11, 6:55 pm |
| "Robert" <no@e.mail> wrote:
>
> The option you're looking for is SPZERO and run-time switch -F.
>
> If you want a fast way to initialize DATA-GROUP, create another structure just like it
> (perhaps using typedef for both), INITIALIZE the second structure once, do a group move to
> initialize DATA-GROUP.
When he says "just like it," he doesn't mean that the actual data names
need to be the same. Only the number, type, size and sequence of the
fields must to be the same, for this purpose. You may want to make
the data names similar for clarity, but if they are identical, you will have
to qualify every reference to any of the data names.
Personally, I like to assign a unique prefix (usually an acronym derived
from the record name) to every field within a given record (01 data item).
Then the two records Robert described above would be identical, except
for the prefixes of the data names.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Louis Krupp 2007-10-11, 6:55 pm |
| tleaders...gmail.com wrote:
> I am using NetCOBOL for .NET version V2.0L10.
>
> When I run this program
> IDENTIFICATION DIVISION.
> PROGRAM-ID. TST-TEMP.
> ENVIRONMENT DIVISION.
> CONFIGURATION SECTION.
> INPUT-OUTPUT SECTION.
> FILE-CONTROL.
> DATA DIVISION.
> FILE SECTION.
> WORKING-STORAGE SECTION.
>
> 01 DATA-GROUP.
> 05 DG-ALPHA PIC X(10).
> 05 DG-NUM PIC S9(9) COMP-3.
> 05 DG-NUM2 PIC 9(3).
>
> PROCEDURE DIVISION.
> START-IT-ALL.
> DISPLAY "TESTING MOVE SPACES".
> MOVE SPACES TO DATA-GROUP.
> IF DG-NUM = 0
> DISPLAY "NUM IS 0"
> ELSE
> DISPLAY "NUM IS NOT 0"
> END-IF.
> IF DG-NUM2 = 0
> DISPLAY "NUM2 IS 0"
> ELSE
> DISPLAY "NUM2 IS NOT 0"
> END-IF.
> IF DG-ALPHA = SPACES
> DISPLAY "ALPHA IS SPACES "
> ELSE
> DISPLAY "ALPHA IS NOT SPACES"
> END-IF.
>
>
> DISPLAY "TESTING INITIALIZE".
> INITIALIZE DATA-GROUP.
> IF DG-NUM = 0
> DISPLAY "NUM IS 0"
> ELSE
> DISPLAY "NUM IS NOT 0"
> END-IF.
> IF DG-NUM2 = 0
> DISPLAY "NUM2 IS 0"
> ELSE
> DISPLAY "NUM2 IS NOT 0"
> END-IF.
> IF DG-ALPHA = SPACES
> DISPLAY "ALPHA IS SPACES "
> ELSE
> DISPLAY "ALPHA IS NOT SPACES"
> END-IF.
>
> PROG-END.
> STOP RUN.
>
>
>
>
> I get this output
>
> TESTING MOVE SPACES
> NUM IS NOT 0
> NUM2 IS NOT 0
> ALPHA IS SPACES
> TESTING INITIALIZE
> NUM IS 0
> NUM2 IS 0
> ALPHA IS SPACES
>
>
> Here is my problem. When I move spaces to a group level item I would
> expect that the numeric display item to test as zero, and the numeric
> comp item not to test as zero. This is the result that I would expect.
> NUM IS NOT 0
> NUM2 IS 0
> ALPHA IS SPACES
>
> Is there a control setting / flag that I missed in the documentation?
>
> Thanks in advance for your help.
>
> Tom
>
You may be confusing what happens when you move DG-NUM2 to an edited
field PIC Z(3) -- if DG-NUM2 is 0, then you get three spaces -- with
what is actually stored in DG-NUM2 if you set it to zero. For ASCII
machines (i.e., something other than an IBM mainframe or Unisys MCP
system), a '0' character is hex 30, and a space is hex 20.
If you test DG-NUM2 to see if it was numeric after you moved spaces to
DATA-GROUP, I wouldn't be surprised if the result turns out to be false.
Louis
| |
| tleaders...gmail.com 2007-10-11, 6:55 pm |
| Robert - thanks I will read up on the SPZERO and run-time switch -F
and try to test it this wend.
For the rest. This was a sample program that I wrote to show the
issue.
I should mention that I am maintaining Unisys A-Series Cobol 74 code
but I port the code and do all the initial testing on my notebook in
cobol.net. This allows me to build/update/destroy the data in sql
server, and the debugging tools are a lot better.
The initialize verb is not available on A-Series Cobol74 at least not
with the settings that I am running. And Yes I could change to Cobol85
but at this time I see no ROI for that effort.
Also the code on the A-series (Clearpath) behaves exactly as I
described.
By the way Doug that was a rather verbose way of saying NO I don't
have a clue.
Tom
| |
| Doug Miller 2007-10-11, 6:55 pm |
| In article <1192127701.497708.78990@k79g2000hse.googlegroups.com>, "tleaders...gmail.com" <tleaders@gmail.com> wrote:
>By the way Doug that was a rather verbose way of saying NO I don't
>have a clue.
<snort>
It wasn't *me* who was expecting MOVE SPACES to produce zeros.
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| tleaders...gmail.com 2007-10-11, 6:55 pm |
| On Oct 11, 3:23 pm, spamb...@milmac.com (Doug Miller) wrote:
> In article <1192127701.497708.78...@k79g2000hse.googlegroups.com>, "tleaders...gmail.com" <tlead...@gmail.com> wrote:
>
>
> <snort>
>
> It wasn't *me* who was expecting MOVE SPACES to produce zeros.
>
> --
> Regards,
> Doug Miller (alphag at milmac dot com)
>
> It's time to throw all their damned tea in the harbor again.
http://supportline.microfocus.com/d...1sp1/cyswit.htm
SPZERO - causes space characters in numeric data items of USAGE
DISPLAY to be treated as zeros.
| |
| Louis Krupp 2007-10-11, 6:55 pm |
| tleaders...gmail.com wrote:
<snip>
> Also the code on the A-series (Clearpath) behaves exactly as I
> described.
Quoting from the B5900 System Reference Manual:
The numeric field (low-order four bits) of each character in an EBCDIC
sequence is interpreted as a decimal digit. The corresponding digit
sequence is the sequence of numeric fields with the zone fields
(high-order four bits) removed. ...
Sounds like the A-Series box is also doing it in hardware (or firmware
or whatever) and is masking out the zone fields, so an EBCDIC space (hex
40, if I recall correctly) conveniently comes out 0 just like an EBCDIC
'0' (hex F0).
netcobol *could* have done the same thing, but, by default, didn't.
Most of the decimal to binary conversion code I've seen computes the
decimal value by subtracting '0' from the character. This assumes only
that the characters '0' through '9' are represented by continuous values.
Louis
| |
| William M. Klein 2007-10-11, 6:55 pm |
| FYI - IBM has a comparable setting "ZWB" (zero when blank). Compiler option.
I don't think it works "universally" to allow spaces to be treated as zeros, but
it does for some statements. (also by ignoring high-order nibble)
--
Bill Klein
wmklein <at> ix.netcom.com
"Louis Krupp" <lkrupp@pssw.nospam.com.invalid> wrote in message
news:13gt2bhli6h1q2e@corp.supernews.com...
> tleaders...gmail.com wrote:
> <snip>
>
>
> Quoting from the B5900 System Reference Manual:
>
> The numeric field (low-order four bits) of each character in an EBCDIC
> sequence is interpreted as a decimal digit. The corresponding digit sequence
> is the sequence of numeric fields with the zone fields (high-order four bits)
> removed. ...
>
> Sounds like the A-Series box is also doing it in hardware (or firmware or
> whatever) and is masking out the zone fields, so an EBCDIC space (hex 40, if I
> recall correctly) conveniently comes out 0 just like an EBCDIC '0' (hex F0).
>
> netcobol *could* have done the same thing, but, by default, didn't. Most of
> the decimal to binary conversion code I've seen computes the decimal value by
> subtracting '0' from the character. This assumes only that the characters '0'
> through '9' are represented by continuous values.
>
> Louis
| |
| Robert Jones 2007-10-11, 6:55 pm |
| On Oct 11, 6:34 pm, "Judson McClendon" <ju...@sunvaley0.com> wrote:
> "Robert" <n...@e.mail> wrote:
>
>
>
>
> When he says "just like it," he doesn't mean that the actual data names
> need to be the same. Only the number, type, size and sequence of the
> fields must to be the same, for this purpose. You may want to make
> the data names similar for clarity, but if they are identical, you will have
> to qualify every reference to any of the data names.
>
> Personally, I like to assign a unique prefix (usually an acronym derived
> from the record name) to every field within a given record (01 data item).
> Then the two records Robert described above would be identical, except
> for the prefixes of the data names.
> --
> Judson McClendon ju...@sunvaley0.com (remove zero)
> Sun Valley Systems http://sunvaley.com
> "For God so loved the world that He gave His only begotten Son, that
> whoever believes in Him should not perish but have everlasting life."
I like the idea, but it would be less code to INITIALIZE the original
group data item, store it in an elementary data item of the same
length and move that back into the original group data item whenever
required. It might even be the case that an optimising compiler would
do this automatically where INITIALIZE is used repetitively for the
same group data item.
| |
| Judson McClendon 2007-10-11, 6:55 pm |
| "Robert Jones" <rjones0@hotmail.com> wrote:
> "Judson McClendon" <ju...@sunvaley0.com> wrote:
>
> I like the idea, but it would be less code to INITIALIZE the original
> group data item, store it in an elementary data item of the same
> length and move that back into the original group data item whenever
> required. It might even be the case that an optimising compiler would
> do this automatically where INITIALIZE is used repetitively for the
> same group data item.
I agree, that would be better. What would be *really* nice is if you could
do this:
01 the-record.
03 the-field-a pic ...
03 the-field-b pic ...
...
01 the-record-initialize pic x(SizeOf(the-record)). :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Robert 2007-10-11, 9:55 pm |
| On Thu, 11 Oct 2007 18:41:49 -0500, "Judson McClendon" <judmc@sunvaley0.com> wrote:
>"Robert Jones" <rjones0@hotmail.com> wrote:
>
>I agree, that would be better. What would be *really* nice is if you could
>do this:
>
>01 the-record.
> 03 the-field-a pic ...
> 03 the-field-b pic ...
> ...
>
>01 the-record-initialize pic x(SizeOf(the-record)). :-)
You can do that under Micro Focus (and under the '02 Standard, with slightly different
syntax).
78 the-record-length value length of the-record.
01 the-record-initialize pic x(the-record-length).
Another good use of 78 is to get the number of entries in a table.
01 big-table.
05 first-entry value 'abc def' pic x(07).
05 value 'bcd efg' pic x(07).
.... 1,000 more values
01 redefines big-table.
78 entries-in-table value
length of big-table / length of first-entry.
05 table-entry occurs entries-in-table.
10 antecedent pic x(04).
10 consequent pic x(03).
perform varying sub from entries-in-table by -1 until sub = zero
perform varying sub from 1 by 1 until sub > entries-in-table
....
You must name the first entry because Micro Focus doesn't allow forward reference on 78.
The '02 Standard syntax does allow forward reference as:
01 entries-in-table CONSTANT [as] length of big-table / length of table-entry.
| |
| Robert 2007-10-11, 9:55 pm |
| On Thu, 11 Oct 2007 18:35:01 -0000, "tleaders...gmail.com" <tleaders@gmail.com> wrote:
>Robert - thanks I will read up on the SPZERO and run-time switch -F
>and try to test it this wend.
SPZERO is if you're executing native code; -F is if you're running the .int.
Of course, neither will work on Unisys nor any compiler but Micro Focus.
> And Yes I could change to Cobol85
>but at this time I see no ROI for that effort.
For a better trip trip through the wayback machine, Unisys was still supporting a '68
compiler two years ago. They may have dropped it by now; it wouldn't hurt to ask.
| |
|
| tleaders...gmail.com wrote:
> I should mention that I am maintaining Unisys A-Series Cobol 74 code
> but I port the code and do all the initial testing on my notebook in
> cobol.net. This allows me to build/update/destroy the data in sql
> server, and the debugging tools are a lot better.
Does the Unisys manual indicate that the behavior you're expecting is
what *should* be expected?
> The initialize verb is not available on A-Series Cobol74 at least not
> with the settings that I am running.
Yep - it's a COBOL 85 creation.
> And Yes I could change to Cobol85
> but at this time I see no ROI for that effort.
> Also the code on the A-series (Clearpath) behaves exactly as I
> described.
Hmm... That's odd. One thing you can do, though, is create a second
variable of the size you need, and ensure the "work" area is initialized
the way you want it. Then, when the program starts, move that to a big
PIC X field, and use that to do your group-level initialization moves.
Something like...
01 THIS-HERE-VAR.
12 THIS-VAR-1 PIC 9(06) VALUE ZERO.
12 THIS-VAR-2 PIC X(10) VALUE SPACES.
12 FILLER PIC X(22) VALUE ALL '-'.
12 THIS-VAR-3 PIC 9(03) VALUE 123.
01 INIT-THIS-HERE-VAR PIC X(41).
MOVE THIS-HERE-VAR TO INIT-THIS-HERE-VAR.
*MOVE SPACES TO THIS-HERE-VAR.
MOVE INIT-THIS-HERE-VAR TO THIS-HERE-VAR.
(Of course, INIT-THIS-HERE-VAR could be any size, as long as it's big
enough. An alphanumeric move would left-justify or truncate as needed.)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++
"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| tleaders...gmail.com 2007-10-15, 6:55 pm |
|
Thanks to everyone for their suggestions.
Some years ago I started writing a sql file system for my Cobol
programs as an intellectual exercise, to learn the whole ".Net"
concept. I decided to write my own because I did not like the
underlying logic model used at the last place that I worked. After all
"How Hard Could It Be" - months (nights and wends) later the new
system was better, more responsive, and easer to modify the tables.
Then I decided to move the A-series Cobol 74 programs to my notebook,
so I could maintain the documentation and cross references in sql. It
was at this point that I saw the difference between a group level
"move spaces" on the old system and an initialize on my notebook. I
modified the one of transfer programs to change "move spaces" to
initialize in most cases. Then I moved on.
Then because I had the programs on my notebook I generated the data
export and import programs to move data from the Unisys machine to my
notebook and tested the programs to make sure that they work.
Then I started using my notebook to test major program changes and
putting the corrections back to Unisys.
I bought one of the earliest versions of cobol.net and the
documentation was directed more towards the windows product. I thought
that I might be missing a flag/option that would fill this niche from
someone with a later version on the compiler. Thanks anyway I guess
that I'm stuck with initialize.
Things I learned along the way.
Extract the FD to a file: While you can generate import/export
programs directly from the FD, when start building create tables and
indexes you will need the key information from the select. Might as
well be consistent from the start.
After you export your ebcdic indexed file to a flat text file, and
transfer/convert it to ascii. Watch out for those ebcdic characters
that have no ascii equivalent. Sql bulk inserts will load them into a
table. Cobol.net will abort, treating at least some of these
characters as end-of-file. VB.Net will ignore the character and shift
the record. So the data in column 50 is now in column 49.
Split the create table and create index into 2 separate processes.
Then first create the table, use a sql bulk load to load the data, and
then create the indexes. On my notebook, like me it is old and slow, a
200,000 record table will take more than an hour longer to load if the
indexes and triggers are in place.
I converted an existing Cobol screen program in vb.net. The Cobol
program was 13798 lines long, accessed 12 files, contained 11 main
screen, 5 sub screens, and had 1884 literals and fields. It also
contained all the field validation and update logic.
The VB program contained 13884 line of "windows generated code". It
was a windows form with 11 tab pages that matched the old screens and
contained 1068 literals and fields. The VB program contained no logic
other that the designer fields.
I know that you are thinking that "but the VB code was generated by
Visual Studio", true, but the Cobol program was also generated in
1988.
The version of the compiler I am running is limited to 35,000 methods
and seems to count everything as a method. The 13798 line program blew
out this limit when I tried to convert it to a series of objects. I
see that later versions have bumped this limit to 1mil.
Time to go write something.
Later
Tom
|
|
|
|
|