AKA: We want to be the only ones who can spy on *our* citizens - and these bozos will not sign a reciprocity of data collection with us (5 eyes and all).
Obviously a disgruntled and inexperienced mainframe user - sorry:-(
And yes, for a customer, I rewrote (from a hex dump) an old ASM routine that they'd lost the source for - simply so I could make it 64bit safe.
However, one does not need to go through CICS to compile a COBOL program - though your shop may have created a CICS transaction to do compiles.
As for IDEs, if you don't have ISPF and plugins for most of that, complain to your management! My first IDE was emacs (BSD 4.2) with functions to compile and point me at all the compiler messages.
As far as Java/AJAX/REST/XML/... yes there are still some rough edges - after all, these are, by and large, bolted on very old (and stable) code.
That was supposed to be ADA but, at the time, compiler technology was not upto snuff - so things like: * Loop pre-conditions * Loop invariants * Loop pst-conditions
Just were not validated.
But yeah, you obviously have never tried to reconstruct the logic of a 65K+ line long COBOL program:-(
The problem is the language is COBOL. Programmers should learn Hexadecimal and Binary (machine level code) and then go into application layer programming from there, but that is neither cool or trendy.
I learned Assembly fairly early on, and I would agree that, once knowing how the machine operates, it is much easier to express what you want in any higher level language (neglecting things like synchronization points) - even OO constructs often boil down to simple things - calling by pointer. I still write vastly more C than C++ code.
I have read more hex dumps than many extant programmers (long before IPCS), and can still read many opcodes (ld, st,...) - but I would not recommend starting at that level. Assembly and/or (restricted) C code fulfill the requisite learning objectives nicely enough.
However, this is not a path to a feature rich resume (lacking in super models).
AFAIK there are still no viruses on MVS & VM systems. TPF and CICS still function wonderfully there is just a huge price to get into the game with a mainframe system vs. PC/minicomputers.
Well, when was the last time you spent some quality time perusing the micro-fiche PL/X listings for MVS (doubt they still exist for z/OS) ? The barrier for entry is quite high here... for the nonce !
Joe random hacker isn't going to easily get access to a z/OS (or z/VM) image to start inspecting object files for issues
> I've had to resort to using FORTRAN to C converters several times, mainly to turn code written by scientists into something useful in a product. It was ALWAYS worth the effort!
Really ? Do you not understand the largest difference in FORTAN and all other current languages ?
In many applications, the difference may not be noticable, but in many mathematical cores, the transformation is fatal !
FORTRAN stores arrays in Column major order, whereas nearly everyone else stores them in Row major order.
This difference can be the difference betwixt high order page/cache/tlb misses, and running/scaling smoothly
Patently false... Last I checked there were still more lines of COBOL in business and government than all the other languages, combined.
I'll grant the fact that new comers don't want to get their hands dirty... they want something that enhances the resume for the next job... Something we see with all the 'legacy languages'.
I played vanguard during the stupid Y2K false apocalypse - writing superviser level code to track storage from a date field all the way through a program, in order to generate a report saying 'This field is a data, or is based upon a date value'.
I don't plan on doing updating that code for the Y2038 issue, but I fully expect COBOL & PL/I to still be in wide use at that time
It is simply not practical in the normative case, especially if you're looking for a resultant code suite that &language_du_jour jockey can read and maintain.
As noted above (AC, sorry - fscked up), modern COBOL has many of the flaws of other major languages (even pointers, &diety forbid).
The control flow of old COBOL programs is horrendous (I've seen > 65K line, monolithic programs), where a C++ guy would do a metric crap-tonne of 20+ line functions.
COBOL PERFORM flow is covered by a (5, maybe 4) way return function - optimization under patent. It drives optimizer folk bat-shit crazy (as if they weren't already there):-)
I have also seen an inordinate amount of old and new programmers who fail to grasp the power of the COBOL I/O system - and pay dearly in runtime costs because they chose the wrong file organization...
Really, have we learned nothing from ANDF (https://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format) ?
I actually started down this path, but got side tracked by earning a living wage.
The idea was to take a PL/I and Ada basis as an IL, and provide language based decoder/encoder - so one could achieve idiomatic code in any Source->Source translation.
Interesting yes, lucrative - kinda... There are companies that make their living doing this... but the bugaboo is in the details, especially with PL/I deriviatives and the macro processor.
The article explains what ANDF is, but it doesn't say what was wrong with it. What was wrong with ANDF?
That is a very good question. The quest for an UNCOL (http://en.wikipedia.org/wiki/UNCOL) goes back to the mid 1950s.
A terse, but readable history/background upto and including early ANDF (http://homepage.ntlworld.com/michael.harley/uncol.html) This paper seems to argue that a change in relative costs betwixt machines and programmers changed the landscape to where the complexity was not worth doing a true UNCOL.
Things changed from complexity to business politics, much like we see now with cell carriers (and lockin), customers wanted to be able to move work from one vendor to another, and up sprang another organization to guide that - the OSF (http://en.wikipedia.org/wiki/Open_Software_Foundation)
A changing playing field (enter MS and Apple) and business politics seemed to doom OSF and most of its work - as it turned to 'every man for himself' until Linux came into being and pretty much changed everything... How many vendors still have their own Unix ?
I've been playing in this industry since the mid 1970s, professionally since the early 1980s - most all with a bent towards compilers and operating systems.
My reading of the tea leaves entails a re-birth of the UNCOL idea - and again, due to changing relative man/machine costs, and the prevalence of the IoT.
I believe we actually wind up with the ANDF variant of UNCOL * You compile language du-jour (with whatever optimization, say to SSA, you can do at a high level), and generate a distribution package (apk, deb, rpm) that includes the UNCOL instead of binaries. * At install time, the UNCOL is compiled to native (for some definition of native) code... This too, should be optimized
This is where Android is already moving - ART vs Davlik. On smaller devices, you don't want the interpretation overhead unless you have a scheme to handle JiT and building up a native application as the various codepaths are exercised.
Today, we have fewer architectures to contend with (x64, arm, ppc), a better battering ram (open source/crowd source & funding) - ie, driving from the correct side.
This still requires effort by the hardware business to create the UNCOL->Native binary
You seem to only recall on of the possible definitions (granted the most common, and the one the government would like to use against whistleblowers):
From WordNet (r) 3.0 (2006) [wn]:
treason
n 1: a crime that undermines the offender's government [syn:
{treason}, {high treason}, {lese majesty}]
2: disloyalty by virtue of subversive behavior [syn: {treason},
{subversiveness}, {traitorousness}]
3: an act of deliberate betrayal [syn: {treachery}, {betrayal},
{treason}, {perfidy}]
The other two do, in some ways, describe the NSA & FISA
I'll grant iMessage, and the current Google Hangouts -- neither have an option for 'otr' type functionality (yet, in the latter case).
gtalk did have 'otr' (not sure if it was as secure as BBM), and I routinely ran 'otr' plugins on XMPP (including gtalk), and even SameTime
the otr plugins likely matches BBM - with symmetric encryption
The problem with setting up a secure IM is the setup effort can reduce the number of folks using it. otr was actually pretty simple, but things like pgp require users to setup and distribute keys... Something a lot of non-tech people just wont do
Real men use calcium-carbide... a few rocks in a small chamber, add water... wait a few seconds for the gass to build & click the barbeque ligher:)
Just be *very* careful with miss-fires... I set the cannon down & the lighter hit the patio as I was openning the chamber (it took a while for the beard & eyebrow to grow back on that side of my face):)
At ~ 1(us)$ / pound, a cheap and fun way to waste an afternoon...
In the 70's we use tin soda/beer cans (taped ~6 together end-to-end), put a small hole in the end and applied a liberal dose of lighter fluid to the inside, then we stuffed a tennis ball as far down as we could. Then one applied flame to the hole and watched as the tennis ball shot several blocks away !
I learned the hard way to not fire these like a rifle... I held it against my shoulder for better aim and when lit, the ball went one way, and I the other:)
You get the key from public keyservers, not the same place (though the key is also stored in the tarball)... Or you get the key by request to sendmail.org (sent PGP signed - by a key again you get from a public keyserver).
Then, you store the key in your private keyring so you'll no longer have to trust the public keyservers.
Next, when you get the announcement letter for a new release, you download the source/sig files and compare the MD5sums with whats in the announcement letters... IFF that passes, you make sure the signature file is valid.
You store the validated md5sums & signature along with the source package so it can be verified by any builder.
All this is quite trivial and easily automated ! [11:31:44 cowboy@badlands:sendmail-8.12.6 565:0]$ debian/rules verify # Verifying the md5 summs and signed files Checking MD5 source:./sendmail.8.12.6.tar.md5. Checking signature file./sendmail.8.12.6.tar.sig. gpg: Signature made Mon Aug 26 22:06:30 2002 EDT using RSA key ID 678C0A03 gpg: Good signature from "Sendmail Signing Key/2002 "
Check out the 'recent' mod in the netfilter Patch-O-Matic... the newest version looks like it provides the feature you're looking for (I'm looking to do the same thing; open 113 after a connection on 25/6667)
Slashdot Mirror
Indeed !
AKA: We want to be the only ones who can spy on *our* citizens - and these bozos will not sign a reciprocity of data collection with us (5 eyes and all).
COBOL is not your average Algol deriviative !
I'll grant the the 80-20% rule likely applies..
But things like Sequential vs Relative vs Indexed I/O, BCD (packed & zoned), multi-return option on PERFORM, etc...
I'd be more comfortable saying 'mediocre' instead of 'proficient'
Obviously a disgruntled and inexperienced mainframe user - sorry :-(
And yes, for a customer, I rewrote (from a hex dump) an old ASM routine that they'd lost the source for - simply so I could make it 64bit safe.
However, one does not need to go through CICS to compile a COBOL program - though your shop may have created a CICS transaction to do compiles.
As for IDEs, if you don't have ISPF and plugins for most of that, complain to your management! My first IDE was emacs (BSD 4.2) with functions to compile and point me at all the compiler messages.
As far as Java/AJAX/REST/XML/... yes there are still some rough edges - after all, these are, by and large, bolted on very old (and stable) code.
You owe me a new monitor :-)
APL/SV VS/APL, APL/2, or the new fangled ASCII keyboard friendly J ?
If you're game, I'll do the RTE hookup (I/O, BCD, ...)
I wrote the APL/SV -> APL/2 )MCOPY command ... ah the joys of EXCP level I/O :-)
Program by contract, anyone ?
That was supposed to be ADA but, at the time, compiler technology was not upto snuff - so things like:
* Loop pre-conditions
* Loop invariants
* Loop pst-conditions
Just were not validated.
But yeah, you obviously have never tried to reconstruct the logic of a 65K+ line long COBOL program :-(
They are learning COBOL
(ftfy).
The problem is the language is COBOL. Programmers should learn Hexadecimal and Binary (machine level code) and then go into application layer programming from there, but that is neither cool or trendy.
I learned Assembly fairly early on, and I would agree that, once knowing how the machine operates, it is much easier to express what you want in any higher level language (neglecting things like synchronization points) - even OO constructs often boil down to simple things - calling by pointer. I still write vastly more C than C++ code.
I have read more hex dumps than many extant programmers (long before IPCS), and can still read many opcodes (ld, st, ...) - but I would not recommend starting at that level. Assembly and/or (restricted) C code fulfill the requisite learning objectives nicely enough.
However, this is not a path to a feature rich resume (lacking in super models).
AFAIK there are still no viruses on MVS & VM systems. TPF and CICS still function wonderfully there is just a huge price to get into the game with a mainframe system vs. PC/minicomputers.
Well, when was the last time you spent some quality time perusing the micro-fiche PL/X listings for MVS (doubt they still exist for z/OS) ?
The barrier for entry is quite high here... for the nonce !
Joe random hacker isn't going to easily get access to a z/OS (or z/VM) image to start inspecting object files for issues
> I've had to resort to using FORTRAN to C converters several times, mainly to turn code written by scientists into something useful in a product. It was ALWAYS worth the effort!
Really ? Do you not understand the largest difference in FORTAN and all other current languages ?
In many applications, the difference may not be noticable, but in many mathematical cores, the transformation is fatal !
FORTRAN stores arrays in Column major order, whereas nearly everyone else stores them in Row major order.
This difference can be the difference betwixt high order page/cache/tlb misses, and running/scaling smoothly
Patently false... Last I checked there were still more lines of COBOL in business and government than all the other languages, combined.
I'll grant the fact that new comers don't want to get their hands dirty... they want something that enhances the resume for the next job... Something we see with all the 'legacy languages'.
I played vanguard during the stupid Y2K false apocalypse - writing superviser level code to track storage from a date field all the way through a program, in order to generate a report saying 'This field is a data, or is based upon a date value'.
I don't plan on doing updating that code for the Y2038 issue, but I fully expect COBOL & PL/I to still be in wide use at that time
See comment above wrt ANDF
It is simply not practical in the normative case, especially if you're looking for a resultant code suite that &language_du_jour jockey can read and maintain.
Full agreement, on most all accounts !
As noted above (AC, sorry - fscked up), modern COBOL has many of the flaws of other major languages (even pointers, &diety forbid).
The control flow of old COBOL programs is horrendous (I've seen > 65K line, monolithic programs), where a C++ guy would do a metric crap-tonne of 20+ line functions.
COBOL PERFORM flow is covered by a (5, maybe 4) way return function - optimization under patent. It drives optimizer folk bat-shit crazy (as if they weren't already there) :-)
I have also seen an inordinate amount of old and new programmers who fail to grasp the power of the COBOL I/O system - and pay dearly in runtime costs because they chose the wrong file organization...
Really, have we learned nothing from ANDF (https://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format) ?
I actually started down this path, but got side tracked by earning a living wage.
The idea was to take a PL/I and Ada basis as an IL, and provide language based decoder/encoder - so one could achieve idiomatic code in any Source->Source translation.
Interesting yes, lucrative - kinda... There are companies that make their living doing this... but the bugaboo is in the details, especially with PL/I deriviatives and the macro processor.
Yes, according identity relationships, n / n == 1.
But, as I mentioned above, APL is the only language I am aware of that got this correct.
Please don't forget that dividing by zero is *not* always zero (or, simply, undefined) !
Anything divided by itself is one - something most everything but APL gets incorrect :-(
The article explains what ANDF is, but it doesn't say what was wrong with it. What was wrong with ANDF?
That is a very good question. The quest for an UNCOL (http://en.wikipedia.org/wiki/UNCOL) goes back to the mid 1950s.
A terse, but readable history/background upto and including early ANDF (http://homepage.ntlworld.com/michael.harley/uncol.html) This paper seems to argue that a change in relative costs betwixt machines and programmers changed the landscape to where the complexity was not worth doing a true UNCOL.
Things changed from complexity to business politics, much like we see now with cell carriers (and lockin), customers wanted to be able to move work from one vendor to another, and up sprang another organization to guide that - the OSF (http://en.wikipedia.org/wiki/Open_Software_Foundation)
A changing playing field (enter MS and Apple) and business politics seemed to doom OSF and most of its work - as it turned to 'every man for himself' until Linux came into being and pretty much changed everything... How many vendors still have their own Unix ?
I've been playing in this industry since the mid 1970s, professionally since the early 1980s - most all with a bent towards compilers and operating systems.
My reading of the tea leaves entails a re-birth of the UNCOL idea - and again, due to changing relative man/machine costs, and the prevalence of the IoT.
I believe we actually wind up with the ANDF variant of UNCOL
* You compile language du-jour (with whatever optimization, say to SSA, you can do at a high level), and generate a distribution package (apk, deb, rpm) that includes the UNCOL instead of binaries.
* At install time, the UNCOL is compiled to native (for some definition of native) code... This too, should be optimized
This is where Android is already moving - ART vs Davlik. On smaller devices, you don't want the interpretation overhead unless you have a scheme to handle JiT and building up a native application as the various codepaths are exercised.
Today, we have fewer architectures to contend with (x64, arm, ppc), a better battering ram (open source/crowd source & funding) - ie, driving from the correct side.
This still requires effort by the hardware business to create the UNCOL->Native binary
Those who don't remember the past are doomed to repeat it...
http://en.wikipedia.org/wiki/A... (one of the earlier UNCOL)
I'll go back to my cave now
Bouvier's Law Dictionary, of course, only has the 1st definition, in somewhat more detail
You seem to only recall on of the possible definitions (granted the most common, and the one the government would like to use against whistleblowers):
From WordNet (r) 3.0 (2006) [wn]:
treason
n 1: a crime that undermines the offender's government [syn:
{treason}, {high treason}, {lese majesty}]
2: disloyalty by virtue of subversive behavior [syn: {treason},
{subversiveness}, {traitorousness}]
3: an act of deliberate betrayal [syn: {treachery}, {betrayal},
{treason}, {perfidy}]
The other two do, in some ways, describe the NSA & FISA
This is just one amongst the plethora of reasons I install openWRT on linksys and (some) belkin devices.
I'll grant iMessage, and the current Google Hangouts -- neither have an option for 'otr' type functionality (yet, in the latter case).
gtalk did have 'otr' (not sure if it was as secure as BBM), and I routinely ran 'otr' plugins on XMPP (including gtalk), and even SameTime
the otr plugins likely matches BBM - with symmetric encryption
The problem with setting up a secure IM is the setup effort can reduce the number of folks using it. otr was actually pretty simple, but things like pgp require users to setup and distribute keys... Something a lot of non-tech people just wont do
If not, it should at least limit the number of users to those who *must* communicate to a Blackberry device.
Otherwise, 'tis just another small player in the plethora of contenders for IM tools
Real men use calcium-carbide... a few rocks in a small chamber, add water... wait a few seconds for the gass to build & click the barbeque ligher :)
:)
Just be *very* careful with miss-fires... I set the cannon down & the lighter hit the patio as I was openning the chamber (it took a while for the beard & eyebrow to grow back on that side of my face)
At ~ 1(us)$ / pound, a cheap and fun way to waste an afternoon...
90's... come on !
:)
In the 70's we use tin soda/beer cans (taped ~6 together end-to-end), put a small hole in the end and applied a liberal dose of lighter fluid to the inside, then we stuffed a tennis ball as far down as we could. Then one applied flame to the hole and watched as the tennis ball shot several blocks away !
I learned the hard way to not fire these like a rifle... I held it against my shoulder for better aim and when lit, the ball went one way, and I the other
You get the key from public keyservers, not the
./sendmail.8.12.6.tar.md5. ./sendmail.8.12.6.tar.sig.
same place (though the key is also stored in
the tarball)... Or you get the key by request
to sendmail.org (sent PGP signed - by a key again
you get from a public keyserver).
Then, you store the key in your private keyring so
you'll no longer have to trust the public keyservers.
Next, when you get the announcement letter for a new release, you download the source/sig files and
compare the MD5sums with whats in the announcement
letters... IFF that passes, you make sure the signature file is valid.
You store the validated md5sums & signature along
with the source package so it can be verified by
any builder.
All this is quite trivial and easily automated !
[11:31:44 cowboy@badlands:sendmail-8.12.6 565:0]$ debian/rules verify
# Verifying the md5 summs and signed files
Checking MD5 source:
Checking signature file
gpg: Signature made Mon Aug 26 22:06:30 2002 EDT using RSA key ID 678C0A03
gpg: Good signature from "Sendmail Signing Key/2002 "
Check out the 'recent' mod in the netfilter Patch-O-Matic... the newest version looks like it provides the feature you're looking for (I'm looking to do the same thing; open 113 after a connection on 25/6667)
What cypher are you using ?
I've seen dramatic speedups by putting this
in $HOME/.ssh/config:
Host *
Cipher blowfish
It is *much* faster than the default (3DES)