• _ (unregistered)

    [This comment intentionally left blank]

  • justsomedudette (unregistered)

    So the real challenge of national service is not to kill your supervisor?

    Captcha - vindico, a vindictive directive.

  • (cs)

    But they could use oracle to crunch and massage the data into the correct report format, export it to a flat file as fixed length fields (e.g.: one field consisting of <line-length> columns and one field consisting of CRLF), and have the flat file then "processed" into the final report.

    It'd still be within the imposed rules.

  • Don (unregistered) in reply to snoofle
    snoofle:
    But they could use oracle to crunch and massage the data into the correct report format, export it to a flat file as fixed length fields (e.g.: one field consisting of <line-length> columns and one field consisting of CRLF), and have the flat file then "processed" into the final report.

    It'd still be within the imposed rules.

    I smell a bureaumancer!
  • Jens (unregistered)

    Many? Like about 10 of roughly 50.

  • (cs) in reply to Don
    Don:
    snoofle:
    But they could use oracle to crunch and massage the data into the correct report format, export it to a flat file as fixed length fields (e.g.: one field consisting of <line-length> columns and one field consisting of CRLF), and have the flat file then "processed" into the final report.

    It'd still be within the imposed rules.

    I smell a bureaumancer!
    Bureaumancer ! I love that.

    You just happened to find the almost only character class which is not defined in Rolemaster tabletop RPG. (besides Owl Herder and Yogurt Swimmer)

  • Captcha:abico (unregistered)

    I thought Nordic countries were moderately competent.

  • Andrew (unregistered)

    Obviously, TRWTF is... hey! They didn't mention the programming language this was written in! What a rip off.

  • Peter J. Kootsookos (unregistered)
    50,000 €/year to keep the system from falling over and crushing a passing pedestrian. Since the 1,000 page report was only run once a year, the total bill was a thrifty 500€/page.

    Surely that's cheap: only 50€/page ???

  • (cs) in reply to Peter J. Kootsookos

    Apparently I changed some numbers in one of my edits but didn't redo my math. Corrected for accuracy and basic arithmetic.

  • (cs)

    No direct access to the database is a good idea.

    And there IS some SQL being used in the PL/SQL routine. What you might want is to modify or add a new PL/SQL routine to give you the data you want in its final form, but it isn't a total WTF to not allow direct SQL calls to a database that can have sensitive data on it that you don't wish to allow accses to.

  • (cs) in reply to Don
    Don:
    snoofle:
    But they could use oracle to crunch and massage the data into the correct report format, export it to a flat file as fixed length fields (e.g.: one field consisting of <line-length> columns and one field consisting of CRLF), and have the flat file then "processed" into the final report.

    It'd still be within the imposed rules.

    I smell a bureaumancer!
    As someone who once had to order a $250,000 piece of equipment to swap a $50 part, I am honored, Sir!
  • (cs) in reply to Cbuttius
    Cbuttius:
    No direct access to the database is a good idea.

    And there IS some SQL being used in the PL/SQL routine. What you might want is to modify or add a new PL/SQL routine to give you the data you want in its final form, but it isn't a total WTF to not allow direct SQL calls to a database that can have sensitive data on it that you don't wish to allow accses to.

    I know it's dangerous to assume that any of the colour in the article was in the original, but the reason given in the article was nothing to do with protecting access to the data.
  • (cs)

    I hoped the supervisor would choke on dust and die as he closed the binder...

  • Pentti Hirsmäki (unregistered) in reply to snoofle
    snoofle:
    But they could use oracle to crunch and massage the data into the correct report format, export it to a flat file as fixed length fields (e.g.: one field consisting of <line-length> columns and one field consisting of CRLF), and have the flat file then "processed" into the final report.

    It'd still be within the imposed rules.

    Yes but that would be the smart thing to do, whereas only stupid people and/or drug addicts choose siviilipalvelus. (There's a myth that gay guys do as well but it's pretty obvious they all choose the sausage fest that is Finnish Defense Force.)

  • Migala (unregistered)

    Sampo asked the wrong questions. If instead of finding out how the report was generated, he tried to find out how the data was used, I'm pretty sure he could have saved the finnish taxpayer EUR 50,000 per year. No specifications? Probably shelf-ware.

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered)

    TRWTF is finding out that the pension payments were homosexual.

    そして、サンポさんが散歩をしました

  • Tor Lillqvist (unregistered) in reply to Andrew
    Andrew:
    Obviously, TRWTF is... hey! They didn't mention the programming language this was written in! What a rip off.

    FAS? Somewhat surprisingly, I don't find any original information about FAS as such on the net. http://www.cse.tkk.fi/fi/opinnot/T-106.5800/2009_Autumn-History_of_Programming_Languages/slides/suomi.pdf contains some information (in Finnish, but the code snippet examples might be interesting anyway). As important as that programming language was in government data processing in Finland in the 70s and 80s, one would think somebody would out of historical interest put a manual or something up on the net...

    I used FAS myself when doing my siviilipalvelus in 1983 at the City of Oulu's Department of Health.

  • chris (unregistered) in reply to justsomedudette
    justsomedudette:
    So the real challenge of national service is not to kill your supervisor?
    Clearly it's the Establishment's way of saying "Sooo, PACIFIST, are we? ..."
  • (cs)
    His supervisor reached under his desk and extracted a dusty binder labeled “Treasury Programming Standards Manual: 1976 Edition,” the most recent version of their programming standards. “Due to the highly variable and proprietary nature of database formats, all data-processing will be done in flat-files consisting of fixed-length fields,” he read. “No direct access to databases is permitted.” He closed the binder with a puff of dust. When the cloud cleared, he finished, “And we’re not reimplementing it anyway. Go finish your audit.”

    Well, SQL is a standard since 1986, 10 years after the manual.

    Anyway technically using SQL is not direct acces to database.

  • Todd Lewis (unregistered)

    Honest to Peat, I thought he was going to discover that the ultimate source of the data was... the output of last year's run.

  • (cs) in reply to jnareb
    jnareb:
    His supervisor reached under his desk and extracted a dusty binder labeled “Treasury Programming Standards Manual: 1976 Edition,” the most recent version of their programming standards. “Due to the highly variable and proprietary nature of database formats, all data-processing will be done in flat-files consisting of fixed-length fields,” he read. “No direct access to databases is permitted.” He closed the binder with a puff of dust. When the cloud cleared, he finished, “And we’re not reimplementing it anyway. Go finish your audit.”

    Well, SQL is a standard since 1986, 10 years after the manual.

    Anyway technically using SQL is not direct acces to database.

    You may be pedantically correct, but it's like saying if I stab you, I didn't actually kill you -- it's the cardiorespiratory arrest secondary to exsanguination that killed you.

  • AGray (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    そして、サンポさんが散歩をしました

    I feel it reasonably safe to assume that this came true.

  • (cs) in reply to snoofle
    snoofle:
    export it to a flat file as fixed length fields (e.g.: one field consisting of <line-length> columns and one field consisting of CRLF)

    You know, that's one of those rare situations where XML is usefull. Of course, he'd do better with JSON, CSV, or any other format that is simple, but even XML is better than fixed lenght fields.

  • (cs)

    In Finnish folklore, the Sampo is a mythical device that brings the bearer good fortune. According to one interpretation, it is a millstone that can mill salt, flour, and gold from thin air.

    I think the Sampo in this story is most likely going to be milling a lot of spaghetti and bile, though.

  • (cs) in reply to Mcoder
    Mcoder:
    snoofle:
    export it to a flat file as fixed length fields (e.g.: one field consisting of <line-length> columns and one field consisting of CRLF)

    You know, that's one of those rare situations where XML is usefull.

    Good try.

  • (cs) in reply to nonpartisan
    nonpartisan:
    jnareb:
    His supervisor reached under his desk and extracted a dusty binder labeled “Treasury Programming Standards Manual: 1976 Edition,” the most recent version of their programming standards. “Due to the highly variable and proprietary nature of database formats, all data-processing will be done in flat-files consisting of fixed-length fields,” he read. “No direct access to databases is permitted.” He closed the binder with a puff of dust. When the cloud cleared, he finished, “And we’re not reimplementing it anyway. Go finish your audit.”

    Well, SQL is a standard since 1986, 10 years after the manual.

    Anyway technically using SQL is not direct access to database.

    You may be pedantically correct, but it's like saying if I stab you, I didn't actually kill you -- it's the cardiorespiratory arrest secondary to exsanguination that killed you.

    What is much more important that my tongue-in-cheek pedantry is that highly variable and proprietary nature of database formats is not true any longer. SQL was meant and to larger extent is a solution to this problem. It is an open standard: it is neither highly variable (slightly variable because of extensions to standard etc.) nor proprietary.

  • Zapp Brannigan (unregistered)

    If they changed the print routine to print a blank page after each page of text, they could reduce the cost per page to 25 Euro. If he did that, he should get a bonus.

  • (cs)

    The real WTF is idiots that don't update their programming standards when the times change.

  • ratis (unregistered)

    WTF is this article showing on this site.

  • (cs) in reply to Cbuttius
    Cbuttius:
    No direct access to the database is a good idea.

    And there IS some SQL being used in the PL/SQL routine. What you might want is to modify or add a new PL/SQL routine to give you the data you want in its final form, but it isn't a total WTF to not allow direct SQL calls to a database that can have sensitive data on it that you don't wish to allow accses to.

    Even IF one would want to use a flat file, I'd say it's a better idea to import the flat file into a local(host), temporary database, do all the stuff on it, and then remove the database...

  • Anonymous Hero (unregistered) in reply to justsomedudette
    justsomedudette:
    So the real challenge of national service is not to kill your supervisor?

    That's why they give the task to a conscientious objector - keeps down the murder rate.

  • (cs) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    The real WTF is idiots that don't update their programming standards when the times change.
    Clearly you've never worked in the glass house.
  • (cs) in reply to jnareb
    jnareb:
    Well, SQL is a standard since 1986, 10 years after the manual.

    Anyway technically using SQL is not direct acces to database.

    that's not the point, the point is that they don't want you to have any access to the database at all, not even indirect.

    The database provides you with the data you need to know and that is what you get access to.

    Of course they could get the data received from the master database, import it into SQLite or whatever then process queries using that, but given they have had programs in place to handle the flat files before SQLite came into existence, assuming they work efficiently enough, there is no reason not to use them.

  • (cs)

    This reminds me of the European Union "Celex" database. At some point it was decided that all legal documents produced by the EU must be in a database. The French insisted that only their technology be used, so it was a Groupe Bull setup (basically, all the cast offs from Honeywell*). My company wanted to produce a searchable database of this information on CD-ROM, and updated quarterly. The data could only be provided by the EU on reels of 1/2" mag tape, despite this being 1996 when more compact and reliable tape formats were the norm. We read the data into an otherwise redundant Vax, since it was the only machine we had with a reel to reel mag tape reader. Then we had to parse the data which was in some ISO standard format. Except the French engineers had modified the format, and if the modifications were ever documented then that documentation had been lost. That took some reverse engineering ...

    • In case this comes across as Francophobia, I should point out that the British equivalent of Bull, ICI, was also by that point a dumping ground for bad technology (from Fujitsu). If you've ever had to use a object-oriented database called ODB-II you'll know what I mean.
  • (cs) in reply to jnareb
    jnareb:
    What is much more important that my tongue-in-cheek pedantry is that highly variable and proprietary nature of database formats is not true any longer. SQL was meant and to larger extent is a solution to this problem. It is an open standard: it is neither highly variable (slightly variable because of extensions to standard etc.) nor proprietary.
    Pedanticness aside, what it looks like you're missing is that SQL moved the bar. So giving SQL access is now the same as giving direct access. If I ask a DBA for access to one of our key databases where I can run unfettered SQL queries, he's going to look at me like my head is sideways and backwards and I have five eyeballs, all of different sizes. SQL is now the same as "direct access" to the data.
  • move (unregistered) in reply to Don

    You surely mean a bereuamancer.

  • Jockamo (unregistered)

    The true WTF is that I couldn't finish the article because of all the damn unicorns.

    yes, finish.

    captcha: saluto. i need a drinko

  • (cs) in reply to Todd Lewis
    Todd Lewis:
    Honest to Peat, I thought he was going to discover that the ultimate source of the data was... the output of last year's run.
    That kind of recursion would be too efficient for a government run agency.
  • (cs) in reply to toshir0
    toshir0:
    Bureaumancer ! I love that.

    You just happened to find the almost only character class which is not defined in Rolemaster tabletop RPG. (besides Owl Herder and Yogurt Swimmer)

    The chance is good that all those exist in WFRP, though.

  • um. (unregistered) in reply to nonpartisan

    Last time I looked, all RDBM systems worth their salt also included rather fine-grained controls on what kind of operations and to which data any sql user/role can have access to. GRANT command, anyone? Heck, if you want to really separate things you could even set up another database which only has the needed data, possibly pre-formatted for the spesific applications' needs... like a previous poster suggested with SQLite, actually.

    So, if the system needed a read-only access to a specific subset of the data, asking if you "can run unfettered SQL queries" is also completely unnecessary and off topic. Anyway, as a Finnish taxpayer, I think I'm already somewhat cynically desensitized to the mess that is the IT in our public sector. Coding standards from 1976... I'd like to say "holy shit", but actually, it seems to be par for the course.

  • poogles (unregistered) in reply to Jockamo
    Jockamo:
    The true WTF is that I couldn't finish the article because of all the damn unicorns.

    yes, finish.

    captcha: saluto. i need a drinko

    yoooneekornz!!

  • Orv (unregistered)

    I actually see this as a rather admirable (for 1976) attempt to avoid vendor lock-in, which was a BIG problem with databases at the time. They were essentially all proprietary. Flat files were about the only thing you could guarantee you could interchange, or read in the future if your software vendor went out of business.

    In other words, the problem isn't that the original requirement was unreasonable, it's that they haven't updated it in a reasonable amount of time.

  • qbolec (unregistered) in reply to Todd Lewis
    Todd Lewis:
    Honest to Peat, I thought he was going to discover that the ultimate source of the data was... the output of last year's run.
    Me, too. The story lacks interesting ending, and explanation of the high cost of maintenance. A company using workforce provided by goverment should not pay that much...

    Iusto - I used to care.

  • qbolec (unregistered) in reply to Anonymous Hero

    Brilant.

    I am also disapointed they have not pictured a wooden table somewhere in the process.

  • (cs)

    Wow. These finnish people are funny. No wondering that finland is now bankrupt.

  • (cs) in reply to curtmack
    curtmack:
    In Finnish folklore, the Sampo is a mythical device that brings the bearer good fortune.
    You've got to start using a clearer font or something. IWPTA "brings the beaver good fortune."
  • I don't think it matters (unregistered) in reply to qbolec
    qbolec:
    Brilant.

    I am also disapointed they have not pictured a wooden table somewhere in the process.

    That is actually a valid strategy to transfer data between systems. If all else fails, print it all and use OCR.

  • a random passerby (unregistered) in reply to Don

    The Central Bureaucracy would be proud. He must be Bureaucrat Grade 19, at least.

  • (cs) in reply to da Doctah
    da Doctah:
    IWPTA
    WTF.

Leave a comment on “Finish the Finnish Audit”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article