A program’s request for a D-bank fails.
Symptom
The program receives a message like one of the following examples:
APP n DCS RB 60340 An error occurred when creating an id-level level bank.
Overall result status: 734062000yyy Result auxiliary status: 000000000000 CREATE$BANK packet status: 734062000xxx
APP n DCS IN 10740 A request for space from type banks failed because space was not available in existing d-banks of that memory type, and the attempt to create another bank via CREATE$BANK failed. CREATE$BANK specific status is 734062000xxx
CREATE$BANK ELMS status is 734062000yyy
CREATE$BANK ELMS auxiliary status is 000000000000
where:
n is an application group number
id-level is application or activity.
type is TCSD, LOCK, FPTE, or SCHM (schema).
yyy is an octal Exec message-id for the overall result status.
xxx is an octal Exec message-id for the specific bank request.
Analysis
It is expected that the system can always allocate another application-level bank; however, all application-level banks were allocated at the time of the program’s failed bank request.
The Exec returned ELMS statuses that identify the reason for the bank allocation failure. For descriptions of returned statuses, see the information in the System
Services Programming Manual about return status codes for bank calls.
DCS 60340 messages might contain an id-level of activity. In some situations, UDS might have attempted to allocate activity-level banks only after attempts to allocate application-level banks failed. Therefore, a DCS 60340 message with an id-level of activity can be a symptom that the system is unable to allocate any more application- level banks.
Recognizing and Correcting Abnormal Conditions
Possible causes include the following:
• The Exec might have been built with inappropriate values for the NEWCON parameters APLDYNBDS and MAXBDI. Refer to information about the NEWCON statement and parameters in the Universal Data System Planning and Installation
Overview for more information about the parameters.
• The pool of application-level banks was exhausted, even though no program or subsystem owns an unreasonable number of application-level banks. Another application-level bank was not available at the time of the request.
• One or more programs or subsystems own an unusually large number of
application-level banks, resulting in an inability to allocate another application-level bank at the time of the request.
• An RDMS thread has an unusually large number of application-level RDMS scratch banks allocated for the thread’s use. The large number of scratch banks allocated to the thread might indicate a memory leak.
Corrective Action
If APLDYNBDS and MAXBDI are not set to appropriate values, as suggested by the
Universal Data System Planning and Installation Overview, rebuild and reinstall the
Exec.
If APLDYNBDS and MAXBDI are set to appropriate values, use the @SSINFO command to identify the number of application-level banks held by all subsystems on the
system. The SSINFO command is documented in the Linking Systems Subsystems
Programming Guide. Consider the following actions:
• If the subsystem of the application group of the failing program does not own an unusually large number of banks, it is possible that one or more other subsystems own an unexpectedly large number of banks. Focus attention on any subsystem with a relatively large number of application-level banks.
Deactivating a subsystem is one possible method of releasing its banks back to the system for use by other programs; however, take great care to understand the consequences of deactivating the offending subsystem before you use this method.
If a UDSC or RDMS subsystem owns a relatively large number of application-level banks, then the UDSMON “A” screen can identify threads that have a large number of RDMS scratch banks. Offending threads can be terminated with an E keyin, which results in releasing RDMS scratch banks to the system or to the application group’s free chain. Application-level banks released to the system are available for future bank requests by any program on the system. Application-level scratch banks released to the free chain are available to other RDMS threads executing within the application group.
Alternatively, you can use the SUDS IL or II commands to deactivate a UDS Control protected fixed-gate subsystem; however, take great care to understand the consequences of deactivating the subsystem before you use this method.
Recognizing and Correcting Abnormal Conditions
• If the subsystem of the application group of the failing program owns an unusually large number of banks, do the following:
1. Use the SUDS AE command to set an error for the DCS message number, to get a UDS dump if the problem happens again. The problem information, including dump, must be submitted to Unisys with a User Communication Form (UCF).
2. Use the UDSMON “A” screen to determine if any thread has an unusually large number of RDMS scratch banks allocated to the thread. Any thread with a large number of scratch banks could be a candidate for termination through an E keyin. The result of terminating the thread is that UDS Control releases the thread’s scratch banks, either to the scratch bank pool or to the system— most likely to the system, if the thread has an unusually large number of scratch banks. Note that a thread with an unusually large number of scratch banks could be doing a lot of legitimate work; on the other hand, the thread could be the victim of a UDS memory leak. In any event, it is important that you produce a UDS dump prior to terminating the thread, so that Unisys can determine if a memory leak is involved.