Re: Real fun for companies on older machines & SCRT

[Timothy Sipples]

John, a couple questions from me:

1. What release of z/OS? 2.1?

2. What's your Java release? (java -version should tell you.)

3. What's the exact, complete error message you're getting?

— — — — —
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM zSystems/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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

Re: bpxpqrmxx and $SYSNAME vs

[Joe Monk]

Since $ is a valid character in a SYSNAME, I dont think you want to make
that change.

Joe

On Sun, Sep 11, 2022 at 11:44 PM Lizette Koehler 
wrote:

> I have a coworker saying we should change our //etc/..   To
> /$SYSNAME/etc/.
>
>
>
> I am not familiar with coding this way
>
>
>
> Could someone provide a cons vs pros (simple words please) on which is
> needed, or used or preferred?
>
>
>
> Thank you
>
>
>
>
>
>
> --
> 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

bpxpqrmxx and $SYSNAME vs

[Lizette Koehler]

I have a coworker saying we should change our //etc/..   To
/$SYSNAME/etc/.

 

I am not familiar with coding this way

 

Could someone provide a cons vs pros (simple words please) on which is
needed, or used or preferred?

 

Thank you 

 

 


--
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?

[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:


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?

[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?

[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: Real fun for companies on older machines & SCRT

[John McKown]

On Sat, Sep 10, 2022 at 7:05 PM Michael Oujesky 
wrote:

> Look like LINUX desktops are supported and simple binary transfer of
> the SMF data per
> <
> https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/SCRTsc236845/$file/e0z3s127.pdf>SCRT:
>
> Using the Sub-Capacity Reporting Tool V28.2.0
> (ibm.com)
>
> https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/SCRTsc236845/$file/e0z3s127.pdf
>
>
> Michael
>

Thanks, Michael.

I have downloaded this on my work desktop PC. I tested it out. The report
numbers are the same, with some minor differences in "comment" type data.
Or so says my "diff".



>
> At 12:50 PM 9/10/2022, John McKown wrote:
>
> >Not too sure the form the SMF data would need to be in. And I thought to
> he
> >Linux version was only for z/Linux. But it's something to look into.
> >
> >On Sat, Sep 10, 2022, 11:56 Michael Oujesky 
> wrote:
> >
> > > It has been a while since I worked with SCRT, but thought it also ran
> > > on Linux and Windows.
> > >
> > > Michael
> > >
> > > At 08:20 AM 9/9/2022, John McKown wrote:
> > >
> > > >I just found out that IBM will be releasing version 29 of the SCRT
> program
> > > >on 15Oct2022. Version 28 reports will be accepted only up to the
> Nov2022
> > > >report (submitted in Dec2022), at which time only version 29 reports
> will
> > > >be accepted. Version 29 of SCRT requires Java 8.
> > > >
> > > >I just tested this out at work using Java 8 instead of Java 7. Java 8
> > > >reports that it will not run on a z9BC. "Processor detected (z9) does
> not
> > > >support instruction MVGHI" .
> > > >
> > > >This is going to be fun. A sister company is on a z15, running z/OS.
> So
> > > >perhaps they will be tasked to take our SMF data, produce the SCRT
> report,
> > > >and then upload it to IBM. But perhaps they will give me an ID on
> their
> > > >system to do this.
> > > >
> > > >--
> > > >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
>
> --
> 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?

[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?

[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?

[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?

[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?

[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?

[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?

[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: refresh system symbols

[Peter Relson]

Michael Babcock's comment was fully correct and on point.

If you have LOADxx in SYS1.IPLPARM on volume VOL123 and that dataset is not in 
the parmlib concatenation then
SETLOAD xx,IEASYM,DSN=SYS1.IPLPARM,VOL=VOL123
applies.

And, as is described, you can use
SETLOAD xx,IEASYM,DSN=IPL,VOL=IPL
To indicate to take the dataset and volume used from IPL to locate LOADxx.

Colin, what commentary update are you thinking of requesting?
The doc indicates that the default is to locate LOADxx via the parmlib 
concatenation (which is true) and shows how to override the default.
There's almost always room for improvement in documentation

Peter Relson
z/OS Core Technology Design


--
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?

[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: refresh system symbols

[McIntosh, Richard]

If you LOAD02 is in SYS.IPLPARM, then like Mike Babcock said, use the DSN parm.

SETLOAD 02,IEASYM,DSN=SYS.IPLPARM

I do this all the time.

Richard McIntosh

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Babcock
Sent: Saturday, September 10, 2022 10:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: refresh system symbols

The 02 was just an example straight from the doc.

On Sat, Sep 10, 2022 at 11:15 AM Colin Paice  wrote:

> SETLOAD 02,IEASYM,DSN=sys2.relson,VOL=123456
> only works if you have a load02 in the dataset.
> I do not - my LOADxx's are in SYS.IPLPARM - that's the problem.
> I can create a LOAD02 just for refreshing the symbols, but that feels
> like working round the problem (no real hardship) I've raised a doc
> comment on this.
> Colin
>
> On Sat, 10 Sept 2022 at 14:46, Michael Babcock 
> wrote:
>
> > You can specify a dataset name and volser.
> >
> > SETLOAD 02,IEASYM,DSN=sys2.relson,VOL=123456
> >
> > On Sat, Sep 10, 2022 at 5:42 AM Colin Paice 
> wrote:
> >
> > > I've been trying to refresh the system symbols, and have hit a problem.
> > > There is the setload command, which you can use to refresh IPL or
> IEASYM
> > -
> > > but only if the LOADxx member is in the PARMLIB concatenation.
> > >
> > > My LOADxx (from the ADCD system) is in SYS1.IPLPARM, and setload
> > > does
> not
> > > pick the changes up from there.
> > >
> > > For example
> > >
> > > 05.34.10   setload 00,ieasym
> > >
> > > 05.34.10   IEF764I MSTJCL00 RESOLVER IEFPARM SETLOAD_LOAD00
> > PARMLIB
> > > READ FAILED - MEMBER LOAD00 NOT FOUND.
> > > 05.34.10   IEF901I SYSTEM SYMBOLS WERE NOT UPDATED FROM LOAD00.
> > >
> > > IEFPRMLB RETURN CODE=000C REASON=0001
> > >
> > > If I copy load00 to user.z25a.parmlib and repeat it I get SETLOAD
> > > 00,IEASYM IEF900I SYSTEM SYMBOLS WERE UPDATED FROM LOAD00
> > >
> > >
> > > Is there another command I should be using, or do I need to set up
> > > a
> > dummy
> > > member in user.z25a.parmlib to do it?
> > >
> > > Colin
> > >
> > > --
> > >  For IBM-MAIN subscribe / signoff / archive access
> > > instructions, send email to lists...@listserv.ua.edu with the
> > > message: INFO IBM-MAIN
> > >
> > --
> > Michael Babcock
> > OneMain Financial
> > z/OS Systems Programmer, Lead
> >
> > 
> > -- 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
>
--
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

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


CONFIDENTIALITY NOTICE This message and any included attachments are from 
Cerner Corporation and are intended only for the addressee. The information 
contained in this message is confidential and may constitute inside or 
non-public information under international, federal, or state securities laws. 
Unauthorized forwarding, printing, copying, distribution, or use of such 
information is strictly prohibited and may be unlawful. If you are not the 
addressee, please promptly delete this message and notify the sender of the 
delivery error by e-mail or you may call Cerner's corporate offices in Kansas 
City, Missouri, U.S.A at (+1) (816)221-1024.

--
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?

[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?

[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?

[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?

[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