Re: DUMMY and BLKSIZE=0

[Binyamin Dissen]

On Wed, 1 Jun 2005 14:31:42 -0700 Charles Mills <[EMAIL PROTECTED]> wrote:

:>I remember (I believe) when DSN=NULLFILE came along. The altering of DD
:>statements in a proc is the whole essence of DSN=NULLFILE. Before
:>NULLFILE came along, if you had a proc with the DD statement

:>//MYDD DD DSN=&SOMEPRM,...

:>then there was no "parameter" way for the user (caller) to "dummy out"
:>MYDD. Stating it differently, there was no way to code a DD statement
:>inside a proc that based on a user parameter could be either a "real"
:>DSN or DUMMY. DSN=NULLFILE made it possible.

Certainly was.

// PROC   DUMMY1='DUMMY,'


//  DD &DUMMY1.DSN=whatever ..

Remember many procs like that

:>I think that is the entire difference between DUMMY and NULLFILE: it's a
:>syntactical difference. It's like languages with more than one way to
:>express (for example) an iterative loop. DUMMY is easier to code,
:>NULLFILE is more flexible, especially in a proc.

--
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: GDG gen existence check via JCL

[Peter Hunkeler]

>I have a GDG base that has no GDS's.  I ran an IDCAMS step specifying:
>LISTCAT ENT(GSP.FAM.GSW02.KEEP.*)

This only works if the GDG is defined with SCRATCH. With NOSCRATCH,
the LISTCAT ENT() would also find rolled-off data sets. But you 
probably have SCRATCH, right.

Peter Hunkeler
Senior IT Specialist, IBM zSeries Technical Sales Support, Switzerland

--
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: SA78 abends - resolved

[Perryman, Brian]

Thanks all.

The $PXEQ and $SXEQ suggestions have sorted the problem of the residual state 
data in the WLM initiators.

The problem seems to have been caused because job(s) that abended were using 
PDSEs. This uses DIV apparently, and some control blocks got left behind in the 
initiator I guess. I'm also guessing that these control blocks have some kind 
of ACEE/SAF association, as that would explain why I could successfully run a 
job under the same userid as the one that abended, but unsuccssfully run one 
under a different userid.

Unfortunately I could not avail myself of IBM support on this problem because 
it's an OS/390 2.9 system (due for upgrade to z/OS 1.4 in July).

Thanks again all for the help and suggestions.

Brian

-
This e-mail message is for the sole use of the intended recipient(s)and may 
contain confidential and privileged information of Transaction NetworkServices. 
 
Any unauthorized review, use, disclosure or distribution isprohibited.  If you 
are not the intended recipient, please contact thesender by reply e-mail and 
destroy all copies of the original message.

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

Re: Best practice of reducing the extent of PDS defined in lnklst

[Peter Relson]

Why anyone would want to do this, I have no idea.
Extents do not cause problems. Adding to existing data sets
resulting in new extents is what causes problems. That is
why IBM recommends that you allocate your LNKLST PDSs so that
they cannot have secondary extents. That just makes it so
that you get alerted (by a failure) if your addition of a
module would have caused a new extent -- it just indicates
'no room at all'.

If you had asked how to compress, or delete, a data set
that is in the LNKLST, the process is the same, so let's
proceed on that basis.

Start from the realization that it is not OK to compress
or delete a data set that someone has allocated. For those
reasons, the system (in the XCFAS address space, but not
XCF processing itself) allocates each LNKLST data set. And
LLA does the same.

So the key, overall, is to make it so that the system does
not have the data set allocated (at which point you can do
whatever you want with that data set). And the system will
no longer have the data set allocated when that data set
is not in any active LNKLST set and is not being managed
by LLA.

(This procedure, more or less, can be found in the
documentation of the CSVDYNL macro, under the CHECKSYS1=NO
operand)

1.LNKLST DEFINE NAME(PROD01) COPYFROM(CURRENT)
2.LNKLST DELETE NAME(PROD01) DSNAME(MODULE.NAME)
3.LNKLST ACTIVATE NAME(PROD01)
4.LNKLST UPDATE JOB(*)
As always, I add the caution here that any UPDATE is
unpredictably dangerous, but if the alternative is re-IPL,
might be worth it.
After the UPDATE, the only active LNKLST set is PROD01
which does not have MODULE.NAME so LNKLST processing
does not have MODULE.NAME allocated.
Now that only PROD01 is active, the system, knowing that
any other LNKLST sets are inactive can close their DCBs
which frees the DEB. BUT, note that this is not done for
the IPL-time LNKLST set (whose DCB is pointed to by CVTLINK)
for compatibility reasons, protecting against customer or
vendor programs that might be looking at that DCB / DEB.
5.STOP LLA or (in CSVLLAxx) REMOVE(MODULE.NAME) and
MODIFY LLA,UPDATE=xx.
After this, LLA will no longer be managing MODULE.NAME so
LLA will not have that data set allocated
6.Do whatever you want to MODULE.NAME (compress, copy to
"old", allocate a new one with no secondary extents,
copy from "old" back to the "new"
7.LNKLST ACTIVATE NAME(previous)
The previous LNKLST set (the one that was "current" before
you worked with PROD01 is perfectly usable.
8.LNKLST UPDATE JOB(*)
You need this only if existing address spaces need
to use MODULE.NAME. Otherwise, it can be omitted, since
new address spaces will be assigned to the "previous"
LNKLST. Since MODULE.NAME is now in an active LNKLST set,
LNKLST processing will have allocated it.
PROD01, no longer active, has its DCB closed (and as
a result) DEB freed.
9.START LLA or (in CSVLLAxx) LIBRARIES(MODULE.NAME) and
MODIFY LLA,UPDATE=xx
Now LLA is once again managing MODULE.NAME.

Note that it would be wholly incorrect to use the
LNKLST UNALLOCATE function to get LNKLST processing to
release its allocation. That function is intended only
to allow you to manipulate uncataloged data sets of the
same name as a data set in an active LNKLST set.

>If the module is share across several systems do
>F LLA,REFRESH
I did not understand what this is for. If the data set
is shared across several systems, the same process must
be done on all those systems. If you are updating a
data set that is allocated by some system, all bets are off.

Peter Relson
z/OS Core Technology Design

--
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: SA78 abends

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Ed Gould
> 
> SNIP__
> 
> > *  through termination.*
> > 
> > * RECOMMENDATION:  *
> > 
> > Repeated ABENDA78-RC1C abends in an initiator address space.
> > A DIV map is left outstanding which causes any subsequent subpool 
> > freemains that encompass the mapped storage to fail.  This is a 
> > FINREVERSAL of APAR OW24818.
> > 
> --SNIP---
> 
> 
> FINREVERSAL  Any Clues?

Just a WAG:  Original APAR closed FIN; now a fix is intended for "this"
release.

-jc-

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

Re: SA78 abends

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Perryman, Brian
> 
> [ snip ]
>  
> Sorry for not responding sooner, I'd left the office (now 
> 10:30pm here in The 51st State).

You're in Iraq??

-jc-

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

Re: queastion on running DITTO in REXX

[Dave Butts]

Pulled up this old question from the archives.
I am facing the same problem that Paul detailed below.
Looks like nobody had an answer then, does anyone have any idea now?

Thanks,
Dave


On Tue, 17 Sep 2002 11:24:46 -0500, Paul Ip <[EMAIL PROTECTED]> wrote:

>Hi all,
>
>I am trying to use REXX to read a KSDS file (with key access) and I wanted
>to use DITTO VX functions to do so, I coded the followings:
>/* REXX */
>  ADDRESS TSO
>  VAR1.0 = 0; VAR.1 = "NOTHING"
>  "DITTOU $VX DSNIN=USER001.VSAM.KSDS KEY=0011 VARNAME=VAR1"
>  SAY "DITTO RC IS" RC
>  SAY "VAR1.0 =" VAR1.0
>  SAY "VAR.1 =" SUBSTR(VAR1.1,1,8)
>  SAY "TODAYS JULIAN IS" C2X(SUBSTR(VAR.1,26,4))
>  EXIT 0
>
>and I got the error:
>DIT0370I Function VX not supported in authorized mode
>Function terminated
>DITTO command in error:
>+++ DITTO $VX DSNIN=USER001.VSAM.KSDS KEY=0011 VARNAME=VAR1
>DITTO RC IS 16
>
>I searched the DITTO user guide   for the error message  but I've no idea
>how to set the mode to unauthorized... I also tried to use DITTOU and
DITTOA
>as the DITTO alias and was failed  also.
>Besides, I'd like to run the REXX in batch mode (using IKJEFT01),  will
>there be any extra precaution to take??
>
>Please help,
>
>Paul
>
>--
>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: SA78 abends

[Perryman, Brian]

>SNIP<

From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Chase, John

You're in Iraq??

>UNSNIP<

With Blair in charge, it feels like it - similar infrastructure, but without 
the sunshine..
This e-mail message is for the sole use of the intended recipient(s)and may 
contain confidential and privileged information of Transaction NetworkServices. 
 
Any unauthorized review, use, disclosure or distribution isprohibited.  If you 
are not the intended recipient, please contact thesender by reply e-mail and 
destroy all copies of the original message.

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

Get rid of EXPDT in catalog and format-1 DSCB?

[Jan Vanbrabant]

Hi,

We have (some) datasets with an expiration date (EXPDT), but we want to
remove those EXPDTs in order to have the datasets managed by ONLY the
MGMTCLASS 'Retention Limit'.
I know the rules by which 'Retention Limit' *CAN* co-exist with & work
together with the 'Expiration Attributes' RETPD or EXPDT. (They are
explained in SC26-7402-02 zOS V1R5.0 DFSMSdfp Storage Administration
Reference on page 68-69.)
So we might play with 'Retention Limit', but we can't & don't want to do
so. Changing the MGMTCLASS 'Retention Limit' might/would have to much
impact on the other (non-EXPDT) datasets. Changing such a MGTCLASS
attribute is absolutely forbidden. By death penalty.:(
*
With IDCAMS ALTER TO(date)|FOR(days) you can 'alter' the retention period
(of course!) & hence update the expiration date in the catalog, and, for
SMS-managed data sets, change the expiration date in the format-1 DSCB;
but you can *NOT* 'delete' it as far as I know.
At least not via an officially supported way.
*
Do you know (other) means to get rid of the expiration date in catalogs or
format-1 DSCBs?
Jan

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

Re: Get rid of EXPDT in catalog and format-1 DSCB?

[Dave Cartwright]

On Thu, 2 Jun 2005 07:37:21 -0500, Jan Vanbrabant
<[EMAIL PROTECTED]> wrote:

>*
>Do you know (other) means to get rid of the expiration date in catalogs or
>format-1 DSCBs?


Have a look at CDSCB on the CBT tape. There are many versions, there should
be a Y2K compliant version in file 172. This will update the DSCB, as its
name implies. I don't think the catalog itself holds expiration dates.

DC

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

Re: Get rid of EXPDT in catalog and format-1 DSCB?

[Robert L. Griffin]

 How about IDCAMS   ALTER NULLIFY(RETENTION)   

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Jan Vanbrabant
Sent: Thursday, June 02, 2005 8:37 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Get rid of EXPDT in catalog and format-1 DSCB?


Hi,

We have (some) datasets with an expiration date (EXPDT), but we want to
remove those EXPDTs in order to have the datasets managed by ONLY the
MGMTCLASS 'Retention Limit'.
I know the rules by which 'Retention Limit' *CAN* co-exist with & work
together with the 'Expiration Attributes' RETPD or EXPDT. (They are
explained in SC26-7402-02 zOS V1R5.0 DFSMSdfp Storage Administration
Reference on page 68-69.)
So we might play with 'Retention Limit', but we can't & don't want to do
so. Changing the MGMTCLASS 'Retention Limit' might/would have to much
impact on the other (non-EXPDT) datasets. Changing such a MGTCLASS
attribute is absolutely forbidden. By death penalty.:(
*
With IDCAMS ALTER TO(date)|FOR(days) you can 'alter' the retention period
(of course!) & hence update the expiration date in the catalog, and, for
SMS-managed data sets, change the expiration date in the format-1 DSCB;
but you can *NOT* 'delete' it as far as I know.
At least not via an officially supported way.
*
Do you know (other) means to get rid of the expiration date in catalogs or
format-1 DSCBs?
Jan

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

TSO replacement? [WAS: RE: Userids]

[Farley, Peter x23353]

Ed,  I've been curious about this topic for a while, and have not seen a
reasonable answer to it yet:

If TSO is "a dead horse", as you say, then what is the currently available
replacement for TSO (i.e., normal, everyday developer access and usage)
supposed to be?  Has IBM ever told anyone their intentions on this subject?

Or is it like the theater-owner's line from "Shakespeare In Love": "Is a
mystery"?

Peter

-Original Message-
From: Ed Gould [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 01, 2005 9:32 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Userids

Gil,

You are beating a dead horse TSO is comatose or not breating take your pick.

Ed

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

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

Re: queastion on running DITTO in REXX

[Mark Zelden]

On Thu, 2 Jun 2005 07:12:01 -0500, Dave Butts <[EMAIL PROTECTED]>
wrote:

>Pulled up this old question from the archives.
>I am facing the same problem that Paul detailed below.
>Looks like nobody had an answer then, does anyone have any idea now?
>
>Thanks,
>Dave
>
>
>On Tue, 17 Sep 2002 11:24:46 -0500, Paul Ip <[EMAIL PROTECTED]> wrote:
>
>>Hi all,
>>
>>I am trying to use REXX to read a KSDS file (with key access) and I wanted
>>to use DITTO VX functions to do so, I coded the followings:
>>/* REXX */
>>  ADDRESS TSO
>>  VAR1.0 = 0; VAR.1 = "NOTHING"
>>  "DITTOU $VX DSNIN=USER001.VSAM.KSDS KEY=0011 VARNAME=VAR1"
>>  SAY "DITTO RC IS" RC
>>  SAY "VAR1.0 =" VAR1.0
>>  SAY "VAR.1 =" SUBSTR(VAR1.1,1,8)
>>  SAY "TODAYS JULIAN IS" C2X(SUBSTR(VAR.1,26,4))
>>  EXIT 0
>>
>>and I got the error:
>>DIT0370I Function VX not supported in authorized mode
>>Function terminated
>>DITTO command in error:
>>+++ DITTO $VX DSNIN=USER001.VSAM.KSDS KEY=0011 VARNAME=VAR1
>>DITTO RC IS 16
>>
>>I searched the DITTO user guide   for the error message  but I've no idea
>>how to set the mode to unauthorized... I also tried to use DITTOU and
>DITTOA
>>as the DITTO alias and was failed  also.
>>Besides, I'd like to run the REXX in batch mode (using IKJEFT01),  will
>>there be any extra precaution to take??
>>
>>Please help,
>>

Is DITTOU defined in IKJTSOxx as an authorized command?  I just tried
the code you quoted on one of our systems and it worked. On the other hand,
if I used DITTOA or DITTO I get the same failure as those are both
defined to AUTHCMD in IKJTSOxx on the system that I tested this on.

So if DITTOU is not requred to be in IKJTSOxx (which I have no idea
about since I've never installed / supported this product - RTFM),
then remove it and update dynamically via PARMLIB command or SET
command if you are at a high enough level of z/OS.

Regards,

Mark
--
Mark Zelden
Sr. Software and Systems Architect
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://Search390.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

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

Re: Reliability of tape drive

[Rob Wunderlich]

On Wed, 1 Jun 2005 14:07:05 +0800, victorzhang_mvscn
<[EMAIL PROTECTED]> wrote:

>Hello list,
>  When we thinking about the reliability of a tape drive technology,
>  vendors may say how many MTBF is, how customer experience this?
>  For tape drivers used today(3590 any model,3592 J1A,9840,etc), how long
will you ever use it to work?
>  For example,12 hours to backup/restore without any errors occurr.
>  I'd like to hear your response.
>  Is this figure enough to let us think if a tape drive is reliable
>  and an enterprise class product?

I don't have failure figures at my fingertips, but yes, I would consider
mainframe tape drives reliable enough to be considered an "enterprise class
product". In addition, the swap feature generally allows for graceful
recovery from a rare failure.

-Rob

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

Re: How to know which codepage mainframe uses or supports?

[Ed Finnell]

 
In a message dated 6/2/2005 1:23:15 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Code  page support is product specific, some have it, some don't. You
would have  to search the product specific documentation, I  guess.



>>
For products, it's usually a fee based FMID. Then comes emulators,
keyboards, fonts(more FMIDs), printers(memory size, disc size, band, meta  
language support;i.e. PS,PCL,AFP,SAP), type tranformers(more FMIDs), DBCS, and  
ODBC if you're so inclined. Normally this
level of detail is hashed out prior to placing an order. This is where the  
knowledgeable ISVs can save tons by helping the
customer get it right the first time.

--
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: FTP.DATA

[Rob Wunderlich]

>> -Original Message-
>> From: IBM Mainframe Discussion List On Behalf Of Howard Rifkind
>>
>> Hello all,
>>
>> I'm trying to find the file FTP.DATA.
>>
>> More then likely it should have a name like HLQ.FTP.DATA but
>> I can't find it in my system the way it is presented here.

"FTP.DATA" is a generic name. The actual dataset names and search order are
documented in "Communications Server: IP User's Guide and Commands" for the
FTP client, and in "Communications Server: IP Configuration Reference" for
the FTP server.

-Rob

--
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: Reliability of tape drive

[Ed Finnell]

 
In a message dated 6/2/2005 9:10:30 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

I don't  have failure figures at my fingertips, but yes, I would consider
mainframe  tape drives reliable enough to be considered an "enterprise class
product".  In addition, the swap feature generally allows for graceful
recovery from a  rare failure.



>>
If it's mechanical it will break! We lose about a tape head a year in the  
3590/A60. Worst problem ever was hard drive crash in the
tape specialist support PC. It is mirrored, but took about 32 hours to get  
another one and another full day to run all the restore
utilities to get everything back in sync.
 
There's also a bad problem in the power sequencing box in that
it leaves itself in limbo until it's completely powered down and the  
internal relays are flipped. Found that out before hooking to
UPS and the crack UPS team left it hover mode.
 
 

--
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: SDB, BLKSIZE=0, and IEBGENER SYSPRINT

[Bruce Black]

Yet, SDB appears to have filled in BLKSIZE for a data set that was never
opened.

SDB determines the blocksize twice.  At allocation time, even if the 
dataset was never opened, it calculates the blocksize from the supplied 
RECFM and LRECL.  Then it sets a flag saying that it did so.


At OPEN time, if that flag is set, and if the RECFM or LRECL in the DCB 
is different from the values provided at allocation time, it 
recalculates the blocksize. 


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

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

Re: Get rid of EXPDT in catalog and format-1 DSCB?

[Jan Vanbrabant]

Robert,

BINGO with IDCAMS ALTER dsn NULLIFY(RETENTION)!
Thanks A LOT !!!
There are/were a couple of apars in that area:
OA07317 MULTI-VOLUME SMS DS WITH AN EXPIRATION DATE IS NOT COMPLETE
= Release 1H0   : UA10323 available 04/05/07 (F405 )
OA07695 HSM RECALL CREATES ORPHAN CATALOG FOR DS HAVING CANDIDATE VOLUME
AFTER APPLY OF OA07317.
OA08303 AE OA07695 FIX COMPLETION
= Release 1H0   : UA11742 available 04/08/26 (F408 )
OA08306 MULTI-VOLUME SMS DS WITH AN EXPIRATION DATE IS NOT COMPLETE
= Release 1H0   : UA12678 available 04/07/28 (F407 )

Once again, thank you.
Also to Dave for the other suggestion.
Jan

--
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: queastion on running DITTO in REXX

[Dave Butts]

On Thu, 2 Jun 2005 09:06:44 -0500, Mark Zelden <[EMAIL PROTECTED]>
wrote:
>
>Is DITTOU defined in IKJTSOxx as an authorized command?  I just tried
>the code you quoted on one of our systems and it worked. On the other hand,
>if I used DITTOA or DITTO I get the same failure as those are both
>defined to AUTHCMD in IKJTSOxx on the system that I tested this on.
>
>So if DITTOU is not requred to be in IKJTSOxx (which I have no idea
>about since I've never installed / supported this product - RTFM),
>then remove it and update dynamically via PARMLIB command or SET
>command if you are at a high enough level of z/OS.
>
>Regards,
>
>Mark


Yes.  I do have DITTOU in IKJTSOxx.
I'll give that a try.
Thanks for the response.

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

Re: TSO replacement? [WAS: RE: Userids]

[Bruce Black]

If TSO is "a dead horse", as you say, then what is the currently available
replacement for TSO (i.e., normal, everyday developer access and usage)
supposed to be?  Has IBM ever told anyone their intentions on this subject?

I think Ed has overstated it.  TSO is stabilized but supported, not 
dead.  And ISPF is still being enhanced (although few enhancements in 
recent years). 


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

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

Re: TSO replacement? [WAS: RE: Userids]

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Black
> Sent: Thursday, June 02, 2005 9:44 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: TSO replacement? [WAS: RE: Userids]
> 
> 
> >
> >
> >If TSO is "a dead horse", as you say, then what is the 
> currently available
> >replacement for TSO (i.e., normal, everyday developer access 
> and usage)
> >supposed to be?  Has IBM ever told anyone their intentions 
> on this subject?
> >
> I think Ed has overstated it.  TSO is stabilized but supported, not 
> dead.  And ISPF is still being enhanced (although few enhancements in 
> recent years). 
> 
> -- 
> Bruce A. Black

Perhaps IBM is really wanting to push WSED (WebSphere Studio Enterprise
Developer)? I don't know much about it, but it appears to be some sort
of Microsoft Windows based GUI development that interfaces with some
WebSphere thingie on z/OS. This may explain the demise of the ISPF GUI.


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

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

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

Re: TSO replacement? [WAS: RE: Userids]

[Ed Finnell]

 
In a message dated 6/2/2005 9:56:08 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Perhaps  IBM is really wanting to push WSED (WebSphere Studio Enterprise
Developer)?  I don't know much about it, but it appears to be some  sort



>>
Anything to sell hardware?

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

Sun to acquire StorageTek

[Eric Chevalier]

I'm a bit surprised that this hasn't been mentioned on the list yet, but 
it looks like Sun is acquiring StorageTek:


http://www.sun.com/smi/Press/sunflash/2005-06/sunflash.20050602.1.html
http://storagetek.shareholder.com/releaseDetail.cfm?ReleaseID=165007

Eric

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

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

Re: TSO replacement? [WAS: RE: Userids]

[Farley, Peter x23353]

But that doesn't cover the millions of lines of batch and CICS and DB2 and
IMS code in all the languages supported that is still being maintained and
newly developed.

I'm sorry, but Java and C# and .Net aren't going to replace those anytime
soon, IMHO.  Add "friendly" (YMMV) interfaces to them, yes; replace them,
not soon, if ever.

Peter

-Original Message-
From: McKown, John [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 10:59 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: TSO replacement? [WAS: RE: Userids]

Perhaps IBM is really wanting to push WSED (WebSphere Studio Enterprise
Developer)? I don't know much about it, but it appears to be some sort
of Microsoft Windows based GUI development that interfaces with some
WebSphere thingie on z/OS. This may explain the demise of the ISPF GUI.

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

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

Re: TSO replacement? [WAS: RE: Userids]

[Dave Salt]

From: "McKown, John" <[EMAIL PROTECTED]>
Perhaps IBM is really wanting to push WSED (WebSphere Studio Enterprise
Developer)? I don't know much about it, but it appears to be some sort
of Microsoft Windows based GUI development that interfaces with some
WebSphere thingie on z/OS. This may explain the demise of the ISPF GUI.



I don't know much about WebSphere Developer either, but from what I read at 
the following web site:


http://www-306.ibm.com/software/awdtools/devzseries/

It sounds as though the product is geared towards helping programmers 
(including traditional mainframe/COBOL programmers) develop web based or web 
integrated applications. In other words, it doesn't sound as though it's 
some sort of 'general' replacement for everyday mainframe development.


Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm

--
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: Sun to acquire StorageTek

[Jon Brock]

Yes, they are.  Perhaps I'm being too pessimistic, but I expect a bumpy ride 
once McNealy gets ahold of things.

Jon




I'm a bit surprised that this hasn't been mentioned on the list yet, but 
it looks like Sun is acquiring StorageTek:

http://www.sun.com/smi/Press/sunflash/2005-06/sunflash.20050602.1.html
http://storagetek.shareholder.com/releaseDetail.cfm?ReleaseID=165007


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

3290 datastream question

[Tim Alpaerts]

Hello All,
I'm trying to understand the special magic inside the 3290 terminal
that enables it to do VSPLIT in ISPF.
My problem is I don't have access to real 3290 hardware to trace the datastream.

Would someone of you be prepared to email me a sample trace of the datastream ?

I'm intrested in particular in the datastream during ISPF initialization and 
what happens when the VSPLIT command is entered. 
(I'm realy not after your password)

If someone is prepared to help, please email me: Tim . Alpaerts at telenet . be

many thanks, Tim.

--
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: Sun to acquire StorageTek

[Ed Finnell]

 
In a message dated 6/2/2005 10:16:18 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

I'm a  bit surprised that this hasn't been mentioned on the list yet, but 
it  looks like Sun is acquiring StorageTek:




>>
Ashes to ashes, dust to dust.

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

[Mark Yuhas]

John Eels queried why we are still using UADS?  I tried to convert to
using our security software, but, was outvoted.

You pick your battles, you win your wars.  Or, in my case, you get to
survive.

--
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: TSO replacement? [WAS: RE: Userids]

[Steve Comstock]

Bruce Black wrote:



If TSO is "a dead horse", as you say, then what is the currently 
available

replacement for TSO (i.e., normal, everyday developer access and usage)
supposed to be?  Has IBM ever told anyone their intentions on this 
subject?


I think Ed has overstated it.  TSO is stabilized but supported, not 
dead.  And ISPF is still being enhanced (although few enhancements in 
recent years).


Well, maybe you haven't been paying attention.

In z/OS 1.6, the following enhancements were introduced:

* ability to add REXX code to panel definitions
* extensive additions to file tailoring
* extended configuration options
* new QTABOPEN service
* new edit primary command COLS
* new edit primary command HIDE
* added {X|NX} option to CUT command

and more.

And there was a lot of new stuff in 1.5

This is one reason I can't sell ISPF update courses:
the perception is that everyone knows it all already.

Kind regards,

-Steve Comstock

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

Re: TSO replacement? [WAS: RE: Userids]

[Ed Gould]

on 6/2/05 9:04 AM, Farley, Peter x23353 at [EMAIL PROTECTED] wrote:

> Ed,  I've been curious about this topic for a while, and have not seen a
> reasonable answer to it yet:
> 
> If TSO is "a dead horse", as you say, then what is the currently available
> replacement for TSO (i.e., normal, everyday developer access and usage)
> supposed to be?  Has IBM ever told anyone their intentions on this subject?
> 
> Or is it like the theater-owner's line from "Shakespeare In Love": "Is a
> mystery"?
> 
> Peter
>

Peter,

When IBM semi announced that TSO was dead the first question was what was
the replacement? We did not get an answer or even a hint. One of my IBM
sources said they were working on a *COMPLETE* replacement but did not
elaborate.

This was quite a while ago (10 years about). I have lost all my contacts at
IBM so I am as much dark as the rest of you.

I was hoping for some indication as to the status, about 5 years ago. But
nothing was announced. that I heard about.

Since there is no pressure ( SHARE is IBM's patcy (AFAIC) there is no longer
any leverage to get IBM off the dime .

Maybe if you can get the SHARE board to make it a point to ASK IBM what the
status of TSO they might give them the answer.

Ed


 

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

Re: 3290 datastream question

[Steve Bireley]

Tim,

Download an eval copy of BlueZone from the Seagull website.  It supports
split and vsplit.  You can use the built in trace facility to record the
data stream and view it in notepad.

Steve Bireley
Seagull Software
www.seagullsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Tim Alpaerts
Sent: Thursday, June 02, 2005 11:11 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: 3290 datastream question

Hello All,
I'm trying to understand the special magic inside the 3290 terminal
that enables it to do VSPLIT in ISPF.
My problem is I don't have access to real 3290 hardware to trace the
datastream.

Would someone of you be prepared to email me a sample trace of the
datastream ?

I'm intrested in particular in the datastream during ISPF initialization
and 
what happens when the VSPLIT command is entered. 
(I'm realy not after your password)

If someone is prepared to help, please email me: Tim . Alpaerts at
telenet . be

many thanks, Tim.

--
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: 3290 datastream question

[Bob Wright]

[EMAIL PROTECTED] wrote:


I'm trying to understand the special magic inside the 3290 terminal
that enables it to do VSPLIT in ISPF.
My problem is I don't have access to real 3290 hardware to trace the datastream.

Would someone of you be prepared to email me a sample trace of the datastream ?

I'm intrested in particular in the datastream during ISPF initialization and 
what happens when the VSPLIT command is entered. 
(I'm realy not after your password)




There is a book online, 3270 Information Display System Data Stream 
Programmer's Reference, Document Number GA23-0059-07, that talks about 
"partitions".  It also discusses a read partition query order that 
permits an application to ask a 3270 what features, including 
partitioning, that it supports.  The 3290 is the only hardware that I've 
encountered that ever supported software partitioning as described in 
the book.  It also supported hardware partitioning, allowing it to 
imitate four distinct 3278s, albeit with orange and black appearing 
rather than the usual pair of colors.


I live within the IBM firewall, and I got to the book by using the 
following URL:


http://ehone.ibm.com/public/applications/publications/cgibin/pbi.cgi?CTY=US.

I was able to download a copy in a few seconds via a broadband 
connection.  The book will likely tell you more than you really want to 
know about the subject.


--
Bob Wright - MVS Service Aids

--
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: Sun to acquire StorageTek

[salah Balboul]

I'm glad Sun did that. My stock is much higher now.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Jon Brock
Sent: Thursday, June 02, 2005 11:21 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Sun to acquire StorageTek

Yes, they are.  Perhaps I'm being too pessimistic, but I expect a bumpy ride
once McNealy gets ahold of things.

Jon




I'm a bit surprised that this hasn't been mentioned on the list yet, but 
it looks like Sun is acquiring StorageTek:

http://www.sun.com/smi/Press/sunflash/2005-06/sunflash.20050602.1.html
http://storagetek.shareholder.com/releaseDetail.cfm?ReleaseID=165007


--
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: Shopping the zMall

[Edward E. Jaffe]

Skip Robinson wrote:


Here's what I can do in Shop that was never doable in SUF.

1. Manage multiple releases and products in multiple CSIs in a single
procedure.
2. Keep these multiple releases and products in 'maintenance synch' with
each other automatically
3. Limit superfluous inventory uploads by choosing if and when I want to
refresh them
4. Limit superfluous ingestion of HOLDDATA across multiple orders when I'm
sure that nothing has changed, e.g multiple order in a single day.
 



Sounds like ShopzSeries has some nice features there.


Here's what I do for regular maintenance. I do it very often.

1. Run a *single* batch job to produce a composite inventory of z/OS 1.4
and z/OS 1.6 (installed in two separate and unrelated CSIs), and a suite of
Tivoli products installed in the 'Candle CSI'. I could easily change the
set of CSIs by simply adding or removing them from the inventory job. The
order I will create is based entirely on the inventory. The batch job
outputs the composite inventory to a single HFS file.

2. Map the inventory HFS file via SMB to the Z: drive on my workstation. I
do this once per 'boot session' on my PC.

3. Log on to ShopzSeries.

4. Request a Maintenance order for 'all products installed in one or more
zones'. There are other options, but this one uses the inventory.

5. Upload a new inventory if I've created one, or use the previous one if
nothing (much) has changed. The latter is a good option for multiple
successive orders. The inventory file is mapped to my PC, so I just select
it from the pop-up.

6. Choose the scope of the order: HIPER only, RSU (includes HIPER), or
everything available. Brian Peterson pulls everything. The old me pulled
only HIPER. The new me selects RSU. Whatever floats the boat.

7. Submit the order. Do something else for a while. Watch for email
notification or just check the order status now and then until it's ready
for download.

8. Click on the order and drill down to the sample job stream. CTRL C copy
*only* the section called SERVINFO.

9. Paste the SERVINFO lines into a canned job stream that otherwise never
changes. If I want to skip processing of HOLDDATA, I can delete a few
keywords before submitting.

10. Run the job, which pulls the entire order via FTP and passes it step by
step directly to each CSI named in the job stream. SMPE output will show
which CSIs RECEIVEd which PTFs.
 



Yikes! You've done well to illustrate exactly my complaints re: using 
ShopzSeries for maintenance. Too many manual steps!


What got me thinking about this was today's update to APAR OA11031 
indicating PTF availability. (Finally!)


I fired up my browser (Mozilla Firefox 1.0.4), clicked on my SUF 
bookmark, and logged on to SUF. I selected the right target zone from 
the target zone tree and clicked "Create Order". In the resulting window 
I selected "Corrective Service", pasted in "OA11031", selected "All 
values specified denote APARs", and clicked the "Submit Order to IBM" 
button.


A few minutes later -- and without *any* additional intervention by me 
-- the proper PTF (UA18318 in this case) was ready to be applied. I even 
got notified in my TSO session after the SMPRCV job ran!


SUF had automatically queried the target zone and associated global 
zone, figured out which PTF(s) I needed (based on the APAR I supplied 
and my current maintenance level),  uploaded the bit map, ordered the 
necessary PTF(s), periodically polled IBM waiting for the maintenance 
package to be created, downloaded the maintenance package, unzipped the 
maintenance package, and RECEIVEd the PTF(s) and HOLDDATA into my global 
zone.


I use an equally simple procedure to obtain preventive service (e.g., 
quarterly or monthly RSUs).


Put simply: I want ShopzSeries to do more things "automagically", like 
SUF! All that copy/paste and submitting of jobs seems like taking a 
giant leap backwards!


--
.-.
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | 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: TSO replacement? [WAS: RE: Userids]

[David Andrews]

On Thu, 2005-06-02 at 10:43 -0500, Ed Gould wrote:
> When IBM semi announced that TSO was dead the first question was what was
> the replacement? We did not get an answer or even a hint. One of my IBM
> sources said they were working on a *COMPLETE* replacement but did not
> elaborate.

I always assumed that OMVS was the intended replacement.  Didn't work
out that way -- maybe OMVS was itself stunted by Linux?

-- 
David Andrews
A. Duda and Sons, Inc.
[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: TSO replacement? [WAS: RE: Userids]

[Edward E. Jaffe]

McKown, John wrote:


Perhaps IBM is really wanting to push WSED (WebSphere Studio Enterprise
Developer)? I don't know much about it, but it appears to be some sort
of Microsoft Windows based GUI development that interfaces with some
WebSphere thingie on z/OS. This may explain the demise of the ISPF GUI.
 



WSED cannot be considered a general TSO/ISPF replacement.

More to the point, you're giving IBM waaay too much credit here. When 
TSO/E development was unstaffed, nobody had even heard of  Java or 
Websphere. Heck, they hadn't even heard of the Web!


If anything, maybe someone thought that the shell environment for z/OS 
UNIX (back then called MVS Open Edition) would be a viable replacement. 
In some ways it is.


--
.-.
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | 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: Sun to acquire StorageTek

[Howard Brazee]

On  2-Jun-2005, [EMAIL PROTECTED] (Eric Chevalier) wrote:

> I'm a bit surprised that this hasn't been mentioned on the list yet, but
> it looks like Sun is acquiring StorageTek:

Interesting.   Sun has a big campus between Boulder and Denver, about a mile
away from Storage Tech (which has streets named Disk Drive and Tape Drive).

--
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: TSO replacement? [WAS: RE: Userids]

[Paul Gilmartin]

In a recent note unmask]> said:

> Date: Thu, 2 Jun 2005 11:17:00 -0400
>
> But that doesn't cover the millions of lines of batch and CICS and DB2 and
> IMS code in all the languages supported that is still being maintained and
> newly developed.
>
Don't all those things exist independent of TSO?  In fact, I believe this
thread's parent was started by someone using 8-character IDS to access
CICS, which couldn't be used for TSO.

-- gil
--
StorageTek
INFORMATION made POWERFUL

--
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: TSO replacement? [WAS: RE: Userids]

[Farley, Peter x23353]

Agreed about WSED.  As for the shell environment, not even a remote
possiblility until the "kernel" can run without sucking up so much CPU that
it chokes a T-rex (i.e., get rid of all the busy-wait loops), and not until
X11 is ported and supported fully so that KDE and/or gnome GUI environments
can be used, along with all of the GNU applications and utilities.

IMHO, of course.

Peter

-Original Message-
From: Edward E. Jaffe [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 12:15 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: TSO replacement? [WAS: RE: Userids]

WSED cannot be considered a general TSO/ISPF replacement.

More to the point, you're giving IBM waaay too much credit here. When 
TSO/E development was unstaffed, nobody had even heard of  Java or 
Websphere. Heck, they hadn't even heard of the Web!

If anything, maybe someone thought that the shell environment for z/OS 
UNIX (back then called MVS Open Edition) would be a viable replacement. 
In some ways it is.

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

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

Re: TSO replacement? [WAS: RE: Userids]

[Farley, Peter x23353]

Yes, but no programmer in their right mind would devlop under z/OS
"independent" of TSO.  TSO is your everyday, all-the-time development
environment for these applications, at least it is in all the shops I have
known.

I suppose it is possible to do so, given that there are a few decent peecee
editors and given ftp of JCL to JES and listings back from JES, but that
doesn't cover source-level debugging needs or post-mortem interactive dump
review to solve problems.

Peter

-Original Message-
From: Paul Gilmartin [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 12:39 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: TSO replacement? [WAS: RE: Userids]

In a recent note unmask]> said:

> Date: Thu, 2 Jun 2005 11:17:00 -0400
>
> But that doesn't cover the millions of lines of batch and CICS and DB2 and
> IMS code in all the languages supported that is still being maintained and
> newly developed.
>
Don't all those things exist independent of TSO?  In fact, I believe this
thread's parent was started by someone using 8-character IDS to access
CICS, which couldn't be used for TSO.

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

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

Re: TSO replacement? [WAS: RE: Userids]

[Bob Shannon]

> Since there is no pressure ( SHARE is IBM's patcy (AFAIC) there is no
>longer any leverage to get IBM off the dime .

>Maybe if you can get the SHARE board to make it a point to ASK IBM what
the >status of TSO they might give them the answer.

Ed, will you ever stop beating a dead horse? Don't respond, the answer
is no. TSO is functionally stabilized because 1) IBM doesn't make any
money from it and 2) because it already provides all the functionality
that anyone is willing to pay for. IBM is a business. No revenue, no
development. Get used to it. 

TSO is not dead; it's stabilized. I use it daily; you use it daily; just
about everyone on IBM-MAIN uses it daily. It doesn't need replacement
because it still works. Would you like enhancements? How much would you
pay for them. Again, don't respond. The answer is zero. You get what you
pay for. 

SHARE is no one's patcy (sic). That's a horse%&@* comment and you know
it.

Bob Shannon

--
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: FTP.DATA

[Matt Simpson]

On Thu, 2 Jun 2005 09:18:05 -0500, Rob Wunderlich <[EMAIL PROTECTED]> wrote:

>"FTP.DATA" is a generic name. The actual dataset names and search order are
>documented in "Communications Server: IP User's Guide and Commands" for the
>FTP client, and in "Communications Server: IP Configuration Reference" for
>the FTP server.

Does anybody else wish the FTP client would merge all files it finds in the 
search order, instead of stopping at the first one?  The way it works now, as 
far as I can tell, if I want to create a userid.FTP.DATA to override a couple 
of options in SYS1.TCPPARMS(FTPDATA),  I have to copy the system-wide file into 
the user file and make the changes, rather than just changing what I want 
changed and letting it pick up the rest from the system file.

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

[Low, David]

> John Eels queried why we are still using UADS?  I tried to convert to
> using our security software, but, was outvoted.

My boss asked me about this the other day.  We have Top Secret yet we have been 
maintaining UADS for all our userids.  Is this unnecessary?  I guess I should 
go RTF TSS manuals.

Dave Low

--
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: TSO replacement? [WAS: RE: Userids]

[Paul Gilmartin]

In a recent note unmask]> said:

> Date: Thu, 2 Jun 2005 09:12:36 -0700
>
> If anything, maybe someone thought that the shell environment for z/OS
> UNIX (back then called MVS Open Edition) would be a viable replacement.
> In some ways it is.
>
A fantasy, based on this.

With z/OS 1.5, Rexx now has the "address TSO" environment, which starts
a captive TSO TMP address space (with no display).  There's no reason
one can't have such a captive TMP address space for each linemode shell
session.

Now, suppose support were added to run 3270 OMVS directly from a tn3270
connection, with no TSO involvement.  Then a given user could run
several 3270 OMVS sessions, since the TSO one-session-per-user limit
would not apply.

Then suppose some combination of "address TSO" and "address SYSCALL pt3270"
(the latter now used to support OEDIT and OBROWSE) allowed the user to
bring up a captive TMP address space (as above), but _with_ the 3270
display active.

The best of both worlds?

I'm sure Walt Farrell will say it can't be done; Jim Mulder would be
more sympathetic.

-- gil
--
StorageTek
INFORMATION made POWERFUL

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

[Edward E. Jaffe]

Low, David wrote:


My boss asked me about this the other day.  We have Top Secret yet we have been 
maintaining UADS for all our userids.  Is this unnecessary?  I guess I should 
go RTF TSS manuals.
 



Totally unnecessary. UADS is needed only for the "emergency" User ID -- 
used when no security product is available.


--
-
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | 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: Userids

[Craig Kittendorf]

No, it is not necessary to maintain UADS for users defined in Top Secret.
There is even a provided utility to convert your UADS to TSS.  Once a TSO
segment is added to a TSS acid, if the user is defined in UADS, it will be
ignored for that acid.

There are some functions which can not be permitted using UADS.

Craig

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Low, David
Sent: Thursday, June 02, 2005 12:50 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Userids

> John Eels queried why we are still using UADS?  I tried to convert to
> using our security software, but, was outvoted.

My boss asked me about this the other day.  We have Top Secret yet we have
been maintaining UADS for all our userids.  Is this unnecessary?  I guess I
should go RTF TSS manuals.

Dave Low

--
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: TSO replacement? [WAS: RE: Userids]

[Paul Gilmartin]

On Thu, 2 Jun 2005 12:39:43 -0400, Farley, Peter x23353 <[EMAIL PROTECTED]> 
wrote:

> it chokes a T-rex (i.e., get rid of all the busy-wait loops), and not until
> X11 is ported and supported fully so that KDE and/or gnome GUI environments
> can be used, along with all of the GNU applications and utilities.
>
Make this specifically run time libraries for X11 and Curses in ASCII mode.

-- gil
--
StorageTek
INFORMATION made POWERFUL

--
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: TSO replacement? [WAS: RE: Userids]

[Howard Brazee]

On  2-Jun-2005, [EMAIL PROTECTED] (Ed Gould) wrote:

> When IBM semi announced that TSO was dead the first question was what was
> the replacement? We did not get an answer or even a hint. One of my IBM
> sources said they were working on a *COMPLETE* replacement but did not
> elaborate.

The trouble is, IBM has to be very careful in what it implies.What happens
if its bigwigs decide internally that, say MVS should no longer be developed
because new customers should go to other platforms that IBM is working on?If
it they decided that, they certainly would not want to let us know until they
were ready for our response.

Well, replacing TSO might have similar consequences on a smaller scale.  
Companies that are thinking about their next applications upgrade are biased to
use platforms that they are familiar with that cost less to train users on.   
If they hear that TSO is going away, they see "We'll have to train people
anyway, it doesn't matter what platform we go to".So IBM is better off if we
don't hear that TSO is going away - at least until their salesmen have something
better to show us.

--
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: TSO replacement? [WAS: RE: Userids]

[Edward E. Jaffe]

Howard Brazee wrote:


...So IBM is better off if we
don't hear that TSO is going away - at least until their salesmen have something
better to show us.
 



In this case, it's been 10-15 years in the waiting!

--
-
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | 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: FTP.DATA

[Craig Kittendorf]

I'm not sure what you're after but we use a proc to exec FTP.  The proc
contains a SYSFTPD dd card.  We can concatenate other datasets to that to
provide overrides.  I have even done the following:

// EXEC FTP
//SYSFTPDDD
//   DD *
 config statements
//SYSIN  DD *

Craig

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Matt Simpson
Sent: Thursday, June 02, 2005 12:50 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: FTP.DATA

On Thu, 2 Jun 2005 09:18:05 -0500, Rob Wunderlich
<[EMAIL PROTECTED]> wrote:

>"FTP.DATA" is a generic name. The actual dataset names and search order are
>documented in "Communications Server: IP User's Guide and Commands" for the
>FTP client, and in "Communications Server: IP Configuration Reference" for
>the FTP server.

Does anybody else wish the FTP client would merge all files it finds in the
search order, instead of stopping at the first one?  The way it works now,
as far as I can tell, if I want to create a userid.FTP.DATA to override a
couple of options in SYS1.TCPPARMS(FTPDATA),  I have to copy the system-wide
file into the user file and make the changes, rather than just changing what
I want changed and letting it pick up the rest from the system file.

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

Jamie Pease is away from the Office.

[PEASE, Jamie]

I will be out of the office from 02/06/2005 until 06/06/2005.

If you need a response whilst I'm away, please contact one of the following
people. Otherwise, I'll respond to your e-mail when I return.

Scott Thomas - for matters relating to MOSAR and project S&AM
Phil Secker - for any other business


Regards
Jamie Pease
Subject Matter Expert/Manager
NUCS Security Services



**
This email and any files sent with it are intended only for the named
recipient. If you are not the named recipient please telephone/email
the sender immediately. You should not disclose the content or
take/retain/distribute any 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: Userids

[Low, David]

> Totally unnecessary. UADS is needed only for the "emergency" 
> User ID -- 
> used when no security product is available.

Wow.  That's very good to know, thanks.

Dave Low

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

Anyone able to read/write VBM file from COBOL?

[Kovach, Mike]

I am trying to work with the output of GDDM and want to manage the file
myself.  Any ideas?
 Important Notice to Recipients 
It is important that you do not use e-mail to request, authorize or effect the 
purchase or sale of any security or commodity, to send fund transfer 
instructions, or to effect any other transactions. Any such request, orders, or 
instructions that you send will not be accepted and will not be processed by 
Morgan Stanley.


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

Off on another wild goose chase - Electronic Vaulting

[Dean Montevago]

Hi,

Anyone have any recommendations on vendors ? Is anyone doing this ? I did a 
search in Google and got alot of hits. This is for both z/OS and distributed 
platforms.

TIA
Dean

Dean Montevago
Sr. Systems Specialist
Visiting Nurse Service of New York

phone: (212) 609 - 5596
email: [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

ISRSUPC - Odd Behavior

[Tom Savor]

Cross posted with ISPF group:

Seeing some odd behavior with ISRSUPC (SuperC) scan in Batch:

//SEARCH  EXEC PGM=ISRSUPC,
//PARM=(SRCHCMP,
//'ANYC')
//NEWDD  DD DSN=PDS1,DISP=SHR
//   DD DSN=PDS2,DISP=SHR
//OUTDD  DD SYSOUT=(*)
//SYSIN  DD *
SRCHFOR  'COUNTRY'

Results in:
PGM1CONCAT#(01)  --- STRING(S) FOUND ---
 5  127815 MOVE MST-COUNTRY TO WK-COUNTRY.
 7  153925 MOVE MST-COUNTRY-ALPHATO W-COUNTRY-TEST.

LINES-FOUND  LINES-PROC  MEMBERS-W/LNS  MEMBERS-WO/LNS  COMPARE-COLS
LONGEST-LI
2   3049971   1561   1:80
80

THE FOLLOWING "SRH" FILE CONCATENATED DATA SETS WERE SPECIFIED:
 (01) PDS1
 (02) PDS2

Now PDS1 has 435 members.
PDS2 has 1272 members for a total of 1707.
But only 1561 members were searched !!  Huh ??

Both PDS's are defined as LRECL=80, BLKSIZE=18400, RECFM=FB and they are
both PDS's not
PDSE's.

Now if I flip the concatenation of PDS1 and PDS2, the same number of
members is searched,
but the search results happens to be "none found".

LINES-FOUND  LINES-PROC  MEMBERS-W/LNS  MEMBERS-WO/LNS  COMPARE-COLS
LONGEST-LI
0   3390430   1562   1:80
80
PROCESS OPTIONS USED: ANYC
THE FOLLOWING PROCESS STATEMENTS (USING COLUMNS 1:72) WERE PROCESSED:
   SRCHFOR  'COUNTRY'
THE FOLLOWING "SRH" FILE CONCATENATED DATA SETS WERE SPECIFIED:
 (01) PDS2
 (02) PDS1
Why does scan stop at 1561 or 1562 members when concatenated total is 1707
??

Thanks,

Tom Savor
Certegy Card Services
11720 Amber Park Drive, Suite 500
Alpharetta, GA  30004

Phone: 678-867-8431
cell:  404-660-6898
E-Mail: [EMAIL PROTECTED]
/\/\_00_/\/\







--
This message contains information from Certegy, Inc which may be confidential 
and privileged.  If you are not an intended recipient, please refrain from any 
disclosure, copying, distribution or use of this information and note that such 
actions are prohibited.  If you have received this transmission in error, 
please notify by e:mail [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: ISRSUPC - Odd Behavior

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Savor
> Sent: Thursday, June 02, 2005 1:23 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: ISRSUPC - Odd Behavior
> 
> 
> Cross posted with ISPF group:
> 
> Seeing some odd behavior with ISRSUPC (SuperC) scan in Batch:
> 
> //SEARCH  EXEC PGM=ISRSUPC,
> //PARM=(SRCHCMP,
> //'ANYC')
> //NEWDD  DD DSN=PDS1,DISP=SHR
> //   DD DSN=PDS2,DISP=SHR
> //OUTDD  DD SYSOUT=(*)
> //SYSIN  DD *
> SRCHFOR  'COUNTRY'
> 
> Results in:
> PGM1CONCAT#(01)  --- STRING(S) FOUND 
> ---
>  5  127815 MOVE MST-COUNTRY TO WK-COUNTRY.
>  7  153925 MOVE MST-COUNTRY-ALPHATO 
> W-COUNTRY-TEST.
> 
> LINES-FOUND  LINES-PROC  MEMBERS-W/LNS  MEMBERS-WO/LNS  COMPARE-COLS
> LONGEST-LI
> 2   3049971   1561   1:80
> 80
> 
> THE FOLLOWING "SRH" FILE CONCATENATED DATA SETS WERE SPECIFIED:
>  (01) PDS1
>  (02) PDS2
> 
> Now PDS1 has 435 members.
> PDS2 has 1272 members for a total of 1707.
> But only 1561 members were searched !!  Huh ??
> 
> Both PDS's are defined as LRECL=80, BLKSIZE=18400, RECFM=FB 
> and they are
> both PDS's not
> PDSE's.
> 
> Now if I flip the concatenation of PDS1 and PDS2, the same number of
> members is searched,
> but the search results happens to be "none found".
> 
> LINES-FOUND  LINES-PROC  MEMBERS-W/LNS  MEMBERS-WO/LNS  COMPARE-COLS
> LONGEST-LI
> 0   3390430   1562   1:80
> 80
> PROCESS OPTIONS USED: ANYC
> THE FOLLOWING PROCESS STATEMENTS (USING COLUMNS 1:72) WERE PROCESSED:
>SRCHFOR  'COUNTRY'
> THE FOLLOWING "SRH" FILE CONCATENATED DATA SETS WERE SPECIFIED:
>  (01) PDS2
>  (02) PDS1
> Why does scan stop at 1561 or 1562 members when concatenated 
> total is 1707
> ??
> 
> Thanks,
> 
> Tom Savor

I'd guess that you have duplicate member names and that the member in
PDS1 hides the same named member in PDS2.


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

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

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

Re: TSO replacement? [WAS: RE: Userids]

[Paul Hanrahan]

I say we go with ROSCOE. (smirk) - Paul Hanrahan

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Farley, Peter x23353
Sent: Thursday, June 02, 2005 12:47 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: TSO replacement? [WAS: RE: Userids]


Yes, but no programmer in their right mind would devlop under z/OS
"independent" of TSO.  TSO is your everyday, all-the-time development
environment for these applications, at least it is in all the shops I
have known.

I suppose it is possible to do so, given that there are a few decent
peecee editors and given ftp of JCL to JES and listings back from JES,
but that doesn't cover source-level debugging needs or post-mortem
interactive dump review to solve problems.

Peter

--
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: ISRSUPC - Odd Behavior

[Farley, Peter x23353]

Maybe some of the member names in the two PDS files are identical?
Concatenations will only return the *first* occurence of a given unique
member name, all other members named identically below that first one are
ignored.

That explanation, however, can't explain the difference between the two
runs.  I would think the number of uniquely-named members was identical,
unless someone added a new uniquely-named member to one of them in between
those two runs.

HTH

Peter

-Original Message-
From: Tom Savor [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 2:26 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: ISRSUPC - Odd Behavior


Cross posted with ISPF group:

Seeing some odd behavior with ISRSUPC (SuperC) scan in Batch:



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

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

Re: ISRSUPC - Odd Behavior

[Kovach, Mike]

Of course it does.  The members share the same name.  They are not
necessarily equal in content.  Depending on the order of concatenation,
different modules will be scanned.

Mike

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Farley, Peter x23353
Sent: Thursday, June 02, 2005 2:45 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: ISRSUPC - Odd Behavior

Maybe some of the member names in the two PDS files are identical?
Concatenations will only return the *first* occurence of a given unique
member name, all other members named identically below that first one
are
ignored.

That explanation, however, can't explain the difference between the two
runs.  I would think the number of uniquely-named members was identical,
unless someone added a new uniquely-named member to one of them in
between
those two runs.

HTH

Peter

-Original Message-
From: Tom Savor [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 02, 2005 2:26 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: ISRSUPC - Odd Behavior


Cross posted with ISPF group:

Seeing some odd behavior with ISRSUPC (SuperC) scan in Batch:



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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
 Important Notice to Recipients 
It is important that you do not use e-mail to request, authorize or effect the 
purchase or sale of any security or commodity, to send fund transfer 
instructions, or to effect any other transactions. Any such request, orders, or 
instructions that you send will not be accepted and will not be processed by 
Morgan Stanley.


--
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: ISRSUPC - Odd Behavior

[Wayne Driscoll]

I think Peter Farley hit the nail on the head, and the reason that the
MEMBERS-W/LNS is 0 if PDS2 is first, but 1 if PDS1 is first is because both
PDS1 and PDS2 have a member PGM1.  In PDS1, it has the word COUNTRY, but in
PDS2 it doesn't.  The number of members SCANNED is the same in both runs,
1562, its just that in the first run, there was 1 member with lines + 1561
w/o = 1562.  In the second run, 0 with lines + 1562 w/o = 1562.
Wayne Driscoll
Product Developer
Western Metal Supply
NOTE: All opinions are strictly my own.
  

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Tom Savor
Sent: Thursday, June 02, 2005 1:23 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: ISRSUPC - Odd Behavior

Cross posted with ISPF group:

Seeing some odd behavior with ISRSUPC (SuperC) scan in Batch:

//SEARCH  EXEC PGM=ISRSUPC,
//PARM=(SRCHCMP,
//'ANYC')
//NEWDD  DD DSN=PDS1,DISP=SHR
//   DD DSN=PDS2,DISP=SHR
//OUTDD  DD SYSOUT=(*)
//SYSIN  DD *
SRCHFOR  'COUNTRY'

Results in:
PGM1CONCAT#(01)  --- STRING(S) FOUND ---
 5  127815 MOVE MST-COUNTRY TO WK-COUNTRY.
 7  153925 MOVE MST-COUNTRY-ALPHATO W-COUNTRY-TEST.

LINES-FOUND  LINES-PROC  MEMBERS-W/LNS  MEMBERS-WO/LNS  COMPARE-COLS
LONGEST-LI
2   3049971   1561   1:80
80

THE FOLLOWING "SRH" FILE CONCATENATED DATA SETS WERE SPECIFIED:
 (01) PDS1
 (02) PDS2

Now PDS1 has 435 members.
PDS2 has 1272 members for a total of 1707.
But only 1561 members were searched !!  Huh ??

Both PDS's are defined as LRECL=80, BLKSIZE=18400, RECFM=FB and they are
both PDS's not PDSE's.

Now if I flip the concatenation of PDS1 and PDS2, the same number of members
is searched, but the search results happens to be "none found".

LINES-FOUND  LINES-PROC  MEMBERS-W/LNS  MEMBERS-WO/LNS  COMPARE-COLS
LONGEST-LI
0   3390430   1562   1:80
80
PROCESS OPTIONS USED: ANYC
THE FOLLOWING PROCESS STATEMENTS (USING COLUMNS 1:72) WERE PROCESSED:
   SRCHFOR  'COUNTRY'
THE FOLLOWING "SRH" FILE CONCATENATED DATA SETS WERE SPECIFIED:
 (01) PDS2
 (02) PDS1
Why does scan stop at 1561 or 1562 members when concatenated total is 1707
??

Thanks,

Tom Savor
Certegy Card Services
11720 Amber Park Drive, Suite 500
Alpharetta, GA  30004

Phone: 678-867-8431
cell:  404-660-6898
E-Mail: [EMAIL PROTECTED]
/\/\_00_/\/\








--
This message contains information from Certegy, Inc which may be
confidential and privileged.  If you are not an intended recipient, please
refrain from any disclosure, copying, distribution or use of this
information and note that such actions are prohibited.  If you have received
this transmission in error, please notify by e:mail [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

--
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: TSO replacement?

[Howard Brazee]

On  2-Jun-2005, Anne & Lynn Wheeler <[EMAIL PROTECTED]> wrote:

> guess who used to pay for ISPF development? it is an inside joke.
> when every business operation had to show a profit ... a "strategic"
> product that couldn't cover its own bills (customers would never pay
> what was actually necessary to cover the run rate of the operation
> doing the development) would be combined with some real profit making
> product(s) ... so the overall business operation showed a profit. at
> one point ISPF was frequently held up as a prime example.

Programmers are used to persuading our companies that they need to pay for
projects that individual customers are not willing to pay for.

If people in charge of making purchases of systems believe TSO is dead, then
they will be more likely to go with systems that they perceive having a future.
  Which means IBM doesn't sell as many systems, and our skills have less value.

--
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: ISRSUPC - Odd Behavior

[Tom Savor]

In looking closer at these 2 PDS's, yes there are duplicate names.  There
are 145 of them.
No alias, but my first reaction was "so what".  I don't normally
concatenate PDS's when
I do scans, I normally scan 1 at a time.  In looking at the manual, I see
that there is
an option called SDUPM (Scan duplicate members).  Never heard of it.

Anyway, ran scan again adding SDUPM option, it scanned all 1707 !!!

I guess you learn something every day.

Thanks to everyone for their guidance !!

Thanks again,


Tom Savor
Certegy Card Services
11720 Amber Park Drive, Suite 500
Alpharetta, GA  30004

Phone: 678-867-8431
cell:  404-660-6898
E-Mail: [EMAIL PROTECTED]
/\/\_00_/\/\







--
This message contains information from Certegy, Inc which may be confidential 
and privileged.  If you are not an intended recipient, please refrain from any 
disclosure, copying, distribution or use of this information and note that such 
actions are prohibited.  If you have received this transmission in error, 
please notify by e:mail [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: Best practice of reducing the extent of PDS defined in lnklst

[Patrick O'Keefe]

On Thu, 2 Jun 2005 07:46:07 -0400, Peter Relson <[EMAIL PROTECTED]> wrote:

>...
>So the key, overall, is to make it so that the system does
>not have the data set allocated (at which point you can do
>whatever you want with that data set). And the system will
>no longer have the data set allocated when that data set
>is not in any active LNKLST set and is not being managed
>by LLA.
>...
>1...
>...
>9...

I'm way out of my area of expertise here - couldn't get much farther - so
I may be way off base, but I think this is also the procedure needed to
get space freed in a linklist PDSE.  You just don't have to do anything
between freeing it and reallocating it.  But if you don't go through the
procedure, freed space doesn't get reclaimed.  At least that used to be
the case.

And I think "system" means "all systems in a Sysplex".

Pat O'Keefe

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

Re: TSO replacement? [WAS: RE: Userids]

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Edward E. Jaffe
> Sent: Thursday, June 02, 2005 11:13 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: TSO replacement? [WAS: RE: Userids]
> 
> 
> McKown, John wrote:
> 
> >Perhaps IBM is really wanting to push WSED (WebSphere Studio 
> Enterprise
> >Developer)? I don't know much about it, but it appears to be 
> some sort
> >of Microsoft Windows based GUI development that interfaces with some
> >WebSphere thingie on z/OS. This may explain the demise of 
> the ISPF GUI.
> >  
> >
> 
> WSED cannot be considered a general TSO/ISPF replacement.
> 

I'm not too sure of that after looking at:

http://www-306.ibm.com/software/awdtools/devzseries/


Improves the productivity for developers to create, maintain, debug and
deploy traditional transactional and batch applications to the z/OS(r)
platform, while providing additional tools for assisting them in their
Web integration efforts.


It also has the ability to open up a "standard" TSO session via TN3270E
as well as other 3270 applications, using Host On Demand:

http://www-128.ibm.com/developerworks/websphere/library/techarticles/050
4_barosa/0504_barosa.html

I, personally, would really like to have our programmers (the really
smart ones) look at this gizmo. Of course, if I read the pricing
correctly, it is $5,500 per user. But I could be wrong on that point. If
true, it is yet another case of "the mainframe is too expensive!"

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

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

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

Re: TSO replacement? [WAS: RE: Userids]

[Ed Gould]

on 6/2/05 12:02 PM, Howard Brazee at [EMAIL PROTECTED] wrote:

> On  2-Jun-2005, [EMAIL PROTECTED] (Ed Gould) wrote:
> 
>> When IBM semi announced that TSO was dead the first question was what was
>> the replacement? We did not get an answer or even a hint. One of my IBM
>> sources said they were working on a *COMPLETE* replacement but did not
>> elaborate.
> 
> The trouble is, IBM has to be very careful in what it implies.What happens
> if its bigwigs decide internally that, say MVS should no longer be developed
> because new customers should go to other platforms that IBM is working on?
> If
> it they decided that, they certainly would not want to let us know until they
> were ready for our response.
> 
> Well, replacing TSO might have similar consequences on a smaller scale.
> Companies that are thinking about their next applications upgrade are biased
> to
> use platforms that they are familiar with that cost less to train users on.
> If they hear that TSO is going away, they see "We'll have to train people
> anyway, it doesn't matter what platform we go to".So IBM is better off if
> we
> don't hear that TSO is going away - at least until their salesmen have
> something
> better to show us.
> 

Howard,

I agree with you. Somehow I would expect IBM to come up with a similar
product but will act/feel like the old TSO we all know (and love/hate). From
what little feedback that was given us IBM is scared about how TSO has grown
over the years (This bit for this and that bit for that). Probably the
entire structure is so poorly documented now that no one can really touch
it.

Mind you this could let IBM to take the "best " parts and move them to the
replacement and leave the old stuff behind. IKJDAIR was mentioned as a
nightmare. 

As to Bob Shannons comments, so its stabalized.. that pretty much means that
their should be a replacement is in the wings (to me).

VSPC at one time was thought to be a TSO killer, but it was pretty apparant
(to me) it was dead on arrival.

Why not get SHARE board to ask? That will let everyone know what the
situation really is (assuming IBM will let the question be asked or for that
matter even answered.

Ed

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

Re: TSO replacement? [WAS: RE: Userids]

[Edward E. Jaffe]

McKown, John wrote:


It also has the ability to open up a "standard" TSO session via TN3270E
as well as other 3270 applications, using Host On Demand:
 



This is necessary because WSED cannot be considered a general TSO/ISPF 
replacement.


--
-
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | 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: VTAM newsgroup

[Matthew Stitt]

On Wed, 1 Jun 2005 12:34:41 -0700, Edward E. Jaffe
<[EMAIL PROTECTED]> wrote:

>Patrick O'Keefe wrote:
>
>>>Is there a newsgroup dedicated to just VTAM Q and A's?
>>>...
>>>
>>>
>>
>>2 of them, both at news.software.ibm.com
>>   ibm.networking.vtam
>>   ibm.software.commserver.os390.sna
>>Both are pretty inactive except for occassional spam.
>>
>>
>
>These groups were once very active VTAM-related CFORA from IBMLink. It's
>sad that the transition from CFORA to internet news didn't work.
>
>
There is also this Listserv list:

[EMAIL PROTECTED]

Not much traffic and not many subscribers.

--
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: TSO replacement? [WAS: RE: Userids]

[Paul Gilmartin]

In a recent note, McKown, John said:

> Date: Thu, 2 Jun 2005 14:23:06 -0500
> 
> It also has the ability to open up a "standard" TSO session via TN3270E
> as well as other 3270 applications, using Host On Demand:
> 
What if the user is already logged on to TSO on another terminal?

One of the adverse consequences of the single-session limit is that
such tools can't bring up a transient TSO/ISPF session to edit some
text, or to run a query command, because of the possibility that
the user may already have a contending TSO session.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
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: TSO replacement? [WAS: RE: Userids]

[Steve Grimes]

I've heard ROSCOE may make a comeback!

(Is it Friday yet?)

Stg

--
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: Encryting Data on Tapes

[Jeffrey Deaver]

>
>Now maybe FDR can enable it as well;-)
>

Ask, and you shall receive...  just got an announcement from Innovation on
their forthcoming encryption software.

Find it here...   http://www.innovationdp.com/products/fdrcrypt/

Jeffrey Deaver, Senior Analyst, Systems Engineering
651-665-4231

--
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: Shopping the zMall

[Skip Robinson]

Ed J,

I have to admit that, having enumerated the steps for my earlier post, Shop
does look a bit labor intensive. But so does your morning ritual over the
bathroom sink if you detail the entire rigamarole necessary to make
yourself presentable (or at least tolerable!) to your fellow creatures. The
question is whether the process could be greatly simplified without
omitting critical steps (ugh!).

In defense of Shop as it works today, the procedure I laid out manages--and
synchronizes--three CSIs at once. I once had to manage two CSIs with SUF
and was always queasy about how close together I was keeping the z/OS
levels.

As to your wish list, I have it on some authority that Shop may be veering
toward the automation ramp. Think of a cross between the self-propelled
nature of SUF and the connection simplicity of Shop while preserving the
ability to leap multiple CSIs in a single bound. You might have to get used
to longer coffee breaks to take up the slack time. ;-)

.
.
.
JO.Skip Robinson
Southern California Edison Company
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[EMAIL PROTECTED]


>
> Yikes! You've done well to illustrate exactly my complaints re: using
> ShopzSeries for maintenance. Too many manual steps!
>

>
> Put simply: I want ShopzSeries to do more things "automagically", like
> SUF! All that copy/paste and submitting of jobs seems like taking a
> giant leap backwards!

--
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: Two questions: Q1 - DFHSM CPU usage; Q2 - Tape Allocation

[Russell Witt]

Of course there is always the Tape Preferencing and Control Facility (TPCF)
within the MIA component of Unicenter CA-MIM. That has a couple of different
options for controlling the allocation of shared tape drives (either
dedicate them to a single system, share, or assign a preference value). Just
another option..

Russell Witt
CA-1 Level-2 Support Manager

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Ted MacNEIL
Sent: Wednesday, June 01, 2005 7:00 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Two questions: Q1 - DFHSM CPU usage; Q2 - Tape Allocation


...
Using the lowest tape drive address is bad for tape drive wear and tear
...

I was attempting to be sarcastic about the “thank-you”.

And, you are correct.
The algorithm is wrong.

--
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: Encryting Data on Tapes

[Ed Gould]

on 6/2/05 4:30 PM, Jeffrey Deaver at [EMAIL PROTECTED] wrote:

>> 
>> Now maybe FDR can enable it as well;-)
>> 
> 
> Ask, and you shall receive...  just got an announcement from Innovation on
> their forthcoming encryption software.
> 
> Find it here...   http://www.innovationdp.com/products/fdrcrypt/

How does it work in a Stand Alone environment, any ideas?

Ed

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

Re: Two questions: Q1 - DFHSM CPU usage; Q2 - Tape Allocation

[Ed Gould]

on 6/2/05 6:26 PM, Russell Witt at [EMAIL PROTECTED] wrote:

> Of course there is always the Tape Preferencing and Control Facility (TPCF)
> within the MIA component of Unicenter CA-MIM. That has a couple of different
> options for controlling the allocation of shared tape drives (either
> dedicate them to a single system, share, or assign a preference value). Just
> another option..
> 
> Russell Witt
> CA-1 Level-2 Support Manager
--SNIP__

Thanks Russell, finally, a reason to use MIM:-)


Ed

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

Re: Userids

[Tony Babonas]

Oh my gosh, I thought we were the last company to convert from UADS to
external security (TSS last year).  It's mystifying why anyone would
"outvote" you on this count.  We were years and years overdue but we're
certainly not looking back.

I've done several of these conversions, each with the popular 3 ESMs, all
but the last were easy, transparent, and gradually phased in.

My sympathies,
tb

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Craig Kittendorf
Sent: Thursday, June 02, 2005 12:00 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Userids

No, it is not necessary to maintain UADS for users defined in Top Secret.
There is even a provided utility to convert your UADS to TSS.  Once a TSO
segment is added to a TSS acid, if the user is defined in UADS, it will be
ignored for that acid.

There are some functions which can not be permitted using UADS.

Craig

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Low, David
Sent: Thursday, June 02, 2005 12:50 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Userids

> John Eels queried why we are still using UADS?  I tried to convert to 
> using our security software, but, was outvoted.

My boss asked me about this the other day.  We have Top Secret yet we have
been maintaining UADS for all our userids.  Is this unnecessary?  I guess I
should go RTF TSS manuals.

Dave Low

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

Tracking down a NETID used within a program

[William McKinley]

It appears that a NETID, namely IBMIN is being called
from a program.

Are there any ideas on how to track this user?

We suspect it might be used within another program product - Connect Direct.

Regards, 
Bil McKinley 
SLF Consulting Services, inc. 
67 Wall Street 
Suite 2211-0094 
New York, NY 10005 
t/212.945.0062 
m/917.224.6012 
[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: Userids

[Ed Gould]

on 6/2/05 8:19 PM, Tony Babonas at [EMAIL PROTECTED] wrote:

> Oh my gosh, I thought we were the last company to convert from UADS to
> external security (TSS last year).  It's mystifying why anyone would
> "outvote" you on this count.  We were years and years overdue but we're
> certainly not looking back.
> 
> I've done several of these conversions, each with the popular 3 ESMs, all
> but the last were easy, transparent, and gradually phased in.
> 
> My sympathies,
> tb
> 
Tony,

I was a hold out as well. One of the main reasons was that our security
people were clueless when it came to assigning userids.

It was only after giving them strict guidelines and a physical threat to cut
off certain pieces of their body did I let go. I still had final OK but let
them do most of the work. The systems group maintain the responsibility for
defining their alias in the mastercat(s).

Ed

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

Re: Userids

[Tony Babonas]

Well,  I must share our last experience, the difficult one.  We were
mandated to preserve the EXACT logon sequence from the UADS days, byte for
bleeping byte.  The TSO user was formerly prompted for the UADS "password"
which mapped to the logon proc.  We had to write an exit to preserve the
prompt, populate the TSO segment that contains the logon proc (each of which
we had to rename) to match the UADS value, then log the user on. 

You would think our crack management team would appreciate losing a
keystroke sequence at logon time, times thousands of TSO users by losing the
UADS baggage.  But N.

Glad it's not my money..

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Ed Gould
Sent: Thursday, June 02, 2005 10:18 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Userids

on 6/2/05 8:19 PM, Tony Babonas at [EMAIL PROTECTED] wrote:

> Oh my gosh, I thought we were the last company to convert from UADS to 
> external security (TSS last year).  It's mystifying why anyone would 
> "outvote" you on this count.  We were years and years overdue but 
> we're certainly not looking back.
> 
> I've done several of these conversions, each with the popular 3 ESMs, 
> all but the last were easy, transparent, and gradually phased in.
> 
> My sympathies,
> tb
> 
Tony,

I was a hold out as well. One of the main reasons was that our security
people were clueless when it came to assigning userids.

It was only after giving them strict guidelines and a physical threat to cut
off certain pieces of their body did I let go. I still had final OK but let
them do most of the work. The systems group maintain the responsibility for
defining their alias in the mastercat(s).

Ed

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

--
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: Best practice of reducing the extent of PDS defined in lnklst

[Leonard Woren]

On Thu, Jun 02, 2005 at 07:46:07AM -0400, Peter Relson ([EMAIL PROTECTED]) 
wrote:
[...]
> Adding to existing data sets
> resulting in new extents is what causes problems. That is
> why IBM recommends that you allocate your LNKLST PDSs so that
> they cannot have secondary extents.

Agreed.  So, how do you do this?  Specify a secondary allocation of 0?
What about the following (incorrect but extremely common) JCL?
  // EXEC whateverCL
  //SYSLMOD DD DISP=SHR,DSN=some.linklist.dataset

That seemingly-reasonable JCL will allow secondary extents to be
allocated.  Why?  Because all of the IBM-supplied whateverCL procs
have //SYSLMOD DD UNIT=something,DISP=(MOD,PASS),SPACE=(t,(p,s)) .
Since, as touched on in another thread, the //SYSLMOD override 
doesn't nullify keywords in the proc which weren't on the override,
the secondary quantity "s" is applied on a one-time basis and a
secondary extent can be taken.  The "fix" for this is to specify
  // EXEC whateverCL
  //SYSLMOD DD DISP=SHR,DSN=some.linklist.dataset,SPACE=

Now, how many people do that?  Even ignoring the linklist issue, this
design problem wreaks all kinds of havoc.  If the in-proc DD contains
RLSE (because after all it was set up for a temporary dataset), then
you end up with a bunch of tiny extents.  And if the allocation type
specifications are different, you can get track-allocated secondary
extents in datasets which were allocated CYL or ROUND.  I won't even
mention what happens to libraries with blocksizes less than the 
maximum when the SYSLMOD in the proc contains a BLKSIZE= value
larger than the dataset's original blocksize.  (I don't know about
now, but in the past, compressing such a dataset with IEBCOPY would
destroy it because IEBCOPY would move members until it encountered a
block larger than the blocksize, then it would bail without updating
the directory for the already-moved members.)

Personally, I think the quick fix for this would be to risk breaking
poorly written JCL by completely removing SYSLMOD from all whateverCL
procs.

This is why I have used only my own custom-written whateverCL procs
for the last 30 years.

My personal rule of thumb:  vendor supplied JCL is *always* wrong.


/Leonard

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

Which thread Implementation Models does z/OS Unix use?

[Bo Xie]

Hi,

   Which thread Implementation Models does z/OS Unix use? M:1 or 1:1
or M:N ?  Thank you!

Best Regards,
Xie Bo

Reference
1. "Pthread Implementation Models Overview"
http://www.llnl.gov/LCdocs/pthreads/index.jsp?show=s5

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

Performance and Capacity Planning

[Paul Hanrahan]

Hi,
 
Anyone want to discuss LSPR, MIPS, RMF and SMF ? I found a free mips msu
chart at :
 
http://www.isham-research.co.uk/mips_z990.html
 
Paul Hanrahan

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

Re: Performance and Capacity Planning

[ibm-main]

And Phil will no doubt appreciate the free plug.
His disclaimers generally make the best reading ...

Shane ...

- Original Message - 
  
> Anyone want to discuss LSPR, MIPS, RMF and SMF ? I found a free mips msu
> chart at :
>  
> http://www.isham-research.co.uk/mips_z990.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