File sharing OMVS/TSO

[Höglund Lars]

Do I need guidance or do I need guidance...


1. A Rexx in OMVS allocates a HFS-file like this:

47 *-* address 'TSO'
48 *-* "ALLOCATE FILE(HTMLPAGE) PATH('"TFILE"') ", "PATHOPTS(ORDWR,OCREAT,OEXCL,OTRUNC) PATHMODE(SIRWXU)", "PATHDISP(KEEP,KEEP) LRECL("LEN")"
>>> "ALLOCATE FILE(HTMLPAGE) PATH('/tmp/HTML.230.htm') PATHOPTS(ORDWR,OCREAT,OEXCL,OTRUNC) PATHMODE(SIRWXU) PATHDISP(KEEP,KEEP) LRECL(1000)"
51 *-* ARC = RC
>>> "0"


2. Then calls a Rexx (in TSO) who writes records to that file.

1705 *-* "EXECIO" PAGE.0 "DISKW HTMLPAGE (STEM PAGE.)"
>>> "EXECIO 423 DISKW HTMLPAGE (STEM PAGE.)"
1706 *-* if rc <> 0
>>> "0"


3. After return, the OMVS-Rexx tries to read the file

110 *-* say 'After z/OS='address()
>>> "After z/OS=TSO"
After z/OS=TSO
111 *-* address
112 *-* say 'Default='address()
>>> "Default=TSO"
Default=TSO
113 *-* "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"
>>> "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"
114 *-* say 'RC='rc 'HTM.0='HTM.0
>>> "RC=-3 HTM.0=HTM.0"
RC=-3 HTM.0=HTM.0


If I change to MVS when reading the result is:

113 *-* address 'MVS'
114 *-* "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"
>>> "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"
IRX0555E The input or output file HTMLPAGE is not allocated. It cannot be opened for I/O.
IRX0670E EXECIO error while trying to GET or PUT a record.



What kind of ADDRESS shall I use in ALLOC/EXECIO?
Do I gain something by using BPXWDYN when allocating?
Can/shall I use SYSCALL (somewhere)

//Lasse

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[Binyamin Dissen]

I would throw a FINIS on the DISKW.

On Mon, 9 Nov 2009 10:02:18 +0100 H�glund Lars <Lars.H...@ALECTA.SE> wrote:

:>Do I need guidance or do I need guidance...

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

[Höglund Lars]

Still ending up with -3 in reading the file

-----Ursprungligt meddelande-----
Fr�n: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] F�r Binyamin Dissen
Skickat: den 9 november 2009 10:32
Till: TSO-...@VM.MARIST.EDU
�mne: Re: [TSO-REXX] File sharing OMVS/TSO

[Binyamin Dissen]

On Mon, 9 Nov 2009 11:03:08 +0100 H�glund Lars <Lars.H...@ALECTA.SE> wrote:

:>Still ending up with -3 in reading the file

Then I would try a native OMVS command like CP against the file and see what
happens. Do not know enough about OMVS to know if an option is required to
indicate that the file might be read after created.

Perhaps try to free it and reallocate it?

:>-----Ursprungligt meddelande-----
:>Fr�n: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] F�r Binyamin Dissen

:>Skickat: den 9 november 2009 10:32
:>Till: TSO-...@VM.MARIST.EDU

:>�mne: Re: [TSO-REXX] File sharing OMVS/TSO

:>
:>I would throw a FINIS on the DISKW.
:>

[Martin Cox]

Hi

The -3 indicates that EXECIO is not a TSO Command.

Using MVS (which is what I use for EXECIO - he why is lost in the mists of
time:) ) tells you that the file is no longer allocated.

So I suspect (my knowledge of OMVS is limited) that the return from your TSO
REXX tidied up and freed all the allocated files - including the one you
want to read.

Allocate the file again and all should be OK.

I've no idea if there is a better way to do this..........

Cheers
Martin

[Höglund Lars]

Did a FREE and then an ALLOC again, after returning from z/OS (under ADDRESS 'TSO')

NOP.... = -3

Changed to "MVS" and then it wasn't allocated

111 *-* address 'MVS'
112 *-* say 'Changed to='address()
>>> "Changed to=MVS"
Changed to=MVS

113 *-* "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"
>>> "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"

IRX0555E The input or output file HTMLPAGE is not allocated. It cannot be opened for I/O.
IRX0670E EXECIO error while trying to GET or PUT a record.

+++ RC(20) +++

Isn't EXECIO a REXX function?

//Lasse

-----Ursprungligt meddelande-----
Fr�n: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] F�r Martin Cox
Skickat: den 9 november 2009 11:42
Till: TSO-...@VM.MARIST.EDU
�mne: Re: [TSO-REXX] SV: [TSO-REXX] File sharing OMVS/TSO

[Albert Klimek]

Try syscall command readfile.

Albert

VERLAGSGRUPPE WELTBILD GMBH
Sitz der Gesellschaft: Augsburg
Handelsregister Augsburg HRB 6035
Ust-ID-Nr: DE 127501299

Geschäftsführung:
Carel Halff (Vorsitzender), Dr. Martin Beer, Dr. Klaus Driever

Vorsitzender des Aufsichtsrates:
Dr. Klaus Donaubauer

[Höglund Lars]

One more thing (didn't mention that cause that's not the solution I want)

This is working (almost everytime) when I'm using...

Len = 1000
do while lines(fn) > 0
ws_ina = linein(fn)
FILE_LEN = length(ws_ina)
ROWS = FILE_LEN / LEN
do i = 0 to ROWS
say substr(ws_ina,1 + (LEN * i),LEN)
end
end

//Lasse

-----Ursprungligt meddelande-----
Fr�n: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] F�r Martin Cox
Skickat: den 9 november 2009 11:42
Till: TSO-...@VM.MARIST.EDU
�mne: Re: [TSO-REXX] SV: [TSO-REXX] File sharing OMVS/TSO

[Pinnacle]

Lasse,

This is one of the reasons that I advocate putting the address command on
each individual instruction, and NEVER setting the default command
environment. I have had Rexx execs fail because the wrong command
environment was in effect. So this is my suggestion. Get rid of any
standalone address 'TSO' or address 'MVS' statements. Use address tso
"ALLOC FI........." and see how you do.

Regards,
Tom Conley

[Paul Gilmartin]

Be aware that the "address TSO" from an EXEC running under OMVS
is quite different from "address TSO" from a TSO EXEC.

Under OMVS, the first "address TSO" starts a new address space
which remains active until "address TSO logoff" or until your
EXEC terminates, whichever comes first. All subsequent TSO
commands within that EXEC are issued to that child address space.
but allocations within that TSO child are not accessible after
the EXEC terminates, nor from the parent address space.

It appears that you are using multiple nested EXECs, but there
was too much snippage to tell which belonged to which address
space.

> :>What kind of ADDRESS shall I use in ALLOC/EXECIO?

That would necessarily be "address TSO".

> :>Do I gain something by using BPXWDYN when allocating?

You don't need "address TSO". But you can do:

address TSO "call *(BPXWDYN) 'alloc ...'"

But that limits you to 100 characters of PARM (sound familiar?)

> :>Can/shall I use SYSCALL (somewhere)
> :>

Yes, but that would require using Unix System Services
throughout; a profound rewrite and a desperate last resort.

Do you actually need TSO? Certainly if you are using IDCAMS
or ISPF services. Otherwise, you might be able to replace
all ALLOCATEs and FREEs with BPXWDYN, and use "address MVS EXECIO".

-- gil

[Paul Gilmartin]

On Nov 9, 2009, at 08:14, Pinnacle wrote:
>
> This is one of the reasons that I advocate putting the address
> command on each individual instruction, and NEVER setting the
> default command environment. I have had Rexx execs fail because
> the wrong command environment was in effect. So this is my
> suggestion. Get rid of any standalone address 'TSO' or address
> 'MVS' statements. Use address tso "ALLOC FI........." and see how
> you do.
>

Gasp! I'd like to see some of your EXECs. No, on second thought,
I wouldn't. I imagine:

address TSO 'allocate ...'
address TSO 'allocate ...'
address TSO 'EXECIO ...'
address ISREDIT 'ISREDIT find ...'
address TSO 'CALL ...'

(in fact, the last has considerable value because so many
novices confuse the Rexx call with the TSO call.)

Often I'll do:

RC = syscalls( 'ON' )
address 'SYSCALL' /* set environment for rest of EXEC. */

... then within that EXEC I will largely avoid the standalone
"address"; it's treacherous, as you suggest. However, I
may start a procedure with, e.g. "address MVS", knowing that
the caller's subcommand environment will be restored on
RETURN.

-- gil

[Pinnacle]

----- Original Message -----
From: "Paul Gilmartin" <PaulGB...@AIM.COM>
Newsgroups: bit.listserv.tsorexx

Gil,

I know it's tedious, and like your Email, I've taken a lot of heat from
others who don't like that style. But I've had many instances where a
default command environment was set way earlier in the code, then a command
failed, and it was EXTREMELY difficult to figure out why. By anal
retentively putting the address on each command, I KNOW EXACTLY which
environment is in play, and I don't have to guess. Also, when I have a
number of different environment commands in a row, changing the default just
makes the code harder to read. Want to have some fun? Take an ISREDIT
macro and change the default command environment to TSO, then run the macro.
It will slow to a crawl because ISREDIT is the last command environment in
the chain. So it's also a performance improvement.

Regards,
Tom Conley

[Paul Gilmartin]

On Nov 9, 2009, at 08:38, Pinnacle wrote:
>
> number of different environment commands in a row, changing the
> default just
> makes the code harder to read. Want to have some fun? Take an
> ISREDIT
> macro and change the default command environment to TSO, then run
> the macro.
> It will slow to a crawl because ISREDIT is the last command
> environment in
> the chain. So it's also a performance improvement.
>

One of my complaints with ISREDIT macro processing is that
(last time I checked) when a macro is entered, the initial
command environment is _not_ ISREDIT. So do I assume that
rather than use a standalone "address ISREDIT", you prefix
every command with that?

-- gil

[Pinnacle]

----- Original Message -----
From: "Paul Gilmartin" <PaulGB...@AIM.COM>
Newsgroups: bit.listserv.tsorexx

Sent: Monday, November 09, 2009 11:10 AM
Subject: Subcommand Environments (was: File sharing OMVS/TSO)

> On Nov 9, 2009, at 08:38, Pinnacle wrote:
>>
>> number of different environment commands in a row, changing the
>> default just
>> makes the code harder to read. Want to have some fun? Take an
>> ISREDIT
>> macro and change the default command environment to TSO, then run
>> the macro.
>> It will slow to a crawl because ISREDIT is the last command
>> environment in
>> the chain. So it's also a performance improvement.
>>
> One of my complaints with ISREDIT macro processing is that
> (last time I checked) when a macro is entered, the initial
> command environment is _not_ ISREDIT. So do I assume that
> rather than use a standalone "address ISREDIT", you prefix
> every command with that?
>

Gil,

Correct, I prefix every command with its environment. I get what you're
saying about edit macros and setting address isredit only once, but I like
to keep consistent style, no matter what environment I might be in. I also
have edit macros with ispexec and tso stuff in them. The real problem is
what happens when a command can be used in multiple environments and you
happen to have the wrong default at that time. I avoid this by addressing
each command. Tedious, yes, but I spend most of my time debugging, not
coding, so I always err on the side of writing code with fewer bugs, and
less guessing as to what is going on. Many disagree, but I gotta be me ;-)

Regards,
Tom Conley

[Robert Zenuk]

I saw Tom's (and others) recommendation several years ago and adopted it
myself for all my production code. Combined with my subroutines to wrapper
all commands to the different environments, it works great, does exactly
what he says and facilitated debugging.

My personal wrapper subroutines that do this are called (TSOTRAP, ISPWRAP,
ISRWRAP, USSTRAP and USSWRAP)

TSOTRAP issues an address TSO "your_passed_command"
ISPWRAP issues an address ISPEXEC "your_passed_command"
ISRWRAP issues an address ISREDIT "your_passed_command"
USSTRAP issues an address TSO BPXBATCH" sh/pgm "your_passed_command"
USSTRAP issues an address SYSCALL "your_passed_command"

There are two major benefits to this approach.

1) Like Tom says, the address environment is always right. I never get
-3's.
2) When you always pass the command into a subroutine you get several
"automatic" debugging benefits (if you code them into your subroutine and I do).

If you design your code well, you get consistent return code checking for
all possible combinations (evolves over time) and when you have errors you
can print the command that failed in your error message(s). Additionally
(even though I never need them ;-) if you use signal on
syntax/failure/novalue and sourceline(sigl) and condition() you can end up with very useful
diagnostic error messages during failures. Since I started coding like this I
always know exactly where the problem occurred and have the "call path" on
how I got there since I push and pull the stack with subroutine information
on every subroutine entry and exit. When a routine croaks, I call a
common "abend" routine that formats messages and unloads the stack into a
formatted call trace (I briefly discussed this in a prior post). With a call
trace, the line number of the offending line, a mini interpret of the failing
line, the last command passed to a *TRAP/*WRAP routine and any additional
messages I put out, I always have something useful to figure out a problem.

In case you are wondering what the difference is between my "*TRAP" and
"*WRAP" subroutines, my "*TRAP" subroutines execute the commands as well as
capture all the output in a consistent, dependable stem for possible later
use. I also tend to provide a BROWSE, EDIT or STEM option for the output in
the *TRAP routines. My "*WRAP" routines just do the address and execute
the command.

I did some performance testing several years ago when I first heard of this
because I was worried the extra address XXXX words in each command were
going to increase runtime and it did not increase runtime.

I evolved passed the basic address XXX prefixing in native code for 2
reasons. I wanted the benefits of the address on every appropriate line, but I
did not like the appearance. My subroutines made my code look slightly
better and it also allows me to use the subroutines as functions which can
also streamlines the code.

I have been building my production coding this way for close to a decade
and whole heartedly endorse it...

Rob

In a message dated 11/9/2009 8:38:36 A.M. US Mountain Standard Time,
pinn...@ROCHESTER.RR.COM writes:

----- Original Message -----
From: "Paul Gilmartin" <PaulGB...@AIM.COM>
Newsgroups: bit.listserv.tsorexx

Gil,

number of different environment commands in a row, changing the default
just
makes the code harder to read. Want to have some fun? Take an ISREDIT
macro and change the default command environment to TSO, then run the
macro.
It will slow to a crawl because ISREDIT is the last command environment in
the chain. So it's also a performance improvement.

Regards,

[Paul Gilmartin]

Robert Zenuk wrote:
>
> USSTRAP issues an address TSO BPXBATCH" sh/pgm "your_passed_command"
> USSTRAP issues an address SYSCALL "your_passed_command"
>
>

Is there a typo above?

Do you also have a wrapper for "address SH"?

> There are two major benefits to this approach.
>
> 1) Like Tom says, the address environment is always right. I never get
> -3's.
> 2) When you always pass the command into a subroutine you get several
> "automatic" debugging benefits (if you code them into your subroutine and I do).
>
> If you design your code well, you get consistent return code checking for
> all possible combinations (evolves over time) and when you have errors you
> can print the command that failed in your error message(s).
>

I certainly agree with some of this (and do somewhat similar myself.
but my wrappers all start with a standalone modal "address".)
I haven't got to the point of keeping a history stack, and I rely
a lot on Rexx's pretty good function call traceback. And I've
lately added to my "SYSCALL waitpid" wrapper:

...
/* Report status returned by wait.
*/
Code = 1
if Stat.W_IFEXITED then do
if Stat.W_EXITSTATUS==0 then Code = 0
ZEDLMSG = 'Shell command' C 'exited with status' Stat.W_EXITSTATUS
ZEDSMSG = 'Exit:' Stat.W_EXITSTATUS; end
if Stat.W_IFSIGNALED then do
ZEDLMSG = 'Shell command' C 'terminated by signal' Stat.W_TERMSIG
ZEDSMSG = 'Signal:' Stat.W_TERMSIG; end
if Stat.W_IFSTOPPED then do
ZEDLMSG = 'Shell command' C 'stopped by signal' Stat.W_STOPSIG
ZEDSMSG = 'Stopped:' Stat.W_STOPSIG; end
signal off Error
Trace Off
address 'ISPEXEC' 'SETMSG MSG(ISRZ00'Code')'
if RC<>0 then say ZEDLMSG
return( Code )

(I should comment this, but) the ISPEXEC SETMSG is issued regardless
of whether ISPF is active or not. If active, it sets the ISPF reporting
variables; otherwise it fails (RC=-3) with no terminal chatter, and the
"say" is performed.

Don't you feel the desperate need in Rexx for a COPY/include facility?
In batch, I can IEBGENER my code concatenated with the utility
function package to a member of a temporary PDS SYSEXEC.
In foreground, I have no such recourse. What do you do?

-- gil

[Robert Zenuk]

Oops! The second USSTRAP should be USSWRAP...

I agree a COPY/INCLUDE feature would be nice. However, I gave up on that
wish in 1989 and wrote my own.
I have a commenting standard that allows me to exploit my @REFRESH edit
macro. I add a special 2 line comment (the special start and end comments)
to get a subroutine included. To update an EXEC after subroutine
improvements, @REFRESH scans my code, finds all subroutines, determines if the
subroutines are the latest copy, if necessary deletes obsolete line then adds
back the latest code. I never wrote a batch process to update an entire PDS,
but it would not be hard... I like to test before and after when I decide
to update the subroutines, so a blanket update of 1300 EXEC's would not be
manageable (for me anyway). I tend to do this the next time I have a need
for the EXEC. I first run it the old way, then run it with the @REFRESH
enhancements and confirm I get similar results.

Rob

In a message dated 11/9/2009 6:02:54 P.M. US Mountain Standard Time,

[Paul Gilmartin]

Robert Zenuk wrote:
> Oops! The second USSTRAP should be USSWRAP...
>
> I agree a COPY/INCLUDE feature would be nice. However, I gave up on that
> wish in 1989 and wrote my own.
> I have a commenting standard that allows me to exploit my @REFRESH edit
> macro. I add a special 2 line comment (the special start and end comments)
> to get a subroutine included. To update an EXEC after subroutine
> improvements, @REFRESH scans my code, finds all subroutines, determines if the
> subroutines are the latest copy, if necessary deletes obsolete line then adds
> back the latest code. I never wrote a batch process to update an entire PDS,
> but it would not be hard... I like to test before and after when I decide
> to update the subroutines, so a blanket update of 1300 EXEC's would not be
> manageable (for me anyway). I tend to do this the next time I have a need
> for the EXEC. I first run it the old way, then run it with the @REFRESH
> enhancements and confirm I get similar results.
>
>

You're close to reinventing make(1). In fact, "make -n" reports unresolved
dependencies without performing the updates, which should be valuable
to the mode of operation you describe.

[Robert Zenuk]

I do something very similar for messaging. I have a STDENTRY subroutine
where I gather basic runtime data for the rest of the EXEC and all
subroutines (obviously not a procedure). One of the things is the environment I am
running in. I determine if I am in TSO, TSO/ISPF or USS. If TSO or
TSO/ISPF, I determine if I am foreground or background. To issue messages, I use
my MSG subroutine. MSG checks the environment variable and determines if
it should issue ISPEXEC SETMSG, ISPEXEC LOG or just plain SAY to issue the
message. If I want to force a SAY (usually in batch to direct to
SYSTSPRT), I just code a SAY.

I also wrote a SAYDD subroutine. This allows me to "SAY" to a specific DD
(usually a SYSOUT in batch). It does all the EXECIO stuff for the one
line and provides some optional formatting features like line spacing,
timestamping, word wrapping, stripping, no striping, upper, lower, asis, etc. I
used this for various logging activities and diagnostic reports.

Rob

-- gil

[Höglund Lars]

Now I'm getting RC=1 when I read the HTMLPAGE-file in OMVS (haven't found that rc for DISKR...)

72 *-* /* Read thru EXECIO */
73 *-* "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"

>>> "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"

+++ RC(1) +++
74 *-* if rc <> 0
>>> "1"
*-* then
75 *-* say 'RC='rc 'HTM.0='HTM.0
>>> "RC=1 HTM.0=HTM.0"
RC=1 HTM.0=HTM.0

This is the OMVS-rexx

/*REXX*/
/**************************************/
'cgiutils -status 200 -ct text/html -expires now'
/***************************************/
call shcmd '/usr/lpp/internet/bin/cgiparse -POST',,fields.

incl_parm = ''
do z = 1 to fields.0
incl_parm = incl_parm !! fields.z
end /*do z = 1 to fields.0*/

do i=1 to __environment.0
if pos('DOCUMENT_URI',__environment.i) > 0 then
parse var __environment.i dummy '=' Whole_URL
end /*do i=1 to __environment.0*/

incl_parm = translate(incl_parm,'"',"'")

call outtrap 'out.'

address 'SYSCALL' 'getpid'
unique = retval /* get the USS process id */

/* Create temporary STDOUT file */
tfile = '/tmp/HTML.'unique'.htm'
len = 1000

trace r
cmd = "ALLOCATE FILE(HTMLPAGE) PATH('"tfile"') ",
"PATHOPTS(ORDWR,OCREAT,OEXCL,OTRUNC) PATHMODE(SIRWXU)",
"PATHDISP(KEEP,KEEP) LRECL("len")"
address 'TSO' cmd
arc = rc

parm = "'"whole_url incl_parm"'"
address 'TSO' ex "'FLYU.WEB.EXEC(SDSFWEB)'" "''"parm"''"
exrc = rc

do zz = 1 to out.0
say out.zz
end /*do zz = 1 to out.0*/
drop out.

if exrc <> 0 then
do
say parm'<br>'
say 'TSO/REXX via EX cmd rc:'EXRC '<br>'
end

/* Read thru EXECIO */

"EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"

if rc <> 0 then

say 'RC='rc 'HTM.0='HTM.0

And this is the TSO-rexx

/* REXX */
parse source rexxenv rexxinv me rexxdd rexxdsn . rexxenv addrspc .
PAGE.1 = 'From' me
PAGE.0 = 1
trace r
"EXECIO" PAGE.0 "DISKW HTMLPAGE (STEM PAGE. FINIS)"
return

-----Ursprungligt meddelande-----
Fr�n: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] F�r Pinnacle
Skickat: den 9 november 2009 16:15
Till: TSO-...@VM.MARIST.EDU
�mne: Re: [TSO-REXX] File sharing OMVS/TSO

[Robert Zenuk]

According to the manual:

If you specify either OCREAT alone, or OCREAT and OEXCL, on the PATHOPTS
operand, and if the file does not exist, then MVS performs an open()
function. The options from PATHOPTS, the pathname from the PATH operand, and the
options from PATHMODE (if specified) are used in the open(). MVS uses the
close() function to close the file before the application program receives
control.

I think you need to allocate it again with just ORWR

Rob




In a message dated 11/10/2009 1:04:50 A.M. US Mountain Standard Time,
Lars.H...@ALECTA.SE writes:

This is the OMVS-rexx

call outtrap 'out.'

'
say 'TSO/REXX via EX cmd rc:'EXRC '

[Paul Gilmartin]

On Nov 10, 2009, at 07:05, Robert Zenuk wrote:

> According to the manual:
>
> If you specify either OCREAT alone, or OCREAT and OEXCL, on the
> PATHOPTS
> operand, and if the file does not exist, then MVS performs an open()
> function. The options from PATHOPTS, the pathname from the PATH
> operand, and the
> options from PATHMODE (if specified) are used in the open(). MVS
> uses the
> close() function to close the file before the application program
> receives
> control.
>
> I think you need to allocate it again with just ORWR
>

Apparently not a problem. On z/OS 1.10, the following:

//STEP EXEC PGM=IEBGENER
//SYSUT2 DD PATHMODE=(SIRUSR,SIWUSR,SIRGRP,SIROTH),
// PATHOPTS=(OCREAT,OWRONLY,OTRUNC,OEXCL),
// FILEDATA=TEXT,
// PATH=...

... runs successfully and creates the file. But when I
submit it again, it fails with:

IEF344I OEXCL STEP SYSUT2 - ALLOCATION FAILED DUE TO DATA
FACILITY SYSTEM ERROR

and the application program does not receive control. I
can only conjecture that the allocation created the file
using O_EXCL, but does not pass O_EXCL to the application.

-- gil

[Robert Zenuk]

I could not get a second step to run until I changed the JCL like this...

//jobcaard...
//***************************************************************
//* WRITE THE FILE *
//***************************************************************
//WRITE EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
This is a test
//SYSUT2 DD PATHOPTS=(OCREAT,OWRONLY,OTRUNC,OEXCL),
// PATHMODE=(SIRUSR,SIWUSR,SIRGRP,SIROTH),
// PATHDISP=(KEEP,KEEP),
// PATH='/u/rob/alloctest.txt',
// FILEDATA=TEXT
//SYSIN DD DUMMY
//***************************************************************
//* READ THE FILE *
//***************************************************************
//READ EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD PATHOPTS=(ORDWR),
// PATH='/u/rob/alloctest.txt',
// LRECL=80,BLKSIZE=32004,
// FILEDATA=TEXT
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY

So, the reuse for READ is not possible with the PATHOPTS used for the
CREATE/WRITE. I believe if you add a second ALLOC for the minimum required
parms, it works (like this JCL). PATHMODE and PATHDISP are extraneous in the
second step so I removed them.

In the EXEC the ALLOC would be:

cmd = "ALLOCATE FILE(HTMLPAGE) PATH('"tfile"') ",

"PATHOPTS(ORDWR) LRECL("len") BLKSIZE("(len*32)+4")"

I'm not sure if a REUSE would work on this ALLOCATE (I did not test it).
If not, do a FREE first in case the allocation is still there. You need a
BLKSIZE also. I built in a little formula to optimize the BLKSIZE based on
your LRECL=1000.

Hope this helps,

Rob

In a message dated 11/10/2009 8:13:13 A.M. US Mountain Standard Time,

[Paul Gilmartin]

On Nov 10, 2009, at 09:58, Robert Zenuk wrote:
>
> So, the reuse for READ is not possible with the PATHOPTS used for the
> CREATE/WRITE. I believe if you add a second ALLOC for the minimum
> required
> parms, it works (like this JCL). PATHMODE and PATHDISP are
> extraneous in the
> second step so I removed them.
>

Well, yes. The point of O_EXCL is that you're not supposed to
be able to do it twice. Which is why I'm puzzled that JCL
can create the file that way, and the application program can
then open it.

> I'm not sure if a REUSE would work on this ALLOCATE (I did not
> test it).
> If not, do a FREE first in case the allocation is still there.
>

ALLOCATE makes REUSE mutually exclusive with any of the Unix
options. BPXWDYN supports it by doing a FREE before the ALLOCATE.
This seems to be internal to DYNALLOC, because the DYNALLOC doc
somewhere states that Unix file allocations can't be reused.
Silly rule; I certainly don't understand it.

[Höglund Lars]

Thanks for all the work you all put into this!

Trying and trying...

When I implemented the "reallocation" after my call to TSO the result is

70 *-* blks = (len*32)+4
>>> "32004"
71 *-* cmd = "ALLOCATE FILE(HTMLPAGE) PATH('"tfile"')", "PATHOPTS(ORDWR) FILEDATA(TEXT) LRECL("len") BLKSIZE("blks")"
>>> "ALLOCATE FILE(HTMLPAGE) PATH('/tmp/HTML.50332304.htm') PATHOPTS(ORDWR) FILEDATA(TEXT) LRECL(1000) BLKSIZE(32004)"
73 *-* address 'TSO' cmd
>>> "ALLOCATE FILE(HTMLPAGE) PATH('/tmp/HTML.50332304.htm') PATHOPTS(ORDWR) FILEDATA(TEXT) LRECL(1000) BLKSIZE(32004)"
IKJ56246I PATH /tmp/HTML.50332304.htm NOT ALLOCATED, FILE IN USE

Then I put in a FREE before "reallocation" and end up with this

69 *-* address 'TSO' "FREE FILE(HTMLPAGE)"
>>> "FREE FILE(HTMLPAGE)"
70 *-* blks = (len*32)+4
>>> "32004"
71 *-* cmd = "ALLOCATE FILE(HTMLPAGE) PATH('"tfile"')", "PATHOPTS(ORDWR) FILEDATA(TEXT) LRECL("len") BLKSIZE("blks")"
>>> "ALLOCATE FILE(HTMLPAGE) PATH('/tmp/HTML.16778105.htm') PATHOPTS(ORDWR) FILEDATA(TEXT) LRECL(1000) BLKSIZE(32004)"
73 *-* address 'TSO' cmd
>>> "ALLOCATE FILE(HTMLPAGE) PATH('/tmp/HTML.16778105.htm') PATHOPTS(ORDWR) FILEDATA(TEXT) LRECL(1000) BLKSIZE(32004)"
IKJ56228I PATH /tmp/HTML.16778105.htm NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED

When I changed the PATHDISP to (KEEP,KEEP), creating the file, the "reallocation" works BUT I still get RC=1 in EXECIO
(MVS/QuickRef 7.0: says "truncation during diskW") I don't know if it's the same for diskR. The stem HTM. is uninitialized

89 *-* say address()
>>> "SH"
SH
90 *-* "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"

>>> "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"
+++ RC(1) +++

91 *-* say 'RC='rc 'HTM.0='HTM.0
>>> "RC=1 HTM.0=HTM.0"
RC=1 HTM.0=HTM.0

As You can see, returning from TSO my address is SH (tried MVS and TSO but NO...)

-----Ursprungligt meddelande-----
Fr�n: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] F�r Robert Zenuk
Skickat: den 10 november 2009 17:58
Till: TSO-...@VM.MARIST.EDU

�mne: Re: [TSO-REXX] SV: [TSO-REXX] File sharing OMVS/TSO

I could not get a second step to run until I changed the JCL like this...

[Paul Gilmartin]

On Nov 11, 2009, at 00:57, H�glund Lars wrote:
>
> When I changed the PATHDISP to (KEEP,KEEP), creating the file, the
> "reallocation" works BUT I still get RC=1 in EXECIO
> (MVS/QuickRef 7.0: says "truncation during diskW") I don't know if
> it's the same for diskR. The stem HTM. is uninitialized
>
> 89 *-* say address()
>>>> "SH"
> SH
> 90 *-* "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"
>>>> "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"
> +++ RC(1) +++
> 91 *-* say 'RC='rc 'HTM.0='HTM.0
>>>> "RC=1 HTM.0=HTM.0"
> RC=1 HTM.0=HTM.0
>
>

EXECIO is not a shell command, so QuickRef is irrelevant. And
you're missing an error message. My test shows:

user@MVS:133$ rexx "trace R; say address(); 'EXECIO * DISKR HTMLPAGE
(STEM HTM. FINIS)'"
1 *-* say address()
>>> "SH"
SH

*-* 'EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)'
>>> "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"

FSUM7332 syntax error: got (, expecting Newline
+++ RC(1) +++
user@MVS:134$

[Höglund Lars]

Well as You can see, the message I'm getting is RC=1 and nothing more (where can I find the message that You got?)

Probably I shouldn't use address 'SH', but what shall I use?

I'm allocating with TSO
I'm calling with TSO
I'm writing with TSO
And then I'm trying to read with TSO but...

Tried 'TSO' with result (-3)

89 *-* say address()
>>> "SH"
SH

90 *-* address 'TSO'
91 *-* say address()
>>> "TSO"
TSO
92 *-* "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"

>>> "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"

93 *-* say 'RC='rc 'HTM.0='HTM.0
>>> "RC=-3 HTM.0=HTM.0"
RC=-3 HTM.0=HTM.0

Tried 'MVS' with result (=20 (not allocated))

89 *-* say address()
>>> "SH"
SH

90 *-* address 'MVS'
91 *-* say address()
>>> "MVS"
MVS
92 *-* "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"

>>> "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"

IRX0555E The input or output file HTMLPAGE is not allocated. It cannot be opened for I/O.
IRX0670E EXECIO error while trying to GET or PUT a record.

+++ RC(20) +++
93 *-* say 'RC='rc 'HTM.0='HTM.0
>>> "RC=20 HTM.0=0"
RC=20 HTM.0=0

-----Ursprungligt meddelande-----
Fr�n: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] F�r Paul Gilmartin
Skickat: den 11 november 2009 14:40
Till: TSO-...@VM.MARIST.EDU
�mne: Re: [TSO-REXX] File sharing OMVS/TSO

[Paul Gilmartin]

On Nov 11, 2009, at 07:08, H�glund Lars wrote:

> Well as You can see, the message I'm getting is RC=1 and nothing
> more (where can I find the message that You got?)
>

stderr.

> Probably I shouldn't use address 'SH', but what shall I use?
>
> I'm allocating with TSO
> I'm calling with TSO
> I'm writing with TSO
> And then I'm trying to read with TSO but...
>

Have you tried "address MVS" and using BPXWDYN instead of
ALLOCATE?

> Tried 'TSO' with result (-3)
>
> 89 *-* say address()
>>>> "SH"
> SH
> 90 *-* address 'TSO'
> 91 *-* say address()
>>>> "TSO"
> TSO
> 92 *-* "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"
>>>> "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"
> 93 *-* say 'RC='rc 'HTM.0='HTM.0
>>>> "RC=-3 HTM.0=HTM.0"
> RC=-3 HTM.0=HTM.0
>

I get this, also. I'm mystified. I'll ask on MVS-OE.

> Tried 'MVS' with result (=20 (not allocated))
>
> 89 *-* say address()
>>>> "SH"
> SH
> 90 *-* address 'MVS'
> 91 *-* say address()
>>>> "MVS"
> MVS
> 92 *-* "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"
>>>> "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"
> IRX0555E The input or output file HTMLPAGE is not allocated. It
> cannot be opened for I/O.
> IRX0670E EXECIO error while trying to GET or PUT a record.
> +++ RC(20) +++
> 93 *-* say 'RC='rc 'HTM.0='HTM.0
>>>> "RC=20 HTM.0=0"
> RC=20 HTM.0=0
>

Because the allocations were done in the TSO address space,
but EXECIO was trying to run in the parent address space.

[Paul Gilmartin]

On Nov 11, 2009, at 07:34, Paul Gilmartin wrote:

> On Nov 11, 2009, at 07:08, H�glund Lars wrote:
>
>> 90 *-* address 'TSO'
>> 91 *-* say address()
>>>>> "TSO"
>> TSO
>> 92 *-* "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"
>>>>> "EXECIO * DISKR HTMLPAGE (STEM HTM. FINIS)"
>> 93 *-* say 'RC='rc 'HTM.0='HTM.0
>>>>> "RC=-3 HTM.0=HTM.0"
>> RC=-3 HTM.0=HTM.0
>>
> I get this, also. I'm mystified. I'll ask on MVS-OE.
>

And I got a prompt reply at:

Linkname: 09/11/11 09:04:38
URL: http://www2.marist.edu/htbin/wlvtype?MVS-OE.52188

[Robert Zenuk]

The answer appears to be readfile... Here is a functioning snippet.
Sorry if the indenting gets lost...

/* rexx */
parse arg path
EXITRC = 0
/*********************************************************************/
/* Use open the file for read only */
/*********************************************************************/
fd = ussapi('readfile' path 'rec.')
/*********************************************************************/
/* Read the file */
/*********************************************************************/
do i=1 to rec.0
say rec.i
end
/*********************************************************************/
/* Close the file */
/*********************************************************************/
exit(EXITRC)
/*********************************************************************/
/* USS API subroutine */
/*********************************************************************/
ussapi: parse arg usscmd
say center(' Before' usscmd' ',76,'-')
address SYSCALL usscmd
say 'RETVAL='RETVAL 'ERRNO='ERRNO 'ERRNOJR='ERRNOJR
if ERRNO <> 0 | ERRNOJR <> 0 then
do
address SYSCALL 'strerror' ERRNO ERRNOJR 'err.'
say
say err.SE_ERRNO
say
parse var err.SE_REASON . '15'x errmsg
say errmsg
say
say err.SE_ACTION
end
say center(' After' usscmd' ',76,'-')
return RETVAL

Rob




In a message dated 11/11/2009 8:18:30 A.M. US Mountain Standard Time,

[Paul Gilmartin]

On Nov 11, 2009, at 08:35, Robert Zenuk wrote:

> The answer appears to be readfile...
>

Indeed. However if the OP is more comfortable with the TSO
paradigm, an alternative might be a short wrapper EXEC:

/* Rexx */
address TSO /* Sorry, Rob and Pinnacle */
'ALLOCATE DD(SYSEXEC) ...'
'%MAINEXEC args ...'

[Höglund Lars]

I think that this did the trick.

Not use to USS stuff so reading the manual saying EXECIO works I gave it a try.

Thank You guys, I owe You one

//Lasse

-----Ursprungligt meddelande-----
Fr�n: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] F�r Robert Zenuk
Skickat: den 11 november 2009 16:35

Till: TSO-...@VM.MARIST.EDU
�mne: Re: [TSO-REXX] File sharing OMVS/TSO

The answer appears to be readfile... Here is a functioning snippet.

[Bob Bridges]

My own solution, gil, whenever there's a doubt, is to check how I was called
and proceed on that basis:

/* Find out whether we were called as a macro or TSO command */
address ISPEXEC 'CONTROL ERRORS RETURN'
address ISREDIT 'MACRO (ARGS)'
if rc>16 then do; fmac=0; arg args; end; else fmac=1
address ISPEXEC 'CONTROL ERRORS CANCEL'
if fmac then....

I can use this flag to trigger an error message ("No, don't call me with the
'TSO' prefix..."), or in some cases to act differently depending on how I
was called.

---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313

/* Back in the old days, most families were close-knit. Grown children and
their parents continued to live together, under the same roof, sometimes in
the same small, crowded room, year in and year out, until they died,
frequently by strangulation. -Dave Barry */

-----Original Message-----
From: Paul Gilmartin
Sent: Monday, November 9, 2009 11:10

One of my complaints with ISREDIT macro processing is that
(last time I checked) when a macro is entered, the initial
command environment is _not_ ISREDIT. So do I assume that
rather than use a standalone "address ISREDIT", you prefix
every command with that?

----------------------------------------------------------------------

[Paul Gilmartin]

On Nov 14, 2009, at 16:38, Bob Bridges wrote:

> My own solution, gil, whenever there's a doubt, is to check how I
> was called
> and proceed on that basis:
>
> /* Find out whether we were called as a macro or TSO command */
> address ISPEXEC 'CONTROL ERRORS RETURN'
> address ISREDIT 'MACRO (ARGS)'
> if rc>16 then do; fmac=0; arg args; end; else fmac=1
>

Be careful. RC isn't what you expect if this is invoked
from the TSO READY prompt.

But yes, I know it can be done. My question is, what was
the designers' motivation for entering ISPF EDIT macros with
the default addressing environment TSO rather than ISREDIT?

-- gil