Chairman: Frank Fleming (Frank.Fleming @ barclays.co.uk) - 01565-613581
Secretary: Peter Armstrong (peter_armstrong @ bmc.com) - 01276-419835
The dates for the first-half-of- next-year's IMS education classes have been published. Those classes, which clash with the GSE UK IMS Working Group meeting on 9 March, are expected to be rescheduled. There are no courses for IMS V7 yet scheduled. The CICS and DBCTL course will change emphasis away from CICS local DLI migration. Frank asked about OTMA and IMS related education, and Alan agreed to consider this request.
APARs PQ12171 PQ29833 are now available and allow MDA blocks to be placed in a non-APF library. This particular functional enhancement was raised at the previous meeting by Frank. Howard Rogers has raised a PMR as it does not currently work for the IMS monitor. A set of APARs are available which extend the support for protected APPC conversations to include DB2.
A number of red books have been released. This includes DBRC Examples and Usage Hints SG24-3333-1 which is a reprint of the manual and not a revision, so not all its content may be correct. Frank recommended Peter's DBRC In Practice manual available from BMC Software. The e-business red books that have been published, highlight the IBM recommended way to implement an application connecting the web and IMS.
Handouts were provided.
Dougie gave a brief overview presentation of the product (5697-D14 announcement letter ZP99-0432) before giving a demonstration of some of its functions. It has 47 functions assisting in problem determination, monitoring, and performance analysis. Dougie had installed it in half a day, but it does require an IPL to install an SVC. Dougie ran DRC as a WFI BMP as against an MPP. Some of the functions demonstrated included the ability to switch database datasets without stopping IMS, and to reload preloaded programs without stopping the region.
Handouts were provided.
Overall Frank felt that the implementation had been very smooth. Barclays needed a flexible growth path as they were running at full capacity. Initially just implemented Fast Path data sharing for batch BMPs. This proved somewhat problematical. As a result of this experience and limited experience of shared queues, it was decided that the implementation of data sharing would not include shared queues.
Application functions had to be catered for in design.
Rollout was performed over 7 weeks to 800 platforms after extensive testing using TPNS at the later stages. Fallback was catered for by treating it as rollout of the original system.
Data sharing needs careful planning and testing. The design is mostly affected by application characteristics. On reflection the design would have been easier using shared queues.
Handouts were provided.
Alan gave an overview of all the new function in the new version of IMS. The new release full name is IMS Version 7; it is product number 5655-B01 and its Announcement Letter is ZP99-0460. The Quality Partnership Program is already running but no General Availability date has yet been set - expected 2H2000. The largest single line item in the release is the High Availability Large DataBases (HALDB).
There are some new chargeable features: Online Recovery Services, and IMS Connect. IMS installation now uses OS390 naming standards for those libraries involved in SMP/E. CPLOG can now be changed by command and at start up. The default is now 500K
For those users who always want dual logging, say for remote DR logs, DEGRADE=NO ensures dual or will stop logging. IMS Control Region Resource Manager runs in Master Scheduler address space ensures DLISAS and DBRC address spaces terminate when control region terminates - UK customer suffered from problem when this did not occur with unpredictable results.
IMS Monitor supports Fast Path, and the IMS Performance Analyser (PA) has been enhanced to report on the information. DFSUTR20 has not been enhanced and does not report on the Fast Path information.
Handouts were provided.
Problem: MQ: you did a presentation a couple of years ago in Manchester on some of the tribulations you experienced setting this up. We've had problems of late - especially with disappearing queues. Have you come across this?
Contacts/Comments:Dougie said raise a PMR
Frank had only had problems with queues which would not go.
Problem:Preparing for IMS V6 and Data Sharing: this will be upon us in the New Year. What, as a DBA, should I be doing now?
Contacts/Comments: Dougie recommended sharing VSAM datasets
Obtain copies and read the IMS V6 and Parallel Sysplex red books
Attend education
Frank agreed to reply to his request
Problem: He would like to speak to any users of ITOC with moderate (6+ transactions/second) transaction rates
Contacts/Comments: Alan Cooper offered European customer and that Alan should contact Alison Coughtrie of IBM at Hursley.
Problem: Using IMS V6 he performed a full function database recovery using image copy and change accumulation. The change accumulation file covered a time period across a time change. Everything runs outside of DBRC control. The recovered database was invalid even when they used different image copy datasets.
Contacts/Comments: Alan Cooper suggested that the wrong time had been specified as the purge time for the change accumulation ie the time was specified in BST but the change accumulation was running in GMT. Subsequent discussion over lunch proved that this was indeed the case. A salutary warning to use DBRC as it would have correctly generated the appropriate purge time?
Problem: Wanted information from anyone who had recently compared OMEGAMON for IMS and MAINVIEW for IMS
Contacts/Comments: Frank said that Barclays had decided to stay with MAINVIEW
when they last looked at monitors. They had felt that the user interface
was better.
Andrew Hendry of the Bank of Scotland commented that IMF (MAINVIEW) was better
at monitoring and taking actions. Ian Tyson added that OMEGAMON IMS was based
on OMEGAMON MVS and missing the ability to take actions
A straw pole showed more MAIVIEW users than OMEGAMON IMS
It was suggested that support for data sharing and shared queues is stronger
from MAINVIEW
Peter gave an introductory presentation to the main line item in IMS Version 7 - High Availability Large Databases (HALDB). These provide enormous full function databases, which can have up to 1001 partitions with each partition having 10 datasets per partition! Fully configured this could be about 40 terabytes or 20000 3390 devices! The architecture can handle more than 1001 partitions, but user demand did not demand more and testing higher numbers of partitions would have been difficult even for IBM.
Database records are grouped into partitions with each partition having up to 10 data set groups. Partition selection for a database record is by high key or a Partition Selection Exit. Dataset/partitioning information is not contained in the DBD but is defined using an ISPF interface. Some information is held in the RECON datasets. There are PHIDAM and PHDAM database organisations, which correspond to HIDAM and HDAM, but there is no PHISAM. OSAM HALDB datasets can only be up to 4G not 8G.
Secondary indexes are supported through PSINDEX organisation. These utilise Indirect List dataset (ILDS) which contain the reorganisation number for the partition and the current location (RBA) of all segments involved in both secondary indexes and logical relationships. These datasets are updated as part of a reorganisation whereas the internal direct pointers contained in the header of a segment are not updated at reorganisation time. When a segment is accessed after reorganisation then IMS recognises that the reorganisation has occurred, and uses the ILDS to locate the segment and at the same time updates that segment's direct pointer. Thereafter access of that logically related or target segment is through the updated direct pointer in the segment. Thus reorganisation of a HALDB partition does not use prefix resolution, prefix update, HISAM reorganisation unload, or HISAM reorganisation reload, and can be performed independently of the secondary index or logically related database. A new utility, the Index/ILDS Rebuild utility (DFSPREC0), has to be run as part of reorganisation in order to rebuild the primary index and/or the ILDS. The first access of logically related or target segments after a reorganisation will incur the overhead of performing the update of the segment's direct pointer; this can be pre-empted by running a job which accesses all relevant segments before normal processing in order to perform the pointer update.
Logical relationships are supported through the same mechanism as secondary indexes. You cannot mix HALDB with normal full function databases in a logical relationship.
HALDB enforces naming conventions for both dataset and DDNAMEs. It does not require that partition keys have to be in partition number order; this enables a partition to be split with the original database records being split between the original partition and a partition added to the end of the list ie the whole database would not need reorganising only the partition being split.
Application programs should be enhanced to cope with conditions where the database is available but the partition is not. The INIT STATUS GROUPA call will cause the application program to receive a 'BA' status code indicating that data (a partition) is not available and IMS will just continue with the other partitions.
Future functional enhancements to IMS full function databases should be expected only in HALDB.
Handouts were provided.
Alan started by describing Online Recovery Services (ORS). This uses an ORS address space, which is created by the control region as needed. Commands can by issued to the control region requesting recovery of a list of databases (commands exist to edit the lists); these lists include DBDSGRPs and CAGRPs. The Recovery Data Manager (RDM) in the ORS address space restores the database datasets from image copies and optionally change accumulation datasets during phase 1. In phase 2, the RDM reads the necessary logs and passes log records to the Database Recovery Manger (DRM) in the control region, to be applied. Phase 1 and phase 2 may overlap for different databases but must be synchronous for an individual database. For data sharing IMS subsystems, ORS will merge the log data by reading separate log streams for each member of the group. Databases to be recovered must still be unauthorised and datasets re-allocated prior to recovery.
Alan then spoke with much feeling about his beloved Fast Path. I/O toleration support has been improved to the same level as full function except for MADS. "Long busy" I/O requests are now detected and the write is stored in the coupling facility until it can be applied after the condition has passed.
Change accumulation would not accumulate records until all records with the same DSSN were available. This caused Barclays a severe problem as some databases stayed allocated for long periods. IMS V7 solves this by accumulating to the end of the oldest log using a Lock Sequence Number (LSN). Batch backout can now work in a similar way to the control region in reading the log data forward into storage and then processing them backwards. ACBGEN can selectively skip automatic PSB rebuilds.
Despite Peter Armstrong being absent (or was it because), Alan covered the DBRC enhancements. Use of PROCOPT=L or LS will cause the image copy needed flag to be set; this was highlighted in a previous presentation by Peter Armstrong. IMS V7 will issue warning messages as a PRILOG record approaches the maximum VSAM record size. It will also issue messages when a RECON becomes bad which could be trapped and automatically actioned; this is of most significance to those sites who are sharing RECONs.
Alan noted that IMS V7 was largely a database oriented release but there
were some minor enhancements to TM.
Alan underlined that IMS was strategic to IBM as they are planning for many releases ahead and have increased headcount for next year.
Handouts were provided.
The IMS list server precipitated the discussion. Some users have indicated that they are stopping or even powering down over the end of the year. FM sites are effectively told by their customers what strategy to take.
Barclays intend to continue throughout the whole period, as any loss of availability would be highlighted by the press. They do plan to IPL all systems around Christmas time. They are, however, worried about the potential for high volumes during year end - panic stocking up of money! Frank mentioned that the period would include two consecutive four-day weekends, and this would have to be considered in relation to retention periods and SDEP data. Barclays testing has included leap year testing and last day of end of 2000 testing.
Tesco's plan to shutdown at 4 o'clock on 31/12/99 and back everything up. They will not start up until normal working hours the next day. Howard Rogers also indicated that he would be one user who would be contacting ISV's after 6pm to see whether Australia had reported any Y2K issues.
On the IBM Y2K web page there is a PDF book, which can be downloaded, that addresses rollover planning. Dougie agreed to publish a list of Y2K fixes for IMS on the web site ( http://web.ukonline.co.uk/dougie.lawson/gse ). He demonstrated how to obtain a list using YR2000MVS keyword and showed that at the time there were 38 fixes for IMS V5.1 and 17 fixes for IMS V6.1.
None.
| 1. | IBM Whats New | 44534344455453354452544233433433=121/32=3.78 |
| Up to Alan's usual high standard. | ||
| Useful information. | ||
| 2. | IMS Dynamic Resource Control | 53522454344343253342433245312333=106/32=3.31 |
| IMS CTL View Storage - looks brilliant - Karen wants a demo. | ||
| Good to have online demos. | ||
| Very interesting - would like to have. | ||
| Not relevant as we are DBCTL only. | ||
| Not bad, more of use to developers I think. | ||
| May be useful but I need a closer look. | ||
| Looks a nice tool - Cost? | ||
| Good to get a quick overview of a new product. | ||
| 3. | Online Data Sharing | 43554344314151243332334522422332=109/32=3.40 |
| Not relevant for our installation but interesting. | ||
| Not relevent as we are DBCTL only. | ||
| Very informative, lots to bear in mind when our management gives data | ||
| sharing the green light. | ||
| Unlikely to apply to any of our current customers in the future. | ||
| Useful info especially on the planning aspects. | ||
| 4. | IMS V7 | 54554444555554454452545344554445=140/32=4.37 |
| HALDB looks v interesting. | ||
| HALDB particularly useful. | ||
| Some good new features. | ||
| HALDB V good. | ||
| Fastpath not relevant. | ||
| First time I'd heard about V7 - very useful. | ||
| We're mostly Fastpath (apart from a couple of recent aquisitions) so I've no expectation of needing HALDB. | ||
| HALDB not very relevant - predominantly a fastpath site. | ||
| Other V7 enhancements were very interesting, especially ORS and FP enhancements. | ||
| Currently on V5 - Lots of new function in V7. | ||
| Overview pretty good highlighting various new features etc. | ||
| Good to know for future planning. | ||
| Need to do it again at GA date. | ||
| 5. | Y2K Roundup Discussion | 3335154533343333335=60/19=3.15 |
| Good luck Barclays. | ||
| Good to hear the different options/opinions/viewpoints. | ||
| A little unstructured | ||