Re: Special characters in passwords from non-US computers (Italy)

[Tom Brennan]

This is just some wild guessing and assumptions:  In Windows there's a 
Language option in the Control Panel where you can specify Italy and 
many other places I've never been to.  I just did that and the top row 
on my keyboard comes out like this when I hold the shift key:


EN English:  !@#$%^&*()_+
IT Italy:!"£$%&/()=?^

So if you were using a PC belonging to an Italian, maybe the odd 
characters were typed but you couldn't tell because of the asterisk echo 
in a password field.  If that's the case, then yes, copy/paste should 
work because it isn't the codepage or hex code that is changing between 
countries (non-mainframe), it's the keyboard.  But I would have thought 
the printed text on an Italian keyboard would also reflect these 
changes.  So maybe this isn't such a good theory after all.


John Mattson wrote:

I try to include the special characters on standard US keyboards in
some of my passwords.  On a trip it Italy, I attempted to login to some
websites (not anything very secure of course) and I found that the
passwords always failed.  I could only conclude that the local hex encoding
for the ! @ and/or # characters was different from what it is on a US
keyboard.  Now since these are in pretty common use, especially @ and #, I
thought they would be no problem, but I was wrong.
Now, I could carry my passwords on a US thumb drive and paste them, but
I would rather find out what special characters are common to most European
keyboards, and select from those.  I have not found anything helpful in
Google.   Does anyone have and information on this?

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




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

Re: Special characters in passwords from non-US computers (Italy)

[Paul Gilmartin]

On Mon, 16 May 2016 22:11:32 -0300, Clark Morris  wrote:

>[Default] On 16 May 2016 14:33:18 (John Mattson) wrote:
>
>>I...  On a trip it Italy, I attempted to login to some
>>websites ...
>
>The @ sign,# sign and $ sign are problematic within EBCDIC since they
>are nationals and vary by country, the hex value for a $ is used for
>the pound sterling sign in Britain and the Yen sign in  Japan.  You
>need to use special characters that are both stable across all EBCDIC
>code pages and all ISO (ASCII) code pages and are acceptable as input
>for passwords.
>
... And meet your admins' and auditors' criteria for password strength.

https://xkcd.com/936/

But if the OP was trying to login to websites, EBCDIC should hardly
have been a consideration.  (Unless he was using an EBCDIC terminal
to access an ASCII website.)

-- gil

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

Re: What was a 3314? (was: Whither VIO)

[Edward Finnell]

Lots of OEM's changed 1st digit but kept geometry.CDC, Memorex, Telex,  
Amdahl, StoraeTek.
 
 
In a message dated 5/16/2016 6:40:33 P.M. Central Daylight Time,  
charl...@mcn.org writes:

You are  going to get some replies on  that!


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

Re: Special characters in passwords from non-US computers (Italy)

[Clark Morris]

[Default] On 16 May 2016 14:33:18 -0700, in bit.listserv.ibm-main
johnmattson...@gmail.com (John Mattson) wrote:

>I try to include the special characters on standard US keyboards in
>some of my passwords.  On a trip it Italy, I attempted to login to some
>websites (not anything very secure of course) and I found that the
>passwords always failed.  I could only conclude that the local hex encoding
>for the ! @ and/or # characters was different from what it is on a US
>keyboard.  Now since these are in pretty common use, especially @ and #, I
>thought they would be no problem, but I was wrong.

The @ sign,# sign and $ sign are problematic within EBCDIC since they
are nationals and vary by country, the hex value for a $ is used for
the pound sterling sign in Britain and the Yen sign in  Japan.  You
need to use special characters that are both stable across all EBCDIC
code pages and all ISO (ASCII) code pages and are acceptable as input
for passwords.

Clark Morris  
>Now, I could carry my passwords on a US thumb drive and paste them, but
>I would rather find out what special characters are common to most European
>keyboards, and select from those.  I have not found anything helpful in
>Google.   Does anyone have and information on this?
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: What was a 3314? (was: Whither VIO)

[Rugen, Len]

The real odd balls, 3340, 3344, 3370 & 3375's :-)

3340's had the coolest looking removable disk assembly.

I suspected that the 3344 was a code-hacked 3350, it just carved 4 70Mb disks 
out of the larger physical disk.  

Len Rugen

University of Missouri
Division of Information Technology
Systems & Operations - Metrics & Automation Team


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Steve Thompson [ste...@copper.net]
Sent: Monday, May 16, 2016 6:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What was a 3314? (was: Whither VIO)

2314, 2419, 2311, these are just a few of the "IBM" DASD that
I've had the pleasure of working with. I've forgotten the drum
device numbers and the noodle snatcher model number.

Regards,
Steve Thompson

On 05/16/2016 07:24 PM, Jesse 1 Robinson wrote:
> OK, the sleeping dog wants some attention. Before my first reply, I carefully 
> Googled device type 2314 to verify the number. Then I typed '3314' because 
> who has ever worked with DASD that started with something other than '33'? 
> 2314 remained valid in the IODEVICE macro long, long after the final one 
> disappeared into the sunset. And as I said, I was advised to use it for VIO 
> because of 'device architecture', whatever that meant. Track size, I guess, 
> from what others have posted.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Clark Morris
> Sent: Monday, May 16, 2016 4:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: What was a 3314? (was: Whither VIO)
>
> [Default] On 16 May 2016 07:01:50 -0700, in bit.listserv.ibm-main 
> jcal...@narsil.org (Jerry Callen) wrote:
>
>> In the "Whither VIO" thread, J.O.Skip Robinson wrote:
>>
>>>   In a previous life, we defined VIO (I believe) to device 3314 even
>>> though we had none left on the floor
>>
>> That's a device type I've never heard of, and the Google knows not of. Could 
>> this be a typo for "2314"?
>
> I believe the OP meant 2314 which had 7294 bytes per track.  It was a 
> removable disk.
>
> Clark Morris
>>
>> -- Jerry
>
> --
> 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: What was a 3314? (was: Whither VIO)

[Steve Thompson]

2314, 2419, 2311, these are just a few of the "IBM" DASD that 
I've had the pleasure of working with. I've forgotten the drum 
device numbers and the noodle snatcher model number.


Regards,
Steve Thompson

On 05/16/2016 07:24 PM, Jesse 1 Robinson wrote:

OK, the sleeping dog wants some attention. Before my first reply, I carefully 
Googled device type 2314 to verify the number. Then I typed '3314' because who 
has ever worked with DASD that started with something other than '33'? 2314 
remained valid in the IODEVICE macro long, long after the final one disappeared 
into the sunset. And as I said, I was advised to use it for VIO because of 
'device architecture', whatever that meant. Track size, I guess, from what 
others have posted.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clark Morris
Sent: Monday, May 16, 2016 4:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What was a 3314? (was: Whither VIO)

[Default] On 16 May 2016 07:01:50 -0700, in bit.listserv.ibm-main 
jcal...@narsil.org (Jerry Callen) wrote:


In the "Whither VIO" thread, J.O.Skip Robinson wrote:


  In a previous life, we defined VIO (I believe) to device 3314 even
though we had none left on the floor


That's a device type I've never heard of, and the Google knows not of. Could this be a 
typo for "2314"?


I believe the OP meant 2314 which had 7294 bytes per track.  It was a removable 
disk.

Clark Morris


-- Jerry


--
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: What was a 3314? (was: Whither VIO)

[Charles Mills]

> who has ever worked with DASD that started with something other than '33'?

You are going to get some replies on that!

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jesse 1 Robinson
Sent: Monday, May 16, 2016 4:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What was a 3314? (was: Whither VIO)

OK, the sleeping dog wants some attention. Before my first reply, I
carefully Googled device type 2314 to verify the number. Then I typed '3314'
because who has ever worked with DASD that started with something other than
'33'? 2314 remained valid in the IODEVICE macro long, long after the final
one disappeared into the sunset. And as I said, I was advised to use it for
VIO because of 'device architecture', whatever that meant. Track size, I
guess, from what others have posted. 

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

Re: What was a 3314? (was: Whither VIO)

[Jesse 1 Robinson]

OK, the sleeping dog wants some attention. Before my first reply, I carefully 
Googled device type 2314 to verify the number. Then I typed '3314' because who 
has ever worked with DASD that started with something other than '33'? 2314 
remained valid in the IODEVICE macro long, long after the final one disappeared 
into the sunset. And as I said, I was advised to use it for VIO because of 
'device architecture', whatever that meant. Track size, I guess, from what 
others have posted. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clark Morris
Sent: Monday, May 16, 2016 4:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What was a 3314? (was: Whither VIO)

[Default] On 16 May 2016 07:01:50 -0700, in bit.listserv.ibm-main 
jcal...@narsil.org (Jerry Callen) wrote:

>In the "Whither VIO" thread, J.O.Skip Robinson wrote:
>
>>  In a previous life, we defined VIO (I believe) to device 3314 even 
>> though we had none left on the floor
>
>That's a device type I've never heard of, and the Google knows not of. Could 
>this be a typo for "2314"?

I believe the OP meant 2314 which had 7294 bytes per track.  It was a removable 
disk.

Clark Morris
>
>-- Jerry

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

Re: What was a 3314? (was: Whither VIO)

[Clark Morris]

[Default] On 16 May 2016 07:01:50 -0700, in bit.listserv.ibm-main
jcal...@narsil.org (Jerry Callen) wrote:

>In the "Whither VIO" thread, J.O.Skip Robinson wrote:
>
>>  In a previous life, we defined VIO (I believe) to device 3314 even though 
>> we had none left on the floor
>
>That's a device type I've never heard of, and the Google knows not of. Could 
>this be a typo for "2314"?

I believe the OP meant 2314 which had 7294 bytes per track.  It was a
removable disk.

Clark Morris
>
>-- Jerry
>
>--
>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: Questions about EZAZSSI

[Jesse 1 Robinson]

Again, from a non-expert, I can only say how we do it. We explicitly start 
TN3270 and FTPD via SA.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, May 16, 2016 3:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Questions about EZAZSSI

I am out on a limb here talking about stuff I don't know about but isn't there 
a configuration option in TCP to start various related tasks like
TN3270 and FTPD? Is the start command in there?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Yuhas
Sent: Monday, May 16, 2016 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Questions about EZAZSSI

I am preparing for the first IPL of z/OS 2.2.

I was reviewing the COMMND00 PARMLIB member and found a start command for 
EZAZSSI.
 I am totally unfamiliar with this address space.  I googled it and found that 
EZAZSSI starts the TNF & VMCF address spaces.

I reviewed the log from Saturday night's IPL and found this associated message 
-  'EZY6043I TNF Start Initiated'.  I looked up the message:
Explanation:  A TNF address space start was issued.
System Action:  EZAZSSI continues; start of TNF expected.

Of course, a similar message was issued for VMCF.

I check our PARMLIB concatenation and did not find a start command for EZAZSSI; 
and, I know the IPL procedure did not start EZAZSSI?

So, how did EZAZSSI get started?

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

Re: z890 in my basement

[Ted MacNEIL]

Sorry, my fat fingers

He deserves it; if not more!

It was a vote of confidence.

-teD
  Original Message  
From: zMan
Sent: Sunday, May 15, 2016 22:15
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: z890 in my basement

Ted, can you translate that post into English please? :)

On Sun, May 15, 2016 at 8:22 PM, Ted MacNEIL <
010d3e53f7a3-dmarc-requ...@listserv.ua.edu> wrote:

> He deserves the internship of ot more!
>
> -teD
> Original Message
> From: Mark Post
> Sent: Tuesday, April 19, 2016 16:00
> To: IBM-MAIN@LISTSERV.UA.EDU
> Reply To: IBM Mainframe Discussion List
> Subject: Re: z890 in my basement
>
> >>> On 4/19/2016 at 03:11 PM, Mike Schwab  wrote:
> > https://twitter.com/ConnorKrukosky/status/722218600975724544
> > Connor turned 19 and accepted an IBM Internship.
>
> This makes me happy. :)
>
> I'm really glad to see the contacts he made at SHARE are already taking
> him places.
>
>
> Mark Post
>
> --
> 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: So long everyone!!!

[Steve Horein]

I always think it bittersweet when good folks leave the mainframe area -
Sorry to see years of experience leaving the knowledge pool, but glad to
see people reaping the rewards of a fruitful career.
Enjoy your time!

On Mon, May 16, 2016 at 1:04 PM, Norman.Hollander <
norman.hollan...@desertwiz.biz> wrote:

> All the best, Ken.  On the same retirement train starting 6/6.
> zNorman
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ken Hume
> Sent: Monday, May 16, 2016 10:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: So long everyone!!!
>
> Hi all,
>
> I will be unsubscribing from the list in a few days as I leave IBM. Once
> out
> of here I have no plans to ever see a mainframe, or any non personal
> computer for that matter, ever again.
>
> I just wanted to thank everyone for the posts over the last few years.
> Even if they were not related to what I do, I always felt as if I learned
> something.
>
> So long all!!
>
> Ken Hume
>
> Former Product Manager, IBM Application Performance Analyzer
>
> Former CST Team Representative
>
> Former PD Tools Client Advocate
>
> --
> 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: Questions about EZAZSSI

[Charles Mills]

I am out on a limb here talking about stuff I don't know about but isn't
there a configuration option in TCP to start various related tasks like
TN3270 and FTPD? Is the start command in there?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mark Yuhas
Sent: Monday, May 16, 2016 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Questions about EZAZSSI

I am preparing for the first IPL of z/OS 2.2.

I was reviewing the COMMND00 PARMLIB member and found a start command for
EZAZSSI.
 I am totally unfamiliar with this address space.  I googled it and found
that EZAZSSI starts the TNF & VMCF address spaces.

I reviewed the log from Saturday night's IPL and found this associated
message -  'EZY6043I TNF Start Initiated'.  I looked up the message:
Explanation:  A TNF address space start was issued.
System Action:  EZAZSSI continues; start of TNF expected.

Of course, a similar message was issued for VMCF.

I check our PARMLIB concatenation and did not find a start command for
EZAZSSI; and, I know the IPL procedure did not start EZAZSSI?

So, how did EZAZSSI get started?

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

Re: SYNCSORT IFTHEN with OVERLAY: how to specify RDW?

[Farley, Peter x23353]

Double thanks Bill, once for the answer and again for the reply.  I also got 
that same advice privately from another expert source, but thanks to you I 
don't have to post the follow-up.  Good job!

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Woodger
Sent: Monday, May 16, 2016 4:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SYNCSORT IFTHEN with OVERLAY: how to specify RDW?

Second things first. Your input data is 1,4,5. An RDW plus all the data from 
position five to the end of the record. There is no need for a WHEN=NONE to 
BUILD an identical record to the one that already exists.

Your problem is that you have not supplied any "column numbers" for your 
OVERLAY, so you automatically use the default column, which is one. From 
position one you put two bytes starting at 76 (byte 72 of data), then a 6B, 
then one byte from 1644, then a C, then one byte from 1668, then a C, then one 
byte from 1789, then a C, the one byte from 1812, then a C, then follows the 
rest of the data on your record undisturbed.

I think what you probably want is this:

 OPTION COPY  
 OUTREC IFTHEN=(WHEN=(05,02,CH,NE,X'',AND,
   05,02,CH,NE,X''),
OVERLAY=(76:C'6B',   
 1644:C'C',1668:C'C',  
 1789:C'C',1812:C'C')) 

As to your question, you are correct, you cannot change the RDW with an OVERLAY 
(or a PUSH, from WHEN=GROUP). 


On Monday, 16 May 2016 21:20:58 UTC+2, Farley, Peter x23353  wrote:
> I am using SYNCSORT to modify VB records (LRECL is > 2000), and this is my 
> SYSIN:
> 
> OPTION COPY  
> OUTREC IFTHEN=(WHEN=(05,02,CH,NE,X'',AND,
>   05,02,CH,NE,X'') ,  
>OVERLAY=(76,2,C'6B',   
> 1644,1,C'C',1668,1,C'C',  
> 1789,1,C'C',1812,1,C'C')),
> IFTHEN=(WHEN=NONE,BUILD=(1,4,5))  
> 
> However, I get the following error message:
> 
> WER235A  OUTREC   RDW NOT INCLUDED
> 
> I cannot see from the SYNCSORT documentation of the OVERLAY sub-parameter how 
> to legally specify the RDW field in the OPVERLAY value, since the doc clearly 
> says:
> 
> "The RDW cannot be overlaid." (page 2-198 in "SYNCSORT MFX for z/OS Release 
> 1.4")
> 
> Can anyone point me to the right way to specify the RDW here?
> 
> If it matters, the SYNCSORT version is:
> 
> SYNCSORT FOR Z/OS  1.4.1.0N
> 
> TIA for any assistance you can provide.
> 
> Peter

--


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


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

Re: Dataset space information

[Ted MacNEIL]

VTOCIX is the index -- required for SMS, along with the VVDS. The VTOC is 
unnamed.

-teD
  Original Message  
From: michelbutz
Sent: Tuesday, May 3, 2016 11:29
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Dataset space information

Hi

I need to obtain dataset space information 

I have been looking at the DFSMS advanced services and there seems like a few 
away of going about this 

The OBTAIN and camlist seems like the easiest 
As all it needs is a dataset name and volser

The CVAF macros seems like the must current
But I would need to get (if I am using for instance)
CVAFDIR the DEB of the VTOC


BTW is the VTOC dataset name SYS1.VTOCIX. (Volser) ?

I guess that would mean allocating and opening it

Any suggestions ?

Sent from my iPhone
--
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: Questions about EZAZSSI

[Greg Shirey]

I'm confused - you found a start command for EZAZSSI in COMMND00 or you didn't? 
 

Greg Shirey
Ben E. Keith Company 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Yuhas
Sent: Monday, May 16, 2016 3:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Questions about EZAZSSI

I am preparing for the first IPL of z/OS 2.2.

I was reviewing the COMMND00 PARMLIB member and found a start command for 
EZAZSSI.
 I am totally unfamiliar with this address space.  I googled it and found that 
EZAZSSI starts the TNF & VMCF address spaces.

I reviewed the log from Saturday night's IPL and found this associated message 
-  'EZY6043I TNF Start Initiated'.  I looked up the message:
Explanation:  A TNF address space start was issued.
System Action:  EZAZSSI continues; start of TNF expected.

Of course, a similar message was issued for VMCF.

I check our PARMLIB concatenation and did not find a start command for  
EZAZSSI; and, I know the IPL procedure did not start EZAZSSI?

So, how did EZAZSSI get started?

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

Re: Special characters in passwords from non-US computers (Italy)

[Charles Mills]

Google 

A problem is not just that the hex associated with a given graphic may be 
different, but also issued of the ASCII graphic, the Italian keyboard mapping, 
and the ASCII to EBCDIC translation table.

! is always a big problem!

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Mattson
Sent: Monday, May 16, 2016 2:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Special characters in passwords from non-US computers (Italy)

I try to include the special characters on standard US keyboards in some of 
my passwords.  On a trip it Italy, I attempted to login to some websites (not 
anything very secure of course) and I found that the passwords always failed.  
I could only conclude that the local hex encoding for the ! @ and/or # 
characters was different from what it is on a US keyboard.  Now since these are 
in pretty common use, especially @ and #, I thought they would be no problem, 
but I was wrong.
Now, I could carry my passwords on a US thumb drive and paste them, but I 
would rather find out what special characters are common to most European 
keyboards, and select from those.  I have not found anything helpful in
Google.   Does anyone have and information on this?

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

Re: Questions about EZAZSSI

[Jesse 1 Robinson]

Can't say how your EZAZSSI got started, but that task is as old as the hills. 
We start it at IPL time with System Automation. And before that with our 
predecessor automation product. It may not be necessary to start EZAZSSI 
explicitly; I'm not a network guy. But it's been SOP here for a long time.

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Yuhas
Sent: Monday, May 16, 2016 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Questions about EZAZSSI

I am preparing for the first IPL of z/OS 2.2.

I was reviewing the COMMND00 PARMLIB member and found a start command for 
EZAZSSI.
 I am totally unfamiliar with this address space.  I googled it and found that 
EZAZSSI starts the TNF & VMCF address spaces.

I reviewed the log from Saturday night's IPL and found this associated message 
-  'EZY6043I TNF Start Initiated'.  I looked up the message:
Explanation:  A TNF address space start was issued.
System Action:  EZAZSSI continues; start of TNF expected.

Of course, a similar message was issued for VMCF.

I check our PARMLIB concatenation and did not find a start command for  
EZAZSSI; and, I know the IPL procedure did not start EZAZSSI?

So, how did EZAZSSI get started?

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

Special characters in passwords from non-US computers (Italy)

[John Mattson]

I try to include the special characters on standard US keyboards in
some of my passwords.  On a trip it Italy, I attempted to login to some
websites (not anything very secure of course) and I found that the
passwords always failed.  I could only conclude that the local hex encoding
for the ! @ and/or # characters was different from what it is on a US
keyboard.  Now since these are in pretty common use, especially @ and #, I
thought they would be no problem, but I was wrong.
Now, I could carry my passwords on a US thumb drive and paste them, but
I would rather find out what special characters are common to most European
keyboards, and select from those.  I have not found anything helpful in
Google.   Does anyone have and information on this?

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

Re: So long everyone!!!

[Edward Finnell]

I little travelin' music for the guys. Onea anna twoa...
 
https://www.youtube.com/watch?v=KKsDQaTkkxo
 
 
In a message dated 5/16/2016 1:11:23 P.M. Central Daylight Time,  
norman.hollan...@desertwiz.biz writes:

All the  best, Ken.  On the same retirement train starting 6/6.   


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

Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

[Paul Gilmartin]

On Mon, 16 May 2016 19:47:43 +, Jerry Whitteridge wrote:

>I'd reply to the Auditor "Please define Admin access as there is no one 
>privilege  that grants all access"
>
"If there's more than one, then, all of them!"

(The Wookie wins.)

-- gil

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

Re: [EXTERNAL] Re: smp/e sha-2 support?

[Paul Gilmartin]

On Mon, 16 May 2016 14:25:38 -0500, Dyck, Lionel B. (TRA) wrote:

>What's going to happen is that IBM will not support SHA-2 (or -3) and every 
>shop with any degree of security (hipaa, sox, dod, ...) will cease to be able 
>to use the internet delivery option. Being told to create an RFE for something 
>that is obvious is troubling and to be told that it doesn't matter is worse. 
>This is not my first shop where auditors dictate a higher level of security 
>than most think required but they are following guidelines from someone higher 
>up that can't be argued with.
>
>Somehow I don't think I'm the first to raise this nor will I be the last.
>
"Let the Wookie win!"  But what happens when there are Wookies on both
teams and you're just trying to do your job?

-- gil

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

SYNCSORT IFTHEN with OVERLAY: how to specify RDW?

[Bill Woodger]

Second things first. Your input data is 1,4,5. An RDW plus all the data from 
position five to the end of the record. There is no need for a WHEN=NONE to 
BUILD an identical record to the one that already exists.

Your problem is that you have not supplied any "column numbers" for your 
OVERLAY, so you automatically use the default column, which is one. From 
position one you put two bytes starting at 76 (byte 72 of data), then a 6B, 
then one byte from 1644, then a C, then one byte from 1668, then a C, then one 
byte from 1789, then a C, the one byte from 1812, then a C, then follows the 
rest of the data on your record undisturbed.

I think what you probably want is this:

 OPTION COPY  
 OUTREC IFTHEN=(WHEN=(05,02,CH,NE,X'',AND,
   05,02,CH,NE,X''),
OVERLAY=(76:C'6B',   
 1644:C'C',1668:C'C',  
 1789:C'C',1812:C'C')) 

As to your question, you are correct, you cannot change the RDW with an OVERLAY 
(or a PUSH, from WHEN=GROUP). 


On Monday, 16 May 2016 21:20:58 UTC+2, Farley, Peter x23353  wrote:
> I am using SYNCSORT to modify VB records (LRECL is > 2000), and this is my 
> SYSIN:
> 
> OPTION COPY  
> OUTREC IFTHEN=(WHEN=(05,02,CH,NE,X'',AND,
>   05,02,CH,NE,X'') ,  
>OVERLAY=(76,2,C'6B',   
> 1644,1,C'C',1668,1,C'C',  
> 1789,1,C'C',1812,1,C'C')),
> IFTHEN=(WHEN=NONE,BUILD=(1,4,5))  
> 
> However, I get the following error message:
> 
> WER235A  OUTREC   RDW NOT INCLUDED
> 
> I cannot see from the SYNCSORT documentation of the OVERLAY sub-parameter how 
> to legally specify the RDW field in the OPVERLAY value, since the doc clearly 
> says:
> 
> "The RDW cannot be overlaid." (page 2-198 in "SYNCSORT MFX for z/OS Release 
> 1.4")
> 
> Can anyone point me to the right way to specify the RDW here?
> 
> If it matters, the SYNCSORT version is:
> 
> SYNCSORT FOR Z/OS  1.4.1.0N
> 
> TIA for any assistance you can provide.
> 
> Peter

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

Re: Subscriber e-mail needs to be changed for me.

[Jesse 1 Robinson]

Best course of action is register at IBM-Main for your preferred email address. 
Once you're getting what you need, like regular email or whatever, then 
unsubscribe your deprecated email address. No list manager intervention 
required. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Benik
Sent: Monday, May 16, 2016 1:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Subscriber e-mail needs to be changed for me.

I did not see any way to change my subscriber e-mail.  At any rate I would like 
it changed from john_e_be...@uhc.com to john_e_be...@optum.com.  The UHC.COM 
address may eventually be disabled.


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

Re: EXTERNAL: Re: smp/e sha-2 support?

[Jerry Whitteridge]

That used to be my retort until I was told to stop being a smartass

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, May 16, 2016 1:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: smp/e sha-2 support?

I guess I'm getting ornery in my old age. I would reply, 'No users have Admin 
access on the mainframe.' Start of a whole new conversation.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Monday, May 16, 2016 12:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

I'd reply to the Auditor "Please define Admin access as there is no one 
privilege  that grants all access"

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lester, Bob
Sent: Monday, May 16, 2016 12:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

Hi All,

 What would you make of this request:   "Show me all the users that have 
admin. Access on the mainframe".  ?

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Monday, May 16, 2016 1:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support? [ EXTERNAL ]

And anyone that thinks Auditors don't set policy and rules hasn't worked in the 
commercial environment for a while. Let alone the fact of having to train PCI 
Auditors that the Mainframe isn't just a slightly bigger PC or  Windows server. 
Some shops could best be summarized as "What the Auditor Wants - The Auditor 
Gets (Even if it makes no sense at all)"

Even though John is absolutely correct on the implications of using SHA1 for 
the purposes of receiving patches - the knee jerk reaction is "SHA1 has been 
superseded as its insecure - everyone must move to SHA2"  (unsaid is even 
though it makes no sense for what the purpose is)

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Monday, May 16, 2016 12:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

What's going to happen is that IBM will not support SHA-2 (or -3) and every 
shop with any degree of security (hipaa, sox, dod, ...) will cease to be able 
to use the internet delivery option. Being told to create an RFE for something 
that is obvious is troubling and to be told that it doesn't matter is worse. 
This is not my first shop where auditors dictate a higher level of security 
than most think required but they are following guidelines from someone higher 
up that can't be argued with.

Somehow I don't think I'm the first to raise this nor will I be the last.


--
Lionel B. Dyck

--- Opinions expressed are my own and not my employer ---

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith III
Sent: Monday, May 16, 2016 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: smp/e sha-2 support?

Charles Mills wrote:

>I suspect you've got a problem, however. There's a saying in sales
>"when
you

>explain, you lose." I can hear auditors saying "SHA-1 -- no good --
security

>exposure" and I would not want to be the one explaining what you say
>below

>to them.



>Perhaps I underestimate IT auditors. I just know the "buzzword kneejerk"

>problem.



I reluctantly have to support this position (not because I don't generally 
agree with Charles, but because it flies in the face of reason).



"Trouble is, sheep are very dim. Once they get an idea in their 'eads, there's 
no shiftin' it." Same applies to far too many auditors/QSAs/et al.



SHA-1 is dead; "good enough" or not, there's no reason to use it any more, 
given that SHA-2 (and, hey, SHA-3!) exist, eh?



.phsiii

--
For IBM-MAIN subscribe / signoff / archive access instructions,

Re: [EXTERNAL] Re: smp/e sha-2 support?

[Charles Mills]

I am not at an end-user shop but I think we are not dealing with rationality
here, we are dealing with voodoo. SHA-1 is bad juju. End of story. If the
distribution server were NAMED SHA1 it would be a problem.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Eells
Sent: Monday, May 16, 2016 1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: smp/e sha-2 support?

Without promising anything at all, please don't be too hasty to prejudge the
outcome of this dicussion.  What I tried to ask is what the actual
requirement is.

The consensus seems to be that the actual requirement is "keep the auditors
happy [and by implication let us keep using internet-based software
delivery, because they set rules we have to follow] by making any use of
SHA-1 'go away' in this context."

That is not quite the same as it being (a) an actual security exposure or
(b) a system integrity exposure.  That also does *not* make it unimportant.
I just want to be sure we are talking about the right things.

Suppose we went off on the path of providing digital signatures for z/OS
software packaging that Andrew Rowley brought up:

- Would a certificate-based signature do?
- What requirements would you have for certificates?
- Would you want signature verification to be optional?
- If signature verification were to be optional, would it be acceptable to
use the SHA-1 hash for integrity checking if the recipient chose not to
verify the signature?  Or, would it still be necessary to use a different
algorithm?
- Anything else to think about?

Dyck, Lionel B. , TRA wrote:
> What's going to happen is that IBM will not support SHA-2 (or -3) and
every shop with any degree of security (hipaa, sox, dod, ...) will cease to
be able to use the internet delivery option. Being told to create an RFE for
something that is obvious is troubling and to be told that it doesn't matter
is worse. This is not my first shop where auditors dictate a higher level of
security than most think required but they are following guidelines from
someone higher up that can't be argued with.
>
> Somehow I don't think I'm the first to raise this nor will I be the last.


--
John Eells
IBM Poughkeepsie
ee...@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: smp/e sha-2 support?

[Jesse 1 Robinson]

I guess I'm getting ornery in my old age. I would reply, 'No users have Admin 
access on the mainframe.' Start of a whole new conversation. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Monday, May 16, 2016 12:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

I'd reply to the Auditor "Please define Admin access as there is no one 
privilege  that grants all access"

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lester, Bob
Sent: Monday, May 16, 2016 12:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

Hi All,

 What would you make of this request:   "Show me all the users that have 
admin. Access on the mainframe".  ?

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Monday, May 16, 2016 1:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support? [ EXTERNAL ]

And anyone that thinks Auditors don't set policy and rules hasn't worked in the 
commercial environment for a while. Let alone the fact of having to train PCI 
Auditors that the Mainframe isn't just a slightly bigger PC or  Windows server. 
Some shops could best be summarized as "What the Auditor Wants - The Auditor 
Gets (Even if it makes no sense at all)"

Even though John is absolutely correct on the implications of using SHA1 for 
the purposes of receiving patches - the knee jerk reaction is "SHA1 has been 
superseded as its insecure - everyone must move to SHA2"  (unsaid is even 
though it makes no sense for what the purpose is)

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Monday, May 16, 2016 12:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

What's going to happen is that IBM will not support SHA-2 (or -3) and every 
shop with any degree of security (hipaa, sox, dod, ...) will cease to be able 
to use the internet delivery option. Being told to create an RFE for something 
that is obvious is troubling and to be told that it doesn't matter is worse. 
This is not my first shop where auditors dictate a higher level of security 
than most think required but they are following guidelines from someone higher 
up that can't be argued with.

Somehow I don't think I'm the first to raise this nor will I be the last.


--
Lionel B. Dyck

--- Opinions expressed are my own and not my employer ---

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith III
Sent: Monday, May 16, 2016 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: smp/e sha-2 support?

Charles Mills wrote:

>I suspect you've got a problem, however. There's a saying in sales 
>"when
you

>explain, you lose." I can hear auditors saying "SHA-1 -- no good --
security

>exposure" and I would not want to be the one explaining what you say 
>below

>to them.



>Perhaps I underestimate IT auditors. I just know the "buzzword kneejerk"

>problem.



I reluctantly have to support this position (not because I don't generally 
agree with Charles, but because it flies in the face of reason).



"Trouble is, sheep are very dim. Once they get an idea in their 'eads, there's 
no shiftin' it." Same applies to far too many auditors/QSAs/et al.



SHA-1 is dead; "good enough" or not, there's no reason to use it any more, 
given that SHA-2 (and, hey, SHA-3!) exist, eh?



.phsiii

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

Questions about EZAZSSI

[Mark Yuhas]

I am preparing for the first IPL of z/OS 2.2.

I was reviewing the COMMND00 PARMLIB member and found a start command for 
EZAZSSI.
 I am totally unfamiliar with this address space.  I googled it and found that 
EZAZSSI starts the TNF & VMCF address spaces.

I reviewed the log from Saturday night's IPL and found this associated message 
-  'EZY6043I TNF Start Initiated'.  I looked up the message:
Explanation:  A TNF address space start was issued.
System Action:  EZAZSSI continues; start of TNF expected.

Of course, a similar message was issued for VMCF.

I check our PARMLIB concatenation and did not find a start command for  
EZAZSSI; and, I know the IPL procedure did not start EZAZSSI?

So, how did EZAZSSI get started?

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

Subscriber e-mail needs to be changed for me.

[John Benik]

I did not see any way to change my subscriber e-mail.  At any rate I would like 
it changed from john_e_be...@uhc.com to john_e_be...@optum.com.  The UHC.COM 
address may eventually be disabled.

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

Re: MTL

[Lizette Koehler]

If you are setting up DLms - then there are several things you need to do.  Are 
you using (if EMC) Consulting services from EMC?  I found that very helpful.

Let me know. I can dig up my notes from when we did this a couple of years ago.

Also, search the IBM MAIN Archives for DLm

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John Benik
> Sent: Monday, May 16, 2016 12:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: MTL
> 
> We are about to install some new hardware .  The new hardware will be an MTL
> and it will consist of two DLMS each of which will be configured as an MTL.
> I'm just trying to find out if there is anything that we need to be aware of
> as we head down this road?
> 

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

Re: MTL

[Porowski, Ken]

I'm running 2 DLM's as part of a single MTL.  Have been for a couple of years.  
No issues, just be sure to get your scratch processing set up correctly.  And 
be aware that unlike physical tape once a volume goes scratch you can't recover 
the data.



CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | +1 973 
740 5459 (tel) | ken.porow...@cit.com




This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, “CIT”), and are intended solely for the 
recipient(s) named above.  If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited.  CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s).  If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials.  To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Benik
Sent: Monday, May 16, 2016 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] MTL

We are about to install some new hardware .  The new hardware will be an MTL 
and it will consist of two DLMS each of which will be configured as an MTL.  
I'm just trying to find out if there is anything that we need to be aware of as 
we head down this road?

--
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: [EXTERNAL] Re: smp/e sha-2 support?

[John Eells]

Without promising anything at all, please don't be too hasty to prejudge 
the outcome of this dicussion.  What I tried to ask is what the actual 
requirement is.


The consensus seems to be that the actual requirement is "keep the 
auditors happy [and by implication let us keep using internet-based 
software delivery, because they set rules we have to follow] by making 
any use of SHA-1 'go away' in this context."


That is not quite the same as it being (a) an actual security exposure 
or (b) a system integrity exposure.  That also does *not* make it 
unimportant.  I just want to be sure we are talking about the right things.


Suppose we went off on the path of providing digital signatures for z/OS 
software packaging that Andrew Rowley brought up:


- Would a certificate-based signature do?
- What requirements would you have for certificates?
- Would you want signature verification to be optional?
- If signature verification were to be optional, would it be acceptable 
to use the SHA-1 hash for integrity checking if the recipient chose not 
to verify the signature?  Or, would it still be necessary to use a 
different algorithm?

- Anything else to think about?

Dyck, Lionel B. , TRA wrote:

What's going to happen is that IBM will not support SHA-2 (or -3) and every 
shop with any degree of security (hipaa, sox, dod, ...) will cease to be able 
to use the internet delivery option. Being told to create an RFE for something 
that is obvious is troubling and to be told that it doesn't matter is worse. 
This is not my first shop where auditors dictate a higher level of security 
than most think required but they are following guidelines from someone higher 
up that can't be argued with.

Somehow I don't think I'm the first to raise this nor will I be the last.



--
John Eells
IBM Poughkeepsie
ee...@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: Catalog move

[Tony IBM-MAIN]

Look at Catalog Recovery Plus from Rocket Software. There is a MERGECAT 
WHILEOPEN function.


Catalog entries may be moved while datasets are in use, including all 
those tricky VSAM datasets that are open by long running STC's like CICS.


Tony.

On 05/05/16 17:35, Peter wrote:

Hi

We have some product DATASET catalog to master instead of a user catalog.

So moving the DATASET entries from master to a user catalog is doable only
when the started task is down ?

Any thoughts on the above approach ?

Peter

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



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

MTL

[John Benik]

We are about to install some new hardware .  The new hardware will be an MTL 
and it will consist of two DLMS each of which will be configured as an MTL.  
I'm just trying to find out if there is anything that we need to be aware of as 
we head down this road?

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

Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

[Jerry Whitteridge]

I'd reply to the Auditor "Please define Admin access as there is no one 
privilege  that grants all access"

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lester, Bob
Sent: Monday, May 16, 2016 12:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

Hi All,

 What would you make of this request:   "Show me all the users that have 
admin. Access on the mainframe".  ?

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Monday, May 16, 2016 1:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support? [ EXTERNAL ]

And anyone that thinks Auditors don't set policy and rules hasn't worked in the 
commercial environment for a while. Let alone the fact of having to train PCI 
Auditors that the Mainframe isn't just a slightly bigger PC or  Windows server. 
Some shops could best be summarized as "What the Auditor Wants - The Auditor 
Gets (Even if it makes no sense at all)"

Even though John is absolutely correct on the implications of using SHA1 for 
the purposes of receiving patches - the knee jerk reaction is "SHA1 has been 
superseded as its insecure - everyone must move to SHA2"  (unsaid is even 
though it makes no sense for what the purpose is)

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Monday, May 16, 2016 12:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

What's going to happen is that IBM will not support SHA-2 (or -3) and every 
shop with any degree of security (hipaa, sox, dod, ...) will cease to be able 
to use the internet delivery option. Being told to create an RFE for something 
that is obvious is troubling and to be told that it doesn't matter is worse. 
This is not my first shop where auditors dictate a higher level of security 
than most think required but they are following guidelines from someone higher 
up that can't be argued with.

Somehow I don't think I'm the first to raise this nor will I be the last.


--
Lionel B. Dyck

--- Opinions expressed are my own and not my employer ---

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith III
Sent: Monday, May 16, 2016 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: smp/e sha-2 support?

Charles Mills wrote:

>I suspect you've got a problem, however. There's a saying in sales
>"when
you

>explain, you lose." I can hear auditors saying "SHA-1 -- no good --
security

>exposure" and I would not want to be the one explaining what you say
>below

>to them.



>Perhaps I underestimate IT auditors. I just know the "buzzword kneejerk"

>problem.



I reluctantly have to support this position (not because I don't generally 
agree with Charles, but because it flies in the face of reason).



"Trouble is, sheep are very dim. Once they get an idea in their 'eads, there's 
no shiftin' it." Same applies to far too many auditors/QSAs/et al.



SHA-1 is dead; "good enough" or not, there's no reason to use it any more, 
given that SHA-2 (and, hey, SHA-3!) exist, eh?



.phsiii


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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


--
For IBM-MAIN subscribe / signoff / archive access instructions, 

Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

[Lester, Bob]

Hi All,

 What would you make of this request:   "Show me all the users that have 
admin. Access on the mainframe".  ?

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Monday, May 16, 2016 1:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support? [ EXTERNAL ]

And anyone that thinks Auditors don't set policy and rules hasn't worked in the 
commercial environment for a while. Let alone the fact of having to train PCI 
Auditors that the Mainframe isn't just a slightly bigger PC or  Windows server. 
Some shops could best be summarized as "What the Auditor Wants - The Auditor 
Gets (Even if it makes no sense at all)"

Even though John is absolutely correct on the implications of using SHA1 for 
the purposes of receiving patches - the knee jerk reaction is "SHA1 has been 
superseded as its insecure - everyone must move to SHA2"  (unsaid is even 
though it makes no sense for what the purpose is)

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Monday, May 16, 2016 12:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

What's going to happen is that IBM will not support SHA-2 (or -3) and every 
shop with any degree of security (hipaa, sox, dod, ...) will cease to be able 
to use the internet delivery option. Being told to create an RFE for something 
that is obvious is troubling and to be told that it doesn't matter is worse. 
This is not my first shop where auditors dictate a higher level of security 
than most think required but they are following guidelines from someone higher 
up that can't be argued with.

Somehow I don't think I'm the first to raise this nor will I be the last.


--
Lionel B. Dyck

--- Opinions expressed are my own and not my employer ---

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith III
Sent: Monday, May 16, 2016 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: smp/e sha-2 support?

Charles Mills wrote:

>I suspect you've got a problem, however. There's a saying in sales 
>"when
you

>explain, you lose." I can hear auditors saying "SHA-1 -- no good --
security

>exposure" and I would not want to be the one explaining what you say 
>below

>to them.



>Perhaps I underestimate IT auditors. I just know the "buzzword kneejerk"

>problem.



I reluctantly have to support this position (not because I don't generally 
agree with Charles, but because it flies in the face of reason).



"Trouble is, sheep are very dim. Once they get an idea in their 'eads, there's 
no shiftin' it." Same applies to far too many auditors/QSAs/et al.



SHA-1 is dead; "good enough" or not, there's no reason to use it any more, 
given that SHA-2 (and, hey, SHA-3!) exist, eh?



.phsiii


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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


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

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 

Re: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

[Jerry Whitteridge]

And anyone that thinks Auditors don't set policy and rules hasn't worked in the 
commercial environment for a while. Let alone the fact of having to train PCI 
Auditors that the Mainframe isn't just a slightly bigger PC or  Windows server. 
Some shops could best be summarized as "What the Auditor Wants - The Auditor 
Gets (Even if it makes no sense at all)"

Even though John is absolutely correct on the implications of using SHA1 for 
the purposes of receiving patches - the knee jerk reaction is "SHA1 has been 
superseded as its insecure - everyone must move to SHA2"  (unsaid is even 
though it makes no sense for what the purpose is)

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

If you feel in control
you just aren't going fast enough.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Monday, May 16, 2016 12:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?

What's going to happen is that IBM will not support SHA-2 (or -3) and every 
shop with any degree of security (hipaa, sox, dod, ...) will cease to be able 
to use the internet delivery option. Being told to create an RFE for something 
that is obvious is troubling and to be told that it doesn't matter is worse. 
This is not my first shop where auditors dictate a higher level of security 
than most think required but they are following guidelines from someone higher 
up that can't be argued with.

Somehow I don't think I'm the first to raise this nor will I be the last.


--
Lionel B. Dyck

--- Opinions expressed are my own and not my employer ---

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith III
Sent: Monday, May 16, 2016 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: smp/e sha-2 support?

Charles Mills wrote:

>I suspect you've got a problem, however. There's a saying in sales
>"when
you

>explain, you lose." I can hear auditors saying "SHA-1 -- no good --
security

>exposure" and I would not want to be the one explaining what you say
>below

>to them.



>Perhaps I underestimate IT auditors. I just know the "buzzword kneejerk"

>problem.



I reluctantly have to support this position (not because I don't generally 
agree with Charles, but because it flies in the face of reason).



"Trouble is, sheep are very dim. Once they get an idea in their 'eads, there's 
no shiftin' it." Same applies to far too many auditors/QSAs/et al.



SHA-1 is dead; "good enough" or not, there's no reason to use it any more, 
given that SHA-2 (and, hey, SHA-3!) exist, eh?



.phsiii


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

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


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

Re: [EXTERNAL] Re: smp/e sha-2 support?

[Dyck, Lionel B. (TRA)]

What's going to happen is that IBM will not support SHA-2 (or -3) and every 
shop with any degree of security (hipaa, sox, dod, ...) will cease to be able 
to use the internet delivery option. Being told to create an RFE for something 
that is obvious is troubling and to be told that it doesn't matter is worse. 
This is not my first shop where auditors dictate a higher level of security 
than most think required but they are following guidelines from someone higher 
up that can't be argued with.

Somehow I don't think I'm the first to raise this nor will I be the last.


--
Lionel B. Dyck 

--- Opinions expressed are my own and not my employer ---

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith III
Sent: Monday, May 16, 2016 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: smp/e sha-2 support?

Charles Mills wrote:

>I suspect you've got a problem, however. There's a saying in sales 
>"when
you

>explain, you lose." I can hear auditors saying "SHA-1 -- no good --
security

>exposure" and I would not want to be the one explaining what you say 
>below

>to them.

 

>Perhaps I underestimate IT auditors. I just know the "buzzword kneejerk"

>problem.

 

I reluctantly have to support this position (not because I don't generally 
agree with Charles, but because it flies in the face of reason). 

 

"Trouble is, sheep are very dim. Once they get an idea in their 'eads, there's 
no shiftin' it." Same applies to far too many auditors/QSAs/et al.

 

SHA-1 is dead; "good enough" or not, there's no reason to use it any more, 
given that SHA-2 (and, hey, SHA-3!) exist, eh?

 

.phsiii


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

SYNCSORT IFTHEN with OVERLAY: how to specify RDW?

[Farley, Peter x23353]

I am using SYNCSORT to modify VB records (LRECL is > 2000), and this is my 
SYSIN:

OPTION COPY  
OUTREC IFTHEN=(WHEN=(05,02,CH,NE,X'',AND,
  05,02,CH,NE,X'') ,  
   OVERLAY=(76,2,C'6B',   
1644,1,C'C',1668,1,C'C',  
1789,1,C'C',1812,1,C'C')),
IFTHEN=(WHEN=NONE,BUILD=(1,4,5))  

However, I get the following error message:

WER235A  OUTREC   RDW NOT INCLUDED

I cannot see from the SYNCSORT documentation of the OVERLAY sub-parameter how 
to legally specify the RDW field in the OPVERLAY value, since the doc clearly 
says:

"The RDW cannot be overlaid." (page 2-198 in "SYNCSORT MFX for z/OS Release 
1.4")

Can anyone point me to the right way to specify the RDW here?

If it matters, the SYNCSORT version is:

SYNCSORT FOR Z/OS  1.4.1.0N

TIA for any assistance you can provide.

Peter

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

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

Re: JCL "COMMAND" statements

[Itschak Mugzach]

OK. my version is based on TSO CONSOLE command. It reads command and
verification value from sysin (see rexx test below), execure the command
and verifies that the command response equal to the one read from sysin. it
can be easily modified to read multiple commands and verification strings.
The idea behind the verification is to ensure that the command executed as
expected (file was closed, job was started, etc.). igone the copywrite
statement of course...

Best,
ITschak

/* MugiRexx V1.3 */
ConsoleCommandInterface:
   Signal ConsoleCommandInterface.main
ConsoleCommandInterface.Doc:
   --
 CCC
Console Command Confirmation

   the program receives input from Parmlib in the format of:
   SET CMDTEXT   = 'command'
   SET CMDVERIFY = 'value to look in the command response'

   > CmdVerify must follow CMDTEXT.
   > example:
 set cmdtext   = '+dbr db pge'
 set cmdverify = 'DFS0488I  DBR COMMAND COMPLETED'

   Copyright (c) SecuriTeam Software, 1999-2012.  All Rights Reserved
   --
ConsoleCommandInterface.Main:
   Call ReadParmlib
   Call ConsoleCmd
   Return
   --
ConsoleCmd:
   MsgMode = Msg('OFF')
   xTrap   = Outtrap('xMsgs.')
   "CONSPROF SOLDISP(NO) UNSOLDISP(NO)"
   "CONSOLE ACTIVATE NAME(IMS)"
   Do i = 1 to K
  CmdText   = CmdBuff.i.Cmd
  CmdVerify = CmdBuff.i.Verify
  "CONSOLE SYSCMD("CmdText") cart(x1938)"
  MsgResp = GetMsg('Msg.','SOL',x1938,,162)
  say 'number of responses from cmd:' msg.0
  do j = 1 to Msg.0
 say 'response from mvs:' msg.j
 If ((Pos(CmdVerify,Msg.j)>0) | (Pos('DFS058I',Msg.j) > 0)) ,
Then Do
Say 'STE5006I Command execution confirmed by server.',
   'command:' CmdText
Leave
End
 End
  If (j > Msg.0) Then Do
 Say 'STE5007E Command execution not confirmed by server.'
 Say 'STE5008W Command text:' CmdText
 Say 'STE500iE Rest of commands not executed!'
 Exit 20
 End
  End
   "CONSOLE DEACTIVATE"
   Say 'STE5010I Console session completed.'
   Return
   --
ReadParmlib:
   /*  */
   /* Parmlib should be pre-allocated by the caller, as the  main  */
   /* use of this program is to run under a job step.  */
   /*  */
   AuthVars   = 'CMDTEXT CMDVERIFY'
   FileStatus = ListDsi('PARMLIB FILE')
   If (FileStatus > 4) Then Do
  If (sysreason <> 3) Then Do
 Say 'STE5001E Parmlib not allocated in JCL.',
FileStatus SysReason
 Say 'STE5002I Fix JCL and re-run the job.'
 Exit 20
 End
  End
   "ExecIO * DiskR PARMLIB (Stem Parm. finis"
   K = 0
   Do i = 1 to Parm.0
  parm.i = Substr(Parm.i,1,71)
  xPos = Pos(';',Parm.i)
  If (xPos > 0) Then Do
 parm.i = Substr(Parm.i,1,xPos-1)
 End
  Parse Upper Var Parm.i CmdOpt CmdVar . CmdValue
  If (CmdOpt = 'SET') Then Do
 If (POS(CmdVar,AuthVars) = 0) Then Do
Say 'STE5003E Variable' CmdVar 'is not defined to Program'
Say 'STE5004I Please verify PARMLIB syntax.'
Exit 20
End
 Interpret CmdVar '=' CmdValue
 If (CmdVar = 'CMDTEXT') Then Do
CmdFound = 'YES'
End
 If (CmdVar = 'CMDVERIFY') Then Do
If (CmdFound Ž= 'YES') Then Do
   Say 'STE5006E Sequence error. No command definded for',
  'verification by line' i'.'
   exit 20
   End
K = K + 1
say 'k='k cmdtext
CmdBuff.k.Cmd= CmdText
CmdBuff.k.Verify = CmdVerify
CmdFound = 'NO'
End
 Say 'STE5005I Variable' CmdVar 'SET TO' Value(CmdVar)'.'
 End
  End
   Return


ITschak Mugzach
Z/OS, ISV Products and Application Security & Risk Assessments Professional

On Mon, May 16, 2016 at 10:08 PM, Jousma, David  wrote:

> This is similar to Charles, using SDSF, but it captures the output, and
> writes it to DD, you can stack as many commands in there as you wish.
>
> //OPERCMD   EXEC PGM=IKJEFT1B,PARM='%OPERCMDB'
> //SYSEXEC   DD   DSN=your.sysexec.dataset,DISP=SHR
> //SYSIN DD   *
> D ASM
> /*
> //SYSTSIN  DD   DUMMY
> //SYSTSPRT DD   DUMMY
> //
>
> /* REXX */
> /* this REXX exec will issue operator commands via SDSF REXX interface
>security is based on the person using the command.  this exec is to be
>used for batch only   */
> 'EXECIO * DISKR SYSIN (STEM mycmd. FINIS'
> if rc > 0 then do
>say 'Return code from OPEN was' rc
>say 'Aborting...'
>

Re: JCL "COMMAND" statements

[Jousma, David]

This is similar to Charles, using SDSF, but it captures the output, and writes 
it to DD, you can stack as many commands in there as you wish.

//OPERCMD   EXEC PGM=IKJEFT1B,PARM='%OPERCMDB'
//SYSEXEC   DD   DSN=your.sysexec.dataset,DISP=SHR  
//SYSIN DD   *
D ASM 
/*
//SYSTSIN  DD   DUMMY 
//SYSTSPRT DD   DUMMY 
//

/* REXX */ 
/* this REXX exec will issue operator commands via SDSF REXX interface 
   security is based on the person using the command.  this exec is to be  
   used for batch only   */
'EXECIO * DISKR SYSIN (STEM mycmd. FINIS'  
if rc > 0 then do  
   say 'Return code from OPEN was' rc  
   say 'Aborting...'   
   exit
   end 
   
/* Allocate results output file  */
ddnm = 'DD'||random(1,9)   
Address TSO "Alloc Fi("ddnm") SYSOUT"  
   
/* Process all input commands*/
Do c=1 to mycmd.0  
 oper_command.0 = 1
 oper_command.1 = mycmd.c  
 Call Main_process 
End
   
/* Free results output file  */   
Address TSO "Free Fi("ddnm")" 
Return 0  
  
Main_process: 
/* process all data from SYSIN   */   
rc=isfcalls('ON') 
Address SDSF ISFSLASH "("oper_command.") (WAIT)"  
l_cnt = 0 
If datatype(isfulog.0) = "NUM" Then Do
 If isfulog.0 <> 0 Then Do
  l_cnt = l_cnt + 1   
  l.l_cnt = substr(isfulog.1,1,43)
  Do ix=1 to isfulog.0
   ll = length(isfulog.ix)
   qdata = substr(isfulog.ix,44,ll-43)
   l_cnt = l_cnt + 1  
   l.l_cnt = qdata
  End 
 End  
Else Do   
 l_cnt = l_cnt + 1
 l.l_cnt = "No command response available"
 End  
End   
Else Do   
 l_cnt = l_cnt + 1
 l.l_cnt = "Error in command reponse" 
End   
rc=isfcalls("OFF")
If (l_cnt = 0) Then Do
 l_cnt = l_cnt + 1
 l.l_cnt = ' /* no data produced */'  
End   
l.0 = l_cnt   
Address MVS "ExecIO "l_cnt" DiskW "ddnm" (Finis Stem l.)" 
l_cnt = 0 
Return

_
Dave Jousma
Assistant Vice President, Manager, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, May 16, 2016 11:38 AM
To: 

Re: So long everyone!!!

[Norman.Hollander]

All the best, Ken.  On the same retirement train starting 6/6.  
zNorman

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Ken Hume
Sent: Monday, May 16, 2016 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: So long everyone!!!

Hi all,

I will be unsubscribing from the list in a few days as I leave IBM. Once out
of here I have no plans to ever see a mainframe, or any non personal
computer for that matter, ever again.

I just wanted to thank everyone for the posts over the last few years. 
Even if they were not related to what I do, I always felt as if I learned
something.

So long all!!

Ken Hume

Former Product Manager, IBM Application Performance Analyzer

Former CST Team Representative

Former PD Tools Client Advocate

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

So long everyone!!!

[Ken Hume]

Hi all,

I will be unsubscribing from the list in a few days as I leave IBM. Once 
out of here I have no plans to ever see a mainframe, or any non personal 
computer for that matter, ever again.

I just wanted to thank everyone for the posts over the last few years. 
Even if they were not related to what I do, I always felt as if I 
learned something.

So long all!!

Ken Hume

Former Product Manager, IBM Application Performance Analyzer

Former CST Team Representative

Former PD Tools Client Advocate

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

Re: Do we need another thread bemoaning JCL? (Was "JCL "COMMAND" statements")

[John McKown]

On Mon, May 16, 2016 at 11:25 AM, Charles Mills  wrote:

> I'm not even real familiar with UNIX export and I expected it to work the
> other way. You set a value and then you send (export) it somewhere, no?
>
> Charles
>
>
​Actually, at least in BASH on Linux, you can either export then set or set
then export. They have the same effect. What export does​

​make a shell environment variable "available" to ​a sub-shell or a
program. Example transcript which may help a bit:

$ printenv X # no value yet
$ sh -c 'printenv X' # likewise in subshell
$ X='a' # set value
$ printenv X # show it's here
a
$ sh -c 'printenv X' # but not here
$ export X
[tsh009@it-johnmckown-linux ~]$ sh -c 'printenv X' # export makes it
available
a
[tsh009@it-johnmckown-linux ~]$ printenv Y # try again - not there
[tsh009@it-johnmckown-linux ~]$ sh -c 'printenv Y' # not here either
[tsh009@it-johnmckown-linux ~]$ export Y # export it
[tsh009@it-johnmckown-linux ~]$ printenv Y # still no value
[tsh009@it-johnmckown-linux ~]$ sh -c 'printenv Y' # likewise
[tsh009@it-johnmckown-linux ~]$ Y="bye bye" #set value
[tsh009@it-johnmckown-linux ~]$ printenv Y # ow, wow - it's here!
bye bye
[tsh009@it-johnmckown-linux ~]$ sh -c 'printenv Y' # likewise, wow.
bye bye
[tsh009@it-johnmckown-linux ~]$

​Actually the export does not "make an environment variable available".
What happens in UNIX is that the shell create a _new_ environment array (an
array of pointers to pointers to chars - char **envp) based upon what has
been exported. I.e. the only name/values exported are copies into a _NEW_
environment block which is sent to the command. That's why a shell script
or program cannot affect the environment of its parent.




-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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: Do we need another thread bemoaning JCL? (Was "JCL "COMMAND" statements")

[Paul Gilmartin]

On Mon, 16 May 2016 09:25:14 -0700, Charles Mills wrote:

>I'm not even real familiar with UNIX export and I expected it to work the 
>other way. You set a value and then you send (export) it somewhere, no?
> 
POSIX shell:  Either way (almost).  Note the surprising semantics of special
builtins.  "unset" complicates things.

C Shell has distinct "set" and "setenv" commands, with irritatingly different 
syntax.
(cf. Tom Christiansen; we don't need a thread bemoaning C shell.)

-- gil

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

Re: Do we need another thread bemoaning JCL? (Was "JCL "COMMAND" statements")

[Paul Gilmartin]

("Yes" only if you haven't been following my posts.)

On Mon, 16 May 2016 08:51:08 -0700, Ed Jaffe wrote:
>
>Made the mistake more than once of placing the EXPORT statement *after*
>the SET statements. But, really it's only counterintuitive if you're
>used to UNIX-style export (as apparently we both are). Otherwise, it's
>just "the way it works..."
> 
I got accustomed to the "the way [EXPORT] works."  But then I was truly
astonished by:

//  SET X=BEFORE
//SYSUT1  DD  *,SYMBOLS=JCL

//  SET X=AFTER

versus (untested; my guess):

//  SET A=BEFORE
//  SET X=  (JCL Ref. is fuzzy about validity of this.  RCF submitted.)
//SYSUT1  DD  SYMBOLS=JCL

//  SET A=AFTER

And:

//SYSUT1  DD  *
//  SET X=BEFORE
//DD  *,SYMBOLS=JCL  /* (JCL error here; documented.)  */


versus:

//SYSUT1  DD  *
//SYSUT1  DD  *
//  SET X=BEFORE
//DD  *,SYMBOLS=JCL  /* (JCL syntax OK.)  */


-- gil

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

Re: JCL "COMMAND" statements

[Tony Thigpen]

These are 'system' jobs that are running with higher security. Most are 
nightly to stop some regions for nightly processes.


Tony Thigpen

Jeremy Nicoll wrote on 05/16/2016 12:19 PM:

On Mon, 16 May 2016, at 17:03, Itschak Mugzach wrote:

Tony. You may already seen that the //comand1 is not a dd nor exe jcl
card.
It is a jcl command statement and has nothing to do with the job steps.
Jcl
commands and jes /* commands are executed at conversion tome independed
with the job status. They are executed even if the job will never run.

As others explained, u can use tso console command and even verify
response. This way u can use a single jobstep.


Quite a few years ago, we used steps which issued a WTOR asking for
something to be done, and
either - even longer ago - real operators then did it, or more recently
AOC would issue the command
PROVIDED THE JOB ASKING FOR IT WAS ALLOWED TO DO IT and then reply to
the WTOR.

Generally I discouraged people from coding actual commands in the WTOR
text, and made the AOC
code NOT execute the arbitrary contents of the WTOR as a command.  So we
end up with, if you like,
plain text requests "PLEASE DO SOMETHING OR OTHER" and translated them
into the actual
command or commands required.

I can't imagine working in a site that would allow any job to issue any
arbitrary command!



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

Re: Alter access to datasets

[Ted MacNEIL]

In an ideal world:
1. Subject ma‎tter experts set the guidelines (with mgt approval)
2. Auditors have no authourity, they merely report.
3. Compliance officers enforce the rules.


-teD
  Original Message  
From: Arthur
Sent: Friday, April 29, 2016 00:31
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Alter access to datasets

On 28 Apr 2016 18:43:27 -0700, in bit.listserv.ibm-main 
(Message-ID:<9982011699705061.wa.gsg808yahoo@listserv.ua.edu>)
0053fe88ed35-dmarc-requ...@listserv.ua.edu (gsg) wrote:

>As part of a systems programmer duties, they have ALTER 
>access to many datasets. They need/require this access to 
>install, upgrade, maintain and resolve problems. Audit 
>has been pushing more and more to remove the ALTER access.
>
>Has anyone else been experiencing this?

The following is opinion based on my experience:

Auditors feel they have to make recommendations in order to 
justify their existence. Thus, if you have a secure system, 
they start to make stuff up. Removing required sysprog 
authorities is one of the easier demands to think of, 
regardless of its impracticality.

Too many companies then make those ridiculous "recommended" 
changes because they think the auditors know what they're 
doing, or because it's easier to defend stupid things 
ordered by auditors than smart things contrary to the 
auditors advice.

I do know one person who managed to short-circuit this 
particular suggestion. He said, "If I have enough tools to 
do my job, I can access any dataset regardless of the 
security system. If I have to bypass the security system, 
I'll do so in a way that leaves no traces. But, it would 
take time and effort I'd rather put into doing my actual 
job. So, leave my access and just make sure to thoroughly 
check my audit trail." It worked. 

--
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: Do we need another thread bemoaning JCL? (Was "JCL "COMMAND" statements")

[Charles Mills]

I'm not even real familiar with UNIX export and I expected it to work the other 
way. You set a value and then you send (export) it somewhere, no?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Monday, May 16, 2016 8:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Do we need another thread bemoaning JCL? (Was "JCL "COMMAND" 
statements")

On 5/16/2016 8:45 AM, Charles Mills wrote:
> OT, but me too. I found the order of  EXPORT and SET to be counterintuitive.

Made the mistake more than once of placing the EXPORT statement *after* the SET 
statements. But, really it's only counterintuitive if you're used to UNIX-style 
export (as apparently we both are). Otherwise, it's just "the way it works..."

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

Re: JCL "COMMAND" statements

[Tony Thigpen]

Thanks all.

After the many suggestions, it 'rang a bell' with something I had worked 
on before:


//STEP01   EXEC PGM=IKJEFT1A,REGION=0M
//SYSPRINT DD SYSOUT=*
//SYSTSPRT  DD SYSOUT=*
//SYSTERM  DD SYSOUT=*
//SYSTSOUT DD SYSOUT=*
//SYSTSIN  DD *
 OC C('DS QD,TYPE=ALL,ONLINE')
/*

I have used the same OC exec to make one of my jobs work right.

Tony Thigpen

Nims,Alva John (Al) wrote on 05/16/2016 11:46 AM:

Check CBTTAPE.ORG there might be a couple of them there.

Create a REXX program to interface with TSO "OPERATOR" command or interface 
with SDSF API.
Can check results

IEBGENER to STDRDR, use $VS'' to issue MVS commands.
   Can't check results.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Monday, May 16, 2016 11:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL "COMMAND" statements

I have spent most of my life as a z/VSE and z/VM systems programmer, but during 
the last year, I have been managing a couple of z/OS systems in our small 
outsourcing shop.

At this point, I would consider myself just a very knowledgeable, but still 
novice z/OS systems programmer. So, be gentle with your replies. :-) And, 
please don't laugh.

Last night/this morning, I have stumped because I noticed that some JCL set up 
by a previous systems programmer was not working as it appeared it should. [At 
least, until I read the manual.]

We have many jobs set up something like thus:

//STEP1EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPTOR'
//WAIT1EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP2EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPDOR'
//WAIT2EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP3EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPAOR1'
//COMMD1   COMMAND 'S CICSPAOR2'
//WAIT3EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//*

I, of course, though the commands would be synchronized with the execution JCL. 
But, we were seeing timing errors that could not be corrected by just 
increasing the wait timers. So, I started looking for the problem and found 
that all the commands were being issued to the console before the first IEFBR14 
even executed.

I was totally surprised when I found that IBM documents the COMMAND jcl card as 
being processed during the JCL conversion phase and not during the execution 
phase. *And* that a previous systems programmer must not have known it either.

So, now I have 2 questions for the knowledgeable people on the list:

1) Are there any other jcl statements that are executed outside the normal 
execution phase?

2) What is the 'normal' method to issue console commands synchronized with the 
job execution?

--
Tony Thigpen

--
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: JCL "COMMAND" statements

[Jeremy Nicoll]

On Mon, 16 May 2016, at 17:03, Itschak Mugzach wrote:
> Tony. You may already seen that the //comand1 is not a dd nor exe jcl
> card.
> It is a jcl command statement and has nothing to do with the job steps.
> Jcl
> commands and jes /* commands are executed at conversion tome independed
> with the job status. They are executed even if the job will never run.
> 
> As others explained, u can use tso console command and even verify
> response. This way u can use a single jobstep.

Quite a few years ago, we used steps which issued a WTOR asking for
something to be done, and
either - even longer ago - real operators then did it, or more recently
AOC would issue the command 
PROVIDED THE JOB ASKING FOR IT WAS ALLOWED TO DO IT and then reply to
the WTOR.

Generally I discouraged people from coding actual commands in the WTOR
text, and made the AOC
code NOT execute the arbitrary contents of the WTOR as a command.  So we
end up with, if you like,
plain text requests "PLEASE DO SOMETHING OR OTHER" and translated them
into the actual 
command or commands required.

I can't imagine working in a site that would allow any job to issue any
arbitrary command!

-- 
Jeremy Nicoll - my opinions are my own.

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

Re: WLM issue with a proposed solution

[Ted MacNEIL]

Dispatching priorities mean nothing if the work is getting done. You're using 
the WLM; you should learn and use its terminology.

-teD
  Original Message  
From: Tracy Adams
Sent: Thursday, April 28, 2016 15:57
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: WLM issue with a proposed solution

The importance (priority) of DB2 is set 2, as well as the CICS service class. 
It serves both the CICS and batch jobs.

I only speak of dispatching priorities because isn't ultimately that is driven 
by the collective results of WLM?

To Mark's question, I am not sure what is stalling those transactions, I will 
try to collect some delay information. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Martin Packer
Sent: Thursday, April 28, 2016 3:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WLM issue with a proposed solution

Hello Tracy.

What importance have you set DB2 address spaces' service class(es) to? 
Likewise the things it serves, such as CICS regions and CICS transactions/

If DB2 is getting locked out it could be caused by it being Imp 2 or something, 
rather than Imp 1 with a goal 70+.

I also note you're mainly talking dispatching priorities rather than WLM 
language.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator, Worldwide Cloud & Systems 
Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): 
https://developer.ibm.com/tv/category/mpt/



From: Tracy Adams 
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 28/04/2016 19:22
Subject: WLM issue with a proposed solution
Sent by: IBM Mainframe Discussion List 



So here is my issue:

We have a soft capped LPAR that runs our DB2 and CICS regions and during the 
day some "marketing batch". On Wednesdays, the marketing batch (online submit 
via CICS) increases and by afternoon we hit our 4 hour soft cap. Once or twice 
while we are capped, the busiest CICS slow down to the point where some old 
automation kicks in to kill transactions over 45 seconds old, some of these 
transactions dump through DumpMaster, we then go to max sockets and more 
transactions dump and in 10 - 30 seconds all is fine again.

What I see: The CICS regions have a DP around EC and are meeting their service 
goal of 99% under .5 seconds. But there are tens of thousands transactions that 
have led to this. The batch jobs (3-5 of them), while running 10 - 15 % cpu 
have a DP of C0 and are in a discretionary level of the service class. I 
believe the problem lies with the DB2 service class. 
That has a definition of velocity at 66 and it tends to run below that when 
there is more contention in the system. The DP of the DB2 region is F6. 

My theory: when this brown out occurs the resources are maxed out and the CICS 
regions being the ones that have meet their goal and will have to suffer many 
transactions missing the service goal to make the DP go up. 
They get hung up just long enough to cause the delays that trigger the "panic" 
automation to clear the stalled transactions. Chaos breaks out! 

My proposal: A. limit the batch jobs to a max of three by controlling open 
initiators for their job class. B. change the DB2 velocity to 60 C. 
Starve the CICS service goal by reducing it to 99% in .4 forcing his DP to be a 
little more desperate.

Thoughts?

TIA,

Tracy

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


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--
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: How well does z/OS handle large, but sparse, memory objects?

[John McKown]

On Mon, May 16, 2016 at 10:48 AM, Tony Harminc  wrote:

> On 16 May 2016 at 11:29, Paul Gilmartin
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> > In circumvention, AIX introduced a nonstandard signal, SIGDANGER,
> > thrown when backing storage was (FSVO) nearly exhausted.
>
> OT, but are signals "thrown"? I know that in C++ and Java, exceptions
> are objects and are "thrown" (and perhaps "caught"), where in PL/I and
> some other languages they are states and are "raised". But signals...?
> [Just to compund things, PL/I (and REXX) has a SIGNAL verb that raises
> an exception.]
>

​Yes, signals are "thrown". But the program doesn't do the throwing. The OS
"throws" the signal asynchronously, which the program must "​catch" via
something like a sigaction(). In many cases, the language start up routines
or the OS will set up a default signal action, usually to simply ignore the
signal. Unless it is a critical error such as SIGSEGV (S0C4 type abend in
z/OS).



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



-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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: JCL "COMMAND" statements

[Itschak Mugzach]

Tony. You may already seen that the //comand1 is not a dd nor exe jcl card.
It is a jcl command statement and has nothing to do with the job steps. Jcl
commands and jes /* commands are executed at conversion tome independed
with the job status. They are executed even if the job will never run.

As others explained, u can use tso console command and even verify
response. This way u can use a single jobstep.

Best
ITschak
בתאריך 16 במאי 2016 18:22,‏ "Tony Thigpen"  כתב:

> I have spent most of my life as a z/VSE and z/VM systems programmer, but
> during the last year, I have been managing a couple of z/OS systems in our
> small outsourcing shop.
>
> At this point, I would consider myself just a very knowledgeable, but
> still novice z/OS systems programmer. So, be gentle with your replies. :-)
> And, please don't laugh.
>
> Last night/this morning, I have stumped because I noticed that some JCL
> set up by a previous systems programmer was not working as it appeared it
> should. [At least, until I read the manual.]
>
> We have many jobs set up something like thus:
>
> //STEP1EXEC PGM=IEFBR14
> //COMMD1   COMMAND 'S CICSPTOR'
> //WAIT1EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
> //STEP2EXEC PGM=IEFBR14
> //COMMD1   COMMAND 'S CICSPDOR'
> //WAIT2EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
> //STEP3EXEC PGM=IEFBR14
> //COMMD1   COMMAND 'S CICSPAOR1'
> //COMMD1   COMMAND 'S CICSPAOR2'
> //WAIT3EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
> //*
>
> I, of course, though the commands would be synchronized with the execution
> JCL. But, we were seeing timing errors that could not be corrected by just
> increasing the wait timers. So, I started looking for the problem and found
> that all the commands were being issued to the console before the first
> IEFBR14 even executed.
>
> I was totally surprised when I found that IBM documents the COMMAND jcl
> card as being processed during the JCL conversion phase and not during the
> execution phase. *And* that a previous systems programmer must not have
> known it either.
>
> So, now I have 2 questions for the knowledgeable people on the list:
>
> 1) Are there any other jcl statements that are executed outside the normal
> execution phase?
>
> 2) What is the 'normal' method to issue console commands synchronized with
> the job execution?
>
> --
> Tony Thigpen
>
> --
> 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: Do we need another thread bemoaning JCL? (Was "JCL "COMMAND" statements")

[Ed Jaffe]

On 5/16/2016 8:45 AM, Charles Mills wrote:

OT, but me too. I found the order of  EXPORT and SET to be counterintuitive.


Made the mistake more than once of placing the EXPORT statement *after* 
the SET statements. But, really it's only counterintuitive if you're 
used to UNIX-style export (as apparently we both are). Otherwise, it's 
just "the way it works..."


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

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

Re: How well does z/OS handle large, but sparse, memory objects?

[Tony Harminc]

On 16 May 2016 at 11:29, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> In circumvention, AIX introduced a nonstandard signal, SIGDANGER,
> thrown when backing storage was (FSVO) nearly exhausted.

OT, but are signals "thrown"? I know that in C++ and Java, exceptions
are objects and are "thrown" (and perhaps "caught"), where in PL/I and
some other languages they are states and are "raised". But signals...?
[Just to compund things, PL/I (and REXX) has a SIGNAL verb that raises
an exception.]

Tony H.

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

Re: smp/e sha-2 support?

[Phil Smith III]

Charles Mills wrote:

>I suspect you've got a problem, however. There's a saying in sales "when
you

>explain, you lose." I can hear auditors saying "SHA-1 -- no good --
security

>exposure" and I would not want to be the one explaining what you say below

>to them.

 

>Perhaps I underestimate IT auditors. I just know the "buzzword kneejerk"

>problem.

 

I reluctantly have to support this position (not because I don't generally
agree with Charles, but because it flies in the face of reason). 

 

"Trouble is, sheep are very dim. Once they get an idea in their 'eads,
there's no shiftin' it." Same applies to far too many auditors/QSAs/et al.

 

SHA-1 is dead; "good enough" or not, there's no reason to use it any more,
given that SHA-2 (and, hey, SHA-3!) exist, eh?

 

.phsiii


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

Re: JCL "COMMAND" statements

[Nims,Alva John (Al)]

Check CBTTAPE.ORG there might be a couple of them there.

Create a REXX program to interface with TSO "OPERATOR" command or interface 
with SDSF API.
   Can check results

IEBGENER to STDRDR, use $VS'' to issue MVS commands.
  Can't check results.

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Monday, May 16, 2016 11:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL "COMMAND" statements

I have spent most of my life as a z/VSE and z/VM systems programmer, but during 
the last year, I have been managing a couple of z/OS systems in our small 
outsourcing shop.

At this point, I would consider myself just a very knowledgeable, but still 
novice z/OS systems programmer. So, be gentle with your replies. :-) And, 
please don't laugh.

Last night/this morning, I have stumped because I noticed that some JCL set up 
by a previous systems programmer was not working as it appeared it should. [At 
least, until I read the manual.]

We have many jobs set up something like thus:

//STEP1EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPTOR'
//WAIT1EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP2EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPDOR'
//WAIT2EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP3EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPAOR1'
//COMMD1   COMMAND 'S CICSPAOR2'
//WAIT3EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//*

I, of course, though the commands would be synchronized with the execution JCL. 
But, we were seeing timing errors that could not be corrected by just 
increasing the wait timers. So, I started looking for the problem and found 
that all the commands were being issued to the console before the first IEFBR14 
even executed.

I was totally surprised when I found that IBM documents the COMMAND jcl card as 
being processed during the JCL conversion phase and not during the execution 
phase. *And* that a previous systems programmer must not have known it either.

So, now I have 2 questions for the knowledgeable people on the list:

1) Are there any other jcl statements that are executed outside the normal 
execution phase?

2) What is the 'normal' method to issue console commands synchronized with the 
job execution?

--
Tony Thigpen

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

Do we need another thread bemoaning JCL? (Was "JCL "COMMAND" statements")

[Charles Mills]

> I found the counterintuitive interaction between SET and DD SYMBOLS=JCL 
> rudely astonishing.

OT, but me too. I found the order of  EXPORT and SET to be counterintuitive. 
That was the fat-fingering I was referring to that slowed me down on my 
"condition a jobstep on symbol comparison" quest. If IEBCOMPR did not log what 
it was seeing I might still be trying to figure out the problem.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, May 16, 2016 8:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL "COMMAND" statements

On Mon, 16 May 2016 11:21:00 -0400, Tony Thigpen wrote:
>
>1) Are there any other jcl statements that are executed outside the 
>normal execution phase?
> 
I found the counterintuitive interaction between SET and DD SYMBOLS=JCL rudely 
astonishing.

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

Re: JCL "COMMAND" statements

[Paul Gilmartin]

On Mon, 16 May 2016 11:21:00 -0400, Tony Thigpen wrote:
>
>1) Are there any other jcl statements that are executed outside the
>normal execution phase?
> 
I found the counterintuitive interaction between SET and DD SYMBOLS=JCL
rudely astonishing.

>2) What is the 'normal' method to issue console commands synchronized
>with the job execution?
>
My guess: a program issuing MGCR?

-- gil

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

Re: PDS I/O Performance Improvement

[Ted MacNEIL]

That's the way PDS's work. Bigger directory more connect time. Member access is 
trivial.

-teD
  Original Message  
From: Kreiter IBM-Main
Sent: Thursday, April 28, 2016 08:33
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: PDS I/O Performance Improvement

Hello, 

I'm looking for some suggestions on how to possibly improve I/O performance to 
a PDS. A user is running a job that is reading a large parmlib (through PROJCL 
I believe). I think the access is random rather than sequential. The parmlib 
has ~180,000 members is has an LRECL of 80/BLKSIZE of 27,920. The performance 
team has reviewed a found ~ 6ms response time to the volume that houses the PDS 
with most of the time being connect time.

Thanks, 
Chuck 

--
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: JCL "COMMAND" statements

[Charles Mills]

Don't know the answer to 'normal' but you are welcome to this FWIW

/* CONSCMD: Rexx to issue any arbitrary console command via SDSF */  
rc=isfcalls('ON') 
Address SDSF ,
  "ISFEXEC '/" || Arg(1) || "'"   
rc=isfcalls('OFF')

//stepname EXEC PGM=IRXJCL,   
// PARM='CONSCMD  some.console.command  ' 
//* :: :  
//* NAME OF EXEC <-->: :  
//* ARGUMENT :<--->:  
//SYSEXEC  DD   DSN=pds.where.above.stored,DISP=SHR 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Monday, May 16, 2016 8:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: JCL "COMMAND" statements

I have spent most of my life as a z/VSE and z/VM systems programmer, but during 
the last year, I have been managing a couple of z/OS systems in our small 
outsourcing shop.

At this point, I would consider myself just a very knowledgeable, but still 
novice z/OS systems programmer. So, be gentle with your replies. :-) And, 
please don't laugh.

Last night/this morning, I have stumped because I noticed that some JCL set up 
by a previous systems programmer was not working as it appeared it should. [At 
least, until I read the manual.]

We have many jobs set up something like thus:

//STEP1EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPTOR'
//WAIT1EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP2EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPDOR'
//WAIT2EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP3EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPAOR1'
//COMMD1   COMMAND 'S CICSPAOR2'
//WAIT3EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//*

I, of course, though the commands would be synchronized with the execution JCL. 
But, we were seeing timing errors that could not be corrected by just 
increasing the wait timers. So, I started looking for the problem and found 
that all the commands were being issued to the console before the first IEFBR14 
even executed.

I was totally surprised when I found that IBM documents the COMMAND jcl card as 
being processed during the JCL conversion phase and not during the execution 
phase. *And* that a previous systems programmer must not have known it either.

So, now I have 2 questions for the knowledgeable people on the list:

1) Are there any other jcl statements that are executed outside the normal 
execution phase?

2) What is the 'normal' method to issue console commands synchronized with the 
job execution?

--
Tony Thigpen

--
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: JCL "COMMAND" statements

[John McKown]

On Mon, May 16, 2016 at 10:21 AM, Tony Thigpen  wrote:

> I have spent most of my life as a z/VSE and z/VM systems programmer, but
> during the last year, I have been managing a couple of z/OS systems in our
> small outsourcing shop.
>
> At this point, I would consider myself just a very knowledgeable, but
> still novice z/OS systems programmer. So, be gentle with your replies. :-)
> And, please don't laugh.
>
> Last night/this morning, I have stumped because I noticed that some JCL
> set up by a previous systems programmer was not working as it appeared it
> should. [At least, until I read the manual.]
>
> We have many jobs set up something like thus:
>
> //STEP1EXEC PGM=IEFBR14
> //COMMD1   COMMAND 'S CICSPTOR'
> //WAIT1EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
> //STEP2EXEC PGM=IEFBR14
> //COMMD1   COMMAND 'S CICSPDOR'
> //WAIT2EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
> //STEP3EXEC PGM=IEFBR14
> //COMMD1   COMMAND 'S CICSPAOR1'
> //COMMD1   COMMAND 'S CICSPAOR2'
> //WAIT3EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
> //*
>
> I, of course, though the commands would be synchronized with the execution
> JCL. But, we were seeing timing errors that could not be corrected by just
> increasing the wait timers. So, I started looking for the problem and found
> that all the commands were being issued to the console before the first
> IEFBR14 even executed.
>
> I was totally surprised when I found that IBM documents the COMMAND jcl
> card as being processed during the JCL conversion phase and not during the
> execution phase. *And* that a previous systems programmer must not have
> known it either.
>
> So, now I have 2 questions for the knowledgeable people on the list:
>
> 1) Are there any other jcl statements that are executed outside the normal
> execution phase?
>

​If you see anything like:

/*$VS,'... some z/OS command'

it will be executed when read.


>
> 2) What is the 'normal' method to issue console commands synchronized with
> the job execution?


​I know three. The first is "insecure" and has what many consider a "nasty"
requirement. That is to use IEBGENER to copy the command(s) to the INTRDR.
This is insecure and a security problem because it allows anyone to issue
commands via the INTRDR. The INTRDR needs to be granted the authority to do
this.

A better way is to download file 246 from
http://www.cbttape.org/cbtdowns.htm . This is a batch program which will
use the MGCR macro to issue z/OS operator commands. It must be in an APF
authorized library. You can user its use by _not_ placing it on the
LINKLIST, and securing access to the APF library using your ESM (RACF, TSS,
ACF2, other).​

​The last method is to run SDSF in batch and issue commands like you would
as a TSO user.​

I just saw where Ed has a fourth method.




-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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: JCL "COMMAND" statements

[Ed Jaffe]

On 5/16/2016 8:21 AM, Tony Thigpen wrote:
2) What is the 'normal' method to issue console commands synchronized 
with the job execution?


You can send "synchronized" commands in an executable step using the 
TSO/E CONSOLE or any software product (such as (E)JES, SDSF, IOF, etc.) 
that can issue commands... Here is an example using TSO/E CONSOLE that 
issues the 'DISPLAY ASM' command:


//COMMAND EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD DATA,DLM='@@'
CONSOLE ACTIVATE
CONSOLE SYSCMD(D ASM)
@@

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

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

Re: How well does z/OS handle large, but sparse, memory objects?

[Paul Gilmartin]

On Mon, 16 May 2016 07:32:56 -0700, Ed Jaffe wrote:

>On 5/16/2016 7:23 AM, Jerry Callen wrote:
>> As an example: Does z/OS require that there be sufficient page space 
>> available to back all of the space requested for a large memory object?
>
>A virtual page is not backed by a REAL frame until it is referenced, and
>not backed by an AUX slot until that frame is paged out.
> 
Some traditional UNIX partisans found this behavior ("lazy malloc()")
a rude shock in AIX:

o They were accustomed at program initiation to malloc() a small work area
  only for recovery and orderly termination in case of an unexpected failure.
  But if the failure was for backing storage exhausted the recovery area was
  unavailable.

o In circumvention, AIX introduced a nonstandard signal, SIGDANGER,
  thrown when backing storage was (FSVO) nearly exhausted.  But that
  might be caught by an innocent, memory-conservative process that
  by happenstance caused a page fault at an inopportune time.

I don't know what techniques Windows or Linux uses to avoid these
problems for the OP.

Historically, mainframe programmers overallocate data sets, "Just in case".
But virtual DASD might cause similar undesired benavior by deferring
allocation of backend page frames.

-- gil

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

JCL "COMMAND" statements

[Tony Thigpen]

I have spent most of my life as a z/VSE and z/VM systems programmer, but 
during the last year, I have been managing a couple of z/OS systems in 
our small outsourcing shop.


At this point, I would consider myself just a very knowledgeable, but 
still novice z/OS systems programmer. So, be gentle with your replies. :-)

And, please don't laugh.

Last night/this morning, I have stumped because I noticed that some JCL 
set up by a previous systems programmer was not working as it appeared 
it should. [At least, until I read the manual.]


We have many jobs set up something like thus:

//STEP1EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPTOR'
//WAIT1EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP2EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPDOR'
//WAIT2EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//STEP3EXEC PGM=IEFBR14
//COMMD1   COMMAND 'S CICSPAOR1'
//COMMD1   COMMAND 'S CICSPAOR2'
//WAIT3EXEC PGM=WAITRCAB,PARM='30'   wait 30 seconds
//*

I, of course, though the commands would be synchronized with the 
execution JCL. But, we were seeing timing errors that could not be 
corrected by just increasing the wait timers. So, I started looking for 
the problem and found that all the commands were being issued to the 
console before the first IEFBR14 even executed.


I was totally surprised when I found that IBM documents the COMMAND jcl 
card as being processed during the JCL conversion phase and not during 
the execution phase. *And* that a previous systems programmer must not 
have known it either.


So, now I have 2 questions for the knowledgeable people on the list:

1) Are there any other jcl statements that are executed outside the 
normal execution phase?


2) What is the 'normal' method to issue console commands synchronized 
with the job execution?


--
Tony Thigpen

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

Re: How well does z/OS handle large, but sparse, memory objects?

[John McKown]

On Mon, May 16, 2016 at 10:07 AM, Edward Finnell <
000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:

> You got your PART, you got your SART and you got your Frame Allocation
> Resource Tables. Moving right along...from MVS Internals early eighties.
>

​Noticed you didn't use the acronym for the last of those ​

-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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: How well does z/OS handle large, but sparse, memory objects?

[Edward Finnell]

You got your PART, you got your SART and you got your Frame Allocation  
Resource Tables. Moving right along...from MVS Internals early eighties.
 
 
In a message dated 5/16/2016 10:03:24 A.M. Central Daylight Time,  
li...@akphs.com writes:

And z/VM  has managed cases like this forever. If you want to learn more,
suggest you  go to some z/VM sessions at SHARE. Lots of folks there who can
speak  knowledgably about this.



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

Re: How well does z/OS handle large, but sparse, memory objects?

[Phil Smith III]

And z/VM has managed cases like this forever. If you want to learn more,
suggest you go to some z/VM sessions at SHARE. Lots of folks there who can
speak knowledgably about this.

 

In case this helps, here's a simplified version of how it works: there are
segment and page tables. These indicate what pages exist and where
(in-memory, on backing store, not at all), and what segments (1MB? 16MB
these days? I forget! Been too long!)-bigger "chunks" of memory-exist. Those
can be sparse as well (since 2**64 pages would itself take a lot of memory
to describe-let's see, if a PTE (Page Table Entry) was just 4 bytes
(probably optimistic), then 2**64 bytes of memory would take
2**(64-12+4)=2**56 bits of memory just to describe, if I've done the math
right. That would be a lot.

 

Does this help?

 

.phsiii


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

Re: 1620 veterans! [was:RE: What was a 3314?]

[Tony Thigpen]

"sensible students"

*OXYMORON*

Tony Thigpen

Farley, Peter x23353 wrote on 05/16/2016 10:48 AM:

You too?  Hey, this is a small world indeed.  You didn't happen to attend a 
certain engineering college (now gone, sad to say) in Brooklyn, NY in the late 
1960's, did you?

At one point I was addicted to beating 3D TicTacToe using the 1620 console late 
nights when all sensible students were sleeping . . .

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Monday, May 16, 2016 10:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What was a 3314? (was: Whither VIO)

On Mon, May 16, 2016 at 9:09 AM, R.S. 
wrote:


W dniu 2016-05-16 o 16:01, Jerry Callen pisze:


In the "Whither VIO" thread, J.O.Skip Robinson wrote:

   In a previous life, we defined VIO (I believe) to device 3314 even

though we had none left on the floor


That's a device type I've never heard of, and the Google knows not of.
Could this be a typo for "2314"?


IMHO anything older than 3380 is prehistory or a myth ;-)



​Hum, I had a 1316 disk volume (dismountable like )​ when I was in college. It was 
used in the 1311 disk storage unit, attached to a 1620 computer. I loved that machine. A 
kind of "personal computer" for running FORTRAN II programs.

--


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


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




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

Re: 1620 veterans! [was:RE: What was a 3314?]

[John McKown]

On Mon, May 16, 2016 at 9:48 AM, Farley, Peter x23353 <
peter.far...@broadridge.com> wrote:

> You too?  Hey, this is a small world indeed.  You didn't happen to attend
> a certain engineering college (now gone, sad to say) in Brooklyn, NY in the
> late 1960's, did you?
>

​Nope. U.T. Arlington (Texas), early 70s.​


>
> At one point I was addicted to beating 3D TicTacToe using the 1620 console
> late nights when all sensible students were sleeping . . .
>

​My favorite one would "play music" by running specific instructions / data
and the radio interference could be picked up on a portable A.M. radio. It
was controlled by the console switches.


>
> Peter
>
>

-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

Maranatha! <><
John McKown

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

1620 veterans! [was:RE: What was a 3314?]

[Farley, Peter x23353]

You too?  Hey, this is a small world indeed.  You didn't happen to attend a 
certain engineering college (now gone, sad to say) in Brooklyn, NY in the late 
1960's, did you?

At one point I was addicted to beating 3D TicTacToe using the 1620 console late 
nights when all sensible students were sleeping . . . 

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Monday, May 16, 2016 10:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What was a 3314? (was: Whither VIO)

On Mon, May 16, 2016 at 9:09 AM, R.S. 
wrote:

> W dniu 2016-05-16 o 16:01, Jerry Callen pisze:
>
>> In the "Whither VIO" thread, J.O.Skip Robinson wrote:
>>
>>   In a previous life, we defined VIO (I believe) to device 3314 even
>>> though we had none left on the floor
>>>
>> That's a device type I've never heard of, and the Google knows not of.
>> Could this be a typo for "2314"?
>>
> IMHO anything older than 3380 is prehistory or a myth ;-)
>

​Hum, I had a 1316 disk volume (dismountable like )​ when I was in college. 
It was used in the 1311 disk storage unit, attached to a 1620 computer. I loved 
that machine. A kind of "personal computer" for running FORTRAN II programs.

--


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


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

How well does z/OS handle large, but sparse, memory objects?

[Jerry Callen]

The 64-bit address space available to memory objects opens up a whole range of 
algorithms that use lots of VIRTUAL memory, but relatively modest amounts of 
REAL memory. The data is "clumped" into a relatively small number of pages; 
it's not like sprinkling a few bytes all over the object, which would drive the 
real storage utilization through the roof.  I've used such algorithms 
successfully on both Windows and Linux, and I'm wondering if there are issues 
peculiar to z/OS that would make this approach infeasible.

As an example: Does z/OS require that there be sufficient page space available 
to back all of the space requested for a large memory object? I might have an 
object whose virtual size is several terabytes, but requires only a few 
gigabytes of real storage. 

With the amount of memory available on machines like the z/13 this is a 
perfectly sensible way to use memory, but if z/OS insists on having enough page 
space available for the whole object, this is not going to work.

I've done some testing on both z/OS and Linux on Z, with good results, but 
that's on LPARs specifically designated for experimentation. What might I run 
into on a production system?

-- Jerry

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

Re: How well does z/OS handle large, but sparse, memory objects?

[Ed Jaffe]

On 5/16/2016 7:23 AM, Jerry Callen wrote:

As an example: Does z/OS require that there be sufficient page space available 
to back all of the space requested for a large memory object?


A virtual page is not backed by a REAL frame until it is referenced, and 
not backed by an AUX slot until that frame is paged out.


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

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

Re: What was a 3314? (was: Whither VIO)

[John McKown]

On Mon, May 16, 2016 at 9:09 AM, R.S. 
wrote:

> W dniu 2016-05-16 o 16:01, Jerry Callen pisze:
>
>> In the "Whither VIO" thread, J.O.Skip Robinson wrote:
>>
>>   In a previous life, we defined VIO (I believe) to device 3314 even
>>> though we had none left on the floor
>>>
>> That's a device type I've never heard of, and the Google knows not of.
>> Could this be a typo for "2314"?
>>
> IMHO anything older than 3380 is prehistory or a myth ;-)
>

​Hum, I had a 1316 disk volume (dismountable like )​ when I was in
college. It was used in the 1311 disk storage unit, attached to a 1620
computer. I loved that machine. A kind of "personal computer" for running
FORTRAN II programs.



>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> ---
> Treść tej wiadomości może zawierać informacje prawnie chronione Banku
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś
> adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej
> przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie
> zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo,
> prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale
> usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee
> authorized to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility in
> your e-mail software and delete permanently this e-mail including any
> copies of it either printed or saved to hard drive.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl
> Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego
> Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP:
> 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku
> S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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: What was a 3314? (was: Whither VIO)

[R.S.]

W dniu 2016-05-16 o 16:01, Jerry Callen pisze:

In the "Whither VIO" thread, J.O.Skip Robinson wrote:


  In a previous life, we defined VIO (I believe) to device 3314 even though we 
had none left on the floor

That's a device type I've never heard of, and the Google knows not of. Could this be a 
typo for "2314"?

IMHO anything older than 3380 is prehistory or a myth ;-)

--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: smp/e sha-2 support?

[Charles Mills]

Ah! What you say makes perfect sense. I should have known.

I suspect you've got a problem, however. There's a saying in sales "when you
explain, you lose." I can hear auditors saying "SHA-1 -- no good -- security
exposure" and I would not want to be the one explaining what you say below
to them.

Perhaps I underestimate IT auditors. I just know the "buzzword kneejerk"
problem.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Eells
Sent: Monday, May 16, 2016 4:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: smp/e sha-2 support?

Dyck, Lionel B. , TRA wrote:
> We asked IBM support about implementing SHA2 for the SMP/E FTP download
process and was told to open an RFE. That seems kinda insane given that
SHA-1 seems to be heading to the heap of obsolete technologies.
>
> Can anyone shed any light on this?  Opening an RFE seems absurd given that
this is an industry standard for security that we are being forced into as I
type this and I'm sure we're not the only IBM customer who will be impacted
by the lack of SHA2 support.
>


We understand the NIST recommendation to move off SHA-1 for security-related
purposes.  However, our use of SHA-1 in this context has nothing to do with
security, and as far as I know it was never intended to provide any.  We are
using SHA-1 just to be reasonably sure that what we send over the wire is
what you get from a data integrity standpoint.  (I wrote the ServerPac part
of the design for Internet
delivery.)

As I hope everyone knows, we are shortly disallowing FTP connections at our
servers. The use of FTPS or HTTPS will be required to download z/OS platform
products and PTFs.  Secure delivery using HTTPS or FTPS uses different
algorithms for securing the link, and happens to pass through a package that
has a SHA-1 hash of its content.

So...with all that in mind...what is the actual requirement here?  Does
anyone think the probability of an undetected data integrity exposure is too
high because we're using SHA-1?  Are auditors reflexively telling you that
any use of SHA-1 for anything at all is not acceptable whether or not it's
security related?  Something else?

-- 
John Eells
IBM Poughkeepsie
ee...@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

What was a 3314? (was: Whither VIO)

[Jerry Callen]

In the "Whither VIO" thread, J.O.Skip Robinson wrote:

>  In a previous life, we defined VIO (I believe) to device 3314 even though we 
> had none left on the floor

That's a device type I've never heard of, and the Google knows not of. Could 
this be a typo for "2314"?

-- Jerry

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

Re: AW: Suggestion for conditioning step on symbols

[Elardus Engelbrecht]

John McKown wrote:

>​Well, I understand your comments on DFSORT's control language. ICETOOL + 
>SYMNAMES does a lot to enhance DFSORT. 

Indeed. ICETOOL is my friend.


>But a more "general purpose" language, building on these, might be nice.​

Agreed. I look at what is available, how that is suited for a problem at hand 
and then try out a solution or two. Sometimes off the shelf is enough, but 
sometime you need to re-invent the wheel and do your RYO thing...


>​... I'm a dumb old sysprog.

That makes two of us ... [1]  ;-)

Groete / Greetings
Elardus Engelbrecht

[1] - Geez, I had to do a COBOL trace another day, and... I had to relook at a 
source code twice just to get a grasp on what that was supposed to do... 
Previously, only a fast skim on the source was needed and I'm finished and 
ready for debugging.

Getting old is not for sissies...

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

Re: smp/e sha-2 support?

[Andrew Rowley]

On 16/05/2016 09:05 PM, John Eells wrote:
We understand the NIST recommendation to move off SHA-1 for 
security-related purposes.  However, our use of SHA-1 in this context 
has nothing to do with security, and as far as I know it was never 
intended to provide any.  We are using SHA-1 just to be reasonably 
sure that what we send over the wire is what you get from a data 
integrity standpoint.  (I wrote the ServerPac part of the design for 
Internet delivery.)


As I hope everyone knows, we are shortly disallowing FTP connections 
at our servers. The use of FTPS or HTTPS will be required to download 
z/OS platform products and PTFs.  Secure delivery using HTTPS or FTPS 
uses different algorithms for securing the link, and happens to pass 
through a package that has a SHA-1 hash of its content.


So...with all that in mind...what is the actual requirement here? Does 
anyone think the probability of an undetected data integrity exposure 
is too high because we're using SHA-1?  Are auditors reflexively 
telling you that any use of SHA-1 for anything at all is not 
acceptable whether or not it's security related?  Something else?


If the FTPS/HTTPS connections use SHA-2 and SHA-1 is only being used to 
verify the data transferred inside that connection you would hope that 
auditors would be satisfied.


Presumably they would accept data transferred securely without any 
additional verification step, so adding SHA-1 shouldn't cause an issue. 
But in that case the SHA-1 step should also not be visible to the 
network, firewalls etc. to trigger a warning.


What I would like to see is proper digital signatures for z/OS software 
packaging - for IBM and other vendors. That solves the problem of 
ensuring what you send is what you get as well as verifying the origin, 
whatever transport is used. It might only be a matter of time before 
auditors start asking for it.


Alternatively, if the FTPS/HTTPS certificates are using SHA-1 I think 
the momentum of the rest of the world will force change, whether or not 
it is a significant security exposure.


Andrew Rowley

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

Re: AW: Suggestion for conditioning step on symbols

[John McKown]

On Mon, May 16, 2016 at 7:23 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> John McKown wrote:
>
> >> You can always write a 3rd SORT system with a build in programming
> language. Hopefully that system is sort of free...
>
> >​Oh, yeah. Perhaps based on Guile (big grin)
> >https://en.wikipedia.org/wiki/GNU_Guile. It's a LISP variant.
>
> H, very very interesting part of the GNU project. I have bookmarked
> that! Many thanks!
>
>
> >​CA-Easytrieve Plus might fit your bill. Of course, being as how it's
> from CA, it is not free at all. But it is faster and easier to write than
> COBOL.​
>
> My purse (usually empty and made from scottish leather) will drop me real
> faster than I write than COBOL or use that software ...
>
> Groete / Greetings
> Elardus Engelbrecht
>
>
​Well, I understand your comments on DFSORT's control language. ICETOOL +
SYMNAMES does a lot to enhance DFSORT. But a more "general purpose"
language, building on these, might be nice.​

​I can imagine such a thing, even though I don't have the talent to
actually design it. ​I'm not an application programmer, I'm a dumb old
sysprog.


-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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: AW: Suggestion for conditioning step on symbols

[Elardus Engelbrecht]

John McKown wrote:

>> You can always write a 3rd SORT system with a build in programming language. 
>> Hopefully that system is sort of free...

>​Oh, yeah. Perhaps based on Guile (big grin)
>https://en.wikipedia.org/wiki/GNU_Guile. It's a LISP variant.

H, very very interesting part of the GNU project. I have bookmarked that! 
Many thanks!


>​CA-Easytrieve Plus might fit your bill. Of course, being as how it's from CA, 
>it is not free at all. But it is faster and easier to write than COBOL.​

My purse (usually empty and made from scottish leather) will drop me real 
faster than I write than COBOL or use that software ... 

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

Re: [EXTERNAL] Re: smp/e sha-2 support?

[John McKown]

On Mon, May 16, 2016 at 6:22 AM, Dyck, Lionel B. (TRA) 
wrote:

> The auditors are dictating the use of SHA-2 and discounting the use of
> SHA-1. It is a blanket requirement and one that one does not argue with.
>

​Another reason to "off" all auditors. Ignoramuses.

-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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: AW: Suggestion for conditioning step on symbols

[John McKown]

On Mon, May 16, 2016 at 4:31 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Peter Hunkeler wrote:
>
> >Not sure whether I shall laugh or cry. DFSort is a great tool, no doubt;
> it's control statements (I intentionally don't called it "language") are a
> nightmare, no doubt. Hopefully noone will ever consider the above as
> something suitable for production. Overkill; not maintainable.
>
> Perhaps, this is why ICETOOL is in place. That is a great tool.
>
> You can always write a 3rd SORT system with a build in programming
> language. Hopefully that system is sort of free...
>

​Oh, yeah. Perhaps based on Guile (big grin)
https://en.wikipedia.org/wiki/GNU_Guile. It's a LISP variant.


>
> Something like this, sort of, but ...
>
> PROGRAM Sort-it-Yourself
>
> Declaration fiels left to programmer as an exercise...
>
> OPEN IN
> OPEN OUT
>
> For records 1 - last do
>  sort by surname
>  output name, surname, phone number
> end for
>
> SHOW records 'Records sorted by surname.'
>
> Close everything;
>
> SHOW ' You're sorted out!'
>

​CA-Easytrieve Plus might fit your bill. Of course, being as how it's from
CA, it is not free at all. But it is faster and easier to write than COBOL.​



>
> Groete / Greetings
> Elardus Engelbrecht
>
>
-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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: [EXTERNAL] Re: smp/e sha-2 support?

[Dyck, Lionel B. (TRA)]

The auditors are dictating the use of SHA-2 and discounting the use of SHA-1. 
It is a blanket requirement and one that one does not argue with. 

--
Lionel B. Dyck (Contractor)
Mainframe Systems Programmer 
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
VA OI Service Delivery & Engineering
Office: 512-326-6173


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Monday, May 16, 2016 6:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: smp/e sha-2 support?

Dyck, Lionel B. , TRA wrote:
> We asked IBM support about implementing SHA2 for the SMP/E FTP download 
> process and was told to open an RFE. That seems kinda insane given that SHA-1 
> seems to be heading to the heap of obsolete technologies.
>
> Can anyone shed any light on this?  Opening an RFE seems absurd given that 
> this is an industry standard for security that we are being forced into as I 
> type this and I'm sure we're not the only IBM customer who will be impacted 
> by the lack of SHA2 support.
>


We understand the NIST recommendation to move off SHA-1 for security-related 
purposes.  However, our use of SHA-1 in this context has nothing to do with 
security, and as far as I know it was never intended to provide any.  We are 
using SHA-1 just to be reasonably sure that what we send over the wire is what 
you get from a data integrity standpoint.  (I wrote the ServerPac part of the 
design for Internet
delivery.)

As I hope everyone knows, we are shortly disallowing FTP connections at our 
servers. The use of FTPS or HTTPS will be required to download z/OS platform 
products and PTFs.  Secure delivery using HTTPS or FTPS uses different 
algorithms for securing the link, and happens to pass through a package that 
has a SHA-1 hash of its content.

So...with all that in mind...what is the actual requirement here?  Does anyone 
think the probability of an undetected data integrity exposure is too high 
because we're using SHA-1?  Are auditors reflexively telling you that any use 
of SHA-1 for anything at all is not acceptable whether or not it's security 
related?  Something else?

-- 
John Eells
IBM Poughkeepsie
ee...@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: smp/e sha-2 support?

[John Eells]

Dyck, Lionel B. , TRA wrote:

We asked IBM support about implementing SHA2 for the SMP/E FTP download process 
and was told to open an RFE. That seems kinda insane given that SHA-1 seems to 
be heading to the heap of obsolete technologies.

Can anyone shed any light on this?  Opening an RFE seems absurd given that this 
is an industry standard for security that we are being forced into as I type 
this and I'm sure we're not the only IBM customer who will be impacted by the 
lack of SHA2 support.




We understand the NIST recommendation to move off SHA-1 for 
security-related purposes.  However, our use of SHA-1 in this context 
has nothing to do with security, and as far as I know it was never 
intended to provide any.  We are using SHA-1 just to be reasonably sure 
that what we send over the wire is what you get from a data integrity 
standpoint.  (I wrote the ServerPac part of the design for Internet 
delivery.)


As I hope everyone knows, we are shortly disallowing FTP connections at 
our servers. The use of FTPS or HTTPS will be required to download z/OS 
platform products and PTFs.  Secure delivery using HTTPS or FTPS uses 
different algorithms for securing the link, and happens to pass through 
a package that has a SHA-1 hash of its content.


So...with all that in mind...what is the actual requirement here?  Does 
anyone think the probability of an undetected data integrity exposure is 
too high because we're using SHA-1?  Are auditors reflexively telling 
you that any use of SHA-1 for anything at all is not acceptable whether 
or not it's security related?  Something else?


--
John Eells
IBM Poughkeepsie
ee...@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: PVT Storage z/OS Upgrade

[Elardus Engelbrecht]

Peter wrote:

>This is just a question out of curiosity. On every zOS Upgrade the PVT Storage 
>remain same. Are there any factor that might increase the PVT Storage?

Above or below the line? Also answer depends on how you configure your storage 
in total and what your software mix is.

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

Re: PVT Storage z/OS Upgrade

[Binyamin Dissen]

On Mon, 16 May 2016 13:51:05 +0530 Peter  wrote:


:>This is just a question out of curiosity. On every zOS Upgrade the PVT
:>Storage remain same. Are there any factor that might increase the PVT
:>Storage?

A big enough CSA/LPA increase would do it, likelihood depending on how much
slack you currently have. 

I would guess much of the new stuff is above the line so you will not be
losing low private.

Others have lost private.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: AW: Suggestion for conditioning step on symbols

[Elardus Engelbrecht]

Peter Hunkeler wrote:

>Not sure whether I shall laugh or cry. DFSort is a great tool, no doubt; it's 
>control statements (I intentionally don't called it "language") are a 
>nightmare, no doubt. Hopefully noone will ever consider the above as something 
>suitable for production. Overkill; not maintainable.

Perhaps, this is why ICETOOL is in place. That is a great tool.

You can always write a 3rd SORT system with a build in programming language. 
Hopefully that system is sort of free...

Something like this, sort of, but ...

PROGRAM Sort-it-Yourself

Declaration fiels left to programmer as an exercise...

OPEN IN
OPEN OUT

For records 1 - last do
 sort by surname
 output name, surname, phone number
end for

SHOW records 'Records sorted by surname.'

Close everything;

SHOW ' You're sorted out!'

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

PVT Storage z/OS Upgrade

[Peter]

Hi

This is just a question out of curiosity. On every zOS Upgrade the PVT
Storage remain same. Are there any factor that might increase the PVT
Storage?

Peter

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

AW: Suggestion for conditioning step on symbols

[Peter Hunkeler]

>So, changed those to non-printable. That would fix it up, but the code is 
>still suffering from having to change >horses in mid-stream. And there's the 
>fat-fingering, which is an all-too-common issue.
 >
>Leads to sort symbols, WHEN=INIT, two FINDREPs with STARTPOS and DO=1 and 
>SHIFT=NO.
 >
>//CHEKPARM EXEC PGM=SORT,PARM='JP1"",JP2""'
>//SYMNAMES DD *
>* RECORD FIELDS TO CREATE AND MANIPLUATE
>FIRST-COMPARATOR,*,80,CH
>SECOND-COMPARATOR,*,=,=
>* CONSTANTS
>DUMMY-VALUE1-TO-REPLACE,X'FD'
>DUMMY-VALUE2-TO-REPLACE,X'FE'
>//SYMNOUT  DD SYSOUT=*
>//SYSOUT   DD SYSOUT=*
>//SORTOUT  DD SYSOUT=*
>//SYSINDD *
>OPTION COPY,STOPAFT=1
>
>INREC  IFTHEN=(WHEN=INIT,
>OVERLAY=(FIRST-COMPARATOR:
>DUMMY-VALUE1-TO-REPLACE,
>79X,
>SECOND-COMPARATOR:
>DUMMY-VALUE2-TO-REPLACE,
>79X)),
>IFTHEN=(WHEN=INIT,
>FINDREP=(IN=DUMMY-VALUE1-TO-REPLACE,
>OUT=JP1,
>STARTPOS=1,
>DO=1,
>SHIFT=NO)),
>IFTHEN=(WHEN=INIT,
>FINDREP=(IN=DUMMY-VALUE2-TO-REPLACE,
>OUT=JP2,
>STARTPOS=81,
>DO=1,
>SHIFT=NO))
>OUTFIL INCLUDE=(FIRST-COMPARATOR,
>EQ,
>SECOND-COMPARATOR),
>NULLOFL=RC4
>//SORTIN   DD *
>CONTENT IMMATERIAL
 >
>If concerned that it is overly wordy (some people have a problem with that), 
>...



Not sure whether I shall laugh or cry. DFSort is a great tool, no doubt; it's 
control statements (I intentionally don't called it "language") are a 
nightmare, no doubt. Hopefully noone will ever consider the above as something 
suitable for production. Overkill; not maintainable.


--
Peter Hunkeler


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

AW: Re: EAV bug or feature?

[Peter Hunkeler]

>So if you want to use EAV's, make them SMS. ...



... and be prepared to have to deal with strange errors with software which is 
not EAV-savvy, i.e. which show strange behaviour with cylinder managed block 
addresses. E.g. code written with SAS-C may not like them.


--
Peter Hunkeler



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

AW: Re: Whither VIO?

[Peter Hunkeler]

>[snip] Expanded storage is one of those things that, for a combination of 
>technical and marketing reasons, had its day in the sun and has gone, while 
>VIO continues.


It's back, just called "Flash Express" these days. It's used for paging, and 
for some other things (or things to come) just as Expanded Storage was.


--
Peter Hunkeler



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

Re: Can a FRR routine be in the SASN address space

[Binyamin Dissen]

On Sun, 15 May 2016 22:24:51 -0400 michelbutz  wrote:

:>The documentation states that SETFRR can be issued ASC AR mode and PASN |= 
SASN |= HASN

:>so can the recovery routine itself be in a secondary address space I am 
taking protecting the code in the primary address space 

Instruction fetch is only from primary (if in primary/secondary/AR mode), home
(if in home mode) or dat-off (if dat is off).

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: XMEM and Swap ability

[Binyamin Dissen]

On Sun, 15 May 2016 15:55:37 -0400 michelbutz  wrote:

:>Forget about my design how about 
:>A general XMEM question what the point if
:>You are going to get S0C4

Why would I ignore a bad design?

 If you are asking for advice, be humble enough to accept that others already
went down the path and are aware of the dangers.

Explain why you need access to the other address space. What is your business
case?

:>> On May 15, 2016, at 2:30 PM, Binyamin Dissen  
wrote:
 
:>> On Sun, 15 May 2016 14:12:39 -0400 michealbutz 
:>> wrote:
 
:>> :>Transferring data between 2 address spaces weather its MVCP/MVCS or AR 
mode
:>> :>there is always the possibility of a S0C4. 
 
:>> :>What the best way of making sure the target Address Space is Swapped in.
:>> :>Doing XMEM post to  the target address space  to do a SYSEVENT ?  

:>> Terrible design. You should rethink it.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


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

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

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