Re: [UV] Fault type 4
Basically, it means that you've hit a SIGILL, an illegal instruction signal, during the execution of the BASIC program, at address 5004. If that part of the error message is consistent (the address 5004), you can determine WHERE in the program it is failing by looking at the VLIST listing. I'd suggest contacting IBM support, as this represents some internal failure that you need to have assessed and corrected. It may be a known issue that already has a fix. Dave At 07:36 AM 3/29/2004 -0500, you wrote: We have a problem with a piece of code that we have been debugging all day so far with no progress. A transaction process runs through the same bit of code several times without a problem, then for no 'apparent' reason (I guess there is one there some-where) the programme kicks up with: Abnormal Termination of UniVerse. Fault type is 4. Layer type is BASIC run machine Fault occurred in BASIC program prog name at address 5004. Can anyone tell me what this fault means - if anything? We have re-compiled the code, checked all the data files for corruptions and thrown it into debug - unfortunately because we cannot re-create the problem consistently, it may take hours still to find the exact place where it crashes. Any help would be appreciated... Thanks in advance, Mike -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users David T. Meeks || All my life I'm taken by surprise Architect, Technology Office || I'm someone's waste of time Ascential Software || Now I walk a balanced line [EMAIL PROTECTED] || and step into tomorrow - IQ -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: Modern Universe - was: The lists are closing
So, UV does everything on the BackEnd, but SQL Server does your data warehousing. And you question why UV can't support the DW? Why not ask the alternate question of why the SQL Server can't handle the backend? No one is saying UV is a truly 'enterprise' class DB. It's not marketed as such. It's an extremely efficient, low-cost, high-performance, zero administration DB primarily geared at being the backend (as you have now) for application usage. It's primarily used as an embedded database shipped as part of a solution package. It is seldom sold as a stand-alone DB. Building actual applications that directly go at your Oracle/DB2's of the world is a pain in the arse. Administering said DBs is also a high-cost, complex, cumbersome task as well. Highlighting that the couple of UV people on your staff not knowing XML is somehow a weakness in the product is ludicrous. My wife is an Oracle expert/DBA/etc... she can barely spell XML. Does this imply Oracle's XML support sucks? Of course not. Again, you pick on UV, claiming you have to use DataStage to pull data out of UV into SQL Server. Why then: a) Doesn't SQL Server sufficiently handle your back-end? b) Can't SQL Server directly access the data? c) Is DataStage, the tool being used to do this (and handles Web Services, XML, XPath, XSLT, etc...), built on top of UniVerse? Finally, don't fall into the mistake that performing well would mean you would be in the top 3. Why? Simple... marketing wins over technology almost all the time. Informix was a great example. They had a wonderfully performant VLDB technology. They did very well in OLTP benchmarks. Yet, they weren't a top 3 DB (being #4/#5, depending on the timeframe). The U2 products are great products. They are not 'cutting edge', but they are not way behind either. Their target market is very different from the BigThree, and many would argue they are much better at the job they are intended for than the Big Three. They are NOT better at all things. But, for low-cost, low-maintenance embedded data base support with high-performance, high-user concurrency support, it's hard to beat it. Dave At 11:27 AM 3/29/2004 -0500, you wrote: We have UV doing everything on the BackEnd, we also have MSSQL Server to Support Data Warehousing... Why 2 Databases Systems? Cause UV Cant support Data Warehousing? Doesn't this eventually introduce Disparate Systems? U2, for example, has support for Java connectivity, XML, and I believe they either have or are working on Web Services support Its funny you say the above, UV/PICK Guys in our Team didn't even understand the basics of XML.. leave alone XPath, XQuery etc. These Technologies are NATIVELY Supported in ORACLE/DB2 Etc. e.g. We pull XML Reports from our Vendors Real Time. I have to parse through the XML and give UV/PICK Guys a FLAT TEXT File... cause either UV Cannot handle the storage and Retrival of XML Data Using XPath/XQuery Techniques. Yes, we use DataStage to pull data out of UV Into MSSQL SERVER... For what? Why cant UV handle of the DB Job? As for Performance...UV Does NOT Perform Well in a OLTP Environment, SIMPLE: IF UV did Perform Well...Today's Fortune 500 would depend on UV and UV/PICK would have been in the TOP 3 OF DataBases. Joe Eugene -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David T. Meeks Sent: Monday, March 29, 2004 9:37 AM To: U2 Users Discussion List Subject: RE: Modern Universe - was: The lists are closing While one could make the argument that Pick has not embraced emerging technologies as rapidly as the 'Big Three', it HAS done so. U2, for example, has support for Java connectivity, XML, and I believe they either have or are working on Web Services support (I know, for example, that the DSEngine in DataStage has support for Web Services). One could argue the need or purpose of supporting certain technologies, and the level of support currently within the products, but to say that there is little/no support is a bit uninformed. The U2 products ARE supported in certain Integration software. I wouldn't typically consider SAP/PeopleSoft integration software. They are Enterprise Software Suites, but not geared particularly at 'integration'. However, given that SAP and PeopleSoft OEM the DataStage product sets for both of their integration products (SAP's BW, PeopleSoft's EPM, JDEdwards stuff as well), and given DataStage works very well with both U2 products, this point is actually wrong. People who have SAP or PeopleSoft solutions CAN, very easily, integrate their U2 data to/from those environments. As to 'efficiency', one can measure that in a variety of different dimensions. From a memory/disk space/footprint/administrative overhead dimensions, the U2 database products are VERY efficient. Finally, as to being slow, again this depends on the measurement criteria being used. From
RE: Modern Universe - was: The lists are closing
Frankly, my dear, I don't give a damn - Clark Gable as Rhett Butler in Gone with the Wind At 12:01 PM 3/29/2004 -0500, you wrote: With all due respects, Sir, you are beginning to bore the hell out of me! -- Clint Eastwood as Gunnery Sgt. Thomas Highway in Heartbreak Ridge David T. Meeks || All my life I'm taken by surprise Architect, Technology Office || I'm someone's waste of time Ascential Software || Now I walk a balanced line [EMAIL PROTECTED] || and step into tomorrow - IQ -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
RE: [UV] Recursive GOSUB
|Dave, | |$LOCALSTART --- New construct |Var1 = NewTest |PRINT NewValue of Var1 = :Var1 |$LOCALEND | |when you implemented this, did it add new opcodes or change the object |format, |or were the objects still backwards compatible with previous versions and |the $LOCALxxx directives just affecting the compiler? | |(or between the lines: if I contact IBM and suggest they retrive this code |and add it to UV, do you think I will still be able to copy object from |UV10.x to UV9.x) | |thanks, No, this was not a new opcode, but rather, a construct within the lexical analyzer. So yes, this would be perfectly portable, at least the object code would be... at least insofar as any other object code would be. Obviously, the source code would fail to compile... Essentially, during a pre-pass phase of the compilation, the lexer will examine the tokens to determine if the referenced value is a variable or not. It will then determine whether the variable has been seen or not. If so, it returns that entry in the vartab slot (where you see in the 'VLIST ... R' listing the slot values. The change basically established scope levels inside the analyzer to disambiguate between variables that were local/global scope. Thus, in the construct: A=1 $LOCALSTART A=2 $LOCALEND The lexer would see the 'A', determine it was a LVALUE (variable), and assign it to slot one. The parser would then construct the opcode using the move opcode, using slot 1. The second statement, however, would be within a local scope, so the lexer would mark the boundary in the vartab table, and again, upon determining that 'A' was an LVALUE(variable), it would look up the value, find that it wasn't in the vartab (at least within the local scope range), and assign it a new slot. Effectively, this treats it as if you named it 'A' and 'Local1A', as the actual run-time component doesn't care. Now, there were also mechanisms to mark certain variables as being global scope as well, that I haven't discussed. Now, as to whether IBM could get the code and put it in... the answer is most likely NO. IBM and Ascential are separate organizations, and our code streams are separate and effectively protected. Now, if Susie/Helen were to give me a call, I could probably tell them exactly how to do this.. Hey... didn't this post already do that :-) Dave David T. Meeks || All my life I'm taken by surprise Architect, Technology Office || I'm someone's waste of time Ascential Software || Now I walk a balanced line [EMAIL PROTECTED] || and step into tomorrow - IQ -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
