- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Returning Status From Datatrieve (DTR)
Categories
Company
Local Language
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
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
Community
Resources
Forums
Blogs
- 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
12-19-2006 12:40 PM
12-19-2006 12:40 PM
I don't know if anyone uses DTR anymore, but I'd like to know if it's possible to return a status to a command procedure to indicate when an error has occurred with a DTR command. Here's the situation:
Log of DTR within a command procedure to write a record to an RMS file that has "no duplicates" (simplified version)...
$
$ DTR
DATATRIEVE V7.2A
Digital Query and Report System
Type HELP for help
ready interface_domains.svoc_interface_tracking as trf write
store trf using
begin
run_number = "000001";
file_type = "NOTEIF";
extract_date = "20061220";
batch_status = "P";
data_flag = "N";
sched_seq_number = "000001";
file_seq_number = "01";
day_seq_number = "01";
end
You cannot store a duplicate value in an RMS key field that doesn't allow duplicates.
exit
$ l_stat = $status
$!
$ if .not. l_stat
$ endif
$!
$ exit
$status always has a value %X008D8CB9 on exit from DTR, no "on error goto" or checking of $status is going to pick up the fact that the record wasn't written.
Seeing as all the data in this case is character means I could use DCL to concatenate and $write/error=[err trap], but the DTR method seems more correct.
Redirecting the output to a separate log and searching for "You cannot store..." seems like too much trouble too.
Maybe it's not designed to be used this way.
Any thoughts?
Thanks,
Ramondo.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2006 02:07 PM
12-19-2006 02:07 PM
Re: Returning Status From Datatrieve (DTR)
%X008D8CB9 is a DTR facility message, see:
$ WRITE SYS$OUTPUT F$MESSAGE(%X008D8CB9)
%DTR-S-NOMSG, Message number 008D8CB9
Since I don't have a DTRMSG file (DTR not installed here), I can't identify the actual message, but you may be able to. Try:
$ SET MESSAGE SYS$MESSAGE:DTRMSG
and repeat the above command.
The severity is -S- which means "Success", so whatever DTR has done, it's been considered successful.
By OpenVMS conventions, an image should return a longword status code in R0 when it exits. DCL makes that value available as $STATUS. It's entirely up to DTR to decide what to place in R0. My recollection is that DTR doesn't give you anything useful. However, it's been a long time, so I may be incorrect. There may also be switches or commands within DTR to return something to DCL which you can test.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2006 03:24 PM
12-19-2006 03:24 PM
Re: Returning Status From Datatrieve (DTR)
DTR> exit
$ sh sym $status
$STATUS == "%X008D8CB9"
$ SET MESSAGE SYS$MESSAGE:DTRMSGs
$ write sys$output f$message("%X008D8CB9")
%DTR-S-EXIT, Exit from DATATRIEVE requested by operator.
It's the status of EXIT command at the end of my DTR session that it's returning.
If I remove the EXIT the last DTR command executed is the attempt to store the record - but same result. It seems there's an implied exit that returns the generic DTR Exit Status regardless of what's gone before.
I've had a look at DTR help and can't find anything relating to return of status codes...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2006 11:13 PM
12-19-2006 11:13 PM
SolutionHi Ramondo,
Actually the Callable DTR is intended to be used when you need that type of error handling control of Datatrieve functions. However there is a way to first grab the Datatrieve Status Value and then put it into your own DCL symbol. Please see the example below that has already worked for me.
$ mc dtr32 DEC DATATRIEVE V7.2
Digital Query and Report System
Type HELP for help
DTR> show mydomain
Element "MYDOMAIN" not found in dictionary.
DTR> FN$SET_SYMBOL("DTR_STATUS",FN$STATUS)
DTR> exit
$ set message sys$message:DTRMSGS.EXE
$ say f$message("%D''DTR_STATUS'") %DTR-E-ELTNOTDIC, Element "!AS" not found in dictionary.
$ show symbol DTR_STATUS
DTR_STATUS = "9273746"
$
Note that the DTR Status returned is a Decimal base 10 value.
Cheers!
Keith Cayemberg
Consultant
Wipro Technologies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-21-2006 08:52 AM
12-21-2006 08:52 AM
Re: Returning Status From Datatrieve (DTR)
I notice there's nothing in the online help about FN$STATUS, but there are lots of other functions listed.
Also, if you do nothing in a DTR session (as in no reads or writes), the status returned is zero. A value of 1 would be better, I think.
Anyhow, just what I needed.
Thanks again,
Ramondo.