The Technology Vent and Rant Thread

[Katsunami]

I've just connected my main backup drive to the TPM-less desktop and unlocked it. Now it just works. The desktops data disc is synchronizing at the external drive's maximum speed of 125 MB/s.

So, it seems...
- Something went wrong with the file system on that backup drive yesterday.
- You don't need a TPM to unlock drives that have been encrypted with Bitlocker ToGo and a password. (Obviously you need a TPM if you want to encrypt your boot drive, as it has to be unlocked using the decryption key before Windows boots.)

[Greg Anos]

This will be meaningless to any non-mainframe programmer, but. . .

I had to back out a change. The change worked perfectly, but the user didn't bother to do the testing with the applications who used the modified output file. One of them choked on it. . .

So I had to "back it out" (in the parlance of mainframes). I did so, and repaired (brought back to the previous standard), the data that caused the problem. Standard mainframe PITA.

However. . .

The back out procedure didn't back out the source code for the change out of the automated code library. So I had to go in and change the source code back.

Which meant I had to do all the documentation for another change. Which I did, explaining that the original change had been backed out and I was backing out the source code.

I get to the QA review, and the QA idiot couldn't figure out what I was saying.

Where were the code change results for the before and after data test? (There was no before and after! This was a code back out!)

Why didn't I show the code changes between Production and Test? (There weren't any. I was <backing out> the changes!!)

Why was I comparing Prod data to Prod data? (Because there were no data changed. I was showing a regression test to <show there were no data changing!!!>, you blithering idiot!!!!)

I <had> written up exactly what I was doing, and why, in the documentation. The moron said nobody could glean what I was doing, from my explanation. (Gee, nobody knows what backing out a change means, with full explanation as to why, and that there would be no changing data, because the code was not changing from the existing production? Arrgh!!!!!)

So I had to add several more paragraphs to explain, in a "Run, Spot, Run" manner, what a back out meant, and how I did actually run a test with the new source against the Production source (Which was exactly the same. I had already included a comparison between the two sources, showing they were identical. ), and that the Regression test was actually the Test vs Prod; it was placed as a regression test because there were no source changes and therefore no data changes to any data. (The purpose of a regression test is to show that no data, other that what was supposed to be changed, was changed. No code change, no data change, you only <have> a regression test anyways. . . (Bloody h*ll, I've seen smarter goldfish )

Then, and only then, would that idiot sign off. . .

[PeterT]

Originally Posted by Ralph Sir Edward

This will be meaningless to any non-mainframe programmer, but. . .

I had to back out a change. The change worked perfectly, but the user didn't bother to do the testing with the applications who used the modified output file. One of them choked on it. . .

So I had to "back it out" (in the parlance of mainframes). I did so, and repaired (brought back to the previous standard), the data that caused the problem. Standard mainframe PITA.

However. . .

The back out procedure didn't back out the source code for the change out of the automated code library. So I had to go in and change the source code back.

Which meant I had to do all the documentation for another change. Which I did, explaining that the original change had been backed out and I was backing out the source code.

I get to the QA review, and the QA idiot couldn't figure out what I was saying.

Where were the code change results for the before and after data test? (There was no before and after! This was a code back out!)

Why didn't I show the code changes between Production and Test? (There weren't any. I was <backing out> the changes!!)

Why was I comparing Prod data to Prod data? (Because there were no data changed. I was showing a regression test to <show there were no data changing!!!>, you blithering idiot!!!!)

I <had> written up exactly what I was doing, and why, in the documentation. The moron said nobody could glean what I was doing, from my explanation. (Gee, nobody knows what backing out a change means, with full explanation as to why, and that there would be no changing data, because the code was not changing from the existing production? Arrgh!!!!!)

So I had to add several more paragraphs to explain, in a "Run, Spot, Run" manner, what a back out meant, and how I did actually run a test with the new source against the Production source (Which was exactly the same. I had already included a comparison between the two sources, showing they were identical. ), and that the Regression test was actually the Test vs Prod; it was placed as a regression test because there were no source changes and therefore no data changes to any data. (The purpose of a regression test is to show that no data, other that what was supposed to be changed, was changed. No code change, no data change, you only <have> a regression test anyways. . . (Bloody h*ll, I've seen smarter goldfish )

Then, and only then, would that idiot sign off. . .

You couldn't just restore the load library?

[Greg Anos]

Originally Posted by PeterT

You couldn't just restore the load library?

Load and source are separate in the mainframe world. it's a compiled world, not interactive.

The load was restored. But the now <bad> source was still in the source lib, as a "land mine" for the next person who changed the program. . .

[Terisa de morgan]

Originally Posted by Ralph Sir Edward

Load and source are separate in the mainframe world. it's a compiled world, not interactive.

The good compiled world

[Greg Anos]

Originally Posted by Terisa de morgan

The good compiled world

Bueno y gracias, Sennora. (My keyboard does not have a tilde over the n, so I have to fall back on the old Spanish usage of the double n instead. . . (bows politely))

[badgoodDeb]

Ahh yes - familiar with that sort of thing here. Fortunately we don't have that many hoops to jump through. I just store a new version in the code repository, that matches version-2 and we're good to go. No sign offs; just a cessation of wailing and complaints.

[Terisa de morgan]

Good for you, now I have to give support to a code I haven't seen

[Greg Anos]

Originally Posted by Terisa de morgan

Good for you, now I have to give support to a code I haven't seen

Good luck. Been there before myself. . .

[DMcCunney]

Originally Posted by Ralph Sir Edward

This will be meaningless to any non-mainframe programmer, but. . .

This is not unique to the mainframe world. I see similar instances all over.

What was the host language for the program? What are you using as a code repository?

Backing out the change in the repository should not result in a land mine. A backed out change shouldn't be presented to the compiler if someone does another build.

I assume you properly commented the commit statement that specified why you backed out the change...

What I get from this talke of woe is that the user couldn't be bothered to test, and the QA analyst is an idiot. Again, not at all unique to mainframes.
______
Dennis

[DMcCunney]

Originally Posted by Ralph Sir Edward

Load and source are separate in the mainframe world. it's a compiled world, not interactive.

Load and source are separate in the non-compiled world.

The difference between mainframes and what I think Peter is referring to is the use of libraries. Most code is not monolithic, and the code the programmer writes will link against external libraries to get functions not in the programmer's code. But the code the programmer writes often expects to link against a specific version of an external library. If that's not present in the default library location, chaos ensues. (The joys of needing to set the LOAD_LIBRARY_PATH variable in the environment of a Linux program to get it to link agianst the proper version and successfully run... )

The load was restored. But the now <bad> source was still in the source lib, as a "land mine" for the next person who changed the program. . .

See my earlier question about what repository was used. This shouldn't be an issue. If it is, there are other problems.
______
Dennis

[DMcCunney]

Originally Posted by Katsunami

I've just connected my main backup drive to the TPM-less desktop and unlocked it. Now it just works. The desktops data disc is synchronizing at the external drive's maximum speed of 125 MB/s.

So, it seems...
- Something went wrong with the file system on that backup drive yesterday.
- You don't need a TPM to unlock drives that have been encrypted with Bitlocker ToGo and a password. (Obviously you need a TPM if you want to encrypt your boot drive, as it has to be unlocked using the decryption key before Windows boots.)

Glad to hear you got is sorted, but since I assume the backup drive is on your premises, under your control, why did you feel the need to encrypt it? Under what circumstances might someone else get access to it and read it?

(An old friend a few years back was playing with Windows full disk encryption, and managed to lock himself out of his main system. He managed to restore order, but his wife was seriously considering finding somewhere else to stay for a few days while he got it sorted out because he was not fit to be around while he tried to solve the problem. Speaking personally, I wouldn't have chosen the boot drive on my main system as the one to use to experiment with full disk encryption...)

Here, data is backed up to USB thumb drives, and I feel no need for encryption. I live in a multi-unit dwelling with a front desk. The only way anyone gets anything of my machine is sitting down at the keyboard. If they can do that, I've got bigger problems than computer security.
______
Dennis

[Greg Anos]

Sigh. . . I said it wouldn't mean anything to a non-mainframe programmer.

There are no repositories (as you think of repositories) in the mainframe world. At least not in the dinosaur world.

I are a COBOL programmer.

There are library systems. They are all third party applications. The shop can use any of them (or none of them). Any connection between the executable and the source is strictly a manual setup. If it is set up well, the set of jobs used to back out the executable can also call the library system and back out the source. The shop I'm in is. . . ahem. . . not well set up. Running one of the library systems is a high paid gig (6 figures). I don't do that.

This structure dates back to the 1960's. . .

[Greg Anos]

Originally Posted by DMcCunney

Glad to hear you got is sorted, but since I assume the backup drive is on your premises, under your control, why did you feel the need to encrypt it? Under what circumstances might someone else get access to it and read it?

(An old friend a few years back was playing with Windows full disk encryption, and managed to lock himself out of his main system. He managed to restore order, but his wife was seriously considering finding somewhere else to stay for a few days while he got it sorted out because he was not fit to be around while he tried to solve the problem. Speaking personally, I wouldn't have chosen the boot drive on my main system as the one to use to experiment with full disk encryption...)

Here, data is backed up to USB thumb drives, and I feel no need for encryption. I live in a multi-unit dwelling with a front desk. The only way anyone gets anything of my machine is sitting down at the keyboard. If they can do that, I've got bigger problems than computer security.
______
Dennis

The data is in a sealed silo, thousands of kilometers from where I am. I'd have to get a pass from God to get in. The mainframe world has security like Cheyenne Mountain used to have. . .

Separate off-site back up systems, disaster recovery system, and an army of auditors to make certain the rules are followed.

It's a whole different world from the client/server or cloud.

But it pays well.

(These are the systems that settle Wall Street transactions, most bank transactions, and are the backbone of credit card transactions. I was once on -call for a system that clears 2-3 Trillion USD - a day!)

[DMcCunney]

Originally Posted by Ralph Sir Edward

The data is in a sealed silo, thousands of kilometers from where I am. I'd have to get a pass from God to get in. The mainframe world has security like Cheyenne Mountain used to have. . .

I was in the mainframe worlds decades ago, and am aware of practices. But that question was posed to Katsunami, not you, so it's not clear why you answered it.
______
Dennis