40-year-old Cobol applications are often extremely well debugged (although anyone who was bit by the Y2K date bug, primarily a Cobol problem, might disagree).
Utter nonsense. The Y2K problem grew out of the extremely high cost of memory and storage, an environment in which the idea of storing the century 30-50 years before Y2K was considered an insane extravagance. When every character of memory cost terribly, and memory and rotating storage were tiny by today's standards, storing only the last two digits of the 4-digit year made perfect sense. If any of today's experts at hindsight had been present back then and had suggested storing 4-digit years, they would have been shown the door in a heartbeat.
The thing to remember about COBOL is that it was developed to solve a specific kind of problems. Today we would call it a Domain-Specific Language. And that kind of problems it solves with relative straightforwardness. Most of the critics I see of COBOL are for trying to use it as a general-purpose language.
I have written two mainframe Web servers. The first was a proof of concept and was written in COBOL. Yes, COBOL parsed the HTTP headers received from the browser and formatted the response, stringing together header fields then the HTTP body, including sending binary graphics.
So much for COBOL only being able to handle simple processing of fixed-field records.
I can't speak for the IBM COBOL world but I can speak for the Wang VS COBOL world and Wang VS mainframes. The VS has optional transaction processing at the OS / file system level. Any indexed file can be initially built or later reorganized to have recovery blocks. Any program that opens such a file will cause the OS automatically to create a BIJ per user of the file. Wang COBOL 74 and 85 both have COMMIT and ROLLBACK verbs. Moreover, the Wang VS transaction system supports committing nested transactions into the higher one or rolling back just the current nested level.
If a program lacking COMMIT/ROLLBACK statements is suddenly given to deal with a soft recoverable file, all the updates it makes will accumulate and will automatically commit when the program successfully completes. If the program is canceled or the system stops, all the changes it made will be rolled back.
When testing software, the ability of the system to roll back changes is not the way it's done in Wang VS systems. It's more efficient to back up the files to be modified, disk-to-disk, and put them back if a rerun is necessary. In many cases the tests are done on a development system or a development partition in a VM environment. In these cases file snapshots are brought into the development environment, where it is just common sense to park copies of them in case the inevitable reruns become necessary.
One of the problems of using tools like COBOL outside the mainframe environment is that you won't have the infrastructure like transaction processing.
In the Wang VS mainframe, now virtualized and running on Dell PowerEdge servers under Linux, we have transaction processing and specific file types at the OS level. The VS OS knows about consecutive files, print files, object files, indexed files, alternate indexed files, relative files, etc. Record-level compression is an option at the OS level and is the default for indexed data files, source files and printfiles. Compressed records are an option for the program or utility that creates a file but are transparent to programs reading a file.
We also have a good 4GL and relational database, PACE. I can create an example customer file in less than five minutes, with a full range of access screen programs, without writing a single line of code.
Perhaps this is a trap for you. I'm sorry about that. I am gracious but pernicious. I asked you a question. You've avoided it so I'll ask it again:
In the end everybody retires. What then?
So... What then? Have you got a plan for that? Your customers deserve a plan.
Sorry. I just didn't get to it in my reply.
I'm not aware of a "retirement problem." We have customers who have no difficulty keeping staffed with programmers, even the one Wang VS Assembler site we know of. There are some sites that have been foolish enough to lay off their VS staffs, but the active and vibrant sites have no trouble retaining and maintaining staff to work with the VS and to program in their preferred languages.
I my self have had no formal training other than a 12-week course on the PDP-1 hardware, which has stood me in good stead. My list of languages is about 30. I learned all of them "on the job," except a couple I invented. I have written two FORTH compilers, one of them self-compiling and with I/O control blocks to solve the troubling problem that the FORTH purists seem to think that I/O streams should go directly into the interpreter/compiler. The concept that a programmer will be helpless in a new language is a rather new one, probably hatched by clueless HR and management people.
No, but the voices reassure me and tell me not to listen to you.
Since I used to work with 4D(http://www.4d.com/), the *easily* most insane development language/toolkit ever made, MY voices reassures me that it's OK not to.
Cool.
I looked at the 4D link but was unable to find anything that simply described it by saying, "4D is..."
I have worked for over 20 years with Wang PACE (Professional Application Creation Environment). PACE is a 4GL and relational database without an SQL interface per se, but with limited SQL in its Host Language Interface that allows using database functionality in several high level languages.
PACE is an exceptionally powerful tool that supports relationships and referential integrity rules in its Data Dictionary, and allows creating default apps at the touch of a button that contain Display, Add, Modify, List, List Add, List Modify, Delete and Query screens that can further be modified by an exquisite screen editor. Complex apps can integrate Host Language Interface (HLI) code either to enhance screen and field functionality or even to completely control the flow between screens and screensets.
Entire straightforward PACE apps can be created, containing many screensets and screens and dealing with many related tables, all without writing a single line of code.
I began working with PACE about 1986. In 1989 I got involved in an Oracle project. I was shocked at how primitive Oracle was compared to PACE. Yes, it had a solid database engine, and yes, it had ad hoc and stored query capability, but it knew nothing about referential integrity unless you had the CASE tool, which faked referential integrity by generation of zillions of triggers in SQL*Forms. Heaven help anyone who tinkered with such forms because they could disrupt referential integrity without realizing it. And heaven help anyone trying, as I did, to build forms from scratch -- it was necessary to figure out and painstakingly write all the forms triggers necessary to accomplish referential integrity.
PACE is still a contender today for rapid development of finished database apps and maintenance thereafter.
The moderator who tagged my post as Flamebait is proof that slashdot is Snob City and that way too much moderation is not done on the basis of content but on the basis of prejudice and clueless vindictiveness.
I have real issues with the generational problem of C being regarded as suitable for business apps and COBOL being demeaned. I've been out there in IT, living with these problems. Here on slashdot they are only words expressing opinions, but out there in the real world IT has real problems and numerous disasters.
And I really did write a mainframe Web server in COBOL 74. I mentioned it because those who don't know COBOL or only have a passing familiarity with it think it can only deal with fixed format records and fields. In fact, COBOL can parse strings and build strings of variable length fields, as is necessary in dealing with HTTP, which has virtually no fixed-length structures.
If C isn't okay for business apps, what do you suggest? Java? Please. C will work just fine.
C was never suitable for writing business apps because it is usually cryptic, offers too many opportunities for fatal errors and oversights, is not well suited to dealing with business data fields, including decimal numbers and doing decimal arithmetic, etc.
In COBOL, and particularly Wang VS COBOL, all data items are typed, conversions between compatible data types are mostly handled seamlessly by COBOL, there are no pointers directly accessible to forget to initialize or to set to an incorrect value, arguments are passed by reference, which is incredibly efficient and allows argument values to be modified and passed back, both the language and machine directly deal with decimal numbers and decimal fractions in ASCII and in packed decimal, the machine has instructions that perform decimal arithmetic on such fields, etc. etc.
Very well then. I am impressed. I had made light of the situation. Your detailed and well thought comment reminds me that one measure of the quality of a tool is its durability. COBOL certainly has that.
Thank you kindly. I'm not accustomed to this kind of response on slashdot. Note that although you may have originally made light, your were not flippant and derisive, which lack will not win you friends on slashdot, but earns my respect.
Another measure of a programming language is the breadth and depth of tools, the utility of the applications developed in it. COBOL has this too as you note.
Yes, at least in the back office, although I should point out that perCOBOL, now seemingly defunct, did offer a COBOL that generated Java object and alowed traditional COBOL app programmers to write servlets and applets. That was an example of how even stodgy tools like COBOL can be moving targets, growing and adapting.
I've also heard it reported that IBM has built so many layers and functionality into CICS to hide its awful nature that IBM mainframe programmers can now write web apps quite easily.
The times have for the most part left mainframes behind. Perhaps these virtualized mainframes you speak of will help bring a wider audience to their appeal.
We hope so. Mainframes in general, of course, are doing much better than most people in IT realize. IBM's mainframe sales figures have been rising in the last decade, not declining.
Our solution is, at least for some, the best of two worlds: we bring forward the exceptionally good Wang VS environment but we package it in a Dell PowerEdge. In the extreme we can put it into a 1U server although we prefer the 2U over that, and the 5U over the 2U because it can have internal tape and removable disk in its 5.25" bays.
Whether 1U, 2U, 5U or the tower alternative, this box is relatively small and efficient compared to legacy Wang VS mainframes which, although they had deskside models, often weighed 600 or 900 lbs and were power hungry.
Our product is 100% seamlessly compatible with all Wang VS software and even with some of the legacy peripherals. Moving up to it involves zero conversion of programs or data. Our New VS is loaded by restoring the legacy VS backup tapes or tansferring the VS volumes disk-to-disk. After some minor configuration tweaking it's up and running and, as one observer commented when asked what he thought, "It's a VS!"
But it's small, reliable, has fault tolerant disk storage and power, supports many more devices that the legacy systems supported and, like a Timex, just keeps on ticking. It also interchanges data with other systems much faster and more readily than the legacy models, and can run as fast as 220% of the speed of the fastest legacy model, the VS18950.
You remind me also that a great well integrated team can make great code and enjoy doing it. Both are important if you would do great things and I admire your achievements.
As I have written elsewhere here, I think that is the most important factor, regardless of language or platform. I spent all of the 1970s and these last four years working in stable, small team environments. I've seen how the production can be 10, 20 or more times that of comparable large-team shops.
In today's IT, though, two factors inhibit this. First is that "modern" management views computer software the same way they view their copying machines: it's not rocket science and people are not important. It is rocket science, and continuity of people is crucial.
Second is that in an environment of ever-changing tools and languages and revolving door staff, the benefits of stable, long-term small team development are just about impossible to realize.
OK then, COBOL is not dead yet.
But I understand that COBOL is habit forming and youths are not ea
I never said they weren't (it should be fairly obvious whose stuff I was working on) because, frankly, I've never even heard of Wang COBOL. Whether its total obscurity is down to the power of Big Blue's marketing department (WWBFATWWTRC) or because Wang are shit is left as an exercise for the reader.
My point was that some COBOLs on some platforms never suffered from IBM's problem of batch OSs forced to mimic interactive systems.
If you've never heard of Wang and Wang COBOL, you're either very young or you've been living in a cave, or both.
Total obscurity: in your limited world, maybe. Millions of other people have had their fingers on Wang keyboards and at least hundreds of thousands have worked with Wang VS systems in programming and operations.
As to exercises left to the reader, aside from that being a dismissive, trite and hackneyed expression, the reader in this case probably doesn't have the information to make that evaluation, can't easily find it, and the two alternatives you offer are both erroneous.
Flash bulletin: Wang Laboratories was built on a foundation of the invention of core memory technology that became adopted by the entire computer industry, was the first to offer affordable calculators, was the first to bring WP to market, was instrumental in bringing affordable DP to small and medium businesses, and was the first to bring digital document imaging to market. Along the way they invented SIMMs and other less visible technological thingies.
The first Wang VS was released in 1977. It was closely patterned after the IBM 360 but with an entirely new and different OS. When IBM went to the 370, Wang adopted many of the new instructions in the Wang VS, which was microcode driven and could change and adapt without hardware changes.
Altogether, Wang pushed about 65,000 Wang VS mainframes out the door. They peaked at a high water mark of about 30,000 systems in the installed base in the mid to late 1980s. Wang VS systems were in every conceivable industry and application. They were on U.S. Navy ships, they were in every U.S. State Dept facility around the world, and they were in every "vertical" in industry. Their decline was a result of bad decisions on Wang's part rather than any weakness in the Wang VS systems or any particular successes of Big Blue marketing.
Here's the interesting part: in 1992 Wang Labs slid into bankruptcy. Every U.S. sales office closed and they lost some of their foreign subsidiaries. While they came out of bankruptcy a year or two later, kept alive by their Wang VS maintenance revenues, there has never again been marketing of the Wang VS, and sales have mostly been of upgrades to existing customers. Wang, the company, moved on to new and different businesses. But the Wang has continued to stay alive as we approach the 16th anniversary of their 1992 bankruptcy filing. Customers evidently like them. They like them because they work and are easy to work with.
There are many Wang VS systems doing work today in commerce and government that were manufactured 20 or more years ago. We just replaced one of the second model made, a 1979 VS100 superceded in 1985, earlier this year. Few systems in the history of computing have been as well engineered or as long-lived as the Wang VS. I have one I got in 1997, built probably in 1992-95, that has never suffered a hardware failure of any kind. That's the rule rather than the exception. CPU and controller failures do occur, but they are rare. The latest Wang VS CPUs were released in 1999 and 2000, before our 2004 virtualization of the VS freed it from its legacy hardware albatross.
Big Blue's marketing had little to do with the decline of the Wang VS or Wang Laboratories. Wang, which peaked at about 35,000 employees sometime in the mid 1980s, was always an IBM wannabe but failed to take note of the practices and policies that helped IBM
Personally, I'm not a big fan of COBOL the language, but there are features in and around the culture and environment of COBOL I'd like to see a lot more of.
Firstly, I'd like to see exactly the attitude towards projects you just expressed. Too many project proposals read like buzzword bingo and are packed full of inappropriate technology complete with flavor of the month fad language constructs (several of which are really very old ideas re-implemented poorly for people who think it's new). They also seem full of all sorts of irrelevant eye candy and featuritus that ultimately take longer than the core logic to implement without contributing anything of substance.
In some ways, the limited options in the old mainframe world forced a focus on appropriateness that's sorely missing these days.
A big one is I would love to see arbitrary precision BCD. IEEE floats and their sloppy handling of precision are a nightmare once you get beyond trivial uses.
Stability over change for the sake of change is another big win.
Indeed. And thank you.
One of the things against which we fight in my Wang mainframe subset of IT is what I might call the corrupting influence of IT fashion trends. Perhaps the greatest of these is the widespread belief that apps have to have GUI. A less focused one is that of being impressed with trendy, sometimes pretty tools and user interfaces. This is more like how people behave in the world of clothing fashion trends than how some of us think people should be behaving in Information Technology, formerly called Data Processing, where we are supposed to be providing our companies with applications that facilitate doing business. I prefer to deal with these IT fashion trend issues head on rather than skirting carefully around them.
The business of business is characters... letters, digits and some special characters. Mainframes and COBOL deal with char information and decimal values exceptionally well. Whether the chars are stored in mainframe indexed files or in a database is really not so important. Typically, businesses have to know who their customers are, what their own products are, have to be able to create and process orders, manage inventory, create invoices, process purchase orders, post various things to journals and general ledger, issue purchase orders, and in more advance EDI environments, process customer purchasing forecasts and deal with inbound and outbound electronic invoices, purchase orders, shipping notifications, etc.
All of that is characters organized into fields, the fields into records (or "rows"), and the records stored in files (or "tables"). GUI has nothing whatsoever to do with that, and all of that can be managed and dealt with without GUI. In the back office GUI doesn't contribute to the management of the company's data. If anything, it slows things down.
The big thing that some in my community have overlooked is that the application itself doesn't need GUI, it just needs to live on a GUI desktop. This is why the dedicated terminals or workstations have given way to emulators running in Windows. The app window may be char-based but more than one can be opened and it supports copy/paste. That's the key. Too many equate a char interface with a dedicated, single-purpose terminal and assume that if the terminal is replaced by a window on a GUI desktop, the app must then have all manner of GUI eye candy. Not so.
Starting in the early 1990s customers in the Wang VS community began to switch from dedicated Wang workstations to PCs with the ability to emulate Wang workstations. Very few surviving Wang VS systems still use dedicated workstations today. Their users work on PCs, usually running Windows, and they do the whole range of the usual PC things as well as having one or more mainframe app windows. They don't have any GUI issues even though the app windows are char-based.
Meanwhile, the preoccupation with trendy languages and tools encourages the creation of ti
It's not screaming at you. Before the adoption of ASCII with upper and lower case, many representations defined only the upper case alphabet and languages like COBOL were created in that era.
The code looks to me like COBOL 85 and looks suspiciously like it might even be Wang VS COBOL 85.
FYI, ten thousand lines of code is tiny in the COBOL world. Many single programs run to ten thousand lines and entire apps for small and medium size businesses typically run to 1-3 million lines.
Wang COBOL 74 and 85 are fully interactive. The difference is that Wang built their mainframe OS to support both interactive and batch from the ground up, whereas IBM was stuck with a batch OS and had to graft thingies onto it to give the appearance of interactive functionality.
Wang COBOL 74 and 85 have a USAGE-IS-DISPLAY working storage construct that provides for full screen composition and even optionally separating the origin and destination variables for screen items. In the procedure division there is a DISPLAY AND READ that throws the screen up on the user workstation and determines which function keys will be active, and reads the variable fields back after the user hits a function key. Error redisplays can alter the field attributes of fields to blink fields in error or that are inconsistent with each other.
This is integrated, not stuff off on the side that has to be separately compiled. If you have an error in a screen definition, the one and only compiler catches it.
In a fast Wang VS in the IDE the turnaround time from editing to compiling to running and back to editing can be just a few seconds. The interactive debugger is stunning. The IDE and debugger support about a dozen languages. Each language beyond Procedure (JCL) and Assembler is a for-pay option that just drops in and then everything else works with it.
One other thing I can't resist: how about a system that knows about file types at the OS level and has an integrated file system that supports multi-indexed files and soft recoverable files (commit / rollback)? An option supports hard recoverable (roll forward) files. No worrying about installing a file system or database, and no worrying about which libraries are present. That's the Wang VS.
Comments like this coming from ppl like you (experienced) are for me a very strong reason to read comments on/.. And your "TFA is a joke." is once again an indication that most of the time only 10 to 25% of an article consists of actual truths.
Thank you. You made my day. Sometimes it seems like posting fact, perspective and/or common sense on slashdot is like pissing into the wind. Your comment affirms that it has value.
Thank you, symbolset. And I respect your opinion but I disagree. There's actually a parallel world thing going on here. You live in one, I live in another.
I started programming just as the minicomputer revolution was breaking out in the early 1960s. I spent some time around the PDP-1, which was used by a major international communication carrier for doing message switching. I worked for a time on the Burroughs B300, a business computer that worked directly with data in the BCD char set, the forerunner of ASCII, and did decimal arithmetic directly on fields of digits. Tools were primitive and I was attracted to building tools.
In the 1970s I personally developed the core communications operating system for a financial information service company, in assembly language, on a proprietary 16-bit minicomputer. I helped them recover from 2% market share in the industry they had invented to over 60% market share. While there I designed and built what may have been the first caching disk controller, wrote numerous neat utilities, and specified what may have been one of the early proto-LANs to interconnect up to 16 of our machines at DMA speed. I also learned the power of small team development where everyone knows their stuff cold and can complete each other's sentences in an environment free of politics.
It wasn't until the mid 1980s that I came to know a certain type of mainframe. I did about 50/50 systems and utility development and business applications, first in compiled BASIC, later in COBOL and a proprietary 4GL/database. That segment of the mainframe world peaked in the mid to late 1980s and began a decline brought on by a combination of overzealous PC weenies and slow movement by all mainframe and mini manufacturers to integrate PC technology.
The user community in which I worked shrank seriously through the 1990s but it wasn't until after Y2K that consulting business began to drop off for me. I switched my attention to a package that allowed moving COBOL apps essentially unchanged to Unix on RS/6000 or HP. The speed was great but there were too many wrinkles, and much of the beloved mainframe environment was missing.
In 2003 I took steps that resulted in the virtualization of my favorite line of mainframes, and in 2004 co-founded two companies to promote the technology. In early 2005 we signed a multi-year contract with the mainframe manufacturer to bring a new, virtualized generation of their systems to market. By that time all their legacy stuff was showing its age and they had nothing to offer their customers as a way forward.
In late 2005 the first of our systems was sold. By then we had settled on the Dell PowerEdge 28x0 machines running Linux and spec'ed out with the fastest Intel CPUs and other parameters. We were able to offer performance 50% greater than the fastest of the legacy mainframe models. In 2006 we adopted the PowerEdge 29x0 machines and faster, better Intel CPU chips and were able to offer twice the performance of the legacy top end. This year we're moving up again and can offer 220% of the legacy top end performance.
Things progressed, and we now have over 60 sites in ten countries, all happy customers, most of the systems being the enterprise processor, a few being subordinate in large conglomerations of multiple platforms, and a few used only for archival storage of and access to data.
It is typical of our customers that they built their own applications over the course of 10, 15, 20, even 25 or more years. The applications do precisely what they want, they are stable and nearly bug free, and they have competent staffs of programmers. Most use COBOL, a few use RPG, and one notable case that has not moved to our technology has apps written entirely in assembly language and 1/10th the processing cost that is standard in their industry.
Our virtualized mainframe is the perfect solution for these folks. It is 100% seamlessly compatible with all their software. No data or programs have to be converted, just moved into the
C is NOT okay for business apps, at least in today's business world.
C was NEVER OK for business apps. Those who thought/still think it was/is have been unfamiliar with solid business programming tools like COBOL.
Time is by far the scarcest resource, and who has time for stupid 80s shit like finding memory leaks and buffer overflows and such?
The funny thing is, we who have been in business programming for a long time have been saying this since C appeared on the business scene. We have never chased memory leaks and buffer overflows. In a proper business system, code and data are in different spaces; code is not modifiable, and so buffer overflows cannot modify code.
The business wants an app that does X, as soon as possible,
I don't know of any businesses that want X. I know of businesses that don't want X or any GUI in the back office. The business of business is characters -- letters and digits and some special characters. Anyone who thinks GUI is a good way to interface with business data has never seen real data entry or inquiry, which would make their heads spin.
Sorry, I wasn't suggesting that anyone and everyone should learn or approach COBOL without reason; I was addressing the mindless ridicule of COBOL, the comments that make it clear that many look down on COBOL and wouldn't want to go near it even with reason, most of them without even understanding it.
COBOL is easy, it lends itself to explanatory naming, and the constructs are rarely cryptic. The mainframes for which COBOL is almost an assembler do decimal arithmetic and implement machine instructions for most COBOL verbs, including the MOVE to an edited numeric that involves formatting the number with things like currency symbol, leading spaces or asterisks, commas, decimal point, etc. The main complaint I have heard from those who have actually worked in COBOL is that it is verbose. That was a more valid complaint in the days of punchcards than it is in the day of editors that make it easy to work with verbose languages.
My first computer was a Bendix G-15D, my second was a CDC 160A, then a PDP-1. Today I still work with a certain kind of mainframe and compiled BASIC in addition to COBOL 74 and 85. Oh yeah, I arranged for the legacy mainframe to be virtualized and run on modern servers, and we have 60 of the new ones installed in ten countries, running all manner of businesses, with more always in the sales pipeline.
We who work with this stuff and actually get the business of business done while consulting weenies propose multilanguage tinkertoys while having no clue about the business, laugh at today's typical project where some of the languages and tools become obsolete before the project is even finished.
I know of a COBOL shop where half a dozen long-term, competent people tend a repository of 50,000 programs that they wrote, 37,000 of which were found to be in active use in a 30-day audit, and where that repository can be drawn on by people who understand both the code and the business to produce new apps in times that would make today's trendy programmers' heads spin.
TFA is a joke. It says more about the organization that owns the code than it does about the language it's written in. Any business programmer reading that they can't modify pay in a reasonable time would conclude that they can't find their way to the bathroom or parking lot, either.
Quite true, but this is Snob City here, so you won't convince anyone, least of all the morons who think C and C++ are suitable for writing business applications. OTOH, I once wrote a mainframe web server in COBOL 74. Anyone who can't get their mind around COBOL is a moron. Anyone who simply doesn't want to is a fool.
Native Spanish speakers know. Educated native Spanish speakers know even better.
It's a myth that all Spanish words ending in 'a' are feminine. 'Programa' is masculine. 'Telegrama' is masculine. I've been told in an advanced Spanish class that all words ending in 'ma' are masculine, but I have some doubts.
What you've found strongly suggests that 'chupacabra' is masculine, hence 'el chupacabra' and 'los chupacabras.' Spanish, although highly regular, has its exceptions, too.
Jam or spoof the RF link? Yeah, right.
False positives? Are you referring to the wireless sensors or the wireless link to alarm.com? In several years of operation we have seen zero problems of any kind with the sensors. As to false positives with the main link, I don't think you have a clue what you're talking about. It's a telemetry link with protocol and data, it's not just some presence/absence of an RF signal.
Billybob might cut the phone line. If that doesn't set off an audible alarm he'll think the coast is clear.
Next we're gonna put in cameras... just for giggles.
The fact that alarm.com systems use a radio link (not a cellphone) and can't easily be cut off was a big plus when I selected the system for an office. I think we laid out about $1800 for the high-end panel but could have saved a lot with the pre-configured smaller panel as we never even installed most of the sensors. We put wireless door sensors on all the doors and wireless motion sensors in all the rooms. If anyone comes in a window they get nabbed by the motion sensor. The system calls us by phone and sends us emails if there is an actual alarm. Non-alarm conditions are logged and we can get notifications of menu-selected events like arming and disarming, so we know who is coming and going. The system can be armed or disarmed through the web interface. Yeah, I'd say it's pretty awesome. We're trying to find the time to try the new integrated video cameras.
Even for what it purports to be it's so far badly done. It's not clear what they mean by 'subimage.' If there are two lions, are they a unit or is each of them a unit or is only one of them a unit? Where is the geometric center of a lion? Somewhere in the chest region, or, as is more intuitive, the center of the face or head? Why do several of the annotation tests show ruins that are NOT pyramids yet the correct annotation is "pyramid?"
I saw 2001 in NYC when it came out. As we entered, a guy was unsuccessfully trying to sell copies of a thin, glossy magazine about the movie. As we left, his pitch had changed to "Explains everything!" I don't recall whether the exit price was higher, but that spoke volumes about the comprehensibility of the movie.
Slashdot Mirror
40-year-old Cobol applications are often extremely well debugged (although anyone who was bit by the Y2K date bug, primarily a Cobol problem, might disagree).
Utter nonsense. The Y2K problem grew out of the extremely high cost of memory and storage, an environment in which the idea of storing the century 30-50 years before Y2K was considered an insane extravagance. When every character of memory cost terribly, and memory and rotating storage were tiny by today's standards, storing only the last two digits of the 4-digit year made perfect sense. If any of today's experts at hindsight had been present back then and had suggested storing 4-digit years, they would have been shown the door in a heartbeat.
The thing to remember about COBOL is that it was developed to solve a specific kind of problems. Today we would call it a Domain-Specific Language. And that kind of problems it solves with relative straightforwardness. Most of the critics I see of COBOL are for trying to use it as a general-purpose language.
I have written two mainframe Web servers. The first was a proof of concept and was written in COBOL. Yes, COBOL parsed the HTTP headers received from the browser and formatted the response, stringing together header fields then the HTTP body, including sending binary graphics.
So much for COBOL only being able to handle simple processing of fixed-field records.
I can't speak for the IBM COBOL world but I can speak for the Wang VS COBOL world and Wang VS mainframes. The VS has optional transaction processing at the OS / file system level. Any indexed file can be initially built or later reorganized to have recovery blocks. Any program that opens such a file will cause the OS automatically to create a BIJ per user of the file. Wang COBOL 74 and 85 both have COMMIT and ROLLBACK verbs. Moreover, the Wang VS transaction system supports committing nested transactions into the higher one or rolling back just the current nested level.
If a program lacking COMMIT/ROLLBACK statements is suddenly given to deal with a soft recoverable file, all the updates it makes will accumulate and will automatically commit when the program successfully completes. If the program is canceled or the system stops, all the changes it made will be rolled back.
When testing software, the ability of the system to roll back changes is not the way it's done in Wang VS systems. It's more efficient to back up the files to be modified, disk-to-disk, and put them back if a rerun is necessary. In many cases the tests are done on a development system or a development partition in a VM environment. In these cases file snapshots are brought into the development environment, where it is just common sense to park copies of them in case the inevitable reruns become necessary.
One of the problems of using tools like COBOL outside the mainframe environment is that you won't have the infrastructure like transaction processing.
In the Wang VS mainframe, now virtualized and running on Dell PowerEdge servers under Linux, we have transaction processing and specific file types at the OS level. The VS OS knows about consecutive files, print files, object files, indexed files, alternate indexed files, relative files, etc. Record-level compression is an option at the OS level and is the default for indexed data files, source files and printfiles. Compressed records are an option for the program or utility that creates a file but are transparent to programs reading a file.
We also have a good 4GL and relational database, PACE. I can create an example customer file in less than five minutes, with a full range of access screen programs, without writing a single line of code.
Perhaps this is a trap for you. I'm sorry about that. I am gracious but pernicious. I asked you a question. You've avoided it so I'll ask it again:
So... What then? Have you got a plan for that? Your customers deserve a plan.
Sorry. I just didn't get to it in my reply.
I'm not aware of a "retirement problem." We have customers who have no difficulty keeping staffed with programmers, even the one Wang VS Assembler site we know of. There are some sites that have been foolish enough to lay off their VS staffs, but the active and vibrant sites have no trouble retaining and maintaining staff to work with the VS and to program in their preferred languages.
I my self have had no formal training other than a 12-week course on the PDP-1 hardware, which has stood me in good stead. My list of languages is about 30. I learned all of them "on the job," except a couple I invented. I have written two FORTH compilers, one of them self-compiling and with I/O control blocks to solve the troubling problem that the FORTH purists seem to think that I/O streams should go directly into the interpreter/compiler. The concept that a programmer will be helpless in a new language is a rather new one, probably hatched by clueless HR and management people.
No, but the voices reassure me and tell me not to listen to you.
Since I used to work with 4D(http://www.4d.com/), the *easily* most insane development language/toolkit ever made, MY voices reassures me that it's OK not to.
Cool.
I looked at the 4D link but was unable to find anything that simply described it by saying, "4D is..."
I have worked for over 20 years with Wang PACE (Professional Application Creation Environment). PACE is a 4GL and relational database without an SQL interface per se, but with limited SQL in its Host Language Interface that allows using database functionality in several high level languages.
PACE is an exceptionally powerful tool that supports relationships and referential integrity rules in its Data Dictionary, and allows creating default apps at the touch of a button that contain Display, Add, Modify, List, List Add, List Modify, Delete and Query screens that can further be modified by an exquisite screen editor. Complex apps can integrate Host Language Interface (HLI) code either to enhance screen and field functionality or even to completely control the flow between screens and screensets.
Entire straightforward PACE apps can be created, containing many screensets and screens and dealing with many related tables, all without writing a single line of code.
I began working with PACE about 1986. In 1989 I got involved in an Oracle project. I was shocked at how primitive Oracle was compared to PACE. Yes, it had a solid database engine, and yes, it had ad hoc and stored query capability, but it knew nothing about referential integrity unless you had the CASE tool, which faked referential integrity by generation of zillions of triggers in SQL*Forms. Heaven help anyone who tinkered with such forms because they could disrupt referential integrity without realizing it. And heaven help anyone trying, as I did, to build forms from scratch -- it was necessary to figure out and painstakingly write all the forms triggers necessary to accomplish referential integrity.
PACE is still a contender today for rapid development of finished database apps and maintenance thereafter.
Re:COBOL. (Score:1, Flamebait)
The moderator who tagged my post as Flamebait is proof that slashdot is Snob City and that way too much moderation is not done on the basis of content but on the basis of prejudice and clueless vindictiveness.
I have real issues with the generational problem of C being regarded as suitable for business apps and COBOL being demeaned. I've been out there in IT, living with these problems. Here on slashdot they are only words expressing opinions, but out there in the real world IT has real problems and numerous disasters.
And I really did write a mainframe Web server in COBOL 74. I mentioned it because those who don't know COBOL or only have a passing familiarity with it think it can only deal with fixed format records and fields. In fact, COBOL can parse strings and build strings of variable length fields, as is necessary in dealing with HTTP, which has virtually no fixed-length structures.
If C isn't okay for business apps, what do you suggest? Java? Please. C will work just fine.
C was never suitable for writing business apps because it is usually cryptic, offers too many opportunities for fatal errors and oversights, is not well suited to dealing with business data fields, including decimal numbers and doing decimal arithmetic, etc.
In COBOL, and particularly Wang VS COBOL, all data items are typed, conversions between compatible data types are mostly handled seamlessly by COBOL, there are no pointers directly accessible to forget to initialize or to set to an incorrect value, arguments are passed by reference, which is incredibly efficient and allows argument values to be modified and passed back, both the language and machine directly deal with decimal numbers and decimal fractions in ASCII and in packed decimal, the machine has instructions that perform decimal arithmetic on such fields, etc. etc.
Very well then. I am impressed. I had made light of the situation. Your detailed and well thought comment reminds me that one measure of the quality of a tool is its durability. COBOL certainly has that.
Thank you kindly. I'm not accustomed to this kind of response on slashdot. Note that although you may have originally made light, your were not flippant and derisive, which lack will not win you friends on slashdot, but earns my respect.
Another measure of a programming language is the breadth and depth of tools, the utility of the applications developed in it. COBOL has this too as you note.
Yes, at least in the back office, although I should point out that perCOBOL, now seemingly defunct, did offer a COBOL that generated Java object and alowed traditional COBOL app programmers to write servlets and applets. That was an example of how even stodgy tools like COBOL can be moving targets, growing and adapting.
I've also heard it reported that IBM has built so many layers and functionality into CICS to hide its awful nature that IBM mainframe programmers can now write web apps quite easily.
The times have for the most part left mainframes behind. Perhaps these virtualized mainframes you speak of will help bring a wider audience to their appeal.
We hope so. Mainframes in general, of course, are doing much better than most people in IT realize. IBM's mainframe sales figures have been rising in the last decade, not declining.
Our solution is, at least for some, the best of two worlds: we bring forward the exceptionally good Wang VS environment but we package it in a Dell PowerEdge. In the extreme we can put it into a 1U server although we prefer the 2U over that, and the 5U over the 2U because it can have internal tape and removable disk in its 5.25" bays.
Whether 1U, 2U, 5U or the tower alternative, this box is relatively small and efficient compared to legacy Wang VS mainframes which, although they had deskside models, often weighed 600 or 900 lbs and were power hungry.
Our product is 100% seamlessly compatible with all Wang VS software and even with some of the legacy peripherals. Moving up to it involves zero conversion of programs or data. Our New VS is loaded by restoring the legacy VS backup tapes or tansferring the VS volumes disk-to-disk. After some minor configuration tweaking it's up and running and, as one observer commented when asked what he thought, "It's a VS!"
But it's small, reliable, has fault tolerant disk storage and power, supports many more devices that the legacy systems supported and, like a Timex, just keeps on ticking. It also interchanges data with other systems much faster and more readily than the legacy models, and can run as fast as 220% of the speed of the fastest legacy model, the VS18950.
You remind me also that a great well integrated team can make great code and enjoy doing it. Both are important if you would do great things and I admire your achievements.
As I have written elsewhere here, I think that is the most important factor, regardless of language or platform. I spent all of the 1970s and these last four years working in stable, small team environments. I've seen how the production can be 10, 20 or more times that of comparable large-team shops.
In today's IT, though, two factors inhibit this. First is that "modern" management views computer software the same way they view their copying machines: it's not rocket science and people are not important. It is rocket science, and continuity of people is crucial.
Second is that in an environment of ever-changing tools and languages and revolving door staff, the benefits of stable, long-term small team development are just about impossible to realize.
OK then, COBOL is not dead yet.
But I understand that COBOL is habit forming and youths are not ea
I never said they weren't (it should be fairly obvious whose stuff I was working on) because, frankly, I've never even heard of Wang COBOL. Whether its total obscurity is down to the power of Big Blue's marketing department (WWBFATWWTRC) or because Wang are shit is left as an exercise for the reader.
My point was that some COBOLs on some platforms never suffered from IBM's problem of batch OSs forced to mimic interactive systems.
If you've never heard of Wang and Wang COBOL, you're either very young or you've been living in a cave, or both.
Total obscurity: in your limited world, maybe. Millions of other people have had their fingers on Wang keyboards and at least hundreds of thousands have worked with Wang VS systems in programming and operations.
As to exercises left to the reader, aside from that being a dismissive, trite and hackneyed expression, the reader in this case probably doesn't have the information to make that evaluation, can't easily find it, and the two alternatives you offer are both erroneous.
Flash bulletin: Wang Laboratories was built on a foundation of the invention of core memory technology that became adopted by the entire computer industry, was the first to offer affordable calculators, was the first to bring WP to market, was instrumental in bringing affordable DP to small and medium businesses, and was the first to bring digital document imaging to market. Along the way they invented SIMMs and other less visible technological thingies.
The first Wang VS was released in 1977. It was closely patterned after the IBM 360 but with an entirely new and different OS. When IBM went to the 370, Wang adopted many of the new instructions in the Wang VS, which was microcode driven and could change and adapt without hardware changes.
Altogether, Wang pushed about 65,000 Wang VS mainframes out the door. They peaked at a high water mark of about 30,000 systems in the installed base in the mid to late 1980s. Wang VS systems were in every conceivable industry and application. They were on U.S. Navy ships, they were in every U.S. State Dept facility around the world, and they were in every "vertical" in industry. Their decline was a result of bad decisions on Wang's part rather than any weakness in the Wang VS systems or any particular successes of Big Blue marketing.
Here's the interesting part: in 1992 Wang Labs slid into bankruptcy. Every U.S. sales office closed and they lost some of their foreign subsidiaries. While they came out of bankruptcy a year or two later, kept alive by their Wang VS maintenance revenues, there has never again been marketing of the Wang VS, and sales have mostly been of upgrades to existing customers. Wang, the company, moved on to new and different businesses. But the Wang has continued to stay alive as we approach the 16th anniversary of their 1992 bankruptcy filing. Customers evidently like them. They like them because they work and are easy to work with.
There are many Wang VS systems doing work today in commerce and government that were manufactured 20 or more years ago. We just replaced one of the second model made, a 1979 VS100 superceded in 1985, earlier this year. Few systems in the history of computing have been as well engineered or as long-lived as the Wang VS. I have one I got in 1997, built probably in 1992-95, that has never suffered a hardware failure of any kind. That's the rule rather than the exception. CPU and controller failures do occur, but they are rare. The latest Wang VS CPUs were released in 1999 and 2000, before our 2004 virtualization of the VS freed it from its legacy hardware albatross.
Big Blue's marketing had little to do with the decline of the Wang VS or Wang Laboratories. Wang, which peaked at about 35,000 employees sometime in the mid 1980s, was always an IBM wannabe but failed to take note of the practices and policies that helped IBM
Personally, I'm not a big fan of COBOL the language, but there are features in and around the culture and environment of COBOL I'd like to see a lot more of.
Firstly, I'd like to see exactly the attitude towards projects you just expressed. Too many project proposals read like buzzword bingo and are packed full of inappropriate technology complete with flavor of the month fad language constructs (several of which are really very old ideas re-implemented poorly for people who think it's new). They also seem full of all sorts of irrelevant eye candy and featuritus that ultimately take longer than the core logic to implement without contributing anything of substance.
In some ways, the limited options in the old mainframe world forced a focus on appropriateness that's sorely missing these days.
A big one is I would love to see arbitrary precision BCD. IEEE floats and their sloppy handling of precision are a nightmare once you get beyond trivial uses.
Stability over change for the sake of change is another big win.
Indeed. And thank you.
One of the things against which we fight in my Wang mainframe subset of IT is what I might call the corrupting influence of IT fashion trends. Perhaps the greatest of these is the widespread belief that apps have to have GUI. A less focused one is that of being impressed with trendy, sometimes pretty tools and user interfaces. This is more like how people behave in the world of clothing fashion trends than how some of us think people should be behaving in Information Technology, formerly called Data Processing, where we are supposed to be providing our companies with applications that facilitate doing business. I prefer to deal with these IT fashion trend issues head on rather than skirting carefully around them.
The business of business is characters... letters, digits and some special characters. Mainframes and COBOL deal with char information and decimal values exceptionally well. Whether the chars are stored in mainframe indexed files or in a database is really not so important. Typically, businesses have to know who their customers are, what their own products are, have to be able to create and process orders, manage inventory, create invoices, process purchase orders, post various things to journals and general ledger, issue purchase orders, and in more advance EDI environments, process customer purchasing forecasts and deal with inbound and outbound electronic invoices, purchase orders, shipping notifications, etc.
All of that is characters organized into fields, the fields into records (or "rows"), and the records stored in files (or "tables"). GUI has nothing whatsoever to do with that, and all of that can be managed and dealt with without GUI. In the back office GUI doesn't contribute to the management of the company's data. If anything, it slows things down.
The big thing that some in my community have overlooked is that the application itself doesn't need GUI, it just needs to live on a GUI desktop. This is why the dedicated terminals or workstations have given way to emulators running in Windows. The app window may be char-based but more than one can be opened and it supports copy/paste. That's the key. Too many equate a char interface with a dedicated, single-purpose terminal and assume that if the terminal is replaced by a window on a GUI desktop, the app must then have all manner of GUI eye candy. Not so.
Starting in the early 1990s customers in the Wang VS community began to switch from dedicated Wang workstations to PCs with the ability to emulate Wang workstations. Very few surviving Wang VS systems still use dedicated workstations today. Their users work on PCs, usually running Windows, and they do the whole range of the usual PC things as well as having one or more mainframe app windows. They don't have any GUI issues even though the app windows are char-based.
Meanwhile, the preoccupation with trendy languages and tools encourages the creation of ti
I suffered no brain damage examining the code.
So you say...
Yes, so I say. Actual working contact with COBOL before the onset of hardening of the opinions confers lifelong immunity.
The code looks to me like COBOL 85 and looks suspiciously like it might even be Wang VS COBOL 85.
I'd say it's because the damage was already done...and those dreams never really go away either, do they? :-)
No, but the voices reassure me and tell me not to listen to you.
It's not screaming at you. Before the adoption of ASCII with upper and lower case, many representations defined only the upper case alphabet and languages like COBOL were created in that era.
The code looks to me like COBOL 85 and looks suspiciously like it might even be Wang VS COBOL 85.
I suffered no brain damage examining the code.
FYI, ten thousand lines of code is tiny in the COBOL world. Many single programs run to ten thousand lines and entire apps for small and medium size businesses typically run to 1-3 million lines.
Wang COBOL 74 and 85 are fully interactive. The difference is that Wang built their mainframe OS to support both interactive and batch from the ground up, whereas IBM was stuck with a batch OS and had to graft thingies onto it to give the appearance of interactive functionality.
Wang COBOL 74 and 85 have a USAGE-IS-DISPLAY working storage construct that provides for full screen composition and even optionally separating the origin and destination variables for screen items. In the procedure division there is a DISPLAY AND READ that throws the screen up on the user workstation and determines which function keys will be active, and reads the variable fields back after the user hits a function key. Error redisplays can alter the field attributes of fields to blink fields in error or that are inconsistent with each other.
This is integrated, not stuff off on the side that has to be separately compiled. If you have an error in a screen definition, the one and only compiler catches it.
In a fast Wang VS in the IDE the turnaround time from editing to compiling to running and back to editing can be just a few seconds. The interactive debugger is stunning. The IDE and debugger support about a dozen languages. Each language beyond Procedure (JCL) and Assembler is a for-pay option that just drops in and then everything else works with it.
One other thing I can't resist: how about a system that knows about file types at the OS level and has an integrated file system that supports multi-indexed files and soft recoverable files (commit / rollback)? An option supports hard recoverable (roll forward) files. No worrying about installing a file system or database, and no worrying about which libraries are present. That's the Wang VS.
Comments like this coming from ppl like you (experienced) are for me a very strong reason to read comments on /.. And your "TFA is a joke." is once again an indication that most of the time only 10 to 25% of an article consists of actual truths.
Thank you. You made my day. Sometimes it seems like posting fact, perspective and/or common sense on slashdot is like pissing into the wind. Your comment affirms that it has value.
Thank you, symbolset. And I respect your opinion but I disagree. There's actually a parallel world thing going on here. You live in one, I live in another.
I started programming just as the minicomputer revolution was breaking out in the early 1960s. I spent some time around the PDP-1, which was used by a major international communication carrier for doing message switching. I worked for a time on the Burroughs B300, a business computer that worked directly with data in the BCD char set, the forerunner of ASCII, and did decimal arithmetic directly on fields of digits. Tools were primitive and I was attracted to building tools.
In the 1970s I personally developed the core communications operating system for a financial information service company, in assembly language, on a proprietary 16-bit minicomputer. I helped them recover from 2% market share in the industry they had invented to over 60% market share. While there I designed and built what may have been the first caching disk controller, wrote numerous neat utilities, and specified what may have been one of the early proto-LANs to interconnect up to 16 of our machines at DMA speed. I also learned the power of small team development where everyone knows their stuff cold and can complete each other's sentences in an environment free of politics.
It wasn't until the mid 1980s that I came to know a certain type of mainframe. I did about 50/50 systems and utility development and business applications, first in compiled BASIC, later in COBOL and a proprietary 4GL/database. That segment of the mainframe world peaked in the mid to late 1980s and began a decline brought on by a combination of overzealous PC weenies and slow movement by all mainframe and mini manufacturers to integrate PC technology.
The user community in which I worked shrank seriously through the 1990s but it wasn't until after Y2K that consulting business began to drop off for me. I switched my attention to a package that allowed moving COBOL apps essentially unchanged to Unix on RS/6000 or HP. The speed was great but there were too many wrinkles, and much of the beloved mainframe environment was missing.
In 2003 I took steps that resulted in the virtualization of my favorite line of mainframes, and in 2004 co-founded two companies to promote the technology. In early 2005 we signed a multi-year contract with the mainframe manufacturer to bring a new, virtualized generation of their systems to market. By that time all their legacy stuff was showing its age and they had nothing to offer their customers as a way forward.
In late 2005 the first of our systems was sold. By then we had settled on the Dell PowerEdge 28x0 machines running Linux and spec'ed out with the fastest Intel CPUs and other parameters. We were able to offer performance 50% greater than the fastest of the legacy mainframe models. In 2006 we adopted the PowerEdge 29x0 machines and faster, better Intel CPU chips and were able to offer twice the performance of the legacy top end. This year we're moving up again and can offer 220% of the legacy top end performance.
Things progressed, and we now have over 60 sites in ten countries, all happy customers, most of the systems being the enterprise processor, a few being subordinate in large conglomerations of multiple platforms, and a few used only for archival storage of and access to data.
It is typical of our customers that they built their own applications over the course of 10, 15, 20, even 25 or more years. The applications do precisely what they want, they are stable and nearly bug free, and they have competent staffs of programmers. Most use COBOL, a few use RPG, and one notable case that has not moved to our technology has apps written entirely in assembly language and 1/10th the processing cost that is standard in their industry.
Our virtualized mainframe is the perfect solution for these folks. It is 100% seamlessly compatible with all their software. No data or programs have to be converted, just moved into the
C is NOT okay for business apps, at least in today's business world.
C was NEVER OK for business apps. Those who thought/still think it was/is have been unfamiliar with solid business programming tools like COBOL.
Time is by far the scarcest resource, and who has time for stupid 80s shit like finding memory leaks and buffer overflows and such?
The funny thing is, we who have been in business programming for a long time have been saying this since C appeared on the business scene. We have never chased memory leaks and buffer overflows. In a proper business system, code and data are in different spaces; code is not modifiable, and so buffer overflows cannot modify code.
The business wants an app that does X, as soon as possible,
I don't know of any businesses that want X. I know of businesses that don't want X or any GUI in the back office. The business of business is characters -- letters and digits and some special characters. Anyone who thinks GUI is a good way to interface with business data has never seen real data entry or inquiry, which would make their heads spin.
Thank you. You demonstrate my point.
Sorry, I wasn't suggesting that anyone and everyone should learn or approach COBOL without reason; I was addressing the mindless ridicule of COBOL, the comments that make it clear that many look down on COBOL and wouldn't want to go near it even with reason, most of them without even understanding it.
COBOL is easy, it lends itself to explanatory naming, and the constructs are rarely cryptic. The mainframes for which COBOL is almost an assembler do decimal arithmetic and implement machine instructions for most COBOL verbs, including the MOVE to an edited numeric that involves formatting the number with things like currency symbol, leading spaces or asterisks, commas, decimal point, etc. The main complaint I have heard from those who have actually worked in COBOL is that it is verbose. That was a more valid complaint in the days of punchcards than it is in the day of editors that make it easy to work with verbose languages.
My first computer was a Bendix G-15D, my second was a CDC 160A, then a PDP-1. Today I still work with a certain kind of mainframe and compiled BASIC in addition to COBOL 74 and 85. Oh yeah, I arranged for the legacy mainframe to be virtualized and run on modern servers, and we have 60 of the new ones installed in ten countries, running all manner of businesses, with more always in the sales pipeline.
We who work with this stuff and actually get the business of business done while consulting weenies propose multilanguage tinkertoys while having no clue about the business, laugh at today's typical project where some of the languages and tools become obsolete before the project is even finished.
I know of a COBOL shop where half a dozen long-term, competent people tend a repository of 50,000 programs that they wrote, 37,000 of which were found to be in active use in a 30-day audit, and where that repository can be drawn on by people who understand both the code and the business to produce new apps in times that would make today's trendy programmers' heads spin.
TFA is a joke. It says more about the organization that owns the code than it does about the language it's written in. Any business programmer reading that they can't modify pay in a reasonable time would conclude that they can't find their way to the bathroom or parking lot, either.
Quite true, but this is Snob City here, so you won't convince anyone, least of all the morons who think C and C++ are suitable for writing business applications. OTOH, I once wrote a mainframe web server in COBOL 74. Anyone who can't get their mind around COBOL is a moron. Anyone who simply doesn't want to is a fool.
Native Spanish speakers know. Educated native Spanish speakers know even better. It's a myth that all Spanish words ending in 'a' are feminine. 'Programa' is masculine. 'Telegrama' is masculine. I've been told in an advanced Spanish class that all words ending in 'ma' are masculine, but I have some doubts. What you've found strongly suggests that 'chupacabra' is masculine, hence 'el chupacabra' and 'los chupacabras.' Spanish, although highly regular, has its exceptions, too.
Jam or spoof the RF link? Yeah, right. False positives? Are you referring to the wireless sensors or the wireless link to alarm.com? In several years of operation we have seen zero problems of any kind with the sensors. As to false positives with the main link, I don't think you have a clue what you're talking about. It's a telemetry link with protocol and data, it's not just some presence/absence of an RF signal. Billybob might cut the phone line. If that doesn't set off an audible alarm he'll think the coast is clear. Next we're gonna put in cameras... just for giggles.
The fact that alarm.com systems use a radio link (not a cellphone) and can't easily be cut off was a big plus when I selected the system for an office. I think we laid out about $1800 for the high-end panel but could have saved a lot with the pre-configured smaller panel as we never even installed most of the sensors. We put wireless door sensors on all the doors and wireless motion sensors in all the rooms. If anyone comes in a window they get nabbed by the motion sensor. The system calls us by phone and sends us emails if there is an actual alarm. Non-alarm conditions are logged and we can get notifications of menu-selected events like arming and disarming, so we know who is coming and going. The system can be armed or disarmed through the web interface. Yeah, I'd say it's pretty awesome. We're trying to find the time to try the new integrated video cameras.
Even for what it purports to be it's so far badly done. It's not clear what they mean by 'subimage.' If there are two lions, are they a unit or is each of them a unit or is only one of them a unit? Where is the geometric center of a lion? Somewhere in the chest region, or, as is more intuitive, the center of the face or head? Why do several of the annotation tests show ruins that are NOT pyramids yet the correct annotation is "pyramid?"
I saw 2001 in NYC when it came out. As we entered, a guy was unsuccessfully trying to sell copies of a thin, glossy magazine about the movie. As we left, his pitch had changed to "Explains everything!" I don't recall whether the exit price was higher, but that spoke volumes about the comprehensibility of the movie.