[U2] u2 Abbasoft
Does anyone have any experience or knowledge about an ERP package called Abbasoft. I am lead to believe it is Pick based, but the website indicates that it is SAP. Thanks, any enlighten would be helpful. Tom Dodds mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] 513-563-2800 Cincinnati Office 708-234-9608 Chicago Office 630-235-2975 Anywhere Cell --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] TCP/IP Standard Packet design
Hi Being new to this type development, does anyone have advice on how to build a standard packet. What we will be doing is to prebuild an XML file and to it this we will be sending over TCP to the server. Any suggestions would be great R, Sunny Sunny Matharoo Development Team Leader Tristar Worldwide Chauffeur Services Tel:+44 (0) 1895 432074 Fax:+44 (0) 1895 432098 E-mail: [EMAIL PROTECTED] www.tristarworldwide.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Shorter link to mailing list subscription info?
At 12:29 -0700 2006/08/22, Wendy Smoak wrote: On 8/22/06, Glen Batchelor [EMAIL PROTECTED] wrote: The server admin can create a mail.php script that includes the URL. That or a page that simply redirects to the right one would be fine... anything but that long, ugly URL that wraps and potentially breaks depending on your mailreader. Most mail servers and readers are smart enough not to break URL's surrounded in 'S. I've not been able to find any RFC's on that one, but it's fairly universal. Ray -- .=. | =-=-=-=-=-=-= Eagle Rock Information Systems Corp =-=-=-=-=-=-= | | -=-=-=-=-=-=- web and database business solutions -=-=-=-=-=-=- | | http://www.eriscorp.commailto:[EMAIL PROTECTED] | |Midwest Regional Office: 815-547-0662 (voice) 815-547-0353 (Fax)| .=. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] TCP/IP Standard Packet design
You need to decide a few things first. Do you want really want defined packets, or will a stream work? If you are going to be transmitting packets, then you should size the packets according to your average document size. For example, if your document is normally 1K (1024 bytes) then it makes sense to send the document in a single packet sized to 1024 data bits. If your document is 100K, then you will want to break the document into packets sized at a maximum of say 4K. The larger the packet size, the fewer packets will need to be handled. On the other hand, the larger the packet the larger your retransmit time will be if such packets get corrupted or are received incompletely. Smaller packets mean more transmissions, but your retry rate is much lower. You should write your packet handlers to be data size configurable, so that you can tweak the connection for best performance. Simple packet: start identifierdata length[data segment]end identifier Anything in is considered statically sized. Anything in [] is considered dynamically sized. STRING = TESTING PACKET = CHAR(27):A PACKET := LEN(STRING)R%6 PACKET := STRING PACKET := CHAR(27):E escA07TESTINGescE R%6 will give you 99,999 byte maximum data size in the packet. Keep in mind that when you design a packet structure, the length of the start block, length block, and end block are all static byte lengths. If you make a change and expand say data length, then you will need to update every piece of code that uses the packet design. Otherwise everyone will get very confused! Incoming packet- MYPACKET IF MYPACKET[1,2] = CHAR(27):A THEN IF MYPACKET[LEN(MYPACKET),2] = CHAR(27):E THEN DATASIZE = MYPACKET[3,6] DATABLOCK = MYPACKET[9,DATASIZE] END ELSE GOSUB WAIT.FOR.DATA END ELSE GOSUB WAIT.FOR.DATA END END This is definitely pseudo code that has 99% of the logic missing. Even if you are streaming data, both sides need to understand at least two static packets defined for error conditions. Retry Received OK These short packets should be communicated uni-directionally and in sequence to the data packets. When sending a packet, the process should withhold continuing until a Recevied OK or Retry acknowledgment is received. A receiving packet should be verified immediately and the other side should be notified of either a Retry or Received OK scenario. For all of the communication steps, timeouts should be an integral part and initiate a Retry or quit with a fatal error upon serious or repeat problems. For more info on packet designs and possible pitfalls with various socket types and layers, Google for socket packet design. --- Glen Batchelor IT Director All-Spec Industries phone: (910) 332-0424 fax: (910) 763-5664 e-mail: [EMAIL PROTECTED] --- www.allspec.com --- -Original Message- From: [EMAIL PROTECTED] [mailto:owner-u2- [EMAIL PROTECTED] On Behalf Of Sunny Matharoo Sent: Wednesday, August 23, 2006 10:22 AM To: u2-users@listserver.u2ug.org Subject: [U2] TCP/IP Standard Packet design Hi Being new to this type development, does anyone have advice on how to build a standard packet. What we will be doing is to prebuild an XML file and to it this we will be sending over TCP to the server. Any suggestions would be great R, Sunny Sunny Matharoo Development Team Leader Tristar Worldwide Chauffeur Services Tel: +44 (0) 1895 432074 Fax: +44 (0) 1895 432098 E-mail: [EMAIL PROTECTED] www.tristarworldwide.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Set udt priority on Unix (Solaris,Aix,HP)
-Original Message- From: [EMAIL PROTECTED] [mailto:owner-u2- [EMAIL PROTECTED] On Behalf Of John Jenkins Sent: Wednesday, August 23, 2006 4:16 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Set udt priority on Unix (Solaris,Aix,HP) On some Unix systems the command is chap - SNI / Reliant Unix by my (vague) recollection being an example. Other posters have already picked out nice which is more usual. Regards JayJay --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] IBM IOD Conference in Anaheim October 15-20
I am presenting a session at the IBM Information On Demand Conference in Anaheim, CA on Monday 16th October. The session is titled: Servicing the Olympics and it will present details of our use of Universe to support the services provided by Spotless Services at the Athlete's Village and Media Village during the 2000 Olympics. https://www014.temporary.ibm.com/IOD2006/activity.do?method=viewaID=ke39c2 2d5176aade710b90ce44fd https://www014.temporary.ibm.com/IOD2006/activity.do?method=viewaID=ke39c22 d5176aade710b90ce44fd Are there any u2ug listers going? Feel free to contact me. Regards, David Sharp Manager, Software Services Melbourne Spotless Services Australia Ltd 350 Queen Street, Melbourne, 3000 (w) +(613) 9269 7325 (f) +(613) 9269 7615 (m) 0403 253 010 ** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this email in error please notify the Spotless IS Support Centre (+61 3 9269 7555) immediately, who will advise further action. This footnote also confirms that this email message has been scanned for the presence of computer related viruses. ** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Shorter link to mailing list subscription info?
That or a page that simply redirects to the right one would be fine... anything but that long, ugly URL that wraps and potentially breaks depending on your mailreader. The use case is responding to private email inquiries with, Please ask on the u2-users list, you can find subscription info here: . www.tinyurl.com? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
