[U2] The Pick
This caught my eye - Anyone see any typographical similarities? http://www.the-pick.com.au/ Cheers, Stuart Boydell ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Conversion Documentation
Lol - how many times have i done x = var1 var2 instead of x = var1 : var2 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: 16 June 2011 01:35 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Conversion Documentation Which piece of documentation covers things like VARIABLEONE = VARIABLEL(#33) and VARIABLETWO = VARIABLER(%9) ... I'd like to know what exactly it is that I'm doing when I use them rather than just blindly following examples that I've seen to produce results I want. That syntax is traditionally called Masking. The codes you use in ICONV/OCONV are also traditionally called Processor Codes or Conversions (even though you can use Correlatives there). Not all masks are conversions and vice versa. As others said, FMT/FORMAT performs the same operation as a Mask, but using Function syntax. FWIW, using the mask syntax we can also do this: MASK = L#33 TEXT = INFO MASK Developers are sometimes surprised when output looks weird, and it's because they wanted to say something like this: PRINT INFO1:INFO2 or PRINT INFO1: :INFO2 but they accidentally do this: PRINT INFO1 INFO2 or PRINT INFO1 : INFO2 In the first case, INFO2 is used as an invalid MASK on INFO1. That doesn't result in a compiler or runtime error. The system just does its best to apply the text you provided as a mask. In the second case, with the colon for concatenation missing, the space in quotes is applied as a mask to INFO1, which can destroy the data, and INFO2 is then concatenated. The thing to remember is that the system will do exactly what we tell it to, even if that's not what we want. HTH Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com remove.pleaseNebula-RnD.com/blog Visit PickWiki.com! Contribute! http://Twitter.com/TonyGravagno ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1382 / Virus Database: 1513/3705 - Release Date: 06/15/11 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] Uniobjects UOEncoding
Hi I have some utf8 encoded data in my unidata databse, and i want to display it on a web page using uniobjects.net. The data is coming through as iso-8859-1 encoded, so i use the UOEncoding as UniSession udSesh =UniObjects(xxx, yyy, zzz,aaa, udcs); Encoding en=Encoding.UTF8; udSesh.UOEncoding=en; however I get null data returned in by unisubroutine call. The unibasic sub is called on the ud server but the data is lost somewhere. Anything else i need to do ?? Rgds Symeon. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] Question about updating customer's systems...
Hi, We develop software for college bookstores. Over the past year and a half, we implemented PRC's version control software in-house, which has helped us improve the development and release process. We are no looking at how to improve the installation process at our customers. At this point, our goal is to have an isolated, sandbox, where we can install the update and have our customers test. Once they are happy, provide them tools to install the code into their production system. As we start down this path, we are wondering if anyone in this group could share their experiences of implementing something like this, and be willing to share what they learned through your implementation (what worked, what didn't, what are the gotcha's that we should make sure we address). Thanks! Tom Whitmore RATEX Business Solution ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Question about updating customer's systems...
Hi Tom: We had a similar problem years ago trying to deliver our customers consistent releases that we could script. We tried Windows bat files and Unix shell scripts but each release was never quite right. Our staff would forget this file or this dictionary or just plain copy the wrong account to our customer. Then there was the problem the installation for our payroll system, for example, took 8 hours to do a full installation using wIntegrate bridge copy utility which was a really bad way of doing it. [ad] We developed XLr8Installer an Eclipse plug-in. You build a XML script using our tool. The script can be saved on say your network drive for everyone to access or in your version control software. The script can be run over the internet to create your customer's test account environment from your base system. It will create all of the files, copy all of the dictionaries, compile all of the dictionaries, create the indexes, copy any data and program, compile all of the programs, remove source if required, and can run and TCL/ECL commands. We open a connection to our client using XLr8Installer. We either install the full release or a patch release using the XML script that we previously built. All of the data is copied over the internet in a few minutes. Our payroll installation takes about 7 to 10 minutes to do a full install. Our Doc Mgt system that use to take an 1 hour with wIntegrate now takes 45 seconds max. On some of our Client systems we open 3 connections and use all of those connections to updating their site simultaneously. We do not have to do linear installs anymore which cuts our installation time from several hours per site to about 15 minutes depending on how many packages we have to install. For those sites that do not allow internet access in but allow it out. You can run the scripts from the client site to your build site. We even have client that does not allow internet access out or in, so we send our base account on thumb drive. The client or our staff uses the thumb driver to install the software at their site. Pricing is at $99.00 per workstation for XLr8Installer. So even in these hard times, it is difficult that you or your clients cannot afford this amazing solution. [/ad] Regards, Doug www.u2logic.com Eclipse solutions for U2 marketplace ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Question about updating customer's systems...
Thanks Doug, PRC does a great job of tracking what needs to go where, as we pack up the update. The problems we are currently having are 1) our customers want updates after their business hours (read late into the night) 2) our customers have custom code 3) our customers would like to be able to test before going live with the update. Putting the update in an isolated environment, and letting them push the button to install the code, I believe, would address these issues. However, there are so many factors involved, we want to make sure we have identified the gotchas that others have come across. Tom -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Doug Averch Sent: Thursday, June 16, 2011 12:19 PM To: U2 Users List Subject: Re: [U2] Question about updating customer's systems... Hi Tom: We had a similar problem years ago trying to deliver our customers consistent releases that we could script. We tried Windows bat files and Unix shell scripts but each release was never quite right. Our staff would forget this file or this dictionary or just plain copy the wrong account to our customer. Then there was the problem the installation for our payroll system, for example, took 8 hours to do a full installation using wIntegrate bridge copy utility which was a really bad way of doing it. [ad] We developed XLr8Installer an Eclipse plug-in. You build a XML script using our tool. The script can be saved on say your network drive for everyone to access or in your version control software. The script can be run over the internet to create your customer's test account environment from your base system. It will create all of the files, copy all of the dictionaries, compile all of the dictionaries, create the indexes, copy any data and program, compile all of the programs, remove source if required, and can run and TCL/ECL commands. We open a connection to our client using XLr8Installer. We either install the full release or a patch release using the XML script that we previously built. All of the data is copied over the internet in a few minutes. Our payroll installation takes about 7 to 10 minutes to do a full install. Our Doc Mgt system that use to take an 1 hour with wIntegrate now takes 45 seconds max. On some of our Client systems we open 3 connections and use all of those connections to updating their site simultaneously. We do not have to do linear installs anymore which cuts our installation time from several hours per site to about 15 minutes depending on how many packages we have to install. For those sites that do not allow internet access in but allow it out. You can run the scripts from the client site to your build site. We even have client that does not allow internet access out or in, so we send our base account on thumb drive. The client or our staff uses the thumb driver to install the software at their site. Pricing is at $99.00 per workstation for XLr8Installer. So even in these hard times, it is difficult that you or your clients cannot afford this amazing solution. [/ad] Regards, Doug www.u2logic.com Eclipse solutions for U2 marketplace ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Question about updating customer's systems...
We typically recommend that customers have at minimum two accounts, a test account and a live account which are virtually identical and share nothing. This allows us to install to the test account and have them test the code and then we take the same ravel files and roll it up to their production environment. For those customers where we develop on their system, we also recommend having a development account separate from the other two. We then roll from DEV - TEST - production. -K ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Question about updating customer's systems...
Hi Tom; 1) This is not a problem if you allow customers to do their on updates by allowing access to the base system or sending them it to them on a thumb drive, or allowing them to upload the base system via FTP, or some other mechanism. 2) This is always a problem that requires structure from the beginning. If they are changing your live programs, forms, and whatever in their live account then who knows what is custom and what is original. You have setup up files where they can import the original program and modify to their hearts content, but the system knows what to execute by cataloging over the original or modify pointers. This is not something that can be solved by XLr8Installer from your end. Your client would have to it's own custom install script to run after they have run you regular install script. 3) You install your new live code on the customers test account. This allows your customer to test and import their changes until the system is ready to go. Regards, Doug www.u2logic.com 100% Web based applications solutions too On Thu, Jun 16, 2011 at 11:28 AM, Tom Whitmore tewhitm...@ratex.com wrote: Thanks Doug, PRC does a great job of tracking what needs to go where, as we pack up the update. The problems we are currently having are 1) our customers want updates after their business hours (read late into the night) 2) our customers have custom code 3) our customers would like to be able to test before going live with the update. Putting the update in an isolated environment, and letting them push the button to install the code, I believe, would address these issues. However, there are so many factors involved, we want to make sure we have identified the gotchas that others have come across. Tom ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Question about updating customer's systems...
I would also suggest either of the following: 1) If possible, run Dev/Test/Prod on separate machines. Obviously, this requests budget, but if your production system is the lifeblood of your company, it is worth it. Otherwise: 2) Have the accounts set up with appropriate file permissions (owner/group) and *separate login credentials* so someone if Dev cannot simply change a file pointer to start modifying production. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: Friday, 17 June 2011 4:58 AM To: U2 Users List Subject: Re: [U2] Question about updating customer's systems... We typically recommend that customers have at minimum two accounts, a test account and a live account which are virtually identical and share nothing. This allows us to install to the test account and have them test the code and then we take the same ravel files and roll it up to their production environment. For those customers where we develop on their system, we also recommend having a development account separate from the other two. We then roll from DEV - TEST - production. -K ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ### The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files with the permission of IMB. ### ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Question about updating customer's systems...
On 16/06/11 17:18, Doug Averch wrote: On some of our Client systems we open 3 connections and use all of those connections to updating their site simultaneously. We do not have to do linear installs anymore which cuts our installation time from several hours per site to about 15 minutes depending on how many packages we have to install. Why multiple connections? Is this just for speed, a bit like these download accelerators? Just a tip-off, but from what I've read, this could be disastrous. The accelerators work fine up to a point - that point being at which a router gets overloaded. And due to a design failure (basically hardware and software guys not talking to each other) if a router does overload, it basically locks up :-( And the router that overloads is nearly always the edge router between the internet and the office. I think I've managed to do exactly that on a couple of occasions, and the internet simply *appears* to die, until you kill the downloads. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] RPC timeouts
The timeout value is in seconds so the default is 1 hour. The optimal setting is going to be unique to your environment and depends on how you're using unirpc. The default is fine for us because we mainly have connections from an app server that last a few seconds at most. I actually have monitoring set up that pages me if a connection is over an hour old because that almost always means there's a bug in some web subroutine. If you want to change the value, just use your text editor of choice and restart the rpc service afterwards. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Chris Austin Sent: Wednesday, June 01, 2011 8:15 AM To: u2-users@listserver.u2ug.org Subject: [U2] RPC timeouts We recently switched to a new server and I've been having some weird RPC failures. Every night we run a nightly cycle that processes our batches and transactions. During the monthly cycles (which take a little longer), we have a process at the very end that will connect to our java data pool and then kick off a process but it has to read a UniVerse file first (config table). This POST backup never finishes on the new server so I started to investigate. The error we get in our log is below: doPostBatch() LIVE: 81009 Error opening table LFCONFIG The RPC failed NOT opened ok @ Wed Jun 01 02:11:04 GMT-06:00 2011 DataPool.clear() Disconnect PickVolume * run(): Error opening table LFCONFIG The RPC failed I noticed the following directory contains timeouts and I compared the 2 files (old server vs new) and saw the differences of the timeouts was 864,000 (old server) and only 3,600 (new server). $home\IBM\unishared\unirpc\unirpcservices My question is what do most of you guys set this timeout to? And is there any specific formula to it? I would assume the timeout is in seconds. I didn't see anywhere in UniAdmin to adjust this, I assume you guys are doing it through an editor? Also, is this the timeout from the uniRPC-shell? Thanks. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Question about updating customer's systems...
Use colours, so users know if they are in Live or Test (eg normal grey for live, yellow background for test). The users can happily copy live data to test, do any conversions, run things to make sure all OK. Before we did this, users would do some testing, then forget they were not in Live, and do some real work. Cheers, Kate Kate Stanton Walstan Systems Ltd 4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand Phone: + 64 9 360 5310 Mobile: + 64 21 400 486 Email: k...@walstan.com On 17 June 2011 03:10, Tom Whitmore tewhitm...@ratex.com wrote: Hi, We develop software for college bookstores. Over the past year and a half, we implemented PRC's version control software in-house, which has helped us improve the development and release process. We are no looking at how to improve the installation process at our customers. At this point, our goal is to have an isolated, sandbox, where we can install the update and have our customers test. Once they are happy, provide them tools to install the code into their production system. As we start down this path, we are wondering if anyone in this group could share their experiences of implementing something like this, and be willing to share what they learned through your implementation (what worked, what didn't, what are the gotcha's that we should make sure we address). Thanks! Tom Whitmore RATEX Business Solution ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
