On my Win2K Platform, Add/Remove programs shows that I have the
following installed:

IBM Object Rexx for Windows Development Edition Update 2.1.2.0
IBM Object Rexx for Windows Development Edition Version 2.1

If I try to install the Object Rexx Redist Update package (2.1.2), it
fails because it states that I don't have the Development Edition 2.1
or higher installed.

When I enter "Rexx /Ver" at a command prompt I get:

  IBM Object REXX Interpreter Version 2.1.2
  Build date: Dec  2 2002
  Copyright (c) IBM Corporation 1996, 2002. All Rights Reserved.

Clearly Object Rexx is confused (the above information suggests to me
that the version information was stored in multiple places instead of
in a single location).  Any ideas how I can get it unconfused?  Right
now I can't distribute updated code in tokenized form because I'm at
2.1.2 and the Runtime installed on my client PCs is at 2.1 (and no,
I'm not going back).

Thanks,
Mike

Mike Pringle wrote:

> On my Win2K Platform, Add/Remove programs shows that I have the
> following installed:
> 
> IBM Object Rexx for Windows Development Edition Update 2.1.2.0

Ah, your answer is right there.... IBM's update "messes up" the MSI database to where the remove does not work right / clean, reinstall is not successful, and other various negative results. Setting 
RxAPI as a service (which you do yourself) further complicates this mess.

Personally, I repackage all three flavours of Object REXX and do not use IBM's MSI installer due to the issues. For the rest of the world, you have some of my sympathy.

-- 
Michael Lueck
Lueck Data Systems

Remove the upper case letters NOSPAM to contact me directly.

Michael,

I tried again this morning.  (I know, I know.  "Insanity is doing the
same thing again and expecting a different result."  However, this is
software.  :)

Anyway, I downloaded the patch again.  Ran it again.  This time it
worked.  I'd like to blame Windows but in fairness it should probably
be chalked up as a "user error" (though I'm not sure what I could have
done wrong--it's a very simple procedure).

All I know for certain is that the \REDIST\ folder now contains the
2.1.2 files.  Good enough for me.

Thanks,
Mike

Well you should also be aware that is you create and tokenize an
application with 2.1.2, your client systems will NOT run the program
if they are at a lower level (2.1).

You have a couple of alternatives:
1) Upgrade your client systems
2) Maintain a system with the earlier version of ObjRexx so that you
can tokenize your code with that version (of course you can't use any
of the features released in the later editions).

Lee


On 13 Apr 2004 07:58:23 -0700, mike.pringle@iowa.gov (Mike Pringle)
wrote:

>Michael,
>
>I tried again this morning.  (I know, I know.  "Insanity is doing the
>same thing again and expecting a different result."  However, this is
>software.  :)
>
>Anyway, I downloaded the patch again.  Ran it again.  This time it
>worked.  I'd like to blame Windows but in fairness it should probably
>be chalked up as a "user error" (though I'm not sure what I could have
>done wrong--it's a very simple procedure).
>
>All I know for certain is that the \REDIST\ folder now contains the
>2.1.2 files.  Good enough for me.
>
>Thanks,
>Mike

Lee Peedin wrote:

> Well you should also be aware that is you create and tokenize an
> application with 2.1.2, your client systems will NOT run the program
> if they are at a lower level (2.1).

At some version in the 2.x history, Lavrentios agreed aaahh... now I remember... to allow newer Rexx runtimes to run back level tokenized code without complaining. Correct, tokenizing on 2.1.2 should 
require a 2.1.2 runtime.

Some where, maybe just in person, Lavrentios mentioned he had some issue where this level of support came one version after he promised to support it... I.E. they had to not support back level 
tokenized files silently "one more time"... which I SURE HOPE they are done with the "one more times" now. Hey, someone going to the Symposium, buy Lavrentios a beer for me to make sure the "one more 
times" are all done now! *wink*

My point was when upgrading the developer / runtime versions, it would be mission impossible to run around and retokenize everything "big bang" upgrade style... and some kind words from MFC helped 
convince Lavrentios of the validity of my point / request.

IBM has done good things at each new release of 2.x so there is no reason to avoid the upgrade.

-- 
Michael Lueck
Lueck Data Systems

Remove the upper case letters NOSPAM to contact me directly.

"Backwards" compatability is nice in theory; however, quite often it
is not possible.  Take for instance the MutableBuffer Class that was
added in version 2.1.2.  If an application was developed using this
class, surely it would fail when it was run under any lesser version
of the Runtime.

Even though it is inconvenient to redistribute Runtime files, I
consider it a necessary evil if we are to continue to get upgrades and
enhancements from Lavrentios, Manfred and the Rexx team at IBM.

That being said, I do feel that the Rexx Development team could do all
of us that create and distribute Rexx applications a favor by creating
an "install routine".  Not an install routine for the Runtime, but an
all emcompassing routine that would allow us to bundle the Runtime,
our application, and any additional Class files and/or ActiveX dlls
into 1 "setup.exe" application.

Lee Peedin
VP RexxLA

On Wed, 14 Apr 2004 11:24:50 -0400, Michael Lueck
<NmlueckO@SlueckPdataAsystemsM.com> wrote:

>Lee Peedin wrote:
>
>> Well you should also be aware that is you create and tokenize an
>> application with 2.1.2, your client systems will NOT run the program
>> if they are at a lower level (2.1).
>
>At some version in the 2.x history, Lavrentios agreed aaahh... now I remember... to allow newer Rexx runtimes to run back level tokenized code without complaining. Correct, tokenizing on 2.1.2 should 
>require a 2.1.2 runtime.
>
>Some where, maybe just in person, Lavrentios mentioned he had some issue where this level of support came one version after he promised to support it... I.E. they had to not support back level 
>tokenized files silently "one more time"... which I SURE HOPE they are done with the "one more times" now. Hey, someone going to the Symposium, buy Lavrentios a beer for me to make sure the "one more 
>times" are all done now! *wink*
>
>My point was when upgrading the developer / runtime versions, it would be mission impossible to run around and retokenize everything "big bang" upgrade style... and some kind words from MFC helped 
>convince Lavrentios of the validity of my point / request.
>
>IBM has done good things at each new release of 2.x so there is no reason to avoid the upgrade.

No, hang on there Lee. I meant existing working tokenzed files continue to work as-is with future runtime versions. That had not always been the case.

Tokenize on 2.1.2... along comes RunTime v3 and it can run those 2.1.2 tokenized files as-is.

Better? You need a beer too? I'll auction one off for ya! Who will start the bidding? Anyone give me 50 cents? Who ever wins it must give it to Lee, after paying for it of course. *wink*

-- 
Michael Lueck
Lueck Data Systems

Remove the upper case letters NOSPAM to contact me directly.

I knew what you meant, but how often will we be faced with a version
of the Runtime "newer" than the developer's edition we're using?

50 cent beer - I'll take all you got :-)

BTW: did you see my granddaughters pictures? (not proud or anything)

http://naomi.safedataisp.net


On Thu, 15 Apr 2004 09:35:27 -0400, Michael Lueck
<NmlueckO@SlueckPdataAsystemsM.com> wrote:

>No, hang on there Lee. I meant existing working tokenzed files continue to work as-is with future runtime versions. That had not always been the case.
>
>Tokenize on 2.1.2... along comes RunTime v3 and it can run those 2.1.2 tokenized files as-is.
>
>Better? You need a beer too? I'll auction one off for ya! Who will start the bidding? Anyone give me 50 cents? Who ever wins it must give it to Lee, after paying for it of course. *wink*

Lee Peedin wrote:

> I knew what you meant, but how often will we be faced with a version
> of the Runtime "newer" than the developer's edition we're using?

No no... how many times does IBM update ORexx, thus we all update it... but we can't scrable around and retokenize everything... or maybe we don't even own the source. Say I but some classes from 
you... you deliver me a tokenized .cls file, you are too busy enjoying your 50 cent beer to be bothered udpating the tokenized file but I want the latest ORexx... OUCH!

EXE's... OS/2 3.x EXE's work on OS/2 4.x, they didn't have to be upgraded / recompiled. Why should tokenized programs be treated worse? Such limitations will hinder ORexx's broader use in the IT 
industry, our favorite language need not be stuck in a box.

That makes two grand kids now, doesn't it? Now remember, work on the important things in life like SAY and PULL... closely followed by a good dose of PARSE! *wink* Congrads buddy!

-- 
Michael Lueck
Lueck Data Systems

Remove the upper case letters NOSPAM to contact me directly.

Nope it's the FIRST grandchild.  And I see what you're saying - let's
just press on for an "Install Wizard" that will "work" and be simple
enough for our users to implement.

L8R


On Thu, 15 Apr 2004 13:53:45 -0400, Michael Lueck
<NmlueckO@SlueckPdataAsystemsM.com> wrote:

>Lee Peedin wrote:
>
>> I knew what you meant, but how often will we be faced with a version
>> of the Runtime "newer" than the developer's edition we're using?
>
>No no... how many times does IBM update ORexx, thus we all update it... but we can't scrable around and retokenize everything... or maybe we don't even own the source. Say I but some classes from 
>you... you deliver me a tokenized .cls file, you are too busy enjoying your 50 cent beer to be bothered udpating the tokenized file but I want the latest ORexx... OUCH!
>
>EXE's... OS/2 3.x EXE's work on OS/2 4.x, they didn't have to be upgraded / recompiled. Why should tokenized programs be treated worse? Such limitations will hinder ORexx's broader use in the IT 
>industry, our favorite language need not be stuck in a box.
>
>That makes two grand kids now, doesn't it? Now remember, work on the important things in life like SAY and PULL... closely followed by a good dose of PARSE! *wink* Congrads buddy!

Lee Peedin wrote:

>  let's
> just press on for an "Install Wizard" that will "work" and be simple
> enough for our users to implement.

Just have your folk use our managed computers and you'll never have to worry about ORexx not working or being current. *wink*

-- 
Michael Lueck
Lueck Data Systems

Remove the upper case letters NOSPAM to contact me directly.

"Lee Peedin" <lee@DONOTSPAMMEsafedatausa.com> wrote in message
news:gjts70l19qlph26h2i84mrblu9rt0ge5ue@4ax.com...
> That being said, I do feel that the Rexx Development team could do all
> of us that create and distribute Rexx applications a favor by creating
> an "install routine".  Not an install routine for the Runtime, but an
> all emcompassing routine that would allow us to bundle the Runtime,
> our application, and any additional Class files and/or ActiveX dlls
> into 1 "setup.exe" application.

NO!

I do not want yet another installer tool. IBM is highly unlikely to be able
to produce anything evern partially adequate, without investing the sort of
effort that single-focus companies such as InstallShield or WISE expend. All
IBM would do is create bad will.

Nor is an install tool in any way required, as there is an architected
solution to the problem of redistributing "third party" code - the merge
module:

"Merge modules provide a standard method by which developers deliver shared
Windows� Installer components and setup logic to their applications. Merge
modules are used to deliver shared code, files, resources, registry entries,
and setup logic to applications as a single compound file."

If IBM were to supply the REXX redistributables as merge modules we would be
able redistribute the REXX runtime  (REXX runtime merge-module) and, where
required OODialog (secondary merge module) as part of our full installation.
A merge module is fairly easy to create once you know what you have to do.
Having IBM do the merge module would provide central control of the GUIDs,
thus preventing the conflicts that arise when two customers create their own
merge modules.

Full details on merge modules can be found at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/merge_modules.asp

Mark Yudkin wrote:

> "Merge modules provide a standard method by which developers deliver shared
> Windows� Installer components and setup logic to their applications

bbaaahhh hhuuummbbuuggg, Microsoft is not the answer, it is the question, the answer is NO!

I can think of several situations which would blow up relying merely on MSI to do the fix'n. Each ORexx build is specific and exclusive. Being in a developer 2.1.1 build and then installing XYZ which 
has the 2.1.2 runtime module embedded... YUCK! and so on and so forth.

The only good thing about MSI is that one can use tools to look inside. Otherwise it is too little, too complicated, too late.

-- 
Michael Lueck
Lueck Data Systems

Remove the upper case letters NOSPAM to contact me directly.

You seem to have forgotten that the IBM REXX V2 installer is an MSI
installer.

Given your attitude, I'm glad I don't have to install your software. But
worse than that, it's attitudes like these that make it hard for those of us
out here who do use MSI - very successfully - to manage large applications
of which the REXX runtime is a minuscule part, to produce a business case to
IBM that they improve their REXX runtime installation support.

It is obvious that the MSI merge module must validate that it's not
installing a runtime on a system with a developer edition installed. The
2.1.1 to 2.1.2 update should be harmless, otherwise IBM will need to ensure
side-by-side component registration and version-specific installation
directories. So far, they support neither - presumably they believe their
code to be upwards compatible (if it isn't, they should support coexistence
via the documented procedures).

Today things can blow up because each of us has to do his own REXX
installation, and we might forget to validate for a "downgrade". Or we may
get into a mess because we have different component guids. Central control
of the merge modules is the solution.

Avoiding MSI is the problem. The world has gone MSI. Many companies today
repackage non-MSI installs into MSI installs.

"Michael Lueck" <NmlueckO@SlueckPdataAsystemsM.com> wrote in message
news:1087uc9l1qnod0c@corp.supernews.com...
> Mark Yudkin wrote:
>
> > "Merge modules provide a standard method by which developers deliver
shared
> > Windows� Installer components and setup logic to their applications
>
> bbaaahhh hhuuummbbuuggg, Microsoft is not the answer, it is the question,
the answer is NO!
>
> I can think of several situations which would blow up relying merely on
MSI to do the fix'n. Each ORexx build is specific and exclusive. Being in a
developer 2.1.1 build and then installing XYZ which
> has the 2.1.2 runtime module embedded... YUCK! and so on and so forth.
>
> The only good thing about MSI is that one can use tools to look inside.
Otherwise it is too little, too complicated, too late.
>
> -- 
> Michael Lueck
> Lueck Data Systems
>
> Remove the upper case letters NOSPAM to contact me directly.

Mark Yudkin wrote:
> You seem to have forgotten that the IBM REXX V2 installer is an MSI
> installer.

Was, it's in MichaelDist over here.

> Given your attitude, I'm glad I don't have to install your software.

We provide a turn-key managed computing platform to our clients, part of which is inventing our own cross-platform electronic software distribution system which runs circles around MSI's capabilities. 
Though it can handle big ugly MSI's such as office suites which would not be fun to repackage at all, smaller things such as Rexx we convert and arrive at better results. Thus, we design technology 
solutions for those who just want computers that work, not for those that want to get under the hood and tinker along side of us. THAT is the bulk of what is wrong with the PC industry, all vendors 
expect their clients at some level to get under the hood and tinker, so everyone tinkers in a slightly different way, and PC's are the mess they are as a result. Why should every customer need to come 
up with their own implementation... I though wise people said NOT to reinvent the wheel. Aaahhh, the inventer of this wheel must not have done the entire job. Hey, it's job security for us! (At least 
as long as we are allowed to have fat clients / fat servers / fat anything)

-- 
Michael Lueck
Lueck Data Systems

Remove the upper case letters NOSPAM to contact me directly.

"Michael Lueck" <NmlueckO@SlueckPdataAsystemsM.com> wrote in message
news:108fc2o1f9omd6d@corp.supernews.com...
> THAT is the bulk of what is wrong with the PC industry, all vendors
> expect their clients at some level to get under the hood and tinker,
> so everyone tinkers in a slightly different way, and PC's are the
> mess they are as a result. Why should every customer need to come
> up with their own implementation...
> I though wise people said NOT to reinvent the wheel.

Which is _exactly_ why an MSI merge module is the _only sensible way_ for
IBM to bundle the REXX runtime installation logic.

That way I don't have to get under the hood and tinker. That way I don't
have to come up with my own implementation, That way my implementation
doesn't conflict with yours (if only because we have different component
GUIDs to break uninstall). That way nobody has to reinvent anything.