Come on Ed, the doc is out there, in fact there is so much doc it's sometimes hard to find exactly where something is. Well, strategically WAS makes sense. Why would they, IBM, not position themselves to take advantage of this application technology. Not having WAS available for z/OS would just help nudge the door shut a bit more, no? We had our hands on this technology from the beginning, 01'. I can tell you that early on the doc and support was lacking. And there are challenges tuning a WAS/Domino with traditional mainframe workload, especially on 2 way g5. It has come a long way and there still may be some problems but we're talking about a convergence of single server/application technology with traditional mainframe multi-application technology. Of course there will be growing pains and problems. Ed Gould <[EMAIL PROTECTED]> wrote: On Dec 15, 2007, at 3:09 AM, Michael Poil wrote: > ----------------------SNIP-------------------------------- > As for the criticism "JAVA was probably rewritten for the MF > without the > years and years of experienced IBM design philosophy and > debugging", I am > in a privileged position where I can see the amount of work that > has been > invested in its design over many years, I can assure you that your > assertion is untrue. If you were allowed to visit the lab and see for > yourself, you might change your mind.
Well OK I reserve judgement until then but if true they are looking extremely guilty right now just with the surface discussion on here, IMO. No trace tables, no Messages and Codes, No SAG, no MANUALS PERIOD. (If there are I sure have not heard of any), NO CLASSES (IBM) (Steve here is your que). Especially no debugging classes (big call to Steve), It should would embarrass IBM to have a 3rd party offer something. IBM has let loose a product nobody can put their hands on. This is extremely unlike IBM, if this is the future I hate to say it maybe its time for the MF to die. > > One of the big problems was that the Java design required it to > support > "lazy" programming whereby the programmer did not have to clean up > dynamically-allocated data areas (thus avoiding user storage creep > - see I > am using the "right" terminology now). This resulted in the need for a > large pool of storage (the JVM heap) and very complex and > sophisticated > code to do what the programmers should have been doing (Garbage > Collection). The OO design also costs due to its complexity versus > more > traditional languages. That still doesn't sound like the traditional IBM any old time (IMO) would have made a method o this apparent madness for debugging purposes when this is let (wait its too kate) go to the customer. What I am understanding from your writing there is no way to debug this monster and we are essentially buying a pig in a poke. Don't ever open a PMR as it will certainly never be closed (with a fix). > > The totally portable byte code (Sun design) was initially > interpreted and > was too slow, so various techniques were used to compile the byte code > into machine code, resulting in the JIT which compiles on the fly; > again > complex and needing storage for compilation and storing the compiled > results. > > All software products in this category need yet more storage to > function, > I worked in CICS a few years back and I know that it is the case, > it has > to manage the environment and this costs. > > I could hark back to my System/360 with 64K of memory and Assembler > - we > managed to get applications to work with real memory, none of this > Virtual > Storage nonsense etc. etc. etc. Technology moves on, and the extra > sophistication costs, but we now have the hardware and OS to match the > demands. > > No language is perfect, but Java provides a write-once-run-anywhere > facility that would have been undreamed of back in the early days. > I even > had to convert COBOL to run on different platforms, never mind all the > other myriad languages that were available somewhere but not > everywhere. Unless it can be debugged (in a timelyt fashion) it is a non dependable (ie production) product and should never be used in that environment, IMO. > > I have a feeling that there are possibly a large number that I am > never > going to convince, but I can't just sit back and ignore assertions > like > the above that are made due to lack of knowledge. Probably going to > get a > load of flack about this, but I will never be Politically Correct, > I tend > to speak my mind. > We are willing to be convinced but like I said before the dragon has no clothes. Ed ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
