Yes, it runs above 16M. The problem arises when displaying a COBOL map, always at the same point. We are considering splitting the application into smaller pieces to see if it works this way.
Saludos, José R. Barón Dpto. Sistemas CALCULO S. A. Tel. 91 330 86 44 e-mail: [EMAIL PROTECTED] P No imprima este e-mail si no es realmente necesario -----Mensaje original----- De: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] En nombre de Stracka, James (GTI) Enviado el: martes, 13 de noviembre de 2007 17:31 Para: [email protected] Asunto: Re: Virtual Storage Capacity Exceeded - PJBR Just a guess, but will this COBOL program run above 16M? There were problems with old programs that had to be recompiled to run above 16M awhile back. -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jose Raul Baron Sent: Tuesday, November 13, 2007 10:59 AM To: [email protected] Subject: Virtual Storage Capacity Exceeded - PJBR Hi list, We have a problem running an OLTP application. The scenario is a z/VM 4.4 user running a VAG Cobol application against a DB2/VM database. At a certain point, when trying to load the third map inside the same application (maps 1 + 2 have already been loaded) we find the following error: DMSSMN109S Virtual storage capacity exceeded CEE0374C CONDITION = CEE3250C TOKEN = 00040CB2 61C3C5C5 00000000 WHILE RUNNING PROGRAM UNKNOWN AT THE TIME OF INTERRUPT PSW 00000000 00000000 GPR 0-3 04000000 0480A000 0000080A 00000000 GPR 4-7 00F127EC 80F2BDE0 00CF6C98 80CF4B30 GPR 8-B 00D0D068 00CF6C9C 00F34D08 00EE3010 GPR C-F 00F2BC28 00D00500 80F2C194 00000000 FLT 0-2 441C200000000000 4E000000039DE21D FLT 4-6 4E00000000025E7A 0000000001839560 DMSABE148T System abend 80A called from 008274DE CMS If I query for virtual storage this is what I get: q v stor STORAGE = 64M Ready; We have tried to increase the virtual storage for this user up to 512M but the result made no change. The last instructions it executes successfully are: EZERESRC-SCHED 1153* /* ***** Proceso repetitivo principal ****** EZERESRC-SCHED 1154* MOVE 'SI' TO ERROR; EZERESRC-SCHED 1155* MOVE 'NO' TO GRABAR; EZERESRC-SCHED 1156* WHILE ERROR EQ 'SI' EZERESRC-SCHED 1157* OR GRABAR EQ 'NO'; EZERESRC-SCHED 1158* SXHCPMAPI(); /* Converse mapa SXHCPMAPI 0850* MOVE X000W01 TO SXHCM0I; /* datos a mapa SXHCPMAPI 0851* MOVE SXHCM00 TO SXHCM0I; SXHCPMAPI 0852* MOVE EZETIM TO SXHCM0I.HORA; /* hora SXHCPMAPI 0853* /* SXHCPMAPI 0854* /* SXHCPMAPI 0855* The last line (0855) should be a map converse but it is THEN when it crashes. This is the VAGEN COBOL source code for line 0855: 000855* MOVE SPACES TO TRACE-STRING OF EZERTS-STMTTR-REQUEST-BLOCK MOVE "000855* " TO TRACE-STRING OF EZERTS-STMTTR-REQUEST-BLOCK(1:8) PERFORM EZEAPP-STATEMENT-TRACE PERFORM EZECONV-EZEP-4 Any ideas are most welcome. Thanks in advance, Saludos, José R. Barón Dpto. Sistemas CALCULO S. A. Tel. 91 330 86 44 e-mail: [EMAIL PROTECTED] -------------------------------------------------------- This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. --------------------------------------------------------
