Restore librairie et IASP

[frfancha]

Bonjour,
Nous avons 4 IASP tous les 4 contenant la même librairie 'MYLIB' (ce qui est le but de nos IASP: 4 environnements de développement indépendants).
Avec un GO SAVE 21 ils sont tous sauvés sur la tape.
Comment faire, lors d'un restore pour choisir sur la tape la librairie 'MYLIB' d'un IASP en particulier?
En faisant DSPTAP on voit les 4 numéros de séquence des 4 sauvetage de 'MYLIB', et on "devine" qu'elles sont dans "l'ordre" des IASP, mais y a-t-il un moyen plus sûr, par exemple en utilisant le nom ou le numéro de l'IASP dans un des paramètres de la comande de restore?
Merci,
Fred
P.S. le paramètre à utiliser pour indiquer l'IASP ou on veut faire le restore lui on l'a bien trouvé

[Hédhili Jaïdane]

Bonjour.

Avec RSTLIB tu as deux paramètres :
- SEQNBR = N° séquence sur la bande
- RSTASP = N° ASP de restauration.

Ces paramètres se retrouvent dans d'autres commandes de restauration.

[K2R400]

Je pense qu'il faut BRMS pour connaître l'iASP d'origine.
Ce qui est certain, Lorsqu'on fait une sauvegarde complète (option 21) ou des données utilisateur (option 23), les iASPs sont sauvegardés par ordre alphabétique. En le sachant, c'est plus facile pour restaurer.

[rcordonnier]

Bonjour,

nous avons rencontré le problème et notre façon de le résoudre a été des plus simples :

Il suffit de creer un objet dans chaque bibliothèque qui donne le nom de l'environnemt pa exemple une datara (APRD) (ADEV) (ARCT)
ou alors chaque environnement a ces bibliothèques propres EXPLOITDEV EXPLOITPRD EXPLOITRCT EXPLOIxxx.

cela implique lors de la restore de rechercher le premier objet de la bibliothèque ou un type d'objet particulier, mais après la restore est simple..


cordialement

[frfancha]

Envoyé par rcordonnier

Bonjour,
nous avons rencontré le problème et notre façon de le résoudre a été des plus simples :
Il suffit de creer un objet dans chaque bibliothèque qui donne le nom de l'environnemt pa exemple une datara (APRD) (ADEV) (ARCT)
ou alors chaque environnement a ces bibliothèques propres EXPLOITDEV EXPLOITPRD EXPLOITRCT EXPLOIxxx.
cela implique lors de la restore de rechercher le premier objet de la bibliothèque ou un type d'objet particulier, mais après la restore est simple..

Ok, merci, on va faire cela.

Tiens 2 mots sur la raison de l'existence de la même librairie dans différents iASP, pourquoi nous ne développons pas (plus) sur DTEST, DDEV, DQUALIF, DPROD, ... mais que ce sont les iASP qui jouent ce rôle avec le même nom de librairie: c'est parce que tous nos programmes sont des SQL stored procedures. Dans ces procedures les statements SQL sont statiques non qualifiés => cela permet de les compiler dans une lib au choix, mais une fois compilés ils sont qualifiés (PRTSQLINF le montre). Et donc cela ne marche pas de restaurer l'environnement de prod en test si le nom de la librairie change.
Le problème existe aussi avec les vues: si on restaure la librairie X comme Y, les vues de X sont restaurées dans Y mais pointant sur les tables de X... ce qui n'est pas ce qu'on veut.
Bref pour simplifier tout cela: le même nom de librairie dans chaque environnement (test1, test2, qualif, ...) mais séparer par iASP. Du coup ma question du backup/restore.

[K2R400]

@frfancha

Dans ton CREATE PROCEDURE s'il s'agit d'un RPGLE, tu mets directement

EXTERNAL NAME MONPROG
(sans quotes, guillemets, et bibliothèque)
au lieu de
EXTERNAL NAME 'MABIB/MONPROG'

ainsi, il utilisera la *LIBL, tu veux le voir en interrogeant SYSPROCS

[frfancha]

Envoyé par K2R400

@frfancha
Dans ton CREATE PROCEDURE s'il s'agit d'un RPGLE

Ok merci mais ce sont des SQL Stored procedures pas du RPG.

[Mercure]

Envoyé par frfancha

Ok merci mais ce sont des SQL Stored procedures pas du RPG.

Dans ce cas, utilise la *CURLIB.

[frfancha]

Intéressant, mais comment ca marche?

Prenons librairie A et B.
Nous avons ODBC A avec "default SQL library"=A et ODBC B avec "default SQL library"=B.

Soit la stored procedure:
create testproc(in ini int, inout inoutn) language sql begin
select n into inoutn from testtable where i = ini;
end;

Pour le moment on compile testproc dans A et une autre fois dans B.

Connection ODBC vers A, appel (non qualifié!) de testproc => on lit la table a.testtable
Connection ODBC vers B, appel (non qualifié!) de testproc => on lit la table b.testtable.

Comme je l'ai dit ce qui ne fonctionne pas dans ce scénario c'est restore de a.testproc comme b.testproc au lieu de recompile en b, car alors connecté à odbc b et call de b.testproc on lit la table a.testtable.

Je ne vois pas très bien comment arranger ce scénario avec *CURLIB?

[K2R400]

Oulaaaaa... il ne faut pas confondre l'appel de la procédure et l'accès aux données dans la procédure.

Quand tu créés ta procédure, utilises-tu la convention *SQL ou *SYS ?
Car si tu utilises *SYS il va rechercher automatiquement les données dans la *LIBL !!!!!

En ce qui concerne une vue, c'est normal qu'elle pointe toujours vers sa (ou ses) table(s) comme le ferait un index.
Sur l'IBM i une vue ou un index sont représentés comme des fichiers logiques.

[frfancha]

Envoyé par K2R400

Oulaaaaa... il ne faut pas confondre l'appel de la procédure et l'accès aux données dans la procédure.

Sorry, petit problème dans ma manière d'expliquer alors, mais nous utilisons exclusivement SQL sur l'i5 (et avant Orable et DB2 Windows) et je peux t'assurer que je comprends parfaitement ce que sont l'appel de la procédure et l'accès aux données dans la procédure.

Envoyé par K2R400

Quand tu créés ta procédure, utilises-tu la convention *SQL ou *SYS ?
Car si tu utilises *SYS il va rechercher automatiquement les données dans la *LIBL !!!!!

Nous utilisons uniquement *SQL.
Le tout tourne sur i5, mais le but est d'être indépendant de cette machine et d'avoir uniquement du code qui compile tel quel (ou presque) sur DB2 linux/windows ou autre pour être indépendant du choix de la machine.

[Mercure]

A propos de la CURLIB.

Il faut que tu aies au moins 3 bibliothèques :

1. une bibliothèque réservée aux Procédures Stockées (PS). Cette bibliothèque sera désormais la bibliothèque réservée à la création des PS et rien d'autre
2. une bibliothèque pour les fichiers de production
3. une bibliothèque pour les fichiers de test.

Tu ne qualifies rien dans les PS. Le nom des bibliothèques ne doit apparaître nulle part dans le code.
Quand tu crées ou compiles les PS, mets d'abord la bibliothèque des PS dans la CURLIB de ton travail et compiles avec l'option NAMING(*SYS) :

Code :

CHGCURLIB CURLIB(Biblio des PS)

Les PS seront alors créées dans cette bibliothèque.

Au niveau du client (ce que tu appelles "Connection ODBC"), tu vas alors jouer de nouveau sur la *CURLIB.

Par exemple, si tu veux exécuter les PS avec la bibliothèque de production en ligne, tu fais, en amont et avant tout accés aux PS, au niveau de ce que tu appelles "Connection ODBC",

Code :

CHGCURLIB CURLIB(Biblio de production)

et places la bibliothèque des PS dans la *USRLIBL du travail avec par ex. un ADDLIBLE. Comme la *CURLIB est toujours placée en tête, donc AVANT la *USRLIBL, tu alimenteras la BDD de la bibliothèque de production.

Code :

1
2
3
CURLIB  =  BDDProd
USRLIBL =  QTEMP
           BibPS

Même principe avec la bibliothèque de test.

NB : si tu es appelé à modifier/tester une PS, il faut évidemment mettre la PS à tester dans une bibliothèque placée entre la CURLIB et la bibliothèque des PS :

Code :

1
2
3
4
CURLIB  =  BDDTest
USRLIBL =  QTEMP
           TestPS
           BibPS

Est-ce + clair maintenant ?

[frfancha]

Envoyé par Mercure

Il faut que tu aies au moins 3 bibliothèques :

1. une bibliothèque réservée aux Procédures Stockées (PS). Cette bibliothèque sera désormais la bibliothèque réservée à la création des PS et rien d'autre
2. une bibliothèque pour les fichiers de production
3. une bibliothèque pour les fichiers de test.

Ouais pas tout à fait car certaines PS sont changées en quelif / devel par rapport à la prod, mais tu en parles après.

Envoyé par Mercure

Tu ne qualifies rien dans les PS. Le nom des bibliothèques ne doit apparaître nulle part dans le code.

Ca c'est bien clair et c'est ce que nous avons toujours fait. Le souci c'est que au moment de l'exécution du statement 'create procedure ...' l'i5 qualifie pour nous avec les options que nous utilisons actuellement en run sql script.

Envoyé par Mercure

Quand tu crées ou compiles les PS, mets d'abord la bibliothèque des PS dans la CURLIB de ton travail :

Code :

CHGCURLIB CURLIB(Biblio des PS)

Les PS seront alors créées dans cette bibliothèque.

Ok comment ce CHGCURLIB CURLIB se traduit-il en terme d'option run sql scripts?

Envoyé par Mercure

Au niveau du client (ce que tu appelles "Connection ODBC")

Ce n'est pas seulement une appellation, les applications utilisateurs sont des écrans windows qui se connecte via ODBC.

Envoyé par Mercure

, tu vas alors jouer de nouveau sur la *CURLIB.
Par exemple, si tu veux exécuter les PS avec la bibliothèque de production en ligne, tu fais, en amont et avant tout accés aux PS, au niveau de ce que tu appelles "Connection ODBC",

Code :

CHGCURLIB CURLIB(Biblio de production)

et places la bibliothèque des PS dans la *USRLIBL du travail avec par ex. un ADDLIBLE. Comme la *CURLIB est toujours placée en tête, donc AVANT la *USRLIBL, tu alimenteras la BDD de la bibliothèque de production.

Code :

Même principe avec la bibliothèque de test.

Ok mais comment cela se traduit-il en terme d'option dans la config ODBC?

Envoyé par Mercure

NB : si tu es appelé à modifier/tester une PS

C'est ce que les développeurs font tous les jours ;-)

Envoyé par Mercure

, il faut évidemment mettre la PS à tester dans une bibliothèque placée entre la CURLIB et la bibliothèque des PS :

Code :

Ben même question, comment cela se traduit-il en terme d'option dans la config ODBC?

[K2R400]

Envoyé par frfancha

Ca c'est bien clair et c'est ce que nous avons toujours fait. Le souci c'est que au moment de l'exécution du statement 'create procedure ...' l'i5 qualifie pour nous avec les options que nous utilisons actuellement en run sql script.

C'est ce que je t'explique, au moment de ton CREATE PRODEDURE assures-toi d'exécuter le script avec la convention *SYS au lieu de *SQL.

Par quel moyen exécutes-tu tes scripts ?

[Mercure]

Envoyé par frfancha

...quelif / devel...

J'ai un peu de mal à comprendre...

Envoyé par frfancha

comment ce CHGCURLIB CURLIB se traduit-il en terme d'option run sql scripts?

dans le script, exécute en premier lieu la commande

Code :

CL: CHGCURLIB CURLIB(...)

et choisis l'option de naming *SYS, pas *SQL.

Envoyé par frfancha

comment cela se traduit-il en terme d'option dans la config ODBC?

Tu ajoutes les biblio concernées dans l'ordre que j'ai indiqué au paramètre "DEFAULT COLLECTION" dans la chaîne de connexion ODBC. Lire ceci attentivement.
NB : un petit script VB ferait sans doute mieux l'affaire pour établir la chaîne de connexion ODBC et pouvoir jouer plus commodément sur la liste des bibliothèques.

[frfancha]

Desole, cela va peut etre vous sembler bizarre mais nous voulons du code indépendant de l'i5, qui tourne tel quel (ou quasi moyenant des changements syntaxiques minimes realisables automatiquement), donc pas d'utilisation de *SYS ici, seulement *SQL.
Fred

[K2R400]

Envoyé par frfancha

Desole, cela va peut etre vous sembler bizarre mais nous voulons du code indépendant de l'i5, qui tourne tel quel (ou quasi moyenant des changements syntaxiques minimes realisables automatiquement), donc pas d'utilisation de *SYS ici, seulement *SQL.
Fred

Celà n'a rien à voir avec la façon de coder ! et ça ne remet pas en cause les standards. Bref, alors courage avec tes iASPs

[Mercure]

Mais justement, toutes les procédures stockées sont TOTALEMENT INDEPENDANTES de la plate-forme et de l'OS sur lesquels elles tournent.

Leur code ne contient aucun nom de bibliothèque. Le fait de jouer sur la convention de dénomination *SYS et sur la liste des bibliothèques est fonction de l'OS sur lequel elles tournent mais cela n'altère en rien leur code ou leur intégrité. A priori, ces mêmes procédures tourneraient aussi bien sur par ex. LUW telles qu'elles sont écrites.

De surcroît, imposer une dénomination *SQL est pire car, tu l'as dit toi-même, les scripts SQL sont alors automatiquement qualifiés et c'est ce que tu ne veux pas. Alors ?

[frfancha]

Envoyé par K2R400

Celà n'a rien à voir avec la façon de coder !

Ben si énormément. Puisque dans les autres DB les concepts de library list et curlib n'existent pas, il est exclu de baser le design là-dessus.

Sinon pour les iASP jusqu'à présent cela fonctionne parfaitement, cela nous permet d'avoir plusieurs environnements complètement identiques (y compris libl et curlib ;-) ) et de passer de l'un à l'autre sans soucis, et d'avoir plusieurs développements en parallèle dans chacun des iASP.
La seule chose qu'on ne peut pas faire c'est tester des PTF's dans un iASP et pas dans l'autre, mais bon les iASP sont sur la machine de test et elle est là pour cela.

D'ailleurs samedi c'est le grand jour! Mise en prod de nos 2 nouveaux 720 (1 de test/dev, 1 de prod)!
Au fond si quelqu'un est intéressé par un 520 et un 800...

Et merci à tous pour l'aide apportée sur ce forum.

Fred

[frfancha]

Envoyé par Mercure

Leur code ne contient aucun nom de bibliothèque. Le fait de jouer sur la convention de dénomination *SYS et sur la liste des bibliothèques est fonction de l'OS sur lequel elles tournent mais cela n'altère en rien leur code ou leur intégrité. A priori, ces mêmes procédures tourneraient aussi bien sur par ex. LUW telles qu'elles sont écrites.

Ben cela est déjà vrai aujourd'hui. D'ailleurs une (petite) partie d'entre elles vient encore de la migration de DB2 windows vers i5 en 2003.
Migration pednant laquelle un seul changement fut nécessaire:
en DB2 windows c'était:
create procedure truc (
...params...
)
specific truc
language sql
begin
...
et en DB i5 il faut (en tout cas en V5R2 à l'époque) inverser specific et language:
create procedure truc (
...params...
)
language sql
specific truc
begin
...

Et dans cette migration les applications ODBC qui tournaient vers DB2 Windows ont tourné telle quelle sans aucune adaptation/recompilation vers l'i5 (sans ajouter de concept tel que curlib ou autre).

Fred