Y2K, 2038 Unix timeout, IBM5100

M

MEM

Quantum Scribe
I asked the following question to an IBM expert:

“Is much of the infrastructure of the USA run by applications written
for the IBM S/360 machine?”

“Quite probably. In particular, I can say with certainty that the air traffic
system in the US is run on 360-family systems (I belive they're actually IBM
9083s, a version of the 3083, these days, but still software compatible).
Every credit card transaction you make with a Visa, Mastercard, or American
Express card goes through an IBM mainframe. Nearly all of the airline
reservation systems, and a lot of others, run on IBM mainframes. I seem to
recall reading somewhere that well over 90% of the Fortune 500 use IBM
mainframe systems for some portion of their business data processing.

I should mention here that every IBM mainframe built since the introduction
of System/360 is compatible with the 360 instruction set. IBM added many new
architectural features, but they religiously maintained backward
compatibility at the application level.”

IBM 5100

“An imprint of a hook on the outside of the 5100 symbolized the ability of Dubke's interface to drop into what Titor called "legacy code," and scoop out any necessary operating instructions.”
Rochester Magazine, August 2004, Article about John Titor refering to Bob Dubke’s contribution to the unique ability of the IBM 5100

Titor: “The 5100 has the ability to easily translate between the old IBM code, APL, BASIC and (with a few tweaks in 1975) UNIX.”

Titor: “As you are probably aware, UNIX will have a timeout error in 2038 and many of the mainframe systems that ran a large part of the infrastructure were based on very old IBM computer code.”

Titor: “We need the system (IBM 5100) to “debug” various lagacy (sic) computer programs in 2036.”

What does all that mean?

First, old IBM code must mean applications written for the IBM S/360 that run a large part of the infrastructure. It could possibly mean applications written for the S/370 as well. The S/370 was introduced in 1970 and it is possible the 5100 could work with S/370 instructions as well. The S/370 instruction set did not change again until 1982 when addresses were expanded from 24 bits to 31 bits. So we are talking about potentially all applications written for IBM mainframes between 1960 and 1982 + a few years.

Second, the source code must not be available. Otherwise one could simply edit the source code and recompile the application.

Almost all software is distributed to customers as executable, or binary, files. The source code is controlled by the vendor and is not widely distributed. Executable files, on the other had, are stored in numerous customer locations.

The problem with working with executable files is that it contains machine code, like 1001 0101 1000 0000 and one does not know if a “chunk” of data is an instruction, data, or a pointer to data. The computer CPU knows how to handle the instructions but it would be very difficult to reconstruct assembly language or some higher level language from executable code.

How does Unix fit into the picture?

Titor: “As you are probably aware, UNIX will have a timeout error in 2038 …. “

So? Maybe all of the legacy IBM applications that run a large part of the infrastructure operate on Unix machines with the aid of emulators. Why? Because IBM mainframes are not around anymore. Due to events in 2015 and beyond maybe the only computer hardware available runs Unix.

After testing it was determined that fixing the 2038 Unix timeout error caused the legacy IBM applications, operating on Unix platforms with the aid of an emulator, to malfunction. And they need the 5100 with it’s unique abilities to fix the problem.

Titor: “Yes, the Pearl Harbor example relates to Y2K. Have you considered that I might already have accidentally screwed up your worldline?”

Many have used this statement to suggest that Titor was responsible for preventing Y2K on this worldline. But in January 2001 he states, “This worldline and my own are almost exactly alike.” If they are the same then Y2K on his worldline had a similar outcome to the Y2K on this worldline. Then how did he screw up this worldline?

Maybe he is referring to the 2038 Unix timeout error problem. Maybe he accidentally gives too much information to his grandfather in 1975 so that the 2038 Unix timeout error does not cause a problem on this worldline with legacy IBM applications operating on a Unix platform with the aid of an emulator.
 
Yes your expert is right, IBM mainframes run a lot, except on Linux. If a corporation can do more cpu work in smaller square footage, they make more money so you can count on them always dumping their legacy hardware.

There are free open source s/360 emmulators that are 64 bit already. Why not just go back to 2005 and grab the software and go back. Why get a slow bulky artifact that nobody knows how to operate.

The only way I can see Unix fitting into the picture is if it was a hint towards "Caldera" systems (The guys who bought what remains of the Unix copyright).

Even if it's full of half truths, only enough to get someone to listen, so as to give the warning you noticed, then it's gotta be 100% hoax.
 
This is a very interesting topic, so I'd like to have a word there.

You are right newb...

There are free open source s/360 emmulators that are 64 bit already. Why not just go back to 2005 and grab the software and go back. Why get a slow bulky artifact that nobody knows how to operate.
Click to expand...

But consider Y2K being fixed in our worldline using the Legacy code from IBM 5100.

Its not the HARDWARE that is needed to fix Y2K but its the "OLD" Software that is initially used to run the dates that causes the Timeout error.

Again I repeat, it is not the Hardware of IBM 5100 that was needed, but the Software.

So when a TT grabs the 5100 from 1975, he has got to take back up of the Legacy code on CDs which is not possible in 1975, without which there could be a problem. The TT comes to 1998, does every thing for his own good sells the code and travels to 2000 where Y2K was fixed. He returns with the code and the y2k fix. Remember, from the observer's perspective in 2036, he will come back immediately after he left.

So the problem is solved in no time.

Here I am not debating its real, but when coming to this part the story, it becomes very interesting...

Even if it's full of half truths, only enough to get someone to listen, so as to give the warning you noticed, then it's gotta be 100% hoax.
Click to expand...

provided you understood the entire Story.
 
So the problem is solved in no time.
Click to expand...

Interesting. I still lean towards Y2K not being a stranded-on-the-side-of-the-highway kind of problem. The ones who would be hit if we didn't fix anything are the banks & financial sectors. The billing departments of the power stations, not the power delivery systems. When big money is @ risk, the whole world has to take note and scramble to make sure all the rich folks $ is safe.

provided you understood the entire Story.
Click to expand...

Agreed.
 
There are free open source s/360 emmulators that are 64 bit already. Why not just go back to 2005 and grab the software and go back.
Click to expand...

That is the most common response I hear. But one can only run an executable written for the S/360 instruction set on an emulator. If you need to fix a program you must convert machine code to a language first. Why. An executable, or binary, file is just a bunch of 1's and 0's. So for code that looks like: 0010 1011 1110 0101, it is impossible to know if that is an instruction, data, or a pointer (address). You need to convert the machine code to a language to be able to then modify the code. Take a look at these statements by Titor:

Titor: "Titor: “The 5100 has the ability to easily translate between the old IBM code, APL, BASIC and (with a few tweaks in 1975) UNIX.”

Titor: “We need the system (IBM 5100) to “debug” various lagacy (sic) computer programs in 2036.”
 
"But one can only run an executable written for the S/360 instruction set on an emulator."

The 5100 didn't have binary executables. It ran interpreted APL and BASIC. You typed in all the code, 1 line after another and saved it to tape. When you loaded it from tape, you load all the source.

You can get APL & Basic interpreters on other platforms. He could get APL for Windows and type in the source code again.

“The 5100 has the ability to easily translate between the old IBM code, APL, BASIC and (with a few tweaks in 1975) UNIX.”
Click to expand...

That statement itself raises eyebrows. The 5100 could not translate between old IBM code, APL or BASIC. It had a physical TOGGLE SWITCH you had to set and then reboot to choose either APL mode or BASIC mode.

"old IBM code" is not a programming language, neither is "UNIX" so translating between APL and "UNIX" make no sense what-so-ever.
 
The 5100 didn't have binary executables.
Click to expand...

From the Rochester Magazine, August 2004:

According to Bob Dubke, the second engineer on IBM's 5100 team in Rochester, that secret function was his contribution to the design of the computer. The function, which IBM suppressed because of worries about how their competition might use it, was an interface between the assembly code surrounding the computer's ROM exterior, and the 360 emulator hidden beneath it. (IBM declined to comment for this story.) The 5100's emulator gave programmers access to the functions of the monstrous, and much less portable machines, that IBM had produced during the 1960s. An imprint of a hook on the outside of the 5100 symbolized the ability of Dubke's interface to drop into what Titor called "legacy code," and scoop out any necessary operating instructions.

I understand this to mean that the interface can translate between binary instructions for the S/360 instruction set to operating instructions, APL, Basic, or other language compatible with Unix.

"Old IBM code" refers to mainframe applications written for the IBM S/360.

Unix is not a language. From Titor's statement it is apparent he is not a computer "guru." He even admits this in the following post:

February 19, 2001
Titor: "Ahhh…something we have in common. Yes, I felt that way too. However, my job was to go and get it and not debate why they wanted it. I am not a computer expert.

I think he is confused when he says this statement:

“The 5100 has the ability to easily translate between the old IBM code, APL, BASIC and (with a few tweaks in 1975) UNIX.”

He is what I think. Not "I know" or "This is the only interpretation" but what I think:

In 2034, mainframe applications that run much of the infrastructure and written for the S/360 instruction set run on Unix computers with the aid of an emulator. IBM mainframes are not around anymore.

When testing the fix to the 2036 Unix timeout problem it was discovered that the IBM "legacy" applications running on Unix boxes with the aid of an emulator malfunctioned in some way.

The original source code to thse applications were destroyed in 2015. All that is available are the executable files. An IBM5100 is needed to translate "old IBM code", or binary, executable code written for the IBM s/360 instruction set to APL or BASIC, or some language compatible with Unix, like C is now.
 
Ok, maybe he wasn't versed in PC's and just explained it wrong, very possible.

I can guarantee though, that if I had to find a solution for any software problem in 2036, I could do it with free tools and without needing a 5100.
 
I can guarantee though, that if I had to find a solution for any software problem in 2036, I could do it with free tools and without needing a 5100.
Click to expand...

Try it today. Take an executable file on your PC, say Excel or any program of your choice, and convert it to assembly language or a high-level language of your choice. You'll soon find out why you need "something like the IBM 5100 with it's hidden capabilities" to help with the conversion.
 
The original source code to thse applications were destroyed in 2015. All that is available are the executable files. An IBM5100 is needed to translate "old IBM code", or binary, executable code written for the IBM s/360 instruction set to APL or BASIC, or some language compatible with Unix, like C is now.
Click to expand...


Yes but he said he has to fix the timeout error in 2038. Why would he need a translator?
 
Yes but he said he has to fix the timeout error in 2038. Why would he need a translator?
Click to expand...


I don't know but here is what I think (from the original post):

In 2034, mainframe applications that run much of the infrastructure and written for the S/360 instruction set run on Unix computers with the aid of an emulator. IBM mainframes are not around anymore.

When testing the fix to the 2036 Unix timeout problem it was discovered that the IBM "legacy" applications running on Unix boxes with the aid of an emulator malfunctioned in some way.

The original source code to thse applications were destroyed in 2015. All that is available are the executable files. An IBM5100 is needed to translate "old IBM code", or binary, executable code written for the IBM s/360 instruction set to APL or BASIC, or some language compatible with Unix, like C is now.

A translator is needed to convert legacy programs in IBM S/360 executable (binary) files to another language in order to "fix" the legacy programs.
 
Try it today. Take an executable file on your PC, say Excel or any program of your choice, and convert it to assembly language or a high-level language of your choice. You'll soon find out why you need "something like the IBM 5100 with it's hidden capabilities" to help with the conversion.
Click to expand...

A 5100 wouldn't help me at all in that case. I'd want a dissasembler such as SoftICE. But even without a dissasembler, raw assembly isn't much harder than BASIC (especially on limited instruction set from older cpu's), it's just boring - not impossible.
 
I'd want a dissasembler such as SoftICE.
Click to expand...

Does it support the IBM S/360 instruction set?

But even without a dissasembler, raw assembly isn't much harder than BASIC (especially on limited instruction set from older cpu's), it's just boring - not impossible.
Click to expand...

Just to make sure we are talking about the same thing. We are talking about converting machine code 1011 0110 0101 1111 0101 1100 ...... into a higher-level language so that it can be modified.

You will know the instruction set (that's easy) but you do not know if a piece of data, 1011 0110 0101 1111 0101 1100 ...... is an instruction, data, pointer (address), or constant.
 
Does it support the IBM S/360 instruction set?
Click to expand...

No but to be fair, Excel won't run on a S/360 ;-) There are dissasemblers for every architechture though.

It's not raw binary I would have to look at, it's 8 bit numbers. 0->255. Each number, or combinations of numbers, map to assembly instructions. It's not impossible, it would be easier to rewrite the software from scratch IMO. But it's not impossible to fix a piece of S/360 software without a 5100.

Although I think we'd agree it'd be way more "fun" to try a mission like this rather than waiting around for a nerd to fix your code. (And perhaps easier to convince the decision makers as well?)
 
If there are disassemblers for the S/360 instruction set then there would be no need for a 5100, at least based on what I have written. If anyone reading this knows of one please speak up.

Each number, or combinations of numbers, map to assembly instructions.
Click to expand...

Not true. An executable can have instructions, data, and address. That's the problem. If it was only instructions, then yeah, it would be easy. But it's a mix of instructions, data, and addresses.

For example, if the high-level instruction is:

If date > 01/01/2038 then ......

gets converted to assembly language with instructions like:

Load Register A with (some representation of the date)

Compare Register B with Register A

And that gets converted to binary that includes instructions (Load Register A) with data (01/01/2038).
 
Ok yes, I agree its stored in binary and a lot of the operations you can do are binary ops because they are fastest. But the charts that map assembly commands to numbers are mapping them to bytes.

http://www.bixoft.nl/english/opcodes.htm

The assembly instruction LDR (load register I assume, it has 16 registers I think) maps to byte value 28 (hex) or 40 (decimal) or 101000 (binary).

So you could examine the contents of an executable, write out the assembly and play around. Boring, but not impossible.



This site has instructions on how to setup your own os/360 emulator,

http://www.bsp-gmbh.com/turnkey/cookbook/hercules/hercfaq.html

With that opcode chart anyone could make a simple dissasembler in a couple days.
 
With that opcode chart anyone could make a simple dissasembler in a couple days.
Click to expand...

If it's so easy then why would IBM suppress this capability in the 5100?

"The function, which IBM suppressed because of worries about how their competition might use it, was an interface between the assembly code surrounding the computer's ROM exterior, and the 360 emulator hidden beneath it. (IBM declined to comment for this story.) The 5100's emulator gave programmers access to the functions of the monstrous, and much less portable machines, that IBM had produced during the 1960s.

At this link:

http://www.postbulletin.com/magazine/2004/08/index.shtml

If you tell me that technology has changed since 1975 then what specifically has changed that would make it easy to build today but impossible to build in 1975.
 
MEM,

Not true. An executable can have instructions, data, and address. That's the problem. If it was only instructions, then yeah, it would be easy. But it's a mix of instructions, data, and addresses.
Click to expand...
While I will readily admit I am not as knowledgeable about computers as you, let me tell you a true story from my college days that should help you understand that what you claim is difficult is not all that difficult:

While my major back in the early 80s was Aerospace, my roommate and I bought a cocktail table model of the game Space Duel (like asteroids, but color, and you could have two ships linked together). It was based on the old 6502 processor, which was also the basis for Atari PCs at the time. We took on an extra project, which we were given credit for both ARO and ECE classes, to convert this game (it used vector graphics instead of the normal raster graphics) into a color, 3-D engineering drafting/display tool. We were easily able to pull the ROMs, put them into a chip reader, and print out the binary machine code. Along with a a full hardware schematic of the machine and a memory map, we were able to sort out instructions, from addresses, from data. Yes, it was time consuming, but once we discovered the interrupt service routines, all the code fell apart after that. We were even able to retain all the built-in-test functions which were invoked with the flip of a specific switch inside the machine, and simply placed our 3-D drafting code in the same locations that used to hold the game code. We were even able to figure out that we had to fake a CRC stored in the ROM such that it matched the CRC from our added code.

So, if two ARO majors (who just happened to have a fascination for microprocessors and machine code) could pull this off, certainly people with a greater level of experience could crack other binary codes, as long as they have the basic instruction set for the target processor.

RMT
 
Well thank you for that post. I'll have to think, maybe rethink why JT said he needed the 5100.

If it is that easy then you are right, they could have done the same thing in 2036. Or 1975 for that matter. I mean IBM's competition could have done the same thing.

Help me figure this one out. It is a feature of the 5100 that IBM did not want revealed because they were afraid their competition would use it to ..... ?

A hint from an original engineer on the project:

"The function, which IBM suppressed because of worries about how their competition might use it, was an interface between the assembly code surrounding the computer's ROM exterior, and the 360 emulator hidden beneath it. (IBM declined to comment for this story.) The 5100's emulator gave programmers access to the functions of the monstrous, and much less portable machines, that IBM had produced during the 1960s.
 
Hi MEM,
Help me figure this one out. It is a feature of the 5100 that IBM did not want revealed because they were afraid their competition would use it to ..... ?
Click to expand...
Well, just a guess here, but a function like that would make it a lot easier to do what could be done by brute force. Whereas myself and my roommate had a limited set of code that we had to dis-assemble (the Atari computers had 64Kb ROMs, and the Space Duel game code took up much less space than that), if you were going to try to dis-assemble lots of large, complex mainframe-based programs it would take many more people and much more time than it took me and my roommate to do what we did. But the potential to create "pirated" versions of 360 programs (in much the same way that folks in China create pirated versions of MS software today) would have been huge.

"The function, which IBM suppressed because of worries about how their competition might use it, was an interface between the assembly code surrounding the computer's ROM exterior, and the 360 emulator hidden beneath it. (IBM declined to comment for this story.) The 5100's emulator gave programmers access to the functions of the monstrous, and much less portable machines, that IBM had produced during the 1960s."
Click to expand...
The nebulous word in this quote is "interface". What was the physical nature of this interface, and what do they mean by "hidden beneath it"? Hidden beneath WHAT? The ROM is what the machine boots off of, and it is the lowest level of code in the machine. So I would wonder what they meant, in a physical sense, by being "hidden beneath" the ROM. Is it actually PART OF the ROM (rather than "beneath" it)? If so, then my guess might be that it was an unpublished interrupt vector for which there was no hardware device hooked up to trigger that interrupt. However, if someone was programming at the assembly/machine level of the 5100, then they could invoke that vector, and make use of whatever interrupt servicing routines "lived" at that vector. Without a better description of what they mean by "interface", this would be the only guess I would be able to make from my limited understanding of those early HW and OS structures.

That's about the best I can do. Like I say, I know just enough about this stuff to be "dangerous". /ttiforum/images/graemlins/smile.gif

RMT
 
Back
Top