IDMS Release 14.0 in Serious Production

________________ contents last updated on 6 Nov 1997

Please note that the concerns and ptfs below are based on the first R14.0 tape 9610. Now that 9711 product and Maint tapes are available, almost all of the PTFS below have been taken care of. We are in the process of making an update based on SQL and COBOL / 370 expereince at some clients here. There will be an update before 15th Feb.

Yet again it has to be a Scandinavian client to be the first one to go with Release 14.0 in serious production. (There has been 10+ beta sites around the world and a few in production sites on a smaller scale, earlier]. Here the client has gone into production with the whole setup of OLTP, LU6.2, SQL, ODBC and batch programs.

We have information that the full production in Finland has encountered some unexpected problems in certain areas, but overall, the system is now stable.

Problem areas

For LU6.2 APPC, data-complete flag PTF is required for 14.0. This ptf has been on and off ever since 10.2, 12.0 and 12.01 and classified as optional. But most, if not all, clients need this. Details, please contact local CA.
ESA datapsace usage seems to show performance figures not as good as 12.01. This is being investigated. Also client saw some abends when multiple batch jobs use ESA dataspace at the same time. This happens only when the jobs are heavy in database access (cause, not confirmed yet).
Programmers report that ADSALIVE will work in 14.0, only if the dialogs are regenerated. CA sources say this is not necessary. We do not have confirmation on this at the moment.
APPC tasks requiring external signon seem to fail if the password is less than 8 characters. Client has circumvented with 8 digit password for the time. Again, details on the real solution is sketchy at the moment.
ODBC problems are also reported. Client has had a stable ODBC environment with IDMS 12.01/9607, IDMS/Server 3.0, CA90s 9312 - running Windows under OS2. Recently, they upgraded IDMS to 14.0. This required upgrading CA90s to 9611. Since then, their capacity to connect to CVs (CAS9VTAM) on both release 12.0 and 14.0 has become very unstable. Sometimes, they are able to connect to 12.0, but never 14.0.
Update 09/07/97 Later client found that ODBC connection works for IDMS's first run of an ENF run. If IDMS is recycled while ENF is up, then ODBC fails. Basically, if IDMS is recycled, he has to cycle ENF also. Hyper PTF LO10697 for CA90S (9611) is the solution.
Update 25/09/97ODBC Access and CCI-User Error After 14.0 install ODBC access started giving crazy errors! Everything has been working in 12.01 tape. While connecting VISUAL EXPRESS (or any other ODBC product, we got the message DC_SYSTEM CCI-USER NOT DEFINED TO SECURITY.
CCIDCH follows. This message comes in the IDMS log.
Finally it was found out that the module RHDCD0LV has been linked incomplete by the Release 14.0 Install! There is a missing CSECT in the link of RHDCD0LV. The CSECT RHDCD0LB is not delivered with the IDMS installation, but only with the CA-Server installation. When you link RHDCD0LV, you have to make sure that you pick up RHDCD0LB from the SERVER DISTLIB.
Note: This confusion with RHDCD0LV link was experienced in 12.01 also.
For ex-DBMS tools there was an optional APAR to provide the user with a way to set the products queue retention period (currently set to 255 days or forever) to any value in the range from X'01' thru X'FF'. For example, for DME, 12.0 version was CS96377. Release 14.0 apar is not there but clients can use the offsets in 12.01 APAR GS36809, for the time being.
SQL applications, by and large, seem to be running smoothly. Some clients have reported some anomalies in IDMSDMLC pre-processing of COBOL/SQL programs with dynamic SQL.
ADS applications using LRF (including ASF) may encounter
```
 
 IDMS DC171067 RBE AT <03A9E52C> WAS OVERLAYED ON LINK TO USER PROGRAM
 
```
A ptf is available from Computer Associates.
Update 29/09/97 SQLCIB which is automatically copied to ADS Dialogs has increased in length in R14.0. There are new fields and the new length is 116 bytes, whereas in 12.01 it was 60 bytes. Individually the dialog works fine. Looks like IDMSDBMS is taking care of the length change automatic. But you may get record length mismatch message if you mix dialogs compiled in 12.01 and 14.0 in the same application thread. Is the message issued by ADS runtime environment?
For example, if you have recompiled DIIDSU03 in 14.0, which is linked from DIIDSU02 (12.01) at run time, you get,
```
 IDMS DC171065 V33 CURRENT DIALOG DIIDSU03 USES RECORD LENGTH    116
 IDMS DC171064 V33 DIIDSU02 ALLOCATED THE RECORD WITH LENGTH     60
```
Update 03/10/97 The problem is not in SQL but in ADS! SQL and DBMS handle the difference in legth allright, but ADSA is flagging SQLCIB as a Global Record (it should not be). A PTF is available now. Contact CA.
Update 07/10/97 CS91050 is the optional PTF to adjust the formfeeds on VTAM printers. This has been working allright until 12.01. But now in 14.0 client reports problems with formfeed after e.g. Idd-reports and get output from other sources on the same sheet as the last Idd-sheet. CS91050 on tape E09610 is supposed to help, but it didn't.
This problem has been fixed now by CA Technical Support. Temporary PTF Product: IDMSDC Release: 14.0 Solution#: 27 Type: T is available. This apar is required if optional apar CS91050 is applied for 14.0 clients. There is also news that the PTF has only partly fixed the problem. Contact local CA for the latest.
Updated 6/11/97
Mixed Sessions
A release 14.0 client in Turku reports that their users come into old sessions when they logon to IDMS! The old sessions are logged off from ADS application. But something is left over on LTE and the next user trying to logon come into the old session. Note that this has raised some security concerns. Client has temporarily circumvented the problem by changing the 'bye' to signoff and manual 'BYE', but still waiting for a final solution. The problem seems to affect only if you logon from ADS using RHDCSNON or #SECSGON macro and CLISTS are involved behind the scene. Application has been in production in 12.0 without any trouble.
The problem has been identified and noted at CA as IDMSDC/1533
New user gets session from previous user on lte. This problem only occurs in release 14.0. It is corrected by a test APAR available at CA.
There is some indication that this is related to the optional PTF GS20620 applied. GS20620 was the optional apar to redirect messages from external security managers. The apar will prevent external security messages from being delivered to the end users terminal and has been in use in 12.0 without problems.
Updated 1/11/97
Update Statistics against Index Areas? Not Needed!
Update Statistics command against an SQL index area gives a new incomplete message (see below). In 12.0 it works allright. Example:
```
Release 12.0 
                      OCF 12.0 ONLINE IDMS NO ERRORS                        
UPDATE STATISTICS FOR AREA APPLCAT.DDLCATX;
*+ Status = 0

Release 14.0 
                      OCF 14.0 ONLINE IDMS      1 ERROR
UPDATE STATISTICS FOR AREA SYSSQL.DDLCATX;
*+ Status = -4       SQLSTATE = 5000B        Messages follow:
*+ DB003200 T37 -4 6005
5000B - 50 CA defined, 00B - internal error

Also the message is not listed in IDD.
DCMT    D MESS DB003200
IDMS DC280905 V12 T40 MESSAGE DB003200 NOT FOUND
V14  (E09610 - R14.0) Enter Next Task Code:
```
Clarification from CA Technical Support:
The new message (not in IDD) DB003200 should read 'Nothing to process". It also means that one doesn't need UPDATE Statistics against an INDEX area! (This is totally new information from 12.0).
But the way it works is the same for 12.0 and 14.0, except for the message DB003200. When you run UPDATE STATISTICS for an area, IDMS looks in the catalog to see what tables are in the area and for each table it reads each index and sweep the area. The indexes are read even if they are in different areas.
1. There is no need to run UPDATE STATISTICS against areas that have only indexes.
2. Running UPDATE STATISTICS against an empty table or an area that that has only empty tables isn't very useful. At best it would suggest to the optimizer to use an index rather than an area sweep, but normally some rows would be added before you bothered to run a query.
3. Statistics are kept for tables, indexes and columns that are high keys in an index. Running UPDATE STATISTICS against an empty area is like running UPDATE STATISTIC against each table defined to be in that area. If there are empty tables see #2 above. If the area has no tables nothing is done except possibly issue a message.

Note: This is not an exhaustive list. IDMS just mention some problems encountered here in production. Anyone is welcome to update this with some useful information.

Nice to be the first, but...

It is a privilege to be the first client to be in serious production. We recall that Norwegian Telecom took the brave step in June 1993 to go into production with an early tape of Release 12.0, when the the whole world was hesitating. Again, the first major IDMS/SQL application was developed and put in production in record time at a client site in Bergen in May 1994. This was followed by Powerbuilder/ODBC applications in production at the same site. Yet again, internet applications using NT and ODBC/IDMS were put in production in 1996.

Clients here are a little uneasy that no one else is taking the lead. Scandinavian clients are normally classified medium sized, but some have databases as large as 270 Giga bytes (total size)! And most of them use advanced features of the product line like SQL, ODBC, DDS and LU6.2 across IDMSDC, CICS, OS/2, VAX, Tandem etc. We also have mission critical applications in production under VM/ESA (R12.0) with a maximum unexpected downtime of 15 minutes a day, but not more than 2.5 hours a year!

It is a mystery why some of the obvious errors encountered here in production have never been noticed by the much larger beta sites, earlier. IDMS/SQL News congratulates all the clients involved here who are going forward, even when the mainframe support resources at the clients as well as the vendors are diminishing!

Some important PTFs for Release 14.0

Again, not an exhaustive list, but randomly supplied by users. Details contact the local office of the vendor or Web/TCC

APAR #: LO10478 DATE: 15 JAN 1997

PROBLEM DESCRIPTION: 14.0 RHDCOESA "CA-IDMS - SVC MUST BE INSTALLED WITH
                      CAIRIM BEFORE STARTING DATABASE" message is  issued
                      at  startup  and  CA-IDMS  job terminates with COND
                      CODE  of  0255.  The  messages  follow the DC390008
                      message issued at startup. This APAR is for  module
                      RHDCOESA        product        FMID        CGJE011.

APAR LO19520 DATE: 19 JUN 1997

DESCRIPTION: DCUF  SHOW  USERS  ALL  does  not display all users
             signed onto the 14.0 CA-IDMS CV. This problem first
             occurs as  of 14.0  release and  is most noticeable
             when         using         multiple         signon.

APAR #: LO19521 DATE: 19 JUN 1997

 PROBLEM DESCRIPTION: 3970  RHDCSCEN+1A24  STILL  POSSIBLE AFTER APPLYING
                      LO18516 (14.0). In release 12.0, LO18515 (12.0)  is
                      a   coreq   and   offset   in   RHDCSCEN  is  164E.

APAR #: LO18516 DATE: 22 MAY 1997

 PROBLEM DESCRIPTION: 3970  abend  of  CV  after  DC027002  near RHDCSCEN
                      around     offsets     x'18DE'     and     x'1A22'.

APAR #: LO17921 DATE: 14 MAY 1997

PROBLEM DESCRIPTION: CICS DML  PROGRAMS THAT  LINKED WITH  AMODE 31  may
                      hang.  PGMa  issues  BIND  RU, OBTAIN,...call PGMb.
                      PGMb issues  another BIND  RU and  receives a  1477
                      error which is normal. Prior to 9607, if GO95345 is
                      NOT applied,  PGMb can  ignore the  1477 error  and
                      continue with another DML command. With 9607  tape,
                      PGMb would hang at  the DML command after  the 1477
                      error.

APAR #: LO17783 DATE: 12 MAY 1997

PROBLEM DESCRIPTION: VARIOUS ABENDS AND ERRORS USING R14.0. R13 CONTAINS
                      AN XA ADDRESS, BUT IS REQUIRED TO BE NON-XA.

APAR #: LO17780 DATE: 12 MAY 1997

PROBLEM DESCRIPTION: MVS/XA  S0C4  abend  in  RHDCOMVS suspend routines.
                      (Around  offset   783A  but   other  symptoms   are
                      possible). This only happens with 14.0 RHDCOMVS for
                      MVS/XA

APAR #: LO17778 (VM/ESA Only) DATE: 12 MAY 1997

PROBLEM DESCRIPTION: VM/ESA- Long running batch exec abends 3949, out of
                      RLEs,  if  a  SYSIDMS  file  is used with a CVMACH=
                      statement.

The following added on 09th July 1997

APAR #: LO10697 Date: 17 Jan 1997

 Several ODBC errors with Release 14.0 and CA90S 9611 Tape.
 Title: CAS9VTAM  -  CCI   INQY  MISSING  ENTRIES   -  9611

 APAR #: LO10697 Product: CCIMVS     Release: 1.1         Solution #: 31   
 PRODUCT: CAIENF/CCI-MVS                          RELEASE: 1.1

 problem resolution:  apply the ptf to the system.
                      refresh CAS9VTAM via console command
                      i.e.      enf refresh(CAS9VTAM)

APAR #: LO17581 DATE: 7 MAY 1997

PROBLEM DESCRIPTION: Sort  error  12  or  unpredictable  results w/mult.
                      sorts. SQL commands which invoke multiple sorts may
                      cause  a  sort  error  12  and  or   unpredicatable
                      results.

APAR #: LO12678 DATE: 4 MAR 1997

 PROBLEM DESCRIPTION: DC027002 SMPC near IDMSTMGR or IDMSTASK.
  HYPER: YES

APAR #: LO12028 DATE: 18 FEB 1997

 PROBLEM DESCRIPTION: 
                     Serious DDS overlay problems and LTE being used  by
                      two  tasks  causes  3964,  3970,  3985,  LOOPS   in
                      RHDCMSTR, shutdown abend 3964, line driver  abends,
                      DC016001  violations,  and  more.  Problem  is most
                      prevalent  in  DDS  VTAM  environment that has more
                      than     two     CVs     connected     thru    DDS.

PEA #: LI11905 DATE: 14 FEB 1997

***** Product Error Alert ***** *** Important note for installing Release 14.0 ***

PROBLEM DESCRIPTION:
                  IDMS R14.0 FAILS WHEN RUNNING MVS/XA OR MVS/ESA PRIOR
                  TO MVS/ESA 4,3.   IDMS 14.0 RUNS FINE WHEN USING
                  MVS/ESA 4.3 AND LATER.
 
                  IN THE INSTALL PROCEDURE, THE USER IS ASKED IF THEY
                  ARE ESA, (MVS 4.3 AND LATER). A REPLY OF GJMVSESA=YES
                  CAUSES RHDCOESA TO BE LINKED WITH THE STARTUP MODULE.
                  HOWEVER, A REPLY OF 'NO' CAUSES RHDCOMVS TO BE LINKED
                  WITH THE STARTUP MODULE. THIS VERSION OF RHDCOMVS
                  IS BAD, AND CAUSES MANY DIFFERENT TYPES OF ABENDS.
 
                  MVS/XA AND MVS/ESA (PRIOR TO 4.3) MUST REQUEST A NEW
                  COPY OF THE RHDCOMVS FROM COMPUTER ASSOCIATES TECHNICAL
                  SUPPORT.

PEA #: LI09997 DATE: 7 JAN 1997

***** Product Error Alert *****

PROBLEM DESCRIPTION: 
                  CAISAG LINK FAILURE ON CA-IDMS 14.0 9610 MVS TAPE
                   A problem has been encountered by some clients when they attempt to
                   linkedit the CAISAG program using the DOWNLOAD member in the SAMPJCL
                   file. The linkedit of the module does not execute successfully. The error
                   received is an IEW0594 ERROR - INPUT DATA SET BLOCKSIZE IS INVALID, or
                   an equivalent error depending on the version of the linkage editor that
                   is installed at your site.
 
                   The problem comes only if you are not using the BINDER for linkage edit.

                   Contact CA for the circumvention.

Back to Main Page

This page hosted by

� Get your own Free Home Page