Re: decision support odbc driver for db2?
Gerald, actually, TDS doesn't include any ODBC drivers. The ODBC driver is provided by your DB manufacturer. So, you should use the ODBC driver that is provided by DB2, probably in some client package) Best regards, Wim. Wim Feyants IT Specialist - Tivoli Storage Manager support - IBM Belgium Tivoli ADSM certified consultant 32-2-2253825 [EMAIL PROTECTED]
Re: Open Edition for MVS
Hello, don't get confused about open edition (or Unix system services or USS) on MVS, and the fact that you're running the MVS system on a P/390 card in a RS6K. Both have nothing to do with each other. For the backup from within MVS, you won't be able to do anything with the open edition or USS TSM client. This client will actually backs up open edition files (which is an emulated unix file system) from within the open edition component of MVS. But, it won't give you the opportunity to backup the actual MVS datasets (=filesystem). One way could be, as Petr menitionned to stop the MVS, and run an "offline" backup using the normal AIX client. Otherwise, check with the MVS people: MVS has its own backup and recovery software (the DFSMS product suite if you choose IBM software), but I'm not at all sure that this will work on this type of installations. Best regards, Wim. Wim Feyants IT Specialist - Tivoli Storage Manager support - IBM Belgium Tivoli ADSM certified consultant 32-2-2253825 [EMAIL PROTECTED]
Re: decision support
Gerarld, OK. Indeed, you need to create the tables first. For that purpose, you've normally got SQL command files (there is another name for this type of code ...) that will generate these tables. They also should come with the product. Best regards, Wim. Wim Feyants IT Specialist - Tivoli Storage Manager support - IBM Belgium Tivoli ADSM certified consultant 32-2-2253825 [EMAIL PROTECTED]
Re: how are processes and schedules handled?
Robert, the db access will be handled as any access to a database: threads will access the tables they require, setting locks on the ones they are using (there are several level of locks, depending on the type of access required, which can reserve a table exclusively or not). So, the response is yes, several processes and sessions can use the db at one time, but will need to wait for access to tables if another thread has set a lock. The performance hit you're seeing when running multiple sessions can have two reasons: 1. your server is using much more resources when serving multiple sessions, and hence becomes slower. 2. Database access uses a chaching mechanism. If you use multiple sessions, the chance that a db page remains in cache is less than when you are using only one sessions. So, the result is more I/O to your database, and slower operation. You might solve this by increasing the bufpool size, or using the self tuning mechanims for caches available from 3.7 on. Finally, if you are going to delete a lot of big filespaces, you can run multiple processes at once, but, keep in mind that due to the cache and increased use of server resources, this might not be the best solution. I've seen situations where the time required to complete multiple processes was larger that the sum of the time required to run the processes seperately. Unfortunately, this is no general rule. Best regards, Wim. Wim Feyants
Re: Brainstorming with ADSM 3.1 server in mixed OS390 and VM environm ent
John, a first reaction to this would be that it is possible, but would require a lot of work. Due to the fact that some ADSM DB entries are platform specific, you cannot just move the database between your MVS and VM. The route to follow would be an export of the original server, and an import on the VM system. One advantage in this environment is that you can share DASD, which means that you might be able to use this DASD as export and import medium . For the tape volumes, I believe there will be an issue that you cannot read MVS/ADMS created tapes on a VM system. However, I never got real confirmation for this, so if someone tried it and it works, great. Also, watch out for server levels: this will only work when your ADSM running on MVS is at a lower or equal level that the one available on VM. I think one of my customers tried the reverse scenario by just "moving" the tapes (created a copy storage pool on the VM machine, and used that one to restore it on the MVS side). Didn't receive any feedback if this worked ... . I'll check. I have an ADSM 3.1 server running on OS390 2.8. The OS390 2.8 machine, a 9672-R45, is running pretty much at capacity. Actually, we've shut down ADSM and find that we are at about 90-95% CPU utilization. Not a lot of room for ADSM. We have a shared DASD environment between our OS390 and VM machines. The VM machine is a 9672-R35 with about 30% CPU capacity to spare. So, my question is Other than ADSM server licensing and software installation, how difficult would it be to install ADSM 3.1 on the VM system and bring it up there using the existing ADSM DBvolumes and Storage Pools? I know there are some issues involving the life expectancy of both ADSM 3.1 and *SM on any VM system. Consider this a brainstorming question. Any suggestions and comments would be most welcome. Best regards, Wim. Wim Feyants IT Specialist - Tivoli Storage Manager support - IBM Belgium Tivoli ADSM certified consultant 32-2-2253825 [EMAIL PROTECTED]
Re: FW: ADSM problem
Jerry, this is a know problem with the USS client. The reason is probably a memory leak somewhere. Check with you local IBM support, as this has an apar attached to it. If I'm correct, a start/stop of the schedule process should fix it. Wim Feyants
