Uncompressed, terabyte is about 1500 to 2000 CDs (roughly). With compression, say, 1:10, it is still only up to 20,000 CDs. A lot but hardly 'all of the recorded music'.
Russians never managed to build the rocket engines powerful enough. Several tests ended in disaster, with many space program personnel killed. They lost the moon race, and that says it all.
(i) Hire consultants (ii) Consultants produce a report essentially saying the whole company will go to pieces unless they hire more consultants to write more reports how to avoid Y2K problem. (iii)... (iv) Profits (that is, to Y2K consultants).
and I know something about MVS internals, probably more than you'll evern now.
TSO? It's a hack. It has never been succesfully integrated into MVS. I've worked enough with TSO, by the way. TSO, as any interactive task, does lots of things dynamically, and this intefers with the whole spirit of MVS which attempts to preallocate resources before the job is scheduled for execution. TSO is nominally interactive system, but try to do to any extensive work on that.
Oh well, going through the rest of your messages, let me explain you something. I've been working as Mainframe application programmer for a couple of years (mostly BAL/370, even if you believe there is no such thing), then for about 5 years as a systems programmer on MVS/XA, MVS/ESA, and VM/XA and VM/ESA, did some installation, configuration, performance and tuning, then switched to mostly VTAM and SNA for a couple of years, and then drifted to TCP/IP. I know MVS and VM internals quite well.
At least at that time. If your program in a tight loop and doesn't do any concurrent I/O, it will continue runing forever. That's why every job on MVS had some implied CPU time limit. Once the job has exceeded that limit, the whole thing is cancelled.
I was working with IBM MVS (batch oriented) and VM (interactive) for quite a while. At that time the main choice was between COBOL and Assembly Language (BAL/370). COBOL provided some basic routines, but do to something interesting (like asynch I/O, your own memory management, etc) you had to use BAL.
The following example might be interesting, not sure if helpful. On batch system you have many jobs executing concurrently. MVS (at that time) didn't have anything like preemptive multitasking. COBOL didn't have asynch I/O either, so when it issues I/O it just goes into a wait state, so another task is scheduled. So the bottom line was that your program won't be very efficient (e.g., won't be overlapping I/O and CPU activites), but that would create a nice (from MVS perspective) mix of jobs. Some are doing I/O, some are doing CPU, so MVS can accomodate many concurrent tasks.
Well, at that time I was budding assembly language programmer and even took a course at university where we had to write our own operating system, entirely in BAL/370, including the Initial Program Loader (boot, if you wish). I was working at the same time, and there was a problem at my job. They (John Hancock Insurance) had hundreds and hundreds of COBOL programs, and nothing like cross-referencing dictionary, like which program modifies some common record fields. So when something unexpected happened, they had to search through the source code, to find all the instances of such references and that was taking something like 5-6 hours. I've learned asynch I/O at school and how to overlap I/O and CPU activites, and I've ended up writing fairly efficient program. Program was reading large chunks of disk data into several buffers. As soon as the first buffer was full, that event was detected, and the program starts parsing that buffer for some keywords --- while continuing reading the tracks into other buffers. (it was a circular list of buffers). After some trials I got the execution time down to less than 20 minutes. Everyone in my area was happy.
Everyone except mainframe operators. I've been told they HATED my program to its guts. The problem was that the program didn't behave nice as far as 'good mix' is concerned. It grabbed the resources and hold them for a long time because it went to the wait state only occasionally. But that was a great help for production problems, so they had to let it run.
That was many years ago. I don't know if MVS got changed so to introduce preemptive multitasking. At that time it was a strictly batch-oriented system. All I/O was executed in a separate subsystems (channels). To run something interactive (like CICS) wasn't trivial at all. The best strategy was to dedicate entire mainframe to such task. Mixing CICS and batch jobs int the same machine was suboptimal solution. Of course, MVS scheduler got improved since, to provide better balancing between batch and interactive tasks, and yet, as I understand, MVS fundamentally remains batch operating system.
Sun has made so much noises how THEIR distribution of Linux is true to the LInux spirit whereas Red Hat isn't - I've never doubt their linux campaign won't last that long. Just another half-backed marketing idea which boils down to bait and switch. Except it smelled fishy for me right from the start, and I guess for many others as well.
well, 'smooth' and 'curvy' is more advanced concepts, like differential geometry. meaning the 'smooth and curvy' alternative to iPod will be more advanced as well.
I had to call Toshiba tech support a couple of times. Both times got somebody in India even if they've claimed they are in Canada. BUT they were willing to help and took their time to find the answers. The only problem was with their help --- well, it wasn't entirely correct, not quite helpful so to speak. But Toshiba has a wealth of technical information on-line, and going through all the docs I've found the right information anyway.
But the bottom line is that my Tosh laptop is very reliable, so I don't have lots of reasons to call tech support anyway. So that's my advice: get a laptop with good records, and make sure information on line is available. For instance, I was able to locate detailed repair manual for my laptop, written for pros servicing laptops, not low-life like me, but the manual is very detailed and carefully explains how to take it apart and replace virtually anything. Can't complain about that.
and CLISTs in TSO. I had the same experience. REXX under VM/CMS came first, of course, and that was quite a pleasure from switch from EXEC/2. on TSO it became available at some later point, but I was able to create some fairly complex apps before dropping into Ultrix and Sun/OS word and never going back.
As I remember REXX was fairly concise and compact and easy to deal with (kind of reminds me PASCAL), certainly neater and better organized than PERL (but what is NOT better organized than PERL anyway?). Yet since there are some many choices in Un*x world (many scripts, and then PERL and PYTHON), I doubt REXX would ever achieve that level of acceptance it did in mainframe world.
Slashdot Mirror
with my short attention span, sounds (eh, looks) like a great idea to me.
isn't Chtulhu a father of Flying Spaghetti Monster?
Of course, supernova is manifestation of Flying Spaghetti Monster getting angry or something like that. I can't believe anyone can think otherwise.
and Microsoft, right?
of the recorded music.
Uh?
Uncompressed, terabyte is about 1500 to 2000 CDs (roughly). With compression, say, 1:10, it is still only up to 20,000 CDs. A lot but hardly 'all of the recorded music'.
I may find it more exciting to know that 'Buttbandits' are encoded with 2048-bit RSS key.
My key is bigger than your key!
as two rocket scientists. Gosh, isn't that cute or what?
Make it about 2000. Christianity died with Christ.
Russians never managed to build the rocket engines powerful enough. Several tests ended in disaster, with many space program personnel killed. They lost the moon race, and that says it all.
Didn't Stephen J Gould provided fairly adequate explanation of such mechanism: mutation in isolated subgroup.
I've thought it was iPod Shuffle.
the same way IT handled Y2K problem.
...
(i) Hire consultants
(ii) Consultants produce a report essentially saying the whole company will go to pieces unless they hire more consultants to write more reports how to avoid Y2K problem.
(iii)
(iv) Profits (that is, to Y2K consultants).
and I know something about MVS internals, probably more than you'll evern now.
TSO? It's a hack. It has never been succesfully integrated into MVS. I've worked enough with TSO, by the way. TSO, as any interactive task, does lots of things dynamically, and this intefers with the whole spirit of MVS which attempts to preallocate resources before the job is scheduled for execution. TSO is nominally interactive system, but try to do to any extensive work on that.
Oh well, going through the rest of your messages, let me explain you something. I've been working as Mainframe application programmer for a couple of years (mostly BAL/370, even if you believe there is no such thing), then for about 5 years as a systems programmer on MVS/XA, MVS/ESA, and VM/XA and VM/ESA, did some installation, configuration, performance and tuning, then switched to mostly VTAM and SNA for a couple of years, and then drifted to TCP/IP. I know MVS and VM internals quite well.
You, on the other hand, is mostly full of it.
At least at that time. If your program in a tight loop and doesn't do any concurrent I/O, it will continue runing forever. That's why every job on MVS had some implied CPU time limit. Once the job has exceeded that limit, the whole thing is cancelled.
I was working with IBM MVS (batch oriented) and VM (interactive) for quite a while. At that time the main choice was between COBOL and Assembly Language (BAL/370). COBOL provided some basic routines, but do to something interesting (like asynch I/O, your own memory management, etc) you had to use BAL.
The following example might be interesting, not sure if helpful. On batch system you have many jobs executing concurrently. MVS (at that time) didn't have anything like preemptive multitasking. COBOL didn't have asynch I/O either, so when it issues I/O it just goes into a wait state, so another task is scheduled. So the bottom line was that your program won't be very efficient (e.g., won't be overlapping I/O and CPU activites), but that would create a nice (from MVS perspective) mix of jobs. Some are doing I/O, some are doing CPU, so MVS can accomodate many concurrent tasks.
Well, at that time I was budding assembly language programmer and even took a course at university where we had to write our own operating system, entirely in BAL/370, including the Initial Program Loader (boot, if you wish). I was working at the same time, and there was a problem at my job. They (John Hancock Insurance) had hundreds and hundreds of COBOL programs, and nothing like cross-referencing dictionary, like which program modifies some common record fields. So when something unexpected happened, they had to search through the source code, to find all the instances of such references and that was taking something like 5-6 hours. I've learned asynch I/O at school and how to overlap I/O and CPU activites, and I've ended up writing fairly efficient program. Program was reading large chunks of disk data into several buffers. As soon as the first buffer was full, that event was detected, and the program starts parsing that buffer for some keywords --- while continuing reading the tracks into other buffers. (it was a circular list of buffers). After some trials I got the execution time down to less than 20 minutes. Everyone in my area was happy.
Everyone except mainframe operators. I've been told they HATED my program to its guts. The problem was that the program didn't behave nice as far as 'good mix' is concerned. It grabbed the resources and hold them for a long time because it went to the wait state only occasionally. But that was a great help for production problems, so they had to let it run.
That was many years ago. I don't know if MVS got changed so to introduce preemptive multitasking. At that time it was a strictly batch-oriented system. All I/O was executed in a separate subsystems (channels). To run something interactive (like CICS) wasn't trivial at all. The best strategy was to dedicate entire mainframe to such task. Mixing CICS and batch jobs int the same machine was suboptimal solution. Of course, MVS scheduler got improved since, to provide better balancing between batch and interactive tasks, and yet, as I understand, MVS fundamentally remains batch operating system.
Hey, IBM, I'm throwing this *towards* you. Ooga booga.
and how is that any better?
Sun has made so much noises how THEIR distribution of Linux is true to the LInux spirit whereas Red Hat isn't - I've never doubt their linux campaign won't last that long. Just another half-backed marketing idea which boils down to bait and switch. Except it smelled fishy for me right from the start, and I guess for many others as well.
well, 'smooth' and 'curvy' is more advanced concepts, like differential geometry. meaning the 'smooth and curvy' alternative to iPod will be more advanced as well.
I had to call Toshiba tech support a couple of times. Both times got somebody in India even if they've claimed they are in Canada. BUT they were willing to help and took their time to find the answers. The only problem was with their help --- well, it wasn't entirely correct, not quite helpful so to speak. But Toshiba has a wealth of technical information on-line, and going through all the docs I've found the right information anyway.
But the bottom line is that my Tosh laptop is very reliable, so I don't have lots of reasons to call tech support anyway. So that's my advice: get a laptop with good records, and make sure information on line is available. For instance, I was able to locate detailed repair manual for my laptop, written for pros servicing laptops, not low-life like me, but the manual is very detailed and carefully explains how to take it apart and replace virtually anything. Can't complain about that.
Funny, that was the very first thing that came to my mind when I read this item.
a small explosive device, to start with. then move to a larger explosive device.
are belongs to us.
Bill Gates.
hey, he says 'emacs, emacs, emacs is the greatest editor', and then he shows up the display with --- God forbid --- XEmacs.
Bloody hypocrite.
and CLISTs in TSO. I had the same experience. REXX under VM/CMS came first, of course, and that was quite a pleasure from switch from EXEC/2. on TSO it became available at some later point, but I was able to create some fairly complex apps before dropping into Ultrix and Sun/OS word and never going back.
As I remember REXX was fairly concise and compact and easy to deal with (kind of reminds me PASCAL), certainly neater and better organized than PERL (but what is NOT better organized than PERL anyway?). Yet since there are some many choices in Un*x world (many scripts, and then PERL and PYTHON), I doubt REXX would ever achieve that level of acceptance it did in mainframe world.