Known problem with Operations Console when upgrading to 7.1
When upgrading a 6.1 version of IBM i Access for Windows to 7.1, there is a known problem which causes the existing 6.1 Operations Console configurations to be lost. This problem only affects the Operations Console configurations which exist on 6.1 IBM i Access for Windows prior to the upgrade to 7.1.
This problem may be resolved by either of the following ways:
Apply 6.1 service pack SI41053 or later. Then start Operations Console which performs a necessary migration. Then you may upgrade to 7.1 at any time.
Known problem with Operations Console and Windows NT and Microsoft security update
If you use Windows NT with Operations Console with either of the following configurations:
local console directly attached to the system
local console directly attached with remote access allowed
then the installation of Microsoft security update Q823803 may prevent future connections and the creation or change of existing configurations. Microsoft has a hot fix available, hotfix KB823803, that may be installed to correct this issue. Contact Microsoft directly to obtain this hotfix. Refer to the Microsoft web site(link resides outside of ibm.com) for details.
Known problem with Operations Console and Windows 2000 Service Pack 4
A problem with Operations Console when using Service Pack 4 for Microsoft Windows 2000 is documented in APAR SE11182. Microsoft resolved this problem with a hotfix. It is documented in Microsoft knowledge base article 824301(link resides outside of ibm.com). Contact Microsoft to obtain this fix.
Summary of IBM i Access for Windows – Operations Console support
Windows 2000
Windows XP
Windows Vista
Windows 7
7.1
(1)
LAN
LAN
LAN
6.1
LAN,Async
LAN,Async
LAN
LAN(2)
V5R4
LAN,Async
LAN,Async
LAN (3)
(1)
V5R3 (out of service)
LAN,Async
LAN,Async
(1)
(1)
LAN – supports a LAN connection
Async – supports a local console directly attached to the system
(1) – This version of “IBM i Access for Windows” is not supported on this version of Windows.
The operating system underlies everything that happens on our PC
When we use a PC, we’re usually only concerned with the program we’re currently using, whether it’s a browser, a word processor or our preferred social networking app. We don’t often think about the rather extensive program underlying everything that happens on the PC: its operating system.
We can fire off the name of our chosen OS at the drop of a hat (Windows 7, Chromium or Ubuntu, for example), but could we say just what it is and what it does?
When we think of an operating system at all, it’s usually to help define what our PC is – 2.66GHz Core 2 Duo, 4GB RAM, 256GB SSD, Windows 7, for example. It’s almost like a physical peripheral; something we could swap for a similar substitute in the future.
And until now, the operating system defined a PC just like the hardware. We’ve grown up with large, all-encompassing operating systems that provided a wealth of services, but that might be on the cusp of changing.
Let’s start by considering what a PC is. It’s a collection of hardware: the motherboard, CPU, memory chips, video adaptor, hard disk (or SSD), optical drive, keyboard, mouse, screen and so on. Each of those pieces of hardware is, in essence, interchangeable with others that perform the same functionality, but perhaps faster, more efficiently or more compactly.
With a desktop machine, you can pretty much replace the whole PC a bit at a time by upgrading each component. The modular nature of PCs sometimes seems almost miraculous (it’s certainly not the case for cars – I can’t just decide to pop a Ford engine into my Audi, for example) and it’s only possible because the operating system smooths over any differences between components and hides them from us, usually through the use of specially written drivers.
In the beginning
Let’s approach what an operating system does by considering what happens when you boot your PC. Pressing the power switch starts up a small program that’s stored in read-only memory – a chip on the PC’s motherboard.
This program, known as the BIOS (basic input/output system) on PCs and EFI (extensible firmware interface) on Macs, runs a set of routines intended to identify peripherals and system devices, and initialise their firmware. This is known as the POST (power-on self test) and, as its name suggests, is needed to check the proper functioning of the hardware.
POST routines, if the option is set, can also perform intensive checks like testing all installed memory, but the level of checking is usually curtailed for the sake of speed.
Both the BIOS and EFI are written for the particular motherboards they’re found on. They have knowledge of the chipsets that are embedded in the motherboard and require changes in order to run on other systems. They’re encoded on EEPROMs soldered onto the motherboard so they can be updated.
The BIOS is archaic – the archetypal legacy system, first implemented in the days of DOS PCs. Back then, you could access the BIOS directly from your applications using a well-known standard API (applications programming interface), circumventing DOS completely. You could almost view it as part of the operating system.
These days, despite the increased capability of modern PCs compared to their DOS forebears, the BIOS is still a 16-bit program running in 1MB of memory (the start point of the program is at address 0xFFFF0, 16 bytes below the 1MB mark).
EFI was designed as the successor to BIOS. It has better support for larger disks and the ability to boot from them, a much faster boot time (since it doesn’t use backwards-compatible code to access chipsets and disks), 32-bit or 64-bit code, installable drivers and so on. Unfortunately for PC users, the BIOS maintains its stranglehold on our machines.
One of the final stages of the POST process is to identify and initialise the drives in the system. The BIOS has a table that defines the boot order for disks, and it starts looking through this table for a disk that contains an operating system.
To do this, it looks for the bootstrap loader on each disk in sequence. The BIOS doesn’t know about filesystems (the filesystem is only loaded as part of the operating system). Instead, it only knows about sectors, heads and cylinders.
To find the bootstrap loader, the drive must be formatted in a peculiar way. In particular, the first 512-byte sector of the drive (found at cylinder 0, head 0, sector 1) has to be formatted as a master boot record (MBR).
Although small, the MBR has enough code to continue the loading of the installed operating system (each operating system has its own code), and also has a small table of partitions that the drive has been split into.
This table contains information about all the partitions on the drive. Since the MBR only contains enough room for the information on four partitions, that’s what we’re limited to for PC systems.
On the run
Once the BIOS finds an MBR, it loads it into memory and starts executing it. The MBR code identifies the primary active partition by looking at the partition table, reads the partition’s boot loader (known as the volume boot record) from the disk into memory (the partition table stores where the VBR can be found), and starts executing it.
This second boot loader is the one that will load yet more sectors into memory, have more knowledge of the filesystem and continue the loading of the operating system. It will load the actual operating system boot loader (known as ‘ntdlr’ prior to Windows Vista and ‘winload.exe‘ after that), and this boot loader will switch the CPU to 32-bit mode or, increasingly, to 64-bit mode.
At this point the BIOS is no longer used because Windows uses boot-level drivers in order to access the hardware.
For EFI, the process is largely similar, the difference being that EFI has knowledge of the filesystem and can load the boot loader directly. This is called BootX on a Mac. Once the operating system starts to boot, it initialises the various systems it moderates. These include the CPU, memory, on-board devices, persistence mechanisms, and app and user interfaces.
FIGURE 1:Major components in an operating system
For the CPU, the operating system not only switches it into 32-bit or 64-bit operation, but also virtualises the CPU for security and protection. The OS and its kernel drivers execute at the highest privilege at Ring 0, whereas normal user applications (such as the browser or a word processor) run at the lowest privilege in Ring 3 (there are four privilege or protection rings in modern Intel architecture, of which Windows uses only two).
The main reason for this is security; by ensuring that non-privileged programs can’t corrupt the OS, either maliciously or accidentally, the system as a whole is made more stable.
By providing this level of protection, the OS can also abstract away certain physical limitations of the PC (say, the amount of memory) from user applications and then provide services like program swapping and multitasking, making the application easier to write and the overall system more efficient.
Operating system 