Re: Why is my second Rexx SYSCALLS read failing?

2022-09-12 Thread Paul Gilmartin
Thanks for trimming to relevant sentences, excluding LISTSERV footers;
a rare courtesy hereabouts.

On Mon, 12 Sep 2022 17:08:19 -0500, Charles Mills wrote:
>
>Ah! A case of RTFM.
>
Rather, scrutinize minutely and memorize TFM.  You just happened to touch on
a construct I had used.

>One tends to get started using a tool without later going back and educating 
>oneself from the top down.
>
A more complete excerpt from 
:
Informal Introduction to ALGOL 68
C. H. Lindsey, S. G. van Der Meulen

0.0. Aims and methods
Since ALGOL 68 is a highly recursively structured language, it is quite 
impossible to describe it until it has been described. So that you can read 
this Introduction without tying your own mental processes into a recursive 
knot, it has been laid out to a certain pattern, which we ask you to follow. 
Please, therefore, start by reading once or twice "Very Informal Introduction", 
in
which we try to give a broad survey of what is in this language - mainly by the 
way of small examples and plain explanations. Aft~r that, we shall tell you 
what to do next.
if you think you know it all already .
then
read (what to do next) comment Section 0.14 comment
fi

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-12 Thread Charles Mills
> Ah!  A coding error.

Yep! Pretty much knew it was either a coding error or an "understanding error." 
I am about fifty years past the point of starting out with "I think I found a 
bug in the compiler." (Yes, it does happen.)

> A variable name enclosed in parentheses

Ah! A case of RTFM.

One tends to get started using a tool without later going back and educating 
oneself from the top down.

Thanks again,
Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-12 Thread Paul Gilmartin
On Mon, 12 Sep 2022 11:49:07 -0500, Charles Mills wrote:
>...
>The file names are constructed by the program. Each file covers one month. The 
>user specifies a date range and the program constructs the appropriate file 
>names. It was getting the first one right but subsequent ones wrong. 
> 
Ah!  A coding error.

>...
>The file names are constructed by the program and should never be perverse. 
>They are not user input.
> 
Provided that you make no coding errors.  Programmer's taste whether
-21 from SYSCALL or ENOENT from open is more lucid.

>I find the documentation very lacking in "big picture." 
>
There's a facetious statement in the intro to the ALGOL-68 reference (roughly,
from memory): "Since the syntax of ALGOL-68 is specified recursively, it is
impossible to explain it until it has been explained ..."  This applies to many
languages.  Consider DFSORT.

>... The examples are often nearly useless. Is that (FN) syntax documented 
> anywhere? I take it that the parentheses dereference FN so that the filename 
> is the value of FN, not "FN" literally. Is that documented anywhere? Is there 
> a SHARE presentation or anything like that that gives a big picture and some 
> seriously useful examples?
> 
It's easy to find the answer when you already know it.  I'll call this "Brin's 
Law".
Many years ago, I asked the converse question on MVS-OE and WJS generously 
replied.


...
A variable name enclosed in parentheses. Strings that contain both the single
quotation mark and double quotation mark characters must be stored in a
variable, and you must use the variable name.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-12 Thread Charles Mills
Again, thanks everyone. The problem is solved. Just to respond to a couple of 
loose ends:

> I simply entered "REXX SYSCALLS OPEN" into Google Search

Yeah, me too. I got a different manual,

> Why does it always fail on the second file regardless of swapping  the order?

The file names are constructed by the program. Each file covers one month. The 
user specifies a date range and the program constructs the appropriate file 
names. It was getting the first one right but subsequent ones wrong. If you 
want the gory details, the filenames are of the form Foo-2022-09 and for the 
second file it was computing Foo-2022-9, not -09. I was displaying the 
constructed filename and Foo-2022-9 looks right to a human, not so much to the 
UNIX file system.

> I'll suggest defending against perverse file names 

The file names are constructed by the program and should never be perverse. 
They are not user input.

> That should make -21 impossible.

The -21 was on the read, not the open, and was appropriate.

I find the documentation very lacking in "big picture." The examples are often 
nearly useless. Is that (FN) syntax documented anywhere? I take it that the 
parentheses dereference FN so that the filename is the value of FN, not "FN" 
literally. Is that documented anywhere? Is there a SHARE presentation or 
anything like that that gives a big picture and some seriously useful examples?

Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Seymour J Metz
I figured out which manual he was citing. The new lines are needed in order for 
the commas to be valid. Similarly, the new lines between statements are needed 
because the are no explicit semicolons. The example in the manual is correct if 
you don't mess with the line breaks.

Note that the expression uses variables set by syscalls(on).


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, September 11, 2022 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Why is my second Rexx SYSCALLS read failing?

On Sun, 11 Sep 2022 12:15:37 +, Seymour J Metz wrote:

>Comma isn't a valid delimitor in an expression. Did you mean
>'open' path', O_rdwr+O_creat+O_trunc, 660'
>?
There was no such comma in Charles's original (pseudo?)code.

Bernd noted that he had problems copying from "the IBM doc"
with no specific citation.

The comma is used to denote a continuation in:
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.5.0%3Ftopic%3Dcommands-open-write-close-filedata=05%7C01%7Csmetz3%40gmu.edu%7Cdb9a65644e5844ab29c908da93fb9e15%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637985006158213715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=GLcD7zJceGY4%2FJiFQxmyFRlvIbloB17b%2BAdfCPjVjjI%3Dreserved=0>

Now, back to our story?

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Seymour J Metz
Those are commands, not functions.


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 <031df298a9da-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, September 11, 2022 2:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Why is my second Rexx SYSCALLS read failing?

The RC values are documented here for all SYSCALLS functions (including -21, 
-22, ...):

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.5.0%3Ftopic%3Dvalues-returned-from-syscall-environmentdata=05%7C01%7Csmetz3%40gmu.edu%7C1b5dd8dd2547425096d408da94211308%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637985167026192689%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=rhp0K68GqYNO3o19hMLnmujc4tn5DD9iDurJPtWqY04%3Dreserved=0

Note though that there is also language saying that various "other" RC values 
can be produced by "some" functions without a list or table of the exceptional 
functions and values.  That lack may well call for an RCF.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, September 11, 2022 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Why is my second Rexx SYSCALLS read failing?

On Sun, 11 Sep 2022 11:29:07 -0500, Charles Mills wrote:

>... Bad open of course yields a bad fd which yields a -21. It is all new 
> code and I had not tested open failures specifically.
>
>Not sure where you saw the example that you cited. The IBM doc that I am 
>looking at has the following for an example (in its entirety):
>
>"open /u/linda/my.exec" o_rdwr+o_trunc+o_creat 700
>
>which is of course useless with regard to how one checks for errors. IBM could 
>do better, especially if open is atypical in how it reports errors.
>
>(https://secure-web.cisco.com/13jzWG1lrHqEXmpDKoJJLtxK58LUEE-w7MwQJoqcI5dCBwUnFVuID-iR3lBlE7-Wo1J_vegpFadoEVj-gztP8ZYY16w-BgRS12SbJLVq7U51ACQdgy9aYeknjbVDbC-w4W081H2VXOLzsuvX8wjLyrrYkamPX3Yn9Dq-T0lG8fS6LA30Xer-0f0oF2uKnMQFPiRS3lpR9uL5XKoNH753cfkqPkRzlkcWdKMtWR0HYU-Bg4SSdz-Xsa_juOgS-UPgLNqVLYCGwCUEn1OSXEvhhCoQpaOA0JezC2d8Q5K-rPkcL2ln0Ei4QWbIcEvcs2niT9f2ookUac5Z1JhawVgEX4MXWgkWuf8zhSlRsq57hgklUvNvJt-3I2ceF831mzIC2ZnrVHkVqBAhc75_mlG0ToVfg82XXZEeO7-ljyztc5aw9e2CKDwtG9yRZTq-xY56_7Pk7uuGv1G5Op3b6DetMWg/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.5.0%3Ftopic%3Ddescriptions-open__%3B%21%21Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg%21L7gY3iiW9XBWoek9Fsjq0fdDz_0RnVlGyAETtbKnP6KER4VB3pgLFDxBipH85Zm3rn1tFStB-MFvZSGT9_NWtMbWqqg72Q68YLVSfUef%24
>  )
>
-1 is highly typical among UNIX functions, perhaps even in the purview
of "ça va sans dire", but there are numerous atypical cases for which the
programmer must check ERRNO; for example EAGAIN.  If you intend
to read from a transient stream (pipe, terminal), you should check EAGAIN.

-21 is extraordinary.  If it's not clearly documented (where?) it merits an 
RCF';
probably even an SR.

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Bernd Oppolzer

You're welcome.

I simply entered "REXX SYSCALLS OPEN" into Google Search, and this was 
the first hit:

https://www.ibm.com/docs/en/zos/2.1.0?topic=commands-open-write-close-file

this is where I found the sample code.

I didn't know or use SYSCALLS before.

Kind regards

Bernd


Am 11.09.2022 um 18:29 schrieb Charles Mills:

Thank you all and especially @Bernd Oppolzer. They key is that I was not 
checking the open for success correctly. I was formatting the second file name 
incorrectly and as a result the open was failing but my code did not make me 
aware of that. Bad open of course yields a bad fd which yields a -21. It is all 
new code and I had not tested open failures specifically.

Not sure where you saw the example that you cited. The IBM doc that I am 
looking at has the following for an example (in its entirety):

"open /u/linda/my.exec" o_rdwr+o_trunc+o_creat 700

which is of course useless with regard to how one checks for errors. IBM could 
do better, especially if open is atypical in how it reports errors.

(https://www.ibm.com/docs/en/zos/2.5.0?topic=descriptions-open)

Thanks again,
Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Paul Gilmartin
On Sat, 10 Sep 2022 18:45:04 -0500, Charles Mills wrote:
>...
>... the first file works (and the second file works if it is first). 
>

On Sun, 11 Sep 2022 11:29:07 -0500, Charles Mills wrote:

>Thank you all and especially @Bernd Oppolzer. They key is that I was not 
>checking the open for success correctly. I was formatting the second file name 
>incorrectly and as a result the open was failing but my code did not make me 
>aware of that. Bad open of course yields a bad fd which yields a -21. It is 
>all new code and I had not tested open failures specifically. 
> 
Why does it always fail on the second file regardless of swapping  the order?

I'll suggest defending against perverse file names by replacing:
"open" Arg(1) O_RDONLY 

with:
FN = Arg(1)
"open (FN)" O_RDONLY 

That should make -21 impossible.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Paul Gilmartin
On Sun, 11 Sep 2022 18:11:11 +, Farley, Peter x23353 wrote:

>The RC values are documented here for all SYSCALLS functions (including -21, 
>-22, ...):
>
>https://www.ibm.com/docs/en/zos/2.5.0?topic=values-returned-from-syscall-environment
> 
Thanks.  I missed that.  Very similar convention to BPXWDYN.

>Note though that there is also language saying that various "other" RC values 
>can be produced by "some" functions without a list or table of the exceptional 
>functions and values.  That lack may well call for an RCF.
> 
Those are probably best described under the individual functions.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Farley, Peter x23353
The RC values are documented here for all SYSCALLS functions (including -21, 
-22, ...):

https://www.ibm.com/docs/en/zos/2.5.0?topic=values-returned-from-syscall-environment

Note though that there is also language saying that various "other" RC values 
can be produced by "some" functions without a list or table of the exceptional 
functions and values.  That lack may well call for an RCF.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, September 11, 2022 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Why is my second Rexx SYSCALLS read failing?

On Sun, 11 Sep 2022 11:29:07 -0500, Charles Mills wrote:

>... Bad open of course yields a bad fd which yields a -21. It is all new 
> code and I had not tested open failures specifically. 
>
>Not sure where you saw the example that you cited. The IBM doc that I am 
>looking at has the following for an example (in its entirety):
>
>"open /u/linda/my.exec" o_rdwr+o_trunc+o_creat 700
>
>which is of course useless with regard to how one checks for errors. IBM could 
>do better, especially if open is atypical in how it reports errors. 
>
>(https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/2.5.0?topic=descriptions-open__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!L7gY3iiW9XBWoek9Fsjq0fdDz_0RnVlGyAETtbKnP6KER4VB3pgLFDxBipH85Zm3rn1tFStB-MFvZSGT9_NWtMbWqqg72Q68YLVSfUef$
>  )
>
-1 is highly typical among UNIX functions, perhaps even in the purview
of "ça va sans dire", but there are numerous atypical cases for which the
programmer must check ERRNO; for example EAGAIN.  If you intend
to read from a transient stream (pipe, terminal), you should check EAGAIN.

-21 is extraordinary.  If it's not clearly documented (where?) it merits an 
RCF';
probably even an SR.

-- 

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Paul Gilmartin
On Sun, 11 Sep 2022 11:29:07 -0500, Charles Mills wrote:

>... Bad open of course yields a bad fd which yields a -21. It is all new 
> code and I had not tested open failures specifically. 
>
>Not sure where you saw the example that you cited. The IBM doc that I am 
>looking at has the following for an example (in its entirety):
>
>"open /u/linda/my.exec" o_rdwr+o_trunc+o_creat 700
>
>which is of course useless with regard to how one checks for errors. IBM could 
>do better, especially if open is atypical in how it reports errors. 
>
>(https://www.ibm.com/docs/en/zos/2.5.0?topic=descriptions-open)
>
-1 is highly typical among UNIX functions, perhaps even in the purview
of "ça va sans dire", but there are numerous atypical cases for which the
programmer must check ERRNO; for example EAGAIN.  If you intend
to read from a transient stream (pipe, terminal), you should check EAGAIN.

-21 is extraordinary.  If it's not clearly documented (where?) it merits an 
RCF';
probably even an SR.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Charles Mills
Thank you all and especially @Bernd Oppolzer. They key is that I was not 
checking the open for success correctly. I was formatting the second file name 
incorrectly and as a result the open was failing but my code did not make me 
aware of that. Bad open of course yields a bad fd which yields a -21. It is all 
new code and I had not tested open failures specifically. 

Not sure where you saw the example that you cited. The IBM doc that I am 
looking at has the following for an example (in its entirety):

"open /u/linda/my.exec" o_rdwr+o_trunc+o_creat 700

which is of course useless with regard to how one checks for errors. IBM could 
do better, especially if open is atypical in how it reports errors. 

(https://www.ibm.com/docs/en/zos/2.5.0?topic=descriptions-open)

Thanks again,
Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Paul Gilmartin
On Sun, 11 Sep 2022 12:15:37 +, Seymour J Metz wrote:

>Comma isn't a valid delimitor in an expression. Did you mean 
>'open' path', O_rdwr+O_creat+O_trunc, 660'
>?
There was no such comma in Charles's original (pseudo?)code.

Bernd noted that he had problems copying from "the IBM doc"
with no specific citation.

The comma is used to denote a continuation in:


Now, back to our story?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Seymour J Metz
What I see is multiple lines, with a new line after the comma, making the comma 
a continuation character. For that to be valid on a single line you must remove 
the comma and insert semicolons to separate statements.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Sunday, September 11, 2022 3:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Why is my second Rexx SYSCALLS read failing?

Why is there suddenly the variable RC used to test the outcome of OPEN?
In the examples in the IBM doc I see:

|'open' path, O_rdwr+O_creat+O_trunc, 660 if retval=-1 then do say 'file
not opened, error codes' errno errnojr return end fd=retval |that is:

the returned fd and the code to test the success of OPEN
is both in the variable retval, not RC.

And: it would be better to assign the value of retval to
fd after the test for success.

Kind regards

Bernd


Am 11.09.2022 um 01:45 schrieb Charles Mills:
> I am working on a Rexx program that reads one or more UNIX files. (And 
> please, don't beat me up for Rexx; we can have the "superiority of Python" 
> discussion another day.)
>
> The logic works for the first file, but if there is a second file the read 
> fails with a -21, which I interpret as "bad fd." (Am I wrong about that?)
>
> Here are the read and open routines. The read routine gets called with the 
> file name. It's getting that right because the first file works (and the 
> second file works if it is first). There is no error printed by FileOpen. I 
> can see from the Print at the start of ReadOneFile that the filename is 
> correct. How could the fd be bad if the open succeeds?
>
> ReadOneLogFile:
>If IsVerbose Then Call Print "ReadOneLogFile:" Arg(1)
>
>ADDRESS SYSCALL
>Call FileOpen Arg(1)
>
>Do Forever
>  "read" Filefd "record" LogFileRecLen
>  If Length(record) <> LogFileRecLen Then Leave
>
>  /* snip */
>
>  End   /* Read records forever */
>
>"close" Filefd
>
>Return
>
> FileOpen:
>/* Open the file */
>"open" Arg(1) O_RDONLY
>Filefd = retval
>if RC = -1 Then Do
>  Call Print "Error from Log File open. RC =" RC errno errnojr
>  Signal EndProgram
>  End  /* RC <> 0 */
>Return
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Seymour J Metz
Comma isn't a valid delimitor in an expression. Did you mean 
'open' path', O_rdwr+O_creat+O_trunc, 660'
?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Sunday, September 11, 2022 4:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Why is my second Rexx SYSCALLS read failing?

Once again wrong, my e-Mail client is fooling me. Next try:

'open' path, O_rdwr+O_creat+O_trunc, 660
if retval=-1 then do
 say 'file not opened, error codes' errno errnojr
 return
end
fd=retval


Am 11.09.2022 um 10:01 schrieb Bernd Oppolzer:
> sorry for the strange formatting of the example code:
>
> should be
>
> 'open' path, O_rdwr+O_creat+O_trunc, 660
> if retval=-1 then do
> say 'file not opened, error codes' errno errnojr return
> end
> fd=retval
>
> Kind regards
>
> Bernd
>
>
> Am 11.09.2022 um 09:57 schrieb Bernd Oppolzer:
>> Why is there suddenly the variable RC used to test the outcome of OPEN?
>> In the examples in the IBM doc I see:
>>
>> |'open' path, O_rdwr+O_creat+O_trunc, 660 if retval=-1 then do say
>> 'file not opened, error codes' errno errnojr return end fd=retval
>> |that is:
>>
>> the returned fd and the code to test the success of OPEN
>> is both in the variable retval, not RC.
>>
>> And: it would be better to assign the value of retval to
>> fd after the test for success.
>>
>> Kind regards
>>
>> Bernd
>>
>>
>> Am 11.09.2022 um 01:45 schrieb Charles Mills:
>>> I am working on a Rexx program that reads one or more UNIX files.
>>> (And please, don't beat me up for Rexx; we can have the "superiority
>>> of Python" discussion another day.)
>>>
>>> The logic works for the first file, but if there is a second file
>>> the read fails with a -21, which I interpret as "bad fd." (Am I
>>> wrong about that?)
>>>
>>> Here are the read and open routines. The read routine gets called
>>> with the file name. It's getting that right because the first file
>>> works (and the second file works if it is first). There is no error
>>> printed by FileOpen. I can see from the Print at the start of
>>> ReadOneFile that the filename is correct. How could the fd be bad if
>>> the open succeeds?
>>>
>>> ReadOneLogFile:
>>>If IsVerbose Then Call Print "ReadOneLogFile:" Arg(1)
>>>ADDRESS SYSCALL
>>>Call FileOpen Arg(1)
>>>   Do Forever
>>>  "read" Filefd "record" LogFileRecLen
>>>  If Length(record) <> LogFileRecLen Then Leave
>>>   /* snip */
>>>   End   /* Read records forever */
>>>   "close" Filefd
>>>  Return
>>>
>>> FileOpen:
>>>/* Open the file */
>>>"open" Arg(1) O_RDONLY
>>>Filefd = retval
>>>if RC = -1 Then Do
>>>  Call Print "Error from Log File open. RC =" RC errno errnojr
>>>  Signal EndProgram
>>>  End  /* RC <> 0 */
>>>Return
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Paul Gilmartin
On Sun, 11 Sep 2022 10:02:53 +0200, Bernd Oppolzer wrote:

>Once again wrong, my e-Mail client is fooling me. Next try:
> 
It's way hard nowadays to Copy/Paste from manuals preserving formatting.

>'open' path, O_rdwr+O_creat+O_trunc, 660
>if retval=-1 then do
>     say 'file not opened, error codes' errno errnojr
>     return
>end
>fd=retval
>
>
>> Am 11.09.2022 um 09:57 schrieb Bernd Oppolzer:
>>> Why is there suddenly the variable RC used to test the outcome of OPEN?
>>> 
Yes.  Beware of the exception:  SYSCALL spqwnp (at least formerly) set
RC, not RETVAL.  Bad historical reasons.


>>> the returned fd and the code to test the success of OPEN
>>> is both in the variable retval, not RC.
>>>
>>> And: it would be better to assign the value of retval to
>>> fd after the test for success.
>>>
ObHeisenberg, it is a habit of Shell programmers to assign the status
to a variable immediately, lest reporting the status change the status.

In Charles's (pseudocode?) example, the main program fails to test
for failure of FileOpen.  Is it his intent with "Signal EndProgram" to
terminate all processing on the first error encountered?

>>> Am 11.09.2022 um 01:45 schrieb Charles Mills:
...
 The logic works for the first file, but if there is a second file
 the read fails with a -21, which I interpret as "bad fd." (Am I
 wrong about that?)

 Here are the read and open routines. The read routine gets called
 with the file name. It's getting that right because the first file
 works (and the second file works if it is first). There is no error
 printed by FileOpen. I can see from the Print at the start of
 ReadOneFile that the filename is correct. How could the fd be bad if
 the open succeeds?

 ReadOneLogFile:
    If IsVerbose Then Call Print "ReadOneLogFile:" Arg(1)
        ADDRESS SYSCALL
    Call FileOpen Arg(1)
       Do Forever
  "read" Filefd "record" LogFileRecLen
  If Length(record) <> LogFileRecLen Then Leave
   /* snip */
   End   /* Read records forever */
       "close" Filefd
      Return

 FileOpen:
    /* Open the file */
    "open" Arg(1) O_RDONLY
    Filefd = retval
    if RC = -1 Then Do
  Call Print "Error from Log File open. RC =" RC errno errnojr
  Signal EndProgram
  End  /* RC <> 0 */
    Return

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Bernd Oppolzer

Once again wrong, my e-Mail client is fooling me. Next try:

'open' path, O_rdwr+O_creat+O_trunc, 660
if retval=-1 then do
    say 'file not opened, error codes' errno errnojr
    return
end
fd=retval


Am 11.09.2022 um 10:01 schrieb Bernd Oppolzer:

sorry for the strange formatting of the example code:

should be

'open' path, O_rdwr+O_creat+O_trunc, 660
if retval=-1 then do
    say 'file not opened, error codes' errno errnojr return
end
fd=retval

Kind regards

Bernd


Am 11.09.2022 um 09:57 schrieb Bernd Oppolzer:

Why is there suddenly the variable RC used to test the outcome of OPEN?
In the examples in the IBM doc I see:

|'open' path, O_rdwr+O_creat+O_trunc, 660 if retval=-1 then do say 
'file not opened, error codes' errno errnojr return end fd=retval 
|that is:


the returned fd and the code to test the success of OPEN
is both in the variable retval, not RC.

And: it would be better to assign the value of retval to
fd after the test for success.

Kind regards

Bernd


Am 11.09.2022 um 01:45 schrieb Charles Mills:
I am working on a Rexx program that reads one or more UNIX files. 
(And please, don't beat me up for Rexx; we can have the "superiority 
of Python" discussion another day.)


The logic works for the first file, but if there is a second file 
the read fails with a -21, which I interpret as "bad fd." (Am I 
wrong about that?)


Here are the read and open routines. The read routine gets called 
with the file name. It's getting that right because the first file 
works (and the second file works if it is first). There is no error 
printed by FileOpen. I can see from the Print at the start of 
ReadOneFile that the filename is correct. How could the fd be bad if 
the open succeeds?


ReadOneLogFile:
   If IsVerbose Then Call Print "ReadOneLogFile:" Arg(1)
       ADDRESS SYSCALL
   Call FileOpen Arg(1)
      Do Forever
 "read" Filefd "record" LogFileRecLen
 If Length(record) <> LogFileRecLen Then Leave
  /* snip */
  End   /* Read records forever */
      "close" Filefd
     Return

FileOpen:
   /* Open the file */
   "open" Arg(1) O_RDONLY
   Filefd = retval
   if RC = -1 Then Do
 Call Print "Error from Log File open. RC =" RC errno errnojr
 Signal EndProgram
 End  /* RC <> 0 */
   Return

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Bernd Oppolzer

sorry for the strange formatting of the example code:

should be

'open' path, O_rdwr+O_creat+O_trunc, 660
if retval=-1 then do
    say 'file not opened, error codes' errno errnojr return
end
fd=retval

Kind regards

Bernd


Am 11.09.2022 um 09:57 schrieb Bernd Oppolzer:

Why is there suddenly the variable RC used to test the outcome of OPEN?
In the examples in the IBM doc I see:

|'open' path, O_rdwr+O_creat+O_trunc, 660 if retval=-1 then do say 
'file not opened, error codes' errno errnojr return end fd=retval 
|that is:


the returned fd and the code to test the success of OPEN
is both in the variable retval, not RC.

And: it would be better to assign the value of retval to
fd after the test for success.

Kind regards

Bernd


Am 11.09.2022 um 01:45 schrieb Charles Mills:
I am working on a Rexx program that reads one or more UNIX files. 
(And please, don't beat me up for Rexx; we can have the "superiority 
of Python" discussion another day.)


The logic works for the first file, but if there is a second file the 
read fails with a -21, which I interpret as "bad fd." (Am I wrong 
about that?)


Here are the read and open routines. The read routine gets called 
with the file name. It's getting that right because the first file 
works (and the second file works if it is first). There is no error 
printed by FileOpen. I can see from the Print at the start of 
ReadOneFile that the filename is correct. How could the fd be bad if 
the open succeeds?


ReadOneLogFile:
   If IsVerbose Then Call Print "ReadOneLogFile:" Arg(1)
       ADDRESS SYSCALL
   Call FileOpen Arg(1)
      Do Forever
 "read" Filefd "record" LogFileRecLen
 If Length(record) <> LogFileRecLen Then Leave
  /* snip */
  End   /* Read records forever */
      "close" Filefd
     Return

FileOpen:
   /* Open the file */
   "open" Arg(1) O_RDONLY
   Filefd = retval
   if RC = -1 Then Do
 Call Print "Error from Log File open. RC =" RC errno errnojr
 Signal EndProgram
 End  /* RC <> 0 */
   Return

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-11 Thread Bernd Oppolzer

Why is there suddenly the variable RC used to test the outcome of OPEN?
In the examples in the IBM doc I see:

|'open' path, O_rdwr+O_creat+O_trunc, 660 if retval=-1 then do say 'file 
not opened, error codes' errno errnojr return end fd=retval |that is:


the returned fd and the code to test the success of OPEN
is both in the variable retval, not RC.

And: it would be better to assign the value of retval to
fd after the test for success.

Kind regards

Bernd


Am 11.09.2022 um 01:45 schrieb Charles Mills:

I am working on a Rexx program that reads one or more UNIX files. (And please, don't beat 
me up for Rexx; we can have the "superiority of Python" discussion another day.)

The logic works for the first file, but if there is a second file the read fails with a 
-21, which I interpret as "bad fd." (Am I wrong about that?)

Here are the read and open routines. The read routine gets called with the file 
name. It's getting that right because the first file works (and the second file 
works if it is first). There is no error printed by FileOpen. I can see from 
the Print at the start of ReadOneFile that the filename is correct. How could 
the fd be bad if the open succeeds?

ReadOneLogFile:
   If IsVerbose Then Call Print "ReadOneLogFile:" Arg(1)

   ADDRESS SYSCALL

   Call FileOpen Arg(1)
   
   Do Forever

 "read" Filefd "record" LogFileRecLen
 If Length(record) <> LogFileRecLen Then Leave
 
 /* snip */
 
 End   /* Read records forever */
   
   "close" Filefd
  
   Return


FileOpen:
   /* Open the file */
   "open" Arg(1) O_RDONLY
   Filefd = retval
   if RC = -1 Then Do
 Call Print "Error from Log File open. RC =" RC errno errnojr
 Signal EndProgram
 End  /* RC <> 0 */
   Return

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-10 Thread Paul Gilmartin
On Sat, 10 Sep 2022 19:29:22 -0500, Charles Mills wrote:
>
>> FileOpen: PROCEDURE EXPOSE FileFd
> 
It might make things worse because O_RDONLY would become
undefined (which would be caught by SIGNAL ON NOVALUE.)

>In the absence of PROCEDURE, all variables are exposed.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-10 Thread Paul Gilmartin
On Sat, 10 Sep 2022 19:29:22 -0500, Charles Mills  wrote:
>...
>> FileOpen: PROCEDURE EXPOSE FileFd
>
>In the absence of PROCEDURE, all variables are exposed.
> 
True.  SIGNAL ON NOVALUE obviates many such concerns.

More shotgunning:

SIGNAL ON NOVALUE.

Add TRACE R at the beginning of V; then TRACE N after the
first read (to avoid voluminous output.)  Something unexpected
might appear.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-10 Thread Paul Gilmartin
On Sat, 10 Sep 2022 18:45:04 -0500, Charles Mills wrote:

>I am working on a Rexx program that reads one or more UNIX files. 
>...
>The logic works for the first file, but if there is a second file the read 
>fails with a -21, which I interpret as "bad fd." (Am I wrong about that?)
>
SYSCALL  strerror error_code reason_code stem
might tell you more.

I always use SIGNAL ON NOVALUE.  It finds unsuspected errors.

Does open return the same Filefd each time?  As an experiment
you might try omitting the close to see how it works with a different
fd.  (WAG!)

for:
>  if RC = -1 Then Do
>Call Print "Error from Log File open. RC =" RC errno errnojr

RC is(usually) nonzero if Rexx is unable to issue a system call,
in which case errno and errnojr are meaningless, perhaps unset.

>Here are the read and open routines. The read routine gets called with the 
>file name. It's getting that right because the first file works (and the 
>second file works if it is first). There is no error printed by FileOpen. I 
>can see from the Print at the start of ReadOneFile that the filename is 
>correct. How could the fd be bad if the open succeeds?
>
>ReadOneLogFile:
>  If IsVerbose Then Call Print "ReadOneLogFile:" Arg(1) 
>   
>  ADDRESS SYSCALL 
>  Call FileOpen Arg(1)
>  
>  Do Forever
>"read" Filefd "record" LogFileRecLen
>If Length(record) <> LogFileRecLen Then Leave
>
>/* snip */
>
>End   /* Read records forever */
>  
>  "close" Filefd
> 
>  Return
>
>FileOpen:
>  /* Open the file */
>  "open" Arg(1) O_RDONLY 
>  Filefd = retval
>  if RC = -1 Then Do
>Call Print "Error from Log File open. RC =" RC errno errnojr
>Signal EndProgram
>End  /* RC <> 0 */
>  Return

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-10 Thread Peter Sylvester

On 11/09/2022 02:29, Charles Mills wrote:

In the absence of PROCEDURE, all variables are exposed.



Thanks

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-10 Thread Charles Mills
Thanks!

> Shouldn’t Arg(1) be something like Arg(n) ?  Seems like your processing the 
> same file regardless of the number of arguments specified.

ReadOneLogFile is called multiple times with one argument each time. Arg(1) is 
always "the" file to read.

> Where is the error occurring?

On "read" Filefd "record" LogFileRecLen

Oh, by the way, LogFileRecLen is 20 and the read works for hundreds of records 
in the first file.

> FileOpen: PROCEDURE EXPOSE FileFd

In the absence of PROCEDURE, all variables are exposed.

Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-10 Thread Peter Sylvester

A late night guess:

FileOpen: PROCEDURE EXPOSE FileFd

https://www.ibm.com/docs/en/zos/2.5.0?topic=variables-exposing-procedure-expose

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Why is my second Rexx SYSCALLS read failing?

2022-09-10 Thread Matt Hogstrom
Shouldn’t Arg(1) be something like Arg(n) ?  Seems like your processing the 
same file regardless of the number of arguments specified.

Where is the error occurring?

Matt Hogstrom

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Sep 10, 2022, at 7:45 PM, Charles Mills  wrote:
> 
> I am working on a Rexx program that reads one or more UNIX files. (And 
> please, don't beat me up for Rexx; we can have the "superiority of Python" 
> discussion another day.)
> 
> The logic works for the first file, but if there is a second file the read 
> fails with a -21, which I interpret as "bad fd." (Am I wrong about that?)
> 
> Here are the read and open routines. The read routine gets called with the 
> file name. It's getting that right because the first file works (and the 
> second file works if it is first). There is no error printed by FileOpen. I 
> can see from the Print at the start of ReadOneFile that the filename is 
> correct. How could the fd be bad if the open succeeds?
> 
> ReadOneLogFile:
>  If IsVerbose Then Call Print "ReadOneLogFile:" Arg(1) 
> 
>  ADDRESS SYSCALL 
>  Call FileOpen Arg(1)
> 
>  Do Forever
>"read" Filefd "record" LogFileRecLen
>If Length(record) <> LogFileRecLen Then Leave
> 
>/* snip */
> 
>End   /* Read records forever */
> 
>  "close" Filefd
> 
>  Return
> 
> FileOpen:
>  /* Open the file */
>  "open" Arg(1) O_RDONLY 
>  Filefd = retval
>  if RC = -1 Then Do
>Call Print "Error from Log File open. RC =" RC errno errnojr
>Signal EndProgram
>End  /* RC <> 0 */
>  Return
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Why is my second Rexx SYSCALLS read failing?

2022-09-10 Thread Charles Mills
I am working on a Rexx program that reads one or more UNIX files. (And please, 
don't beat me up for Rexx; we can have the "superiority of Python" discussion 
another day.)

The logic works for the first file, but if there is a second file the read 
fails with a -21, which I interpret as "bad fd." (Am I wrong about that?)

Here are the read and open routines. The read routine gets called with the file 
name. It's getting that right because the first file works (and the second file 
works if it is first). There is no error printed by FileOpen. I can see from 
the Print at the start of ReadOneFile that the filename is correct. How could 
the fd be bad if the open succeeds?

ReadOneLogFile:
  If IsVerbose Then Call Print "ReadOneLogFile:" Arg(1) 
   
  ADDRESS SYSCALL 
  Call FileOpen Arg(1)
  
  Do Forever
"read" Filefd "record" LogFileRecLen
If Length(record) <> LogFileRecLen Then Leave

/* snip */

End   /* Read records forever */
  
  "close" Filefd
 
  Return

FileOpen:
  /* Open the file */
  "open" Arg(1) O_RDONLY 
  Filefd = retval
  if RC = -1 Then Do
Call Print "Error from Log File open. RC =" RC errno errnojr
Signal EndProgram
End  /* RC <> 0 */
  Return

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN