State of the Market

[malvolio]

See, now there are more details being revealed.

So input a 4-digit number and return a Y or N.
How exactly do we measure memory efficiency? I don't run a mainframe, and different compilers/linkers/platforms have different ways of using memory.
The DIVIDE statement is very inefficient of course, but avoid 4? Why?

Were I to take a first crack, I might use the MOD function, and add 2 to a variable twice. See what I did there?

It's an old solution to an old environment problem. The mainframe in question had 32Kb virtual memory to play with an roughly a fiftieth the CPU power of a modern PC. Lines of compiled code output and memory utilisation were quite important.

But it is actually an exercise in binary arithmetic... Not something that troubles modern coders.

[sadkingbilly]

It's not about applications. It's about efficient use of COBOL. Or if that's too difficult, it's about lateral thinking.

don't do COBOL.
(apart from installing and maintaining compilers)

[Dorkeaux]

No, its a real problem i had to solve in the 90s - write a reusable subroutine to apply across a suite of complex real time applications to validate if any given 4 dhigit year was a leap year or not. The inout parameter was a four digit number, the output was a simple Yes/No flag.

Other requirement was to be as memory efficient as possible while using COBOL features.

There is more than one answer, but no need to code it, merely work out a high level solution.

See, now there are more details being revealed.

So input a 4-digit number and return a Y or N.
How exactly do we measure memory efficiency? I don't run a mainframe, and different compilers/linkers/platforms have different ways of using memory.
The DIVIDE statement is very inefficient of course, but avoid 4? Why?

Were I to take a first crack, I might use the MOD function, and add 2 to a variable twice. See what I did there?

[secwombat]

No, its a real problem i had to solve in the 90s - write a reusable subroutine to apply across a suite of complex real time applications to validate if any given 4 dhigit year was a leap year or not. The inout parameter was a four digit number, the output was a simple Yes/No flag.

Other requirement was to be as memory efficient as possible while using COBOL features.

There is more than one answer, but no need to code it, merely work out a high level solution.

Ah - and there in lies the problem faced by a number of banks when we were testing for Y2K problems. The year 2000 wasn't a leap year (every 400 years it skips) ...

Would have cost a lot of money if we hadn't caught it.

[malvolio]

Sorry, but I expect that when I propose a solution that doesn't use the DIVIDE statement nor a constant of 4 you'll say it's wrong and drip feed in some other requirement that fits only the answer you came up with.

Not my first rodeo.

No, its a real problem i had to solve in the 90s - write a reusable subroutine to apply across a suite of complex real time applications to validate if any given 4 dhigit year was a leap year or not. The inout parameter was a four digit number, the output was a simple Yes/No flag.

Other requirement was to be as memory efficient as possible while using COBOL features.

There is more than one answer, but no need to code it, merely work out a high level solution.

[Dorkeaux]

Nor should you. We use the skills we have to their best effect. obviously. On occasion I'm tempted to dig out my old ANSI 74 COBOL skills and see how I get on*!

Just acknowledge that all the other skills are no less critical. We're all here to service the business, after all.


Nice challengefor us oldies. Write a COBOL subroutine to test for leap years up to year 9999. You can't use a DIVIDE statement. Or a number 4...

Sorry, but I expect that when I propose a solution that doesn't use the DIVIDE statement nor a constant of 4 you'll say it's wrong and drip feed in some other requirement that fits only the answer you came up with.

Not my first rodeo.

[malvolio]

i don't do applications.

It's not about applications. It's about efficient use of COBOL. Or if that's too difficult, it's about lateral thinking.

[Protagoras]

got wrong techs then, or windoze DCs

What I see happening here is that 'we' are reduced to in-fighting, be it about technical skills, nationality or whatever. It's not nice and it's not helpful.

Our challenge is that with no credible government willing to invest in the UK to rebalance and grow our economy it's becoming 'every man for himself'.

We're being punished by successive governments' policies aimed at supporting their favoured skakeholders to the detriment of UK workers. Half a century ago it was manufacturing and heavy industry. Later is was utilities (read essential public services). Time moved on and it's been our turn for a while now. There's a pattern here ...

Government policies set the basis for costs in the economy. They've driven out business and they're driving out people. Even if we had an election tomorrow, I don't see any party with the vision to make the levels of investment necessary, rather we'll probably just have more rent-seeking privatisation, driving up our costs (and taxes) in a spiral of decline.

There are probably only two camps; those with the skills to survive and those with the funds to opt-out. Certainly there's no point holding out for better days; they're behind us.

[Protagoras]

Just acknowledge that all the other skills are no less critical. We're all here to service the business, after all.

For those like me, "Service the business" is simply a means to an end.

The main objective is to extract maximum personal revenue for the minimum effort while hopefully enjoying it a bit.

[fatJock]

Powerpoint Monkeys(PMs) and Bullsh1t Artists(BAs) are a waste of time anyway.

got wrong techs then, or windoze DCs

Wrong on all counts.