mardi 8 décembre 2009

RIA Flex & Integration Mainfame

RIA et intégration - comment remplacer vos anciennes applications Windows par un client riche sans complexité ?

Le RIA (Rich Internet Application) est appelé à remplacer les clients lourds des années 1990 (Nsdk, Forte, VB, Uniface, etc...)
Nous avons choisi FLEX pour illustrer cette vocation. Son FLEX Designer - plugin Eclipse - vous a séduit par sa facilité d'utilisation qui le rend aussi facile à utiliser que les AGL de 4eme génération précités ainsi que pour sa gratuité ?
Mais lorsque ces applications sont intégrées à des serveurs de données ou des systèmes transactionnels comme CICS, IMS et d'autres, le RIA n'a pas cette intégration native et vous ne souhaitez pas re-développer une nouvelle API pour le faire dans un serveur Lifecycle.

Nous avons une nouvelle offre qui permet de remplacer vos applications Windows par du RIA. Cette offre est une démarche mixte: Non pas une migration pour l'IHM car les nouveaux contrôles graphiques de FLEX sont bien plus intéressants que ceux offerts par le vieux Nsdk , Nous choisissons de redévelopper l'IHM avec le studio.
Mais nous industrialisons la migration des appels de services et de données externes avec une intégration native des ActionScript de Flex avec les services d'accès aux traitements transactionnels et aux données SQL.

Vous souhaitez en savoir plus ? regardez ce qu'en dit Scort

vendredi 27 novembre 2009

Legacy mainframe integration into SAAS

Comment décloisonner les grands comptes qui ont une vielle informatique et les faire rejoindre le cloud ?

Dans les prochaines années, le développement des activités centrées sur l'informatique va être tiré par le cloud. Cette organisation de l'IT éclatée, dispersée, ou chaque centre interagit avec d'autres centres selon des contrats de service bien précis pour produire une valeur ajoutée jusqu'ici touchait peu le métier des grandes organisations. Parmi les acteurs majeurs on trouve Salesforce, Microsoft, Amazon, Google, Par exemple, connecter une feuille excel sur google documents avec un fournisseur de service pour agréger des données de différentes sources et faire un tableau de bord dynamique. Cela ne touchait en rien le métier du back office de gestion dans l'assurance ou dans la banque. Le "legacy" - comme on appelle souvent les applications coeur de métier d'un guichet bancaire ou d'un agent d'assurance - restait isolé dans sa tour d'ivoire avec un temps d'adaptation et une inertie au changement digne des plus grands tankers face aux véliplanchistes du SaaS.

Les premières expériences de connexion entre Salesforce ou d'autres locomotives du SaaS et l'informatique "on-premise" - c'est à dire les applications internes à l'entreprise - ont commencé sur SAP, Oracle, et des fournisseurs de données. Les plus avancés des candidats au cloud ont crée leur propres web services au dessus de leur "legacy" pour intégrer le CRM Salesforce avec leurs données d'entreprise.
Mais cela supposait pour ces entreprises d'être capable de web servicer les fonctions métier exposées. Et du coup, l'avantage du SaaS, sa souplesse, sa rapidité, ses qualités de non-intrusion et l'approche low cost du SaaS s'en trouvent stoppées net !

Au lieu de semaines, ce sera des mois, au lieu de mois, ce sera des années. Et c'est comme cela qu'on enterre les projets portés par des métiers qui ont besoin de faire mieux, plus vite et avec moins.

vendredi 23 octobre 2009

I Have a Dream

Livre blanc


Et l’Archange Gabriel apparut au Directeur SI et lui dit : « Votre système d’information devra passer au SOA. » Evangile selon Saint Gartner, Verset 12.5

Le jour suivant, Gabriel rendit à nouveau visite au Directeur SI et lui dit : « Mais vous avez six mois pour réussir. » Evangile selon Saint MOA, Verset 13.4

Et l’Archange Gabriel ajouta : « Bien sûr le budget est limité, mais ce n’est pas un problème puisque vous réutiliserez 90% des applications existantes. » Evangile selon Saint Directeur Financier, Verset 6.2


L’informatique on le sait a connu une succession d’ères qui ont commencé avec la préhistoire et ses dinosaures que furent les mainframes. Depuis lors chaque époque apporte sa technologie qui reste insérée dans le mille-feuille du « legacy » : Les applications d’entreprise. Avec cet héritage technologique et la complexification des organisations s’accroit l’inertie opposée aux énergies créatrices et la difficulté à gérer les changements : De moins en moins de patrons sont prêts à assumer le risque du changement et nos sociétés cherchent à se protéger plus qu’à éviter le risque. Les phases de qualification et recette sont budgétivores.

Après le mainframe vinrent le PC et leurs clients lourds, qui ont séduit par la souplesse et la richesse de leurs IHM. Mais avec deux gros inconvénients, il fallait d’une part réécrire le mainframe pour faire des services - ce qui ne fut jamais terminé car cela faisait exploser les budgets – et d’autre part intégrer 200 à 500 clients lourds sur un socle Windows qui n’était pas prévu pour cela et en gérer le déploiement avec sa cohorte de ratés - multipliée par le nombre de postes. Le poste de travail était devenu à la fois un centre de couts et un feu d’artifices d’incidents. Contre cela on « ferma » le poste de travail en empêchant les installations sauvages et on commence à le virtualiser.

Avec l’internet toutes les entreprises prient le virage du web pour les applications d’entreprise. Mais en perdant le client lourd, elles n’ont jamais retrouvé son agilité. Au contraire, le web d’entreprise fut très vite une usine à gaz avec tous ses Frameworks déjà obsolètes quand on commençait à les utiliser. Résultat : le coût de développement du front office est aujourd’hui plus élevé que celui du back. C’est une évidence, mais bonne à rappeler.

Et comme cela ne suffisait pas, les cerveaux bien pensants de l’architecture inventèrent les ESB, EAI etc.… pour réduire les liens point à point qui font désordre dans les « big pictures » de la cartographie. Parfois même on inventa le « middle office » comme une nécessité allant de soit simplement parce qu’on ne savait pas intégrer le front et back ensemble.

Comment garantir un temps de réponse, une bonne disponibilité et une gouvernance simple quand on multiplie les couches ?

Et pendant ce temps, les projets n’avancent pas, les budgets s’allongent et sont amputés par la crise, les métiers et les opérationnels sont pris dans l’étau des objectifs de productivité sans que les moyens IT les accompagnent.

Le paysage de l’informatique d’entreprise est maintenant constitué d’un socle dur et pérenne dans le mainframe et l’ERP qui assurent le cœur des processus stratégiques.

Autour, on trouve des référentiels complémentaires, moins stratégiques (du moins vu d’avion) et souvent avec des données redondantes avec le cœur. Ils répondent à des contrats de service spécifiques, n’ont pas le « batch » à trainer toutes les nuits pour les contraindre à un service dégradé. Ces serveurs font des choses que le mainframe ne sait généralement pas bien faire. Mais pour un mainframe dans l’entreprise on a 500 serveurs de production autour et 5000 postes clients dans la nature … laissant un immense marché aux affairistes de la virtualisation.

Dont acte !

Mais que diable peut-on faire dans cette galère ?

Une entreprise est un corps vivant fait de personnes d’une part - de moyens, et de méthodes et organisation d’autre part. Pour retrouver l’agilité d’une seconde jeunesse, régénérer leur créativité, innover dans leur métier, et développer leurs activités sur le marché, c’est sur ces trois leviers qu’il faut agir en même temps.

  • Avec les humains, on sait travailler en mode projet, on sait beaucoup moins bien travailler ensemble, et pour contourner une difficulté ou une crise souvent on alourdi la complexité.
  • Avec l’informatique on sait empiler (les serveurs comme les logiciels), on sait les oublier, mais du coup on ne sait plus comment ça fonctionne, alors on dit que c’est complexe

Comment dans ce paysage réduire la complexité, travailler ensemble, et aligner les moyens informatiques sur ces objectifs ?


Remettre le métier à sa place

D’abord on dit souvent que les métiers ne savent pas ce qu’ils veulent, c’est pour cela qu’on a inventé les informaticiens, pour dire à leur place ce qu’ils veulent, et s’ils ne le veulent pas c’est qu’ils ont tort.

Eh bien non, ils n’ont pas toujours tort. Et ce qu’ils souhaitent n’est pas toujours impossible.

Il est vrai que pour savoir ce que l’on veut il fait l’avoir rêvé !

Et sait-on encore rêver quand on a travaillé 20 ans avec les vieux écrans du mainframe ?

Rêver n’est pas donné à tout le monde, ça se travaille ! Ça ne vient pas tout seul surtout quand on s’est installé dans une routine ça m’suffit

Parce que justement, cela ne suffit plus. Le monde change et il faut changer avec lui.

Alors qu’est-ce qu’on fait ? On commence par imaginer un monde où le mainframe n’a plus d’IHM, il a des services. Un jour il les aura pour de vrai. En attendant on va l’aider à les fabriquer.

Les IHM, alors parlons-en ! 80% du coût des projets, vous trouvez ça normal ? Et tout cela pour des IHM qui ne valent pas les bons vieux clients lourds d’autrefois.

Alors : « I have a dream… »

  • Rendez-moi mon agilité dit la DSI
  • Laissez-moi rêver à mon poste de travail sans contraintes dit la MOA
  • Donnez-moi un outil qui marche toujours, vite et bien dit l’opérateur sur le terrain.

Et après le rêve, si c’est pour retomber dans la médiocrité d’avant ?

Non, on se met au travail ensemble, on valide les hypothèses en en invitant les gens du terrain

Et puis on écrit le rêve : Oh pour cela pas besoin d’outils d’avant-garde ! Du papier, des couleurs, des dessins maladroits et des notes prises au vol : ça s’appelle un story board

Et puis on commence à construire le rêve. Et le rêve commence par des images, des IHM.

Vous n’avez pas l’application derrière ? Ce n’est pas le problème, on va vous monter le film par séquences détachées. Et la colle, le son, les données, le modèle de données vont venir naturellement.

De toute façon si on en oublie c’est l’affaire de quelques clics pour les ajouter.

Et l’appel des services du mainframe qui est encore à 70% à base d’écrans et de navigations contraignantes ? Comment je fais pour le faire rentrer dans la boîte, pour cacher ces écrans que je ne veux plus voir ?

Les services on les prend là où ils sont, dans le mainframe comme ailleurs. Et pour cela, il y a un standard aujourd’hui, ce sont les web services. Et si vous trouvez qu’ils ne sont pas très performants, qu’on ne peut pas garantir un temps de service très bon sur cette technologie, sachez qu’il y a d’autres solutions qui rentrent dans vos exigences.

Mais mon mainframe, mes applications écran qui représentent 35 ans de savoir faire ?

Eh bien on en fait des services aussi performants que ceux que vous avez déjà écrit, et soit ce sont des services entièrement pris en charge par l’outil d’intégration – soit on se contentera d’intégrer les données de l’IHM de l’application back office dans celle du front sans que jamais l’écran n’apparaisse.

Et comment gérer plusieurs contextes de travail, sous forme d’onglets par exemple, alors que mon mainframe ne le permet pas ?

D’abord on sait rendre le mainframe multi-contexte, sans consommation de ressources supplémentaires.

Ensuite il arrive que des applications interdisent le multi-contexte pour des raisons de sécurité, mais est-ce toujours un problème de sécurité ? Un verrou, ça s’ouvre avec la clé.

Vous avez dit que le mainframe est ouvert, qu’est-ce que cela veut dire ?

Le back office est dans une infrastructure ouverte. Ses services sont accessibles comme n’importe quel composant du Cloud.

Vous avez entendu parler du SAAS, votre back office va exposer ses services aussi pour des front office du Cloud.

Et pour vos CRM et Workflows ou BPM d’entreprise, les services back office viendront s’intégrer quel que soit leur état. S’ils sont déjà servicés, cela demande quelques minutes de les intégrer

S’ils ne le sont pas, il faudra juste quelques heures …

Yes we can !

Je n’y crois pas … on rêve

Non, vous ne rêvez pas, ça existe chez d’autres, et ça peut aussi vous arriver si vous le voulez

Le voulez-vous ? Alors appelez-moi

mardi 13 octobre 2009

Dupliquer un IMS

Vous vous êtes peut être demandé comment on défini plusieurs IMS dans le même groupe XCF et comment on duplique un IMS pour avoir un backup

Dans l'exemple ci-dessous, on a dupliqué IVP1 en IVP2 en partageant le maximum de choses et en ne dupliquant que ce qui est nécessaire. Le but est de mettre en place un pooling des connexions depuis un connecteur JCA IMSConnect et de tester la continuité du service en cas de rupture d'un IMS avec reprise des pseudo conversations en cours dans l'autre IMS


Construction d’un nœud majeur VTAM

Modification du démarrage automatique de VTAM

ADCD.Z19.VTAMLST(IMS91AP2)

IMS91AP2 VBUILD TYPE=APPL

IRLM1 APPL AUTH=ACQ,DLOGMOD=IRLM,MODETAB=IMS91TAB

JRLM2 APPL AUTH=ACQ,DLOGMOD=IRLM,MODETAB=IMS91TAB

IMS3272 APPL AUTH=(PASS,ACQ,SPO),DLOGMOD=IMS,MODETAB=IMS91TAB,

PARSESS=YES,HAVAIL=YES,ACBNAME=IMS91CR2

Ajout d’un Datastore IMSConnect

EDIT IMS910.PROCLIB(HWSCFG00) - 01.28 Columns 00001 00080

Command ===> Scroll ===> CSR

****** ********************************* Top of Data **********************************

000001 HWS (ID=HWS,RACF=Y,XIBAREA=20)

000002 TCPIP (HOSTNAME=ZOS19,RACFID=RACFID,PORTID=(4004),MAXSOC=2000,

000003 TIMEOUT=8888,EXIT=(HWSSMPL0,HWSCSLO0,HWSCSLO1))

000004 DATASTORE (ID=IVP1,GROUP=DTSCIMS,MEMBER=HWSMEM,TMEMBER=DTSCOTMA,

000005 DRU=HWSYDRU0,APPL=TSTNETAG)

000006 DATASTORE (ID=IVP2,GROUP=DTSCIMS,MEMBER=HWSMEM2,TMEMBER=DTSCOTM2,

000007 DRU=HWSYDRU0,APPL=TSTNETAB)

000008 IMSPLEX (MEMBER=PLEX1,TMEMBER=PLEX1)


Nouvelle région de contrôle: seuls les fichiers dupliqués sont indiqués ici, les autres sont partagés avec IVP1


ADCD.Z19.PROCLIB(IMS91CR2)

// PROC RGN=64M,SOUT=A,DPTY='(14,15)', 00000010

// SYS=,SYS1=,SYS2=, 00000020

// RGSUF=IV2,PARM1='RRS=Y', 00000030

// PARM2='OTMA=Y,OTMASE=N,GRNAME=DTSCIMS,OTMANM=DTSCOTM2'

………..

//******** MESSAGE QUEUE STATEMENTS ****************** 00003680

//* 00003690

//QBLKS DD DSN=IMS910.IVP2.QBLKS,DISP=OLD 00003700

//SHMSG DD DSN=IMS910.IVP2.SHMSG,DISP=OLD 00003710

//LGMSG DD DSN=IMS910.IVP2.LGMSG,DISP=OLD 00003720

…………

//MODSTAT DD DSN=IMS910.IVP2.MODSTAT,DISP=SHR 00003800

……….

//DFSTCF DD DSN=IMS910.TCFSLIB2,DISP=SHR 00004060


Nouveau paramétrage de cette région de contrôle pointée par RGSUF=IV2

IMS910.PROCLIB(DFSPBIV2)

APPLID1=IMS91CR2,

APPLID1=IMS91CR2,

DBRCNM=IMS91RC2,

DBWP=024,

DLINM=IMS91DL2,

IMSID=IVP2,

OTMANM=DTSCOTM2,

PRDR=IMS91RD2,

Paramétrage des nouvelles régions attachées à IVP2

ADCD.Z19.PROCLIB(IMS91DL2)

// PROC RGN=64M,DPTY='(14,15)',SOUT=A, 00000010

// IMSID=IVP2,SYS2= 00000020

//IEFPROC EXEC PGM=DFSMVRC0,REGION=&RGN, 00000030

ADCD.Z19.PROCLIB(IMS91CR2)

// PROC RGN=64M,SOUT=A,DPTY='(14,15)', 00000010

// SYS=,SYS1=,SYS2=, 00000020

// RGSUF=IV2,PARM1='RRS=Y', 00000030

// PARM2='OTMA=Y,OTMASE=N,GRNAME=DTSCIMS,OTMANM=DTSCOTM2'

//IEFPROC EXEC PGM=DFSMVRC0,DPRTY=&DPTY, 00000040

ADCD.Z19.PROCLIB(IMS91RD2)

// PROC MBR=IMSMSG2,CLASS=A,SYS2= 00000010

//IEFPROC EXEC PGM=IEBEDIT 00000020

//SYSPRINT DD DUMMY 00000030

//SYSUT1 DD DDNAME=IEFRDER 00000040

//SYSUT2 DD SYSOUT=(&CLASS,INTRDR),DCB=BLKSIZE=80 00000050

//SYSIN DD DUMMY 00000060

//IEFRDER DD DISP=SHR, 00000070

// DSN=IMS910.&SYS2.JOBS(&MBR) 00000080


ADCD.Z19.PROCLIB(IMS91RC2)

// PROC RGN=64M,DPTY='(14,15)',SOUT=A, 00000010

// IMSID=IVP2,SYS2= 00000020

//IEFPROC EXEC PGM=DFSMVRC0,REGION=&RGN, 00000030


Ajout d'un nouveau membre IMSMSG pour démarrer les depedent regions

IMS910.JOBS(IMSMSG2)

//IMS91M21 JOB ACTINFO1,

...

//IMS91M21 EXEC PROC=DFSMPR,TIME=(1440),

...

// IMSID=IVP2, IMSID OF IMS CONTROL REGION

...

//IMS91F21 JOB ACTINFO1,

...

//IMS91F21 EXEC PROC=IMSFP,TIME=(1440),

...

// IMSID=IVP2, IMSID OF IMS CONTROL REGION

...

//IMS91F21 JOB ACTINFO1,

...

//IMS91F21 EXEC PROC=IMSFP,TIME=(1440),

...

// IMSID=IVP2, IMSID OF IMS CONTROL REGION

...

//IMS91F23 JOB ACTINFO1,

//IMS91F23 EXEC PROC=IMSFP,TIME=(1440),

...

// IMSID=IVP2, IMSID OF IMS CONTROL REGION



mardi 21 juillet 2009

Le BPM libère les mainframes

SCORT spécialiste de l'intégration des mainframe et Lombardi leader mondial du BPM ont signé un partenariat pour l'intégration des processus métiers avec le patrimone des services métiers existants sur les mainframes. A cette occasion a été réalisée une intégration directe avec des transactions IMS et/ou CICS en mode service mais aussi par réutilisation des IHM des systèmes transactionnels dans le BPM.

Deux petites minutes pour découvrir comment ça se passe ...

Lombardi®, l’un des principaux éditeurs de logiciels de gestion des processus métier (BPM), présente aujourd’hui Teamworks® 7, la nouvelle version de sa suite de BPM. Teamworks 7 permet aux entreprises non seulement d’automatiser et de contrôler leurs processus stratégiques mais aussi d’accroître le retour sur investissement de leurs programmes de transformation métier à grande échelle.

mercredi 27 mai 2009

mise en oeuvre du passticket IMS & CICS

L'usage du passticket en remplacement du password pour l'authetificqation des accès aux mainframe IBM sous le système de sécurité RACF est maintenant répandue
Toutefois le passticket étant non rejouable par défaut, chaque authentification doit présenter un nouveau passticket pour un même utilisateur, une même application cible sur le mainframe (IMS, CICS ...) et un même groupe (au sens RACF connect group)

Le passticket utilisé sur une session 3270 n'est utilisé qu'à l'établissement de la session. Les messages échangés au cours de cette session ne sont pas authentifiés.
Mais lorsque le passticket est utilisé en mode service, chaque accès doit porter un nouveau passticket, car il n'existe pas comme en SNA 3270 de session.

Le mode service pour IMS utilise le connecteur IMS Connect. Pour CICS, il utilise le connecteur ECI et peut être associé au bridge pour accéder des transactions en mode écran.

Comment éviter alors d'engendrer une forte augmentation de la consommation de ressources de RACF qui va être sollicité à chaque authentification ?

Pour IMS Connect, il existe IMS Connect Extension qui cache les passwords durant une période paramétrable dans une ACEE Ageing Table; évitant ainsi de faire appel à RACF systématiquement. Mais ce caching ne fonctionne pas pour des passtickets. Il entre en fonction pour un même userid, password et connect group et dans la limite de temps donnée.
Pour forcer IMS Connect Extension à cacher des passticket, il faut rejouer le passticket et ne le regénérér que s'il est rejeté.

Pour CICS il n'y a pas d'équivalent. la seule solution est de rendre le passticlet rejouable en précisant RDEFINE applname APPLDATA(’NO REPLAY PROTECTION’) dans la définition RACF.
Et si on veut cloisonner plusieurs environnements qui générent des passtickets, on peut définir plusieurs passtickets pour une même application. L'une avec et l'autre sans la protection contre le REPLAY
exemple:
- RDEFINE applname pour tout le monde
- RDEFINE applname.groupname APPLDATA(’NO REPLAY PROTECTION’) pour l'application qui utilise le REPLAY dans la limite de temps des 10 mn fixée par RACF.

lundi 23 février 2009

prendre une trace IMS

Prendre une trace IMS, c'est simple

/TRACE SET ON TRAN
/SWITCH OLDS (pour avoir juste la trace qui nous intéresse)
Jouer le scénario à tracer
/SWITCH OLDS pour fermer le fichier log
/SET TRACE OFF TRAN
Chercher dans le job généré IMS81JCL le dsname associé à DFSLOGP (attention il doit être en DISP=(NEW,CATLG) dans la procédure IMS810.PROCLIB(ARCHJCL) et je l’ai mis par défaut à DELETE pour éviter d’avoir à gérer les fichiers archives de IMS)
Et remplacer dans SYSUT1 ci dessous

Puis passer le job suivant et chercher dans son sysout

//IMSERA10 JOB ACTINFO1,'IBMUSER',CLASS=A,MSGCLASS=H,MSGLEVEL=(1,1),
// REGION=0M,NOTIFY=&SYSUID
// EXEC PGM=DFSERA10
//STEPLIB DD DSNAME=IMS810.SDFSRESL,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSNAME=IMS810.SLDSP.IVP1.D07270.T1310344.V02,
// DISP=(OLD,KEEP)
//SYSIN DD *
OPTION PRINT
END