Re: Virtual Storage Capacity Exceeded - PJBR

2007-11-26 Thread Jose Raul Baron
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: IBMVM@LISTSERV.UARK.EDU
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: IBMVM@LISTSERV.UARK.EDU
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 

 WHILE RUNNING PROGRAM UNKNOWN

 AT THE TIME OF INTERRUPT

 PSW  

 GPR 0-3 0400 0480A000 080A 

 GPR 4-7 00F127EC 80F2BDE0 00CF6C98 80CF4B30

 GPR 8-B 00D0D068 00CF6C9C 00F34D08 00EE3010

 GPR C-F 00F2BC28 00D00500 80F2C194 

 FLT 0-2 441C2000  4E00039DE21D

 FLT 4-6 4E025E7A  01839560

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.



Re: Virtual Storage Capacity Exceeded - PJBR

2007-11-13 Thread Stracka, James (GTI)
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: IBMVM@LISTSERV.UARK.EDU
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 

 WHILE RUNNING PROGRAM UNKNOWN

 AT THE TIME OF INTERRUPT

 PSW  

 GPR 0-3 0400 0480A000 080A 

 GPR 4-7 00F127EC 80F2BDE0 00CF6C98 80CF4B30

 GPR 8-B 00D0D068 00CF6C9C 00F34D08 00EE3010

 GPR C-F 00F2BC28 00D00500 80F2C194 

 FLT 0-2 441C2000  4E00039DE21D

 FLT 4-6 4E025E7A  01839560

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.



Virtual Storage Capacity Exceeded - PJBR

2007-11-13 Thread Jose Raul Baron
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 

 WHILE RUNNING PROGRAM UNKNOWN

 AT THE TIME OF INTERRUPT

 PSW  

 GPR 0-3 0400 0480A000 080A 

 GPR 4-7 00F127EC 80F2BDE0 00CF6C98 80CF4B30

 GPR 8-B 00D0D068 00CF6C9C 00F34D08 00EE3010

 GPR C-F 00F2BC28 00D00500 80F2C194 

 FLT 0-2 441C2000  4E00039DE21D

 FLT 4-6 4E025E7A  01839560

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]