Re: z/OS unsupported programming practice - Finding TSO ECT

2016-02-25 Thread Binyamin Dissen
I have used this for many many years

 L R9,PSATOLD-PSA   -> TCB   
 L R9,TCBJSCB-TCB(,R9)  -> JSCB 
 L R9,JSCBPSCB-IEZJSCB(,R9) -> PSCB 
 USING PSCB,R9   
 L R8,PSCBRLGB   -> RELOGON BUFFER   
 L R8,RLGBECT-RLGB(,R8)  -> ECT  
 USING ECT,R8  

 IHAPSA ,
 IKJTCB ,   
 IEZJSCB ,   
 IKJPSCB ,
 IKJRLGB ,  
 IKJECT ,

On Thu, 25 Feb 2016 19:57:22 -0600 Anthony Fletcher 
wrote:

:>When running a TSO program it requires a CPPL. When TSO is started by using 
the TMP, a CPPL is provided, and it can be accessed.
:>One of the fields that is a supported programming interface is the ECT 
(Environment Control Table), and it can be updated.
:>
:>If a program or command is indirectly invoked eg from ISPF then the CPPL  may 
not be directly available and so will have to be constructed. One of the fields 
required in the CPPL is the ECT.
:>
:>For many many years it so happened that the ECT pointer was 8 bytes back from 
the UPT, so code like the following could be used to find the ECT pointer and 
store it in the CPPLECT field.
:>
:>L R1,X'21C'   POINT TO TCB
:>
:> ICM   R1,7,X'0B5'(R1) POINT TO JSCB 
:>
:> L R1,X'108'(,R1)  POINT TO PSCB 
:>
:> STR1,CPPLPSCB SAVE PSCB POINTER 
:>
:> L R1,X'034'(,R1)  POINT TO UPT  
:>
:> STR1,CPPLUPT  SAVE UPT POINTER  
:>
:> LAR1,0(,R1)   CLEAR HIGH ORDER BYTE 
:>
:> SHR1,=H'8'ASSUME ECT POINTER AT UPT - 8 
:>
:> MVC   CPPLECT,0(R1)   PICK UP ECT POINTER 
:>
:>With the application of the following PTFs, for the z/OS 2.1 system at least, 
this no longer works.
:>UA80338 UA80339 UA80340  (which ever is appropriate for the z/OS version).
:>For some reason it still works with the z/OS 1.13 version.
:>These are security/integrity fixes, hence the APAR is not shown. 
:>These PTFs are unlikely to be marked PE, so users that have old assembler 
programs should check to see whether any of them use this method of locating 
the ECT.
:>In the case of z/OS 1.13 which did not abend, it may have found storage that 
it wsa allowed to address but it may not be a real ECT, and so an overlay may 
occur. Future maintenance to TMP modules may well cause the ECT to be in a 
different location to what it has been in for 25-30 years so it is advisable to 
check any assembler programs that might be using this technique and change to 
using the correct method.
:>
:>Documented way is this:  
:>
:>The URLs are not hyperlinks so they have to be pasted into a 
browser. The fact that the documents are for z/OS 2.2 does not matter the steps 
are applicable to z/OS 1.13 and z/OS 2.1.   
 
:>
:>ECT: 
:>
:>-
:>
:>http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v 
:>
:>2r2.ikjd200/ikjd200100.htm?lang=en   
:>
:> 
:>
:>Pointed to by:   
:>
:>CPPLECT field of the CPPL
:>
:>TPLECT field of the TPL  
:>
:>LWAPECT field of the LWA 
:>
:> 
:>
:>LWA: 
:>
:>-
:>
:>http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v 
:>
:>2r2.ikjd200/ikjd200292.htm?lang=en   
:>
:> 
:>
:>Pointed to by:   
:>
:>ASXBLWA field of the ASXB
:>
:>JSXL communication field of the JSXL 
:>
:> 
:>
:>ASXB:
:>
:>---  
:>
:>http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v 
:>
:>2r2.iead100/iead10094.htm?lang=en 

Re: Prefix save area - confused

2016-02-25 Thread 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: IBM-MAIN and what it is for

2016-02-25 Thread Elardus Engelbrecht
Peter Hunkeler wrote:

>
One of the unwritten rules, at least in my understanding: Tell who you are!
Two ways to do this: Use an email address that shows your name, or, preferably, 
sign your post with your name, first name at least.
>

Very true! I tend to help people who are NOT anonymous.

From: http://catb.org/esr/faqs/smart-questions.html this little gem to all 
these anonymous posters :

"... don't expect to be treated like a fragile doll just because you're a 
newcomer with a theatrically hypersensitive soul and delusions of entitlement."

... 'nuff said!

Groete / Greetings
Elardus Engelbrecht

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


Re: Prefix save area - confused

2016-02-25 Thread Jim Mulder
> 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


Re: VSAM file not extending to new volume

2016-02-25 Thread Vernooij, CP (ITOPT1) - KLM
This reminds me of an ISMF problem I has last year: did you do some updates to 
the dataclass definitions.
Search the archives for: Heads up: ISMF error using the EOF key.
It was solved by PTF UA77758, available in aug 2015.
Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Shirey
Sent: 25 February, 2016 18:50
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VSAM file not extending to new volume

Hmm, thanks for that.  It looks like the EA value was NO instead of YES.  
I'll have to figure out how that happened.

Greg 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, February 25, 2016 11:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VSAM file not extending to new volume

Check for this in your data class
DATA CLASS DISPLAY   Page 2 of 5
   
 CDS Name  . . . . . : ACTIVE  
 Data Class Name . . : DIRECT   
 
   
 Data Set Name Type  . . . . . : EXTENDED  
   If Extended . . . . . . . . : REQUIRED  
   Extended Addressability . . : YES
   Record Access Bias  . . . . : USER  
 Space Constraint Relief . . . : NO
--



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

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

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




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


Re: Prefix save area - confused

2016-02-25 Thread 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: Prefix save area - confused

2016-02-25 Thread Robert Hahne
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


Re: IBM-MAIN and what it is for

2016-02-25 Thread Peter Hunkeler
To ibmmain.10.ats...@xoxy.net, and other anonymous posters


One of the unwritten rules, at least in my understanding: Tell who you are!
Two ways to do this: Use an email address that shows your name, or, preferably, 
sign your post with your name, first name at least.





--
Peter Hunkeler


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


Re: IBM-MAIN and what it is for

2016-02-25 Thread ibmmain . 10 . atsjbt
On 25 Feb 2016 18:19:15 -0800, in bit.listserv.ibm-main 
(Message-ID:<8702884056351431.wa.fletchanz1.ibm@listserv.ua.edu>) 
flet...@nz1.ibm.com (Anthony Fletcher) wrote:


Like all 'LISTS' the members are there to provide or 
solicit information, and it is like a club.


I agree with much of what you wrote.

One of the fundamental assumptions is that before posting 
a request for help the poster will have done as much as 
they  possibly can to find the answer, and then post the 
question with documentation of what they have done and why 
they are in need of help.


I think that's a bit strong.  If you replace your "possibly 
can" with "reasonably can" I think it's closer to the 
truth.


This was not written for mainframers, but almost everything 
in it is applicable to IBM-Main:

How to ask questions the smart way:
http://catb.org/esr/faqs/smart-questions.html

Finally, there's one good way to get people to want to help 
you on this list: show that you're willing to help other 
people on this list.  


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


Re: IPCS

2016-02-25 Thread Ed Jaffe

On 2/25/2016 4:54 PM, Jesse 1 Robinson wrote:

I'm getting into IPCS with no IPCSPARM DD allocated according to both ISRDDN 
and LISTALC.


If you pre-allocate IPCSPARM, it will be used. If you don't, the system 
parmlib concatenation will be used.


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

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


IBM-MAIN and what it is for

2016-02-25 Thread Anthony Fletcher
Like all 'LISTS' the members are there to provide or solicit information, and 
it is like a club.
Responding to posts to a list is seldom part of a job description.

There are rules for membership of the club. They may not be written down, but 
they do exist, and some have to be discovered by trial and error.
One of the fundamental assumptions is that before posting a request for help 
the poster will have done as much as they  possibly can to find the answer, and 
then post the question with documentation of what they have done and why they 
are in need of help.
Posting an error message and asking what it means without further investigation 
is vastly different from posting a message with all the fields and some 
information about what happened before the message appeared,

Unfortunately, some of the people that have joined the list recently seem to 
think that it is a replacement for a vendor support channel, and they don't 
provide nearly enough information. This just wastes the time of the people who 
are prepared to respond, and in the end they will just not respond unless they 
know what what they advise or recommend will use that information, and 
inevitably posters will get to be known by name.

Posting a question or request for help to any list, but in this case to 
IBM-MAIN, does not entitle the poster to a response. If a person's posts just 
cause irritation, then they will not get a response, or if they do get a 
response and they ignore that response and continue to come back with the same 
question or request.

In other words, if someone wants to learn from the experience of other people 
then need to respect those other people and not waste their time. Its not a 
question of whether someone works for an outsourcer or not, its a question of 
professional integrity. Two sides to that, someone wanting to learn must use 
published documentation of it they are able, go to courses. The potential 
responder needs to recognise that there is a problem at the moment around the 
world where the number of professionally responsible people is dwindling, and 
the incomers can't  instantly learn what has taken 25 years to accumulate.

And I am not going to comment on the irresponsible management class that got 
things into this potential mess.

End of rant!

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


z/OS unsupported programming practice - Finding TSO ECT

2016-02-25 Thread Anthony Fletcher
When running a TSO program it requires a CPPL. When TSO is started by using the 
TMP, a CPPL is provided, and it can be accessed.
One of the fields that is a supported programming interface is the ECT 
(Environment Control Table), and it can be updated.

If a program or command is indirectly invoked eg from ISPF then the CPPL  may 
not be directly available and so will have to be constructed. One of the fields 
required in the CPPL is the ECT.

For many many years it so happened that the ECT pointer was 8 bytes back from 
the UPT, so code like the following could be used to find the ECT pointer and 
store it in the CPPLECT field.

L R1,X'21C'   POINT TO TCB

 ICM   R1,7,X'0B5'(R1) POINT TO JSCB 

 L R1,X'108'(,R1)  POINT TO PSCB 

 STR1,CPPLPSCB SAVE PSCB POINTER 

 L R1,X'034'(,R1)  POINT TO UPT  

 STR1,CPPLUPT  SAVE UPT POINTER  

 LAR1,0(,R1)   CLEAR HIGH ORDER BYTE 

 SHR1,=H'8'ASSUME ECT POINTER AT UPT - 8 

 MVC   CPPLECT,0(R1)   PICK UP ECT POINTER 

With the application of the following PTFs, for the z/OS 2.1 system at least, 
this no longer works.
UA80338 UA80339 UA80340  (which ever is appropriate for the z/OS version).
For some reason it still works with the z/OS 1.13 version.
These are security/integrity fixes, hence the APAR is not shown. 
These PTFs are unlikely to be marked PE, so users that have old assembler 
programs should check to see whether any of them use this method of locating 
the ECT.
In the case of z/OS 1.13 which did not abend, it may have found storage that it 
wsa allowed to address but it may not be a real ECT, and so an overlay may 
occur. Future maintenance to TMP modules may well cause the ECT to be in a 
different location to what it has been in for 25-30 years so it is advisable to 
check any assembler programs that might be using this technique and change to 
using the correct method.

Documented way is this:  

The URLs are not hyperlinks so they have to be pasted into a 
browser. The fact that the documents are for z/OS 2.2 does not matter the steps 
are applicable to z/OS 1.13 and z/OS 2.1.   
 

ECT: 

-

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v 

2r2.ikjd200/ikjd200100.htm?lang=en   

 

Pointed to by:   

CPPLECT field of the CPPL

TPLECT field of the TPL  

LWAPECT field of the LWA 

 

LWA: 

-

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v 

2r2.ikjd200/ikjd200292.htm?lang=en   

 

Pointed to by:   

ASXBLWA field of the ASXB

JSXL communication field of the JSXL 

 

ASXB:

---  

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v 

2r2.iead100/iead10094.htm?lang=en

 

Pointed to by:   

ASCBASXB 

 

ASCB:

---  

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v 

2r2.iead100/iead10059.htm?lang=en

 

Pointed to by:   


Re: Outsourcing Stories Good or Bad!

2016-02-25 Thread 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: Outsourcing Stories Good or Bad!

2016-02-25 Thread Farley, Peter x23353
To me, the most important thing that is lost in outsourcing is the friendly 
call  or deskside chat between a curious/puzzled application programmer and a 
cooperative/knowledgeable systems staff person.  In my applications career I 
have always made it a particular point to be polite and friendly with the 
systems staff and to cultivate their good opinion of me, since they were 
usually far more senior in experience and knowledge than I was.  I also tried 
to learn from them and not make the same dumb mistake more than once (OK, maybe 
twice . . . :).

Outsourced systems staff means formal and tightly controlled contact 
procedures, prioritized question/research lists, where outsourced projects like 
hardware and software upgrades mean application questions and puzzles get very 
short shrift and low priority, if indeed they ever get answered at all.  
Eventually the questions are directed elsewhere (like to this list), or they 
just do not get answered at all because they are never asked.

As a senior applications developer now I get some of the questions and puzzles 
from other application programmers, even from some of my peers in seniority and 
experience, because no one person knows it all.  The loss of those informal 
communications channels with the systems staff is IMHO a serious loss to the 
corporation as well as to the individual programmers.

But what do I know, I'm just a programmer, not a manager.  The only time I 
count beans is for chile con carne.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Wilson
Sent: Wednesday, February 24, 2016 5:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Outsourcing Stories Good or Bad!

I am working with a client in Europe that is being requested by his senior 
management team to look at outsourcing their IT systems, including their system 
z platform.

Would anyone be willing to share any war stories of their experiences with 
Outsourcing good or bad?

Offline from the list via email or for anyone attending Share in Texas willing 
to have a coffee/beer and discuss face to face.

Mark

--


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


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


Re: IPCS

2016-02-25 Thread Jesse 1 Robinson
I'm getting into IPCS with no IPCSPARM DD allocated according to both ISRDDN 
and LISTALC. Maybe that was required for the ancient dump-management facility?

.
.
.
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
jesse1.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jim Mulder
Sent: Thursday, February 25, 2016 11:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IPCS

> > What are the risks of giving [IPCS] access to developers?
> 
> Mostly, you risk them learning and understanding more about our 
> platform
> -- and post-mortem debugging -- than they did previously.
> 
> IIRC, IPCS requires READ access to parmlib. If that's an issue, I 
> believe it might be possible to create a stand-alone parmlib just for 
> IPCS use.

  If the IPCSPARM ddname is allocated. that is what IPCS will use for accessing 
parmlib members. If IPCSPARM is not allocated, IPCS will use the system's 
parmlib concatenation.

  IPCS needs the parmlib members which IBM provides.  Typically, these are 
found on the sysres volume in a data set named SYS1.IBM.PARMLIB (or some 
similar name chosen by the systems programmer). 

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


Re: Outsourcing Stories Good or Bad!

2016-02-25 Thread Savor, Thomas (Alpharetta)
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


Re: Outsourcing Stories Good or Bad!

2016-02-25 Thread Ed Gould

On Feb 25, 2016, at 2:51 PM, Sankaranarayanan, Vignesh wrote:

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


- 
SNIP---


Then have your employer pop for education because that is how *WE*  
did it.
I don't have an issue of answering questions but it is NOT a one way  
street.
Go to SHARE (or your area equivalence). In years past I have paid for  
my OWN trip to GUIDE/SHARE out of my own pocket.
Have you done the same. It occurs to me that you see IBM-MAIN as a  
one way street, it isn't its a group and we all contribute not just  
ask questions.


Ed

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


Re: Tritus SPF again

2016-02-25 Thread Field, Alan
Look for vDOS. It is based on DOSBOX and I think a better 16bit emulator, 
especially for something like this.

 https://www.vdos.info/

Alan Field
Systems Engineer Principal
Blue Cross Blue Shield of MN

651.662.3546


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richard Pinion
Sent: Thursday, February 25, 2016 4:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Tritus SPF again

I received my USB 3.5 inch diskette drive today.  I copied the contents of the 
diskette to my SSD, and tried to execute TSPF.EXE.  It didn't work because it 
is a 16 bit application.  Googled a little, and found DOSBOX.
Downloaded and installed DOSBOX.  Executed DOSBOX, and I am able to execute 
TSPF!

I'm out $19 just for the sake of being able to do this.  Still have those
5.25 diskettes.  I'm not sure if they contain the same thing, lower level, or 
higher level of TSPF.  I got a few offers from people to copy the
5.25 diskettes, but I didn't keep those emails.  If you're one of them, please 
contact me offlist, rpinion at netscape dot com, if the offer is still open.

Thanks in advance.



_
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


This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the named addressee you must not disseminate, distribute or copy 
this e-mail. Please notify the sender immediately by e-mail if you have 
received this e-mail by mistake and delete this e-mail from your system. If you 
are not the intended recipient you are notified that disclosing, copying, 
distributing or taking any action in reliance on the contents of this 
information is strictly prohibited.


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


Re: Tritus SPF again

2016-02-25 Thread Tom Brennan
Nice!  I ordered a 3.5 drive too and went through my pile of old disks 
looking for anything I should try to copy once it arrives.  Thanks for 
the DOSBOX hint, maybe I can install my old Lemmings game disk and pick 
up where I left off in 1993.


And I have a 1991 CTC SPF/2 3.5" disk which should be interesting. 
Don't know if that's related to TSPF.


Richard Pinion wrote:

I received my USB 3.5 inch diskette drive today.  I copied the contents
of the diskette to my SSD, and tried to execute TSPF.EXE.  It didn't work
because it is a 16 bit application.  Googled a little, and found DOSBOX.
Downloaded and installed DOSBOX.  Executed DOSBOX, and I am able to 
execute TSPF!


I'm out $19 just for the sake of being able to do this.  Still have those
5.25 diskettes.  I'm not sure if they contain the same thing, lower level,
or higher level of TSPF.  I got a few offers from people to copy the
5.25 diskettes, but I didn't keep those emails.  If you're one of them,
please contact me offlist, rpinion at netscape dot com, if the offer is
still open.

Thanks in advance.



_
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


Tritus SPF again

2016-02-25 Thread Richard Pinion
I received my USB 3.5 inch diskette drive today.  I copied the contents
of the diskette to my SSD, and tried to execute TSPF.EXE.  It didn't work
because it is a 16 bit application.  Googled a little, and found DOSBOX.
Downloaded and installed DOSBOX.  Executed DOSBOX, and I am able to 
execute TSPF!

I'm out $19 just for the sake of being able to do this.  Still have those
5.25 diskettes.  I'm not sure if they contain the same thing, lower level,
or higher level of TSPF.  I got a few offers from people to copy the
5.25 diskettes, but I didn't keep those emails.  If you're one of them,
please contact me offlist, rpinion at netscape dot com, if the offer is
still open.

Thanks in advance.



_
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


An ISPF Editor RFE to vote for (or not...)

2016-02-25 Thread Robert Prins
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=84517

Description:


It is possible to limit both the "width" and "depth" of the ISPF editor
F(ind), C(jange) and (e)X(clude) commands, by specifying bounds and labels.

Of these two, the bounds ("width") can be set using the "BOUNDS" primary
and/or "BNDS" line commands, and once set it will remain in force until
changed.

However, there is no mechanism to limit the operation of the above commands
for a "depth" range, other than to specify the line-labels on which the
commands need to operate again and again, or eXclude all lines not of
interest and use the NX operand of the above commands.

What is proposed is that an additional Edit/View command is added that
allows the user to set the vertical bounds to two user-defined labels, as
in "VB(ound) .a .b". All subsequent Find. Change. and eXclude commands
would then be limited to operating on just the lines between inclusive the
.A and .B labels, without the user having to respecify them over and over
again.

A "VB(ound) RES(et)" would reset this mode, as would the "RES(et) LAB(el)"
command, or even the "RES(et)" command all by itself.

Use case:
=

It's pretty common to perform a number of Find, Change and/or eXclude
commands on a small set of lines in the editor. The addition of the
proposed "VB(ound)" command would make it easier to perform these
operations without having to respecify the range over and over again.

Robert
-- 
Robert AH Prins
robert.ah.pr...@gmail.com

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


Re: SMP/E and STRIPSECT? (was: ... INCLUDE only when necessary)

2016-02-25 Thread Paul Gilmartin
On Thu, 25 Feb 2016 15:19:59 -0600, Barry Lichtenstein wrote:
>> 
>> Does SMP/E respect STRIPSEC?  Does it cause no problems, e.g. with
>> RESTORE?  How might it interact with the "++MOD(...) CSECT(...)"
>> argument?
>
>Can't really blame SMP/E for accumulating them, that's the binders fault.  For 
>a given section name, it quietly deletes same-named duplicates it finds (if 
>any), so for an unnamed section it has no handle.
>
>Since SMP/E does not document recognizing STRIPSEC on the JCLIN PARM, I expect 
>it would be ignored (you might get away with using SETOPT if you really had 
>some need for this).
>
>I would hope however that modules are not shipped which contain unnecessary 
>unnamed sections!  Though sometimes unreferenced sections, named or not, are 
>there for a reason and should not be removed.
>
ISTR Pascal makes them.  Hardly relevant nowadays.

>That said I don't think SMP/E could care about unnamed sections, only ones 
>that it can have been told the names of.
>
And, now that I think about it, STRIPSEC is probably pernicious for SMP/E.
SMP/E sometimes includes MOD elements from the target zone, and if
they have been stripped desired results will not occur.

In fact, for some searches the target zone is first in the search order.
I consider this a bad design.  SMP/E should search the DLIB zone and
the GLOBAL zone and fail if the element is not found there; never
search the target zone.

-- gil

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

2016-02-25 Thread Lucas Rosalen
I have always worked for the Outsourcerer-IBM (which is different than
working for "the real" IBM), so I might have some points to bring in:

- Best scenario I've worked was for a customer that kept 1 key-person for
each area (z/OS, DB2, etc.). This person would bring historical knowledge,
technical knowledge and sense of urgency depending on the situation. Weekly
checkpoint meetings kept the teams aligned with what the customer desired;

- SLAs MUST be carefully reviewed and agreed. Both sides could and WILL use
it "against" the other side. If SLA is met, then no problem, no matter
what's going on. Short-term contracts (3-5 years instead of 10-15 years)
allow for a better SLA adjustment down the road;

- There MUST be some sort of responsibility matrix with DETAILED activites
(generic activites like "maintain systems" are too broad). Just by looking
at this matrix, you should be able to tell: who's responsible for doing X?
who's to be informed about X? who should be consulted if doing X?;

- Outsourcers will probably request a lot of documentation (that in-house
companies probably don't even have). This is vital! Part of the issues that
might come could be avoided with a good documentation to start with;

- Projects (processor upgrade, OS upgrade, router replacements, etc.) will
most likely be treated like so (PROJECTS). Which means that probably a
Project Manager will have to be involved to make teams talk to each other.
Some overhead in these activities have to be considered;

There are good and there are bad people working on outsourcerers, but I
*guess* this is everywhere though, so no news.
Where I worked, people tend to "standardize" the systems the most they can
after transition has stabilized. This means the less exits, the better.
Keep in mind the outsourcerer might have many clients and when someone gets
called in the middle of the night it might be hard to remember the
peculiarities of one of them.
On the other hand teams are usually able to compare cross-customers
solutions and propose enhancements should they apply.

Hope this helps a bit.

Regards,

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


2016-02-25 18:00 GMT-03:00 Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR) <
z...@cdc.gov>:

> I'm not going to judge anyone here - but I have always had the attitude
> that if someone wants Mainframe help and I can help them - I am going to
> help them.   I would never have learned half of what I know after almost 30
> years in IT without others taking the time to answer a question or two (or
> MANY) over the years.   And I for one have learned a great deal just
> monitoring these emails that come out on IBM-MAIN every day.  I have a
> folder of probably 500 emails I have kept over the years - and I still
> access them occasionally to fix a problem, etc...  There is a great deal of
> knowledge on this forum and I for one am very appreciate of the help I have
> received over the years - and I have also been glad to offer assistance
> here and there where I can.
>
> -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
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ed Gould
> Sent: Friday, Feb 26, 2016 1:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Outsourcing Stories Good or Bad!
>
> On Feb 25, 2016, at 12:54 PM, Sankaranarayanan, Vignesh wrote:
>
> > Some thoughts from someone on the other side.
> >
> > What's the point of saying "Oh, I'm an outsourced nobody." in a post
> > where one is asking for help. So you may choose to not answer or sit
> > on your high horse and ridicule their incompetence when they're
> > struggling?
> > If you guys (actual mainframe folk with decades of background) are
> > going to compare outsourced folk vs yourselves, you're doing it wrong.
> > Most of your outsourced folk are younger than the total experience you
> > may have. Of course they're going to be inferior.
> > Do you call a baby rubbish because it can't write a 

Re: SMP/E and STRIPSECT? (was: ... INCLUDE only when necessary)

2016-02-25 Thread Barry Lichtenstein
On Tue, 23 Feb 2016 10:36:16 -0600 Paul Gilmartin wrote:

> Oooh!  Neat!  Thanks.  And I see:
> 
> z/OS MVS Program Management: User's Guide and Reference
> SA23-1393-00 
> 
> STRIPSEC={PRIV|YES | NO}
> STRIPSEC=PRIV
> Specifies that unreferenced unnamed sections are to be removed. 
> 
> This addresses a misbehavior of SMP/E which secularly piles up private
> sections (Which I think are something programmers should avoid anyway.
> But Pascal reportedly dotes on them.)
> 
> Note: For a section to be considered unreferenced, it must:
> ...
> Not be the target of a control statement
> (Such as ORDER?)
> 
> Does SMP/E respect STRIPSEC?  Does it cause no problems, e.g. with
> RESTORE?  How might it interact with the "++MOD(...) CSECT(...)"
> argument?
> 
> Thanks again,
> gil

Can't really blame SMP/E for accumulating them, that's the binders fault.  For 
a given section name, it quietly deletes same-named duplicates it finds (if 
any), so for an unnamed section it has no handle.

Since SMP/E does not document recognizing STRIPSEC on the JCLIN PARM, I expect 
it would be ignored (you might get away with using SETOPT if you really had 
some need for this).

I would hope however that modules are not shipped which contain unnecessary 
unnamed sections!  Though sometimes unreferenced sections, named or not, are 
there for a reason and should not be removed.

That said I don't think SMP/E could care about unnamed sections, only ones that 
it can have been told the names of.

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

2016-02-25 Thread Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR)
I'm not going to judge anyone here - but I have always had the attitude that if 
someone wants Mainframe help and I can help them - I am going to help them.   I 
would never have learned half of what I know after almost 30 years in IT 
without others taking the time to answer a question or two (or MANY) over the 
years.   And I for one have learned a great deal just monitoring these emails 
that come out on IBM-MAIN every day.  I have a folder of probably 500 emails I 
have kept over the years - and I still access them occasionally to fix a 
problem, etc...  There is a great deal of knowledge on this forum and I for one 
am very appreciate of the help I have received over the years - and I have also 
been glad to offer assistance here and there where I can.  

-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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Gould
Sent: Friday, Feb 26, 2016 1:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Outsourcing Stories Good or Bad!

On Feb 25, 2016, at 12:54 PM, Sankaranarayanan, Vignesh wrote:

> Some thoughts from someone on the other side.
>
> What's the point of saying "Oh, I'm an outsourced nobody." in a post 
> where one is asking for help. So you may choose to not answer or sit 
> on your high horse and ridicule their incompetence when they're 
> struggling?
> If you guys (actual mainframe folk with decades of background) are 
> going to compare outsourced folk vs yourselves, you're doing it wrong.
> Most of your outsourced folk are younger than the total experience you 
> may have. Of course they're going to be inferior.
> Do you call a baby rubbish because it can't write a sonnet? Yes, the 
> baby has no business writing sonnets but welcome to the world of 
> outsourcing.
>
> When deciding to outsource, your employer has chosen money over the 
> people who have served him/her for a long time.
> Don't take out your anger and disgust on people who are struggling to 
> better themselves because they have massive shoes to fill.
> It's not his/her action that has led to you being laid off and being 
> forced to accept ridiculous things (train or you don't get your 401k 
> or whatever) in your last hours (on the job).
>
> That said, here's some actual feedback which may not be possible to 
> implement at all though:
> 1. Exercise as many choices as you must to ensure you do not suffer.
> Try as hard as you can to not accept people who can't speak basic 
> English.
> The big man at the outsourcer may not leave that choice to you but 
> trust me, this is the root of all the abscess that you're
> (employer) being charged for.
> "This guy can't speak, so let's make him work under some 15,000 
> managers who repeat the same thing without adding value."
> Oh, and BTW, these managers are paid a f*k load more than the people 
> working, I would assume.
>
> 2. Offshoring development, IMHO, is the worst thing you can do.
> You want your company to work on code that's written by someone who's 
> knowledge is extremely limited, and someone who would keep trying to 
> nail everything because he has a hammer?
>
> 3. If you are able to pick the right (technical) people, keep the 
> overhead (hey, if we're "resources", what's above us ought to be 
> "overhead" right?) to an extreme minimum.
>
> Who knows, some day Watson may make the whole industry go away and one 
> machine may manage the other. At that point, you get to say "Ha! No 
> more of these 'incompetent masses'".
>
> - Vignesh
> Mainframe Infrastructure

> --SNIP--

Then why should we provide expertise for free?
We all learned the hard way with no IBM-MAIN at beck and call.
We developed our own word of mouth partners. You should be doing the same.

Ed

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422

Re: Outsourcing Stories Good or Bad!

2016-02-25 Thread Sankaranarayanan, Vignesh
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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Gould
Sent: Friday, Feb 26, 2016 1:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Outsourcing Stories Good or Bad!

On Feb 25, 2016, at 12:54 PM, Sankaranarayanan, Vignesh wrote:

> Some thoughts from someone on the other side.
>
> What's the point of saying "Oh, I'm an outsourced nobody." in a post
> where one is asking for help. So you may choose to not answer or sit
> on your high horse and ridicule their incompetence when they're
> struggling?
> If you guys (actual mainframe folk with decades of background) are
> going to compare outsourced folk vs yourselves, you're doing it wrong.
> Most of your outsourced folk are younger than the total experience you
> may have. Of course they're going to be inferior.
> Do you call a baby rubbish because it can't write a sonnet? Yes, the
> baby has no business writing sonnets but welcome to the world of
> outsourcing.
>
> When deciding to outsource, your employer has chosen money over the
> people who have served him/her for a long time.
> Don't take out your anger and disgust on people who are struggling to
> better themselves because they have massive shoes to fill.
> It's not his/her action that has led to you being laid off and being
> forced to accept ridiculous things (train or you don't get your 401k
> or whatever) in your last hours (on the job).
>
> That said, here's some actual feedback which may not be possible to
> implement at all though:
> 1. Exercise as many choices as you must to ensure you do not suffer.
> Try as hard as you can to not accept people who can't speak basic
> English.
> The big man at the outsourcer may not leave that choice to you but
> trust me, this is the root of all the abscess that you're
> (employer) being charged for.
> "This guy can't speak, so let's make him work under some 15,000
> managers who repeat the same thing without adding value."
> Oh, and BTW, these managers are paid a f*k load more than the people
> working, I would assume.
>
> 2. Offshoring development, IMHO, is the worst thing you can do.
> You want your company to work on code that's written by someone who's
> knowledge is extremely limited, and someone who would keep trying to
> nail everything because he has a hammer?
>
> 3. If you are able to pick the right (technical) people, keep the
> overhead (hey, if we're "resources", what's above us ought to be
> "overhead" right?) to an extreme minimum.
>
> Who knows, some day Watson may make the whole industry go away and one
> machine may manage the other. At that point, you get to say "Ha! No
> more of these 'incompetent masses'".
>
> - Vignesh
> Mainframe Infrastructure

> --SNIP--

Then why should we provide expertise for free?
We all learned the hard way with no IBM-MAIN at beck and call.
We developed our own word of mouth partners. You should be doing the same.

Ed

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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

2016-02-25 Thread Ed Gould

On Feb 25, 2016, at 12:54 PM, Sankaranarayanan, Vignesh wrote:


Some thoughts from someone on the other side.

What's the point of saying "Oh, I'm an outsourced nobody." in a  
post where one is asking for help. So you may choose to not answer  
or sit on your high horse and ridicule their incompetence when  
they're struggling?
If you guys (actual mainframe folk with decades of background) are  
going to compare outsourced folk vs yourselves, you're doing it wrong.
Most of your outsourced folk are younger than the total experience  
you may have. Of course they're going to be inferior.
Do you call a baby rubbish because it can't write a sonnet? Yes,  
the baby has no business writing sonnets but welcome to the world  
of outsourcing.


When deciding to outsource, your employer has chosen money over the  
people who have served him/her for a long time.
Don't take out your anger and disgust on people who are struggling  
to better themselves because they have massive shoes to fill.
It's not his/her action that has led to you being laid off and  
being forced to accept ridiculous things (train or you don't get  
your 401k or whatever) in your last hours (on the job).


That said, here's some actual feedback which may not be possible to  
implement at all though:
1. Exercise as many choices as you must to ensure you do not  
suffer. Try as hard as you can to not accept people who can't speak  
basic English.
The big man at the outsourcer may not leave that choice to you but  
trust me, this is the root of all the abscess that you're  
(employer) being charged for.
"This guy can't speak, so let's make him work under some 15,000  
managers who repeat the same thing without adding value."
Oh, and BTW, these managers are paid a f*k load more than the  
people working, I would assume.


2. Offshoring development, IMHO, is the worst thing you can do.
You want your company to work on code that's written by someone  
who's knowledge is extremely limited, and someone who would keep  
trying to nail everything because he has a hammer?


3. If you are able to pick the right (technical) people, keep the  
overhead (hey, if we're "resources", what's above us ought to be  
"overhead" right?) to an extreme minimum.


Who knows, some day Watson may make the whole industry go away and  
one machine may manage the other. At that point, you get to say  
"Ha! No more of these 'incompetent masses'".


– Vignesh
Mainframe Infrastructure



--SNIP--


Then why should we provide expertise for free?
We all learned the hard way with no IBM-MAIN at beck and call.
We developed our own word of mouth partners. You should be doing the  
same.


Ed

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

2016-02-25 Thread Chris Hoelscher
Whatever outsourcer is selected - have your SLA be as detailed as possible and 
include major penalties for non-compliance ...

A long long time ago in a data center far far away ... I was consulting to a 
outsourcing firm - they had control of a LARGE datacenter - at some point 
something happened (I honestly don’t remember what) - the clients were 
noticeably limping along - but at a level that met SLA - the outsourcer HAD a 
solution , but would have required an outage (IPL?) - which would have caused 
an SLA violation - so because degraded service was contractually acceptable, 
the clients limped along for some time ...

The mantra we were told (in essence) was ...

We don’t care if you NEVER do anything RIGHT, as long as you DON'T do anything 
WRONG

It seemed the  SLA was written that the benefits of success were far outweighed 
by the risks of failure

So YOU, the client, make sure that YOU set the Service Level you expect nay 
DEMAND and don’t let the outsourcers off the hook with a substandard SLA



Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538



The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.


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


Re: Knowing GEN level

2016-02-25 Thread Chris Hoelscher
And keep in mind that what is in your TARGET zone is in no way (hopefully) tied 
to your runtime environment
In the past - I have used different solutions for different products 
DB2 has a utility command MEPL to provide this information
For other products I use AMBLIST  with LISTIDR can return module information 
such as PTF# imbedded in the IDR space

Other products may have other proprietary fix tracking tools ... (Lizette is 
correct as always)


Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538

N

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.


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

2016-02-25 Thread Stone, Sandy
Where’s the 'like' button?
:-)
s



http://www.medmutual.com/
Visit http://www.medmutual.com/
CONFIDENTIALITY NOTICE:
This message is intended only for the use of the individual or entity to which 
it is addressed and may contain information that is privileged, confidential or 
exempt from disclosure by law. If the reader of this message is not the 
intended recipient, or the employee or agent responsible for delivering the 
message to the intended recipient, you are hereby notified that you are 
strictly prohibited from printing, storing, disseminating, distributing or 
copying this message. If you have received this message in error, please notify 
us immediately by replying to the message and deleting it from your computer. 
Neither this information block, the typed name of the sender, nor anything else 
in this message is intended to constitute an electronic signature, unless a 
specific statement to the contrary is included in this message.
Thank you, Medical Mutual.

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

Some thoughts from someone on the other side.

What's the point of saying "Oh, I'm an outsourced nobody." in a post where one 
is asking for help. So you may choose to not answer or sit on your high horse 
and ridicule their incompetence when they're struggling?
If you guys (actual mainframe folk with decades of background) are going to 
compare outsourced folk vs yourselves, you're doing it wrong.
Most of your outsourced folk are younger than the total experience you may 
have. Of course they're going to be inferior.
Do you call a baby rubbish because it can't write a sonnet? Yes, the baby has 
no business writing sonnets but welcome to the world of outsourcing.

When deciding to outsource, your employer has chosen money over the people who 
have served him/her for a long time.
Don't take out your anger and disgust on people who are struggling to better 
themselves because they have massive shoes to fill.
It's not his/her action that has led to you being laid off and being forced to 
accept ridiculous things (train or you don't get your 401k or whatever) in your 
last hours (on the job).

That said, here's some actual feedback which may not be possible to implement 
at all though:
1. Exercise as many choices as you must to ensure you do not suffer. Try as 
hard as you can to not accept people who can't speak basic English.
The big man at the outsourcer may not leave that choice to you but trust me, 
this is the root of all the abscess that you're (employer) being charged for.
"This guy can't speak, so let's make him work under some 15,000 managers who 
repeat the same thing without adding value."
Oh, and BTW, these managers are paid a f*k load more than the people working, I 
would assume.

2. Offshoring development, IMHO, is the worst thing you can do.
You want your company to work on code that's written by someone who's knowledge 
is extremely limited, and someone who would keep trying to nail everything 
because he has a hammer?

3. If you are able to pick the right (technical) people, keep the overhead 
(hey, if we're "resources", what's above us ought to be "overhead" right?) to 
an extreme minimum.

Who knows, some day Watson may make the whole industry go away and one machine 
may manage the other. At that point, you get to say "Ha! No more of these 
'incompetent masses'".

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, Feb 25, 2016 12:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Outsourcing Stories Good or Bad!

On Wed, 24 Feb 2016 10:31:14 +, Mark Wilson wrote:

>I am working with a client in Europe that is being requested by his
>senior management team to look at outsourcing their IT systems,
>including their system z platform.
>
>Would anyone be willing to share any war stories of their experiences
>with Outsourcing good or bad?

There has been considerable evidence of outsourcing to incompetent companies on 
IBM-Main lately. They don't say that they are outsourcers, but in the last few 
days there have been threads from people who hadn't a clue what they were 
doing. My guess is that they are outsourcers. Two that come to mind are the 
thread on a DASD device not going offline, and one about Applying a PTF to
DB2 10.

--
Tom Marchant

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in 

Re: Issues with VSAM Enqueuers and Batch job with IDCAMS

2016-02-25 Thread DiBianca, Robert
Lizette,
I've see the same type of problem with a VSAM file in our scheduler as well.  
It can be open to people looking at job history and thus, we have problems 
reloading it.

We received an IEC161I message to SYSLOG - so, I wrote some automation to take 
the dataset name from the error message and issue a D GRS command against the 
dataset (d grs,res=(sysdsn,dsname.here)).   Some of our applications have had 
similar issues with VSAM files - and this automation helped them determine who 
caused their abends.

Robert DiBianca

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, February 15, 2016 11:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Issues with VSAM Enqueuers and Batch job with IDCAMS

I have an issue where an STC holds a VSAM Dataset.  The STC is a scheduling 
software that writes all of the info on jobs running/completed/failed and so 
forth, to this file.

Once per day we close and free the VSAM file from the STC, run an archive 
process and then re-open then file to the STC.

This works nearly all of the time.  However, on occasion (a couple times a 
year) the job will fail in the IDCAMS Step with DATASET IN USE BY ANOTHER TASK 
message.  The enq is so fast, I do not have any indication of what was holding 
it.
The IDCAMS Step reloads the history file with the last 3 days' worth of 
information about jobs.  It is a very simple REPO IFILE(x) OFILE(y)


I opened an SR to IBM DFSMS and asked if they could add some checks in IDCAMS 
for the nonzero return code from the enq and let me know what job is using it.
They indicated that extra code path to do that would not help.  They felt that 
the enq is released so soon the extra test for the enqueue would not provide 
the name of the task.

I have looked at RMF reports - I could see nothing.
I have looked at DAF reports for the 5 min time frame - I could see nothing.
When the step fails with RC12, I do the D GRS,C and nothing shows up.
I am tempted to start the ISG Monitor for Enqueues for the 15 minute window 
when this job runs.

If we rerun the job it is successful.

Anyone have any other ideas to try and trap this rascally rabbit?



Lizette Koehler
statistics: A precise and logical method for stating a half-truth inaccurately

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


The information in this transmission may contain proprietary and non-public 
information of BB or its affiliates and may be subject to protection under 
the law. The message is intended for the sole use of the individual or entity 
to which it is addressed. If you are not the intended recipient, you are 
notified that any use, distribution or copying of the message is strictly 
prohibited. If you received this message in error, please delete the material 
from your system without reading the content and notify the sender immediately 
of the inadvertent transmission.

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


Re: IPCS

2016-02-25 Thread Jim Mulder
> > What are the risks of giving [IPCS] access to developers?
> 
> Mostly, you risk them learning and understanding more about our platform
> -- and post-mortem debugging -- than they did previously.
> 
> IIRC, IPCS requires READ access to parmlib. If that's an issue, I
> believe it might be possible to create a stand-alone parmlib just for
> IPCS use.

  If the IPCSPARM ddname is allocated. that is what IPCS will use for 
accessing parmlib members. If IPCSPARM is not allocated, IPCS will use 
the system's parmlib concatenation.

  IPCS needs the parmlib members which IBM provides.  Typically, these 
are found on the sysres volume in a data set named SYS1.IBM.PARMLIB 
(or some similar name chosen by the systems programmer). 

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


Re: Outsourcing Stories Good or Bad!

2016-02-25 Thread Sankaranarayanan, Vignesh
Some thoughts from someone on the other side.

What's the point of saying "Oh, I'm an outsourced nobody." in a post where one 
is asking for help. So you may choose to not answer or sit on your high horse 
and ridicule their incompetence when they're struggling?
If you guys (actual mainframe folk with decades of background) are going to 
compare outsourced folk vs yourselves, you're doing it wrong.
Most of your outsourced folk are younger than the total experience you may 
have. Of course they're going to be inferior.
Do you call a baby rubbish because it can't write a sonnet? Yes, the baby has 
no business writing sonnets but welcome to the world of outsourcing.

When deciding to outsource, your employer has chosen money over the people who 
have served him/her for a long time.
Don't take out your anger and disgust on people who are struggling to better 
themselves because they have massive shoes to fill.
It's not his/her action that has led to you being laid off and being forced to 
accept ridiculous things (train or you don't get your 401k or whatever) in your 
last hours (on the job).

That said, here's some actual feedback which may not be possible to implement 
at all though:
1. Exercise as many choices as you must to ensure you do not suffer. Try as 
hard as you can to not accept people who can't speak basic English.
The big man at the outsourcer may not leave that choice to you but trust me, 
this is the root of all the abscess that you're (employer) being charged for.
"This guy can't speak, so let's make him work under some 15,000 managers who 
repeat the same thing without adding value."
Oh, and BTW, these managers are paid a f*k load more than the people working, I 
would assume.

2. Offshoring development, IMHO, is the worst thing you can do.
You want your company to work on code that's written by someone who's knowledge 
is extremely limited, and someone who would keep trying to nail everything 
because he has a hammer?

3. If you are able to pick the right (technical) people, keep the overhead 
(hey, if we're "resources", what's above us ought to be "overhead" right?) to 
an extreme minimum.

Who knows, some day Watson may make the whole industry go away and one machine 
may manage the other. At that point, you get to say "Ha! No more of these 
'incompetent masses'".

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, Feb 25, 2016 12:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Outsourcing Stories Good or Bad!

On Wed, 24 Feb 2016 10:31:14 +, Mark Wilson wrote:

>I am working with a client in Europe that is being requested by his
>senior management team to look at outsourcing their IT systems,
>including their system z platform.
>
>Would anyone be willing to share any war stories of their experiences
>with Outsourcing good or bad?

There has been considerable evidence of outsourcing to incompetent companies on 
IBM-Main lately. They don't say that they are outsourcers, but in the last few 
days there have been threads from people who hadn't a clue what they were 
doing. My guess is that they are outsourcers. Two that come to mind are the 
thread on a DASD device not going offline, and one about Applying a PTF to
DB2 10.

--
Tom Marchant

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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


Re: VSAM file not extending to new volume

2016-02-25 Thread Greg Shirey
Hmm, thanks for that.  It looks like the EA value was NO instead of YES.  
I'll have to figure out how that happened.

Greg 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, February 25, 2016 11:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VSAM file not extending to new volume

Check for this in your data class
DATA CLASS DISPLAY   Page 2 of 5
   
 CDS Name  . . . . . : ACTIVE  
 Data Class Name . . : DIRECT   
 
   
 Data Set Name Type  . . . . . : EXTENDED  
   If Extended . . . . . . . . : REQUIRED  
   Extended Addressability . . : YES
   Record Access Bias  . . . . : USER  
 Space Constraint Relief . . . : NO
--



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


Archive (was Re: Apply PTF on DB2 10 (z/os 1.12))

2016-02-25 Thread John Eells

Tom Marchant wrote:

On Thu, 25 Feb 2016 10:25:56 -0500, John Eells wrote:


Anyone know why I get this trying to follow the link?

"Sorry, you are not authorized to search the archives of the
IBM-MAIN-ARCHIVES list from the email address (ee...@us.ibm.com) you
entered on the login screen."


John, IBM-MAIN-ARCHIVES is a different list than IBM-MAIN. Are you
subscribed to it as well? A while back, old messages for IBM-MAIN were split
off into the IBM-MAIN-ARCHIVES list. IIRC it was to improve search time.



Aha!  Must have been asleep when that happened.  Thanks so much to you 
and Elardus.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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


Re: History of Computing 1944 and the evolution to the System/360

2016-02-25 Thread Hobart Spitz
Additional memory was available from third party vendors.  At Cornell in
the early 1970s, the 360/65(?) had 1M.  I don't recall if that was the
total or the additional memory.

On Thu, Feb 25, 2016 at 12:36 PM, Hobart Spitz  wrote:

>
>
> On Thu, Feb 25, 2016 at 12:11 PM, Mike Schwab 
> wrote:
>
>> https://en.wikipedia.org/wiki/IBM_700/7000_series
>> Basically, the IBM 7xx and 7xxx had 4 branches in the family tree.
>> Each incompatible with the other. The IBM 360 was a common design to
>> satisfy all customers with one product.  Businesses go the decimal
>> instructions, science labs got the floating point instructions, time
>> sharing sites got virtual memory (67).  By the time 31 bit addressing
>> came out, every machine had every instruction available for that
>> model.
>>
>> On Wed, Feb 24, 2016 at 9:34 PM, Lizette Koehler
>>  wrote:
>> > I was trolling for information on what the 360 indicated in the
>> System/360 (yes
>> > the old one) and came across this video
>> >
>> >
>> >
>> > Thought some might enjoy the walk down memory lane. The S/360 Model 30
>> had 1MB
>> > of memory (I think) at the time.
>> >
>> >
>> >
>> >
>> >
>> > https://www.youtube.com/watch?v=V4kyTg9Cw8g
>> >
>> >
>> >
>> > Lizette Koehler
>> >
>> > statistics: A precise and logical method for stating a half-truth
>> inaccurately
>> >
>> >
>> >
>> >
>> > --
>> > 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
>>
>
>
>
> --
> OREXXMan
>



-- 
OREXXMan

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


Re: History of Computing 1944 and the evolution to the System/360

2016-02-25 Thread Hobart Spitz
On Thu, Feb 25, 2016 at 12:11 PM, Mike Schwab 
wrote:

> https://en.wikipedia.org/wiki/IBM_700/7000_series
> Basically, the IBM 7xx and 7xxx had 4 branches in the family tree.
> Each incompatible with the other. The IBM 360 was a common design to
> satisfy all customers with one product.  Businesses go the decimal
> instructions, science labs got the floating point instructions, time
> sharing sites got virtual memory (67).  By the time 31 bit addressing
> came out, every machine had every instruction available for that
> model.
>
> On Wed, Feb 24, 2016 at 9:34 PM, Lizette Koehler
>  wrote:
> > I was trolling for information on what the 360 indicated in the
> System/360 (yes
> > the old one) and came across this video
> >
> >
> >
> > Thought some might enjoy the walk down memory lane. The S/360 Model 30
> had 1MB
> > of memory (I think) at the time.
> >
> >
> >
> >
> >
> > https://www.youtube.com/watch?v=V4kyTg9Cw8g
> >
> >
> >
> > Lizette Koehler
> >
> > statistics: A precise and logical method for stating a half-truth
> inaccurately
> >
> >
> >
> >
> > --
> > 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
>



-- 
OREXXMan

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


Re: VSAM file not extending to new volume

2016-02-25 Thread Lizette Koehler
Check for this in your data class
DATA CLASS DISPLAY   Page 2 of 5
   
 CDS Name  . . . . . : ACTIVE  
 Data Class Name . . : DIRECT   
 
   
 Data Set Name Type  . . . . . : EXTENDED  
   If Extended . . . . . . . . : REQUIRED  
   Extended Addressability . . : YES
   Record Access Bias  . . . . : USER  
 Space Constraint Relief . . . : NO
--


Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Thursday, February 25, 2016 10:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VSAM file not extending to new volume
> 
> Did you check to see if the file is over 4GB in size?  And if it is, does it
> have EA/EF specified?
> 
> Do a LISTC ALL and look at the options and HIURBA and HIARBA
> 
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Greg Shirey
> > Sent: Thursday, February 25, 2016 9:35 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: VSAM file not extending to new volume
> >
> > We upgraded to z/OS 2.1 on the 13th and all seemed well until this
> > morning when several jobs were trying to write to a VSAM file and
> > received this
> > message:
> >
> > IEC070I 034(004)-220,GSFAQ200,GS200060GS200,VTSREG4,4621,PROD33,
> > IEC070I SPP.ALL.SP013V,SPP.ALL.SP013V.DATA,CATALOG.x.xxx
> >
> > The message indicates the file could not extend - but it should have
> > extended to a new volume.  The DATACLAS for our VSAM files has a Dynamic
> Volcount of
> > 20.When we did a LISTCAT on the data set, it showed a second volume with
> > VOLSER of * and  VOLFLAG as CANDIDATE.   (and Attribute of Extended)
> >
> > In order to recover the batch job, the applications group had to
> > rebuild the VSAM file, so they did, then the sysprogs moved it to a
> > volume with a lot of free space, and all the jobs ran fine.
> >
> > We generated a data set listing in ISMF and filtered on MULTIVOL = YES
> > and our sequential data sets are successfully being extended to other
> > volumes, but all of the VSAM files on the list only had CANDIDATE volumes
> after the primary.
> >
> > We've opened a PMR and searched the database, but we keep thinking we
> > must have missed a migration step or something because we aren't seeing
> anyone else
> > reporting anything like this.   Any suggestions?
> >
> > Thanks,
> > Greg Shirey
> > Ben E. Keith Company

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


Re: Apply PTF on DB2 10 (z/os 1.12)

2016-02-25 Thread Paul Gilmartin
On Thu, 25 Feb 2016 10:25:56 -0500, John Eells wrote:

>Anyone know why I get this trying to follow the link?
>
>"Sorry, you are not authorized to search the archives of the
>IBM-MAIN-ARCHIVES list from the email address (ee...@us.ibm.com) you
>entered on the login screen."
> 
Thanks, John, for your attention.

Google Groups has it as:
https://groups.google.com/d/topic/bit.listserv.ibm-main/kOCEy0DbOnM
Perhaps the APAR IDs:
 SMP/E APARs IR44571/IR46256 (does sup have all elements?)
-- Kurt Quackenbush

>>> On Wed, 24 Feb 2016 19:51:07 -0600, Paul Gilmartin wrote:
>>>
>>  http://bama.ua.edu/cgi-bin/wa?A2=ind0110=ibm-main-archives=R58709
>>
And my ancient bookmark still works.  Perhaps I'm grandfathered in.

-- gil

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


Re: Knowing GEN level

2016-02-25 Thread Lizette Koehler
Jake,

Are you asking how to know what level of service is on particular product?  If 
so, you will need to find out how each vendor handles that.  For IBM - RSU, for 
CA CARS, and so on.  And then there are those cases where you want to know on 
specific module/src.  Again, ask your vendor.

Then you need to query your zones to see what is there.  There is no magic.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jake Anderson
> Sent: Thursday, February 25, 2016 8:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Knowing GEN level
> 
> Hi
> 
> Is there a way to determine the GEN level from a product CSI ?
> 
> Jake
> 

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


Re: VSAM file not extending to new volume

2016-02-25 Thread Lizette Koehler
Did you check to see if the file is over 4GB in size?  And if it is, does it 
have EA/EF specified?

Do a LISTC ALL and look at the options and HIURBA and HIARBA


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Greg Shirey
> Sent: Thursday, February 25, 2016 9:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: VSAM file not extending to new volume
> 
> We upgraded to z/OS 2.1 on the 13th and all seemed well until this morning
> when several jobs were trying to write to a VSAM file and received this
> message:
> 
> IEC070I 034(004)-220,GSFAQ200,GS200060GS200,VTSREG4,4621,PROD33,
> IEC070I SPP.ALL.SP013V,SPP.ALL.SP013V.DATA,CATALOG.x.xxx
> 
> The message indicates the file could not extend - but it should have extended
> to a new volume.  The DATACLAS for our VSAM files has a Dynamic Volcount of
> 20.When we did a LISTCAT on the data set, it showed a second volume with
> VOLSER of * and  VOLFLAG as CANDIDATE.   (and Attribute of Extended)
> 
> In order to recover the batch job, the applications group had to rebuild the
> VSAM file, so they did, then the sysprogs moved it to a volume with a lot of
> free space, and all the jobs ran fine.
> 
> We generated a data set listing in ISMF and filtered on MULTIVOL = YES and our
> sequential data sets are successfully being extended to other volumes, but all
> of the VSAM files on the list only had CANDIDATE volumes after the primary.
> 
> We've opened a PMR and searched the database, but we keep thinking we must
> have missed a migration step or something because we aren't seeing anyone else
> reporting anything like this.   Any suggestions?
> 
> Thanks,
> Greg Shirey
> Ben E. Keith Company
> 

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


Re: History of Computing 1944 and the evolution to the System/360

2016-02-25 Thread Mike Schwab
https://en.wikipedia.org/wiki/IBM_700/7000_series
Basically, the IBM 7xx and 7xxx had 4 branches in the family tree.
Each incompatible with the other. The IBM 360 was a common design to
satisfy all customers with one product.  Businesses go the decimal
instructions, science labs got the floating point instructions, time
sharing sites got virtual memory (67).  By the time 31 bit addressing
came out, every machine had every instruction available for that
model.

On Wed, Feb 24, 2016 at 9:34 PM, Lizette Koehler
 wrote:
> I was trolling for information on what the 360 indicated in the System/360 
> (yes
> the old one) and came across this video
>
>
>
> Thought some might enjoy the walk down memory lane. The S/360 Model 30 had 1MB
> of memory (I think) at the time.
>
>
>
>
>
> https://www.youtube.com/watch?v=V4kyTg9Cw8g
>
>
>
> Lizette Koehler
>
> statistics: A precise and logical method for stating a half-truth inaccurately
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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


Re: Apply PTF on DB2 10 (z/os 1.12)

2016-02-25 Thread Elardus Engelbrecht
Tom Marchant wrote:

>John Eells wrote:
>>Anyone know why I get this trying to follow the link?

>>"Sorry, you are not authorized to search the archives of the 
>>IBM-MAIN-ARCHIVES list from the email address (ee...@us.ibm.com) you entered 
>>on the login screen."

>John, IBM-MAIN-ARCHIVES is a different list than IBM-MAIN. Are you subscribed 
>to it as well? A while back, old messages for IBM-MAIN were split off into the 
>IBM-MAIN-ARCHIVES list. IIRC it was to improve search time.

Tom, thanks for your kind help to John.

Look at https://listserv.ua.edu/cgi-bin/wa?INDEX to see all list-servs hosted. 
Both IBM-MAIN and IBM-MAIN-ARCHIVES are listed there. You can use the web-pages 
of these to logon and get your password and searching fixed.

Groete / Greetings
Elardus Engelbrecht

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


Re: Digest oddity, item in Topics, but not in Body

2016-02-25 Thread Elardus Engelbrecht
John Mattson wrote:

>Last couple of days I have noticed some occurrences of a subject being listed 
>in the Topics of the day, but not found in the body.  Is there a problem?  
>Anyone else getting this?

Not me, but there are 3 formats of digest e-mails:

Digest (traditional)
Digest (MIME format)
Digest (HTML format)

and two types of index:

Index (traditional)
Index (HTML format)

Which of those are you using?

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


Digest oddity, item in Topics, but not in Body

2016-02-25 Thread John Mattson
Last couple of days I have noticed some occurrences of a subject being
listed in the Topics of the day, but not found in the body.  Is there a
problem?  Anyone else getting this?

IBM-MAIN Digest - 23 Feb 2016 to 24 Feb 2016 (#2016-55)
There are 78 messages totaling 4940 lines in this issue.
Topics of the day:
 13. Introducing Open Blockchain for IBM z Systems

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


VSAM file not extending to new volume

2016-02-25 Thread Greg Shirey
We upgraded to z/OS 2.1 on the 13th and all seemed well until this morning when 
several jobs were trying to write to a VSAM file and received this message: 
 
IEC070I 034(004)-220,GSFAQ200,GS200060GS200,VTSREG4,4621,PROD33, 
IEC070I SPP.ALL.SP013V,SPP.ALL.SP013V.DATA,CATALOG.x.xxx

The message indicates the file could not extend - but it should have extended 
to a new volume.  The DATACLAS for our VSAM files has a Dynamic Volcount of 20. 
   When we did a LISTCAT on the data set, it showed a second volume with VOLSER 
of * and  VOLFLAG as CANDIDATE.   (and Attribute of Extended) 

In order to recover the batch job, the applications group had to rebuild the 
VSAM file, so they did, then the sysprogs moved it to a volume with a lot of 
free space, and all the jobs ran fine.   

We generated a data set listing in ISMF and filtered on MULTIVOL = YES and our 
sequential data sets are successfully being extended to other volumes, but all 
of the VSAM files on the list only had CANDIDATE volumes after the primary.  

We've opened a PMR and searched the database, but we keep thinking we must have 
missed a migration step or something because we aren't seeing anyone else 
reporting anything like this.   Any suggestions? 

Thanks,
Greg Shirey
Ben E. Keith Company 

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


Re: Knowing GEN level

2016-02-25 Thread Tom Marchant
On Thu, 25 Feb 2016 21:05:02 +0530, Jake Anderson wrote:

>Is there a way to determine the GEN level from a product CSI ?

GEN level? what do you mean by that?

-- 
Tom Marchant

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


Re: Apply PTF on DB2 10 (z/os 1.12)

2016-02-25 Thread Tom Marchant
On Thu, 25 Feb 2016 10:25:56 -0500, John Eells wrote:

>Anyone know why I get this trying to follow the link?
>
>"Sorry, you are not authorized to search the archives of the
>IBM-MAIN-ARCHIVES list from the email address (ee...@us.ibm.com) you
>entered on the login screen."

John, IBM-MAIN-ARCHIVES is a different list than IBM-MAIN. Are you 
subscribed to it as well? A while back, old messages for IBM-MAIN were split 
off into the IBM-MAIN-ARCHIVES list. IIRC it was to improve search time.

-- 
Tom Marchant

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

2016-02-25 Thread Tom Marchant
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


Re: AW: Re: Prefix save area - confused

2016-02-25 Thread Steve Thompson

Peter Hunkler:

What I'm about to say does not contradict Peter Relson's post 
clarifying things relative to MVS -> z/OS.


Unless IBM has done some interesting magic, the c-store of a 
z/Architecture box is "owned" by the Hypervisor, in this case 
PR/SM. There are no bare metal SCPs today because of how IBM does 
things.


Now, going back > 20 years for an Amdahl 5990, MDF started at low 
storage, and self-relocated to high storage (HSA) -- very early 
in the process. Absolute 0 was still at absolute 0. Meanwhile the 
580s' HSA was low storage if I remember correctly.


Within the Hypervisor, once the MP init (Multi-Processor) was 
done, all the CPUs were prefixed into HSA (which belongs to the 
hypervisor).


At some point, domain init gets run, and the domains get built 
(IBM's LPARs). They start off with a pseudo absolute 0 which is 
at the bottom of their storage block. So you do an IPL (for the 
SCP for that domain), and the SCP loads, and at some point (MVS 
or VM) MP INit is done, now the domain (again, LPAR in IBM 
parlance) "prefixes" all of the CPUs it knows about.


After that SCP gets virtual storage controls initialized, DAT 
becomes is functional. Depends on the SCP as to how soon this is 
completed.


So, here you are with VM and SIE. You now have virtual storage 
run by VM (CP) to the second level machine which may be REAL or 
may be a Virtual system as well.


Eyes glazed over yet?

To effect all of this, the CEC must implement some kind of 
Hypervisor Registers (probably at the CPU level) so that one can 
switch between DOMAIN/LPAR mode and Hypervisor mode and address 
storage accordingly.


When VM/CP are functioning, it must do the same kind of tracking 
for each of its guests.


Wanna have some more fun? The hardware has just detected a 
double-bit parity error. How will you reflect that MCK to the 
affected LPAR?


The Hypervisor is the one that gets posted with that. And now it 
has to figure out where that CPU was in the grand scheme of 
things so that the MCK can be handled correctly. I used to do 
that level of programming at Amdahl.


So, one finds what the domain registers contained, and then you 
do the MCK PSW swap after setting all the bits/etc. in that CPU's 
Prefix area in that domain (LPAR), and let that SCP figure it out 
-- depending on whether it was exigent or repressive and the CR 
bits were set...


And we haven't even mentioned I/O in all of this other than to 
hint at it because of "IPL".


It gets complicated. And when Amdahl started this (MDF) IBM's 
machines were still Base 370, and some engineers had to figure 
out how to float I/O 'rupts so they could be reflected to the 
correct CPU in the correct Domain. Plus, page fixing and getting 
I/O synced with the right channel Having X/A channels would 
have made this much easier I just wonder who came up with 
that idea.


(If I'm a bit off, forgive me, it has been a bit over 20 years 
since I did this level of programming, and with CMOS a lot 
changed that I was never part of).


Regards,
Steve Thompson

On 02/25/2016 01:39 AM, Peter Hunkeler wrote:

Nevertheless, absolute 0 is owned by PR/SM, right?


The 8 KiB area at absolute 0 is the place where the hardware writes status information as 
result of performing the "Store Status" operation. 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.



... and for practical purposes absolute and real addressing are the same, 
except when takling about the 8 KiB at real address 0 and the 8KiB point to by 
the prefix resigsters.


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


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?), and 
will translate real 0 (with the help of the Prefix Register) to absolute 0 (for this LPAR). Some 
other part of the hardware needs to translate "absolute 0 of this LPAR" to a *physical* 
memory address (how this works in detail  is far beyond my knowledge).


--
Peter Hunkeler



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


Knowing GEN level

2016-02-25 Thread Jake Anderson
Hi

Is there a way to determine the GEN level from a product CSI ?

Jake

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


Re: Apply PTF on DB2 10 (z/os 1.12)

2016-02-25 Thread John Eells

Anyone know why I get this trying to follow the link?

"Sorry, you are not authorized to search the archives of the 
IBM-MAIN-ARCHIVES list from the email address (ee...@us.ibm.com) you 
entered on the login screen."


I used to be able to look in the archives...

Paul Gilmartin wrote:

On Wed, 24 Feb 2016 21:28:05 -0600, Tom Marchant  
wrote:


On Wed, 24 Feb 2016 19:51:07 -0600, Paul Gilmartin wrote:


I suspect CA's shenanigans were a motivation for IBM's tightening the rules on
SUPERSEDEs a few years prior to that.


How were the rules for SUP tightened?


 http://bama.ua.edu/cgi-bin/wa?A2=ind0110=ibm-main-archives=R58709





--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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


Web Version

2016-02-25 Thread Ed Gould

Gil wrote on a item and gave the web interface URL.
I tried it and for after a lot of shenanigans I got this message:


Confirmation Sent

Your password registration request has been accepted. For your  
protection, the password will not be activated just yet (anyone could  
have completed this form using your email address). To activate your  
password, simply follow the instructions which have been sent to you  
at edgould1...@comcast.net. Please wait until you receive a message  
from LISTSERV saying "Your new password was registered successfully"  
before trying to use it with the Web interface.


That was 8 hours ago and still nothing (and nothing in my junk folder  
either). Since Darren is lost who are we sup[posed to make inquiries to?


Ed

ps: Can Gil just report the original item, please?

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


Re: Parsing IEASYS00 entries

2016-02-25 Thread Field, Alan
Thanks Peter. I resolved it by using 

Since  isn't in my IEASYMxx I think it is being defined during the 
startup of some ISV software. 



Alan Field
Systems Engineer Principal
Blue Cross Blue Shield of MN

651.662.3546

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Thursday, February 25, 2016 6:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Parsing IEASYS00 entries

In all symbol substitution situations you need to start by asking "what is the 
value of the symbol?", in this case, "what is the value of ?".

Since z/OS does not create such a symbol, then if you don't have it in your 
IEASYMxx then it's very unlikely that it's available for usage during IPL.

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


This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the named addressee you must not disseminate, distribute or copy 
this e-mail. Please notify the sender immediately by e-mail if you have 
received this e-mail by mistake and delete this e-mail from your system. If you 
are not the intended recipient you are notified that disclosing, copying, 
distributing or taking any action in reliance on the contents of this 
information is strictly prohibited.

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


Re: System Trace Table Size -- REDUX

2016-02-25 Thread Gord Tomlin

On 2016-02-25 09:34, Ed Jaffe wrote:

I brought this up on IBM-MAIN many years ago after noticing several
system traces, from large customers, with less than one screen's worth
of good trace data. At that time, the maximum trace table size was 999K
and I recommended setting that size (if you could afford the real
memory). 1M is now the default...

Just last night I was asked to take a look at a dump -- from a large
customer running on the newest, biggest "iron" -- that had only .045
seconds of good trace data:

 Trace data is not available from all processors before this time.
0008 0269 008C3448  I/O  02013 _0D91ABCA  10104007 6F932740
0C000100  0080  0009 0269 08:22:55.743019140 40
07544000 8000   024FE070
0010  
.
. (two measly pages of trace data)
.
0012 0226 084B8B00  SSRV   118  A6476E64  01E6A110 8007611A
08245B88  Suspend 08:22:55.788338762 6E
   
 Trace data is not available from all processors after this time.

Don't forget to re-visit your MVS trace table allocations whenever you
upgrade your hardware. Luckily, major increases in processor speed and
the number of logical processors have been accompanied by similar
increases in LPAR real memory allocations, making larger trace tables
possible.

The TRACE ST command now supports up to 9G per processor! LOL! I'm not
in any way suggesting that value be used, I'm just pointing out that
it's possible.

IMHO, trace tables should be sized to hold _at least_ one full clock
second of data on your zIIPs or whatever your fastest processors might
be. Others might have different ROTs.

Just do it! Your debugging teams will thank you. :)



Too bad listservs don't have "like" buttons!

I can't count the number of times where key information was outside of 
the time range covered by system trace. On the other side of the coin, I 
can think of several cases where the trace table size was a generous 
size and information I needed was several seconds before the event 
causing the dump.


Providing ample storage for system trace is a great way to help your 
vendors solve any problems you encounter, and in today's environment of 
cheap and plentiful storage the cost is minimal.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

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


System Trace Table Size -- REDUX

2016-02-25 Thread Ed Jaffe
I brought this up on IBM-MAIN many years ago after noticing several 
system traces, from large customers, with less than one screen's worth 
of good trace data. At that time, the maximum trace table size was 999K 
and I recommended setting that size (if you could afford the real 
memory). 1M is now the default...


Just last night I was asked to take a look at a dump -- from a large 
customer running on the newest, biggest "iron" -- that had only .045 
seconds of good trace data:


 Trace data is not available from all processors before this time.
0008 0269 008C3448  I/O  02013 _0D91ABCA  10104007 6F932740 
0C000100  0080  0009 0269 08:22:55.743019140 40
   07544000 8000   024FE070 
0010  

.
. (two measly pages of trace data)
.
0012 0226 084B8B00  SSRV   118  A6476E64  01E6A110 8007611A 
08245B88  Suspend 08:22:55.788338762 6E

  
 Trace data is not available from all processors after this time.

Don't forget to re-visit your MVS trace table allocations whenever you 
upgrade your hardware. Luckily, major increases in processor speed and 
the number of logical processors have been accompanied by similar 
increases in LPAR real memory allocations, making larger trace tables 
possible.


The TRACE ST command now supports up to 9G per processor! LOL! I'm not 
in any way suggesting that value be used, I'm just pointing out that 
it's possible.


IMHO, trace tables should be sized to hold _at least_ one full clock 
second of data on your zIIPs or whatever your fastest processors might 
be. Others might have different ROTs.


Just do it! Your debugging teams will thank you. :)

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

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


Re: Novel Data Centers around the world

2016-02-25 Thread Elardus Engelbrecht
Lizette Koehler wrote:

>I stumbled across this.  It is photos of data centers that do not match the 
>old concrete concept of a DC.  Some of these are actually incredible 
>repurposed buildings (like cathedrals).  

Interesting! Thanks for sharing these nice eye-candies.

As a bonus, I followed some of the link and discovered a real bunker of a 
datacentre...

Have fun reading this...

http://www.cyberbunker.com/web/cityhall.php 


>Proving that Sweden can be not only cold but also cool, this hip underground 
>data bunker run by internet service provider looks like it could survive a 
>hydrogen bomb...

And those Sweden people can build excellent cars too. Think Volvo, Saab and 
Scania amongst other...

Groete / Greetings
Elardus Engelbrecht

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


Re: Prefix save area - confused

2016-02-25 Thread Peter Relson
>In what way do they say PSA is a common area of every address space when
>there is a unique PSA for every processor ?

"common area for every address space" has nothing to do with "processor". 
It says that no matter what address space you are in you can access fields 
in the PSA. And that is true. That is unlike "private area" where the 
private storage at address X in an address space has no necessary 
correlation to the private storage at address X in another address space.

PSA is an MVS (probably older than that, actually) term. It has not to my 
knowledge ever varied from "prefixed save area". Within there you will 
also see "FLC" for "Fixed Low Core". Neither of these is an architectural 
term.

As was mentioned, prefixing is a hardware function, provided so that 
programs could use the same address (e.g., 0) but get to a different area 
per processor. Many fields in the PSA are the same in every processor's 
PSA (e.g., the address of the CVT), but many are different (e.g, the 
address of the home TCB, the address of the home ASCB, the address of the 
LCCA). 

It is true that in between instructions (when not disabled for I/O and 
external interrupts) your work unit could be moved to another processor 
where it would then reference a different PSA. But for the most part the 
program is expected not to care -- for the things that the program needs, 
the PSA is expected to be "correct" on whichever processor the program is 
dispatched.

When a work unit is undispatched from one processor and redispatched on 
another, about the only "normal" things updated in the PSA are the home 
TCB and home ASCB addresses. Another thing that is updated is the FRR 
stack. The FRR stack is saved upon undispatch and the "target PSA's" FRR 
stack is set up from that saved FRR stack to accompany the redispatch. 
There are some other things that are updated upon redispatch related to 
the status of the work unit; those are not used as frequently by 
applications.

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


Novel Data Centers around the world

2016-02-25 Thread Lizette Koehler
I stumbled across this.  It is photos of data centers that do not match the old
concrete concept of a DC.  Some of these are actually incredible repurposed
buildings (like cathedrals).  I found some of the ways companies (like Google)
enhanced their employees experience quite unusual at times.

http://www.techrepublic.com/pictures/these-data-centers-are-insanely-gorgeous/?f
tag=ACQd47fd66

More than just row upon row of whirring information-storage obelisks, today's
repositories of zeroes and ones take design to the next level.  For example:
Proving that Sweden can be not only cold but also cool, this hip underground
data bunker run by internet service provider looks like it could survive a
hydrogen bomb...


Lizette Koehler
statistics: A precise and logical method for stating a half-truth inaccurately

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


Re: DASD device not going offline

2016-02-25 Thread Peter Relson
>Did it really say "HAS VOLUME ID DOESNT NOT MATCH WITH CATALOG"?

The answer better be "no". That part of the message text is:
HAS A VOLUME ID THAT DOES NOT MATCH CATALOG

>It might not even say CSV540E.
Due to customer request, it was changed from CSV540I to CSV540E in z/OS 
2.1.

Peter Relson
z/OS Core Technology Design


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


Re: IPCS

2016-02-25 Thread Binyamin Dissen
Is there really anything in PARMLIB that cannot be found in unprotected CSA?

On Wed, 24 Feb 2016 20:16:57 -0600 Ed Gould  wrote:

:>Binyamin:
:>
:>I agree but to a specific point disagree.
:>
:>I have been in several shops where read access was given to  
:>SYS1.PARMLIB . Every one of those shops at least one time a month we  
:>were called into a meeting to "discuss"  contents of sys1.parmlib.  
:>Those meeting could last 2-5 hours arguing the contents of one member  
:>or another. It got so bad that I had to move the contents to another  
:>restricted library (in the concatenation) to stop such meetings(and  
:>leave dummy entries behind). It seems that every tom dick and harry  
:>*KNEW* what one parameter or another should be. On one occasion I  
:>changed a member because it was mandated and of course it did not do  
:>anything to solve the problem (was there really a problem?)
:>Politics is a PITA time waster so keep everything in other libraries  
:>so you stop the politics before it happens.
:>
:>Ed
:>
:>On Feb 24, 2016, at 3:42 PM, Binyamin Dissen wrote:
:>
:>> None.
:>>
:>> You should protect your SYS1.DUMP dataset.
:>>
:>> In general, protect the data, not the program - unless the program  
:>> is APF and
:>> bypasses OPEN without a security check.
:>>
:>> On Wed, 24 Feb 2016 20:46:34 + "Lopez, Sharon"  
:>> 
:>> wrote:
:>>
:>> :>Do others use IPCS instead of systems programmers?  I always  
:>> thought of it as a system's programmers tool but now we have  
:>> application developers that want access to it.  What are the risks  
:>> of giving access to developers?
:>> :>
:>> :>Thanks 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
:>>
:>> --
:>> Binyamin Dissen 
:>> http://www.dissensoftware.com
:>>
:>> Director, Dissen Software, Bar & Grill - Israel
:>>
:>>
:>> Should you use the mailblocks package and expect a response from me,
:>> you should preauthorize the dissensoftware.com domain.
:>>
:>> I very rarely bother responding to challenge/response systems,
:>> especially those from irresponsible companies.
:>>
:>> --
:>> For IBM-MAIN subscribe / signoff / archive access instructions,
:>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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


Re: IPCS

2016-02-25 Thread Peter Relson
>There should be no risks at all to allowing application developers to
>use IPCS.

This is surely true. 

Applications may take SYSMDUMPs for example. If you want people to be able 
to debug their applications, they will need to be able to use dump reading 
tools to read their dumps. And many things in SYSMDUMPs are captured that 
are not captured in SYSABEND or SYSUDUMPs (think storage above 2G).

As others have posted, what is also true is that it may be very important 
to protect the data.
It is usually not appropriate to give everyone read access to system 
dumps.

But if you have read access to the dump, then using IPCS is not exposing 
anything that you could not (with some difficulty, admittedly, but doable) 
determine yourself. And as Ed Jaffe mentioned, with the "ACTIVE" option, 
in the absence of security profiles that permit otherwise, the user cannot 
see anything that an unauthorized program in their address space could 
see.

Peter Relson
z/OS Core Technology Design


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


Re: Parsing IEASYS00 entries

2016-02-25 Thread Peter Relson
In all symbol substitution situations you need to start by asking "what is 
the value of the symbol?", in this case, "what is the value of ?".

Since z/OS does not create such a symbol, then if you don't have it in 
your IEASYMxx then it's very unlikely that it's available for usage during 
IPL.

Peter Relson
z/OS Core Technology Design


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


Re: History of Computing 1944 and the evolution to the System/360

2016-02-25 Thread Mike Myers
The 360-mod 40 in the Field Engineering Education Center in Poughkeepsie 
had 64K in 1968. We were using it to train PSRs for OS/360.


Mike Myers
Mentor Services Corporation

On 02/24/2016 10:34 PM, Lizette Koehler wrote:

I was trolling for information on what the 360 indicated in the System/360 (yes
the old one) and came across this video

  


Thought some might enjoy the walk down memory lane. The S/360 Model 30 had 1MB
of memory (I think) at the time.

  

  


https://www.youtube.com/watch?v=V4kyTg9Cw8g

  


Lizette Koehler

statistics: A precise and logical method for stating a half-truth inaccurately

  



--
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 Open Blockchain for IBM z Systems

2016-02-25 Thread Bigendian Smalls
Fantastic thank you.  

> On Feb 25, 2016, at 3:36 AM, Timothy Sipples  wrote:
> 
> Yes, take a look here for source code (with more to come, including as I
> understand it more details on building on z):
> 
> https://github.com/IBM-Blockchain
> https://github.com/openblockchain
> 
> Although optional, IBM would very much like to stay in touch with those
> working with Blockchain on z. Please visit this page:
> 
> http://www.ibm.com/blockchain/z.html
> 
> and click on "Contact an expert" to get in that loop.
> 
> 
> 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: Introducing Open Blockchain for IBM z Systems

2016-02-25 Thread Timothy Sipples
Yes, take a look here for source code (with more to come, including as I
understand it more details on building on z):

https://github.com/IBM-Blockchain
https://github.com/openblockchain

Although optional, IBM would very much like to stay in touch with those
working with Blockchain on z. Please visit this page:

http://www.ibm.com/blockchain/z.html

and click on "Contact an expert" to get in that loop.


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