SQL/MX Programs migration

[Rach]

We need to get SQL/MX programs(run in pathway as guardian process)
migrated to QA environment(which resides on same Tandem node but
different database,pathway etc). Unlike SQL/MP where we just move the
object and sqlcomp with different catalog , SQL/MX need to be re-
compiled the program targetting for QA environment using the
moduleTableset option. This would generate different module name and
keep the user module in global location(/usr/tandem/sqlmx/
USERMODULES).We dont want to take this approach as this would require
us to compile the program for QA, UAT and PROD environments and
maintain them seperately.
HP provides the option to mxcmp the module def file and crate the
module (with same name as it was compiled) in a local directory(using -
g moduleLocal option). But it is not very clear on how to make the
executable look for the module in the local directory.The define
=_MX_MODULE_SEARCH_ can hold only guardian path and doesnot help much
if we keep the module names in the oss directory. Any thoughts on how
the migration needs to be done other than the targetted compilation.?

[Keith Dick]

Two points:

1. The environment variable _MX_MODULE_SEARCH_PATH serves the same purpose as the =_MX_MODULE_SEARCH_ DEFINE, and does take OSS directory names.

2. A PROTOTYPE host variable can be used to specify an SQL/MX table name dynamically at run time. You would have to arrange to initialize the host variables containing the table references yourself, perhaps taking the names from an environment variable or reading them from a file whose name you passed as an environment variable. I don't know why something more automatic like DEFINEs for SQL/MP was not implemented.

Both of these are described in the SQL/MX Release 3.1 Programming Manual for C and COBOL.

[Rach]

> Both of these are described in the SQL/MX Release 3.1 Programming Manual for C and COBOL.- Hide quoted text -
>
> - Show quoted text -
We dont want to use the prototype which causes auto recompile(we are
using views so similairyt check option is not applicable)

How do we make the guardian process in pathway take the OSS define ?

[Keith Dick]

Sorry, I was rushed when I was writing my first suggestion and did not understand completely what you were asking.

The SQL/MX executor always first looks in the same location as the executable for the module, so I think if you have different directories for QA, UAT, and PROD, copy the executable files from one to the next as you progress from QA to PROD, and recompile the module locally, then the executor will find the module in QA, UAT, or PROD directory, whichever executable file you are running, without the need for the =_MX_MODULE_SEARCH_PATH DEFINE. I have never done that, but that is what I believe the manual says will work.

Note the warnings in the manual that say it is not wise to mix using global module files and local module files in the same system, just because of the possibility that, because of the way SQL/MX searches for modules, if you have both global and local, it might find a wrong, out-of-date module if the one you intended has been deleted.

I see you say your SQL/MX programs are running as Guardian processes. I wasn't aware that was possible (I've been away from hands-on work with NonStop for a while), but if it is possible and that is what you are doing, and if you are putting your object files in Guardian subvolumes, perhaps you cannot put the module files in the same directory as your executable files. On the other hand, on page 17-6, it says you can generate module files in any user-specified Guardian or OSS location, however the syntax just below mentions only OSSdir for giving the location. Of course, every Guardian subvol has an OSS name under /G, so maybe that is how you can put a module file into a Guardian location, if you need to do that. It seems to me that the Guardian 8-character name limit would make that impractical, though. Aren't module file names much longer than that?

[Rach]

> I see you say your SQL/MX programs are running as Guardian processes.  I wasn't aware that was possible (I've been away from hands-on work with NonStop for a while), but if it is possible and that is what you are doing, and if you are putting your object files in Guardian subvolumes, perhaps you cannot put the module files in the same directory as your executable files.  On the other hand, on page 17-6, it says you can generate module files in any user-specified Guardian or OSS location, however the syntax just below mentions only OSSdir for giving the location.  Of course, every Guardian subvol has an OSS name under /G, so maybe that is how you can put a module file into a Guardian location, if you need to do that.  It seems to me that the Guardian 8-character name limit would make that impractical, though.  Aren't module file names much longer than that?- Hide quoted text -

>
> - Show quoted text -

The user modules are generated cat.sch.modulename. As the program
executables are in guardian it resricts the filenames to be 8
characters.It really doesnot help us here. The oss dir allows to
mention guardian file location but cannot keep a filename longer than
that. SQL/MX programs can run out of guardian (we are doing that)

[dimandja]

Rach wrote:
> SQL/MX programs can run out of guardian (we are doing that) .

Yes indeed.

"HP NonStop SQL/MX Programming Manual for C and COBOL" has a chapter
called "Building SQL/MX Guardian Applications in the Guardian
Environment" (Starting at Chapter 15-53) that explains how to do it.

[Rach]

That doesnot give solution for the problem.Guardina compilation is
done with oss passthrough commands.

[Keith Dick]

I'm not sure this is relevant, but let's get it straightened out, just to be sure.

When you said "We need to get SQL/MX programs(run in pathway as guardian process) ...", do you just mean that the SQL/MX programs are stored in Guardian subvolumes rather than in OSS directories? Or do you actually mean the programs run as Guardian processes, not OSS processes? Pathway can run both kinds of processes as serverclasses. In your Pathway configuration, in the serverclass definitions, do you specify the PROCESSTYPE attribute, and if so, does it say GUARDIAN or OSS? I just asked a colleague who has more recent experience with SQL/MX than I do, and she says she also believes that SQL/MX can only be used in OSS processes, not Guardian process. She confirms that SQL/MX programs can be put into Guardian subvolumes and run from there, but believes they must be OSS processes.


Now, regardless of that, in my most recent post, I pointed out that the manual says that the executor will first look for a module in the same location as the executable. You seemed to say that you are storing the program files in a Guardian subvolume. You also seemed to say that the module names were too long to be put into a Guardian subvolume.

Two possible solutions: (1) Change what you are doing so you put the executables in an OSS directory (one directory each for QA, UAT, and PROD) and put the compiled modules in the same directories, or (2) Find a way to make the module names short enough to fit into 8 characters and store them in the Guardian subvolumes.

I'm not sure (2) is even possible. The manual says you can put modules in Guardian subvolumes, but does not explain how to do so, nor how the three-part module name is squeezed into the Guardian filename syntax. I kind of doubt that the manual would say that it is possible to put modules into Guardian subvolumes if it is, in fact, impossible (but manuals have been wildly wrong before), so it might be worth inquiring of the HP Support Center just how one makes use of that advertised capability.

If it turns out that (2) is not possible or not practical, I think you are left with (1) -- put your executables into OSS directories. Is there any fundamental reason you cannot do that?

[dimandja]

In the same manual, chapter 17.8 says:

"Module Management Naming
Use module management naming to externally qualify the file names of
modules to
assist you with these development tasks:
• Configuring applications to target different sets of database
objects
• Managing different versions of an application
• Grouping the modules of an application
To accomplish these tasks, you need not change the C, C++, or COBOL
source file or
rely strictly on the MODULE directive or on module naming defaults.
Instead, you can
specify the catalog and schema and the target, version, and group
attributes for the
module names during SQL preprocessing. The external naming of the
module files
during preprocessing influences the targeting, versioning, and
grouping properties of
an application."

Does this not solve your problem?

[Keith Dick]

Note that it says "during SQL preprocessing". That implies recompiling the application, not just recompiling the module. I think that may be the feature he mentioned that they do not want to use because it requires recompiling the application.

[dimandja]

Keith wrote:
> Note that it says "during SQL preprocessing". That implies recompiling the application, not just recompiling the module.

Yes, of course.

I never used SQL/MX and I only skimmed that manual -- using my other
Tandem skills. The bottom line is that the manual I quoted shows how
to compile (from the same location) for test, QA, and production
without changing the source code. Unless one wants to do tricky
stuff, this should be the best (and pretty safe) approach. Then
again, I don't know how the OP's code management tools are organized.

[dimandja]

I took time to (re)read the original post of this thread. The OP
says:

> We dont want to take this approach as this would require
> us to compile the program for QA, UAT and PROD environments and
> maintain them seperately.

This is precisely what the manual says you do not have to do. The
manual says (unless I'm very mistaken -- it can happen:) you can
compile the same source code and target QA or production or whatever.
Furthermore, good code maintenance and versioning means DO NOT
maintain separate code sources for test, QA and production. You must
be able to use the same unchanged source code in all environments.

[Keith Dick]

Rach, the original poster, in that quote you gave says he does not want to compile the program for QA, UAT, and PROD. The quote you gave from the manual says you compile the same source code and target whatever environment. I believe that means compiling once for each environment. "compile the program" == "compile the same source code". That is what he does not want.

What Rach wants to do is use the same executable in QA, UAT, and PROD, recompiling only the SQL statements in the module, if I understand his goal correctly.

[dimandja]

Keith wrote:
> Rach, the original poster, in that quote you gave says he does not want to compile the program for QA, UAT, and PROD.

That's true, Keith. However Rach goes on to say they don't want to
"separately maintain source codes for QA, UAT, and PROD". That's a
totally different issue, Keith, than merely recompiling source code
without "separately maintaining version for QA, UAT, and PROD".

Keith wrote:
> I believe that means compiling once for each environment. "compile the program" == "compile the same source code".

Thanks for clarifying that, Keith ;), that's exactly what I mean. SQL/
MX is not SQL/MP or Enscribe. That beast goes by its own rules.

I wonder if this project is already in Production? If it is, and
these issues are only now being raised, it could be costly to fix the
problem, if at all possible.

[Keith Dick]

dimandja wrote:
> Keith wrote:
>
>>Rach, the original poster, in that quote you gave says he does not want to compile the program for QA, UAT, and PROD.
>
>
> That's true, Keith. However Rach goes on to say they don't want to
> "separately maintain source codes for QA, UAT, and PROD". That's a

Odd. I don't find that reference to source codes in any of the posts from Rach that I see in the thread. Which one do you see it in?

The closest I can find to what you quote is: "We dont want to take this approach as this would require us to compile the program for QA, UAT and PROD environments and
maintain them seperately." Maybe you think "maintain them separately" means "maintain source code separately". I'll admit that it isn't completely clear what he means there. From the references to how SQL/MP works and other parts of the post, I interpret it to mean that he wants to compile the application program once, copy the object files from environment to environment, and only recompile the SQL statements in each new environment. The method HP describes in the manual does not work that way, and I think you are pointing to the same method.

[dimandja]

Keith wrote:
> Maybe you think "maintain them separately" means "maintain source code separately".

What else could it mean, Keith? How could one "maintain object code
separately"? It doesn't make any sense. And I think Rach writes
English very well.

Keith wrote:
> I interpret it to mean that he wants to compile the application program once, copy the object files from environment to environment, and only recompile the SQL statements in each new environment.

Perhaps.

I think Rach raised many completely different issues in this thread,
including Guardian hosting vs OSS hosting, module generation, module
naming, module management, using Pathway, code versioning, compilation
targeting, etc.

What I have been saying Keith, is that there isn't one single magic
bullet to solve all those issues. The manual does provide solutions
and suggestions. The problem I see here is,s for various reasons,
Rach does not like those solutions and suggestions, longing instead
for the simplicity of SQL/MP.

Anyway, it doesn't help to concentrate on what I wrote or what I
meant. What matters is for Rach to find a solution to his problems.

[Keith Dick]

dimandja wrote:
> Keith wrote:
>
>>Maybe you think "maintain them separately" means "maintain source code separately".
>
>
> What else could it mean, Keith? How could one "maintain object code
> separately"? It doesn't make any sense. And I think Rach writes
> English very well.
>

Oh, I think "maintain object code separately" makes sense. It could mean to generate different object code from the same source by compiling with different options.

>
> Keith wrote:
>
>> I interpret it to mean that he wants to compile the application program once, copy the object files from environment to environment, and only recompile the SQL statements in each new environment.
>
>
> Perhaps.
>
> I think Rach raised many completely different issues in this thread,
> including Guardian hosting vs OSS hosting, module generation, module
> naming, module management, using Pathway, code versioning, compilation
> targeting, etc.

I don't believe there are so many issues. He wants to do something when the object files are stored in Guardian subvolumes that can be done when storing them in OSS directories (either specify a module search list or collocate the modules with the executables). The rest of the points are just setting up the problem or have nothing to do with it.

>
> What I have been saying Keith, is that there isn't one single magic
> bullet to solve all those issues.

Right -- no magic bullet. I expect he cannot do what he wants to do without changing to store the executables in an OSS directory. Then, there probably are two ways to do it. Actually, another possible solution just occurred to me as I was writing. Although he said his processes were Guardian processes, I think he may have been mistaken about that. Assuming they are, in fact, OSS processes, then he could use the OSS environment variable to give a search path for finding modules, and that would let him store the modules in an OSS directory and still store the executables in a Guardian subvol. I'll have to put that in a post of its own, in case he is still looking for an answer.

> The manual does provide solutions
> and suggestions. The problem I see here is,s for various reasons,
> Rach does not like those solutions and suggestions, longing instead
> for the simplicity of SQL/MP.

I don't believe he is longing for the simplicity of SQL/MP. I believe he is longing for an apparently lost capability of SQL/MP. SQL/MX is supposed to be an enhancement over SQL/MP, and losing capabilities is not what you expect with enhanced versions. The capability I mean is the ability to use the same object file in QA, UAT, and PROD, recompiling only the SQL statements.

>
> Anyway, it doesn't help to concentrate on what I wrote or what I
> meant. What matters is for Rach to find a solution to his problems.

I only concentrate on what you wrote to try to understand what you meant when it doesn't seem to match what I see. About solving Rach's problem, I agree -- and since he seems not to have been around here for a day and a half, maybe he found something that works for him. If so, it would be nice to know what it was.

[Keith Dick]

I just realized there might be another solution I did not think of before.

Assuming your SQL/MX programs really are OSS processes, not Guardian processes, then you can specify OSS environment variables in the Pathway configuration for the serverclasses. So you could use the OSS environment variable _MX_MODULE_SEARCH_PATH to point to the OSS directory that contains the version of the modules you want the server to use.

If you actually are correct in saying that your SQL/MX programs run as Guardian processes, I think that won't work, but I'm pretty sure they cannot be Guardian processes.

[ghr]

The OP opined:
"We dont (grammar) want to take this approach as this would require us

to compile the program for QA, UAT and PROD environments and maintain
them seperately. "

A desire to have a single source for Dev, QA, UAT and Production is
fraught with danger: as soon as source is changed in Dev it becomes
disconnected from the QA, UAT and Production realities. Where is the
source to enable QA, UAT or Production problem/issue investigation?
Surely the OP should be dissuaded by 'wiser' heads from the notion
that a single source spanning more than one of the above environments
is not career-enhancing and s/he should seriously entertain the notion
that this path is sure to lead to tears?

When I was a young man, this is what I did: a single source for all
environments. But experience (inter alia) teaches my previous point:
humans are not infallible. The time between a Dev modification and its
sane release into production is not measured in pico seconds.

Separate sources for each/most environments is surely the preferred
way to business continuity and job retention.

[wbreidbach]

You are able to use SQL/MX from Guardian, so that should not be the problem.
We had a similar problem, having Development, QA and 2 production systems.
The main difference is that we are using OSS-processes.
We solved the problem using the PROTOTYPE.
It is true that the statements will be recompiled the first time they are executed but for us that has never been a problem.
There has been a problem if you had different versions on the systems but as far as I unterstand we are talking about one physical system.
So from our experience I would recommend the PROTOTYPE option.

[Keith Dick]

I suspect you misunderstand. I imagine that they would be using some sort of version control system to manage the versions of their source. What I believe he wants to do is, for any given version of that source, once he compiles it to start QA, then he wants not to have to recompile the source in order to move from QA to UAT, and from UAT to PROD. Further work on the application in Dev would generate a new version of the source in the source control system; the older version of the source would be still be there, forever.

I believe the desire not to recompile when moving between QA, UAT, and PROD is an entirely reasonable desire. Do you disagree with that? Or do you think I am misinterpreting what Rach, the original poster, meant?

[wbreidbach]

I agree, Keith. We are using the same way, we compile on the development system and than the program is tested on dev, afterwards on QA and then it goes into production. Compiles are done either on dev or using ETK. Of course we have version control.

[Rach]

On Apr 26, 11:14 am, wbreidbach <wolfgang.breidb...@bv-

zahlungssysteme.de> wrote:
> I agree, Keith. We are using the same way, we compile on the development system and than the program is tested on dev, afterwards on QA and then it goes into production. Compiles are done either on dev or using ETK. Of course we have version control.

You are right Keith. We want to compile and build the executable once
but make it point to different catalogs/schemas on the same NODE.

In SQL/MP it is pretty straight forward we can do a sqlcomp pointing
to different catalogs.As SQL statements are embedded in the
executable.

In SQL/MX the executbale essentially uses CLI (callable library
interfaces) to execute specifc sql procedures residin in the module
file.

And the fundamental problem seems to be that the user module files
need to reside only on a global location for a pathway guardian
program

The docs dont specify a way if there is any way we can make to use the
local directory.

[Keith Dick]

Please confirm whether in your Pathway configuration, you specify PROCESSTYPE GUARDIAN. You've said several times that your SQL/MX processes are Guardian processes, but I've been told that does not work. I'm told you can store the SQL/MX object files in Guardian subvolumes, but when you run them, they must be run as OSS processes, so I feel pretty sure that your Pathway serverclasses will say PROCESSTYPE OSS.

If you actually are running your SQL/MX programs as Guardian processes, then the person I was talking with is wrong, but she is pretty knowledgeable about SQL/MX, so I think chances are pretty high that she is right.

If you actually are running your SQL/MX programs as OSS processes, you can use the _MX_MODULE_SEARCH_PATH environment variable in the Pathway definition of your serverclasses to specify the OSS directory in which you want SQL/MX to look for modules. Using that, I believe you could keep your SQL/MX programs in Guardian subvolumes, keep your compiled modules in OSS directories, and direct SQL/MX to use the proper directory for the modules, depending on whether it is running as QA, UAT, or PROD.

It seems to me it would be simpler to store the SQL/MX programs in OSS directories and put the modules in those same directories, so you don't need to specify a search path (SQL/MX always first looks for the modules in the location of the executable), but if you want to keep your executables in a Guardian subvol, I believe the above would solve your problem, unless you also must store the modules in Guardian subvols (which I don't see is possible, due to the length of the names).

[Rach]

> It seems to me it would be simpler to store the SQL/MX programs in OSS directories and put the modules in those same directories, so you don't need to specify a search path (SQL/MX always first looks for the modules in the location of the executable), but if you want to keep your executables in a Guardian subvol, I believe the above would solve your problem, unless you also must store the modules in Guardian subvols (which I don't see is possible, due to the length of the names).- Hide quoted text -

>
> - Show quoted text -

Keith, We have processtype as GUARDIAN and SQL/MX programs run
perfectly alright in Gaurdian space.
We dont want to run programs in OSS space.

[dimandja]

Rach wrote:

> the fundamental problem seems to be that the user module files
> need to reside only on a global location for a pathway guardian
> program

I think I am starting to understand what the real problem is.

Questions to Rach:

1. Which location are you currently using as "Global Location"?
2. Who/What determines a certain location as "Global"?

[dimandja]

I'm assuming you are using SQL/MX Release 2.x. If so, then you can
place test, QA and production modules on the same machine as explained
in Chapter 17. My understanding, however, is that SQL/MX will not
simply let you copy objects from test to other environments without
recompiling.

I didn't see (didn't search for) anything specific to Pathway.

[Keith Dick]

Okay, my friend must be wrong that SQL/MX program must run as OSS processes. I apologize for doubting what you said.

I can think of only two things that might let you do what you want, and I'm doubtful about both of them.

One is to find a way that the SQL modules can be given names small enough to put them into a Guardian filename, and either store them in the same subvolume as the executable file or use the module search DEFINE to get SQL/MX to look in the correct subvol for the module. If there is a way to get the module file names to be small enough to be Guardian filenames, I don't know how to do that, but that does not mean it isn't possible, just that I don't know how to do it. But the description of the MODULE directive seems to say that the preprocessor is going to add a catalog and schema part to the name, so I don't see how the module files could be Guardian filenames, even though the programming manual says the modules can be put in a Guardian location. Either some part of the manual is wrong or it is missing some information.

The other thing that might work is to store your executables in OSS directories and put the modules in the same directories as the executable it is to be used by. However there are several places in various documents that seem to say pretty clearly that Guardian processes can only be run from files with Guardian filenames and OSS processes can only be run from files with OSS filenames, so that would rule out starting a Guardian process from an object file stored in an OSS directory. There is some chance that that restriction has been removed and the manuals have not been updated, but I think that probably is not the case.

So the only two ways I can think of to do what you want seem to be ruled out. The first one has some small glimmer of hope remaining, since the manual does say that you can put modules into a Guardian location. It just doesn't say how to do that or give any examples. If there is, in fact, a way to get the SQL/MX compiler to put modules into a Guardian subvolume, I think that would solve your problem, so maybe you should call the HP Support Center and ask for more explanation and examples about that.

If you look at the SQL/MX 3.1 Programming Manual for C and COBOL, just about every place where it talks about where modules can be put, it has been updated to include Guardian locations. (Notice the change bars in the margin.) Prior versions of the manual explicitly said that the OSS path for the modules could not start with /G or /E. That strongly suggests that something was implemented to allow putting modules into Guardian subvols. Maybe they devised some way to encode the long name into the 8-character Guaridan name. Or it is magic. But I don't think they would have updated all those references by accident. So, assuming you are using release 3.1, either try specifying a Guardian location (-g moduleLocal=/G/vol/subvol) and see what it does, or ask HP Customer Support to explain how Guardian locations for modules is used.

If you aren't using release 3.1, I think you are out of luck.

[Bill Honaker]

I found this information by reading the Release 3.1 Programming
Manual, chapter 17 (Program and Module Management). I have not tested
it but please try it if you are on 3.1 (it may also work on 2.x and
the manual may have not been updated correctly to explain).

When you want to mxcmp the file, use the mxCompileUserModule command
with the =g option:

osh -c "mxCompileUserModule -g module_local=/G/vol/resvol &
/G/vol/appvol/app"

When you run the program, include a SEARCH define named
=_MX_MODULE_SEARCH_PATH

ADD SERVER DEFINE =_MX_MODULE_SEARCH_PATH, &
CLASS SEARCH, SUIBVOL0 $vol.resvol


Note that the syntax (page 15-35) of the mxCompileUesrModule says taht
the applicaiton file 'must not specify a Gurdian subvolume (/G/...)'
but that may be a missed documentation issue since it would keep you
from running a Guardian SQL/MX program (which we already know works).

You will have to name your modules from the source programs with an 8
or less character, Guardian-friendly filename.

See if that helps.






On Mon, 23 Apr 2012 17:48:09 -0700 (PDT), Rach <rbp...@gmail.com>
wrote:

>We need to get SQL/MX programs(run in pathway as guardian process)

>migrated to QA environment(which resides on same Tandem node but
>different database,pathway etc). Unlike SQL/MP where we just move the
>object and sqlcomp with different catalog , SQL/MX need to be re-
>compiled the program targetting for QA environment using the
>moduleTableset option. This would generate different module name and
>keep the user module in global location(/usr/tandem/sqlmx/

>USERMODULES).We dont want to take this approach as this would require

>us to compile the program for QA, UAT and PROD environments and
>maintain them seperately.

[Rach]

On Apr 27, 6:56 pm, Bill Honaker <no_spam_bhonaker__@x_i_d.com> wrote:
> I found this information by reading the Release 3.1 Programming
> Manual, chapter 17 (Program and Module Management).  I have not tested
> it but please try it if you are on 3.1 (it may also work on 2.x and
> the manual may have not been updated correctly to explain).
>
> When you want to mxcmp the file, use the mxCompileUserModule command
> with the =g option:
>
>   osh -c "mxCompileUserModule -g module_local=/G/vol/resvol &
>           /G/vol/appvol/app"
>
> When you run the program, include a SEARCH define named
> =_MX_MODULE_SEARCH_PATH
>
>   ADD SERVER DEFINE =_MX_MODULE_SEARCH_PATH, &
>      CLASS SEARCH, SUIBVOL0 $vol.resvol
>
> Note that the syntax (page 15-35) of the mxCompileUesrModule says taht
> the applicaiton file 'must not specify a Gurdian subvolume (/G/...)'
> but that may be a missed documentation issue since it would keep you
> from running a Guardian SQL/MX program (which we already know works).
>
> You will have to name your modules from the source programs with an 8
> or less character, Guardian-friendly filename.
>
> See if that helps.
>

> On Mon, 23 Apr 2012 17:48:09 -0700 (PDT), Rach <rbpa...@gmail.com>

> wrote:
>
>
>
> >We need to get SQL/MX programs(run in pathway as guardian process)
> >migrated to QA environment(which resides on same Tandem node but
> >different database,pathway etc). Unlike SQL/MP where we just move the
> >object and sqlcomp with different catalog , SQL/MX  need to be re-
> >compiled the program targetting for QA environment using the
> >moduleTableset option. This would generate different module name and
> >keep the user module in global location(/usr/tandem/sqlmx/
> >USERMODULES).We dont want to take this approach as this would require
> >us to compile the program for QA, UAT and PROD environments and
> >maintain them seperately.
> >HP provides the option to mxcmp the module def file  and crate the
> >module (with same name as it was compiled) in a local directory(using -
> >g moduleLocal option). But it is not very clear on how to make the
> >executable look for the module in the local directory.The define
> >=_MX_MODULE_SEARCH_ can hold only guardian path and doesnot help much
> >if we keep the module names in the oss directory. Any thoughts on how

> >the migration needs to be done other than the targetted compilation.?- Hide quoted text -

>
> - Show quoted text -

We want to have the modules in oss directory. We have worked with HP
folks closely and apparently current SQL/MX doesnot support.
They will make this feature supported in the future .They would have
to take through the RFE route,So that leaves us the only option of
recompling for different environments seperately .
thanks for all your support and prompt responses. Greatly apprreciate
it.

[Keith Dick]

Are you using SQL/MX 3.1? If not, then recompiling the application source files probably is your only solution.

If you are using SQL/MX 3.1, the updates to the manuals for 3.1 indicate that you could accomplish what you want to do by putting the modules into Guardian subvolumes, as I mentioned in another post here. I know you just said that you want to keep the modules in OSS directories, but since you put your executables into Guardian subvolumes, it is not clear to me why you insist that you need to put your modules into OSS directories. Perhaps you have a good reason for that, but you have not explained what it is.

I mention this again only because it seems to me to be better to put the modules into Guardian subvolumes and avoid the recompilation of the application source files. Maybe later, when HP finally implements a way to allow you to give OSS directories as search locations for Guardian programs, you could change where you store the modules at that time, if having the modules in OSS directories is important enough to you then.

[dimandja]

Le lundi 23 avril 2012 20:48:09 UTC-4, Rach a écrit :
> We need to get SQL/MX programs(run in pathway as guardian process)
> migrated to QA environment(which resides on same Tandem node but
> different database,pathway etc). Unlike SQL/MP where we just move the
> object and sqlcomp with different catalog , SQL/MX need to be re-
> compiled the program targetting for QA environment using the
> moduleTableset option. This would generate different module name and
> keep the user module in global location(/usr/tandem/sqlmx/
> USERMODULES).We dont want to take this approach as this would require
> us to compile the program for QA, UAT and PROD environments and
> maintain them seperately.
> HP provides the option to mxcmp the module def file and crate the
> module (with same name as it was compiled) in a local directory(using -
> g moduleLocal option). But it is not very clear on how to make the
> executable look for the module in the local directory.The define
> =_MX_MODULE_SEARCH_ can hold only guardian path and doesnot help much
> if we keep the module names in the oss directory. Any thoughts on how
> the migration needs to be done other than the targetted compilation.?

> We want to have the modules in oss directory. We have worked with HP
folks closely and apparently current SQL/MX doesnot support.

I see. All you wanted to do was access OSS hosted modules from a Pathway Guardian-process. Can't be done (yet), of course.

Your most viable option is what Wolgang posted: use Pathway OSS-processes.

[Keith Dick]

Acrually, I believe one can access OSS-hosted modules from a Guardian process, as long as you are willing for the modules to be in the global directory. What apparently cannot be done is access them when they are in other OSS directories.

Changing their processes from Guardian processes to OSS processes might not be a very easy job, and they might have good reasons for them to be Guardian processes in any case -- we don't know all of the constraints.

If the manuals are correct, SQL/MX 3.1 can put modules into Guardian subvolumes, and I believe that would solve Rach's problem, except for his need for the modules to be in OSS directories. Again, he might have some good reason for insisting that the modules have to be in OSS directories, but we haven't been told what it is.

Prior to 3.1, I think it was not possible for the modules to be in Guardian subvolumes, at least that is what the manuals seem to say. But as of 3.1, they can be in Guardian subvolumes, and that seems like it would solve the problem, as originally described.

[dimandja]

It's also possible that this project hasn't gotten off the ground yet(?). Which should leave all options open. I'd hate to think this is already headed to production.

[Keith Dick]

I suppose that is possible, since I don't remember that point being mentioned. I somehow got the impression that it was to the point where they are ready to start testing and are trying to figure out how to avoid changing the application executable files when moving from QA to UAT to PROD. However, they might be doing all that planning up front (which would be good), so you might be right that they would at least have the opportunity to choose to make the application programs be OSS programs rather than Guardian programs, unless there are some requirements that dictate that they must be Guardian programs.

We might never know anything more, since Rach's most recent message sounded like a sign-off to me. He might not be looking here again.