Re: Tape devices not online during IPL

[Peter]

Hello

This will require a POR ? We dont have a scheduled downtime for next 2
months.

Will this be a good idea to add these devices in COMMDxx ?

Peter

On Thu, 26 Mar, 2020, 10:22 AM (K.K.Paradox)T.Kobayashi, <
kobaya...@paradox.jp> wrote:

> Hello Peter,
>
> Check the OFFLINE setting in IODF's Define Device Parameters.
> If the value is "Yes", change to "No".
>
>  E Ess HCD Help ssN
> sssN
>  e e  e
> e
>  e Command === e Command=> Scroll=> CSR   e
> CSR
> e
>  e e OFFLINE  e
> e
>  e Specify or  e  e
> e
>  e e Specifies whether MVS is to consider the device  e
> e
>  e Configurati e online or offline at IPL.e
> e
>  e Device numb e  e
> e
>  e Device type e Yes  The device is considered offline at IPL.e
> e
>  e e  e
> e
>  e Parameter/  e No   The device is considered online at IPL. e
> e
>  e Feature e  (Default)   e
> e
>  e OFFLINE e  e
> IPL
> e
>  e DYNAMIC e If MVS needs the device during IPL, specify No.  e
> e
>  e LOCANY  e - end -  e
> e
>  e LIBRARY e  e
> e
>  e AUTOSWITCH  e  e
> e
>  e LIBRARY-ID  e  e
> e
>  e LIBPORT-ID  e  e
> e
>  e MTL e  e
> =32)
> e
>  e SHARABLEe  e
> e
>  e  F1=Helpe  F1=Help  F2=Ex help   F3=Exit  F5=Windowe
> e
>  e  F7=Backwar e  F7=Backward  F8=Forward   F9=Keyshelp F12=Cancele nd
> e
>  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
> .  .
>
>
> Best regards,
> Toyokazu Kobayashi
>
> - Original Message -
> From: "Peter" 
> Newsgroups: bit.listserv.ibm-main
> To: 
> Sent: Thursday, March 26, 2020 1:25 PM
> Subject: Tape devices not online during IPL
>
>
> > Hello
> >
> > Hope everyone is doing well and safe .
> >
> > When we IPL our system our Physical and virtual devices are not coming
> > online automatically and everytime we need to issue VARY ONLINE command.
> > Due to this our DFSMSrmm often throws intervention error message for
> > RETRY.
> >
> > I know COMMDxx parm can vary on it automatically during startup. Is it
> > possible that I can modify it in IODF definition which can make it online
> > automatically once the system loads ?
> >
> > What would be the best approach to this issue?
> >
> > Peter
> >
> > --
> > 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: Tape devices not online during IPL

[(K.K.Paradox)T.Kobayashi]

Hello Peter,

Check the OFFLINE setting in IODF's Define Device Parameters.
If the value is "Yes", change to "No".

E Ess HCD Help ssN 
sssN
e e  e 
e
e Command === e Command=> Scroll=> CSR   e CSR 
e
e e OFFLINE  e 
e
e Specify or  e  e 
e
e e Specifies whether MVS is to consider the device  e 
e
e Configurati e online or offline at IPL.e 
e
e Device numb e  e 
e
e Device type e Yes  The device is considered offline at IPL.e 
e
e e  e 
e
e Parameter/  e No   The device is considered online at IPL. e 
e
e Feature e  (Default)   e 
e
e OFFLINE e  e IPL 
e
e DYNAMIC e If MVS needs the device during IPL, specify No.  e 
e
e LOCANY  e - end -  e 
e
e LIBRARY e  e 
e
e AUTOSWITCH  e  e 
e
e LIBRARY-ID  e  e 
e
e LIBPORT-ID  e  e 
e
e MTL e  e =32) 
e
e SHARABLEe  e 
e
e  F1=Helpe  F1=Help  F2=Ex help   F3=Exit  F5=Windowe 
e
e  F7=Backwar e  F7=Backward  F8=Forward   F9=Keyshelp F12=Cancele nd 
e
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 
.  .



Best regards,
Toyokazu Kobayashi

- Original Message - 
From: "Peter" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Thursday, March 26, 2020 1:25 PM
Subject: Tape devices not online during IPL



Hello

Hope everyone is doing well and safe .

When we IPL our system our Physical and virtual devices are not coming
online automatically and everytime we need to issue VARY ONLINE command.
Due to this our DFSMSrmm often throws intervention error message for 
RETRY.


I know COMMDxx parm can vary on it automatically during startup. Is it
possible that I can modify it in IODF definition which can make it online
automatically once the system loads ?

What would be the best approach to this issue?

Peter

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

Tape devices not online during IPL

[Peter]

Hello

Hope everyone is doing well and safe .

When we IPL our system our Physical and virtual devices are not coming
online automatically and everytime we need to issue VARY ONLINE command.
Due to this our DFSMSrmm often throws intervention error message for RETRY.

I know COMMDxx parm can vary on it automatically during startup. Is it
possible that I can modify it in IODF definition which can make it online
automatically once the system loads ?

What would be the best approach to this issue?

Peter

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

Re: REXX MVSVAR SYMDEF behavoiur

[Bruce Hewson]

Hi,

I am writing a general subroutine that would replace system symbols in any text 
string.
I had a fairly complicated piece of code to do the correct symbol replacement, 
including possible symbol concatenation, obeying all the replacement rules I 
could remember. My code still had somewhere to go to be closer to what I 
wanted, when I accidentally ran the below code.

The parameter being passed is a text string, so no REXX Variable replacement 
should be made.

What I think is happening, the & values are being recognised as symbols and 
being replaced, then the whole text string is turned into a symbol name , i.e. 
&textstring., and since that has no replacement is being returned as an 
unresolved symbol name.

Thus, end result, my text string gets any symbol name replaced as desired, but 
is uppercased, prefixed with "&" and suffixed with "."

I can live with that a simple coding exercise.

So far I have not seen anyone identify where this is fully documented.

On Wed, 25 Mar 2020 04:43:52 -0500, Bruce Hewson  
wrote:

>Hi,
>
>In a REXX exec I was building I stumbled onto:-
>
>Say 'MVSVAR'("SYMDEF",'testing &sysname in &sysplex')
>
>which provides an unexpected result 
>
>&'TESTING SYSA IN PLEX01'.   
>
>The symbols &SYSNAME and &SYSPLEX were replaced.
>And, sadly, the whole lot was uppercased.
>
>Couldn't find this behaviour documented.
>
>Regards
>Bruce
>

Regards
Bruce

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

Re: SLIP TRACE

[Peter Cook]

Hi Martin,

1) Yes you can, I am pretty rure you should still get a message if it triggers
2) Yes, to get trace data you will need to run GTF trace at the same time

Regards
Peter Cook

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
MARTIN, MIKE
Sent: Thursday, 26 March 2020 3:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SLIP TRACE

IBM provided this slip (below) for user key common before our 2.2/2.4 upgrade.  
 (We do not have the maintenance yet for healthcheck and SMF)

SLIP SET,IF,A=TRACE,ID=UCSA,NUCEP=(IGVVSMG2,0,1),END

My questions are...


  1.  Can I change A=TRACE to A=NODUMP  (possibly add MATCHLIM) just to see if 
get any bites?
  2.  Later, if we need to... Do I need to run GTF during the SLIP A=TRACE ?

Mike Martin




This email may contain confidential and privileged material for the sole use of 
the intended recipient. If you are not the intended recipient, please contact 
the sender and delete all copies. Any review or distribution by others is 
strictly prohibited. Personal emails are restricted by policy of the State 
Employees' Credit Union (SECU).  Therefore SECU specifically disclaims any 
responsibility or liability for any personal information or opinions of the 
author expressed in this email.

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

[SUSPECTED SPAM] Tivoli Omegamon High Availability Hub on z/OS & DVIPA

[esst...@juno.com]

Hi
.
Is anyone using a Omegamon High Availability Hub on z/OS ?.I need some guidance 
-
.
Im looking for sample DVIPA (Dynamic Virtual IP Address) definitions for an 
Omegamon High Availability Hub on z/OS ?Google is not producing what 'Im 
looking for.  
.
In addition to defining a DVIPA, do I need to specify the HOSTNAME "OMEGAHAHUB" 
in the HOSTNAME statement section of TCPDATA  ?
.
If I have Four LPARS and the High Availability Hub is Defined on LPAR1, should 
I add the DVIPA and Hostname definition on the other LPARS ?
.Thanks In Avance.
Paul D'Angelo*

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

[SUSPECTED SPAM] Tivoli Omegamon High Availability Hub on z/OS & DVIPA

[esst...@juno.com]

Hi
.I need some clarification -.
Is anyone using an Omegamon High Availability Hub on z/OS  with Dynamic Virtual 
IP Address (DVIPA) ?
.
Im looking for sample DVIPA definitions with a Omegamon High Availability Hub 
on z/OS ?Google didn't produce the expected results.
.
In addition should  I specify the HOSTNAME "OMEGAHAHUB" in the HOSTNAME 
statement section of TCPDATA  ?
.
If I have Four LPARS and the High Availability Hub is Defined  only on LPAR1, 
should  I add the DVIPA and Hostname definition on the other  three LPARS ?
.
Paul D'Angelo
.

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

[SUSPECTED SPAM] Tivoli Omegamon High Availability Hub on z/OS & DVIPA

[esst...@juno.com]

.Hi
.I need some clarification -.
Is anyone using a Omegamon High Availability Hub on z/OS  with Dynamic Virtual 
IP Address (DVIPA) ?
.
Im looking for sample DVIPA definitions for an Omegamon High Availability Hub 
on z/OS ?
.
In addition should  I specify the HOSTNAME "OMEGAHAHUB" in the HOSTNAME 
statement section of TCPDATA  ?
.
If I have Four LPARS and the High Availability Hub is Defined  only on LPAR1, 
should  I add the DVIPA and Hostname definition on the other  three LPARS ?
.
Paul D'Angelo
.

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

Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64

[Binyamin Dissen]

The critical part of the dump is the trace table from the ESTAEX thru the
abend.

On Wed, 25 Mar 2020 00:02:59 -0400 Thomas David Rivers 
wrote:

:>Peter Relson wrote:
:>
:>>
:>>What it _looks_ like from the dump is that ESTAEX is invoked
:>>(via  PC - this is just problem state) and on return, the address
:>>in the PSW has the AMODE bit set - but we are in AMODE 64,
:>>so now my PSW address is pointing to the wrong place.
:>>
:>>
:>>Some day, maybe I'll start reading these initial posts more carefully. For 
:>>whatever reason, I thought you were talking about the ESTAEX routine 
:>>getting control at an incorrect place. 
:>>
:>>Are you saying that when you issued the PC you were AMODE 64 but you did 
:>>not return to the next sequential instruction? There's no realistic chance 
:>>of that happening (aside from an abend having occurred). The linkage stack 
:>>entry would have had to be overlaid or the PR instruction failed to do 
:>>what it is architected to do.  One way or another, you are almost 
:>>certainly misreading the dump.
:>>
:>>Please provide some data to show that this is true. For example, capture 
:>>data to prove that you did issue the ESTAEX as you thought and that you 
:>>did not get control at the NSI (such as by having x'' as the NSI and 
:>>seeing that you did not get a PIC 1 at that point). 
:>>
:>>If you compare the expansions for ESTAEX myESTAEX,PARAM=P you'll see that 
:>>the only difference in the expansion between SYSSTATE AMODE64=NO and 
:>>SYSSTATE AMODE64=YES lies with how the parameter is processed.  AMODE 31 
:>>ESTAEX gets control with the 4-byte parameter address and parameter ALET. 
:>>AMODE 64 ESTAEX gets control with the 8-byte parameter address. If the 
:>>linkage stack entry for the ESTAEX PC indicates that the call was made in 
:>>AMODE 64 then the routine will get control in AMODE 64. Otherwise it will 
:>>not.
:>>
:>>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
:>>
:>>  
:>>
:>Hi Peter!
:>
:> What I seem to be seeing is that I issue the ESTAEX; *without* SYSSTATE 
:>AMODE=64,
:>but the program is running AMODE64.
:>
:> When I return back from the PC that results as the expansion of ESTAEX, 
:>the PSW
:>is pointing at the next instruction.. but the address in the PSW has the 
:>31-bit AMODE
:>set... so - it's the proper address only if you strip that off.   The 
:>machine has been
:>returned to AMODE 64, but since that AMODE31 bit is set in the PSW 
:>address it's
:>a "bad" address...
:>
:>  Hope that helps explain things a little more about what I'm seeing... 
:>and I understand
:>your point about linkage-stack - that shouldn't be possible.   Perhaps 
:>the dump
:>is simply showing the wrong PSW address?
:>
:>  And - this is just what it looks like from the dump...   but - I might 
:>just be misreading
:>the dump as you suggest.
:>
:>   Here is the start of my SYSUDUMP:
:>
:>1JOB AOUT STEP AOUTTIME 170714   DATE 20083
:>ID = 000
:>   CPUID = D301BF6B1090   PAGE 0001
:>0COMPLETION CODE  SYSTEM = 0C2  REASON CODE = 0002
:>
:>
:>
:>   PSW AT ENTRY TO ABEND   078D1001  9F90B1C2  ILC  04  INTC  0002
:>
:>0PSW MODULE ADDRESS = _1F900880  OFFSET = A942
:>
:> NAME=AOUT
:>
:>
:>which is a 31-bit PSW in the dump?
:>
:>Here's the bytes at 1F90B1A0-1F90B200:
:> 1F90B1A0 10009604 10005020 10089201 1003410058E0 001058EE 
:>030458EE 00B0B218   *..o...&...k\*
:> 1F90B1C0 E000B904 00D4E380 C0A40014 B90A0087BF8F8004 4770C15A 
:>50F0 D0A8E3F0   *\MT.{u.g..A!..&0}yT0*
:> 1F90B1E0 C0A40014 B90A00F7 A718 5010F004E3F0D0A8 0014D707 
:>D088D088 E3D0D080   *{u.7x...&.0.T0}y..P.}h}hT}}.*
:>
:>
:>And - here is the disassembly at starting at 0x1f90b1a0 going for 12 
:>instructions:
:>
:>
:>   0x1f90b1a0:1000LPR   0,0
:>   0x1f90b1a2:9604 1000   OI0(1),4
:>   0x1f90b1a6:5020 1008   ST2,8(0,1)
:>   0x1f90b1aa:9201 1003   MVI   3(1),1
:>   0x1f90b1ae:4100    LA0,0(0,0)
:>   0x1f90b1b2:58e0 0010   L 14,16(0,0)
:>   0x1f90b1b6:58ee 0304   L 14,772(14,0)
:>   0x1f90b1ba:58ee 00b0   L 14,176(14,0)
:>   0x1f90b1be:b218 e000   PC0(14)
:>   0x1f90b1c2:b904 00d4   LGR   13,4
:>
:>This is the ASM source:
:>
:>  LGR 4,13
:>  LGR 13,5
:>  LG  6,=AD(ESTAE_EXIT)
:>  XGR 1,1   clear upper bits of R1 ESTAEX needs it
:>  ESTAEX (6),PARAM=(2),MF=(E,(3)) 
:>  LGR 13,4
:>
:>R5 points to a temp DSA space for the ESTAEX macro (to avoid possible 
:>overwrites)
:>and R2 contains the parm to be placed in SDWAPARM.
:>
:>So - it _appears_ (but - I might be reading this wrong) that the PSW address
:>is pointing at the instruction just following the PC for the ESTAEX 

TEST TEST TEST

[esst...@juno.com]

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

SLIP TRACE

[MARTIN, MIKE]

IBM provided this slip (below) for user key common before our 2.2/2.4 upgrade.  
 (We do not have the maintenance yet for healthcheck and SMF)

SLIP SET,IF,A=TRACE,ID=UCSA,NUCEP=(IGVVSMG2,0,1),END

My questions are...


  1.  Can I change A=TRACE to A=NODUMP  (possibly add MATCHLIM) just to see if 
get any bites?
  2.  Later, if we need to... Do I need to run GTF during the SLIP A=TRACE ?

Mike Martin




This email may contain confidential and privileged material for the sole use of 
the intended recipient. If you are not the intended recipient, please contact 
the sender and delete all copies. Any review or distribution by others is 
strictly prohibited. Personal emails are restricted by policy of the State 
Employees' Credit Union (SECU).  Therefore SECU specifically disclaims any 
responsibility or liability for any personal information or opinions of the 
author expressed in this email.

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

Re: REXX MVSVAR SYMDEF behavoiur

[Seymour J Metz]

In this case, LONG_SYMBOL_NAME was the SYMDEF name, so there was no way to 
refer to it with an 8-character name if the manual tells us true.  

No, I remember when IBM documentation varied all over the landscape. The 
Utilities documentation was appalling, the MVT logic manuals excellent and 
others fell somewhere in between. When IBM went to HIPO things got worse and 
"task-oriented documentation" was a death blow for quality.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, March 25, 2020 12:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX MVSVAR SYMDEF behavoiur

On Wed, 25 Mar 2020 16:13:22 +, Seymour J Metz wrote:

>If MFC doesn't know then it's probably impossible to find out why.
>
>BTW, I submitted and RCF on the conflict between text and example.
>
Thanks.  Of course, no such problem exists if LONG_SYMBOL_NAME
has been assigned a value no longer than 8 characters, such as:
LONG_SYMBOL_NAME = 'Brief'
z1 = MVSVAR('SYMDEF','LONG_SYMBOL_NAME')

Remember when IBM was lauded for the quality of its documentation?
 “There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the other
way is to make it so complicated that there are no obvious deficiencies.
The first method is far more difficult.”
-- C.A.R. Hoare

Carries over, magnified, to the documentation.

>
>From: Paul Gilmartin
>Sent: Wednesday, March 25, 2020 12:03 PM
>
>On Wed, 25 Mar 2020 15:43:47 +, Seymour J Metz wrote:
>
>>Why? I suspect that only Mike knows.
>>
>MFC?  I suspect it was out of his control before that happened.
>
>>Worse, the same manual has an example where the name is longer than 8 
>>characters.
>>
>Oh, don't you make me search for it.  ITYM:
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ikja300/mvsvarr.htm
>
>That is, IEASYMxx contains the definitions:
>
>SYMDEF(&LONG_SYMBOL_NAME='SY1T_ON_PLEX_A44T')
>SYMDEF(&EXTSYM_='<==THIS VALUE CAN BE UP TO 44 CHARS LONG===>')
>
>Then, the MVSVAR function can be used to retrieve the values of these symbols 
>as shown:
>
>z1 = MVSVAR('SYMDEF','LONG_SYMBOL_NAME')
>z2 = MVSVAR('SYMDEF','EXTSYM_')
>
>For z1:
><- Returns z1: SY1T_ON_PLEX_A44T
>
>For z2:
><- Returns z2: <==THIS VALUE CAN BE UP TO 44 CHARS LONG===>
>
>-- 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: NFS Problem

[Steve Beaver]

Its happens that way once in a blue moon - Not once a day like windows
support people have users do



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Wednesday, March 25, 2020 1:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

That sounds like someone who support windows machines hehehe


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids,
MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Steve Beaver
Sent: Wednesday, March 25, 2020 1:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

The easiest and old school way is to IPL out of the problem and that is what
I'm going to do

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Wednesday, March 25, 2020 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

This may be a hint:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3
.bpxb200/tranreq.htm

Use the PARM= parameter of the z/OS UNIX colony address space. To set
transport affinity for the NFS Client or DFS Client, use the PARM= keyword
of the EXEC statement that starts BPXVCLNY in the colony address space
procedure as follows:
//MVSCLNT EXEC PGM=BPXVCLNY,TIME=1440,PARM=TP(TPNAME)Copy
where the PARM=value is the following:
All in uppercase
Starts with "TP("
TPNAME is the left-aligned, 1-to-8-character name of the desired transport
If PARM= is specified and does not conform to these rules, the colony is
terminated by an EC6 abend with a reason code of 11BE8039. When CINET is
configured on the system and the specified transport is not configured under
CINET, the colony is terminated by an EC6 abend with a reason code of
11BE803A. In either case, the colony can be restarted after the procedure is
corrected by replying to the operator prompt that is issued.


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids,
MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Steve Beaver
Sent: Wednesday, March 25, 2020 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

Dave - now I have the following

IEF450I MVSNFSC MVSNFSC - ABEND=SEC6 U REASON=11BE8039

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Wednesday, March 25, 2020 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

Steve,


I could be mistaken, but its only necessary to issue that command if you are
running NFS Client.  It sounds to me like you configured/started the z/OS
NFS server, in which case I believe you just recycle the task.

We only run the NFS client, and that is how we shutdown MVSNFSC task.
Restarting that task is the SET OMVS command you mention, and that restarts
just the Client.

RTFM says
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.id
an400/sts.htm


P NFS or F NFS,STOP, or F NFS,SHUTDOWN
S NFS to start


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids,
MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Steve Beaver
Sent: Wednesday, March 25, 2020 11:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: NFS Problem

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

I was forced to STOP NFS (See Below) because of a RACF definition problem

 

F OMVS,STOPPFS=NFS



Now when I SET OMVS=MC  I get this message

 


BPXF011I A FILE SYSTEM WITH FILESYSTYPE OR SUBFILESYSTYPE NFS 114   
FAILED TO INITIALIZE.   
A DUPLICATE FILESYSTYPE/SUBFILESYSTYPE STATEMENT WAS FOUND IN PARMLIB   
MEMBER  
BPXPRMMC.  

 

Anyone have any idea how to remediate this problem



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

Re: NFS Problem

[Jousma, David]

That sounds like someone who support windows machines hehehe

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, March 25, 2020 1:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

The easiest and old school way is to IPL out of the problem and that is what 
I'm going to do

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, March 25, 2020 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

This may be a hint:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3
.bpxb200/tranreq.htm

Use the PARM= parameter of the z/OS UNIX colony address space. To set transport 
affinity for the NFS Client or DFS Client, use the PARM= keyword of the EXEC 
statement that starts BPXVCLNY in the colony address space procedure as follows:
//MVSCLNT EXEC PGM=BPXVCLNY,TIME=1440,PARM=TP(TPNAME)Copy
where the PARM=value is the following:
All in uppercase
Starts with "TP("
TPNAME is the left-aligned, 1-to-8-character name of the desired transport If 
PARM= is specified and does not conform to these rules, the colony is 
terminated by an EC6 abend with a reason code of 11BE8039. When CINET is 
configured on the system and the specified transport is not configured under 
CINET, the colony is terminated by an EC6 abend with a reason code of 11BE803A. 
In either case, the colony can be restarted after the procedure is corrected by 
replying to the operator prompt that is issued.


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, March 25, 2020 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Dave - now I have the following

IEF450I MVSNFSC MVSNFSC - ABEND=SEC6 U REASON=11BE8039

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, March 25, 2020 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

Steve,


I could be mistaken, but its only necessary to issue that command if you are 
running NFS Client.  It sounds to me like you configured/started the z/OS NFS 
server, in which case I believe you just recycle the task.

We only run the NFS client, and that is how we shutdown MVSNFSC task.
Restarting that task is the SET OMVS command you mention, and that restarts 
just the Client.

RTFM says
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.id
an400/sts.htm


P NFS or F NFS,STOP, or F NFS,SHUTDOWN
S NFS to start


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, March 25, 2020 11:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: NFS Problem

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I was forced to STOP NFS (See Below) because of a RACF definition problem

 

F OMVS,STOPPFS=NFS



Now when I SET OMVS=MC  I get this message

 


BPXF011I A FILE SYSTEM WITH FILESYSTYPE OR SUBFILESYSTYPE NFS 114   
FAILED TO INITIALIZE.   
A DUPLICATE FILESYSTYPE/SUBFILESYSTYPE STATEMENT WAS FOUND IN PARMLIB   
MEMBER  
BPXPRMMC.  

 

Anyone have any idea how to remediate this problem



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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you 

Re: adrdssu utility

[Shelia Chalk]

Thank you so much  IT WORKS !


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Vernooij, Kees (ITOP NM) - KLM
Sent: Wednesday, March 25, 2020 10:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: adrdssu utility

A Mistake I made many times: you should not put filtlist names in quotes, only 
strings.
So in your routine, &HLQ is compared to the string '&FIST'
To compare &HLQ to the filtlist &FIST, you should code: (&HLQ EQ &FIST)

Met vriendelijke groet,
Kees Vernooij
KLM Information Services
z/OS Systems
Tel +31 6 10 14 58 78


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shelia Chalk
Sent: 25 March 2020 15:52
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: adrdssu utility

has anyone ever use adrdssu utility to restore a dataset from tape and rename 
then dataset. here is my problem  see jcl below
I am trying to use the sms routines.  I want the renameu dataset q2vo.slc.*** 
to go to a different volume  then the include dataset. in the sms routines I 
have   in the &fist I have in the filtlist the q2vo.** dataset..

 
IF ((&ACSENVIR EQ 'RECOVER') AND (&HLQ EQ '&FIST'))  
THEN 
  DO 
SET &STORCLAS = 'FIST'   
EXIT 
  END  

 

JCL I AM RUNNING

 //D2REST   EXEC PGM=ADRDSSU,REGION=8M  
//SYSPRINT DD SYSOUT=* 
//OUTDDDD UNIT=SYSDA,DISP=(NEW,CATLG,CATLG)
//INDD DD DSN=Q2SC.GN.GN.P010.GNTAPE.Q2BKUP(0),
//DISP=SHR 
//DUMMYDD   DUMMY  
//SYSINDD   *  
 RESTORE INDD(INDD) OUTDD(OUTDD) - 
DATASET( - 
INCLUDE(-  
Q2VO.GN.GN.P010.GNCDE.V -  
   ) - 
  ) -  
   RENAMEU((Q2VO.GN.GN.P010.GNCDE.V-   
Q2VO.SLC.**   )) - 
CANCELERROR -  
CATALOG -  
TGTGDS(ACTIVE)-
REPLACE-   
SHR SPHERE 



any ideas???

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

For information, services and offers, please visit our web site: 
https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.com&data=01%7C01%7CSChalk%40TRUSTMARK.COM%7C23ded3e07ad14b8f4b1408d7d0ce88f5%7C518d66eacb8948c8a7b903cba11cde91%7C1&sdata=zGPmL9ic%2FkGd9IBYeFOgIbBKv3QMqOQ0k6PCU8lROSI%3D&reserved=0.
 This e-mail and any attachment may contain confidential and privileged 
material intended for the addressee only. If you are not the addressee, you are 
notified that no part of the e-mail or any attachment may be disclosed, copied 
or distributed, and that any other action related to this e-mail or attachment 
is strictly prohibited, and may be unlawful. If you have received this e-mail 
by error, please notify the sender immediately by return e-mail, and delete 
this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
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: NFS Problem

[Steve Beaver]

The easiest and old school way is to IPL out of the problem and that is what
I'm going to do

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Wednesday, March 25, 2020 11:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

This may be a hint:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3
.bpxb200/tranreq.htm

Use the PARM= parameter of the z/OS UNIX colony address space. To set
transport affinity for the NFS Client or DFS Client, use the PARM= keyword
of the EXEC statement that starts BPXVCLNY in the colony address space
procedure as follows:
//MVSCLNT EXEC PGM=BPXVCLNY,TIME=1440,PARM=TP(TPNAME)Copy
where the PARM=value is the following:
All in uppercase
Starts with "TP("
TPNAME is the left-aligned, 1-to-8-character name of the desired transport
If PARM= is specified and does not conform to these rules, the colony is
terminated by an EC6 abend with a reason code of 11BE8039. When CINET is
configured on the system and the specified transport is not configured under
CINET, the colony is terminated by an EC6 abend with a reason code of
11BE803A. In either case, the colony can be restarted after the procedure is
corrected by replying to the operator prompt that is issued.


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids,
MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Steve Beaver
Sent: Wednesday, March 25, 2020 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

Dave - now I have the following

IEF450I MVSNFSC MVSNFSC - ABEND=SEC6 U REASON=11BE8039

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Wednesday, March 25, 2020 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

Steve,


I could be mistaken, but its only necessary to issue that command if you are
running NFS Client.  It sounds to me like you configured/started the z/OS
NFS server, in which case I believe you just recycle the task.

We only run the NFS client, and that is how we shutdown MVSNFSC task.
Restarting that task is the SET OMVS command you mention, and that restarts
just the Client.

RTFM says
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.id
an400/sts.htm


P NFS or F NFS,STOP, or F NFS,SHUTDOWN
S NFS to start


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids,
MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Steve Beaver
Sent: Wednesday, March 25, 2020 11:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: NFS Problem

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

I was forced to STOP NFS (See Below) because of a RACF definition problem

 

F OMVS,STOPPFS=NFS



Now when I SET OMVS=MC  I get this message

 


BPXF011I A FILE SYSTEM WITH FILESYSTYPE OR SUBFILESYSTYPE NFS 114   
FAILED TO INITIALIZE.   
A DUPLICATE FILESYSTYPE/SUBFILESYSTYPE STATEMENT WAS FOUND IN PARMLIB   
MEMBER  
BPXPRMMC.  

 

Anyone have any idea how to remediate this problem



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

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**


This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it
in any manner. If you are not the intended recipient, any disclosure,
copying, distribution or use of the contents of this information is
prohibited. Please reply to the message immediately by informing the sender
that the message was misdirected. After replying, please erase it from your
computer system. Your assistance in correcting this error is appreciated.

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

Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64

[Thomas David Rivers]

Peter Relson wrote:



What it _looks_ like from the dump is that ESTAEX is invoked
(via  PC - this is just problem state) and on return, the address
in the PSW has the AMODE bit set - but we are in AMODE 64,
so now my PSW address is pointing to the wrong place.


Some day, maybe I'll start reading these initial posts more carefully. For 
whatever reason, I thought you were talking about the ESTAEX routine 
getting control at an incorrect place. 

Are you saying that when you issued the PC you were AMODE 64 but you did 
not return to the next sequential instruction? There's no realistic chance 
of that happening (aside from an abend having occurred). The linkage stack 
entry would have had to be overlaid or the PR instruction failed to do 
what it is architected to do.  One way or another, you are almost 
certainly misreading the dump.


Please provide some data to show that this is true. For example, capture 
data to prove that you did issue the ESTAEX as you thought and that you 
did not get control at the NSI (such as by having x'' as the NSI and 
seeing that you did not get a PIC 1 at that point). 

If you compare the expansions for ESTAEX myESTAEX,PARAM=P you'll see that 
the only difference in the expansion between SYSSTATE AMODE64=NO and 
SYSSTATE AMODE64=YES lies with how the parameter is processed.  AMODE 31 
ESTAEX gets control with the 4-byte parameter address and parameter ALET. 
AMODE 64 ESTAEX gets control with the 8-byte parameter address. If the 
linkage stack entry for the ESTAEX PC indicates that the call was made in 
AMODE 64 then the routine will get control in AMODE 64. Otherwise it will 
not.


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

 


Hi Peter!

What I seem to be seeing is that I issue the ESTAEX; *without* SYSSTATE 
AMODE=64,

but the program is running AMODE64.

When I return back from the PC that results as the expansion of ESTAEX, 
the PSW
is pointing at the next instruction.. but the address in the PSW has the 
31-bit AMODE
set... so - it's the proper address only if you strip that off.   The 
machine has been
returned to AMODE 64, but since that AMODE31 bit is set in the PSW 
address it's

a "bad" address...

 Hope that helps explain things a little more about what I'm seeing... 
and I understand
your point about linkage-stack - that shouldn't be possible.   Perhaps 
the dump

is simply showing the wrong PSW address?

 And - this is just what it looks like from the dump...   but - I might 
just be misreading

the dump as you suggest.

  Here is the start of my SYSUDUMP:

1JOB AOUT STEP AOUTTIME 170714   DATE 20083
ID = 000

  CPUID = D301BF6B1090   PAGE 0001
0COMPLETION CODE  SYSTEM = 0C2  REASON CODE = 0002



  PSW AT ENTRY TO ABEND   078D1001  9F90B1C2  ILC  04  INTC  0002

0PSW MODULE ADDRESS = _1F900880  OFFSET = A942

NAME=AOUT


which is a 31-bit PSW in the dump?

Here's the bytes at 1F90B1A0-1F90B200:
1F90B1A0 10009604 10005020 10089201 1003410058E0 001058EE 
030458EE 00B0B218   *..o...&...k\*
1F90B1C0 E000B904 00D4E380 C0A40014 B90A0087BF8F8004 4770C15A 
50F0 D0A8E3F0   *\MT.{u.g..A!..&0}yT0*
1F90B1E0 C0A40014 B90A00F7 A718 5010F004E3F0D0A8 0014D707 
D088D088 E3D0D080   *{u.7x...&.0.T0}y..P.}h}hT}}.*



And - here is the disassembly at starting at 0x1f90b1a0 going for 12 
instructions:



  0x1f90b1a0:1000LPR   0,0
  0x1f90b1a2:9604 1000   OI0(1),4
  0x1f90b1a6:5020 1008   ST2,8(0,1)
  0x1f90b1aa:9201 1003   MVI   3(1),1
  0x1f90b1ae:4100    LA0,0(0,0)
  0x1f90b1b2:58e0 0010   L 14,16(0,0)
  0x1f90b1b6:58ee 0304   L 14,772(14,0)
  0x1f90b1ba:58ee 00b0   L 14,176(14,0)
  0x1f90b1be:b218 e000   PC0(14)
  0x1f90b1c2:b904 00d4   LGR   13,4

This is the ASM source:

 LGR 4,13
 LGR 13,5
 LG  6,=AD(ESTAE_EXIT)
 XGR 1,1   clear upper bits of R1 ESTAEX needs it
 ESTAEX (6),PARAM=(2),MF=(E,(3)) 
 LGR 13,4


R5 points to a temp DSA space for the ESTAEX macro (to avoid possible 
overwrites)

and R2 contains the parm to be placed in SDWAPARM.

So - it _appears_ (but - I might be reading this wrong) that the PSW address
is pointing at the instruction just following the PC for the ESTAEX 
(which makes sense)
but it kinda looks like we are not quite right somehow?  


Or - maybe it's just how the SYSUDUMP formatted the PSW at the top - and I
just might be really confused - because it looks like a 31-bit PSW but 
is in AMODE 64?


If one of those values is incorrect though (like, say, R2) would that 
cause the ESTAEX

to blow-up with an 0C2 ?


 - Thanks! -
 - Dave Rivers -




--
riv...@dignus.comWork: (919) 676-

Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64

[Thomas David Rivers]

Ed Jaffe wrote:


On 3/23/2020 2:15 AM, Thomas David Rivers wrote:


I think I've run into an interesting problem with ESTAEX
when it is invoked in AMODE 64 without SYSTATE AMODE=64
set at assembly time.

That is, this is code that could potentially run in either AMODE 31
or AMODE 64... so it's not assembled with SYSTATE AMODE=64.




Macro expansions can differ depending on the SYSSTATE settings. It's 
not safe to ignore that.



If the module can legitimately run in either AMODE, I would do 
something like:



|SYSSTATE PUSH Save current SYSSTATE
|TAM   ,   Test addressing mode
|IF O  If 64-bit mode
|  SYSSTATE AMODE64=YES  Tell macros how to expand
|  ESTAEX ...Establish recovery exit
|ELSE ,Else 31-bit mode
|  SYSSTATE AMODE64=NO   Tell macros how to expand
|  ESTAEX ...Establish recovery exit
|ENDIF ,   EndIf
|SYSSTATE POP  Restore current SYSSTATE



This is a really good idea...

There another complication though - the SDWAPARM in the ESTAE EXIT is 
different
when SYSSTATE AMODE64=YES is specified on the ESTAEX macro.   So, you 
might need

to do a test in the ESTAE EXIT for AMODE 64 as well.

That seems like it would make for a pretty generic routine... many 
thanks for the idea!


- Dave R. -


--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Re: REXX MVSVAR SYMDEF behavoiur

[Paul Gilmartin]

On Wed, 25 Mar 2020 16:13:22 +, Seymour J Metz wrote:

>If MFC doesn't know then it's probably impossible to find out why.
>
>BTW, I submitted and RCF on the conflict between text and example.
>
Thanks.  Of course, no such problem exists if LONG_SYMBOL_NAME
has been assigned a value no longer than 8 characters, such as:
LONG_SYMBOL_NAME = 'Brief'
z1 = MVSVAR('SYMDEF','LONG_SYMBOL_NAME')

Remember when IBM was lauded for the quality of its documentation?
 “There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the other
way is to make it so complicated that there are no obvious deficiencies.
The first method is far more difficult.”
-- C.A.R. Hoare

Carries over, magnified, to the documentation.

>
>From: Paul Gilmartin
>Sent: Wednesday, March 25, 2020 12:03 PM
>
>On Wed, 25 Mar 2020 15:43:47 +, Seymour J Metz wrote:
>
>>Why? I suspect that only Mike knows.
>>
>MFC?  I suspect it was out of his control before that happened.
>
>>Worse, the same manual has an example where the name is longer than 8 
>>characters.
>>
>Oh, don't you make me search for it.  ITYM:
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ikja300/mvsvarr.htm
>
>That is, IEASYMxx contains the definitions:
>
>SYMDEF(&LONG_SYMBOL_NAME='SY1T_ON_PLEX_A44T')
>SYMDEF(&EXTSYM_='<==THIS VALUE CAN BE UP TO 44 CHARS LONG===>')
>
>Then, the MVSVAR function can be used to retrieve the values of these symbols 
>as shown:
>
>z1 = MVSVAR('SYMDEF','LONG_SYMBOL_NAME')
>z2 = MVSVAR('SYMDEF','EXTSYM_')
>
>For z1:
><- Returns z1: SY1T_ON_PLEX_A44T
>
>For z2:
><- Returns z2: <==THIS VALUE CAN BE UP TO 44 CHARS LONG===>
>
>-- gil

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

Re: REXX MVSVAR SYMDEF behavoiur

[Seymour J Metz]

If MFC doesn't know then it's probably impossible to find out why.

BTW, I submitted and RCF on the conflict between text and example.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, March 25, 2020 12:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX MVSVAR SYMDEF behavoiur

On Wed, 25 Mar 2020 15:43:47 +, Seymour J Metz wrote:

>Why? I suspect that only Mike knows.
>
MFC?  I suspect it was out of his control before that happened.

>Worse, the same manual has an example where the name is longer than 8 
>characters.
>
Oh, don't you make me search for it.  ITYM:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ikja300/mvsvarr.htm

That is, IEASYMxx contains the definitions:

SYMDEF(&LONG_SYMBOL_NAME='SY1T_ON_PLEX_A44T')
SYMDEF(&EXTSYM_='<==THIS VALUE CAN BE UP TO 44 CHARS LONG===>')

Then, the MVSVAR function can be used to retrieve the values of these symbols 
as shown:

z1 = MVSVAR('SYMDEF','LONG_SYMBOL_NAME')
z2 = MVSVAR('SYMDEF','EXTSYM_')

For z1:
<- Returns z1: SY1T_ON_PLEX_A44T

For z2:
<- Returns z2: <==THIS VALUE CAN BE UP TO 44 CHARS LONG===>

-- 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: NFS Problem

[Jousma, David]

This may be a hint:  
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb200/tranreq.htm

Use the PARM= parameter of the z/OS UNIX colony address space. To set transport 
affinity for the NFS Client or DFS Client, use the PARM= keyword of the EXEC 
statement that starts BPXVCLNY in the colony address space procedure as follows:
//MVSCLNT EXEC PGM=BPXVCLNY,TIME=1440,PARM=TP(TPNAME)Copy
where the PARM=value is the following:
All in uppercase
Starts with "TP("
TPNAME is the left-aligned, 1-to-8-character name of the desired transport
If PARM= is specified and does not conform to these rules, the colony is 
terminated by an EC6 abend with a reason code of 11BE8039. When CINET is 
configured on the system and the specified transport is not configured under 
CINET, the colony is terminated by an EC6 abend with a reason code of 11BE803A. 
In either case, the colony can be restarted after the procedure is corrected by 
replying to the operator prompt that is issued.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, March 25, 2020 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Dave - now I have the following

IEF450I MVSNFSC MVSNFSC - ABEND=SEC6 U REASON=11BE8039

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, March 25, 2020 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

Steve,


I could be mistaken, but its only necessary to issue that command if you are 
running NFS Client.  It sounds to me like you configured/started the z/OS NFS 
server, in which case I believe you just recycle the task.

We only run the NFS client, and that is how we shutdown MVSNFSC task.
Restarting that task is the SET OMVS command you mention, and that restarts 
just the Client.

RTFM says
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.id
an400/sts.htm


P NFS or F NFS,STOP, or F NFS,SHUTDOWN
S NFS to start


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, March 25, 2020 11:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: NFS Problem

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I was forced to STOP NFS (See Below) because of a RACF definition problem

 

F OMVS,STOPPFS=NFS



Now when I SET OMVS=MC  I get this message

 


BPXF011I A FILE SYSTEM WITH FILESYSTYPE OR SUBFILESYSTYPE NFS 114   
FAILED TO INITIALIZE.   
A DUPLICATE FILESYSTYPE/SUBFILESYSTYPE STATEMENT WAS FOUND IN PARMLIB   
MEMBER  
BPXPRMMC.  

 

Anyone have any idea how to remediate this problem



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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it in 
any manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
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 **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpect

Re: NFS Problem

[Jousma, David]

That's usually security error in unix, but that reason code is unknown on my 
system when I issue TSO BPXMTEXT 11BE8039

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, March 25, 2020 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Dave - now I have the following

IEF450I MVSNFSC MVSNFSC - ABEND=SEC6 U REASON=11BE8039

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Wednesday, March 25, 2020 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

Steve,


I could be mistaken, but its only necessary to issue that command if you are 
running NFS Client.  It sounds to me like you configured/started the z/OS NFS 
server, in which case I believe you just recycle the task.

We only run the NFS client, and that is how we shutdown MVSNFSC task.
Restarting that task is the SET OMVS command you mention, and that restarts 
just the Client.

RTFM says
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.id
an400/sts.htm


P NFS or F NFS,STOP, or F NFS,SHUTDOWN
S NFS to start


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, March 25, 2020 11:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: NFS Problem

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I was forced to STOP NFS (See Below) because of a RACF definition problem

 

F OMVS,STOPPFS=NFS



Now when I SET OMVS=MC  I get this message

 


BPXF011I A FILE SYSTEM WITH FILESYSTYPE OR SUBFILESYSTYPE NFS 114   
FAILED TO INITIALIZE.   
A DUPLICATE FILESYSTYPE/SUBFILESYSTYPE STATEMENT WAS FOUND IN PARMLIB   
MEMBER  
BPXPRMMC.  

 

Anyone have any idea how to remediate this problem



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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it in 
any manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
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 **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: REXX MVSVAR SYMDEF behavoiur

[Paul Gilmartin]

On Wed, 25 Mar 2020 15:43:47 +, Seymour J Metz wrote:

>Why? I suspect that only Mike knows.
>
MFC?  I suspect it was out of his control before that happened.

>Worse, the same manual has an example where the name is longer than 8 
>characters.
>
Oh, don't you make me search for it.  ITYM:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ikja300/mvsvarr.htm
 
That is, IEASYMxx contains the definitions:

SYMDEF(&LONG_SYMBOL_NAME='SY1T_ON_PLEX_A44T')
SYMDEF(&EXTSYM_='<==THIS VALUE CAN BE UP TO 44 CHARS LONG===>')

Then, the MVSVAR function can be used to retrieve the values of these symbols 
as shown:

z1 = MVSVAR('SYMDEF','LONG_SYMBOL_NAME')
z2 = MVSVAR('SYMDEF','EXTSYM_')

For z1:
<- Returns z1: SY1T_ON_PLEX_A44T

For z2:
<- Returns z2: <==THIS VALUE CAN BE UP TO 44 CHARS LONG===>

-- gil

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

Re: NFS Problem

[Steve Beaver]

Dave - now I have the following

IEF450I MVSNFSC MVSNFSC - ABEND=SEC6 U REASON=11BE8039

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jousma, David
Sent: Wednesday, March 25, 2020 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: NFS Problem

Steve,


I could be mistaken, but its only necessary to issue that command if you are
running NFS Client.  It sounds to me like you configured/started the z/OS
NFS server, in which case I believe you just recycle the task.

We only run the NFS client, and that is how we shutdown MVSNFSC task.
Restarting that task is the SET OMVS command you mention, and that restarts
just the Client.

RTFM says
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.id
an400/sts.htm


P NFS or F NFS,STOP, or F NFS,SHUTDOWN
S NFS to start


_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids,
MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Steve Beaver
Sent: Wednesday, March 25, 2020 11:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: NFS Problem

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

I was forced to STOP NFS (See Below) because of a RACF definition problem

 

F OMVS,STOPPFS=NFS



Now when I SET OMVS=MC  I get this message

 


BPXF011I A FILE SYSTEM WITH FILESYSTYPE OR SUBFILESYSTYPE NFS 114   
FAILED TO INITIALIZE.   
A DUPLICATE FILESYSTYPE/SUBFILESYSTYPE STATEMENT WAS FOUND IN PARMLIB   
MEMBER  
BPXPRMMC.  

 

Anyone have any idea how to remediate this problem



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

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**


This e-mail transmission contains information that is confidential and may
be privileged.   It is intended only for the addressee(s) named above. If
you receive this e-mail in error, please do not read, copy or disseminate it
in any manner. If you are not the intended recipient, any disclosure,
copying, distribution or use of the contents of this information is
prohibited. Please reply to the message immediately by informing the sender
that the message was misdirected. After replying, please erase it from your
computer system. Your assistance in correcting this error is appreciated.

--
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: REXX MVSVAR SYMDEF behavoiur

[Paul Gilmartin]

On Wed, 25 Mar 2020 11:24:30 -0400, Ken Smith wrote:

>Useful, but this is closer and more clear (don't have a system to test)
>
>sysname = MVSVAR('SYMDEF','SYSNAME')
>sysplex = MVSVAR('SYMDEF','sysplex')
>
>say 'Testing on' system 'in' sysplex
> 
If, as described in the Ref.:
The MVSVAR('SYMDEF',string) function goes through REXX substitution for 
string first,
the result of which must be a 1-8 character symbolic-name specifying the 
symbol that
has been defined in the SYMDEF statement. Any other values including REXX 
delimiters
might cause unpredictable results.
I code:
Foo = 'SYSNAME'
Bar = 'sysplex'
sysname = MVSVAR('SYMDEF','Foo')
sysplex = MVSVAR('SYMDEF','Bar')
... I'd expect to get the (same) desired result.

Whereas, if I code:
SYSNAME = 'Foo'
sysplex = 'Bar
sysname = MVSVAR('SYMDEF','SYSNAME')
sysplex = MVSVAR('SYMDEF','sysplex')
... I'd expect to get an undesired result.

 Right? 
The Ref. should clarify this with examples.

-- gil

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

Re: REXX MVSVAR SYMDEF behavoiur

[Seymour J Metz]

Why? I suspect that only Mike knows.


Worse, the same manual has an example where the name is longer than 8 
characters.












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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, March 25, 2020 11:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX MVSVAR SYMDEF behavoiur

On Wed, 25 Mar 2020 13:28:12 +, Seymour J Metz wrote:

>"The MVSVAR('SYMDEF',string) function goes through REXX substitution for 
>string first, the result of which must be a 1-8 character symbolic-name 
>specifying the symbol that has been defined in the SYMDEF statement. Any other 
>values including REXX delimiters might cause unpredictable results."
>
I see.  But why!?  is this an ill-conceived attempt to appease CLIST
programmers by supporting synthesized variable names?

is the "REXX substitution" identical to that which would be performed
by VALUE( string ); compound symbols resolved according to the
Symbolic rather than Direct convention, etc.?
o If not, the exact behavior should be specified.
o Even if so, a statement to that effect should appear.

(I suspect, hope actually, that this uses  IRXEXCOM with the SHVSYFET option.)
>
>From:  Bruce Hewson
>Sent: Wednesday, March 25, 2020 5:43 AM
>
>In a REXX exec I was building I stumbled onto:-
>
>Say 'MVSVAR'("SYMDEF",'testing &sysname in &sysplex')
>
>which provides an unexpected result
>
>&'TESTING SYSA IN PLEX01'.
>
>The symbols &SYSNAME and &SYSPLEX were replaced.
>And, sadly, the whole lot was uppercased.
>
>Couldn't find this behaviour documented.
>
Was there no error indication?  I'd expect one because of "must".

-- 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: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64

[Steve Smith]

 I think that snip is just a misunderstanding.

There are two AMODE bits in the PSW, and in the real 128-bit PSW, neither
is in the address part.  It doesn't work the way general registers do when
you switch AMODE without cleaning up addresses in registers (which involves
clearing the top 33 bits, not just the high-half).

sas


On Wed, Mar 25, 2020 at 11:21 AM Peter Relson  wrote:

> 
> What it _looks_ like from the dump is that ESTAEX is invoked
> (via  PC - this is just problem state) and on return, the address
> in the PSW has the AMODE bit set - but we are in AMODE 64,
> so now my PSW address is pointing to the wrong place.
> 
>
> Some day, maybe I'll start reading these initial posts more carefully. For
> whatever reason, I thought you were talking about the ESTAEX routine
> getting control at an incorrect place.
>
> Are you saying that when you issued the PC you were AMODE 64 but you did
> not return to the next sequential instruction? There's no realistic chance
> of that happening (aside from an abend having occurred). The linkage stack
> entry would have had to be overlaid or the PR instruction failed to do
> what it is architected to do.  One way or another, you are almost
> certainly misreading the dump.
>
> Please provide some data to show that this is true. For example, capture
> data to prove that you did issue the ESTAEX as you thought and that you
> did not get control at the NSI (such as by having x'' as the NSI and
> seeing that you did not get a PIC 1 at that point).
>
> If you compare the expansions for ESTAEX myESTAEX,PARAM=P you'll see that
> the only difference in the expansion between SYSSTATE AMODE64=NO and
> SYSSTATE AMODE64=YES lies with how the parameter is processed.  AMODE 31
> ESTAEX gets control with the 4-byte parameter address and parameter ALET.
> AMODE 64 ESTAEX gets control with the 8-byte parameter address. If the
> linkage stack entry for the ESTAEX PC indicates that the call was made in
> AMODE 64 then the routine will get control in AMODE 64. Otherwise it will
> not.
>
> 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
>


-- 
sas

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

Re: NFS Problem

[Jousma, David]

Steve,


I could be mistaken, but its only necessary to issue that command if you are 
running NFS Client.  It sounds to me like you configured/started the z/OS NFS 
server, in which case I believe you just recycle the task.

We only run the NFS client, and that is how we shutdown MVSNFSC task.   
Restarting that task is the SET OMVS command you mention, and that restarts 
just the Client.

RTFM says 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.idan400/sts.htm


P NFS or F NFS,STOP, or F NFS,SHUTDOWN
S NFS to start

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Beaver
Sent: Wednesday, March 25, 2020 11:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: NFS Problem

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I was forced to STOP NFS (See Below) because of a RACF definition problem

 

F OMVS,STOPPFS=NFS



Now when I SET OMVS=MC  I get this message

 


BPXF011I A FILE SYSTEM WITH FILESYSTYPE OR SUBFILESYSTYPE NFS 114   
FAILED TO INITIALIZE.   
A DUPLICATE FILESYSTYPE/SUBFILESYSTYPE STATEMENT WAS FOUND IN PARMLIB   
MEMBER  
BPXPRMMC.  

 

Anyone have any idea how to remediate this problem



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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: REXX MVSVAR SYMDEF behavoiur

[Paul Gilmartin]

On Wed, 25 Mar 2020 13:28:12 +, Seymour J Metz wrote:

>"The MVSVAR('SYMDEF',string) function goes through REXX substitution for 
>string first, the result of which must be a 1-8 character symbolic-name 
>specifying the symbol that has been defined in the SYMDEF statement. Any other 
>values including REXX delimiters might cause unpredictable results."
>
I see.  But why!?  is this an ill-conceived attempt to appease CLIST
programmers by supporting synthesized variable names?

is the "REXX substitution" identical to that which would be performed
by VALUE( string ); compound symbols resolved according to the
Symbolic rather than Direct convention, etc.?
o If not, the exact behavior should be specified.
o Even if so, a statement to that effect should appear.

(I suspect, hope actually, that this uses  IRXEXCOM with the SHVSYFET option.)
>
>From:  Bruce Hewson
>Sent: Wednesday, March 25, 2020 5:43 AM
>
>In a REXX exec I was building I stumbled onto:-
>
>Say 'MVSVAR'("SYMDEF",'testing &sysname in &sysplex')
>
>which provides an unexpected result
>
>&'TESTING SYSA IN PLEX01'.
>
>The symbols &SYSNAME and &SYSPLEX were replaced.
>And, sadly, the whole lot was uppercased.
>
>Couldn't find this behaviour documented.
> 
Was there no error indication?  I'd expect one because of "must".

-- gil

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

Re: REXX MVSVAR SYMDEF behavoiur

[Ken Smith]

Useful, but this is closer and more clear (don't have a system to test)

sysname = MVSVAR('SYMDEF','SYSNAME')
sysplex = MVSVAR('SYMDEF','sysplex')

say 'Testing on' system 'in' sysplex

Ken Smith
Retired Sysprog


On Wed, Mar 25, 2020 at 11:01 AM Gerardo Toro  wrote:

> First excuse my English it is so bad.
>
> I put these sentences:
>
> I = MVSVAR('SYMDEF','SYSNAME')
> j = MVSVAR('SYMDEF','sysplex')
> SAY 'Testing MVSVAR(SYMDEF,sysname)' i 'in sysplex ' j
>
> and I obtained this ...
>
> Testing MVSVAR(SYMDEF,sysname) CHT8 in sysplex  PLEXDE
> ***
>
> It is useful or not?
>
> --
> 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

NFS Problem

[Steve Beaver]

I was forced to STOP NFS (See Below) because of a RACF definition problem

 

F OMVS,STOPPFS=NFS



Now when I SET OMVS=MC  I get this message

 


BPXF011I A FILE SYSTEM WITH FILESYSTYPE OR SUBFILESYSTYPE NFS 114   
FAILED TO INITIALIZE.   
A DUPLICATE FILESYSTYPE/SUBFILESYSTYPE STATEMENT WAS FOUND IN PARMLIB   
MEMBER  
BPXPRMMC.  

 

Anyone have any idea how to remediate this problem



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

Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64

[Peter Relson]

What it _looks_ like from the dump is that ESTAEX is invoked
(via  PC - this is just problem state) and on return, the address
in the PSW has the AMODE bit set - but we are in AMODE 64,
so now my PSW address is pointing to the wrong place.


Some day, maybe I'll start reading these initial posts more carefully. For 
whatever reason, I thought you were talking about the ESTAEX routine 
getting control at an incorrect place. 

Are you saying that when you issued the PC you were AMODE 64 but you did 
not return to the next sequential instruction? There's no realistic chance 
of that happening (aside from an abend having occurred). The linkage stack 
entry would have had to be overlaid or the PR instruction failed to do 
what it is architected to do.  One way or another, you are almost 
certainly misreading the dump.

Please provide some data to show that this is true. For example, capture 
data to prove that you did issue the ESTAEX as you thought and that you 
did not get control at the NSI (such as by having x'' as the NSI and 
seeing that you did not get a PIC 1 at that point). 

If you compare the expansions for ESTAEX myESTAEX,PARAM=P you'll see that 
the only difference in the expansion between SYSSTATE AMODE64=NO and 
SYSSTATE AMODE64=YES lies with how the parameter is processed.  AMODE 31 
ESTAEX gets control with the 4-byte parameter address and parameter ALET. 
AMODE 64 ESTAEX gets control with the 8-byte parameter address. If the 
linkage stack entry for the ESTAEX PC indicates that the call was made in 
AMODE 64 then the routine will get control in AMODE 64. Otherwise it will 
not.

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: adrdssu utility

[Allan Staller]

1) I am not sure &ACSENVIR is recover. IIRC, this is related to dfHSM and like 
prodiucts, not ADRDSSU restore.

2) It is not clear if the target environment is SMS managed or not.
 You can supply (STORCLAS, DATACLAS, MGMTCLAS) and override the ACS 
routines with BYPASSACS(**)


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shelia Chalk
Sent: Wednesday, March 25, 2020 9:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: adrdssu utility

[CAUTION: This Email is from outside the Organization. Do not click links or 
open attachments unless you trust the sender.]

has anyone ever use adrdssu utility to restore a dataset from tape and rename 
then dataset. here is my problem  see jcl below
I am trying to use the sms routines.  I want the renameu dataset q2vo.slc.*** 
to go to a different volume  then the include dataset. in the sms routines I 
have   in the &fist I have in the filtlist the q2vo.** dataset..


IF ((&ACSENVIR EQ 'RECOVER') AND (&HLQ EQ '&FIST'))
THEN
  DO
SET &STORCLAS = 'FIST'
EXIT
  END



JCL I AM RUNNING

 //D2REST   EXEC PGM=ADRDSSU,REGION=8M
//SYSPRINT DD SYSOUT=*
//OUTDDDD UNIT=SYSDA,DISP=(NEW,CATLG,CATLG)
//INDD DD DSN=Q2SC.GN.GN.P010.GNTAPE.Q2BKUP(0),
//DISP=SHR
//DUMMYDD   DUMMY
//SYSINDD   *
 RESTORE INDD(INDD) OUTDD(OUTDD) -
DATASET( -
INCLUDE(-
Q2VO.GN.GN.P010.GNCDE.V -
   ) -
  ) -
   RENAMEU((Q2VO.GN.GN.P010.GNCDE.V-
Q2VO.SLC.**   )) -
CANCELERROR -
CATALOG -
TGTGDS(ACTIVE)-
REPLACE-
SHR SPHERE



any ideas???

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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

Re: adrdssu utility

[Vernooij, Kees (ITOP NM) - KLM]

A Mistake I made many times: you should not put filtlist names in quotes, only 
strings.
So in your routine, &HLQ is compared to the string '&FIST'
To compare &HLQ to the filtlist &FIST, you should code: (&HLQ EQ &FIST)

Met vriendelijke groet,
Kees Vernooij
KLM Information Services
z/OS Systems
Tel +31 6 10 14 58 78


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shelia Chalk
Sent: 25 March 2020 15:52
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: adrdssu utility

has anyone ever use adrdssu utility to restore a dataset from tape and rename 
then dataset. here is my problem  see jcl below
I am trying to use the sms routines.  I want the renameu dataset q2vo.slc.*** 
to go to a different volume  then the include dataset. in the sms routines I 
have   in the &fist I have in the filtlist the q2vo.** dataset..

 
IF ((&ACSENVIR EQ 'RECOVER') AND (&HLQ EQ '&FIST'))  
THEN 
  DO 
SET &STORCLAS = 'FIST'   
EXIT 
  END  

 

JCL I AM RUNNING

 //D2REST   EXEC PGM=ADRDSSU,REGION=8M  
//SYSPRINT DD SYSOUT=* 
//OUTDDDD UNIT=SYSDA,DISP=(NEW,CATLG,CATLG)
//INDD DD DSN=Q2SC.GN.GN.P010.GNTAPE.Q2BKUP(0),
//DISP=SHR 
//DUMMYDD   DUMMY  
//SYSINDD   *  
 RESTORE INDD(INDD) OUTDD(OUTDD) - 
DATASET( - 
INCLUDE(-  
Q2VO.GN.GN.P010.GNCDE.V -  
   ) - 
  ) -  
   RENAMEU((Q2VO.GN.GN.P010.GNCDE.V-   
Q2VO.SLC.**   )) - 
CANCELERROR -  
CATALOG -  
TGTGDS(ACTIVE)-
REPLACE-   
SHR SPHERE 



any ideas???

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: [EXTERNAL] adrdssu utility

[Gorham, Steve]

What results do you get with this?

Steve Gorham, Baltimore

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shelia Chalk
Sent: Wednesday, March 25, 2020 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] adrdssu utility

has anyone ever use adrdssu utility to restore a dataset from tape and rename 
then dataset. here is my problem  see jcl below
I am trying to use the sms routines.  I want the renameu dataset q2vo.slc.*** 
to go to a different volume  then the include dataset. in the sms routines I 
have   in the &fist I have in the filtlist the q2vo.** dataset..


IF ((&ACSENVIR EQ 'RECOVER') AND (&HLQ EQ '&FIST'))
THEN
  DO
SET &STORCLAS = 'FIST'
EXIT
  END



JCL I AM RUNNING

 //D2REST   EXEC PGM=ADRDSSU,REGION=8M
//SYSPRINT DD SYSOUT=*
//OUTDDDD UNIT=SYSDA,DISP=(NEW,CATLG,CATLG)
//INDD DD DSN=Q2SC.GN.GN.P010.GNTAPE.Q2BKUP(0),
//DISP=SHR
//DUMMYDD   DUMMY
//SYSINDD   *
 RESTORE INDD(INDD) OUTDD(OUTDD) -
DATASET( -
INCLUDE(-
Q2VO.GN.GN.P010.GNCDE.V -
   ) -
  ) -
   RENAMEU((Q2VO.GN.GN.P010.GNCDE.V-
Q2VO.SLC.**   )) -
CANCELERROR -
CATALOG -
TGTGDS(ACTIVE)-
REPLACE-
SHR SPHERE



any ideas???

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

adrdssu utility

[Shelia Chalk]

has anyone ever use adrdssu utility to restore a dataset from tape and rename 
then dataset. here is my problem  see jcl below
I am trying to use the sms routines.  I want the renameu dataset q2vo.slc.*** 
to go to a different volume  then the include dataset. in the sms routines I 
have   in the &fist I have in the filtlist the q2vo.** dataset..

 
IF ((&ACSENVIR EQ 'RECOVER') AND (&HLQ EQ '&FIST'))  
THEN 
  DO 
SET &STORCLAS = 'FIST'   
EXIT 
  END  

 

JCL I AM RUNNING

 //D2REST   EXEC PGM=ADRDSSU,REGION=8M  
//SYSPRINT DD SYSOUT=* 
//OUTDDDD UNIT=SYSDA,DISP=(NEW,CATLG,CATLG)
//INDD DD DSN=Q2SC.GN.GN.P010.GNTAPE.Q2BKUP(0),
//DISP=SHR 
//DUMMYDD   DUMMY  
//SYSINDD   *  
 RESTORE INDD(INDD) OUTDD(OUTDD) - 
DATASET( - 
INCLUDE(-  
Q2VO.GN.GN.P010.GNCDE.V -  
   ) - 
  ) -  
   RENAMEU((Q2VO.GN.GN.P010.GNCDE.V-   
Q2VO.SLC.**   )) - 
CANCELERROR -  
CATALOG -  
TGTGDS(ACTIVE)-
REPLACE-   
SHR SPHERE 



any ideas???

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

Re: REXX MVSVAR SYMDEF behavoiur

[Gerardo Toro]

First excuse my English it is so bad.

I put these sentences:

I = MVSVAR('SYMDEF','SYSNAME')  
j = MVSVAR('SYMDEF','sysplex')  
SAY 'Testing MVSVAR(SYMDEF,sysname)' i 'in sysplex ' j  

and I obtained this ...

Testing MVSVAR(SYMDEF,sysname) CHT8 in sysplex  PLEXDE  
*** 

It is useful or not?

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

Re: REXX MVSVAR SYMDEF behavoiur

[Jeremy Nicoll]

On Wed, 25 Mar 2020, at 09:43, Bruce Hewson wrote:
> Hi,
> 
> In a REXX exec I was building I stumbled onto:-
> 
> Say 'MVSVAR'("SYMDEF",'testing &sysname in &sysplex')
> 
> which provides an unexpected result 
> 
> &'TESTING SYSA IN PLEX01'.   
> 
> The symbols &SYSNAME and &SYSPLEX were replaced.
> And, sadly, the whole lot was uppercased.
> 
> Couldn't find this behaviour documented.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ikja300/mvsvarr.htm

seems to describe the MVSVAR("SYMDEF",string) 

call; string is first substituted by rexx ... which I guess would mean that
eg "testing" is replaced by the value of the symbol 'testing' which, if 
not set, is of course "TESTING"... then the mvs symbols are replaced.

(I think.  I've not done any of this for 20 years.)

-- 
Jeremy Nicoll - my opinions are my own.

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

Re: REXX MVSVAR SYMDEF behavoiur

[Seymour J Metz]

"The MVSVAR('SYMDEF',string) function goes through REXX substitution for string 
first, the result of which must be a 1-8 character symbolic-name specifying the 
symbol that has been defined in the SYMDEF statement. Any other values 
including REXX delimiters might cause unpredictable results."


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Bruce Hewson [bruce_hew...@hotmail.com]
Sent: Wednesday, March 25, 2020 5:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: REXX MVSVAR SYMDEF behavoiur

Hi,

In a REXX exec I was building I stumbled onto:-

Say 'MVSVAR'("SYMDEF",'testing &sysname in &sysplex')

which provides an unexpected result

&'TESTING SYSA IN PLEX01'.

The symbols &SYSNAME and &SYSPLEX were replaced.
And, sadly, the whole lot was uppercased.

Couldn't find this behaviour documented.

Regards
Bruce

--
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: OT: Mandatory Work From Home at my company

[Sebastian Welton]

I have one of these which I connect to a Windows 10 and an Ubuntu laptop and so 
far it works a dream. Has made my life so much easier.

Sebastian


On Mon, 23 Mar 2020 07:44:08 -0500, Steve Beaver  wrote:

>It will arrive here in a couple of days so I will let everyone know how well
>it does or not work
>
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>Behalf Of Bob Bridges
>Sent: Sunday, March 22, 2020 11:09 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: OT: Mandatory Work From Home at my company
>
>I'd be interested in hearing a quick review, Steve, once you've tried it out
>and have an opinion.  I don't know how serious I am about it, but it sounds
>convenient.
>
>---
>Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
>/* That sort of wit which employs itself insolently in criticizing and
>censuring the words and sentiments of others in conversation is absolute
>folly; for it answers none of the ends of conversation.  He who uses it
>neither improves others, is improved himself, nor pleases anyone.  -Poor
>Richard's Almanack, 1756 */
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>Behalf Of Steve Beaver
>Sent: Sunday, March 22, 2020 13:06
>
>I ordered the following from amazon
>
>   UGREEN USB 3.0 Sharing Switch Selector 4 Port 2 Computers Peripheral
>Switcher Adapter Hub for PC, Printer, Scanner, Mouse, Keyboard with One
>Button Sw
>
>--
>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: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64

[Peter Relson]

What services, IBM or ISV, nowadays can *not* be invoked:
o In AMODE 64?
o With parameters above-the-bar?
o Called from an address above-the-bar?


Surely the audience and OP know the answers to these question for IBM 
services
-- most
-- almost all
-- even closer to all.


when can programmers forget about 31 and 24?


Not in my lifetime.

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: GOTOs (was CLIST)

[David Crayford]

||

On 2020-03-25 12:34 AM, Seymour J Metz wrote:

It's much cleaner in PL/I than in REXX; ITERATE and LEAVE use labels rather 
than control variables.

FOO: DO I=1 TO N
...
ITERATE FOO
...
END
BAR: DO I=1 TO N
...
ITERATE BAR
...
END


That's just a GOTO with a mask on!

All the anti-goto rhetoric is dogmatic BS! We all know we should use 
structured constructs for loops like while/until etc. You're iterate example
is just a goto with a different name. Same with leave with labels. 
What's the difference?? They are probably considered better because to name

signifies intent but the action is the same as a goto.

In systems software languages that do not support RAII goto is almost 
always the best choice for error handling with cleanup code which is why

it is still widely used by (sensible) engineers.

I would challenge anybody to refactor this code without goto's.

https://github.com/eclipse/omr/blob/e9b85117d18c369108a9ddb790023103c35b4379/thread/common/omrthread.c#L246



Note that the two loops have the same control variable but the labels are 
different.


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



From: IBM Mainframe Discussion List  on behalf of Paul 
Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, March 24, 2020 11:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GOTOs (was CLIST)

(Thanks for changing the Subject:)
On Tue, 24 Mar 2020 11:19:16 -0400, Bob Bridges wrote:


There is such a thing as overdoing GOTOs, but I agree that a blanket 
never-do-it rule is counter-productive.  I don't often use SIGNAL in REXX, 
because I find that its structured features are adequate.  But in other 
languages I have argued for limited GOTO use.

In COBOL, for example, it seems to me that there's a place for GOTO 
TOP-OF-PARAGRAPH (to simulate ITERATE in REXX), GOTO EXIT-PARAGRAPH (to 
simulate LEAVE) and GOTO END-OF-PROGRAM (for controlled abend conditions).  
These don't violate structured-programming principles, they implement them.  In 
VBA I freely use Goto IterateSomething (putting the label just before the Next 
statement).  I don't think PL/1 ever needs it, but I'm glad it's there just in 
case.

Even in REXX there's one missing structured ingredient: some way to leave a 
~simple~ block.  A SELECT comes close, but it's not perfect.  Say you're 
looping through a list of candidates and have to perform a number of candidates:

  do jr=1 to stem.0
v0=stem.jr
if v0='' then iterate
v1=function1(v0)
if v1<5 then iterate
v2=functionv2(v1 + othervalue)
if v2=previous then iterate
say 'TRK:' v0 v1 v2
end


I almost always label ITERATE, LEAVE, and END for clarity and'
syntax error detection:

   do jr=1 to stem.0
 v0=stem.jr
 if v0='' then iterate  jr
 v1=function1(v0)
 if v1<5 then iterate  jr
 v2=functionv2(v1 + othervalue)
 if v2=previous then iterate  jr
 say 'TRK:' v0 v1 v2
 end  jr

(Even though it looks more like "GOTO jr".)


That's great in a controled DO loop.  But it's harder in simple block of code.  
A SELECT won't do the job, because of the calculations you have to do between 
the various tests.  I handle it this way:

  do 1
if v0='' then leave
v1=function1(v0)
if v1<5 then leave
v2=functionv2(v1+othervalue)
if v2=previous then leave
say 'TRK:' v0 v1 v2
end


Even at the cost of introducing an almost-otiose control variable:

   do myBlock= 0 for 1
 if v0='' then leave myBlock
 v1=function1(v0)
 if v1<5 then leave myBlock
 v2=functionv2(v1+othervalue)
 if v2=previous then leave myBlock
 say 'TRK:' v0 v1 v2
 end myBlock


I always suspect I'd get complaints from structured enthusiasts if they ever 
saw me cheating like that.  ...


Not from me.  Except for not using labels.

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


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

REXX MVSVAR SYMDEF behavoiur

[Bruce Hewson]

Hi,

In a REXX exec I was building I stumbled onto:-

Say 'MVSVAR'("SYMDEF",'testing &sysname in &sysplex')

which provides an unexpected result 

&'TESTING SYSA IN PLEX01'.   

The symbols &SYSNAME and &SYSPLEX were replaced.
And, sadly, the whole lot was uppercased.

Couldn't find this behaviour documented.

Regards
Bruce

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

Re: Problems with ESTAEX invoked in AMODE 64 when assembled without SYSTATE AMODE=64

[Binyamin Dissen]

On Tue, 24 Mar 2020 16:47:18 -0700 Ed Jaffe 
wrote:

:>On 3/24/2020 2:02 PM, Binyamin Dissen wrote:
:>> PC invoked? - pretty much anything. It really annoyed me that IBM trumpeted
:>> support for 64 bit callers for many services when the hardware did all the
:>> work.

:>Not true. In order for a service to officially support 64-bit callers, 
:>IBM must assign people to write test plans and validate every possible 
:>scenario. At a minimum, the macros and/or the code behind them must 
:>ensure garbage high-halves are not passed back in return registers.

My PC routines supported 64 bit callers on day 1.

:>Plus, most 64-bit callers expect to be able to pass parameters from 
:>their working storage areas (i.e., above the "bar"). Unchanged PCs hat 
:>are simply validated and nothing more will require special handling by 
:>64-bit callers to ensure all parameters reside in 31-bit storage. That's 
:>lame support at best. Full support implies new parameter lists that 
:>allow 8-byte pointers and such.

My comment was that many of the 64bit supported routines did not support 64
bit plists and thus 

--
Binyamin Dissen 
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.

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