Re: crazy thoughts - keeping product installation infomation

[Andrew Armstrong]

I think this would be an excellent use for a Wiki server - of pretty much
any flavor, take your pick...

http://www.wikimatrix.org/

All you have to do is post your install JCL, output, sage advice, product
PDFs etc
onto it, and it is available as long as you have access to a web browser. If
the Wiki is located at your DR site then you automatically have the
information you need when you need it.

My two cents.

Cheers,
Andrew.

--
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: Remote tape drive

[R.S.]

Skip Robinson wrote:
[...]

Note also a complexity you need to plan for. MVS sees tape drives as
devices more or less indistinguishable from each other except for physical
characteristics. If you have any tape drives located far away from the data
center, you have to take precautions to prevent your system from trying to
mount a local tape on a remote drive. 


Same problem occurs when all drives are local. Let's take some drives on 
another floor, or - even worse - another geometry (but still the same 
generic). How would you manage 3590B, 3590H and 3592 ?

How would you manage 3490E and STK 9840C, 9840B ?
Of course there are means to do it under MVS, but - again - the problem 
is NOT related to the distance.



--
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.2008 r. kapita zakadowy BRE Banku SA  wynosi 
118.642.672 zote i zosta w caoci wpacony.

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

CICS/TS 2.3 and z/OS 1.7

[Bill Klein]

I was hoping that no one was going to be able to find any copies of that
paper still online.  I am sorry that you were still able to find it at the
site.

I spent quite a bit of time last year trying to work with Hursley and
getting that paper corrected (as well as updated).  There are some
INCREDIBLE errors in it - and were even when it was "current".  Since more
recent CICS, COBOL, and LE releases, it is even a WORSE document to believe.
The final decision that I received from Hursley was that it was going to be
"pulled" because it was so WRONG that it wasn't worth spending the resources
to fix (given the current state of the official documentation).

There are places in the current COBOL, LE, and CICS documentation that give
correct and current information on all the issues in that document.

PLEASE, do not rely on what it says without cross-checking with the official
documentation!!!

"Timur Alpaslan" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Why don't you try this one?
> It's a bit long, but...
> 
>
http://www-1.ibm.com/support/docview.wss?rs=0&dc=DA400&q1=Language+Environme
nt+within+CICS+TS&uid=swg27006638&loc=en_US&cs=utf-8&cc=us&lang=en
> 
> Cheers
> 
> > Date: Wed, 14 May 2008 15:13:00 -0500
> > From: [EMAIL PROTECTED]
> > Subject: Re: CICS/TS 2.3 and z/OS 1.7
> > To: IBM-MAIN@BAMA.UA.EDU
> > 
> > Following the provided link gave me an error.
> > 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> > Behalf Of Timur Alpaslan
> > Sent: Wednesday, May 14, 2008 1:26 AM
> > To: IBM-MAIN@BAMA.UA.EDU
> > Subject: Re: CICS/TS 2.3 and z/OS 1.7
> > 
> > I'll also recommend following White Paper by Robert Harris which can be
> > rather useful in many occasions even it's not updated since May 2005;
> > 
> > "Language Environment within CICS TS: Q&A"
> > 
> > http://www-1.ibm.com/support/docview.wss?uid=swg2700
> > 
> > 
> > 
> > 
> > 
> > > Date: Tue, 13 May 2008 18:26:45 -0500
> > > From: [EMAIL PROTECTED]
> > > Subject: CICS/TS 2.3 and z/OS 1.7
> > > To: IBM-MAIN@BAMA.UA.EDU
> > > 
> > > The exact requirements for ALL31(OFF) are at:
> > >  
> > >
> > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ceea3180/1.2.
> > 4.2 
> > > 
> > > 
> > > 
> > > "Imbriale, Donald" <[EMAIL PROTECTED]> wrote in message
> > >
> > news:<[EMAIL PROTECTED]
> > ar.c
> > > om>...
> > > > The information I provided was from the current LE manuals.  And I
> > have
> > > > confirmed this by running some tests.  ALL31(OFF) is needed if there
> > are
> > > > any AMODE 24 routines.
> > > > 
> > > > Don Imbriale
> > > > 
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> > > > Behalf Of Ted MacNEIL
> > > > Sent: Tuesday, May 13, 2008 2:49 PM
> > > > To: IBM-MAIN@BAMA.UA.EDU
> > > > Subject: Re: CICS/TS 2.3 and z/OS 1.7
> > > > 
> > > > >ALL31(OFF) is needed if there are any AMODE 24 routines.
> > > > 
> > > > Not according to IBM, as I said in my original post.
> > > > They still worked for us.
> > > > What happens with ALL31(ON), according to an IBM expert (whose name
> > > > escapes me), is the AMODE 24 support is not initialised until the
> > first
> > > > 24-bit programme is called.
> > > > 
> > > 
> > > --
> > > 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
> > 
> > ==
> > This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity
> > to which they are addressed. If you have received this email in error
please notify the system manager. This message
> > contains confidential information and is intended only for the
individual named. If you are not the named addressee you
> > should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you
> > have received this e-mail by mistake and delete this e-mail from your
system. If you are not the intended recipient
> > you are notified that disclosing, copying, distributing or taking any
action in reliance on the contents of this
> > information is strictly prohibited.

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

Re: Remote tape drive

[Dave Cartwright]

On Tue, 13 May 2008 13:37:20 -0600, David Logan 
<[EMAIL PROTECTED]> wrote:

>I would like to have a tape drive at a remote office from where the
>mainframe is physically located. Preferably a (normally) channel attached
>tape drive, rather than a SCSI type of thing, although I would take the
>latter if given no other choices.
>
>Does anyone happen to know what options I have available?
>

My immediate thought was of a Fundamental Software Flex-ES CUB based 
solution, but that is really an ESCON to SCSI connector.  You COULD use this 
to write Faketape (tm) files on a remote filesystem which could use a 
FakeTape to real tape program to create images on tape.  Maybe a Flex 
reseller such as T3 Technologies could help you out.

I would like to hear of a similar solution so that I could use our T-Server 
boat 
anchor now that it has been replaced by a Z9BC because of the IBM-FSI 
breakup.  Sadly it has a B&T channel card rather than the ESCON card 
required for CUB so the costs to make use of it outweigh the benefits.

I went to a Riverbed presentation yesterday and amongst the throw-away 
benefits their agents claim are huge speedups for NFS.  If true that may be an 
alternative to remote tape - a fast remote file system.

Good luck
Dave

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

CICS/TS 2.3 and z/OS 1.7

[Bill Klein]

Earlier in this thread there was a discussion about whether or not one was
"safe" ALWAYS using ALL31(ON) or not.

I think part of the confusion has to do with the subject of this thread
mentioning CICS.  If you are talking about a CICS environment (and the LE
run-time options specific to that), then it is true that for an ALL COBOL
(any compiler) CICS environment, you ARE totally safe using ALL31(On).

This is documented in the COBOL Migration guide at:

 It is in the COBOL Migration Guide. See:
  http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3mg40/3.1.1.2 

which states, (in part)<

"ALL31(ON) is the recommended setting for COBOL applications. You can use
ALL31(ON) if all of your VS COBOL II, IBM COBOL and Enterprise COBOL
programs are AMODE 31, even if you are also running OS/VS COBOL programs in
your CICS regions. (Load modules containing only OS/VS COBOL and
assembler programs are AMODE 24 and are not affected by the setting of
ALL31.) 

   ***

The confusion in this discussion may have to do with the fact that this does
NOT say that ALL31(ON) is supported for non-COBOL 24-bit applications under
CICS or COBOL or non-COBOL applications in a non-CICS environment.

If anyone can find cases where a COBOL-only CICS environment has problems
with ALL31(ON), this should be APARable - and IBM would certainly be
interested in such.  

P.S.  Concerning the reference to VS COBOL II and AMODE 31, CICS has always
required the RES compiler option (pre-LE) and this always (in VS COBOL II)
produced AMODE 31 code.  (CICS also required RENT which also produced RMODE
ANY code).   

   

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

Healther checker documentation

[Lindy Mayfield]

How is it possible that IBM let a sense of humor slip into the official
documentation?  Mainframes are serious business!  There's no room for
monkeying about, especially when health care is at stake.

Here are some things I ran across:

"Hey! My system has been configured like this for years, and now I'm
receiving exceptions!"

"Of course you're going to read this entire chapter to understand
everything you need to know about writing a REXX check. But we also have
what you're really looking for - REXX check samples in SYS1.SAMPLIB."

"Here are some automation ideas to kick around..."

"Programming Considerations: 2.2.4.4 Gotchas"

"Make your check clean up after itself, because the system won't do it
for you."

"The well-behaved local check routine..."

"Save time, save trouble - test your check with these commands..."

--
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: crazy thoughts - keeping product installation infomation

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Armstrong
> Sent: Thursday, May 15, 2008 2:13 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: crazy thoughts - keeping product installation infomation
> 
> I think this would be an excellent use for a Wiki server - of 
> pretty much
> any flavor, take your pick...
> 
> http://www.wikimatrix.org/
> 
> All you have to do is post your install JCL, output, sage 
> advice, product
> PDFs etc
> onto it, and it is available as long as you have access to a 
> web browser. If
> the Wiki is located at your DR site then you automatically have the
> information you need when you need it.
> 
> My two cents.
> 
> Cheers,
> Andrew.

I would love that. I suggested that. I was shot down. Them: "Nobody to
maintain it." Me: "I'll do it." Them: "Not your job function!"

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.  

--
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: Healther checker documentation

[Elardus Engelbrecht]

Lindy Mayfield wrote:
>How is it possible that IBM let a sense of humor slip into the official 
documentation?  Mainframes are serious business!  There's no room for 
monkeying about, especially when health care is at stake.

New generation authors or programmers in big blue?

>Here are some things I ran across:


More free quotes for you to worry about... :-D

"Make your check clean up after itself, because the system won't do it for 
you: "
 
"Have your check stop itself when necessary:"

"Naturally, we hope you'll never need this section and that all your checks
will run perfectly the very first time. However, if you do run into trouble, 
this 
section will help [ ... snipped ... ]"

"Cheat sheet: examples of MODIFY hzsproc commands"

etc...

Groete / Greetings
Elardus Engelbrecht

--
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: crazy thoughts - keeping product installation infomation

[Staller, Allan]

Is Wally or Dilbert in the next cube?

Is the PHB in the next cube? Wally, Dilbert?


I would love that. I suggested that. I was shot down. Them: "Nobody to
maintain it." Me: "I'll do it." Them: "Not your job function!"


--
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: crazy thoughts - keeping product installation infomation

[Ted MacNEIL]

>I would love that. I suggested that. I was shot down. Them: "Nobody to 
>maintain it." Me: "I'll do it." Them: "Not your job function!"

It's not your job function to maintain supporting documentation about how you 
do your job?

-
Too busy driving to stop for gas!

--
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: crazy thoughts - keeping product installation infomation

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL
> Sent: Thursday, May 15, 2008 7:47 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: crazy thoughts - keeping product installation infomation
> 
> >I would love that. I suggested that. I was shot down. Them: 
> "Nobody to maintain it." Me: "I'll do it." Them: "Not your 
> job function!"
> 
> It's not your job function to maintain supporting 
> documentation about how you do your job?

Yes, but not with that method. We have a method (the PDS version
previously mentioned) which "works well". So maintaining a Wiki or CMS
(Content Management System) is unnecessary. And, to be honest, I'm
likely the only one in the group who likes the idea. Curiously, I'm the
second oldest (55).

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.  

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

ADRDSSU to dump Selective mebers of PDS to PS or Tape

[vignesh]

Hi,
I am trying to use ADRDSSU with Dump option to dump all my PDS members 
using Include option. But the file created with dump option is with  Record 
length >80 and data is not viewable / meaningful format.
I tried the ADRDSSU with PRINT option too.Which also yielded the same result.

The Following is the output iam getting with the JCL as shown:

//STEP010  EXEC PGM=ADRDSSU,COND=(0,NE)
//SYSPRINT  DD SYSOUT=*
//INPUT12   DD DSN=xx.xxx.,DISP=SHR  (PDS dataset name)
//BKFILEDD DSN=SVRB.MDM.RAINQ.TEST.PROC1,DISP=SHR  
//SYSIN DD *   
   DUMP INDDNAME(INPUT12) OUTDDNAME(BKFILE)
/* 
//*

My output file contains:

...ç.ØØ._...STM246a...?.ãñè...4ã   
...>.Ø .BMBB.^·°.i...0"Û.0"..ÿ.¬Õ.Ø.{.."[EMAIL 
PROTECTED]
...>.Ø .BMBB.^[0.i.0.8.
...>.Ø .BMBB.^B&.iÚ


Could anyone offer any help on this.
Further, I also need to produce a Dump of members named AMP* friom my list 
of PDS files only.

--
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: crazy thoughts - keeping product installation infomation

[Jousma, David]

I'm surprised Rob Schramm has not replied to this topic, as he is a big
proponent of Wiki on mainframe.  

We run Wiki on the mainframe to store all of our doc.  Since we are a
multi-image shop we move the wiki around, so that it is always
available.  I imagine if you were a single image shop, that availability
could be an issue.

Wiki on mainframe works really nice, is completely searchable, and easy
to maintain.  Best of all it showcases some of the "new" things the old
mainframe can do.


___

Dave Jousma
Assistant Vice President
Mainframe Services
[EMAIL PROTECTED]
616.653.8429


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Andrew Armstrong
Sent: Thursday, May 15, 2008 3:13 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: crazy thoughts - keeping product installation infomation

I think this would be an excellent use for a Wiki server - of pretty
much any flavor, take your pick...

http://www.wikimatrix.org/

All you have to do is post your install JCL, output, sage advice,
product PDFs etc onto it, and it is available as long as you have access
to a web browser. If the Wiki is located at your DR site then you
automatically have the information you need when you need it.



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

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

Re: Remote tape drive

[Ron Hawkins]

Dave,

Riverbed's technology is not about speed, but rather the intelligent caching
of objects across the network. Reading something from the source location
the first time will be governed by whatever you have used  to link those
sites - it does not make the pipe any faster.

Ron

> 
> I went to a Riverbed presentation yesterday and amongst the throw-away
> benefits their agents claim are huge speedups for NFS.  If true that
> may be an
> alternative to remote tape - a fast remote file system.
> 

--
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: ADRDSSU to dump Selective mebers of PDS to PS or Tape

[Myers, Edouard (OCTO)]

I think you are using this for the wrong purpose. ADRDSSU is used for backing 
up and restoring datasets. The file it creates is only readable by ADRDSSU. Try 
IEBCOPY instead


Edouard A. Myers

Senior Information Technology Specialist
Office of the Chief Technology Officer  
DC Government  
222 Massachusetts Ave, NW, Suite 200 
Washington, DC 20001  

Phone : 202-727-4017 
Fax: 202-727-3880  
Email: [EMAIL PROTECTED]
Website: http://www.octo.dc.gov
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of 
vignesh
Sent: Thursday, May 15, 2008 8:43 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: ADRDSSU to dump Selective mebers of PDS to PS or Tape

Hi,
I am trying to use ADRDSSU with Dump option to dump all my PDS members 
using Include option. But the file created with dump option is with  Record 
length >80 and data is not viewable / meaningful format.
I tried the ADRDSSU with PRINT option too.Which also yielded the same result.

The Following is the output iam getting with the JCL as shown:

//STEP010  EXEC PGM=ADRDSSU,COND=(0,NE)
//SYSPRINT  DD SYSOUT=*
//INPUT12   DD DSN=xx.xxx.,DISP=SHR  (PDS dataset name)
//BKFILEDD DSN=SVRB.MDM.RAINQ.TEST.PROC1,DISP=SHR  
//SYSIN DD *   
   DUMP INDDNAME(INPUT12) OUTDDNAME(BKFILE)
/* 
//*

My output file contains:

...ç.ØØ._...STM246a...?.ãñè...4ã   
...>.Ø .BMBB.^·°.i...0"Û.0"..ÿ.¬Õ.Ø.{.."[EMAIL 
PROTECTED]
...>.Ø .BMBB.^[0.i.0.8.
...>.Ø .BMBB.^B&.iÚ


Could anyone offer any help on this.
Further, I also need to produce a Dump of members named AMP* friom my list 
of PDS files only.

--
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: ADRDSSU to dump Selective mebers of PDS to PS or Tape

[גדי בן אבי]

The output from ADRDSSU is not meant to be read by humans.

If you want to copy members from one PDS to another, use IEBCOPY.

Gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of 
vignesh
Sent: Thursday, May 15, 2008 3:43 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: ADRDSSU to dump Selective mebers of PDS to PS or Tape

Hi,
I am trying to use ADRDSSU with Dump option to dump all my PDS members using 
Include option. But the file created with dump option is with  Record length 
>80 and data is not viewable / meaningful format.
I tried the ADRDSSU with PRINT option too.Which also yielded the same result.

The Following is the output iam getting with the JCL as shown:

//STEP010  EXEC PGM=ADRDSSU,COND=(0,NE)
//SYSPRINT  DD SYSOUT=*
//INPUT12   DD DSN=xx.xxx.,DISP=SHR  (PDS dataset name)
//BKFILEDD DSN=SVRB.MDM.RAINQ.TEST.PROC1,DISP=SHR  
//SYSIN DD *   
   DUMP INDDNAME(INPUT12) OUTDDNAME(BKFILE)
/* 
//*

My output file contains:

...ç.ØØ._...STM246a...?.ãñè...4ã   
...>.Ø .BMBB.^·°.i...0"Û.0"..ÿ.¬Õ.Ø.{.."[EMAIL 
PROTECTED]
...>.Ø .BMBB.^[0.i.0.8.
...>.Ø .BMBB.^B&.iÚ


Could anyone offer any help on this.
Further, I also need to produce a Dump of members named AMP* friom my list of 
PDS files only.

--
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: crazy thoughts - keeping product installation infomation

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Jousma, David
> Sent: Thursday, May 15, 2008 7:56 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: crazy thoughts - keeping product installation infomation
> 
> I'm surprised Rob Schramm has not replied to this topic, as 
> he is a big
> proponent of Wiki on mainframe.  
> 
> We run Wiki on the mainframe to store all of our doc.  Since we are a
> multi-image shop we move the wiki around, so that it is always
> available.  I imagine if you were a single image shop, that 
> availability
> could be an issue.
> 
> Wiki on mainframe works really nice, is completely 
> searchable, and easy
> to maintain.  Best of all it showcases some of the "new" 
> things the old
> mainframe can do.
> 
> ___
> 
> Dave Jousma

I've looked at JSPWiki. But the argument against using the mainframe is
basically that we are "maxed out" and don't want to use "expensive
cycles" for such things. I'm am slowly, slowly, showing off a few, very
minor and small Web based applications that are z/OS hosted. One is our
RACF administration, which I modelled on a TSO program. The other is my
"dataset list" function. Both of these so that the user doesn't need to
log on to TSO for a "quick and dirty" function.

Oh, and my pushing for a zAAP to run Java is shot down because: (1) it
costs money; (2) the mainframe is going away; (3) we don't run Java on
the mainframe. My contention that if we had a zAAP we could write Java
code to run on the mainframe usually gets the response of "the
programmers know COBOL, not Java." But it basically goes back to reason
#2. Mangement is convinced that eliminating the mainframe for  is the Holy Grail and has for the
last 3 administrations.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.  

--
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: Question About DFDSS :FCNOCOPY/FCWITHDRAW - Problem Found/Resovled

[esmie moo]

Andrew,
   
  We finally found the problem - bad drive in the ROBOT.  It was not apparent 
from our tracking tools (so much for those softwares).  It took continous batch 
job abends which raised our suspicion.  We had the drive checked and found a 
defective R/W head.
   
  Thanks to all who responded to my post.

Andrew N Wilt <[EMAIL PROTECTED]> wrote:
  Esmie,
I would add the UTILMSG=YES parameter to the backup EXEC statements.
This will tell you if DFSMSdss is invoking ICKDSF to init the volumes
instead of simply issuing the FCWITHDRAW after the DUMP is completed. If
ICKDSF is being invoked, it is because the VTOC tracks of the DASD volume
are in a target FlashCopy relationship, and issuing an FCWITHDRAW against
them could well cause the volume to be online but invalid (because the VTOC
location now contains the residual data from before the FlashCopy was done
to it).

Thanks,

Andrew Wilt
IBM DFSMSdss Architecture/Development


IBM Mainframe Discussion List wrote on 05/08/2008
08:43:05 AM:

> [image removed]
>
> Question About DFDSS :FCNOCOPY/FCWITHDRAW
>
> esmie moo
>
> to:
>
> IBM-MAIN
>
> 05/08/2008 08:46 AM
>
> Sent by:
>
> IBM Mainframe Discussion List 
>
> Please respond to IBM Mainframe Discussion List 
>
> Good Morning Gentle Readers,
>
> I am investigating a problem with a backup(backups of SNAP
> volumes) that is executed daily. For some reason in the last 2 days
> the backup has been taking 12-15 hours to execute. I covered all
> angles : changes to the job, Z/OS version, tape mounts/tape drives,
> scheduling, envirnonment changes etc. Nothing has been changed. I
/snip
>
> //BACKUP1 EXEC PGM=ADRDSSU,TIME=60
> //SYSPRINT DD SYSOUT=*
> //SYSUDUMP DD SYSOUT=*
> //DEV1LST DD SYSOUT=*
> //INDEV DD UNIT=3390,VOL=SER=SNAP01,DISP=SHR
> //OUTDEV DD DSN=SYS2.BACKUP1.OUT.SYS001(+1),
> // DISP=(,CATLG,DELETE),
> // DCB=GDGDSCB,
> // UNIT=3490,VOL=(,RETAIN),
> // LABEL=(01,SL)
> //SYSIN DD *
> DUMP FULL INDD(INDEV) OUTDD(OUTDEV) CAN OPT(4) FCWITHDRAW
> //*
> //BACKUP2 EXEC PGM=ADRDSSU,TIME=60
> //SYSPRINT DD SYSOUT=*
> //SYSUDUMP DD SYSOUT=*
> //DEV1LST DD SYSOUT=*
/snip
--
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



   
-
Looking for the perfect gift? Give the gift of Flickr!

--
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: Remote tape drive

[Hal Merritt]

Well, there -are- such things as B/T to ESCON converters. And there are
some shops out there who have some that need a good home (nudge, nudge,
wink, wink.)

To the OP: is there some reason you could not attach a tape unit to the
MP-3000 using native channels and use FTP to get the data there? 

Also to the OP: most modern tap units can drive an ESCON path to
saturation. I believe the current ROT is one path per transport. That
should give you an idea as to pipe size needed to get the best use of
the unit.   

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Cartwright
Sent: Thursday, May 15, 2008 3:38 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Remote tape drive

On Tue, 13 May 2008 13:37:20 -0600, David Logan 
<[EMAIL PROTECTED]> wrote:

>I would like to have a tape drive at a remote office from where the
>mainframe is physically located. Preferably a (normally) channel
attached
>tape drive, rather than a SCSI type of thing, although I would take the
>latter if given no other choices.
>
>Does anyone happen to know what options I have available?
>

My immediate thought was of a Fundamental Software Flex-ES CUB based 
solution, but that is really an ESCON to SCSI connector.  You COULD use
this 
to write Faketape (tm) files on a remote filesystem which could use a 
FakeTape to real tape program to create images on tape.  Maybe a Flex 
reseller such as T3 Technologies could help you out.

I would like to hear of a similar solution so that I could use our
T-Server boat 
anchor now that it has been replaced by a Z9BC because of the IBM-FSI 
breakup.  Sadly it has a B&T channel card rather than the ESCON card 
required for CUB so the costs to make use of it outweigh the benefits.

I went to a Riverbed presentation yesterday and amongst the throw-away 
benefits their agents claim are huge speedups for NFS.  If true that may
be an 
alternative to remote tape - a fast remote file system.

Good luck
Dave

 

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

Re: crazy thoughts - keeping product installation infomation

[Tom Marchant]

On Thu, 15 May 2008 08:06:44 -0500, McKown, John wrote:
>
>I've looked at JSPWiki. But the argument against using the mainframe is
>basically that we are "maxed out" and don't want to use "expensive
>cycles" for such things.

I guess the PHB's think that PDS doesn't use those "expensive" mainframe 
resources.

-- 
Tom Marchant

--
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: Remote tape drive

[Daniel McLaughlin]

Just so happens we have some surplus ESCON converters. If one is needed I 
can check with the PTB for disposition.

Daniel McLaughlin
Z-Series Systems Programmer
Information & Communications Technology
Crawford & Company
4680 N. Royal Atlanta
Tucker GA 30084 
phone: 770-621-3256 
fax: 770-621-3237
email: [EMAIL PROTECTED]
web: www.crawfordandcompany.com 



IBM Mainframe Discussion List  wrote on 05/15/2008 
09:36:11 AM:

> Hal Merritt <[EMAIL PROTECTED]> 
> Sent by: IBM Mainframe Discussion List 
> 
> 05/15/2008 09:36 AM
> 
> Please respond to
> IBM Mainframe Discussion List 
> 
> To
> 
> IBM-MAIN@BAMA.UA.EDU
> 
> cc
> 
> Subject
> 
> Re: Remote tape drive
> 
> -- Information from the mail header 
> ---
> Sender:   IBM Mainframe Discussion List 
> Poster:   Hal Merritt <[EMAIL PROTECTED]>
> Subject:  Re: Remote tape drive
> 
---
> 
> Well, there -are- such things as B/T to ESCON converters. And there are
> some shops out there who have some that need a good home (nudge, nudge,
> wink, wink.)
> 
> To the OP: is there some reason you could not attach a tape unit to the
> MP-3000 using native channels and use FTP to get the data there? 
> 
> Also to the OP: most modern tap units can drive an ESCON path to
> saturation. I believe the current ROT is one path per transport. That
> should give you an idea as to pipe size needed to get the best use of
> the unit. 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Dave Cartwright
> Sent: Thursday, May 15, 2008 3:38 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Remote tape drive
> 
> On Tue, 13 May 2008 13:37:20 -0600, David Logan 
> <[EMAIL PROTECTED]> wrote:
> 
> >I would like to have a tape drive at a remote office from where the
> >mainframe is physically located. Preferably a (normally) channel
> attached
> >tape drive, rather than a SCSI type of thing, although I would take the
> >latter if given no other choices.
> >
> >Does anyone happen to know what options I have available?
> >
> 
> My immediate thought was of a Fundamental Software Flex-ES CUB based 
> solution, but that is really an ESCON to SCSI connector.  You COULD use
> this 
> to write Faketape (tm) files on a remote filesystem which could use a 
> FakeTape to real tape program to create images on tape.  Maybe a Flex 
> reseller such as T3 Technologies could help you out.
> 
> I would like to hear of a similar solution so that I could use our
> T-Server boat 
> anchor now that it has been replaced by a Z9BC because of the IBM-FSI 
> breakup.  Sadly it has a B&T channel card rather than the ESCON card 
> required for CUB so the costs to make use of it outweigh the benefits.
> 
> I went to a Riverbed presentation yesterday and amongst the throw-away 
> benefits their agents claim are huge speedups for NFS.  If true that may
> be an 
> alternative to remote tape - a fast remote file system.
> 
> Good luck
> Dave
> 
> 
> 
> 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 



Best Overall Third-Party Claims Administrator - 2007 "Business Insurance" 
Readers Choice Awards
 
Consider the environment before printing this message.

This transmission is intended exclusively for the individual or entity to which 
it is addressed. This communication may contain information that is 
confidential, proprietary, privileged or otherwise exempt from disclosure. If 
you are not the named addressee, you are NOT authorized to read, print, retain, 
copy or disseminate this communication, its attachments or any part of them. If 
you have received this communication in error, please notify the sender 
immediately and delete this communication from all computers.  This 
communication does not form any contractual obligation on behalf of the sender, 
the sender's employer, or the employer's parent company, affiliates or 
subsidiaries.

--
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: crazy thoughts - keeping product installation infomation

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant
> Sent: Thursday, May 15, 2008 8:38 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: crazy thoughts - keeping product installation infomation
> 
> On Thu, 15 May 2008 08:06:44 -0500, McKown, John wrote:
> >
> >I've looked at JSPWiki. But the argument against using the 
> mainframe is
> >basically that we are "maxed out" and don't want to use "expensive
> >cycles" for such things.
> 
> I guess the PHB's think that PDS doesn't use those 
> "expensive" mainframe 
> resources.
> 
> -- 
> Tom Marchant

I guess it is because using TSO is "normal" and the cycles used to
maintain the doc PDSes is "buried" in other activity, whereas having a
Wiki can be directly measured. Also, I am fairly sure that maintaining
and accessing a PDS with TSO/ISPF costs fewer cycles than using a Wiki
to do "equivalent" work.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.  

--
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: crazy thoughts - keeping product installation infomation

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of McKown, John
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf Of Andrew Armstrong
> > [ snip ]
> > 
> > I think this would be an excellent use for a Wiki server - 
> > of pretty much any flavor, take your pick...
> > 
> > http://www.wikimatrix.org/
> > 
> > All you have to do is post your install JCL, output, sage advice, 
> > product PDFs etc onto it, and it is available as long as you have 
> > access to a web browser. If the Wiki is located at your DR site then

> > you automatically have the information you need when you need it.
> 
> I would love that. I suggested that. I was shot down. Them: 
> "Nobody to maintain it." Me: "I'll do it." Them: "Not your 
> job function!"

"I'm not allowed to drive the train;
The whistle I can't blow.

I'm not allowed to specify
How fast the train will go.

I'm not allowed to blow off steam,
Nor even clang the bell.

But let the damn thing jump the track,
And see who catches hell!"

(It's Friday somewhere.  :-) )

-jc-

> 
> --
> John McKown
> Senior Systems Programmer
> HealthMarkets
> Keeping the Promise of Affordable Coverage Administrative 
> Services Group Information Technology
> 
> The information contained in this e-mail message may be 
> privileged and/or confidential.  It is for intended 
> addressee(s) only.  If you are not the intended recipient, 
> you are hereby notified that any disclosure, reproduction, 
> distribution or other use of this communication is strictly 
> prohibited and could, in certain circumstances, be a criminal 
> offense.  If you have received this e-mail in error, please 
> notify the sender by reply and delete this message without 
> copying or disclosing it.  
> 
> --
> 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: Remote tape drive

[David Logan]

>> To the OP: is there some reason you could not attach a tape unit to the
>> MP-3000 using native channels and use FTP to get the data there?

Yes. Getting the data there isn't the issue. The hard part is FTPing the
warm body to the tape drive so that said warm body could *mount* a tape.
This is a development shop, not production. There are no operators. The
people mulling up and down the hallways at the remote location are generally
unwilling to stop and mount a tape, and even if they were willing, they go
home at 5 :)

>> Also to the OP: most modern tap units can drive an ESCON path to
>> saturation. I believe the current ROT is one path per transport. That
>> should give you an idea as to pipe size needed to get the best use of
>> the unit.   

Thanks! As I said, it's only a development shop, so a single unit would
suffice. We just need some type of access to a tape unit.

David Logan
Manager of Product Development, Pitney Bowes Business Insights
http://centrus.com
4750 Walnut St, Suite 200
Boulder, CO  80301
W: (720) 564-3056

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Hal Merritt
Sent: Thursday, May 15, 2008 7:36 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Remote tape drive

Well, there -are- such things as B/T to ESCON converters. And there are
some shops out there who have some that need a good home (nudge, nudge,
wink, wink.)

To the OP: is there some reason you could not attach a tape unit to the
MP-3000 using native channels and use FTP to get the data there? 

Also to the OP: most modern tap units can drive an ESCON path to
saturation. I believe the current ROT is one path per transport. That
should give you an idea as to pipe size needed to get the best use of
the unit.   

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Cartwright
Sent: Thursday, May 15, 2008 3:38 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Remote tape drive

On Tue, 13 May 2008 13:37:20 -0600, David Logan 
<[EMAIL PROTECTED]> wrote:

>I would like to have a tape drive at a remote office from where the
>mainframe is physically located. Preferably a (normally) channel
attached
>tape drive, rather than a SCSI type of thing, although I would take the
>latter if given no other choices.
>
>Does anyone happen to know what options I have available?
>

My immediate thought was of a Fundamental Software Flex-ES CUB based 
solution, but that is really an ESCON to SCSI connector.  You COULD use
this 
to write Faketape (tm) files on a remote filesystem which could use a 
FakeTape to real tape program to create images on tape.  Maybe a Flex 
reseller such as T3 Technologies could help you out.

I would like to hear of a similar solution so that I could use our
T-Server boat 
anchor now that it has been replaced by a Z9BC because of the IBM-FSI 
breakup.  Sadly it has a B&T channel card rather than the ESCON card 
required for CUB so the costs to make use of it outweigh the benefits.

I went to a Riverbed presentation yesterday and amongst the throw-away 
benefits their agents claim are huge speedups for NFS.  If true that may
be an 
alternative to remote tape - a fast remote file system.

Good luck
Dave

 

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 [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: Looking for concise (!) OPERATOR-oriented manual(s) to manage & drive CICS, DB2 and IMS

[Hal Merritt]

Alas, real console operators. I knew them, Jan, fellows of infinite jest, of 
most excellent fat fingers. They hath bore me on their back a thousand times. 
(Shameless and horrible rip off of Hamlet, act 5, scene 1.)

IMNSHO, the 'definitive' operator instructions are one printed page with mostly 
white space. Banned words include 'If', 'when' and 'else'. Banned resources 
would include the console. The document proper might be written by one of your 
better operators. If you can't do that, then perhaps your environment needs 
some work. In my experience, high on the top ten causes of issues were operator 
errors.  The root cause of many of those errors were calling for decisions 
based on incomplete or even defective information. 
 
Since the implementation of those mighty subsystems vary greatly from shop to 
shop (and sometimes even shift to shift) a 'one size fits all' doc would be 
pretty hard to write. 

My $0.02 (before taxes). 

HTH and good luck!


   

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jan 
Vanbrabant
Sent: Wednesday, May 14, 2008 5:14 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Looking for concise (!) OPERATOR-oriented manual(s) to manage & drive 
CICS, DB2 and IMS

*** cross-posted to IBM-MAIN, IMS-L, CICS-L and DB2-L listservers ***

1°
Looking for concise (!) OPERATOR-oriented manual(s)to manage & drive CICS, DB2 
and IMS
instead of thesejust PARTLY oriented operator manuals, which are much too 
overloaded for them: 
SC18-7416-05 DB2 UDB for z/OS V8 --- Command Reference (February 2008)
http://publib.boulder.ibm.com/epubs/pdf/dsncrj15.pdf

...snip
 
After quite some investigation,I don’t think they exist.
Any other pointers?

2°
And what about an IMS/TM manual for DB2 like there is the
SC34-6837-01 CICS Transaction Server for z/OSDB2 Guide V3R2
for CICS and DB2?

jan



 

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

Re: Remote tape drive

[Hal Merritt]

I'm confused. My original reply addressed the TCO (total cost of ownership) of 
a remote tape drive which included the biological components. 

Ignoring that, the options include channel extenders or some sort of store and 
forward process that exploits the MP-3000 MVS. 

Back to the biological issue, a 3590 ATL (Auto Tape Loader) features a cassette 
for about a dozen cartridges. That might be a good fit if your mission is 
output only. Once every so often, a carbon based biological unit could swing by 
and perform the TLC. The 3590's are long gone from marketing, so used units 
should be available for not much more than shipping and installation. In fact, 
I gave two such units away not long ago. 

HTH.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of 
David Logan
Sent: Thursday, May 15, 2008 9:01 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Remote tape drive

>> To the OP: is there some reason you could not attach a tape unit to the
>> MP-3000 using native channels and use FTP to get the data there?

Yes. Getting the data there isn't the issue. The hard part is FTPing the
warm body to the tape drive so that said warm body could *mount* a tape.
This is a development shop, not production. There are no operators. The
people mulling up and down the hallways at the remote location are generally
unwilling to stop and mount a tape, and even if they were willing, they go
home at 5 :)

>> Also to the OP: most modern tap units can drive an ESCON path to
>> saturation. I believe the current ROT is one path per transport. That
>> should give you an idea as to pipe size needed to get the best use of
>> the unit.   

Thanks! As I said, it's only a development shop, so a single unit would
suffice. We just need some type of access to a tape unit.

David Logan
Manager of Product Development, Pitney Bowes Business Insights
http://centrus.com
4750 Walnut St, Suite 200
Boulder, CO  80301
W: (720) 564-3056

 

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

Re: crazy thoughts - keeping product installation infomation

[Arthur T.]

On 15 May 2008 00:13:05 -0700, in bit.listserv.ibm-main 
(Message-ID:<[EMAIL PROTECTED]>) 
[EMAIL PROTECTED] (Andrew Armstrong) wrote:



If
the Wiki is located at your DR site then you automatically 
have the

information you need when you need it.


My feeling is that the only times you should have to back 
up data from the DR site is after a test or after a 
disaster.  Putting live data there could really confuse 
things.  How do you get the data if the DR site is down?


Much better to follow SOP and put the data in some normal 
place, take normal backups of it, and have procedures to 
restore it at the DR site when needed.



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

Re: Cleanup a unconnected Coupling Facility

[Arthur Gutowski]

Coming up with a "fresh" CFRM CDS in DR is a quick and effective solution, if 
your configuration supports it.  We *used* to do this very same thing, when 
we had several "sham"plexes.  Then we revised our DR setup (specifying BOTH 
CF's in the PREFLISTs, as someone else pointed out).

I wonder, has anyone who uses th "clean" CFRM CDS technique migrated to 
GRS Star?

We are migrating our sysplexes and monoplexes into a cross-site sysplex 
("sham"plex/e) for PSA pricing, and as we will have more than two systems, 
we saw fit to migrate away from Ring.

During sandbox testing, and implementing our first production system last 
night, I discovered that GRS Star does not IPL when you have a brand-
spanking new CFRM dataset, even if it has a policy loaded into it, because 
that policy has not yet been STARTED.  Because you cannot START the policy 
from the new CFRM dataset prior to IPL, and COMMNDxx is too late to start 
the policy, I found I had to override the IPL SYSP=(xx,yy,...),GRS=TRYJOIN, 
get the Ring initialized, start the CFRM policy, then SETGRS MODE=STAR.  I 
IPLed a second time, just to make sure all was well.

Just some food for thought... If anyone else is in STAR, using the "clean" 
CFRM technique and has an easier way, I'd love to hear from you.  Going 
forward, this might not be a concern for us, but the first one was a little 
rough.

Regards,
Art Gutowski
Ford Motor Company IT Infrastructure
[EMAIL PROTECTED]

--
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: absurd programs that used to be everywhere ...

[Rick Fochtman]

---
If you just want block letters, roll your own with IEFSD095.
--
Or pick up EALSD095 from the CBTTAPE site; useage is the same but a 
broader character set, including some special characters.


--
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: Cleanup a unconnected Coupling Facility

[Mark Jacobs]

Arthur Gutowski wrote:
> Coming up with a "fresh" CFRM CDS in DR is a quick and effective solution, if 
> your configuration supports it.  We *used* to do this very same thing, when 
> we had several "sham"plexes.  Then we revised our DR setup (specifying BOTH 
> CF's in the PREFLISTs, as someone else pointed out).
>
> I wonder, has anyone who uses th "clean" CFRM CDS technique migrated to 
> GRS Star?
>
> We are migrating our sysplexes and monoplexes into a cross-site sysplex 
> ("sham"plex/e) for PSA pricing, and as we will have more than two systems, 
> we saw fit to migrate away from Ring.
>
> During sandbox testing, and implementing our first production system last 
> night, I discovered that GRS Star does not IPL when you have a brand-
> spanking new CFRM dataset, even if it has a policy loaded into it, because 
> that policy has not yet been STARTED.  Because you cannot START the policy 
> from the new CFRM dataset prior to IPL, and COMMNDxx is too late to start 
> the policy, I found I had to override the IPL SYSP=(xx,yy,...),GRS=TRYJOIN, 
> get the Ring initialized, start the CFRM policy, then SETGRS MODE=STAR.  I 
> IPLed a second time, just to make sure all was well.
>
> Just some food for thought... If anyone else is in STAR, using the "clean" 
> CFRM technique and has an easier way, I'd love to hear from you.  Going 
> forward, this might not be a concern for us, but the first one was a little 
> rough.
>
> Regards,
> Art Gutowski
> Ford Motor Company IT Infrastructure
> [EMAIL PROTECTED]
>
>   

The CFRMPOL option in the COUPLExx member takes care of your GRSSTAR
problem.


-- 
Mark Jacobs
Time Customer Service
Tampa, FL


Progress doesn't come from early risers - progress is made 
by lazy men looking for easier ways to do things.

Robert A. Heinlein - Time Enought for Love(1973)

--
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: S33E abend and X33E slip

[Rick Fochtman]

When an address space terminates normally, RCT simply detaches the dump 
task. The 33E abend is normal and expected.


When you run the application as a batch job, ending the job does not 
terminate the initiator address space.

--
Wouldn't it be easier, and more efficient, to have RCT signal the dump 
task so it could go through normal termination, rather than generating 
an abend and going through all the related processing, including SLIP? 
Maybe it's a dumb question, but it seems to me that a little 
coordination via WAIT/POST could do the trick very nicely.


Considering all the control blocks already related to the address space, 
one more ECB can't be that hard to define.


--
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: Cleanup a unconnected Coupling Facility

[Mark Zelden]

On Thu, 15 May 2008 10:17:09 -0500, Arthur Gutowski <[EMAIL PROTECTED]> wrote:


>
>During sandbox testing, and implementing our first production system last
>night, I discovered that GRS Star does not IPL when you have a brand-
>spanking new CFRM dataset, even if it has a policy loaded into it, because
>that policy has not yet been STARTED.  Because you cannot START the policy
>from the new CFRM dataset prior to IPL, and COMMNDxx is too late to start
>the policy, I found I had to override the IPL SYSP=(xx,yy,...),GRS=TRYJOIN,
>get the Ring initialized, start the CFRM policy, then SETGRS MODE=STAR.  I
>IPLed a second time, just to make sure all was well.
>
>Just some food for thought... If anyone else is in STAR, using the "clean"
>CFRM technique and has an easier way, I'd love to hear from you.  Going
>forward, this might not be a concern for us, but the first one was a little
>rough.
>

That is how we do it for the sysplexes running GRS STAR. 

 1) IPL with an IEASYSxx that has GRS=TRYJOIN, 
 2) Load a CFRM policy
 3) START CFRM policy
 4) SETGRS MODE=STAR.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Cleanup a unconnected Coupling Facility

[Mark Zelden]

On Thu, 15 May 2008 10:42:48 -0500, Mark Zelden <[EMAIL PROTECTED]>
wrote:

>
>That is how we do it for the sysplexes running GRS STAR.
>
> 1) IPL with an IEASYSxx that has GRS=TRYJOIN,
> 2) Load a CFRM policy
> 3) START CFRM policy
> 4) SETGRS MODE=STAR.
>

There are RACF and JES2 considerations also since we run with RACF
data sharing and JES2 checkpoint in the CF in some sysplexes.  
When RACF detects a problem with the CF at IPL time, it comes up in 
read only mode.

A more complete list looks something like this.

1) IPL with an IEASYSxx that has GRS=TRYJOIN,
2) RACF RVARY NODATASHARE   (RACF = subsystem command char.)
2) Load a CFRM policy
3) START CFRM policy  
4) SETGRS MODE=STAR.
5) RACF RVARY DATASHARE 
6) $TCKPTDEF,RECONFIG=Y 


--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Cleanup a unconnected Coupling Facility

[Skip Robinson]

As I've indicated in previous posts, we began doing DR with DASD mirroring
years before GRS star even existed. We would simply IPL one system
minimally, run a job to create a CFRM policy in the freshly formatted
couple data set, activate the policy, and bring up the rest of the system.
With GRS star, that procedure would no longer work because no system will
IPL at all unless the ISGLOCK structure can be allocated in a defined and
reachable CF.

IBM knew this would put a serious cramp in customers' DR procedures, so
they invented the CFRMPOL parameter in COUPLExx. The sole purpose of this
parameter is to name a policy to activate at IPL if the CFRM couple data
set indicates that no policy is already active. In other words, when IPLing
with a freshly formatted CFRM couple data set. You have the ability to
create a policy and store it in 'another' couple data set by volser, one
belonging to another sysplex or to no active sysplex at all, but you cannot
activate it 'remotely'. When a system is IPLed with that CFRM couple data
set, CFRMPOL tells XCF to activate the named policy (previously stored
there) at IPL time.

BTW anyone with a parallel sysplex should be running GRS star. Our
experience shows that even a single system performs better in star mode
than in ring mode.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]


   
 Mark Zelden   
 <[EMAIL PROTECTED] 
 CHNA.COM>  To 
 Sent by: IBM  IBM-MAIN@BAMA.UA.EDU
 Mainframe  cc 
 Discussion List   
 <[EMAIL PROTECTED] Subject 
 .EDU> Re: Cleanup a unconnected Coupling  
   Facility
   
 05/15/2008 08:42  
 AM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  
 <[EMAIL PROTECTED] 
   .EDU>   
   
   




On Thu, 15 May 2008 10:17:09 -0500, Arthur Gutowski <[EMAIL PROTECTED]>
wrote:


>
>During sandbox testing, and implementing our first production system last
>night, I discovered that GRS Star does not IPL when you have a brand-
>spanking new CFRM dataset, even if it has a policy loaded into it, because
>that policy has not yet been STARTED.  Because you cannot START the policy
>from the new CFRM dataset prior to IPL, and COMMNDxx is too late to start
>the policy, I found I had to override the IPL
SYSP=(xx,yy,...),GRS=TRYJOIN,
>get the Ring initialized, start the CFRM policy, then SETGRS MODE=STAR.  I
>IPLed a second time, just to make sure all was well.
>
>Just some food for thought... If anyone else is in STAR, using the "clean"
>CFRM technique and has an easier way, I'd love to hear from you.  Going
>forward, this might not be a concern for us, but the first one was a
little
>rough.
>

That is how we do it for the sysplexes running GRS STAR.

 1) IPL with an IEASYSxx that has GRS=TRYJOIN,
 2) Load a CFRM policy
 3) START CFRM policy
 4) SETGRS MODE=STAR.

Mark

--
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: Cleanup a unconnected Coupling Facility

[Mark Zelden]

>IBM knew this would put a serious cramp in customers' DR procedures, so
>they invented the CFRMPOL parameter in COUPLExx. The sole purpose of this
>parameter is to name a policy to activate at IPL if the CFRM couple data
>set indicates that no policy is already active.

Which works great if you know what hardware you will be running on.  For
those who run at a vendor's site, you can't count on this.  

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: HIPAA auditing (was:RE: VSAM / COBOL question - redux (fwd))

[Galambos, Robert]

 All valid questions.

While the information captured must be complete (showing the  complete session 
in question from initiation to completion), the storage of the information  
should be in a 'compressed' form. The reasoning is to try to save on storage 
space as well.

Your question about application testing eluded to a bigger question. How can 
one 'selectively' monitor/audit transactions/MQ/APPC etc traffic. Any  solution 
worth its weight should allow for this. Certain terminals/regions etc. may have 
different needs for auditing vs. others. 

Then there is the question about test data. One must also make sure that, if 
production data is being copied to a test/qa/user acceptance testing area that 
the data be 'scrubbed' beforehand, or once again one can have issues of data  
exposures

And least we forget the legal requirements that are all  'forced' upon us. 
Whether its abiding by laws (an example is PIPEDA in Canada, or the EU 
directive) or court required chain of evidence rules all must be taken into 
account.

So the reason behind my previous post. While capturing logs will show that what 
changes/deletion etc happened, it will not prove beyond any reasonable doubt 
that a breach has occurred, or who was the culprit. Browsing the data is as 
important action to monitor as changing/ deleting the data is. Because at the 
end of the day, its still exposing personnel information to individuals that 
may not have authority to do so.. 

All concerns. Let me know if you want to talk more about this


 
Robert Galambos CIPP/C  

Compuware Senior Technical Specialist 
IBM Certified Solutions Expert - 
DB2 UDB for OS/390 Database Administration
Certified Information Privacy Professional/Canada 
[EMAIL PROTECTED]
 
  
Tel: +1 905 886 7000 
Toll Free: +1 800 263 7189
Fax: +1 905 886 7023
Quebec: +1 877-281-1888 
  
Compuware  Canada

Service is our best product 
 Les renseignements contenus dans le présent message électronique sont 
confidentiels et concernent exclusivement le(s) destinataire(s) désigné(s). Il 
est strictement interdit de distribuer ou de copier ce message. Si vous avez 
reçu ce message par erreur, veuillez répondre par courriel à l'expéditeur et 
effacer ou détruire toutes les copies du présent message.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of 
Clark Morris
Sent: Monday, May 12, 2008 4:15 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: HIPAA auditing (was:RE: VSAM / COBOL question - redux (fwd))

On 12 May 2008 10:35:48 -0700, in bit.listserv.ibm-main you wrote:

>You are correct that this auditing must be done.  This "Application Auditing" 
>must include not just what a RACF log would show - that someone had access to 
>a file, but to show exactly what the user saw.  It is one thing to know that 
>someone logged in, accessed a sensitive file and logged out later in the day, 
>but the requirements are to be able to know what they were doing and which 
>sensitive information they saw.  You would need to be able to see they same 
>screens they saw.  This "Application Auditing" is possible and goes beyond 
>what logs can do.  

How much data needs to be stored in order to accomplish that?   What
are the implications for application testing?  Does this mean that test data 
correction must include obfuscation of identifiable data?

Clark Morris
>
>
> 
>Robert Galambos CIPP/C
>
>Compuware Senior Technical Specialist
>IBM Certified Solutions Expert -
>DB2 UDB for OS/390 Database Administration Certified Information 
>Privacy Professional/Canada [EMAIL PROTECTED]
> 
>  
>Tel: +1 905 886 7000
>Toll Free: +1 800 263 7189
>Fax: +1 905 886 7023
>Quebec: +1 877-281-1888
>  
>Compuware  Canada
>   
>Service is our best product
> Les renseignements contenus dans le présent message électronique sont 
> confidentiels et concernent exclusivement le(s) destinataire(s) désigné(s). 
> Il est strictement interdit de distribuer ou de copier ce message. Si vous 
> avez reçu ce message par erreur, veuillez répondre par courriel à 
> l'expéditeur et effacer ou détruire toutes les copies du présent message.
>
>
>The contents of this e-mail are intended for the named addressee only. It 
>contains information that may be confidential. Unless you are the named 
>addressee or an authorized designee, you may not copy or use it, or disclose 
>it to anyone else. If you received it in error please notify us immediately 
>and then destroy it.
>
>From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On 
>Behalf Of McKown, John
>Sent: Friday, May 09, 2008 8:25 AM
>To: IBM-MAIN@BAMA.UA.EDU
>Subject: HIPAA auditing (was:RE: VSAM / COBOL question - redux (fwd))
>
>> -Original Message-
>> From: IBM Mainframe Discussion List
>> [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth E Tomiak
>> Sent: Thursday, May 08, 2008 7:10 PM
>> To: IBM-MAIN@BAMA.UA.EDU
>> Subject: Re: VSAM / COBOL question - redux (fwd)
>> 
>> My understanding of HIPA

Display or view the Crypto Current domain index or Usage domain index

[Roberto Ibarra]

This might sound like a RACF-L posting but think it has more to do with
operating system, please let me know: 

when we do tests on a recovery site we have to change the DOMAIN parameter
in SYS1.PARMLIB(CSFPRMxx) to the domain that the HW people tell us. In order
to avoid asking them (just a time issue). I've been doing some tests
eliminating the DOMAIN parameter so ICSF could take it from the HW??? as the
ICSF SPs Guide says:

“...If DOMAIN is not specified in the options data set, ICSF determines
which domains are available in this LPAR. If only one domain is defined for
the LPAR, ICSF will use it...”

obviously this will work fine if there is only one domain per LPAR if that
changes anytime, then as stated:

“...ICSF will issue error message CSFM409E...”

Question is: is there any way to “display” from the operating system (or
from a REXX program, something like IPLINFO maybe?) the Current domain index
or Usage domain index?? sure ICSF takes it from somewhere in the system, but
where? 

Think I should post this in the RACF-L??

Thanks in advance for any help! 

--
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: Cleanup a unconnected Coupling Facility

[Skip Robinson]

For the method I describe, I don't think you need to know any more any
earlier than for the ring-to-star method. What you do need is a 'driving'
system, in our case the SDM host that was performing XRC mirroring until
the moment of disconnect. I would have thought that any DR site provided a
driving system to get the ball rolling; if not, then you can't use my
method.

If there is a driving system at the DR site, you use it to create the DR
policy and store it in your own CFRM data set by volser before your first
IPL. COUPLExx needs only the policy name. We got creative and decided to
call ours POLICYDR, which is permanently coded in CFRMPOL in production.

One of our original goals for a DR procedure was to keep it as simple as
possible. Assuming that a gaggle of sysprogs would not necessarily be front
and center in a true DR, we might need to depend on any available
operations person or godforbid even a manager type with limited experience.
In the case of a third party provider, you might have a very experienced
person who happens to know squat about your particular environment. The
simpler the procedure, the better chance you have of getting your systems
running ASAP.




   
 Mark Zelden   
 <[EMAIL PROTECTED] 
 CHNA.COM>  To 
 Sent by: IBM  IBM-MAIN@BAMA.UA.EDU
 Mainframe  cc 
 Discussion List   
 <[EMAIL PROTECTED] Subject 
 .EDU> Re: Cleanup a unconnected Coupling  
   Facility
   
 05/15/2008 09:29  
 AM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  
 <[EMAIL PROTECTED] 
   .EDU>   
   
   




>IBM knew this would put a serious cramp in customers' DR procedures, so
>they invented the CFRMPOL parameter in COUPLExx. The sole purpose of this
>parameter is to name a policy to activate at IPL if the CFRM couple data
>set indicates that no policy is already active.

Which works great if you know what hardware you will be running on.  For
those who run at a vendor's site, you can't count on this.

Mark

--
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: Cleanup a unconnected Coupling Facility

[Mark Zelden]

On Thu, 15 May 2008 09:50:02 -0700, Skip Robinson <[EMAIL PROTECTED]>
wrote:

>If there is a driving system at the DR site, you use it to create the DR
>policy and store it in your own CFRM data set by volser before your first
>IPL. COUPLExx needs only the policy name. We got creative and decided to
>call ours POLICYDR, which is permanently coded in CFRMPOL in production.
>

Ok... got ya now.   Yes, that could easily be done from a floor system
or a RESCUE system that is IPLed first.  

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: S33E abend and X33E slip

[Miklos Szigetvari]

Rick Fochtman wrote:



When an address space terminates normally, RCT simply detaches the 
dump task. The 33E abend is normal and expected.


When you run the application as a batch job, ending the job does not 
terminate the initiator address space.

--
Wouldn't it be easier, and more efficient, to have RCT signal the dump 
task so it could go through normal termination, rather than generating 
an abend and going through all the related processing, including SLIP? 
Maybe it's a dumb question, but it seems to me that a little 
coordination via WAIT/POST could do the trick very nicely.


Considering all the control blocks already related to the address 
space, one more ECB can't be that hard to define.


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




--
Miklos Szigetvari

Development Team
ISIS Information Systems Gmbh 
tel: (+43) 2236 27551 570
Fax: (+43) 2236 21081 

E-mail: [EMAIL PROTECTED] 

Info: [EMAIL PROTECTED] 
Hotline: +43-2236-27551-111 

Visit our Website: http://www.isis-papyrus.com 
---

This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS accepts
no responsibility for malicious or inappropriate content.
--- 


--
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: Display or view the Crypto Current domain index or Usage domain index

[Mark Zelden]

On Thu, 15 May 2008 11:28:51 -0500, Roberto Ibarra
<[EMAIL PROTECTED]> wrote:

>This might sound like a RACF-L posting but think it has more to do with
>operating system, please let me know:
>
>when we do tests on a recovery site we have to change the DOMAIN parameter
>in SYS1.PARMLIB(CSFPRMxx) to the domain that the HW people tell us. In order
>to avoid asking them (just a time issue). I've been doing some tests
>eliminating the DOMAIN parameter so ICSF could take it from the HW??? as the
>ICSF SPs Guide says:
>
>“...If DOMAIN is not specified in the options data set, ICSF determines
>which domains are available in this LPAR. If only one domain is defined for
>the LPAR, ICSF will use it...”
>
>obviously this will work fine if there is only one domain per LPAR if that
>changes anytime, then as stated:
>
>“...ICSF will issue error message CSFM409E...”
>
>Question is: is there any way to “display” from the operating system (or
>from a REXX program, something like IPLINFO maybe?) the Current domain index
>or Usage domain index?? sure ICSF takes it from somewhere in the system, but
>where?
>
>Think I should post this in the RACF-L??
>
>Thanks in advance for any help!
>

You probably know this already, but if you see it from the ICSF ISPF panels
if it comes active.  But I assume you are asking for the case where more
than one is assigned and you want to find out.   

BTW,  we use a system symbol for domain and specify that in our 
CSF parms.  For DR there is a different IEASYMxx that has the correct
domain.  This goes back to when you had to have domain in there (or
at least when I thought you had to have it in there - and still may be
required if running on older hardware).

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: S33E abend and X33E slip

[Miklos Szigetvari]

Rick Fochtman wrote:



When an address space terminates normally, RCT simply detaches the 
dump task. The 33E abend is normal and expected.


When you run the application as a batch job, ending the job does not 
terminate the initiator address space.

--
Wouldn't it be easier, and more efficient, to have RCT signal the dump 
task so it could go through normal termination, rather than generating 
an abend and going through all the related processing, including SLIP? 
Maybe it's a dumb question, but it seems to me that a little 
coordination via WAIT/POST could do the trick very nicely.


Considering all the control blocks already related to the address 
space, one more ECB can't be that hard to define.


I agree with this 100%

It turned out,  the original problem was a HASP310  "TERMINATED AT END 
OF MEMORY" condition, and  as I seen the X33E traps and the HASP310 
explanation,
I thought the S33E abend is the responsible  for "TERMINATED AT END OF 
MEMORY".

Currently I have no idea who is responsible  for HASP310

--
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: VMWare more reliable

[Craddock, Chris]

> than the mainframe.  Or so it was reported back in January...
> 
> http://redmondmag.com/features/article.asp?editorialsid=2400#reliable
> 
> But disputed...
> 
> Watch the wrap.
> 
> http://serverspecs.blogs.techtarget.com/2008/05/13/vmware-esx-more-
> reliable-than-the-mainframe-says-mag/?track=NL-
> 576&ad=639921&asrc=EM_NLN_3643720&uid=1900046

I loved the comment "The least stable part of ESX is usually the
administrator. The code is virtually bomb-proof." That is pretty much
the case with every major piece of technology today. People are the
problem.

As to whether ESX is more reliable that "a mainframe" - I guess that
depends on what you're comparing. Realistically though, I'd say... "not
a prayer".

CC

--
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: CLIST and REXX list locations

[Paul Gilmartin]

On Wed, 14 May 2008 15:24:32 -0400, Jack Kelly wrote:

>  ... CLIST seems to be a loss cause?
>
Amen.

-- gil

--
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: ADRDSSU to dump Selective mebers of PDS to PS or Tape

[Paul Gilmartin]

On Thu, 15 May 2008 09:00:33 -0400, Myers, Edouard (OCTO) wrote:

>I think you are using this for the wrong purpose. ADRDSSU is used for backing 
>up and restoring datasets. The file it creates is only readable by ADRDSSU. 
>Try IEBCOPY instead
>
And how many other utilities will read a file offloaded by IEBCOPY?

(Actually, somewhat unwarranted rhetoric.  I know a few: CMS PIPELINES,
ISPF/VM, and (IIRC) XMIT Manager.)

But for maximum portability, I'd suggest copying it to a UNIX directory
and archiving that (selectively) with Info-Zip or pax.

If you want it human-readable, there's IEBUPDTE, with restrictions.

-- gil

--
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: S33E abend and X33E slip

[Edward Jaffe]

Rick Fochtman wrote:
Wouldn't it be easier, and more efficient, to have RCT signal the dump 
task so it could go through normal termination, rather than generating 
an abend and going through all the related processing, including SLIP? 
Maybe it's a dumb question, but it seems to me that a little 
coordination via WAIT/POST could do the trick very nicely.


I doubt it would be easier or more efficient. And, in the midst of an 
abnormal termination scenario, it might not even work!


Why is anyone suddenly concerned about this decades-old, benign behavior 
of displaying X33E when an address space terminates? Personally, I 
*like* to see the X33E SLIP message. It tells me something *extremely* 
useful -- namely the ASID of the address space that just terminated! 
Clearly, one man's information is another man's clutter...


There are at least a dozen expected abend conditions with SLIP A=NODUMP 
defined in IEASLP00. If you're not happy with those settings, you can 
delete them or redefine them to specify different actions. Specifically, 
for the case being described in this thread, the following commands will 
suppress the IEA989I message for any S33E abend s going forward:


SLIP DEL,ID=X33E
SLIP SET,C=33E,ID=X33E,A=IGNORE,END

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.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

May 28th -LVC- High Availability for Linux on IBM System z Servers

[Pamela Christina-on a cloudy day in Endicott]

For those on IBMVM, LINUX390, IBMMAIN who are interested in an hour
of no-charge education via webcast.

Two LVC's coming up on Wed May 28 and Thurs. May 29.
Here's the May 28 info

The next Live Virtual Class (LVC)/Webcast is scheduled for
Wednesday, May 28th at 11:00 AM EDT.

There is no charge to participate in this technical education session.

Wednesday, May 28, 2008 at 11:00 AM EDT US & Canada

WEBCAST:  High Availability for Linux on IBM System z Servers

Speaker:Scott Loveland, IBM Customer Test Chief Architect
Systems/Product Assurance Engineering Professional

Abstract:
Linux virtual servers are increasingly being used to support
critical applications in IBM System z and zSeries server environments. As
the mission becomes more important; so does the need to ensure its
supporting infrastructure is highly available. But how? z/OS system
programmers know the best practices for eliminating single points of
failure for their systems; but may be unsure how to translate those
techniques to the Linux world. Admins coming from a distributed Linux
background may wonder how a virtualized environment on zSeries changes the
game. And both groups may ponder how to best marry the Linux and z/OS
worlds to maximize availability.

Wonder no more. This session will cover a set of high availability
architectures for Linux virtual servers (LVS); in the context of serving
data to WebSphere applications (though WebSphere itself won't be the main
focus). We'll discuss:

1. Single points of failure in an LVS environment; probabilities of each;
and the relative cost to eliminate them -- with examples of how to do so
2. The power of virtualization to minimize degradation of service in the
wake of failures; and to reduce the need for large clusters of redundant
servers
3. How software running on Linux virtual servers can work cooperatively
with a Parallel Sysplex and z/OS data sharing groups
4. Sample architecture specifics; including architectural decisions and
tradeoffs; configuration options; and product technologies used

Date: Wed - May 28, 2008
Time:  11:00 AM Eastern Daylight Time (New York),
   10:00 AM Central Daylight Time
   London 4:00 PM, Frankfurt  5:00 PM,
   Moscow  7:00PM
Duration: 75 minutes

How to attend:
Connect to the Live Virtual Class (LVC) session using the following URL:
URL:  https://asp22.centra.com:443/GA/main/0148c02f0119890365ca8e2f
 OR
Connect from the z/VM Website at:
http://www.vm.ibm.com/education/lvc

You can connect to the LVC session up to 10 minutes prior to the start of
the session.

You do not have to pre-register to attend the webcast, but you will need to
enter your email to join the call.

The REPLAY will be available on the web using the same "connect" URL
approximately 4 hours after the event.

If you are unable to connect to the Live Virtual Class session, you can
download the presentation from the z/VM LVC website the day
before the webcast and listen to the audio portion of the session via
telephone using the following:

Teleconference Information
Call info:1 - 888-240-4148
Toll: 1 - 719-234-0214
 Passcode:   893049

 Note: use of the telephone connection does not provide capability for you
to ask questions during the session.

Replays: As a reminder, the 2007/2008 sessions are available for replay
from the z/VM website at:
http://www.vm.ibm.com/education/lvc


Please direct any questions to Julie Liesenfelt at [EMAIL PROTECTED]


Regards,
Pam C (on behalf of Julie)

--
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: ADRDSSU to dump Selective mebers of PDS to PS or Tape

[Lizette Koehler]

If you have SAS on the mainframe then you can use the SAS UNLOAD function and 
select members.  It creates an IEBUPDTE output file which is readable.


PROC SOURCE INDD=INDD  OUTDD=OUTDD ;
  EXCLUDE=BOO: ;   (Or INCLUDE=XXX: for all members beginning with XXX) 
   

PROC SOURCE INDD=INDD OUTDD=OUTDD ;

The example above will dump the entire PDS as IEBUPDTE.


Otherwise DFDSS will only create output readable by DFDSS.  What is the 
function you are trying to create?  Backup process, Archive process?  Audit 
Control?


Lizette



>I am trying to use ADRDSSU with Dump option to dump all my PDS members 
>using Include option. But the file created with dump option is with  Record 
>length >80 and data is not viewable / meaningful format.
>I tried the ADRDSSU with PRINT option too.Which also yielded the same result.
>
>The Following is the output iam getting with the JCL as shown:
>
>//STEP010  EXEC PGM=ADRDSSU,COND=(0,NE)
>//SYSPRINT  DD SYSOUT=*
>//INPUT12   DD DSN=xx.xxx.,DISP=SHR  (PDS dataset name)
>//BKFILEDD DSN=SVRB.MDM.RAINQ.TEST.PROC1,DISP=SHR  
>//SYSIN DD *   
>   DUMP INDDNAME(INPUT12) OUTDDNAME(BKFILE)
>/* 
>//*
>
>My output file contains:
>
>...ç.ØØ._...STM246a...?.ãñè...4ã   
>...>.Ø .BMBB.^·°.i...0"Û.0"..ÿ.¬Õ.Ø.{.."[EMAIL 
>PROTECTED]
>...>.Ø .BMBB.^[0.i.0.8.
>...>.Ø .BMBB.^B&.iÚ
>
>
>Could anyone offer any help on this.
>Further, I also need to produce a Dump of members named AMP* friom my list 
>of PDS files only.

--
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: VMWare more reliable

[Howard Brazee]

On 15 May 2008 10:09:45 -0700, [EMAIL PROTECTED] (Craddock, Chris)
wrote:

>I loved the comment "The least stable part of ESX is usually the
>administrator. The code is virtually bomb-proof." That is pretty much
>the case with every major piece of technology today. People are the
>problem.

8^)   (Cars without people are crash-proof too!)

So get rid of the people.

But one place where this issue is obvious is in the policies companies
create for secure passwords.   People can't remember a hundred unique
secure passwords, so a policy of requiring them to do so is not a
secure policy.

--
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: Display or view the Crypto Current domain index or Usage domain index

[Roberto Ibarra Magdaleno]

Yes Mark, thanks,

saw that in the panel that's why I tought ICSF can take it out from
somewhere, because if you code the wrong domain the panel shows it, but if
you do not code DOMAIN then the panel shows the right one. But precisely the
question comes before we start ICSF in order to code the parameter and bring
it up. Yes, to know if there is only one domain number assigned or more.

Symbols sounds good, thought in them but still you have to depend in a fixed
domain for the recovery site, right?

Roberto.

On Thu, May 15, 2008 at 12:04 PM, Mark Zelden <[EMAIL PROTECTED]>
wrote:

> On Thu, 15 May 2008 11:28:51 -0500, Roberto Ibarra
> <[EMAIL PROTECTED]> wrote:
>
> >This might sound like a RACF-L posting but think it has more to do with
> >operating system, please let me know:
> >
> >when we do tests on a recovery site we have to change the DOMAIN parameter
> >in SYS1.PARMLIB(CSFPRMxx) to the domain that the HW people tell us. In
> order
> >to avoid asking them (just a time issue). I've been doing some tests
> >eliminating the DOMAIN parameter so ICSF could take it from the HW??? as
> the
> >ICSF SPs Guide says:
> >
> >"...If DOMAIN is not specified in the options data set, ICSF determines
> >which domains are available in this LPAR. If only one domain is defined
> for
> >the LPAR, ICSF will use it..."
> >
> >obviously this will work fine if there is only one domain per LPAR if that
> >changes anytime, then as stated:
> >
> >"...ICSF will issue error message CSFM409E..."
> >
> >Question is: is there any way to "display" from the operating system (or
> >from a REXX program, something like IPLINFO maybe?) the Current domain
> index
> >or Usage domain index?? sure ICSF takes it from somewhere in the system,
> but
> >where?
> >
> >Think I should post this in the RACF-L??
> >
> >Thanks in advance for any help!
> >
>
> You probably know this already, but if you see it from the ICSF ISPF panels
> if it comes active.  But I assume you are asking for the case where more
> than one is assigned and you want to find out.
>
> BTW,  we use a system symbol for domain and specify that in our
> CSF parms.  For DR there is a different IEASYMxx that has the correct
> domain.  This goes back to when you had to have domain in there (or
> at least when I thought you had to have it in there - and still may be
> required if running on older hardware).
>
> Mark
> --
> Mark Zelden
> Sr. Software and Systems Architect - z/OS Team Lead
> Zurich North America / Farmers Insurance Group - ZFUS G-ITO
> mailto:[EMAIL PROTECTED]
> 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 [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: Display or view the Crypto Current domain index or Usage domain index

[Jousma, David]

If there is ever only one domain assigned to a particular lpar, then
don't code anything, period.  My understanding is that domain only needs
to be coded if you assign more than one to the same lpar.  In our shop,
we have only one domain per lpar, and we don't code it in the CSFPRMxx
members 


___

Dave Jousma
Assistant Vice President
Mainframe Services
[EMAIL PROTECTED]
616.653.8429


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Roberto Ibarra Magdaleno
Sent: Thursday, May 15, 2008 2:05 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Display or view the Crypto Current domain index or Usage
domain index

Yes Mark, thanks,

saw that in the panel that's why I tought ICSF can take it out from
somewhere, because if you code the wrong domain the panel shows it, but
if you do not code DOMAIN then the panel shows the right one. But
precisely the question comes before we start ICSF in order to code the
parameter and bring it up. Yes, to know if there is only one domain
number assigned or more.

Symbols sounds good, thought in them but still you have to depend in a
fixed domain for the recovery site, right?

Roberto.


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

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

BLSCECT Imbedded members missing?

[Ken Porowski]

Installing z/OS 1.8 and reviewing various PARMLIB members I am having no
luck in locating the following members referenced in BLSCECT.  I've
looked everywhere I could think of (TLIBs, CPAC libs, doc, SMP, Google).

Anyone know where they are (or if they no longer exist)?

IMBED MEMBER(IGDIPCSP) ENVIRONMENT(ALL) /* DFP   @L1A*/
IMBED MEMBER(DXRIPCSP) ENVIRONMENT(ALL) /* IRLM  @L1A*/
IMBED MEMBER(DSNIPCSP) ENVIRONMENT(ALL) /* DB2   @L1A*/
IMBED MEMBER(ISPIPCSP) ENVIRONMENT(ALL) /* ISPF  @L1A*/
IMBED MEMBER(IKJIPCSP) ENVIRONMENT(ALL) /* TSO/E @L1A*/

Thanks all

Ken Porowski
AVP Systems Software
CIT Group
E: [EMAIL PROTECTED]



--
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: Display or view the Crypto Current domain index or Usage domain index

[Roberto Ibarra Magdaleno]

Still the same question David, how to know if there is always only one
domain without asking anyone, but the system?


On Thu, May 15, 2008 at 1:12 PM, Jousma, David <[EMAIL PROTECTED]> wrote:

> If there is ever only one domain assigned to a particular lpar, then
> don't code anything, period.  My understanding is that domain only needs
> to be coded if you assign more than one to the same lpar.  In our shop,
> we have only one domain per lpar, and we don't code it in the CSFPRMxx
> members
>
>
> ___
>
> Dave Jousma
> Assistant Vice President
> Mainframe Services
> [EMAIL PROTECTED]
> 616.653.8429
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Roberto Ibarra Magdaleno
> Sent: Thursday, May 15, 2008 2:05 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Display or view the Crypto Current domain index or Usage
> domain index
>
> Yes Mark, thanks,
>
> saw that in the panel that's why I tought ICSF can take it out from
> somewhere, because if you code the wrong domain the panel shows it, but
> if you do not code DOMAIN then the panel shows the right one. But
> precisely the question comes before we start ICSF in order to code the
> parameter and bring it up. Yes, to know if there is only one domain
> number assigned or more.
>
> Symbols sounds good, thought in them but still you have to depend in a
> fixed domain for the recovery site, right?
>
> Roberto.
>
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or disseminate it
> in any manner. If you are not the intended recipient, any disclosure,
> copying, distribution or use of the contents of this information is
> prohibited. Please reply to the message immediately by informing the sender
> that the message was misdirected. After replying, please erase it from your
> computer system. Your assistance in correcting this error is appreciated.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [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: Display or view the Crypto Current domain index or Usage domain index

[Mark Zelden]

On Thu, 15 May 2008 13:05:14 -0500, Roberto Ibarra Magdaleno
<[EMAIL PROTECTED]> wrote:


>Symbols sounds good, thought in them but still you have to depend in a fixed
>domain for the recovery site, right?
>

Yes.   That should be part of the vendor's DR setup for your site.  Assuming
you are not running under VM, they have to set up CPs, memory, weights,
LPAR names, etc.  This is just one more thing.  

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: S33E abend and X33E slip

[Jim Mulder]

Miklos Szigetvari <[EMAIL PROTECTED]> wrote on 05/15/2008 
01:05:01 PM:

> Rick Fochtman wrote:
> 
> > 
> > When an address space terminates normally, RCT simply detaches the
> > dump task. The 33E abend is normal and expected.
> >
> > When you run the application as a batch job, ending the job does not
> > terminate the initiator address space.
> > --
> > Wouldn't it be easier, and more efficient, to have RCT signal the dump
> > task so it could go through normal termination, rather than generating
> > an abend and going through all the related processing, including SLIP?
> > Maybe it's a dumb question, but it seems to me that a little
> > coordination via WAIT/POST could do the trick very nicely.
> >
> > Considering all the control blocks already related to the address
> > space, one more ECB can't be that hard to define.
> 
> I agree with this 100%
> 
> It turned out,  the original problem was a HASP310  "TERMINATED AT END
> OF MEMORY" condition, and  as I seen the X33E traps and the HASP310
> explanation,
> I thought the S33E abend is the responsible  for "TERMINATED AT END OF
> MEMORY".
> Currently I have no idea who is responsible  for HASP310

  HASP310 indicates that the job failed due to abnormal memory 
termination.  This should be preceeded by an IEF402I message. 

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

--
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: Cleanup a unconnected Coupling Facility

[Arthur Gutowski]

Thanks all for pointing out the CFRMPOL keyword.  That would have saved me 
some grief in building my new sysplex.  Perfect that it is ignored if there is 
an 
active policy "checkpointed" in the dataset, unlike COMMNDxx.  I hoped this 
was new with z/OS 1.8 (just got to), but much to my chagrin, I found it in the 
z/OS 1.6 I/T Ref (just came from).  One day I'll learn to RTFM...

Now that we're past the first system, it doesn't matter, unless someday we 
build a *complete* DR solution.  Just the same, I think I'll update PARMLIB...

Regards,
Art Gutowski
Ford Motor Company ITInfrastructure
[EMAIL PROTECTED]

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

Racroute and cross memory question

[David Day]

I have an application that has two components.  An ISPF user interface, and a 
server address space.  Server address space runs authorized.  I would like to 
use a generalized resource rule to protect certain functions within the 
application.  The ISPF session communicates with the server address space via a 
space switch PC.  Nothing in the ISPF session executes authorized, and I would 
like to keep it that way, if I could.  In reading the manual for Racroute, the 
manual states it has to be invoked in non-cross memory, authorized, except as 
noted for certain request types.  The REQUEST=AUTH request type does not 
mention anything about being able to execute in cross memory mode.  I had hoped 
to be able to do this while the PC was executing inside the server address 
space, where PASN=server, and SASN and HASN = the ISPF address space.

I could add a function to an existing task within the server to do the 
checking, but then I have to add logic to make the request to the server 
task,park the user task till the request completes, then wake the user back up. 
 Seems like a long way to go for this function.

Can RACROUTE REQUEST=AUTH be used inside a space switch PC when PASN is not 
equal to HASN? 

--Dave Day

--
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: Cleanup a unconnected Coupling Facility

[Field, Alan C.]

Don't feel bad Art. I had to have IBM L2 point this one out at about
04:00 when everything was down and none of the sysplex lpars would IPL.


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

Subject: Re: Cleanup a unconnected Coupling Facility

Thanks all for pointing out the CFRMPOL keyword.  That would have saved
me 
some grief in building my new sysplex.  Perfect that it is ignored if
there is an 
active policy "checkpointed" in the dataset, unlike COMMNDxx.  I hoped
this 
was new with z/OS 1.8 (just got to), but much to my chagrin, I found it
in the 
z/OS 1.6 I/T Ref (just came from).  One day I'll learn to RTFM...

Now that we're past the first system, it doesn't matter, unless someday
we 
build a *complete* DR solution.  Just the same, I think I'll update
PARMLIB...

Regards,
Art Gutowski
Ford Motor Company ITInfrastructure
[EMAIL PROTECTED]

--
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: Racroute and cross memory question

[Edward Jaffe]

David Day wrote:
[snip]

I could add a function to an existing task within the server to do the 
checking, but then I have to add logic to make the request to the server 
task,park the user task till the request completes, then wake the user back up. 
 Seems like a long way to go for this function.
  


Worse yet, the server task would have to somehow assume the identity of 
the user for the duration of the RACROUTE request. If you can't issue 
the RACROUTE with PASN<>HASN, I might consider SCHEDIRB to schedule a 
simple privileged routine to do the checking under the user's TCB.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.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: Racroute and cross memory question

[Binyamin Dissen]

On Thu, 15 May 2008 15:21:38 -0500 David Day <[EMAIL PROTECTED]> wrote:

:>I have an application that has two components.  An ISPF user interface, and a 
server address space.  Server address space runs authorized.  I would like to 
use a generalized resource rule to protect certain functions within the 
application.  The ISPF session communicates with the server address space via a 
space switch PC.  Nothing in the ISPF session executes authorized, and I would 
like to keep it that way, if I could.  In reading the manual for Racroute, the 
manual states it has to be invoked in non-cross memory, authorized, except as 
noted for certain request types.  The REQUEST=AUTH request type does not 
mention anything about being able to execute in cross memory mode.  I had hoped 
to be able to do this while the PC was executing inside the server address 
space, where PASN=server, and SASN and HASN = the ISPF address space.

:>I could add a function to an existing task within the server to do the 
checking, but then I have to add logic to make the request to the server 
task,park the user task till the request completes, then wake the user back up. 
 Seems like a long way to go for this function.

:>Can RACROUTE REQUEST=AUTH be used inside a space switch PC when PASN is not 
equal to HASN? 

FASTAUTH can - and you load the profiles in the server address space.

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

Re: Racroute and cross memory question

[Wayne Driscoll]

RACROUTE REQUEST=AUTH cannot be issued with HASN<>PASN.  However,
REQUEST=AUTH and REQUEST=FASTAUTH do not require APF authorization for the
general usage.  I would think that you want the request to execute on behalf
of the ISPF user, not the server address anyway, so putting the requests in
the application prior to issuing the PC-ss would make sense.  If you are
trying to avoid having the code in the TSO user address space, you might be
able to have the server load a routine into CSA, set it up as a PC-cp that
is on a SYSTEM LX, have the PC-cp routine perform the RACROUTE request, then
issue the PC-ss if the RACROUTE succeeded.  Now I have never attempted to
issue a RACROUTE from a PC-cp routine.  The reason that a RACROUTE
REQUEST=AUTH cannot be issued in space switch PC is because REQUEST=AUTH
(usually, often, always) results in an SVC instruction (at least with RACF).

Wayne Driscoll
Product Developer
NOTE:  All opinions are strictly my own.


 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of David Day
Sent: Thursday, May 15, 2008 3:22 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Racroute and cross memory question

I have an application that has two components.  An ISPF user interface, and
a server address space.  Server address space runs authorized.  I would like
to use a generalized resource rule to protect certain functions within the
application.  The ISPF session communicates with the server address space
via a space switch PC.  Nothing in the ISPF session executes authorized, and
I would like to keep it that way, if I could.  In reading the manual for
Racroute, the manual states it has to be invoked in non-cross memory,
authorized, except as noted for certain request types.  The REQUEST=AUTH
request type does not mention anything about being able to execute in cross
memory mode.  I had hoped to be able to do this while the PC was executing
inside the server address space, where PASN=server, and SASN and HASN = the
ISPF address space.

I could add a function to an existing task within the server to do the
checking, but then I have to add logic to make the request to the server
task,park the user task till the request completes, then wake the user back
up.  Seems like a long way to go for this function.

Can RACROUTE REQUEST=AUTH be used inside a space switch PC when PASN is not
equal to HASN? 

--Dave Day

--
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: Racroute and cross memory question

[Rob Scott]

>If you are trying to avoid having the code in the TSO user address space, you 
>might be able to have the server load a routine into CSA, set it up as a PC-cp 
>that is on a SYSTEM LX, have the PC-cp routine perform the RACROUTE request, 
>then issue the PC-ss if the RACROUTE succeeded.

Been there, done that - works a treat.


Rob Scott
Rocket Software, Inc
275 Grove Street
Newton, MA 02466
617-614-2305
[EMAIL PROTECTED]


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of 
Wayne Driscoll
Sent: 15 May 2008 21:56
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Racroute and cross memory question

RACROUTE REQUEST=AUTH cannot be issued with HASN<>PASN.  However, REQUEST=AUTH 
and REQUEST=FASTAUTH do not require APF authorization for the general usage.  I 
would think that you want the request to execute on behalf of the ISPF user, 
not the server address anyway, so putting the requests in the application prior 
to issuing the PC-ss would make sense.  If you are trying to avoid having the 
code in the TSO user address space, you might be able to have the server load a 
routine into CSA, set it up as a PC-cp that is on a SYSTEM LX, have the PC-cp 
routine perform the RACROUTE request, then issue the PC-ss if the RACROUTE 
succeeded.  Now I have never attempted to issue a RACROUTE from a PC-cp 
routine.  The reason that a RACROUTE REQUEST=AUTH cannot be issued in space 
switch PC is because REQUEST=AUTH (usually, often, always) results in an SVC 
instruction (at least with RACF).

Wayne Driscoll
Product Developer
NOTE:  All opinions are strictly my own.




-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of 
David Day
Sent: Thursday, May 15, 2008 3:22 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Racroute and cross memory question

I have an application that has two components.  An ISPF user interface, and a 
server address space.  Server address space runs authorized.  I would like to 
use a generalized resource rule to protect certain functions within the 
application.  The ISPF session communicates with the server address space via a 
space switch PC.  Nothing in the ISPF session executes authorized, and I would 
like to keep it that way, if I could.  In reading the manual for Racroute, the 
manual states it has to be invoked in non-cross memory, authorized, except as 
noted for certain request types.  The REQUEST=AUTH request type does not 
mention anything about being able to execute in cross memory mode.  I had hoped 
to be able to do this while the PC was executing inside the server address 
space, where PASN=server, and SASN and HASN = the ISPF address space.

I could add a function to an existing task within the server to do the 
checking, but then I have to add logic to make the request to the server 
task,park the user task till the request completes, then wake the user back up. 
 Seems like a long way to go for this function.

Can RACROUTE REQUEST=AUTH be used inside a space switch PC when PASN is not 
equal to HASN?

--Dave Day

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

--
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: Mainframe programming vs the Web

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 05/12/2008
   at 10:19 PM, Ted MacNEIL <[EMAIL PROTECTED]> said:

>Since I'm not a JAVA expert,

Clearly not, if you believe that JavaScript has anything to do with Java
;-)
 
-- 
 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: Mainframe programming vs the Web

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 05/13/2008
   at 10:08 AM, Daniel McLaughlin <[EMAIL PROTECTED]> said:

>While we're speaking of books we no longer have, but wish we did, I vote 
>for "The Adolescence of P1".

I found that my willing suspension of disbelief could not stand up to the
technological gaffs.

What I wish that I still had is my copy of A Programming Language.
 
-- 
 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: Mainframe programming vs the Web

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 05/11/2008
   at 02:25 PM, David Alcock <[EMAIL PROTECTED]> said:

>Subject: Mainframe programming vs the Web

Versus? It's perfectly feasible to serve web pages on z/OS.

>Ever since the Web came along I've been annoyed by those web sites that
>won't accept spaces or dashes like for credit cards and phone numbers. 
>I know that even ancient mainframe COBOL has support for removing them
>with one command.   I see that it's just pure laziness as I suspected
>all along: 

Never attribute to laziness what can be explained by incompetence or by
managerial fiat.

IAC, there is nothing about, e.g. *bsd, Linux, Intel, SPARC, windoze that
requires writing poorly designed web pages with hostile user interfaces.
Google for Tufte[1] for some principles that, while not intended for the
web, are still quite relevant.

BTW, removing optional spaces and hyphens from a credit card number is a
simple one liner in Perl and similar languages. It's not the platform,
it's the implementors.

[1] Who, IMHO, should be mandatory reading for anybody presenting
data to human viewers.
 
-- 
 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: Mainframe programming vs the Web

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
A<[EMAIL PROTECTED]>AA<
[EMAIL PROTECTED]
> <[EMAIL PROTECTED]>,
on 05/13/2008
   at 01:36 PM, "Robert A. Rosenberg" <[EMAIL PROTECTED]> said:

>Agreed but you need a US Town not a County to be equivalent since you 
>normally are not asked for your County.

If you don't like counties, how about, e.g., Hell, MI, Intercourse, PA.
 
-- 
 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: Mainframe programming vs the Web

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
05/13/2008
   at 12:15 PM, Tony Harminc <[EMAIL PROTECTED]> said:

>Over editing is often worse than under,

I'd be tempted to say always worse, not just often. Don't do validation
without first learning what isa valid. A related sin is insisting on a
fixed format without telling the end user what that format is, e.g., if
you don't acept punctuation then tell the user that *BEFORE* he keys in
the data.

>Disallowing valid characters in email addresses. I'd say the majority of
>sites won't allow a plus sign,

In my experience it's not a majority, but certainly far too many.

>Same goes for all-numeric domain names.

Those are invalid. From RFC 1035:

  ::=  | " "

  ::=  |  "." 

  ::=  [ [  ]  ]

Now, you might want to accept invalid names regardless, but rejecting them
is not in the same category as rejecting RFC complaint names.
 
-- 
 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: Mainframe programming vs the Web

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 05/13/2008
   at 02:34 PM, Gary Green <[EMAIL PROTECTED]> said:

>Are you certain it was a DOS system.  I thought it was an MFT, or MVT,
>and "housed" in a 165/95, was it...?

It was DOS/360, on a 360/75, at the University of Waterloo.
 
-- 
 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: Mainframe programming vs the Web

[Ted MacNEIL]

>Clearly not, if you believe that JavaScript has anything to do with Java

I admit -- I don't know the difference, having never programmed in either.

-
Too busy driving to stop for gas!

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

May 29 z/VSE Live Virtual Class (LVC) z/VSE Tools: An Overview

[Pamela Christina and now it's sunny Endicott]

Posted to the IBMVM, LINUX-390, IBMMAIN listservs for those
who are interested in no-charge educational webcasts on
topics relating to z/VM, z/VSE, Linux on System z.

The next z/VSE Live Virtual Class (LVC)/Webcast is planned for
Thursday, May 29th at 11:00 AM EDT.
(There's also a Linux on System z webcast on Wed May 28)
 http://www.vm.ibm.com/education/lvc/

There is no charge to participate in this technical education session.

WEBCAST:  z/VSE Tools - An Overview
Speaker: Ingo Franzki - z/VSE Development, IBM Boeblingen Lab
Abstract:

 The z/VSE web site offers more than 20 tools ('as is'; at no additional
 charge) for download. The tools are designed make certain z/VSE
 tasks easier and more interesting. Because of the sheer number of
 tools; you may have lost track about what tools are provided and what
 they are for. There may be a tool available that you are not aware of;
 for a task you need to perform. This session will provide an overview
 of each the tools that are currently available on the VSE homepage. For
 every tool; a short description and usage scenarios will be discussed.

Date:  Thursday May 29, 2008
Time:  11:00 A.M. Eastern Daylight Time ( New York)
   10:00 AM Central Daylight Time
   London 3:00 PM, Frankfurt 4:00 PM, Moscow 6:00 PM
Duration: 75 minutes

How to attend:
Connect to the Live Virtual Class (LVC) session using the following URL:
 URL:
https://asp22.centra.com:443/GA/main/019d9c0d0119cce10cd58e45
   OR
Connect from the z/VSE Home Page at:
  http://ibm.com/vse

You can connect to the LVC session up to 10 minutes prior to the start of
the session.

You do not have to pre-register to attend the webcast, but you will
need to enter your email to join the call.
The REPLAY will be available on the web using the same "connect" URL
approximately 4 hours after the event.

If you are unable to connect to the Live Virtual Class session, you can
download the presentation from the z/VSE LVC website the day
before the webcast and listen to the audio portion of the session via
telephone using the following:

Call info:1 - 888-240-4148
Toll:   1 - 719-234-0214
Passcode:   893049

Playbacks:
The z/VSE calls from the 2007/2008 education series are available on the
z/VSE website for playback at:

http://ibm.com/vse

Other LVC playbacks are listed here:
http://www.vm.ibm.com/education/lvc/

And, let's me say it again, even if you'll ignore it...
please direct LVC questions to Julie Liesenfelt at [EMAIL PROTECTED]
:-)

Thanks..

Regards, Pam C

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

Old hardware (Was: Mainframe programming vs the Web)

[Lester, Bob]

>  -Original Message-
>  From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
>  Behalf Of Shmuel Metz (Seymour J.)
>  Sent: Thursday, May 15, 2008 2:13 PM
>  To: IBM-MAIN@BAMA.UA.EDU
>  
>  It was DOS/360, on a 360/75, at the University of Waterloo.
>  

  Hi Shmuel,

 Do you know if the 360/75 was a common machine at the time?

 I worked as an operator on a 360/75J (and a 360/30).  Seems to me
that ours ran MFT? (later MVT?).  This would've been around 1979.

 Just curious (and it's almost Friday).

Cheers!
Bob Lester 

--
This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications. 
==

--
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: Old hardware (Was: Mainframe programming vs the Web)

[Bob Rutledge]

Do you mean 1969?  By 1979 360/75s were 10+ years old.

I did see a shiny new 360/75 at Gulf Research, probably in 1967.

Bob

Lester, Bob wrote:

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Shmuel Metz (Seymour J.)
 Sent: Thursday, May 15, 2008 2:13 PM
 To: IBM-MAIN@BAMA.UA.EDU
 
 It was DOS/360, on a 360/75, at the University of Waterloo.
 


  Hi Shmuel,

 Do you know if the 360/75 was a common machine at the time?

 I worked as an operator on a 360/75J (and a 360/30).  Seems to me
that ours ran MFT? (later MVT?).  This would've been around 1979.

 Just curious (and it's almost Friday).

Cheers!
Bob Lester 


--
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: Old hardware (Was: Mainframe programming vs the Web)

[Ted MacNEIL]

>Do you mean 1969?  By 1979 360/75s were 10+ years old.

I went to the University of Waterloo (1976-1980), and I was told it was a 
360/40, at the time.
But, I do remember when it was replaced with a 303x machine.

-
Too busy driving to stop for gas!

--
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: Old hardware

[Anne & Lynn Wheeler]

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.


[EMAIL PROTECTED] (Ted MacNEIL) writes:
> I went to the University of Waterloo (1976-1980), and I was told it
> was a 360/40, at the time.  But, I do remember when it was replaced
> with a 303x machine.

quicky search engine; random web URL:
http://www.therecord.com/links/generic_020607102451.html

from above:

By 1967, the university had an IBM 360/75 the largest computer in
Canada. It filled a room the size of a gymnasium and was designated as a
backup for NASA's Apollo space missions.

... snip ... 

and more:
http://www.cs.uwaterloo.ca/40th/Chronology/1974.shtml

other drift from above:

Waterloo SCRIPT was developed as one of the early text formatting
systems. One version of SCRIPT was created at MIT and the AA/CS at UW
took over project development in 1974. The program was first used at UW
in 1975. In the 1970s, SCRIPT was the only practical way to word process
and format documents using a computer. By the late 1980s, the SCRIPT
system had been extended to incorporate various upgrades. (Cowan,
Graham, Mackie et al. 29).

... snip ...

i.e. waterloo script was clone of the CMS (cp67 and/or vm370) script
command.

various computer related pictures from waterloo, including
360/75
http://www.cs.uwaterloo.ca/40th/Chronology/1967.shtml

following has reference to 360/75 being put up for auction (and "the
console was mounted on a wall in the Red Room")
http://www.cs.uwaterloo.ca/40th/Chronology/1979.shtml

picture of decommissioning 360/75
http://www.cs.uwaterloo.ca/40th/Chronology/1980.shtml

in the early 90s, we were doing several ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

marketing tours on the far side of the pacific. on one tour at a bank
hdqtrs, a recent waterloo graduate happened to mentioned that they
studied the "wheeler scheduler" at waterloo.

misc. scheduler related posts
http://www.garlic.com/~lynn/subtopic.html#fairshare

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

SMP/E Question

[Vinson Lee]

When checking the PSP bucket for recommended maintenance, is one supposed to
skip a Hiper fix if there is an Error Hold on it?

Thanks.

Vince

--
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: SMP/E Question

[Rick Fochtman]

--


When checking the PSP bucket for recommended maintenance, is one supposed to
skip a Hiper fix if there is an Error Hold on it?

Thanks.
 



Much of the answer depends on the reason for the error hold. I tend to 
wait until an ERROR hold is resolved, then apply the fixing PTF. Error 
holds tend to be resolved rather quickly, especially when it's marked 
HIPER.


--
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: Old hardware (Was: Mainframe programming vs the Web)

[William H. Blair]

Bob Lester wrote:

> Do you know if the 360/75 was a common machine at the time?
> I worked as an operator on a 360/75J (and a 360/30). 

The System/360 Model 75 was not an UNcommon machine (as were
the Models 91, 95, 85 and 195) but it was not exactly common. 
Only VERY large shops would feel the need for one. NASA had 
five which were used to support the Apollo moon program. And
lots of universities had one or two. For businesses, a 360/40
or 360/50 were "common." Big businesses might have a 360/65
or two (instead of a 360/75, since it was almost as fast, but 
much cheaper). The Model 75 was the smallest machine that 
implemented the System/360 instruction set in hardware, so
it was correspondingly expensive.

Without memory, a bare 360/75 cost ~$1,012,860 in 1965 $$$s. 
Memory was ~$1.54 per byte, so a 360/75 J (1024 KB or 1 MB)
would have cost $2,583,860 (approximately).  But very, very
few customers actually purchased computers from IBM at that
time. The vast majority simply rented them. The third-party
leasing business had not yet arrived on the scene.  Here is
what a typical 360/75 configuration would have cost a "real"
customer (that is, not an educational institution, to whom
IBM rented equipment at a 40% discount) in August of 1968: 

$ 39,308 2075 360/75 CPU
  63,532 (4) 2365 256 KB core storage units (1024 KB)
  12,875 (5) 2860 Selector Channels
   4,460 (1) 2870 Multiplexer Channel
   1,050 2150 console attachment + 1052 console typewriter
  36,060 (4) 2314 Disk Facility (8 drives ea.)
   2,000 (100) 2316 Disk packs (for 2314s)
   5,278 (1) 2401 + (4) 2402 tape drives + (1) 2803 control unit
   4,808 2821 control unit + 2540 card reader/punch 
 + 1403 printer + 1416 print train (see note)
   6,590 2703 "Teleprocessing" (TM IBM) Control Unit
  17,300 (100) 029 keypunches 
   0 OS/360 software + compilers + any other programming
   0 (2) resident, on-site IBM System Engineers, dedicated
 to the customer, to support the SCP software, and any-
 thing else that the customer wanted them to do.
   0 (5) resident, on-site IBM Customer Engineers, whose
 job was to bang screwdriver handles on the floating
 point card cage at 4 AM when the machine red-lighted
 and machine checked.

$193,261 Total (that's PER MONTH, boys and girls, in 1968 $s)

(NOTE: It was asserted in the IBM anti-trust trial discovery
that IBM made more PROFIT on RENTAL of JUST print trains for
IBM 1403 printers than the GROSS revenues of ALL of the other
computer hardware vendors that competed with IBM - combined.)

In those days, the software was "free" (i.e., no extra charge).
People were cheap, hardware was expensive. In terms of its raw 
instruction processing power, a 360/75 had about the computing 
capacity equivalent to an Intel 80286 6 MHz processor (the IBM
PC/AT used a 6 MHz CPU when it first shipped in 1982). But the 
360/75 had 1.2 MB/sec channels, and it could support 6 of them. 
The PC/AT or indeed most Intel-based systems up until recently
would have had a hard time keeping up with the 57.6Mb/s data 
transfer rate of a 360/75 (or 360/65, which was equivalent).

Those 256KB 2365 core storage units were an amazing piece of
gear. Core density was 455 bits/cubic inch. They sucked power
and generated enormous amounts of heat. You could fry eggs on 
the heat vents (and yes, we did that more than once, just to
show off for folks who were not impressed by the size of that
beast alone, all 10 frames of it [for just the CPU+memory]).
 
> Seems to me that ours ran MFT? (later MVT?).  

That might have been the case. The first release of MVT was
OS/360 Release 13 (FCS 08/14/67) but MVT didn't get its act 
together until Release 17 in 1969. So most folks continued
to run MFT-I (Release 14 CMR) -- or MFT-II (Release 15/16) --
until about 1970 or '71 when Release 18.6 became available.  
  
> This would've been around 1979.

Only universities and IBM itself, plus folks who had actually
purchased a 360/75, would have been using one as late as 1979.

If you were renting one (the only other option available from
IBM at that time), then you long ago moved on to both faster
and cheaper (via leasing, which was now getting started) gear.

By the end of 1971, 360/155 and 360/165 boxes were displacing
the high-end S/360 boxes, and the 370/145 was displacing the
low-end S/360 boxes. I know that the University of Waterloo 
kept their (famous) Model 75 around for a long time, but by 
1974, basically, they were becoming as rare as hen's teeth. 

Unless you worked in such a place, I really doubt that you
were operating a 360/75 in 1979.

In fact, so many 360/50 machines were being returned to IBM
(off rental), being replaced by either a 370/155 or 370/165,
that IBM was able to plan to build all core memory units for
the 370/165 processor from used (although re-built with new 
electronics) 360/50 core memory. It took 4 of the usual size
(512 KB) 360/50 machines to get enough core me

Re: Old hardware

[Anne & Lynn Wheeler]

The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.


[EMAIL PROTECTED] (William H. Blair) writes:
> In fact, so many 360/50 machines were being returned to IBM
> (off rental), being replaced by either a 370/155 or 370/165,
> that IBM was able to plan to build all core memory units for
> the 370/165 processor from used (although re-built with new 
> electronics) 360/50 core memory. It took 4 of the usual size
> (512 KB) 360/50 machines to get enough core memory (2 MB) for
> the smallest 370/165. There was enough to go around. IBM, in
> fact, sent the vast majority of their off-rental 360/50 core
> memory to the landfill (for tax/depreciation reasons). They
> were happy to do so, because 360/40 and 360/50 customers were
> snapping up 370/155 boxes like hotcakes. A bunch got a hold
> of 370/165s as well, but unfortunately too many folks leased
> or bought one outright. (Both of these boxes were later to
> be deemed boat anchors when the OS/VS1 and OS/VS2 SVS + MVS
> announcement was made, since the "DAT box" upgrades to them
> were so horribly expensive.)

re:
http://www.garlic.com/~lynn/2008h.html#95 Old hardware

DAT box retrofit for 370/165 was a bear. vm370 had taken advantage and
used a bunch of new features that were part of 370 virtual memory
architecture ... especially in support of cms virtual machines ... and
it was all running on 370/145s internally.

however, 165 engineers were having a hard time implementing the full 370
virtual memory architecture. finally there was an escalation meeting
where the 165 engineers proposed dropping a whole bunch of 370 virtual
memory hardware features in order to cut six months off their
engineering development cycle. Eventually they got their way ... so that
370 virtual memory announce and ship didn't have to slip an additional
six months. However, everybody else (both hardware & software) that had
already finished implementing the full 370 virtual memory architecture
had to go back and pull everything dropped on behalf of the 165 (this
included vm370 having to put together a real Q&D cludge for things like
supporting shared segments across cms virtual machines).

--
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: Healther checker documentation

[Barbara Nitz]

Lindy,

I was going to say "obviously you haven't read the Diagnosis: Tools and 
Procedure book. It contains quite funny sentences at the start of each 
chapter". Unfortunately, when I just looked, they're all gone It is still 
in the old os/390 R10 books.

Those were sentences like for standalone dump "Like a trip to the dentist. . .  
you only go when you have to, and you know it's gonna hurt".
Or: "SVC dump is like a burglar alarm. . . .  It lets you know something's 
wrong and helps you pinpoint where it started."
"Component trace is like a Swiss Army Knife: a lot of little tools built into 
one."

Now who took that humour back out?!?

Regards, Barbara
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

--
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: Cleanup a unconnected Coupling Facility

[Barbara Nitz]

To rub salt into the wound: :-)

>Don't feel bad Art. I had to have IBM L2 point this one out at about
>04:00 when everything was down and none of the sysplex lpars would IPL

This parm has been around (at least) since OS/390 2.10. Came in very handy when 
the big DR requirements started.

As for JES2 checkpointing in the CF: We only had it in the sysprog sandplex, 
and that one got deactivated along with the CFs rather frequently, resulting in 
an automatic checkpoint reconfig dialog at restart. I finally took it out of 
the CF, as we never got around to rolling JES2 exploitation out into production.

Mark,
Out of curiosity: What's the problem with RACF datasharing? We do that, too, 
and never had a problem with fresh CFRM policies.

>Which works great if you know what hardware you will be running on. For
>those who run at a vendor's site, you can't count on this.

Something to keep in mind if we ever have to get rid of the box in the other 
location that we use for DR.

Regards, Barbara
-- 
249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro.
Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de

--
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: BLSCECT Imbedded members missing?

[Barbara Nitz]

>IMBED MEMBER(IGDIPCSP) ENVIRONMENT(ALL) /* DFP @L1A*/
imbedded in our BLSCECT, too, but I cannot find it either. Even the DFP 
Diagnosis books don't talk about it, only about smsdata and smsxdata, which 
*can* be found.

>IMBED MEMBER(ISPIPCSP) ENVIRONMENT(ALL) /* ISPF @L1A*/
>IMBED MEMBER(IKJIPCSP) ENVIRONMENT(ALL) /* TSO/E @L1A*/
Cannot find them either.

>IMBED MEMBER(DXRIPCSP) ENVIRONMENT(ALL) /* IRLM @L1A*/
>IMBED MEMBER(DSNIPCSP) ENVIRONMENT(ALL) /* DB2 @L1A*/
These two I would expect to be somewhere in IRLM/DB2 datasets, with 
instructions buried somewhere to copy them over to parmlib. But in ours I 
cannot find them, either.

So I am left with the suspicion that these members are imbedded just for IBM 
use in IBM locations that have access to *A LOT* more commands. After all, 
unless you happen to use a command defined in one of those members, IPCS 
wouldn't go searching for it and come back with 'not found'. And these commands 
are not described to the rest of the world on the assumption that IBM support 
are the only ones ever using IPCS () so why describe them anywhere 
much less ship them? 

Means that IBM would have to support those commands, and debugging isn't what's 
done these days. We just restart the application, right? And don't report a 
problem to IBM if it is not 100% reproducible, especially not in the 'new 
world' (the clickable one)IBM won't debug it, either.

With IBMs push to make a problem reproducible, the up-front-request to produce 
a lot of docs that you usually don't have in a production environment or when a 
problem occurs intermittendly, IBMs general negligence of looking at 
non-reproducible problems (some exceptions to that noted), and the 'brand-new' 
technique of putting in test code into the reproducible testcase, who needs 
debugging these days? Much less imbedded IPCS members?

Barbara Nitz


-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

--
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: Cleanup a unconnected Coupling Facility

[Skip Robinson]

I don't want to rent Mark's thunder (can't afford it), but I remember some
quirks of DR before we had the CFRM policy pre-installed at the first IPL.
RACF came up in non-data-sharing mode, but there were no consequences aside
from a little kvetching. Hey, if you can drag your kid through a
supermarket checkout line without caving in to unreasonable demands, you
can ignore software sniveling a while about trivia until SOP is reinstated.

After the CFRM policy is established and structures can be allocated, RACF
can be told to resume data sharing. Being READ-ONLY at the start of DR in
an uncertain state is not such a bad thing. Probably a bad time to be
making updates anyway.   ;-)




   
 Barbara Nitz  
 <[EMAIL PROTECTED] 
 >  To 
 Sent by: IBM  IBM-MAIN@BAMA.UA.EDU
 Mainframe  cc 
 Discussion List   
 <[EMAIL PROTECTED] Subject 
 .EDU> Re: Cleanup a unconnected Coupling  
   Facility
   
 05/15/2008 09:53  
 PM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  
 <[EMAIL PROTECTED] 
   .EDU>   
   
   




To rub salt into the wound: :-)

>Don't feel bad Art. I had to have IBM L2 point this one out at about
>04:00 when everything was down and none of the sysplex lpars would IPL

This parm has been around (at least) since OS/390 2.10. Came in very handy
when the big DR requirements started.

As for JES2 checkpointing in the CF: We only had it in the sysprog
sandplex, and that one got deactivated along with the CFs rather
frequently, resulting in an automatic checkpoint reconfig dialog at
restart. I finally took it out of the CF, as we never got around to rolling
JES2 exploitation out into production.

Mark,
Out of curiosity: What's the problem with RACF datasharing? We do that,
too, and never had a problem with fresh CFRM policies.

>Which works great if you know what hardware you will be running on. For
>those who run at a vendor's site, you can't count on this.

Something to keep in mind if we ever have to get rid of the box in the
other location that we use for DR.

Regards, Barbara

--
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: SMP/E Question

[Skip Robinson]

I confess to not dogging these issues the way I should, but the correct
answer--if you have reason to be concerned--is to open your own PMR to get
advice from IBM. 'It depends' is not necessarily a dodge. It may be well a
best guess judgment call that cannot absolve the customer from the risk of
going either way.

Here is my last best refuge in such cases. I don't think it's a cop-out,
but you may feel otherwise. If a vendor (IBM or otherwise), recommends a
certain course of action, you can

1. Take the advice
2. Ignore the advice

If major fit hits the shan, you can expect to sit down in your boss's
office and explain what happened. I would so much rather explain course (1)
than course (2). Your mileage may vary.




   
 Rick Fochtman 
 <[EMAIL PROTECTED] 
 T> To 
 Sent by: IBM  IBM-MAIN@BAMA.UA.EDU
 Mainframe  cc 
 Discussion List   
 <[EMAIL PROTECTED] Subject 
 .EDU> Re: SMP/E Question  
   
   
 05/15/2008 06:01  
 PM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  
 <[EMAIL PROTECTED] 
   .EDU>   
   
   




--

>When checking the PSP bucket for recommended maintenance, is one supposed
to
>skip a Hiper fix if there is an Error Hold on it?
>
>Thanks.
>
>

Much of the answer depends on the reason for the error hold. I tend to
wait until an ERROR hold is resolved, then apply the fixing PTF. Error
holds tend to be resolved rather quickly, especially when it's marked
HIPER.

--
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: Remote tape drive

[Ron Hawkins]

David,

If moving the data to and from a local ASCII platform is not a problem, then
why don't you look at using an iSCSI ATL. Most Windows flavours support
iSCSI software drivers so you don't need a special TOE card to drive it, and
the connection can be done through whatever backbone you currently provision
between the sites.

I'm using iSCSI based disk arrays for SAS/MXG on Windows XP and it works
just great. Something like a QANTUM PX502 means you don't need people to
mount the tapes for you (not an endorsement of Quantum - I just looked for a
brand I know).

Ron 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of David Logan
> Sent: Thursday, May 15, 2008 7:01 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: [IBM-MAIN] Remote tape drive
> 
> >> To the OP: is there some reason you could not attach a tape unit to
> the
> >> MP-3000 using native channels and use FTP to get the data there?
> 
> Yes. Getting the data there isn't the issue. The hard part is FTPing
> the
> warm body to the tape drive so that said warm body could *mount* a
> tape.
> This is a development shop, not production. There are no operators. The
> people mulling up and down the hallways at the remote location are
> generally
> unwilling to stop and mount a tape, and even if they were willing, they
> go
> home at 5 :)
> 
> >> Also to the OP: most modern tap units can drive an ESCON path to
> >> saturation. I believe the current ROT is one path per transport.
> That
> >> should give you an idea as to pipe size needed to get the best use
> of
> >> the unit.
> 
> Thanks! As I said, it's only a development shop, so a single unit would
> suffice. We just need some type of access to a tape unit.
> 
> David Logan
> Manager of Product Development, Pitney Bowes Business Insights
> http://centrus.com
> 4750 Walnut St, Suite 200
> Boulder, CO  80301
> W: (720) 564-3056
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf
> Of Hal Merritt
> Sent: Thursday, May 15, 2008 7:36 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Remote tape drive
> 
> Well, there -are- such things as B/T to ESCON converters. And there are
> some shops out there who have some that need a good home (nudge, nudge,
> wink, wink.)
> 
> To the OP: is there some reason you could not attach a tape unit to the
> MP-3000 using native channels and use FTP to get the data there?
> 
> Also to the OP: most modern tap units can drive an ESCON path to
> saturation. I believe the current ROT is one path per transport. That
> should give you an idea as to pipe size needed to get the best use of
> the unit.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Dave Cartwright
> Sent: Thursday, May 15, 2008 3:38 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Remote tape drive
> 
> On Tue, 13 May 2008 13:37:20 -0600, David Logan
> <[EMAIL PROTECTED]> wrote:
> 
> >I would like to have a tape drive at a remote office from where the
> >mainframe is physically located. Preferably a (normally) channel
> attached
> >tape drive, rather than a SCSI type of thing, although I would take
> the
> >latter if given no other choices.
> >
> >Does anyone happen to know what options I have available?
> >
> 
> My immediate thought was of a Fundamental Software Flex-ES CUB based
> solution, but that is really an ESCON to SCSI connector.  You COULD use
> this
> to write Faketape (tm) files on a remote filesystem which could use a
> FakeTape to real tape program to create images on tape.  Maybe a Flex
> reseller such as T3 Technologies could help you out.
> 
> I would like to hear of a similar solution so that I could use our
> T-Server boat
> anchor now that it has been replaced by a Z9BC because of the IBM-FSI
> breakup.  Sadly it has a B&T channel card rather than the ESCON card
> required for CUB so the costs to make use of it outweigh the benefits.
> 
> I went to a Riverbed presentation yesterday and amongst the throw-away
> benefits their agents claim are huge speedups for NFS.  If true that
> may
> be an
> alternative to remote tape - a fast remote file system.
> 
> Good luck
> Dave
> 
> 
> 
> 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-

Re: S33E abend and X33E slip

[Miklos Szigetvari]

Hi

In this case no IEF402 only the X33E slip trap
As the message says : The specified job is ended as a result of the 
abnormal end of the address space.

I thought the 33E abend is the reason

Jim Mulder wrote:

Miklos Szigetvari <[EMAIL PROTECTED]> wrote on 05/15/2008 
01:05:01 PM:


 


Rick Fochtman wrote:

   



When an address space terminates normally, RCT simply detaches the
dump task. The 33E abend is normal and expected.

When you run the application as a batch job, ending the job does not
terminate the initiator address space.
--
Wouldn't it be easier, and more efficient, to have RCT signal the dump
task so it could go through normal termination, rather than generating
an abend and going through all the related processing, including SLIP?
Maybe it's a dumb question, but it seems to me that a little
coordination via WAIT/POST could do the trick very nicely.

Considering all the control blocks already related to the address
space, one more ECB can't be that hard to define.
 


I agree with this 100%

It turned out,  the original problem was a HASP310  "TERMINATED AT END
OF MEMORY" condition, and  as I seen the X33E traps and the HASP310
explanation,
I thought the S33E abend is the responsible  for "TERMINATED AT END OF
MEMORY".
Currently I have no idea who is responsible  for HASP310
   



 HASP310 indicates that the job failed due to abnormal memory 
termination.  This should be preceeded by an IEF402I message. 


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

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


 



--
Miklos Szigetvari

Development Team
ISIS Information Systems Gmbh 
tel: (+43) 2236 27551 570
Fax: (+43) 2236 21081 

E-mail: [EMAIL PROTECTED] 

Info: [EMAIL PROTECTED] 
Hotline: +43-2236-27551-111 

Visit our Website: http://www.isis-papyrus.com 
---

This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS accepts
no responsibility for malicious or inappropriate content.
--- 


--
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: Remote tape drive

[R.S.]

Ron Hawkins wrote:

David,

If moving the data to and from a local ASCII platform is not a problem, then
why don't you look at using an iSCSI ATL. Most Windows flavours support
iSCSI software drivers so you don't need a special TOE card to drive it, and
the connection can be done through whatever backbone you currently provision
between the sites.

I'm using iSCSI based disk arrays for SAS/MXG on Windows XP and it works
just great. Something like a QANTUM PX502 means you don't need people to
mount the tapes for you (not an endorsement of Quantum - I just looked for a
brand I know).



Ron,
I believe the goal is not to have some data in some format on some tape. 
Tape is not a goal. Tape is intended to be read by receiving shop. 
Recording data on QUANTUM drive will not solve the problem - mainframe 
customer won't be able to read it.


The real goal is to distribute data (not tape) in format/media which is 
readable by customer.
IMHO it is really worth to convince customers to use CD/DVD or Internet 
download.


Of course some customer may insist on tape and ...he's right. Customer 
is always right 




--
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.2008 r. kapita zakadowy BRE Banku SA  wynosi 
118.642.672 zote i zosta w caoci wpacony.

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