[Info-vax] fortran version && Compile the main file in debug mode only

[Stephen Hoffman]

On 2020-08-25 11:04:49 +0000, HCorte said:

>   Thanks for the feedback,Hoff about an app can lauch the debugger on 
> itself, was reading the 1.7 Starting the Debugger After Interrupting a 
> Running Program of 
> https://vmssoftware.com/pdfs/HP_branded_docs_1st_batch/HP_OpenVMS_Debugger.pdf 
> but isn't what you refered and also interest to use can you point to 
> the correct documentation?

See page B-1 in that PDF.

Well hidden / poorly-explained / lacking an answer to "why do I want 
this?" is an endemic documentation issue, whether within OpenVMS or 
within many other software products. Obvious to the writer is not 
obvious to the reader.

As for debugging-related OpenVMS features, app and system crash 
handling and app and system update handling support on OpenVMS is, 
well, antiquated. It's stuck about Y2K or so. What's in use is 
home-grown. Or manual. Or both.

There've been efforts in some of these areas, with CANASTA/CCAT/etc for 
system crash handling and with an automated crash scanner back-end, but 
that's all seemingly fallen by the wayside. And there's never been app 
handling, past the stackdump and displaying a stackdump to an end user 
is just stupid, and not beyond local and homegrown app code. Same for 
system and app updates. What little exists is all home-grown, and the 
defaults are all manual, and there's no library (framework, etc) 
support for automating system or app telemetry, or app or system 
software update checks, bug and crash reporting, nor general app 
maintenance. Getting crash reports is really handy for various reasons, 
and not the least of which is earlier detection of malware.

App maintenance tooling such as Sparkle is just so far past what 
OpenVMS provides, it's not comparable. https://sparkle-project.org  — 
and we all end up writing our own telemetry support.

> Have a program that created and run using a "cron job" well not realy a 
> cron job since not using a scheduler but the dcl submit with after:     
>        > submit/LOG_FILE=DKD10:[path]/NOPRINTER/after="+:1" runswap.com
> 
> where the COMMAND PROCEDURE runswap is only the dcl command run a exe
>    > type runswap.com
>    $RUN DKD10:[path]SWAP.EXE
>    $EXIT
> 
> where SWAP.EXE using the SUBMIT to simulate a program that is alls 
> running and wanted to make it call the debugger as you refered in the 
> code how to achieve that and in what documentation talks or refers 
> that??

What's not listed on page B-1 in that PDF is that you'll need to set up 
an X terminal or a physical terminal as a target for the debugger 
session (DECwTermPort), then set up DBG$INPUT and DBG$OUTPUT to 
reference that terminal device, then signal SS$_DEBUG.
DECwTermPort: 
https://www.itec.suny.edu/scsys/vms/OVMSDOC073/v73/5635/5635pro_034.html#decw_term_port_app 

Defining DBG$DECW$DISPLAY and then signaling SS$_DEBUG will also work 
for a detached process, if you'd prefer to use the X debugger display 
and not the character-cell display.  That'll all give the debugger 
somewhere to open.

There are also discussions about app and system security lurking here. 
Discussions I'm intentionally ignoring for now.

That written, your case is rather less involved, as you're here in 
batch and not detached, and don't need most (any?) of the stuff needed 
for a detached process. Yours is batch, which means you have DCL, etc. 
You can SET DISPLAY or SET DISPLAY /CREATE at the target X display, and 
aim the Debugger's X display where you want. The executable can then 
either be launched with the debugger active, or can be launched 
/NODEBUG and SS$_DEBUG then signaled later.

A lack of a job scheduler is another discussion. No, batch is not a 
scheduler. Another gap I'll here ignore.

OpenVMS doc is in need of an overhaul, too. There's a fair amount 
missing, and there's a fair amount that's become wrong within what is 
documented. VSI is seemingly starting with some cookbook material. Lots 
more needed. And the doc navigation with the existing HELP tooling and 
within and among the PDFs is weak.

VSI has infinite work awaiting, and across many areas. The trade-offs 
inherent here won't be fun. The x86-64 port is first and foremost. 
Then... well... picking from among everything else awaiting.


-- 
Pure Personal Opinion | HoffmanLabs LLC