back to article Things I learned from Y2K (pt 87): How to swap a mainframe for Microsoft Access

As the IT world continues to suffer the after-effects of 20-year-old botched Y2K fixes, please take a moment to enjoy a bonus Y2K tale of Microsoft Access 97 taking the place of a mainframe at a particularly paranoid financial institution. Register reader "Jim" was employed in that time-limited role of "Y2K developer" for a …

  1. Anonymous Coward
    Anonymous Coward

    In IT, encrpytion algorithms can't be secret....

    ... so they have to rely on their robustness to cryptographic attacks only.

    1. Loyal Commenter Silver badge

      Re: In IT, encrpytion algorithms can't be secret....

      "Security by obscurity is no security at all"

      See also: Bruce Schneier

    2. Doctor Syntax Silver badge

      Re: In IT, encrpytion algorithms can't be secret....

      Or in this case hardly anything, it seems.

      1. MiguelC Silver badge

        Re: In IT, encrpytion algorithms can't be secret....

        I once took over the development of a property management system for a large bank that relied on - I kid you not - ROT-13 for user's passwords obfuscation....

        1. big_D Silver badge

          Re: In IT, encrpytion algorithms can't be secret....

          Didn't Logitech keyboards use ROT-13 "encryption" for their wireless keyboards for a long time?

        2. David 132 Silver badge

          Re: In IT, encrpytion algorithms can't be secret....

          Golly. Did they at least have the sense to double-encrypt the data using that algorithm, just to make sure?

      2. Anonymous Coward
        Anonymous Coward

        Re: In IT, encrpytion algorithms can't be secret....

        Worked at a mainframe manufacturer that had an internal group create a company wide messaging board app in the 80's.

        And to prove who you were you signed into it with a user id and password. There was a message thread worrying about if the passwords were encrypted well enough. The developers said yes trust us they are encrypted. Trust was in short supply.

        Well I eventually thought to check it out. I worked on the program that read the log file. No problem for me figuring out what files the messaging app used. At our location someone had made a file view program that could look at files in all kinds of encodings, binary, octal, hex, ASCII, FIELDATA...

        So I saved a few copies of the messaging programs file then changed my password a few times and compared the files.

        Hum, the encrypting didn't seem that good. Looked at it a bit then noticed a pattern. It looked like EBCDIC. Hey the file view program even did EBCDIC to so I looked and saw I was right. And then I sent a private message to the developers saying I checked and the encrypting was not encrypting.

        1. phuzz Silver badge

          Re: In IT, encrpytion algorithms can't be secret....

          "And then I sent a private message to the developers saying I checked and the encrypting was not encrypting."

          The correct response would have been to get the developer's password, and post the message from them to everyone else.

          The BoFH response would have been to get the developer's password, and post smut to everyone else.

  2. My-Handle

    The first bit of production software I ever wrote was in Access / VBA. When I was discussing it with a few mates (all IT professionals), one scoffed and said it wasn't a real database (i.e. not SQL, which is what he worked with). I still have a soft spot for it, as it can be a surprisingly effective tool in the right circumstances.

    1. MiguelC Silver badge

      The main problem with Access is that it makes it really easy for users to bypass IT.

      We've had a user who, over the years, moved a lot within the company and that, in every department he was in, he left MS Access apps that all became business critical. Over the years we've been porting them all into our internal platform, but they seem to still keep popping up everywhere!

      1. Captain Scarlet

        Ah ok, often for us its Microsoft Excel Spreadsheets linked to god knows what doing god knows what in macro buttons

        1. Christopher Reeve's Horse

          "The main problem" is perhaps the wrong way of looking at it. If all these Access databases and Excel spreadsheets became business critical then perhaps he was doing entirely the right thing!

          Going the corporate 'full IT' way with these things can be very difficult and challenging, especially without first having proof of concept or working model. Irrespective of whether the model owner and IT bods are in agreement, there's always at least one, or more layers of management level funding decisions to be made in-between.

          1. My-Handle

            I hold my hand up here, the situation was exactly as MiguelC describes. I was that guy, and yes my code did hook in to "god knows what" as CaptainScarlet suggested.

            But... my team was starved of resource. I asked for SQL and was turned down, so I used what tools I had to hand. A year later, the three-month backlog of work for my team had disappeared. The quality of the work we were doing had shot up. I was saving the business something between £200k and £300k in labour costs. And all the while, I was telling upper management that this software was business critical, I was the only one who knew how it worked, and I hadn't been allowed the time to document any of it.

            I left the company after my entire team were made redundant. I had a redundancy date 'pencilled in' and pushed back several months in a row, yet my software was still in active use in several teams. I have no idea what happened to my software after that.

            So Access... yes there are better tools for the job. But it can be damned useful in a pinch. And it was my ladder into proper software development :)

            1. Alan Brown Silver badge

              "I left the company after my entire team were made redundant. I had a redundancy date 'pencilled in' and pushed back several months in a row, yet my software was still in active use in several teams. I have no idea what happened to my software after that."

              You warned them - meaning you discharged your responsibility. What happened after that point isn't your problem or your liability, but I'd make DAMNED sure I kept copies of the correspondence.

            2. ma1010

              This is EXACTLY what happens all the time

              This is SO TRUE. Most companies either have short-sighted management who won't give their workers the IT resources they need to do their jobs, or they've got an IT department that doesn't give a damn about user needs and/or isn't allowed or interested enough to talk to the actual users to see what their needs might be (see government IT).

              So a few skilled individuals do "guerrilla IT" using tools like Excel or Access to try to get their jobs done and get bugger all thanks for it, frequently the opposite for "unauthorized activity." Later, their little projects end up becoming business critical systems, but since the systems were never documented properly, and the creators are retired or were laid off to make room for younger, more malleable, lower-paid employees, it's difficult at best to alter if business needs change.

          2. Claptrap314 Silver badge

            So, are these things in source control? Do they comply with regulatory issues? What access controls are appropriate for the work that they do, and are they in place? Is their function documented?

            I fully agree that enterprise processes can get in the way of getting things working. And skunkworking a POC is a well-honored solution in many cases. But when businesses come to rely on such things, the entire enterprise becomes vulnerable.

            It's all fun and games until the auditor drop by or the knowledgeable person leaves.

          3. Bruce Ordway


            >>a user... moved a lot within the company....left MS Access apps that all became business critical.

            >> perhaps

            Yeah, I'm guilty of this too. I really liked using Access for quickly generating a prototype.

            Unfortunately, some users tended to run off with these and before I knew it, whole departments were relying on the damn things. What's worse, along the way some users learned enough Access skills to be fairly dangerous on their own.

            Over the years I've manged to port only a few of these to the "proper" places. To my horror, there are plenty Access dbs still left. (Management resists allotting hours for fixings things that "already work").

            At least I've learned my lesson. These days I may still use Access for roughing something out but... I would not share the files with anyone.

            1. Alan Brown Silver badge

              Re: Perhaps....

              >> (Management resists allotting hours for fixings things that "already work").

              A couple of "anonymous" hints to the auditors can be handy in such instances

        2. TeeCee Gold badge

          Some of us remember when that held true with "Lotus 123" substituted for "Microsoft Excel".

          1. Bob Carter

            Back in the day I wrote a complete stock control system for a logic card rework line in 123 macros worked well....

        3. Sgt_Oddball

          Oh dear lord....

          I thought I'd finally forgotten the horrors of that sort of tomfoolery.

          Used to just deny all knowledge of Excel (and VBA) so I didn't get roped into that eldritch horror.

          Extra points as it was hooked into an accounts database running a foxpro database that used access to kick it back into life after it would enevitably fall over after hitting its max file limit (all too frequently...).

          For the record this was within the last decade. In the 6+ years since I've left the place I can still see my touches on their website *sigh*, so who knows. The foxpro/excel combo might be still lingering on.

      2. Anonymous Coward
        Anonymous Coward

        What he said

        > The main problem with Access is that it makes it really easy for users to bypass IT.

        I once worked a financial services company whose offshore arm included some people working on the actuarial team who, with justification at least once*, regularly bypassed IT. A PFY in the team came up with some swanky idea based on an Access database. One day the regulators asked some awkward questions the answers to which should have come from that Access database. Only the database turned out to be built on quicksand, and it took a lot of proper development and a regulator threatening to shut the business in 24 hours to dig out of the hole.

        It was such a scare, it made me forbid Access unless there was some over-riding reason that absolutely could not be resolved in any other way.

        Fast forward 10 years or so. The CFO of the company I worked for, pharma this time, took on a PFY, who soon asked for Access. I explained my concerns to the CFO, especially as most of what the PFY was planning could come from the accounting system. He over-rode me and ordered me to produce a copy for the PFY.

        (Have you guessed what's about to happen?) Once I saw what the PFY was doing, I again approached the CFO and suggested he might want to intervene, as the guy was effectively writing his own accounting system. I was told I had a personal grudge against the PFY and had better improve my attitude.

        Then, one fateful day, when the auditors were swarming around the place during some M&A activity, the Access database, as expected started spewing garbage. It took the chief accountant a week of working deep into the night to retrieve the situation, which was more than a mere embarrassment - it was beginning to look like a systematic swindle to the auditors, who said as much.

        The PFY left a few days later.

        1. Fruit and Nutcase Silver badge

          Re: What he said

          "...the auditors, who said as much"

          HP should have retained those auditors to do due diligence on a big acquisition a few years back

        2. paulf

          Re: What he said


          "The PFY left a few days later." Did he really last that long after such a monumental cluster fuck? Did the CFO last that long too? I'm assuming CFO != Chief Accountant.

          And it's interactions like this that you make sure you have in triplicate, including hard copy, ready for the inevitable search for someone to blame investigation: "I explained my concerns to the CFO, especially as most of what the PFY was planning could come from the accounting system. He over-rode me and ordered me to produce a copy for the PFY."

          1. Anonymous Coward
            Anonymous Coward

            Re: What he said

            > Did he really last that long after such a monumental cluster fuck? Did the CFO last that long too? I'm assuming CFO != Chief Accountant.

            Yes, I' m afraid it did. Off he went in his Porsche... No, the CFO didn't last that much longer, I'm pleased to say. He was way out of his depth .

        3. Alan Brown Silver badge

          Re: What he said

          "He over-rode me and ordered me to produce a copy for the PFY.

          ....Once I saw what the PFY was doing...

          ....I was told I had a personal grudge...

 was beginning to look like a systematic swindle to the auditors...

          ....The PFY left a few days later."

          Except it wasn't JUST the PFY who should have left - and with a correspondance trail handed to the auditors, it wouldn't have been.

          That 'CFO' was (and is) a liability to the company.

          1. Anonymous Coward
            Anonymous Coward

            Re: What he said

            > Except it wasn't JUST the PFY who should have left

            Absolutely right. But it seems a common aspect of people in these positions and who cause those types of chaos is an ego that rarely allows them to see they've done anything wrong at all.

      3. John70

        We had a rule in IT, if someone not in IT created an Access database, it wasn't our problem.

        1. Claptrap314 Silver badge

          Which works great until either 1) the other departments start asking out loud what IT is actually doing for them or 2) the whole thing comes crashing down and EVERYONE gets to look for a new job.


      4. Rockets

        This is why where I work we don't deploy Access in our Office deployments. We've been bitten too many times by the rogue user who sets up a small Access DB to do a task which then becomes important. We had a guy working full time for 2 years on converting some these DB's to SQL with front ends for where we couldn't buy a off the shelf package that did the same task.

      5. Twanky

        Really easy to bypass IT

        There are a couple of lessons here:

        1) If the Access user wizard can identify solutions for (in)efficiencies in the various departments he's worked to the extent that his solutions become business critical why didn't the IT management supported him to get the job completed properly? Sounds like a bad case of 'Not Invented Here' to me.

        2) really easy for users to bypass IT Two things here: Who gave the users the tools to bypass IT - if you didn't want them to use Access then why the hell was it installed? And why do the users feel the need to bypass IT? This looks like a failure of IT management to be either helpful or secure.

        And no, insisting that IT call their colleagues in the other departments 'customers' or outsourcing their jobs does not fix any of this - are you listening former Ms 'Service Delivery Manager'?.

    2. big_D Silver badge

      I used to do a lot of prototyping on Access, then create scripts to convert it to Oracle, MySQL or SQLServer, once I had the basic model sorted - the database modelling on Access was a lot better than Oracle, or at least a lot cheaper.

      Later there were some good open source and low-priced tools that did a good job, but back in the early days, Access had its uses.

      1. This post has been deleted by its author

        1. jeffdyer

          I do remember using Access as the table designer for MSSQL backends, until SQL Server Management Studio became more friendly.

    3. Anonymous Coward
      Anonymous Coward

      The problem with Access is it is a file-based database, so all concurrent users need to have physical access to the files - as it happened with dBase and FoxPro. As long as it was accessed locally by a single user, little issues. When it was accessed by multiple users over a file-sharing protocol issues could become more serious, especially on shaky or slow networks (far less common today, a bigger issue years ago).

      The advantage of real RDBMS wasn't much SQL - as most databases after all use their own dialect and it's far less portable than it should (yes, I know the S is for "structured", not "standard") - it was their access over network protocols that ensure far better security and reliability, even on slower networks, with only the server accessing the file storage.

      Not surprisingly, in the article each user got a separate copy of the database.

      1. hmv

        ... and the fact that central databases tend to be backed up with occasional restore testing thrown in. Backing up Access files is ... interesting ... especially if someone never closes it.

      2. Nick Ryan Silver badge

        One of the most disastrous ways to implement MS-Access "applications" was to have the "application" and the "database" in the same damn file. Separate the two and a whole lot of pain suddenly disappeared. It also made it rather more obvious that using MS-Access as a front end into a "real database" was considerably better than relying on file-sharing concurrent access which Microsoft intentionally borked on anything other than Microsoft file servers... damn that was painful getting down to the bottom of.

        1. atheist

          Some of that borking was in the Microsoft client for Netware, causing corrupion in numerous 3rd party databases, regardless of vendor, hosted on Netware file servers.

    4. rcxb Silver badge

      "it can be a surprisingly effective tool in the right circumstances."

      The same can be said of a toilet plunger. Many of us can say we've had to use it at some point, but that's nothing to put on a resume.

      1. My-Handle

        I don't know, it got me my current job. Access / VBA, not the toilet plunger :)

  3. Steve Todd

    Not really a situation in which Access worked

    But I was working for a large American bank who used Access to track their commercial client’s advanced requests for foreign exchange transactions (if they booked the request in advance then the FX desk could arrange better rates).

    The problem was that this was one Access database replicated to multiple foreign branches (because Access databases do NOT work well across a WAN), and every time someone at one branch exited the system in other than a controlled fashion (by crashing, or by simply just turning their PC off for example) then they would break replication at their local branch copy. I had to hold this steaming pile together while a proper solution built around .NET and SQL server was built, and I’ve never forgiven it since.

    1. Anonymous Coward Silver badge

      Re: Not really a situation in which Access worked

      I have a client with similar issues... and they've proposed/contracted/built at least 3 replacements for it in the last 12 years but each time it always gets to the "almost ready to deploy, just a few last tweaks" stage before fizzling out.

      As a result they're still using the monstrosity.

      Unfortunately their 'access guy' has passed away, so I'm left holding the reins :-(

      1. Steve Todd

        Re: Not really a situation in which Access worked

        You have my sympathies. It took rather longer to get a replacement written than I would have liked in my case also (Access, while in some ways being a complete pain in the butt, does give you a lot of functionality out of the box).

    2. Stevie

      Re: Not really a situation in which Access worked

      I like Access a lot. I developed a scad of single-user niftiness using Access 97 and prototyped a megascad more for porting to a network-capable database.

      I think when all is said and done, MS Access is like any other complex piece of software; if it starts showing odd behaviour or odd results it is a pretty good indicator it isn't being used within its designer's specification.

      My personal fave was a system I wrote to fill time and track a code-conversion project I was budgeted to take six months on but actually spent one afternoon writing some SSG (call is perl for Unisys mainframe) and automated the thing so it all ran in less than an hour. Because the worthless bag of smell in charge hadn't requested disc quota, the results all got deleted, so I was forced to run the automation again. And again. I tracked all this on an Access database I wrote, as I said, just to have something interesting to do.

      WBOS mused that it was a pity we had no way of knowing how far along the project was in terms of converted code. I disappeared for about an hour and provided him with a report of exactly what he asked for (a byproduct of mi'Access database). He bemoaned the fact that to be useful it would have to be grouped by one of the subordinate data items. I took the report away for about 30 minutes and brought it back the way he had wished, sighing theatrically, for.

      After that he didn't ask me for anything else. I think I genuinely frightened him with mi'powers.

      Best blade on the swiss army knife? Getting a full command of the combo box events. You can make absolutely gobsmacking proof of concept stuff once you've mastered that little trick.

  4. karlkarl Silver badge

    One thing that could be said is that Office/VBA has had a damn good lifespan. I.e software that was written back then, still can mostly function now. The only other language that seems to offer that is C.

    I wonder when the final bullet will be fired and Microsoft replaces the VB6/VBA component with .NET?

    Or will it? Thinking about it now, I can actually see VB6/VBA outliving the .NET platform!

    1. Steve Todd

      VB6 is long gone (more than 20 years now since Microsoft released a compiler that handled it, and out of support for many years), but VBA is so different to VB.NET that I suspect that they have to keep it for backwards compatibility. The problem is that Office would need to be rewritten into .NET (with the associated slowdowns) in order for a .NET based scripting language to make any sense (in general Win32 apps can only access .NET components if they have been exposed via COM, and these are in the minority)

      1. Ragarath


        Can someone please tell my employer that VB6 is dead? I still have to support it and OCX files, yes welcome to my security nightmare, you may come in!

    2. big_D Silver badge

      We have a number of legacy databases kicking around. The problem is, one is Access 2003 - attached to a truck scale, which can't be migrated to anything newer.

      Then we have another system for Access 2007, which uses features depricated in Access 2013... You have to ensure each application is opened with the correct version of Access, otherwise the newer version will try and auto-convert it and nothing will work and users on the correct version of Access can no longer access it.

    3. Stevie

      The only other language that seems to offer that is C.

      "C" as in "Cobol"?

      Get off my lawn with your pathetic johnny-come-lately 20-year-old programs, sonny!

  5. GlenP Silver badge

    We Still Use Access

    We use Access for a label printing system. it was a relatively simple way of building a set of forms and reports to access SQL data and format the output. If I had to replace it I'm not sure what I'd use now but it would probably end up having to buy something in.

  6. Prst. V.Jeltz Silver badge
    Paris Hilton


    "lost" the algorithm used for password encryption, which meant the whole "give me the second, fifth and eighth character" challenge wasn't going to fly.

    Lets just pretend i know narthing...

    So how does a bank verify your password when you tell them some of it , if the whole thing is encrypted?

    1. mj.jam

      Re: help!

      Assuming encryption not hashing, then the answer is easy. Decrypt the password, check the characters provided, return true/false.

      If hashing, the problem is actually worse. Even if they hash each combination of 3 characters, then any leakage is trivial to brute force. First 3 characters require 64^3 guesses, and then each additional one requires just 64 (assuming your bank actually allows 64 different characters in your password)

      1. Prst. V.Jeltz Silver badge

        Re: help!

        hmm , after a quick google to refresh terms like hash & salt, I assumed all passwords were hashed , but that does lead to the conundrum of "how can they ask for some it"?

        The Guardian explains:

        If a site such as a bank asks you to verify particular characters of your password, rather than enter the whole thing, it is encrypting your password as it must decrypt it and verify individual characters rather than simply match the whole password to a stored hash.

        Encrypted passwords are typically used for second-factor verification, rather than as the primary login factor.

        So a rogue Santander employee could decyrpt everyones passwords and go see where alse they used them. great.

        1. katrinab Silver badge

          Re: help!

          Either way, you effectively have a 3 letter password, and that can be brute forced in miliseconds.

        2. Anonymous Coward
          Anonymous Coward

          Re: help!

          >So a rogue Santander employee could decyrpt everyones passwords and go see where alse they used them. great.

          Not easily. They're deposited in an HSM.

          1. hplasm

            Re: help!

            "Not easily. They're deposited in an HSM."

            Steganography in High School Musical songs?

            (I hoped HSM was long gone... erk! )

          2. Anonymous Coward
            Anonymous Coward

            Re: help!

            It depends how the HSM is configured and how the keys are imported in the HSM: in certain configurations, the keys can easily be exported if one has access to the HSM. I'm on the development side of things (using PKCS 11 to communicate between the software and the HSM) and due to some requirement on the software, the clients using a certain brand of HSM have to leave a few export options available.

        3. Nick Ryan Silver badge

          Re: help!

          Basically it's not secure. However it's bloody annoying and most banks foist this on us because most other banks foist it on us. And they can't all be wrong can they.... [eek]

          Next they'll try using "memorable data" as some form of password...

        4. petef

          Re: help!

          A scam that is used by those who purport to be from your bank is to ask for characters 1, 4 and 6 from your password. Oh I didn't catch that, please give me 2, 3 and 5.

        5. doublelayer Silver badge

          Re: help!

          An alternative method is to store a salted hash for the full password that you and an external attacker would have to provide, plus three randomly-selected characters that they can use to verify you. That does reduce the number of possibilities for an attacker who has both the hashes and those letters, but by far less than a rolling hash or simple encryption.

  7. HatHatHatHatHat

    Access, only second to excel (of course), as a reason why we had global financial crisis.

    1. Christopher Reeve's Horse

      Hey! I can understand some of the hatred for Access, but Excel always seems to be an easy soft target. For all the criticism it gets it actually does a great job for most people in most circumstances.

      As for Access or Excel not being 'proper' solutions, show me an alternative that 'ordinary' people can use without specialist IT training? The difference is ownership. Sure, if I contract out building a custom SQL database to run a particular business model or application, then I expect to need IT professional support to operate it. But show me a consumer level equivalent. Most people have other specialisms and responsibilities beyond being DB admins or system architects. These office level tools just let normal people get on with whatever they need to do. If there was a consumer level 'Office' style implementation of a 'proper' database would this solve more problems, or create more problems?

      1. Mongrel

        I think its just habit, blame MS opposed to whatever combination of budget restraints, bad management, anemic dev budgets or whatever else caused someone to make *their* job easier with a spreadsheet & VB. Then saw that become a pondering monolith, barely strung together with hasty kludges and hand coddled at the end of the month to run the business critical task that the company depends on.

        1. G.Y.


          When I use a Swiss army knife to do a job for a craftsman tool, I don't blame the Swiss army for the resulting debacle

      2. Stork Silver badge

        Completely agree! Excel was the only bit of MS Office I did not actually dislike.

      3. aks

        SQL is not a "proper database" but a collection of similar but different extensions to a basic set of clumsy scripts to access and manipulate utterly different underlying data-storage systems.

        Believe me, I've been there, done that, and have the T-shirt. Writing code to query the provider for its name, version, and locale before knowing which dialect to use in driving it is decidedly non-trivial.

    2. katrinab Silver badge

      The global financial crisis was caused by a wetware failure, not a software failure.

      You can't make a profit by lending to people who can't afford to pay it back, no matter what financial wizardry you perform. Ultimately, the return comes from the people paying back the loans, and if they don't have money, there is no return.

      Adding "on the internet" to a business plan does not guarantee unlimited returns, or indeed any returns at all.

      1. Christopher Reeve's Horse

        Yes, if anything the software enabled the financial wizardry to happen entirely successfully, irrespective of the wetware's ability to understand the consequences for real people in operating in meat-space.

        1. katrinab Silver badge

          The financial wizardry was merely several layers of obfuscation to disguise the fact that the entire thing was underwritten by an unemployed trailer park resident.

      2. Stork Silver badge

        Yep - spoke to a local bank clerk, she had told here manglement that lending on those terms (0.25% spread on Euroibor) made no sense and was going to lose tha bank money. The answer was "shut up and meet your lending target" or words to that effect.

        Good news is we got one of those. Free loan.

      3. Korev Silver badge

        >Adding "on the internet" to a business plan does not guarantee unlimited returns, or indeed any returns at all.

        AI does though...

        1. Cris E

          Amanfromars would like to lend you money!

      4. Anonymous Coward
        Anonymous Coward

        "You can't make a profit by lending to people who can't afford to pay it back, no matter what financial wizardry you perform."

        You can, however, make the situation into a global crisis through the use of exotic financial instruments to multiply and obfuscate the risk.

        1. Anonymous Coward
          Anonymous Coward

          I don't think that's how they described derivatives...but they should have...

  8. Anonymous Coward
    Anonymous Coward

    A System/38 aint no mainframe, boy!

    A System/38 is a larger mini computer. Equivalent proper mainframe of the era would have been a 3090 or maybe a 4343.

    1. TimMaher Silver badge

      Re: A System/38 aint no mainframe, boy!


      I was going to write that.

      People today eh? Cant tell their mainframe from their mini, or their micro.

      Whatever happened to the expression “mid-range” eh?

      Have a pint sized pint. ———->

    2. big_D Silver badge

      Re: A System/38 aint no mainframe, boy!

      Yep, it is a mid-sized mainframe. I used to work on a S/36 and a S/38 as a student on placement at Upjohn's. I had to write some RGP/II and RPG/III to monitor disk DASD usage.

      Our IT director in the 'States is an ex-IBMer and we were talking last week about a VMware machine and he wanted to make the "DASD" bigger on one of the clients.

      1. Steve Todd

        Re: A System/38 aint no mainframe, boy!

        No, it’s a mid to large sized mini. IBM mainframes were descended from the venerable 360 range (which became the 370, which became the 3090, and these days I believe is called the system Z). The S/38 was designed from scratch as a Mini back in about 1978.

        The 3090 (from about the same period) was designed to handle hundreds if not thousands of users. The S/38 would top out at a couple of dozen.

        1. cschneid

          Re: A System/38 aint no mainframe, boy!

          System/360 -> System/370 -> System/390 -> System z -> IBM Z

          My recollection, not backed up by anything, Wikipedia disagrees and I say they're wrong in no small part because they simply redirect System z to IBM Z and retcon the z900 as the latter.

          None of this is helped by the conflation and confluence of architecture names and marketing names.

          System/38 is not a mainframe. A static copy of a database is not a replacement for the source system from which the copy was obtained. I wonder if a copy of the CD was made by any of the staff.

          1. Anonymous Coward
            Anonymous Coward

            Re: A System/38 aint no mainframe, boy!

            Where did the AS/400 fit into this progression?

            Asking for an old QOPERSYS

            1. big_D Silver badge

              Re: A System/38 aint no mainframe, boy!

              Definitely a mini, not a mainframe. I wasn't really using IBM at that point, at least not beyond the desktop. I think it was basically the successor for the S/38 market.

              I remember that we took over a contract for a shipping company and our computer room suddenly started to fill up. We had only a couple of MicroVAX sitting in the corner, with a desk-draw roller unit sized disk array with 4GB of storage (a huge amount of storage back then) and this 4' x 4' x 6' monstrosity with an IBM badge turned up in the server room.

              I asked, what the fsck is that? Oh, it is a disk drive. I looked at the MicroVAX, looked back at the "tower", wow, how many hundreds of gigabytes of storage does it have? :-O Oh, only around 500MB. :-D

    3. keith_w

      Re: A System/38 aint no mainframe, boy!

      aught that not to be a 4341? (or it's baby brother, with the ICA a 4331?

  9. Anonymous Coward
    Anonymous Coward

    Terrific article

    More of this please.

  10. Tim99 Silver badge


    Access applications could be dreadful, particularly when produced by a user to get a job done; but as usual, a bit of thought could produce a useful and stable solution. Access 97 was OK, Access 95 was dreadful. We produced a number of applications for $1million-$10million p.a. organizations. The rough rule was: Always split the application into a front-end (forms, code, and reports); and a back-end (data, relations, and rules/integrity). An Access back-end was usually OK for ~5 concurrent users and 10s of thousands of rows of data on a reliable network - For important data, or more users, or an imperfect network, replacing the back end with an MS SQL Server (V6 at the time) could produce a fast and reliable application. For Y2K we replaced several green screen mini-computer applications with Access/SQL Server systems - Typically a few hundred thousand rows and 20 concurrent users.

    Originally I had been developing applications with traditional Oracle type systems; but after we prototyped something in Access for a customer with the intention of upscaling to a “proper system”, the customer said the prototype works fine so why would you do that?

    We picked up quite a lot of work because most of our competitors were doing what we had been: Big databases with lots of code. Typically our prototyping took a couple of weeks with another week or so to upscale to a Server version. Having said that, the initial learning curve to get around undocumented bugs and performance issues was quite long, but I had been playing Access from version 1 and using version 2 for small systems. One reason that Access was not popular with professional developers was that it required 6-8MB of RAM when many desktops had <=4MB, but we usually quoted to upgrade the punters’ PCs and still came in cheaper than the typical MS VB-SQL/Powerbuilder shops who would quote several months for development time. I’ve been retired for a while, but the company still has many customers using updated applications with the latest versions of Access and SQL Server.

    1. Cris E

      Re: Access

      Around Y2K I did a bunch of Access front ends. At the time the tools available for writing complex clients with lots of forms were some combination of awful, expensive, unreliable and complicated. Our team could knock out an app against a SQL Server back end before a Powerbuilder contractor could be hired or the java guys could decide on struts vs spring.

      1. John Brown (no body) Silver badge

        Re: Access

        "or the java guys could decide on struts vs spring."

        Struts. It's always struts. The more the better or you'll never reach orbit!

  11. Spamfast

    Access? Pah!

    Anyone else remember coding dBase III?

    1. Tim99 Silver badge

      Yes. Generally it was worse, dBase IV was much worse.

      (Edited icon) >>===========>

    2. CAPS LOCK

      dBase III?

      pah, I've got some running code with the signature of dBase II to dBase III conversion. These days it all runs under Harbour Compiler, an open source, cross platform thingy. Highly recommended!

      1. Richard Jones 1

        Re: dBase III?

        I used Quick Basic to capture stream data and format it into DBase data base files. Then Clipper to assemble that into a stream of activity reports back in the days before integrated Office suites. In some cases Lotus 123 was invoked, only to draw graphs, which then loaded word-processing for automatically written letters to be sent to international correspondents. Programs were loaded, used and dropped when down returning control to the main program. This was all back in the times of DOS 3 or thereabouts. In fact some PCs were used to take live data from more than one serial port source, process each stream into reports and send them on their merry way to different operational areas. One was a staffing report that analysed work demands and produced draft 24 hour staffing schemes. You could do a lot of work with a 8088 PC working in 640k of memory.

        Downloading accounts data out of the IBM mainframe reformatting it and auto-loading it into online customer service systems was fun and far faster than a two person manual team achieved. They took 2 weeks and made errors, the machine brought that down to just over two hours, reporting every odd event it found. Those old systems managed what felt like miracles at the time. Of course, they look like rubbish now.

        1. Tim99 Silver badge
          Thumb Up

          Re: dBase III?

          Yes QB was brilliant for data acquisition. We used it on Netware/PC-LAN networks to talk to instruments. About 40 lines of code would open a file, open a serial port, download data to the file, copy the file to a "safe" folder, check that the "safe" file was OK, tell the instrument to delete the data at its end, and then close the serial port. The data file was then used to load data into a database - At the time we often used R:Base as it was about the only SQL compliant DB for the PC. This worked well for about 100 scientists/engineers on about 10 different networks. We could then merge the data into a bigger DB.

    3. SpinkyMuffler

      You young whippersnapper! I remember dBase II. It was all fields you know..... I'll get my coat.

      1. Spamfast

        He-he. And I thought I was old.

        Thanks gramps.

    4. TheRealRoland


    5. Olivier2553

      I think that was dBase (II, III) I used around the end of the 80's to implement the accounting of our non-for-profit organisation: maintain the list of membership, maintain the list of subscribers to our magazine, call for renewals (these were proper letters, the body of the letter extracted from dBase and then formatted in LaTeX and send by snail mail).

      For our couple hundred members, it worked fine enough. I moved abroad in 93 and left my function of treasurer, so I don't know what it became after that.

  12. jmch Silver badge

    bare hands?

    "he destroyed each one, "which really hurt my hands after the first few," "

    Methinks an opportunity lost for some more 'creative' destruction!

    1. Spanners Silver badge

      Re: bare hands?

      'creative' destruction

      1 second in a microwave does them very prettily. more than 2 seconds sets off the fire alarms!

    2. Chloe Cresswell Silver badge

      Re: bare hands?

      Creative spelt "Photonicinducation"? ;)

  13. redwine

    Made a killing

    The accounts software company I worked for at the time sold their Y2K fix to their customers for a fortune; a few lines of shell script as I remember!

  14. Beachrider

    Taking charge of one's OWN decisions...

    If someone converted from 'mainframes' to 'MS Access', they notice an IMMENSE difference in cost and staffing. To have them 'discover' that their decision had unintended outcomes is just... stupid

  15. katrinab Silver badge

    Did the script look anything like this?



    echo "Scanning your files for y2k compliance"


    for i in `find .`; do

    echo $i

    cat $i > /dev/null



    echo $n " files scanned for y2k compliance"

    echo "Warning, your computer is not y2k compliant"

    1. jeffdyer

      Reminds me of a time my firm was looking at taking over a struggling competitor, and their directors came down to sell the deal to us. While running through the back end procedures they showed us a shortcut they just ran to update the database with external data. I asked him to open it just to see what it did, only to find that is was a bomb intended to shut down the database server, rename all the database files and restart the database server, all the while displaying various fragmentation and reconfiguration messages.

      They'd not been paying their developer who decided to get his own back. Needless to say, they deal fell through, and they went bust.

  16. John Arthur


    "which meant the whole "give me the second, fifth and eighth character" challenge wasn't going to fly."

    A: What are the second, fifth and eighth characters of your password?

    B. That will be B, 6 and T

    A. staring at blank screen: Thank you for completing security successfully!

    1. jeffdyer

      Re: Security?

      Surely the simplest solution - after all, the caller could hardly pull money out of the system, could they?

  17. Anonymous Coward
    Anonymous Coward

    Access All Areas - Access powered Internet Banking

    Saw the inside of the embryonic Internet Banking section of large UK finance house around Y2K. Despite it supposedly being an IBM/LOTUS shop there was an amazing MS Office ecosystem of Access databases, Excel Spreadsheets, Word Macros and Mail Merges powered by over 50 Access Databases, including one that ran the dozen or so seats of the Call Centre. Despite it being the essential engine of the company's internet banking department, large chunks were not backed up.

    Put me off internet banking for decades.

  18. Anonymous South African Coward Bronze badge

    Prehistory of our favourite bank, TSB?

  19. Anonymous Coward
    Anonymous Coward

    Still using Access

    My current workplace, a very important body both in my country and for countries around the world, uses a very large access database still, that was written some twenty years ago, before a few of my colleagues were ever born. And you can tell. Still uses the same 8bit color palette, still has a fax field for personal records, into which we put cell numbers. This database is vital for operation and there is a team tasked with essentially curating it enough to keep it going, even now as we move into Windows 10. It doesn't even work that well. I've asked for things to be added to it, I could even write it myself, but nooooo. Haha. Terrible.

  20. StuntMisanthrope

    Code Integer.

    This used to happen all the time within a bank payments department around the turn of the century into the present day. The system is down but the card payments and ATM withdrawals still work. Don’t tell the merchants on punters though. Now it’s it just it’s broken again and nothing works and costs everyone. #spreadsheetville #keepthemusicgoingitsawedding

  21. Captain Obvious

    Count me as one

    Who was tasked at the same time period to help with shutting down permanently an AS/400 and move the data to Access 97 for archival purposes. Things went very smoothly surprisingly...

  22. lowjik


    I have long suspected that all recruitment "consultants" could be replaced with a reasonably simple SELECT query...

    I actually got to prove this many moons ago with my first commission of independent tech work - my then girlfriend (now wife and mother to our first child) had a 'year in industry' job as part of her degree course and was placed at an agency of sorts that provided health related training and they needed a business application to manage job vacancies and applicants.

    I mentioned I could build something for a price - negotiations went well and an Access db was created that essentially had two main tables with a many-to-many relationship that represented applications from applicants to vacancies. It worked, I got paid

    Later it turned out that the owner was .... less than scrupulous (I had my doubts after working even for only a few days) and this resulted in my partner being removed by the University from her placement and no further placements would happen with them - yup that bad

    Anywho fastforward many years later (5?) I got a call on my mobile from an unrecognised number asking for support on this very application at which point I quizzed the person calling (turns out they has swapped cheap labour sources universities) and I politely declined the opportunity to proide support but recommended a check on disk space/old records to be removed - my bad for actually putting my personal mobile in the 'help' dialogue on the app!

    Turns out a simple set of tables and select query can indeed be used as a complete implementation of a recruitment agency!

  23. Earwig

    I've been eating out on Access for the last 20 years, first job was ironically Y2K proofing a shed load of financial apps. It seems that there are a lot of companies with legacy VBA apps of varying quality where the original developer has either left, died of natural causes or took their own life due to desperation.

    It's still a good prototyping and basic database training tool, although it obviously shouldn't be used for heavy crunching or customer facing solutions. When the only tool you have is a hammer, every problem becomes a nail and we have stretched this application further than we should have. If it's a choice between waiting a year for a professionally developed .net solution or knocking up a quick two week bodge job in Access, guess what usually happens? Hence the legacy plague.

    Sort of shot myself in the foot though, as being the last one in the team to leave, have naturally become a key dependancy and therefore am missing out on the current round of juicy redundancies.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon