Re: Modernizing the BCP code ?

2012-04-15 Thread Shmuel Metz (Seymour J.)
In eca05fed-2f46-42eb-be35-50536de31...@yahoo.com, on 04/12/2012
   at 12:34 PM, Scott Ford scott_j_f...@yahoo.com said:

What about folks not running  Z9 for z/os 2.1 ?

Preumably like any levelset; stay backlevel or upgrade.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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


0C4 pic 4

2012-04-15 Thread Micheal Butz
Hi,

 

 

 I am getting S0C4 04 within a wait which leads me to believe that the
storage key of the ECB storage key is not the same as the PSW STORAGE KEY
8- 11

 

 

Does the following code make sense to resolve this address

 

 

TESTAUTH FCTN=1  TEST APF AUTORIZATION 

LTR   R15,R5 CHECK R15 

BNZ   NAPFSYSNDXNOT APF   

MODESET MODE=SUP,KEY=NZERO  TURN ON BIT 15 IN PSW  

LAR0,REPLY_ECB  GET ECB ADDRESS

IVSK  R1,R0 GET STORAGE KEY

MODESET KEYREG=R1,SAVEKEY=OLDKEY SET STORAGE KEY IN PSW 



  WAIT=REPLY_ECB

 

   MODESET MODE=PROB,KEY=NZERO   back to current TCB key


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


Re: 0C4 pic 4

2012-04-15 Thread Binyamin Dissen
No, because if you arbitrarily use the key as determined by IVSK, why not
simply do it in Key 0?

On Sun, 15 Apr 2012 13:29:55 -0400 Micheal Butz michealb...@optonline.net
wrote:

:Hi,
:
: 
:
: 
:
: I am getting S0C4 04 within a wait which leads me to believe that the
:storage key of the ECB storage key is not the same as the PSW STORAGE KEY
:8- 11
:
: 
:
: 
:
:Does the following code make sense to resolve this address
:
: 
:
: 
:
:TESTAUTH FCTN=1  TEST APF AUTORIZATION 
:
:LTR   R15,R5 CHECK R15 
:
:BNZ   NAPFSYSNDXNOT APF   
:
:MODESET MODE=SUP,KEY=NZERO  TURN ON BIT 15 IN PSW  
:
:LAR0,REPLY_ECB  GET ECB ADDRESS
:
:IVSK  R1,R0 GET STORAGE KEY
:
:MODESET KEYREG=R1,SAVEKEY=OLDKEY SET STORAGE KEY IN PSW 
:
:
:
:  WAIT=REPLY_ECB
:
: 
:
:   MODESET MODE=PROB,KEY=NZERO   back to current TCB key   

--
Binyamin Dissen bdis...@dissensoftware.com
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...@bama.ua.edu with the message: INFO IBM-MAIN


Re: 0C4 pic 4

2012-04-15 Thread Micheal Butz
Being in PSW Key 0 is good for any storage 0 - 16 



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Binyamin Dissen
Sent: Sunday, April 15, 2012 1:42 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: 0C4 pic 4

No, because if you arbitrarily use the key as determined by IVSK, why not
simply do it in Key 0?

On Sun, 15 Apr 2012 13:29:55 -0400 Micheal Butz michealb...@optonline.net
wrote:

:Hi,
:
: 
:
: 
:
: I am getting S0C4 04 within a wait which leads me to believe that the
:storage key of the ECB storage key is not the same as the PSW STORAGE KEY
:8- 11
:
: 
:
: 
:
:Does the following code make sense to resolve this address
:
: 
:
: 
:
:TESTAUTH FCTN=1  TEST APF AUTORIZATION 
:
:LTR   R15,R5 CHECK R15 
:
:BNZ   NAPFSYSNDXNOT APF   
:
:MODESET MODE=SUP,KEY=NZERO  TURN ON BIT 15 IN PSW  
:
:LAR0,REPLY_ECB  GET ECB ADDRESS
:
:IVSK  R1,R0 GET STORAGE KEY
:
:MODESET KEYREG=R1,SAVEKEY=OLDKEY SET STORAGE KEY IN PSW 
:
:
:
:  WAIT=REPLY_ECB
:
: 
:
:   MODESET MODE=PROB,KEY=NZERO   back to current TCB key   

--
Binyamin Dissen bdis...@dissensoftware.com
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...@bama.ua.edu with the message: INFO IBM-MAIN

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


Re: 0C4 pic 4

2012-04-15 Thread Binyamin Dissen
Exactly. Why overcomplicate?


On Sun, 15 Apr 2012 14:48:20 -0400 Micheal Butz michealb...@optonline.net
wrote:

:Being in PSW Key 0 is good for any storage 0 - 16 
:
:
:
:-Original Message-
:From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
:Of Binyamin Dissen
:Sent: Sunday, April 15, 2012 1:42 PM
:To: IBM-MAIN@bama.ua.edu
:Subject: Re: 0C4 pic 4
:
:No, because if you arbitrarily use the key as determined by IVSK, why not
:simply do it in Key 0?
:
:On Sun, 15 Apr 2012 13:29:55 -0400 Micheal Butz michealb...@optonline.net
:wrote:
:
::Hi,
::
:: 
::
:: 
::
:: I am getting S0C4 04 within a wait which leads me to believe that the
::storage key of the ECB storage key is not the same as the PSW STORAGE KEY
::8- 11
::
:: 
::
:: 
::
::Does the following code make sense to resolve this address
::
:: 
::
:: 
::
::TESTAUTH FCTN=1  TEST APF AUTORIZATION 
::
::LTR   R15,R5 CHECK R15 
::
::BNZ   NAPFSYSNDXNOT APF   
::
::MODESET MODE=SUP,KEY=NZERO  TURN ON BIT 15 IN PSW  
::
::LAR0,REPLY_ECB  GET ECB ADDRESS
::
::IVSK  R1,R0 GET STORAGE KEY
::
::MODESET KEYREG=R1,SAVEKEY=OLDKEY SET STORAGE KEY IN PSW 
::
::
::
::  WAIT=REPLY_ECB
::
:: 
::
::   MODESET MODE=PROB,KEY=NZERO   back to current TCB key   

--
Binyamin Dissen bdis...@dissensoftware.com
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...@bama.ua.edu with the message: INFO IBM-MAIN


GO TO cobol

2012-04-15 Thread Jake anderson
Hi All,

Apology for asking a basic question and Being Ignorant. We know that GO TO
statments are a big NO in many production sites and one of the reason
being it monopolizes the entire CPU. Are there any documentation explaining
about the  GO TO statements  which clearly describes how it  effects the
System CPU and performances ?

Apology again if the question is not really sensible or else it requires
more information.

Jake

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


Re: GO TO cobol

2012-04-15 Thread Sam Siegel
On Sun, Apr 15, 2012 at 8:49 PM, Jake anderson justmainfra...@gmail.comwrote:

 Hi All,

 Apology for asking a basic question and Being Ignorant. We know that GO TO
 statments are a big NO in many production sites and one of the reason
 being it monopolizes the entire CPU. Are there any documentation explaining
 about the  GO TO statements  which clearly describes how it  effects the
 System CPU and performances ?


I don't think a GO TO statement in COBOL monopolizes the CPU.  A poorly
designed program (with or without GO TO statements) can
needlessly monopolizes the CPU.

Typically GO TO statements can be avoided by having a good design.  A local
GO TO here and there is not so bad.  The non-local GO TO statements can
make long-term maintenance of a program problematic and expensive.

Saam



 Apology again if the question is not really sensible or else it requires
 more information.

 Jake

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


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


Re: GO TO cobol

2012-04-15 Thread Steve Comstock

On 4/15/2012 9:49 PM, Jake anderson wrote:

Hi All,

Apology for asking a basic question and Being Ignorant. We know that GO TO
statments are a big NO in many production sites and one of the reason
being it monopolizes the entire CPU.


Really? Well, as they say, It ain't what you know, it's what
you 'know' that ain't so




Are there any documentation explaining
about the  GO TO statements  which clearly describes how it  effects the
System CPU and performances ?

Apology again if the question is not really sensible or else it requires
more information.

Jake


The root of it all is a paper Go To Statement Considered Harmful
by E. Dijkstra; get Ed Yourdon's book Classics in Software
Engineering; lots of classic papers in there, including this one.

But the Go To in and of itself does not have a significant effect
on CPU utilization. I guess you could have a problem with:

here.
  Go to here.


Don't take anything for granted. Recieved wisdom is often based on
misunderstandings of old folklore.



--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

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


Re: GO TO cobol

2012-04-15 Thread Mike Schwab
Even a structured IF THEN ELSE END-IF or SELECT WHEN WHEN OTHERWISE
END-SELECT does gotos at the object code levels.  This is why
hyperthreading is so helpful.  One thread starts processing the GOTO
instructions and the other thread starts processing the fall through
instructions.  Once the branch is finalized, the wrong branch is
discarded.

On Sun, Apr 15, 2012 at 11:31 PM, Steve Comstock
st...@trainersfriend.com wrote:
 On 4/15/2012 9:49 PM, Jake anderson wrote:

 Hi All,

 Apology for asking a basic question and Being Ignorant. We know that GO TO
 statments are a big NO in many production sites and one of the reason
 being it monopolizes the entire CPU.


 Really? Well, as they say, It ain't what you know, it's what
 you 'know' that ain't so
deleted
-- 
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...@bama.ua.edu with the message: INFO IBM-MAIN


brand new CF LPAR

2012-04-15 Thread Munif Sadek
Dear Lister

We are replacing our mainframe i.e.  Power off old mainframe, rip it apart, 
move power supply, I/O  cages, OSA cards on to the new box and IML/IPL new CF 
and other LPARs. 

I have defined brand new Coupling datasets , ARM, BMPXMCDS, CFRM, SFM, LOGR, 
WLM dataset and have updated COUPLExx parmlib members.

Are there other gottchas I should look out for. Our  target is to Activate CF 
partition and IPL production LPAR in parallel sysplex ASAP after HW migration.

All help is appreciated. I have gone through RTFM -  setting up sysplex , 
CFSIZER tool etc. 

Regards,
Munif.

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


Re: GO TO cobol

2012-04-15 Thread Wayne Bickerdike
For devotees of Jackson Structured programming, the GOTO is a must for
POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO.

I'm a devotee FWIW

On Mon, Apr 16, 2012 at 2:43 PM, Mike Schwab mike.a.sch...@gmail.com wrote:
 Even a structured IF THEN ELSE END-IF or SELECT WHEN WHEN OTHERWISE
 END-SELECT does gotos at the object code levels.  This is why
 hyperthreading is so helpful.  One thread starts processing the GOTO
 instructions and the other thread starts processing the fall through
 instructions.  Once the branch is finalized, the wrong branch is
 discarded.

 On Sun, Apr 15, 2012 at 11:31 PM, Steve Comstock
 st...@trainersfriend.com wrote:
 On 4/15/2012 9:49 PM, Jake anderson wrote:

 Hi All,

 Apology for asking a basic question and Being Ignorant. We know that GO TO
 statments are a big NO in many production sites and one of the reason
 being it monopolizes the entire CPU.


 Really? Well, as they say, It ain't what you know, it's what
 you 'know' that ain't so
 deleted
 --
 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...@bama.ua.edu with the message: INFO IBM-MAIN



-- 
Wayne V. Bickerdike

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