Infobase Section 8

	HOME FAQ Contents Part 1 Part 2 Part 3 Part 4 Part 5 Part 6 Part 7 you are here Part 9 Part 10 Part 11 Part 12	The ISSUG Infobase contains archived postings from our on-line discussion forums. Nothing here may be quoted without the written permission of the author(s) of the original postings. The Infobase is organised into 12 sections concerning different topics. FAQ content: Ram Malladi

Part 8: Deployment 8.1) Source Management of Composer generated code 8.2) How to distribute Client Software? 8.3) How to reduce Load Module Size? 8.4) How to use the Encryption on the Internet for Client/Server 8.5) How to Managing OLE files for Composer 4 OCX? 8.6) How to Handle the comunications in Client/Server environment ? 8.7) Why should we add these Composer 4 run-time DLLs on users PC? 8.8) Composer 3 application working on NT, but not on 95 8.9) Promotion of Dynamic-linked modules across environments 8.10) Client Manager wrapper for OS/2 8.1) Source Management of Composer generated code Venu Gopa, Dated : 28 August, 1997 at 08:13 Subject: Source Management of Composer generated code Hi, We are using the product CHANGEMAN for the source management at our installation. We are on MVS server. I have few queries on the integartion of CHANGEMAN with COMPOSER. I would like to know if any body is using CHANGEMAN for the source management. With regards, Venu Gopal. ======== Darius Panahy, Dated : 29 August, 1997 at 08:54 Subject: Re: Source Management of Composer generated code Hi Venu, We have developed a configuration management system for Composer called GuardIEn. We also have some customers who use Changeman for promoting changes to production and we have developed an interface between GuardIEn and Changeman. In summary, GuardIEn will automate the migration and generation of the source code and then stage the generated components to Changeman using the CMN APIs. It also updates the Changeman package content so that the final move to production can be authorised at the Changeman package level, perhaps also including components that were developed outside of Composer. Further details of GuardIEn at http://www.iet.co.uk. Please also contact me direct if you would like more details on the Changeman interface. Regards Darius Panahy Information Engineering Technology dpanahy@iet.co.uk ======== R. G. Eaton Dated : 29 August, 1997 at 14:04 Subject: Re: Source Management of Composer generated code We are addressing a similar situation. Does you have interfaces to Endevor? The source isn't a primary concern. Managing the object load and executables is our primary concern. Do you have a recommendation for managing client executables? ======== Darius Panahy Dated : 01 September, 1997 at 09:21 Subject: Re: Source Management of Composer generated code Yes, we have customers who have linked GuardIEn to Endevor, SCLM, Librarian and in house tools for managing source and object code. Our production updating module contains facilities for developing customised interfaces to other tools, and we have a customer that has linked GuardIEn to Endevor. Whilst some of our customers use GuardIEn to update production, the primary reason for developing these interfaces is to allow production support to have a single tool for updating the production libraries, whatever tools were used to develop the application. For the client side, the main problem in the past has been that the source code has to be generated on the workstation which is not a secured/controlled environment. Furthermore it is not possible to automate the construction of the source code using the workstation toolset. The C4 host encyclopaedia now supports generation of source code for co-operative servers but not clients. However the client/server encyclopaedia (CSE) does allow generation of both client and server code. We have just announced a new release of GuardIEn for the CSE that supports the automated generation of both client and server load modules using the CSE. At present it will generate the source for clients and servers and build the rmt file. The code can also be compiled and linked using GuardIEn's own routines or it could be transferred to a product like Endevor along with control information, link-edit response files, etc. for this tool to perform the compile and link. Regards Darius Panahy Information Engineering Technology 8.2) How to distribute Client Software? Preben Nilsson, Dated : 25 February, 1997 at 10:05 Subject: Client software distribution Hi there, I was wondering, how those of you doing C/S systems are distributing the client parts of the systems to the end users. Our current situation is, that the client parts of our C/S systems are placed on 1 central LAN-server, and the end users run the programs from that LAN-server. To get access to the programs, we manually setup the icons on the users desktops. In the near future, we will have to distribute the programs to multiple LAN-servers and target many more (+500) users than we have been used to so far, so automation is a must. So if any of you do LAN-server mirroring, maintenance of end-user desktops etc. in an automated way, I would like to hear from you (including product names). Best regards/Preben Nilsson FDB Data - Denmark ======== Kevin Bingham, Dated : 26 February, 1997 at 09:26 Subject: Re: Client software distribution You don't stipulate which Operating system you will be implementing on, so generic answers probably won't solve your problem.... However, WinNT 4 has some very useful features on resource sharing and remote administrator access. As and administrator, you could setup someone's desktop for them remotely, pointing to LAN based software. This would include desktop icons and/or "Start Menu". I'm sure that as use of WinNT4 proliferates, a tool/technique will become available to do this for many workstations, in "batch" mode. I hope that this helps. Regards, Kevin Bingham Mike Bergen & Associates. ======== Sean Hansen, Dated : 28 February, 1997 at 10:20 Subject: Re: Client software distribution I would recommend using InstallShield -- I know its typical, but the new InstallFromTheWeb component will allow you to distribute files to remote users quite easily -- especially when needing to send new .dll's, etc. I know it will take some form of user intervention and a method of client app versioning and version checking, but I've tested it wit C4 and it seems to work well. -- Distribute once via a master CD, then perform enhancements via InstallFromTheWeb. 8.3) How to reduce Load Module Size? Ram Malladi, Dated : 18 November, 1997 at 18:33 Subject: Load Module Size Reduction Introduction: ---------- Envirnonment is MVS/DB2/Client-Server and Batch/Composer3. This is a big system with lots of procedures and action blocks. Some action blocks are common in Batch and Server Load Modules. Right now all the action blocks and the procedure step are built into a single load module. But the client wants the Loadmodule size to be less than 700K for the server load modules on MVS/DB2. This may involve calling some action blocks dynamically on the Server. A good analogy would be breaking a large EXE to a small EXE and several DLLs on the PC. The catch is Only Server Load modules (please don't get confused with Batch load modules) need to be broken. We can leave the Batch load module bigger, if we want to. On the Generation window, we can set the parameter on how the action block will be called. We can either have it called statically (built into a single load module) or dynamically (several object modules). But if we change it in one place, it gets set globally. Question: ----------- Have you experienced a similar situation? How did you break large load modules on the server into smaller ones? What are the points to be noted for development/deployment and model management? Thank you for your help Ram Malladi ======== Glenn Smyth, Dated : 19 November, 1997 at 11:53 Subject: Re: Load Module Size Reduction Three approaches to address this : 1) Leave the common routines as being dynamically called in Batch. It improves performance in batch also (we ran extensive tests on this when I was at DEETYA). The only hassle here is that the CE does not handle having a dynamically called action block that runs in two environments (CICS and Batch in this case). Well it can sort of but it is such a nightmare to use it that it is effectively un-useable. We wrote a simple additonal panel which we added to the CE which re-links the dynamic action block after it has been generated for one (say for CICS) to create versions for all other environments, batch TSO etc. This requires adoption of PDS type naming standards). I can send you a paper on this process. 2) Adopt CBD as this can be handled inherently due to the use of separate specification and consuming models. As this is probably a bit too major an undertaking now :-) the third option below is a chopped down version that only covers the bits who would need to do to address your issue. 3) Firstly you would need to develop your batch in a separate model from the online. Once you have a separate model then migrate the action blocks (after they have been given member names) that are common to the batch model. Change them to be statically called and then check out the action blocks. Delete all statements and change them to be external. Then add the NCAL library from the online model to the batch business system external libraries (not required if it is the same as the batch as it is in most cases)and away you go. The action blocks are always maintained and generated in the online model where they are always defined as dynamically called. This works because when you generate and install a dynamic action block it still creates (as it has to) the NCAL version so it will be available to be statically linked from the batch model (as it is defined as static in that model). Note that unless the views of the action block change you do not need to migrate the action block to the batch model again. If they do change then you can manually change the views in the batch model to match or migrate and then delete all statements again as described above. Hope this helps, Mail me some feedback if you decide to use one of the options as it would be good to see whether or not anyone uses any of the answers I am putting up here or is it more like 'God its that bloody Glenn Smyth again' :-) ======== Peter Brennan, Dated : 19 November, 1997 at 15:54 Subject: Re: Load Module Size Reduction Ram, As Glenn suggests it is probably easier in the long run for you to make the required action blocks dynamic in both environments. And then just re-link them for the different environments. It makes life a lot easier and doesn't cause any significant perfomance overhead ( unless STROBE lies of course... ) One thing that you may need to be watchful of is that under CICS (3.3 or less ) You'll have to define all your dynamic programs in the PPT, and that they end up in a load library that is available to CICS. If not you will get all these wonderful -1029 Cobol II runtime errors!! In CICS 4.X, if you have autoinstall turned on, definition of the programs isn't required at all. In batch, all of the dynamic modules will need to be accessible via the STEPLIB for the Job Step.. Glenn - do you have a access to a copy of the Panels/JCL we wrote to relink the modules? I seem to have lost it somewhere between Oz and Finland... Peter ===== Ram Malladi, Dated : 19 November, 1997 at 23:21 Subject: Thanks Glenn & Peter Glenn,Peter Thank you for your posting. Looks like Sterling also recommended the same thing. We are going to have action blocks called dyanamically in both batch as well as on-line. In your mail, you mentioned that you have a document which highlights the process. Would you please send it to me. Also we are using "Changeman" for library management. Dis use the same or some other tool? What are your comments? Thank you once again... Ram ====== Keith Attai, Dated : 22 November, 1997 at 05:47 Subject: Re: Load Module Size Reduction Glenn, I had just starting thinking about this same problem and was happy to see your potential solutions. I was looking for an easy way to use dynamic linking in support of both a CICS and batch environment. I would like to get a copy of your paper that discusses the process for solution #1. Are you also willing to share your code? Does it also work with Intelligent Regeneration? Thanks ======== Glenn Smyth, Dated : 24 November, 1997 at 10:58 Subject: Re: Load Module Size Reduction I will e-mail the paper discussing the approach to you. DEETYA has intellectual property rights on the code (as it is was developed while I was there) so I can't a vendor with that I'm afraid. If you are interested please contact Mike Borucinski (mgr applications Architecture section) on 00 66 6 240 5614 if you wish to discuss obtaining the code. Yes, it does work with intelligent re-generation. It is a stand alone utility that is added to the CE and does not modify any of the existing CE functionality (unlike, say, the CE/Endevor integration). Glenn ======== Peter Robinson, Dated : 25 November, 1997 at 01:10 Subject: Re: Load Module Size Reduction Ram Another thing to consider when you change action blocks to dynamic is the fact that Composer likes to link edit all dynamics used within a procedure step. Even intelligent regen doesn't handle dynamics very well when it comes to link-editing. If you install a load module with the linkedit dynamics flag turned on, you will often end up linking far more than you need to - wasting a lot of time and causing all sorts of fragmentation problems in your load libraries. This is even worse when you have to install a number of load modules that all use the same dynamic action blocks, because the same action blocks will be linked over and over (even intelligent regen will do this). Of course all this is really only a problem if you have a large number of dynamics. If, like us, you end up with a lot of them, it is best to do your installs with the link-edit dynamics option set to 'no' and then go back and use a method like what Peter and Glenn have previously suggested to link only the dynamics that are required. There are some tricks to making sure you don't get problems - like making sure that your dynamics don't call statically linked action blocks because a change to the static one means the dynamic action block needs to be link-edited and that can be difficult to detect (that's why composer always wants to do everything - brute force rather than use some smarts). PJR 8.4) How to use the Encryption on the Internet for Client/Server Larry Barreca, Dated : 03 December, 1997 at 04:00 Subject: Encryption, Virtual Private Networks We are getting ready to deploy a distributed client/server application built with Composer 3. This application will be running Windows 95, Windows NT, and Windows 3.x clients communicating via TCP/IP with MVS CICS COBOL server programs. We have a Communications Bridge (version 4.1a) running on Windows NT v4.0. Some of our users want to use a local ISP to connect to the Comm Bridge through the internet. We would like to use encryption to protect the IP packets. We have tested a digital signature/virtual private network solution from two companies called Entrust Technologies and Sagus Security but could not get this to work with Client Manager. Has anyone used the internet for their client/server applications? If so, did you use IP tunneling, VPN, or some other encryption solution that worked with Client Manager v4.1a and Communications Bridge v4.1a. Thanks in advance for any information on this. Larry ======== Martin, Dated : 03 December, 1997 at 15:38 Subject: Re: Encryption, Virtual Private Networks Hallo Larry, sorry that I cant offer a solution for your problem. But we use a similar environment (NT-Clients, MVS-Host). I am migrating our CommBridge(3.0) from OS/2 Communication Mangager to Win NT SNA-Server. . I use SNA Server 3.0 on NT 4.0. I had problems providing the information for SNA-Server-configuration. Sterling Support told me to use the paper "step-by-step How To..." from Customer Support Newsletter of June/July 1996. I tried to use the information from this article and supplied the information for SNA-Srv. 3.0 (the article refers to 2.1 and configuration has changed in many ways). But ComdBridge doesnt work (return code 609). Have you experience in configuring SNA-Server? How can I test and troubleshoot the connection? (I have tested 3270-Emulation over SNA-Serve, which showed me that the connection to MVS via VTAM works). In ComBridge Trace I receive the following error-message: 12/03 16:02:12 TID:350 TIRCOMM thread TID 350 starting... 12/03 16:02:12 TID:350 Target System LICT3, Transport Type: CPI-C 12/03 16:02:12 TID:350 Transport configuration: IO6253N/Y/N/LC4EI00/LICT3/LU62IEF/CICS/32767 12/03 16:02:12 TID:350 Constructing CIF object for target [LICT3] 12/03 16:02:13 TID:350 Target LICT3 CIF ID is: 0xbd0740 12/03 16:02:13 TID:353 Creating RecvComm Thread for LICT3 12/03 16:02:13 TID:353 [LICT3] >> IefnetOccpCUCommSetup()... In Progress 12/03 16:02:13 TID:353 RecvComm Thread Connected to Target System LICT3 12/03 16:02:13 TID:353 [LICT3] >> IefnetOccpCUCommRecv()... In Progress 12/03 16:02:13 TID:350 [LICT3] >> IefnetOccpCUSetup()... In Progress 12/03 16:02:13 TID:350 [LICT3] >> IefnetOccpSetup()... In Progress 12/03 16:02:13 TID:350 [LICT3] OCCP Type: IO6253N, LLU: LC4EI00, PLU: LICT3, MODE: LU62IEF 12/03 16:02:13 TID:350 [LICT3] OCCP Target TP Name: ECHO , User ID: gierlin 12/03 16:02:13 TID:350 [LICT3] Attempting WinCPICStart() 12/03 16:02:13 TID:350 [LICT3] Return From WinCPICStart() - Completed OK 12/03 16:02:13 TID:350 [LICT3] Attempting CMINIT 12/03 16:02:14 TID:350 [LICT3] CPIC: CMINIT - RC = PRODUCT_SPECIFIC_ERROR 12/03 16:02:14 TID:350 [LICT3] CPIC: CMINIT - SYM_DEST_NAME = 12/03 16:02:14 TID:350 CIF Setup failure for target [LICT3], return code = 301 12/03 16:02:14 TID:350 [LICT3] ERROR, OccpSetup FAILED Have you any ideas what could cause the problem? If you think you could help me, please contact me by e-mail at martin.gierlinger@voest.co.at Thanks! Kind regards Martin 8.5) How to Manage OLE files for Composer 4 OCX? Kevin Bilodeau, Dated : 02 May, 1997 at 01:38 Subject: Composer 4 OCX Controls and .ole files I am interested in anyone who has figured out a way to manage the .ole files that you must keep up with when using OCX Controls with Composer 4. They are not as easy to deal with as the Bitmaps are. You must keep them for each Window/Control that is added. I understand that these files as well as bitmaps may be incorporated into the Encyclopedia in about a year. Any information will be appreciated. ======== Doug Michael, Dated : 02 May, 1997 at 12:00 Subject: Re: Composer 4 OCX Controls and .ole files For those who havent come across it yet, this is the problem: Every time you add an OCX to a window, Composer creates a binary file with extension .OLE in the model /ole subdirectory in which the persistent state (property values) of that OCX is stored. As Kevin says, this information is not uploaded to the encyclopaedia so you have to manage it yourself manually. This is more difficult than with bitmaps because its not easy to tell from the filenames which OCXs they relate to. If you generate a window with an OCX on it which doesnt have the right .OLE file you get an OLE Area "black hole" on your window instead of the OCX. The .OLE filenames are a concatenation of procedure name and control name but if you dont give your controls meaningful names you cant tell which ones which (the default names would just be OLEControl1, OLEControl2, etc). If you change procedure and/or control names after adding OCXs, the filenames dont change so you can get into even more of a mess. The problem was made worse in early versions of Composer 4 because upload/download operations seemed to randomly delete .OLE files on the workstation, but this has been fixed now. A related problem is that when you come to deploy your application you need to be able to know which versions of which OCXs it uses and the names of the DLLs so you can create your setup procedures accordingly. In response to specific requests from people facing these problems we have included in our Exposer 4 product the facility to create a report from model DAT files or CSE which lists what versions of what OCXs are used on what windows AND the names of the associated .OLE files. More info at http://ourworld.compuserve.com/homepages/rainier Doug Michael Rainier Software 8.6) How to Handle the comunications in Client/Server environment? Preben Nilsson, Dated : 17 February, 1997 at 14:11 Subject: TCP/IP communication to C/S clients. Hi there, We are about to construct a C/S system for around 500 end-users in multiple locations, all of them running Windows 3.1. Our current C/S systems use a setup, where the Windows 3.1 clients talk NetBIOS to an OS/2 Comms. Bridge, which in turnn talks LU6.2 to the host (CICS). We would like to use TCP/IP all the way, but it seems that the only way to do that is via PIPES. We have already tried PIPES on top of NetBIOS, and that gave serious performance degradations. So if any of you good people make C/S systems for Win3.1 and CICS and use TCP/IP for some/all of the communication, pls. drop a line. If you have had success using PIPES on a windows 3.1 platform, I would be interested in feedback as well. Regards, Preben Nilsson (-: ======== Kevin Bilodeau, Dated : 19 February, 1997 at 03:02 Subject: Re: TCP/IP communication to C/S clients. I understand where you have been and where you want to go. We started out 3 years ago with an OS/2 Bridge and Netbios. We then tried using TCP/IP from the PC to the bridge using PIPES. This was a mistake. PIPES gave us performance and configuration problems. We are now using a Windows NT Bridge and use TCP/IP from the PC to the Bridge and then LU6.2 from the Bridge to CICS. This solution has been great. We never have any problems and the performance is good. I think that TI has plans to have a direct TCP/IP connection from the PC to the Mainframe by Dec. 1997. ======== Piergiorgio Ardizzi, Dated : 20 February, 1997 at 17:40 Subject: Re: TCP/IP communication to C/S clients. We're at development stage with a Client/Server project. Our target platform is the same as yours, that is Win 3.1 clients with MVS/CICS/DB2 Server. Regarding the communication architecture, we're trying to test some of the possible configurations offered by the tool: 1. CM - Pipes - CB - APPC - MVS/CICS 2. CM - Pipes - MVS/CICS 3. CM - Socket - CB NT - APPC - MVS/CICS 4. CM - Netbios - CB - APPC - MVS/CICS Initially we were planning to target the PIPES MVS solution because we thought that a direct TCP/IP connection should be more performant. This could be true, but what we've experienced up to now is that PIPES is not steady as it should be, and it's been giving us quite a lot of troubles in trying to determine where the problems could be. It may also be that the problems we've had so far could be caused by our network configuration but, as a matter of facts, the other solutions, that obviously work on the same network, are not giving us such problems. We've not yet made detailed performance testing but, for instance, the Socket connection (via CB NT - APPC) is very simple in configuration and seems to be at least performant as the PIPES connection. Anyway, we haven't decided to leave PIPES, and we're also looking for contacts with other companies that are exploiting PIPES solutions, succesfully and not. Regards Pier 8.7) Why should we add these Composer 4 run-time DLLs on users PC? Ram Malladi, Dated : 20 May, 1997 at 12:01 Subject: Composer 4 Runtime DLLs on Users PC. Hello... Looks like something strange is happening. Problem background: We have developed Composer 4 GUI on Windows NT 3.51, Visual C++ 4.2 and Local Database of Oracle 7.3 on Windows NT. The Client excecutables (generated in Cooperative mode) are working in development environment, system test environment (which is similar to development environment). Last week we installed the client executbles on Users PCs (Windows NT 3.51) successfully. BUT during the installation we had to provide some runtime DLLs of Oracle and Visual C++. Problem: 1) Why do we have to provide DLLs of Oracle 7.3 and MS Visual C++ on users PC? These are the DLLs copied onto users PC. Core35.dll core35o.dll kg73.dll msvcrt.dll nlsrtl32.dll ora73.dll sqllib18.dll 2) If we have to live with these DLLs on users PCs, Do we have to buy Oracle and VC++ licences for the users as they have those DLLs sitting on their PCs? Regards, Ram Malladi British Telecom, London. ======== george simpson, Dated : 20 May, 1997 at 15:03 Subject: Re: Composer 4 Runtime DLLs on Users PC. Ram, Oracle usually gets paid by the # concurrent users. The runtimes get distributed freely. I'm worried here, youre deploying the app and run time to the work station and not the lan. Regards, George ======== Ram Malladi, Dated : 22 May, 1997 at 15:51 Subject: Re: Composer 4 Runtime DLLs on Users PC. George, My message may not be very clear. We got Brand new PCs for users. Before we installed our Client executables, all they had was Windows NT 3.51 and network software. That's all. They had no Oracle products (even SQL net etc..) Then we installed the client executables, Composer 4 Client Manager and some Composer 4 runtime DLLs. At that stage when we tried running the Client exceutables, we got some error messages saying "MSVCRT.DLL" not found etc. The same message appeared (for different DLLs) until we provided all the DLLs which I listed in my first posting. After all the DLLs are copied, everything seems OK. Now when we click on the Client Exceutable Icons, application talks through the Composer 4 Client Manager to the remote Database. Regards, Ram ======== george simpson, Dated : 22 May, 1997 at 23:22 Subject: Re: Composer 4 Runtime DLLs on Users PC. Ram, Being clear on the www is becoming a full time problem for me. I've never been kicked of a list server,,, yet ! If you go into your msdev (microsoft c++) and do a keyword search on "loadlibrary" it will return to you a description of the where and when it will look when it loads a dll. I think some products also search the libpath, though I can't remember for sure. The reason you need the dll's is because when you precompiled, and linked, it referenced code to these in it. You all had these, your new pc's didn't. The msvcrt??.dll seems to get distributed with a lot of software products,,, (yours!). I knew when your sqlnet you needed the oracle dll's, but was suprised to learn about needing them when you use client manager. What we do here is instead of starting the composer app directly from the desktop, we start a "wrapper" which starts the app. This gives us an opportunity to make sure the path,, etc.. is correct. 8.8) Composer 3 application working on NT, but not on 95 Rajen Pillay, Dated : 08 May, 1997 at 10:48 Subject: Executing Composer3 gen. Application on Win95 Hi, Can someone help? I got a problem running Composer3 application on Win95. Below is the description of the problem. Problem Description The application is generated for distributed processing client server. The server modules and the Oracle database are sitting on the UNIX box. The client modules are sitting on a fileserver. They were generated for NT and built for win95. The 32-bit client manager and the runtime are installed locally on the users workstation. The client exe's works when tested on NT. The same executables, when tested for win95, it fails with the following message: Receiving error message - "Can't complete return flow!" On execution of the system , control is transferred from procedure (1) to procedure (2). Both procedures are in the same business system. Control then flows from procedure (2) to procedure (3). Procedure (3) is in a different business system. Procedure (3) window pops up on the users screen, the user enter the necessary information and presses the OK button. Procedure (3) then calls the server module which then updates the database and then returns control to procedure (3). Procedure (3) executes and now must return control to procedure (2) which is in a different business system. At this point there is a long wait (+-10min) before the said error is displayed on screen. After the OK button on the error dialog box is entered, control actually returns to procedure (2). It then takes about +- 20min before procedure (2) can execute which then call procedure (4). Once procedure (4) executes, the system then works fine until control flows to a procedure in a different business system. Again on returning to the calling procedure, the same problem arises. Conclusion is that it seems to be a time-out problem. How do I resolve this problem? A solution will be appreciated. P.S. The following PTFs have been applied in this order: rtn3001, rtn3006, rtn3020, rtn3021, rtn3023, rtn3024, rtn3025, rtn3026 Regards Rajen Pillay IT Specialist IT Solution Delivery - Planning and Coordination Telkom S.A. Ltd Tel : +27 12 3113334 eMail: pillayrr@telkom.co.za ======== Darius Panahy, Dated : 08 May, 1997 at 11:01 Subject: Re: Executing Composer3 gen. Application on Win95 I have also had this problem, but not frequently. I think it was related to lack of memory, but am not sure since it went away when I increased the memory from 16Mb to 48Mb. Regards Darius Panahy Information Engineering Technology Ltd ======== Rajen Pillay, Dated : 08 May, 1997 at 14:35 Subject: Re: Executing Composer3 gen. Application on Win95 Hi, Thanks for the suggestion. I increased the memory to 48M and unfortunately I still have the same problem. Regards Rajen ======== Chris Uttley, Dated : 08 May, 1997 at 18:15 Subject: Re: Executing Composer3 gen. Application on Win95 This problem can be easily solved. Within Composer WINDOWS PACKAGING, make sure the procedures are packaged together as one load module rather than separate load modules. Composer has a problem with the kind of scenario you have and it can't get back to the procedure it came from so it eventually dies. If you package the two procedures in the same load module, it works fine. The same solution applies to COOPERATIVE PACKAGING. Make sure the two client procedures are packaged together as one load module. ======== Rajen Pillay, Dated : 09 May, 1997 at 07:52 Subject: Re: Executing Composer3 gen. Application on Win95 In the definition of my problem I did state that there are two business systems involved. One more thing that Composer does not all is packaging procedures of one business system into another business system. If I had to reduce the number of loadmodules and package the procedures of different business systems into one business system (if it was allowable), I will have very large clients. How feasible are very fat clients? What will be the implications of the hardware requirements of the system users in order to execute the system? 8.9) Promotion of Dynamic-linked modules across environments Rodney Maxwell, Dated : 28 July, 1997 at 22:47 Subject: Promotion of Dynamic-linked modules across environments We are developing a dynamically linked CICS application, also some batch. Our client currently has a Configuration Management approach that involves regeneration and installation in Production after the Acceptance Testing is done. We do not want to regenerate in Production, due to the size of the application. In most of the places I've been, we have promoted the executables from Test to Production and done a re-bind. The encyclopedia objects associated are migrated to a Production model in a tight, auditable process. Now, the question... I have not seen this done in a Dynamic Linking situation. Some of our people are concerned that the re-bind approach will not work for dynamically-linked CICS modules. Is anyone aware of problems with this approach? Is it viable for dynamic linking? ==== Hurriyet Gendj, Dated : 29 July, 1997 at 17:37 Subject: Re: Promotion of Dynamic-linked modules across environments I think the concern might be due to losing the one-to-one relationship between a DB2 plan and an executable, when dynamic linking is used. This relationship becomes 1 to many with dynamic linking. However this should not cause any particular problems. As with any DB2 application, you will need to migrate the right DBRM(s) with each executable. Dynamic linking would reduce the compile and link time, but not the rebind time unless DB2 package bind is used. Therefore you may wish to consider using the DB2 package bind with dynamically link option. ==== Piergiorgio Ardizzi, Dated : 29 July, 1997 at 17:41 Subject: Re: Promotion of Dynamic-linked modules across environments Rodney, dynamically linking a module doesn't imply that you have the same dynamic features with DB2 objects; it depends whether you're using DB2 static plans or Bind Packages. If you're using static plans, you'll have to promote into production the load member of the dinamically linked module and the corresponding DBRM, and then bind all the procedures that use this module, otherwise you'll get a -818 sqlcode. If you're using bind packages (supported only in C4) things are easier, because after having promoted load and dbrm into production you'll only have to bind the corresponding package; it will be automatically available for all the calling procedures. Hope this will help you. Pier 8.10) Client Manager wrapper for OS/2 george simpson, Dated : 21 August, 1997 at 21:49 Subject: client manager wrapper for os/2 We have a client manager "wrapper" for NT, which solves a host of deployment problems with a simple routine. Problem is other departments here at our IS shop still have os/2 customers. Does any one have an os/2 cm wrapper they would/could share ? Thanks, George ======== george simpson, Dated : 02 September, 1997 at 16:44 Subject: Re: client manager wrapper for os/2 Composer is not a deployment tool, just like its not a dba tool. It's a programming tool. Java will solve most of the deployment problems, but unfortunately we aren't that far along. What we and others are doing to help w/ the deployment issues is to place our app on the lan, along w/ the runtime, client manager, the wrapper and a setup program. The only thing that gets configured on the desk top is the addition and removal of short cuts. If your using arranger or ocx's i think you need to make sure the registry is adjusted correctly. The short cuts all point to the wrapper taking the load module to be called as a parameter. When we re-release or if we move the app, the wrapper detects this and reruns setup.exe to alter the desktop. If any environment variables need set the wrapper takes care of that... Eric O'Donnell, a TI consultant, and a good chap, has been giving a copy of his wrapper away. Unfortunately i don't have a copy of it.here is a copy of ours,,,, it's under construction,, if anyone improves it,, please email the improvement back.... Cheers, George /********************************************************/ / gws 6/12/97 simpsg@mail.modot.state.mo.us / /*******************************************************/ #include #include #include #include #include #include "wrapper.h" #include "wrproto.h" #define WR_DIALOG 110 / global variables / HWND DlgHWND, hwndcm, hwndlst, hwndstr, hwndlog, hwndecho; char dialog_message[100]; FILETIME fbegin, fend, fker, fstat; SYSTEMTIME apptime, cmtime; // call back funtions that does the work of finding desired windows BOOL CALLBACK FindC3(HWND hwnd, LPARAM lParam) { char buf[100]; GetClassName(hwnd,buf,100); if (! strcmp(buf, "#32770")) { GetWindowText(hwnd,buf,100); if (! strcmp(buf, "Composer 3 Client Manager")) hwndcm = hwnd; } return(1); } BOOL CALLBACK FindC4(HWND hwnd, LPARAM lParam) { char buf[100]; GetClassName(hwnd,buf,100); if (! strcmp(buf, "IEFWINDOW")) { GetWindowText(hwnd,buf,100); if (! strcmp(buf, "Composer 4 Client Manager")) hwndcm = hwnd; } return(1); } BOOL CALLBACK FindLogon(HWND hwnd, LPARAM lParam) { char buf[100]; GetClassName(hwnd,buf,100); if (! strcmp(buf, "IEFWINDOW")) { GetWindowText(hwnd,buf,100); if (! strcmp(buf, "Logon")) hwndlog = hwnd; } return(1); } BOOL CALLBACK FindEcho(HWND hwnd, LPARAM lParam) { char buf[100]; GetClassName(hwnd,buf,100); if (! strcmp(buf, "#32770")) { GetWindowText(hwnd,buf,100); if (! strcmp(buf, "Composer 4 Client Manager")) hwndecho = hwnd; } return(1); } BOOL CALLBACK FindList(HWND hwnd, LPARAM lParam) { char buf[100]; GetClassName(hwnd,buf,100); if (! strcmp(buf, "ListBox")) hwndlst = hwnd; return(1); } BOOL CALLBACK FindMsg(HWND hwnd, LPARAM lParam) { char buf[100]; GetClassName(hwnd,buf,100); if (! strcmp(buf, "Static")) { GetWindowText(hwnd,buf,100); if (buf[0] != '?') hwndstr = hwnd; } return(1); } BOOL APIENTRY MainDlgProc(HWND hwnd,UINT message,WPARAM wParam,LONG lParam) { switch (message) { case WM_INITDIALOG: SendMessage(GetDlgItem(hwnd,WR_DIALOG),WM_SETTEXT,(WPARAM)0,(LPARAM)(LPCTSTR)dialog_message); break; case WM_USER: SendMessage(GetDlgItem(hwnd,WR_DIALOG),WM_SETTEXT,(WPARAM)0,(LPARAM)(LPCTSTR)dialog_message); break; case WM_CLOSE: EndDialog(hwnd, 0); break; } return(0); } int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCommandLine,int nCmdShow) { int status, index; int cm_ready=0; BOOL displayed=FALSE; DWORD Result; DWORD process_status=STILL_ACTIVE; char buf[1000]; char buf2[1000]; STARTUPINFO app_sui; PROCESS_INFORMATION app_pi, cm_pi; app_sui.cb = sizeof (STARTUPINFO); app_sui.lpReserved = NULL; app_sui.lpDesktop = NULL; app_sui.lpTitle = NULL; app_sui.dwX = 0; app_sui.dwY = 0; app_sui.dwXSize = 0; app_sui.dwYSize = 0; app_sui.dwXCountChars = 0; app_sui.dwYCountChars = 0; app_sui.dwFillAttribute = 0; app_sui.dwFlags = STARTF_FORCEONFEEDBACK; app_sui.wShowWindow = 0; app_sui.cbReserved2 = 0; app_sui.lpReserved2 = 0; app_sui.hStdInput = NULL; app_sui.hStdOutput = NULL; app_sui.hStdError = NULL; SetPriorityClass(OpenProcess(PROCESS_ALL_ACCESS, TRUE, GetCurrentProcessId()), NORMAL_PRIORITY_CLASS); hwndcm = NULL; EnumDesktopWindows(GetThreadDesktop(GetCurrentThreadId()), (WNDENUMPROC)FindC3,NULL); if (hwndcm != NULL) { MessageBox(NULL,"Client Manager Version 3 is running ", "Fatal Error - Could not Start Application", MB_OK \| MB_ICONSTOP \| MB_SETFOREGROUND ); return(1); } // set the needed environment variable rc = GetEnvironmentVariable("PATH",buf,sizeof(buf)); strcpy (buf2,".;"); strcat (buf2,buf); rc = SetEnvironmentVariable("PATH", buf2); strcpy (buf,lpCmdLine); buf[8]=0; / if (!strcmp(buf,"tc0050c1") ) { rc = SetEnvironmentVariable("HCSLOC", "Q:"); strcpy (buf2, "j:\\"); rc = SetEnvironmentVariable("PUBLICLOC", "Q:"); GetEnvironmentVariable("USERNAME",buf,sizeof(buf)); strcat(buf2,buf); strcat(buf2,"\\hcs2.par"); if ( ! SearchPath(spath , lpscmdline, buf2, nRbufSize, lpszRbuf, filest)) { } / hwndcm = NULL; EnumDesktopWindows(GetThreadDesktop(GetCurrentThreadId()), (WNDENUMPROC)FindC4, NULL); if (hwndcm == NULL) { memset(buf,0,sizeof(buf)); GetEnvironmentVariable("PATH",buf,sizeof(buf)); SetEnvironmentVariable("PATH",buf); if (! CreateProcess (NULL, "IEFCM54N.EXE iefcm startup /initfile=iefcmn.ini", NULL, NULL, FALSE, DETACHED_PROCESS, GetEnvironmentStrings(), NULL, &app_sui, &cm_pi )) { MessageBox(NULL, "Fatal Error - Could not Start Client Manager", "Initialization Failure", MB_OK \| MB_ICONSTOP \| MB_SETFOREGROUND ); return(1); } strcpy(dialog_message, "Starting Client Manager, Please Wait... "); DlgHWND = CreateDialog(hInstance, MAKEINTRESOURCE(101), NULL, (DLGPROC) MainDlgProc); //SendMessage (DlgHWND, WM_COMMAND, NULL,NULL); status = WaitForInputIdle(cm_pi.hProcess, 30000); strcpy(dialog_message, " Please Logon "); SendMessage(DlgHWND, WM_USER, NULL,NULL); UpdateWindow(DlgHWND); loginloop: hwndlog = NULL; index = 0; while (hwndlog == NULL){ EnumDesktopWindows(GetThreadDesktop(GetCurrentThreadId()),(WNDENUMPROC)FindLogon,NULL); Sleep(0); } while (hwndlog != NULL) { hwndlog = NULL; EnumDesktopWindows(GetThreadDesktop(GetCurrentThreadId()),(WNDENUMPROC)FindLogon,NULL); Sleep(0); } index=0; hwndecho = NULL; while (hwndecho == NULL) { EnumDesktopWindows(GetThreadDesktop(GetCurrentThreadId()), (WNDENUMPROC)FindEcho,NULL); if (hwndecho != NULL) break; Sleep(100); ++index;/ if (index > 500) { hwndcm = NULL; EnumDesktopWindows(GetThreadDesktop (GetCurrentThreadId()), (WNDENUMPROC)FindC4, NULL); if (hwndcm != NULL) { // && IsWindowVisible(hwndcm)) { DestroyWindow(DlgHWND); EnumChildWindows(hwndcm, (WNDENUMPROC)FindList, NULL); SendMessage(hwndlst, WM_KEYDOWN, VK_SPACE, 1); SendMessage(hwndlst, WM_KEYUP, VK_SPACE, 1); MessageBox(NULL, "Please select Server and Logon before continueing", "User Cancelled logon", MB_OK \| MB_ICONSTOP \| MB_SETFOREGROUND); return(1); } } */ if (index > 2000) { MessageBox(NULL, "Fatal Error - Could not talk to Server", "Call Support", MB_OK \| MB_ICONSTOP \| MB_SETFOREGROUND); return(1); } } EnumChildWindows(hwndecho, (WNDENUMPROC)FindMsg,NULL); GetWindowText(hwndstr,buf,100); SendMessage(hwndecho, WM_CLOSE, 0,0); hwndcm = hwndlst = NULL; EnumDesktopWindows(GetThreadDesktop(GetCurrentThreadId()), (WNDENUMPROC)FindC4,NULL); EnumChildWindows(hwndcm, (WNDENUMPROC)FindList,NULL); SendMessage(hwndlst, WM_KEYDOWN, VK_SPACE, 1); SendMessage(hwndlst, WM_KEYUP, VK_SPACE, 1); if (strncmp(buf, "Test Transaction ECHO Returned from:", 35) == 0) ShowWindow(hwndcm, SW_MINIMIZE); else if (strstr(buf, "902") \|\| strstr(buf, "903")) { ShowWindow(hwndcm, SW_MINIMIZE); ShowWindow(hwndcm, SW_MINIMIZE); SendMessage(hwndcm, WM_COMMAND, 148, 0); strcpy(dialog_message, "Invalid Userid and or Password "); SendMessage(DlgHWND, WM_USER, NULL,NULL); UpdateWindow(DlgHWND); goto loginloop; } else if (strstr(buf, "629")) { MessageBox(NULL, "Fatal Error - Could not talk to Server", "Call Support", MB_OK \| MB_ICONSTOP \| MB_SETFOREGROUND); return(1); } else { MessageBox(NULL,"Fatal Error - Could not Configure Client Manager", "Initialization Failure", MB_OK \| MB_ICONSTOP \| MB_SETFOREGROUND ); return(1); } DestroyWindow(DlgHWND); } if (CreateProcess (NULL,lpCommandLine, NULL, NULL, FALSE, DETACHED_PROCESS, GetEnvironmentStrings(), NULL, &app_sui, &app_pi )) { strcpy(dialog_message, "Starting Application, Please Wait... "); DlgHWND = CreateDialog(hInstance, MAKEINTRESOURCE(101), NULL, (DLGPROC) MainDlgProc); status = WaitForInputIdle(app_pi.hProcess, 30000); // status = SendMessageTimeout(HWND_TOPMOST,WM_PAINT,0,0,SMTO_BLOCK,50,&Result); DestroyWindow(DlgHWND); } else { MessageBox(NULL, "Fatal Error - Could not Start Application", "Initialization Failure", MB_OK \| MB_ICONSTOP \| MB_SETFOREGROUND ); return(1); } return(0); }