Re: [U2] [u2] Parallel processing in Universe
On Tue, Oct 2, 2012 at 5:58 PM, Symeon Breen syme...@gmail.com wrote: However map reduce and hadoop are pretty horrible things. Even Google have moved away from it with Caffiene etc. Going OT a little, i think Google is replacing BigTable which was part of Caffeine in 2010 with Spanner now. Here is a doc about it released last month: http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/spanner-osdi2012.pdf ...amusingly they call it a Multi-Version Database, can't wait till that gets abbreviated. - Robert ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Runoff ?
Hi Bill, On Mon, Jun 18, 2012 at 3:55 AM, Bill Haskett wphask...@advantos.net wrote: A typical big problem today is figuring out what is happening in (through) a UniObjects connection. This can be monumentally frustrating to track down. In D3, the socket into D3 could be tandemed to and the data flow could be watched. Apparently, no one thought this would be a useful feature in the U2 world so it's either not available or not widely known how to do it. In mv.NET they, at least, built a window to watch the data flow through their connection (via UniObjects), which, as we all know, is a tremendous help is debugging application code. Going OT a little from the original thread we had the above problem when first using uniobjects on projects 5+ years ago. From experience found the best method to communicate between client and server is to send unique XML messages to a single dispatching subroutine on the server. The dispatching subroutine then looks at the messages and calls the appropriate subroutine handler to send a return XML message back to the client. This is so much easier to debug as you can just watch the XML message conversation go back and forth with client, can also replay problematic sequences later in a test environment to track down a problem. For the above today i noticed unidata 7.3 has JSON added so may be able to use that as an alternative medium to XML to carry the messages back and forth between the 2 parties. - Robert ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Uniobjects for Java and Domino 8
Hello,
Ok created a quick test routine to show problem(attached to end of
post). It simply gets a record from the demo database and dumps the
output, first the the system default character encoding, then setting
file.encoding and finally clientencoding:
$ echo $LANG
en_US.UTF-8
$ java -classpath asjava.zip:. CharacterEncodingTest
Otis\65533AscProf\6553325800\65533FA\65533PY100\65533221345665\65533414446545\65533Eades
$ java -Dfile.encoding=ISO8859_1 -classpath asjava.zip:. CharacterEncodingTest
Otis\254AscProf\25425800\254FA\254PY100\254221345665\253414446545\254Eades
$ java -Dclientencoding=ISO8859_1 -classpath asjava.zip:. CharacterEncodingTest
Otis\254AscProf\25425800\254FA\254PY100\254221345665\253414446545\254Eades
So setting clientencoding seems to work, providing same output as
file.encoding.
As can see above because system is UTF8 the delimiter characters come
through incorrectly. The same occurs for other binary data outside
the ascii range. On windows for binary data amusingly you even get
different results depending on whether you run the program from the
GUI or console as 2 different character sets are used by the operating
system(for backwards compatability i guess).
Looking at the UniRPC class in UOJ it loads the character encoding
statically thus must specify either file.encoding or
clientencoding on the java command line to reliably ensure UOJ
works. Trying System.setProperty(...) within the java program may or
may not work depending on whether the UniRPC class has already been
loaded by the java classloader.
Would recommend using clientencoding define over file.encoding or
LANG settings both of which will interfere with the reading and
writing of operating systems files by the application.
- Robert
CharacterEncodingTest.java
import asjava.uniclientlibs.*;
import asjava.uniobjects.*;
public class CharacterEncodingTest {
public static final void main(String[] args) {
try {
UniJava dataSource = new UniJava();
UniSession session = dataSource.openSession();
session.setHostName(localhost);
session.setUserName(myuser);
session.setPassword(XX);
session.setAccountPath(demo);
session.setConnectionString(udcs);
session.connect();
UniFile file = session.open(STAFF);
UniString rec = file.read(2);
char[] arr = rec.toCharArray();
StringBuffer sb = new StringBuffer();
for (int i =0; i arr.length; i++) {
if (arr[i] 31 arr[i] 128) {
sb.append(arr[i]);
} else {
sb.append(\\ + (int)arr[i]);
}
}
System.out.println(sb.toString());
file.close();
} catch (UniFileException ufe) {
ufe.printStackTrace(System.err);
} catch (UniSessionException use) {
use.printStackTrace(System.err);
}
}
}
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Uniobjects for Java and Domino 8
Hi John, On Fri, Dec 2, 2011 at 10:01 AM, John Hester jhes...@momtex.com wrote: We've been using UOJ with WebSphere App Server since around 2003. Not quite the same as Domino, I realize, but at least under the same IBM Java middleware umbrella. I can't offer a lot the way of best practices, but I can say that the combination is robust and trouble-free. This is more OS related, but if you're connecting to or from a linux box you need to make sure the LANG environment variable is set correctly. The RedHat default is incorrect for UOJ (at least up to EL 5) and will result in MV delimiters being incorrectly translated into other ascii characters. RedHat EL 5 stores the LANG value in /etc/sysconfig/i18n and the official setting I was given by IBM is en_US.iso885915. The above has caused me many problems in both web applications and running UOJ on mobile devices. I got a debugger out and went through what is happening, it appears UOJ is using deprecated routines within java and writing invalid data to the udcs server. The deprecated routines are using the systems character encoding to convert 16bit java characters to 8bit bytes. As the host systems character encoding is variable thus different data will be sent to the server depending on what location and operating system is used. Roughly the uniobjects conversion routines grab the java system property file.encoding which is meant for reading and writing files and use it directly and indirectly to write data to the socket. Quick fix is on the java command line -Dfile.encoding=iso8859_1 Warning: once java program is running ie System.setProperty(file.encoding,iso8859_1) does not work as a bunch of system level stuff is cached on startup. The above quick fix has many bad side effects as the java process now has the wrong character encoding to read and write files on the local system and has caused me issues in third party libraries which expect to be able to read and write files correctly. ie my web server should be emitting utf8 for maximum compatibility but is putting out iso8859_1 for most files thanks to this quick fix It would be better for the rocket engineers to decide on a character encoding to talk to the server with and set it as a separate define(or hard code it maybe), according to oracle the basic encodings below should be available on most jvms : http://docs.oracle.com/javase/1.3/docs/guide/intl/encoding.doc.html ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Uniobjects for Java and Domino 8
On Tue, Dec 6, 2011 at 1:43 PM, Robert Colquhoun robert.colquh...@gmail.com wrote: It would be better for the rocket engineers to decide on a character encoding to talk to the server with and set it as a separate define(or hard code it maybe), according to oracle the basic encodings below should be available on most jvms : http://docs.oracle.com/javase/1.3/docs/guide/intl/encoding.doc.html Updating post above - had another look at asjava.zip, there appears to be a more recent version in latest unidata at least that has a config parameter clientencoding used by the UniRPC class to convert to and from 16bit java characters to 8 bit characters for sending to socket. The files within the asjava.zip are dated Sept 10 2004. Cannot see where clientencoding is set anywhere in the code, if parameter is absent seems to use system encoding file.encoding as before. Seaching documentation cannot find any reference to it :( Somebody could experiment with it ie java -Dclientencoding=ISO8859_1 -classpath asjava.zip MyProgram to see if that works. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] UV UOJ hung sessions
On Tue, Jun 30, 2009 at 7:15 AM, Baakkonen, Rodney A (Rod) 46Krodney.baakko...@cigna.com wrote: Do you have truss or a trace command at UNIX that can track what the PID is doing. I think on redhat/linux strace is the equivalent routine. Also lsof might be useful. - Robert ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] IPv6
Hello, Just for reference: http://arstechnica.com/articles/paedia/IPv6.ars (...if too technical, just look at the pictures ;-) Am in the pessimists camp about conversion, unless there is a big crunch on ip addresses as the article suggests might happen. Too many applications have hard coded ipv4 addresses and associated logic. Pulling discussion back on subject, does ibm's device licensing on u2 support ipv6 networks? Do the various SYSTEM() calls that return ip address work? - Robert --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Maverick DBMS
Hello Mac, On 3/20/07, Mac Bhyat [EMAIL PROTECTED] wrote: Has anyone had any experience with the open source mv database maverick. What were your impressions, experiences etc. Yes some experience ;-) I am evaluating it as an alternative to Universe, specifically looking at converting our BASIC code to Java. Is this possible ?, or does maverick just put a wrapper around by BASIC code so that it acts like a Java Class The maverick basic compiler compiles basic into either java source code or directly into java byte code(a class file). Today compiling directly to bytecode is preferred method, the java source code generator hasnt been as well maintained lately(my fault). The resulting classfiles run in a JVM the same as any classfile compiled from java source. They are freely callable to and from java routines. Also the large body of third party java libraries can be easily integrated with the basic code. This is a list for u2 users, probably better to ask further questions on the maverick-devel mailing list. - Robert --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Maverick DBMS
Hello, On 3/21/07, george r smith [EMAIL PROTECTED] wrote: I looked at Maverick along time ago. Yes it was written in Java but unless my memory is totatly gone the datastore was one of the open-source databases (MySQL ??). Currently available(For the last 5 years at least): Berkeley DB, Linear Hash(Same as ARev, very similar u2 dynamic files), DIR/Type 19, MySql, Postgres and U2 via Uniobjects. I just could not grasp how his was a help - now you have not only Java to worry about you have another database to hold your pick data. Without writing out a treatise, the idea was prevent your data from being trapped within an obscure data format. Managers hate that, they know it implies paying ever increasing maintenance on the DB itself and greater and greater difficulty and thus expense finding staff competent in managing it. - Robert --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Maverick DBMS
Hello Martin, On 3/20/07, Martin Phillips [EMAIL PROTECTED] wrote: As far as I know, Maverick has quietly died. I may be completely wrong. Have been a bit slack adding new code lately but i am still breathing at this moment! Why would you want to do this? The very nature of both multivalue Basic and Java suggests that this will cost you heavily in performance. Just for reference have worked really hard on the basic programs runtime library to get the performance close to the commercial mv variants. From actually doing it there is really *no* significant penalty in executing your basic code in a JVM(which is JIT compiled) relative to the homespun VM's in other mv platforms or the C translated code jbase produces. The problems have all being due to the library implementation(ie wrong algorithm chosen) not the actual underlying platform. For example last week the debate over using -1 vs X++ type addressing runs pretty much the same under maverick, you can use either without penalty. - Robert --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Article
Hello, http://www.economist.com/business/displaystory.cfm?story_id=811 Who said prime has been all but forgotten? ;-) - Robert --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Embedding JPG/GIF
On 9/30/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: That begs the question, anyone out there (or you, Bill) care to contribute enough information to me that I don't have to do any more work than I have to? 8^} I'm running a Linux workstation and will be checking out the ps2pdf-like utilities that abound on this marvelously techy-geek friendly platform. If you want to do it in the postscript/pdf world the easiest way is to use a desktop scanner + software to produce an eps(encapulated postscript) file of each signature(a secretary or clerk could easily perform this task). The signatures produced can be stored as individual files on the server/db and inserted into other postscript documents with a fairly standard set of commands. Pdf conversion is trivial. The solutions involving font downloads and micr chips for the printer are problematic in that the solution becomes tied to a specific piece of hardware ie electronic transmission of signed documents is difficult/impossible and failure of the hardware can cause headaches. On the other hand, tying to particular hardware might be good from a security point of view. - Robert --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] How do you avoid out-of-office Outlook auto-reply to this list
At 10:46 PM 12/09/2004, Stevenson, Charles wrote: And we do know that I'm not the only one! ToolsOutofOfficeAssistantAddRule From: [EMAIL PROTECTED];[EMAIL PROTECTED] A more general rule that does not reply to any Precedence: bulk messages might work better as it should work for pretty much all lists as well as the annoying corporate spam that big companies send ie HP, IBM i mean you... - Robert --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [OT]Postscript to a Laser on Dumb Term Aux Port
Hello Anthony, At 11:31 AM 6/06/2004, Anthony Dzikiewicz wrote: Much has been considered. These are retail cashiering station that we are talking about. One central printer would be my next choice. The only thing that can go wrong is that the printer hangs and the whole front counter is dead. Don't share a printer between more than 2 lanes - the time it takes for the cashier to walk over to get the printout becomes too much. They also can easily mix up receipts at busy times. When the printer runs out of paper, or toner or the drum, or what have you, they would panic, because the light would be blinking and they wouldnt know what to do (these guys really arent too bright and would always rather have the other guy fix the problem). Write a 2-3 page instruction sheet on printer errors. It will lead to a situation where the printer gets disabled at the unix level and has to be enabled (easy for you and me, but a mountain for these guys). Mind you all this is happening in a retail environment with customers waiting for receipts (ever been in a supermarket when the receipt printer jams - what if that was one printer for the whole market). Modern receipt printer are getting better at this most thermals have a fairly straight paper path for the receipt roll. Best tactic if possible is to have a spare lane to move the customers across to. This isnt good. The spooler is the obstacle that Im trying to avoid. I started to think of the cheapest, easiest, uncomplicated way to go about doing this. This is to continue doing the same thing that has worked flawlessly for about 15 years. People often get quite sentimental about old computer systems, the faults become so ingrained the users can no longer see them, the users get molded to fit the system. When talking about how good a system is always ask the new employees they have a better perspective on the relative merits. The reason for going to laser is to eliminate preprinted forms, which saves substantial cash. I originally believed that the $99 laser I had did postscript. If it did, I would be golden. It doesnt. It does do PCL4. So, my next avenue to explore is to convert the postscript to PLC4 or convert the PDF being created directly to PCL4. Postscript requires more memory than pcl, it used to be i think that they also paid a royalty to adobe. But those things are fading as memory is now very cheap and i think they use 3rd party emulations(ie like ghostscript) to rasterize the document. I did a quick search on http://froogle.google.com/ there was a Brother Laser printer 1450N with postscript for a little over $200. Network printers are also faster than slave printing with serial and perhaps parallel or usb. With network printers you can also quickly redirect the receipts to another lane if one printer stuffs up. Currently, the preprinted forms/Epson arrangement is doing straight ascii printing. We have started using the Cross PDF package and we are converting everything to PDF. We are eliminating pre printed forms wherever they exist. If all of this ends up not working, then I will go with the spooled printer solution. Then I have to create a bunch of menu options to allow users to view the status of the spooler and printer - is lpd running, is the printer disabled, is there a lock file that needs to be cleaned up. I dont look forward to this. The dumb terminal cost about $350 w/kybd new. The laser Im considering is $99. The cheapest laser that does postscript (that I know of yet) is the hp 2100 about $400. We use the hp1200N, not as cheap but fairy fast and reliable both of which imho are more important than the purchase price. Im open to anything that is completely simple and cheap. I have brought up the idea of thermal printers like they use in Best Buy, etc... nobody likes em. We are a furniture store and the appearance of this just doesnt fit considering the average ticket is about $1500 and some substantially more. The owner likes something a little more elegant. So, now you know a little more about the environment what do you think ? $1500 tickets being printed on a $100 laser? So if you print 50 tickets a day = $75000so if your printer dies for a day cause you went for too cheap without a maintenance agreement or backup printer that has cost the company $75k in sales. I imagine cause each ticket is so large you are not printing a huge number the printer warmup time will be importantif you choose the wrong printer then each customer could be waiting an additional 10 seconds for the receipt. If you main computer goes down your dumb terminals are history and you might have to close the store till it is fixed. If you replace with PC's which are cheaper than your dumb terminals you can run a local pc point of sale software in the event of your main machine failure. Secondly printer running costs usually outflank the purchase price - try to work out the current running costs
