Is there a way when a program is run in the context of a command procedure to pass a value/string for the READ statement in case of FORTRAN.
This way avoiding the user to manualy insert in the terminal a filename for example or someother parameter.

script.com
$!example
$! DEFINE/USER_MODE SYS$INPUT SYS$COMMAND
$RUN PROGRAM_EXAMPLE
---inject the input value to the READ FILENAME---

program_example.for
IMPLICIT NONE
CHARACTER*60 FILENAME
.....

WRITE(*,*) 'ENTER FILE NAME:'
READ(*,*) FILENAME
C write(*,*) 'File Name is: ',FILENAME
.....

On 2/7/2022 10:51 AM, HCorte wrote:
> Is there a way when a program is run in the context of a command procedure to pass a value/string for the READ statement in case of FORTRAN.
> This way avoiding the user to manualy insert in the terminal a filename for example or someother parameter.
>
> script.com
> $!example
> $! DEFINE/USER_MODE SYS$INPUT SYS$COMMAND
> $RUN PROGRAM_EXAMPLE
> ---inject the input value to the READ FILENAME---
>
>
>
> program_example.for
> IMPLICIT NONE
> CHARACTER*60 FILENAME
> ....
>
>
> WRITE(*,*) 'ENTER FILE NAME:'
> READ(*,*) FILENAME
> C write(*,*) 'File Name is: ',FILENAME
> ....

$!** keep this outcommented ** DEFINE/USER_MODE SYS$INPUT SYS$COMMAND
$ RUN PROGRAM_EXAMPLE
foobar.dat
$ $! continue with whatever

should work.

Arne

A segunda-feira, 7 de fevereiro de 2022 à(s) 16:09:15 UTC, Arne Vajhøj escreveu:
> On 2/7/2022 10:51 AM, HCorte wrote:
> > Is there a way when a program is run in the context of a command procedure to pass a value/string for the READ statement in case of FORTRAN.
> > This way avoiding the user to manualy insert in the terminal a filename for example or someother parameter.
> >
> > script.com
> > $!example
> > $! DEFINE/USER_MODE SYS$INPUT SYS$COMMAND
> > $RUN PROGRAM_EXAMPLE
> > ---inject the input value to the READ FILENAME---
> >
> >
> >
> > program_example.for
> > IMPLICIT NONE
> > CHARACTER*60 FILENAME
> > ....
> >
> >
> > WRITE(*,*) 'ENTER FILE NAME:'
> > READ(*,*) FILENAME
> > C write(*,*) 'File Name is: ',FILENAME
> > ....
> $!** keep this outcommented ** DEFINE/USER_MODE SYS$INPUT SYS$COMMAND
> $ RUN PROGRAM_EXAMPLE
> foobar.dat
> $
> $! continue with whatever
>
> should work.
>
> Arne

Thanks @Arne thats it, also so in https://community.hpe.com/t5/Operating-System-OpenVMS/VMS-How-to-pass-parameters-to-to-an-executable-through-DCL/td-p/5129590#.YgFD9OrP2Uk.

On Monday, February 7, 2022 at 10:51:35 AM UTC-5, HCorte wrote:
> Is there a way when a program is run in the context of a command procedure to pass a value/string for the READ statement in case of FORTRAN.
> This way avoiding the user to manualy insert in the terminal a filename for example or someother parameter.

Symbol substitution doe NOT work for dataline, so that's a non-starter.
Specifically for filenames, logical names will work in the program, so the script could define a logical name value before the run, then provide the logical name as input.

PIPE should work.

The classical OpenVMS workaround is to generate a self deleting helper command line with the DEFIN/USER sys$input sys$command; the run; and the datalines all prepared.

Can you change the program at all?

If so you can see is a logical name or symbol is defined with the required answer and only prompt when not provided already.

Or for simple input I like to just use something line: ISTAT = LIB$GET_FOREIGN (FILE_NAME, 'File name: ')

Good luck,
Hein

On Monday, February 7, 2022 at 11:13:59 AM UTC-5, HCorte wrote:
> A segunda-feira, 7 de fevereiro de 2022 à(s) 16:09:15 UTC, Arne Vajhøj escreveu:
> > On 2/7/2022 10:51 AM, HCorte wrote:
> > > Is there a way when a program is run in the context of a command procedure to pass a value/string for the READ statement in case of FORTRAN.

> > $ RUN PROGRAM_EXAMPLE
> > foobar.dat
> > $
> > $! continue with whatever

> Thanks @Arne thats it,

Ah cool. I was overthinking it.
You just needed the simple static case where you can indeed just provide the parameter. DCL 101 :-).
I thought you tried to figure out the more tricky dynamic case where a fixed script tries to provide variable data.

Glad you hear your problem is solved.
Cheers,
Hein.

Well the project that am working multiple executables the source code is using in the WRITE statements unit=5 instead of correct unit=6 that originates the following error when running the script to inject the params needed for the input's...

%FOR-F-ERRDURWRI, error during write
unit 5 file SYS$INPUT:.;
user PC 00000000

Since it detects that its a unit 5 assumes that is READ/SYS$INPUT when in fact for this specific cases its a Write... can't change the source code since this value is passed as parameter in multiple source code file, so gona have to give up the ideia of automatizing the running of a group of programs.

Is there any reason one would use unit=5 for Write??

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Three unit numbers are automatically associated with specific standard I/O files at the start of program execution. These preconnected units are standard input, standard output, and standard error:

Standard input is logical unit 5 (also Fortran 90 unit 100)

Standard output is logical unit 6 (also Fortran 90 unit 101)

Standard error is logical unit 0 (also Fortran 90 unit 102)

On Tuesday, February 8, 2022 at 10:16:57 AM UTC-5, HCorte wrote:
> Well the project that am working multiple executables the source code is using in the WRITE statements unit=5 instead of correct unit=6 that originates the following error when running the script to inject the params needed for the input's...
>
> %FOR-F-ERRDURWRI, error during write
> unit 5 file SYS$INPUT:.;
> user PC 00000000
>
> Since it detects that its a unit 5 assumes that is READ/SYS$INPUT when in fact for this specific cases its a Write... can't change the source code since this value is passed as parameter in multiple source code file, so gona have to give up the ideia of automatizing the running of a group of programs.
>
> Is there any reason one would use unit=5 for Write??
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Three unit numbers are automatically associated with specific standard I/O files at the start of program execution. These preconnected units are standard input, standard output, and standard error:
>
> Standard input is logical unit 5 (also Fortran 90 unit 100)
>
> Standard output is logical unit 6 (also Fortran 90 unit 101)
>
> Standard error is logical unit 0 (also Fortran 90 unit 102)
In older FORTRAN programs, writes to unit 5 were usually prompts to the user. I haven't seen this in many years though.

A terça-feira, 8 de fevereiro de 2022 à(s) 15:19:36 UTC, abrsvc escreveu:
> On Tuesday, February 8, 2022 at 10:16:57 AM UTC-5, HCorte wrote:
> > Well the project that am working multiple executables the source code is using in the WRITE statements unit=5 instead of correct unit=6 that originates the following error when running the script to inject the params needed for the input's...
> >
> > %FOR-F-ERRDURWRI, error during write
> > unit 5 file SYS$INPUT:.;
> > user PC 00000000
> >
> > Since it detects that its a unit 5 assumes that is READ/SYS$INPUT when in fact for this specific cases its a Write... can't change the source code since this value is passed as parameter in multiple source code file, so gona have to give up the ideia of automatizing the running of a group of programs.
> >
> > Is there any reason one would use unit=5 for Write??
> >
> > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > Three unit numbers are automatically associated with specific standard I/O files at the start of program execution. These preconnected units are standard input, standard output, and standard error:
> >
> > Standard input is logical unit 5 (also Fortran 90 unit 100)
> >
> > Standard output is logical unit 6 (also Fortran 90 unit 101)
> >
> > Standard error is logical unit 0 (also Fortran 90 unit 102)
> In older FORTRAN programs, writes to unit 5 were usually prompts to the user. I haven't seen this in many years though.

The source code of this subroutine is from the 90's, gona try later changing this subroutine itself and put a condition if its unit=5 change the value to unit=6.

Getting a behaviour when the WRITE uses format with editor descriptor $ when the script injects the input:

>@script
ENTER FILE NAME:
File Name is:
good
ENTER FILE NAME2: >
File Name is:
well

when the program run directly puts well
>r program_example
ENTER FILE NAME:
good
File Name is:
good
ENTER FILE NAME2: >well
File Name is:
well

is there a way to provide in the script to ignore the $ edit descriptor?
(https://docs.oracle.com/cd/E19957-01/805-4939/z400074387ff/index.html)

-----------------------------------------------------------------------------------------
the script
$!example
$!DEFINE/USER_MODE SYS$INPUT SYS$COMMAND
$RUN PROGRAM_EXAMPLE
good
well
-----------------------------------------------------------------------------------------
the program
PROGRAM PROGRAM_EXAMPLE
IMPLICIT NONE

CHARACTER*60 FILENAME,FILENAME2

WRITE(6,102) 'ENTER FILE NAME:'
READ(5,101) FILENAME
write(6,102) 'File Name is: ',FILENAME
C-------second Read-------------------------
C PAUSE
C WRITE(6,102) 'ENTER FILE NAME2:'
CALL WRITE_TEST(6,'ENTER FILE NAME2:')
READ(5,101) FILENAME2
write(6,102) 'File Name is: ',FILENAME2
101 FORMAT(' ',A)
102 FORMAT(' ',A)

------------------------------------------------------------------------------------------
the subroutine
SUBROUTINE WRITE_TEST(LUN, STRING)
IMPLICIT NONE
C INTEGER*4 LUN
CHARACTER STRING*(*)
C C
WRITE(LUN, 1001) ,STRING
1001 FORMAT(' ',A,' >',$)
C RETURN
END

A terça-feira, 8 de fevereiro de 2022 à(s) 16:38:02 UTC, HCorte escreveu:
> A terça-feira, 8 de fevereiro de 2022 à(s) 15:19:36 UTC, abrsvc escreveu:
> > On Tuesday, February 8, 2022 at 10:16:57 AM UTC-5, HCorte wrote:
> > > Well the project that am working multiple executables the source code is using in the WRITE statements unit=5 instead of correct unit=6 that originates the following error when running the script to inject the params needed for the input's...
> > >
> > > %FOR-F-ERRDURWRI, error during write
> > > unit 5 file SYS$INPUT:.;
> > > user PC 00000000
> > >
> > > Since it detects that its a unit 5 assumes that is READ/SYS$INPUT when in fact for this specific cases its a Write... can't change the source code since this value is passed as parameter in multiple source code file, so gona have to give up the ideia of automatizing the running of a group of programs.
> > >
> > > Is there any reason one would use unit=5 for Write??
> > >
> > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > > Three unit numbers are automatically associated with specific standard I/O files at the start of program execution. These preconnected units are standard input, standard output, and standard error:
> > >
> > > Standard input is logical unit 5 (also Fortran 90 unit 100)
> > >
> > > Standard output is logical unit 6 (also Fortran 90 unit 101)
> > >
> > > Standard error is logical unit 0 (also Fortran 90 unit 102)
> > In older FORTRAN programs, writes to unit 5 were usually prompts to the user. I haven't seen this in many years though.
> The source code of this subroutine is from the 90's, gona try later changing this subroutine itself and put a condition if its unit=5 change the value to unit=6.
>
> Getting a behaviour when the WRITE uses format with editor descriptor $ when the script injects the input:
>
> >@script
> ENTER FILE NAME:
> File Name is:
> good
> ENTER FILE NAME2: >
> File Name is:
> well
>
> when the program run directly puts well
> >r program_example
> ENTER FILE NAME:
> good
> File Name is:
> good
> ENTER FILE NAME2: >well
> File Name is:
> well
>
> is there a way to provide in the script to ignore the $ edit descriptor?
> (https://docs.oracle.com/cd/E19957-01/805-4939/z400074387ff/index.html)
>
> -----------------------------------------------------------------------------------------
> the script
> $!example
> $!DEFINE/USER_MODE SYS$INPUT SYS$COMMAND
> $RUN PROGRAM_EXAMPLE
> good
> well
> -----------------------------------------------------------------------------------------
> the program
> PROGRAM PROGRAM_EXAMPLE
> IMPLICIT NONE
>
> CHARACTER*60 FILENAME,FILENAME2
>
> WRITE(6,102) 'ENTER FILE NAME:'
> READ(5,101) FILENAME
> write(6,102) 'File Name is: ',FILENAME
> C-------second Read-------------------------
> C PAUSE
> C WRITE(6,102) 'ENTER FILE NAME2:'
> CALL WRITE_TEST(6,'ENTER FILE NAME2:')
> READ(5,101) FILENAME2
> write(6,102) 'File Name is: ',FILENAME2
> 101 FORMAT(' ',A)
> 102 FORMAT(' ',A)
>
> ------------------------------------------------------------------------------------------
> the subroutine
> SUBROUTINE WRITE_TEST(LUN, STRING)
> IMPLICIT NONE
> C
> INTEGER*4 LUN
> CHARACTER STRING*(*)
> C
> C
> WRITE(LUN, 1001) ,STRING
> 1001 FORMAT(' ',A,' >',$)
> C
> RETURN
> END

**the script output is the follow:
@script
ENTER FILE NAME:
File Name is:
good
ENTER FILE NAME2: >
File Name is:
well

@script
ENTER FILE NAME:
File Name is:
good
ENTER FILE NAME2: >
***********************File Name is:
well

the * are white space but keeps removing in the post...

From the HP Fortran for OpenVMS Language Reference Manual BA368-90004

11.4.8 Dollar Sign ($) and Backslash (\) Editing
....
If the first character of the record is a blank or a plus sign ( + ), the dollar sign
and backslash descriptors suppress carriage return (after printing the record)

Volker.

On 2022-02-08 16:38:00 +0000, HCorte said:

> The source code of this subroutine is from the 90's, gona try later
> changing this subroutine itself and put a condition if its unit=5
> change the value to unit=6.

I'd use an explicit OPEN and your own chosen unit, and use FILE and
DEFAULTFILE for the file specification on the explicit OPEN. This gives
you direct control over all of this.

The file unit selected is best not 5 or 6 (nor 100, 101, nor 102), and
either manually coordinated with all other units used in the app, or
automatically coordinated with other units via ubiquitous usage of
LIB$GET_LUN within the app.

--
Pure Personal Opinion | HoffmanLabs LLC

> Well the project that am working multiple executables the source code is
> using in the WRITE statements unit=5 instead of correct unit=6 that
> originates the following error when running the script to inject the
> params needed for the input's...

Is this program being ported from some non-VMS origin platform?

De

A terça-feira, 8 de fevereiro de 2022 à(s) 20:40:48 UTC, Dennis Boone escreveu:
> > Well the project that am working multiple executables the source code is
> > using in the WRITE statements unit=5 instead of correct unit=6 that
> > originates the following error when running the script to inject the
> > params needed for the input's...
> Is this program being ported from some non-VMS origin platform?
>
> De

No, its all been in OpenVMS. Nerver the less its a project with quite some time and in Fortran77.

On Thursday, February 10, 2022 at 12:02:23 PM UTC-5, HCorte wrote:
> A terça-feira, 8 de fevereiro de 2022 à(s) 20:40:48 UTC, Dennis Boone escreveu:
> > > Well the project that am working multiple executables the source code is
> > > using in the WRITE statements unit=5 instead of correct unit=6 that
> > > originates the following error when running the script to inject the
> > > params needed for the input's...
> > Is this program being ported from some non-VMS origin platform?
> >
> > De
> No, its all been in OpenVMS. Nerver the less its a project with quite some time and in Fortran77.

As I stated, this was a very common "feature" in many FORTRAN programs that provided prompts to users. Both channel 5 and 6 were the screen for interactive applications and often the programmers would differentiate prompts from "output" this way. I didn't agree, but it was a convention in some places. With direct execution, there was no problem. As you found, command procedure wrappers create problems. I believe that you can get around this by assigning both FOR005 and FOR006 to TT: (I haven't tried this, but it may work.)

Dan

A quinta-feira, 10 de fevereiro de 2022 à(s) 17:10:11 UTC, abrsvc escreveu:
> On Thursday, February 10, 2022 at 12:02:23 PM UTC-5, HCorte wrote:
> > A terça-feira, 8 de fevereiro de 2022 à(s) 20:40:48 UTC, Dennis Boone escreveu:
> > > > Well the project that am working multiple executables the source code is
> > > > using in the WRITE statements unit=5 instead of correct unit=6 that
> > > > originates the following error when running the script to inject the
> > > > params needed for the input's...
> > > Is this program being ported from some non-VMS origin platform?
> > >
> > > De
> > No, its all been in OpenVMS. Nerver the less its a project with quite some time and in Fortran77.
> As I stated, this was a very common "feature" in many FORTRAN programs that provided prompts to users. Both channel 5 and 6 were the screen for interactive applications and often the programmers would differentiate prompts from "output" this way. I didn't agree, but it was a convention in some places. With direct execution, there was no problem. As you found, command procedure wrappers create problems. I believe that you can get around this by assigning both FOR005 and FOR006 to TT: (I haven't tried this, but it may work.)
>
> Dan

Yes @Dan it seems to be the case where direct execution there isn't any probleam only now that am trying to wrapping in command procedure that arised this situation, thanks for the feedback about this being a convention.

Gona Try to see if there exists a symbol to differentiate when this subroutine is called from a script or the normal direct execution.

what do you mean by assigning both FOR005 and FOR006 to TT?

On 2/8/2022 11:38 AM, HCorte wrote:
> A terça-feira, 8 de fevereiro de 2022 à(s) 15:19:36 UTC, abrsvc escreveu:
>> On Tuesday, February 8, 2022 at 10:16:57 AM UTC-5, HCorte wrote:
>>> Well the project that am working multiple executables the source
>>> code is using in the WRITE statements unit=5 instead of correct
>>> unit=6 that originates the following error when running the
>>> script to inject the params needed for the input's...
>>>
>>> %FOR-F-ERRDURWRI, error during write unit 5 file SYS$INPUT:.;
>>> user PC 00000000
>>>
>>> Since it detects that its a unit 5 assumes that is READ/SYS$INPUT
>>> when in fact for this specific cases its a Write... can't change
>>> the source code since this value is passed as parameter in
>>> multiple source code file, so gona have to give up the ideia of
>>> automatizing the running of a group of programs.
>>>
>>> Is there any reason one would use unit=5 for Write??

>> In older FORTRAN programs, writes to unit 5 were usually prompts to
>> the user. I haven't seen this in many years though.
>
> The source code of this subroutine is from the 90's, gona try later
> changing this subroutine itself and put a condition if its unit=5
> change the value to unit=6.

It is what it is.

read unit * means read unit 5

write unit * means write unit 6

unit 5 points default to SYS$INPUT

unit 6 points default to SYS$OUTPUT

if SYS$INPUT and SYS$OUTPUT both points to the terminal then 5 and 6
points to the same and you can both read and write from and to both

if SYS$INPUT points to an input file then you cannot write to 5

if SYS$OUTPUT points to an output file then you cannot read from 6

Demo:

program io
character*1 dummy
write(*,*) '*'
c this fails if SYS$INPUT is a file:
write(5,*) '5'
write(6,*) '6'
write(*,'(1x,a,$)') 'Read from *: '
read(*,*) dummy
write(*,'(1x,a,$)') 'Read from 5: '
read(5,*) dummy
write(*,'(1x,a,$)') 'Read from 6: '
c this fails if SYS$OUTPUT is a file:
read(6,*) dummy
end

Arne

Its working added a condition IF(LIB$GET_SYMBOL('script_origin',SYMBOL_VALUE)) then uses unit=6.

for performance purposes LIB$GET_SYMBOL('script_origin',SYMBOL_VALUE) shouldn't have impact right?

On 2/11/2022 10:12 AM, HCorte wrote:
> Its working added a condition IF(LIB$GET_SYMBOL('script_origin',SYMBOL_VALUE)) then uses unit=6.
>
> for performance purposes LIB$GET_SYMBOL('script_origin',SYMBOL_VALUE) shouldn't have impact right?

A single call? No.

Arne

On 2/11/2022 10:12 AM, HCorte wrote:
> Its working added a condition IF(LIB$GET_SYMBOL('script_origin',SYMBOL_VALUE)) then uses unit=6.
>
> for performance purposes LIB$GET_SYMBOL('script_origin',SYMBOL_VALUE) shouldn't have impact right?

So you are setting a symbol to indicate what to do.

Why not just test on what SYS$INPUT is?

Demo:

program dvi
include '($dvidef)'
include '($dcdef)'
integer*4 devclz
call lib$getdvi(DVI$_DEVCLASS, %VAL(0), 'SYS$INPUT', devclz)
if (devclz.eq.DC$_TERM) then
write(*,*) 'You can write to unit 5'
else
write(*,*) 'Do not try to write to unit 5'
end if
end

Arne

A sexta-feira, 11 de fevereiro de 2022 à(s) 15:20:35 UTC, Arne Vajhøj escreveu:
> On 2/11/2022 10:12 AM, HCorte wrote:
> > Its working added a condition IF(LIB$GET_SYMBOL('script_origin',SYMBOL_VALUE)) then uses unit=6.
> >
> > for performance purposes LIB$GET_SYMBOL('script_origin',SYMBOL_VALUE) shouldn't have impact right?
> A single call? No.
>
> Arne

This subroutine is called in quite some programs/executables but since its alls to prompt the user for some kind of input, expect that any point in time would only be running one of this executables at a time, but could call this subroutine some times never the less each exe.

A sexta-feira, 11 de fevereiro de 2022 à(s) 15:32:15 UTC, Arne Vajhøj escreveu:
> On 2/11/2022 10:12 AM, HCorte wrote:
> > Its working added a condition IF(LIB$GET_SYMBOL('script_origin',SYMBOL_VALUE)) then uses unit=6.
> >
> > for performance purposes LIB$GET_SYMBOL('script_origin',SYMBOL_VALUE) shouldn't have impact right?
> So you are setting a symbol to indicate what to do.
>
> Why not just test on what SYS$INPUT is?
>
> Demo:
>
> program dvi
> include '($dvidef)'
> include '($dcdef)'
> integer*4 devclz
> call lib$getdvi(DVI$_DEVCLASS, %VAL(0), 'SYS$INPUT', devclz)
> if (devclz.eq.DC$_TERM) then
> write(*,*) 'You can write to unit 5'
> else
> write(*,*) 'Do not try to write to unit 5'
> end if
> end
>
> Arne

thanks @Arne gona try that.

On 2/11/2022 10:36 AM, HCorte wrote:
> A sexta-feira, 11 de fevereiro de 2022 à(s) 15:20:35 UTC, Arne Vajhøj
> escreveu:
>> On 2/11/2022 10:12 AM, HCorte wrote:
>>> Its working added a condition
>>> IF(LIB$GET_SYMBOL('script_origin',SYMBOL_VALUE)) then uses
>>> unit=6.
>>>
>>> for performance purposes
>>> LIB$GET_SYMBOL('script_origin',SYMBOL_VALUE) shouldn't have
>>> impact right?
>> A single call? No.
>
> This subroutine is called in quite some programs/executables but
> since its alls to prompt the user for some kind of input, expect that
> any point in time would only be running one of this executables at a
> time, but could call this subroutine some times never the less each
> exe.

Measure!

program gsoh
integer*8 N
parameter (N=10000000)
character*256 s
integer*4 slen, i
integer*8 t1,t2
call lib$get_symbol('X', s, slen)
write(*,*) s(1:slen)
call sys$gettim(t1)
do 100 i = 1,n
call lib$get_symbol('X', s, slen)
100 continue
call sys$gettim(t2)
write(*,*) N * 10000000 / (t2 - t1), ' calls per second'
end

Arne