[Info-vax] Variable declarations, was: Re: improving EDT

[Bill Gunshannon]

On 11/23/16 10:58 AM, Kerry Main wrote:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
>> Of Bill Gunshannon via Info-vax
>> Sent: 23-Nov-16 10:30 AM
>> To: info-vax at rbnsn.com
>> Cc: Bill Gunshannon <bill.gunshannon at gmail.com>
>> Subject: Re: [Info-vax] Variable declarations, was: Re:
> improving
>> EDT
>>
>> On 11/22/16 11:39 PM, David Froble wrote:
>>> Bill Gunshannon wrote:
>>>> On 11/22/16 4:04 PM, David Froble wrote:
>>>>> Scott Dorsey wrote:
>>>>>>  <johnwallace4 at yahoo.co.uk> wrote:
>>>>>>> Quite a few people and organisations would say they
>> cared about
>>>>>>> security. They especially say this after they've been
>> publically
>>>>>>> breached.
>>>>>>>
>>>>>>> Fewer people and organisations actually consider (let
>> alone invest
>>>>>>> in) real security upfront.
>>>>>>
>>>>>> Indeed, and few of them even consider or invest in it
> after
>> the fact.
>>>>>>
>>>>>>> For certain specific applications, ARM's TrustZone seems
>> to have
>>>>>>> some applicability:
>>>>>>> https://www.arm.com/products/security-on-
>> arm/trustzone
>>>>>>>
>>>>>>> Intel have been trying to achieve something similar on=20
>> specific
>>>>>>> x86-based systems, with little visible effect to
>>>>>>> date:
>>>>>>> https://software.intel.com/en-us/sgx
>>>>>>>
>> https://en.wikipedia.org/wiki/Software_Guard_Extensions
>>>>>>>
>>>>>>> And back in the day, didn't Intel have a capability-based
>> chip?
>>>>>>> The ill-fated iAPX 432?
>>>>>>> https://en.wikipedia.org/wiki/Intel_iAPX_432
>>>>>>
>>>>>> Yes, the iAPX 432 was a very slow machine but one with a
>> lot of
>>>>>> real security features.  Although it died a horrible death
> of
>>>>>> bloat, many of the useful features in the 432 appeared in
>> the i960
>>>>>> which was an ingenious and well thought-out architecture
>> that Intel
>>>>>> seemed to be totally unable to sell in spite of excellent
>>>>>> performance and well-designed security.
>>>>>>
>>>>>>> If people actually wanted security, we wouldn't be
> reading
>> about
>>>>>>> obvious exploit after obvious exploit on the latest
> devices
>> from
>>>>>>> the Interweb of Trash. Or something.
>>>>>>
>>>>>> Precisely.
>>>>>> --scott
>>>>>
>>>>> I've had two experiences that caused me to throw in the
>> towel and do
>>>>> whatever people wanted.
>>>>>
>>>>> 1) I mentioned to a customer that storing credit card data
> and
>>>>> checking account data with no protection on an IIS server
>> wasn't a good idea.
>>>>> The response: "why not, everyone does it".
>>>>>
>>>>> 2) While discussing security with another customer I was
> told
>> "my
>>>>> boss doesn't care about security".
>>>>
>>>> For the first one I would explain the reason why.
>>>
>>> I did.  But, "everyone does it" seemed to be all they wanted
> to
>> know.
>>
>> Sorry, you said they asked "why not".  To me that implied they
>> wanted to know.
>>
>>>
>>>> For the second I would ask "his boss" if that was true.
>>>> If yes, I would look for somewhere else to work.
>>>
>>> Bill, companies, consultants, and such work hard to acquire
>> customers.
>>> They do not throw them away, just because the customer is
>> wrong.
>>>
>>> Rules of customers:
>>>
>>> 1) The customer is always right
>>>
>>> 2) When the customer is wrong, refer to rule #1
>>>
>>> Nuff said?
>>>
>>> I haven't worked as an employee since 1982 ...
>>
>>
>> That's fine, until they start blaming the workers for the
> breaches.
>> Not gearing a lot about it over hear, but listening to German
> radio
>> pretty much everyday I hear a lot about the VW fiasco. Current
>> trend is to blame the programmers who actually wrote the code.
>> It doesn't seem to matter that they were employees doing what
>> they were told to do.  Some of them will likely end out as the
>> scapegoats. Once again, "I was just following orders" is not
> going
>> to work as a defense.  I certainly would not want to work for a
>> place that is going to make me do things I don't agree with and
>> then hold me responsible later.
>>
>
> You are correct that all too often the blame is placed squarely
> on the shoulders of those in Operations Support.
>
> That is why it is so critical for those in  Operations Support to
> document those cases where for example, they asked for downtime
> to apply critical security patches or asked for additional
> critical App testing time and were denied.

Document? For what?  The guy at VW who is going to be tasked with
firing all those programmers who wrote the code that cheated on
the emissions tests is the same one who told them to do it. Of
course, his golden parachute will protect him when he leaves and
unlike the programmers who will find it hard to get new jobs when
they have to explain bring fired, he will be considered a great
asset cause he placed the blame and fixed the problem.

>
> Unfortunately, in the commodity OS world, due to the volume of
> monthly security patches, many Operations shops have adopted a
> "patch-n-pray" philosophy because there is no way the business
> will give the OPS folks the corresponding amount of time to
> re-test important applications.
>
>> Of course, this is all academic as I seriously doubt anyone is
> going
>> to hire me for anything at this point in time.  Unless someone
>> really gets in a bind with their COBOL.  :-)
>>
>> bill
>>
>
> A bit dated, but given the huge amount of Cobol code still
> running many mission critical banking, insurance and similar
> environments, likely still applies today:
> http://www.eweek.com/c/a/Application-Development/Is-COBOL-the-18W
> heeler-of-the-Web
>
> http://www.theinquirer.net/inquirer/news/1432435/cobol-lease-life

Your preaching to the choir.  I still advocate for COBOL when I
stop in at the University for visits.  Academia is famous for never
admitting they made a mistake.  And they never go back to fix a
problem they caused.

Remember when I left the University for a stint doing COBOL for the
Navy in Georgia? (I mentioned it here.) Well, they have gone thru a
number of hiring cycles (including one just about a month ago) since
I left.  Have found no one to hire as a replacement.  They have
decided to stop looking and just let the COBOL continue to run as is.
Well, ti ran before they hired me without a babysitter and it has been
running since mid 2012 when I left so I guess that is an option.  But
what happens when a problem is discovered? (I discovered a major math
error that they had run with for years that affected pretty much all
of the programs.) Or when the compiler vendor makes a change that makes
the programs no longer compile? (Yeah, that happened when I was there,
too!)

>
> Key point is to leverage and sell Cobol integration skills with
> .Net, J2EE and other web integration technologies with the
> philosophy of "upgrade and integrate", not "rip-and-replace".

Don't do .Net or J2EE.  Web integration doesn't require it anyway.
I have written web programs in COBOL.  I converted a broken PHP
program that was used for the Department's High School Programming
Contest into COBOL just as a "proof of concept". (Remember the comment
earlier about the maintainability, or lack thereof, of PHP. A change
in PHP with a new version broke the running script.  The student who
wrote it couldn't figure out what it actually did in order to fix it.
2 students and a professor spent days trying to fix it.  I wrote my
COBOL version in about a half hour.  I wrote a version is Bourne Shell
using awk, which is still running today, in about 15 minutes.

Also as a proof of concept, as they never put them into production, I
made one of the programs in GA generate its reports in HTML so they
could be viewed without wasting alll that paper.

The only place COBOL is dead is academia.  They are already feeling
the pinch from tech/trade schools.  I can see a future (not to
distant)  where they will start teaching things like COBOL and
academia will feel the bite even more.  No one comes out of a trade
school with $100,000 in debt and no prospects for a real job.

Oh, and if you thought all this COBOL stuff is funny, I saw an ad
the other day looking for someone with COBOL experience and RPGII.
That's going to be nearly impossible to fill.  :-)

bill