Re: IODF Change...

[R.S.]

Tom Marchant pisze:

On Wed, 14 Oct 2009 09:56:46 -0700, Guy Gardoit wrote:


I like to coordinate the last two characters
of the IODF data set with the IOCDS I intend to write it to.  Example:
Create production IODF00 and write it to IOCDS A0.


Do you mean that you only use IODF00, IODF01, IODF02 and IODF03?  That
doesn't allow much flexibility.  It isn't very hard to figure out which IODF
matches an IOCDS.


There is a place in IOCDS load job, where you can put your comment. The 
comment is then visible on HMC panels.

My rule is ABCDnn, where ABCD is username and nn is IODFnn suffix.
The other rule is to avoid touching IOCDS used for last IPL and 
preferrably IOCDS containing last working configuration.


--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM book prices

[R.S.]

Gerhard Postpischil pisze:

Eric Chevalier wrote:

Out of curiosity, why would the developer want hardcopy of the
Principles of Operation when it can be downloaded for free as a PDF?


1) It's easier to take hardcopy to the bathroom, and it has all these 
chapters you'll never read anyway, just in case.


2) It's faster to flip back and forth among bookmarked pages in hardcopy 
than on screen


3) It makes a great doorstop

4) Recreational reading of hardcopy produces significantly less neck 
strain than viewing a screen


5) It can be read even when there is bright sunlight in your room


That's why we have smart device called PRINTER. It can print on both 
sides of paper, then I can bind the pages and have a book. It takes 
significantly less time than ordering process in IBM. Of course it's 
much cheaper.


Ad5: we have venetian blinds (louvres).
Ad4: My monitor have an adjustment and it is set up to be comfortable to 
my neck and backbone.
Ad3: except for commercial products there are bricks or cheaper books 
(maybe already no longer needed).
Ad2: It depends. I strongly prefer Bookreader for browsing, while 
"sequential reading" is better (for me) in paper form.

Ad1: Notebook and redundant roll ;-)

My $0.02
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JES2 Parmlib inconsistent with active definitions

[Robert A. Rosenberg]

At 10:46 -0400 on 10/14/2009, Lizette Koehler wrote about Re: JES2 
Parmlib inconsistent with active definitions:



JES2 allows almost everything to be altered by a JES2 command with the
execption of the length of the spool volume name.  That one still takes a
cold start.

What you might do is create an automation process that at JES2 startup sees
the HASP442 and HASP496 messages the indicates the parms are not in sync
with what she knew from the last warm/cold start.  Then you could know well
before an issue occurs if anything has changed.


Do all parms that are changed by commands get logged to the 
checkpoint record and thus survive a warm-start? If I alter the 
settings for a printer for example, after I warm-start will it have 
those settings or the ones from PARMLIB? I can think of a number of 
other settings of this type where the changes are intended to not be 
permanent and thus may not get logged.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM book prices

[Binyamin Dissen]

On Wed, 14 Oct 2009 15:15:53 -0500 Eric Chevalier 
wrote:

:>On Wed, 14 Oct 2009 12:39:54 -0400,
:>Pierre Fichaud  wrote:

:>>I've just talked to a Canadian product developer who wanted to order 
:>>Principles of Operation (SA22-7832-06) and the Reference Summary 
:>>(SA22-7871-05). He was quoted CAD 274.48 and CAD 50.46 respectively. I 
:>>read in this newsgroup, late last year, that this was to be corrected.

:>>Does anyone have a status on this? These prices are ridiculous.

:>Out of curiosity, why would the developer want hardcopy of the
:>Principles of Operation when it can be downloaded for free as a PDF?

It may be cheaper than printing it. And it comes nicely bound.

--
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How to concatenate

[bububut]

Hi all,

Just come back from a short break : )

Thank you all for your many replies and solutions. I'll try them out
though I still need time to learn and understand some principles of
ISPF. (Steve - the courses you provided are very attractive to me,
they are really what I need to learn. But we have some senior
mainframe specialists in the company and I think my boss will consider
them first if I require for a class...)

Best regards,
Wei



On Tue, Oct 13, 2009 at 5:13 AM, Shmuel Metz (Seymour J.)
 wrote:
> In , on 10/11/2009
>   at 11:10 PM, Dave Salt  said:
>
>>Once ISPF libraries have been allocated (ISPMLIB, ISPPLIB etc) you can't
>>change what's allocated to those DDNAMEs.
>
> You can if you first exit ISPF. However, LIBDEF is usually the superior
> approach.
>
> --
>     Shmuel (Seymour J.) Metz, SysProg and JOAT
>     ISO position; see 
> 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: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM book prices

[Ted MacNEIL]

>) It's easier to take hardcopy to the bathroom, and it has all these chapters 
>you'll never read anyway, just in case.

Funny thing.
You can print a PDF and have all the glories of a hard copy.
-
Too busy driving to stop for gas!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM book prices

[Gerhard Postpischil]

Eric Chevalier wrote:

Out of curiosity, why would the developer want hardcopy of the
Principles of Operation when it can be downloaded for free as a PDF?


1) It's easier to take hardcopy to the bathroom, and it has all 
these chapters you'll never read anyway, just in case.


2) It's faster to flip back and forth among bookmarked pages in 
hardcopy than on screen


3) It makes a great doorstop

4) Recreational reading of hardcopy produces significantly less 
neck strain than viewing a screen


5) It can be read even when there is bright sunlight in your room



Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IODF Change...

[Guy Gardoit]

But it has a lot to do with any POR that may be necessitated for some other
reason - Like MCLs, CPC failure etc.
Better safe than sorry - besides I just like to be "neat" - a Monk complex,
if you know who I mean.

And, you're right, I did not mention IPLing with the correct IODF - I've
found using LOAD** in IPLPARM works best.  YMMV

On Wed, Oct 14, 2009 at 10:30 AM, Scott Rowe  wrote:

> Gary,
>
> Writing the IOCDS has nothing to do with "out of sync" conditions.  The
> "out of sync" conditions are caused when the activation is not done to both
> hardware and software.  They can also be caused by IPLing with the incorrect
> IODF, which can be easily solved by not hard coding the IODF number in the
> LOADxx member.
>
> >>> Guy Gardoit  10/14/2009 12:56 PM >>>
> I disagree completely.
>
> To avoid easily obtained "out of sync" conditions, this process should
> always be followed for *any* IODF changes:
>
> "WAS"
>
> 1. "W"  After the new production IODF is created, use HCD to write it to
> one
> of the IOCDS in each machine.  I like to coordinate the last two characters
> of the IODF data set with the IOCDS I intend to write it to.  Example:
> Create production IODF00 and write it to IOCDS A0.
> 2. "..."   Activate the IODF in all systems using HCD - I try to avoid
> "activate configuration sysplex wide".  I'm not brave enough for that one.
> Just do one system at a time.
> 3. "S"  From one LPAR on each machine, use HCD to switch to the new IOCDS -
> same (ok, almost) as doing a POR
>
> Following this process will always avoid any chance of hardware/software
> being out of sync.
>
> Sometimes laziness is a good qulaity in a systems programmer - but not with
> hardware/software configuration changes.
>
>
>
>  CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
> confidential and privileged information intended only for the addressee.  If
> you are not the intended recipient, please be advised that you have received
> this material in error and that any forwarding, copying, printing,
> distribution, use or disclosure of the material is strictly prohibited.  If
> you have received this material in error, please (i) do not read it, (ii)
> reply to the sender that you received the message in error, and (iii) erase
> or destroy the material. Emails are not secure and can be intercepted,
> amended, lost or destroyed, or contain viruses. You are deemed to have
> accepted these risks if you communicate with us by email. Thank you.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Guy Gardoit
z/OS Systems Programming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IODF Change...

[Guy Gardoit]

True, but it usually works for me.   I do keep a running "tab", if you will,
of IODF work files.  I usually keep at least 30 lying around "just in
case".   I fortunately haven't run into a situation as you describe.   There
was one exception quite a while agao where I did not follow my usual
practice - it was when I dynamically converted all of our substantial DASD
farm from ESCON to FICON in stages - 8 ESCON to 2 FICON per CU - one IODF
gen per set.

On Wed, Oct 14, 2009 at 11:05 AM, Tom Marchant wrote:

> On Wed, 14 Oct 2009 09:56:46 -0700, Guy Gardoit wrote:
>
> >I like to coordinate the last two characters
> >of the IODF data set with the IOCDS I intend to write it to.  Example:
> >Create production IODF00 and write it to IOCDS A0.
>
> Do you mean that you only use IODF00, IODF01, IODF02 and IODF03?  That
> doesn't allow much flexibility.  It isn't very hard to figure out which
> IODF
> matches an IOCDS.
>
> I always like to keep the IODF that was used for the last IPL.
>
> Sometimes it is necessary to perform an IODF update in stages.  I once did
> about 8 in a day to remove a channel switch that was connected to printers.
>  When I was finished, each printer was on a dedicated channel that could be
> reconfigured to any LPAR, and I did it without ever having more than one
> printer unavailable at a time.
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Guy Gardoit
z/OS Systems Programming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Oct 20 Webcast: Responding to Today s Demands with a Dynamic Infrastructure

[NY]

Cross posted to ibmvm,ibmmain, linux390 for your z interests.

Hi
We had a great week last week at IBM System z Expo in Orlando.
Thanks to everyone who attended, presented, exhibited, and stopped
by the z10 booth to say hi to Julie and me and the z team.
(And if you saw our friend Sam Cohen (IBM) --same Sam, different dog.
This year's service dog-in-training, named Cupid, attended the conference
with Sam.)

Some attendees told us they had not received IBM emails about the
conference. Perhaps opting out of something causes you to miss
some other things that might be important to you.  In any case,
if you think you're missing out on things, you might want to check
your opt-in/opt-out and choice of areas of interest in your
IBM registrations.

Let's continue the z momentum with a webcast next Tuesday.

If you go the IBM Systems page, you'll see the link to
register for this webcast.
http://www.ibm.com/systems/
Responding to Today's Demands with a Dynamic Infrastructure
Tuesday, October 20, 11:00am EST

Enjoy.

Regards,
Pam C

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

[Joel C. Ewing]

On 10/14/2009 03:44 PM, Rick Fochtman wrote:
>>> 
> But you still need to prevent testers from submitting jobs with a
> production USERID. We used a TSO exit to remove USER/PASSWORD parms
> from the JOB statement. Got a better idea?
>  
>   
 Sure; don't have passwords for production jobs. Only allow them to be
 submitted by a user with surrogate access to the production user id.
 Only
 give that surrogate access to user ids that need it, e.g., scheduler.
 
>>> ---
>>> We eventually did just that. I set the password to a "private" value and
>>> never told anyone what it was. Surrogate access was the ONLY way to
>>> submit a production job, either by the automation or the production
>>> support staff.
>>>
>>> Rick
>>>   
>>
>> But if you're going to use the userid in that fashion, it makes sense to
>> go one step further and make it a RACF "PROTECTED" userid.  Then there
>> is no password to "forget" or protect, and better yet the userid cannot
>> even be used in a context where a password would be required.
>> Otherwise, someone can either intentionally or accidentally execute a
>> denial-of-service attack against your production job streams by trying
>> enough bad passwords to revoke the userid and prevent production batch
>> from running.  Also, "PROCTECTED" will prevent a rarely used production
>> userid from getting auto-revoked from excessive days from last use.
>>  
>>
> -
> 
> True enough, but the "PROTECTED" attribute didn't exist when this was
> all put in place.
> 
> Rick
> 

Granted.  You are always constrained by what's available. We have gone
through three stages since 1985 as RACF enhancements were added:

We started before the SURROGAT class was available with production
userid passwords only recorded long enough to get them embedded in
encrypted form in a program that was only available to the job scheduler
and a few other applications that needed to run jobs under production
userids.

When SURROGAT became available, we were able to phase out our encrypted
password handler for SURROGAT profiles.

When "PROTECTED" became available,  it took us a while before we
realized that it could solve a few remaining problems that rarely but
occasionally disabled some production jobs.  Adding the "PROTECTED"
attribute to production userids was completely transparent, because by
then SURROGAT profiles had already eliminated all legitimate usage of
production job userids in a context where the password was needed.
Joel

-- 
Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JES2 Parmlib inconsistent with active definitions

[Edward Jaffe]

Mark Zelden wrote:

It's nice to dream.   But why stop there?   The entire operating system
is full of places you can make dynamic changes without "hardening" them.
z/OS PARMLIB is full of them.  LNKLST, APF, EXITs, SMF, PPT, 
Subsystems, ... and the list goes on.   Then there are your major subsytems
(CICS, DB2, MQ, CICS, WAS) that also support dynamic changes.  Some 
changes survive recycles / restarts without overt action, some don't.
  


And why stop with the operating system? The HMC/SE lets you make dynamic 
changes--some that can make or break your business--without hardening 
them to the activation profiles.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JES2 Parmlib inconsistent with active definitions

[Jim Thomas]

Gil,

My code (that I earlier referred to) .. does the same ... but .. it does not

stop at just JES. Any and all 'dynamic' updates are monitored ... and
ofcourse
... recorded. 

Hooking into an existing 'change management' product / procedure would be
simple
though I have only tried it with one product. 

Please note that this was something that I wrote just for personal
satisfaction.

What I fail to understand is the need for an actual command / service that
does 
this function.

More so, given that there are 'supposedly' few that are allowed to make
'dynamic'
changes. 


My apologies for being dense.


Kind Regards,

Jim Thomas
617-233-4130
j...@thethomasresidence.us


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Wednesday, October 14, 2009 3:18 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: JES2 Parmlib inconsistent with active definitions

On Wed, 14 Oct 2009 14:46:56 -0500, Mark Zelden wrote:
>
>
>It's nice to dream.   But why stop there?   The entire operating system
>is full of places you can make dynamic changes without "hardening" them.
>z/OS PARMLIB is full of them.  LNKLST, APF, EXITs, SMF, PPT,
>Subsystems, ... and the list goes on.   Then there are your major subsytems
>(CICS, DB2, MQ, CICS, WAS) that also support dynamic changes.  Some
>changes survive recycles / restarts without overt action, some don't.
>
>This is what change control and procedures are meant for.   If you don't
>have both and enforce them, bad things will happen eventually.
>I realize it's nice to have the double check but the best tool is probably
>still a sledge hammer to the fingers of those that don't follow those
>procedures.
>
>
>
I'll dream on.  What I'd consider an excellent control
procedure is a system where:

o The master copy of the control file is updated using
  a controlled, trackable, auditable, revertible, ...
  etc. tool such as RCS, CVS, SCLM, whatever.

o The updated control file is copied into the working
  area (PARMLIB, etc.)

o A command is issued to refresh the active environment.
  I don't know how generally z/OS provides this, but
  for anything that can be dynamically modified from
  the console there should be no fundamental technical
  obstacle to refreshing from a library member.

o Dynamic updates from the console are largely prohibited.
  The procedure above should suffice except for unforseen
  and urgent situations (e.g DASD containing PARMLIB is
  inaccessible.)

o Refreshing from updated library member(s) has the
  advantage of greatly narrowing or closing the timing
  window between changes that must be coordinated.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.421 / Virus Database: 270.14.16/2435 - Release Date: 10/14/09
06:33:00

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PSW question

[Tom Marchant]

On Wed, 14 Oct 2009 15:00:49 -0500, Paul Gilmartin wrote:

>On Wed, 14 Oct 2009 12:55:37 -0500, McKown, John wrote:
>
>>> -Original Message-
>>> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant
>>> Sent: Wednesday, October 14, 2009 12:37 PM
>>>
>>> On Wed, 14 Oct 2009 11:45:49 -0500, Paul Gilmartin wrote:
>>>
>>> >And I recall one microprocessor (I forget which; Zilog? 6502?)
>>> >which packed two decimal digits in a byte as values 0x00..0x63
>>> >rather than nybble-by-nybble as on z.
>>>
>>> 6502 could do decimal addition and subtraction, one byte at a
>>> time.  It
>>> would treat each nybble as a decimal number and handle
>>> overflow as you might
>>> expect.  0x63+0x48=0x11 with a carry, which could then be
>>> added into the
>>> next higher pair of digits.
>>
>>IIRC, the z80 had an opcode which I think was DAA to do a "Decimal Adjust
for Addition". You'd do a normal ADD instruction, then a DAA. The DAA would
adjust the register so that the result contained valid decimal digits (0..9).
>>
>>0x63+0x48=0xAB from the ADD
>>then DAA would convert 0xAB to 0x11 and set the carry flag.
>>
>What am I missing here?  I would expect that after adjustment
>(or if the adjustment was incorporated in the instruction)
>the register would contain 0x47 with the carry flag set.

decimal 63+48=111

I had to go back and re-read your first post on this.  I misunderstood what
you had written there  "two decimal digits in a byte as values 0x00..0x63".

I'm not aware of any processor that does that.  The 6502 that I mentioned
stores a decimal digit in each nybble, similar to packed decimal.  I never
worked with z80 (or 8080 or 8085), but I think they all had a DAA like John
described.   I know the 8085 did and IIRC that was little more than an 8080
with on-chip clock.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Multiple jobs/same name

[Rick Fochtman]

   


But you still need to prevent testers from submitting jobs with a
production USERID. We used a TSO exit to remove USER/PASSWORD parms
from the JOB statement. Got a better idea?
 
   


Sure; don't have passwords for production jobs. Only allow them to be
submitted by a user with surrogate access to the production user id. Only
give that surrogate access to user ids that need it, e.g., scheduler.


 


---
We eventually did just that. I set the password to a "private" value and
never told anyone what it was. Surrogate access was the ONLY way to
submit a production job, either by the automation or the production
support staff.

Rick
   



But if you're going to use the userid in that fashion, it makes sense to
go one step further and make it a RACF "PROTECTED" userid.  Then there
is no password to "forget" or protect, and better yet the userid cannot
even be used in a context where a password would be required.
Otherwise, someone can either intentionally or accidentally execute a
denial-of-service attack against your production job streams by trying
enough bad passwords to revoke the userid and prevent production batch
from running.  Also, "PROCTECTED" will prevent a rarely used production
userid from getting auto-revoked from excessive days from last use.
 


-
True enough, but the "PROTECTED" attribute didn't exist when this was 
all put in place.


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IODF Change...

[carlos roberto visconde]

Omit CUADD.

2009/10/13 Jeffrey Deaver 

> I have an IODF which has a mistake in it in regards to some new storage
> we've attached...
>
> CNTLUNIT CUNUMBR=5000,PATH=((CSS(0),B3,B2,82,83,40,41,D0,D1)),*
>  UNITADD=((00,256)),CUADD=0,UNIT=2107
> IODEVICE ADDRESS=(5000,228),CUNUMBR=(5000),STADET=Y,UNIT=3390B
> IODEVICE ADDRESS=(50E4,028),CUNUMBR=(5000),STADET=Y,UNIT=3390A
>
> The CUADD statements have the wrong value.  They should be CUADD=50 etc
> instead of CUADD=0 etc.
> I altered the IODF and IPL'ed my test system, but the change has not taken.
> In other words, I still can't access the storage
> From an init job...
>
> ICK30713I UNABLE TO ALLOCATE UCB, RC=0008, RSN=0004 FROM IOSODS
> ICK31024I UNABLE TO OPEN VOLUME.
> ICK30003I FUNCTION TERMINATED. CONDITION CODE IS 12
>  12:26:0010/13/09
>
> I can't vary the paths online...
>
> IEE386I PATH(5001,40) NOT BROUGHT ONLINE
> IEE763I NAME= IECVIOPM CODE= 0004
> IOS552I PATH NOT PHYSICALLY AVAILABLE
> IEE764I END OF IEE386IRELATED MESSAGES
>
> Assuming I'm not missing some other configuration issue, I should be able
> to change the IODF, IPL that LPAR and have the change take effect, right?
> No POR necessary, right?
> What am I missing?
> Thanks.
>
>
> Jeffrey Deaver, Engineer
> Systems Engineering
> jeffrey.dea...@securian.com
> 651-665-4231(v)
> IS - "Creating competitive advantage with technology.  Providing service
> that excels."
> OSS - " Where Innovation Happens"
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

CA Support Online - Maintenance Outage

[Ken Porowski]

So it's not just IBMLink 

Maintenance Outage:
On Saturday, October 17, 2009, from 08:00 p.m. to 12:00 midnight ET
(GMT-5), CA will be conducting maintenance updates on CA Support Online.
CA Support Online will be unavailable during this time. We apologize for
any inconvenience this may cause.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JES2 Parmlib inconsistent with active definitions

[Paul Gilmartin]

On Wed, 14 Oct 2009 14:46:56 -0500, Mark Zelden wrote:
>
>
>It's nice to dream.   But why stop there?   The entire operating system
>is full of places you can make dynamic changes without "hardening" them.
>z/OS PARMLIB is full of them.  LNKLST, APF, EXITs, SMF, PPT,
>Subsystems, ... and the list goes on.   Then there are your major subsytems
>(CICS, DB2, MQ, CICS, WAS) that also support dynamic changes.  Some
>changes survive recycles / restarts without overt action, some don't.
>
>This is what change control and procedures are meant for.   If you don't
>have both and enforce them, bad things will happen eventually.
>I realize it's nice to have the double check but the best tool is probably
>still a sledge hammer to the fingers of those that don't follow those
>procedures.
>
>
>
I'll dream on.  What I'd consider an excellent control
procedure is a system where:

o The master copy of the control file is updated using
  a controlled, trackable, auditable, revertible, ...
  etc. tool such as RCS, CVS, SCLM, whatever.

o The updated control file is copied into the working
  area (PARMLIB, etc.)

o A command is issued to refresh the active environment.
  I don't know how generally z/OS provides this, but
  for anything that can be dynamically modified from
  the console there should be no fundamental technical
  obstacle to refreshing from a library member.

o Dynamic updates from the console are largely prohibited.
  The procedure above should suffice except for unforseen
  and urgent situations (e.g DASD containing PARMLIB is
  inaccessible.)

o Refreshing from updated library member(s) has the
  advantage of greatly narrowing or closing the timing
  window between changes that must be coordinated.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM book prices

[Eric Chevalier]

On Wed, 14 Oct 2009 12:39:54 -0400,
Pierre Fichaud  wrote:

>I've just talked to a Canadian product developer who wanted to order 
>Principles of Operation (SA22-7832-06) and the Reference Summary 
>(SA22-7871-05). He was quoted CAD 274.48 and CAD 50.46 respectively. I 
>read in this newsgroup, late last year, that this was to be corrected.
>
>Does anyone have a status on this? These prices are ridiculous.

Out of curiosity, why would the developer want hardcopy of the
Principles of Operation when it can be downloaded for free as a PDF?

Eric

--
Eric Chevalier  E-mail: et...@tulsagrammer.com
   Web: www.tulsagrammer.com
Is that call really worth your child's life?  HANG UP AND DRIVE!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Moving Catalog Entries

[Burrell, C. Todd (CDC/OCOO/ITSO) (CTR)]

I'm on z/OS 1.9, and I ran a REPRO MERGECAT on one high level that had
over 225,000 entries, and it took a few hours on a weekend.  I ran
separate jobs by second level, and ran about 500 separate jobs
single-threaded to get the job done. 

I'd recommend just using REPRO MERGECAT during off hours to do the move
unless the number is over 50,000 or so.  The jobs usually run pretty
quick, and I would see no reason to buy a product just to do this
move...

C. Todd Burrell, PMP, MCP
Lead z/OS Systems Programmer
ITSO
(404) 723-2017 (Cell)
 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Amerigo Baldassarri
Sent: Wednesday, October 14, 2009 3:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Moving Catalog Entries

Mainstar's Catalog RecoveryPlus (a comprehensive ICF catalog utility
toolkit) contains a feature called "Mergecat While Open" that will allow
the user to dynamically move catalog entries from one ICF catalog to
another whilst in use.

www.mainstar.com

Regards

Amerigo Baldassarri  

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Martin, Mike
Sent: Thursday, October 15, 2009 1:22 AM
To: IBM-MAIN@bama.ua.edu
Subject: Moving Catalog Entries

All,

 

I am looking for a way to move ICF catalog entries from one catalog to
another.  I have thousands of entries to move because we are
restructuring our catalogs.  I know I can use REPRO MERGECAT, but we
have MANY datasets that are in-use on this production system.  Is there
a better way than REPRO MERGECAT for moving production catalog entries
on a live system?  I would like to be able to do these moves during our
normal production window (no additional downtime).

 

Any thoughts/ideas are greatly appreciated.  

 

Mike Martin

This email may contain confidential and privileged material for
the sole use of the intended recipient. If you are not the intended
recipient, please contact the sender and delete all copies. Any review
or distribution by others is strictly prohibited. Personal emails are
restricted by policy of the State Employees' Credit Union (SECU).
Therefore SECU specifically disclaims any responsibility or liability
for any personal information or opinions of the author expressed in this
email.



--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PSW question

[Paul Gilmartin]

On Wed, 14 Oct 2009 12:55:37 -0500, McKown, John wrote:

>> -Original Message-
>> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant
>> Sent: Wednesday, October 14, 2009 12:37 PM
>>
>> On Wed, 14 Oct 2009 11:45:49 -0500, Paul Gilmartin wrote:
>>
>> >And I recall one microprocessor (I forget which; Zilog? 6502?)
>> >which packed two decimal digits in a byte as values 0x00..0x63
>> >rather than nybble-by-nybble as on z.
>>
>> 6502 could do decimal addition and subtraction, one byte at a
>> time.  It
>> would treat each nybble as a decimal number and handle
>> overflow as you might
>> expect.  0x63+0x48=0x11 with a carry, which could then be
>> added into the
>> next higher pair of digits.
>
>IIRC, the z80 had an opcode which I think was DAA to do a "Decimal Adjust for 
>Addition". You'd do a normal ADD instruction, then a DAA. The DAA would adjust 
>the register so that the result contained valid decimal digits (0..9).
>
>0x63+0x48=0xAB from the ADD
>then DAA would convert 0xAB to 0x11 and set the carry flag.
>
What am I missing here?  I would expect that after adjustment
(or if the adjustment was incorporated in the instruction)
the register would contain 0x47 with the carry flag set.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JES2 Parmlib inconsistent with active definitions

[Jim Thomas]

I have something that already does this ... but ... that said .. are you 
speaking of JES only ?? ... or ... globally ?. 


Kind Regards,

Jim Thomas
617-233-4130
j...@thethomasresidence.us

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Mark Zelden
Sent: Wednesday, October 14, 2009 2:47 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: JES2 Parmlib inconsistent with active definitions

On Wed, 14 Oct 2009 14:40:17 -0400, Arthur T.  wrote:

>On 14 Oct 2009 03:11:45 -0700, in bit.listserv.ibm-main
>(Message-ID:)
>luc.mart...@kbc.be (Luc Martens  , KBC) wrote:
>
>>we recently had some incidents which caused us a lot of
>>debugging before we noticed what was going one.
>>Some JES2 parmlib definitions did not correspond with the
>>actual state of the definitions in JES2.
>
>  This doesn't exactly address your issue, but is it
>time (and is it feasible) to open a requirement to
>IBM?  The requirement would be for a JES2 command which
>would create a valid parmlib that matched the current
>settings.
>




It's nice to dream.   But why stop there?   The entire operating system
is full of places you can make dynamic changes without "hardening" them.
000z/OS PARMLIB is full of them.  LNKLST, APF, EXITs, SMF, PPT, 
Subsystems, ... and the list goes on.   Then there are your major subsytems
(CICS, DB2, MQ, CICS, WAS) that also support dynamic changes.  Some 
changes survive recycles / restarts without overt action, some don't.

This is what change control and procedures are meant for.   If you don't
have both and enforce them, bad things will happen eventually. 
I realize it's nice to have the double check but the best tool is probably
still a sledge hammer to the fingers of those that don't follow those 
procedures.



Mark 
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.421 / Virus Database: 270.14.16/2435 - Release Date: 10/14/09
06:33:00

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Moving Catalog Entries

[Amerigo Baldassarri]

Mainstar's Catalog RecoveryPlus (a comprehensive ICF catalog utility toolkit) 
contains a feature called "Mergecat While Open" that will allow the user to 
dynamically move catalog entries from one ICF catalog to another whilst in use.

www.mainstar.com

Regards

Amerigo Baldassarri  

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Martin, Mike
Sent: Thursday, October 15, 2009 1:22 AM
To: IBM-MAIN@bama.ua.edu
Subject: Moving Catalog Entries

All,

 

I am looking for a way to move ICF catalog entries from one catalog to
another.  I have thousands of entries to move because we are
restructuring our catalogs.  I know I can use REPRO MERGECAT, but we
have MANY datasets that are in-use on this production system.  Is there
a better way than REPRO MERGECAT for moving production catalog entries
on a live system?  I would like to be able to do these moves during our
normal production window (no additional downtime).

 

Any thoughts/ideas are greatly appreciated.  

 

Mike Martin

This email may contain confidential and privileged material for the sole 
use of the intended recipient. If you are not the intended recipient, please 
contact the sender and delete all copies. Any review or distribution by others 
is strictly prohibited. Personal emails are restricted by policy of the State 
Employees' Credit Union (SECU).  Therefore SECU specifically disclaims any 
responsibility or liability for any personal information or opinions of the 
author expressed in this email.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JES2 Parmlib inconsistent with active definitions

[Mark Zelden]

On Wed, 14 Oct 2009 14:40:17 -0400, Arthur T.  wrote:

>On 14 Oct 2009 03:11:45 -0700, in bit.listserv.ibm-main
>(Message-ID:)
>luc.mart...@kbc.be (Luc Martens  , KBC) wrote:
>
>>we recently had some incidents which caused us a lot of
>>debugging before we noticed what was going one.
>>Some JES2 parmlib definitions did not correspond with the
>>actual state of the definitions in JES2.
>
>  This doesn't exactly address your issue, but is it
>time (and is it feasible) to open a requirement to
>IBM?  The requirement would be for a JES2 command which
>would create a valid parmlib that matched the current
>settings.
>




It's nice to dream.   But why stop there?   The entire operating system
is full of places you can make dynamic changes without "hardening" them.
z/OS PARMLIB is full of them.  LNKLST, APF, EXITs, SMF, PPT, 
Subsystems, ... and the list goes on.   Then there are your major subsytems
(CICS, DB2, MQ, CICS, WAS) that also support dynamic changes.  Some 
changes survive recycles / restarts without overt action, some don't.

This is what change control and procedures are meant for.   If you don't
have both and enforce them, bad things will happen eventually. 
I realize it's nice to have the double check but the best tool is probably
still a sledge hammer to the fingers of those that don't follow those 
procedures.



Mark 
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JES2 Parmlib inconsistent with active definitions

[Arthur T.]

On 14 Oct 2009 03:11:45 -0700, in bit.listserv.ibm-main 
(Message-ID:) 
luc.mart...@kbc.be (Luc Martens  , KBC) wrote:


we recently had some incidents which caused us a lot of 
debugging before we noticed what was going one.
Some JES2 parmlib definitions did not correspond with the 
actual state of the definitions in JES2.


 This doesn't exactly address your issue, but is it 
time (and is it feasible) to open a requirement to 
IBM?  The requirement would be for a JES2 command which 
would create a valid parmlib that matched the current 
settings.


 Business reasons:

1.  As stated, it's easy for the existing parmlib to get 
out of sync with actual, used settings.  It would be good 
to know that for a cold start the settings would match what 
had been in use before.  Cold start could be for some 
planned reason, at one's normal site or at a DR 
site.  (Time is precious at a DR test; you don't want to 
waste it in problem determination only to find that the 
root cause was reverted parmlib changes.)


2.  A shop could use two of these taken at different times 
to compare and verify that all and only the authorized 
changes had been made.  Since the output parms would be 
expected to be in some fixed, defined order, the compare 
would be easy.




--
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" intergate "dot" com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Alternatives to TSM for Linux under Z/os DR?

[Jim Marshall]

>
>  Since TSM has been stabilized by IBM, we are looking for alternatives to 
Backup and DR solutions for our Linux environment. We currently run FDR full 
volume backups during low use periods but that results in 'fuzzy' backups 
unless the Linux server is down at the time of backup.
>
Last week I was invited as a guest speaker to the IBM TopGun School and 
arrived early. I sat in on a presentation talking about all the great things 
which 
is going to be available for TSM for z/OS Version 6.  Presently I run TSM V5 
and have seen things about the death of TSM for z/OS with the excuse they 
could not get z/OS-DB2 to perform very well and gave up trying.

I challenged the speaker with the above info and there seems to be some 
question within IBM as to what is the status of TSM for z/OS V6. I too had 
read the comment about IBM admiting the decision would really upset many 
users of the product. I sent the speaker off into TSM land to find out if 
indeed 
I too will have to look elsewhere outside of IBM for a TSM like product. 

Stay tuned TSM fans and hopefully IBM is rethinking a questionable choice. 

jim  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Instream Commands

[Mark Baron]

Mike & Walt - 

Thanks for the responses - I did some further experimenting and confirmed
that the instream command is scheduled using the execution ID.

Appreciate the responses.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IODF Change...

[Tom Marchant]

On Wed, 14 Oct 2009 09:56:46 -0700, Guy Gardoit wrote:

>I like to coordinate the last two characters
>of the IODF data set with the IOCDS I intend to write it to.  Example:
>Create production IODF00 and write it to IOCDS A0.

Do you mean that you only use IODF00, IODF01, IODF02 and IODF03?  That
doesn't allow much flexibility.  It isn't very hard to figure out which IODF
matches an IOCDS.

I always like to keep the IODF that was used for the last IPL.

Sometimes it is necessary to perform an IODF update in stages.  I once did
about 8 in a day to remove a channel switch that was connected to printers.
 When I was finished, each printer was on a dedicated channel that could be
reconfigured to any LPAR, and I did it without ever having more than one
printer unavailable at a time.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PSW question

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tom Marchant
> Sent: Wednesday, October 14, 2009 12:37 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: PSW question
> 
> On Wed, 14 Oct 2009 11:45:49 -0500, Paul Gilmartin wrote:
> 
> >And I recall one microprocessor (I forget which; Zilog? 6502?)
> >which packed two decimal digits in a byte as values 0x00..0x63
> >rather than nybble-by-nybble as on z.
> 
> 6502 could do decimal addition and subtraction, one byte at a 
> time.  It
> would treat each nybble as a decimal number and handle 
> overflow as you might
> expect.  0x63+0x48=0x11 with a carry, which could then be 
> added into the
> next higher pair of digits.
> 
> -- 
> Tom Marchant

IIRC, the z80 had an opcode which I think was DAA to do a "Decimal Adjust for 
Addition". You'd do a normal ADD instruction, then a DAA. The DAA would adjust 
the register so that the result contained valid decimal digits (0..9).

0x63+0x48=0xAB from the ADD
then DAA would convert 0xAB to 0x11 and set the carry flag.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PSW question

[Tom Marchant]

On Wed, 14 Oct 2009 11:45:49 -0500, Paul Gilmartin wrote:

>And I recall one microprocessor (I forget which; Zilog? 6502?)
>which packed two decimal digits in a byte as values 0x00..0x63
>rather than nybble-by-nybble as on z.

6502 could do decimal addition and subtraction, one byte at a time.  It
would treat each nybble as a decimal number and handle overflow as you might
expect.  0x63+0x48=0x11 with a carry, which could then be added into the
next higher pair of digits.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IODF Change...

[Scott Rowe]

Sorry Guy, I realized I typed your name incorrectly only after I had hit send.

>>> Guy Gardoit  10/14/2009 12:56 PM >>>
I disagree completely.

To avoid easily obtained "out of sync" conditions, this process should
always be followed for *any* IODF changes:

"WAS"

1. "W"  After the new production IODF is created, use HCD to write it to one
of the IOCDS in each machine.  I like to coordinate the last two characters
of the IODF data set with the IOCDS I intend to write it to.  Example:
Create production IODF00 and write it to IOCDS A0.
2. "..."   Activate the IODF in all systems using HCD - I try to avoid
"activate configuration sysplex wide".  I'm not brave enough for that one.
Just do one system at a time.
3. "S"  From one LPAR on each machine, use HCD to switch to the new IOCDS -
same (ok, almost) as doing a POR

Following this process will always avoid any chance of hardware/software
being out of sync.

Sometimes laziness is a good qulaity in a systems programmer - but not with
hardware/software configuration changes.



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Moving Catalog Entries

[Darth Keller]

>>I am looking for a way to move ICF catalog entries from one catalog to
>>another.  I have thousands of entries to move because we are
>>restructuring our catalogs.  I know I can use REPRO MERGECAT, but we
>>have MANY datasets that are in-use on this production system.  Is there
>>a better way than REPRO MERGECAT for moving production catalog entries
>>on a live system?  I would like to be able to do these moves during our
>>normal production window (no additional downtime).

>>Any thoughts/ideas are greatly appreciated. 
>>Mike Martin

I've been restructuring our catalogs for TSO users for the past 4-5 weeks 
using Dino-Software's TREX product.   I run the TREX job once with the 
following cards:
REPRO - 
   INFORMATIONONLY - 
   DSN(- 
   ID0001.**,  - 
   ID0002.**,  - 
   ID0003.**   - 
 )  - 
   MOVEALIAS(AUTO) - 
   DETAIL  - 
   ENQTEST(YES)- 
   MERGECAT- 
   OUTBCS(UCAT.TSO.S)  - 
   MASTERCATALOG(MCAT.PROD,MCAT.TECH)

The first time, it checks to determine if there are any datasets under the 
specified aliases in use and gives me a CC008 if there are.  I remove the 
ones in use to do later & run it again to ensure I get zero's.  Once I do, 
I remove the INFORMATIONONLY parm and, slick as a whistle, it moves the 
catalog entries for each of the ID's into the OUTBCS and then updates the 
alias entries in my two masters.

Very slick - I've been doing it in my 'spare' time, a couple dozen ID's at 
a time. I've run through a couple of hundred iterations of the job. I did 
have a small issue this morning which caused one of our tech guys to have 
an issue logging onto one of our tech LPARs and we were told we need to 
get the PTF for APAR OA28245 which deals with hanging SYSZVVDS enqueues 
on.

For the aliases which won't be so co-operative (translation: in use nearly 
all the time), we have Dino's Teradon product which I haven't used yet. 
I'd be interested in hearing from anyone who has used it.
**
This e-mail message and all attachments transmitted with it may contain legally 
privileged and/or confidential information intended solely for the use of the 
addressee(s). If the reader of this message is not the intended recipient, you 
are hereby notified that any reading, dissemination, distribution, copying, 
forwarding or other use of this message or its attachments is strictly 
prohibited. If you have received this message in error, please notify the 
sender immediately and delete this message and all copies and backups thereof.

Thank you.
*m

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IODF Change...

[Scott Rowe]

Gary,
 
Writing the IOCDS has nothing to do with "out of sync" conditions.  The "out of 
sync" conditions are caused when the activation is not done to both hardware 
and software.  They can also be caused by IPLing with the incorrect IODF, which 
can be easily solved by not hard coding the IODF number in the LOADxx member.

>>> Guy Gardoit  10/14/2009 12:56 PM >>>
I disagree completely.

To avoid easily obtained "out of sync" conditions, this process should
always be followed for *any* IODF changes:

"WAS"

1. "W"  After the new production IODF is created, use HCD to write it to one
of the IOCDS in each machine.  I like to coordinate the last two characters
of the IODF data set with the IOCDS I intend to write it to.  Example:
Create production IODF00 and write it to IOCDS A0.
2. "..."   Activate the IODF in all systems using HCD - I try to avoid
"activate configuration sysplex wide".  I'm not brave enough for that one.
Just do one system at a time.
3. "S"  From one LPAR on each machine, use HCD to switch to the new IOCDS -
same (ok, almost) as doing a POR

Following this process will always avoid any chance of hardware/software
being out of sync.

Sometimes laziness is a good qulaity in a systems programmer - but not with
hardware/software configuration changes.



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Moving Catalog Entries

[Gibney, Dave]

  And CR+ formerly Mainstar, not RocketSoft

Dave Gibney
Information Technology Services
Washington State University

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of McKown, John
> Sent: Wednesday, October 14, 2009 9:54 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Moving Catalog Entries
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Martin, Mike
> > Sent: Wednesday, October 14, 2009 9:22 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Moving Catalog Entries
> >
> > All,
> >
> > I am looking for a way to move ICF catalog entries from one catalog
> to
> > another.  I have thousands of entries to move because we are
> > restructuring our catalogs.  I know I can use REPRO MERGECAT, but we
> > have MANY datasets that are in-use on this production system.
> >  Is there
> > a better way than REPRO MERGECAT for moving production catalog
> entries
> > on a live system?  I would like to be able to do these moves
> > during our
> > normal production window (no additional downtime).
> >
> > Any thoughts/ideas are greatly appreciated.
> >
> > Mike Martin
> 
> I am fairly sure that Dino Software's T-REXX will do this. I don't
know
> of a "freebie".
> 
> --
> John McKown
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets(r)
> 
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone * (817)-961-6183 cell
> john.mck...@healthmarkets.com * www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain confidential
or
> proprietary information. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the
> original message. HealthMarkets(r) is the brand name for products
> underwritten and issued by the insurance subsidiaries of
HealthMarkets,
> Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life
> Insurance Company of TennesseeSM and The MEGA Life and Health
Insurance
> Company.SM
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IODF Change...

[Guy Gardoit]

This article is very confusing - HCD is not that complicated.  You'd be wise
to ignore it.


On Tue, Oct 13, 2009 at 1:27 PM, Jeffrey Deaver  wrote:

> >I have an IODF which has a mistake in it in regards to some new storage
> >we've attached...
> >Assuming I'm not missing some other configuration issue, I should be able
> >to change the IODF, IPL that LPAR and have the change take effect, right?
> >No POR necessary, right?
> >What am I missing?
>
> See, as soon as I send the question, I find what I need.  This article
> seems to explain it quite well...
>
> http://www.zjournal.com/index.cfm?section=article&aid=375#
>
> ... and points out a few things I'm missing.
>
> Jeffrey Deaver, Engineer
> Systems Engineering
> jeffrey.dea...@securian.com
> 651-665-4231(v)
> IS - "Creating competitive advantage with technology.  Providing service
> that excels."
> OSS - " Where Innovation Happens"
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Guy Gardoit
z/OS Systems Programming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Moving Catalog Entries

[Larry Crilley]

REPRO MERGECAT would move the entries that are OPEN, but would get an error
when attempting to remove the record from the SOURCE catalog.  But, the real
problem for these OPEN datasets (assuming they are VSAM) is twofold.
Assuming you moved the entries for these OPEN files to another catalog:

 

1.  If an I/O causes an extent, the I/O would fail as VSAM has the catalog's
ACB address in an OPEN control block.  This was established when the file
was opened and will thus point to the original source catalog. Since the
records for this dataset now reside in a different catalog, the I/O fails.

 

2.  Part of the SYSVSAM ENQ RNAME structure contains the catalog name.  If
you move an entry that is OPEN to another catalog, you just violated the
entire SHAREOPTION functionality.  For example, if your dataset is defined
with SHR(2,3) and the file is currently opened for OUTPUT, once you move the
entries to another catalog, another user would be able to successfully open
the same file for output.  You would now have 2 users who have opened the
same file for OUTPUT and the file is defined with SHR(2,3).  

 

Sorry to say, but you would need a vendor tool to accomplish the move while
datasets are OPEN.  Dino-Software has such a tool: Teradon.  I'd be happy to
discuss this with you offline.  Feel free to call and/or email me anytime.

 

Larry Crilley

Dino-Software Corporation

800.480.DINO

412.366.3566

 
 www.dino-software.com

 

 http://www.dino-software.com/trex_factsheet.php> T-REX -
Superior ICF catalog mgmt with full Tape support and HSM Auditing
 http://www.dino-software.com/reorgadon_factsheet.php>
REORGadon - First ever online REORG for HSM
 http://www.dino-software.com/teradon_factsheet.php>
TERADON - First ever REPRO MERGECAT While-OPEN 
 http://www.dino-software.com> XTINCT - Secure DASD/TAPE
data eradication
 http://www.dino-software.com/rtd_factsheet.php> RTD -
DASD Real Time Defrag
 http://www.dino-software.com/dal_details.php> DAL - DINO
healthcheck Analysis service for Legato 
 http://www.dino-software.com/sentinel_factsheet.php>
SENTINEL - Real-time FTP Management. All Secure, all the time.

 

 

 

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Martin, Mike
Sent: Wednesday, October 14, 2009 10:22 AM
To: IBM-MAIN@bama.ua.edu
Subject: Moving Catalog Entries

 

All,

 

 

 

I am looking for a way to move ICF catalog entries from one catalog to

another.  I have thousands of entries to move because we are

restructuring our catalogs.  I know I can use REPRO MERGECAT, but we

have MANY datasets that are in-use on this production system.  Is there

a better way than REPRO MERGECAT for moving production catalog entries

on a live system?  I would like to be able to do these moves during our

normal production window (no additional downtime).

 

 

 

Any thoughts/ideas are greatly appreciated.  

 

 

 

Mike Martin

 

This email may contain confidential and privileged material for the
sole use of the intended recipient. If you are not the intended recipient,
please contact the sender and delete all copies. Any review or distribution
by others is strictly prohibited. Personal emails are restricted by policy
of the State Employees' Credit Union (SECU).  Therefore SECU specifically
disclaims any responsibility or liability for any personal information or
opinions of the author expressed in this email.

 



 

--

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

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

Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IODF Change...

[Guy Gardoit]

I disagree completely.

To avoid easily obtained "out of sync" conditions, this process should
always be followed for *any* IODF changes:

"WAS"

1. "W"  After the new production IODF is created, use HCD to write it to one
of the IOCDS in each machine.  I like to coordinate the last two characters
of the IODF data set with the IOCDS I intend to write it to.  Example:
Create production IODF00 and write it to IOCDS A0.
2. "..."   Activate the IODF in all systems using HCD - I try to avoid
"activate configuration sysplex wide".  I'm not brave enough for that one.
Just do one system at a time.
3. "S"  From one LPAR on each machine, use HCD to switch to the new IOCDS -
same (ok, almost) as doing a POR

Following this process will always avoid any chance of hardware/software
being out of sync.

Sometimes laziness is a good qulaity in a systems programmer - but not with
hardware/software configuration changes.

On Wed, Oct 14, 2009 at 4:49 AM, Scott Rowe  wrote:

> I agree completely.
>
> >>> Tom Marchant  10/14/09 7:42 AM >>>
>  On Tue, 13 Oct 2009 16:52:58 -0400, Scott Rowe wrote:
>
> >There is no need to change an IOCDS, it is enough to ACTIVATE the IODF.
>
> To clarify, there is no need to create an IOCDS to activate the IODF.  It
> is
> a good idea to create an IOCDS when you think you have the IODF ready so
> that the next time you perform a POR the correct hardware definitions will
> be loaded into the HSA.
>
> Of course, if you never need to perform a POR, the IOCDS is not needed at
> all.  However, if there is ever a need to perform a POR, you want an IOCDS
> that is reasonably close to the IODF that you have been running with.
>
> --
> Tom Marchant
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>
>
> CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
> confidential and privileged information intended only for the addressee.  If
> you are not the intended recipient, please be advised that you have received
> this material in error and that any forwarding, copying, printing,
> distribution, use or disclosure of the material is strictly prohibited.  If
> you have received this material in error, please (i) do not read it, (ii)
> reply to the sender that you received the message in error, and (iii) erase
> or destroy the material. Emails are not secure and can be intercepted,
> amended, lost or destroyed, or contain viruses. You are deemed to have
> accepted these risks if you communicate with us by email. Thank you.
>
> --
>  For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Guy Gardoit
z/OS Systems Programming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Moving Catalog Entries

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Martin, Mike
> Sent: Wednesday, October 14, 2009 9:22 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Moving Catalog Entries
> 
> All,
> 
> I am looking for a way to move ICF catalog entries from one catalog to
> another.  I have thousands of entries to move because we are
> restructuring our catalogs.  I know I can use REPRO MERGECAT, but we
> have MANY datasets that are in-use on this production system. 
>  Is there
> a better way than REPRO MERGECAT for moving production catalog entries
> on a live system?  I would like to be able to do these moves 
> during our
> normal production window (no additional downtime).
> 
> Any thoughts/ideas are greatly appreciated.  
> 
> Mike Martin

I am fairly sure that Dino Software's T-REXX will do this. I don't know of a 
"freebie".

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PSW question

[Paul Gilmartin]

On Wed, 14 Oct 2009 09:38:03 -0400, Thompson, Steve wrote:
>
>
>
>"Packed ASCII"? That sounds "interesting", do you know where I could
>find a defination? I know that the z now has a PACK ASCII and UNPACK
>ASCII instructions.
>
>
>
>Find a WANG/VS manual set. WANG did packed arithmetic on their ASCII
>based systems. They implemented the Decimal Instruction set (similar to
>S/360).
>
And I recall one microprocessor (I forget which; Zilog? 6502?)
which packed two decimal digits in a byte as values 0x00..0x63
rather than nybble-by-nybble as on z.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Outsourcing your Computer Center to IBM ?

[Hal Merritt]

Of course, that may have been the intent, but we'll never know for sure. But 
these days I'd think that it is prudent to assume that any email you send has 
the potential to be widely published.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Graeme Gibson
Sent: Wednesday, October 14, 2009 2:13 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Outsourcing your Computer Center to IBM ?

Yes Andrew, the quoted source for the CEO was "in an internal memo", 
but one worded, I'd suggest, with an eye to it becoming public.

Graeme.




At 07:27 AM 14/10/2009, you wrote:
>Graeme Gibson wrote:
>
>>Distributing blame should have been kept entirely behind closed doors.
>>He looked weak blowing off in public that way.
>
>Did he do it in public? The way I read the original report I thought 
>it was an internal email that was leaked.
>
>--
>Andrew Rowley
> 
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JES2 Parmlib inconsistent with active definitions

[Lizette Koehler]

JES2 allows almost everything to be altered by a JES2 command with the
execption of the length of the spool volume name.  That one still takes a
cold start.

What you might do is create an automation process that at JES2 startup sees
the HASP442 and HASP496 messages the indicates the parms are not in sync
with what she knew from the last warm/cold start.  Then you could know well
before an issue occurs if anything has changed.  If that message does
appear, send your group an email to that effect.

You will then be able to find out the answer to the questions
  What was changed
  When was it changed
  And what group /person changed it.

Lizette


> Hi guys,
> we recently had some incidents which caused us a lot of debugging before
we
> noticed what was going one.
> Some JES2 parmlib definitions did not correspond with the actual state of
the
> definitions in JES2.
> I'm wondering if someone has had already the same problem, and is having
an
> automated way to check for differences between parmlib and actual jes2
defs
> (which have been dynamically changed).
> We are thinking on querying all jes2 defs, and checking then with defs in
> parmlib. Should someone has already written this and willing to share,
that
> would be very much appreciated.
> Any other ideas are also welcome.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JES2 Parmlib inconsistent with active definitions

[Luc Martens (KBC)]

Marc, overtime we changed a lot of parms dynamically and did apparently not 
always updated our parmlib.
I need to crosscheck this, and prevent this from happening in the future.
So I was thinking on writing an rexx health-check.
Currently, we could be in a very unpleasant situation if we need to have a cold 
start (rather rare, but you never know).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Moving Catalog Entries

[Martin, Mike]

All,

 

I am looking for a way to move ICF catalog entries from one catalog to
another.  I have thousands of entries to move because we are
restructuring our catalogs.  I know I can use REPRO MERGECAT, but we
have MANY datasets that are in-use on this production system.  Is there
a better way than REPRO MERGECAT for moving production catalog entries
on a live system?  I would like to be able to do these moves during our
normal production window (no additional downtime).

 

Any thoughts/ideas are greatly appreciated.  

 

Mike Martin

This email may contain confidential and privileged material for the sole 
use of the intended recipient. If you are not the intended recipient, please 
contact the sender and delete all copies. Any review or distribution by others 
is strictly prohibited. Personal emails are restricted by policy of the State 
Employees' Credit Union (SECU).  Therefore SECU specifically disclaims any 
responsibility or liability for any personal information or opinions of the 
author expressed in this email.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Instream Commands

[Walt Farrell]

On Wed, 14 Oct 2009 10:45:47 +0200, Mike Shorkend 
wrote:

>AFAIK, It is the submitter. I tried issuing a protected(via RACF OPERCMDS
>class) command from a job submitted by an unauthorized user and it failed
>with a ICH408I message.

Commands contained within a job's JCL should run as though issued by the
execution user ID (not necessarily the same as the submitting user ID).

-- 
Walt Farrell, CISSP
IBM STSM, z/OS Security Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Ron Ferguson's VSAM Book

[Richards, Robert B.]

I also have an autographed copy, but I will not part with mine!

Bob


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Chris Edwards
Sent: Wednesday, October 14, 2009 9:35 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Ron Ferguson's VSAM Book

I have a signed copy ... open to offers !!!

Regards,
Chris

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PSW question

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of McKown, John
Sent: Wednesday, October 14, 2009 8:09 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: PSW question



"Packed ASCII"? That sounds "interesting", do you know where I could
find a defination? I know that the z now has a PACK ASCII and UNPACK
ASCII instructions.



Find a WANG/VS manual set. WANG did packed arithmetic on their ASCII
based systems. They implemented the Decimal Instruction set (similar to
S/360).

Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Ron Ferguson's VSAM Book

[Chris Edwards]

I have a signed copy ... open to offers !!!

Regards,
Chris
 
 
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Vince Getgood
Sent: Wednesday, 7 October 2009 6:30 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Ron Ferguson's VSAM Book

I found 1 used on Amazon for $100.

Look for :-

Author Ronald K Ferguson

ASIN: B0006YOHFO

Sounds like a bargain to me! 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic

[Howard Brazee]

On 13 Oct 2009 14:20:58 -0700, john.mck...@healthmarkets.com (McKown,
John) wrote:

>I'd say that, to me, it seems that IBM "likes" AIX and Linux. 
>The iSeries people complain the same way that we do about IBM 
>not doing much to encourage people to adopt the i. I don't know 
>any AIX people, but it wouldn't really surprise me to learn that IBM 
>would generally prefer Linux because it costs them much less to 
>develop and support it. FSF basically enhances and supports the 
>non-kernel portion and various other groups support the kernel. 
>IBM only needs to support the IBM specific portions of the kernel, 
>not the entire thing.

That direction could also be useful in selling upgrades to users of
data warehouses and other large databases.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Calulators or Computers? (Was: Outsourcing your Computer Center to IBM ?)

[Howard Brazee]

On 13 Oct 2009 14:00:46 -0700, et...@tulsagrammer.com (Eric Chevalier)
wrote:

>>Anyway in this day and age TI or HP  calculators can do most of
>>the preflight calculations...
>
>It's not quite that simple. Sure, your TI or HP probably could perform
>the calculations, but they don't integrate very well with the rest of
>the system. Once you've figured out your basic payload and center of
>gravity, now you need to order fuel. How much fuel? You don't want too
>much, since excess fuel travels at air freight rates.  Obviously the
>outputs from weight & balance become input to your fuel calculations.
>But fuel requirements are also also a function of weather along the
>route. So you'd also like to tap into the weather forecasting system
>as inputs to the fuel system.

I haven't stayed current with flight technology - I still have my old
draw-on "flight computer" from my flying days in the USAF.   It did
the job, but obviously not as well as what's available now.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PSW question

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.)
> Sent: Tuesday, October 13, 2009 7:31 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: PSW question
> 
> In <660412.68830...@web54601.mail.re2.yahoo.com>, on 10/10/2009
>at 03:25 PM, Ed Gould  said:
> 
> >There is a bit reserved in the PSW for "ASCII".
> 
> On S/360, yes, but on anything later?
> 
> >Does anyone know if this was ever used
> 
> Not that I'm aware of. It was intended to allow decimal arithmetic on
> packed ASCII data.
> 
> -- 
>  Shmuel (Seymour J.) Metz, SysProg and JOAT

"Packed ASCII"? That sounds "interesting", do you know where I could find a 
defination? I know that the z now has a PACK ASCII and UNPACK ASCII 
instructions.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: JES2 Parmlib inconsistent with active definitions

[Mark Zelden]

On Wed, 14 Oct 2009 05:09:36 -0500, Luc Martens (KBC) 
wrote:

>Hi guys,
>we recently had some incidents which caused us a lot of debugging before we
>noticed what was going one.
>Some JES2 parmlib definitions did not correspond with the actual state of the
>definitions in JES2.
>I'm wondering if someone has had already the same problem, and is having an
>automated way to check for differences between parmlib and actual jes2 defs
>(which have been dynamically changed).
>We are thinking on querying all jes2 defs, and checking then with defs in
>parmlib. Should someone has already written this and willing to share, that
>would be very much appreciated.
>Any other ideas are also welcome.
>Regards, Luc.


How often are they changing and why?  Many shops (including us) use dynamic
proclib definitions, but don't routinely change them.  Or is this just needed 
as a "one and done" action from a problem postmortem?


Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: additional processor?

[Mark Zelden]

On Wed, 14 Oct 2009 02:43:35 -0500, Brian Westerman
 wrote:

>Also, if you are
>running (or going to run) z/OS 1.11, there is new support for using them
>interchangeably with each other (zIIPs and zAAPs). 

Not quite.  The support is for zAAP on zIIP.  Not the other way around. 
So if you have a small Java workload for example (there are some other
zAAP exploiters, like XML) and can't justify a zAAP based on that alone,
it may be beneficial to get a zIIP still since it can run the zAAP workload
on the zIIP also. 

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PSW question

[Tom Marchant]

On Tue, 13 Oct 2009 19:31:19 -0500, Shmuel Metz (Seymour J.) wrote:

>In <660412.68830...@web54601.mail.re2.yahoo.com>, on 10/10/2009
>   at 03:25 PM, Ed Gould  said:
>
>>There is a bit reserved in the PSW for "ASCII".
>
>On S/360, yes, but on anything later?
>
>>Does anyone know if this was ever used
>
>Not that I'm aware of. It was intended to allow decimal arithmetic on
>packed ASCII data.

More precisely, I think, it causes UNPK to insert B'0101' in bits 0-3 of
each byte (except the last) rather than B''.  AFAICT, when an ASCII
number is PACKed, the sign bit contains B'0101', which is not a valid sign.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IODF Change...

[Scott Rowe]

I agree completely.

>>> Tom Marchant  10/14/09 7:42 AM >>>
On Tue, 13 Oct 2009 16:52:58 -0400, Scott Rowe wrote:

>There is no need to change an IOCDS, it is enough to ACTIVATE the IODF.

To clarify, there is no need to create an IOCDS to activate the IODF.  It is
a good idea to create an IOCDS when you think you have the IODF ready so
that the next time you perform a POR the correct hardware definitions will
be loaded into the HSA.

Of course, if you never need to perform a POR, the IOCDS is not needed at
all.  However, if there is ever a need to perform a POR, you want an IOCDS
that is reasonably close to the IODF that you have been running with.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IODF Change...

[Tom Marchant]

On Tue, 13 Oct 2009 16:52:58 -0400, Scott Rowe wrote:

>There is no need to change an IOCDS, it is enough to ACTIVATE the IODF.

To clarify, there is no need to create an IOCDS to activate the IODF.  It is
a good idea to create an IOCDS when you think you have the IODF ready so
that the next time you perform a POR the correct hardware definitions will
be loaded into the HSA.

Of course, if you never need to perform a POR, the IOCDS is not needed at
all.  However, if there is ever a need to perform a POR, you want an IOCDS
that is reasonably close to the IODF that you have been running with.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: additional processor?

[David Cartwright]

If your workload is mainly DB2 and CICS  these products used to run on other 
platforms.  Have you investigated a Windows Server? To keep it IBM you could 
look at a P series running AIX or Linux. May be faster and cheaper than Z.
Perhaps moving part of the workload to another platform could offer savings.

DC

On Tue, 13 Oct 2009 13:38:04 +, Jan Vanbrabant 
 wrote:

>*** cross-posted in IBM-MAIN, CICS-L, DB2-L ***
>
>Hi,
>
>If having the choice between a z10-BC with 2 or 3 processors,
>and if NOT taking (or having to take) into account the price aspect,
>is it possible to investigate wether a 2- or a 3-processor system might better 
suit us?
>
>I assume it may be possible to gather info about a latent demand for a 
processor.
>Where to look at in RMF, or in SMF to find this out?
>
>What about DB2 and/or CICS?
>DB2 and especially CICS do offer more and more parallellism.
>Any ideas if we can find this out within these subsystems?
>
>Jan
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PSW question

[Shmuel Metz (Seymour J.)]

In <660412.68830...@web54601.mail.re2.yahoo.com>, on 10/10/2009
   at 03:25 PM, Ed Gould  said:

>There is a bit reserved in the PSW for "ASCII".

On S/360, yes, but on anything later?

>Does anyone know if this was ever used

Not that I'm aware of. It was intended to allow decimal arithmetic on
packed ASCII data.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Page Faults and Interrupts

[Shmuel Metz (Seymour J.)]

In <4ad00200.7020...@longpelaexpertise.com.au>, on 10/10/2009
   at 11:39 AM, David Stephens  said:

>I've always thought that a page fault in any operating system, including 
>z/OS, would generate an interrupt. The task requiring the missing page 
>would be put aside whilst RSM did the required I/O to the page datasets 
>(unless the page was already in memory - in expanded storage, or a 
>stolen page).

Close. The RSM might also assign a free page frame immediately if the page
was previously uninitialized and in some systems the RSM might reflect the
page fault back to the running task, e.g., OS/VS1-VMF/370 handshaking.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

JES2 Parmlib inconsistent with active definitions

[Luc Martens (KBC)]

Hi guys,
we recently had some incidents which caused us a lot of debugging before we 
noticed what was going one.
Some JES2 parmlib definitions did not correspond with the actual state of the 
definitions in JES2.
I'm wondering if someone has had already the same problem, and is having an 
automated way to check for differences between parmlib and actual jes2 defs 
(which have been dynamically changed).
We are thinking on querying all jes2 defs, and checking then with defs in 
parmlib. Should someone has already written this and willing to share, that 
would be very much appreciated.
Any other ideas are also welcome.
Regards, Luc.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Instream Commands

[Mike Shorkend]

AFAIK, It is the submitter. I tried issuing a protected(via RACF OPERCMDS
class) command from a job submitted by an unauthorized user and it failed
with a ICH408I message.



On Tue, Oct 13, 2009 at 10:03 PM, Mark Baron  wrote:

> Good afternoon all -
>
> Does anyone know the userid that actually issues instream commands
> encountered in submitted JCL.
>
> Experimentation and testing has shown it to be neither the submitter nor
> JES2 nor the INITIATOR.  Message IEFC165I (the echo back of the command
> text) is issued by module IEFCNCMD which I am assuming is Converter.  If
> that is the case, under whose address space and userid does it run.
>
>
>
--

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Alternatives to TSM for Linux under Z/os DR?

[Vince Getgood]

Doesn't Innovations FDR/Upstream do this?

>From the product page: -

"FDR/UPSTREAM provides file level backups directly to z/OS mainframe tape or 
DASD. UPSTREAM backups/restores and file transfers can be Automatically 
Initiated from the z/OS mainframe and can be completely automated with 
exception reporting thus combining the backup of critical open systems data 
into existing Disaster Recovery plans"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: additional processor?

[Brian Westerman]

We also do capacity plans at Syzygy for our clients for free.  Plus we
perform system audits which can be used for this decision as well, but a
simple capacity plan is all you really need to do.

It's difficult to tell what you should get CPU-wise without actual physical
data to base it on.

Architecture has changed a lot over the years and many of the old "rule of
thumb" are now closer to "old wives tales".  Whether or not you need 1, 2 or
3 CPU's is a fairly simple thing to calculate once you have the proper data.
 I didn't see the initial post, but did you say what it is you're running now?

One thing you should also consider is getting zIIP or zAAP processors, since
you appear to be running DB/2 and CICS you can benefit from them and they
are a much lower cost than the "standard" processors.  Also, if you are
running (or going to run) z/OS 1.11, there is new support for using them
interchangeably with each other (zIIPs and zAAPs).  Without knowing what you
are currently running and how you are meeting your current needs it's
difficult to help.  If you have the money though, I would suggest getting as
many specialty processors as you can.  If you only get 1 "standard"
processor, you should also get 1 specialty processor, the cost is
reasonable, and you can gain a lot of benefit from it.  Beyond that, it's a
matter of what your site NEEDS to be able to meet it's plan and goals,
weighed against the costs involved. 

If you want to contact me offline we can discuss what you need to look at to
make your decision.  You more than likely have everything you need already
to make the choice, you just need to gather it into a format that you can
use for your decision.

Brian

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Outsourcing your Computer Center to IBM ?

[Graeme Gibson]

Yes Andrew, the quoted source for the CEO was "in an internal memo", 
but one worded, I'd suggest, with an eye to it becoming public.


Graeme.




At 07:27 AM 14/10/2009, you wrote:

Graeme Gibson wrote:


Distributing blame should have been kept entirely behind closed doors.
He looked weak blowing off in public that way.


Did he do it in public? The way I read the original report I thought 
it was an internal email that was leaked.


--
Andrew Rowley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html