|
IDMS/SQL NewsThere is growing concern among Release 12.01/ 14.0 clients about the technical support in general and commitment to SQL in particular! Several outstanding SQL problems are still unsolved. Recently a Finnish client was forced to ask the vendor: "Who is your SQL person in Europe?" "Kuka han on?" There was no answer!Many clients here in Helsinki, Turku, Tornio, Oslo, Bergen, Copenhagen, Sweden ... are seriously running / developing production applications using modern front-end tools, ODBC, TCP/IP and the IDMS database at the backend. Instead of getting practical help on existing products and issues, clients are lectured on 'future' solutions with untested and unproven sub-products! Send your contributions to : [email protected] |
|
Scandinavian Corner We are starting a Scandinavian Corner to discuss special issues facing Scandinavian clients in Norway, Finland, Denmark and Sweden. The discussion will be carried out in a mixed environment, even mixed languages - Finnish, Norwegian, Swedish, Danish and English. We will try to translate the main points to English whenever it is relevant and possible. So all clients, consultants and readers are requested to send the material in Finnish, Swedish, Norwegian, Danish or English to this new column. Some of these may be later published in SQL News itself. |
Skandinaavisen keskustelukulma Aloitamme skandinaavisen keskustelukulman, k�sittelem��n Norjan, Suomen, Tanskan ja Ruotsin asiakkaiden erityiskysymyksi�. Keskustelu k�yd��n sekalaisessa ymp�rist�ss�, my�s kielellisesti - suomi, norja, ruotsi, tanska ja englanti. Pyrimme k��nt�m��n m��r�tyt kohdat englanniksi kun on aihetta ja mohdollista. Joten kaikki Suomen asiakkaat ja lukijat pyydet��n l�hett�m��n aineistoa - suomeksi, ruotsiksi tai englanniksi t�h�n uuteen kolumniin. Jotkut n�ist� tullaan ehk� julkaisemaan SQL News lehdess�kin my�hemmin. |
Skandinavisk Hj�rne
Vi skal starte ett Skandinavisk Hj�rne for � diskutere spesielle saker (problemer) ang�ende Skandinaviske kunder i Norge, Finland, Danmark og Sverige. Diskusjonen vil bli gjort i mikset milj�, til og med i mikset spr�k - finsk, norsk, svensk, dansk og engelsk. Vi vil pr�ve � oversette de viktigste poengene til engelsk n�r det er meningsfullt og mulig. S�, alle norske kunder og konsulenter er �nsket til � sende materiale p� norsk, svensk eller engelsk til denne nye spalte. Noen av disse vil kanskje komme p� trykk i selve "SQL News". |
Broken Chains after Batch-CV JobA client in Oslo had a long standing problem with a mix of CV batch and local jobs getting broken chains in very special situations. Re-running the job with backup usually worked ok. The problem has been associated with the dynamic change in the buffer pool value after CV startup. Contact CA for the solution for 12.01 and 14.0. [Solved Sept 97] |
Product: IDMS Problem #1915 Reported Rel: 12.0 When the number of pages in a buffer pool is varied to a higher number the bit tables associated with that buffer may ignore some pages near the end of the pool. As a result any action against an area that uses that buffer pool and causes a purge of pages may omit some pages from the operation. An example of this would be varying an area from retrieval to update. All pages for the area should be purged from the buffer pool but this problem can result in some of the pages remaining active in the pool at the completion of the DMCT VARY command. This could result in incorrect application results and potential broken chains if these pages are involved in an update operation. |
SQL Issueswhere more documentation is needed
|
1. IDMS/SQL Preliminary Report on Unload and Reload of SQL databases
First of all SQL database areas can be UNLOAD/RELOAD-ed using the same utility used for network databases. There are some differences and restrictions.
The Utility Manual says " Using UNLOAD on an SQL-defined database: You can use the UNLOAD utility
statement to unload and reload an SQL-defined database to make these
changes: UNLOAD SEGMENT segment-name (AREA area-name) RELOAD INTO same-segment-name DMCL dmcl-nameNote that the named DMCL above is the new DMCL which contains the same named SQL segment, optionally with the limited changed described above. This DMCL will be used for the RELOAD operation. The DMCL used for UNLOAD is the one given under //SYSIDMS card. This minute difference is not clear in the manual. For SQL databases, unload and reload should use the same segment name. So if one has to resize the areas, this can be done only by using a new DMCL. You cannot make changes to table definitions in an SQL-defined database between the unload and reload steps. For SQL-defined segments, area and table stamps are unloaded during the UNLOAD steps of an SQL-defined database and are reloaded during RELOAD processing. This becomes a problem if one wants to unload an SQL data area from production to test IDMS. Some clients do want to do this to use the same data in testing (the actual database size in pages will be smaller in test). Such an operation is common in the case of network databases.
|
Year 2000 Conversion with Builtin Functions in ADSThe following is a problem faced by a client in Finland in recent days:We are using substring and concatenate built-in-functions in ads to manipulate date fields. When changing 9(6) date fields using builtin function substring and concat, leading zeroes are converted to blanks producing erraneous results. For example, yymmdd to ddmmyy change from '000909' gives '09 9 ', when result fields is x(6). When result field is 9(6) then result is '000009'. This happens even with cobol moves=yes option. ads statement : move con(sub(w-date,5,2), sub(w-date,3,2),sub(w-date,1,2)) to w-date2 where w-date Pic 9(6).We found that ads performs leading zero suppression before giving the field to substring function, because it moves w-date to another location without following cobol moves=yes rules Basic need is to convert date handling in ads dialogs to year 2000 compatible with minimum effort, without changing date field formats, only changing cobol moves option in ADSC to yes.
[Continued on the next column on the right] |
case 1:
MOVE '000909' TO W-DATE.
MOVE
CON(SUBS(W-DATE,5,2),
SUBS(W-DATE,3,2),
SUBS(W-DATE,1,2))
TO W-DATE2.
On gets '09 9 '
--------------------------------
Case 2:
MOVE '000909' TO W-DATE1.
MOVE
CON(SUBS(W-DATE1,5,2),
SUBS(W-DATE1,3,2),
SUBS(W-DATE1,1,2))
TO W-DATE.
One gets '000009'
The fields used are
02 W-DATE
PICTURE IS 9(6)
02 W-DATE1
PICTURE IS X(6)
02 W-DATE2
PICTURE IS X(6)
One Technician proposed the following solutions:
1. Use translate function MOVE '000909' TO W-DATE. <----the field is 9(6) MOVE TRANS(CON(SUBS(W-DATE,5,2), SUBS(W-DATE,3,2),SUBS(W-DATE,1,2)),'0',' ') TO W-DATE2. MOVE W-DATE2 TO WS-X6. The above works allright and will give the result as '090900'. 2. another might be to use the input x(6), after moving the date in 9(6) field to x(6) field. Again you might want to do the things with least possible coding and errors. 3. Third option which is not yet investigated is the usage of DATECHG bifs. Has anyone any other solution? 20/Oct/97 Update A senior technician informs us that DATECHG bif also can be used. We' ll have the details in a few days. |
COBOL/370 Online?A client from Oslo reports that COBOL/370 subroutine usage seems to be extremely slow in online environments. The exact reasons are unknown at the moment, though we believe that it is not due to the execution time of the COBOL code itself. The complete scenario follows:
_________
! !
! ADS ! Main dialog
!_________!
!
!
____v____ _________
! ! pgm1 ! !pgm2
! COBOL ! ------> ! COBOL !
!_________! !_________!
COBOL/370 pgm with sql access also calls another COBOL subroutine with no database calls. The ADS dialog has no SQL calls. It is mainly a driver dialog for display purpose. The SQL calls are in COBOL pgm1, which is called repeatedly by the dialog to fill the map. The whole thing was slow.
Just for testing, the client replaced the COBOL code with an ADS dialog and the response was very fast. Also in OCF the corresponding SQL query was even faster. Obviosuly the problem points to COBOL. But we know that the COBOL code is fast. The culprit seems to be The environment setup for LE/370When COBOL II was introduced it was found that COBOL II environment setup was too heavy for online systems. Many IGZ.. modules were loaded 100s and 1000s of times repeatedly. This was finally circumvented by IDMDC by intercepting those calls for IGZ... modules. Here in COBOL/370 there are new modules starts with CEE... The client has checked up every one of them, they are loaded onlu once (at least according to IDMSDC DCMT program statistics). But at least one of them - IBM LE/370 module CEEPLKA - seems to be the biggest module in the IDMS system - 689K! This has been called for every link to the COBOL program. A problem has been reported to CA as investigations continue.latest 1/11/97 Various problems are reported with LE/370 runtime support. See guidelines in LO06374 and LO06375. Performance issue has also been addressed by a new PTF. Contact CA. |
If any of the readers know more about COBOL/370 in general or COBOL/370 in IDMSDC or CICS environment, please let us know. What is the purpose of CEELPKA module? IDMS/SQL Final report will appear here. |
Referential Integrity ViolationRelease 12.0:ssa oli virhe IDMS/1688 Linkkaamaton rajoite, jota k�ytti yksi tai useampi tauluun viittava NULLABLE-sarake, saattoi sallia poistoja, jotka rikkoivat rajoitetta. Paras tapa kiert�� t�m� oli tehd� avainsarakkeet NOT NULL. T�m�n piti olla korjattu 14.0:ssa, mutta se esiintyy yh�. |
Details of this error was discussed in IDMS/SQL News 5.3 Our Response will appear here |
Mixed IndexToinen virhe on ongelma IDMS/1355 Indeksit, joilla on sekalainen(mixed) tai laskeva lajitteluj�rjestys aiheuttavat arvaamattomia tuloksia SQL:ss�, esim. tietokannan rivej� ei l�ydy. T�m� voidaan tilap�isesti kiert�� lajittelemalla indeksit nousevaksi. - eli lyhyesti: ei k�ytet� sekalaista (mixed) lajitteluj�rjestyst�. T�m�kin virhe on viel� 14.0:ssakin.N�m� virheet ovat SQL-k�yt�n kannalta oleellisia. Ensimm�inen n�ytt�� olevan looginen virhe DBMS-ytimess� koskien viite-eheytt�. Toinen on vakava optimoija-h�iri�, joka antaa aivan v��ri� tuloksia (ei virheilmoituksia, joten k�ytt�j� ei ole tietoinen vakavasta virheest� SQL-SELECT tuloksessa). |
IDMS/SQL Response will appear here |
Kokemuksia IDMS Release 14.0:staMartin Floman, Senior DBA, Oy Yleisradio AB, Helsinki 1997-10-28Miksi halusimme kiirehtiä installointia?
SQL-kokemuksia
Muita havaintoja SQL:n käytöstä (myös ennen rel. 14.0)
|
IDMS/SQL has asked an SQL expert to make comments on these issues. Our report will appear here |