QGPL or QUSRSYS ... where to store these objects?
Ron Koudijs
I'm not sure where put the following objects:
1) My *PRDDFN, the product definition of my product,
together with all the license key information and
the *MSGF message file which contains the descriptions.
2) My STRxxx *CMD, the command to start working with my application.
I can't put them in the one few libraries that belong to the
application because I can't assume one or more of them are always
available in the system or user library list part.
If the *MSGF is not in the library list you don't see any descriptions
while working with WRKLICINF.
If the *CMD is not in the library list you can't start the application
without explicitly specifying where the command is located.
So I think I should store these object in QGPL or QUSRSYS.
Which one to pick? Or is there even a better one?
Greetings,
Ron
--------------------
Kou...@Com-Unit.com
Ed Fishel
Put all your product definition, product load, command, programs, and
message file objects in your products library. Do not put them in QUSRSYS
or QGPL. The correct way to solve the problem you are having is to create
your CL commands with the PRDLIB parameter set to load your product
library. Then during install of your product use an install exit program
to copy your commands into library QSYS.
Doing this will make your commands available to everyone and when anyone
uses one of your commands your product library will automatically be added
to the product portion of the library list. This will allow all other
objects in that library to be found.
Ed Fishel
Charles R. Pence
> I'm not sure where put the following objects:
> 1) My *PRDDFN, the product definition of my product,
> together with all the license key information and
> the *MSGF message file which contains the descriptions.
> 2) My STRxxx *CMD, the command to start working with my application.
>
> I can't put them in the one few libraries that belong to the
> application because I can't assume one or more of them are always
> available in the system or user library list part.
>
> If the *MSGF is not in the library list you don't see any descriptions
> while working with WRKLICINF.
>
> If the *CMD is not in the library list you can't start the application
> without explicitly specifying where the command is located.
>
> So I think I should store these object in QGPL or QUSRSYS.
> Which one to pick? Or is there even a better one?
For a simple example, look at 57xxQU1. There is a run-time and a
definition-time division of function; the *QRYDFN produced can be
used w/out the existence of the product, as well RUNQRY *NONE (file).
The *PRDDFN and *MSGF are in the product library QQRYLIB <the latter
not exactly... but it would normally be>. The help/screens for the
product are in the product library.
For those features which are supported without the product library,
or which are required to enter the product/application, the run-time
objects like a *MSGF/screen/help/commands are duplicated/moved from
the product library into QSYS -- the only library required to be in
the *LIBL. The command that activates the product/application
should have been created using the PRDLIB() parm on the CRTCMD, so
the application's product lib is automatically made part of *LIBL.
See the WRKQRY command.
I am not sure about the WRKLICINF case....
Regards, Chuck
All comments provided "as is" with no warranties of any kind whatsoever.
Worley Barry
>Hello,
>
>I'm not sure where put the following objects:
>1) My *PRDDFN, the product definition of my product,
> together with all the license key information and
> the *MSGF message file which contains the descriptions.
>2) My STRxxx *CMD, the command to start working with my application.
>
>I can't put them in the one few libraries that belong to the
>application because I can't assume one or more of them are always
>available in the system or user library list part.
>
>If the *MSGF is not in the library list you don't see any descriptions
>while working with WRKLICINF.
Are you sure? I locate everyhing in the product library and
I just tested WRKLICINF with only QTEMP and QGPL in the library
list. It displayed the feature discriptions from the message
file.
>If the *CMD is not in the library list you can't start the application
>without explicitly specifying where the command is located.
I've written an install command executed by a lodrun
program. One of the parameters for the install command is
common command library and it defaults to QGPL. To the best of
my knowledge everyone has taken the default.
Actually, I have two copies of the commands one in the
product library and one in 'QGPL'. I create the command in QGPL
with CRTDUPOBJ in an install exit program.
> >So I think I should store these object in QGPL or QUSRSYS.
>Which one to pick? Or is there even a better one?
I don't think you can go wrong with QGPL.
If you're not passing any parameters on the start command you might
like this little trick to start the command with GO
1. Add parameters to the command source to match the paramaters for CRTMNU..
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
CMD PROMPT('Start DATABASICS Executive')
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
/* STRDBI Command */
/* */
/* Executes SYC400 same As Menu DBI */
/* */
/* Chg Date Person Description */
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
/* | 11/07/88 | W.Barry | Command created */
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
PARM KWD(MNU) TYPE(*CHAR) LEN(10) CONSTANT(STRDBI)
PARM KWD(MNULIB) TYPE(*CHAR) LEN(10) CONSTANT(DBI)
PARM KWD(MNURTN) TYPE(*CHAR) LEN( 2) CONSTANT(CM)
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
2. Create command processing program with menu parameters
testing paramters to see if command or menu started the program.
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
PGM PARM(&MNU &MNULIB &MNURTN)
DCL VAR(&PGM) TYPE(*CHAR) LEN(10) VALUE(SYC400)
DCL VAR(&MNU) TYPE(*CHAR) LEN(10)
DCL VAR(&MNULIB) TYPE(*CHAR) LEN(10)
DCL VAR(&MNURTN) TYPE(*CHAR) LEN( 2)
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---------*/
/* Initial program for general purpose users */
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---------*/
IF COND(&MNURTN *EQ CM) THEN(DO)
CHGVAR VAR(&CALLTYPE) VALUE('Command')
ENDDO
3. Create program type menu to execute command processing program.
CRTNMU MENU(DBInnnPSY/DBI) TYPE(*PGM) PGM(DBInnnPSY/SYC400) CURLIB(DBInnnD)
PRDLIB(DBInnnPSY)
The product can be started with STRDBI or GO DBI.
Regards, Worley
Ron Koudijs
This is al exactly what I needed to hear. ;-)
On Thu, 17 Aug 2000 12:21:02 +0600, Worley Barry
<wor...@databasics.hurst.tx.us> wrote:
>>If the *MSGF is not in the library list you don't see any descriptions
>>while working with WRKLICINF.
>
> Are you sure? I locate everyhing in the product library and
>I just tested WRKLICINF with only QTEMP and QGPL in the library
>list. It displayed the feature discriptions from the message
>file.
For my it doesn't so I have to figure out where I went wrong.
Maybe the message file was not found a creation time of the product
definition ...
> I've written an install command executed by a lodrun
>program. One of the parameters for the install command is
>common command library and it defaults to QGPL. To the best of
>my knowledge everyone has taken the default.
>
> Actually, I have two copies of the commands one in the
>product library and one in 'QGPL'. I create the command in QGPL
>with CRTDUPOBJ in an install exit program.
That's exactly what I did, I only was unsure about the right default.
QGPL or QUSRSYS.
BTW What's the differnce between these two?
AND Nice trick! ;-)
Greetings,
Ron
--------------------
Kou...@Com-Unit.com
Ron Koudijs
You're example is clear to my but are you not mixing up IBM Products
with Non-IBM products? If I would store my command, the only thing a
need outside of my own libraries, in QSYS ... will it still be there
after a Release Upgrade? I'm a freight not.
Ron
On Thu, 17 Aug 2000 12:50:35 -0500, "Charles R. Pence"
<crp...@vnet.ibm.com> wrote:
> For a simple example, look at 57xxQU1. There is a run-time and a
> definition-time division of function; the *QRYDFN produced can be
> used w/out the existence of the product, as well RUNQRY *NONE (file).
> The *PRDDFN and *MSGF are in the product library QQRYLIB <the latter
> not exactly... but it would normally be>. The help/screens for the
> product are in the product library.
>
> For those features which are supported without the product library,
> or which are required to enter the product/application, the run-time
> objects like a *MSGF/screen/help/commands are duplicated/moved from
> the product library into QSYS -- the only library required to be in
> the *LIBL. The command that activates the product/application
> should have been created using the PRDLIB() parm on the CRTCMD, so
> the application's product lib is automatically made part of *LIBL.
> See the WRKQRY command.
>
> I am not sure about the WRKLICINF case....
>
>Regards, Chuck
>All comments provided "as is" with no warranties of any kind whatsoever.
Met vriendelijke groeten,
Ron
--------------------
Kou...@Com-Unit.com
Ron Koudijs
wrote:
>The correct way to solve the problem you are having is to create
>your CL commands with the PRDLIB parameter set to load your product
>library.
That's what I do ...
>Then during install of your product use an install exit program
>to copy your commands into library QSYS.
... but why would QSYS be a better choice over QGPL or QUSRSYS?
What will happen during a Release Upgrade!?
Greetings,
Ron
--------------------
Kou...@Com-Unit.com
Ed Fishel
QSYS is a better choice than QGPL and QUSRSYS because it is always in
the library list. There is no telling where, or if, QGPL and QUSRSYS
will be in the library list. If you use WRKOBJ OBJ(QGPL/*ALL)
OBJTYPE(*CMD) you will find very few commands in these libraries.
Customers expect system type data to be stored in QUSRSYS and user type
data to be in QGPL (it is the default current library). QSYS is used for
operating system and application commands.
During a release upgrade your commands will stay in QSYS unless the
system creates a new command by that name. (Of course if they do that
you will have other problems.)
Just to be clear, do not place your products *PRDDFN object in library
QSYS. It belongs in your products library.
One other thought. You should provide an exit program that will be run
when your product is uninstalled that will remove your commands from
QSYS.
Ed Fishel
Ron Koudijs
wrote:
>One other thought. You should provide an exit program that will be run
>when your product is uninstalled that will remove your commands from
>QSYS.
What exactly do you mean by "an exit program"?
An "exit program" to be used by an "IBM Uninstall Program" which will
uninstall my application? Or just a user writen uninstall program?
Greetings,
Ron
--------------------
Kou...@Com-Unit.com
Ed Fishel
Since your initial question asked about a *PRDDFN (product definition)
object I assumed that you wanted your product to install and uninstall like
products from IBM. (Not installed by using just LODRUN or RSTLIB.) So when
I talked about an exit program I was talking about an install exit program.
Install provides several install exit points that let you call your own
programs at pre and post install and I believe at pre and post uninstall as
well.
Ed Fishel
Ron Koudijs
At the moment I only use the product defintion for license checking.
Right know I'm building my our installation and Cumm.-PTF and PTF
procedures for use with LODRUN. Using tape, optical and networkfile's.
I know there are API's for IBM like install and uninstall, but my time
frame is so thight that I did not dare to "dive into these API's".
Are they easy to use?
Is it flexible?
It must be possible to install the product more than once on the same
machine. For instance to test a new version before taking it into
production. Or to run two totaly seperate administrations with the
same application.
I've a week left, should I take a look at these API's or do I do
better if a just finish my own procedures.
Ron
On Fri, 18 Aug 2000 11:58:56 -0500, Ed Fishel <edfi...@us.ibm.com>
wrote:
>Ron,
>
>Since your initial question asked about a *PRDDFN (product definition)
>object I assumed that you wanted your product to install and uninstall like
>products from IBM. (Not installed by using just LODRUN or RSTLIB.) So when
>I talked about an exit program I was talking about an install exit program.
>Install provides several install exit points that let you call your own
>programs at pre and post install and I believe at pre and post uninstall as
>well.
>
>Ed Fishel
Greetings,
Ron
--------------------
Kou...@Com-Unit.com
Worley Barry
>Ed,
>
>At the moment I only use the product defintion for license checking.
>Right know I'm building my our installation and Cumm.-PTF and PTF
>procedures for use with LODRUN. Using tape, optical and networkfile's.
Are you using the create PTF API without the PRDLOD
objects? I didn't' know that would work. How do you build the
cumulative PTF's ?
>I know there are API's for IBM like install and uninstall, but
my time
>frame is so thight that I did not dare to "dive into these API's".
>
>Are they easy to use?
As always, it depends. I have a complex product with
multiple options and multiple libraries. It became very involved
building the PRDLOD objects and the exit programs for the
products. A simple product with one or two libraries should be
easy to do.
>Is it flexible?
Yes you can call preinstall/postinstall exit programs
for each library and you can have up to ten libraries for each
product load and an unlimited number of product loads for a
product definition.
<It must be possible to install the product
more than once on the same
>machine. For instance to test a new version before taking it into
>production. Or to run two totaly seperate administrations with the
>same application.
>
Almost, you cannot have more that one copy of a 'release
number' on the system at the same time, but you can have
multiple releases on the same system. So you must build a 'new'
release to distribute and then delete it after you've made the
distribution media so you can test the restore of the product on
the same machine.
A major problem with this technique is the database
reference file adds and deletes records for the files
created, deleted, and restored so a lot of deleted records
accumulate in the database cross reference. Be sure to run
RCLSTG for the file frequently while you're testing your
install.
I currently have three releases on my system the base
production release, a CISC, and RISC release.
>I've a week left, should I take a look at these API's or do I do
>better if a just finish my own procedures.
>
I say use your own procedures, if they are working. I needed
a better way to uninstall features and the exit programs provided
a good way to do it.
If someone has not already written an install procedure, I
recommend using the API's. But, I think you must still write
LODRUN and install programs using Restore Licensed Programs
command.
A quick overview of the API's without looking up there names:
You create a Product Load Object that contains the
libraries used by the product and the exit program called when
the libraries are saved, restored, and deleted.
Change every object included in the product with the
change license object command. You must mark every object in the
product for the product load. (This is an Object API)
Package the products reads the product load to see which
libraries to check and then builds a list of all the objects
marked by the change license object command. Object in the
library not marked by the command are not included in the
product.
Save and restore licensed programs.
You cannot save save files created by the save licensed
program command with save save file data. Libraries are not
saved but created by the restore licensed program command.
The text for the libraries is left blank, I wrote an exit
program the change the library text to identify the library.
Regards, Worley
Ron Koudijs
<wor...@databasics.hurst.tx.us> wrote:
>Are you using the create PTF API without the PRDLOD objects?
>I didn't' know that would work.
I only use QSZCRTPD to create a product definition, QLZADDLI to add a
product license and QLZAGENK to generated a license key. Of course I
use some other API's, like QLZARTV and QLZAREQ, to test and request
licenses.
>How do you build the cumulative PTF's ?
;-) I don't have 'real IBM' PTF's. They are just save files. We
distribute them as network files and use our own procedure/program to
check what's in the save file and where it is supposed to go to.
>>Are they easy to use?
>>Is it flexible?
> As always, it depends. I have a complex product with
>multiple options and multiple libraries. It became very involved
>building the PRDLOD objects and the exit programs for the
>products. A simple product with one or two libraries should be
>easy to do.
Thanks for all the information you've provided. I might rebuild our
own procedures sometime now I know that is not going to be that tough.
And since I've build my own procedures I also know:
a) what I want/need to do in the exit programs
b) that I've got most of the coding I will need for these exit
programs.
Ron
Met vriendelijke groeten,
Ron
--------------------
Kou...@Com-Unit.com