HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: error 229380
Operating System - OpenVMS
1825737
Members
2564
Online
109687
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-08-2007 07:41 PM
02-08-2007 07:41 PM
error 229380
Hi,
Brickwall after brick wall, I'm currently faced with error 229380 being returned from dbms_scheduler 10gr1 on openVMS 8.3.
Here's what I've managed to deduce so far:
ORACLE10:EC2>exit 229380
%DCL-F-NOMSG, Message number 00038004
ORACLE10:EC2>exit 38004
%SYSTEM-F-NOMSG, Message number 00009474
ORACLE10:EC2>exit 9474
%SYSTEM-E-BADCHAIN, chained item list is inaccessible or else chain is circular
ORACLE10:EC2>help /message SYSTEM-E-BADCHAIN
%MSGHLP-F-NOTFOUND, message not found in Help Message database
Can anyone please explain what this error is about or where I might find more information?
The program I'm trying to run, runs perfectly from the command line, but not from dbms_scheduler!?
Brickwall after brick wall, I'm currently faced with error 229380 being returned from dbms_scheduler 10gr1 on openVMS 8.3.
Here's what I've managed to deduce so far:
ORACLE10:EC2>exit 229380
%DCL-F-NOMSG, Message number 00038004
ORACLE10:EC2>exit 38004
%SYSTEM-F-NOMSG, Message number 00009474
ORACLE10:EC2>exit 9474
%SYSTEM-E-BADCHAIN, chained item list is inaccessible or else chain is circular
ORACLE10:EC2>help /message SYSTEM-E-BADCHAIN
%MSGHLP-F-NOTFOUND, message not found in Help Message database
Can anyone please explain what this error is about or where I might find more information?
The program I'm trying to run, runs perfectly from the command line, but not from dbms_scheduler!?
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-08-2007 08:01 PM
02-08-2007 08:01 PM
Re: error 229380
BADCHAIN, chained item list is inaccessible or else chain is
circular
Facility: SYSTEM, System Services
Explanation: The item list for the system service call contains an item
code that was interpreted as a pointer to an additional item
list (for example, JPI$_CHAIN). The BUFADR field of this item
list entry either points to an inaccessible block of memory
or points back to the beginning of the item list in which this
entry occurs.
User Action: Verify that the BUFADR field of the chain item list entry
points to a block of memory whose page protection is readable
in the access mode of the system service caller. Also ensure
that this address is not the same as the starting address of
the current item list.
circular
Facility: SYSTEM, System Services
Explanation: The item list for the system service call contains an item
code that was interpreted as a pointer to an additional item
list (for example, JPI$_CHAIN). The BUFADR field of this item
list entry either points to an inaccessible block of memory
or points back to the beginning of the item list in which this
entry occurs.
User Action: Verify that the BUFADR field of the chain item list entry
points to a block of memory whose page protection is readable
in the access mode of the system service caller. Also ensure
that this address is not the same as the starting address of
the current item list.
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-08-2007 11:29 PM
02-08-2007 11:29 PM
Re: error 229380
Martin,
you may be looking at the wrong area for your error.
The initial error is 229380 (hex or decimal?).
When you did the first EXIT command there was no specific message found for the error, and you got the generic NOMSG reply - with the HEX value of your error. The DCL prefix comes from the %X3 portion of the hex value.
i.e. 229380 (decimal) = %X38004
From there on you have been supplying a hex value to EXIT, but indicating a decimal radix!
thus 38004 (decimal) = %X9474
Therefore, your original error has absolutely nothing to do with BADCHAIN!
If your original error was in hex rather than
decimal then you should check it with
EXIT %X229380
I get back %FDV-W-NOMSG, Message number 00299380
Unfortunately I do not have V8.3 environment with Oracle 10 to check out the other message files for a possible match.
Regards,
Duncan
you may be looking at the wrong area for your error.
The initial error is 229380 (hex or decimal?).
When you did the first EXIT command there was no specific message found for the error, and you got the generic NOMSG reply - with the HEX value of your error. The DCL prefix comes from the %X3 portion of the hex value.
i.e. 229380 (decimal) = %X38004
From there on you have been supplying a hex value to EXIT, but indicating a decimal radix!
thus 38004 (decimal) = %X9474
Therefore, your original error has absolutely nothing to do with BADCHAIN!
If your original error was in hex rather than
decimal then you should check it with
EXIT %X229380
I get back %FDV-W-NOMSG, Message number 00299380
Unfortunately I do not have V8.3 environment with Oracle 10 to check out the other message files for a possible match.
Regards,
Duncan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-09-2007 12:35 AM
02-09-2007 12:35 AM
Re: error 229380
If your first exit 229380 does not produce a reasonable error, don't bother with a chain of translations. It's either the first status, or not -- it's not a "status pointer" construction. (There can be signals buried in stack frames, but even those aren't indirected.)
Another reply mentions the radix, that's a common way where the (first) translation won't be valid. More than a few tools are not good at indicating whether the status is decimal or hexadecimal. (Made this one myself.)
There's also nothing that says the error code is valid, either. It's possible for an application to tip over and leave some junk in the register that becomes the status value visible from DCL.
I'd be looking for ECOs, and then to discuss this case with Oracle, assuming this value is returned directly from DBMS_SCHEDULER and not from some local code.
None of what I immediately see here looks like a valid error code, so either Oracle isn't following the status code rules or the status code is bad.
Another reply mentions the radix, that's a common way where the (first) translation won't be valid. More than a few tools are not good at indicating whether the status is decimal or hexadecimal. (Made this one myself.)
There's also nothing that says the error code is valid, either. It's possible for an application to tip over and leave some junk in the register that becomes the status value visible from DCL.
I'd be looking for ECOs, and then to discuss this case with Oracle, assuming this value is returned directly from DBMS_SCHEDULER and not from some local code.
None of what I immediately see here looks like a valid error code, so either Oracle isn't following the status code rules or the status code is bad.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Support
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP