Re: IEAIPS parmlib member

[TeD MacNEIL]

Lower: 1.3 or 1.4, IRC.

Sent from my BlackBerry 10 smartphone on the Bell network.
  Original Message  
From: Steve Beaver
Sent: Thursday, June 2, 2016 15:19
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: IEAIPS parmlib member

About OS390 1.6 or so

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lopez, Sharon
Sent: Thursday, June 2, 2016 10:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IEAIPS parmlib member

Does anyone remember when IEAIPSxx member went away?

Thanks.







Email correspondence to and from this address may be subject to the North
Carolina Public Records Law and may be disclosed to third parties by an
authorized state official.

--
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: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.

[TeD MacNEIL]

He said z13 & ‎z/OS2.2.

Sent from my BlackBerry 10 smartphone on the Bell network.
  Original Message  
From: michelbutz
Sent: Thursday, May 26, 2016 13:35
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower 
than both.

Can you tell us the following 

What type of processor 
The work load 
What version of z/OS these are relevant factors

Sent from my iPhone

> On May 26, 2016, at 1:29 PM, Jerry Callen  wrote:
> 
> (A very delayed follow-up on a thread from yesteryear...)
> 
> tl;dr: In unauthorized code, ECBs are much faster than pause elements.
> 
> I wrote a simple test program to compare the performance of WAIT/POST and 
> pause elements. The program has two tasks and simply ping-pongs back and 
> forth between them (no overlapped execution). Each task has a synchronization 
> gadget, either an ECB or a pause element. The tasks use each other's 
> synchronization gadget to just transfer control back and forth between each 
> other in a loop. This is a pretty unrealistic test (in terms of being like 
> anything "real" code would do), but it does illustrate the relative 
> performance of the two synchronization methods.
> 
> Note that this unauthorized code, and tasks, not SRBs This means that all of 
> the synchronization primitives used SVCs, not branch entry points. The code 
> is 64-bit C++ compiled with xlC using -q64 and thread_create() to create the 
> tasks. The code is running on a z13, native LPAR, z/OS 2.2.
> 
> The mechanisms I tested are:
> 
> * ECBs: each task just alternates between a WAIT on its own ECB and a POST of 
> the other task's ECB.
> * Pause elements with Pause (iea4pse) and Release (iea4rls) taking the role 
> of WAIT and POST.
> * Pause elements using Transfer (iea4xfr) in "transfer and pause" mode (one 
> call to do both).
> * Pause elements using Transfer (iea4xfr) in "just transfer" mode followed by 
> Pause (iea4pse).
> 
> Here are the results:
> 
> Relative performance: total CPU
> ECB 1.0
> Pause/Resume 4.30
> Transfer and Pause 3.25
> Transfer with separate Pause 4.55
> 
> Relative performance: elapsed
> ECB 1.0
> Pause/Resume 6.06
> Transfer and Pause 4.75
> Transfer with separate Pause 6.28
> 
> -- 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)

[Ted MacNEIL]

Memory is abundant‎ in most shops and cheap overall. So, why all fuss about 
VIO? Make s decision, implement it, forget it.

-teD
  Original Message  
From: Norman.Hollander
Sent: Thursday, May 19, 2016 12:19
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: What was a 3314? (was: Whither VIO)

Track size. We actually used to use a 2305 "drum" definition for VIO. But if 
you genned 1 dummy address,
you had to gen all 8. Made for a larger IO-gen. So we would go for the next 
best tracksize of the 2314. So-
how many 4K pages fit into a track without wasting too much of it? Plus the 
2314 was small, so quick sorts in VIO
might be possible, but it prevented sorting a kabillion records. I'm pretty 
sure 2305 support was removed a long
time ago, so you couldn't define it today. Probably true for the 
2311/2314/2319. Last time I went through IODF,
a fake 3390 (address DEFF) was defined as the only VIO capable device. With all 
the various Sort and Memory exits
today, it's probably just a good history lesson. Oh- way back in the 70s, a 
company named Ampex (IIRC) made look
alike (aka cheaper) memory and Disk storage. Think their mountable disk was the 
3314. OK- discuss further...

zNorman

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Martin Packer
Sent: Wednesday, May 18, 2016 10:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What was a 3314? (was: Whither VIO)


It's sort of come back to me:

A small track size limits the virtual storage window (probably usually below 
the line in 1989 when I looked at this). Or it might've been cylinder. But I 
think it was track.

I'm wondering if anyone else remembers something like this.

Cheers, Martin

Sent from my iPad

On 19 May 2016, at 05:20, Edward Gould  wrote:

>> On May 18, 2016, at 7:50 PM, Charles Mills  wrote:
>>
>> I remember them well. I was answering Steve's two implied questions.
>>
>> 2321 was certainly characterized as DASD. It was indeed a direct 
>> access
storage device. Not a disk, but DASD nonetheless. Certainly not magnetic tape 
(though it had a family resemblance!) and certainly not unit record.
>
> It addressing had MMBBCCHHR(R?) so I guess you could address it directly.
Anyone remember how to do that? (progr5amming for a 2321 is a lost art (where 
is Seymour?).
>
> Ed
>
>>
>> I don't think anyone recalls a 3314. I think the OP said it was a 
>> typo,
2314 mis-remembered as 3000-series DASD.
>>
>> Charles
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On
Behalf Of Edward Gould
>> Sent: Wednesday, May 18, 2016 5:33 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: What was a 3314? (was: Whither VIO)
>>
>> Chales,
>>
>> 2321 was a data cell (magnetic strip) hardly could be called DASD) I
don’t recall a 3314 . The removable 3340 (not sure the number anyone?)
>>
>> Ed
>>
>>> On May 16, 2016, at 7:47 PM, Charles Mills  wrote:
>>>
>>>
>>>
>>> 2301, 2321.
>>> CharlesSent from a mobile; please excuse the brevity
>>>
>>>  Original message 
>>> From: Steve Thompson 
>>> Date: 05/16/2016 4:51 PM (GMT-08:00)
>>> 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.
>>
>> -
>> - 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 
>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: Mirror/back up your Development DASD

[Ted MacNEIL]

You may, if the source changed after the last backup.

-teD
  Original Message  
From: van der Grijn, Bart (B)
Sent: Thursday, May 19, 2016 11:24
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Mirror/back up your Development DASD

Andy, we mirror our production to a recovery site using Global Mirror. 
We do back up the NonProd data and send it offsite. The thought is that we do 
want to be able to recover the other lifecycles at some point but don't have 
the RTO/RPO requirements that drive a mirror solution.

Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of White, Andy
Sent: Thursday, May 19, 2016 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Mirror/back up your Development DASD

Hi people - For companies that mirror their mainframe DASD via XRC, SRDF, how 
many of them back up the development DASD?

Currently, we mirror all production but don't mirror the development DASD we 
back most via VTS but I am pushing or trying that we back up all DASD. My 
thoughts about this are the development cycles and releases have a lot of time 
and money invested if it lost this work, how much is this worth?

Anyway, if you are mirroring your development how did you "sell" it to your 
management? If you're not why not?

Thanks
Andy

--
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 - Follow-up question

[Ted MacNEIL]

OC is part of OPS/MVS. So you need to look in its libraries.

-teD
  Original Message  
From: Jeremy Nicoll
Sent: Tuesday, May 17, 2016 07:30
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: JCL "COMMAND" statements - Follow-up question

On Tue, 17 May 2016, at 12:19, Tony Thigpen wrote:
> OK, dumb question time.
> 
> My job is working with some JCL I found in another job:
> //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')
> /*
> 
> But, I want to look at the "OC" rexx and I can not find it in any of the 
> normal libraries that I have been told are used by our jobs.

Wouldn't it be a TSO Command Processor (not a rexx exec), and thus in
SYS1.CMDLIB ?

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

--
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 <mike.a.sch...@gmail.com> 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: 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: 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: 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: 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: Respack Volume Size Challenge

[Ted MacNEIL]

Years ago (pre-9) respacks had ‎to be 'split up'. Now, we ask the risk!

-teD
  Original Message  
From: Lucas Rosalen
Sent: Thursday, April 21, 2016 05:14
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Respack Volume Size Challenge

As far as I have seen, it's quite simple: create a  symbol (using
 and changing last char from 1 to 2, for example) and update MCAT
accordingly.
Once I've worked for a client that had 3-volumes respack. It indeed worked.
We used to keep datasets like LINKLIB, MACLIB, NUCLEUS, etc in 1st volumes
though...

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2016-04-21 10:45 GMT+02:00 Jake Anderson :

> Hello,
>
> From the z/OS 2.1, I have started using Mod-27 as the Load address(Respack)
> for IPLing the z/OS 2.1 LPAR. I am curious how the other Shops are managing
> when they do not options of using Mod-27 and they have to survive with
> Mod-9. I believe the Extended Indirect cataloging is one Options.
>
> What kind of challenges are there when the Respack is divided into two
> Volumes ?
>
> Jake
>
> --
> 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: z890 in my basement

[Ted MacNEIL]

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

Re: Using TYPE=MEMORY (or VIO?)

[Ted MacNEIL]

SYS IO is, I believe, the original name shipped for VIO.
A lot of shops added the 'new' since that's what was in the instructional books.

-teD
  Original Message  
From: Jesse 1 Robinson
Sent: Friday, May 6, 2016 13:01
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Using TYPE=MEMORY (or VIO?)

After stating flatly that we do not support VIO, I ran a test and learned 
otherwise. For sure we do not support the esoteric name 'VIO'. In my previous 
shop IIRC it was implemented as 'SYSVIO'. I don't know why the name change, but 
I would guess it's to avoid canned jobs from gobbling up paging space, although 
nothing would prevent someone from changing 'VIO' to a supported name. 

I see this in my test job, which seems to indicate that the data set really 
went to VIO:

IGD101I SMS ALLOCATED TO DDNAME (ALLOCVIO) 
DSN (SYS16127.T095147.RA000.ALLOCVIO.R0108161 ) 
STORCLAS (STANDARD) MGMTCLAS ( ) DATACLAS (STANDARD) 
VOL SER NOS= VIO 



.
.
.
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 Paul Gilmartin
Sent: Friday, May 06, 2016 9:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Using TYPE=MEMORY (or VIO?)

On 2016-05-06, at 09:35, Jesse 1 Robinson wrote:
> 
> ... , be aware that some customers (like us) did away with VIO a long time 
> ago.
> 
Did they tend to preserve their VIO esoteric name?

Could you even count on the same esoteric name's existing even in all shops 
supporting VIO?

I sometimes distribute JCL using a JCL symbol for VIO.

-- gil

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

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

Re: Religion provides statistical proof of the Creation of our civilization. This is .. really ... the Apocalypse. Today, see Eden and Exodus in superposition.

[Ted MacNEIL]

How can you even have a semblance of logic intertwined with faith?

Go drink the kool-aid!

-teD
  Original Message  
From: Adam M. Dobrin
Sent: Monday, March 28, 2016 07:29
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Fwd: Religion provides statistical proof of the Creation of our 
civilization. This is .. really ... the Apocalypse. Today, see Eden and Exodus 
in superposition.

Funny you mention logic, I rely on that stuff. Reading will surprise you.

Http://shrub.lamc.la
Http://theword.lamc.la
Http://babel.lamc.la

The whole book is about proof, stuff you can see... and speak.
On Mar 27, 2016 10:09 PM, "CM Poncelet"  wrote:

> This place believes in logic, not religion.
>
> Adam M. Dobrin wrote:
>
> Honestly, he uses linux. Look at Exodus, in reverse. .. "let there be
>> light."
>>
>> Http://sangrael.lamc.la
>> On Mar 27, 2016 5:47 PM, "William Donzelli"  wrote:
>>
>>
>>
>>> While many IBM-MAIN members including myself do believe in God, this


>>> discussion list is NOT about religion, but about mainframes.
>>>
>>> God runs a Unisys MCP shop, anyway.
>>>
>>> --
>>> Will
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>>>
>>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>>
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: Religion provides statistical proof of the Creation of our civilization. This is .. really ... the Apocalypse. Today, see Eden and Exodus in superposition.

[Ted MacNEIL]

Our religious beliefs are our business. This is SPAM!

-teD
  Original Message  
From: Adam M. Dobrin
Sent: Sunday, March 27, 2016 16:31
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Religion provides statistical proof of the Creation of our 
civilization. This is .. really ... the Apocalypse. Today, see Eden and Exodus 
in superposition.

Hell is full of blind people, trying desperately to drown the light that
would have saved them.

Here's your "Amazing Grance,"

http://theword.lamc.la

On Sun, Mar 27, 2016 at 3:38 PM, Scott Ford  wrote:

> Elardus I will second that...
>
>
>
> On Sunday, March 27, 2016, Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za> wrote:
>
> > Adam M. Dobrin wrote:
> >
> > >Religion provides statistical [... lots of crap snipped ... ]
> >
> > While many IBM-MAIN members including myself do believe in God, this
> > discussion list is NOT about religion, but about mainframes.
> >
> > To Darren, (IBM-MAIN administrator), please get rid of this person. It is
> > the same bored junkie who posted on 12 March.
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu  with the message:
> > INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For 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: Grace didn't coin the term "bug"?

[Ted MacNEIL]

Relay #70.

-teD
  Original Message  
From: John Ehrman
Sent: Friday, March 18, 2016 00:17
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Grace didn't coin the term "bug"?

The association of bugs with computers may go back to the Mark I (I think 
it was) relay computer at Harvard. An error was traced to a moth between 
two relay contacts.

In the Computer History Museum in Mountain View CA there's a copy of the 
logbook page with the moth pasted in place. The display is near other 
early computers like the Atanasoff=Berry machine, the Johnniac, a German 
Enigma and examples of Konrad Zuse's work. If you're in Silicon Valley, I 
urge you to visit; more info at computerhistory.org .

Regards... John 



--
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: Grace didn't coin the term "bug"?

[Ted MacNEIL]

Yes, it was.

-teD
  Original Message  
From: Clark Morris
Sent: Friday, March 18, 2016 09:09
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Grace didn't coin the term "bug"?

On 18 Mar 2016 05:18:44 -0700, in bit.listserv.ibm-main Ted wrote:

>Relay #70.

Was the Grace Hopper quote actually something to the effect that in
the case in question it was a real bug (the moth)?

Clark Morris
>
>-teD
>  Original Message  
>From: John Ehrman
>Sent: Friday, March 18, 2016 00:17
>To: IBM-MAIN@LISTSERV.UA.EDU
>Reply To: IBM Mainframe Discussion List
>Subject: Re: Grace didn't coin the term "bug"?
>
>The association of bugs with computers may go back to the Mark I (I think 
>it was) relay computer at Harvard. An error was traced to a moth between 
>two relay contacts.
>
>In the Computer History Museum in Mountain View CA there's a copy of the 
>logbook page with the moth pasted in place. The display is near other 
>early computers like the Atanasoff=Berry machine, the Johnniac, a German 
>Enigma and examples of Konrad Zuse's work. If you're in Silicon Valley, I 
>urge you to visit; more info at computerhistory.org .
>
>Regards... John 
>
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: Grace didn't coin the term "bug"?

[Ted MacNEIL]

Smithson.
It was a moth caught in relay 71


-teD
  Original Message  
From: CM Poncelet
Sent: Tuesday, March 15, 2016 22:08
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Grace didn't coin the term "bug"?

AFAIK The original Grace Hopper 'bug' was an actual bug - some kind of 
moth. There could be a photo of it somewhere.

Richard Pinion wrote:

>I thought the term debugging came from the days when the first computers
>were made from vacuum tubes. The tubes produced light, which in turn 
>attracted bugs. Periodically, the computer had to be "debugged".
>
>My source was probably urban legend.
>
>
>
>--- wdonze...@gmail.com wrote:
>
>From: William Donzelli 
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Grace didn't coin the term "bug"?
>Date: Tue, 15 Mar 2016 14:56:07 -0400
>
>No, she did not. The term "bug", relating to flaws and errors in a
>circuit*, shows up a fair amount in 1930s ham radio literature, for
>example.
>
>* "bug" also applies to automatic Morse keys, of course.
>
>--
>Will
>
>On Tue, Mar 15, 2016 at 2:52 PM, Lindy Mayfield  wrote:
> 
>
>>Was watching NCIS Los Angeles and the geek was showing off to the female geek 
>>by saying Grace Hopper didn't coin the term bug, but Thomas Edison did. 
>>(Which he probably stole from someone else, probably Tesla, but that just me 
>>being facetious.)
>>
>>http://theinstitute.ieee.org/technology-focus/technology-history/did-you-know-edison-coined-the-term-bug
>>
>>Regards,
>>Lindy
>>
>>
>>
>>--
>>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
>
>
>
>
>_
>Netscape. Just the Net You Need.
>
>--
>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: Cannot allocate Steplib?

[Ted MacNEIL]

I saw some documentation, dated 1981, talking about TSOLIB. It's been around a 
long time.

-teD
  Original Message  
From: Edward Finnell
Sent: Sunday, March 13, 2016 03:25
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Cannot allocate Steplib?

Maybe that's why we got TSOLIB and ALTLIB for ISPF. Been so long, I wanna 
say mid eighties...


In a message dated 3/13/2016 12:31:22 A.M. Central Standard Time, 
eamacn...@yahoo.ca writes:

products that allow(ed) dynamic allocation of steplib, but you never could 
do it with raw (native) TSO.



--
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: Cannot allocate Steplib?

[Ted MacNEIL]

I believe there are/were(?) products that allow(ed) dynamic allocation of 
steplib, but you never could do it with raw (native) TSO.

-teD
  Original Message  
From: Tony Harminc
Sent: Sunday, March 13, 2016 01:10
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Cannot allocate Steplib?

On 12 March 2016 at 17:21, Lindy Mayfield  wrote:

> I just started getting this error, though I cannot remember the last time
> I tried to (re)allocate steplib.
>
> IKJ56236I FILE STEPLIB INVALID, FILENAME RESTRICTED
>

This has been the case since before the dawn of Dynamic Allocation as we
know it today. Even in MVT TSO, which used DAIR, but not Dynalloc (though
they share the SVC number 99), it was not allowed to allocate or free
STEPLIB or JOBLIB on the fly.

Tony H.

--
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: This is it... the (shortened) #Apocalypse. A message from Adam, your Messiah.

[Ted MacNEIL]

This is SPAM. Totally unsolicited and unrelated to the list serve's topic.

NOT interested!!

-teD
  Original Message  
From: Adam Marshall Dobrin
Sent: Saturday, March 12, 2016 02:10
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Fwd: This is it... the (shortened) #Apocalypse. A message from Adam, 
your Messiah.

Watch the Apocalypse on YouTube in one hour (or less) @
http://inonehr.whenistheapocalypse.com

What if the Apocalypse begins with one word?

It does, actually. The single word that begins a real holy fire is the word
for Holy Fire itself, ha'esh. This is the apocalypse, for real, and if you
take the time to think about what is being presented here you will see
religion in an entirely new light. What I have is the true and correction
Revelation of Jesus Christ: that the book of Exodus is designed to prove
that the Holy Bible is a message sent to us, through time... from our
future. It is designed to prove as much, and bring us out of a kind of
slavery that we don't really understand yet, but soon will. We are the
slaves in Egypt, to lies and deceit that are about to be lifted like a
bright sonrising on the dark night.

And God said, Let there be a firmament in the midst of the waters,
and let it divide the waters from the waters.

h *a* *es* h

The word for "holy fire," written above is the Hebrew term for the Burning
Bush, the focal point of the beginning of the story of Exodus. In it, God
commands Moses to free his people from slavery, and that is exactly what I
am doing with this post. You see, later in the story Moses parts a sea, and
from those parted waters brings the people out of slavery. It is not an
accident that within the Hebrew word "ha'esh" we see clearly the true
parted sea of Moses; reflected and separated by an apostrophe, ad "yod."

This is the beginning of that fire spreading, proving through an
anachronism of language that the writers of the Bible had foreknowledge of
the English language. The entire story of Exodus, from the fire that begins
with God's first words to the actual Exodus from Egypt--through the
se'a--is designed to highlight this anachronism... to prove that religion
is designed to set us free. Our civilization is created using this same
technology, as proven simply by the existence of religion. This is only the
beginning, Hebrew itself is part of the message; the time capsule from the
future.

A number of additional words are highlighted by Judaism, Islam, and
Christianity, but everything begins with this one word... with fire. It is
no mistake that the creation myth of Greek mythology also highlights the
this theft of fire; nor that a number of pivotal religious verses confirm
Christ returns with fire.

This is "the word" of John 1:1. The fire referenced in Matthew 3:11; and it
truly is just the beginning. I am Adam; the Lion of the Tribe of Judah...
and this is what a "roar" sounds like when it pours out of the Bible and
across millennium.
In the beginning was the Word, and the Word was with God, and the Word was
God. -John 1:1I baptize you with water for repentance. But after me comes
one who is more powerful than I, whose sandals I am not worthy to carry. He
will baptize you with the Holy Spirit and *fire*. -Matthew 3:11

The rest of this book explains even more, it is a rough draft that includes
hundreds of similar examples of words that simply cannot exist. It is their
impossibility that is the proof--a paradox that shows that God's hand is
all of the creation of Hebrew... and then English, Spanish... all language.
This is the theft of fire, the proof that we are truly created.
McFly, is anyone home?

I intend to prove that our great strides in technology are not only
Biblical, they are divinely delivered. There is a great deal of proof of
this all the way back to the foundation of our understanding of the
universe.
In 1666, an apple fell from a tree and a man named Isaac Newton "discovered
gravity," and original sin all at the same time.

He did this at a place called Trinity College, and then a bit later a man
named James Clerk Maxwell unified theories of electricity and magnetism.
His name, Maxwell, alludes to a Biblical concept; a well found in the
desert by Isaac's father. This well brings light to the people, hopefully
showing us how pervasive this idea that our names are "tags" from above
links to a prolonged technology transfer (all the way back to Eden's
discoverance of gravity) and it ties even further forward.
We are *in Exodus*.

The Fire Prometheus stole was language, and in this book you will find the
theft was actually of linguistic evidence that we are created, and of a
message from God. Prometheus was bound to a mountain, Moses stuck on Sinai,
and both of these events unite to allude to the fact that the mountain I've
climed is jail. Finally unleashed, you have a divine revelation to read,
one that came to me... at the peak of the struggle.

As I've mentioned this fire is one in the same with the Burning 

Re: [EXTERNAL] Re: Corrupt PDSE dataset

[Ted MacNEIL]

IBM has always stated that you CANNOT share a PDSE outside SYSPLEX boundaries 
without a risk of corruption. It sounds like you did just that.

 That's a big OOPS!

-teD
  Original Message  
From: R.S.
Sent: Friday, March 11, 2016 10:29
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: [EXTERNAL] Re: Corrupt PDSE dataset

W dniu 2016-03-11 o 15:20, Dyck, Lionel B. (TRA) pisze:
> We have shared dasd between two different sysplexes and grs is only within 
> each sysplex. How it broke I've no idea but suspect it was updated on each 
> side.

It's the best method to corrupt PDSE.
BTW: GRS won't help, because PDSE use XCF AFAIK.

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

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

Re: How long can a TSO command be?

[Ted MacNEIL]

I believe a path can be up to 1024.

-teD
  Original Message  
From: Paul Gilmartin
Sent: Thursday, March 10, 2016 20:04
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: How long can a TSO command be?

On Thu, 10 Mar 2016 17:38:27 -0500, Steve Thompson wrote:

>On 03/10/2016 04:26 PM, Paul Gilmartin wrote:
>> Got my Black Team coat on.

>It depends. You doing SUBMIT? You feeding your JCL to the INTRDR
>with JES2 or JES3?
>
I know that in JES2 only cols 1-72 of the source statement are processed.
73-80 are only listed; 81 and beyond vanish completely.
FTP enforces a limit of 254. I believe this is an obsolete JES3 limit.
SYSIN may be far longer; I've encountered no practical limit.
Symbol substitution and continuation may result in a statement
shorter or longer than the source. I'm idly curious (Black Team)
what limit exists on the source.

>Are you expecting your PARM= to be limited to 100 characters, or
>would you like it to be more than that (PARMDD in the JCL REF
>z/OS 2.1).
>
PARMDD is a kludge. They ought simply to have allowed a longer PARM.
If PARMDD allows substitution of system symbols, that should have been
supported likewise in EXEC PARM.

>And, off the top of my head, TSO has a limit of 256 characters.
>But I haven't needed to deal with that problem for a decade or so.
>
By experiment, ALLOCATE PATH supports longer, but I don't know how
much longer, nor whether any limit exists in the API, at the READY
prompt, or both.

-- gil

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

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

Re: [SURVEY] What ISPF terminal model do you use

[Ted MacNEIL]

It wasn't private.

-teD
  Original Message  
From: Farley, Peter x23353
Sent: Thursday, March 10, 2016 10:36
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: [SURVEY] What ISPF terminal model do you use

David,

I'm replying privately rather than to the list so as to avoid publishing this 
data to the world.

Personally I use two different terminal models on a regular basis:

50x160 for editing and batch development (SDSF, ISPF, etc.). I don't use 60x160 
because the font is a tad small for my aging eyes.

Model-4 (43x80) for all CICS sessions because the CA CICS Intertest version 
installed here doesn't use any lines beyond 43, which can get a little weird 
when single-stepping through a program.

The rest of the shop seems to use mostly model 2 and model 4 as far as I know.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Thursday, March 10, 2016 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [SURVEY] What ISPF terminal model do you use

We're building a new product which will have several UI's; ISPF, Web, 
Eclipse etc. For the ISPF we're wondering how we should optimize the 
screen real estate for todays customer.

I use a custom 60x160 which seems to be the norm in our office. Lots of 
the tools we use, especially debuggers like z/XCD and DebugTool work 
much better with that model.
I use RDz for development but for most stuff fall back on the green 
screens like SDSF and tools that don't have a good GUI, which is 90% of 
them.

What screen size do you use?

--


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: Does everybody use chargeback?

[Ted MacNEIL]

I've worked for, and as a customer of, many sites with chargeback in place. 
Your two vectors were RARELY taken into account! Some even tried to do capacity 
management with the data.

"Oh look! The unit cost per transaction is going down! We DO NOT need an 
upgrade!"

Funny thing, aside from whether the metrics were correct, the unit cost was 
going down because we were using the dead-space at night, due to opening up 
access by the INTERNET; the day-time peak (which was driving need) was still 
increasing. Over-night access was getting a 'free ride'. But, the bean counters 
were still using the data to 'plan'.

-teD
  Original Message  
From: Timothy Sipples
Sent: Thursday, March 10, 2016 01:19
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Does everybody use chargeback?

Elardus Engelbrecht wrote:
>If you get your chargeback defined+setup properly,
>do your SMF, DCOLLECT, 3th party transaction monitor,
>etc. properly, you can't go wrong with chargeback.

I disagree, unless the "etc. properly" part is truly enormous in scope. I
notice you didn't mention anything outside the mainframe, for example. Is
everything else free? :-)

Here's another gigantic problem. Even if (big if) you could precisely
measure and allocate marginal costs at every moment, is cost the *only*
factor? No, it's only one factor...along with (vectors of) functionality
and quality.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

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

Re: Does everybody use chargeback?

[Ted MacNEIL]

Your first example is not necessarily bad behavior.
I bet it performed!


-teD
  Original Message  
From: Jesse 1 Robinson
Sent: Wednesday, March 9, 2016 00:59
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Does everybody use chargeback?

Ah, bad or perverse behaviors. Two stand out in my career.

-- A data base application was redesigned at the last minute to read the entire 
data base into memory at startup. The business unit noticed that they were 
charged for I/O but not for memory use. It was cheaper to occupy virtual 
storage than to perform reads. So much for common sense.

-- An ISAM application that could have been converted to VSAM--as discussed in 
a recent thread--was deliberately left to the sluggish vicissitudes of ISAM 
because of how the client contract was written. Data center would have 
collected less revenue with a more efficient process. Yuck. 

.
.
.
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 Timothy Sipples
Sent: Tuesday, March 08, 2016 9:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Does everybody use chargeback?

Scott Chapman wrote:
>Software billing is based on available/consumed capacity.

IBM's is/are not. It's based on *peak* four hour rolling average utilization 
per month -- or, effectively, per subscription year for products that are not 
Monthly License Charge products.

You can set whatever pricing scheme you want, I suppose. Your chargeback system 
could be based on counting keystrokes (and clicks and taps) on client devices, 
for example. That keystroke-based approach might even be more closely aligned 
with actual marginal costs of computing services than some of the chargeback 
schemes I've seen.

In my view a bad chargeback regime is worse than no chargeback regime, and it's 
quite easy to have a bad chargeback regime. "Bad" here means encouraging 
perverse behaviors and/or discouraging smart behaviors.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

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

Re: rexx and tso alllocate

[Ted MacNEIL]

Why not just create a VBA file with a very long LRECL and not worry about it at 
all? Longer  LRECLs don't introduce any more ov‎eReader than short ones.

-teD
  Original Message  
From: Kjell Holmborg
Sent: Wednesday, March 2, 2016 02:54
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: rexx and tso alllocate

One suggestion might be that your rexx program writes records to a stem 
variable and you could keep track of the longest record and then just before 
writing the contents of the stem variables to the dataset you do a TSO Allocate 
with the longest record as a variable to the ALLOCATE command.

/Kjell

--
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: CBU test

[Ted MacNEIL]

Best question! When I ran the tests we never considered anything smaller than 
the full size of our CBU agreement.

-teD
  Original Message  
From: Ambros, Thomas
Sent: Monday, February 29, 2016 15:38
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: CBU test

I think the real question is whether a temporary upgrade within a temporary 
upgrade counts as two temporary upgrades: 

2. Single CBU test is limited up to 10 days, AFAIK. Is it allowed to perform 
model conversion more than once during the period? For example activate model 
703 and if performance is not OK then further add next processors.

That raises a question, to me at least. Why would you not max out in the first 
place, given that there's no financial effect? 

Thomas Ambros
zEnterprise Operating Systems
zEnterprise Systems Management
518-436-6433

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Monday, February 29, 2016 13:06
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CBU test

No problems at all, you aren't billed for the usage. We do it ourselves during 
our annual DR test at our lukewarm site (VTape replicated, DASD not replicated).

2016-02-29 11:53 GMT-06:00 R.S. :
> W dniu 2016-02-29 o 18:43, Rob Schramm pisze:
>>
>> Sounds like a disaster recovery CBU?
>>
> Yes, it's Capacity Backup Upgrade.
>
> @Mike,
> Neither IBM software fees nor ISV are not a problem here, since I'm 
> allowed to perform such tests without any fees.
> We are talking about CBU *test*.
>
> Regards
> --
> 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



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

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


This communication may contain privileged and/or confidential information. It 
is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. This communication may contain nonpublic 
personal information about consumers subject to the restrictions of the 
Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose 
such information for any purpose other than to provide the services for which 
you are receiving the information.

127 Public Square, Cleveland, OH 44114
If you prefer not to receive future e-mail offers for products or services from 
Key 
send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in 
the 
SUBJECT line.

Re: Debugging APAR statement

[Ted MacNEIL]

I Googled IBM APAR closing codes and found a doc in the IBM Knowledge Centre.

You could have done this, too.

-teD
  Original Message  
From: Peter
Sent: Sunday, February 28, 2016 09:31
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Debugging APAR statement

Hi Lizette

Thank you for pointing me to that link i was rather specifically looking
keywords inside a APAR member. Generally like a template and each keywords
written by IBM and it's explanation.
On Feb 28, 2016 7:31 PM, "Lizette Koehler"  wrote:

> A quick internet search brought up this link. See if it helps.
> I used
> IBM ++APAR for the search keywords
>
> http://www-01.ibm.com/support/docview.wss?uid=swg21424131
>
> If you have more specific questions, please let us know.
>
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Peter
> > Sent: Sunday, February 28, 2016 5:30 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Debugging APAR statement
> >
> > Hi
> >
> > Apology in advance for asking a basic question.
> >
> > I am preparing a notes for my team members. Is there any URL or Manual
> where
> > it explains each keywords of an APAR ?
> >
> > Any pointers would be much appreciated.
> >
> > Peter
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: WLM managed initiators

[Ted MacNEIL]

Sorry resource GROUP.

-teD
  Original Message  
From: גדי בן אבי
Sent: Sunday, February 28, 2016 06:07
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: WLM managed initiators

Hi Ted,
The only reference I found to Resource Classes is RACF related. 
Could you point me to a manual?
Gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ted MacNEIL
Sent: Sunday, February 28, 2016 12:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WLM managed initiators

Per system? Per PLEX‎?
Also, what happens if there aren't enough resources to support that minimum?

Have a look at Resource Classes. It may ‎answer your needs -- it's based on 
resources rather than jobs.

-teD
  Original Message
From: גדי בן אבי
Sent: Sunday, February 28, 2016 04:37
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: WLM managed initiators

Hi,
Is there a way to force WLM or JES2 to have a minimum number of jobs running in 
a WLM managed class?

We are running z/OS v2.1

Gadi



לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה שלה 
(להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.

Please note that in accordance with Malam and/or its subsidiaries (hereinafter 
: "Malam") regulations and signatory rights, no offer, agreement, concession or 
representation is binding on the Malam, unless accompanied by a duly signed 
separate document (or a scanned version thereof), affixed with the Malam seal.

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

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

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

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

Re: WLM managed initiators

[Ted MacNEIL]

Per system? Per PLEX‎?
Also, what happens if there aren't enough resources to support that minimum?

Have a look at Resource Classes. It may ‎answer your needs -- it's based on 
resources rather than jobs.

-teD
  Original Message  
From: גדי בן אבי
Sent: Sunday, February 28, 2016 04:37
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: WLM managed initiators

Hi,
Is there a way to force WLM or JES2 to have a minimum number of jobs running in 
a WLM managed class?

We are running z/OS v2.1

Gadi



לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה שלה 
(להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.

Please note that in accordance with Malam and/or its subsidiaries (hereinafter 
: "Malam") regulations and signatory rights, no offer, agreement, concession or 
representation is binding on the Malam, unless accompanied by a duly signed 
separate document (or a scanned version thereof), affixed with the Malam seal.

--
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: Prefix save area - confused

[Ted MacNEIL]

Not confused. Just didn't remember the hardware correctly.
But, I do remember the complaints for 4K out of an entire HIPERSPACE.

-teD
  Original Message  
From: Jim Mulder
Sent: Friday, February 26, 2016 02:15
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Prefix save area - confused

> With ESA it was 'absolute' zero.
> I remember because we had users complain about the unusable portion 
> of a HIPERSPACE which was the PSA.
> 
> -teD

You are indeed confused, teD. 3090E processors did not 
have the necessary hardware to implement the 
Private-Space Control(P) bit, which overrides 
low-address protection and fetch-protection override. 
For that reason, MVS/ESA did not map addresses 0-4095 in data spaces
on 3090E processors. This had nothing to do with prefixing.
The Private-Space Control(P) bit was implemented on 3090S and 
subsequent processors, so MVS/ESA did map addresses 0-4095 in 
data spaces on those processors. 

Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY


--
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: Prefix save area - confused

[Ted MacNEIL]

With ESA it was 'absolute' zero.
I remember because we had users complain about the unusable portion of a 
HIPERSPACE which was the PSA.

-teD
  Original Message  
From: Robert Hahne
Sent: Friday, February 26, 2016 01:36
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Prefix save area - confused

In MVS/XA , with prefixing, the processors did not use absolute locations
0-4095. Rather, each

processor had its own separate PSA and its own prefix
register. When a processor

is brought on line, the real starting address of its PSA is
stored in its prefix register.

Whenever the processor uses an address between 0 and 4095,
the hardware adds

the the contents of the prefix register to the address and
uses the result. With

prefixing, the address that normally would be the absolute
address of the

information in the first page of storage becomes an offset
from the start of the real

PSA. Because each processor's prefix register contains a
different address, each

processor can address locations 0 to 4095 and reference its
own data.
In Z/architecture , it used to fix the first 2 pages unlike MVS/XA and the 
concept did not change AFAIK ...
Robert Hahne 

> Date: Thu, 25 Feb 2016 09:46:00 -0600
> From: 000a2a8c2020-dmarc-requ...@listserv.ua.edu
> Subject: Re: Prefix save area - confused
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> On Thu, 25 Feb 2016 07:39:30 +0100, Peter Hunkeler wrote:
> 
> >The 8 KiB area at absolute 0 is the place where the hardware writes 
> >status information as result of performing the "Store Status" operation.
> 
> Among other things. Those Assigned Storage Locations are defined by 
> the architecture. Other areas within the PSA are defined by the 
> operating system. 
> 
> >It has existed for longer than PR/SM. I would say, it is owned by the 
> >hardware.
> 
> >> There is Absolute addressing, real addressing, and virtual addressing.
> >
> >But wait a minute, isn't there on more level? Absolulte, real, and 
> >virtual are *within* an LPAR. It is required to support multi-CP 
> >operating system *instances*. Since PR/SM, each LPAR must have its 
> >own "absolute address 0", doesn't it?
> 
> Yes.
> 
> >Actually, the requirement has exited since physically partitionable CECs 
> >had been in place (can't remember exaxtly which were the first such 
> >machines, 3033, or 308x, or?).
> 
> Probably System/360 model 65MP. For sure model 67.
> 
> >The net would be: Some code is accessing virtual address 0. The DAT 
> >feature will (with the help of the DAT tables) translate virtual 0 to *a* 
> >real address (which just happens to always be real frame 0 in z/OS). 
> >The hardware will recognize an address within the "prefixing area" (8 KiB 
> >in z/Architcture, 4 KiB in ESA/390 and predecessors, 2 KiB in even earlier 
> >architectures?),
> 
> System/360 Principles of operation has described prefixing all the way 
> back to the -0 level of the manual. You can find it at 
> http://bitsavers.trailing-edge.com/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf
> The description is on page 18, under "Multisystem Feature". It is 
> described there as a 4K area.
> 
> Before the -4 level of the System/370 POO in 1974, the SET PREFIX 
> instruction was defined. It was not in the -0 edition.
> 
> -- 
> Tom Marchant
> 
> --
> 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: Outsourcing Stories Good or Bad!

[Ted MacNEIL]

What he said!

-teD
  Original Message  
From: Savor, Thomas (Alpharetta)
Sent: Thursday, February 25, 2016 19:39
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Outsourcing Stories Good or Bad!

Vignesh,

Until you have had your job (your way of life) ripped away from you, you cant 
get upset when folks get testy.
Management loves to tell their bosses that we are going to Outsource 
ITsaving boat loads of money, but of course they will get a huge bonus once 
its Outsourced. Then they will disappear once there is a debris field of 
problems. Who's going to get them out of the ditch.well those same folks 
that you either laid-off, forced to retire or if you are lucky, still work 
there.

We know that Outsourced folks aren't as good as local staffproblem is 
Management doesn't see it that way.
They see a Cobol programmer is a Cobol programmernot a Cobol programmer 
with 40 years experience and 20-30 years on an application verses a Cobol 
programmer right out of school. Those 40 years of experience has shown me how 
to code a program or how to fix a problem.unfortunately many times it's 
because we know what will NOT work. So, once we find a way or method of doing 
things, we stick with itit's called experience.

One of the reasons these guys and gals know s much about Z/oS Operating 
System is because they didn't start at Z/oS, many started back in the DOS/VS 
days. My opinion, Systems folks "had" to know a lot more about the Operating 
System then they do today. They didn't have all the fancy cool tools that say 
Candle or CA or BMC put out today. Many times, they had to roll up their 
sleeves and make Programming changes to the Operating System or to an 
Application in a ditch. 

>From an application side, there was no such thing as a job scheduler. 
>Scheduling jobs was a part of the Lead Operators job. Along with knowing what 
>jobs can run togetherenough memory or what disk packs were mounted. When 
>was the last time you mounted disk packs each night ?? I used to do it all the 
>timenow, no one does it.

I personally don't like Outsourcing at all. The joke is that, this can be done 
and no one will notice or there wont be "much" of a cost. How much cost is the 
Business willing to take ?? How much control are you willing to give up ?? Is 
it good business to have business in one Country, IT in another ?? Could be 
HUGE Customer Privacy or Business interests when IT is in a different Country. 
As a vendor, how do I know that my code will be safe in another Country ??

Sorry guys, off my box nowback to work.

Thanks,

Tom Savor
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sankaranarayanan, Vignesh
Sent: Thursday, February 25, 2016 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Outsourcing Stories Good or Bad!

>No one's forcing you to Ed. But I'm guessing you're helping around here 
>because you love what you do, not because you >want to help "your people" 
>alone.
>One can't learn a lot from equals, and one certainly can't learn a lot from 
>those who are (for the lack of a more sensitive >phrase) below them.
>Sure, if this community doesn't want to help, that means workload mounts for 
>IBM in the form of a trillion more service >requests lol.
>But those who are here to learn will find a way.

- Vignesh
Mainframe Infrastructure

--
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: Introducing the New z13s: Tim's Hardware Highlights

[Ted MacNEIL]

Those Christmas/Birthday cards that 'sing' when you open them contain, 
individually, more computing power than was on the face of the planet in 1950.

-teD
  Original Message  
From: zMan
Sent: Wednesday, February 24, 2016 21:00
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Introducing the New z13s: Tim's Hardware Highlights

Ed Gould wrote:
>Remember the *OLD* days there was a 16MB max on (even) an MP? Never mind
the cost of $10K per meg (if memory serves me on a 168).

Maybe at the end of the 370 era. Per http://www.jcmit.com/memoryprice.htm
it wasn't until 1979 or so that it got that cheap.

I remember $1/byte back in the 360 era. Amazing times. I've often noted
that my cellphone contains more memory than *existed on the planet* for
most of my career. Blows my ever lovin' mind!

--
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: Lower ibm-main

[Ted MacNEIL]

In general, e-mail servers are case insensitive.

-teD
  Original Message  
From: Ed Finnell
Sent: Wednesday, February 3, 2016 02:47
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Lower ibm-main

Hopefully it doesn't matter and either case will be routed to the server. 

--
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: Lower ibm-main

[Ted MacNEIL]

I said "in general"


-teD
  Original Message  
From: Paul Gilmartin
Sent: Wednesday, February 3, 2016 13:33
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Lower ibm-main

On 2016-02-03, at 05:43, Ted MacNEIL wrote:

> In general, e-mail servers are case insensitive.
> 
But originating MUAs and MTAs must not assume that. By Internet standard,
domain names are case-insensitive, however, from RFC822:

6.2.4. DOMAIN-DEPENDENT LOCAL STRING
The local-part of an addr-spec in a mailbox specification
(i.e., the host's name for the mailbox) is understood to be
whatever the receiving mail protocol server allows. For exam-
ple, some systems do not understand mailbox references of the
form "P. D. Q. Bach", but others do.

(It makes clear elsewhere that the quotation marks must appear in the
mailbox reference.) And, again, originating MUAs and MTAs must
honor the requirement. Too many fail to do so. Address book utilities
are even worse.

And I and a local website developer learned to his dismay that in the url:
mailto://mail...@somehere.com
... the slashes must be preserved in the mailbox reference (RFC 1738)
Alas, popular browsers delete them (improperly); popular MUAs
preserve them (properly). But if those popular browsers were brought
into conformance with RFC 1738 it would "break" (in a Pickwickian
sense) vast quantities of defective HTML.

I strongly disagree with half of Postel's Principle.

But, if the ua.edu server treats mailbox references as case-insensitive,
who cares how they appear in IBM-Main?

-- gil

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

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

Re: RMF monitor III panel restriction

[Ted MacNEIL]

I don't really understand 'the security reason'.
I can't think of anything that RMF shows you that would be a security exposure.

-teD
  Original Message  
From: Adnan Can
Sent: Tuesday, February 2, 2016 07:14
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: RMF monitor III panel restriction

Hi again,

For the security reason, groups other than MVS should see only the subset of 
the real time RMF reports. For example network group should only see the 
channel utilization or CPU utilization of their tasks. Other hardware and 
config info on the raports are irrelevant to them. 
Also in TEP you can customize certain screens to certain groups.
RMF DDS could be another option, but I wondered whether there was more simple 
solution on RMF III side.

Thanks and regards

--
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: [Bulk] Re: IEFSSREQ SSOBUSER Validate A JES2 Destid

[Ted MacNEIL]

I think the IKJ message is from send/receive.

-teD
  Original Message  
From: Tony Harminc
Sent: Friday, January 29, 2016 00:42
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: [Bulk] Re: IEFSSREQ SSOBUSER Validate A JES2 Destid

On 29 January 2016 at 00:02, Skip Robinson  wrote:
> I have forgotten why this behavior is deemed a problem. It's how JES(2) has 
> always worked AFAIK. You can specify DEST=HAROLD with no adverse effect. The 
> associated output will sit demurely in spool forever until HAROLD is defined 
> to some device or other existing destination. A lot of normal day-to-day 
> procedures depend on this function.

So what is message
IKJ56875I type NOT operation, DESTINATION UNDEFINED TO SUBSYSTEM
for? I can remember getting it; remembering part of the text is how I
managed to Google for it. And that same search found 2012 APAR PM55876
against some product I've never heard of, but it includes:

Under certain circumstances, Bundle print program BJTBBDYS fails to print.
Symptoms include:
IKJ56875I SYSOUT DATA SET NOT ALLOCATED, DESTINATION UNDEFINED
TO SUBSYSTEM

Tony H.

--
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: z13 BC????

[Ted MacNEIL]

404 not found

-teD
  Original Message  
From: Ed Finnell
Sent: Tuesday, January 26, 2016 16:25
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: z13 BC

They've been doing announcements around SHARE so might be a good place to 
find out more faster.

WSC's Harv Emery's Seattle Presentation on z13/zBX rollout super 
informative.

https://share.confex.com/share/124/webprogram/Handout/Session16704




In a message dated 1/26/2016 10:45:13 A.M. Central Standard Time, 
allan.stal...@wunderman.com writes:

Rumored to be announced this spring!


--
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: the Queen of Coding - Adm. Grace Hoper

[Ted MacNEIL]

I always thought it was a relay.

-teD
  Original Message  
From: Ed Finnell
Sent: Monday, January 25, 2016 01:17
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: the Queen of Coding - Adm. Grace Hoper

Chicken fried moth between the vacuum tubes.


In a message dated 1/24/2016 11:43:56 P.M. Central Standard Time, 
charl...@mcn.org writes:

Nope.


--
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: SMFxTME field

[Ted MacNEIL]

That that is is that that is not is not is that it it is

-
-teD
-
  Original Message  
From: Ed Finnell
Sent: Friday, January 8, 2016 03:33
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: SMFxTME field

That that is is that that is not is not? 


In a message dated 1/7/2016 7:02:55 P.M. Central Standard Time, 
charl...@mcn.org writes:

"that"?


--
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: Change CPC name in HMC

[Ted MacNEIL]

We 'had' to do this, once.
IBM originally recommended that LPAR names be independent of the 'name' of the 
image name running within it.

Then, with GDPS, they recommended the reverse. The implementation went without 
a hitch.
All our reporting/billing? Not so well.

-
-teD
-
  Original Message  
From: Skip Robinson
Sent: Thursday, January 7, 2016 10:59
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Change CPC name in HMC

First off, you can name a CPC anything you want within the syntax rules. 
Ideally you should pick a good name at initial install, but it can be changed 
later. That being said, after we installed z12s in a new data center in 2013, 
we intended to rename the z196 remaining in the old data center. We never got 
that done because we had never actually renamed a box before and were wary of 
what it would take to accomplish without disruption. Nothing crucial depended 
on a rename, so we shined it on. The name is embodied in two places:

-- The IODF names all processors.
-- The HMC/SE names each processor in several places from POR (Reset) profile 
onward. 

IODF and HMC must agree. For a new box, this is not so hard. The trick is make 
a change without hosing up the environment. Also consider other implications:

-- BCPii must also be updated. I consider that part of the HMC/SE tasks above, 
but don't overlook it.
-- POR will be required.
-- SMF records contain the CPC name. Any post processing must take a change 
into account.
-- It's not uncommon for various automation processes to refer to CPC by name. 
Again, allow for this. 
-- Many folks in the IT community may be attached to the old name in various 
ways. Any change must 'socialized' thoroughly. 

I suggest you pick a name that you won't regret later. Consider the effects of 
future model upgrades, workload repurposing, and physical relocation. However, 
if an upgrade involves a transition period where both old and new boxes must 
coexist, you need two separate names at least for a while. I can see the appeal 
of serial number to avoid these conundrums, buy as you note the number is 
meaningless to all but a handful of infrastructure geeks. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net
jo.skip.robin...@gmail.com


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Elardus Engelbrecht
> Sent: Thursday, January 7, 2016 04:56 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Change CPC name in HMC
> 
> Tony Thigpen wrote:
> 
> >I have done such a change on two z10s with good results. The third time did
> not go so well. For some reason, the secondary cpc did not change. Everything
> looked ok until we did a POR, then it would not come up. We had to restore the
> CPC.
> 
> Ouch. Where is that behaviour documented?
> 
> Do you get a warning during the renaming that an upcoming POR may fail?
> 
> >I don't know what went wrong, but after that, we no longer change the
> names.
> 
> Now you got a new scar and a T-shirt as a bonus ... :)
> 
> I would also not repeat that stunt after one failure.
> 
> Groete / Greetings
> Elardus Engelbrecht

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

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

Re: BPXBATCH "SH ...; su; pax ..." does not do what you think it does

[Ted MacNEIL]

If you understand how UNIX works, this is quite sensible. See how the ISPF 
interface to USS works.

-
-teD
-
  Original Message  
From: Alan Young
Sent: Tuesday, December 29, 2015 12:13
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: BPXBATCH "SH ...; su; pax ..." does not do what you think it does

Peter Hunkeler wrote:
> 
> 
> To run commands in a "su" shell environment, you have to write all the 
> commands into a UNIX file first, and then call "su" by redirecting stdin to 
> that UNIX file.
>
>
> echo "id" > /tmp/sucommandfile
> su < /tmp/sucommandfile
>
> 

The manual has examples of executing commands via su without redirection 
like this:

To run the /usr/lib/backupall script under the admin user ID and return 
to the parent shell environment when the script completes:

|su admin /usr/lib/backupall|

To run a remove shell command under the admin user ID and return to the 
parent shell environment when the command completes:

|su admin -c "rm -rf /tmp/"


|

Alan

--
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: slight reprieve on the z.

[Ted MacNEIL]

Obviously misinformed!

-
-teD
-
  Original Message  
From: Mike Schwab
Sent: Friday, December 18, 2015 05:21
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: slight reprieve on the z.

They are running the LAST IMS MAINFRAME in North America in 2003?

Why does IBM keep churning out new versions of IMS?

On Thu, Dec 17, 2015 at 6:06 PM, Gary Jacek  wrote:
> Hi Bob
>
> I just have to share this classic from 2003.
>
> https://www.youtube.com/watch?v=tKgl6e31R50
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Bob Shannon
> Sent: December 17, 2015 09:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: slight reprieve on the z.
>
>> it has now been decided that the z will be kept (greatly reduced in
>> MSU & usage) until 4Q2016
>
> Circa 1999 I exchanged emails with someone on this list who was in the 12th 
> year of a five year migration off the mainframe. Y2K extended the migration 
> even farther. Hopefully you will have similar misfortune ;-)
>
> Bob Shannon
> Rocket Software
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

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

Re: TAR Files:" Extracting" on a IBM Mainframe

[Ted MacNEIL]

It was converted from PASCAL for OS/390 1.7 (1990's). So, any doc would be of 
that vintage


-
-teD
-
  Original Message  
From: Elardus Engelbrecht
Sent: Friday, December 18, 2015 06:21
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: TAR Files:" Extracting" on a IBM Mainframe

Tony Harminc wrote:

> Shmuel Metz (Seymour J.) wrote:
>> No TCP/IP? Or is the old Pascal version still supported?

>No.

Hmmm, I know Pascal was used first [1] as source for TCP/IP and some modules 
were later rewritten in other languages.

Where is it documented that Pascal is not used as source for those [ IBM - z/OS 
] TCP/IP modules?

Groete / Greetings
Elardus Engelbrecht

[1] - based on what I remember (hey, my last remaining brain cells don't like 
exercises... ;-D) on IBM-MAIN when Pascal and TCP/IP was discussed in the past.

--
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: HCD Switch Report

[Ted MacNEIL]

If you're interfacing with ISPF programmes then ISPEXEC SELECT works, as well. 
I've done it for years. Of course, you have to have a valid ISPF environment 
set up.

-
-teD
-
  Original Message  
From: Ravi Gaur
Sent: Wednesday, December 9, 2015 05:12
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: HCD Switch Report

The only way given in manual is to load this program "CBDMGHCP" via rexx is 
ATTACH or LINK and tried both however doesn't seems to work.ISPEXEC SELECT 
PGM doesn't work ...

--
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: HCD Switch Report

[Ted MacNEIL]

Did you try using ISPF Services to load it?

I believe:

address ISPEXEC "SELECT PGM()"

Or it might be CMD

-
-teD
-
  Original Message  
From: Lizette Koehler
Sent: Tuesday, December 8, 2015 22:14
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: HCD Switch Report

Doe the HCD ISPF Application provide that type of function?
Or are you doing some this app does not do?

Also, if you are not aware, there is a TSO-REXX list that also might be helpful.

To join, if you have not done so, go to the bottom of the webpage at this url
TSO REXX http://www2.marist.edu/htbin/wlvindex?TSO-REXX

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ravi Gaur
> Sent: Tuesday, December 08, 2015 6:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: HCD Switch Report
> 
> Has anybody been able to use CBDMGHCP program in REXX and successfully
> generate HCD Report like SWITCH report...I have been trying to use it via 
> LINKMVS
> and ATTACHMVS however it gives me RC(-2) ...
> 
> If somebody got some idea someway to generate the report via rexx let me know
> ...What I am trying to do is generate report via rexx then parse it and load 
> in to ISPF
> Table to do query via panels...
> 

--
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: IBM z Systems Development Blog

[Ted MacNEIL]

Oops! Sorry!

-
-teD
-
  Original Message  
From: Vernooij, CP (ITOPT1) - KLM
Sent: Monday, December 7, 2015 03:32
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: IBM z Systems Development Blog

Early Monday? Have a coffee first.
Note the chars after the '365'.
Check John's original 24x7x365.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ted MacNEIL
Sent: 07 December, 2015 9:09
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM z Systems Development Blog

24x7x52 is already a year (less a few days).
Multiplying by 365 makes it 365 yrars.

-
-teD
-
  Original Message  
From: Vernooij, CP (ITOPT1) - KLM
Sent: Monday, December 7, 2015 02:35
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: IBM z Systems Development Blog

You forgot the 52 for the 100%: 24x7x52x365 ;-)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: 04 December, 2015 16:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM z Systems Development Blog

On Fri, Dec 4, 2015 at 9:42 AM, Mike Schwab <mike.a.sch...@gmail.com> wrote:

> On Fri, Dec 4, 2015 at 7:34 AM, John McKown
> <john.archie.mck...@gmail.com> wrote:
> 
> > too true. I may even start playing the state lottery, even though that's
> > not really a good idea. I understand enough statistics to know that.
> >
> Don't play in Illinois. They only give you and IOU.
>

​I live in Texas. But, really, I have no intention of trying the lottery.
It was just a weird & stupid idea. Sort of like converting from z/OS to
Windows and expecting 24x7x365 reliability.​


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

-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

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

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




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

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

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

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

Re: IBM z Systems Development Blog

[Ted MacNEIL]

‎In Texas Hold'em is what I was talking about.

-
-teD
-
  Original Message  
From: Randy Hudson
Sent: Sunday, December 6, 2015 23:03
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: IBM z Systems Development Blog

In article <20151204220655.5476437.57761.60...@yahoo.ca> teD wrote:

> Easier to get a Royal Flush.
> 265,000:1

A dealt royal flush, AKQJT all of the same suit, in any order, is closer to
650,000-1. A drawn royal flush, the jackpot hand on most "video poker" slot
machines, is typically between 32,000-1 and 50,000-1, depending on the
strategy the player is using (which itself should depend on what the payoff
is on other hands than a royal flush.)

--
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: IBM z Systems Development Blog

[Ted MacNEIL]

24x7x52 is already a year (less a few days).
Multiplying by 365 makes it 365 yrars.

-
-teD
-
  Original Message  
From: Vernooij, CP (ITOPT1) - KLM
Sent: Monday, December 7, 2015 02:35
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: IBM z Systems Development Blog

You forgot the 52 for the 100%: 24x7x52x365 ;-)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: 04 December, 2015 16:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM z Systems Development Blog

On Fri, Dec 4, 2015 at 9:42 AM, Mike Schwab  wrote:

> On Fri, Dec 4, 2015 at 7:34 AM, John McKown
>  wrote:
> 
> > too true. I may even start playing the state lottery, even though that's
> > not really a good idea. I understand enough statistics to know that.
> >
> Don't play in Illinois. They only give you and IOU.
>

​I live in Texas. But, really, I have no intention of trying the lottery.
It was just a weird & stupid idea. Sort of like converting from z/OS to
Windows and expecting 24x7x365 reliability.​


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

-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

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

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




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

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

Re: OT: How much does software weigh? (was:What's a "ton" of JCL?)

[Ted MacNEIL]

I know that story.
Since it's Friday, here's another:

A reporter asked Alan Sheppard what he was thinking about as he blasted off.

Response:
Every part in here was built by the lowest bidder.

Scary!

-
-teD
-
  Original Message  
From: Vernooij, CP (ITOPT1) - KLM
Sent: Friday, December 4, 2015 03:01
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: OT: How much does software weigh? (was:What's a "ton" of JCL?)

That's what NASA asked their programmers when designing the Apollo's. 
They answered: 'Nothing.'. 
'Really, we can hardly believe this.'. 
'It is true, we only use the holes in the punchcards.'

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ted MacNEIL
Sent: 04 December, 2015 6:33
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OT: What's a "ton" of JCL?

Is that counting the weight of the boxes themselves?

-
-teD
-
  Original Message  
From: Thomas Kern
Sent: Friday, December 4, 2015 00:14
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: OT: What's a "ton" of JCL?

Approximately 274905 cards.

2000 cards per box is about 14.55 lbs.
137.45 boxes per ton(2000lbs)

It is Friday now.

/Tom Kern

On 12/03/2015 22:40, Joel C. Ewing wrote:
> On 12/03/2015 12:16 PM, Paul Gilmartin wrote:
>> On Thu, 3 Dec 2015 10:43:38 -0600, Joel C. Ewing wrote:
>>> ... Because DOS/VS had native support for source and object
>>> libraries, those were kept online, but there was no decent native
>>> support to effectively submit production job JCL from libraries ...
>>>
>> Astonishing. You could RYO editor but not RYO "SUBMIT".
> OLE' was envisioned and implemented by one person, James Stevens, the
> head of Tech Services at a time when it was a one or two man operation
> (I raised the body count to 3) -- he probably created OLE' as late night
> entertainment for his own convenience and benefit to make development of
> his Mini-Task on-line environment and other utilities less tedious. It
> went company-wide since it significantly improved the efficiency of 40+
> programmers versus fiddling with individual cards in a deck. JCL didn't
> get changed as much and Operator's time was considered less valuable;
> and since they only picked up the entire job deck and moved it around
> as a unit it wasn't that obvious that a significant amount of time would
> be saved by avoiding the use of decks for production JCL.
>
> OLE' did have the ability to submit jobs to DOS, but the interactive
> OLE' work areas assigned to individual users were each a pre-defined
> number of "pages" of 24 80-byte records and the total size of all areas
> was constrained by the capacity of a 3330. With those space constraints,
> the normal practice was to keep in one's OLE' area(s) only data actively
> being edited along with some shorter job streams used for testing and
> development. It would have been possible to submit a short batch job
> from OLE' to extract a production job stream from a source library and
> load it into part of the an OLE' area (as was done for source code
> editing), wait for that job to run, and then submit the production job
> from OLE'; but by the time an Operator had done that they could have
> already loaded a physical deck. There just didn't seem to be enough
> cost-benefit to justify converting JCL from cards to DASD until MVS
> changed the equation.
>>> ... and the
>>> company was averse to spending on "unneeded" additional software, so
>>> production JCL was created in OLE' but punched and kept on cards for use
>>> by Operations.
>>>
>> The supplies must have been cheap.
> My impression was that the volume of new cards was low enough to be a
> trivial cost compared to the cost of printer paper, and I never saw a
> card filing cabinet wear out. Maintenance on the card reader/punch
> became more of a nuisance and issue after the units aged at least a
> decade, but the cost of that was a minor part of the hardware
> maintenance contract.
>>> When we started DOS/VSE to MVS/XA migration in 1985, we were already
>>> running the maximum of four, shared-SPOOL DOS/VSE systems under VM ...
>>>
>> Was that limit imposed by VM or by the DOS/VSE shared spool? I'd
>> suspect the latter.
>>
>> -- gil
>>
> Definitely was not a VM limitation. DOS/VSE had a shared "lock" file to
> coordinate library and other inter-system sharing and that file could be
> shared by a maximum of four systems (and with four systems one did at
> times see performance problems with that drive). I can't remember at
> this point whether the SPOOLER ("POWER"), was 

Re: IBM z Systems Development Blog

[Ted MacNEIL]

Easier to get a Royal Flush.
265,000:1

-
-teD
-
  Original Message  
From: Vince Coen
Sent: Friday, December 4, 2015 16:17
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: IBM z Systems Development Blog

The BBC (British Broadcasting Corporation - UK) does *NOT* run any lottery.

There are more than one (and a bit) different lotteries licensed in the
UK and no I do not subscribe to any.

The odds as you point out are horrendous.

Originally it was bad enough with 6 numbers at odds of 14.5M : 1



On 04/12/15 14:18, Shane Ginnane wrote:
> On Fri, 4 Dec 2015 07:34:25 -0600, John McKown wrote:
>
>> ​too true. I may even start playing the state lottery, even though that's
>> not really a good idea. I understand enough statistics to know that. ​
> Don't do that.
> I was listening to the BBC overnight a few weeks back, and they must have 
> been amending their lottery to have more numbers so the ultimate prize was 
> bigger.
> They had a maths/stats prof on - he said for the current lottery, if you 
> stood in line for six and a half minute waiting for a ticket you had more 
> chance of dying in that 6.5 minutes than winning the money.
> They added more numbers, so the time delta went down accordingly.
>
> Sobering  ;0)
>
> Shane ...
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>


-- 
- IMPORTANT –

This email and the information in it may be confidential, legally
privileged and/or protected by law.
It is intended solely for the use of the person to whom it is addressed.
If you are not the intended recipient, please notify the sender
immediately and do not disclose the contents to any other person, use it
for any purpose, or store or copy the information in any medium. Please
also delete all copies of this email & any attachments from your system.

If this is an encrypted email it is your responsibility to maintain the
1024 byte key system even for one-use keys. Once mail has been sent the
sending key is not kept and therefore a replacement mail cannot be resent.

We cannot guarantee the security or confidentiality of non encrypted email
communications. We do not accept any liability for losses or damages that
you may suffer as a result of your receipt of this email including but
not limited to computer service or system failure, access delays or
interruption, data non-delivery or mis-delivery, computer viruses or
other harmful components.

Copyright in this email and any attachments belongs to Applewood Computers.
Should you communicate with anyone at Applewood Computers by email,
you consent to us monitoring and reading any such correspondence.

Nothing in this email shall be taken or read as suggesting, proposing or
relating to any agreement concerted practice or other practice that could
infringe UK or EC competition legislation (unless it is against Security
requirements).

This Email and its attachments (if any) are scanned for virii using
Clamd and ClamAV 0.98.8 or later (Linux x64).

Dykegrove Limited T/A Applewood Computers is a company registered in
England (no. 01681349) whose registered office is at Applewood House,
Epping Road, Roydon, Essex, CM19 5DA

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

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

Re: OT: What's a "ton" of JCL?

[Ted MacNEIL]

Is that counting the weight of the boxes themselves?

-
-teD
-
  Original Message  
From: Thomas Kern
Sent: Friday, December 4, 2015 00:14
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: OT: What's a "ton" of JCL?

Approximately 274905 cards.

2000 cards per box is about 14.55 lbs.
137.45 boxes per ton(2000lbs)

It is Friday now.

/Tom Kern

On 12/03/2015 22:40, Joel C. Ewing wrote:
> On 12/03/2015 12:16 PM, Paul Gilmartin wrote:
>> On Thu, 3 Dec 2015 10:43:38 -0600, Joel C. Ewing wrote:
>>> ... Because DOS/VS had native support for source and object
>>> libraries, those were kept online, but there was no decent native
>>> support to effectively submit production job JCL from libraries ...
>>>
>> Astonishing. You could RYO editor but not RYO "SUBMIT".
> OLE' was envisioned and implemented by one person, James Stevens, the
> head of Tech Services at a time when it was a one or two man operation
> (I raised the body count to 3) -- he probably created OLE' as late night
> entertainment for his own convenience and benefit to make development of
> his Mini-Task on-line environment and other utilities less tedious. It
> went company-wide since it significantly improved the efficiency of 40+
> programmers versus fiddling with individual cards in a deck. JCL didn't
> get changed as much and Operator's time was considered less valuable;
> and since they only picked up the entire job deck and moved it around
> as a unit it wasn't that obvious that a significant amount of time would
> be saved by avoiding the use of decks for production JCL.
>
> OLE' did have the ability to submit jobs to DOS, but the interactive
> OLE' work areas assigned to individual users were each a pre-defined
> number of "pages" of 24 80-byte records and the total size of all areas
> was constrained by the capacity of a 3330. With those space constraints,
> the normal practice was to keep in one's OLE' area(s) only data actively
> being edited along with some shorter job streams used for testing and
> development. It would have been possible to submit a short batch job
> from OLE' to extract a production job stream from a source library and
> load it into part of the an OLE' area (as was done for source code
> editing), wait for that job to run, and then submit the production job
> from OLE'; but by the time an Operator had done that they could have
> already loaded a physical deck. There just didn't seem to be enough
> cost-benefit to justify converting JCL from cards to DASD until MVS
> changed the equation.
>>> ... and the
>>> company was averse to spending on "unneeded" additional software, so
>>> production JCL was created in OLE' but punched and kept on cards for use
>>> by Operations.
>>>
>> The supplies must have been cheap.
> My impression was that the volume of new cards was low enough to be a
> trivial cost compared to the cost of printer paper, and I never saw a
> card filing cabinet wear out. Maintenance on the card reader/punch
> became more of a nuisance and issue after the units aged at least a
> decade, but the cost of that was a minor part of the hardware
> maintenance contract.
>>> When we started DOS/VSE to MVS/XA migration in 1985, we were already
>>> running the maximum of four, shared-SPOOL DOS/VSE systems under VM ...
>>>
>> Was that limit imposed by VM or by the DOS/VSE shared spool? I'd
>> suspect the latter.
>>
>> -- gil
>>
> Definitely was not a VM limitation. DOS/VSE had a shared "lock" file to
> coordinate library and other inter-system sharing and that file could be
> shared by a maximum of four systems (and with four systems one did at
> times see performance problems with that drive). I can't remember at
> this point whether the SPOOLER ("POWER"), was limited to four systems
> for shared spool because it depended on the "lock" file or whether it
> had its own internal design limits as well.
>

--
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: WLM and Dispatching Priority

[Ted MacNEIL]

Put monitors in SYSSTC.
This gives them the second highest DP in the system. You cannot completely 
control the DP in Service Classes.

-
-teD
-
  Original Message  
From: phil yogendran
Sent: Thursday, November 26, 2015 11:02
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: WLM and Dispatching Priority

Hello All,

I need some assistance with being able to get a proper DP assigned to a set
of tasks. The problem is this;

I have 2 tasks, SYSVIEW and CICSLOGR and many CICS tasks. CICSLOGR is a
subtask attached by SYSVIEW.

In WLM, SYSVIEW is set to a service class of 'monitor' with an importance
of 1 and velocity of 75.

The CICS regions are set to a service class of 'CICSA' which has an
importance of 1 and velocity goal of 65.

However, what I see is that the CICS regions run at a DP of F6 and SYSVIEW
is at F4.

How can I make sure that SYSVIEW and CICSLOGR run at a higher DP? I'm on
z/OS 1.13 and in a sysplex environment.

Looking forward to your response. Thanks.

--
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: CC usage in Germany (Europe) [WAS: Were you at SHARE in Seattle? Watch your credit card statements!]

[Ted MacNEIL]

Our cards are still embossed here in Canada.

-
-teD
-
  Original Message  
From: Smith III, Phil (HP Data Security (Voltage))
Sent: Monday, November 23, 2015 17:52
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: CC usage in Germany (Europe) [WAS: Were you at SHARE in Seattle? 
Watch your credit card statements!]

R.S. wrote:
>I don't understand. Is it a problem with your card/bank or rather small shops 
>in the Forest do not have card terminal?
I suspect this is limitation of your card. I saw such cards.

>BTW: US is last country where my card were imprinted (embossed), it is 
>probably also last place on Earth where signature is needed instead of PIN.
> (obviously my experience is limited, I haven't visited all the countries on 
> Earth)

I believe the point here was that if you do NOT have a Chip card, you may 
find yourself in a situation where you cannot perform a needed transaction 
because the terminals don’t have magstripe readers. This is well-documented: 
unattended gas pumps, ticket kiosks, etc. Less common in cities, more common 
outside them.

--
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: Interesting Article About Cobol

[Ted MacNEIL]

My understanding is that ABO is not required for modern COBOL compilers. Only 
for the 'old' binarys.

-
-teD
-
  Original Message  
From: Lizette Koehler
Sent: Monday, November 23, 2015 09:47
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Interesting Article About Cobol

So just looking at the PDF diagram, it looks like you have to run your load 
module thru the ABO and create a new load module with the same names. So it 
will "do stuff" to your current V3 or V4 COBOL Module to make it better. So the 
new old module is a hybrid of the old with ABO adjustments.

And then any time you would recompile your program, you would need to run it 
through ABO again. 

Seems like some extra steps.

Maybe there are those on this list that might be using ABO and can provide some 
insight.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of George Rodriguez
> Sent: Monday, November 23, 2015 5:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Interesting Article About Cobol
> 
> FYI...
> 
> Mainframe Cobol
>  cobol-programs--70505?rss=1>
> 
> *George Rodriguez*
> *Specialist II - IT Solutions*
> *IT Enterprise Applications*
> *PX - 47652*
> *(561) 357-7652 (office)*
> *(954) 415-7586 (mobile)*
> *School District of Palm Beach County*
> *3348 Forest Hill Blvd.*
> *Room B-251*
> *West Palm Beach, FL. 33406-5869*
> *Florida's Only A-Rated Urban District For Eight Consecutive Years*

--
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: Deleting all members of a pds

[Ted MacNEIL]

Or, more recent versions of IDCAMS.

-
-teD
-
  Original Message  
From: J O Skip Robinson
Sent: Thursday, November 19, 2015 19:07
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: (External):Re: Deleting all members of a pds

Can also be accomplished with PDS[85] command or StarTool product. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, November 19, 2015 3:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Deleting all members of a pds

I have installed the CBTTAPE.ORG utility PDSCLEAN for both PDS and PDSE 
datasets an it works very well. File 693.

Lizette



-Original Message-
>From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
>Sent: Nov 19, 2015 3:51 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Deleting all members of a pds
>
>On 2015-11-19 14:54, Ed Finnell wrote:
>> File 182 on CBT tape contains PDS command. It's a great tool. Can 
>> delete or delete by mask add space, copy, merge and fix. The 
>> commercial version is Startools from Serena. Has saved my bacon numerous 
>> times.
>> 
> STOW DCB,,I
>
>I believe (or hope) PDS uses that nowadays, since its older technique, 
>basically zapping the directory, didn't work for PDSE.
>
>> In a message dated 11/19/2015 3:43:17 P.M. Central Standard Time, 
>> johnmattson...@gmail.com writes:
>> 
>> Someone was asking about deleting all members of a pds. I just 
>> noticed that DFSort has a bunch of "samples" one of which includes 
>> how to use ICETOOL to delete all members of a PDS. Hope this helps. 
>> Lots of other neat things in here too.
>
>I hope it (and IDCAMS) uses STOW. Deleting members one-by-one can be expensive.
>But if so, first sort in reverse order.
>
>I'm not going to measure timings
>
>-- gil


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

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

Re: SMF/RMF Reporting question

[Ted MacNEIL]

ERBRMFPP

Comes free.

See the RMF USER'S GUIDE



















-
-teD
-
  Original Message  
From: Lizette Koehler
Sent: Friday, November 20, 2015 08:50
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: SMF/RMF Reporting question

Do you have any tools like SAS/MICS or SAS/MXG?
Any monitoring tools like Tivoli Omegamon, MainView?

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Hardee, Chuck
> Sent: Friday, November 20, 2015 5:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMF/RMF Reporting question
> 
> Hello Everyone,
> 
> I am trying to find, from a historical perspective, that is to say, after an
event has
> occurred, what units of work were using how much of the available CPU.
> Is there an SMF and/or RMF report that allows on to ask,
> 
> "During the interval from hh:mm to hh:mm on a particular day, in increments of
y
> units, what was the consumption of CPU on a unit of work basis?"
> 
> Another way to put it is, I am looking for a report that shows CPU consumption
in a
> context similar to the SDSF DA screen as one sits at their terminal and
presses the
> enter key.
> 
> We are trying to find out who, during a specific interval of the day, was
consuming
> the greatest amount of CPU to the ultimate effect that it essentially stopped
one of
> our database regions from executing and thereby causing it to think some of
its
> subtasks had gone into a runaway CPU condition so it aborted them as a
preemptive
> action against bad coding. We know that the code is good, it's been literally
running
> for years with no changes and, until the last couple of weeks, has had not a
single
> hiccup. Over the last couple of weeks, for no reason we can identify as of
yet, the
> code has randomly been aborted by the database software in which it runs, as a
> runaway task.
> 
> The theory is that the runaway check process is actually reporting a false
condition
> since it is based on wall clock time (this is vendor code, not ours and I'm
not going to
> debate it one way or another). What the vendor theorizes is that another task
in the
> system, yet to be identified, has stolen the CPU away from the database and
held on
> to it long enough such that when the database finally regained access to the
CPU,
> the runaway interval had been exceeded by the internal task executing our code
so it
> was aborted for a potential loop within the code.
> 
> The database vendor has suggested looking for this kind of information in
order to
> confirm or deny that the database had the CPU it needed or if another task
within
> the LPAR had control. If we find that the database had the CPU, then the
vendor has
> more analysis work to do on the dump with a more powerful magnifying glass, or
we
> have to turn our sights on someone else, either ourselves or, possibly,
another
> vendor for another product.
> 
> Thanks for any thoughts you may have on this.
> Chuck
> 
> 
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration EAS Information Technology
> 
> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile +1
(412)
> 877-2809 | FAX: +1 (412) 490-9230
> chuck.har...@thermofisher.com |
> www.thermofisher.com
> 
> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this
> e-mail or the information herein by anyone other than the intended recipient,
or an
> employee or agent of a system responsible for delivering the message to the
> intended recipient, is prohibited. If you are not the intended recipient,
please inform
> the sender and delete all copies.
> 
> 
> --
> 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: Fastest way to read OLDEST GDG entry

[Ted MacNEIL]

Versioning


-
-teD
-
  Original Message  
From: Peter Hunkeler
Sent: Tuesday, November 17, 2015 16:42
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: AW: Re: Fastest way to read OLDEST GDG entry

> What makes "V00" ever Vnn, where N<>0? 


IIRC, the system does not really care for the version number. When a new GDS is 
allocated using relative numbering, the version is always V00. If you want to 
replace a GDS with a specific generation number while keeping the place in the 
GDG, you cataloge the new data set using the fully qualified DSN but replace 
the V00 with whatever version you like. The new data set will become a GDS in 
place and at the place of the V00 GDS. This new GDS will be treated as any 
other GDS, i.e. aged and eventually rolled off.


I don't see practical use for this.


--
Peter Hunkeler 

--
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: Releasing Orphan Storage without IPL

[Ted MacNEIL]

You can do it (carefully) with OMEGAMON, but it's error-prone and tricky (as 
previously stated). It's documented in a separate manual that the vendor 
advises be kept under lock and key, which I agree with.

We let people free up CCA on the development box, since the alternative was an 
IPL.

This barely lasted a week; somebody logged on the Production OMEGAMON and freed 
CSA for Production Online, with disastrous results!

I'm glad it wasn't me!

-
-teD
-
  Original Message  
From: Vernooij, CP (ITOPT1) - KLM
Sent: Friday, October 30, 2015 04:32
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Releasing Orphan Storage without IPL

It is very difficult and tricky to determine which orphaned storage is left 
orphaned unintentionally and can be releases.

Remember that CSA and ECSA can overflow to SQA and ESQA, so you have more air 
in you (E)CSA than the 2% and 3% and this might help you survive until the next 
scheduled IPL.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jake Anderson
Sent: Friday, October 30, 2015 9:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Releasing Orphan Storage without IPL

Hello,

One of our Test LPAR was victim of S878 abends caused by a DB2 system. Now
the DB2 system is down but still the ECSA and CSA are at 97% and 98%. Is it
possible to release the Unused Storage without IPLing ?

Regards,
Jake

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

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

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




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

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

Re: RE-IPL for the Daylight to Standard time conversion?

[Ted MacNEIL]

What's so special about Sunday? I used to work for an international bank. 
Sunday. Was no excuse for an outage!

-
-teD
-
  Original Message  
From: Vince Coen
Sent: Tuesday, October 27, 2015 07:11
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: RE-IPL for the Daylight to Standard time conversion?

I would have thought that all these issues would have been easy to be 
resolved if all sites used UTC time on hardware level with
the adjustment for local set up at the software level then it only 
requires simple job step to adjust if there is not one built in to the O/S.

Also and if needed that no job/processes was allowed to run over the 
time period of time change where such a process might get upset.

Let face it as clock change occurs for most of us on a Sunday this 
should not really be a major problem.

I am somewhat surprised that IBM does not have standard procedures / 
processes / Job in place to handle this including checking the hardware 
clock against an external source the same that Unix, Linux, Windows does 
even if it has to go through a inhouse Intranet server for security.




On 27/10/15 06:14, Paul Gilmartin wrote:
> On Mon, 26 Oct 2015 23:02:41 -0500, Joel C. Ewing wrote:
>> Since UNIX and Windows platforms handle DST by just forcing the local
>> time discontinuity, if an application has a problem with that, you don't
>> have a choice other than tolerating the result or trying to find and fix
>> any intolerable problems the discontinuity causes for the application.
>> I'm sure there are cases on those platforms where a rare "strangeness"
>> at time zone changes is just tolerated, since users in those environment
>> traditionally seem to expect a higher level of s--- happens and some
>> occasional apparent non-determinism..
>>
> I'm trying to imagine my UNIX-oriented colleagues' snickering at the
> idea of shutting down a system at the DST transition. When they
> stopped giggling, I'd expect them to ask, "But which time zone; which
> country? All? Northern or Southern Hemisphere? Both?" UNIX
> systems run their system clocks on UTC and an input to localtime()
> is a time zone chosen by the programmer. It would be absurd to
> expect an hour's outage for each of several dozen time zones in
> the world. z/OS has a peculiar tunnel vision in its belief that there
> are only two time zones.
>
> Leap seconds are a different issue. z/OS shuts down all applications
> during a leap second. Google and Amazon both steer their clocks
> slow (less than 0.01 percent) for several hours centered on a leap
> second. And the two have chosen different steering durations.
>

--
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: RE-IPL for the Daylight to Standard time conversion?

[Ted MacNEIL]

I've been wondering how long it would take for time-change questions to start. 
It's a little later this year.

-
-teD
-
  Original Message  
From: Charles Mills
Sent: Monday, October 26, 2015 17:29
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: RE-IPL for the Daylight to Standard time conversion?

I'm a developer, not an operations guy. My boss has asked me why a
datacenter we use would need to IPL for the daylight to standard time
transition. He asks if the box does not use UTC, and I said that yes, the
hardware clock is generally set to UTC but that perhaps the LPAR time zone
change required an IPL.

Can anyone enlighten me? Why might our datacenter need or want to IPL for
the Daylight to Standard time conversion?

Thanks,

Charles 

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

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

Re: IEAVAPE2/IEAVPSE2 another address space

[Ted MacNEIL]

So, why michelbutz?


-
-teD
-
  Original Message  
From: michelbutz
Sent: Saturday, October 17, 2015 19:44
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: IEAVAPE2/IEAVPSE2 another address space

Thank you 

My real name is Joseph Reichman
And I have licensed copy of RD

Sent from my iPhone

On Oct 17, 2015, at 10:17 AM, Peter Relson  wrote:

>> Waiting for the likes of Pete Relson to chime in
> 
> I tend not to chime in when a poster does not have the courtesy to the 
> list subscribers of using their real name.
> 
> Pause pauses *you*, as the reference clearly says.
> 
> Regardless, that table row appears to be related to "waking up", so the 
> words "pause and" should be removed.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
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: IBM Mobile Systems Remote

[Ted MacNEIL]

Is it?
We had people supporting that from home because the company was trying to get 
more to work that way because it was cheaper than the cost of having them in 
the office.

-
-teD
-
  Original Message  
From: Clark Morris
Sent: Friday, October 16, 2015 11:59
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: IBM Mobile Systems Remote

On 16 Oct 2015 08:22:03 -0700, in bit.listserv.ibm-main you wrote:

>Is anyone using it?
>
>It is (in my understanding) some kind of remote access to HMC from 
>mobile device.
>I have no idea what is functionality of the application and it connect 
>to the HMC.
>Associated webpage ibmremote.com does not work.

I hope that IBM isn't allowing that. Remote access to a HMC seems to
be a security hole large enough to drive a truck through.

Clark Morris
>
>-- 
>Radoslaw Skorupka
>Lodz, Poland

--
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: CICS suffering from Page-In delay: Page Stealing versus Paging Out

[Ted MacNEIL]

There is an option in the WLM to make a service class memory critical.
It was designed especially for this issue with CICS.
If CICS is not requesting the page out, this will protect all the regions in 
the service class.

-
-teD
-
  Original Message  
From: Peter Hunkeler
Sent: Friday, October 9, 2015 07:35
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: CICS suffering from Page-In delay: Page Stealing versus Paging Out

A word in advance: I have subscribed to the MXG-L list but have not yet granted 
access, so I'm asking here first.



I'm busy working on a problem some of CICS region are suffering from 
periodically. There are times when some CICS regions are paging-in some MB of 
storage and are thus suffering from the paging delay. 


Since this is about page-in, the storage that is paged-out has been in use 
before. It is not too clear yet what this storage is and what is causing it to 
be referenced again in that massive way. That's being investigated and is not 
directly my question here, although any hint is welcome as well.


I'm trying to understand why that amount of storage has been paged-out from 
those CICS regions, and when this has happened. looking at the SMF30 subtype 2 
for the CICS regions a indeed can see intervals with large number of pages 
being paged-out (SMF30PGO). I do not see any non-zero values indicating pages 
had been stolen (SMF30PST). 



It has been my understanding (which may be wrong, of course) that page 
steaqling happens when the Available Frame Queue goes below the min threshold. 
SRM/RSM will them steal pages and page them out. I would expect those numbers 
to appear in SMF30PST. And if this number is 0 for an address space, this one 
was not a donor in a low AFQ situation, right?




We do see the AFQ going low sometimes, and it was my assumption that those 
CICSs were victims by having pages stolen. This does not seem to be the case. 
What then causes the pages to be paged-out (SMF30PGO)? Is CICS doing PGOUT by 
itself?






--
Peter Hunkeler 









--
Peter Hunkeler

--
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: Subscribing to IBM-MAIN

[Ted MacNEIL]

Don't use the angle brackets.

It's just notation


-
-teD
-
  Original Message  
From: Ed Finnell
Sent: Thursday, October 8, 2015 18:20
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Subscribing to IBM-MAIN

Darren will probably respond when he gets off his day job. Guess the answer 
is required. If they're still having trouble might try the web page at 
listserv.ua.edu/archives/ibm-main.html where you can sign up and set options 
for sending and receiving.


In a message dated 10/8/2015 3:49:56 P.M. Central Daylight Time, 
jo.skip.robin...@sce.com writes:

What's with the angle brackets? Required? Prohibited? Nothing seems to 
work

--
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 to limit tiny SMS-managed VSAM KSDS to one volume?

[Ted MacNEIL]

What problems are you attempting to solve by enforcing this?

-
-teD
-
  Original Message  
From: Farley, Peter x23353
Sent: Wednesday, September 30, 2015 12:25
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: How to limit tiny SMS-managed VSAM KSDS to one volume?

I need some advice from storage gurus. I need to make a tiny SMS-managed VSAM 
KSDS that will NOT extend, neither to secondary space on the first volume nor 
to secondary volumes. I need to test some error logic in an application program 
and I need a "file full" or "no more space" condition to test it.

I have these parameters in the define cluster command:

VOLUME(*) CYL (1 0)

But when I try to fill up that file with IDCAMS REPRO so that there is no more 
room for any records by copying from a similar file with many records into the 
tiny one, it automatically extends to new volumes, with messages like this:

SMS4000I TSOUSERZ, MKTSTFIL, SYS1, ATTEMPTING SPACVOLA FOR TSOUSER. 
TINY.DATA, XX, 1
SMS4400I VOLUME ADDED - OLD VOLUME XX, NEW VOLUME SMS . VOLUME COUNT IS 2 

I assume this is due to some hidden parameter in the STORCLAS that overrides my 
specification of only one candidate volume.

My question is, how do I override that hidden STORCLAS parameter to force a 
no-more-space error here? I deliberately want the attempt to add one more 
record to force an error.

I do NOT have easy access to a storage admin on this system, so I need help 
from you. ISMF is not available in my TSO menus, so I cannot check the STORCLAS 
for myself.

TIA for any help you can offer.

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

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

Re: How to limit tiny SMS-managed VSAM KSDS to one volume?

[Ted MacNEIL]

Sorry missed that!

-
-teD
-
  Original Message  
From: Farley, Peter x23353
Sent: Wednesday, September 30, 2015 12:38
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: How to limit tiny SMS-managed VSAM KSDS to one volume?

As I said, I need to check some application program error logic designed to do 
application-specific recovery steps when there is a file-full condition. I need 
a file that I can fill up and that stays filled and does not extend in order to 
test that application logic.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ted MacNEIL
Sent: Wednesday, September 30, 2015 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to limit tiny SMS-managed VSAM KSDS to one volume?

What problems are you attempting to solve by enforcing this?

-
-teD
-
  Original Message  
From: Farley, Peter x23353
Sent: Wednesday, September 30, 2015 12:25
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: How to limit tiny SMS-managed VSAM KSDS to one volume?

I need some advice from storage gurus. I need to make a tiny SMS-managed VSAM 
KSDS that will NOT extend, neither to secondary space on the first volume nor 
to secondary volumes. I need to test some error logic in an application program 
and I need a "file full" or "no more space" condition to test it.

I have these parameters in the define cluster command:

VOLUME(*) CYL (1 0)

But when I try to fill up that file with IDCAMS REPRO so that there is no more 
room for any records by copying from a similar file with many records into the 
tiny one, it automatically extends to new volumes, with messages like this:

SMS4000I TSOUSERZ, MKTSTFIL, SYS1, ATTEMPTING SPACVOLA FOR TSOUSER. 
TINY.DATA, XX, 1
SMS4400I VOLUME ADDED - OLD VOLUME XX, NEW VOLUME SMS . VOLUME COUNT IS 2 

I assume this is due to some hidden parameter in the STORCLAS that overrides my 
specification of only one candidate volume.

My question is, how do I override that hidden STORCLAS parameter to force a 
no-more-space error here? I deliberately want the attempt to add one more 
record to force an error.

I do NOT have easy access to a storage admin on this system, so I need help 
from you. ISMF is not available in my TSO menus, so I cannot check the STORCLAS 
for myself.

TIA for any help you can offer.

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

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

Re: More "ageing mainframe" (bad) press.

[Ted MacNEIL]

Model 204:
The Bank of Nova Scotia (under VM)
Becker's
The Canadian Depository and Clearing Corporation

To name but 3.

-
-teD
-
  Original Message  
From: Anthony Thompson
Sent: Sunday, September 27, 2015 02:48
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: More "ageing mainframe" (bad) press.

The big one in that is the Australian Federal Government's CentreLink. They are 
attempting to replace a mainframe-based solution with a SAP solution.

The then Federal Treasurer, the esteemed Mr. Joe Hocking (now out on his arse 
after we got a new Prime Minister), claimed it was because the applications 
were running on old IBM hardware. Simply untrue, they have z196's (not the 
latest and greatest), but the applications ran on the Model 204 database. I 
think the only other organization on the planet that still runs Model 204 
applications is the US Department of Defence.

I'm pretty sure that $1.5 billion is going to blow out to a crapload more than 
that. Here, in my 'state' government, we attempted to replace a government 
asset control suite of mainframe applications with SAP. At a projected cost of 
$5 million. $70 million of tax payers money and five years later, they gave up 
and went back to the mainframe.

Allegorically, I've heard that 70% of major mainframe applications conversions 
to little-box SAP solutions fail (a Gartner statistic?).

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shane Ginnane
Sent: Friday, 25 September 2015 7:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: More "ageing mainframe" (bad) press.

http://www.itnews.com.au/news/the-top-five-green-screen-systems-that-run-australia-409614

Some large (by Aussie standards) mainframe customers that may be no more in the 
foreseeable future.

Shane ...

--
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: Testing with dates in the future

[Ted MacNEIL]

We did for Y2K.

-
-teD
-
  Original Message  
From: Markus Haselbach
Sent: Wednesday, September 23, 2015 04:55
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Testing with dates in the future

Hallo, 
in our installation we do application testing with special dates like end of 
month, end of year or leap day by IPling all Lpars in a test sysplex with a 
date/time offset which can be as big as 100 days or more. Does someone run test 
sysplexes also this way with future dates? 
Best regards 
Markus 

--
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: Dataset enqueue, how to find the culprit.

[Ted MacNEIL]

There is NO SUCH THINGS as a culprit!
They are just doing their job and so are you. They just happened to collide.

-
-teD
-
  Original Message  
From: Richard Pinion
Sent: Friday, September 18, 2015 14:31
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Dataset enqueue, how to find the culprit.

I think this setting for RMF will cut an SMF record for enqueue conditions.
RMF must be started pointing to the member which specifies ENQ(DETAIL).

EDIT USER.PARMLIB(ERBRMF00) - 01.05 Columns 1 00080 
Command ===> Scroll ===> CSR 
14 ENQ(DETAIL) 



--- stars...@mindspring.com wrote:

From: Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.
Date: Fri, 18 Sep 2015 11:16:35 -0700

So, it will depend on how often the TSO message for enqueue is produced. If it 
is not frequent, you may have to set slips or live with rerunning the job.

Or if it is frequent, you might try adding a first step with DISP=OLD on your 
file. then you would have a better idea of what is doing it or have the job 
wait until the file is freed.

You did not show what type of process is being used when this occurs. So if 
this is REXX/CLIST that does LM functions, or an IEBCOPY, or other

Perhaps if you could describe the process and functions being used that this 
condition occurred, we might provide better diags or alternatives.



Lizette


>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Toni Cecil
>Sent: Friday, September 18, 2015 12:21 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Dataset enqueue, how to find the culprit.
>
>Hello,
>yesterday I got the following dsn enqueue:
>IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I DATA 
>SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I - RETURN=(DD),PERM=YES 
>DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I - ERR=0210, INFO=, 
>REQUESTED DATA SET NOT AVAILABLE.
>SDAB005I ALLOCATED TO ANOTHER JOB.
>
>Is there a way to find today, who was "locking" the pds library ?? I run DAF 
>tool against TLF.ZPT.JCL.CNTL to see if something was shown about the enqueue, 
>but I didn't find anything, am I doing something wrong ?? Or is there any 
>other utility that could be more appropriate to check this "problem" ??
>
>Many thx, A.Cecilio.
>

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




_
Netscape. Just the Net You Need.

--
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: RSU or maintenance level on a system

[Ted MacNEIL]

What would the auditors gain with this knowledge?

-
-teD
-
  Original Message  
From: Jousma, David
Sent: Wednesday, September 16, 2015 08:30
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: RSU or maintenance level on a system

IBM is correct. No way to do that.

_
Dave Jousma
Assistant Vice President, 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 Lopez, Sharon
Sent: Wednesday, September 16, 2015 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RSU or maintenance level on a system

I already posted this question to IBM but wanted to find out if others are 
getting this request from their auditors.

Our auditors want to be able to display the RSU or maintenance level of our 
z/OS system. To my knowledge, there is no way to do that (IBM has also agreed). 
Does anyone know if this is possible and are you getting the same request from 
your auditors.? Keep in mind that our auditors do know z/OS or mainframe. It 
sounds like they are used to seeing displays on other platforms with this 
information with release and fix level.

Thank you in advance.






Email correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

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

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

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

Re: Current market share breakdown for EACH of the three z/OS ESM products: RACF, CA-ACF2 and CA-Top Secret

[Ted MacNEIL]

There are a couple of shops in Toronto that use it.
It was developed by a couple of. CROWN TECH/DATACROWN ex-employees.

-
-teD
-
  Original Message  
From: Shane Ginnane
Sent: Wednesday, September 9, 2015 14:52
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Current market share breakdown for EACH of the three z/OS ESM 
products: RACF, CA-ACF2 and CA-Top Secret

On Wed, 9 Sep 2015 08:47:27 -0500, Steve Harner  wrote:

>(a) When SKK was sold in 1986, ACF2 had a 60% market share while IBM’s RACF 
>and CA’s Top Secret split the other 40%; and (b) Currently , RACF has 75% 
>market share while ACF2 and Top Secret from CA share the other 25 percent.

Does anyone, other than reputedly CA itself, actually use T/S ?. Never seen it 
in a customer site.
When I first saw ACF2 (prior to the buyout), it was the ducks nuts - RACF was a 
slug in comparison. Seems IBM has won that battle though.

Shane ...

--
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: LOADING An AMODE64 Program

[Ted MacNEIL]

It was -- divisible by 400.

-
-teD
-
  Original Message  
From: Jon Butler
Sent: Tuesday, August 11, 2015 11:16
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: LOADING An AMODE64 Program

Did she realize 2000 was not a leap year?

--
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: Limit number of frames of real storage per job

[Ted MacNEIL]

1. IiRC, V=R is no longer supported. I could be wrong -- it happens sometimes.

2. The reason for the 'high' frame count is because the job needs‎ them. 
Limiting them, yourself if it were possible, would strangle the job. z/OS 
(srm/wlm) knows best as to who needs what and, in general, it's better not to 
second guess.

-
-teD
-
  Original Message  
From: Staller, Allan
Sent: Tuesday, August 4, 2015 10:56
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Limit number of frames of real storage per job

MCCAFCTH is not applicable in this case. You are correct that this is a LPAR 
level control.

The only out of the box solution I can think of is to run the job V=R' . See 
VRREGN in SYS1.PARMLIB(IEASYS00).
NOTE: An IPL is*REQUIRED* to change this value.

Of course, you could write a driver program to do what you want. i.e. obtain 
the real storage and then invoke JAVA. JZOS *may* be of some help here.

HTH,

snip
I would like to ask more experienced sysprogs regarding real storage manager.

Is it possible to limit number of frames of real storage on job level? The 
MEMLIMIT/REGION parameters limit virtual memory of whole address space however 
I would like to limit the only real memory while the virtual memory remain as 
it is.

The reason why I need it; I would like to test the performance of a (Java) 
application in case of lack of frames of real storage. In case of shortage of 
real storage a paging is expected. And I would like to simulate this situation 
to see impact a performance of the Java application.

I have found MCCAFCTH (defined in IEAOPTxx) but this seems to be LPAR (not job) 
specifics and moreover this defines length of available frame queue (not number 
of frames per job).
Thx for hints.
/snip

--
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: Limit number of frames of real storage per job

[Ted MacNEIL]

Okay. I knew I might have been wrong.

-
-teD
-
  Original Message  
From: John Eells
Sent: Tuesday, August 4, 2015 13:01
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Limit number of frames of real storage per job

eamacn...@yahoo.ca (Ted MacNEIL) wrote:
 1. IiRC, V=R is no longer supported. I could be wrong -- it happens sometimes.
snip

V=R remains supported.


-- 
John Eells
z/OS Technical Marketing
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: XCF HELP!

[Ted MacNEIL]

Which is worse?
The alleged SPOF?
Or, what happens when GRSRNLxx doesn't match?

-
-teD
-
  Original Message  
From: Vernooij, CP (ITOPT1) - KLM
Sent: Thursday, July 30, 2015 10:51
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: XCF HELP!

Better? I don't like SPOFs, especially when I can avoid them

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Scott Fagen
Sent: 30 July, 2015 16:19
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XCF HELP!

On Mon, 13 Jul 2015 10:47:15 -0400, Joseph W Gentile jwgen...@us.ibm.com 
wrote:

It's a good practice to update all the GRSRNLXX's for 
the sysplex at once. 

It's an even better practice to share the same GRSRNLxx member with all members 
in the GRS complex ;-)

Scott Fagen
Chief Architect - z Systems
CA Technologies

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

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

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




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

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

Re: XCF HELP!

[Ted MacNEIL]

SPOF - Single Point of Failure

I don't need to see the post: that was my point!

-
-teD
-
  Original Message  
From: Elardus Engelbrecht
Sent: Thursday, July 30, 2015 11:22
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: XCF HELP!

Ted MacNEIL wrote:

Which is worse?
The alleged SPOF?

What is SPOF? Single Point Of Failure? Or something else?

Or, what happens when GRSRNLxx doesn't match?

See the OP's message in this thread when she discovered her GRSRNLxx does not 
match...

Groete / Greetings
Elardus Engelbrecht

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

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

Re: Article on COBOL's inevitable return

[Ted MacNEIL]

Hence NOT ludicrous!

-
-teD
-
  Original Message  
From: Vince Coen
Sent: Wednesday, July 29, 2015 12:54
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Article on COBOL's inevitable return

I think you will find that was a demand (?) that all applications 
developed on behalf of the military (well at least the US Navy) had to 
be in Cobol - if nothing else to help with standards, maintenance  
migration.

You have to remember that there was more than one supplier of mainframes 
in the 60's such as IBM, Burroughs, Honeywell Univac, Sperry Rand to 
name but a few and in Europe OK, the U.K., ICL (ICL), English Electric 
and of course the first commercial computer the LEO 3 and these were 
also included in UK manuals of the time.

Check out the copyleft notice that is shown in all Cobol manuals and 
should also be in books although not in my one copy of a Cobol book - 
Cobol unleashed!
.
Vince

Cobol since 1963, IT since 1961 (from 1403, 7094, 360/30 et al).




On 29/07/15 17:20, Paul Gilmartin wrote:
 On Wed, 29 Jul 2015 12:11:56 -0400, Ted MacNEIL wrote:

 Why is it so ludicrous? The USDOD did develop COBOL for some reasom.

 And a generation later, they likewise required ADA. I don't know if that
 was ever countermanded.

 I know a programmer who argued that his assignment could not be accomplished
 in ADA. He was given an exemption and allowed to use assembler.

 � Original Message �
 From: zMan
 Sent: Wednesday, July 29, 2015 11:28

 *The Department of Defense even decreed that all businesses must run on
 COBOL in the 1960s.*
 A ludicrous assertion.
 -- gil


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

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

Re: Article on COBOL's inevitable return

[Ted MacNEIL]

Why is it so ludicrous? The USDOD did develop COBOL for some reasom.

-
-teD
-
  Original Message  
From: zMan
Sent: Wednesday, July 29, 2015 11:28
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Article on COBOL's inevitable return

Fairly decent except for several major points of nonsense:

*The Department of Defense even decreed that all businesses must run on
COBOL in the 1960s.*
A ludicrous assertion.

*But the even bigger reason not to rock the boat is the sheer size and
cost of replacing billions of lines of COBOL that exist today. Many of
these programs contain sensitive information about people, like social
security numbers, banking info, credit card info and healthcare records.*
Sorry, no -- *programs* don't contain that data. Programs read/process
data. WTF.

*Without a doubt, it is a challenge to find a developer in Cobol who is
not nearing retirement age,*
That would surprise IBM Academic Initiative institutions.

Yes, the overall point is valid: COBOL skills are retiring/dying. So more
folks will learn it. Whoopee.

Some of the comments are funny; one of my favorites is the guy who says
he'd take $12,500 less per year to avoid COBOL. I understand his sentiment,
just am baffled by his precision. OTOH, maybe it's like the old joke about
the boss and the secretary (We've established that, we're negotiating...).

On Tue, Jul 28, 2015 at 9:55 AM, John McKown john.archie.mck...@gmail.com
wrote:

 http://blog.hackerrank.com/the-inevitable-return-of-cobol/

 A fairly decent article. It doesn't appear to be a piece designed to
 promote some vendor or another. Not in depth, but with some good truths
 plainly stated. It might even be understandable to a Windows person. OOPS,
 there I go being tacky again.

 --

 Schrodinger's backup: The condition of any backup is unknown until a
 restore is attempted.

 Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

 He's about as useful as a wax frying pan.

 10 to the 12th power microphones = 1 Megaphone

 Maranatha! 
 John McKown

 --
 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: Article on COBOL's inevitable return

[Ted MacNEIL]

Depends on what context you took it in.
I (silly me) took it to mean all DoD business.

-
-teD
-
  Original Message  
From: Joel Ewing
Sent: Wednesday, July 29, 2015 15:16
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Article on COBOL's inevitable return

Well, actually the original statement WAS self-apparently ludicrous
because it stated that U.S. DoD decreed ALL businesses would use COBOL,
period, and DoD has never had that much authority.

DoD had zero control over businesses that did not work on defense
contracts for DoD, and even those with defense contracts could only be
constrained to DoD standards in the work they did on behalf of those
defense contracts. The use of an unconstrained ALL is what made it
ludicrous. The considerable influence of DoD as a major consumer forced
the availability of COBOL and later ADA support and set the standards
for code written for DoD projects, but DoD is not [yet] omnipotent.
JC Ewing

On 07/29/2015 12:04 PM, Ted MacNEIL wrote:
 Hence NOT ludicrous!
 
 -
 -teD
 -
 Original Message 
 From: Vince Coen
 Sent: Wednesday, July 29, 2015 12:54
 To: IBM-MAIN@LISTSERV.UA.EDU
 Reply To: IBM Mainframe Discussion List
 Subject: Re: Article on COBOL's inevitable return
 
 I think you will find that was a demand (?) that all applications 
 developed on behalf of the military (well at least the US Navy) had to 
 be in Cobol - if nothing else to help with standards, maintenance  
 migration.
 
 You have to remember that there was more than one supplier of mainframes 
 in the 60's such as IBM, Burroughs, Honeywell Univac, Sperry Rand to 
 name but a few and in Europe OK, the U.K., ICL (ICL), English Electric 
 and of course the first commercial computer the LEO 3 and these were 
 also included in UK manuals of the time.
 
 Check out the copyleft notice that is shown in all Cobol manuals and 
 should also be in books although not in my one copy of a Cobol book - 
 Cobol unleashed!
 .
 Vince
 
 Cobol since 1963, IT since 1961 (from 1403, 7094, 360/30 et al).
 
 
 
 
 On 29/07/15 17:20, Paul Gilmartin wrote:
 On Wed, 29 Jul 2015 12:11:56 -0400, Ted MacNEIL wrote:

 Why is it so ludicrous? The USDOD did develop COBOL for some reasom.

 And a generation later, they likewise required ADA. I don't know if that
 was ever countermanded.

 I know a programmer who argued that his assignment could not be accomplished
 in ADA. He was given an exemption and allowed to use assembler.

 � Original Message �
 From: zMan
 Sent: Wednesday, July 29, 2015 11:28

 *The Department of Defense even decreed that all businesses must run on
 COBOL in the 1960s.*
 A ludicrous assertion.
 -- gil

 


-- 
Joel C. Ewing, Bentonville, AR jcew...@acm.org  

--
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: model-9 and model-27 mixture

[Ted MacNEIL]

I'm constantly amazed at the number of times this type of question still comes 
u‎p considering how long the technology has been around!

-
-teD
-
  Original Message  
From: Buckton, T. (Theo)
Sent: Monday, July 20, 2015 10:32
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: model-9 and model-27 mixture

Thanks.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: 20 July 2015 04:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: model-9 and model-27 mixture

I have all versions of dasd in my pools. For all types of datasets (VSAM,SEQ, 
etc...)


So Mod3/9/27/54

No issues doing this. 

Lizette


 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
 On Behalf Of Buckton, T. (Theo)
 Sent: Monday, July 20, 2015 7:29 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: model-9 and model-27 mixture
 
 Hi, please advise... is it ok to have a mixture of model-9 and 
 model-27 volumes in one sms storage group? This is for sequential data sets.
 
 Regards
 
 
 

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


Nedbank Limited Reg No 1951/09/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]



--
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: Corrupt PDSE

[Ted MacNEIL]

Look into the fact that you can't share PDSE's across SYSPLEX's.

-
-teD
-
  Original Message  
From: Jake Anderson
Sent: Wednesday, July 15, 2015 17:31
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Corrupt PDSE

Hello,

I get below message when i try to access a PDSE dataset, but when I try to
access the same Dataset from a different SYSPLEX it opens up. We do share
the Dasd .

IGW702I PDSE Directory Validation Unsuccessful
DESC:ND Structure is corrupted
LTK:
*
ERROR NUM:15
DSN:JAKE.PDSE.JCL
VOLSER:TCHN011
RC:8 RS:0118800E R14:8A55EDCE
RPN:N/A
VPTVFN:N/A
IGW702I PDSE Directory Validation Unsuccessful
DESC:ND Structure is corrupted
LTK:
*
ERROR NUM:14
DSN:CA.JAKE.PDSE.JCL
VOLSER:TCHN011
RC:8 RS:0118800E R14:8A55EDE8
RPN:N/A
MEMBER NAME:NETUPQ
VPTVFN:N/A
IEA995I SYMPTOM DUMP OUTPUT
SYSTEM COMPLETION CODE=0F4 REASON CODE=0024
TIME=11.32.41 SEQ=04674 CPU= ASID=01D8
PSW AT TIME OF ERROR 075C1000 8A66C6E0 ILC 2 INTC 0D
NO ACTIVE MODULE FOUND - PRIMARY NOT EQUAL TO HOME
NAME=UNKNOWN
DATA AT PSW 0A66C6DA - 58F05048 0A0DB219 A788
AR/GR 0: 009FF890/_0118800E 1: /_040F4000
2: /0048_00FDB290 3: /_7F2E8268
4: /_7703 5: 0002/_7F2ED0C0
6: /_7F2E8060 7: /_00FD8ED8
8: /_00FD8F48 9: /_7F2E8268
A: /_7F2ED4D8 B: /_
C: /_0A66C062 D: /_7F2ED3E8
E: /_8A66C6D2 F: /_0024
END OF SYMPTOM DUMP
IEC036I 002-A4,IGC0005E,JAKE11,TSOPROC,ISP11321,Z09E,TCHN011,
JAKE.PDSE.JCL
***

Any pointers where I might be looking into ?

Jake

--
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: SMS ACS ROUTINE VARIABLES

[Ted MacNEIL]

A point of curiosity. Why are your users not allowed to create PDSE datasets?

-
-teD
-
  Original Message  
From: willie bunter
Sent: Friday, July 3, 2015 09:34
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: SMS ACS ROUTINE VARIABLES

I saw the USER variable in the doc but I was thrown off track when I read the 
explanation of USER which says the following : The user ID of the person 
allocating the dataset. I would like to try your suggestion however since we 
have multiple batch users begining @ would a @* work because the job(s) are 
submitted by the scheduler?


On Thu, 7/2/15, Greg Shirey wgshi...@benekeith.com wrote:

Subject: Re: SMS ACS ROUTINE VARIABLES
To: IBM-MAIN@LISTSERV.UA.EDU
Received: Thursday, July 2, 2015, 1:46 PM

USER is the User ID
associated with the batch job.   If you have a
FILTLIST of the User IDs called, say, NOPDSES,
then you can code:

WHEN
(USER EQ NOPDSES  AND    
   
  DSNTYPE EQ 'LIB')  THEN DO
    WRITE 'NOT ALLOWED FOR PDSE'
    EXIT CODE(12)
   
END


HTH,
Greg Shirey
Ben E. Keith Company 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of willie bunter
Sent: Thursday,
July 02, 2015 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMS ACS ROUTINE VARIABLES

Hallo All,

I am stuck with trying to figure out how I can
code the variable for a Batch userid.  For examle users
aren't allowed to create a PDSe.  I thought by coding
the condition for the user's batch id it would solve the
problem.  However, I looked at all the SMS ACS read
variable list but there is none for a batch id.
Could anyone suggest how I can go about
this?

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

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

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

Re: z/OS DASD: Way to gather DASD Response Time ?

[Ted MacNEIL]

Statistics can always show what you think you want.
But, showing 24-hour averages doesn't prove a lack of performance impact.

You're doing your customers a disservice if you don't demonstrate the impact 
during peak times. 10-15 minute duration.

-
-teD
-
  Original Message  
From: Toni Cecil
Sent: Thursday, July 2, 2015 05:38
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: z/OS DASD: Way to gather DASD Response Time ?

Hi Shane,
it might sound strange to you, but we need to demonstrate to one our
clients that moving data from mod3, or mod9 to mod27 didn't cause any dasd
performance problems for their applications.
That's a living.
Regards, A.Cecilio.


2015-06-27 5:47 GMT+01:00 Shane Ginnane ibm-m...@tpg.com.au:

 I've decided to use RMF:
 DINTV(2400)

 That's like asking for the average speed for all the taxi drivers in a
 company over an entire day.
 It might be the one number you may have been asked for, but it's useless.
 You need to educate your users/managers.

 Shane ...

 --
 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: Forbes: IT Professionals Don't Have What The Tech Industry Wants

[Ted MacNEIL]

Less money usually means less skill, too.
So it seems from my experience up here in Canada.

(less care, too)

-
-teD
-
  Original Message  
From: Leonard Sasso
Sent: Thursday, July 2, 2015 13:36
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Forbes: IT Professionals Don't Have What The Tech Industry Wants

The REAL reason they bring foreign workers to the U.S. is because they can 
pay them LESS money to do the work. 


Thank You.

Len Sasso
RDC Applications Management - Professional: System Administrator
Backup QMR - Production Operations
CSC

Vacation Alert: ?

327 Columbia TPKE, Rensselaer NY 12144
NES | t: 518.257-4209 | m: 518-894-0879 | f: 257-4300 | lsa...@csc.com | 
www.csc.com


This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.



From: Dana Mitchell mitchd...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 07/02/2015 11:49 AM
Subject: Re: Forbes: IT Professionals Don't Have What The Tech 
Industry Wants
Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



On Thu, 2 Jul 2015 14:16:44 +0800, Timothy Sipples sipp...@sg.ibm.com 
wrote:

The absolute, sure fire way to determine whether there's a specific
shortage is to look at the price of the product or service in alleged
short supply relative to general inflation. 

To net it out, we don't see evidence in these data that there's an IT 
labor
shortage in the United States. Or, if there is a shortage, it isn't
getting materially worse. 


Which makes IBM's response to Senator Charles Grassley even more 
preposterous:

The high skilled visa programs provide a limited but necessary means for 
IBM to meet the near to medium term needs of its U.S clients and our own 
business. The technology industry's shift to new, higher value growth 
areas such as cloud, analytics, mobile, security and social technologies 
is placing a greater premium on a new set of skills. These changes are 
exacerbating the skills shortage that we discussed with you during your 
2013 visit to IBM's Dubuque center.
We bring goreign workers to the U.S. because those workers have specific 
profiles and expertise that we cannot source locally in a timely way to 
fulfill client contract requirements.

Dana

--
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: SMFDUMP CBT S0C4 under z/OS 2.1

[Ted MacNEIL]

The IBM supplied utility IFASMFDP.

-
-teD
-
  Original Message  
From: Rich Szabo
Sent: Monday, June 22, 2015 00:32
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: SMFDUMP CBT S0C4 under z/OS 2.1

SMFDUMP V10 from the CBT tape is giving us a S0C4 under z/OS 2.1. 
It’s choking on the instruction at x’E4’ which is 
GETNSMF TM RDSFLG1,RDSDUMP IS SMF DATASET FULL
Error is a page translation exception, R10 = 130E1

Is anyone running SMFDUMP OK under 2.1? Does anyone have an updated
version of this? 

Or, what else is available to automate the dumping of the correct (just
filled) SMF dataset?

Rich Szabo
State Auto Insurance

--
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 is CAMASTER started?

[Ted MacNEIL]

So, how is it done?

-
-teD
-
  Original Message  
From: Scott Fagen
Sent: Friday, June 19, 2015 17:59
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: How is CAMASTER started?

On Thu, 18 Jun 2015 11:12:27 +0200, nitz-...@gmx.net nitz-...@gmx.net wrote:

 Does anyone know?

Yes. 

We made our case to IBM, they agreed and provided a licensed API.

Scott Fagen
Chief Architect - Mainframe
CA Technologies

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

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

Re: OT STCK question

[Ted MacNEIL]

The only reason for they (singular) is for formal documentation and the press.
The verb still has to match the pronoun.
This has been 'formally' been accepted in Canada.
But, it's all for the sake of political correctness.

Political Correctness is a doctrine fostered by a delusional, illogical 
minority and rabidly promoted by an unscrupulous press which holds forth the 
proposition that it is entirely possible to pick up a turd by the clean end.


-
-teD
-
  Original Message  
From: Tony's Outlook via Mozilla
Sent: Wednesday, June 17, 2015 16:59
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: OT STCK question

Aw geez, where's Gilmore when we need him?




On 6/17/2015 3:48 PM, Ted MacNEIL wrote:
 It's generally for generic usage.
 It's okay when used colloquially, ie:
 Pat enjoys a drink when he's alone.
 OR:
 Pat enjoys a drink when she's alone.

 Exaggerated examples are akin to straw-person arguments.

 -
 -teD
 -
 Original Message
 From: Paul Gilmartin
 Sent: Wednesday, June 17, 2015 16:31
 To: IBM-MAIN@LISTSERV.UA.EDU
 Reply To: IBM Mainframe Discussion List
 Subject: Re: OT STCK question

 On Mon, 15 Jun 2015 19:30:26 -0400, Shmuel Metz (Seymour J.) wrote:

 If they is newly to assume a singular meaning,

 Newly? That ship sailed before or grandfathers were born.

 No, it's dragging its anchor most uncomfortably:

 Pat tells me that they enjoy a glass of wine with their meal when
 they're dining alone.

 -- gil

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

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


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

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

Re: OT STCK question

[Ted MacNEIL]

It's generally for generic usage.
It's okay when used colloquially, ie:
Pat enjoys a drink when he's alone.
OR:
Pat enjoys a drink when she's alone.

Exaggerated examples are akin to straw-person arguments.

-
-teD
-
  Original Message  
From: Paul Gilmartin
Sent: Wednesday, June 17, 2015 16:31
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: OT STCK question

On Mon, 15 Jun 2015 19:30:26 -0400, Shmuel Metz (Seymour J.) wrote:

If they is newly to assume a singular meaning,

Newly? That ship sailed before or grandfathers were born.
 
No, it's dragging its anchor most uncomfortably:

Pat tells me that they enjoy a glass of wine with their meal when
they're dining alone.

-- gil

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

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

Re: Is there any tools or interface which could analyse or monitor SYS1.MANX directly?

[Ted MacNEIL]

'waste' depends on frequency of use, ease of maintenance, skill set(s), AND 
impact to th 4HRA.

-
-teD
-
  Original Message  
From: David Crayford
Sent: Monday, June 15, 2015 10:46
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Is there any tools or interface which could analyse or monitor 
SYS1.MANX directly?

On 15/06/2015 9:40 PM, Itschak Mugzach wrote:
 why did George used ISPF BATCH if he is not doing any use of the
 environment in the Rexx? It is a waist of resources.

IDK. But REXX is a waste of resources when there are better weapons in 
arsenal.

 ITschak

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

 On Mon, Jun 15, 2015 at 4:33 PM, David Crayford dcrayf...@gmail.com wrote:

 On 15/06/2015 9:17 PM, Charles Mills wrote:

 With COBOL? Can you read RAW SMF records like SMF type 30 with all its
 sections with COBOL?

 Good point. Perhaps not. You could certainly do some processing of some
 SMF records with COBOL, or you could write an assembler routine to make SMF
 triplet sections readily addressable with COBOL. Or perhaps with native
 COBOL -- doesn't COBOL now have some sort of based variable support? IANACP
 (I am not a COBOL programmer.)

 COBOL can do all the offset based stuff. It used to be terrible at pointer
 arithmetic but handle that now without a sweat.

 If you have the mappings COBOL would probably be a better choice then a
 lot of languages. Especially now it's fast.


 Charles

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
 Behalf Of Elardus Engelbrecht
 Sent: Monday, June 15, 2015 3:44 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Is there any tools or interface which could analyse or
 monitor SYS1.MANX directly?

 Charles Mills wrote:

 SMF record formats are all documented (some a lot more thoroughly than
 others LOL).

 Of course. Just have a good calculator ready... ;-D


 Having somehow queued your records for further processing, you can do
 analysis to your heart's content in assembler, COBOL, or your language of
 choice.

 With COBOL? Can you read RAW SMF records like SMF type 30 with all its
 sections with COBOL? [1] With Assembler that is easy and I have written

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

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

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

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

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

Re: OT STCK question

[Ted MacNEIL]

Canada and the US: two countries separated by a common language.

-
-teD
-
  Original Message  
From: J O Skip Robinson
Sent: Friday, June 12, 2015 14:21
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: OT STCK question

My head is about to explode. In US English grammar, 'everyone' is and always 
has been singular; 'they' is and always has been plural. I'm not talking about 
'logical reference', just grammatical construction. 

There's a big difference. In UK English, it's common to say 'the committee 
are'. In US English, we say 'the committee is' even though there are multiple 
people involved. In US we adhere to grammatical agreement; in UK, logical 
agreement may prevail. I don't know about Canadian English. 

I have no problem with 'they/them' as genderless generic pronouns. But failure 
of number agreement is linguistic cacophony. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert A. Rosenberg
Sent: Friday, June 12, 2015 7:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OT STCK question

At 11:19 -0500 on 06/11/2015, Paul Gilmartin wrote about Re: OT STCK question:

On Thu, 11 Jun 2015 10:47:39 -0500, Mike Schwab wrote:

I use they all the time as the genderless pronoun. A supervisor 
suggested he, I changed it to (s)he.

Of course, like all pronouns, it should assimilate its number, 
singular, from its antecedent. A form both politically and gramatically 
correct is:

 Everyone thinks they is being politically correct.

Shouldn't that be Everyone thinks they ARE being politically correct?

Everyone and they (?) are plural while is is singular - Thus the change to 
plural are.

--
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: GRS Control Unit ( Was IBM mainframe operations in the 80s)

[Ted MacNEIL]

Now I remember!
In 1981, I had to go in when I was on nights (mornings) and switch all the 
printers over.

-
-teD
-
  Original Message  
From: Norman.Hollander
Sent: Friday, June 12, 2015 12:17
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: GRS Control Unit ( Was IBM mainframe operations in the 80s)

3088 Multi-System Channel-to-Channel I/O Control Unit. Bus and Tag, connecting 
4 CPUs (IIRC).
We used these (had to have 2 for redundancy) for JES2, VTAM, and CA-MIM 
connectivity. Also
used to connect to VM systems (PVM, RSCS, and CA-MIM). Obsoleted by ESCON and 
Directors.
May have a picture somewhere with a 3088 and 9032 (ESCON director). Without the 
3088, you
needed many dedicated channels on each processor.

zNorman

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: Friday, June 12, 2015 7:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GRS Control Unit ( Was IBM mainframe operations in the 80s)

Yep. That's it. Thanks for remembering. We were still using one when I left my 
previous position in 1995 with a 3090 400E processor.

Mark Jacobs

 Gross, Randall [PRI-1PP] mailto:randy.gr...@primerica.com
 June 12, 2015 at 10:05 AM
 IBM 3088 CTC

 Global Resource Serialization

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
 On Behalf Of Mark Jacobs - Listserv
 Sent: Friday, June 12, 2015 10:02 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: GRS Control Unit ( Was IBM mainframe operations in the 
 80s)

 I don't remember the device number but it was used for CTC 
 communications using bus and tag cables.

 Mark Jacobs


 Mark Jacobs - Listserv mailto:mark.jac...@custserv.com June 12, 2015 
 at 10:02 AM I don't remember the device number but it was used for CTC 
 communications using bus and tag cables.

 Mark Jacobs


 Elardus Engelbrecht mailto:elardus.engelbre...@sita.co.za
 June 12, 2015 at 9:53 AM

 I have watched that nice video, bringing back memories of those 3800, 
 3380, 3090, 3420 and such animals.

 But what the four letter word is a 'GRS Control Unit'?

 Searches on IBM webpages (and history webpages) gave me just all 
 [useless] info about GRS or CONTROL or UNIT, but not specific details 
 about that device.

 Anyone having a clue what device is it? Is it the grandfather of the 
 XCF and such things?

 TIA!

 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


 Please be alert for any emails that may ask you for login information 
 or directs you to login via a link. If you believe this message is a 
 phish or aren't sure whether this message is trustworthy, please send 
 the original message as an attachment to 'phish...@timeinc.com'.


-- 

Mark Jacobs
Time Customer Service
Technology and Product Engineering

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


--
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: OT STCK question

[Ted MacNEIL]

‎A common choice, at least in Canada, is to use the plural pro-noun, since, in 
English, it in gender neutral.

It's difficult to get used to, at first.

-
-teD
-
  Original Message  
From: Elardus Engelbrecht
Sent: Thursday, June 11, 2015 10:46
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: STCK question

John McKown wrote:

 I've seen s/he used to cover both genders.
​Well, being computer professionals, despite not being of the UNIX variety, 
perhaps we use use the regular expression: s?he​

​(the ? means repeat 0 or 1 times aka optional). Unless we post in the 
ISPF forum whereupon it becomes r's?sh' to match PDF EDIT's specification of a 
regular expression.​

So, you and me are zero or optional, because we're males? ;-)

Should r's?sh' not be r's?she'? Or am I missing something optional? 


Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

Hehehe, resist, I will not, your good signature lines. ;-)

Groete / Greetings
Elardus Engelbrecht

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

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

Re: IND$FILE Resource Log Monitoring

[Ted MacNEIL]

It was the TV show.

-
-teD
-
  Original Message  
From: Tony's Outlook via Mozilla
Sent: Thursday, June 11, 2015 22:11
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: IND$FILE Resource Log  Monitoring

Not wishing to be a Black Hat and not wanting to think like a White Hat, 
let me don my Gray Hat. If I wanted to send a PDS member containing 
source code I'd simply email it. If it were large I'd mail it in pieces.

In the movie Mash, Corporal Radar O'Reilly send a Jeep from Korea to his 
home town in the U.S. in pieces, in small parcels.



On 6/11/2015 12:20 PM, Carlos Cordero wrote:
 Colleagues,

 Did somebody has implemented a process for monitor/log IND$FILE command 
 activity focussed on file transmission thru 3270 emulators?, maybe with 
 beta88 software?

 Or it must a home-made ad-hoc customization outside of beta88 software?

 What I specifically searching for is to detect the file transfer activity 
 executed from commands given on emulators.


 Many Thanks.




 Date: Sat, 6 Jun 2015 05:59:55 -0400
 From: 000248cce9f3-dmarc-requ...@listserv.ua.edu
 Subject: Re: Volume consideration and migration for z / OS 2.1
 To: IBM-MAIN@LISTSERV.UA.EDU

 Lots of info here:
 http://www-03.ibm.com/systems/z/os/zos/installation/

 Couldn't get the Data Sheet to open(404) maybe it's being updated.



 In a message dated 6/6/2015 2:27:44 A.M. Central Daylight Time,
 justmainfra...@gmail.com writes:

 Any advise on the above would be appreciated.


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


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

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

Re: OT STCK question

[Ted MacNEIL]

I don't know about politically correct.
But, it is recommended in the Canadian Press Book of Style.

-
-teD
-
  Original Message  
From: Paul Gilmartin
Sent: Thursday, June 11, 2015 18:11
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: OT STCK question

On Thu, 11 Jun 2015 10:47:39 -0500, Mike Schwab wrote:

I use they all the time as the genderless pronoun. A supervisor
suggested he, I changed it to (s)he.
 
Of course, like all pronouns, it should assimilate its number, singular,
from its antecedent. A form both politically and gramatically correct is:

Everyone thinks they is being politically correct.

-- gil

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

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

Re: List of all on-line volumes com106.226.661

[Ted MacNEIL]

Sorry. Spellchecker -- OH should read OC.

-
-teD‎
-
  Original Message  
From: Ted MacNEIL
Sent: Friday, May 29, 2015 11:11
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: List of all on-line volumes com106.226.661

OH is part of OPS/REXX which is part of OPS/MVS, iirc.

-
-teD
-
  Original Message  
From: Jousma, David
Sent: Friday, May 29, 2015 10:01
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: List of all on-line volumes com106.226.661

I suspect OC is a site REXX exec that captures the output of the passed 
command back into a ISPF edit/view session. The command actual is DS 
QD,TYPE=ALL,ONLINE

_
Dave Jousma
Assistant Vice President, 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 George Rodriguez
Sent: Friday, May 29, 2015 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: List of all on-line volumes com106.226.661

Bavo,

Ran your job and got this:

OC C('DS QD,TYPE=ALL,ONLINE')
IKJ56500I COMMAND OC NOT FOUND



*George Rodriguez*
*Specialist II - IT Solutions*
*IT Enterprise Applications*
*PX - 47652*
*(561) 357-7652 (office)*
*(954) 415-7586 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-251*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Eight Consecutive Years*

On Fri, May 29, 2015 at 9:30 AM, Bavo Devogeleer  
bavo.devogel...@colruytgroup.com wrote:




 Dear ,


 devserv command in batch gives the nessesary information .


 //STP001 EXEC PGM=IKJEFT1A,REGION=0M

 //SYSPRINT DD SYSOUT=*

 //SYSTSPRT DD SYSOUT=X

 //SYSTERM DD SYSOUT=*

 //SYSTSOUT DD SYSOUT=*

 //SYSTSIN DD *

 OC C('DS QD,TYPE=ALL,ONLINE')

 /*


 regards


 bavo.








 - Origineel bericht: com106.223.412
 -



 From: van der Grijn, Bart (B) (bvandergr...@dow.com)

 To: IBM-MAIN@LISTSERV.UA.EDU

 Copy: claude.cuvel...@colruytgroup.com, 
 bavo.devogel...@colruytgroup.com

 Subject: Re: List of all on-line volumes

 Date: 29 mei 2015 (15:03)






 I believe it is. We use it to get a list of all volumes 
 (online and offline) to check for duplicate volumes.

 Example (change the VOLSTYPE to get just the online volumes):



 //DASDLST EXEC ACBJBAOB,REGION=120M,

 // PLIB1=SYS1.DGTPLIB,

 // TABL2=PSSYS.TEMP.DUPVOL.TABLES

 //SYSTSIN DD *

 PROFILE PREFIX(IBMUSER) MSGID

 ISPSTART CMD(ACBQBAI4 +

 SAVE ALLVOL +

 PHYDATA(Y) +

 SPCDATA(N) +

 VOLSTYPE(3)) +

 NEWAPPL(DGT) BATSCRW(132) BATSCRD(27) BREDIMAX(3)
 BDISPMAX()

 /*



 -Original Message-

 From: IBM Mainframe Discussion List [mailto:
 IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Finnell

 Sent: Thursday, May 28, 2015 2:58

 To: IBM-MAIN@LISTSERV.UA.EDU

 Subject: Re: List of all on-line volumes



 Is it still called Naviquest?



 Several options to include PDS, DEVSERV(DS) console commands, 
 List Backups

 from whatever you're using to create. To shorten the process I 
 made a

 spread sheet that was in every turtle shell. Now we have a 
 mirrored site out of

 state.





 In a message dated 5/28/2015 11:59:17 A.M. Central Daylight 
 Time,

 bvandergr...@dow.com writes:



 ISMF in batch is another option.




 --

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

 send email to lists...@listserv.ua.edu with the message: INFO 
 IBM-MAIN






 Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze 
 website Ce message est soumis aux conditions disponibles sur notre 
 site web This message is subject to the terms and conditions available 
 on our website

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


-- 


*Disclaimer: *Under Florida law, e-mail addresses are public records. If you do 
not want your e-mail address released in response to a public records request, 
do not send electronic mail to this entity. Instead, contact this office by 
phone or in writing.


--
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 contains information that is confidential and may be 
privileged. It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately

Re: List of all on-line volumes com106.226.661

[Ted MacNEIL]

OH is part of OPS/REXX which is part of OPS/MVS, iirc.

-
-teD
-
  Original Message  
From: Jousma, David
Sent: Friday, May 29, 2015 10:01
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: List of all on-line volumes com106.226.661

I suspect OC is a site REXX exec that captures the output of the passed 
command back into a ISPF edit/view session. The command actual is DS 
QD,TYPE=ALL,ONLINE

_
Dave Jousma
Assistant Vice President, 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 George Rodriguez
Sent: Friday, May 29, 2015 9:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: List of all on-line volumes com106.226.661

Bavo,

Ran your job and got this:

OC C('DS QD,TYPE=ALL,ONLINE')
IKJ56500I COMMAND OC NOT FOUND



*George Rodriguez*
*Specialist II - IT Solutions*
*IT Enterprise Applications*
*PX - 47652*
*(561) 357-7652 (office)*
*(954) 415-7586 (mobile)*
*School District of Palm Beach County*
*3348 Forest Hill Blvd.*
*Room B-251*
*West Palm Beach, FL. 33406-5869*
*Florida's Only A-Rated Urban District For Eight Consecutive Years*

On Fri, May 29, 2015 at 9:30 AM, Bavo Devogeleer  
bavo.devogel...@colruytgroup.com wrote:




 Dear ,


 devserv command in batch gives the nessesary information .


 //STP001 EXEC PGM=IKJEFT1A,REGION=0M

 //SYSPRINT DD SYSOUT=*

 //SYSTSPRT DD SYSOUT=X

 //SYSTERM DD SYSOUT=*

 //SYSTSOUT DD SYSOUT=*

 //SYSTSIN DD *

 OC C('DS QD,TYPE=ALL,ONLINE')

 /*


 regards


 bavo.








 - Origineel bericht: com106.223.412
 -



 From: van der Grijn, Bart (B) (bvandergr...@dow.com)

 To: IBM-MAIN@LISTSERV.UA.EDU

 Copy: claude.cuvel...@colruytgroup.com, 
 bavo.devogel...@colruytgroup.com

 Subject: Re: List of all on-line volumes

 Date: 29 mei 2015 (15:03)






 I believe it is. We use it to get a list of all volumes 
 (online and offline) to check for duplicate volumes.

 Example (change the VOLSTYPE to get just the online volumes):



 //DASDLST EXEC ACBJBAOB,REGION=120M,

 // PLIB1=SYS1.DGTPLIB,

 // TABL2=PSSYS.TEMP.DUPVOL.TABLES

 //SYSTSIN DD *

 PROFILE PREFIX(IBMUSER) MSGID

 ISPSTART CMD(ACBQBAI4 +

 SAVE ALLVOL +

 PHYDATA(Y) +

 SPCDATA(N) +

 VOLSTYPE(3)) +

 NEWAPPL(DGT) BATSCRW(132) BATSCRD(27) BREDIMAX(3)
 BDISPMAX()

 /*



 -Original Message-

 From: IBM Mainframe Discussion List [mailto:
 IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Finnell

 Sent: Thursday, May 28, 2015 2:58

 To: IBM-MAIN@LISTSERV.UA.EDU

 Subject: Re: List of all on-line volumes



 Is it still called Naviquest?



 Several options to include PDS, DEVSERV(DS) console commands, 
 List Backups

 from whatever you're using to create. To shorten the process I 
 made a

 spread sheet that was in every turtle shell. Now we have a 
 mirrored site out of

 state.





 In a message dated 5/28/2015 11:59:17 A.M. Central Daylight 
 Time,

 bvandergr...@dow.com writes:



 ISMF in batch is another option.




 --

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

 send email to lists...@listserv.ua.edu with the message: INFO 
 IBM-MAIN






 Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze 
 website Ce message est soumis aux conditions disponibles sur notre 
 site web This message is subject to the terms and conditions available 
 on our website

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


-- 


*Disclaimer: *Under Florida law, e-mail addresses are public records. If you do 
not want your e-mail address released in response to a public records request, 
do not send electronic mail to this entity. Instead, contact this office by 
phone or in writing.


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


--

Re: Did I really need a CLIST???

[Ted MacNEIL]

Real programmers don't document code
 It was hard to write; it should be hard to read!

-
-teD
-
  Original Message  
From: CM Poncelet
Sent: Saturday, May 23, 2015 20:35
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Did I really need a CLIST???

I spake in jest (derived from the original real men don't eat quiche). 
Of course, real programmers read/write in machine code - but then also 
in conditional macro assembler if necessesary grin. Cheers, CP

John McKown wrote:

On Wed, May 20, 2015 at 10:48 AM, CM Poncelet ponce...@bcs.org.uk wrote:

 

Was there not a saying, a while ago, that real programmers write in
Fortran? grin
 



​Real programmers hand assemble and toggle the bits in, a byte at a time!​



 

Elardus Engelbrecht wrote:

 Tom Brennan wrote:
 


 

Coding subcommands in reverse order just to save one letter in each REXX
 

command would be absurd.


 

 

Completely you with agree I, Skip.


 

I cannot code in reverse without Skipping your word play... ;-D Friday,
is it already? 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








lists...@listserv.ua.edu




 

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