Re: Dallas Area ALC Programming Consultant Position

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Paul Hanrahan
> 
> I emailed and received no reply. Remember when potential 
> employers actually tried to establish a dialogue with 
> prospectiver employees ? - Paul Hanrahan

Maybe they're waiting for some 12-year-old geek with 50 years' experience on
z/OS 3.5 and HLASM 8.3 who is willing to pay them $100/hr for the
privilege  :-)

(Hmm  I probably just "disqualified" myself.)

-jc-

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

Re: CA7 to TWS

[Michael Sullivan]

Our products can definitely help - for comprehensive automatic CA7 
flowcharting, documentation and cross reference - check out SmartIS 
http://www.segus.com/nav-index.htm we also support TWS, CTLM, CA-Scheduler, 
Jobtrac and Zeke.


Michael Sullivan
National Account Manager
SEGUS Inc.,
800-327-9650
[EMAIL PROTECTED]

"Andy White" <[EMAIL PROTECTED]> wrote in message 
news:<[EMAIL PROTECTED]>...

Does anyone know of any consulting company or software that can convert or
report on CA7 jobs in a schedule? We took over work from a company but
they run ca7 we use TWS(OPC).

We just wanted to print the jobs in certain trails so we can manually or
automatically using batch (rename them etc) and put them into TWS. Again
if someone has worked with a consulting company or have software that does
this it would be appreciate. I know years ago IBM had a Redbook on
converting to OPC but I cant seem to locate it.

Thanks
Andy
Internet: Mailto:[EMAIL PROTECTED]

The information contained in this message may be CONFIDENTIAL and is for 
the intended addressee only.  Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited.  If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Dallas Area ALC Programming Consultant Position

[Paul Hanrahan]

JC,

I didn't start until 1976 and the guys who were real hard core main frame
were 15 years older than me at the time. I consider myself one of the new
kids on the block even now compared to the guys I admired when I was
starting out.

I've been trying to track down a Dave Potter, one of the guys I admired.
Dave Potter and I did performance and capacity planning together (MVS 3.8
and beyond) back in the late 70's and early 80's. The last I heard Dave was
working at York Town Heights.

Anyone seen or heard from Dave ?  Dave used to work in Endicott.

Paul Hanrahan

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Chase, John
Sent: Monday, August 22, 2005 8:21 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Dallas Area ALC Programming Consultant Position


> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Paul Hanrahan
> 
> I emailed and received no reply. Remember when potential
> employers actually tried to establish a dialogue with 
> prospectiver employees ? - Paul Hanrahan

Maybe they're waiting for some 12-year-old geek with 50 years' experience on
z/OS 3.5 and HLASM 8.3 who is willing to pay them $100/hr for the
privilege  :-)

(Hmm  I probably just "disqualified" myself.)

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: The Ol' Curmudgeon, part 2

[Phil Smith III]

Great rant!  (That's NOT snide, I mean it!)

Be aware that ComputerWorld is well known for never publishing anything without 
a negative slant.  I became aware of this 15 or so years ago, when an editor 
there solicited a piece from me about Rexx; it was rejected for being "too 
positive".  This (and a colleague's assertion that CW only likes negative 
pieces) got me to pay more attention to their writing, and sure enough, it's 
always got this doom, gloom, and impending failure tone to it.

Having said that, I'd say it sounds like a regular "curmudgeon" piece would be 
just what they'd want!

...phsiii

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

Re: Dallas Area ALC Programming Consultant Position

[Ed Gould]

On Aug 22, 2005, at 7:21 AM, Chase, John wrote:


-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Paul Hanrahan

I emailed and received no reply. Remember when potential
employers actually tried to establish a dialogue with
prospectiver employees ? - Paul Hanrahan


Maybe they're waiting for some 12-year-old geek with 50 years' 
experience on

z/OS 3.5 and HLASM 8.3 who is willing to pay them $100/hr for the
privilege  :-)

(Hmm  I probably just "disqualified" myself.)


John,

Funny you don't look like Dennis :)

Ed



-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Share wheather report?

[Howard Brazee]

On 19-Aug-2005, [EMAIL PROTECTED] (Roland Schiradin) wrote:

> No more to say

Maybe not.   But we have to guess about what this post means.


Share whether report?Share weather report?

It's not obvious to me.

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

Re: Share wheather report?

[Lock Lyon]

Howard,

This thread exists solely for the purpose of being able to say (with 
apologies to Red Skeleton):  "That's the worst spell of weather we've had 
in a long time!"


Lock Lyon
Compuware Corp



On 19-Aug-2005, [EMAIL PROTECTED] (Roland Schiradin) wrote:

> No more to say

Maybe not.   But we have to guess about what this post means.


Share whether report?Share weather report?

It's not obvious to me.




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

Re: The Ol' Curmudgeon, part 2

[Ed Finnell]

 
In a message dated 8/22/2005 8:12:14 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

a piece  from me about Rexx; it was rejected for being "too positive".  This 
(and  a colleague's assertion that CW only likes negative pieces) got me to 
pay more  attention to their writing, and sure enough, it's always got this 
doom, gloom,  and impending failure tone to it.



>>
Don Henley pretty much pegged it with 'Dirty Laundry'. Sensationalism at  any 
price! Dropped our subscription long
ago and won't go back. They do show up in google searches every now
and then but only use them as third or fourth choice after the fact.  The 
real Dr. Phil(Bernstein) used to teach a course on
database fundamentals and a follow on database design. Much of it
was based on his DYL204 experience, but it just a great course.
Fist one I every heard use the PhD in CS, fluent in ALC, COBOL,
Fortran, PL/1, JCL, CLISTs, and REXX and under 25 yrs old as prime
description for System programmer. 

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

Re: Share wheather report?

[Ed Finnell]

 
In a message dated 8/22/2005 8:40:15 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

It's not  obvious to me.
>>



50th Anniversary SHARE began yesterday in Boston. The out of towners were  
trying to get a leg up on what to wear/pack.

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

EXPIREBV a general overview

[John Doherty]

I was wondering if anyone can give me some advice or point me in the right
direction re HSM's 'EXPIREBV' I don't really understand how this works.  I
understand why it is required but don't really understand IBM's definition
of this.

We have this executing once per week but I don’t believe that it is doing
anything and need to understand the process to enable me to make the
correct resolution.

For example I ran the following command:

EXPIREBV DISPLAY NONSMSVERSIONS(UNCATALOGEDDATA(10)

and this produced a rather large output dset with the final tally being:

END OF DISPLAY - 9577 BACKUP VERSIONS ELIGIBLE FOR EXPIRATION

I am not sure where or how to proceed from here.

I know I could run ‘EXPIREBV EXECUTE’ but I am not sure what it would get
rid off and how.

Any advice would be appreciated.

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

Re: EXPIREBV a general overview

[Staller, Allan]

The display will list the MVS dataset names.
The execite will expire and deleted the backup versions indicated in the 
display.
Unfortunately, this will display the HSM internal name, not the MVS dataset 
name.

The NONSMSVERSIONS applies to datasets that are not SMS-managed.

You are correct, EXPIREBV DISPLAY does nothing.

-HTH



I was wondering if anyone can give me some advice or point me in the right
direction re HSM's 'EXPIREBV' ...

We have this executing once per week but I don't believe that it is doing
anything and need to understand the process to enable me to make the
correct resolution.

For example I ran the following command:

EXPIREBV DISPLAY NONSMSVERSIONS(UNCATALOGEDDATA(10)

and this produced a rather large output dset with the final tally being:

END OF DISPLAY - 9577 BACKUP VERSIONS ELIGIBLE FOR EXPIRATION



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

Re: HELP - can't IPL ZOS

[John Mycroft]

Thanks to everyone who replied.  Came in this morning and couldn't access
MVS at all, not even to log on under VM.  Then, at about 10:30, it
inexplicably leapt into life and is behaving itself.  Someone must have
known where to give it a thump.

--
Cheers - John Mycroft
coryton_at_cobbsmill_dot_com


"John Mycroft" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Beats the you-know-what out of me.  I have tried replying with r
> 03,CKPT2=(DSNAME= etc and I get told that's an invalid command.  The
> manual tells me to enter a valid command (so glad I read the manual to
> find that out).  Fortunately nobody else wants to use the MVS machine so I
> will now return to sane territory, to whit, a beer on the deck at home.
>
> Thanks for your help, everyone - it really was appreciated and any tinge
> of annoyance in my posts is not directed at anyone here.  Mutter
> mutter.
>
> --
> Cheers - John Mycroft
> coryton_at_cobbsmill_dot_com
>
>
> <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>>
>> In a message dated 8/19/2005 3:20:57 P.M. Central Standard Time,
>> [EMAIL PROTECTED] writes:
>>
>> The  reply should be like 01 or 02 ,,,01 most likely rely "r 01,cold"
>> exclude  the quotes
>>
>>
>>

>> I think it's stuck in JES CHKPT RECONFIG DIALOG. COLD or WARM isn't
>> what it's looking for. Once they get to rolling it's an opportunity
>> to define or find the missing CHKPT2 dataset or create a new one.
>>
>> Also a good time to review the default PFKs. I think K E,1 will clear one
>> Eventual action message.
>>
>> Lacking that the HMC, is pretty good for these type situations.
>>
>> D R,L is your best friend.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

How to easily render a system unIPLable/IPLable

[McKown, John]

I am running some SMP/E jobs to apply maintenance to our "sandbox". It
is currently "down". I have emailed everybody that it needs to say down
while I do my maintenance. Yes, I generally trust them. However, since I
have the "sandbox" OMVS files mounted in order to directly put the
maintenance on them, I was wondering if there is a simple, easy to
reverse, way to render a system unIPLable? I don't really want to
AMASPZAP the IPL text or anything weird like that. I don't want to
rename any libraries (such as SYS1.NUCLEUS) because that would "mess up"
my DDDEFs. And, just to be weird, I really love the result to be a "hard
wait" with a code of 0xDEADBEEF. That would amuse me greatly.


--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

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

Re: How to easily render a system unIPLable/IPLable

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of McKown, John
> 
> I am running some SMP/E jobs to apply maintenance to our 
> "sandbox". It is currently "down". I have emailed everybody 
> that it needs to say down while I do my maintenance. Yes, I 
> generally trust them. However, since I have the "sandbox" 
> OMVS files mounted in order to directly put the maintenance 
> on them, I was wondering if there is a simple, easy to 
> reverse, way to render a system unIPLable?

Create a "bogus" IPLPARM?

-jc-

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

Re: How to easily render a system unIPLable/IPLable

[Marian Gasparovic]

What does happen if IPL process does not find right LOADxx member ?

Marian

On 8/22/05, McKown, John <[EMAIL PROTECTED]> wrote:
> I am running some SMP/E jobs to apply maintenance to our "sandbox". It
> is currently "down". I have emailed everybody that it needs to say down
> while I do my maintenance. Yes, I generally trust them. However, since I
> have the "sandbox" OMVS files mounted in order to directly put the
> maintenance on them, I was wondering if there is a simple, easy to
> reverse, way to render a system unIPLable? I don't really want to
> AMASPZAP the IPL text or anything weird like that. I don't want to
> rename any libraries (such as SYS1.NUCLEUS) because that would "mess up"
> my DDDEFs. And, just to be weird, I really love the result to be a "hard
> wait" with a code of 0xDEADBEEF. That would amuse me greatly.
> 
> 
> --
> John McKown
> Senior Systems Programmer
> UICI Insurance Center
> Information Technology
> 
> This message (including any attachments) contains confidential
> information intended for a specific individual and purpose, and its'
> content is protected by law.  If you are not the intended recipient, you
> should delete this message and are hereby notified that any disclosure,
> copying, or distribution of this transmission, or taking any action
> based on it, is strictly prohibited.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How to easily render a system unIPLable/IPLable

[Alan Schwartz]

Specifying an IODF that doesn't exist will put you in a wait state when 
you ipl.  So a simple member edit should suffice.

Alan Schwartz
Assurant Shared Business Services
Lead Systems Programmer
Phone:  651-361-4758
Fax:   651-361-5625



"McKown, John" <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
08/22/2005 12:01 PM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
How to easily render a system unIPLable/IPLable






I am running some SMP/E jobs to apply maintenance to our "sandbox". It
is currently "down". I have emailed everybody that it needs to say down
while I do my maintenance. Yes, I generally trust them. However, since I
have the "sandbox" OMVS files mounted in order to directly put the
maintenance on them, I was wondering if there is a simple, easy to
reverse, way to render a system unIPLable? I don't really want to
AMASPZAP the IPL text or anything weird like that. I don't want to
rename any libraries (such as SYS1.NUCLEUS) because that would "mess up"
my DDDEFs. And, just to be weird, I really love the result to be a "hard
wait" with a code of 0xDEADBEEF. That would amuse me greatly.


--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology




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

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

Re: Need RACF help defining lowercase ID

[Pommier, Rex R.]

Thanks to all who responded - especially those who responded that I can
use an upper case userid.  The initial problem came from BMC's
documentation that stated "this userid must be defined in lower case"
and the contractor working for us confirming the (apparently incorrect)
documentation from BMC.  We went ahead and defined the userid as
uppercase and it is working fine.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ulrich Boche
Sent: Sunday, August 21, 2005 5:13 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Need RACF help defining lowercase ID


Pommier, Rex R. wrote:

> Waiting for z/OS 1.7 is not an option for a number of reasons - the 
> first being that I'm running on an MP3000 - 1.7 won't run there.  Can 
> I get verification from somebody that I for sure can't use lower-case 
> RACF ID's on z/OS 1.4?
> 
RACF has precisely three lower-case userids which are special IDs for 
certificate management and RACF development made them lower case to 
prevent users to tamper with them. Short answer: there is no way in 
RACF, neither today nor in z/OS 1.7, to define lower-case userids.

OTOH, you have been told in other replies to your posting that you can 
define the userid you need in upper case and the application in question

will run perfectly, so where is your problem?
-- 
Ulrich Boche
SVA GmbH, Germany
IBM Premier Business Partner

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How to easily render a system unIPLable/IPLable

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Alan Schwartz
> Sent: Monday, August 22, 2005 12:09 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: How to easily render a system unIPLable/IPLable
> 
> 
> Specifying an IODF that doesn't exist will put you in a wait 
> state when 
> you ipl.  So a simple member edit should suffice.
> 
> Alan Schwartz

Yeah, I finally figured that out. Simple. Too bad it doesn't give my the
0xDEADBEEF wait state. I don't know where my mind is today. It seems to
have checked out over the weekend and left no forwarding address.

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

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

Nice new function in z/OS 1.7

[McKown, John]

For those who would like to monitor the z/OS system from some "central
location", IBM has integrated a CIM (API) which allows performance
metrics to be queried from another system.


| z/OS CIM implements the CIM server which is based on the OpenPegasus
open
| source project. A CIM monitoring client invokes the CIM server which,
in
| turn, collects z/OS metrics from the system and returns it to the
calling
| client. To get the z/OS metrics, the CIM server invokes the z/OS RMF
| monitoring provider which retrieves the metrics associated with z/OS
| system resources. The z/OS RMF monitoring provider uses RMF Monitor
III
| performance data.



http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/E0Z2A117/1.5.
1


--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

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

Re: How to easily render a system unIPLable/IPLable

[Jay Maynard]

On Mon, Aug 22, 2005 at 12:37:31PM -0500, McKown, John wrote:
> Yeah, I finally figured that out. Simple. Too bad it doesn't give my the
> 0xDEADBEEF wait state.

If you want dead beef, you'll have to go to a steakhouse or write custom IPL
text.

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

Re: INNOVATION DATA PROCESSING ANNOUNCEMENTS - August 15, 2005

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/20/2005
   at 06:43 PM, Don Poitras <[EMAIL PROTECTED]> said:

>Forcing a default OMVS segment sounds like a great idea to me. 

I disagree, but deleting an existing default OMVS segment is a high
impact change and should treated as such. Certainly it needs to show
up in audit reports with a big red flag. I'd also like to see
messages, LOGREC and SMF data for dub failures.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How to easily render a system unIPLable/IPLable

[Glenn Miller]

John,

It depends on how far you want the hardware/software to get before if
fails.
For example:

- If you have access to the HMC, rename the IMAGE profile of the LPAR your
sandbox system runs in.  Then De-activate that LPAR.  If someone attempts
to IPL that LPAR, it will fail, LPAR not activated.  If someone attempts to
activate that
LPAR, the activate will fail because the IMAGE profile does not exist.
Once you
finish with your maintenance, rename the IMAGE profile of that LPAR back to
its original name.  NOTE: The HMC Application does not have a rename
function.
I circumvent this 'editing' ( the customize function ) the profile I want
to rename,
change the Profile Name on the 1st customization screen, Save the 'new'
Profile,
then delete the 'original' Profile.


- Use the NOBOOTSTRAP parameter of the ICKDSF REFORMAT command
against the Sysres volume you're working on.  CAUTION: DO NOT use INIT
command.  Once you finish with your maintenance, perform ICKDSF REFORMAT
command with BOOTSTRAP & IPLDD parameters to 're-install' the correct
z/OS IPL text.


- The other suggestions regarding the LOADxx member are good.  However,
if you don't want your Sysres volume to be access, these may not meet your
requirement.


HTH

Glenn Miller


---
This message (including any attachments) is confidential and may be
privileged. If you have received it by mistake please notify the sender by
return e-mail and delete this message from your system. Any unauthorised
use or dissemination of this message in whole or in part is strictly
prohibited. Please note that e-mails are susceptible to change.
ABN AMRO Bank N.V. (including its group companies) shall not be liable for
the improper or incomplete transmission of the information contained in
this communication nor for any delay in its receipt or damage to your
system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that
the integrity of this communication has been maintained nor that this
communication is free of viruses, interceptions or interference.
---

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

Re: Get involved! Chair a session at SHARE!

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/19/2005
   at 05:05 PM, Ed Gould <[EMAIL PROTECTED]> said:

>I have written before on SHARE participation (and probably why people
> do not want to get involved).  I would only hope that SHARE would 
>realize how they are poisoning the membership and get behind a more 
>voluntary membership involvement.

Poisoning? Not in my experience. I've met a lot of SHARE officers who
were on the prowl for potential volunteers, and none that were chasing
them away.

That said, the one time that I chaired I session I was not adequately
prepared; the duties and ground rules are not obvious, and training
would have been helpful. But that was a procedural lapse rather than
one of attitude or intent.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Managing /service for SMP/E

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/19/2005
   at 12:32 PM, Tom Marchant <[EMAIL PROTECTED]> said:

>I don't have any problem cloning them or changing the PATHs with
>ZONEEDIT.  My question was about managing the mountpoints,
>specifically for those products that are not installed in the root
>HFS.

If you use a naming convention that includes the target zone as part
of both the dsname and the mount point, then I don't see the problem.

/service/CICS01 could have an automount of OMVS.CICS01 and
/service/CICS02 could have an automount of OMVS.CICS02, assuming two
CICS target zones with those names. You must, of course, coordinate
changes to automount policies for SMP and production. 
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HELP - can't IPL ZOS

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/19/2005
   at 04:09 PM, John Mycroft <[EMAIL PROTECTED]> said:

>Our ZOS system is unable to be IPLed by us humble programmers.  It's
>stuck with "MESSAGE WAITING on the console.  Presumably waiting for a
>reply but we haven't got a clue what the replid is or what the reply
>should be.  Could probably see it if we could get rid of the IEE144I
>stuff at the bottom of the screen.

You can delete an out-of-line display with a CONTROL (K) command.

>A cold start of JES would be fine by us, too, if we had a clue how
>to do that.

Depending on the problem, you might have to do FORMAT.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HELP - can't IPL ZOS

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/19/2005
   at 03:28 PM, Greg Saccomanno <[EMAIL PROTECTED]> said:

>K A,NONE

Why? If you define default message routing for all the commands then
you still have only one area for normal operation while retaining the
option of out-of-line messages when you need them. In any case, you
can always delete the out-of-line display with a single command, so K
A,NONE would not have helped the OP and might have exacerbated his
problem.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Is this CICS (or are we having fun yet?)

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Capomaestro
> 
> [ snip ]
> 
> -- --   ---
> |CICS| --> |MYASMBLR|   |R1 --> ???|...|R13 -> ???|
> -- --   ---
> -- --
> |INIT| -|  |DFHEAI  |
> --  |  --   ---
> -> |MYASMBLR|   |R1 --> EIB|...|R13 -> S/A|
>--   ---
> -- --
> |CICS| -|  |DFHEAI  |
> --  |  --   ---
> -> |MYASMBLR|   |R1 --> EIB|...|R13 -> S/A|
>--   ---
> 
> ...and after all that, this behaviour is observed under TS3.1 .

Sorry for the delay in responding; had to don my "RACF hat" for a while

> Have you non-command level, non-preprocessed assembler 
> modules gaining control directly from CICS? The first example 
> experiences a S0C4 on a STM.

Fascinating  I get the same result with a little program I cobbled up
just to load some registers by duplicating the instructions in DFHEAI, then
forcing a S0C1 and SVCDUMP.  If I omit the DFHEAI (I actually use DFHELII;
same difference) stub I get a S0C4 on the first instruction (STM
14,12,12(13) ).  Dump shows that R13 (and R12) both point to the "dummy" CSA
address in fetch-protected (and write-protected) storage.

When I prefix the DFHELII stub (exactly the same instructions as DFHEAI), my
program runs until the S0C1 happens.  Dump shows R13 with a different
address that R12 (which still has the fetch-protected "dummy" TCA address),
but the DFH... stub does not modify R13.  First instruction after the
unconditional branch at the end of the DFH stubs is ...

 ...

STM  14,12,12(13)

Since IBM took CICS "OCO" when they restructured it (ca. CICS/ESA 3.3) and
removed API access to the CSA and TCA, I can't explain why "my" (and your)
STM fails but theirs succeeds.

And just as an observational FYI, the first three instructions in all the
DFH stubs are exactly what DFHAFCD TYPE=LOCATE generates.

So, it appears that a DFH stub is required at the front of an Assembler
program that CICS will invoke directly, if only to get a valid savearea
address in Reg13.

-jc-

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

Re: INNOVATION DATA PROCESSING ANNOUNCEMENTS - August 15, 2005

[Patrick O'Keefe]

On Fri, 19 Aug 2005 23:27:17 -0400, Bruce Black <[EMAIL PROTECTED]>
wrote:

>... I gather that it only occurs if an application calls "resolver"
>which is a TCP/IP service.  Resolver calls USS which fails if the
>calling application does not have the OMVS segment.  ... Obviously, your
>applications are at risk only if they use Resolver.
>...

But just about any TCP/IP function invokes Resolver code.  The code is
named "Resolver" because it performs the first steps in IP name resolution
but the code also handles dynamic dataset and file allocation for TCP/IP
(dynamic allocation of TCPDATA, etc.).

>Prior to z/OS 1.6, TCP recognize the error but they changed some code in
>1.6.  Now it tries to pick up an address of something, and if the
>failure occured that something may sometimes be a UCB address, leading
>to the overlay.  I have no idea if other storage could be overlaid by
>the bug.
>...

I sort of doubt the code goes out of it's way to locate a UCB.  :-)
I suppose it could be following a chain of addrs starting in low storage
that always lands it on a UCB.

>...
>if you are less that 1.6, you should not have the bug.   ...

And we have just finished our migration to 1.6. of course.

I've opened a Tech Q&A incident on IBMLink asking for more detailed
information.  So far I've had the APAR text quoted to me ... twice.


Pat O'Keefe

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

Re: How to easily render a system unIPLable/IPLable

[Paul Hanrahan]

Just write over the boot record and then put it back later. The Dead Beef
part is tough unless you decide to mess with the second boot record and
program.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of McKown, John
Sent: Monday, August 22, 2005 1:02 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: How to easily render a system unIPLable/IPLable


I am running some SMP/E jobs to apply maintenance to our "sandbox". It is
currently "down". I have emailed everybody that it needs to say down while I
do my maintenance. Yes, I generally trust them. However, since I have the
"sandbox" OMVS files mounted in order to directly put the maintenance on
them, I was wondering if there is a simple, easy to reverse, way to render a
system unIPLable? I don't really want to AMASPZAP the IPL text or anything
weird like that. I don't want to rename any libraries (such as SYS1.NUCLEUS)
because that would "mess up" my DDDEFs. And, just to be weird, I really love
the result to be a "hard wait" with a code of 0xDEADBEEF. That would amuse
me greatly.


--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and its' content is
protected by law.  If you are not the intended recipient, you should delete
this message and are hereby notified that any disclosure, copying, or
distribution of this transmission, or taking any action based on it, is
strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How to easily render a system unIPLable/IPLable

[Paul Hanrahan]

> Specifying an IODF that doesn't exist will put you in a wait state when 
> you ipl.  So a simple member edit should suffice.

BORING ! 

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

Re: How to easily render a system unIPLable/IPLable

[Paul Hanrahan]

If the Dead Beef is important to you than don't let it go !

It's not that hard to do.  I can tell you've got what it takes.  Pot a
coffee and a few snickers bars and you'll have the dead beef wait state by
morning.


>Yeah, I finally figured that out. Simple. Too bad it doesn't give my the
0xDEADBEEF wait state. I don't know where my mind >is today. It seems to
have checked out over the weekend and left no forwarding address.

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

Dead Beef

[Paul Hanrahan]

Doesn't being a systems programmer mean you write the system's code that
runs on the bare metal ?  Dave Potter could have written the dead beef wait
state code over night. - Paul Hanrahan

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

Re: Dead Beef

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Hanrahan
> Sent: Monday, August 22, 2005 2:54 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Dead Beef
> 
> 
> Doesn't being a systems programmer mean you write the 
> system's code that
> runs on the bare metal ?  Dave Potter could have written the 
> dead beef wait
> state code over night. - Paul Hanrahan

I know how to, in theory. The simpliest way would be to just overwrite
the the initial PSW in the IPL text. The easiest way to do that is to
zap/edit the IBM supplied IPL text and use ICKDSF to install it. The
more difficult way would be to figure out how to zap the IPL text on the
DASD device. Especially since I cannot figure out a way to get AMASPZAP
to zap an arbitrary record on a disk. And the IPL text is not within a
dataset. 

But I'm way too lazy to do that today. Maybe I'll play with it on
Hercules at home.


--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

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

Re: Dead Beef

[Richard Pinion]

Yes one could use Hercules if running z/OS on Herc were legal.

>>> [EMAIL PROTECTED] 8/22/2005 4:19:25 PM >>>
> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Hanrahan
> Sent: Monday, August 22, 2005 2:54 PM
> To: IBM-MAIN@BAMA.UA.EDU 
> Subject: Dead Beef
> 
> 
> Doesn't being a systems programmer mean you write the 
> system's code that
> runs on the bare metal ?  Dave Potter could have written the 
> dead beef wait
> state code over night. - Paul Hanrahan

I know how to, in theory. The simpliest way would be to just overwrite
the the initial PSW in the IPL text. The easiest way to do that is to
zap/edit the IBM supplied IPL text and use ICKDSF to install it. The
more difficult way would be to figure out how to zap the IPL text on the
DASD device. Especially since I cannot figure out a way to get AMASPZAP
to zap an arbitrary record on a disk. And the IPL text is not within a
dataset. 

But I'm way too lazy to do that today. Maybe I'll play with it on
Hercules at home.


--

John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Dead Beef

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Richard Pinion
> 
> Yes one could use Hercules if running z/OS on Herc were legal.

IPL text works the same on MVS/SP 3.8.

-jc-

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

Re: Dead Beef

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Richard Pinion
> Sent: Monday, August 22, 2005 3:21 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Dead Beef
> 
> 
> Yes one could use Hercules if running z/OS on Herc were legal.
> 

What I meant was that I could use Hercules to develop my IPL text which
does the hard wait of 0xDEADBEEF. I could more easily debug any errors
(how could I make an error with something so simple? I have talent!) on
Hercules than I can on an LPAR at work.

I have MVS 3.8j on Hercules. I can use that to develop the code. It runs
quite well (MVS, that is). And is legal. Along with VM/370 and OS/VS1
and even MVT.

But that is starting to get off-topic.

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

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

Re: Dead Beef

[Steve Comstock]

McKown, John wrote:

-Original Message-
From: IBM Mainframe Discussion List 
[mailto:[EMAIL PROTECTED] On Behalf Of Richard Pinion

Sent: Monday, August 22, 2005 3:21 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Dead Beef


Yes one could use Hercules if running z/OS on Herc were legal.




What I meant was that I could use Hercules to develop my IPL text which
does the hard wait of 0xDEADBEEF. I could more easily debug any errors
(how could I make an error with something so simple? I have talent!) on
Hercules than I can on an LPAR at work.

I have MVS 3.8j on Hercules. I can use that to develop the code. It runs
quite well (MVS, that is). And is legal. Along with VM/370 and OS/VS1
and even MVT.

But that is starting to get off-topic.



Hey, sherif! Ya' better come over quick. There's some
desperados here maybe meanin' to do some damage. They
ain't SHARE'in enough, clearly.

-Steve Comstock

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

Re: Dallas Area ALC Programming Consultant Position

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/21/2005
   at 10:45 AM, Paul Hanrahan <[EMAIL PROTECTED]> said:

>I emailed and received no reply. 

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

Re: The Ol' Curmudgeon, part 2

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/21/2005
   at 08:02 AM, Steve Comstock <[EMAIL PROTECTED]> said:

>3. Why "should" IT dollars be spent on new systems?

Ask any stock broker, or google for churn. Follow the money.

>unknowing, unthinking columnists like you.

You're being charitable, by assuming that he didn't have a vested
interest in churning the industry.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Dead Beef

[Paul Hanrahan]

Work smart not hard. Or why work at all just Think. That's my motto. - Paul
Hanrahan


"I know how to, in theory. The simpliest way would be to just overwrite the
the initial PSW in the IPL text. The easiest way to do that is to zap/edit
the IBM supplied IPL text and use ICKDSF to install it. The more difficult
way would be to figure out how to zap the IPL text on the DASD device.
Especially since I cannot figure out a way to get AMASPZAP to zap an
arbitrary record on a disk. And the IPL text is not within a dataset. 

But I'm way too lazy to do that today. Maybe I'll play with it on Hercules
at home."

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

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

Re: Dead Beef

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Hanrahan
> Sent: Monday, August 22, 2005 3:57 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Dead Beef
> 
> 
> Work smart not hard. Or why work at all just Think. That's my 
> motto. - Paul
> Hanrahan

The motto around here is: "Get the job done, just don't use any hard
cash to do it. Work harder and longer, not necessarily more
efficiently."


--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its'
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.

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

Re: INNOVATION DATA PROCESSING ANNOUNCEMENTS - August 15, 2005

[Patrick O'Keefe]

On Mon, 22 Aug 2005 14:39:41 -0500, Patrick O'Keefe
<[EMAIL PROTECTED]> wrote:

>...
>I've opened a Tech Q&A incident on IBMLink asking for more detailed
>information.  So far I've had the APAR text quoted to me ... twice.
>
>...

I finally got a better response confirming (as others have suggested here)
that the OMVS segment from a default UID entry in the SAF product is
sufficient to avoid this problem.

They also confirmed that the failing to "dub" would not go unnoticed.  It
would be a very visible failure of the address space (or, I bet, at least
the TCB) requesting the TCP/IP function.

To put it another way, if you are a candidate victim of the UCB overlay you
are already experiencing obvious TCP/IP failures.  This bug is not going
to sneak up on you.

Pat O'Keefe

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

Re: Dead Beef

[Paul Hanrahan]

Yall gonna be shootin bugs fer daze iffin you aren't careful.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Steve Comstock
Sent: Monday, August 22, 2005 4:37 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Dead Beef


McKown, John wrote:
>>-Original Message-
>>From: IBM Mainframe Discussion List
>>[mailto:[EMAIL PROTECTED] On Behalf Of Richard Pinion
>>Sent: Monday, August 22, 2005 3:21 PM
>>To: IBM-MAIN@BAMA.UA.EDU
>>Subject: Re: Dead Beef
>>
>>
>>Yes one could use Hercules if running z/OS on Herc were legal.
>>
> 
> 
> What I meant was that I could use Hercules to develop my IPL text 
> which does the hard wait of 0xDEADBEEF. I could more easily debug any 
> errors (how could I make an error with something so simple? I have 
> talent!) on Hercules than I can on an LPAR at work.
> 
> I have MVS 3.8j on Hercules. I can use that to develop the code. It 
> runs quite well (MVS, that is). And is legal. Along with VM/370 and 
> OS/VS1 and even MVT.
> 
> But that is starting to get off-topic.
> 

Hey, sherif! Ya' better come over quick. There's some desperados here maybe
meanin' to do some damage. They ain't SHARE'in enough, clearly.

-Steve Comstock

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: INNOVATION DATA PROCESSING ANNOUNCEMENTS - August 15, 2005

[Bruce Black]

IBM added some text to the APAR

The UCB overlaid was obtained from fixed storage location
address BC (X'BC', 188), which is the PSA field FLCIOFP
or FLCEIOINTPARM, the UCB associated with the most recent
I/O interrupt.

Apparently TCP expected a register to point to some control block but it 
pointed to zero after a dub failure. They picked up what they expected 
to be a pointer to another control block, but instead they picked up the 
PSA address which points to the UCB from the most recent I/O interrupt 
(which may not even be associated with TCP).


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

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

auto reIPL

[Bruce Black]

did anyone notice that the z9-109 announcement includes a function to 
programatically reIPL the system (ala Windows/Intel RESTART).  No 
indication that zOS will make use of this support.  Perhaps it is 
intended for Linux.


--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech support: [EMAIL PROTECTED]
web: www.innovationdp.fdr.com

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

Re: auto reIPL

[Ted MacNEIL]

>did anyone notice that the z9-109 announcement includes a function to 
programatically reIPL the system (ala Windows/Intel RESTART).  No 
indication that zOS will make use of this support.  Perhaps it is 
intended for Linux.
...

UNIX has had the function for years, since quick re-boots have been the 
priority, rather than fewer.


-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

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

Re: auto reIPL

[Mark Zelden]

On Mon, 22 Aug 2005 17:40:31 -0400, Bruce Black <[EMAIL PROTECTED]>
wrote:

>did anyone notice that the z9-109 announcement includes a function to
>programatically reIPL the system (ala Windows/Intel RESTART).  No
>indication that zOS will make use of this support.  Perhaps it is
>intended for Linux.
>

Yep, saw it.   It is intended for Linux running nativly in an
LPAR (not under VM  - which already provides a facility for
shutdown/re-ipl of Linux).  What I don't know yet is how this is
different from VM's ability to shutdown and re-ipl.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://Search390.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

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

Re: auto reIPL

[Patrick O'Keefe]

>>did anyone notice that the z9-109 announcement includes a function to
>programatically reIPL the system (ala Windows/Intel RESTART).  ...
>...
>
>UNIX has had the function for years, since quick re-boots have been the
priority, rather than fewer.
>...

I haven't worked with VM since the late '70s, but I recall it also had a
reIPL as part of its recovery.

Pat O'Keefe

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

Re: auto reIPL

[Ted MacNEIL]

>I haven't worked with VM since the late '70s, but I recall it also had a
reIPL as part of its recovery.
...

Yes, I should have mentioned it.
It did.
Also, as of HPO (I think) it had the capability to 'bounce' without taking the 
'favoured' guests down, as well.
-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

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

Re: auto reIPL

[Stephen Mednick]

IBM are probably going to link it up to SMP/E such that after you've applied a
bunch of fixes you'll get a WTOR to say that you need to re-IPL your system,
please close down any open applications to save your date.

Stephen Mednick
Computer Supervisory Services
Sydney, Australia

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Black
> Sent: Tuesday, 23 August 2005 7:41 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: auto reIPL
> 
> did anyone notice that the z9-109 announcement includes a 
> function to programatically reIPL the system (ala 
> Windows/Intel RESTART).  No indication that zOS will make use 
> of this support.  Perhaps it is intended for Linux.
> 
> --
> Bruce A. Black
> Senior Software Developer for FDR
> Innovation Data Processing 973-890-7300
> personal: [EMAIL PROTECTED]
> sales info: [EMAIL PROTECTED]
> tech support: [EMAIL PROTECTED]
> web: www.innovationdp.fdr.com
> 

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

Re: auto reIPL

[Tom Schmidt]

On Mon, 22 Aug 2005 17:40:31 -0400, Bruce Black <[EMAIL PROTECTED]>
wrote:

>did anyone notice that the z9-109 announcement includes a function to
>programatically reIPL the system (ala Windows/Intel RESTART).  No
>indication that zOS will make use of this support.  Perhaps it is
>intended for Linux.

I recall making that request of IBM (for MVS/ESA v5 at the time) around 9-
10 years ago, as an option of post-SADUMP processing.  The idea was that
standalone dump could capture the information and then jump right into the
IPL parms specified on the HMC to get things recovered more quickly.  I
also suggested that SADUMP could perhaps detect (and dump) some conditions,
presumably pre-selected and initiate SADUMP then reIPL to capture failures
and get back up.

Then again I also asked for the access registers to be displayed with the
GPRs on joblog/syslog displays in around 1989/1990 and that took a longer
time to get to my local mainframe.

--
Tom Schmidt
Madison, WI
(in Boston, MA this week)

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

Re: auto reIPL

[Richard Peurifoy]

Mark Zelden wrote:


Yep, saw it.   It is intended for Linux running nativly in an
LPAR (not under VM  - which already provides a facility for
shutdown/re-ipl of Linux).  What I don't know yet is how this is
different from VM's ability to shutdown and re-ipl.

 

I was wondering the same thing. I haven't had time to try to check yet, 
but the only
thing I can think of is that it causes a system reset to attempt to 
clear any I/O problems.


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

Re: Dead Beef

[Ed Gould]

On Aug 22, 2005, at 3:26 PM, Chase, John wrote:


-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Richard Pinion

Yes one could use Hercules if running z/OS on Herc were legal.


IPL text works the same on MVS/SP 3.8.

-jc-



John,

Which brings up a question. I can only remember once in (20?) years 
that a ptf became available for ipl text.. can anyone remember more 
than one?


Ed

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

Re: Dead Beef

[Charles Mills]

Okay, while we're wasting time here anyway  I've got a question. Why
x'DEADBEEF'?

I recall that on AIX on the RS/6000, that was what the OS filled
unallocated memory with. If you referenced un-initialized malloc
("GETMAIN") storage, you got dead beef, rather than 0. Kind of a cool
feature - more recognizable for debugging than an unintended 0.

Charles

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

Re: Dead Beef

[Joe Zitzelberger]

IIRC the Amiga did the same...

On Aug 22, 2005, at 9:19 PM, Charles Mills wrote:

Okay, while we're wasting time here anyway  I've got a question.  
Why

x'DEADBEEF'?

I recall that on AIX on the RS/6000, that was what the OS filled
unallocated memory with. If you referenced un-initialized malloc
("GETMAIN") storage, you got dead beef, rather than 0. Kind of a cool
feature - more recognizable for debugging than an unintended 0.


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

Re: Dead Beef

[Paul Hanrahan]

FREEBEEF sounds good to me. Dead or alive doesn't matter to me. Dave
Potter's dad owned balogna factory. Dave new all about dead beef. Anyway
thanks for being patient with my off topic posts.

Gotta go. - Paul Hanrahan

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Joe Zitzelberger
Sent: Monday, August 22, 2005 10:14 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Dead Beef


IIRC the Amiga did the same...

On Aug 22, 2005, at 9:19 PM, Charles Mills wrote:

> Okay, while we're wasting time here anyway  I've got a question.
> Why
> x'DEADBEEF'?
>
> I recall that on AIX on the RS/6000, that was what the OS filled 
> unallocated memory with. If you referenced un-initialized malloc
> ("GETMAIN") storage, you got dead beef, rather than 0. Kind of a cool 
> feature - more recognizable for debugging than an unintended 0.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: auto reIPL

[Anne & Lynn Wheeler]

Ted MacNEIL <[EMAIL PROTECTED]> writes:
> UNIX has had the function for years, since quick re-boots have been
> the priority, rather than fewer.

cp67 got fast reboots ... vm370 inherited it from cp67 ...

following has a story about somebody at MIT modifying cp67 resulting
in cp67 crashes 27 times in one day. there is some comment about that
not being possible with multics because it took multics so long to
reboot.
http://www.multicians.org/thvv/360-67.html

i had written tty/ascii terminal support for cp67 while an undergraduate
at the university. i had done some one byte arithmatic for calculating
input line length (couldn't get long lines with teletype).

i think the story is that there was some ascii device at harvard that
had something like 1200-2000 character line length ... that they
needed to connect to the cp67 at mit. the mit system modified various
fields to increase the maximum line length ... but didn't catch the
one byte arithmatic.

some drift ... in the process of adding tty/ascii support .. i tried
to extend the automatic terminal recognition from 1052 & 2741 to
include tty. in theory 2702 terminal controller would allow it.
initial testing sort of worked ... you could dynamically change
the line scanner on each port ... and correctly figure out whether
1052, 2741, or tty and get the correct line scanner. however,
2702 had a short cut where the line-speed oscillator was hardwired
to each port (allowing the correct line-scanner to be dynamically
be set on a port by port basis ... but it wouldn't also change
the port line-speed).

this sort of led to the university having a project to build
a clone controller ... that could support both dynamic terminal
type as well as dynamic line speed. somewhere there is a write-up
blaiming four of us for helping spawn the ibm plug-compatible
clone controller business.
http://www.garlic.com/~lynn/subtopic.html#360oem

on the other hand ... when i was doing getting ready to release
the resource manager  minor trivia drive ... resource manager
was genii pig for first priced kernel software ... past postings
on unbundling and software pricing
http://www.garlic.com/~lynn/subtopic.html#unbundle

we did some automated benchmarking process ... which included
extremely severe stress testing
http://www.garlic.com/~lynn/subtopic.html#bench

and there were numerous things that could consistently kill vm370.  as
a result ... before releasing resource manager for vm370, there were
serveral parts of vm370 that i had to redo ... primarily the task
serialization to eliminate all sorts of timing related failures
(as well as all cases of hung and/or zombie users).

not too long after releasing the resource manager ... i got the
opportunity to do some stuff with the disk enginnering and
product test labs in bldg. 14 & 15.

the labs had quite a few "testcells" ... engineering development
hardware that required all sorts of reqression testing. they were
running these test with stand alone processing and dedicated
scheduled processor time. they had tried doing it under operating
system control ... but found that the MTBF (at the time) for
MVS was on the order of 15 minutes with a single testcells.

i undertook to rewrite the i/o supervisor so things would never
fail ... they were eventually not only able to do single testcell
operation in operating system environment ... but eventually
able to doing multiple concurrent testcell testing. misc. past
posts of disk engineering lab.
http://www.garlic.com/~lynn/subtopic.html#disk

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

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

Re: Need RACF help defining lowercase ID

[John S. Giltner, Jr.]

Pommier, Rex R. wrote:

Thanks to all who responded - especially those who responded that I can
use an upper case userid.  The initial problem came from BMC's
documentation that stated "this userid must be defined in lower case"
and the contractor working for us confirming the (apparently incorrect)
documentation from BMC.  We went ahead and defined the userid as
uppercase and it is working fine.

Rex



What book was this documented in?  We have been running Control-M for
years and have had no problems.

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

Re: Dead Beef

[Ed Gould]

On Aug 22, 2005, at 9:41 PM, Paul Hanrahan wrote:


FREEBEEF sounds good to me. Dead or alive doesn't matter to me. Dave
Potter's dad owned balogna factory. Dave new all about dead beef. 
Anyway

thanks for being patient with my off topic posts.

Gotta go. - Paul Hanrahan



I think the more UN PC is:

 MADCOW


Ed

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

Re: Dead Beef

[Steve Samson]

Kinda hard to create with hex digits...

Ed Gould wrote:

On Aug 22, 2005, at 9:41 PM, Paul Hanrahan wrote:


FREEBEEF sounds good to me. Dead or alive doesn't matter to me. Dave
Potter's dad owned balogna factory. Dave new all about dead beef.
Anyway
thanks for being patient with my off topic posts.

Gotta go. - Paul Hanrahan



I think the more UN PC is:

 MADCOW


Ed


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

Re: Dead Beef

[Ed Gould]

On Aug 22, 2005, at 10:38 PM, Steve Samson wrote:


Kinda hard to create with hex digits...




So convert madcow to hex.

Ed

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

Re: Dead Beef

[Robert A. Rosenberg]

At 15:19 -0500 on 08/22/2005, McKown, John wrote about Re: Dead Beef:


Especially since I cannot figure out a way to get AMASPZAP
to zap an arbitrary record on a disk.


It has been a while but I seem to remember that if you use the DSN of 
FORMAT4.DSCB as your target it will ask permission of the operator 
and if granted, you will have access to the full volume (at which 
point you can use TTR control cards to get at the needed record to 
zap).


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

Re: Is this CICS (or are we having fun yet?)

[Capomaestro]

On Mon, 22 Aug 2005 13:50:44 -0500, Chase, John <[EMAIL PROTECTED]> wrote:

>> -Original Message-
>> From: IBM Mainframe Discussion List On Behalf Of Capomaestro
>>
>> [ snip ]
>>
>> -- --   ---
>> |CICS| --> |MYASMBLR|   |R1 --> ???|...|R13 -> ???|
>> -- --   ---
>> -- --
>> |INIT| -|  |DFHEAI  |
>> --  |  --   ---
>> -> |MYASMBLR|   |R1 --> P/L|...|R13 -> S/A|
>>--   ---
>> -- --
>> |CICS| -|  |DFHEAI  |
>> --  |  --   ---
>> -> |MYASMBLR|   |R1 --> EIB|...|R13 -> S/A|
>>--   ---
>>
>> ...and after all that, this behaviour is observed under TS3.1 .
>Fascinating  I get the same result with a little program I cobbled up
>just to load some registers by duplicating the instructions in DFHEAI, then
>forcing a S0C1 and SVCDUMP.  If I omit the DFHEAI (I actually use DFHELII;
>same difference) stub I get a S0C4 on the first instruction (STM
>14,12,12(13) ).  Dump shows that R13 (and R12) both point to the "dummy" CSA
>address in fetch-protected (and write-protected) storage.
>
>When I prefix the DFHELII stub (exactly the same instructions as DFHEAI), my
>program runs until the S0C1 happens.  Dump shows R13 with a different
>address that R12 (which still has the fetch-protected "dummy" TCA address),
>but the DFH... stub does not modify R13.  First instruction after the
>unconditional branch at the end of the DFH stubs is ...  ...
STM  14,12,12(13)
>Since IBM took CICS "OCO" when they restructured it (ca. CICS/ESA 3.3) and
>removed API access to the CSA and TCA, I can't explain why "my" (and your)
>STM fails but theirs succeeds.
>So, it appears that a DFH stub is required at the front of an Assembler
>program that CICS will invoke directly, if only to get a valid savearea
>address in Reg13.
>
>-jc-
>

No magic involved. The 'stump' is passed control with appropriate R1 and R13
addresses once CICS determines it is command level.

Not trying to teach Granny to suck eggs but as previously reported here,
CICS 'inspects' the beginning of the load module to determine if it is
command level.

HTH

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