Cobol - Are identifier names case sensitive?

Author

Are identifier names case sensitive?

Oliver Wong

2006-02-09, 9:55 pm

I know that the keywords in COBOL are not case sensitive. That is,
"PROCEDURE DIVISION" could just as well be written "procedure division". But
are the identifier names case sensitive? That is, if I declare in my data
division an item called "StudentID", can I later refer to it in a DISPLAY
statement as "StudentId" (lowercase 'd')?

What (other?) exceptions are there to COBOL's case-insensitivity? I know
that the PIC strings are case sensitive, so that PIC AAA is not the same as
PIC aaa. And string literals are probably case sensitive (that is, the
literal "Hello World!" probably evaluates to a different value that "hello
world!"). Anything else?

- Oliver

2006-02-10, 3:55 am

William M. Klein wrote:
> Pic AAA *is* the same as PIC aaa
>
> All NON-literal "COBOL characters" (identifiers, key words, words reserved in
> context) are case IN-sensitive (unless some non-Standard extension is in
> effect). Even the "D" in column 7 is case insensitive.
>
> NOTE:
> Particularly "interesting" is that
>
> 01 This External Pic X.
>
> *will* match
>
> 01 THIS External PIC x.
>
> in another program.
>
> NOTE:
> There was a question/issue about "editing" symbols in PICTURE clauses, but I
> *believe* that this is now resolved and they, too, are "insensitive" (similarly
> "CR" and "DB" in NumVal-C).
>
> NOTE2:
> With the '02 Standard, there are also issues about "non-Latin-1" characters.
> The "Unicode" upper-/lower-case rules apply - and are documented in the '02
> Standard.
>
Without getting into details [too much to digest here], you may want to
check out the Ent. COBOL Compiler option:
> PGMNAME(LONGMIXED)
> With PGMNAME(LONGMIXED), program-names are processed as is, without truncation,
> translation, or folding to uppercase.
See the Programming Guide for details.
Carl

Chuck Stevens

2006-02-10, 6:55 pm

"CG" <carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote in message
news:91b47$43ec1942$453db2dd$26451@FUSE.NET...

> Without getting into details [too much to digest here], you may want to
> check out the Ent. COBOL Compiler option:
> See the Programming Guide for details.
> Carl

Ummm ... What is "Ent. COBOL", and which "Programming Guide" should by all
readers in all shops be understod to be THE programming guide? And how does
this "feature" relate to the requirement of ISO/IEC 1989:2002 page 62,
8.1.2.1, COBOL character repertoirte, General Rule 3a: "Except when used in
the non-hexadecimal formats of alphanumeric and national literals, each
uppercase COBOL basic letter is equivalent to its corresponding lowercase
COBOL basic letter, if any"?

Stated a different way, I might want to "see the Programming Guide for
details", but I fail to see exactly what those details would have to do with
programming in standard COBOL or, for that matter, with programming in COBOL
on Unisys enterprise servers!

Or are we back to the premise that the only *real* computers are IBM
mainframes and the only *real* COBOL is whatever IBM offers at the moment?

-Chuck Stevens

Oliver Wong

2006-02-10, 6:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:V6QGf.126002$fw3.56478@fe07.news.easynews.com...
> Pic AAA *is* the same as PIC aaa

Thanks for that correction. I read through my references to try to find
what I was thinking of, and found this:

<quote>
The lowercase letters corresponding to the uppercase letters representing
the PICTURE symbols A, B, P, S, V, X, Z, CR and DB are equivalent to their
uppercase representations in a PICTURE character-string. Other lowercase
letters are not equivalent to their corresponding uppercase representations.
This means that if a lowercase q, for example, has been designated as the
currency symbol the uppercase Q may not be substituted for it, and vice
versa.
</quote>

so it looks like I mis-remembered what the reference had said.

>
> All NON-literal "COBOL characters" (identifiers, key words, words reserved
> in context) are case IN-sensitive (unless some non-Standard extension is
> in effect). Even the "D" in column 7 is case insensitive.

Okay, so to turn the sentence around, *ONLY* literal character strings
are considered case sensitive. Is this correct?

- Oliver

James J. Gavan

2006-02-10, 6:55 pm

Oliver Wong wrote:
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:V6QGf.126002$fw3.56478@fe07.news.easynews.com...
>
>
>
> Thanks for that correction. I read through my references to try to find
> what I was thinking of, and found this:
>
> <quote>
> The lowercase letters corresponding to the uppercase letters representing
> the PICTURE symbols A, B, P, S, V, X, Z, CR and DB are equivalent to their
> uppercase representations in a PICTURE character-string. Other lowercase
> letters are not equivalent to their corresponding uppercase representations.
> This means that if a lowercase q, for example, has been designated as the
> currency symbol the uppercase Q may not be substituted for it, and vice
> versa.
> </quote>
>
> so it looks like I mis-remembered what the reference had said.
>
>
>
>
> Okay, so to turn the sentence around, *ONLY* literal character strings
> are considered case sensitive. Is this correct?
>
> - Oliver
>
To the last question I would suggest "Yes". Literals "Hello World",
"hello world" or "HeLlO wOrLd" are not the same thing if you are doing
comparisons. No big deal. Consider those three if you were using a
Windows Help file, or even writing your own. You enter the characters,
one by one, "HELL" - temporarily change both your input and the element
being searched both to UPPERCASE or LOWERCASE, (using the intrinsic
functions) and compare Input-Literal(1:4) to on-line Help-Element(1:4)
and you have a match, on the input so far - the program 'jumps' and
highlights the first matching entry in the Listbox, (if there is one).

PC-wise I'm not sure if there are specific rules that all the compilers
follow but using OO, Net Express will find methods "OpenFile" or
"OPENFILE" - if the method is found to be missing, then N/E will
generate an error message in LOWERCASE, "Class xxxx doesn't understand
method 'openfile'". The one specific LOWERCASE that I can think of is in
N/E's old style Class Control (read Repository Section) :-

Class-Control.
EidtCustomers class is "edtcustmrs".

It will hiccup on "EDTCUSTMRS".

But as you can see - that's a requirement for a specific compiler approach.

BTW - I would completely ignore pic aaa or pic a(3) - I've never ever
seen code where they have been used - we are adequately covered by
either pic 9 or pic x. I'd be curious to know if anybody is aware of any
current code where pic a(3) is used.

Jimmy

2006-02-10, 6:55 pm

Chuck Stevens wrote:
> "CG" <carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote in message
> news:91b47$43ec1942$453db2dd$26451@FUSE.NET...
>
>
> Ummm ... What is "Ent. COBOL", and which "Programming Guide" should by all
> readers in all shops be understod to be THE programming guide? And how does
> this "feature" relate to the requirement of ISO/IEC 1989:2002 page 62,
> 8.1.2.1, COBOL character repertoirte, General Rule 3a: "Except when used in
> the non-hexadecimal formats of alphanumeric and national literals, each
> uppercase COBOL basic letter is equivalent to its corresponding lowercase
> COBOL basic letter, if any"?
>
> Stated a different way, I might want to "see the Programming Guide for
> details", but I fail to see exactly what those details would have to do with
> programming in standard COBOL or, for that matter, with programming in COBOL
> on Unisys enterprise servers!
>
> Or are we back to the premise that the only *real* computers are IBM
> mainframes and the only *real* COBOL is whatever IBM offers at the moment?

Since the request did not specify any specific environment, I provided a
point of reference that addressed his question. Since it was not YOUR
question, maybe you should temper your temper... You seem to think that
the only COBOL is 'standard' COBOL. 'Standards' do not execute.
Compilers implemented on specific platforms generate code that execute.
I doubt that there is any compiler that is pure 'standard' with no
'implementor defined' variations.

Pete Dashwood

2006-02-10, 6:55 pm

"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:dsiat0$2nk6$1@si05.rsvl.unisys.com...
>
> "CG" <carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote in message
> news:91b47$43ec1942$453db2dd$26451@FUSE.NET...
>

Ah, yes, that would be the COBOL used by the Ents on planet Lizardworld. Or
was it the COBOL that Ear, Nose and Throat specialists use? I find this all
so bewildering... I need to go and lie down...
[color=darkred]
>
> Ummm ... What is "Ent. COBOL", and which "Programming Guide" should by all
> readers in all shops be understod to be THE programming guide?
Blasphemy! Heresy! Get some tar and faggots... (Oops... sticks) Burn the
heretic! Implicit criticism of the Holy Blue! "THE Programming Guide" is the
inspired word of God as revealed through His prophet Gene Amdahl and
enshrined in the Holy Book of POOs. In His wisdom, Holy Blue wrote "THE
Programming Guide" so that mere mortals who could not follow the esoteric
mysteries of the POO could still find salvation through programming. There
is only ONE! All others are false Gods and idols...!

>And how does this "feature" relate to the requirement of ISO/IEC 1989:2002
>page 62, 8.1.2.1, COBOL character repertoirte, General Rule 3a: "Except
>when used in the non-hexadecimal formats of alphanumeric and national
>literals, each uppercase COBOL basic letter is equivalent to its
>corresponding lowercase COBOL basic letter, if any"?
>
> Stated a different way, I might want to "see the Programming Guide for
> details", but I fail to see exactly what those details would have to do
> with programming in standard COBOL or, for that matter, with programming
> in COBOL on Unisys enterprise servers!
>
> Or are we back to the premise that the only *real* computers are IBM
> mainframes and the only *real* COBOL is whatever IBM offers at the moment?
>

Back to that premise...? I didn't know we ever left it.... :-)

You're not seriously suggesting that a puny little outfit like Unisys should
be taken seriously, are you Chuck?

Next we'll have NCR, ICL (Fujitsu), Siemens, Honeywell and CDC people all
requiring equal air time...

Just because Univac were one of the main movers and shakers behind COBOL 48
years ago doesn't mean their derivative company should have any say today.
They didn't go the distance; IBM did.

It is interesting to note that IBM nearly lost their company by "inventing"
the PC. At the very least they shot themselves in the foot. Now they are
promoting Websphere/Java/OpenSource solutions as well as their "real" COBOL
offering... Back both horses and you must come in somewhere...

If one were forced to back ONE of these options, which would it be? Where do
Unisys stand on Java/Open Source solutions? Nowhere? Ooops...

To get serious for a minute (and I hope you realised the above was not...),
I have been part of a triumvirate interviewing people for my own and some
other projects we are currently looking at. Our main platform is currently
Unisys, with the applications running LINC-generated COBOL. (It will be
replaced by a distributed solution, either WinTel or Java or possibly both).
One of my colleagues on the interview panel is responsible for this
environment and LINC and UNISYS are very dear to his heart. Every single
candidate was asked: "Do you have any experience with LINC?" and every
single one responded with a bemused look. It became kind of amusing by the
second day... I'm sure some of them will thnk they missed the job because
they didn't know what LINC was... (certainly not true).

It is also interesting that Unisys are now touting the ability of LINC to
generate C# rather than COBOL. Maybe they ARE trying to have options other
than COBOL... (I wouldn't blame them...)

Pete.

Pete Dashwood

2006-02-10, 9:55 pm

"CG" <carl.gehr.RemoveThis@ThisToo.attglobal.net> wrote in message
news:716c2$43ecf645$453db2dd$20456@FUSE.NET...
> Chuck Stevens wrote:
>
> Since the request did not specify any specific environment, I provided a
> point of reference that addressed his question. Since it was not YOUR
> question, maybe you should temper your temper... You seem to think that
> the only COBOL is 'standard' COBOL. 'Standards' do not execute.
> Compilers implemented on specific platforms generate code that execute. I
> doubt that there is any compiler that is pure 'standard' with no
> 'implementor defined' variations.

Chuck is sensitive on this point and maybe you can understand why he would
be. He has worked tirelessly for many years on providing support and service
to people and on getting a better COBOL standard. He has suffered fierce
debate and abuse in this forum (much of it from me...I am as passionately
anti-standard as he is pro, and I still believe the fiasco of the Standards
committee (17 years to create a standard and then producing something that
requires a degree in International Law so you can read it) was a major nail
in the coffin of COBOL). I have been one of the strongest opponents of the
standard here, and my position is very close to your own; I don't know a
single programmer who reaches for the standards manual rather than the
vendor's manual, when something needs to be looked up or checked.

But having said that, it is important to recognise there are some very good
and dedicated people who have genuinely striven
to make things better in COBOL land. Bill Klein is one (and was villified
for his position by others who were less rigorous in their approach), Chuck
is another. I have kind of agreed not to discuss the standards here
(feelings run pretty high on both sides), so I won't.

Understand that Chuck works for Unisys, and like most of us, is proud of the
company he represents. IBM are a main competitor, and it is irritating when
people just "assume" that any COBOL environment under discussion must
automatically be IBM. As a courtesy, it is good for anyone posting here to
note the environment they are referring to.

BTW, I found your post "interesting" :-) It is many years since I worked on
IBM mainframes but I am always interested to see "new" (well, to me at
least...) compiler options and smart JCL examples. I have followed the posts
on DFSORT with interest also. Maybe Easytrieve will be the final programming
language of choice... :-)

Pete.

Arnold Trembley

2006-02-11, 3:55 am

James J. Gavan wrote:
> (snip - a lot of stuff)
> BTW - I would completely ignore pic aaa or pic a(3) - I've never ever
> seen code where they have been used - we are adequately covered by
> either pic 9 or pic x. I'd be curious to know if anybody is aware of any
> current code where pic a(3) is used.
>
> Jimmy

I think I have only seen PIC A once in 26 years of COBOL coding. I
will have to try it to see if it actually enforces alphabetic characters.

Another thing I have NEVER seen in production COBOL program is a
picture clause with a P in it. I think I know what it should do, but
it's never been needed in any program I saw.

The final thing I have never seen in COBOL is USAGE COMP-1 or COMP-2.
In IBM mainframe COBOL that would be floating-point, single
precision and double-precision, respectively.

Based on my (not necessarily exhaustive) experience, you could remove
PIC A, PIC P, and floating-point from COBOL, and nobody in the
business world would even notice they were gone.

And to get back on topic, I like it that COBOL reserved words or
user-defined names are case-insensitive.

--
http://arnold.trembley.home.att.net/

Colin Campbell

2006-02-11, 3:55 am

Arnold Trembley wrote:

>
>
> James J. Gavan wrote:
>
>
>
> I think I have only seen PIC A once in 26 years of COBOL coding. I
> will have to try it to see if it actually enforces alphabetic characters.
>
> Another thing I have NEVER seen in production COBOL program is a
> picture clause with a P in it. I think I know what it should do, but
> it's never been needed in any program I saw.
>
> The final thing I have never seen in COBOL is USAGE COMP-1 or COMP-2.
> In IBM mainframe COBOL that would be floating-point, single precision
> and double-precision, respectively.
>
> Based on my (not necessarily exhaustive) experience, you could remove
> PIC A, PIC P, and floating-point from COBOL, and nobody in the
> business world would even notice they were gone.
>
> And to get back on topic, I like it that COBOL reserved words or
> user-defined names are case-insensitive.
>
Arnold,
You would care about the removal of floating-point if you had ever
called IBM graphics routines (the product called GDDM) from your COBOL
program. I wrote a set of programs to produce GANTT charts (basically,
graphical project status reports) in COBOL some years ago. Many of the
calls require floating point arguments.

I'm surprised you've never used the "P" picture character. It would be
useful if you received a number, such as "1", which represented hundreds
of units. You could use this number in an arithmetic operation without
multiplying it by 100 in your own code.

Picture character "A" was outlawed in the shop where I used to work at
least twenty years ago. We just figured that we didn't need to have
data definitions which used "A" in preference to "X". I'll bet you
could, if you tried, find a place to use it, though -- maybe to describe
English highway designations?
Colin

2006-02-11, 3:55 am

Arnold Trembley wrote:
>
><SNIP>
>
> Based on my (not necessarily exhaustive) experience, you could remove
> PIC A, PIC P, and floating-point from COBOL, and nobody in the business
> world would even notice they were gone.

Well, IBM tried to remove floating point from the first release of the
VS COBOL II compiler. The user community went ballistic! I'm not sure
R1 was ever installed in a fully production environment. Floating point
was not the only reason, but there was a very large percentage of shops
that designated this as the show-stopper for them. I cannot speak for
other environments, but it was DOA in the IBM environment.
Carl

Arnold Trembley

2006-02-11, 6:55 pm

Colin Campbell wrote:
> (snip)
> Arnold,
> You would care about the removal of floating-point if you had ever
> called IBM graphics routines (the product called GDDM) from your COBOL
> program. I wrote a set of programs to produce GANTT charts (basically,
> graphical project status reports) in COBOL some years ago. Many of the
> calls require floating point arguments.

My thanks to you (and to Carl Gehr) for correcting me. I should have
realized that just because I've never seen COBOL floating-point used
doesn't mean that nobody uses it. I apologize for the error, but I've
only worked in two different COBOL shops in 26 years! I certainly
would not advocate removing floating point from COBOL if there is user
demand for it.

>
> I'm surprised you've never used the "P" picture character. It would be
> useful if you received a number, such as "1", which represented hundreds
> of units. You could use this number in an arithmetic operation without
> multiplying it by 100 in your own code.

Not only have I never used it, I've never seen it used in a production
COBOL program. Perhaps my experience is very limited. Perhaps you
can give some examples of this feature is useful? If it is useful to
some, that's certainly grounds to keep it.

>
> Picture character "A" was outlawed in the shop where I used to work at
> least twenty years ago. We just figured that we didn't need to have
> data definitions which used "A" in preference to "X". I'll bet you
> could, if you tried, find a place to use it, though -- maybe to describe
> English highway designations?
> Colin

Well, not only English highway designations but also English and
Canadian postal codes seem to use alpha characters in a distinct pattern.

I should try some experiments with PIC A to see what it really does.
I assume it's legal in IBM COBOL so test a PIC A field for being
alphabetic.

With kindest regards,

--
http://arnold.trembley.home.att.net/

HeyBub

2006-02-11, 6:55 pm

Colin Campbell wrote:
> Arnold,

> I'm surprised you've never used the "P" picture character. It would
> be useful if you received a number, such as "1", which represented
> hundreds of units. You could use this number in an arithmetic
> operation without multiplying it by 100 in your own code.

You're surprised? Imagine the surprise of a maintenance programmer
confronting:

ADD A TO B GIVING C.

Where "A" is 1, "B" is 2, and "C" turns out to be 102.

Arnold Trembley

2006-02-11, 6:55 pm

In-Reply-To: <d710b$43ed8e8e$453db2dd$6131@FUSE.NET>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 39
Message-ID: <KmsHf.377379$qk4.21147@bgtnsc05-news.ops.worldnet.att.net>
Date: Sat, 11 Feb 2006 21:07:54 GMT
NNTP-Posting-Host: 12.74.140.185
X-Complaints-To: abuse@worldnet.att.net
X-Trace: bgtnsc05-news.ops.worldnet.att.net 1139692074 12.74.140.185 (Sat, 11 Feb 2006 21:07:54 GMT)
NNTP-Posting-Date: Sat, 11 Feb 2006 21:07:54 GMT
Organization: AT&T Worldnet
Xref: number1.nntp.dca.giganews.com comp.lang.cobol:155700

CG wrote:

> Arnold Trembley wrote:
>
>
>
> Well, IBM tried to remove floating point from the first release of the
> VS COBOL II compiler. The user community went ballistic! I'm not sure
> R1 was ever installed in a fully production environment. Floating point
> was not the only reason, but there was a very large percentage of shops
> that designated this as the show-stopper for them. I cannot speak for
> other environments, but it was DOA in the IBM environment.
> Carl

Thank you for correcting me. It sounds like IBM made a mistake, and
eventually gave the users what they needed.

VS COBOL II was a difficult change in my shop. We had a large number
of users who refused to migrate from OS/VS COBOL, and I believe the
first release of COBOL II we installed was release 3. We always had
NOCMPR2 as a default option.

It took us ten years and Y2K to wean the die-hards off OS/VS COBOL and
BDAM.

With kindest regards,

--
http://arnold.trembley.home.att.net/

Pete Dashwood

2006-02-11, 6:55 pm

ROFL!

Excellent point, very well made.

About 30 years ago, when system memory was expensive
"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:11uskadl1drna99@news.supernews.com...
> Colin Campbell wrote:
>
>
> You're surprised? Imagine the surprise of a maintenance programmer
> confronting:
>
> ADD A TO B GIVING C.
>
> Where "A" is 1, "B" is 2, and "C" turns out to be 102.
>

Pete Dashwood

2006-02-11, 6:55 pm

ROFL!

About 30 years ago when system memory was expensive there MIGHT have been a
case for scaling numbers. I think I saw a few programs where it was used...
But there is really no place for it today that I can think of.

Pete.

TOP POST NO MORE BELOW

"HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:11uskadl1drna99@news.supernews.com...
> Colin Campbell wrote:
>
>
> You're surprised? Imagine the surprise of a maintenance programmer
> confronting:
>
> ADD A TO B GIVING C.
>
> Where "A" is 1, "B" is 2, and "C" turns out to be 102.
>

Pete Dashwood

2006-02-11, 6:55 pm

"Arnold Trembley" <arnold.trembley@worldnet.att.net> wrote in message
news:KmsHf.377379$qk4.21147@bgtnsc05-news.ops.worldnet.att.net...
>
>
> CG wrote:
>
>
> Thank you for correcting me. It sounds like IBM made a mistake, and
> eventually gave the users what they needed.
>
> VS COBOL II was a difficult change in my shop. We had a large number of
> users who refused to migrate from OS/VS COBOL, and I believe the first
> release of COBOL II we installed was release 3. We always had NOCMPR2 as
> a default option.
>
> It took us ten years and Y2K to wean the die-hards off OS/VS COBOL and
> BDAM.

I'm coming to the conclusion that COBOL will only be dead when the
die-hards are dead :-)

Whether I agree with them or not , I certainly respect their tenacity...

Pete.

2006-02-11, 6:55 pm

In article <457adiF5bo7oU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
>"Arnold Trembley" <arnold.trembley@worldnet.att.net> wrote in message
>news:KmsHf.377379$qk4.21147@bgtnsc05-news.ops.worldnet.att.net...

[snip]

>
>I'm coming to the conclusion that COBOL will only be dead when the
>die-hards are dead :-)

Nothing new there, Mr Dashwood... as I was taught, oh-so-many years ago,
'The system is not to be considered decommissioned until ten years after
the last user dies'.

DD

2006-02-12, 6:55 pm

Pete Dashwood wrote:
> "Arnold Trembley" <arnold.trembley@worldnet.att.net> wrote in message
> news:KmsHf.377379$qk4.21147@bgtnsc05-news.ops.worldnet.att.net...
>
> I'm coming to the conclusion that COBOL will only be dead when the
> die-hards are dead :-)
>
> Whether I agree with them or not , I certainly respect their tenacity...
>
> Pete.
I would be happy to get into war stories about migrating from old to new
COBOL compilers. [My first reference would be Bill Klein's book:
"OldBOL to NewBOL".] Migrating OldBOL to NewBOL is the vast majority of
our business, but it should probably be in another thread as we have
gotten far off the 'subject' of this one. I'll wait for someone to ask...

That said, let me make two observation about the comments already made:

First, Arnold's comment about the mistakes IBM made with the first two
releases of COBOL II is true. Part of the problem was that those
releases were defined prior to publishing of the final 1985 standard.
It was not clear what would or would not be in the standard. But, at
the same time, the OS/VS COBOL compiler was considered to be in
'critical condition' [death is/should be in sight] and needed to be
replaced. The 1985 standard was about five years late. IBM needed and
wanted to replace the compiler much earlier than it did, but was trying
to wait for the standard. This is the reason for the introduction of
the [NO]CMPR2 compiler option in Release 3. It said, "Treat the source
as if it were compatible with the implementation in Release 2." After
Release 3, the compiler was really quite complete, stable and
implemented the new standard.

Which leads to point two: Both good and bad news is IBM's long term
policy to provide upward compatibility for all its products. The good
news is that code written thirty years ago [with only a couple of recent
exceptions] can, and is, still running today on the latest z/OS
releases. Both OS/VS COBOL and CMPR2 programs are still churning away
in production environments. [IBM even provides backward compatibility
in a number of ways. Again, a topic for a new thread if anyone is
really interested.] But, the bad news is that code written thirty years
ago can, and is, still running... We regularly find code in production
run-time libraries compiled in the early 1970s. So, Arnold's ten year
effort is, unfortunately, not unusual. Far too many shops simply
patched their old applications for Y2K and played Scarlett O'Hara and
said they would "...think about that tomorrow." Maybe 'tomorrow' is here?

Carl

LX-i

2006-02-12, 9:55 pm

James J. Gavan wrote:
> BTW - I would completely ignore pic aaa or pic a(3) - I've never ever
> seen code where they have been used - we are adequately covered by
> either pic 9 or pic x. I'd be curious to know if anybody is aware of any
> current code where pic a(3) is used.

I have some. I wrote it as a first-year programmer, and it's still in
production today - it's never broken, so I've never had to fix it. :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

LX-i

2006-02-12, 9:55 pm

HeyBub wrote:
> Colin Campbell wrote:
>
>
> You're surprised? Imagine the surprise of a maintenance programmer
> confronting:
>
> ADD A TO B GIVING C.
^^
A small thing - that should be "Add A B Giving C".

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

LX-i

2006-02-12, 9:55 pm

Pete Dashwood wrote:
>
> If one were forced to back ONE of these options, which would it be? Where do
> Unisys stand on Java/Open Source solutions? Nowhere? Ooops...

I don't know about the A-series, but the 2200 series has a JVM, a web
server, JBoss, and a JDBC server for their relational database system.
Unisys started a campaign called "ClearPath: Mainframe and Mainstream"
touting these advancements.

> To get serious for a minute (and I hope you realised the above was not...),
> I have been part of a triumvirate interviewing people for my own and some
> other projects we are currently looking at. Our main platform is currently
> Unisys, with the applications running LINC-generated COBOL. (It will be
> replaced by a distributed solution, either WinTel or Java or possibly both).
> One of my colleagues on the interview panel is responsible for this
> environment and LINC and UNISYS are very dear to his heart. Every single
> candidate was asked: "Do you have any experience with LINC?" and every
> single one responded with a bemused look. It became kind of amusing by the
> second day... I'm sure some of them will thnk they missed the job because
> they didn't know what LINC was... (certainly not true).

Heh - I know what LINC is (although I've never used it) - isn't it's
name now called BIS (Business Information System) as part of the EAE
(Enterprise Application Architecture)?

New names fix everything, don't you know... ;)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Ian Dalziel

2006-02-13, 7:55 am

On Sun, 12 Feb 2006 20:18:51 -0600, LX-i <lxi0007@netscape.net> wrote:

>Heh - I know what LINC is (although I've never used it) - isn't it's
>name now called BIS (Business Information System) as part of the EAE
>(Enterprise Application Architecture)?
>
>New names fix everything, don't you know... ;)

Well, the word I have in mind certainly starts with an "f".
--

Ian

Oliver Wong

2006-02-13, 6:55 pm

"Colin Campbell" <cmcampb@adelphia.net> wrote in message
news:EpudnVqXmv7WFHDeRVn-qQ@adelphia.com...
>
> Picture character "A" was outlawed in the shop where I used to work at
> least twenty years ago. We just figured that we didn't need to have data
> definitions which used "A" in preference to "X". I'll bet you could, if
> you tried, find a place to use it, though -- maybe to describe English
> highway designations?

In Canada, postal codes have the form "A9A-9A9", and license plates used
to be (between 1983-1994) of the form "AAA 999". So I suppose if you wanted
to enforce that type of stuff, you would use 'A' instead of 'X'.

License plates no longer follow the above form, which mean if you didn't
use something more flexible like X(7), you'd have to rewrite some code.

- Oliver

Michael Mattias

2006-02-13, 6:55 pm

PIC A(any) ==> PIC X(any) + 'IF Z IS ALPHABETIC....'

or (syntax may be off a tad here and I know is subject to the vagaries of
the collating sequence)...

SPECIAL-NAMES.
CLASS NUMBERS-AND-LETTERS VALUES '0' THRU '9, 'A' THRU 'Z', 'a' THRU 'z'

IF Z IS NUMBERS-AND-LETTERS ....

MCM

2006-02-13, 6:55 pm

In article <Jv1If.29766$F_3.21034@newssvr29.news.prodigy.net>,
Michael Mattias <michael.mattias@gte.net> wrote:
>PIC A(any) ==> PIC X(any) + 'IF Z IS ALPHABETIC....'
>
>or (syntax may be off a tad here and I know is subject to the vagaries of
>the collating sequence)...
>
>SPECIAL-NAMES.
> CLASS NUMBERS-AND-LETTERS VALUES '0' THRU '9, 'A' THRU 'Z', 'a' THRU 'z'
>
> IF Z IS NUMBERS-AND-LETTERS ....

With all due respect, Mr Mattias, this seems to betray an assumption that
one is working in ASCII. The EBCDIC implementations with which I am
familiar would require 'A' THRU 'I', 'J' THRU 'R', 'S' THRU 'Z' (and
similarly in lower-case) or else garbage would pass through undetected.

DD

Michael Mattias

2006-02-13, 6:55 pm

mmattias@talsystems.com
<docdwarf@panix.com> wrote in message news:dsqamm$n7p$1@reader2.panix.com...
> In article <Jv1If.29766$F_3.21034@newssvr29.news.prodigy.net>,
> Michael Mattias <michael.mattias@gte.net> wrote:
'z'[color=darkred]
>
> With all due respect, Mr Mattias, this seems to betray an assumption that
> one is working in ASCII. The EBCDIC implementations with which I am
> familiar would require 'A' THRU 'I', 'J' THRU 'R', 'S' THRU 'Z' (and
> similarly in lower-case) or else garbage would pass through undetected.

Which part of "subject to the vagaries of the collating sequence" did you
not comprehend?

MCM

2006-02-13, 6:55 pm

In article <5w2If.20406$_S7.19539@newssvr14.news.prodigy.com>,
Michael Mattias <michael.mattias@gte.net> wrote:
>mmattias@talsystems.com
><docdwarf@panix.com> wrote in message news:dsqamm$n7p$1@reader2.panix.com...
>
>Which part of "subject to the vagaries of the collating sequence" did you
>not comprehend?

The part that did not betray an assumption that one is working in ASCII,
of course; my apologies for being obscure.

DD

Frank Swarbrick

2006-02-13, 6:55 pm

We have a field that is required to be specified in multiples of $100. It's
currently defined as PIC S9(7) COMP-3. But it could be defined as PIC
S9(5)PP COMP-3, thus saving us the incredible amount of one byte per record.
:-)
And of course we'd be screwed if we ever got rid of the $100 increments
rule...

I almost used PIC P in production code, but decided against it (for reasons
I have forgotten).

Frank

James J. Gavan wrote:[color=darkred]
> (snip - a lot of stuff)
> BTW - I would completely ignore pic aaa or pic a(3) - I've never ever
> seen code where they have been used - we are adequately covered by
> either pic 9 or pic x. I'd be curious to know if anybody is aware of any
> current code where pic a(3) is used.
>
> Jimmy

I think I have only seen PIC A once in 26 years of COBOL coding. I
will have to try it to see if it actually enforces alphabetic characters.

Another thing I have NEVER seen in production COBOL program is a
picture clause with a P in it. I think I know what it should do, but
it's never been needed in any program I saw.

The final thing I have never seen in COBOL is USAGE COMP-1 or COMP-2.
In IBM mainframe COBOL that would be floating-point, single
precision and double-precision, respectively.

Based on my (not necessarily exhaustive) experience, you could remove
PIC A, PIC P, and floating-point from COBOL, and nobody in the
business world would even notice they were gone.

And to get back on topic, I like it that COBOL reserved words or
user-defined names are case-insensitive.

--
http://arnold.trembley.home.att.net/

James J. Gavan

2006-02-13, 6:55 pm

Oliver Wong wrote:
> "Colin Campbell" <cmcampb@adelphia.net> wrote in message
> news:EpudnVqXmv7WFHDeRVn-qQ@adelphia.com...
>
>
>
> In Canada, postal codes have the form "A9A-9A9", and license plates used
> to be (between 1983-1994) of the form "AAA 999". So I suppose if you wanted
> to enforce that type of stuff, you would use 'A' instead of 'X'.
>
> License plates no longer follow the above form, which mean if you didn't
> use something more flexible like X(7), you'd have to rewrite some code.
>
> - Oliver
>

Only in Canada EH ? :-)

Two UK examples : BA12 9NW or TW20 0YD

Frankly I would still stick with Pic (x) and then validate. After all,
until you *know* which Country you are in (i.e. the keyed-in
information), you can't establish the rules for your postal/zipcode. Not
likely you are going to produce a system just for Canada - your address
file/table is going to have to accommodate our friends below the border
with their numeric zipcodes. (I'm guessing - even a Canadian payroll
could have US addresses - Peter Lacey - that possible with yours ?)

My guess, most will design the layout of a Dialog based on how an
envelope is addressed :-

The Bank of Nova Scotia
PO Box 4100
Postal Station A (Address Line 2 - often this line is blank)
TORONTO
Ontario (or from Droplist ON or TN or Hants - for Canada, US or UK
respectively)
M5W 1T1
Canada (again could use a Droplist)

Logically, (using the Ontario line) - if selected from a droplist, and
providing the Province/State/County list/collection has a
cross-reference to Country - then you can use the set of rules for the
appropriate postal/zipcode format).

Given the above droplist you *could* obviate the droplist for Country
entirely, displaying the Country from info in the first droplist.

I recall one instance where the last one got Pete Dashwood mildly pissed
off when a droplist didn't include NZ - don't blame him. North America
is *not* the centre of the world :-).

On a side issue I find the input of 'identifications' extremely
irritating. Dialogs are designed by programmers and are
'programmer-oriented' rather than being 'user-oriented'. And this
applies to SINs, Credit Cards, Bank Accounts, Telephone Numbers etc. You
want to buy something via the Web using a card. If the embossed number
on my card reads 4298 706 933, then not unreasonably, I would suggest,
that's how I key it in with intervening spaces. Nope ! Some Web forms
will kick it out until I key it in again without the spaces. If we go
back to the Canadian postal code the program should accept 'M5W 1T1' or
'M5W1T1' - the program should figure it out !

OK so there is a partial way around that - for certain numbers, (or
dates), you can mask the input field in grey as a prompt to the user,
like "dd/mm/yy" or "ccyy/mm/dd' etc., and what you enter overrides the
mask.

Any one for components ? Seriously Pete, how would you handle this one -
don't see how passing properties to Factory would help much here. I
somehow don't see you attempting a separate component per country - but
possibly sub-class to invoke the rules for the postal/zipcode validation.

Jimmy

HeyBub

2006-02-13, 6:55 pm

Frank Swarbrick wrote:
> We have a field that is required to be specified in multiples of
> $100. It's currently defined as PIC S9(7) COMP-3. But it could be
> defined as PIC S9(5)PP COMP-3, thus saving us the incredible amount
> of one byte per record. :-)
> And of course we'd be screwed if we ever got rid of the $100
> increments rule...

Nah, you could use it. Isn't 1.5 in a PP field 150 or 0.4730 really $47.30?

I once saw a FORTRAN subroutine where each variable was a varying number of
dollar-signs. Like:

$$$ = SQRT ($$**2 + $$$$**4)

Just to prove it could be done. Same with "P"

Colin Campbell

2006-02-13, 9:55 pm

HeyBub wrote:

>Frank Swarbrick wrote:
>
>
>
>
>Nah, you could use it. Isn't 1.5 in a PP field 150 or 0.4730 really $47.30?
>
>I once saw a FORTRAN subroutine where each variable was a varying number of
>dollar-signs. Like:
>
>$$$ = SQRT ($$**2 + $$$$**4)
>
>Just to prove it could be done. Same with "P"
>
>
>
>
"P" represents a decimal scaling position. It doesn't, however,
represent an actual character or digit.

PIC 9PP has a size of 1 digit, but the digit is considered to be
multiplied by 100.

PIC PP9 also has a size of 1 digit, but the digit is considered to be
divided by 1000.

An assumed decimal point is implied to the left of the first "P" if the
"P's" are leftmost characters. The assumed decimal point is to the
right of the last "P" is the "P's" are rightmost characters.

So there is no way in the first example to represent any values other
than zero, 100, 200, 300, 400, 500, 600, 700, 800, and 900.

I'm getting this from the ANSI 1985 COBOL standard, but I'm pretty sure
this has been consistent in 1968 and 1974 ANSI COBOL, and still works
this way in 2002 ANSI COBOL. (The 2002 standard document is way
upstairs....)

LX-i

2006-02-14, 7:55 am

Ian Dalziel wrote:
> On Sun, 12 Feb 2006 20:18:51 -0600, LX-i <lxi0007@netscape.net> wrote:
>
>
> Well, the word I have in mind certainly starts with an "f".

Is it that bad? :) There's a shop here that used to use PacBase (sp?),
which they said generated COBOL. I didn't quite understand why they
just didn't code COBOL if they wanted COBOL...

(Like I said, I don't understand it because I haven't used it - there
may be a perfectly valid reason to use something like that.)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Ian Dalziel

2006-02-14, 7:55 am

On Mon, 13 Feb 2006 21:59:50 -0600, LX-i <lxi0007@netscape.net> wrote:

>Ian Dalziel wrote:
>
>Is it that bad? :) There's a shop here that used to use PacBase (sp?),
>which they said generated COBOL. I didn't quite understand why they
>just didn't code COBOL if they wanted COBOL...
>

No, LINC isn't (wasn't?) bad at all. It's the inept Unisys marketing
(including changing all the names regularly so that no-one knows what
anyone is talking about) that deserves the expletives.
--

Ian

Pete Dashwood

2006-02-14, 7:55 am

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:v59If.612075$ki.128773@pd7tw2no...
> Oliver Wong wrote:
>
> Only in Canada EH ? :-)
>
> Two UK examples : BA12 9NW or TW20 0YD
>
> Frankly I would still stick with Pic (x) and then validate. After all,
> until you *know* which Country you are in (i.e. the keyed-in information),
> you can't establish the rules for your postal/zipcode. Not likely you are
> going to produce a system just for Canada - your address file/table is
> going to have to accommodate our friends below the border with their
> numeric zipcodes. (I'm guessing - even a Canadian payroll could have US
> addresses - Peter Lacey - that possible with yours ?)
>
> My guess, most will design the layout of a Dialog based on how an envelope
> is addressed :-
>
> The Bank of Nova Scotia
> PO Box 4100
> Postal Station A (Address Line 2 - often this line is blank)
> TORONTO
> Ontario (or from Droplist ON or TN or Hants - for Canada, US or UK
> respectively)
> M5W 1T1
> Canada (again could use a Droplist)
>
> Logically, (using the Ontario line) - if selected from a droplist, and
> providing the Province/State/County list/collection has a cross-reference
> to Country - then you can use the set of rules for the appropriate
> postal/zipcode format).
>
> Given the above droplist you *could* obviate the droplist for Country
> entirely, displaying the Country from info in the first droplist.
>
> I recall one instance where the last one got Pete Dashwood mildly pissed
> off when a droplist didn't include NZ - don't blame him. North America is
> *not* the centre of the world :-).
>
> On a side issue I find the input of 'identifications' extremely
> irritating. Dialogs are designed by programmers and are
> 'programmer-oriented' rather than being 'user-oriented'. And this applies
> to SINs, Credit Cards, Bank Accounts, Telephone Numbers etc. You want to
> buy something via the Web using a card. If the embossed number on my card
> reads 4298 706 933, then not unreasonably, I would suggest, that's how I
> key it in with intervening spaces. Nope ! Some Web forms will kick it out
> until I key it in again without the spaces. If we go back to the Canadian
> postal code the program should accept 'M5W 1T1' or
> 'M5W1T1' - the program should figure it out !
>
> OK so there is a partial way around that - for certain numbers, (or
> dates), you can mask the input field in grey as a prompt to the user, like
> "dd/mm/yy" or "ccyy/mm/dd' etc., and what you enter overrides the mask.
>
> Any one for components ? Seriously Pete, how would you handle this one -
> don't see how passing properties to Factory would help much here. I
> somehow don't see you attempting a separate component per country - but
> possibly sub-class to invoke the rules for the postal/zipcode validation.
>
The country would be derived from the usual drop down (web or desktop based)
and set in the factory of the base. The address parsing component would
utilize the appropriate method, depending on the country specified in the
factory. New countries would be catered for by overriding the address
formatting method, which would inherit common processing and things like
duplicate address detection (fuzzy logic), and Soundex search field
generation. There is also a component that writes it all to a Relational DB
using ODBC (currently MySQL, but SQLServer, Oracle, even ACCESS could all be
plugged in without program change.).

Zip Codes in Australia can be validated online against the APO database, but
I usually don't worry too much about them; it depends on what the addresses
are being collected for. I have components (I wrote) that do all of this. I
could build a program to do it for any and all countries (where the address
format was provided) in about 40 minutes, using PowerCOBOL to provide the
user interface on a Windows desktop, or making it web based with the
components running server side as ASP controlled ActiveX controls on an IIS
web server... Alternatively, if it is web based, the completed package
could be wrapped for dot net or could utilise XML and Soap to provide
address processing as a web service.

And I wouldn't maintain any of it :-)

Pete.

Howard Brazee

2006-02-14, 6:55 pm

On Thu, 09 Feb 2006 23:04:00 GMT, "Oliver Wong" <owong@castortech.com>
wrote:

> What (other?) exceptions are there to COBOL's case-insensitivity? I know
>that the PIC strings are case sensitive, so that PIC AAA is not the same as
>PIC aaa. And string literals are probably case sensitive (that is, the
>literal "Hello World!" probably evaluates to a different value that "hello
>world!"). Anything else?

Interesting. What environment has PIC AAA different from PIC aaa?

I was not aware that there exists a CoBOL environment where CoBOL had
case sensitivity like this.

Howard Brazee

2006-02-14, 6:55 pm

On Sat, 11 Feb 2006 13:40:32 +1300, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:

>It is interesting to note that IBM nearly lost their company by "inventing"
>the PC. At the very least they shot themselves in the foot. Now they are
>promoting Websphere/Java/OpenSource solutions as well as their "real" COBOL
>offering... Back both horses and you must come in somewhere...

You're implying that the company would have been in less risk if a
competitor invented the PC?

Howard Brazee

2006-02-14, 6:55 pm

On Mon, 13 Feb 2006 15:17:04 GMT, "Oliver Wong" <owong@castortech.com>
wrote:

>
> In Canada, postal codes have the form "A9A-9A9", and license plates used
>to be (between 1983-1994) of the form "AAA 999". So I suppose if you wanted
>to enforce that type of stuff, you would use 'A' instead of 'X'.

I've done that code, and did not see any advantage of using "A". My
code checked the validity just fine without that, thank-you.

Howard Brazee

2006-02-14, 6:55 pm

On Sat, 11 Feb 2006 21:07:54 GMT, Arnold Trembley
<arnold.trembley@worldnet.att.net> wrote:

>VS COBOL II was a difficult change in my shop. We had a large number
>of users who refused to migrate from OS/VS COBOL, and I believe the
>first release of COBOL II we installed was release 3. We always had
>NOCMPR2 as a default option.

I remember interviewing for an IBM based job after being away for a
few years (using Univac and DEC). The trouble point was that I
hadn't had any COBOL II experience, instead I had the same current
version of COBOL without that IBM specific name.

Howard Brazee

2006-02-14, 6:55 pm

On Mon, 13 Feb 2006 19:01:18 -0800, Colin Campbell
<cmcampb@adelphia.net> wrote:

>"P" represents a decimal scaling position. It doesn't, however,
>represent an actual character or digit.

I think I have used "P" once. It doesn't give enough advantage to be
used in programs where maintenance programmers are unfamiliar with it.

Arnold Trembley

2006-02-14, 6:55 pm

Howard Brazee wrote:
> On Sat, 11 Feb 2006 21:07:54 GMT, Arnold Trembley
> <arnold.trembley@worldnet.att.net> wrote:
>
>
>
>
> I remember interviewing for an IBM based job after being away for a
> few years (using Univac and DEC). The trouble point was that I
> hadn't had any COBOL II experience, instead I had the same current
> version of COBOL without that IBM specific name.

I've seen other stories like this, and it's just wrong for
interviewers to act that way. But apparently it happens a lot. Any
reasonably competent COBOL programmer should be able to adapt to a
different compiler, even from a different vendor and for different
hardware.

I seem to recall seeing ads for Java programmers with five years
experience - only two years after Java was publicly available.

"Human Resources" shouldn't do the technical interview if they don't
know what they're talking about.

--
http://arnold.trembley.home.att.net/

James J. Gavan

2006-02-14, 6:55 pm

Pete Dashwood wrote:
> Zip Codes in Australia can be validated online against the APO database, but
> I usually don't worry too much about them; it depends on what the addresses
> are being collected for. I have components (I wrote) that do all of this. I
> could build a program to do it for any and all countries (where the address
> format was provided) in about 40 minutes, using PowerCOBOL to provide the
> user interface on a Windows desktop, or making it web based with the
> components running server side as ASP controlled ActiveX controls on an IIS
> web server... Alternatively, if it is web based, the completed package
> could be wrapped for dot net or could utilise XML and Soap to provide
> address processing as a web service.
>
> And I wouldn't maintain any of it :-)
>
Thanks for that - wouldn't say I could do it in 40 minutes, just a
little bit longer. However a general purpose Component in Net Express -
I wouldn't even attempt it. There's a little thing called 'runtime
fees'. Haven't got the details in my head, but over and above the $s
there's a feature using a 'Request Key' which sits in the user's copy of
the software which has to be updated. LUVERLY !

COBOL - RIP.

Jimmy

Frank Swarbrick

2006-02-14, 6:55 pm

Colin Campbell<cmcampb@adelphia.net> 02/13/06 8:01 PM >>>
>HeyBub wrote:
>
$47.30?[color=darkred]
of[color=darkred]
>"P" represents a decimal scaling position. It doesn't, however,
>represent an actual character or digit.
>
>PIC 9PP has a size of 1 digit, but the digit is considered to be
>multiplied by 100.
>
>PIC PP9 also has a size of 1 digit, but the digit is considered to be
>divided by 1000.
>
>An assumed decimal point is implied to the left of the first "P" if the
>"P's" are leftmost characters. The assumed decimal point is to the
>right of the last "P" is the "P's" are rightmost characters.
>
>So there is no way in the first example to represent any values other
>than zero, 100, 200, 300, 400, 500, 600, 700, 800, and 900.
>
>I'm getting this from the ANSI 1985 COBOL standard, but I'm pretty sure
>this has been consistent in 1968 and 1974 ANSI COBOL, and still works
>this way in 2002 ANSI COBOL. (The 2002 standard document is way
>upstairs....)

This is my understanding. Not actually sure what HeyBub's thoughts are on
it...
Frank

LX-i

2006-02-14, 9:55 pm

Ian Dalziel wrote:
> On Mon, 13 Feb 2006 21:59:50 -0600, LX-i <lxi0007@netscape.net> wrote:
>
>
> No, LINC isn't (wasn't?) bad at all. It's the inept Unisys marketing
> (including changing all the names regularly so that no-one knows what
> anyone is talking about) that deserves the expletives.

Ah - you'd substitute a different "F" for "fix"... Missed that on the
first reading. Thanks for the explanation. :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Pete Dashwood

2006-02-15, 7:55 am

"Howard Brazee" <howard@brazee.net> wrote in message
news:rvr3v1pcnq06gv2mctn5ps1kjqlmsdneck@
4ax.com...
> On Sat, 11 Feb 2006 13:40:32 +1300, "Pete Dashwood"
> <dashwood@enternet.co.nz> wrote:
>
>
> You're implying that the company would have been in less risk if a
> competitor invented the PC?
>
A good and fair point Howard. The irony of it has always made me smile, but
you are absolutely correct that their empire would have been in just as much
danger of someone else had done it. I guess it might have taken longer. IBM
at that time was one of the wealthiest companies on Earth and could well
afford to do the research. They probably considered ti would open up whole
new worlds for them, never foreseeing the devastating effect it would have
on their existing world.

Pete.

Pete Dashwood

2006-02-15, 7:55 am

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:73pIf.970$sa3.966@pd7tw1no...
> Pete Dashwood wrote:
> Thanks for that - wouldn't say I could do it in 40 minutes, just a little
> bit longer. However a general purpose Component in Net Express - I
> wouldn't even attempt it. There's a little thing called 'runtime fees'.
> Haven't got the details in my head, but over and above the $s there's a
> feature using a 'Request Key' which sits in the user's copy of the
> software which has to be updated. LUVERLY !

Is that like a software dongle? Some hacker could make serious money... :-)
>
> COBOL - RIP.
>
I know. It is

really. COBOL is the perfect tool for such a data
manipulation exercise. I would stress that the above would be 'glued' into a
single 'address handling component' (it would have a single interface to the
world, yet be distributed as a number of registerable .dlls). It would, in
fact, be at least half a dozen existing components, as I outlined. (Think
Lego... :-))

Presumably the runtime fee would only apply once if you did a NE solution,
as there would only be one runtime involved? Or would each component use its
own copy of the runtime and thus be licensable?

Pete.

Howard Brazee

2006-02-15, 6:55 pm

On Wed, 15 Feb 2006 23:25:15 +1300, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:

>A good and fair point Howard. The irony of it has always made me smile, but
>you are absolutely correct that their empire would have been in just as much
>danger of someone else had done it. I guess it might have taken longer. IBM
>at that time was one of the wealthiest companies on Earth and could well
>afford to do the research. They probably considered ti would open up whole
>new worlds for them, never foreseeing the devastating effect it would have
>on their existing world.

Give them a time machine to see what happens, and they probably would
have held their nose and still invented the PC. Better have the
enemy under their control than elsewhere.

They might have bought a controlling interest in Microsoft first
though.

Richard

2006-02-15, 6:55 pm

> Give them a time machine to see what happens, and they probably would
> have held their nose and still invented the PC. Better have the
> enemy under their control than elsewhere.

I don't know why you think that IBM 'invented the PC'. Ceratainly they
designed the 'IBM PC' but there were many 'PC's around well before IBM
got to do one. For example the Apple ][ was advertised as a Personnal
Computer since 1978. IBM's design was to combat the infiltration of
Visicalc (Apple and Commodore) and dBase II (CP/M mchines) into the
IBM accounts and so was to be 20% better than Apple (160Kb discettes vs
120) and run software that was being used for years: CP/M (or a clone
thereof), Microsoft BASIC (as used on Apple and CP/M), dBase II,
WordStar, VisiCalc, plus it was to be a terminal and to run IBM WP
software from the System 23.

The only new thing about it was the brand name. PC-DOS 1 was just a
clone of CP/M, some say built from sources that SCP (Seattle Computer
Products) had because they were a full DRI OEM for their Zebra range of
S100 based computers and had been for several years. In fact Microsoft
was also a DRI OEM for their Z80 based Apple SoftCards. Intel had
produced a 8080 -> 8086 source converter. SCP-DOS/MS-DOS/MS-DOS did add
the FAT filesystem but this had been written by MS in 1977 for their
Stand Alone BASIC.

So IBM did not 'invent the PC', they merely followed what had been
happening for some years and built a mediocre (some say obsolete even
at that time, such as the 8250 serial ports) machine but put a brand
name on it.

> They might have bought a controlling interest in Microsoft first though.

It was the MS lawyers (such as Bill's father) that should have been
controlled.

In other news Dick Chaney gets a 92% approval rating after shooting a
lawyer.

Pete Dashwood

2006-02-16, 7:55 am

I think the point here, Richard, is that IBM were first to use the term
'PC', and first to proliferate these machines into the workplace. (Once they
had a blue badge on them they became respectable :-)). I know the first "PC"
I ever used was NOT from IBM (but that was at home; the one at work was
IBM...)and I'm not disputing your interesting outline of the history.
However, I believe it is fair to say it was IBM who "popularized" the PC and
gave it commercial credibility... That was what nearly cost them the
company.

Pete.

TOP POST no more from me below. Original post left for reference.

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1140031348.546159.237410@z14g2000cwz.googlegroups.com...
>
> I don't know why you think that IBM 'invented the PC'. Ceratainly they
> designed the 'IBM PC' but there were many 'PC's around well before IBM
> got to do one. For example the Apple ][ was advertised as a Personnal
> Computer since 1978. IBM's design was to combat the infiltration of
> Visicalc (Apple and Commodore) and dBase II (CP/M mchines) into the
> IBM accounts and so was to be 20% better than Apple (160Kb discettes vs
> 120) and run software that was being used for years: CP/M (or a clone
> thereof), Microsoft BASIC (as used on Apple and CP/M), dBase II,
> WordStar, VisiCalc, plus it was to be a terminal and to run IBM WP
> software from the System 23.
>
> The only new thing about it was the brand name. PC-DOS 1 was just a
> clone of CP/M, some say built from sources that SCP (Seattle Computer
> Products) had because they were a full DRI OEM for their Zebra range of
> S100 based computers and had been for several years. In fact Microsoft
> was also a DRI OEM for their Z80 based Apple SoftCards. Intel had
> produced a 8080 -> 8086 source converter. SCP-DOS/MS-DOS/MS-DOS did add
> the FAT filesystem but this had been written by MS in 1977 for their
> Stand Alone BASIC.
>
> So IBM did not 'invent the PC', they merely followed what had been
> happening for some years and built a mediocre (some say obsolete even
> at that time, such as the 8250 serial ports) machine but put a brand
> name on it.
>
>
> It was the MS lawyers (such as Bill's father) that should have been
> controlled.
>
> In other news Dick Chaney gets a 92% approval rating after shooting a
> lawyer.
>

Howard Brazee

2006-02-16, 6:55 pm

On Fri, 17 Feb 2006 00:33:50 +1300, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:

>However, I believe it is fair to say it was IBM who "popularized" the PC and
>gave it commercial credibility... That was what nearly cost them the
>company.

And I believe that if they hadn't been first, commercial credibility
would have come anyway, and the effect of PCs on IBM's bottom line
would not have been more favorable.

Richard

2006-02-16, 6:55 pm

Pete Dashwood wrote:
> I think the point here, Richard, is that IBM were first to use the term
> 'PC', and first to proliferate these machines into the workplace.

And the point that I was making is they weren't. Apple used the term
'Personal Computer' in advertising in 1979 and the use of 'PC' was
common before IBM came out with their copy of what was already going
on.

In fact the IBM machine was a direct result of micros proliferating in
the workplace. It was designed specifically around the capabilities of
the current Apple ][ and CP/M machines for exactly that reason. It took
DOS from CP/M, Basic from MS's Applesoft and CP/M, Visicalc from
Commodore and Apple, dBase II from CP/M _because_ the IBM salesmen were
tripping over these in their accounts.

Certainly the IBM name made the general public take much more notice.

> (Once they
> had a blue badge on them they became respectable :-)).

Absolutely.

> However, I believe it is fair to say it was IBM who "popularized" the PC and
> gave it commercial credibility...

No. It was Visicalc and then Lotus 123. It was Wordstar then
WordPerfect, It was dBase II then several derivitives.

Businesses didn't buy PC because they had IBM on the front, they bought
them because they had a spreadsheet or a word processor on the screen
and because they were cheaper than the single-use word processors that
many companies were already selling. It had to be an IBM or identical
Clone because that is what Lotus-123 required, not because IBM was the
brand.

> That was what nearly cost them the company.

I completely disagree. Mainframes were not replaced by PCs with 386
CPUs, they were replaced by departmental minis. More recently 'PC's, or
more accurately Intel based machines, are being clustered to give
mainframe performance, but IBMs mainframe sales
have been growing too in last few years.

James J. Gavan

2006-02-16, 6:55 pm

Pete Dashwood wrote:
>
> I know. It is

really. COBOL is the perfect tool for such a data
> manipulation exercise. I would stress that the above would be 'glued' into a
> single 'address handling component' (it would have a single interface to the
> world, yet be distributed as a number of registerable .dlls). It would, in
> fact, be at least half a dozen existing components, as I outlined. (Think
> Lego... :-))

Yep - I've always understood the Lego aspect you address. Next time you
use the word, which you have already mentioned, put it in big bold
'R-E-U-S-E'.
>
> Presumably the runtime fee would only apply once if you did a NE solution,
> as there would only be one runtime involved? Or would each component use its
> own copy of the runtime and thus be licensable?

Interesting point - but I think it's OK. Ages since I looked at
distributing software. No problem for me as I put it all, Micro Focus
support software, my own and data into one directory with sub-folders.

However suppose you supply Accounts Payable/Bought Ledger; then
subsequently six months later you supply General Ledger. To avoid
'duplicates' of the M/F software it's a file COBDIR (I think) that you
use to point both applications at the directory containing the M/F
runtime support.

Means of course to use components you would have to have each one
pointing at the M/F directory. So in theory at least, the trigger key
should only apply to one version of the runtime you have in that
separate M/F location. (Naturally - if that's not true - then it is
truly the pits !).

Given that they wont commit to a hard-worded license fee proposal,
chances are if you produced a component, let's suggest your price might
be $50 for something fairly simple, you could probably negotiate with
them - they still aren't going to let you have a 'freebie' and might
want you to tack on $5-10 for them. How it would work if you got lucky
and had say 500-800 end-users, God knows how it would be controlled.
(Incidentally that's one aspect I posed to their CEO - totally ignored
in his reply - so your guess is as good as mine).

As somebody pointed out just before Christmas, get into something like
dotNet where you find the 'appeal' of one of the dotNet languages and
now only callback for minimal COBOL usage, "....they now ch

ily charge
each server side instance as one user licence which is $150...". As she
pointed out 100 x $150 plus an annual fee, (didn't understand the last
comment 'annual fee' - presumably Annual Technical Support) - nice gravy
for M/F.

So, you the developer haven't had a necessity to use Java or 'C'
languages before, but you are *now*, using dotNet - Don't need me to
spell it out - what's the developer's next move ? It's already happening
- and that was the danger I foresaw when both F/J and M/F went the
dotNet route.

Touching on components - and you dismissed my previous observation ages
ago - thinking back to 'economic use' on a limited box like a Radio
Shack, I'm concerned how LARGE support stuff has grown to run your
software. Did you ever use something like Paradox ? I recall feeding the
machine some 20 or more diskettes - it was like feeding strawberries to a
bloody donkey. OK storage grows and even with increased support
software, as a percentage of disk capacity it is negligible. I'd be
curious, given say something like String2Num, written in COBOL and a
comparative copy written entirely in Java, what would be the physical
size of the respective packages - done in F/J or M/F you have to have
the accompanying runtime etc.; presumably something similar even with Java.

Our friends at NASA, (Yes I know they aren't interested in debits or
credits :-) ), and speculatively, they probably have a series of
'own-written' machine code languages to control the various components.
A component might be no more than the ability to switch something On/Off
- but with very tight code. And I betcha they rewrite components -
"Hello Huston, we have a problem". Diagnose it down on Terra Firma and
via the airwaves transmit a new copy of the component up to the Heavens
:-).

You made a comment about not using FACTORY. I'll cover it later - your
reference to the methods GET and SET used in conjunction with PROPERTY
made be twig. Short answer M/F didn't have PROPERTY in the earlier
compilers - certainly not in the sense you are using it.

I'm afraid the whole thing is now getting a bit academic. I've reached
the point where I muse, "Who needs this ?", at an age where I want to
sit down and watch the grass grow. (Actually come spring/summer - the
grass grows too bloody quickly). At this point I'm kinda giving up on
COBOL completely - when will there be such a thing as a COBOL Standard
usable by all, no consistency in GUI-ing with a thousand and one tools
to be learned and evaluated, hoping you pick the right one, then the
bloody nonsense of runtimes. If I were to energize myself then I think I
would make the effort to completely switch to Java - but to what purpose ?

Was a time I used to muse, write a book on OO COBOL. No small task, with
any technical book, as Thane would have found with his TYCI24H - and
zippo money in royalties. Then you have ask (1) Who would publish it ?,
(2) More importantly, who would read it ? and (3) Can't really write the
book without a compiler can you - so the obvious for me, N/E. Let's say
book costs $60, they want about $100 for N/E University Edition, and do
you carefully avoid saying to your readers that when they get into the
'real' compiler, M/F want some unspecified fee for runtimes.

Oh hummmm.

Jimmy

Pete Dashwood

2006-02-17, 7:55 am

"Howard Brazee" <howard@brazee.net> wrote in message
news:lf29v197ghs6015jlksapalq6mehbeud2g@
4ax.com...
> On Fri, 17 Feb 2006 00:33:50 +1300, "Pete Dashwood"
> <dashwood@enternet.co.nz> wrote:
>
>
> And I believe that if they hadn't been first, commercial credibility
> would have come anyway, and the effect of PCs on IBM's bottom line
> would not have been more favorable.

I don't think I ever disagreed with that... :-)

Pete.

Pete Dashwood

2006-02-17, 7:55 am

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1140118312.532245.115810@o13g2000cwo.googlegroups.com...
>
> Pete Dashwood wrote:
>
> And the point that I was making is they weren't. Apple used the term
> 'Personal Computer' in advertising in 1979 and the use of 'PC' was
> common before IBM came out with their copy of what was already going
> on.
>
That's interesting. I believe you, because you are usually very accurate
with these things, but it isn't how I remember it. Maybe our backgrounds
colour our perceptions and thus our memories. I'm sure you are right in what
you say. I just wasn't exposed to the Apple.

> In fact the IBM machine was a direct result of micros proliferating in
> the workplace. It was designed specifically around the capabilities of
> the current Apple ][ and CP/M machines for exactly that reason. It took
> DOS from CP/M, Basic from MS's Applesoft and CP/M, Visicalc from
> Commodore and Apple, dBase II from CP/M _because_ the IBM salesmen were
> tripping over these in their accounts.
>
> Certainly the IBM name made the general public take much more notice.
>
>
> Absolutely.
>
>
> No. It was Visicalc and then Lotus 123. It was Wordstar then
> WordPerfect, It was dBase II then several derivitives.
>

Very possibly. I hadn't looked at it that way.

> Businesses didn't buy PC because they had IBM on the front, they bought
> them because they had a spreadsheet or a word processor on the screen
> and because they were cheaper than the single-use word processors that
> many companies were already selling. It had to be an IBM or identical
> Clone because that is what Lotus-123 required, not because IBM was the
> brand.
>

I worked in Spain in 1985 and they had several IBM PCs. They ran APL on them
! (I know a sample of 1 doesn't mean much, but they certainly weren't using
them for Lotus or Wordstar)

>
> I completely disagree. Mainframes were not replaced by PCs with 386
> CPUs, they were replaced by departmental minis. More recently 'PC's, or
> more accurately Intel based machines, are being clustered to give
> mainframe performance, but IBMs mainframe sales
> have been growing too in last few years.

Well, it is a good argument. I worked at IBM in the early 90s and PCs were
perceived by many as the major threat to the mainframe. For a number of
years after 1983/4 when they began appearing in corporates in significant
numbers, they were written off and dismissed as "toys", but by the early 90s
networks were starting to compete with the centralised mainframe. (I agree
it was minis that were the servers, but again, the perception was PCs on
desktops.) Eventually it became a contest between the network and the
centralised mainframe. Mainframe sales have been growing because they are
used as network servers... It is really no contest. The power of networked
machines is almost infinite; as much as you can expand the network. The
power of a single box is limited to the power of a single box...

Pete.

Pete Dashwood

2006-02-17, 7:55 am

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:LU8Jf.22960$H%4.4608@pd7tw2no...
> Pete Dashwood wrote:
>
> Yep - I've always understood the Lego aspect you address. Next time you
> use the word, which you have already mentioned, put it in big bold
> 'R-E-U-S-E'.
>
> Interesting point - but I think it's OK. Ages since I looked at
> distributing software. No problem for me as I put it all, Micro Focus
> support software, my own and data into one directory with sub-folders.
>
> However suppose you supply Accounts Payable/Bought Ledger; then
> subsequently six months later you supply General Ledger. To avoid
> 'duplicates' of the M/F software it's a file COBDIR (I think) that you use
> to point both applications at the directory containing the M/F runtime
> support.
>
> Means of course to use components you would have to have each one pointing
> at the M/F directory. So in theory at least, the trigger key should only
> apply to one version of the runtime you have in that separate M/F
> location. (Naturally - if that's not true - then it is truly the pits !).
>
That sounds reasonable. I still don't like dongles though and never have...
I worked at British Rail (when the Channel Tunnel was being built), and all
the ticketing was being done by MicroFocus COBOL. It was a high visibility
and very ambitious project (we were talking to mainframes and PC networks
throughout Europe, so that Mr. Jones could buy a railway ticket in
Abergavenny to get him to Dresden, via Boulogne...:-)) We needed to be able
to swap PCs in and out of various environments and the dongles were always
getting lost or trodden on or suchlike... Granted, a software dongle doesn't
have that problem, but you can bet you will be denied access at the most
inopportune time... Iit's Sod's Law...
>
> Given that they wont commit to a hard-worded license fee proposal, chances
> are if you produced a component, let's suggest your price might be $50 for
> something fairly simple, you could probably negotiate with them - they
> still aren't going to let you have a 'freebie' and might want you to tack
> on $5-10 for them. How it would work if you got lucky and had say 500-800
> end-users, God knows how it would be controlled. (Incidentally that's one
> aspect I posed to their CEO - totally ignored in his reply - so your guess
> is as good as mine).

It really sounds insane. No wonder people are moving away from COBOL. I
wonder what would happen if someone wrote an Open Source MF RTS that could
run .INT files and distributed it free... (Maybe they'd pay you to stop
:-))
>
> As somebody pointed out just before Christmas, get into something like
> dotNet where you find the 'appeal' of one of the dotNet languages and
> now only callback for minimal COBOL usage, "....they now ch

ily charge
> each server side instance as one user licence which is $150...". As she
> pointed out 100 x $150 plus an annual fee, (didn't understand the last
> comment 'annual fee' - presumably Annual Technical Support) - nice gravy
> for M/F

Charging for each instance of somethng certainly sounds unfair.
..
>
> So, you the developer haven't had a necessity to use Java or 'C'
> languages before, but you are *now*, using dotNet - Don't need me to
> spell it out - what's the developer's next move ? It's already happening
> - and that was the danger I foresaw when both F/J and M/F went the
> dotNet route.
>

I considered buying Fujitsu COBOL for Dot NET. The best deal I could get was
several thousand dollars from Fujitsu Australia and I simply can't justify
it. I know dot Net has a future but I've got to the point now where I really
can't be bothered. By the time you get Visual Studion for DotNET you might
as well write in VB or C#. COBOL doesn't get a look in...

> Touching on components - and you dismissed my previous observation ages
> ago - thinking back to 'economic use' on a limited box like a Radio
> Shack, I'm concerned how LARGE support stuff has grown to run your
> software.

The Fujitsu runtimes for NetCOBOL and PowerCOBOL are around 6 Megs each. The
MicroSoft run time for VB (which is installed on most windows machines
automatically), is around 400K! Once the Fujitsu runtimes are installed
they never need to be installed again and there are no fees for using them,
but it is still a significant chunkof code to support COBOL. This is one
reason why I moved away from writing components for distribution; the
install size was embarrassing... :-)

>Did you ever use something like Paradox ?

No, But I used DBase and SuperBase... :-)

I recall feeding the
> machine some 20 or more diskettes - it was like feeding strawberries to a
> bloody donkey. OK storage grows and even with increased support software,
> as a percentage of disk capacity it is negligible. I'd be curious, given
> say something like String2Num, written in COBOL and a comparative copy
> written entirely in Java, what would be the physical size of the
> respective packages - done in F/J or M/F you have to have the accompanying
> runtime etc.; presumably something similar even with Java.
>
If it were written as a Java Bean, an Applet, or a Servlet, it would use the
standard JVM. I have never checked the size of this.

To be honest, once a RTS is installed it is only of academic interest. The
resistance happens the first time it is set up. The advantages that Java and
VB have is that they are probably already installed on your machine.

> Our friends at NASA, (Yes I know they aren't interested in debits or
> credits :-) ), and speculatively, they probably have a series of
> 'own-written' machine code languages to control the various components.
> A component might be no more than the ability to switch something On/Off
> - but with very tight code. And I betcha they rewrite components -
> "Hello Huston, we have a problem". Diagnose it down on Terra Firma and
> via the airwaves transmit a new copy of the component up to the Heavens
> :-).
>
I'm sure something like that goes on...

> You made a comment about not using FACTORY. I'll cover it later - your
> reference to the methods GET and SET used in conjunction with PROPERTY
> made be twig. Short answer M/F didn't have PROPERTY in the earlier
> compilers - certainly not in the sense you are using it.
>
I like to use properties rather than pass parameters because doing so keeps
the interface consistent.(There isn't one... can't get much more consistent
than that :-))

> I'm afraid the whole thing is now getting a bit academic. I've reached the
> point where I muse, "Who needs this ?", at an age where I want to sit down
> and watch the grass grow. (Actually come spring/summer - the grass grows
> too bloody quickly).
I understand how you feel. It is quite some time since I wrote any COBOL.
These days it seems to be JavaScript and ASP for my own interest at home and
bloody Visual Basic to put hooks into Clear Quest so I can properly manage
the project at work.

(I have to confess to a sneaking liking for VB - I have never learned it;
just had to write it, and I have it doing some quite useful things. A couple
of months ago I couldn't have imagined scripting in anything other than
JavaScript (even for WSH as well as web pages). Since I have been forced to
use VB for Clear Quest I have found it isn't nearly as bad as I imagined and
it is pretty easy to debug and get working. While it isn't quite as facile
with Objects and OO as Java is, it is still pretty

. I've changed my
mind about it.)

At this point I'm kinda giving up on
> COBOL completely - when will there be such a thing as a COBOL Standard
> usable by all, no consistency in GUI-ing with a thousand and one tools to
> be learned and evaluated, hoping you pick the right one, then the bloody
> nonsense of runtimes. If I were to energize myself then I think I would
> make the effort to completely switch to Java - but to what purpose ?
>
You're right.

> Was a time I used to muse, write a book on OO COBOL. No small task, with
> any technical book, as Thane would have found with his TYCI24H - and zippo
> money in royalties. Then you have ask (1) Who would publish it ?, (2) More
> importantly, who would read it ? and (3) Can't really write the book
> without a compiler can you - so the obvious for me, N/E. Let's say book
> costs $60, they want about $100 for N/E University Edition, and do you
> carefully avoid saying to your readers that when they get into the 'real'
> compiler, M/F want some unspecified fee for runtimes.

Yes, I considered doing so too. What put me off was Wil Price's book which I
think is excellent and there's very little I'd want to add to it. The
edition I have, came with a disk that had an academic version of Net Express
on it. Unfortunately, when the book was transported from England to NZ the
disk got broken. It is just as well I already had Fujitsu Net COBOL which
also supports OO (and does so very well indeed).
>
> Oh hummmm.
>
> Jimmy

2006-02-17, 7:55 am

In article <45lt3iF788biU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:

[snip]

>(I have to confess to a sneaking liking for VB - I have never learned it;
>just had to write it, and I have it doing some quite useful things.

This sort of situation - 'I never learned it, just had to write it' - is
something I have seen more than a few programmers take for granted and all
Human Resources Departments find utterly incomprehensible.

DD

Oliver Wong

2006-02-17, 6:55 pm

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:45lt3iF788biU1@individual.net...
>
> The Fujitsu runtimes for NetCOBOL and PowerCOBOL are around 6 Megs each.
> The MicroSoft run time for VB (which is installed on most windows machines
> automatically), is around 400K! Once the Fujitsu runtimes are installed
> they never need to be installed again and there are no fees for using
> them, but it is still a significant chunkof code to support COBOL. This is
> one reason why I moved away from writing components for distribution; the
> install size was embarrassing... :-)
>
[...]
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:LU8Jf.22960$H%4.4608@pd7tw2no...
>
> I recall feeding the
> If it were written as a Java Bean, an Applet, or a Servlet, it would use
> the standard JVM. I have never checked the size of this.

If you want to become a user of Java software, you need to download the
JRE (Java Runtime Environment), which on my computer takes up 68.7MB. This
includes Sun's Standard Library though, which is basically a massive set of
components (with support for GUI, networking, XML parsing, distributed
computing, cryptography, SQL, threading, logging, regular expressions,
compression, accessibility, image manipulation, printing, sound manipulation
(both waveform and MIDI), internationalization, etc.) There's even a (dated)
HTML web browser component bundled in there somewhere. If you exclude the
library, you're down to 19.8MB.

If you want to become a developer of Java software, you need to download
the JDK (Java Development Kit). It includes everything the JRE has, plus
documentation, the source code for everything in the library, and a few
extra tools (like a compiler, and a certificate signing software, etc.) It's
118MB.

>
> To be honest, once a RTS is installed it is only of academic interest. The
> resistance happens the first time it is set up. The advantages that Java
> and VB have is that they are probably already installed on your machine.

The JVM (Java Virtual Machine) is a subset of the JRE, and it's the
piece of software that actually runs your Java programs. Sun includes a JVM
with the JRE, but Microsoft at one point had developped their own JVM, and
distributed it with Windows.

The two JVMs were incompatible, and so people who had Microsoft's JVM
pre-installed with their copy of Windows would wonder why all the applets
written by Sun would mysteriously fail, while all the applets written by
Microsoft would work just fine.

Sun took Microsoft to court, eventually won, and so now Microsoft no
longer bundles their JVM with windows.

>
> I'm sure something like that goes on...

This is just hearsay, but I heard that they launched the Mars Rover
before the software team finished developping the software for the device!
As the rover was flying through space towards Mars, the updates would
continuously be sent via laser.

- Oliver

James J. Gavan

2006-02-17, 6:55 pm

Oliver Wong wrote:
>
Thanks for the quick intro Oliver. So satisfy my curiosity, why would
someone using Java (like yourself) or the 'C' family, have an interest
in COBOL ? Unless of course as a hobbyist, you are just a dabbler :-)

Any comments - I think Rodey Green's site might be a useful source -
every time he answers a query, always a brief reply, "Go look at my site
- this page".
>
> The two JVMs were incompatible, and so people who had Microsoft's JVM
> pre-installed with their copy of Windows would wonder why all the
> applets written by Sun would mysteriously fail, while all the applets
> written by Microsoft would work just fine.
>
> Sun took Microsoft to court, eventually won, and so now Microsoft no
> longer bundles their JVM with windows.

Yeah I was tuned in on that one. Horstmann and Cornell in their 'Core
Java' made that point at the beginning of the first of the two volumes -
Three Javas - Sun, Microsoft (Windows only - gotcha !) and HP because
they needed features for components in fridges/freezers etc. (The
authors weren't referencing the legal case).
>
> This is just hearsay, but I heard that they launched the Mars Rover
> before the software team finished developping the software for the
> device! As the rover was flying through space towards Mars, the updates
> would continuously be sent via laser.
>
It surely has to be a fairy tale. Can you just imagine, "Line up, Line
up please to get your Chunnel tickets. The next train is due to depart
London at 10:45. We'll let you know when it is due to arrive in Paris,
en route of course, when the engineer has finished building the engine".

Jimmy

LX-i

2006-02-17, 9:55 pm

Oliver Wong wrote:
> If you want to become a developer of Java software, you need to
> download the JDK (Java Development Kit). It includes everything the JRE
> has, plus documentation, the source code for everything in the library,
> and a few extra tools (like a compiler, and a certificate signing
> software, etc.) It's 118MB.

The *download* is 118MB - it uncompresses much larger (at least it
seemed that way to me). :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ 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++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Pete Dashwood

2006-02-18, 6:55 pm

Thanks for that, Oliver. As usual, interesting and informative :-)

Pete.

TOP POST no more below
"Oliver Wong" <owong@castortech.com> wrote in message
news:gVmJf.3882$_62.736@edtnps90...
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:45lt3iF788biU1@individual.net...
> [...]
>
> If you want to become a user of Java software, you need to download the
> JRE (Java Runtime Environment), which on my computer takes up 68.7MB. This
> includes Sun's Standard Library though, which is basically a massive set
> of components (with support for GUI, networking, XML parsing, distributed
> computing, cryptography, SQL, threading, logging, regular expressions,
> compression, accessibility, image manipulation, printing, sound
> manipulation (both waveform and MIDI), internationalization, etc.) There's
> even a (dated) HTML web browser component bundled in there somewhere. If
> you exclude the library, you're down to 19.8MB.
>
> If you want to become a developer of Java software, you need to
> download the JDK (Java Development Kit). It includes everything the JRE
> has, plus documentation, the source code for everything in the library,
> and a few extra tools (like a compiler, and a certificate signing
> software, etc.) It's 118MB.
>
>
> The JVM (Java Virtual Machine) is a subset of the JRE, and it's the
> piece of software that actually runs your Java programs. Sun includes a
> JVM with the JRE, but Microsoft at one point had developped their own JVM,
> and distributed it with Windows.