Operating System Notes In Hindi Pdf Download
Tanja Freeze
An Operating System(OS) is software that manages and handles the hardware and software resources of a computer system. It provides interaction between users of computers and computer hardware. An operating system is responsible for managing and controlling all the activities and sharing of computer resources. An operating system is a low-level Software that includes all the basic functions like processor management, memory management, Error detection, etc.
OS is the most important part of a computer. Through OS users can interact with computer software. It provides an interface between Hardware and CPU. It also provides a platform for the program to run on it and services to users. It performs all the basic tasks required in an application.
Did you shut the system down from the menu, and then restart the system from a complete power down? You have to do this, or the release notes will show every time. Just turn it off from the menu, and your issue should go away until the next update.
Step 1. Close the release notes.
Step 2. Look in the corner.
Step 3. Find the power button in the corner.
Step 4. Click on it via a mouse or other input device.
Step 5. Click on Power off system.
Step 6. Wait for the system to shut down.
Step 7. Turn the system back on.
Have to pull the power plug to shut down. But then on next boot, release notes shows again and you enter a hardlock loop. I needed to reflash Kodi in order to escape this loop since the entire system freezes as soon as the release notes show.
It's not clear whether or not the BLnn-nn value is derived from the downline-loaded software, or the ROM inside the DECserver itself, but I suspect it is the latter - different DECservers all loading WWENG1.SYS have different BLnn-nn values.
We only have one DECserver that is running at NAS V2.3A and which loads WWENG2.SYS (others are running at V1.0, V1.1A, V2.2), and it maintains per-port "Input Characters" and "Output Characters" counters (essentially, DECserver-side equivalent to the Bytes Transmitted and Bytes Received counters in MC LATCP SHOW PORT LTAnnnn: /COUNT).
Q2: Is the NAS version number reported by SHOW SERVER STATUS (and the fact that only the DECserver with NAS V2.3A reports Input/Output Character counts for SHOW PORT n COUNT) an artefact of the ROM inside the DECserver, or the WWENG1.SYS / WWENG2.SYS that we downline load (it doesn't readily appear as a text string in the file, but it may be derived from "binary" byte or word values)?
I ask because changing one of the spare DECservers to load WWENG2.SYS (as used by the DECserver running NAS V2.3A) rather than WWENG1.SYS alters neither the reported NAS S/W version, nor the ability to count per port Input/Output Characters.
This indicates it has encountered a software exception; the PC (Program Counter), SP (Stack Pointer), SR (Status Register) and ME (MEmory address (potentially) attempted to be accessed by the code at the PC address) are effectively meaningless without access to the source code.
None of this really helps me determine the root cause, and there appears to be a dearth of Release Notes for older NAS versions (though given the issues I have with the NAS version number and feature functionaly not appearing to change between WWENG1.SYS and WWENG2.SYS, I wonder whether or not it's not really a software exception, but a hardware issue with the DECserver).
[The only versions that I have been able to find online are for V2.6 and V3.6, and neither mention software exceptions being a known issue or fixed (so whatever is causing the exception that we are having, I presume has possibly fixed prior to V2.6)
I am disinclined to change the downline-loaded image from WWENG1.SYS to WWENG2.SYS for the DECserver 700-16 that has rebooted 5 times, because at first glance, it doesn't /appear/ to offer any differences (NAS and BL version numbers do not change, and there is no new ability to get per-port bytes received/transmitted counts, nor do SHOW MEMORY CONFIGURATION nor SHOW MEMORY STATUS) - I also don't have any real information on the difference between WWENG1.SYS and WWENG2.SYS, so don't know whether or not I might be jumping out of the frying pan into the fire]
I can't answer all of your questions, but I can answer the most important ones. AFAIK, the BL numbers are the build numbers for that version of DNAS. I have a DS90M running "Network Access SW V2.4 BL50 for DS90M" and DS700-16 running "Network Access SW V3.6 BL01 for DS700-16". The DECserver's firmware version is not as important and the amount of RAM and the size of the flash memory card if one is installed for determining what version of DNAS it can run and what the load file name is. Use the show memory command on the DECserver to determine how much RAM and if flash is installed in a DECserver. You can downline load WWENG1 to any DECserver 700, but you have to have at least 2MB of memory in the 700 to download WWENG2. See the table that I have put together below, hopefully it will be readable.
Check your output from show server status more closely. It sounds to me like you have more than one load host and they have different versions of WWENG1.SYS and WWENG2.SYS. Are you sure that the DECservers are not loading from flash and have different versions of DNAS in their flash memory?
Forgot to mention that you can upgrade all of your DECservers to the latest version of DNAS by purchasing an upgrade kit from Vnetek Communications LLC . The cost for the version 3.6 kit was less than $400 US years ago. We were also sent the latest firmware files for the memory challanged DS90's (version 2.4 maybe) that didn't have enough RAM to run version 3.6.
> Use the show memory command on the DECserver to determine how much RAM and if flash is installed in a DECserver
That seems to be a function of the version of NAS that is installed - on almost all of the DECservers, the MEMORY
keyword is not a recognised parameter for the SHOW verb (only the server with NAS V2.3A accepts it - and it's not
a SET PRIVILEGED issue either).
I think the only way to determine the memory would be to configure (where necessary) a console port on the DECserver,
connect a VT terminal to it, and force a reboot during non-production hours with a CRASH or power-cycle.
It's clear therefore that the WWENG2.SYS on the load hosts doesn't appear to be what it says on the tin - a file name with an implied more recent version is actually older (which is hardly surprising, given that the WWENG2.SYS (1101 blocks) on disk is 55 shorter than WWENG1.SYS (1156 blocks), or that WWENG2.SYS has a creation date 6 months earlier than WWENG1.SYS)
>Forgot to mention that you can upgrade all of your DECservers to the latest version of DNAS by purchasing an upgrade kit from Vnetek Communications LLC
I guessed that that would be the case, but as is the case in most shops, reluctance to spend pennies on something that is due to be replaced "soon" is the order of the day.
On further examination, after reboot, SHOW SERVER COUNTERS has regularly reported an "Illegal Messages Rcv'd" count that has normally been 2 (except on the last reboot, when it has remained at zero).
The manual indicates that this is a LAT counter, and the fact it is not the "Illegal Multicasts Rcv'd" that has increased, implies that the LAT frame didn't indicate it was multicast, rather so by default must have been a LAT frame "targetted" at the MAC address of the DS700.
The fact that it is the "Illegal Messsages Rcv'd" counter in SHOW SERVER COUNTERS that is non-zero, rather than one of the nodes in SHOW NODE COUNTERS, indicates that either the host name could not be determined, or the sanity checking of the frame rejected it before it could determine the host to which the erroneous count could be ascribed.
e.g. an RLE length indicator might indicate a length of say 50 bytes, but only 40 bytes is received, so attempts to access byte 41 would extend beyond the bounds of an array/buffer, and cause an exception (I don't think that's what is happening here - the CO=004 indicates a Motorola 68000 Illegal Instruction (not sure if this means the opcode is illegal, or any parameters it requires are illegal), which suggests either the code having been instructed to jump to a memory address that contains data rather than code, or the memory containing the code has been overwritten (it is perhaps not as well defended against such an operation as in OpenVMS)).
I use the term "help" loosely - it would merely mask the problem of (I believe) something sending badly formatted LAT frames that causes the DECserver to generate an exception; how long before an even worse formatted LAT frame defeats even the most recent version of NAS software.
[I know of a mobile network operator who originally had everything on the same VLAN until one day someone plugged something into the data network; it sent out rubbish that cause the VAX systems to crash repeatedly until the offending item was unplugged; needless to say, they subsequently segmented their data network; I'll spare their blushes by not mentioning their name here :-D
I've hate to get the bosses to cough up for the latest version of NAS (and potentially, memory upgrades), only for the sender of the rubbish to have a hissy fit, send even worse frames onto the network in multicast, and cause all the DECservers to crash - I'd really rather get to the bottom of who is sending rubbish, and why, and getting that fixed]
I'm badgering to get a switch port on the same VLAN to be set up to allow a PC with Wireshark to be connected and capture the traffic before an expected reboot, to identify what messages the DECserver is the target of, and depending on how badly formatted the messages (and any preceding ones) are, perhaps identify at least the MAC address of the sender, and possibly from the payload of the message (and preceding ones) determine what was being attempted (and maybe what process on the sender system (assuming it is a server rather than some rogue bit of hardware) was responsible).
7fc3f7cf58