In article <[email protected]>,
pete dashwood <[email protected]> wrote:

[snip]

A recent browse of COBOL jobs showed that COBOL
alone is not really enough to get you employed. There are still
mainframe jobs and knowledge of that environment is good, but they will
be much more interested if you have network knowledge as well.I saw ads
for PHP, Java and COBOL, C# and COBOL, and Windows scripting that were
marked as "desirable".

Every so often I'll get an email from someone asking for The Usual
Suspects (for an IBM shop that's five-to-seven years' of COBOL, VSAM,
CICS, DB2, FileAid and the like). I have two 'kepboard macros' that I use
to respond to such folks:

1) 'Sounds interesting. What kind of rate are they offering?'

... and if a response comes - and they rarely do - the hourly rates
offered are the same ones I used to see in 1985. This triggers the net keyboard macro:

2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
kind of rate are they offering almost forty years later?'

DD

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I am currently working on the PRIMA Web Site to make it reflect a change
in direction of the business.
(https://primacomputing.co.nz)

We had a run of bad luck where our ISP died then, after I managed to get everything transferred to a new host, a short time after the site was
settling down, that ISP sold out to a different one and that has meant a
few trivial but annoying changes.

I wrote the site originally in ASP.NET and it has proven to be excellent
for web development. The later versions of Visual Studio allow me to
develop pages with a design surface just like Win Forms or WPF and it is
very easy to wire them to the C# code-behind that drives all the events,
then FTP them to the server with Filezilla.
Everything runs as compiled code on the server and it is much more
secure than interpreting client side scripts.

It allows me to retain a "hand-made" look and feel which may not be as
slick as a templated WordPress site, but which makes us a little
different from most of the sites out there.

Anyway, recently I put the final touches and end-point processes into
the PRIMA Tools. It has taken me 13 years... :-)

The last processes for PowerCOBOL to Dot.NET are integrated and I am
satisfied with the testing.

The onset of Covid affected the demand for migration (or maybe our niche
was closing anyway... I'll never know) so the Company has had to be run
on its reserves to keep going.

I decided that if we are to encourage any remaining people to move their standard COBOL from indexed files into RDB, or their PowerCOBOL GUI applications into .NET, it is counter-productive to sell them the tools
and help them learn how to use them. Much quicker and cheaper for
everybody, if we just do it for them.

So I am moving PRIMA to be a service company where you have a shopping
list of what you need and I am writing an online calculator that will
give you a "ballpark quote" based on what you want done.

This arose after there was a recent pricing enquiry here and the OP
really didn't get that the price will vary depending on a number of
factors and quantities. I gave him a fairly accurate ball-park but, in
fact, it could have been less expensive if some other factors had been
added in. Hence, an algorithm that will work like a calculator on the
web page and give people a good idea of what THEIR specific cost is
likely to be if they go with our solution.

I've also taken a bit of time to reflect on the tool development and I
have a few observations that might be of consideration to those of you developing applications in COBOL. The following is opinion, based on experience, so it is arguable:

1. Go with a modular design.
The overall design should have 3 tier design if it is for the Network. Presentation Layer, Business Logic Layer, and Database Access Layer.
(Our tools generate all of the code for these layers, salvaging the
COBOL Business Logic from your legacy, creating the DAL Layer and (for PowerCOBOL...) converting the Presentation layer to .NET Forms.
Each of these functions will be on the new shopping list...

If you are doing Batch Processing in COBOL and simply moving to a modern RDBMS, it is very tempting to integrate everything into
monolithic application programs, then go through and simply change all
the indexed IO to be Embedded SQL... My advice: DON'T DO IT! I've
covered it here: https://primacomputing/PRIMAMetro/RDBandSQL3.aspx
(Again, we can offer you a service where we analyze all your existing
COPY books and design an optimized Relational Database, along with a DAL
Layer to handle it (if required). We can also do the code conversion of
your Legacy so that it uses the DAL Layer.

BOTTOM LINE: Small is beautiful. Isolate functionality into components
and use layered collections of these components. This has minimal
disruption when it needs maintenance, and it is much quicker and easier
to locate problem code.

Objected Oriented Programming (in COBOL or any other OO language)
facilitates this approach.

2. Be careful with TABBED controls in your software.
(There are a number of "COBOL PlugIns" that provide a GUI facility. We
deal mostly with PowerCOBOL from Fujitsu.)

It is very easy to let tabbed functionality get out of control. You design a new function; add a new TAB... all well and good but don't let
it go too far...

One of our tools has more than 10 TABs in it and some of these are for functionality that is no longer used. You'd think it would be pretty
easy to simply cut out the unnecessary ones... I worked out it would
take me 1 - 2 days to do this properly. Who has days available for "cosmetics"...? (as we are no longer selling the tools, I immediately
picked up 1 - 2 days.... :-))

3. I have been doing quite a bit of COBOL manipulation using Visual
Studio Code. It has many of the advantages of VS (like Intellisense and Bookmarks...) and I think it does make COBOL coding easier. It's a free
tool and it will deal with ANY Version of COBOL that is at least COBOL
'85 compliant. (I should think it would be very good for GNU COBOL...,
but I'm sure Eclipse is also good.)

4. Back in the 1990s I suggested that COBOL people should expand their
toolbox. Sadly, there was an attitude that "Everything I want to do, I
can do in COBOL..." (I always thought it showed limited aspiration as to
what you want to do...). A recent browse of COBOL jobs showed that COBOL
alone is not really enough to get you employed. There are still
mainframe jobs and knowledge of that environment is good, but they will
be much more interested if you have network knowledge as well.I saw ads
for PHP, Java and COBOL, C# and COBOL, and Windows scripting that were
marked as "desirable".

I would recommend that if you are still interested in expanding your
skill set, take a look at Rust and JavaScript. I have only had limited
exposure to Rust but it really impressed me. On my list for when I get
time... :-)

I'd be interested to hear what people are actually doing, in terms of
COBOL, if there are still people writing COBOL every day.. Why not post
a summarized response? And, of course, any comments on the opinions
expressed above would be acknowledged and/or discussed.

Cheers,

Pete.


--
I used to write *COBOL*; now I can do *anything*...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/11/2021 14:07, [email protected] wrote:

In article <[email protected]>,
pete dashwood <[email protected]> wrote:

[snip]

A recent browse of COBOL jobs showed that COBOL
alone is not really enough to get you employed. There are still
mainframe jobs and knowledge of that environment is good, but they will
be much more interested if you have network knowledge as well.I saw ads
for PHP, Java and COBOL, C# and COBOL, and Windows scripting that were
marked as "desirable".

Every so often I'll get an email from someone asking for The Usual
Suspects (for an IBM shop that's five-to-seven years' of COBOL, VSAM,
CICS, DB2, FileAid and the like). I have two 'kepboard macros' that I use
to respond to such folks:

1) 'Sounds interesting. What kind of rate are they offering?'

... and if a response comes - and they rarely do - the hourly rates
offered are the same ones I used to see in 1985. This triggers the net keyboard macro:

2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
kind of rate are they offering almost forty years later?'

DD

Hi Doc,

that is amazing (and pretty disappointing...).

It seems that COBOL skill continues to be undervalued as it always was.

Pete.

--
I used to write *COBOL*; now I can do *anything*...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <smpngj$i2a$[email protected]>, <[email protected]> wrote:

2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
kind of rate are they offering almost forty years later?'

Presumably one warranted by the productivity of a programmer using the language.

As the productivity (as measured by those paying for the production) of
COBOL programming diminishes relative to the productivity of python / go /
C# / whatever, the rates offered also languish. To improve rates for those skilled in a particular tool, improve the productivity of the programmers
using the tool.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 15 Nov 2021 14:32:36 -0000 (UTC), [email protected] (Randy Hudson) wrote:

In article <smpngj$i2a$[email protected]>, <[email protected]> wrote:

2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
kind of rate are they offering almost forty years later?'

Presumably one warranted by the productivity of a programmer using the >language.

As the productivity (as measured by those paying for the production) of
COBOL programming diminishes relative to the productivity of python / go /
C# / whatever, the rates offered also languish. To improve rates for those >skilled in a particular tool, improve the productivity of the programmers >using the tool.

Do you have anything to support this claim? Additionally, are you talking about modules or systems? Are you taking TCO into
consideration?

My experience differs depending on the requirement. There appears to be a tendency for developing MVP's, something a halfway decent
Cobol developer doesn't consider to be a viable deliverable. MVP's are fine for throw-away systems, not for core bussiness
applications. "The old stuff" or "legacy" is disguised by management and architects even though operationally it is cheap and has a
low incidence rate. It's just not sexy.

FYI: My scope encompasses many languages and technical platforms.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <smtr24$1en$[email protected]>,
Randy Hudson <[email protected]> wrote:

In article <smpngj$i2a$[email protected]>, <[email protected]> wrote:

2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
kind of rate are they offering almost forty years later?'

Presumably one warranted by the productivity of a programmer using the >language.

Hey, good joke! How does one measure the productivity of 'learning where
to hit the machine'?

As the productivity (as measured by those paying for the production) of
COBOL programming diminishes relative to the productivity of python / go /
C# / whatever, the rates offered also languish. To improve rates for those >skilled in a particular tool, improve the productivity of the programmers >using the tool.

Decisions about COBOL and the platforms on which it runs are, nowadays,
not made by considering productivity - in my experience, of course - but
are instead made by someone hollering 'DO SOMETHING NOW!' when a
meetingful of Corporate Equals explodes into that 'you still have a
MAINFRAME?' laughter designed to shrivel one's sensitive regions as does sitting on a winter-chilled Albany bus-bench.

DD

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>,
Joe <[email protected]> wrote:

On Mon, 15 Nov 2021 14:32:36 -0000 (UTC), [email protected] (Randy Hudson) wrote:

In article <smpngj$i2a$[email protected]>, <[email protected]> wrote:

2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what >>> kind of rate are they offering almost forty years later?'

Presumably one warranted by the productivity of a programmer using the
language.

As the productivity (as measured by those paying for the production) of
COBOL programming diminishes relative to the productivity of python / go / >> C# / whatever, the rates offered also languish. To improve rates for those >> skilled in a particular tool, improve the productivity of the programmers
using the tool.

Do you have anything to support this claim?

The claim that rates track perceived productivity of the worker using the
tools of his choice? No; it's probably just a fantasy, and rates are chosen
by throwing 20-sided dice.

Additionally, are you talking about modules or systems? Are you taking TCO into
consideration?

"as measured by those paying..."

TCO is unknown at the time the rates are determined, though of course
attempts are made to estimate it closely.

My experience differs depending on the requirement. There appears to be a tendency for developing MVP's, something a halfway decent Cobol developer doesn't consider to be a viable deliverable. MVP's are fine for
throw-away systems, not for core bussiness applications. "The old stuff"
or "legacy" is disguised by management and architects even though operationally it is cheap and has a low incidence rate. It's just not
sexy.

End-user experience is easier for non-technical executives to themselves observe than "back-end" performance. That may lead to mispricing those deliverables, not because of sexiness, but because their effectiveness is easier to evaluate.

FYI: My scope encompasses many languages and technical platforms.

Probably more than mine; the last time I was paid for programming, I was writing in BAL.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 15 Nov 2021 17:25:56 -0000 (UTC), [email protected] (Randy Hudson) wrote:

In article <[email protected]>,
Joe <[email protected]> wrote:

FYI: My scope encompasses many languages and technical platforms.

Probably more than mine; the last time I was paid for programming, I was >writing in BAL.

Nice one ;-) Haven't done that for a while....

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/11/2021 03:32, Randy Hudson wrote:

In article <smpngj$i2a$[email protected]>, <[email protected]> wrote:

2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what
kind of rate are they offering almost forty years later?'

Presumably one warranted by the productivity of a programmer using the language.

As the productivity (as measured by those paying for the production) of
COBOL programming diminishes relative to the productivity of python / go /
C# / whatever, the rates offered also languish. To improve rates for those skilled in a particular tool, improve the productivity of the programmers using the tool.

That sounds reasonable and you make a fair point.

For myself I am at least twice as productive in C# than I am in COBOL.

This has nothing to do with the language, but rather with the fact that
Visual Studio is MUCH more powerful than the Fujitsu IDEs for COBOL or PowerCOBOL.

It is also undeniable that COBOL is more verbose than the other
languages and requires more writing. (Especially if you want it to be maintainable...)

I tried using Visual Studio Code (another free version of VS, that can
support most dialects of COBOL), and it was definitely better. But I
didn't do prolonged trials with it because I stopped using COBOL
(almost) altogether and for the small amounts I do use it, the IDEs are acceptable.

Pete.
--
I used to write *COBOL*; now I can do *anything*...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/11/2021 05:34, Joe wrote:

On Mon, 15 Nov 2021 14:32:36 -0000 (UTC), [email protected] (Randy Hudson) wrote:

In article <smpngj$i2a$[email protected]>, <[email protected]> wrote:

2) 'Hey, good joke! Seriously, I was billing that rate in 1985... what >>> kind of rate are they offering almost forty years later?'

Presumably one warranted by the productivity of a programmer using the
language.

As the productivity (as measured by those paying for the production) of
COBOL programming diminishes relative to the productivity of python / go / >> C# / whatever, the rates offered also languish. To improve rates for those >> skilled in a particular tool, improve the productivity of the programmers
using the tool.

Do you have anything to support this claim? Additionally, are you talking about modules or systems? Are you taking TCO into
consideration?

My experience differs depending on the requirement. There appears to be a tendency for developing MVP's, something a halfway decent
Cobol developer doesn't consider to be a viable deliverable. MVP's are fine for throw-away systems, not for core bussiness
applications. "The old stuff" or "legacy" is disguised by management and architects even though operationally it is cheap and has a
low incidence rate. It's just not sexy.

FYI: My scope encompasses many languages and technical platforms.

If you look at TCO, COBOL is way behind at the end of the field.

COBOL Compilers continue to be exorbitant with mandatory updates and
service chanrges also required.

C#, VB.NET, RUST, Java, and Python are all FREE! And support is
available with a mouse click from a a community of millions.

Pete.

--
I used to write *COBOL*; now I can do *anything*...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 22/11/2021 20:57, pete dashwood wrote:

On 16/11/2021 05:34, Joe wrote:

On Mon, 15 Nov 2021 14:32:36 -0000 (UTC), [email protected] (Randy Hudson)
wrote:

In article <smpngj$i2a$[email protected]>,  <[email protected]>
wrote:

2)  'Hey, good joke!  Seriously, I was billing that rate in 1985...
what
kind of rate are they offering almost forty years later?'

Presumably one warranted by the productivity of a programmer using the
language.

As the productivity (as measured by those paying for the production) of
COBOL programming diminishes relative to the productivity of python /
go /
C# / whatever, the rates offered also languish.  To improve rates for
those
skilled in a particular tool, improve the productivity of the
programmers
using the tool.

Do you have anything to support this claim?  Additionally, are you
talking about modules or systems?  Are you taking TCO into
consideration?

My experience differs depending on the requirement.  There appears to
be a tendency for developing MVP's, something a halfway decent
Cobol developer doesn't consider to be a viable deliverable.  MVP's
are fine for throw-away systems, not for core bussiness
applications.  "The old stuff" or "legacy" is disguised by management
and architects even though operationally it is cheap and has a
low incidence rate.  It's just not sexy.

FYI: My scope encompasses many languages and technical platforms.

If you look at TCO, COBOL is way behind at the end of the field.

COBOL Compilers continue to be exorbitant with mandatory updates and
service chanrges also required.

C#, VB.NET, RUST, Java, and Python are all FREE! And support is
available with a mouse click from a a community of millions.

Pete.

I just wanted to add something in response to:

MVP's
are fine for throw-away systems, not for core business
applications. "The old stuff" or "legacy" is disguised by management
and architects even though operationally it is cheap and has a
low incidence rate. It's just not sexy.

MVPs are NOT just for throwaway systems. They are the basis of an
evolving system that is responsive to changing user needs. Typically,
this will involve an Agile style of Project Management, where there are iterations of development against user established priorities. (When I
do it, it is also timeboxed...)

This is far removed from the traditional COBOL Waterfall development and
that's why most COBOL people don't really understand it.

The overall concept is that a system evolves from the bare minimum
facilities into something that is very useful and forms a core business solution. And this is driven by 2 factors:

1. Iteration.
2. Interaction.

The interaction ensures that end users are involved throughout the
process, and it is THEIR priorities which are addressed.

Progress is incremental and can be easily backed out if it is found to
be flawed.

If a system is completely designed and signed off before production of
it starts, it will not be timely. Users will get what they signed off 9
months ago... and you will hear the familiar delivery/acceptance phrase:
"It's great, but could we just have this ONE small change..."

With the MVP/Agile approach, instead of the IT Department resisting
changes and waving sign-offs at users, change is embraced and
implemented immediately. The attitude is different and users respond to it.

The "old stuff" or "legacy" has never been "cheap", operationally or in
any other way. The maintenance of existing systems has always been the
most expensive cost for traditional COBOL systems. The procedural nature
of the code (rather than encapsulated OO Classes) means there are knock
on and downstream errors that require more expensive regression testing
and investigation.

Legacy code is not "unpopular" because it isn't "sexy"; it is unpopular
because it is not responsive to the changing requirements of the
marketplace, and costs users large amounts to get change.
(This without even considering the emotional cost of having to go to IT,
cap in hand, and beg for new functionality... then be told: "We are
really busy right now... we'll look at it in 6 months...")

Management don't care whether a programming language is "sexy" or not;
that is something for programmers.

The focus SHOULD be on delivering useful functionality to the users, not
on what a programmer's career CV needs to have...

Modern DevOps using things like MVP and Agile style procedures, deliver
that, and the cost is way less than traditional mainframe procedural development.

Pete.

--
I used to write *COBOL*; now I can do *anything*...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)