Re: OSA vs HiperSockets

[Timothy Sipples]

Gadi Ben-Avi asked:
>Will it give better performance than Hypersockets?

Yes, for anything that can exploit SMC-D (which is anything sockets-based,
z/OS to z/OS).(*) If you go look at the presentation provided in the first
link on the Web page I referenced, on page 11, there's this statement from
IBM:

"SMC-D / ISM provides significantly improved performance benefits above
both [SMC-R and HiperSockets] within the CPC."

Pages 15 and 16 provide performance benchmark results. Latency, throughput,
and CPU efficiency are all improved, all by at least 4X% and in one case by
800%.

The presentation also explains the SMC Applicability Tool (SMCAT), a tool
that can help you assess what you currently have running on z/OS that can
exploit SMC-D (and SMC-R for that matter). More information on SMCAT is
available here:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halg001/rfssmcat.htm

Please note that SMCAT does not tell you what *could* be running (or could
be reconfigured) on z/OS that would *also* benefit. It just looks at the
status quo, so its report should be viewed as something of a minimum. Even
more/better might be possible.

SMC-D runs alongside HiperSockets, so it's not either-or. You use both,
together. And with OSA connectivity too, if you wish. Moreover, SMC-D is no
additional charge. All you've got to do is to configure it. Here are the
configuration steps in z/OS 2.2 (and also please refer to the parent
topics):

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halz002/smcd_steps_for_configuring.htm

It's really a no brainer. If SMCAT reports that you have more than
non-trivial potential for SMC exploitation, you should definitely turn it
on as reasonably expeditiously as you can.

At present, SMC-D is exclusively for z/OS to z/OS communication within the
same machine. In the future, SMC-D might extend to other operating systems
on the same machine, but I don't have any specific information about that.
SMC-R (RoCE Express) is optionally available for cross-machine
communications with z/OS and/or Linux, and I suppose you could use SMC-R
for communications within the same machine, too. (Whatever can cross
between machines doesn't necessarily have to. You can "loop back" if you
wish.)

(*) Notably this can include Enterprise Extender connections, z/OS to z/OS
on the same machine. The z/OS release levels need not be the same, as long
as you meet at least the minimum on both/all sides (z/OS 2.2 with SMC-D
PTFs, or higher; SMCAT is available for some earlier z/OS releases).


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: 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

Issue WTO message using MVS SEND command

[saurabh khandelwal]

Hello Group,


 /*  REXX */

'PIPE SAFE * | STEM MSG.'



TODataset = Word( Msg.3,3 )

mvs "send 'My console name is  "TODataset"',CN=CNDVMSTR"

exit


We used CN operand with send command to send message to  operator console
and now i receive output as required.

But this message is visible in green color which get disappeared as other
message comes on console.

But, I would like to have these message in white color ( not sure if we can
say as WTO), so that until operator intervention, these message will be on
console itself.


Can you please suggest, how can i achieve this

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

Re: Two new RFE's to consider supporting

[Paul Gilmartin]

On Thu, 21 Jun 2018 19:23:28 -0700, Ed Jaffe wrote:

>On 6/21/2018 6:47 PM, Phil Smith III wrote:
>
>That's funny! Of course, there is no such things as a "point and shoot"
>field in 3270! LOL!
>
>The notion of "point and shoot" hinges entirely on how the 3270
>application in question chooses to interpret the cursor position when an
>AID-generating key is pressed.
> 
Oops!  I had thought it referred to light pen (or emulated) awareness.

The OP/Requester seems to want to be able to tab to fields he deems
PAS while bypassing other writable fields.  Or vice-versa.  I agree this
is unlikely.  Use the mouse -- almost everyone has one.  Or design
panels more cleverly.

-- gil

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

Re: Two new RFE's to consider supporting

[Ed Jaffe]

On 6/21/2018 6:47 PM, Phil Smith III wrote:

Gil wrote:


Does 3270 protocol require that PAS fields be writable, therefore tabbable?
Bad design.  It's perfectly reasonable to want to specify a read-only PAS
menu item.  (Too few bits in the attribute byte?)
  
I've done lots of 3270 programming, but am unaware of what a point-and-shoot

field is. I don't remember any such bits in an attribute byte?


That's funny! Of course, there is no such things as a "point and shoot" 
field in 3270! LOL!


The notion of "point and shoot" hinges entirely on how the 3270 
application in question chooses to interpret the cursor position when an 
AID-generating key is pressed.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Using JCL Symbld and TYPRUN=SCAN

[Andrew Rowley]

On 22/06/2018 11:21 AM, Steve Smith wrote:
Why don't we just skip the JCL, and write our jobs in REXX?  The two 
main things JCL does, EXEC and DD, are just as easy in REXX, (call, 
alloc) with a ton more flexibility.  EXPORT, SET, IF, and symbols are 
lipstick for a pig.


I actually like JCL. One of the things it does so well that no-one even 
notices is allocation of resources.


In a previous job I tried to write scripts on a unix system to try to 
fix tasks that had a tendency to open one file and then wait for 
another, where multiple tasks were deadlocking. This is so simple with 
JCL because you don't get one allocation until you get them all.


The connection between program (DDNAME) and resources (dataset etc.) is 
nice too. In something like Rexx you need to pass the names as arguments 
(JCL is much better than one long command line) or hard code them.


--
Andrew Rowley
Black Hill Software
+61 413 302 386

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

Re: Two new RFE's to consider supporting

[Phil Smith III]

Gil wrote:

>Does 3270 protocol require that PAS fields be writable, therefore tabbable?
>Bad design.  It's perfectly reasonable to want to specify a read-only PAS
>menu item.  (Too few bits in the attribute byte?)

 

I've done lots of 3270 programming, but am unaware of what a point-and-shoot
field is. I don't remember any such bits in an attribute byte?


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

Re: Using JCL Symbld and TYPRUN=SCAN

[Paul Gilmartin]

On Thu, 21 Jun 2018 21:21:56 -0400, Steve Smith wrote:

>My only point was the SET wasn't needed the way I used symbols.  It's
>hardly any big deal if it's needed for  library PROCs.  The fact that
>there doesn't seem to be any obvious logical reason for it, is just one
>of things you take for granted with JCL.
>
Not logical, but diachronic.

>Why don't we just skip the JCL, and write our jobs in REXX?  The two
>main things JCL does, EXEC and DD, are just as easy in REXX, (call,
>alloc) with a ton more flexibility.  EXPORT, SET, IF, and symbols are
>lipstick for a pig.
>
(I use LINKMVS and BPXWDYN.  No need for TSO.)
What Rexx lacks is the multiple ENQ with S99WTDSN that prevents
deadlocks.  I could imagine this as an enhancement to BPXWDYN.

>All you must keep in JCL is the JOB card, and a standard EXEC PGM=IRXJCL
>+ SYSEXEC DD.  Everything else you can code in an actual programming
>language.
>
IRXJCL lacks support for //SYSEXEC DD *.  You need at least an IEBUPDTE
step to create a (temporary) SYSEXEC PDS.  (There's an unsupported
workaround.)

>JCL is fun as a puzzle-solving activity (sometimes), but for busy people
>trying to get their work done, it's been a black cloud since 1964.  Even
>Fred P. Brooks said he didn't like it.
> 
Ipse dixit.

-- gil

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

Re: Two new RFE's to consider supporting

[Paul Gilmartin]

On Thu, 21 Jun 2018 19:08:53 +, Dyck, Lionel B. (RavenTek) wrote:

>Please consider supporting these RFE's that I just submitted:
>
>ISPF Point and Shoot Protected Fields
>
>https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=121576


On Thu, 21 Jun 2018 18:13:21 -0400, Phil Smith III wrote:
 
>Steve Smith wrote:
>
>>Isn't #1 impossible?  From what I've retained (or think I have) of 3270
>>programming, a "tab" is merely the start of an unprotected field.
>Catch-22.
>
>Correct. You cannot tab to a protected field. And I suspect that a request
>for an update to the 3270 protocol is not likely to be fulfilled at this
>point.
>
Reading the RFE, it appears that the submitter does not want to be able to
tab to a PAS field; rather he wants to be able to define a PAS field that
will be skipped by tab.

Does 3270 protocol require that PAS fields be writable, therefore tabbable?
Bad design.  It's perfectly reasonable to want to specify a read-only PAS
menu item.  (Too few bits in the attribute byte?)

I believe many emulators nowadays interpret double-click as "shoot".  Or
provide "shoot" as a pop-up selection.

Long ago, I tried to specify a single-cell PAS field.  The host application 
rejected
this, claiming that a light pen can not resolve a single cell.  Bad Lowest 
Common
Denominator design.  The application should support a possibly hi-res light pen
or other PAS device.

-- gil

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

Re: Using JCL Symbld and TYPRUN=SCAN

[Steve Smith]

My only point was the SET wasn't needed the way I used symbols.  It's 
hardly any big deal if it's needed for  library PROCs.  The fact that 
there doesn't seem to be any obvious logical reason for it, is just one 
of things you take for granted with JCL.


Why don't we just skip the JCL, and write our jobs in REXX?  The two 
main things JCL does, EXEC and DD, are just as easy in REXX, (call, 
alloc) with a ton more flexibility.  EXPORT, SET, IF, and symbols are 
lipstick for a pig.


All you must keep in JCL is the JOB card, and a standard EXEC PGM=IRXJCL 
+ SYSEXEC DD.  Everything else you can code in an actual programming 
language.


JCL is fun as a puzzle-solving activity (sometimes), but for busy people 
trying to get their work done, it's been a black cloud since 1964.  Even 
Fred P. Brooks said he didn't like it.


sas


On 6/21/2018 20:50, Paul Gilmartin wrote:

On Fri, 22 Jun 2018 10:34:54 +1000, Andrew Rowley 
 wrote:


On 21/06/2018 11:05 PM, Steve Smith wrote:

I've gotten good results with the EXPORT before the PROC

Which means the EXPORT needs to be in the calling job, not the PROC. My
examples used inline PROCs for convenience, but I was trying to do it
with a PROC in a PROCLIB. If the EXPORT needs to be before the PROC, the
job needs to know exactly which variables the PROC needs exported, which
negates some of the convenience of abstracting stuff into a PROC.


Does it not suffice to code EXPORT before SET, but in the PROC?
(But then are symbols exported to open code, outside the PROC?)


The best solution seems to be SET VAR= in the PROC.


Hardly practical if the vaue of VAR contains metacharacters.  JCL
sorely needs HLASM's DOUBLE BIF.

-- 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: Using JCL Symbld and TYPRUN=SCAN

[Paul Gilmartin]

On Fri, 22 Jun 2018 10:34:54 +1000, Andrew Rowley 
 wrote:

>On 21/06/2018 11:05 PM, Steve Smith wrote:
>> I've gotten good results with the EXPORT before the PROC
>
>Which means the EXPORT needs to be in the calling job, not the PROC. My
>examples used inline PROCs for convenience, but I was trying to do it
>with a PROC in a PROCLIB. If the EXPORT needs to be before the PROC, the
>job needs to know exactly which variables the PROC needs exported, which
>negates some of the convenience of abstracting stuff into a PROC.
> 
Does it not suffice to code EXPORT before SET, but in the PROC?
(But then are symbols exported to open code, outside the PROC?)

>The best solution seems to be SET VAR= in the PROC.
> 
Hardly practical if the vaue of VAR contains metacharacters.  JCL
sorely needs HLASM's DOUBLE BIF.

-- gil

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

Re: Using JCL Symbld and TYPRUN=SCAN

[Andrew Rowley]

On 21/06/2018 11:05 PM, Steve Smith wrote:

I've gotten good results with the EXPORT before the PROC


Which means the EXPORT needs to be in the calling job, not the PROC. My 
examples used inline PROCs for convenience, but I was trying to do it 
with a PROC in a PROCLIB. If the EXPORT needs to be before the PROC, the 
job needs to know exactly which variables the PROC needs exported, which 
negates some of the convenience of abstracting stuff into a PROC.


The best solution seems to be SET VAR= in the PROC.

--
Andrew Rowley
Black Hill Software
+61 413 302 386

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

Re: Two new RFE's to consider supporting

[Paul Gilmartin]

On Thu, 21 Jun 2018 19:08:53 +, Dyck, Lionel B. (RavenTek) wrote:

>Please consider supporting these RFE's that I just submitted:
>
>ISPF Point and Shoot Protected Fields
>
>https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=121576
> 
No need to change the sematics of .  Use mouse (or on a real 3270, arrow
keys) to "point" to field in question, then press the PF key assigned to 
"shoot".
All in software.

>And
>
>Improve ISPF 3.17 by allowing CD on the command line
>
>https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=121575
> 
Yes.  I have come close to this with a Rexx/Macro that issues SYSCALL chdir.
After that, ISPF 3.17 (admirably) interprets "." as the directory I chdired to.

-- gil

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

Re: Two new RFE's to consider supporting

[Phil Smith III]

Steve Smith wrote:

>Isn't #1 impossible?  From what I've retained (or think I have) of 3270
>programming, a "tab" is merely the start of an unprotected field.
Catch-22.

 

Correct. You cannot tab to a protected field. And I suspect that a request
for an update to the 3270 protocol is not likely to be fulfilled at this
point.

-- 

...phsiii

 

Phil Smith III
Senior Architect & Product Manager, Mainframe & Enterprise

Distinguished Technologist
Micro Focus (Voltage)

 


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

PDS with 1 directory block

[Jesse 1 Robinson]

We recently got a corrupted PO data set after using the PDS command to add 
directory blocks. During the FIXPDS operation we were prompted to move members 
to make room for additional directory blocks. SOP. We have done this so often 
for such a long time that we didn't hesitate. Afterwards, however, the PDS was 
unusable. The only unusual thing about this PDS was that it was created (per 
ISV JCL) with only 1 directory block.

I have a dim memory of learning ages ago that a PDS with 1 directory block is 
somehow 'different', that certain updates to it require fiddling with the VTOC 
in addition to changing data on a track. Sound familiar?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office <= NEW
robin...@sce.com


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

Re: 2 possible RFE --- ISPF & SDSF.

[Steve Smith]

I believe JCL's set of "allowable" characters is only a fraction of any
code page.  And probably only common code points.

sas

On Thu, Jun 21, 2018 at 3:12 PM, John McKown 
wrote:

> On Thu, Jun 21, 2018 at 1:57 PM Steve Smith  wrote:
>
> > "... a sequence of 80-byte characters. ".  Is that UTF-640 for true
> > Universe-al support?
> >
> >
> ​If I were a betting man, I'd give 1000:1 odds that JCL must be written in
> CP-037 only, any non-CP027 characters would need to be in ' marks, like a
> PARM= string, or it is JCL ERROR time.​
>

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

Re: ARC0104I INVALID INITIALIZATION COMMAND

[Gibney, Dave]

I have both LOG and PDA files. Never needed them, but the recomenadtion was to 
have them active for IBM if needed.

DFHSM.LOGX
DFHSM.LOGY

DFHSM.PDOX
DFHSM.PDOY


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Jaffe
> Sent: Thursday, June 21, 2018 2:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ARC0104I INVALID INITIALIZATION COMMAND
> 
> On 6/21/2018 2:17 PM, Gibney, Dave wrote:
> > Looking some more and remembering. Do you have the HSM PDA
> (Problem Determination AID) active?  SETSYS PDS() and a couple datasets.
> > I have a vague memory that this data can also be found using IPCS against
> the active region. Or something.
> 
> Yes. I posted some of that data in response to Carmen Vitullo's query.
> No help whatsoever...
> 
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.phoenixsoftware.com_=DwICaQ=C3yme8gMkxg_ihJNXS06Z
> yWk4EJm8LdrrvxQb-Je7sw=u9g8rUevBoyCPAdo5sWE9w=CK-
> VATOToJANlm1EWo7JHmZyFP9PKP4GGqo_6Zp6bWs=z41wqfPdr4WHaTk
> DTu98jbwgbpdwIkUakMf_lDfl6s8=
> 
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise received
> this email message in error, any use, dissemination, distribution, review,
> storage or copying of this e-mail message and the information contained
> therein is strictly prohibited. If you are not an intended recipient, please
> contact the sender by reply e-mail and destroy all copies of this email
> message and do not otherwise utilize or retain this email message or any or
> all of the information contained therein. Although this email message and any
> attachments or appended messages are believed to be free of any virus or
> other defect that might affect any computer system into which it is received
> and opened, it is the responsibility of the recipient to ensure that it is 
> virus
> free and no responsibility is accepted by the sender for any loss or damage
> arising in any way from its opening or use.
> 
> --
> 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: Two new RFE's to consider supporting

[Steve Smith]

Isn't #1 impossible?  From what I've retained (or think I have) of 3270
programming, a "tab" is merely the start of an unprotected field.  Catch-22.

sas

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

Re: ARC0104I INVALID INITIALIZATION COMMAND

[Ed Jaffe]

On 6/21/2018 2:17 PM, Gibney, Dave wrote:

Looking some more and remembering. Do you have the HSM PDA (Problem 
Determination AID) active?  SETSYS PDS() and a couple datasets.
I have a vague memory that this data can also be found using IPCS against the 
active region. Or something.


Yes. I posted some of that data in response to Carmen Vitullo's query. 
No help whatsoever...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: ARC0104I INVALID INITIALIZATION COMMAND

[Gibney, Dave]

Looking some more and remembering. Do you have the HSM PDA (Problem 
Determination AID) active?  SETSYS PDS() and a couple datasets.
I have a vague memory that this data can also be found using IPCS against the 
active region. Or something.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jesse 1 Robinson
> Sent: Thursday, June 21, 2018 2:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ARC0104I INVALID INITIALIZATION COMMAND
> 
> I'd say that this is such an egregious oversight that it should be APARable
> even after all this time. There's no statute of limitations on bad design.
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gibney, Dave
> Sent: Thursday, June 21, 2018 1:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: ARC0104I INVALID INITIALIZATION COMMAND
> 
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Ed Jaffe
> > Sent: Thursday, June 21, 2018 1:41 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: ARC0104I INVALID INITIALIZATION COMMAND
> >
> > On 6/21/2018 11:59 AM, Gibney, Dave wrote:
> > > I expected as much. Another possibility is to insert some LOG
> > > commands into your ARCCMD00 perhaps even as frequently as to echo
> > > each SETSYS
> >
> > I thought we could try something like that, but it seems that some (or
> > maybe
> > all?) of the commands are being executed asynchronously. Plus, I'm not
> > sure what kind of "log" commands are available in the ARCCMDxx member.
> > Do you know?
> 
> I've not found a command I couldn't include in ARCCMDxx, but I admit I've
> not tried many. I didn't know about the aysnc possibility, but I guess I'm not
> surprised DFHSM has been "mulit threaded"  from the start.
> 
> I am sorry, I can't remember the last time I had an error to find here. Once
> set, this is not a frequently changing member :)
> 
> My last thought now is a tedious hand comparison against the results of a
> QUERY SETSYS
> 
> >
> > I'm truly astonished that this problem exists in the first place and
> > -- based on responses I've seen so far -- has been around from the
> > beginning. Should not the error message include the first 'n'
> > characters of command text and/or line number in the input "deck"? The
> > whole thing is crazy! No one has complained to IBM about this serious
> shortcoming before now?!
> >
> > --
> > Phoenix Software International
> > Edward E. Jaffe
> > 831 Parkview Drive North
> > El Segundo, CA 90245
> 
> --
> 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: ARC0104I INVALID INITIALIZATION COMMAND

[Ed Jaffe]

On 6/21/2018 11:00 AM, Ed Jaffe wrote:
I recently noticed we're receiving the following (maybe three times) 
on the MVS log during HSM startup:


ARC0104I INVALID INITIALIZATION COMMAND


Found them! How? Via manual inspection! (HSM facilities were no help AT 
ALL...)


I used ISPF highlighting with "HILITE PLI LOGIC PAREN" and discovered a 
colorized paren mismatch situation.


Turns out the last (continued) part of an ADDVOL statement was repeated 
unnecessarily and then cloned to two other nearly-identical non-SMS 
volume definitions.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: The 'Baby' that ushered in modern computer age - BBC News

[Mike Schwab]

1,000 instructions per second times 20 to 30 million times faster is
20 to 30 GHz for a modern laptop?  They got an extra zero in there.
On Thu, Jun 21, 2018 at 3:26 PM Mark Regan  wrote:
>
> Just FYI...
>
> https://www.bbc.com/news/science-environment-44554891
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Would SHARE kindly kick IBM in the ass for what the've done with their web content?

[Mike Hochee]

Hi Sue, 

It is working again now,  and I'm noticing an updated look and feel with the 
2.2 Elements and Features page.  In my previous attempts, I opened new z.OS 2.2 
Elements and Features tabs. This time however, I shutdown all tabs and 
restarted the browser.  Regardless, it's working - Thank you. 

Mike 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Susan Shumway
Sent: Thursday, June 21, 2018 4:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would SHARE kindly kick IBM in the ass for what the've done with 
their web content?

Hi Mike,

I'm unable to replicate your problem. Please contact me directly and we can try 
to get to the bottom of it. Thanks!

-Sue Shumway

On 06/21/18 3:47 PM, Mike Hochee wrote:
> Yes, extremely well stated, and timely too!.
> 
> Ironically, it looks like the z/OS 2.2 Elements and Features pdf link 
> https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosv2r2-pdf-download?OpenDocument
>  now points at numerous z/OS 2.1 manuals.  I don't know how extensive the 
> problem is, but all the manuals I checked under the z/OS MVS and RMF sections 
> were 2.1 manuals.  Oh well!
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of zMan
> Sent: Thursday, June 21, 2018 2:30 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Would SHARE kindly kick IBM in the ass for what the've done with 
> their web content?
> 
> Good article, of course, Cheryl.
> 
> The one thing it didn't mention is that maintenance of these sites is being 
> moved overseas. That's not inherently bad, except that it inevitably leads to 
> a loss of tribal knowledge, which may be how these huge omissions occurred.
> 
> On Thu, Jun 21, 2018 at 1:06 PM, Chuck Kreiter 
> 
> wrote:
> 
>> I was shocked when this article showed up on my front page on Reddit.
>> Perfectly stated!
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On Behalf Of Cheryl Watson
>> Sent: Thursday, June 21, 2018 10:42 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Would SHARE kindly kick IBM in the ass for what the've 
>> done with their web content?
>>
>> Here's our take on this issue -
>>
>> http://watsonwalker.com/what-is-happening-with-ibms-websites/
>>
>> All my best,
>> Cheryl
>>
>> ===
>> Cheryl Watson
>> Watson & Walker, Inc.
>> www.watsonwalker.com
>> ===
>>
>> -
>> - 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
>>
> 
> 
> 
> --
> zMan -- "I've got a mainframe and I'm not afraid to use it"
> 
> --
> 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
> 

--
Sue Shumway
z/OS Product Documentation Lead
IBM Poughkeepsie
chale...@us.ibm.com

--
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: ARC0104I INVALID INITIALIZATION COMMAND

[Jesse 1 Robinson]

I'd say that this is such an egregious oversight that it should be APARable 
even after all this time. There's no statute of limitations on bad design. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, Dave
Sent: Thursday, June 21, 2018 1:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: ARC0104I INVALID INITIALIZATION COMMAND



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Ed Jaffe
> Sent: Thursday, June 21, 2018 1:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ARC0104I INVALID INITIALIZATION COMMAND
> 
> On 6/21/2018 11:59 AM, Gibney, Dave wrote:
> > I expected as much. Another possibility is to insert some LOG 
> > commands into your ARCCMD00 perhaps even as frequently as to echo 
> > each SETSYS
> 
> I thought we could try something like that, but it seems that some (or 
> maybe
> all?) of the commands are being executed asynchronously. Plus, I'm not 
> sure what kind of "log" commands are available in the ARCCMDxx member. 
> Do you know?

I've not found a command I couldn't include in ARCCMDxx, but I admit I've not 
tried many. I didn't know about the aysnc possibility, but I guess I'm not 
surprised DFHSM has been "mulit threaded"  from the start.

I am sorry, I can't remember the last time I had an error to find here. Once 
set, this is not a frequently changing member :)

My last thought now is a tedious hand comparison against the results of a QUERY 
SETSYS

> 
> I'm truly astonished that this problem exists in the first place and 
> -- based on responses I've seen so far -- has been around from the 
> beginning. Should not the error message include the first 'n' 
> characters of command text and/or line number in the input "deck"? The 
> whole thing is crazy! No one has complained to IBM about this serious 
> shortcoming before now?!
> 
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245

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

Re: IBM shuffles mainframe docs leaving customers crying 'sabotage' • The Register

[Charles Mills]

SHARE may not have kicked any @ss, but Cheryl got noticed.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Regan
Sent: Thursday, June 21, 2018 1:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fwd: IBM shuffles mainframe docs leaving customers crying 'sabotage' • 
The Register

https://www.theregister.co.uk/2018/06/21/ibm_mainframe_docs/

--
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: Would SHARE kindly kick IBM in the ass for what the've done with their web content?

[Susan Shumway]

Hi Mike,

I'm unable to replicate your problem. Please contact me directly and we 
can try to get to the bottom of it. Thanks!


-Sue Shumway

On 06/21/18 3:47 PM, Mike Hochee wrote:

Yes, extremely well stated, and timely too!.

Ironically, it looks like the z/OS 2.2 Elements and Features pdf link 
https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosv2r2-pdf-download?OpenDocument
 now points at numerous z/OS 2.1 manuals.  I don't know how extensive the 
problem is, but all the manuals I checked under the z/OS MVS and RMF sections 
were 2.1 manuals.  Oh well!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of zMan
Sent: Thursday, June 21, 2018 2:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would SHARE kindly kick IBM in the ass for what the've done with 
their web content?

Good article, of course, Cheryl.

The one thing it didn't mention is that maintenance of these sites is being 
moved overseas. That's not inherently bad, except that it inevitably leads to a 
loss of tribal knowledge, which may be how these huge omissions occurred.

On Thu, Jun 21, 2018 at 1:06 PM, Chuck Kreiter 
wrote:


I was shocked when this article showed up on my front page on Reddit.
Perfectly stated!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Cheryl Watson
Sent: Thursday, June 21, 2018 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would SHARE kindly kick IBM in the ass for what the've
done with their web content?

Here's our take on this issue -

http://watsonwalker.com/what-is-happening-with-ibms-websites/

All my best,
Cheryl

===
Cheryl Watson
Watson & Walker, Inc.
www.watsonwalker.com
===

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





--
zMan -- "I've got a mainframe and I'm not afraid to use it"

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



--
Sue Shumway
z/OS Product Documentation Lead
IBM Poughkeepsie
chale...@us.ibm.com

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

Re: ARC0104I INVALID INITIALIZATION COMMAND

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Jaffe
> Sent: Thursday, June 21, 2018 1:41 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ARC0104I INVALID INITIALIZATION COMMAND
> 
> On 6/21/2018 11:59 AM, Gibney, Dave wrote:
> > I expected as much. Another possibility is to insert some LOG commands
> > into your ARCCMD00 perhaps even as frequently as to echo each SETSYS
> 
> I thought we could try something like that, but it seems that some (or maybe
> all?) of the commands are being executed asynchronously. Plus, I'm not sure
> what kind of "log" commands are available in the ARCCMDxx member. Do
> you know?

I've not found a command I couldn't include in ARCCMDxx, but I admit I've not 
tried many. I didn't know about the aysnc possibility, but I guess I'm not 
surprised DFHSM has been "mulit threaded"  from the start.

I am sorry, I can't remember the last time I had an error to find here. Once 
set, this is not a frequently changing member :)

My last thought now is a tedious hand comparison against the results of a QUERY 
SETSYS

> 
> I'm truly astonished that this problem exists in the first place and -- based 
> on
> responses I've seen so far -- has been around from the beginning. Should not
> the error message include the first 'n' characters of command text and/or
> line number in the input "deck"? The whole thing is crazy! No one has
> complained to IBM about this serious shortcoming before now?!
> 
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.phoenixsoftware.com_=DwICaQ=C3yme8gMkxg_ihJNXS06Z
> yWk4EJm8LdrrvxQb-
> Je7sw=u9g8rUevBoyCPAdo5sWE9w=6HHwIpeS03fXGc0-
> 6ZMywYq4ZlEvs6LnH6mTp0zX4Bo=I4PoX6uvRkUi-frBbIOv8-
> 0sgKN8HSbUYQpch5F7H84=
> 
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise received
> this email message in error, any use, dissemination, distribution, review,
> storage or copying of this e-mail message and the information contained
> therein is strictly prohibited. If you are not an intended recipient, please
> contact the sender by reply e-mail and destroy all copies of this email
> message and do not otherwise utilize or retain this email message or any or
> all of the information contained therein. Although this email message and any
> attachments or appended messages are believed to be free of any virus or
> other defect that might affect any computer system into which it is received
> and opened, it is the responsibility of the recipient to ensure that it is 
> virus
> free and no responsibility is accepted by the sender for any loss or damage
> arising in any way from its opening or use.
> 
> --
> 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

Fwd: IBM shuffles mainframe docs leaving customers crying 'sabotage' • The Register

[Mark Regan]

https://www.theregister.co.uk/2018/06/21/ibm_mainframe_docs/

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

Re: ARC0104I INVALID INITIALIZATION COMMAND

[Ed Jaffe]

On 6/21/2018 12:14 PM, John McKown wrote:


​How about just issuing each HSM command in the member as an operator
command, perhaps via (E)JES?​


That's a thought, but what a *major* PITA. Most of our commands are 
split across multiple lines with /* xxx */ comments interspersed. It 
will be very time consuming to edit them all down to a single line each. 
However, once that's done, I agree we should be able to issue them via 
TSO HSEND or MODIFY operator command.


As I said in my response to Dave Gibney, I'm truly astonished this 
problem exists in the first place and has been around for so long!



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: ARC0104I INVALID INITIALIZATION COMMAND

[Ed Jaffe]

On 6/21/2018 11:59 AM, Gibney, Dave wrote:

I expected as much. Another possibility is to insert some LOG commands into 
your ARCCMD00 perhaps even as frequently as to echo each SETSYS


I thought we could try something like that, but it seems that some (or 
maybe all?) of the commands are being executed asynchronously. Plus, I'm 
not sure what kind of "log" commands are available in the ARCCMDxx 
member. Do you know?


I'm truly astonished that this problem exists in the first place and -- 
based on responses I've seen so far -- has been around from the 
beginning. Should not the error message include the first 'n' characters 
of command text and/or line number in the input "deck"? The whole thing 
is crazy! No one has complained to IBM about this serious shortcoming 
before now?!


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Fwd: The 'Baby' that ushered in modern computer age - BBC News

[Mark Regan]

Just FYI...

https://www.bbc.com/news/science-environment-44554891

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

Re: Application-mode use of TRAPping instructions

[David Cole]

Bernd Oppolzer  wrote:

At a site where I was working some years ago we had a site specific 
debugging tool which inserted break points into test objects (= load 
modules) by changing certain instruction's opcodes to hex zero, then 
catching the resulting 0C1 interrupts and this way tracking the 
execution of certain branches of the test object (of course, the 
debugger had to restore the correct opcodes after the 0C1 and resume 
execution ... at the next break point, the hex zero was inserted 
again and so on ...)


[snip]

I proposed to use TRAP instead.





FWIW, the current maintenance level of z/XDC allows setting 
breakpoints either via X'00' "opcodes" or via TRAP2 instructions. I 
wrote some articles about it at www.xdc.com.


Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware

Tools:   z/XDC for Assembler debugging
 c/XDC for C debugging






At 6/20/2018 05:11 PM, Bernd Oppolzer wrote:

Am 19.06.2018 um 22:18 schrieb Farley, Peter x23353:
The recent discussion about the ability (or not) of setting R14 
values in dbx at a break point while debugging brought me back to 
an old and (for me) somewhat sore subject.


The z/Architecture hardware designers graced us with TRAP and TRAP4 
and then with compare-and-trap instructions in the hardware.


z/OS has yet to provide ordinary application-mode programmers (or 
for that matter compiler and debugger writers) with the tools to 
use these hardware features.  Because updates to the DUCT are 
needed to properly utilize the TRAP features, only supervisor-state 
code (and therefore only APF-authorized code) can use these 
facilities in current z/OS versions, leaving ordinary application 
programmers with no way to use any of these hardware features..


When will z/OS provide application programmers (and others) the 
tools to utilize TRAP and friends?


Inquiring minds would love to know.

Peter


At a site where I was working some years ago we had a
site specific debugging tool which inserted break points into
test objects (= load modules) by changing certain instruction's opcodes
to hex zero, then catching the resulting 0C1 interrupts and this way
tracking the execution of certain branches of the test object (of course,
the debugger had to restore the correct opcodes after the 0C1 and resume
execution ... at the next break point, the hex zero was inserted 
again and so on ...)


This worked, but because recovery from the 0C1 had to be executed for every
breakpoint, it was slow ... and there were many breakpoints ... at 
every IF and

every LOOP.

I proposed to use TRAP instead. The problem was indeed the update of the DUCT,
which had to be done by privileged code. To do this, one of our 
friendly system
programmers installed a site specific SVC for us, which allowed us 
to do just this ...

modify the DUCT. Using this SVC, is was no problem to insert the breakpoints
as TRAP instructions instead of hex zeroes (two bytes to modify 
instead of one)
and to control the debugger using a TRAP handler instead of recovery 
from a 0C1 abend.


BTW: when first testing this, we used another SVC which was present 
on our systems
at this time, allowing an arbitrary user program to write into 
protected storage. At one
point during testing, some of our programmers used this incorrectly 
and wrote into

address zero, which caused the whole system to halt :-)

This convinced our systems people

a) that this SVC had to be removed and
b) it would be much better to give us a facility to ONLY update the DUCT

Kind regards

Bernd

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


Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware

Tools:   z/XDC for Assembler debugging
 c/XDC 
for C debugging  


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

Re: Would SHARE kindly kick IBM in the ass for what the've done with their web content?

[Mike Hochee]

Yes, extremely well stated, and timely too!.  

Ironically, it looks like the z/OS 2.2 Elements and Features pdf link 
https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zosv2r2-pdf-download?OpenDocument
 now points at numerous z/OS 2.1 manuals.  I don't know how extensive the 
problem is, but all the manuals I checked under the z/OS MVS and RMF sections 
were 2.1 manuals.  Oh well!  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of zMan
Sent: Thursday, June 21, 2018 2:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would SHARE kindly kick IBM in the ass for what the've done with 
their web content?

Good article, of course, Cheryl.

The one thing it didn't mention is that maintenance of these sites is being 
moved overseas. That's not inherently bad, except that it inevitably leads to a 
loss of tribal knowledge, which may be how these huge omissions occurred.

On Thu, Jun 21, 2018 at 1:06 PM, Chuck Kreiter 
wrote:

> I was shocked when this article showed up on my front page on Reddit.
> Perfectly stated!
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Cheryl Watson
> Sent: Thursday, June 21, 2018 10:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Would SHARE kindly kick IBM in the ass for what the've 
> done with their web content?
>
> Here's our take on this issue -
>
> http://watsonwalker.com/what-is-happening-with-ibms-websites/
>
> All my best,
> Cheryl
>
> ===
> Cheryl Watson
> Watson & Walker, Inc.
> www.watsonwalker.com
> ===
>
> --
> 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
>



--
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
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: ARC0104I INVALID INITIALIZATION COMMAND

[John McKown]

On Thu, Jun 21, 2018 at 1:53 PM Ed Jaffe 
wrote:

> On 6/21/2018 11:35 AM, Gibney, Dave wrote:
> > What is your SETSYS ACTLOGMSGLVL?
>
> That parameter is not relevant here. I did have ACTLOGMSGLVL(REDUCED)
> so, just to prove the point, I changed it to ACTLOGMSGLVL(FULL) and
> recycled HSM. No difference...
>

​How about just issuing each HSM command in the member as an operator
command, perhaps via (E)JES?​



>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/
>
>
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to be
> free of any virus or other defect that might affect any computer system
> into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
There is no such thing as the Cloud. It is just somebody else’s computer.

Maranatha! <><
John McKown

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

Re: 2 possible RFE --- ISPF & SDSF.

[John McKown]

On Thu, Jun 21, 2018 at 1:57 PM Steve Smith  wrote:

> "... a sequence of 80-byte characters. ".  Is that UTF-640 for true
> Universe-al support?
>
>
​If I were a betting man, I'd give 1000:1 odds that JCL must be written in
CP-037 only, any non-CP027 characters would need to be in ' marks, like a
PARM= string, or it is JCL ERROR time.​



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


-- 
There is no such thing as the Cloud. It is just somebody else’s computer.

Maranatha! <><
John McKown

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

Two new RFE's to consider supporting

[Dyck, Lionel B. (RavenTek)]

Please consider supporting these RFE's that I just submitted:

ISPF Point and Shoot Protected Fields

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=121576

And

Improve ISPF 3.17 by allowing CD on the command line

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=121575


--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer - RavenTek Solution Partners


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

Re: ARC0104I INVALID INITIALIZATION COMMAND

[Gibney, Dave]

I expected as much. Another possibility is to insert some LOG commands into 
your ARCCMD00 perhaps even as frequently as to echo each SETSYS

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Jaffe
> Sent: Thursday, June 21, 2018 11:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ARC0104I INVALID INITIALIZATION COMMAND
> 
> On 6/21/2018 11:35 AM, Gibney, Dave wrote:
> > What is your SETSYS ACTLOGMSGLVL?
> 
> That parameter is not relevant here. I did have ACTLOGMSGLVL(REDUCED)
> so, just to prove the point, I changed it to ACTLOGMSGLVL(FULL) and
> recycled HSM. No difference...
> 
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.phoenixsoftware.com_=DwICaQ=C3yme8gMkxg_ihJNXS06Z
> yWk4EJm8LdrrvxQb-Je7sw=u9g8rUevBoyCPAdo5sWE9w=loznVd5jmn-
> XnGsBIQGaS3Ub2q_W9GRtuansIHKm6jE=2t2SEy0hVfBzXP3I-
> 1rB13WKV0pydxdIT7qT4VTW3X8=
> 
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise received
> this email message in error, any use, dissemination, distribution, review,
> storage or copying of this e-mail message and the information contained
> therein is strictly prohibited. If you are not an intended recipient, please
> contact the sender by reply e-mail and destroy all copies of this email
> message and do not otherwise utilize or retain this email message or any or
> all of the information contained therein. Although this email message and any
> attachments or appended messages are believed to be free of any virus or
> other defect that might affect any computer system into which it is received
> and opened, it is the responsibility of the recipient to ensure that it is 
> virus
> free and no responsibility is accepted by the sender for any loss or damage
> arising in any way from its opening or use.
> 
> --
> 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: 2 possible RFE --- ISPF & SDSF.

[Steve Smith]

"... a sequence of 80-byte characters. ".  Is that UTF-640 for true
Universe-al support?

sas

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

Re: ARC0104I INVALID INITIALIZATION COMMAND

[Ed Jaffe]

On 6/21/2018 11:35 AM, Gibney, Dave wrote:

What is your SETSYS ACTLOGMSGLVL?


That parameter is not relevant here. I did have ACTLOGMSGLVL(REDUCED) 
so, just to prove the point, I changed it to ACTLOGMSGLVL(FULL) and 
recycled HSM. No difference...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: ARC0104I INVALID INITIALIZATION COMMAND

[retired mainframer]

Back when I had this issue, my only choice was to count responses and then 
count commands.  Some of the commands had relatively unique responses which 
assisted in synching my counts.  Based on your question, it appears that newer 
versions of HSM don't provide any additional information.

If you have the time and a sandbox LPAR, you could start HSM with only the 
first 10 commands and look for the error.  Then add 10 more in each iteration.  
This will reduce the span of commands to be checked.

> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Ed Jaffe
> Sent: Thursday, June 21, 2018 11:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ARC0104I INVALID INITIALIZATION COMMAND
> 
> I recently noticed we're receiving the following (maybe three times) on
> the MVS log during HSM startup:
> 
> ARC0104I INVALID INITIALIZATION COMMAND

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

Re: ARC0104I INVALID INITIALIZATION COMMAND

[Gibney, Dave]

What is your SETSYS ACTLOGMSGLVL?

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Jaffe
> Sent: Thursday, June 21, 2018 11:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: ARC0104I INVALID INITIALIZATION COMMAND
> 
> I recently noticed we're receiving the following (maybe three times) on the
> MVS log during HSM startup:
> 
> ARC0104I INVALID INITIALIZATION COMMAND
> 
> How can we tell which commands are generating this? I can find no HSM-
> produced log of commands and responses. All I see are the responses.
> 
> Thanks,
> 
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.phoenixsoftware.com_=DwICaQ=C3yme8gMkxg_ihJNXS06Z
> yWk4EJm8LdrrvxQb-
> Je7sw=u9g8rUevBoyCPAdo5sWE9w=NFuXAZR0ZpDnfKO7veV0RNxEx7
> hDB9fT6sfPVF7jHCY=hC7IEUU3uTSU0MRGgey6HTYPYvQDeNYawq0d3ujL1x
> I=
> 
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise received
> this email message in error, any use, dissemination, distribution, review,
> storage or copying of this e-mail message and the information contained
> therein is strictly prohibited. If you are not an intended recipient, please
> contact the sender by reply e-mail and destroy all copies of this email
> message and do not otherwise utilize or retain this email message or any or
> all of the information contained therein. Although this email message and any
> attachments or appended messages are believed to be free of any virus or
> other defect that might affect any computer system into which it is received
> and opened, it is the responsibility of the recipient to ensure that it is 
> virus
> free and no responsibility is accepted by the sender for any loss or damage
> arising in any way from its opening or use.
> 
> --
> 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: Would SHARE kindly kick IBM in the ass for what the've done with their web content?

[zMan]

Good article, of course, Cheryl.

The one thing it didn't mention is that maintenance of these sites is being
moved overseas. That's not inherently bad, except that it inevitably leads
to a loss of tribal knowledge, which may be how these huge omissions
occurred.

On Thu, Jun 21, 2018 at 1:06 PM, Chuck Kreiter 
wrote:

> I was shocked when this article showed up on my front page on Reddit.
> Perfectly stated!
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Cheryl Watson
> Sent: Thursday, June 21, 2018 10:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Would SHARE kindly kick IBM in the ass for what the've done
> with their web content?
>
> Here's our take on this issue -
>
> http://watsonwalker.com/what-is-happening-with-ibms-websites/
>
> All my best,
> Cheryl
>
> ===
> Cheryl Watson
> Watson & Walker, Inc.
> www.watsonwalker.com
> ===
>
> --
> 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
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: ARC0104I INVALID INITIALIZATION COMMAND

[Carmen Vitullo]

okay, I thought so, I was hoping it would provide more info 



Carmen Vitullo 

- Original Message -

From: "Ed Jaffe"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, June 21, 2018 1:22:08 PM 
Subject: Re: ARC0104I INVALID INITIALIZATION COMMAND 

On 6/21/2018 11:15 AM, Carmen Vitullo wrote: 
> Been a while for me supporting / having HSM 
> IIRC isn't there a LOG1 + LOG2 that goes to a dataset? 

Yes. Such data sets exist. Browsing under ISPF you see only the comman 
responses, not the commands themselves. For example, I see "SETSYS 
COMMAND COMPLETED" but not the actual SETSYS command that was issued: 

.ÃM:_.(Þå3STARTUP.é..M:_.+.É3**OPER**.ARC0001I DFSMS 
..M:_.Ý@Û3.DSR..^ .8 
.þ.ã..M:_.]1.3.u..**OPER**.ARC1700I DFSMSHSM COMMANDS ARE RA 
.S.\..M:_.AÓM3...M. .à**IPL***.. 
.S.\..M:_.BÁa3...M. .à**IPL***.. 
.m.\..M:_.B..3...M. .à**IPL***.. 
...\..M:_.D..3...M. .à**IPL***.. 
.:M:_.Eý<3. .à**IPL***.. 
.0M:_.Hm.3. .à**IPL***.. 
.ûM:_.­ÃX3. .à**IPL***.. 
..M:_.ôa.3. .à**IPL***.. 
.­.\..M:_.ö.43...M. .à**IPL***.. 
.=M:_.K;ë3.À..**OPER**.ARC0100I SETSYS COMMAND COMPLETED 
.R.\..M:_.NëÔ3...M. .à**IPL***.. 
.cM:_.O.Ð3. .à**IPL***.. 
...\..M:_.P..3...M. .à**IPL***.. 

-- 
Phoenix Software International 
Edward E. Jaffe 
831 Parkview Drive North 
El Segundo, CA 90245 
http://www.phoenixsoftware.com/ 


 
This e-mail message, including any attachments, appended messages and the 
information contained therein, is for the sole use of the intended 
recipient(s). If you are not an intended recipient or have otherwise 
received this email message in error, any use, dissemination, distribution, 
review, storage or copying of this e-mail message and the information 
contained therein is strictly prohibited. If you are not an intended 
recipient, please contact the sender by reply e-mail and destroy all copies 
of this email message and do not otherwise utilize or retain this email 
message or any or all of the information contained therein. Although this 
email message and any attachments or appended messages are believed to be 
free of any virus or other defect that might affect any computer system into 
which it is received and opened, it is the responsibility of the recipient 
to ensure that it is virus free and no responsibility is accepted by the 
sender for any loss or damage arising in any way from its opening or use. 

-- 
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: ARC0104I INVALID INITIALIZATION COMMAND

[Ed Jaffe]

On 6/21/2018 11:15 AM, Carmen Vitullo wrote:

Been a while for me supporting / having HSM
IIRC isn't there a LOG1 + LOG2 that goes to a dataset?


Yes. Such data sets exist. Browsing under ISPF you see only the comman 
responses, not the commands themselves. For example, I see "SETSYS 
COMMAND COMPLETED" but not the actual SETSYS command that was issued:


.ÃM:_.(Þå3STARTUP.é..M:_.+.É3**OPER**.ARC0001I DFSMS
..M:_.Ý@Û3.DSR..^ .8
.þ.ã..M:_.]1.3.u..**OPER**.ARC1700I DFSMSHSM COMMANDS ARE RA
.S.\..M:_.AÓM3...M. .à**IPL***..
.S.\..M:_.BÁa3...M. .à**IPL***..
.m.\..M:_.B..3...M. .à**IPL***..
...\..M:_.D..3...M. .à**IPL***..
.:M:_.Eý<3. .à**IPL***..
.0M:_.Hm.3. .à**IPL***..
.ûM:_.­ÃX3. .à**IPL***..
..M:_.ôa.3. .à**IPL***..
.­.\..M:_.ö.43...M. .à**IPL***..
.=M:_.K;ë3.À..**OPER**.ARC0100I SETSYS COMMAND COMPLETED
.R.\..M:_.NëÔ3...M. .à**IPL***..
.cM:_.O.Ð3. .à**IPL***..
...\..M:_.P..3...M. .à**IPL***..

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: MVS SEND command Error

[saurabh khandelwal]

 /*  REXX */

'PIPE SAFE * | STEM MSG.'



TODataset = Word( Msg.3,3 )

mvs "send 'My console name is  "TODataset"',CN=CNDVMSTR"

exit


Problem has been resolved by using sync command with option both.

Now, i used CN operand with send command to send message to  operator
console and now i receive as required.

But this message is visible in green color which get disappeared as other
message comes on console.

But, I would like to have these message in white color ( not sure if we can
say as WTO), so that until operator intervention, these message will be on
console itself.


Can you please suggest.

On Thu, Jun 21, 2018 at 2:56 AM, Jesse 1 Robinson 
wrote:

> Two separate issues have been discussed in this thread. One is the use (or
> not) of user logs. The other is the use (or not) of TSOE segments. These
> two issues are independent. You can have user logs with or without TSOE
> segments, and TSOE segments with or without user logs.
>
> I have not been able to reproduce OP's problem directly with MVS commands.
> If I name more than one userid, the message goes to all of them unless (in
> our case) there is no associated user log, in which case I get this:
>
> 16.51.01 X0   se 'test msg from Skip',user=(xxx066, xxx166,
> xxx266),logon
>
> 16.51.01 X0   IKJ591I   USER LOG DOES NOT EXIST FOR USER(S)
> XXX266  AND THE BROADCAST
> 16.51.01 X0   IKJ591I  DATA SET CANNOT BE USED, MESSAGE
> CANCELLED.
>
> All three userids are targeted. The first two are successful while the
> third fails on missing user log.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: Wednesday, June 20, 2018 12:06 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: MVS SEND command Error
>
> It's related to broadcast because you used the LOGON option of SEND. Did
> you do a SYNCH/ Did you try having user logs? See <
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/
> com.ibm.zos.v2r1.ikjb400/conlogs.htm>.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of saurabh khandelwal 
> Sent: Wednesday, June 20, 2018 1:36 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: MVS SEND command Error
>
> yes.. both users have TSO segments and active users. I was unable to
> understand how it is related to UADS and broadcast dataset.
>
> On Wed, Jun 20, 2018 at 7:35 PM, Seymour J Metz  wrote:
>
> > Does AB55 have a TSO segment?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List  on
> > behalf of saurabh khandelwal 
> > Sent: Wednesday, June 20, 2018 11:03 AM
> > To: IBM-MAIN@listserv.ua.edu
> > Subject: Re: MVS SEND command Error
> >
> > Hello Seymour/ Lizette,
> >
> > We use RACF in our system .
> >
> > Below is our definition of IKJTSO.
> >
> > BROWSESYS1.DEVL.PARMLIB(IKJTSODV) - 01.02
> >
> >   LOGNAME(*)   /*   */ +
> >
> >   BROADCAST (DATASET(SYS2.DEVL.BRODCAST))
> >
> > SEND/* SEND COMMAND DEFAULTS */ +
> >
> >OPERSEND(ON) /*   */ +
> >
> >USERSEND(ON) /*   */ +
> >
> >SAVE(ON) /*   */ +
> >
> >CHKBROD(OFF) /*   */ +
> >
> >LOGNAME(*)   /*   */ +
> >
> >BROADCAST (DATASET(SYS2.DEVL.BRODCAST))
> >
> > ALLOCATE/* ALLOCATE COMMAND DEFAULT  */  +
> >
> >DEFAULT(OLD) /*   */
> >
> > TRANSREC /* ALLOCATE COMMAND DEFAULT  */
> >
> >NODESMF((NODENAME,SMF)) /*ALLOCATE COMMAND DEFAULT*/ +
> >
> >CIPHER(YES)  /*   */ +
> >
> >SPOOLCL(B)   /*   */ +
> >
> >OUTWARN(5,15000) /*   */ +
> >
> >OUTLIM(500)  /*   */ +
> >
> >VIO(SYSALLDA)/*   */ +
> >
> >LOGSEL(LOG)  /*   */ +
> >
> >LOGNAME(MISC)/*   */ +
> >
> >DAPREFIX(TUPREFIX)   /*   */ +
> >
> >USRCTL(NAMES.TEXT)   /*   */ +
> >
> >SYSOUT(*)/*   */
> >
> >
> >
> > Can you please tell me, what kind of changes do we have to make to
> > solve this issue in our IKJTSO member.
> >
> >
> >
> >
> > On Tue, Jun 19, 2018 at 10:39 PM, Seymour J Metz  wrote:
> >
> > > Are you using UADS or SAF?
> > >
> 

Re: ARC0104I INVALID INITIALIZATION COMMAND

[Carmen Vitullo]

Been a while for me supporting / having HSM 
IIRC isn't there a LOG1 + LOG2 that goes to a dataset? 


Carmen Vitullo 

- Original Message -

From: "Ed Jaffe"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, June 21, 2018 1:00:51 PM 
Subject: ARC0104I INVALID INITIALIZATION COMMAND 

I recently noticed we're receiving the following (maybe three times) on 
the MVS log during HSM startup: 

ARC0104I INVALID INITIALIZATION COMMAND 

How can we tell which commands are generating this? I can find no 
HSM-produced log of commands and responses. All I see are the responses. 

Thanks, 

-- 
Phoenix Software International 
Edward E. Jaffe 
831 Parkview Drive North 
El Segundo, CA 90245 
http://www.phoenixsoftware.com/ 


 
This e-mail message, including any attachments, appended messages and the 
information contained therein, is for the sole use of the intended 
recipient(s). If you are not an intended recipient or have otherwise 
received this email message in error, any use, dissemination, distribution, 
review, storage or copying of this e-mail message and the information 
contained therein is strictly prohibited. If you are not an intended 
recipient, please contact the sender by reply e-mail and destroy all copies 
of this email message and do not otherwise utilize or retain this email 
message or any or all of the information contained therein. Although this 
email message and any attachments or appended messages are believed to be 
free of any virus or other defect that might affect any computer system into 
which it is received and opened, it is the responsibility of the recipient 
to ensure that it is virus free and no responsibility is accepted by the 
sender for any loss or damage arising in any way from its opening or use. 

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

ARC0104I INVALID INITIALIZATION COMMAND

[Ed Jaffe]

I recently noticed we're receiving the following (maybe three times) on 
the MVS log during HSM startup:


ARC0104I INVALID INITIALIZATION COMMAND

How can we tell which commands are generating this? I can find no 
HSM-produced log of commands and responses. All I see are the responses.


Thanks,

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Would SHARE kindly kick IBM in the ass for what the've done with their web content?

[Chuck Kreiter]

I was shocked when this article showed up on my front page on Reddit.  
Perfectly stated!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cheryl Watson
Sent: Thursday, June 21, 2018 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would SHARE kindly kick IBM in the ass for what the've done with 
their web content?

Here's our take on this issue - 

http://watsonwalker.com/what-is-happening-with-ibms-websites/

All my best,
Cheryl

===
Cheryl Watson
Watson & Walker, Inc.
www.watsonwalker.com
===

--
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: 2 possible RFE --- ISPF & SDSF.

[Paul Gilmartin]

On Thu, 21 Jun 2018 14:28:51 +, Rob Scott wrote:

>From the start of the JCL user guide, there is a blanket statement of "A JCL 
>statement consists of one or more 80-byte records".
> 
That's not exactly true.  IIRC, I've submitted JCL statements in records longer 
than
80 bytes; columns 73 and beyond are quietly ignored.  So 72-byte records would 
be
more accurate than 80-byte.

>However, looking at the SYSIN keyword it indeed says that the 80-byte limit is 
>a minimum length.
>
Does it state an upper limit?

Does it explain how the LRECL and RECFM merged into the DCB at OPEN are
determined?  I've submitted an RCF on this and the information has not been
added to the manual.


On Thu, 21 Jun 2018 15:20:09 +, Rob Scott wrote:

>From what I can tell from the documentation, both native TSO SUBMIT and ISPF 
>SUBMIT (via ISPCTLx) do not allow job submission for anything other than 
>RECFM=FB LRECL=80 datasets.
>
TSO SUBMIT fails with an error if the input data set is other than RECFM=FB 
LRECL=80.
This could be changed with negligible compatibility impact to allocate INTRDR 
with the
attributes of the input data set and proceed successfully.

(Also on my wish list is that SUBMIT have an INDD() option so I could pipe
from a UNIX process.)

I suspect that ISPF SUBMIT copies its input to a RECFM=FB LRECL=80 data set 
(sometimes
with SPACE problems).  Changing to submit directly to INTRDR allocated with 
attributes of
the input data set would have some compatibility impact and would have to be 
made optional.
I have a macro that submits an Edit buffer to INTRDR, defaulting to attributes 
of the data set
being edited, with option to force to FB 80.

>As SDSF "SJ" uses EDIF and implicitly ISPF SUBMIT it is limited by the 
>TSO/ISPF restrictions.
>
Alas.  Truncation should not be quiet; it's data loss.  At a minimum,
the user should be given a prompt with options:
Truncate and submit/Retain attributes and submit/Cancel

-- gil

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

Re: Would SHARE kindly kick IBM in the ass for what the've done with their web content?

[Seymour J Metz]

She generally is nice.

BTW, for those who don't know who she is, I strongly recommend that you take a 
look at her newsletters.


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


From: IBM Mainframe Discussion List  on behalf of 
Allan Staller 
Sent: Thursday, June 21, 2018 12:32 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Would SHARE kindly kick IBM in the ass for what the've done with 
their web content?

Except she was polite about it!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Thursday, June 21, 2018 11:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would SHARE kindly kick IBM in the ass for what the've done with 
their web content?

As would be expected, Cheryl absolutely nailed it!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cheryl Watson
Sent: Thursday, June 21, 2018 7:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would SHARE kindly kick IBM in the ass for what the've done with 
their web content?

Here's our take on this issue -

https://secure-web.cisco.com/1V0GznTDmut8ZxNK1e04NEcncSJJTF4F3uul-mWKoiMtx01kv0W0ejwWqvKbUOj1EM_awTtidouLFgV-JfYf9Uqy91gKWC3E6TYWbJe7qm7YeqA_jcxTj1TReG2-3qifM69Kd9XObHzh2RK3cJpmD1xyP9JOosmRy9ALgR1Jn5LQq08Te3RLwLooAl9GDlKeD518n_UXh7-2f1nOx5Qs_zfVpcEJ78YtYBGCjn_XOiPrIgkhZuIMbtMrt9sTGkulJ-Izf3xylUaa4xQQl5ZMzuVQCYNuC-fXVAWM_YOhd3mUwtdhg6r3xOggLSm6jnm0gtcENR7H3jHFm__DcKwzjuCY3f1k2_W8n_TxNrFIliN9f8UMn4_N1KSrkUCb-Cb5kur_6QIgE0ub_l12S6nRmZQ/https%3A%2F%2Fapac01.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%253A%252F%252Fwatsonwalker.com%252Fwhat-is-happening-with-ibms-websites%252F%26data%3D02%257C01%257Callan.staller%2540HCL.COM%257Cac187c24964b4247d83d08d5d7941e19%257C189de737c93a4f5a8b686f4ca9941912%257C0%257C0%257C636651953551346840%26sdata%3Du%252BEcuSZS8TwLjc3pQbQ1Zy%252FMstCWdptscDSaR4gSR%252BY%253D%26reserved%3D0

All my best,
Cheryl

===
Cheryl Watson
Watson & Walker, Inc.
https://secure-web.cisco.com/1OyR_FoochrVjHrn_jqSh_wIuQZJaZ6qPc0q3kY050JMmbiytZptK80AdkoZdDR9IrNG_P2gzHzTzlobmyHWBLP9fMirlo2vbI_USx2a1zba9JJMHrSss5TAIeDbD1pxm4eBK7lWhmqdwBtd4Oee2LNmoJqimKt9C0m7okawQRCgKJqarA8HEbW3gvbucZHWrdAMqKe2a1RGzHUT3RsVHZ3CzJLzRXdX35C2g0IZ216NPkgZNKZk4DAAndCSeVbl_qQ9Bcs42Rq338cvooqln-Z7Wyq86DQyZ3cFBV7Rm7w8t5omoRNfCfEg2jUoe5UvU5J-_huY1kkzdgjsmgvXchm-RG3HPSiTij_98zKSWZGHYq_UdEZ9fEoQ-56W4DqO9JeR37hUXHMfeOm8CnSUcXg/https%3A%2F%2Fapac01.safelinks.protection.outlook.com%2F%3Furl%3Dwww.watsonwalker.com%26data%3D02%257C01%257Callan.staller%2540HCL.COM%257Cac187c24964b4247d83d08d5d7941e19%257C189de737c93a4f5a8b686f4ca9941912%257C0%257C0%257C636651953551346840%26sdata%3DIsNcyhSEUYxWxbECB3dmRFougbLOklbAxk8sSGz1TC8%253D%26reserved%3D0
===

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

Re: 2 possible RFE --- ISPF & SDSF.

[Seymour J Metz]

Patient: Doctor, it hurts when I do SUBMIT!

Doctor: Nu, so don't do SUBMIT.

Maybe one of these days IBM will fix SUBMIT, but in the meantime just copy the 
job to the Internal Reader.


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


From: IBM Mainframe Discussion List  on behalf of Rob 
Scott 
Sent: Thursday, June 21, 2018 11:20 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: 2 possible RFE --- ISPF & SDSF.

>From what I can tell from the documentation, both native TSO SUBMIT and ISPF 
>SUBMIT (via ISPCTLx) do not allow job submission for anything other than 
>RECFM=FB LRECL=80 datasets.

As SDSF "SJ" uses EDIF and implicitly ISPF SUBMIT it is limited by the TSO/ISPF 
restrictions.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, June 21, 2018 3:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2 possible RFE --- ISPF & SDSF.

On Thu, 21 Jun 2018 09:34:48 +, Rob Scott wrote:

>>> On occasion I have been sorely vexed when I hastily issued SUBMIT from the 
>>> SJ panel and discovered my sysins truncated to 80 characters.  SUBMIT from 
>>> SJ should preserve the attributes of the original job on resubmit.
>
>I must admit to being slightly puzzled by this statement.
>
>JCL is, by definition, a sequence of 80-byte card images and any instream 
>SYSIN will be taken as a sequence of 80-byte characters.
>
No.

>Maybe I am missing something here - please let me know if so.
>
Perhaps the last few decades of OS enhancements?

If you know of any current z/OS documentation that mentions an 80 character 
limit applicable to SYSIN, let me know and I'll submit an RCF.

I have long used either FTP or allocated SYSOUT=(,INTRDR) to submt jobs with 
much longer SYSIN.  The TCPIP Ref. states a limit of 254 for FTP FILE=JES, 
which is enforced (archaic and needless, IMO).  JES3 has supported long SYSIN 
as long as I can remember; JES2 since z/OS circa 1.5.

-- gil

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://secure-web.cisco.com/1w02f89UkKWRWUYKrT0uDqjPxnIt4VXpmzY_VsFcPm7hkBsCP_befm_XvkdYDLnKoWzI_m45LbqQ7CZ6Mh0TWx7ZQAEfVNaVVUNjWs9qq638_xCTClIkzVf8J_dhWHl7XqYbk0BBHwlJWkTAraIEPF-BAQbVm0zaBQ4RyduXW1_NEI7aIPUntszdNTs08O4lIFO5lo3tVuA1TYL-HSLAKRlsRMgs5n8FQ6sbThwOTYHF-Q3M8_ADd4c5C57LjRBeVuZTYVoKSDu0ryqOPURtY748yc0SBg-2yxhksPwKCeVmmOHFkr3K28W7Y2mJs-4ALObA8L_hf0xgG_2XxP1ANuwUW2yP_p7h1iP2Vb78nnm-7RH-BE3K4NhT3YFmna1mNWCwPqSOKXoEvSGEJMpAY8tMyjhBABKs6i_XS4w4tpNIQKCGaiw49NqndpW8GgzMi/https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://secure-web.cisco.com/1T_HRrdCzpoDqFewgReLzSOnFZw44QIBHeHnAUha8SnVbQkmQeCGaYVVx65b6CIt7mmJqnlJLoQPQFz5H5ub1vVpmG2t54NsHDpCa5skINsrFkD-qIgSCm___XnO3IheTYX2TupqJJvcs-yWjcPNPNrp6TcOo96bnELCCgo6PMcchi6bKcQG2tsSEx4-iGiUIN5B3ztHfb63M8bugjFEUGpC-T7H13m8M4Suf9zZ3EaPTSmMOvUtX8QyxavrH06pI54cVojhIuwQNUR29NGRirCTdxV-RjowIjHiK2NbVbullFMathMcL-Mmy93D7DFJfq8v77eBwvecLhmJbA0YVXexF2603bdTZhr9aC6kBiyfkVNsMYS1826K-lU4uwDEuTFliEXvyIZWEN9KCxwrARR6_4eSPR9nvEDrJvypnGll33DXbtndSMQsK4aMX3p4F/http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferences
Privacy Policy - 
http://secure-web.cisco.com/1SMuF3WeR490QLVNZPHsTfgoHXgonn5gC9lZZszVA2v_ktdyLtQX3YVhuiC9qhANVGlMrAJoDlUchBjJ5W-OTOo2FDU4_Fsz4s0i32JF9khYO_UOO6USSPehm9fe0bEMib---cPbIW0dCAYBO5pNE_-iG42uk_OxDq91MbmJcGtwh3O6WTYmS-Y53Au-KL7ZCwT-nj6BO8LXzSB8Gl3r0a-QoncNCiKvhf1oF4uM2fnsykNynBhnTAVnQ6gprrcEtHzyCizv2Hbk61wasDKF4Tg8Ia-WyEJXc9JdU7PbQKoPlXDr0UycWqaoKOBCKr4YtR2dG6TaGQuLD65z50Lc0P45_SfbB5_r0oQPUg2ATBlBNKAPeX_jC5Nicn9u1PoanEns_b2TTJQKc0HJJhbOaZM8xm34VJWXIFBHQrYacTu37arNxMWgp-wXv46lLcW1a/http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. 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

Re: Would SHARE kindly kick IBM in the ass for what the've done with their web content?

[Carmen Vitullo]

Indeed! and articulated the z communities outage in a most civil manner 
thank you Cheryl 


Carmen Vitullo 

- Original Message -

From: "Charles Mills"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, June 21, 2018 11:28:45 AM 
Subject: Re: Would SHARE kindly kick IBM in the ass for what the've done with 
their web content? 

As would be expected, Cheryl absolutely nailed it! 

Charles 


-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cheryl Watson 
Sent: Thursday, June 21, 2018 7:42 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Would SHARE kindly kick IBM in the ass for what the've done with 
their web content? 

Here's our take on this issue - 

http://watsonwalker.com/what-is-happening-with-ibms-websites/ 

All my best, 
Cheryl 

=== 
Cheryl Watson 
Watson & Walker, Inc. 
www.watsonwalker.com 
=== 

-- 
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: Would SHARE kindly kick IBM in the ass for what the've done with their web content?

[Allan Staller]

Except she was polite about it!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Thursday, June 21, 2018 11:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would SHARE kindly kick IBM in the ass for what the've done with 
their web content?

As would be expected, Cheryl absolutely nailed it!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cheryl Watson
Sent: Thursday, June 21, 2018 7:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would SHARE kindly kick IBM in the ass for what the've done with 
their web content?

Here's our take on this issue -

https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwatsonwalker.com%2Fwhat-is-happening-with-ibms-websites%2F=02%7C01%7Callan.staller%40HCL.COM%7Cac187c24964b4247d83d08d5d7941e19%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636651953551346840=u%2BEcuSZS8TwLjc3pQbQ1Zy%2FMstCWdptscDSaR4gSR%2BY%3D=0

All my best,
Cheryl

===
Cheryl Watson
Watson & Walker, Inc.
https://apac01.safelinks.protection.outlook.com/?url=www.watsonwalker.com=02%7C01%7Callan.staller%40HCL.COM%7Cac187c24964b4247d83d08d5d7941e19%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636651953551346840=IsNcyhSEUYxWxbECB3dmRFougbLOklbAxk8sSGz1TC8%3D=0
===

--
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
::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: Would SHARE kindly kick IBM in the ass for what the've done with their web content?

[Charles Mills]

As would be expected, Cheryl absolutely nailed it!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Cheryl Watson
Sent: Thursday, June 21, 2018 7:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would SHARE kindly kick IBM in the ass for what the've done with 
their web content?

Here's our take on this issue - 

http://watsonwalker.com/what-is-happening-with-ibms-websites/

All my best,
Cheryl

=== 
Cheryl Watson
Watson & Walker, Inc.
www.watsonwalker.com
===

--
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: 2 possible RFE --- ISPF & SDSF.

[Rob Scott]

From what I can tell from the documentation, both native TSO SUBMIT and ISPF 
SUBMIT (via ISPCTLx) do not allow job submission for anything other than 
RECFM=FB LRECL=80 datasets.

As SDSF "SJ" uses EDIF and implicitly ISPF SUBMIT it is limited by the TSO/ISPF 
restrictions.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, June 21, 2018 3:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2 possible RFE --- ISPF & SDSF.

On Thu, 21 Jun 2018 09:34:48 +, Rob Scott wrote:

>>> On occasion I have been sorely vexed when I hastily issued SUBMIT from the 
>>> SJ panel and discovered my sysins truncated to 80 characters.  SUBMIT from 
>>> SJ should preserve the attributes of the original job on resubmit.
>
>I must admit to being slightly puzzled by this statement.
>
>JCL is, by definition, a sequence of 80-byte card images and any instream 
>SYSIN will be taken as a sequence of 80-byte characters.
>
No.

>Maybe I am missing something here - please let me know if so.
>
Perhaps the last few decades of OS enhancements?

If you know of any current z/OS documentation that mentions an 80 character 
limit applicable to SYSIN, let me know and I'll submit an RCF.

I have long used either FTP or allocated SYSOUT=(,INTRDR) to submt jobs with 
much longer SYSIN.  The TCPIP Ref. states a limit of 254 for FTP FILE=JES, 
which is enforced (archaic and needless, IMO).  JES3 has supported long SYSIN 
as long as I can remember; JES2 since z/OS circa 1.5.

-- gil

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: 2 possible RFE --- ISPF & SDSF.

[Seymour J Metz]

> JCL is, by definition, a sequence of 80-byte card images and any instream 
> SYSIN 
> will be taken as a sequence of 80-byte characters.

That may have been true in 1964; it has not been true for a very long time.


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


From: IBM Mainframe Discussion List  on behalf of Rob 
Scott 
Sent: Thursday, June 21, 2018 5:34 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: 2 possible RFE --- ISPF & SDSF.

>> On occasion I have been sorely vexed when I hastily issued SUBMIT from the 
>> SJ panel and discovered my sysins truncated to 80 characters.  SUBMIT from 
>> SJ should preserve the attributes of the original job on resubmit.

I must admit to being slightly puzzled by this statement.

JCL is, by definition, a sequence of 80-byte card images and any instream SYSIN 
will be taken as a sequence of 80-byte characters.

Maybe I am missing something here - please let me know if so.


The SDSF "SJ" command acts by allocating the "special" JES dataset name for the 
original JCL and then uses ISPF "EDIF" (without a command routine) to display 
the contents.

The subsequent "SUBMIT" is not under SDSF control - it is the same "SUBMIT" 
command used by ISPF.


As far as the "submit as an SDSF action from NP" idea, the best I could advise 
at the moment would be to use the SDSF REXX interface and the "%" prefix in the 
NP column input to execute it.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, June 20, 2018 6:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2 possible RFE --- ISPF & SDSF.

On Tue, 19 Jun 2018 07:03:21 -0500, John McKown wrote:
>
>1) I think it would be nice if I could do a "SUBMIT" command in ISPF
>option
>2 when I have a list of UNIX files displayed, rather than members of a PDS.
>Yes, I know that I could do an RYO REXX exec. I just don't wanna {grin}.
>
Yes.  Likewise for 3.17.

>2) In SDSF, I quite often want to resubmit a job, as is, which is in
>the output queue. At present, I do an SJ on it, followed by
>"submit;end;;". I would also like a SDSF line command, preferably named
>SUBMIT, which would do this for me. Again, RYO is a possibility, but ... .
>
Yes.  And sometimes finding the job ID can be tricky.  Pedro Vera suggested 
screen scraping.  Crude but effective.

On occasion I have been sorely vexed when I hastily issued SUBMIT from the SJ 
panel and discovered my sysins truncated to 80 characters.  SUBMIT from SJ 
should preserve the attributes of the original job on resubmit.

-- gil

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://secure-web.cisco.com/15nPNCIf051VJBS5NOTRjTbcqdYjtLsLlwyrTwXVBVH5YJenQcUXgRkCoQnPpJAkCWrGeSVKfIZdMqslrnITZjISUdnfhiffpmkCmBsa2jpEC1HEnqdcDNmPa_Y0ZFFxlr3Q-Bi_yIW9oHRzYtwLYV2t3mlVnDQP6q9JRjNTLHWUyDxMU__wT_vXCsDUofgVAtnytBr_ifZaMocqyWZypk1N-OY96_ZmQmnap8hvd_gpqmFjoGJGVF4xn625IwH7XE6QXk_cgUjU_-qfaH8cdy4PeFm6sOsbxHvHsDqGw9MZ1QbWsqc_G9F2FH3i8fbVDDV7xc5qDvJDS9NjgQTh1UK7Su8WYSvdTSRYDljlYQYYp66hqR4vcafV6h2MUO4ltx3lf5CZPpC1FRLtEvzPaAfwg_HGZ5pSue6Nn_Ro2BPiqLZbKdprOwW55VkOrDVhP/https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://secure-web.cisco.com/1Uci4FT4Xo05-zTUahoH16Q-IqwVw7X7TPAymhOiI_0z2ofOVnID_D0pvSVE3SMJlnbVfsszJpMuA8K4r7wWOVqqOjFTL9s8XOr3DpuTEeQzmdx0Q5YqyfN8eOUByUVZR21TYhNxFWnqW50qV-4y3ewpdBU4RbChDc3Qj4pjpQAUfR30fFyku6jkU7bPt4eMrk7YBQVm0W_oTEYwUMXJ8Ouxb6q8mKHU5mA0qOYZvvsWno3EJ6aQ5rlC4yOMSWYaoXXolg1wgYmaytBVTuh6-AmCw-xx7BPHDkCsOpwXqlFVRKblWLO_cglMdqIipEthsKx-eeYQMYHLeHMf2fGh_Lnmk6m_B7Fr0OtHUIFDGFL6kWzD3-oLNomOqlxMi8IxVaBEMV86gvbVYsFmiOQP1abvhJdy0cDvykWNF1Nt6INH7pSW9CkVj3WD2KvXKQawJ/http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferences
Privacy Policy - 
http://secure-web.cisco.com/1JSbvo4hDobYusU30RaMELWXTt8bKWbxkwXJhsFzhi3QRz6yeGtmkogZZXbuntIyaGZKxRUAMM1Od3okjkm190Js2-ZWim1CpdENmuU2njL1QlxxAjj23u_EM3eILaJ-_Hn7rkO_Er7dMeSPOsRF4gPbtBC04gzqBcIor1nwX3JQNF0TS80Pg4mhrIagY4MKvXnZ4IUgAnXx2nh3Xp67oRQSv2rS669HVN93pCxwFRWr81zkskBTdVbab4tGz5uqaId0XV7fKzH433BH-w2UwBPPwaqNYFpXNWiFI5dn1QBo5WXRqfxMKg-QNLQG0otbRgmXeXkqy5HyP0ltLE1ODrvtr9yUbxG_9RoPsJPfvA4HI2J0iSihgO7c8ub3GmCPKrkOpFu6M-2bwWlXImr-xsDaaLPk7pZH-Yq7BqLLP1G1d_w9kHdsX8VTSpHGAC7MO/http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are 

Re: Would SHARE kindly kick IBM in the ass for what the've done with their web content?

[Cheryl Watson]

Here's our take on this issue - 

http://watsonwalker.com/what-is-happening-with-ibms-websites/

All my best,
Cheryl

=== 
Cheryl Watson
Watson & Walker, Inc.
www.watsonwalker.com
===

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

Re: 2 possible RFE --- ISPF & SDSF.

[Rob Scott]

From the start of the JCL user guide, there is a blanket statement of "A JCL 
statement consists of one or more 80-byte records".

However, looking at the SYSIN keyword it indeed says that the 80-byte limit is 
a minimum length.

Looks like am never too old to learn something new...

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, June 21, 2018 3:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2 possible RFE --- ISPF & SDSF.

On Thu, 21 Jun 2018 09:34:48 +, Rob Scott wrote:

>>> On occasion I have been sorely vexed when I hastily issued SUBMIT from the 
>>> SJ panel and discovered my sysins truncated to 80 characters.  SUBMIT from 
>>> SJ should preserve the attributes of the original job on resubmit.
>
>I must admit to being slightly puzzled by this statement.
>
>JCL is, by definition, a sequence of 80-byte card images and any instream 
>SYSIN will be taken as a sequence of 80-byte characters.
>
No.

>Maybe I am missing something here - please let me know if so.
>
Perhaps the last few decades of OS enhancements?

If you know of any current z/OS documentation that mentions an 80 character 
limit applicable to SYSIN, let me know and I'll submit an RCF.

I have long used either FTP or allocated SYSOUT=(,INTRDR) to submt jobs with 
much longer SYSIN.  The TCPIP Ref. states a limit of 254 for FTP FILE=JES, 
which is enforced (archaic and needless, IMO).  JES3 has supported long SYSIN 
as long as I can remember; JES2 since z/OS circa 1.5.

-- gil

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: 2 possible RFE --- ISPF & SDSF.

[Paul Gilmartin]

On Thu, 21 Jun 2018 09:34:48 +, Rob Scott wrote:

>>> On occasion I have been sorely vexed when I hastily issued SUBMIT from the 
>>> SJ panel and discovered my sysins truncated to 80 characters.  SUBMIT from 
>>> SJ should preserve the attributes of the original job on resubmit.
>
>I must admit to being slightly puzzled by this statement.
>
>JCL is, by definition, a sequence of 80-byte card images and any instream 
>SYSIN will be taken as a sequence of 80-byte characters.
>
No.

>Maybe I am missing something here - please let me know if so.
>
Perhaps the last few decades of OS enhancements?

If you know of any current z/OS documentation that mentions an 80 character
limit applicable to SYSIN, let me know and I'll submit an RCF.

I have long used either FTP or allocated SYSOUT=(,INTRDR) to submt jobs
with much longer SYSIN.  The TCPIP Ref. states a limit of 254 for FTP
FILE=JES, which is enforced (archaic and needless, IMO).  JES3 has supported
long SYSIN as long as I can remember; JES2 since z/OS circa 1.5.

-- gil

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

Re: 2 possible RFE --- ISPF & SDSF.

[Tom Marchant]

On Thu, 21 Jun 2018 12:18:31 +0200, ITschak Mugzach wrote:

>The issue is applicable for jcl & instream data. The submitted JCL may
>include variables which after substitution may occupy larger space. SJ does
>not substitute. It uses the post substitution version of the JCL.

Under what circumstances does it do that? When I use SJ, I see the same 
JCL and instream data as was contained in the original file. The symbols are 
still there, and have not been substituted.

-- 
Tom Marchant

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

Re: Z/VM - Clear a console system spool on Z/VM

[Ana Paula]

Hi Doug,

Because i tried the drain command and it's made no effect.

*drain dasd  spool*
10:30:26 Command complete
Ready; T=0.01/0.01 10:30:26

*query alloc   *
DASD 3332 M01RES 3390 CKD-ECKD (UNITS IN CYLINDERS)
 TDISK TOTAL=000 INUSE=000 AVAIL=000
 PAGE  TOTAL=000 INUSE=000 AVAIL=000
 SPOOL TOTAL=000 INUSE=000 AVAIL=000
 DRCT  TOTAL=020 INUSE=005 AVAIL=015, ACTIVE
DASD 3330 VMCOM1 3390 CKD-ECKD (UNITS IN CYLINDERS)
 TDISK TOTAL=000 INUSE=000 AVAIL=000
 PAGE  TOTAL=000 INUSE=000 AVAIL=000
 SPOOL TOTAL=000 INUSE=000 AVAIL=000
 DRCT  TOTAL=000 INUSE=000 AVAIL=000
*DASD  M01S01 3390 CKD-ECKD (UNITS IN CYLINDERS)   *
* TDISK TOTAL=000 INUSE=000 AVAIL=000, DR  *
* PAGE  TOTAL=000 INUSE=000 AVAIL=000, DR  *
* SPOOL TOTAL=0010016 INUSE=0001714 AVAIL=0008302, DR  *
 DRCT  TOTAL=000 INUSE=000 AVAIL=000

Regards,

Ana


2018-06-21 10:19 GMT-03:00 Ana Paula :

> Hi Doug,
>
> Yeas the spool volume is in Draining Mode. I added a new spool volume.
>
> How can i change de old volume? In draining mode?
>
>
> Q ALLOC MAP
>
> EXTENT EXTENT % ALLOCATION
>
> VOLID  RDEV  STARTEND  TOTAL IN USE   HIGH USED TYPE
>
> --  -- -- -- -- --  -
>
> M01RES 3332  1 20 20  5  5  25% DRCT ACTIVE
>
> M01S01   1  10016  1761K 294988 939585  16% SPOOL DR
>
> M01S02 334E  5  10016  1760K  0  0   0% SPOOL
>
> M01P01 3334  1  10016  1761K  0  0   0% PAGE
>
> Ready; T=0.01/0.01 10:17:53
>
>
> Thank you,
>
> Ana Paula
>
>
> 2018-06-20 17:31 GMT-03:00 Doug :
>
>> Your only spool volume in drain status?
>> Format and add another spool volume is an option.
>> Regards, Doug
>>
>>
>> .
>>
>> On Jun 20, 2018, at 14:35, John McKown 
>> wrote:
>>
>> On Wed, Jun 20, 2018 at 1:03 PM Ana Paula  wrote:
>>
>> > Hi, I'm new on z/VM and new in another company. I took the z/vm to watch
>> > how it was configured, and there is a problem.
>> >
>> > *1) We don't have IBM support, so i can't contact them. *
>> >
>> > *2) HCPVSS427E Console 0009 system spool space full; file held*
>> >
>>
>> ​This may be of some help -- how to PURGE SPOOL files.
>>
>> https://www.ibm.com/support/knowledgecenter/en/SSB27U_6.4.0/
>> com.ibm.zvm.v640.hcpb7/purgecmd.htm
>>
>> You _might_ want something like (USE AT OWN RISK!)
>>
>> PURGE SYSTEM PRT ALL
>>
>> (after doing a SPOOL CLOSE as mentioned in another post)
>>
>> To find out what is on the SPOOL, try here:
>>
>> https://www.ibm.com/support/knowledgecenter/en/SSB27U_6.4.0/
>> com.ibm.zvm.v640.hcpb7/qrdrpp.htm
>>
>> QUERY PRT SYSTEM ALL
>>
>> I _think_ that the above is correct. But I don't currently have a z/VM
>> system to test it on.​
>>
>>
>>
>> >
>> > *At manual it says:  *
>> >
>> > Operator Response:  Make an attempt to reduce the spooling load on the
>> > system
>> > as soon as possible. You may use SPXTAPE to save selected spool files on
>> > tape
>> > before purging them. If the real reader file is purged, try the read
>> > operation
>> > again when more space is available.
>> >
>> >
>> > Programmer Response:  For NSS type files, purge unnecessary system data
>> > files
>> > or spool files to reclaim spool space. For system trace files, purge
>> >
>> > unnecessary system data files or spool file files and reissue the
>> TRSOURCE
>> > or
>> > TRSAVE command.
>> >
>> >
>> > **
>> >
>> > I have no idea how to clear/purge files in a console on z/VM. How can i
>> do
>> > it? And I'm having a problem at startup of DirMaint, and i don't know if
>> > this issue has something with it. I've never used DirMaint before.
>> >
>> > **
>> >
>> > *query alloc spool   *
>> >EXTENT EXTENT  TOTAL  PAGES   HIGH%
>> > VOLID  RDEV  STARTEND  PAGES IN USE   PAGE USED
>> > --  -- -- -- -- -- 
>> > M01S01   1  10016  1761K 294988 939585  16% DR
>> >  -- --
>> > SUMMARY1761K 294988 16%
>> > USABLE 0  0  0%
>> > DRAINING   1761K 294988 16%
>> > Ready; T=0.01/0.01 14:46:43
>> >
>> > *Thanks at advance.*
>> >
>> > *Regards, *
>> >
>> > Ana Paula
>> > *Z/OS and trying to be z/VM support analyst. *
>> >
>> > --
>> > Abraços,
>> > Ana
>> >
>> >
>> >
>> > *Não faças de ti um sonho a realizar. Vai.(Cecília Meireles)
>> > 

Re: Z/VM - Clear a console system spool on Z/VM

[Ana Paula]

Hi Doug,

Yeas the spool volume is in Draining Mode. I added a new spool volume.

How can i change de old volume? In draining mode?


Q ALLOC MAP
EXTENT EXTENT % ALLOCATION
VOLID  RDEV  STARTEND  TOTAL IN USE   HIGH USED TYPE
--  -- -- -- -- --  -
M01RES 3332  1 20 20  5  5  25% DRCT ACTIVE
M01S01   1  10016  1761K 294988 939585  16% SPOOL DR
M01S02 334E  5  10016  1760K  0  0   0% SPOOL
M01P01 3334  1  10016  1761K  0  0   0% PAGE
Ready; T=0.01/0.01 10:17:53

Thank you,

Ana Paula


2018-06-20 17:31 GMT-03:00 Doug :

> Your only spool volume in drain status?
> Format and add another spool volume is an option.
> Regards, Doug
>
>
> .
>
> On Jun 20, 2018, at 14:35, John McKown 
> wrote:
>
> On Wed, Jun 20, 2018 at 1:03 PM Ana Paula  wrote:
>
> > Hi, I'm new on z/VM and new in another company. I took the z/vm to watch
> > how it was configured, and there is a problem.
> >
> > *1) We don't have IBM support, so i can't contact them. *
> >
> > *2) HCPVSS427E Console 0009 system spool space full; file held*
> >
>
> ​This may be of some help -- how to PURGE SPOOL files.
>
> https://www.ibm.com/support/knowledgecenter/en/SSB27U_6.4.
> 0/com.ibm.zvm.v640.hcpb7/purgecmd.htm
>
> You _might_ want something like (USE AT OWN RISK!)
>
> PURGE SYSTEM PRT ALL
>
> (after doing a SPOOL CLOSE as mentioned in another post)
>
> To find out what is on the SPOOL, try here:
>
> https://www.ibm.com/support/knowledgecenter/en/SSB27U_6.4.
> 0/com.ibm.zvm.v640.hcpb7/qrdrpp.htm
>
> QUERY PRT SYSTEM ALL
>
> I _think_ that the above is correct. But I don't currently have a z/VM
> system to test it on.​
>
>
>
> >
> > *At manual it says:  *
> >
> > Operator Response:  Make an attempt to reduce the spooling load on the
> > system
> > as soon as possible. You may use SPXTAPE to save selected spool files on
> > tape
> > before purging them. If the real reader file is purged, try the read
> > operation
> > again when more space is available.
> >
> >
> > Programmer Response:  For NSS type files, purge unnecessary system data
> > files
> > or spool files to reclaim spool space. For system trace files, purge
> >
> > unnecessary system data files or spool file files and reissue the
> TRSOURCE
> > or
> > TRSAVE command.
> >
> >
> > **
> >
> > I have no idea how to clear/purge files in a console on z/VM. How can i
> do
> > it? And I'm having a problem at startup of DirMaint, and i don't know if
> > this issue has something with it. I've never used DirMaint before.
> >
> > **
> >
> > *query alloc spool   *
> >EXTENT EXTENT  TOTAL  PAGES   HIGH%
> > VOLID  RDEV  STARTEND  PAGES IN USE   PAGE USED
> > --  -- -- -- -- -- 
> > M01S01   1  10016  1761K 294988 939585  16% DR
> >  -- --
> > SUMMARY1761K 294988 16%
> > USABLE 0  0  0%
> > DRAINING   1761K 294988 16%
> > Ready; T=0.01/0.01 14:46:43
> >
> > *Thanks at advance.*
> >
> > *Regards, *
> >
> > Ana Paula
> > *Z/OS and trying to be z/VM support analyst. *
> >
> > --
> > Abraços,
> > Ana
> >
> >
> >
> > *Não faças de ti um sonho a realizar. Vai.(Cecília Meireles)
> > *--
> >
> >
> > *Ana Paula de Mendonça Braga *
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> There is no such thing as the Cloud. It is just somebody else’s computer.
>
> Maranatha! <><
> John McKown
>
> --
> 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
>



-- 
Abraços,
Ana



*Não faças de ti um sonho a realizar. Vai.(Cecília Meireles)
*--


*Ana Paula de Mendonça Braga *

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

Re: Using JCL Symbld and TYPRUN=SCAN

[Steve Smith]

I've gotten good results with the EXPORT before the PROC, this example is
cut down from a working job:

//TSRCMHL1 JOB 1000,STEVE.SMITH,NOTIFY=,
// CLASS=C,MSGCLASS=X,COND=(1,LT)
//  EXPORT SYMLIST=(PFX,VER,REL,FIX)
//HLDLIBS PROC PFX=RCM,VER=VV,REL=RR,FIX=TAC9
//AMS1EXEC PGM=IDCAMS,REGION=0M
//SYSPRINT  DD SYSOUT=*
//SYSIN DD *,SYMBOLS=JCLONLY
DELETE *
   SET MAXCC=0
//COPY1   EXEC PGM=IEBCOPY,REGION=0M
//SYSPRINT  DD SYSOUT=*
//ASMIN DD DSN=RCM.WRK07,DISP=SHR
//LOADINDD DSN=RCM.WRK07,DISP=SHR
//ASMOUTDD DSN=,DISP=(NEW,CATLG),
// UNIT=SYSDA,SPACE=(CYL,(5,10,1),RLSE),
// DSNTYPE=LIBRARY,RECFM=FB,LRECL=80
//LOADOUT   DD DSN=,
// DISP=(NEW,CATLG),
// UNIT=SYSDA,SPACE=(TRK,(30,20,3),RLSE),
// RECFM=U,BLKSIZE=6233
//SYSIN DD DDNAME=
//  DD *,SYMBOLS=JCLONLY
LOADLIB   COPY INDD=LOADIN,OUTDD=LOADOUT
SELECT MEMBER=
//MKCASMIN  DD *
ASM   COPY INDD=ASMIN,OUTDD=ASMOUT
SELECT MEMBER=((RCM00222,MKC00222))
//RCMASMIN  DD *
ASM   COPY INDD=ASMIN,OUTDD=ASMOUT
SELECT MEMBER=RCM00222
//PEND
//JS16730 EXEC HLDLIBS,PFX=RCM,VER=07,REL=05,FIX=TAC16730
//JS2740  EXEC HLDLIBS,PFX=MKC,VER=02,REL=05,FIX=MCA2740
//JS2741  EXEC HLDLIBS,PFX=MKC,VER=02,REL=06,FIX=MCA2741
//JS2742  EXEC HLDLIBS,PFX=MKC,VER=02,REL=07,FIX=MCA2742
//JS16731 EXEC HLDLIBS,PFX=RCM,VER=07,REL=07,FIX=TAC16731
//

Ain't JCL fun!

sas

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

Re: z/OS 2.2 - how to order ?

[Kurt Quackenbush]

On 6/20/2018 1:40 PM, Elardus Engelbrecht wrote:


Perhaps IBM should post somewhere for z/OS and other products the GA date, EOM date, EOS 
date and also "end of download/order" date?

Check out the section "Product life cycle dates" (mind the wrap):
http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=dd=sm=ShopzSeries=897/ENUS5650-ZOS

Kurt Quackenbush -- IBM, SMP/E Development

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

Re: 2 possible RFE --- ISPF & SDSF.

[Rob Scott]

Here is a quick example of how SDSF can be used to provide the "Resubmit" 
action on panels like "H", "ST" or "O".

To keep things brief, I have omitted environmental and error checking - 
examples of which can be found in the SDSF manuals.

/* REXX  */
/* Example SDSF REXX to re-submit JCL*/
/* from output queue bypassing the   */
/* EDIF panel from "SJ"  */
/*   */
parse arg panel primary token command .
sdsfjcldsn = "SDSF.JCL"
if sysdsn(sdsfjcldsn) <> "OK" then do
  address TSO "ALLOC F(SDSFJCL) DA("sdsfjcldsn") NEW CATALOG ",
  "RECFM(F B) LRECL(80) BLKSIZE(3120) UNIT(SYSALLDA) ",
  "DSORG(PS) TRACKS SPACE(10,10)"
end
else do
address TSO "ALLOC F(SDSFJCL) DA("sdsfjcldsn") SHR REU"
end
x = ISFCALLS("ON")
address SDSF "ISFBROWSE "panel "TOKEN('"token"') (JCL)"
if ISFLINE.0 > 0 then do
  address TSO "EXECIO * DISKW SDSFJCL (FINIS STEM ISFLINE."
  address TSO "SUBMIT "sdsfjcldsn
end
address TSO "FREE F(SDSFJCL)"
x = ISFCALLS("OFF")
exit


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ITschak Mugzach
Sent: Thursday, June 21, 2018 11:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2 possible RFE --- ISPF & SDSF.

The issue is applicable for jcl & instream data. The submitted JCL may include 
variables which after substitution may occupy larger space. SJ does not 
substitute. It uses the post substitution version of the JCL.

ITschak

On Thu, Jun 21, 2018 at 11:34 AM, Rob Scott 
wrote:

> >> On occasion I have been sorely vexed when I hastily issued SUBMIT
> >> from
> the SJ panel and discovered my sysins truncated to 80 characters.
> SUBMIT from SJ should preserve the attributes of the original job on resubmit.
>
> I must admit to being slightly puzzled by this statement.
>
> JCL is, by definition, a sequence of 80-byte card images and any
> instream SYSIN will be taken as a sequence of 80-byte characters.
>
> Maybe I am missing something here - please let me know if so.
>
>
> The SDSF "SJ" command acts by allocating the "special" JES dataset
> name for the original JCL and then uses ISPF "EDIF" (without a command
> routine) to display the contents.
>
> The subsequent "SUBMIT" is not under SDSF control - it is the same
> "SUBMIT" command used by ISPF.
>
>
> As far as the "submit as an SDSF action from NP" idea, the best I
> could advise at the moment would be to use the SDSF REXX interface and the "%"
> prefix in the NP column input to execute it.
>
> Rob Scott
> Rocket Software
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Wednesday, June 20, 2018 6:06 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: 2 possible RFE --- ISPF & SDSF.
>
> On Tue, 19 Jun 2018 07:03:21 -0500, John McKown wrote:
> >
> >1) I think it would be nice if I could do a "SUBMIT" command in ISPF
> >option
> >2 when I have a list of UNIX files displayed, rather than members of
> >a
> PDS.
> >Yes, I know that I could do an RYO REXX exec. I just don't wanna {grin}.
> >
> Yes.  Likewise for 3.17.
>
> >2) In SDSF, I quite often want to resubmit a job, as is, which is in
> >the output queue. At present, I do an SJ on it, followed by
> >"submit;end;;". I would also like a SDSF line command, preferably
> >named SUBMIT, which would do this for me. Again, RYO is a possibility, but 
> >... .
> >
> Yes.  And sometimes finding the job ID can be tricky.  Pedro Vera
> suggested screen scraping.  Crude but effective.
>
> On occasion I have been sorely vexed when I hastily issued SUBMIT from
> the SJ panel and discovered my sysins truncated to 80 characters.
> SUBMIT from SJ should preserve the attributes of the original job on resubmit.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>  Rocket Software, Inc. and
> subsidiaries ■ 77 Fourth Avenue, Waltham MA
> 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer
> Support:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.ro
> cketsoftware.com%2F=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7C6d52a
> 64e9c7a4b9fa74208d5d7605ba1%7C79544c1eed224879a082b67a9a672aae%7C0%7C0
> %7C636651731237844746=Rqo6fO5u29%2FgAL9zVLgi7b49PpAumBAGP8lSL3xi
> f58%3D=0
> RocketCommunity/RCEmailSupport
> Unsubscribe from Marketing Messages/Manage Your Subscription
> Preferences -
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ro
> cketsoftware.com%2Fmanage-your-email-preferences=02%7C01%7CRScott
> %40ROCKETSOFTWARE.COM%7C6d52a64e9c7a4b9fa74208d5d7605ba1%7C79544c1eed2
> 24879a082b67a9a672aae%7C0%7C0%7C636651731237844746=TNutTRQ70bHf2
> iip2UIVYqK49%2FkJC7rC%2BEkXPwgS6E8%3D=0
> Privacy Policy -
> 

Re: 2 possible RFE --- ISPF & SDSF.

[Rob Scott]

OK, I see now.

JES is storing the post-conversion JCL in the spool dataset that SDSF accesses 
with SJ.

I imagine that there are cross-system and MAS reasons for that rather than 
presenting the original JCL as symbols can change with time, date or local 
system environment.

The system you "SJ" on may not be the system where the job was originally 
submitted from.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ITschak Mugzach
Sent: Thursday, June 21, 2018 11:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2 possible RFE --- ISPF & SDSF.

The issue is applicable for jcl & instream data. The submitted JCL may include 
variables which after substitution may occupy larger space. SJ does not 
substitute. It uses the post substitution version of the JCL.

ITschak

On Thu, Jun 21, 2018 at 11:34 AM, Rob Scott 
wrote:

> >> On occasion I have been sorely vexed when I hastily issued SUBMIT
> >> from
> the SJ panel and discovered my sysins truncated to 80 characters.
> SUBMIT from SJ should preserve the attributes of the original job on resubmit.
>
> I must admit to being slightly puzzled by this statement.
>
> JCL is, by definition, a sequence of 80-byte card images and any
> instream SYSIN will be taken as a sequence of 80-byte characters.
>
> Maybe I am missing something here - please let me know if so.
>
>
> The SDSF "SJ" command acts by allocating the "special" JES dataset
> name for the original JCL and then uses ISPF "EDIF" (without a command
> routine) to display the contents.
>
> The subsequent "SUBMIT" is not under SDSF control - it is the same
> "SUBMIT" command used by ISPF.
>
>
> As far as the "submit as an SDSF action from NP" idea, the best I
> could advise at the moment would be to use the SDSF REXX interface and the "%"
> prefix in the NP column input to execute it.
>
> Rob Scott
> Rocket Software
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Wednesday, June 20, 2018 6:06 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: 2 possible RFE --- ISPF & SDSF.
>
> On Tue, 19 Jun 2018 07:03:21 -0500, John McKown wrote:
> >
> >1) I think it would be nice if I could do a "SUBMIT" command in ISPF
> >option
> >2 when I have a list of UNIX files displayed, rather than members of
> >a
> PDS.
> >Yes, I know that I could do an RYO REXX exec. I just don't wanna {grin}.
> >
> Yes.  Likewise for 3.17.
>
> >2) In SDSF, I quite often want to resubmit a job, as is, which is in
> >the output queue. At present, I do an SJ on it, followed by
> >"submit;end;;". I would also like a SDSF line command, preferably
> >named SUBMIT, which would do this for me. Again, RYO is a possibility, but 
> >... .
> >
> Yes.  And sometimes finding the job ID can be tricky.  Pedro Vera
> suggested screen scraping.  Crude but effective.
>
> On occasion I have been sorely vexed when I hastily issued SUBMIT from
> the SJ panel and discovered my sysins truncated to 80 characters.
> SUBMIT from SJ should preserve the attributes of the original job on resubmit.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>  Rocket Software, Inc. and
> subsidiaries ■ 77 Fourth Avenue, Waltham MA
> 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer
> Support:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.ro
> cketsoftware.com%2F=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7C6d52a
> 64e9c7a4b9fa74208d5d7605ba1%7C79544c1eed224879a082b67a9a672aae%7C0%7C0
> %7C636651731237844746=Rqo6fO5u29%2FgAL9zVLgi7b49PpAumBAGP8lSL3xi
> f58%3D=0
> RocketCommunity/RCEmailSupport
> Unsubscribe from Marketing Messages/Manage Your Subscription
> Preferences -
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ro
> cketsoftware.com%2Fmanage-your-email-preferences=02%7C01%7CRScott
> %40ROCKETSOFTWARE.COM%7C6d52a64e9c7a4b9fa74208d5d7605ba1%7C79544c1eed2
> 24879a082b67a9a672aae%7C0%7C0%7C636651731237844746=TNutTRQ70bHf2
> iip2UIVYqK49%2FkJC7rC%2BEkXPwgS6E8%3D=0
> Privacy Policy -
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ro
> cketsoftware.com%2F=02%7C01%7CRScott%40ROCKETSOFTWARE.COM%7C6d52a
> 64e9c7a4b9fa74208d5d7605ba1%7C79544c1eed224879a082b67a9a672aae%7C0%7C0
> %7C636651731237844746=ifzSB3TuUs47OVs%2Fd1AqgVnAU236Mke2SECIbUeV
> v6Q%3D=0
> company/legal/privacy-policy
> 
>
> This communication and any attachments may contain confidential
> information of Rocket Software, Inc. All unauthorized use, disclosure
> or distribution is prohibited. If you are not the intended recipient,
> please notify Rocket Software immediately and destroy all copies of
> this communication. Thank you.
>
> 

Re: 2 possible RFE --- ISPF & SDSF.

[ITschak Mugzach]

The issue is applicable for jcl & instream data. The submitted JCL may
include variables which after substitution may occupy larger space. SJ does
not substitute. It uses the post substitution version of the JCL.

ITschak

On Thu, Jun 21, 2018 at 11:34 AM, Rob Scott 
wrote:

> >> On occasion I have been sorely vexed when I hastily issued SUBMIT from
> the SJ panel and discovered my sysins truncated to 80 characters.  SUBMIT
> from SJ should preserve the attributes of the original job on resubmit.
>
> I must admit to being slightly puzzled by this statement.
>
> JCL is, by definition, a sequence of 80-byte card images and any instream
> SYSIN will be taken as a sequence of 80-byte characters.
>
> Maybe I am missing something here - please let me know if so.
>
>
> The SDSF "SJ" command acts by allocating the "special" JES dataset name
> for the original JCL and then uses ISPF "EDIF" (without a command routine)
> to display the contents.
>
> The subsequent "SUBMIT" is not under SDSF control - it is the same
> "SUBMIT" command used by ISPF.
>
>
> As far as the "submit as an SDSF action from NP" idea, the best I could
> advise at the moment would be to use the SDSF REXX interface and the "%"
> prefix in the NP column input to execute it.
>
> Rob Scott
> Rocket Software
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, June 20, 2018 6:06 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: 2 possible RFE --- ISPF & SDSF.
>
> On Tue, 19 Jun 2018 07:03:21 -0500, John McKown wrote:
> >
> >1) I think it would be nice if I could do a "SUBMIT" command in ISPF
> >option
> >2 when I have a list of UNIX files displayed, rather than members of a
> PDS.
> >Yes, I know that I could do an RYO REXX exec. I just don't wanna {grin}.
> >
> Yes.  Likewise for 3.17.
>
> >2) In SDSF, I quite often want to resubmit a job, as is, which is in
> >the output queue. At present, I do an SJ on it, followed by
> >"submit;end;;". I would also like a SDSF line command, preferably named
> >SUBMIT, which would do this for me. Again, RYO is a possibility, but ... .
> >
> Yes.  And sometimes finding the job ID can be tricky.  Pedro Vera
> suggested screen scraping.  Crude but effective.
>
> On occasion I have been sorely vexed when I hastily issued SUBMIT from the
> SJ panel and discovered my sysins truncated to 80 characters.  SUBMIT from
> SJ should preserve the attributes of the original job on resubmit.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA
> 02451 ■ Main Office Toll Free Number: +1 855.577.4323
> Contact Customer Support: https://my.rocketsoftware.com/
> RocketCommunity/RCEmailSupport
> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences -
> http://www.rocketsoftware.com/manage-your-email-preferences
> Privacy Policy - http://www.rocketsoftware.com/
> company/legal/privacy-policy
> 
>
> This communication and any attachments may contain confidential
> information of Rocket Software, Inc. All unauthorized use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> notify Rocket Software immediately and destroy all copies of this
> communication. Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: 2 possible RFE --- ISPF & SDSF.

[Rob Scott]

>> On occasion I have been sorely vexed when I hastily issued SUBMIT from the 
>> SJ panel and discovered my sysins truncated to 80 characters.  SUBMIT from 
>> SJ should preserve the attributes of the original job on resubmit.

I must admit to being slightly puzzled by this statement.

JCL is, by definition, a sequence of 80-byte card images and any instream SYSIN 
will be taken as a sequence of 80-byte characters.

Maybe I am missing something here - please let me know if so.


The SDSF "SJ" command acts by allocating the "special" JES dataset name for the 
original JCL and then uses ISPF "EDIF" (without a command routine) to display 
the contents.

The subsequent "SUBMIT" is not under SDSF control - it is the same "SUBMIT" 
command used by ISPF.


As far as the "submit as an SDSF action from NP" idea, the best I could advise 
at the moment would be to use the SDSF REXX interface and the "%" prefix in the 
NP column input to execute it.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, June 20, 2018 6:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 2 possible RFE --- ISPF & SDSF.

On Tue, 19 Jun 2018 07:03:21 -0500, John McKown wrote:
>
>1) I think it would be nice if I could do a "SUBMIT" command in ISPF
>option
>2 when I have a list of UNIX files displayed, rather than members of a PDS.
>Yes, I know that I could do an RYO REXX exec. I just don't wanna {grin}.
>
Yes.  Likewise for 3.17.

>2) In SDSF, I quite often want to resubmit a job, as is, which is in
>the output queue. At present, I do an SJ on it, followed by
>"submit;end;;". I would also like a SDSF line command, preferably named
>SUBMIT, which would do this for me. Again, RYO is a possibility, but ... .
>
Yes.  And sometimes finding the job ID can be tricky.  Pedro Vera suggested 
screen scraping.  Crude but effective.

On occasion I have been sorely vexed when I hastily issued SUBMIT from the SJ 
panel and discovered my sysins truncated to 80 characters.  SUBMIT from SJ 
should preserve the attributes of the original job on resubmit.

-- gil

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: z/OS 2.2 - how to order ?

[Timothy Sipples]

Lionel, have you tried to locate the physical or electronic z/OS 2.2 media
you (or somebody else) ordered and used to upgrade your other system to
z/OS 2.2? That media should still work, and obviously somebody had
possession of that media at some point. Otherwise you wouldn't have a
system running z/OS 2.2.

I should probably mention that IBM eliminated the Single Version Charge
(SVC) periods -- every licensee now has "Multi-Version Measurement" -- so
there shouldn't be any harm in electronically ordering every new release of
your licensed IBM software products, on day one of general availability if
you wish, then at least placing the product images in your secure internal
repository, ready for use. (Better yet: get them installed in at least one
development LPAR.) I think there's only one rare exception to this general
"order every new release of products you already have" advice: if you
happen to be licensing an ancient or older COBOL compiler, and you have not
yet licensed Enterprise COBOL.

If you're ordering and stashing every new release on or soon after the GA
dates, then the End of Marketing (EoM) dates will never matter. If you
think ShopZ ought to support automatic new release ordering, then you can
ask:

https://www.ibm.com/developerworks/rfe


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: 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: Using JCL Symbld and TYPRUN=SCAN

[Andrew Rowley]

On 21/06/2018 12:28 PM, Paul Gilmartin wrote:

I believe that symbols assigned values in a PROC statement or in EXEC PRC=
are local to that PROC (and its children?)  Symbols assigned values in a SET
statement within a PROC are global.  Ugh!  It may be better to eschew SET
within a PROC; rather supply default values in the PROC header.


Symbols in a PROC header don't work consistently. SET is required for 
predictable behaviour.


//PROC1 PROC VVV=
//  EXPORT SYMLIST=VVV
//PSTEP1    EXEC PGM=IEBGENER
//SYSPRINT  DD   DUMMY
//SYSIN DD   DUMMY
//SYSUT1    DD *,SYMBOLS=JCLONLY
SYMBOL VVV=
/*
//SYSUT2    DD   SYSOUT=*
//  PEND
//JSTEP1    EXEC PROC1,VVV=VALUE1
//JSTEP2    EXEC PROC1,VVV=VALUE2

gives IEFC657I THE SYMBOL VVV WAS NOT USED for the first step, but not 
subsequent steps (occurring after the first proc's EXPORT SYMLIST=VVV). 
If symbol VVV is used in the JCL:


//PROC1 PROC VVV=VPWRKA
//  EXPORT SYMLIST=VVV
//PSTEP1    EXEC PGM=IEBGENER
//SYSPRINT  DD   DUMMY
//SYSIN DD   DUMMY
//SYSUT1    DD *,SYMBOLS=JCLONLY
SYMBOL VVV=
/*
//SYSUT2    DD   SYSOUT=*
//DD1   DD   DISP=(OLD,DELETE),UNIT=SYSDA,VOL=SER=
//  PEND
//JSTEP1    EXEC PROC1,VVV=VPWRKB
//JSTEP2    EXEC PROC1,VVV=VPWRKC

gives output:
SYMBOL VVV=
SYMBOL VVV=VPWRKC

The in stream symbol is not substituted in the first step but it is 
substituted correctly in subsequent steps. The JCL symbol is substituted 
as expected.


If you SET VVV= the symbols are substituted as expected:

//PROC1 PROC VVV=VPWRKA
//  EXPORT SYMLIST=VVV
//  SET VVV=
//PSTEP1    EXEC PGM=IEBGENER
//SYSPRINT  DD   DUMMY
//SYSIN DD   DUMMY
//SYSUT1    DD *,SYMBOLS=JCLONLY
SYMBOL VVV=
/*
//SYSUT2    DD   SYSOUT=*
//  PEND
//JSTEP1    EXEC PROC1,VVV=VPWRKB
//JSTEP2    EXEC PROC1,VVV=VPWRKC

SYMBOL VVV=VPWRKB
SYMBOL VVV=VPWRKC



Be careful.  If the SYSIN appears within a PROC and different symbol values
are in effect at various EXEC PRC=... statements, multiple copies of that
SYSIN might need to be supplied for the various proc steps.


If I have
//DD1   DD   DISP=(OLD,DELETE),UNIT=SYSDA,VOL=SER=
I end up with multiple copies of that JCL statement with different 
values. I have no problem with multiple copies of the SYSIN, it is what 
I expected.


--
Andrew Rowley
Black Hill Software
+61 413 302 386

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

Re: Using JCL Symbld and TYPRUN=SCAN

[Vernooij, Kees (ITOPT1) - KLM]

Lucas,

Ok, without SYSAFF, the submitting system has a good chance to handle the job 
first, but I thought you meant to say that this was a rule. 
We have seen the opposite, maybe because of JESs loads, that another system 
than the submitting system handled most of the converts.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lucas Rosalen
> Sent: 21 June, 2018 9:18
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Using JCL Symbld and TYPRUN=SCAN
> 
> Thanks Kees, that's exactly what I tried to say and failed miserably :)
> 
> 
> ---
> *Lucas Rosalen*
> rosalen.lu...@gmail.com / lucas.rosal...@ibm.com
> http://br.linkedin.com/in/lrosalen
> 
> 
> 2018-06-21 9:09 GMT+02:00 Vernooij, Kees (ITOPT1) - KLM <
> kees.verno...@klm.com>:
> 
> > Lucas,
> >
> > I think this is a mis-interpretation of your observations:
> >
> > With /*JOBPARM SYSAFF: the job has affinity to the mentioned system:
> for
> > convertor, interpretor and execution, so here you can be sure of the
> > substituted values.
> >
> > Without /*JOBPARM SYSAFF: the job can be handled by any system in the
> MAS
> > for all 3 phases, so it can be submitted on system1, converted on
> system 2
> > and executed on system 3. You will not know in advance which system
> will do
> > what.
> >
> > Kees.
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu] On
> > > Behalf Of Lucas Rosalen
> > > Sent: 21 June, 2018 8:57
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Using JCL Symbld and TYPRUN=SCAN
> > >
> > > On the side topic...
> > >
> > > Based on our latest "experience":
> > > - without /*JOBPARM SYSAFF: symbols got resolved in the submitting
> LPAR,
> > > which caused some problems as they were different from the executing
> > > LPAR
> > > (and used as a dataset qualifier);
> > > - with /*JOBPARM SYSAFF: symbols are resolved in the executing LPAR
> > > (even
> > > with SYSAFF=*);
> > >
> > > I also don't know about the documentation, just learned from a
> colleague
> > > that had worked on our issue.
> > >
> > >
> > > 
> 
> > > ---
> > > *Lucas Rosalen*
> > > rosalen.lu...@gmail.com / lucas.rosal...@ibm.com
> > > http://br.linkedin.com/in/lrosalen
> > >
> > >
> > > 2018-06-21 8:16 GMT+02:00 Elardus Engelbrecht <
> > > elardus.engelbre...@sita.co.za>:
> > >
> > > > Andrew Rowley wrote:
> > > >
> > > > >> to this one (clear out the SYSIN - at least for IDCAMS SYSIN
> and
> > > place
> > > > it in a JCL comment):
> > > > >> //* DELETE KVPO.MOST.DB2DATA.
> > > > >> //SYSIN DD *,SYMBOLS=(JCLONLY,X)
> > > > >> SET MAXCC = 0
> > > >
> > > > >Unfortunately that may not work because the symbols in SYSIN are
> not
> > > > substituted the same way as in the regular JCL. I have been
> playing
> > > around
> > > > with them and my conclusion is that the whole feature seems to
> have
> > > been
> > > > badly thought out.
> > > >
> > > > Thanks for this reminder. I remember that I also discovered that
> > > > substition is not always correct, but I was too busy to follow it
> up.
> > > >
> > > >
> > > > >If IBM had omitted some features, e.g. system symbols on the
> > > execution
> > > > system and instead substituted the symbols at the same time as the
> > > symbols
> > > > in the rest of the JCL, they would have lost maybe 10% of the
> > > usefulness
> > > > but decreased the astonishment by 90%.
> > > >
> > > > Which brings another question - I am just curious - Where are the
> > > Symbols
> > > > resolved? At the submitting LPAR or at the Executing LPAR? Or is
> the
> > > > '/*JOBPARM SYSAFF=' used to determine the LPAR where the
> Symbols
> > > are
> > > > to be resolved/substituted?
> > > >
> > > > I am asking, because there are Symbols unique for a LPAR, like
> this:
> > > >
> > > > D SYMBOLS
> > > > IEA007I STATIC SYSTEM SYMBOL VALUES
> > > >= "2"
> > > >   = "C4"   <--- Unique per LPAR
> > > >= "" <--- Unique per LPAR
> > > >
> > > > If that is documented, I must missed it somewhere ...
> > > >
> > > > Sorry for this topic drift, but ... ;-)
> > > >
> > > > Groete / Greetings
> > > > Elardus Engelbrecht
> > > >
> > > > --
> 
> > > > 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: Using JCL Symbld and TYPRUN=SCAN

[Lucas Rosalen]

Thanks Kees, that's exactly what I tried to say and failed miserably :)

---
*Lucas Rosalen*
rosalen.lu...@gmail.com / lucas.rosal...@ibm.com
http://br.linkedin.com/in/lrosalen


2018-06-21 9:09 GMT+02:00 Vernooij, Kees (ITOPT1) - KLM <
kees.verno...@klm.com>:

> Lucas,
>
> I think this is a mis-interpretation of your observations:
>
> With /*JOBPARM SYSAFF: the job has affinity to the mentioned system: for
> convertor, interpretor and execution, so here you can be sure of the
> substituted values.
>
> Without /*JOBPARM SYSAFF: the job can be handled by any system in the MAS
> for all 3 phases, so it can be submitted on system1, converted on system 2
> and executed on system 3. You will not know in advance which system will do
> what.
>
> Kees.
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Lucas Rosalen
> > Sent: 21 June, 2018 8:57
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Using JCL Symbld and TYPRUN=SCAN
> >
> > On the side topic...
> >
> > Based on our latest "experience":
> > - without /*JOBPARM SYSAFF: symbols got resolved in the submitting LPAR,
> > which caused some problems as they were different from the executing
> > LPAR
> > (and used as a dataset qualifier);
> > - with /*JOBPARM SYSAFF: symbols are resolved in the executing LPAR
> > (even
> > with SYSAFF=*);
> >
> > I also don't know about the documentation, just learned from a colleague
> > that had worked on our issue.
> >
> >
> > 
> > ---
> > *Lucas Rosalen*
> > rosalen.lu...@gmail.com / lucas.rosal...@ibm.com
> > http://br.linkedin.com/in/lrosalen
> >
> >
> > 2018-06-21 8:16 GMT+02:00 Elardus Engelbrecht <
> > elardus.engelbre...@sita.co.za>:
> >
> > > Andrew Rowley wrote:
> > >
> > > >> to this one (clear out the SYSIN - at least for IDCAMS SYSIN and
> > place
> > > it in a JCL comment):
> > > >> //* DELETE KVPO.MOST.DB2DATA.
> > > >> //SYSIN DD *,SYMBOLS=(JCLONLY,X)
> > > >> SET MAXCC = 0
> > >
> > > >Unfortunately that may not work because the symbols in SYSIN are not
> > > substituted the same way as in the regular JCL. I have been playing
> > around
> > > with them and my conclusion is that the whole feature seems to have
> > been
> > > badly thought out.
> > >
> > > Thanks for this reminder. I remember that I also discovered that
> > > substition is not always correct, but I was too busy to follow it up.
> > >
> > >
> > > >If IBM had omitted some features, e.g. system symbols on the
> > execution
> > > system and instead substituted the symbols at the same time as the
> > symbols
> > > in the rest of the JCL, they would have lost maybe 10% of the
> > usefulness
> > > but decreased the astonishment by 90%.
> > >
> > > Which brings another question - I am just curious - Where are the
> > Symbols
> > > resolved? At the submitting LPAR or at the Executing LPAR? Or is the
> > > '/*JOBPARM SYSAFF=' used to determine the LPAR where the Symbols
> > are
> > > to be resolved/substituted?
> > >
> > > I am asking, because there are Symbols unique for a LPAR, like this:
> > >
> > > D SYMBOLS
> > > IEA007I STATIC SYSTEM SYMBOL VALUES
> > >= "2"
> > >   = "C4"   <--- Unique per LPAR
> > >= "" <--- Unique per LPAR
> > >
> > > If that is documented, I must missed it somewhere ...
> > >
> > > Sorry for this topic drift, but ... ;-)
> > >
> > > Groete / Greetings
> > > Elardus Engelbrecht
> > >
> > > --
> > > 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 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 

Re: Using JCL Symbld and TYPRUN=SCAN

[Vernooij, Kees (ITOPT1) - KLM]

Lucas,

I think this is a mis-interpretation of your observations:

With /*JOBPARM SYSAFF: the job has affinity to the mentioned system: for 
convertor, interpretor and execution, so here you can be sure of the 
substituted values.

Without /*JOBPARM SYSAFF: the job can be handled by any system in the MAS for 
all 3 phases, so it can be submitted on system1, converted on system 2 and 
executed on system 3. You will not know in advance which system will do what.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lucas Rosalen
> Sent: 21 June, 2018 8:57
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Using JCL Symbld and TYPRUN=SCAN
> 
> On the side topic...
> 
> Based on our latest "experience":
> - without /*JOBPARM SYSAFF: symbols got resolved in the submitting LPAR,
> which caused some problems as they were different from the executing
> LPAR
> (and used as a dataset qualifier);
> - with /*JOBPARM SYSAFF: symbols are resolved in the executing LPAR
> (even
> with SYSAFF=*);
> 
> I also don't know about the documentation, just learned from a colleague
> that had worked on our issue.
> 
> 
> 
> ---
> *Lucas Rosalen*
> rosalen.lu...@gmail.com / lucas.rosal...@ibm.com
> http://br.linkedin.com/in/lrosalen
> 
> 
> 2018-06-21 8:16 GMT+02:00 Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za>:
> 
> > Andrew Rowley wrote:
> >
> > >> to this one (clear out the SYSIN - at least for IDCAMS SYSIN and
> place
> > it in a JCL comment):
> > >> //* DELETE KVPO.MOST.DB2DATA.
> > >> //SYSIN DD *,SYMBOLS=(JCLONLY,X)
> > >> SET MAXCC = 0
> >
> > >Unfortunately that may not work because the symbols in SYSIN are not
> > substituted the same way as in the regular JCL. I have been playing
> around
> > with them and my conclusion is that the whole feature seems to have
> been
> > badly thought out.
> >
> > Thanks for this reminder. I remember that I also discovered that
> > substition is not always correct, but I was too busy to follow it up.
> >
> >
> > >If IBM had omitted some features, e.g. system symbols on the
> execution
> > system and instead substituted the symbols at the same time as the
> symbols
> > in the rest of the JCL, they would have lost maybe 10% of the
> usefulness
> > but decreased the astonishment by 90%.
> >
> > Which brings another question - I am just curious - Where are the
> Symbols
> > resolved? At the submitting LPAR or at the Executing LPAR? Or is the
> > '/*JOBPARM SYSAFF=' used to determine the LPAR where the Symbols
> are
> > to be resolved/substituted?
> >
> > I am asking, because there are Symbols unique for a LPAR, like this:
> >
> > D SYMBOLS
> > IEA007I STATIC SYSTEM SYMBOL VALUES
> >= "2"
> >   = "C4"   <--- Unique per LPAR
> >= "" <--- Unique per LPAR
> >
> > If that is documented, I must missed it somewhere ...
> >
> > Sorry for this topic drift, but ... ;-)
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> >
> > --
> > 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 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: Using JCL Symbld and TYPRUN=SCAN

[Lucas Rosalen]

On the side topic...

Based on our latest "experience":
- without /*JOBPARM SYSAFF: symbols got resolved in the submitting LPAR,
which caused some problems as they were different from the executing LPAR
(and used as a dataset qualifier);
- with /*JOBPARM SYSAFF: symbols are resolved in the executing LPAR (even
with SYSAFF=*);

I also don't know about the documentation, just learned from a colleague
that had worked on our issue.


---
*Lucas Rosalen*
rosalen.lu...@gmail.com / lucas.rosal...@ibm.com
http://br.linkedin.com/in/lrosalen


2018-06-21 8:16 GMT+02:00 Elardus Engelbrecht <
elardus.engelbre...@sita.co.za>:

> Andrew Rowley wrote:
>
> >> to this one (clear out the SYSIN - at least for IDCAMS SYSIN and place
> it in a JCL comment):
> >> //* DELETE KVPO.MOST.DB2DATA.
> >> //SYSIN DD *,SYMBOLS=(JCLONLY,X)
> >> SET MAXCC = 0
>
> >Unfortunately that may not work because the symbols in SYSIN are not
> substituted the same way as in the regular JCL. I have been playing around
> with them and my conclusion is that the whole feature seems to have been
> badly thought out.
>
> Thanks for this reminder. I remember that I also discovered that
> substition is not always correct, but I was too busy to follow it up.
>
>
> >If IBM had omitted some features, e.g. system symbols on the execution
> system and instead substituted the symbols at the same time as the symbols
> in the rest of the JCL, they would have lost maybe 10% of the usefulness
> but decreased the astonishment by 90%.
>
> Which brings another question - I am just curious - Where are the Symbols
> resolved? At the submitting LPAR or at the Executing LPAR? Or is the
> '/*JOBPARM SYSAFF=' used to determine the LPAR where the Symbols are
> to be resolved/substituted?
>
> I am asking, because there are Symbols unique for a LPAR, like this:
>
> D SYMBOLS
> IEA007I STATIC SYSTEM SYMBOL VALUES
>= "2"
>   = "C4"   <--- Unique per LPAR
>= "" <--- Unique per LPAR
>
> If that is documented, I must missed it somewhere ...
>
> Sorry for this topic drift, but ... ;-)
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> 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: Using JCL Symbld and TYPRUN=SCAN

[Elardus Engelbrecht]

Andrew Rowley wrote:

>> to this one (clear out the SYSIN - at least for IDCAMS SYSIN and place it in 
>> a JCL comment):
>> //* DELETE KVPO.MOST.DB2DATA.
>> //SYSIN DD *,SYMBOLS=(JCLONLY,X)
>> SET MAXCC = 0

>Unfortunately that may not work because the symbols in SYSIN are not 
>substituted the same way as in the regular JCL. I have been playing around 
>with them and my conclusion is that the whole feature seems to have been badly 
>thought out.

Thanks for this reminder. I remember that I also discovered that substition is 
not always correct, but I was too busy to follow it up.


>If IBM had omitted some features, e.g. system symbols on the execution system 
>and instead substituted the symbols at the same time as the symbols in the 
>rest of the JCL, they would have lost maybe 10% of the usefulness but 
>decreased the astonishment by 90%.

Which brings another question - I am just curious - Where are the Symbols 
resolved? At the submitting LPAR or at the Executing LPAR? Or is the '/*JOBPARM 
SYSAFF=' used to determine the LPAR where the Symbols are to be 
resolved/substituted?

I am asking, because there are Symbols unique for a LPAR, like this:

D SYMBOLS  
IEA007I STATIC SYSTEM SYMBOL VALUES
   = "2"  
  = "C4"   <--- Unique per LPAR   
   = "" <--- Unique per LPAR   

If that is documented, I must missed it somewhere ...

Sorry for this topic drift, but ... ;-)

Groete / Greetings
Elardus Engelbrecht

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