Re: [U2] Uni data / uni-objects connectivity

[Doug Averch]

Make sure port 31438 is open if you have a firewall.  Otherwise contact me
offline.
 
Regards,
Doug
www.u2logic.com
303-659-8778

  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of JC Ocasio
Sent: Thursday, June 11, 2009 3:32 PM
To: 'U2 Users List'
Subject: Re: [U2] Uni data / uni-objects connectivity



Doug,

 

 HP-UX and I do have unircpd running..   Wonder if it's
needs something else? 

 

Thanks for the response!

 

Juan Carlos Ocasio CCNA 
Network Planning Manager
Information Technology Department 
County of El Paso 
800 E Overland, Rm 401 
El Paso, TX 79901 
(915) 546-2041   ext 3385
(915) 546-2042  Fax 

(915) 929-0630   Mobile
  Mailto:jcoca...@epcounty.com

 

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Doug Averch
Sent: Thursday, June 11, 2009 2:47 PM
To: 'U2 Users List'
Subject: Re: [U2] Uni data / uni-objects connectivity

 

Are you using Windows or HPUX?  If you are using HPUX you must have unircpd
started.  The command is in the uv.rc file.  If this is Windows then make
sure Unirpc service is running.  Hopefully that helps.

 

Regards,

Doug

www.u2logic.com

  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of JC Ocasio
Sent: Thursday, June 11, 2009 10:35 AM
To: 'u2-users@listserver.u2ug.org'
Subject: [U2] Uni data / uni-objects connectivity

To all:

 

I'm fairly new to IBM universe and Unidata and have been
tasked with upgrading our old PA-RISC to new Itaniums.  Unfortunately we
have little documentation on the configuration and setup of specific items
on our UV  database (as in unirpcd, uniobjects etc).  In a recent dry test
run, we encountered that several of our external websites could not connect
to retrieve data.  I was able to find unirpcd and get the daemon started,
but I also need to get uniobjects running for some of our other
applications.  Where would I find this to get it running and or could
someone point me in the right direction? 

 

As mentioned, I've never administered Universe before and my predecessors
documentation is non-existent.

 

Thanks in advance,

 

Juan Carlos Ocasio CCNA 
Network Planning Manager
Information Technology Department 
County of El Paso 
800 E Overland, Rm 401 
El Paso, TX 79901 
(915) 546-2041   ext 3385
(915) 546-2042  Fax 

(915) 929-0630   Mobile
  Mailto:jcoca...@epcounty.com

 

 

Envirionment info:

HP-UX 11.31

Universe 10.2.11

 

 

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Uni data / uni-objects connectivity

[JC Ocasio]

Doug,

 HP-UX and I do have unircpd running..   Wonder if it's needs 
something else?

Thanks for the response!

Juan Carlos Ocasio CCNA
Network Planning Manager
Information Technology Department
County of El Paso
800 E Overland, Rm 401
El Paso, TX 79901
(915) 546-2041   ext 3385
(915) 546-2042  Fax
(915) 929-0630   Mobile
Mailto:jcoca...@epcounty.com

From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Doug Averch
Sent: Thursday, June 11, 2009 2:47 PM
To: 'U2 Users List'
Subject: Re: [U2] Uni data / uni-objects connectivity

Are you using Windows or HPUX?  If you are using HPUX you must have unircpd 
started.  The command is in the uv.rc file.  If this is Windows then make sure 
Unirpc service is running.  Hopefully that helps.

Regards,
Doug
www.u2logic.com

From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of JC Ocasio
Sent: Thursday, June 11, 2009 10:35 AM
To: 'u2-users@listserver.u2ug.org'
Subject: [U2] Uni data / uni-objects connectivity
To all:

I'm fairly new to IBM universe and Unidata and have been tasked 
with upgrading our old PA-RISC to new Itaniums.  Unfortunately we have little 
documentation on the configuration and setup of specific items on our UV  
database (as in unirpcd, uniobjects etc).  In a recent dry test run, we 
encountered that several of our external websites could not connect to retrieve 
data.  I was able to find unirpcd and get the daemon started, but I also need 
to get uniobjects running for some of our other applications.  Where would I 
find this to get it running and or could someone point me in the right 
direction?

As mentioned, I've never administered Universe before and my predecessors 
documentation is non-existent.

Thanks in advance,

Juan Carlos Ocasio CCNA
Network Planning Manager
Information Technology Department
County of El Paso
800 E Overland, Rm 401
El Paso, TX 79901
(915) 546-2041   ext 3385
(915) 546-2042  Fax
(915) 929-0630   Mobile
Mailto:jcoca...@epcounty.com


Envirionment info:
HP-UX 11.31
Universe 10.2.11


___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] Uni data / uni-objects connectivity

[Doug Averch]

Are you using Windows or HPUX?  If you are using HPUX you must have unircpd
started.  The command is in the uv.rc file.  If this is Windows then make
sure Unirpc service is running.  Hopefully that helps.
 
Regards,
Doug
www.u2logic.com
  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of JC Ocasio
Sent: Thursday, June 11, 2009 10:35 AM
To: 'u2-users@listserver.u2ug.org'
Subject: [U2] Uni data / uni-objects connectivity



To all:

 

I'm fairly new to IBM universe and Unidata and have been
tasked with upgrading our old PA-RISC to new Itaniums.  Unfortunately we
have little documentation on the configuration and setup of specific items
on our UV  database (as in unirpcd, uniobjects etc).  In a recent dry test
run, we encountered that several of our external websites could not connect
to retrieve data.  I was able to find unirpcd and get the daemon started,
but I also need to get uniobjects running for some of our other
applications.  Where would I find this to get it running and or could
someone point me in the right direction? 

 

As mentioned, I've never administered Universe before and my predecessors
documentation is non-existent.

 

Thanks in advance,

 

Juan Carlos Ocasio CCNA 
Network Planning Manager
Information Technology Department 
County of El Paso 
800 E Overland, Rm 401 
El Paso, TX 79901 
(915) 546-2041   ext 3385
(915) 546-2042  Fax 

(915) 929-0630   Mobile
  Mailto:jcoca...@epcounty.com

 

 

Envirionment info:

HP-UX 11.31

Universe 10.2.11

 

 

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] POS System

[Glen Batchelor]

 

  DDI System uses mostly uniobjects for GUI apps now. Their old green screen
software is what our system was built from/around. Ask for Adam Waller and
mention that I referred you. If you want to talk features, tech, and
integration then he's the contact you want.

 

www.ddisys.com


Glen Batchelor
IT Director
All-Spec Industries
 phone: (910) 332-0424
   fax: (910) 763-5664
E-mail: webmas...@all-spec.com
   Web: http://www.all-spec.com
  Blog: http://blog.all-spec.com


  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Norman Bauer
Sent: Wednesday, June 10, 2009 8:32 AM
To: U2 Users List
Subject: [U2] POS System

 

Does anyone know of a point-of-sale system that uses UniVerse?

 

Thanks,

 

Norm

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] POS System

[Norman Bauer]

Thank you all so much for the wonderful leads.
Norm

On Thu, Jun 11, 2009 at 2:04 PM, doug chanco  wrote:

> I used to work at Activant and Eagle (if I remember right) uses a cobal
> backend.  They do sell Vision/Ultimate (which use a pick database, one is
> unidata and the other is jbase/ultplus) but they are for NOT for small
> retail businesses, I believe they have Adis/Jcon for that (neither use a
> pick database)
>
> They do sell AconneX which allows different Activant (and non Activant)
> systems "talk" to each other
>
> dougc
>
>
>
> Steve Romanow wrote:
>
>> I think Activant may sell one that if it doesn't run on U2, it is
>> integrated. Eagle I think. Haven't used it, just know it exists.
>> 
>>
>> ___
>> 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
>
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] POS System

[doug chanco]

I used to work at Activant and Eagle (if I remember right) uses a cobal 
backend.  They do sell Vision/Ultimate (which use a pick database, one 
is unidata and the other is jbase/ultplus) but they are for NOT for 
small retail businesses, I believe they have Adis/Jcon for that (neither 
use a pick database)


They do sell AconneX which allows different Activant (and non Activant) 
systems "talk" to each other


dougc



Steve Romanow wrote:
I think Activant may sell one that if it doesn't run on U2, it is 
integrated. Eagle I think. Haven't used it, just know it exists.



___
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] Pick pocket guide

[George Gallen]

We changed the CHOO-CHOO command on our microdata to say
"REALITY, What a concept" (stolen from Robin Williams)

There was always a few good jokes you could make to people
when they asked what you did.

"Manipulating Reality" was my favorite.

George

> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-
> boun...@listserver.u2ug.org] On Behalf Of Jon Sisk
> Sent: Thursday, June 11, 2009 12:39 PM
> To: u2-users@listserver.u2ug.org
> Subject: Re: [U2] Pick pocket guide
>
>
> That one was easier to explain to my parents than my
> previous book, The REALITY Pocket Guide.
>
> They thought I was mixed up in some crazy California
> religious computer cult.
>
> And they were more or less correct.
>
> j.
>
>
> George Gallen-2 wrote:
> >
> > I recently stumbled across this link
> > http://www.jes.com/mvpubs/ppg4.html
> >
> > I love the comment at the bottom, about them being held up or
> confiscated
> > at customs.
> >
> > I remember when I moved from one apartment to another, my wife's two
> > uncles
> > both police officers, were gravely concerned, took me into another
> room
> > and
> > demanded an explaination as why I had a "pick pocket guide". It
> didn't
> > help at
> > the time when I started laughing! saying, it's not a "pick pocket
> guide",
> > but rather
> > it's a "pick, pocket guide".
> >
> > I still wonder to this day, if they really believed it was
> programming
> > reference book.
> >
> >
> >
> >
> >
> >
> >
> > ___
> > U2-Users mailing list
> > U2-Users@listserver.u2ug.org
> > http://listserver.u2ug.org/mailman/listinfo/u2-users
> >
> >
>
>
> -
> http://jes.com On-demand 1 on 1 private training for all MultiValue
> platforms
> and languages.
> --
> View this message in context: http://www.nabble.com/Pick-pocket-guide-
> tp23967575p23984833.html
> Sent from the U2 - Users mailing list archive at Nabble.com.
>
> ___
> 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] Pick pocket guide

[Jon Sisk]

That one was easier to explain to my parents than my
previous book, The REALITY Pocket Guide.

They thought I was mixed up in some crazy California
religious computer cult.

And they were more or less correct.

j.


George Gallen-2 wrote:
> 
> I recently stumbled across this link
> http://www.jes.com/mvpubs/ppg4.html
> 
> I love the comment at the bottom, about them being held up or confiscated
> at customs.
> 
> I remember when I moved from one apartment to another, my wife's two
> uncles
> both police officers, were gravely concerned, took me into another room
> and
> demanded an explaination as why I had a "pick pocket guide". It didn't
> help at
> the time when I started laughing! saying, it's not a "pick pocket guide",
> but rather
> it's a "pick, pocket guide".
> 
> I still wonder to this day, if they really believed it was programming
> reference book.
> 
> 
> 
> 
> 
> 
> 
> ___
> U2-Users mailing list
> U2-Users@listserver.u2ug.org
> http://listserver.u2ug.org/mailman/listinfo/u2-users
> 
> 


-
http://jes.com On-demand 1 on 1 private training for all MultiValue platforms
and languages. 
-- 
View this message in context: 
http://www.nabble.com/Pick-pocket-guide-tp23967575p23984833.html
Sent from the U2 - Users mailing list archive at Nabble.com.

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

[U2] Uni data / uni-objects connectivity

[JC Ocasio]

To all:

I'm fairly new to IBM universe and Unidata and have been tasked 
with upgrading our old PA-RISC to new Itaniums.  Unfortunately we have little 
documentation on the configuration and setup of specific items on our UV  
database (as in unirpcd, uniobjects etc).  In a recent dry test run, we 
encountered that several of our external websites could not connect to retrieve 
data.  I was able to find unirpcd and get the daemon started, but I also need 
to get uniobjects running for some of our other applications.  Where would I 
find this to get it running and or could someone point me in the right 
direction?

As mentioned, I've never administered Universe before and my predecessors 
documentation is non-existent.

Thanks in advance,

Juan Carlos Ocasio CCNA
Network Planning Manager
Information Technology Department
County of El Paso
800 E Overland, Rm 401
El Paso, TX 79901
(915) 546-2041   ext 3385
(915) 546-2042  Fax
(915) 929-0630   Mobile
Mailto:jcoca...@epcounty.com


Envirionment info:
HP-UX 11.31
Universe 10.2.11


___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] UniVerse Unit Testing

[Dave Laansma]

Very interesting ... Hmmm

 

David Laansma

IT Manager
Hubbard Supply Co. 

Direct: 810-342-7143

Office:810-234-8681

Fax: 810-234-6142

www.hubbardsupply.com

"Delivering Products, Services, and Innovative Solutions"

 

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Doug Averch
Sent: Thursday, June 11, 2009 10:52 AM
To: 'U2 Users List'
Subject: Re: [U2] UniVerse Unit Testing

 

Jerry and All,

 

We did something similar to Brian.  All of our Basic code was
re-designed to have 6 arguments: PARAM1, PARAM2, PARAM3, PARAM4,
RETURN.INFO, and METHOD.  That way we could automatically test any
program from any other program by knowing every program had 6 arguments.
For reports PARAM2 was where all of the data was passed in as dynamic
array, the output uses RETURN.INFO.  Entry programs passed the updated
data in on PARAM2 and passed data out on RETURN.INFO using an open
source format called json.  JSON is not as verbose as XML and JavaScript
and Java natively handle the format by converting it to an array.  We
Basic programmers do like to work with arrays of data.

 

We used METHOD to tell subroutine what it should be doing (i.e.
CreateReport, LoadDefaults, ReadData, WriteData, or BuildGrid).  That
way the programs  became very similar in structure.  We had two or three
programs that supported entry screens were all reduced to a single
programmer.

 

We had to learn how debug the Basic code, the JavaScript, and the HTML
code. You cannot use the debugger on the Web.  We developed what we call
a logger, so instead of using a DEBUG statement or the simple CRT
statement to see what the variables are and where you are in the code,
you now call a subroutine that writes to a log that can be viewed either
from Telnet or from our Eclipse based Basic Editor.  Debugging
JavaScript requires a great open source tool called Firebug that runs on
Firefox.

 

We had upwards of 2000 programs running Accounting, CRM, Distribution,
Document Management, Payroll, Transportation, and Warehousing all
running as "green screen" applications  We stripped out all of the
screen I/O which reduced the program to about 1/3 their previous size.
We changed all of the code from whatever they were to subroutines using
our 6 arguments.  Perhaps the most problematic was all of the reports
had to be switch to HTML format.  That process was the most time
consuming due the amount of code that needed to be changed.  However,
this gave us time to reduce the amount of reports we produced.  We
consolidated similar reports into a single report with multiple report
options.

 

Some programs took minutes, some took days and some took weeks.  Some of
the code was over 25 years old and required a complete rewrite because
of the GOTO's and calls to various green screen subroutines that no
longer existed. Since we have customers that run in Universe and Unidata
we had to develop the techniques to run the same code on both platforms.
We develop all of our software on Universe and port to Unidata. Our
Eclipse based Installer comments out the Universe specific code an
uncomments out the Unidata specific code depending on the destination
machine.

 

I should note that our code was first written for RedBack running on
IIS.  I decided after a few years that platform was not going in the
direction we need to go so we ported to our own middleware using open
source Apache Tomcat.

 

We accomplished this over a period of a year with four programmers.  We
now have around 400 programs that run all of our applications listed
above.  We are constantly evolving our interface.  We just switched from
a home grown cross-reference to a open source tool that allows us to
load 50,000 records in under a second and it has built in filtering,
column sorting and paging.  The Web is truly an amazing place where you
can get open source software that we would have spent weeks to months
writing.

 

Regards,

Doug

www.u2logic.com

 



From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jpb-u2ug
Sent: Thursday, June 11, 2009 7:23 AM
To: 'U2 Users List'
Subject: Re: [U2] UniVerse Unit Testing

Doug and Brian,

Could you give me some numbers on how long and how many people (man
hours) it took to do the changes? Approximately how many programs did
you have to convert to the new way and what did you end up with?

 

Jerry Banker

 

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: Thursday, June 11, 2009 7:55 AM
To: U2 Users List
Subject: Re: [U2] UniVerse Unit Testing

 

Brian,

 

You say that you "designed all our server code as subroutines such that
all of our subroutines had one of two calling interfaces".  This would
seem to mean that you built and maintained two different versions of
every external subroutine/function.  Is this correct or am I just
missing something?

 

T

Re: [U2] UniVerse Unit Testing

[Doug Averch]

Jerry and All,
 
We did something similar to Brian.  All of our Basic code was re-designed to
have 6 arguments: PARAM1, PARAM2, PARAM3, PARAM4, RETURN.INFO, and METHOD.
That way we could automatically test any program from any other program by
knowing every program had 6 arguments.  For reports PARAM2 was where all of
the data was passed in as dynamic array, the output uses RETURN.INFO.  Entry
programs passed the updated data in on PARAM2 and passed data out on
RETURN.INFO using an open source format called json.  JSON is not as verbose
as XML and JavaScript and Java natively handle the format by converting it
to an array.  We Basic programmers do like to work with arrays of data.
 
We used METHOD to tell subroutine what it should be doing (i.e.
CreateReport, LoadDefaults, ReadData, WriteData, or BuildGrid).  That way
the programs  became very similar in structure.  We had two or three
programs that supported entry screens were all reduced to a single
programmer.
 
We had to learn how debug the Basic code, the JavaScript, and the HTML code.
You cannot use the debugger on the Web.  We developed what we call a logger,
so instead of using a DEBUG statement or the simple CRT statement to see
what the variables are and where you are in the code, you now call a
subroutine that writes to a log that can be viewed either from Telnet or
from our Eclipse based Basic Editor.  Debugging JavaScript requires a great
open source tool called Firebug that runs on Firefox.
 
We had upwards of 2000 programs running Accounting, CRM, Distribution,
Document Management, Payroll, Transportation, and Warehousing all running as
"green screen" applications  We stripped out all of the screen I/O which
reduced the program to about 1/3 their previous size.  We changed all of the
code from whatever they were to subroutines using our 6 arguments.  Perhaps
the most problematic was all of the reports had to be switch to HTML format.
That process was the most time consuming due the amount of code that needed
to be changed.  However, this gave us time to reduce the amount of reports
we produced.  We consolidated similar reports into a single report with
multiple report options.
 
Some programs took minutes, some took days and some took weeks.  Some of the
code was over 25 years old and required a complete rewrite because of the
GOTO's and calls to various green screen subroutines that no longer existed.
Since we have customers that run in Universe and Unidata we had to develop
the techniques to run the same code on both platforms.  We develop all of
our software on Universe and port to Unidata. Our Eclipse based Installer
comments out the Universe specific code an uncomments out the Unidata
specific code depending on the destination machine.
 
I should note that our code was first written for RedBack running on IIS.  I
decided after a few years that platform was not going in the direction we
need to go so we ported to our own middleware using open source Apache
Tomcat.
 
We accomplished this over a period of a year with four programmers.  We now
have around 400 programs that run all of our applications listed above.  We
are constantly evolving our interface.  We just switched from a home grown
cross-reference to a open source tool that allows us to load 50,000 records
in under a second and it has built in filtering, column sorting and paging.
The Web is truly an amazing place where you can get open source software
that we would have spent weeks to months writing.
 
Regards,
Doug
www.u2logic.com

  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jpb-u2ug
Sent: Thursday, June 11, 2009 7:23 AM
To: 'U2 Users List'
Subject: Re: [U2] UniVerse Unit Testing



Doug and Brian,

Could you give me some numbers on how long and how many people (man hours)
it took to do the changes? Approximately how many programs did you have to
convert to the new way and what did you end up with?

 

Jerry Banker

 

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: Thursday, June 11, 2009 7:55 AM
To: U2 Users List
Subject: Re: [U2] UniVerse Unit Testing

 

Brian,

 

You say that you "designed all our server code as subroutines such that all
of our subroutines had one of two calling interfaces".  This would seem to
mean that you built and maintained two different versions of every external
subroutine/function.  Is this correct or am I just missing something?

 

Thanks.

 

Perry

 

  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Thursday, June 11, 2009 3:19 AM
To: 'U2 Users List'
Subject: Re: [U2] UniVerse Unit Testing

Hi

 

 

At my last company, we spent a lot of effort on building an automated test
rig for our software, because we had to support multiple platforms and all
our code required full regression testing. It may be a slightly different
scen

Re: [U2] UniVerse Unit

[Susan Joslyn]

unction.  Is this correct or am I just missing something?
 
Thanks.
 
Perry

  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Thursday, June 11, 2009 3:19 AM
To: 'U2 Users List'
Subject: Re: [U2] UniVerse Unit Testing


Hi
 
 
At my last company, we spent a lot of effort on building an automated
test
rig for our software, because we had to support multiple platforms and
all
our code required full regression testing. It may be a slightly
different
scenario to yours, since we were primarily building tools, and also this
was
complicated by the fact that all of our software was client/server in
some
way, and usually involved several languages .. but here is our
experience
for what it's worth:
 
 
The bad news is that you really need to design these in from the start.
 
We designed all our server code as subroutines such that all of our
subroutines had one of two calling interfaces, either:
 
Subroutine name(InData, OutData, ErrText)
 
or
 
Subroutine name(Action, InData, OutData, ErrText)
 
That meant that we could generate a test rig that could feed the InData
(and
Action) and then test for the OutData and log any ErrText values.
For reports, we would capture the report text and do 'spot checks' on
the
expected results.
 
 
We also version stamped our routines, so we were certain we were testing
the
right versions, and had build scripts to recompile everything. Nothing
left
to manual operation since that opens up the opportunity for something to
get
forgotten: there is no point testing stuff to QA and then doing
something
different when you come to release! Incidentally, since this was
client/server, these involved VBScript scripts for the client end
calling
cutting paragraphs on the server along the line.
 
 
Because Universe code doesn't break down into simple blocks, unless you
want
to instrument your code and capture all your file I/O - which is
possible -
and test for that, your only sensible option is to unit test at the
subroutine/external function level.
 
 
The good news is that because UniVerse caches subroutines in memory, the
overheads to breaking out code are not as high as on systems that do
not. it
also means you end up with a more manageable system, better options for
reuse and if you adopt different client front ends, easier to migrate.
You
may also find out that your code mass reduces as you split these out,
because there is less duplication (sorry if I'm stating the obvious
here)
and so your testing domain is reduced also.
 
 
If you want clean-room regression testing, I highly recommend Virtual PC
is
it will support your OS. We kept clean images of all the platforms we
supported, which was a huge time saver. One nice thing about VPC is that
it
supports 'undo disks' which means that you can snapshot the image at a
particular point, and then any changes e.g. brought on by software loads
for
testing are physically and transparently stored outside the virtual disk
and
you choose at the end whether to commit those changes or not, making it
very
easy to go back if that version didn't pass.
 
 
Finallly, having a predictable way to load routines from dev to QA and
from
QA to live is a must - so I'll put in a very small [AD] for
mvInstaller...
 
Regards
 
Brian
 
 


  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: 10 June 2009 20:33
To: u2-users@listserver.u2ug.org
Subject: [U2] UniVerse Unit Testing



The powers that be have been discussing the possibility of going to a
unit
test model for QA.  As I understand the concept, portions of code are
broken
down into smaller manageable chunks against which a dedicated unit test
for
each may be run.  This seems like a good idea in an object oriented
world
where methods of object can be easily invoked.  This would seem less
practical in with a procedural language like BASIC.

It feels like we would end up breaking out thousands of lines of code
into
external subroutines which could then be run through a dedicated unit
test.
This would introduce significant overhead with all the CALLs to hundreds
(thousands) of external subroutines.  Then there are complications such
as
variables in named common, etc.

Is anyone out there in MV land employing serious unit testing?  If so,
care
to share your experiences, concerns, success stories?

Thanks. 

Perry Taylor 
Zirmed, Inc. 

-- next part --
An HTML attachment was scrubbed...
URL:
<http://listserver.u2ug.org/pipermail/u2-users/attachments/20090611/2231
3a8b
/attachment-0001.html>

--

Message: 2
Date: Thu, 11 Jun 2009 14:56:15 +0100
From: "Brian Leach" 
To: "'U2 Users List'" 
Subject: Re: [U2] UniVerse Unit Testing
Message-ID: <0mkt2u-1meklu0yek-000...@mrelayeu.kundenserver.de>
Content-Type: text/plain

Re: [U2] UniVerse Admin Tool for Window

[Anthony W. Youngman]

In message 
, Amy 
Raisanen  writes


I had the same issue happen.  I had upgraded Universe to 10.2.10 on Windows 
then installed UniAdmin. None of the locks or users showed in
Uniadmin, when I contacted support on the issue they suggested I back down a 
version of Uniadmin.  I think the bad version was either 1.3.6 or
1.3.7.  We did back down a version to get the functionality back but have since 
upgraded to 1.3.8 and those now things work fine.


If that's the case, might it be an idea to download the latest 
"evaluation" client CD from the IBM website? I *don't* *think* the 
client tools are timebombed.


Just don't install them on the server itself unless someone at IBM 
confirms that's not a problem :-)


Cheers,
Wol
--
Anthony W. Youngman 
'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man
lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
Visit the MaVerick web-site -  Open Source Pick
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] UniVerse Unit

[Dave Laansma]

 was
client/server, these involved VBScript scripts for the client end
calling
cutting paragraphs on the server along the line.
 
 
Because Universe code doesn't break down into simple blocks, unless you
want
to instrument your code and capture all your file I/O - which is
possible -
and test for that, your only sensible option is to unit test at the
subroutine/external function level.
 
 
The good news is that because UniVerse caches subroutines in memory, the
overheads to breaking out code are not as high as on systems that do
not. it
also means you end up with a more manageable system, better options for
reuse and if you adopt different client front ends, easier to migrate.
You
may also find out that your code mass reduces as you split these out,
because there is less duplication (sorry if I'm stating the obvious
here)
and so your testing domain is reduced also.
 
 
If you want clean-room regression testing, I highly recommend Virtual PC
is
it will support your OS. We kept clean images of all the platforms we
supported, which was a huge time saver. One nice thing about VPC is that
it
supports 'undo disks' which means that you can snapshot the image at a
particular point, and then any changes e.g. brought on by software loads
for
testing are physically and transparently stored outside the virtual disk
and
you choose at the end whether to commit those changes or not, making it
very
easy to go back if that version didn't pass.
 
 
Finallly, having a predictable way to load routines from dev to QA and
from
QA to live is a must - so I'll put in a very small [AD] for
mvInstaller...
 
Regards
 
Brian
 
 


  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: 10 June 2009 20:33
To: u2-users@listserver.u2ug.org
Subject: [U2] UniVerse Unit Testing



The powers that be have been discussing the possibility of going to a
unit
test model for QA.  As I understand the concept, portions of code are
broken
down into smaller manageable chunks against which a dedicated unit test
for
each may be run.  This seems like a good idea in an object oriented
world
where methods of object can be easily invoked.  This would seem less
practical in with a procedural language like BASIC.

It feels like we would end up breaking out thousands of lines of code
into
external subroutines which could then be run through a dedicated unit
test.
This would introduce significant overhead with all the CALLs to hundreds
(thousands) of external subroutines.  Then there are complications such
as
variables in named common, etc.

Is anyone out there in MV land employing serious unit testing?  If so,
care
to share your experiences, concerns, success stories?

Thanks. 

Perry Taylor 
Zirmed, Inc. 

-- next part --
An HTML attachment was scrubbed...
URL:
<http://listserver.u2ug.org/pipermail/u2-users/attachments/20090611/2231
3a8b
/attachment-0001.html>

--

Message: 2
Date: Thu, 11 Jun 2009 14:56:15 +0100
From: "Brian Leach" 
To: "'U2 Users List'" 
Subject: Re: [U2] UniVerse Unit Testing
Message-ID: <0mkt2u-1meklu0yek-000...@mrelayeu.kundenserver.de>
Content-Type: text/plain; charset="us-ascii"

Hi Jerry
 
Like I said, we designed our software from the ground up to fit this
scheme,
so there wasn't any conversion involved.
The result of having been bitten by a previous piece of development that
had
grown ugly..
 
Brian


  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jpb-u2ug
Sent: 11 June 2009 14:23
To: 'U2 Users List'
Subject: Re: [U2] UniVerse Unit Testing



Doug and Brian,

Could you give me some numbers on how long and how many people (man
hours)
it took to do the changes? Approximately how many programs did you have
to
convert to the new way and what did you end up with?

 

Jerry Banker

 

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: Thursday, June 11, 2009 7:55 AM
To: U2 Users List
Subject: Re: [U2] UniVerse Unit Testing

 

Brian,

 

You say that you "designed all our server code as subroutines such that
all
of our subroutines had one of two calling interfaces".  This would seem
to
mean that you built and maintained two different versions of every
external
subroutine/function.  Is this correct or am I just missing something?

 

Thanks.

 

Perry

 

  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Thursday, June 11, 2009 3:19 AM
To: 'U2 Users List'
Subject: Re: [U2] UniVerse Unit Testing

Hi

 

 

At my last company, we spent a lot of effort on building an automated
test
rig for our software, because we had to support multiple platforms and
all
our code required full regress

Re: [U2] UniVerse Unit

[Susan Joslyn]

use and if you adopt different client front ends, easier to migrate. You
may also find out that your code mass reduces as you split these out,
because there is less duplication (sorry if I'm stating the obvious here)
and so your testing domain is reduced also.
 
 
If you want clean-room regression testing, I highly recommend Virtual PC is
it will support your OS. We kept clean images of all the platforms we
supported, which was a huge time saver. One nice thing about VPC is that it
supports 'undo disks' which means that you can snapshot the image at a
particular point, and then any changes e.g. brought on by software loads for
testing are physically and transparently stored outside the virtual disk and
you choose at the end whether to commit those changes or not, making it very
easy to go back if that version didn't pass.
 
 
Finallly, having a predictable way to load routines from dev to QA and from
QA to live is a must - so I'll put in a very small [AD] for mvInstaller...
 
Regards
 
Brian
 
 


  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: 10 June 2009 20:33
To: u2-users@listserver.u2ug.org
Subject: [U2] UniVerse Unit Testing



The powers that be have been discussing the possibility of going to a unit
test model for QA.  As I understand the concept, portions of code are broken
down into smaller manageable chunks against which a dedicated unit test for
each may be run.  This seems like a good idea in an object oriented world
where methods of object can be easily invoked.  This would seem less
practical in with a procedural language like BASIC.

It feels like we would end up breaking out thousands of lines of code into
external subroutines which could then be run through a dedicated unit test.
This would introduce significant overhead with all the CALLs to hundreds
(thousands) of external subroutines.  Then there are complications such as
variables in named common, etc.

Is anyone out there in MV land employing serious unit testing?  If so, care
to share your experiences, concerns, success stories?

Thanks. 

Perry Taylor 
Zirmed, Inc. 

-- next part --
An HTML attachment was scrubbed...
URL:
<http://listserver.u2ug.org/pipermail/u2-users/attachments/20090611/22313a8b
/attachment-0001.html>

--

Message: 2
Date: Thu, 11 Jun 2009 14:56:15 +0100
From: "Brian Leach" 
To: "'U2 Users List'" 
Subject: Re: [U2] UniVerse Unit Testing
Message-ID: <0mkt2u-1meklu0yek-000...@mrelayeu.kundenserver.de>
Content-Type: text/plain; charset="us-ascii"

Hi Jerry
 
Like I said, we designed our software from the ground up to fit this scheme,
so there wasn't any conversion involved.
The result of having been bitten by a previous piece of development that had
grown ugly..
 
Brian


  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jpb-u2ug
Sent: 11 June 2009 14:23
To: 'U2 Users List'
Subject: Re: [U2] UniVerse Unit Testing



Doug and Brian,

Could you give me some numbers on how long and how many people (man hours)
it took to do the changes? Approximately how many programs did you have to
convert to the new way and what did you end up with?

 

Jerry Banker

 

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: Thursday, June 11, 2009 7:55 AM
To: U2 Users List
Subject: Re: [U2] UniVerse Unit Testing

 

Brian,

 

You say that you "designed all our server code as subroutines such that all
of our subroutines had one of two calling interfaces".  This would seem to
mean that you built and maintained two different versions of every external
subroutine/function.  Is this correct or am I just missing something?

 

Thanks.

 

Perry

 

  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Thursday, June 11, 2009 3:19 AM
To: 'U2 Users List'
Subject: Re: [U2] UniVerse Unit Testing

Hi

 

 

At my last company, we spent a lot of effort on building an automated test
rig for our software, because we had to support multiple platforms and all
our code required full regression testing. It may be a slightly different
scenario to yours, since we were primarily building tools, and also this was
complicated by the fact that all of our software was client/server in some
way, and usually involved several languages .. but here is our experience
for what it's worth:

 

 

The bad news is that you really need to design these in from the start.

 

We designed all our server code as subroutines such that all of our
subroutines had one of two calling interfaces, either:

 

Subroutine name(InData, OutData, ErrText)

 

or

 

Subroutine name(Action, InData, OutData, ErrText)

 

That meant th

Re: [U2] UniVerse Unit Testing

[Brian Leach]

Hi Jerry
 
Like I said, we designed our software from the ground up to fit this scheme,
so there wasn't any conversion involved.
The result of having been bitten by a previous piece of development that had
grown ugly..
 
Brian


  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jpb-u2ug
Sent: 11 June 2009 14:23
To: 'U2 Users List'
Subject: Re: [U2] UniVerse Unit Testing



Doug and Brian,

Could you give me some numbers on how long and how many people (man hours)
it took to do the changes? Approximately how many programs did you have to
convert to the new way and what did you end up with?

 

Jerry Banker

 

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: Thursday, June 11, 2009 7:55 AM
To: U2 Users List
Subject: Re: [U2] UniVerse Unit Testing

 

Brian,

 

You say that you "designed all our server code as subroutines such that all
of our subroutines had one of two calling interfaces".  This would seem to
mean that you built and maintained two different versions of every external
subroutine/function.  Is this correct or am I just missing something?

 

Thanks.

 

Perry

 

  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Thursday, June 11, 2009 3:19 AM
To: 'U2 Users List'
Subject: Re: [U2] UniVerse Unit Testing

Hi

 

 

At my last company, we spent a lot of effort on building an automated test
rig for our software, because we had to support multiple platforms and all
our code required full regression testing. It may be a slightly different
scenario to yours, since we were primarily building tools, and also this was
complicated by the fact that all of our software was client/server in some
way, and usually involved several languages .. but here is our experience
for what it's worth:

 

 

The bad news is that you really need to design these in from the start.

 

We designed all our server code as subroutines such that all of our
subroutines had one of two calling interfaces, either:

 

Subroutine name(InData, OutData, ErrText)

 

or

 

Subroutine name(Action, InData, OutData, ErrText)

 

That meant that we could generate a test rig that could feed the InData (and
Action) and then test for the OutData and log any ErrText values.

For reports, we would capture the report text and do 'spot checks' on the
expected results.

 

 

We also version stamped our routines, so we were certain we were testing the
right versions, and had build scripts to recompile everything. Nothing left
to manual operation since that opens up the opportunity for something to get
forgotten: there is no point testing stuff to QA and then doing something
different when you come to release! Incidentally, since this was
client/server, these involved VBScript scripts for the client end calling
cutting paragraphs on the server along the line.

 

 

Because Universe code doesn't break down into simple blocks, unless you want
to instrument your code and capture all your file I/O - which is possible -
and test for that, your only sensible option is to unit test at the
subroutine/external function level.

 

 

The good news is that because UniVerse caches subroutines in memory, the
overheads to breaking out code are not as high as on systems that do not. it
also means you end up with a more manageable system, better options for
reuse and if you adopt different client front ends, easier to migrate. You
may also find out that your code mass reduces as you split these out,
because there is less duplication (sorry if I'm stating the obvious here)
and so your testing domain is reduced also.

 

 

If you want clean-room regression testing, I highly recommend Virtual PC is
it will support your OS. We kept clean images of all the platforms we
supported, which was a huge time saver. One nice thing about VPC is that it
supports 'undo disks' which means that you can snapshot the image at a
particular point, and then any changes e.g. brought on by software loads for
testing are physically and transparently stored outside the virtual disk and
you choose at the end whether to commit those changes or not, making it very
easy to go back if that version didn't pass.

 

 

Finallly, having a predictable way to load routines from dev to QA and from
QA to live is a must - so I'll put in a very small [AD] for mvInstaller...

 

Regards

 

Brian

 

 

 

  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: 10 June 2009 20:33
To: u2-users@listserver.u2ug.org
Subject: [U2] UniVerse Unit Testing

The powers that be have been discussing the possibility of going to a unit
test model for QA.  As I understand the concept, portions of code are broken
down into smaller manageable chunks against which a dedicated unit test for
each may be run.  This seems like a good i

Re: [U2] UniVerse Unit Testing

[Brian Leach]

Hi Perry,
 
No - most of the internally used routines had the shorter calling interface,
externally facing ones used the extra 'Action' parameter so we could always
extend them whilst retaining backward compatibilty.
 
Regards
 
Brian


  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: 11 June 2009 13:55
To: U2 Users List
Subject: Re: [U2] UniVerse Unit Testing


Brian,
 
You say that you "designed all our server code as subroutines such that all
of our subroutines had one of two calling interfaces".  This would seem to
mean that you built and maintained two different versions of every external
subroutine/function.  Is this correct or am I just missing something?
 
Thanks.
 
Perry

  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Thursday, June 11, 2009 3:19 AM
To: 'U2 Users List'
Subject: Re: [U2] UniVerse Unit Testing


Hi
 
 
At my last company, we spent a lot of effort on building an automated test
rig for our software, because we had to support multiple platforms and all
our code required full regression testing. It may be a slightly different
scenario to yours, since we were primarily building tools, and also this was
complicated by the fact that all of our software was client/server in some
way, and usually involved several languages .. but here is our experience
for what it's worth:
 
 
The bad news is that you really need to design these in from the start.
 
We designed all our server code as subroutines such that all of our
subroutines had one of two calling interfaces, either:
 
Subroutine name(InData, OutData, ErrText)
 
or
 
Subroutine name(Action, InData, OutData, ErrText)
 
That meant that we could generate a test rig that could feed the InData (and
Action) and then test for the OutData and log any ErrText values.
For reports, we would capture the report text and do 'spot checks' on the
expected results.
 
 
We also version stamped our routines, so we were certain we were testing the
right versions, and had build scripts to recompile everything. Nothing left
to manual operation since that opens up the opportunity for something to get
forgotten: there is no point testing stuff to QA and then doing something
different when you come to release! Incidentally, since this was
client/server, these involved VBScript scripts for the client end calling
cutting paragraphs on the server along the line.
 
 
Because Universe code doesn't break down into simple blocks, unless you want
to instrument your code and capture all your file I/O - which is possible -
and test for that, your only sensible option is to unit test at the
subroutine/external function level.
 
 
The good news is that because UniVerse caches subroutines in memory, the
overheads to breaking out code are not as high as on systems that do not. it
also means you end up with a more manageable system, better options for
reuse and if you adopt different client front ends, easier to migrate. You
may also find out that your code mass reduces as you split these out,
because there is less duplication (sorry if I'm stating the obvious here)
and so your testing domain is reduced also.
 
 
If you want clean-room regression testing, I highly recommend Virtual PC is
it will support your OS. We kept clean images of all the platforms we
supported, which was a huge time saver. One nice thing about VPC is that it
supports 'undo disks' which means that you can snapshot the image at a
particular point, and then any changes e.g. brought on by software loads for
testing are physically and transparently stored outside the virtual disk and
you choose at the end whether to commit those changes or not, making it very
easy to go back if that version didn't pass.
 
 
Finallly, having a predictable way to load routines from dev to QA and from
QA to live is a must - so I'll put in a very small [AD] for mvInstaller...
 
Regards
 
Brian
 
 


  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: 10 June 2009 20:33
To: u2-users@listserver.u2ug.org
Subject: [U2] UniVerse Unit Testing



The powers that be have been discussing the possibility of going to a unit
test model for QA.  As I understand the concept, portions of code are broken
down into smaller manageable chunks against which a dedicated unit test for
each may be run.  This seems like a good idea in an object oriented world
where methods of object can be easily invoked.  This would seem less
practical in with a procedural language like BASIC.

It feels like we would end up breaking out thousands of lines of code into
external subroutines which could then be run through a dedicated unit test.
This would introduce significant overhead with all the CALLs to hundreds
(thousands) of external subroutines.  Then there are complications such as
variables in named common, etc.

Is anyo

Re: [U2] UniVerse Unit Testing

[jpb-u2ug]

Doug and Brian,

Could you give me some numbers on how long and how many people (man hours)
it took to do the changes? Approximately how many programs did you have to
convert to the new way and what did you end up with?

 

Jerry Banker

 

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: Thursday, June 11, 2009 7:55 AM
To: U2 Users List
Subject: Re: [U2] UniVerse Unit Testing

 

Brian,

 

You say that you "designed all our server code as subroutines such that all
of our subroutines had one of two calling interfaces".  This would seem to
mean that you built and maintained two different versions of every external
subroutine/function.  Is this correct or am I just missing something?

 

Thanks.

 

Perry

 

  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Thursday, June 11, 2009 3:19 AM
To: 'U2 Users List'
Subject: Re: [U2] UniVerse Unit Testing

Hi

 

 

At my last company, we spent a lot of effort on building an automated test
rig for our software, because we had to support multiple platforms and all
our code required full regression testing. It may be a slightly different
scenario to yours, since we were primarily building tools, and also this was
complicated by the fact that all of our software was client/server in some
way, and usually involved several languages .. but here is our experience
for what it's worth:

 

 

The bad news is that you really need to design these in from the start.

 

We designed all our server code as subroutines such that all of our
subroutines had one of two calling interfaces, either:

 

Subroutine name(InData, OutData, ErrText)

 

or

 

Subroutine name(Action, InData, OutData, ErrText)

 

That meant that we could generate a test rig that could feed the InData (and
Action) and then test for the OutData and log any ErrText values.

For reports, we would capture the report text and do 'spot checks' on the
expected results.

 

 

We also version stamped our routines, so we were certain we were testing the
right versions, and had build scripts to recompile everything. Nothing left
to manual operation since that opens up the opportunity for something to get
forgotten: there is no point testing stuff to QA and then doing something
different when you come to release! Incidentally, since this was
client/server, these involved VBScript scripts for the client end calling
cutting paragraphs on the server along the line.

 

 

Because Universe code doesn't break down into simple blocks, unless you want
to instrument your code and capture all your file I/O - which is possible -
and test for that, your only sensible option is to unit test at the
subroutine/external function level.

 

 

The good news is that because UniVerse caches subroutines in memory, the
overheads to breaking out code are not as high as on systems that do not. it
also means you end up with a more manageable system, better options for
reuse and if you adopt different client front ends, easier to migrate. You
may also find out that your code mass reduces as you split these out,
because there is less duplication (sorry if I'm stating the obvious here)
and so your testing domain is reduced also.

 

 

If you want clean-room regression testing, I highly recommend Virtual PC is
it will support your OS. We kept clean images of all the platforms we
supported, which was a huge time saver. One nice thing about VPC is that it
supports 'undo disks' which means that you can snapshot the image at a
particular point, and then any changes e.g. brought on by software loads for
testing are physically and transparently stored outside the virtual disk and
you choose at the end whether to commit those changes or not, making it very
easy to go back if that version didn't pass.

 

 

Finallly, having a predictable way to load routines from dev to QA and from
QA to live is a must - so I'll put in a very small [AD] for mvInstaller...

 

Regards

 

Brian

 

 

 

  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: 10 June 2009 20:33
To: u2-users@listserver.u2ug.org
Subject: [U2] UniVerse Unit Testing

The powers that be have been discussing the possibility of going to a unit
test model for QA.  As I understand the concept, portions of code are broken
down into smaller manageable chunks against which a dedicated unit test for
each may be run.  This seems like a good idea in an object oriented world
where methods of object can be easily invoked.  This would seem less
practical in with a procedural language like BASIC.

It feels like we would end up breaking out thousands of lines of code into
external subroutines which could then be run through a dedicated unit test.
This would introduce significant overhead with all the CALLs to hundreds
(thousands) of external subroutines.  Then there are complica

Re: [U2] POS System

[Ross Ferris]

G'day Norm,

 

We have a GUI POS and/or Green Screen system that may fit the bill
(http://www.stamina.com.au/R5/PointOfSale.htm), but of course "POS" can
cross multiple boundaries (Stock, General Ledger, Debtors etc), so I
fear there are more aspects of "what you are looking for" that you need
to share or discuss (eg: do online sales & "Ecommerce" functionality fit
into your definition of "POS"? Do you need to issue/manage gift
vouchers? How about "Frequent Buyer" or "Loyalty Club" processing?
Staggered deliveries for building trade products for "customer
selections" ?)

 

We have clients that operate across a reasonably broad array of product
and industry sectors - happy to discuss options & your needs
offline/direct

 

 

 

Ross Ferris

Stamina Software

Visage > Better by Design!

 

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Norman Bauer
Sent: Wednesday, 10 June 2009 10:32 PM
To: U2 Users List
Subject: [U2] POS System

 

Does anyone know of a point-of-sale system that uses UniVerse?

 

Thanks,

 

Norm

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] UniVerse Unit Testing

[Perry Taylor]

Brian,
 
You say that you "designed all our server code as subroutines such that
all of our subroutines had one of two calling interfaces".  This would
seem to mean that you built and maintained two different versions of
every external subroutine/function.  Is this correct or am I just
missing something?
 
Thanks.
 
Perry



From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Thursday, June 11, 2009 3:19 AM
To: 'U2 Users List'
Subject: Re: [U2] UniVerse Unit Testing


Hi
 
 
At my last company, we spent a lot of effort on building an automated
test rig for our software, because we had to support multiple platforms
and all our code required full regression testing. It may be a slightly
different scenario to yours, since we were primarily building tools, and
also this was complicated by the fact that all of our software was
client/server in some way, and usually involved several languages .. but
here is our experience for what it's worth:
 
 
The bad news is that you really need to design these in from the start.
 
We designed all our server code as subroutines such that all of our
subroutines had one of two calling interfaces, either:
 
Subroutine name(InData, OutData, ErrText)
 
or
 
Subroutine name(Action, InData, OutData, ErrText)
 
That meant that we could generate a test rig that could feed the InData
(and Action) and then test for the OutData and log any ErrText values.
For reports, we would capture the report text and do 'spot checks' on
the expected results.
 
 
We also version stamped our routines, so we were certain we were testing
the right versions, and had build scripts to recompile everything.
Nothing left to manual operation since that opens up the opportunity for
something to get forgotten: there is no point testing stuff to QA and
then doing something different when you come to release! Incidentally,
since this was client/server, these involved VBScript scripts for the
client end calling cutting paragraphs on the server along the line.
 
 
Because Universe code doesn't break down into simple blocks, unless you
want to instrument your code and capture all your file I/O - which is
possible - and test for that, your only sensible option is to unit test
at the subroutine/external function level.
 
 
The good news is that because UniVerse caches subroutines in memory, the
overheads to breaking out code are not as high as on systems that do
not. it also means you end up with a more manageable system, better
options for reuse and if you adopt different client front ends, easier
to migrate. You may also find out that your code mass reduces as you
split these out, because there is less duplication (sorry if I'm stating
the obvious here) and so your testing domain is reduced also.
 
 
If you want clean-room regression testing, I highly recommend Virtual PC
is it will support your OS. We kept clean images of all the platforms we
supported, which was a huge time saver. One nice thing about VPC is that
it supports 'undo disks' which means that you can snapshot the image at
a particular point, and then any changes e.g. brought on by software
loads for testing are physically and transparently stored outside the
virtual disk and you choose at the end whether to commit those changes
or not, making it very easy to go back if that version didn't pass.
 
 
Finallly, having a predictable way to load routines from dev to QA and
from QA to live is a must - so I'll put in a very small [AD] for
mvInstaller...
 
Regards
 
Brian
 
 




From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: 10 June 2009 20:33
To: u2-users@listserver.u2ug.org
Subject: [U2] UniVerse Unit Testing



The powers that be have been discussing the possibility of going
to a unit test model for QA.  As I understand the concept, portions of
code are broken down into smaller manageable chunks against which a
dedicated unit test for each may be run.  This seems like a good idea in
an object oriented world where methods of object can be easily invoked.
This would seem less practical in with a procedural language like BASIC.

It feels like we would end up breaking out thousands of lines of
code into external subroutines which could then be run through a
dedicated unit test.  This would introduce significant overhead with all
the CALLs to hundreds (thousands) of external subroutines.  Then there
are complications such as variables in named common, etc.

Is anyone out there in MV land employing serious unit testing?
If so, care to share your experiences, concerns, success stories?

Thanks. 

Perry Taylor 
Zirmed, Inc. 

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u

Re: [U2] UniVerse Unit Testing

[Brian Leach]

Hi
 
 
At my last company, we spent a lot of effort on building an automated test
rig for our software, because we had to support multiple platforms and all
our code required full regression testing. It may be a slightly different
scenario to yours, since we were primarily building tools, and also this was
complicated by the fact that all of our software was client/server in some
way, and usually involved several languages .. but here is our experience
for what it's worth:
 
 
The bad news is that you really need to design these in from the start.
 
We designed all our server code as subroutines such that all of our
subroutines had one of two calling interfaces, either:
 
Subroutine name(InData, OutData, ErrText)
 
or
 
Subroutine name(Action, InData, OutData, ErrText)
 
That meant that we could generate a test rig that could feed the InData (and
Action) and then test for the OutData and log any ErrText values.
For reports, we would capture the report text and do 'spot checks' on the
expected results.
 
 
We also version stamped our routines, so we were certain we were testing the
right versions, and had build scripts to recompile everything. Nothing left
to manual operation since that opens up the opportunity for something to get
forgotten: there is no point testing stuff to QA and then doing something
different when you come to release! Incidentally, since this was
client/server, these involved VBScript scripts for the client end calling
cutting paragraphs on the server along the line.
 
 
Because Universe code doesn't break down into simple blocks, unless you want
to instrument your code and capture all your file I/O - which is possible -
and test for that, your only sensible option is to unit test at the
subroutine/external function level.
 
 
The good news is that because UniVerse caches subroutines in memory, the
overheads to breaking out code are not as high as on systems that do not. it
also means you end up with a more manageable system, better options for
reuse and if you adopt different client front ends, easier to migrate. You
may also find out that your code mass reduces as you split these out,
because there is less duplication (sorry if I'm stating the obvious here)
and so your testing domain is reduced also.
 
 
If you want clean-room regression testing, I highly recommend Virtual PC is
it will support your OS. We kept clean images of all the platforms we
supported, which was a huge time saver. One nice thing about VPC is that it
supports 'undo disks' which means that you can snapshot the image at a
particular point, and then any changes e.g. brought on by software loads for
testing are physically and transparently stored outside the virtual disk and
you choose at the end whether to commit those changes or not, making it very
easy to go back if that version didn't pass.
 
 
Finallly, having a predictable way to load routines from dev to QA and from
QA to live is a must - so I'll put in a very small [AD] for mvInstaller...
 
Regards
 
Brian
 
 


  _  

From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor
Sent: 10 June 2009 20:33
To: u2-users@listserver.u2ug.org
Subject: [U2] UniVerse Unit Testing



The powers that be have been discussing the possibility of going to a unit
test model for QA.  As I understand the concept, portions of code are broken
down into smaller manageable chunks against which a dedicated unit test for
each may be run.  This seems like a good idea in an object oriented world
where methods of object can be easily invoked.  This would seem less
practical in with a procedural language like BASIC.

It feels like we would end up breaking out thousands of lines of code into
external subroutines which could then be run through a dedicated unit test.
This would introduce significant overhead with all the CALLs to hundreds
(thousands) of external subroutines.  Then there are complications such as
variables in named common, etc.

Is anyone out there in MV land employing serious unit testing?  If so, care
to share your experiences, concerns, success stories?

Thanks. 

Perry Taylor 
Zirmed, Inc. 

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users