Re: z/OS v1.2 Infoprint Server Arabic printing

[Jaco Kruger]

Hi,

We checked already and there were no user exits for InfoPrint Server
installed

Regards
Jaco Kruger

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Ted MacNEIL]

...
In terms of raw compute power,
excluding I-O what is the ratio between 1 high end Sun engine, 1
PowerPC chip, 1 high end Intel chip (3.4 ghz or something like these
days and 1 Z990 engine?
...

Depending on who you talk to a z/990 is roughly equivalent to 2.5-3 Ghz.

It's getting to the point that if you want compute-intensive go mid-range;
if you want I/O go mainframe.


-teD

In God we Trust!
All others bring data!
  --Deming

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

Re: [BULK] Re: Sysplex communication enabled & in read-only mode

[norrizam md noor]

Hi Mark,B Sysprog, Bryan, etc.

It works. I have to zap/rep ICHRDSNT flags back to 80.

Thank you.

-- zam --

- Original Message -
From: Mark Zelden <[EMAIL PROTECTED]>
Date: Tuesday, July 12, 2005 9:53 pm
Subject: [BULK] Re: Sysplex communication enabled & in read-only mode

> On Tue, 12 Jul 2005 10:51:57 +0800, norrizam md noor 
> <[EMAIL PROTECTED]>wrote:
> 
> >In our recovery site (no XCF facility), our system enter this
> >emergency mode due to coupling facility inaccessible. I try to 
change
> >to RVARY NODATASHARE command (with default password YES) however 
RACF
> >status denied.
> >
> >When I used SETR command (RVARYPW(STATUS(pw))to set the operator
> >password, the system not permitted while running in read-only mode.
> >
> >Is there any where that I can change to system non-data share mode
> >which have full read/write capability to the RACF database.
> >
> >--zam --
> 
> This is a ZAP I use in creating my onepak/twopak systems to turn
> of the data sharing mode. Obviously you would have to run this
> from a driving system prior to IPL.  You could also have another
> ICHRDSNT ready to load into MLPA via IPL parm etc.
> 
> //RACFZAP7  EXEC PGM=AMASPZAP
> //SYSPRINT DD  SYSOUT=*
> //SYSLIB   DD  DSN=SYS1.VSYS1PK.LINKLIB,DISP=SHR
> //SYSINDD  *
> NAME ICHRDSNT ICHRDSNT
> REP 005A 80
> /*
> 
> 
> Mark
> --
> Mark Zelden
> Sr. Software and Systems Architect
> mailto: [EMAIL PROTECTED]
> Systems Programming expert at http://Search390.co
> 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.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: CICS Error ERDSA Problem

[Jeevan ibm]

All these options have been tried but still the same error persist.
Also attached snapshot of SYSVIEW Tool gives some info regarding
ERDSA. (100%)

There are more number of Getmains than Freemains. And also it gives
some info regarding CICS Subpools Can anyone throw some light on this
?

Jobname CICSXXX   ASID 006D  Jobid STC03582  CICS TS1.3
Storage protection is ACTIVE   
RegionUser   Sys Alloc  Free   PctS  Size   PctL Limit Avail  High   SOS   
DSA  1.03M  740K59% 1.75M21%5M 1.75M 1.75M 
EDSA  276M 41.3M87%  318M29%  960M   25M  318M 
PVT  5.46M  704K 6.15M 2.52M77% 7.98M68% 7.98M 
E-PVT 974M 13.3M  987M 25.8M53% 1.82G97% 1000M 
---
Cmd DSAname   Size Alloc  Free MFree SOS Queued Used ...20...40...60...80..100 
UDSA  256K  132K  124K  116K 52%   
CDSA  768K  632K  136K  112K 82%   
SDSA  256K   12K  244K  244K  5%   
RDSA  512K  276K  236K  196K 54%   
ECDSA  30M   29M  992K  636K 97%   
EUDSA 152M  112M 39.8M3M 74%   
ESDSA  
ERDSA 136M  135M  464K   64K100%   
FreeDSA  3.25M   3.25M 3.25M  0%   
FreeEDSA  642M642M  642M  0%   



Subpool  Num DSAname  Alloc  Used  Free Getmains Freemain Elements Align 
LDENRSRO  41 ERDSA5.63M 5.62M 11.5K  2891016  
LDENUCRO  37 ERDSA2.46M 2.44M 17.6K   797   1316  



Subpool  Num Address  Length DSAname  Page Free Stgv SCA  SCE  
LDENUCRO  37 0BEFDEF0272 ERDSA 255 FREE  0BC6F728 0BC5D1A0 
LDENUCRO  37 0BF8CFF0   4528 ERDSA 142 FREE  0BC6F728 0BC98488 
LDENUCRO  37 0BF90F00256 ERDSA 146 FREE  0BC6F728 0BC5D1E8 
LDENUCRO  37 0C3A1EF0   1456 ERDSA 163 FREE  0BC6F728 0BC98A28 
LDENUCRO  37 0C3A8950   1712 ERDSA 170 FREE  0BC6F728 0BC989F8 
LDENUCRO  37 0C3E0C40   1744 ERDSA 226 FREE  0BC6F728 0BC98A10 
LDENUCRO  37 0C3FDBC0   1088 ERDSA 255 FREE  0BC6F728 0BC5D3C8 
LDENUCRO  37 0C9D8F90112 ERDSA 218 FREE  0BC6F728 0BC98638 
LDENUCRO  37 0C9FFAF0   1296 ERDSA 257 FREE  0BC6F728 0BC5DDE8 
LDENUCRO  37 0CDFDF10240 ERDSA 511 FREE  0BC6F728 0BC98668 
LDENUCRO  37 0D1277B0   2128 ERDSA 808 FREE  0BC6F728 0BC98650 
LDENUCRO  37 0D143EF0272 ERDSA 837 FREE  0BC6F728 0BCE24D0 
LDENUCRO  37 0FAE8460   2976 ERDSA 745 FREE  0BC6F728 4876E1B8 




Subpool  Num Address  Length DSAname  Page Free Stgv SCA  SCE
LDENRSRO  41 0BE0 16 ERDSA 257 FREE  0BC6F9F8 0BC5D6E0   
LDENRSRO  41 0BF0 16 ERDSA 257 FREE  0BC6F9F8 0BC5D728   
LDENRSRO  41 0C1FFF00256 ERDSA 513 FREE  0BC6F9F8 0BC5D7B8   
LDENRSRO  41 0C2FFFD0 48 ERDSA 257 FREE  0BC6F9F8 0BC5D7D0   
LDENRSRO  41 0C396FF0 16 ERDSA 152 FREE  0BC6F9F8 0BC5D818   
LDENRSRO  41 0C93D670   2448 ERDSA  62 FREE  0BC6F9F8 0BC98C80   
LDENRSRO  41 0C9F1C20992 ERDSA 243 FREE  0BC6F9F8 0BC98608   
LDENRSRO  41 0D132550   2736 ERDSA 819 FREE  0BC6F9F8 0BC98DE8   
LDENRSRO  41 0D167DA0   4704 ERDSA 873 FREE  0BC6F9F8 0BC5DDB8   
LDENRSRO  41 0D512DC0576 ERDSA 276 FREE  0BC6F9F8 0BC98770   




1.  Write reentrant code, and/or

2.  Link-edit the load module without the RENT attribute.

   -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: At Least Down-Under There Is Demand...

[Paul Gillis]

Nothing about this on the university web site. The 3 companies mentioned are
close to the last of the "not yet outsourced" organisations in the country.

Paul Gillis
Technical Director
Pacific Systems Management Pty. Ltd.  

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Gary Green
> Sent: Tuesday, 12 July 2005 10:41 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: At Least Down-Under There Is Demand...
> 
> For those that care about such issues...
> 
> http://australianit.news.com.au/articles/0,7204,15895569%5E153
17%5E%5Enbv%5E
> 15306,00.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access 
> instructions, send email to [EMAIL PROTECTED] with the 
> message: GET IBM-MAIN INFO Search the archives at 
> http://bama.ua.edu/archives/ibm-main.html
> 

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

Re: OS/2 still Lives?

[R.S.]

John S. Giltner, Jr. wrote:

[...]
I know that OS/2 still lives in the MOSS/E and APPN nodes for the 
3745-xxA and 3746-900's, HCD's and Sysplex Timers. That is in addition 
to 2074 and current HMC's.  I'm not sure about other places.


There is also OS/2 in 3494 tape library (Library Manager is PC with OS/2).

So, OS/2 resides in the following mainframe equipment:
- HMC
- SE
- 3494 LM
- 9037 sysplex timer
- 9032 Escon Director console
- teleprocessors (I didn't know).

I saw the presentation about new (planned) HMC - they claim it will be 
Linux based PC. I have nothing against Linux or OS/2 or whatever system, 
but I saw and sometimes use Linux based PC for ESS Shark. Wrong way! 
Extremely unfriendly, slow, inconvenient.
From the other hand I consider HDS SVP notebooks running under Windows 
95 or even 3.1 as quite useful and convenient.


--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: CPU time and system load

[Mike Meiring]

Should be about the same , but in some cases PR/SM (Lpar) overhead can
cause increase in TCB times. On a lightly loaded system the capture ratio
would typically drop, meaning that operating system is incurring relatively
more 'overhead' ('Low utilization effects' (LUE) coming into play).

On Sun, 10 Jul 2005 09:38:05 +0200, Miklos Szigetvari
<[EMAIL PROTECTED]> wrote:

>Hi
>
>What is the expectable CPU difference depend on system load ?
>(same job's CPU time on heavy loaded system or empty 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Open MVS question

[R.S.]

Marian Gasparovic wrote:


Bruce, there is syntax for accessing MVS dataset from Unix System
Service, name would look something like

cp "\\'mvs_dataset_name'" unixfile 


but I don't remember exactly. Search archives or consult USS documentation.


cp //mvs.name
slash, not backslash.

However only few of USS commands/utilities support MVS datasets.
USS Command Reference clearly mentions the names:
cp
mv
pax
tar
c89

Caution: the above list is for z/OS V1R4.

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[William Ball]

You're making a leap there that -I'm- certainly not ready to make. Speed 
isn't everything, never has been. 

If you want to play games or have application that you don't really care 
about when it gets done and a lot of times in accurate results and only 
has 1 or 2 users, you -might- be able to live with putting it on a Unix 
platform.

However, IMHO, the RAS -really- stinks.

You can't rely on those boxes being up and available to do -production- 
work when you need them.

One line of bad code or a missing line in a script and the box typically 
goes into a loop and freezes and a lot of the time can't be gotten control 
of again without turning the box off or pulling circuit cards to force it 
to quit.

The -whole- attitude of the group of people responsible for the care and 
feeding of the squatty boxes is one that a -production- environment in a 
mainframe world can't tolerate. They think nothing of taking a box down or 
changing an IP address in the middle of the day and without telling anyone 
they're about to do it. 

The number of people it takes to support the squatty box environment is 
unreal (5+to 1) for every application they put up. 

It's cheaper to maintain the mainframeoverall.

The average time for D/R recoverability on a squatty box is measured in 
daysnot hours.

And the list could go on and on.

Personally, I'd rather have a -slower- box and know that the RAS is there, 
unless of course I want to play a game. 

Bill

Mainframe - 

An obsolete device still used by thousands of obsolete companies, serving 
billions of obsolete customers, and making huge obsolete profits, for 
their obsolete shareholders. And this year's run twice fast as last 
year's.  -Phil Payne-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Fenner, Jim]

The average time for D/R recoverability on a squatty box is measured in 
daysnot hours.


For privacy's sake please do NOT read the anal-retentive message
appended automatically by our email system to this message :-)

I concur. At our installation , the SAP system which handles a lot of
the personnel and timekeeping data of 20,000 users suffered a 'bit' of
corruption.
The piddling amount of data would have been rolled back - correctly and
reliably - on mainframe DB2 in hours, IF it ever would have developed
the problem in the first place, which I seriously doubt.

However, it runs on MS-SQL server on PC servers, and the data recovery
took two *days*.






IMPORTANT

 The information transmitted is for the use of the intended recipient only and 
may contain confidential and/or legally privileged material. Any review, 
re-transmission, disclosure dissemination or other use of, or taking of any 
action in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited and may result in severe penalties.  If you 
have received this e-mail in error please notify the Privacy Hotline of the 
Australian Taxation Office, telephone 13 28 69 and delete all copies of this 
transmission together with any attachments. 


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

How to add, dynamically, a catalog to VLF?

[DMR-Qualitas Outsourcing]

Hi folks,

we need to know how to add, dynamically, a catalog to VLF. Actually,
this catalog resides at ISC.

The sequence executed is:

1) Remove this catalog from ISC with 'F CATALOG,ALLOCATE(catname),NOISC'
2) Add this catalog to VLF with 'F CATALOG,VLF(catname)


Then, this catalog is closed. We force to open this catalog (browse to
any file of it) and it's open but at report of 'F CATALOG,ALLOCATED'
shows this catalog with '-' at third position and therefore it isn't
at ISC or VLF!!!

FLAGS -VOLSER-USER-CATALOG NAME   
YS--R- S00013 0001 CATALOG.XXIN  

Y/N-ALLOCATED TO CAS
S-SMS
V-VLF
I-ISC
C-CLOSED
D-DELETED,
R-SHARED
A-ATL
E-ECS SHARED
K-LOCKED


Could you help us?

Tks.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: CPU time and system load

[ibm-main]

From: "Mike Meiring"
...
> On a lightly loaded system the capture ratio
> would typically drop, meaning that operating system is incurring
relatively
> more 'overhead' ('Low utilization effects' (LUE) coming into play).

Haven't seen a lightly loaded system in years.
And of course the LUE can always be "rectified" with one of those
aforementioned BR15s - or ten 

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: At Least Down-Under There Is Demand...

[ibm-main]

I (sortof) drive past Griffith each day.
This training is certainly not "big news" here in Brisbane.

Shane ...

- Original Message - 
From: "Paul Gillis"

> Nothing about this on the university web site. The 3 companies mentioned
are
> close to the last of the "not yet outsourced" organisations in the
country.

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

New z/OS V1R6 DFSMS Technical Guide

[Gary Green]

I just found this.  In case it's new to others, I thought I would post it.

http://publib-b.boulder.ibm.com/Redbooks.nsf/RedpieceAbstracts/sg246651.html
?Open

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: CICS Error ERDSA Problem

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Jeevan ibm
> 
> All these options have been tried but still the same error persist.

You might try starting CICS with SIT parm RENTPGM=NOPROTECT.  That will
cause the (E)RDSAs to be allocated from Key 8 storage (instead of Key 0).

> Also attached snapshot of SYSVIEW Tool gives some info 
> regarding ERDSA. (100%)

It appears you have adequate "reserve" available so this should not be an
issue.

-jc-

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

Re: How to add, dynamically, a catalog to VLF?

[Thomas Conley]

- Original Message - 
From: "DMR-Qualitas Outsourcing" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
Sent: Wednesday, July 13, 2005 6:56 AM
Subject: How to add, dynamically, a catalog to VLF?



Hi folks,

we need to know how to add, dynamically, a catalog to VLF. Actually,
this catalog resides at ISC.

The sequence executed is:

1) Remove this catalog from ISC with 'F CATALOG,ALLOCATE(catname),NOISC'
2) Add this catalog to VLF with 'F CATALOG,VLF(catname)


Then, this catalog is closed. We force to open this catalog (browse to
any file of it) and it's open but at report of 'F CATALOG,ALLOCATED'
shows this catalog with '-' at third position and therefore it isn't
at ISC or VLF!!!

FLAGS -VOLSER-USER-CATALOG NAME
YS--R- S00013 0001 CATALOG.XXIN


This is normal.  The status will be '-' until the catalog is actually 
accessed.  Did you remember to recycle VLF to pick up the new COFVLFxx?


Regards,
Tom Conley 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[David Andrews]

On Tue, 2005-07-12 at 20:33 -0300, Clark Morris wrote:
> Guess what?  While we may not like it, Sun, HP etc. are reliable
> enough for most things.  There are people in the Unix/Linux world who
> brag about the number of months between reboots.

A point well worth repeating.  A few years ago I had a brochure website
hosted on a HP Netserver running under FreeBSD.  It had two years of
consecutive uptime before we lost power in a planned outage.  (My site
~almost~ made Netcraft's list of longest-running sites on the 'net.  At
the time #100 had 800 or so days of uptime.)

The moral is that even five years ago, with commodity hardware and a
static application, you could have decent reliability.  With failover
capabilities, compartmentalized virtual machines, load balancing and
other goodies, the commodity guys are encroaching upon what was formerly
our territory.

(Not that a properly configured business system made out of commodity
parts is cheaper than one powered by zSeries.  But they have the
advantage of a ridiculously low price to get a foot in the door, an
advantage that P'keepsie doesn't have the will to match.)

-- 
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: ABCs of System Programming Volume 9 UNIX System Services

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.)
> Sent: Tuesday, July 12, 2005 8:22 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: ABCs of System Programming Volume 9 UNIX System Services
> 
> 
> In <[EMAIL PROTECTED]>, on 07/12/2005
>at 09:03 PM, Ulrich Boche <[EMAIL PROTECTED]> said:
> 
> >Maybe they try to drive home the fact that z/OS is the only supported
> > operating system for zSeries today
> 
> What happened to, e.g., z/VM?
>  
> -- 
>  Shmuel (Seymour J.) Metz, SysProg and JOAT

I think the original poster mean "z/OS is the only MVS-derived operating
system for the zSeries". Yeah, I know. That's not what he said. Of
course, z/OS people do tend to discount z/VM, z/VSE, and Linux for
zSeries. Hum, one could argue that z/VM is not an operating system. It
is a hypervisor. You cannot run "applications" on z/VM directly. Unless
you can write a "stand alone" application. Note that CMS is not z/VM. It
is an operating system which is tightly coupled to z/VM hypervisor
facilities.

Oh course, I should know better than to debate with you. I will lose
.


--
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: CSRCTABL pointed by ECVTCTBL

[Mark Zelden]

On Wed, 13 Jul 2005 10:30:45 +1000, Shane Ginnane <[EMAIL PROTECTED]>
wrote:

>Roland (of all people !!!) had an issue with non-displayable chars causing
>a screen erasure.
>So to avoid similar problems, maybe you'd like to use the following instead
>- thanks again to Mark for the function, which was unashamedly stolen from
>IPLINFO.
>
>Shane ...
>
>/* REXX */
>NUMERIC DIGITS 16/* handle big addresses */
>CVT  = C2d(Storage(10,4))/* point to CVT */
>ECVT = C2d(Storage(D2x(CVT + 140),4))/* point to CVTECVT */
>CTBL = C2d(Storage(D2x(ECVT + 204),4))   /* pt to Cust anchor tbl*/
>say '*** Customer Anchor Table listing - used slots   ***'
>say '*** note: slots are counted from 1 to correlate with ShowzOS ***'
>say
>  Do I = 0 to 1023
>ptr = (CTBL + (4*I))
>TST = C2d(Storage(D2x(ptr),4))
>If (TST <> '0') then do
> isvcode = storage(D2x(TST),32)
> call XLATE_NONDISP isvcode
> isvcode = RESULT
> /* remove the +1 from the following to use zero based slot counting */
> say 'Slot: 'I+1' ISV text: ' isvcode
>end
>  End
>exit
>
>XLATE_NONDISP:   /* translate non-display characters to a "."*/
>Arg XLATEPRM
>XLATELEN = Length(XLATEPRM) /* length of parm passed to routine  */
>Do J = 1 to XLATELEN/* check each byte for non-display chars */
>  If Substr(XLATEPRM,J,1) < '40'x then , /* and replace each char*/
>XLATEPRM = OVERLAY('.',XLATEPRM,I)   /* that is non-displayable  */
>End  /* with a period (.)*/
>Return XLATEPRM
>

You left out a line of code (not sure why).  x'FF' will also cause
problems.


XLATE_NONDISP:   /* translate non-display characters to a "."*/
Arg XLATEPRM
XLATELEN = Length(XLATEPRM) /* length of parm passed to routine  */
Do I = 1 to XLATELEN  /* check each byte for */
  If Substr(XLATEPRM,I,1) < '40'x | , /* non-display characters  */
 Substr(XLATEPRM,I,1) = 'FF'x  then , /* and replace each char   */
XLATEPRM = OVERLAY('.',XLATEPRM,I)/* that is non-displayable */
End   /* with a period (.)   */
Return XLATEPRM

I think x'00' is valid also but I never change IPLINFO.   If you
check the archives I think STK ..er SUN Paul (AKA gil) gave me
this alternative once:

XLATE_NONDISP:   /* translate non-display characters to a "."*/
Return(translate( arg(1), left('',64,'.') xrange('40'x,'FF'x), ,
  xrange('00'x,'FF'x) ) )

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

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

Re: Another - Another One Bites the Dust

[R.S.]

David Andrews wrote:


On Tue, 2005-07-12 at 20:33 -0300, Clark Morris wrote:


Guess what?  While we may not like it, Sun, HP etc. are reliable
enough for most things.  There are people in the Unix/Linux world who
brag about the number of months between reboots.



A point well worth repeating.  A few years ago I had a brochure website
hosted on a HP Netserver running under FreeBSD.  It had two years of
consecutive uptime before we lost power in a planned outage.  (My site
~almost~ made Netcraft's list of longest-running sites on the 'net.  At
the time #100 had 800 or so days of uptime.)


Uptime depends on many factors, not only hardware platform or operating 
system.
I know of several PC machines which were dedicated to specific tasks: 
modem transmission, telex transmission, etc. These machines worked under 
MS DOS, qutie archaic version, because of no upgrades. NEVER required 
reboot or application restart.
Equipment was XT, AT, 386, "clones" from Taiwan R.O.C. (I mean no famous 
brands like Compaq, Dell or other).


--
Radoslaw Skorupka
Lodz, Poland

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

TIOA problem

[Carroll, William]

I have a transaction that does a 'receive' for when it begins
execution.  All transactions in this region go through a single program,
then are xctl'd to the other programs.  In 1 transaction only, the tioa
somehow is always getting the same string added.  When the router type
program sees this, he sends the transaction on a different path.  I have
dumped the programs involved, used xpeditor, used traces.  When the first
transaction goes to 'exec cics return', there is nothing there.  When the
second transaction kicks off, it is.  Any help or pointers on finding this
would be greatly appreciated.  


Thank you

Bill Carroll

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Gary Green]

I need to concur somewhat...

A number of our IVR and telephony systems ran for years, and I do mean
years, on 286 platforms.  Of course it was under OS/2 1.x, but   Our
in-house-written PBX, Elvira, has been running on NT 4.0 since 4.0 was
released.  The only time it's down is for power outages, equipment moves, OS
updates, and, sad to say, bugs in our own software.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of R.S.
Sent: Wednesday, July 13, 2005 9:06 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Another - Another One Bites the Dust

David Andrews wrote:

> On Tue, 2005-07-12 at 20:33 -0300, Clark Morris wrote:
> 
>>Guess what?  While we may not like it, Sun, HP etc. are reliable 
>>enough for most things.  There are people in the Unix/Linux world who 
>>brag about the number of months between reboots.
> 
> 
> A point well worth repeating.  A few years ago I had a brochure 
> website hosted on a HP Netserver running under FreeBSD.  It had two 
> years of consecutive uptime before we lost power in a planned outage.  
> (My site ~almost~ made Netcraft's list of longest-running sites on the 
> 'net.  At the time #100 had 800 or so days of uptime.)

Uptime depends on many factors, not only hardware platform or operating
system.
I know of several PC machines which were dedicated to specific tasks: 
modem transmission, telex transmission, etc. These machines worked under MS
DOS, qutie archaic version, because of no upgrades. NEVER required reboot or
application restart.
Equipment was XT, AT, 386, "clones" from Taiwan R.O.C. (I mean no famous
brands like Compaq, Dell or other).

-- 
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: CSRCTABL pointed by ECVTCTBL

[ibm-main]

From: "Mark Zelden"
>
> You left out a line of code (not sure why).  x'FF' will also cause
> problems.

Straight cut-and-paste mate; maybe it's time I refreshed my copy of IPLINFO.

>
> I think x'00' is valid also but I never change IPLINFO.   If you
> check the archives I think STK ..er SUN Paul (AKA gil) gave me
> this alternative once:
>
> XLATE_NONDISP:   /* translate non-display characters to a "."*/
> Return(translate( arg(1), left('',64,'.') xrange('40'x,'FF'x), ,
>   xrange('00'x,'FF'x) ) )

I updated it after Eds post - figured I'd hold off and make sure no more
PMRs came in.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Fenner, Jim
> Sent: Wednesday, July 13, 2005 5:54 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Another - Another One Bites the Dust
> 
> 
> 
> 
> The average time for D/R recoverability on a squatty box is 
> measured in 
> daysnot hours.
> 
> 
> For privacy's sake please do NOT read the anal-retentive message
> appended automatically by our email system to this message :-)
> 
> I concur. At our installation , the SAP system which handles a lot of
> the personnel and timekeeping data of 20,000 users suffered a 'bit' of
> corruption.
> The piddling amount of data would have been rolled back - 
> correctly and
> reliably - on mainframe DB2 in hours, IF it ever would have developed
> the problem in the first place, which I seriously doubt.
> 
> However, it runs on MS-SQL server on PC servers, and the data recovery
> took two *days*.

Agreed,

We recover our zSeries production environment (not test or MDOF) in
about 8 hours. The LAN people have never completely restored their
production environment at DR. They just pick one "system" to restore
(maybe 3-4 boxes - MS SQL server, Application Server, IIS Server) and
test it, along with the "Active Directory" environment.

Also, we backup our production environment in about 3 hours on Sunday
(and people complain!). The LAN people schedule all of Saturday and
Sunday for their backups. And they rarely complete successfully. They
blame it on "obsolete tape technology" and are pushing for off-site
replication as the ONLY possible solution. I like off-site replication,
but to say it is the ONLY possible solution just points out the
immaturity of their solution.


--
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: CSRCTABL pointed by ECVTCTBL

[Mark Zelden]

On Tue, 12 Jul 2005 17:45:00 -0700, Edward E. Jaffe
<[EMAIL PROTECTED]> wrote:


>
>FYI. This test is incomplete/erroneous. The valid characters for modern
>3270 devices are x'00' and x'40' through x'FE' inclusive. x'01' through
>x'3F' and x'FF' will cause PROGxxx failures.
>

Ed, thanks for the clarification (x'00').   What about on real 3270
terminals.  Will x'00' cause a program check?

At any rate... here is the slight modification to the REXX code
so it is not erroneous:

XLATE_NONDISP:   /* translate non-display characters to a "."*/
Arg XLATEPRM
XLATELEN = Length(XLATEPRM) /* length of parm passed to routine  */
Do I = 1 to XLATELEN  /* check each byte for */
  If (Substr(XLATEPRM,I,1) > '00'x & ,/* non-display characters  */
Substr(XLATEPRM,I,1) < '40'x ) | ,/* and replace each*/
Substr(XLATEPRM,I,1) = 'FF'x  then ,  /* character that  */
XLATEPRM = OVERLAY('.',XLATEPRM,I)/* is non-displayable  */
End   /* with a period (.)   */
Return XLATEPRM

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

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

Re: TIOA problem

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Carroll, William
> 
>   I have a transaction that does a 'receive' for when it 
> begins execution.  All transactions in this region go through 
> a single program, then are xctl'd to the other programs.  In 
> 1 transaction only, the tioa somehow is always getting the 
> same string added.  When the router type program sees this, 
> he sends the transaction on a different path.  I have dumped 
> the programs involved, used xpeditor, used traces.  When the 
> first transaction goes to 'exec cics return', there is 
> nothing there.  When the second transaction kicks off, it is. 
>  Any help or pointers on finding this would be greatly appreciated.  

Sounds like there might be a (non-display?) protected field on the screen
with the MDT set (a technique once known as "using the screen for temp
storage").

I can't think of any other way that a just-received TIOA would contain
"baggage".

-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: CSRCTABL pointed by ECVTCTBL

[Mark Zelden]

On Wed, 13 Jul 2005 23:20:26 +1000, ibm-main <[EMAIL PROTECTED]> wrote:

>From: "Mark Zelden"
>>
>> You left out a line of code (not sure why).  x'FF' will also cause
>> problems.
>
>Straight cut-and-paste mate; maybe it's time I refreshed my copy of
IPLINFO.
>

I'd say.  I looked back at a 2002 version that had it in there.  I
know prior to that I had bugs in deciphering the IOVT for the
IODF name etc.  When you run your copy you probably get garbage. JES2
node name is probably garbage also since the offsets at OS/390 2.10
and z/OS 1.4.

BTW, what date is your IPLINFO (see ISPF short msg when you invoke
it on top right - or hit HELP afterwards for ISPF long msg)?

If you want to see all the IPLINFO changes since your version,
open this in your browser and do a find on IPLINFO:

http://home.flash.net/~mzelden/mvsfiles/$$change.txt

Cheers,

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

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

Re: Another - Another One Bites the Dust

[Robin Murray]

It's not that difficult to create a reliable box when it's only running 
one or two static applications. Under those conditions it *better* be 
reliable. otherwise it's a mere toy. A mainframe is a different beast, 
offering many, many diverse applications to thousands of users all on one 
box. I've yet to see unix or windows accomplish the same thing. You have 
to compare apples to apples when talking about reliability.


Robin Murray
Tel: (902) 453-7300 x4177
Cell: (902) 430-0637





David Andrews <[EMAIL PROTECTED]>
Sent by: IBM Mainframe Discussion List 
07/13/2005 09:51 AM
Please respond to IBM Mainframe Discussion List
 
To: IBM-MAIN@BAMA.UA.EDU
cc: 
Subject:Re: Another - Another One Bites the Dust


On Tue, 2005-07-12 at 20:33 -0300, Clark Morris wrote:
> Guess what?  While we may not like it, Sun, HP etc. are reliable
> enough for most things.  There are people in the Unix/Linux world who
> brag about the number of months between reboots.

A point well worth repeating.  A few years ago I had a brochure website
hosted on a HP Netserver running under FreeBSD.  It had two years of
consecutive uptime before we lost power in a planned outage.  (My site
~almost~ made Netcraft's list of longest-running sites on the 'net.  At
the time #100 had 800 or so days of uptime.)

The moral is that even five years ago, with commodity hardware and a
static application, you could have decent reliability.  With failover
capabilities, compartmentalized virtual machines, load balancing and
other goodies, the commodity guys are encroaching upon what was formerly
our territory.

(Not that a properly configured business system made out of commodity
parts is cheaper than one powered by zSeries.  But they have the
advantage of a ridiculously low price to get a foot in the door, an
advantage that P'keepsie doesn't have the will to match.)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Ron and Jenny Hawkins]

Just remember that the same squatty boxes and off-the-shelf hardware are
running most of your DASD subsystems. You bet your company's crown jewels on
Power PC, P/series servers and Motorola microprocessors every day. I think
the up-time for most of your DASD is probably a magnitude better than your
z-boxes!!!

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of William Ball
> Sent: Wednesday, 13 July 2005 6:47 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Another - Another One Bites the Dust
> 
> You're making a leap there that -I'm- certainly not ready to make. Speed
> isn't everything, never has been.
> 
> If you want to play games or have application that you don't really care
> about when it gets done and a lot of times in accurate results and only
> has 1 or 2 users, you -might- be able to live with putting it on a Unix
> platform.
> 
> However, IMHO, the RAS -really- stinks.
> 
> You can't rely on those boxes being up and available to do -production-
> work when you need them.
> 
> One line of bad code or a missing line in a script and the box typically
> goes into a loop and freezes and a lot of the time can't be gotten control
> of again without turning the box off or pulling circuit cards to force it
> to quit.
> 
> The -whole- attitude of the group of people responsible for the care and
> feeding of the squatty boxes is one that a -production- environment in a
> mainframe world can't tolerate. They think nothing of taking a box down or
> changing an IP address in the middle of the day and without telling anyone
> they're about to do it.
> 
> The number of people it takes to support the squatty box environment is
> unreal (5+to 1) for every application they put up.
> 
> It's cheaper to maintain the mainframeoverall.
> 
> The average time for D/R recoverability on a squatty box is measured in
> daysnot hours.
> 
> And the list could go on and on.
> 
> Personally, I'd rather have a -slower- box and know that the RAS is there,
> unless of course I want to play a game. 
> 
> Bill
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Howard Brazee]

On 12-Jul-2005, [EMAIL PROTECTED] (Clark Morris) wrote:

> Guess what?  While we may not like it, Sun, HP etc. are reliable
> enough for most things.

What does "reliable" mean for most people?It means they can do their job
with results they can rely on.


> There are people in the Unix/Linux world who
> brag about the number of months between reboots.

Rebooting rarely has anything to do with whether people can get their reliable
results.   So someone's list of red-headed customers that he wanted on his desk
took another 10 minutes to get.

Sure there are some applications where it is critical to have 100% up time.  
But often "reliability" here can be better improved by putting better radios in
the police car than by upgrading their computers from 99% up to 99.9% up.

In Olden Dayze, a computer going down could cost a day's work.But jobs
recover better nowadays."Reliability" means that if the computer does go
down, when it goes up, it continues working from where it was before.Unix
boxes and databases have learned to do this.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: CSRCTABL pointed by ECVTCTBL

[Edward E. Jaffe]

Mark Zelden wrote:


On Tue, 12 Jul 2005 17:45:00 -0700, Edward E. Jaffe
<[EMAIL PROTECTED]> wrote:

 


FYI. This test is incomplete/erroneous. The valid characters for modern
3270 devices are x'00' and x'40' through x'FE' inclusive. x'01' through
x'3F' and x'FF' will cause PROGxxx failures.

   



Ed, thanks for the clarification (x'00').   What about on real 3270
terminals.  Will x'00' cause a program check?
 



No. From the very beginning, x'00' was defined as the "null" character. 
An input field containing trailing nulls can be shifted right with 
insert. Trailing blanks cannot be shifted. This difference in behavior 
is the reason for the ISPF editor NULLS command. In an output field, 
there is no substantive difference.


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

IEC705I with MEDIA0/MEDIA1 after dsname

[Antonio Cecilio]

Hello,
I'm seeing on tape on msg some media types after dsname that I can't find
the meaning exactly. Example:
IEC705I TAPE ON
3124,G75147,SL,COMP,EMM006XX,IKJEFT01.1000,PCC.FF.EMH006XX,MEDIA
0
IEC705I TAPE ON
3124,G76128,SL,COMP,EMH006XX,IKJEFT01.1000,PCC.FF.EMH006XX,MEDIA
1
On this case there 2 types of media for the same dataset.
The closest thing that I think of is:
"MEDIA1=
 specifies a 2-byte hexadecimal value to be used as the 3490 standard
capacity (CST) scratch category code.
MEDIA2=
 specifies a 2-byte hexadecimal value to be used as the 3490 enhanced
capacity (ECST) scratch category code."

However there's no MEDIA0. Can anyone give me an hint ??
Many thx, Antonio Cecilio

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: ABCs of System Programming Volume 9 UNIX System Services

[Ray Mullins]

Speaking of discounting, don't forget z/TPF.  :-)

-- 
M. Ray Mullins 
Roseville, CA, USA 
http://www.catherdersoftware.com/
http://www.mrmullins.big-bear-city.ca.us/ 
http://www.the-bus-stops-here.org/ 

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John
> Sent: Wednesday 13 July 2005 05:52
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: ABCs of System Programming Volume 9 UNIX System Services
> 
> I think the original poster mean "z/OS is the only 
> MVS-derived operating system for the zSeries". Yeah, I know. 
> That's not what he said. Of course, z/OS people do tend to 
> discount z/VM, z/VSE, and Linux for zSeries. Hum, one could 
> argue that z/VM is not an operating system. It is a 
> hypervisor. You cannot run "applications" on z/VM directly. 
> Unless you can write a "stand alone" application. Note that 
> CMS is not z/VM. It is an operating system which is tightly 
> coupled to z/VM hypervisor facilities.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: IEC705I with MEDIA0/MEDIA1 after dsname

[R.S.]

Antonio Cecilio wrote:


Hello,
I'm seeing on tape on msg some media types after dsname that I can't find
the meaning exactly. Example:
IEC705I TAPE ON
3124,G75147,SL,COMP,EMM006XX,IKJEFT01.1000,PCC.FF.EMH006XX,MEDIA
0
IEC705I TAPE ON
3124,G76128,SL,COMP,EMH006XX,IKJEFT01.1000,PCC.FF.EMH006XX,MEDIA
1
On this case there 2 types of media for the same dataset.
The closest thing that I think of is:
"MEDIA1=
 specifies a 2-byte hexadecimal value to be used as the 3490 standard
capacity (CST) scratch category code.
MEDIA2=
 specifies a 2-byte hexadecimal value to be used as the 3490 enhanced
capacity (ECST) scratch category code."

However there's no MEDIA0. Can anyone give me an hint ??


IMHO that would mean reel tape or undefined type of tape.
MEDIA1-5 (or 1-8) are used for 3494 library in DFSMSdfp (not RMM).
MEDIA1= is used in DEVSUPxx member for 3494 partitioning.

What's you tape mgmt system ? IF RMM then check the volser in RMM - it 
should be CST for MEDIA1 and '*' for reels or undefined.



--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Vintage IBM Mainframe Stuff

[Ed Gould]

On Jul 13, 2005, at 12:20 AM, Brian Knittel wrote:


x29's are still in use today

Whoa! Where's that?


Anywhere punched cards are still used: in ballot counting
operations (probably to create control and identification
cards), aperture card libraries, inventory operations, etc.
They still make blank card stock, and there's at least
one company in Texas that offers service contracts.


Lets not bring CHAD up.. talk about politics.. OS/2 is less sensitive 
(so I have heard).


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: Another - Another One Bites the Dust

[Craddock, Chris]

> It's not that difficult to create a reliable box when it's 
> only running one or two static applications. Under those
> conditions it *better* be reliable. otherwise it's a mere toy.

Reliability is only one part of the equation. It is almost 
trivial to demonstrate that you can build high availability
systems from low reliability parts. It has been done that way 
in many disciplines for decades. It used to be in things like
switching networks, phone systems etc. Now with the widespread
availability of ultra-cheap chips it has made its way into
commodity computing gear. Heck even your car probably has 
redundant systems built into it these days.

> A mainframe is a different beast, offering many, many diverse
> applications to thousands of users all on one box.

Well occasionally that's true. The number of users depends on
the application(s) and the diversity likewise. There is no 
doubt that the ability to manage competing workloads is still
a mainframe unique quality of service - for now. CPU and I/O
performance leadership are no longer mainframe features. We 
lost that title a good while ago and are unlikely to get it
back.

> I've yet to see unix or windows accomplish the same thing.

See Ron Hawkins' last post on this. If you're running modern
disk hardware you're running a fault-tolerant unix application
that is solely responsible for the integrity of your data. You
could be scared about that, or not. But it demonstrably works.

> You have to compare apples to apples when talking about reliability.

Rubbish. Reliability is a "nice to have" feature that costs a 
ton of engineering dollars. Go visit the IBM R&D labs to see 
just how expensive it is to deliver the sort of reliability 
you expect from P and Z series (largely the same people, and
hardware and production line BTW)

Availability is what users perceive and that can be delivered 
a lot less expensively. As long as the user doesn't perceive 
incorrect results or degraded service, (s)he doesn't give a rip
how it is done.

We as a community have to get over the idea that the mainframe
is the only, or even the best way of delivering high availability.
There are lots of other systems that do it quite mundanely every
day. Mainframes have some wonderful features and still have some
technical advantages, but those are rapidly diminishing. Chest
thumping is out of place at this point. It is the ninth inning
and we're behind.

CC

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

Re: IEC705I with MEDIA0/MEDIA1 after dsname

[Antonio Cecilio]

On this case tape mgmt is BMC CTT and the robotic env is STK VSM with STK
SL8500 library.
The example on the original post a dataset is writen over several virtual
tapes using the same virtual drive and it's strange to see the different
values for mediatype.Where does this media type come from??

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[David Andrews]

On Wed, 2005-07-13 at 10:45 -0300, Robin Murray wrote:
> It's not that difficult to create a reliable box when it's only running 
> one or two static applications. Under those conditions it *better* be 
> reliable. otherwise it's a mere toy. A mainframe is a different beast, 
> offering many, many diverse applications to thousands of users all on one 
> box. I've yet to see unix or windows accomplish the same thing. You have 
> to compare apples to apples when talking about reliability.

No, actually, I don't.

I take your point that a single static application is likely to be more
reliable than a diverse collection of evolving applications.  I
stipulated that my two-year uptime was for a limited application on a
dedicated box.  (It's worthwhile mentioning that I'd stripped, hardened,
chroot'ed and firewalled the becrap out of it, too.)

But I can run other single applications on ~their~ own dedicated boxes,
growing my portfolio until I have a cluster of applications taking up a
handful of 19-inch racks.  If one server goes down, the rest stay lit,
so that reduces my business exposure in the event of a failure.

To improve AVAILABILITY, I add failover servers.  My costs dramatically
increase, along with the complexity of the installation, but my users
see the same uptime as they would have with Big Iron in place.

(That might be "thousands of users".  You are aware that Yahoo and
Google run on *nix servers, right?  Lots and lots of them.)

The *nix and commodity hardware crowd knows about RAID and network
attached storage.  They know about failover and transaction recovery.
They know about load balancing.  They know about DBMSs and journaled
filesystems.  They don't have CPU recovery yet (so far as I know), and
they have no equivalent to parallel sysplex.  But they've made
significant strides in the past few years, make no mistake.

"Objects in mirror are closer than they appear."

Hardware costs will continue to decline for the upstarts, as
virtualization becomes more popular.  VMWare works well, and there are
free hacks for Linux such as UML or XEN that allow you to run multiple
kernel images on a single box.

This all leads to laughable, ridiculous startup costs for a new
application prototype.  Sure, by the time you build a mainframe you'll
have spent quite a chunk of lucre, not to mention the staff you need to
manage all those virtual images and NAS devices and ancillary support
structure.  But you can start cheaply, and business loves that.  I might
go to management and propose a million-dollar mainframe implementation
for an important new division, and someone else might go to management
with a hundred-thousand-dollar proposal for a *nix prototype that could
be scaled up over time (at significant cost).  Which proposal do you
think is going to win?  My cheaper-in-the-long-run solution, or my
competitor's cheaper-to-start solution?  Most pointy haired bosses can't
see past the current fiscal year.

My rambling point in all this is that you ~can~ build something
approaching Big Iron availability with today's commodity iron and
Free/Open Source operating systems.  This will cost you big money to do
it right, and it will cost you people (continuing expense for staffing,
office space, training, retraining)... but it ~can~ be done, and it's
falling-over-easy to get a project started.

Yeah, I can compare apples and oranges.

-- 
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: Another - Another One Bites the Dust

[Robin Murray]

[snip]
Reliability is only one part of the equation.
[snip]
Good points, however I was responding to the idea that running a simple 
app on a single box somehow proves that the server boxes are now on par 
with mainframe reliablility, and that's not a logical comparison.


[snip]
> A mainframe is a different beast, offering many, many diverse
> applications to thousands of users all on one box.

Well occasionally that's true. 
[snip]
Not in my experience. It has always been true in every shop I've worked 
in.


[snip]
> I've yet to see unix or windows accomplish the same thing.

See Ron Hawkins' last post on this. If you're running modern
disk hardware you're running a fault-tolerant unix application
[snip]
Again, you can't compare a single purpose application (such as a disk 
array), with a mainframe. Sure, some subsystems are supported by cheap 
chips or os/s, but they are doing a very simple job: exactly what these 
things should be used for.


[snip]
> You have to compare apples to apples when talking about reliability.

Rubbish. Reliability is a "nice to have" feature that costs a ton of 
engineering dollars.
[snip]
I'm not sure where you've been working, but if I told the company 
president here that reliabliltiy was "nice to have" I'd be out on the 
street before I could blink. IBM didn't invent RAS systems to keep 
themselves amused, they did so because their customers demanded it, and 
were willing to pay for it. Both IBM and their customers had to invest 
heavily in this or they'd be out of business.


I'm not going to get into chest thumping over mainframes, this issue has 
been beaten to death. All I'm saying is that today's mainframes, 
technically, are still ahead in terms of ras when you consider all they 
are able to take on and the number of concurrent users they are able to 
support. The day that it becomes commonplace for, say, three unix servers 
to be able to support the entire IT production environment for a large 
company, and do so reliably, I'll concede the point.


Robin Murray
Tel: (902) 453-7300 x4177
Cell: (902) 430-0637

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[ibm-main]

> IBM didn't invent RAS systems to keep
> themselves amused, they did so because their customers demanded it, and
> were willing to pay for it. Both IBM and their customers had to invest
> heavily in this or they'd be out of business.

I really have to say that these days the almighty dollar seems to win all
the arguements.
I don't know that either is prepared to spend the bucks these days.
IBM is offloading jobs to cheaper locales, and customers are voting with
their feet.

I'd love to keep doing this job, and preferably earn oodles of money doing
it.
But the pond is shrinking all the time.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another one bites the dust

[john gilmore]

Chris Craddock writes:



We as a community have to get over the idea that the mainframe is the only, 
or even the best way of delivering high availability.  There are lots of 
other systems that do it quite mundanely every day. Mainframes have some 
wonderful features and still have some technical advantages, but those are 
rapidly diminishing. Chest thumping is out of place at this point. It is 
the ninth inning > and we're behind.




This recurrent theme in his posts, that self-satisfied noises are at nest 
fatuouis, is one with which I entirely agree.  That said, it is also worth 
saying that the alternatives to z/OS MVS are still radically immature ones.


Used knowledgeably, MVS can provide much better reliability and availability 
than UNIX, LINUX, et al.  (It can also provide much better CONCURRENT 
high-volume I/O, but that is another topic.)


The chief problems associated with legacy systems stem from the fact that 
they seldom employ this technology.


Few---I had almost written non---of the legacy systems that I examine make 
any explicit use of technololgy that was not available 30 years ago.  These 
systems, the ones I see anyway, are move-orient[at]ed, compile-time bound, 
and synchronous.  They seldom exhibit much explicit design.  Like Topsy, 
they have just grow'd.


Arguments for their in situ modernization and/or replacement are rejected as 
uneconomic in the usual crackpot-realist terms.


Etc., etc.  Thiks litany could unfortunately be continued ad infinitum et 
nauseam; and the at best obsolescent technology that continues to be used to 
maintain MVS applications is digging the mainframe's grave.  Not the 
mainframe burt the people who willfully omit to use the facilities it makes 
available are the problem.


Morerover, and this is particularly melanchoily, there is much anecdotal and 
some systematic evidence thast many applications that are 'successfully' 
moved to other platforms take their disabilities with them.



John Gilmore
Ashland, MA 01721
USA

_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


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

What IF?

[Paul Gilmartin]

OK; who can answer the following:

o without reading the manual or testing

o with reading the manual only, and no testing:

What does the following job do:

//IFJOB  etc.
//*
//  IF ( FALSE ) THEN
//B  EXEC PGM=IEFBR14
//  ELSE
//C  EXEC PGM=IEFBR14
//  ENDIF

o Both steps B and C flush?
o Step B runs; step C flushes?
o Step B flushes; step C runs?
o Both steps B and C run?

Same set of questions for the following:

//IFJOB  etc.
//*
//  IF ( TRUE  ) THEN
//B  EXEC PGM=IEFBR14
//  ELSE
//C  EXEC PGM=IEFBR14
//  ENDIF

And similarly for:

//IFJOB  etc.
//*
//  IF ( FALSE ) THEN
//A  EXEC PGM=IEFBR14
//B  EXEC PGM=IEFBR14
//  ELSE
//C  EXEC PGM=IEFBR14
//  ENDIF

Why?

(Sorry to waste so much resource with all  those IEFBR14s.)

-- 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: What IF?

[R.S.]

No book, no testing.

First job
Both steps will run (and end with RC=0).
Step B - because it is first step (no step A); first step runs 
regardless of conditions.
Step C (second one) will run because it is "ELSE step" and condition was 
false (I don't know how to express it in English).

Shall I explain RC=0 with IEFBR14 ? 

Second job
Now it's easy: B run, C flush.
Reasons are described above, now the condition is true.

Third job
A - run, first step always run
B - not run, condition not met (false)
C - run, see first job

OK, now my question: Do the words TRUE and FALSE really work ?
I don't remember...

--
Radoslaw Skorupka
Lodz, Poland


Paul Gilmartin wrote:


OK; who can answer the following:

o without reading the manual or testing

o with reading the manual only, and no testing:

What does the following job do:

//IFJOB  etc.
//*
//  IF ( FALSE ) THEN
//B  EXEC PGM=IEFBR14
//  ELSE
//C  EXEC PGM=IEFBR14
//  ENDIF

o Both steps B and C flush?
o Step B runs; step C flushes?
o Step B flushes; step C runs?
o Both steps B and C run?

Same set of questions for the following:

//IFJOB  etc.
//*
//  IF ( TRUE  ) THEN
//B  EXEC PGM=IEFBR14
//  ELSE
//C  EXEC PGM=IEFBR14
//  ENDIF

And similarly for:

//IFJOB  etc.
//*
//  IF ( FALSE ) THEN
//A  EXEC PGM=IEFBR14
//B  EXEC PGM=IEFBR14
//  ELSE
//C  EXEC PGM=IEFBR14
//  ENDIF

Why?

(Sorry to waste so much resource with all  those IEFBR14s.)

-- gil


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

Re: IBM VSAM Statistics are often Bogus

[Skip Robinson]

Please forgive me if this is old news. OA11927 was PE'ed on 7/11 . This is
the guy that set out to 'restore' the bogus stats in LISTCAT so that
programs expecting numeric data would not blow up S0C7; the stats would be
marked invalid in some other field. Unfortunately, OA11927 somehow mixed up
the conditions at the 1.4 and 1.5 levels (1G0 and 1H0) and reported on
validity in the opposite way. Good is bad; bad is good. A philosophical and
ethical conundrum if ever there was one. The 1.6 (1J0) level is OK,
however.

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

IBM Mainframe Discussion List  wrote on 07/02/2005
09:59:57:


>
> Anyhow, I only learned of OA11927 in this thread. Good decision. I
haven't
> seen the modified output but will install the fix ASAP. Sure hope I don't
> have to beat up on Serena again right after they finally fixed the
INVALID
> problem. ;-)
>

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

SMPE 3.3 Information.

[Howard Rifkind]

Hello all,
 
I'm thinking of installing SMPE 3.3 because the SMPE version which is now on 
the system is so down leveled that it just doesn't pay to try to update it with 
PTF's.
 
I saw in some documentation that there were some catches and incompatiblities 
as indicate below:
 

CAUTION - Use of SMP/E commands other than the RECEIVE command

after installing either the target library or FMID version of

SMP/E may result in SMPCSI entries that are not compatible with..

lower levels of SMP/E that may currently be installed on your ..

system.

If any one out there has gone through this can you please advise as to what is 
the most important things to do.

Thanks.

 

 



-
 Start your day with Yahoo! - make it your home page 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: what IF?

[john gilmore]

Pauyl Gilmartin has asked for conjectures about what such JCL constructs as

//  IF ( FALSE ) THEN
//B  EXEC PGM=IEFBR14
//  ELSE
//C  EXEC PGM=IEFBR14
//  ENDIF

The first thing toi be said about this construct and its brethren in Paul's 
post is that they are ridiculous..  The parentheses are gratuitous in the 
sense that the expressions


//  IF ABEND
//  IF (ABEND)
//  IF ABEND=TRUE
//  IF (ABEND=TRUE)

The constructs

//  IF ABEND=TRUE THEN
//  IF ABEND=FALSE THEN

were presumably introduced for the delectation of COBOL programmers who know 
no Boolean algebra and thus find the constructs


//  IF ABEND THEN
//  IF NOT(ABEND)

too terse.
.  As such they are, I suppose, innocuous; but their use by anyone of even 
modest technical competence would be unwise.  It would mark them as 
uninformed or worse.


What then does or could

//IF (FALSE) THEN . . .

mean?

My conjecture must be uninformed, because it would never have occurred to me 
to write such a JCL statement, but I will hazard the guesses that


o  '//  IF FALSE THEN' is a contradiction that is always false, and

o  '// IF TRUE THEN' is a tautology that is always true.

If these guesses, which I have refrained from attempting to verify, are 
correct


o JCL following the first would not be executed and the JCL following its 
associated THEN would

  be executed if present; and

o JCL following the second would be executed and the JCL following its 
associated THEN would be

  ignored if present.

John Gilmore
Ashland, MA 01721
USA

_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: What IF?

[Greg Shirey]

Isn't this essentially the same thing you asked a few months ago? 

http://bama.ua.edu/cgi-bin/wa?A2=ind0412&L=ibm-main&P=R50040&I=1

Has something changed since then?

Greg

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Paul Gilmartin
Sent: Wednesday, July 13, 2005 11:16 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: What IF?


OK; who can answer the following:

o without reading the manual or testing

o with reading the manual only, and no testing:

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: What IF?

[Joel Ivey]

1st job, C runs
2nd job, C runs
3rd job, C runs

no book, no testing, rarely use IFs, just a suspicion that the value is null.


On Wed, 13 Jul 2005 10:16:22 -0600, Paul Gilmartin <[EMAIL PROTECTED]>
wrote:

>OK; who can answer the following:
>
>o without reading the manual or testing
>
>o with reading the manual only, and no testing:
>
>What does the following job do:
>
>//IFJOB  etc.
>//*
>//  IF ( FALSE ) THEN
>//B  EXEC PGM=IEFBR14
>//  ELSE
>//C  EXEC PGM=IEFBR14
>//  ENDIF
>
>o Both steps B and C flush?
>o Step B runs; step C flushes?
>o Step B flushes; step C runs?
>o Both steps B and C run?
>
>Same set of questions for the following:
>
>//IFJOB  etc.
>//*
>//  IF ( TRUE  ) THEN
>//B  EXEC PGM=IEFBR14
>//  ELSE
>//C  EXEC PGM=IEFBR14
>//  ENDIF
>
>And similarly for:
>
>//IFJOB  etc.
>//*
>//  IF ( FALSE ) THEN
>//A  EXEC PGM=IEFBR14
>//B  EXEC PGM=IEFBR14
>//  ELSE
>//C  EXEC PGM=IEFBR14
>//  ENDIF
>
>Why?
>
>(Sorry to waste so much resource with all  those IEFBR14s.)
>
>-- 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: What IF?

[Mark Zelden]

>What does the following job do:
>


Didn't we recently go through this exercise?

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

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

Re: IBM VSAM Statistics are often Bogus

[Tim Hare]

SO, Skip,   are you saying 1.6 is bad ("good is bad, bad is good") or 1.6 
is good? But then, I just used "bad" when I meant "bad" but "bad is good" 
so did I mean "good"? 
I certainly meant well. 

Tim Hare
Senior Systems Programmer
Florida Department of Transportation
(850) 414-4209

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: TIOA problem

[Carroll, William]

Thank you John...that was it.

-Original Message-
From: Chase, John [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 13, 2005 9:38 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: TIOA problem


> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Carroll, William
> 
>   I have a transaction that does a 'receive' for when it 
> begins execution.  All transactions in this region go through 
> a single program, then are xctl'd to the other programs.  In 
> 1 transaction only, the tioa somehow is always getting the 
> same string added.  When the router type program sees this, 
> he sends the transaction on a different path.  I have dumped 
> the programs involved, used xpeditor, used traces.  When the 
> first transaction goes to 'exec cics return', there is 
> nothing there.  When the second transaction kicks off, it is. 
>  Any help or pointers on finding this would be greatly appreciated.  

Sounds like there might be a (non-display?) protected field on the screen
with the MDT set (a technique once known as "using the screen for temp
storage").

I can't think of any other way that a just-received TIOA would contain
"baggage".

-jc-

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

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

Re: Another - Another One Bites the Dust

[Craddock, Chris]

> [snip]
> Reliability is only one part of the equation.
> [snip]
> Good points, however I was responding to the idea that 
> running a simple app on a single box somehow proves that
> the server boxes are now on par with mainframe reliablility,
> and that's not a logical comparison.

Sure its a valid comparison. The only thing a user cares about
is the result. They might have a bit of tourist curiosity, but 
as long as they get their job done on time, they generally don't
care HOW it gets done. So if it takes two or more redundant (but
very cheap) boxes to do the job of a single (much more expensive)
mainframe the user probably doesn't care. Moreover, the business
may actually prefer the lower price, even if it comes at the cost
of a bit more operational complexity. 
 
> [snip]
> > I've yet to see unix or windows accomplish the same thing.
> 
> See Ron Hawkins' last post on this. If you're running modern
> disk hardware you're running a fault-tolerant unix application
> [snip]
> Again, you can't compare a single purpose application (such as
> a disk array), with a mainframe. Sure, some subsystems are supported 
> by cheap chips or os/s, but they are doing a very simple job:
> exactly what these things should be used for.

Actually, I -can- compare these things quite usefully. You appear 
to have an inherent preference for running all of these things on
the same box at the same time. That's ok, but you should recognize
it as a preference only. If the same thing can be accomplished more
cost effectively, or more reliably, by some other approach, then
who's to say the other approach is wrong?

> [snip]
> Rubbish. Reliability is a "nice to have" feature that costs a ton of 
> engineering dollars.
> [snip]
> I'm not sure where you've been working, but if I told the company 
> president here that reliabliltiy was "nice to have" I'd be out on the 
> street before I could blink. IBM didn't invent RAS systems to keep 
> themselves amused, they did so because their customers demanded it,
> and were willing to pay for it. Both IBM and their customers had 
> to invest heavily in this or they'd be out of business.

You're missing the point entirely. High AVAILABILITY is a "gotta have
it" business requirement (or not - see below) but there are many ways
of accomplishing that. Availability is the probability that a system
can do work when you want it to and that's MTBF/(MTBF+MTTR) It costs
a lot to make MTBF LARGE for every last component. Depending on design,
you might be more successful by simply making MTTR small. Then if you
factor in the availability of redundant components, you find that you
can get very high overall AVAILABILITY from very low RELIABILITY 
components. I'm not making this up, its just the way it is.

You also should consider the origins of the drive for reliability.
Back in the day, customers typically had just one system. And if 
it was down, so were they. Nobody in their right mind would pay 
the cost of duplicating the resources of that single system even
if the software supported it, which it generally did not. 

So... the only choice was to make every element of the system as
reliable as could be - and that's one of the reasons the platform
has stayed as expensive (raw $$$, not cost/function) as it has.

The engineering that goes into these systems is staggering. But
while the engineering drive for ultimate reliability continues, 
the (mainframe) systems today are increasingly made up of cheap
commodity parts. The memory subsystem has pipelined access and
chip kill and multibit ECC, but its made of cheap and cheerful 
memory chips not unlike those in your own PC.

Now in the brave new world where chips cost pennies, the most
cost effective solution is usually to provide multiple levels of
redundancy. That's entirely different in concept. Instead of having
one big thumper sitting in the corner being a single point of 
failure, you have many equivalent servers and no single point of
failure. That's the mantra for sysplex and for the distributed 
systems too. 

So in fact, as I said earlier. Reliability -is- nice to have. But
you can have high business availability without it. Now to return
to that issue, take a long hard look at the real numbers and the
results are not pretty. z/OS availability, as experienced by most
of our brethren, is nothing to write home about. See all of the 
past threads about IPL frequency for verification. 

Its not that the system isn't capable of continuous operation (IT 
IS!!!) but evidently a wide majority of customers don't actually
trust it to be as reliable as it is. Getting the benefits of the
latest technology takes a fundamental shift in mindset as well as
a shift in configuration. If you keep running your mainframe 
systems and applications in towers the same as they were "back in
the day" then frankly, they are considerably less reliable/available
as off the shelf solutions with other platforms. Sorry if that is
bursting some bubbles, but that's just the way

Re: Open MVS question

[Marian Gasparovic]

Radoslaw, thank you for correcting me, I haven't used that syntax for
couple of months.
M.

On 7/13/05, R.S. <[EMAIL PROTECTED]> wrote:
> Marian Gasparovic wrote:
> 
> > Bruce, there is syntax for accessing MVS dataset from Unix System
> > Service, name would look something like
> >
> > cp "\\'mvs_dataset_name'" unixfile
> >
> > but I don't remember exactly. Search archives or consult USS documentation.
> 
> cp //mvs.name
> slash, not backslash.
> 
> However only few of USS commands/utilities support MVS datasets.
> USS Command Reference clearly mentions the names:
> cp
> mv
> pax
> tar
> c89
> 
> Caution: the above list is for z/OS V1R4.
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
>

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

Asynchronous handling of I/O to logstream

[John Krew]

We are currently trying to record CDC information from within the data capture 
exit (DFSFLGX0) in
our IMS database, by (synchronously) writing the data capture log records to a 
logstream.  This is
still in a development phase, but it is already obvious to us that we have a 
potential performance
bottleneck on our hands.  One possibilility would be to capture changed data at 
log-archival time in
a separate batch process (not via the exit), but our preference is to be able 
to "stream" the CDC on
a near-real-time basis if we can swing it.

We are trying to decide if we want to attach a sub-task within the IMS address 
space to periodically
write those log records asynchronously to the logstream (after they have been 
saved in a memory
buffer by the exit), or if we should set up a service provider in a separate 
address space that
would write out the records passed to it by the exit via cross memory services 
(PC-ss routine).  And
if we are already going to the trouble of setting up our own service provider, 
would the logstream
be superfluous or unnecessarily expensive in resources, and writing to our own 
dataset (sequential
or maybe an LDS?) be preferable?

Anybody want to venture any thoughts on which method would be the way to go?  
Or maybe suggest a
third alternative?

John Krew

(P.S. My apologies to language purists who claim that, etymologically speaking, 
there cannot be more
than one alternative.
I have noticed that you have to be careful how you write on this list .  )

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

HSM using 3592.

[Frank Alequin]

Hello Everyone,

We are about to implement the use of 3592 with HSM but we do not know how
HSM is going to handle them exactly.

We are going to use them for the full volume dump process and will be
specifying STACK(99). That is were my question comes up, is this option
going to stack only 99 dumps or is it going to use the maximum space in
the device.

In other words does STACK(99) mean stack up to 99 or nolimit(maximum).

We dump aprox. 475 volume per week.

Thank you and have a nice day.

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

Re: DB2 and flashcopy2

[Hal Merritt]

What about the work in progress in DB2 buffers that is not yet committed
(flushed) to DASD? The I/O might be consistent, but how would the data?

I would follow the suggestions in the DB2 doc rather than the hardware. 

Also, there is ample discussion in many recovery Redbooks that discuss
the 'Point of Consistency' concepts and issues. 

Only the Lone Ranger has Silver Bullets. 

My US$0.02 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Yi Ming
Sent: Tuesday, July 12, 2005 5:31 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DB2 and flashcopy2

Yup by quisce I mean DB2 "SET LOG SUSPEND" command to temporary
suspend insert/update/delete activities.

Looks like with Flashcopy v2 Freeze FlashCopy Consistency Group option,
this
is no longer necessary, the end results is still the same. Since DB2
won't
be able to do any insert/update/delete activities as ESS will hold off
I/O
activity to a volume for a time period by putting the source volume in
extended long busy state to obtain a consistent point-in-time copy of
the
related volume. But this makes for simpler PIT back operational
procedures
when backing up DB2.

Regards,
Yi Ming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: CSRCTABL pointed by ECVTCTBL

[Ray Mullins]

A little word of warning...

Mark, I ass/u/me that your change is for IPLINFO.  You're using I as the
loop control variable - which Shane is using for his outer loop in his
ECVTCTBL REXX.

So, if you do something stupid like I did, and paste the code below into
Shane's REXX, you'll wind up with a wonderful, almost IEFBR15-like, effect.

(Shane's using J for his loop variable.)

Later,
Ray

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Mark Zelden
Sent: Wednesday July 13 2005 06:38
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: CSRCTABL pointed by ECVTCTBL

On Tue, 12 Jul 2005 17:45:00 -0700, Edward E. Jaffe
<[EMAIL PROTECTED]> wrote:


>
>FYI. This test is incomplete/erroneous. The valid characters for modern 
>3270 devices are x'00' and x'40' through x'FE' inclusive. x'01' through 
>x'3F' and x'FF' will cause PROGxxx failures.
>

Ed, thanks for the clarification (x'00').   What about on real 3270
terminals.  Will x'00' cause a program check?

At any rate... here is the slight modification to the REXX code so it is not
erroneous:

XLATE_NONDISP:   /* translate non-display characters to a "."*/
Arg XLATEPRM
XLATELEN = Length(XLATEPRM) /* length of parm passed to routine  */
Do I = 1 to XLATELEN  /* check each byte for */
  If (Substr(XLATEPRM,I,1) > '00'x & ,/* non-display characters  */
Substr(XLATEPRM,I,1) < '40'x ) | ,/* and replace each*/
Substr(XLATEPRM,I,1) = 'FF'x  then ,  /* character that  */
XLATEPRM = OVERLAY('.',XLATEPRM,I)/* is non-displayable  */
End   /* with a period (.)   */
Return XLATEPRM

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

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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 Secure Implicit port 990 timeout

[Hal Merritt]

Sounds like that scam in a recent CERT advisory. 

Really nasty payload. It is reported to be crafted to get around the
virus checkers and firewalls. 




-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mendelson, Eric
Sent: Friday, July 08, 2005 7:46 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: FTP Secure Implicit port 990 timeout

Welcome to Secure Messaging by Kryptiq.

You have received a secure message from Mendelson, Eric
[EMAIL PROTECTED]
To retrieve this message please click on the link below.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Welch, Mp P [ITS]]

We've seen that many of our midrange projects end up costing much more
than the mainframe solution they replaced.

The problem we've seen is that its usually too late to bring the
application back after it migrates regardless of how much more expensive
it becomes.

If you look at your numbers, you may find the "much more expensive"
mainframe wasn't so expensive after all.

Even if the perception that the mainframe is too expensive turns out to
be true after reviewing all of the cost factors, there are ways to
reduce many of the cost factors and keep the mainframe infrastructure
cost effective.

We've seen IBM give us ridiculously high MIP estimates for new mainframe
projects as Norris had mentioned, and CEC based software contracts have
caused unnecessarily high cpu upgrade costs, but we still feel that our
mainframe environment (with proper financial care and feeding) continues
to provide significant contribution to IT value at our company.

Maybe someday alternative non-mainframe computing will be best for all
our work but if we can wait a little longer those solutions will only be
better (cheaper?) next year...

Mp Welch
Sprint
214-215-7284

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Craddock, Chris
Sent: Wednesday, July 13, 2005 1:14 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Another - Another One Bites the Dust

> [snip]
> Reliability is only one part of the equation.
> [snip]
> Good points, however I was responding to the idea that running a 
> simple app on a single box somehow proves that the server boxes are 
> now on par with mainframe reliablility, and that's not a logical 
> comparison.

Sure its a valid comparison. The only thing a user cares about is the
result. They might have a bit of tourist curiosity, but as long as they
get their job done on time, they generally don't care HOW it gets done.
So if it takes two or more redundant (but very cheap) boxes to do the
job of a single (much more expensive) mainframe the user probably
doesn't care. Moreover, the business may actually prefer the lower
price, even if it comes at the cost of a bit more operational
complexity. 
 

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

Re: Help needed with ICSF

[Hal Merritt]

There are some hardware patches for the z/890 box that may apply. Not clear 
about details, but something to do with an unexpected return code when a field 
is padded with blanks. 

HTH and good luck.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of De 
La Fuente Seivane, Victor
Sent: Tuesday, July 12, 2005 6:54 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Help needed with ICSF

Hi all!
I'm hard fighting with ICSF. I'm writing a program where I try to use
CSNDSYI function, but I always get RTC=8 and RSC=11000. It means that there
is a length parameter wrong. I couldn't find it; I can't imagine which of
the three length parameters could be wrong.
 
I tried to find more information, with no success. Could anyone show me the
correct way? Just some hints on which could be the mistake!
 
Thank you very much!
 
Best regards!
 Víctor de la Fuente Seivane
 

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

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

Re: How constant is the CPU time

[Hal Merritt]

The rule of thumb was +/- 20% at one time. 

HTH and good luck.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Miklos Szigetvari
Sent: Tuesday, July 12, 2005 1:15 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: How constant is the CPU time

Hi

How constant is the CPU time, depend on system  load etc. for a given 
application ?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Ron and Jenny Hawkins]

> 
> > The day that it becomes commonplace for, say, three unix servers
> > to be able to support the entire IT production environment
> > for a large company, and do so reliably, I'll concede the point.
> 

Hmm, how about most of the largest Telcos in Asia, the largest airlines in
Asia, and a 270TB Credit Card Authorisation company, to name a few. 

What do the core applications in NASDAQ run on?

Most of the Unix sites I work in running large, partitioned Servers from
IBM, SUN and HP seem to be much, much larger than many of the sites
discussed on this list - and I'm talking transaction volume and customers,
not just TB.

And of course the very high availability applications aren't on MVS at all -
they are running on Stratus and Tandem (HP), right?

Then there is technology like Engenera and VMware, or simple bladeservers at
the low end that make many single application, clustered servers a low cost
reality. One customer has 240 servers running on Bladeservers in a pair of
19" cabinets connected to storage using iSCSI. MVS with all its WLM
automated knob twirling would not be able to give the same combined level of
RAS or TCO for these 240 applications. And these are servers, so even if
there is just an average of 5 concurrent users per application we are
talking 1200 users.

Ron

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Robin Murray]

[snip]
Sure its a valid comparison. The only thing a user cares about
is the result. They might have a bit of tourist curiosity, but 
as long as they get their job done on time, they generally don't
care HOW it gets done. So if it takes two or more redundant (but
very cheap) boxes to do the job of a single (much more expensive)
mainframe the user probably doesn't care. Moreover, the business
may actually prefer the lower price, even if it comes at the cost
of a bit more operational complexity. 
[snip]

We are wondering wide of my original point, but I hardly think you can 
replace a mainframe with two very cheap boxes. In our small shop here, we 
have 200-300 servers that need to be supported, and we *still* have a 
mainframe doing most of the bread-and-butter business. And I feel you are 
being disingenuous when you say "a bit more operational complexity". From 
my experience, adding truckloads of servers creates a lot more complexity, 
a lot more support staff, and a very convoluted, doubtful disaster 
recovery.

I realize there is an industry wide push to recentralize servers, but I 
have not seen this done in practise yet in my neck of the woods.

[snip]
Actually, I -can- compare these things quite usefully. You appear 
to have an inherent preference for running all of these things on
the same box at the same time. That's ok, but you should recognize
it as a preference only. If the same thing can be accomplished more
cost effectively, or more reliably, by some other approach, then
who's to say the other approach is wrong?
[snip]

My original point was you can't compare a single-purpose box's reliability 
with that of a mainframe and get a fair comparison. This is a very narrow 
point, regardless of what the user sees and platform costs and whatnot. 
You're looking at a wider picture here.

I have always believed that the idea of having many hundreds of servers is 
ridiculous, that processing should be centralized to give you better 
control, easier disaster recovery, and fewer support staff. But that's 
another kettle of fish. I actually agree with your interesting arguments 
up to a point, I'm not going to try to refute them.

Any computing platform that is used by business to make money must be: 
reliable, easy to recover in a disaster, easy to maintain and debug, and 
deliver these things inexpensively with as few support staff as possible. 
In many cases it will make sense to run the business on a bunch of 
servers, but for large business I still feel the mainframe is the only 
platform that can deliver, despite its over inflated software costs. 
Perhaps in the next few years, if servers are consolidated sufficiently to 
a more managable level, they will be able to take over, but I don't think 
they've arrived yet. Certainly not around here anyway.

If you are delivering mega-tons of grain over long distances to few 
destinations, it's better, and cheaper in the long run, to use a couple of 
mile-long freight trains, despite their high initial cost. If you are 
delivering thousands of envelopes to many destinations, it's better to 
have a fleet of chevettes. Each approach is correct for the product. What 
I inherantly disagree with is putting a few shovel fulls of grain in the 
trunks of thirty thousand chevettes, and saying that that's somehow better 
than using the train. Damn the cost, it just ain't right. 


Robin Murray
Tel: (902) 453-7300 x4177
Cell: (902) 430-0637

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Ron and Jenny Hawkins]

Hands up all of you that have successfully migrated your SAS/MXG
applications from MVS to Windows and saved money. 

Hands up those of you that believe it is now costing more?

The MXG PDB is a classic example of an application that can be successfully
moved from mainframe to a windows or Unix and provide a better TCO along
with improved performance, function and productivity. 

In fact, if I was asked to develop an MXG PDB from scratch for a site I
wouldn't even consider using MVS. A reasonable server class desktop, with XP
Professional and some FC connections to SAN storage would be a better and
cheaper way to go in almost all cases.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Welch, Mp P [ITS]
> Sent: Thursday, 14 July 2005 3:48 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Another - Another One Bites the Dust
> 
> We've seen that many of our midrange projects end up costing much more
> than the mainframe solution they replaced.
> 
> The problem we've seen is that its usually too late to bring the
> application back after it migrates regardless of how much more expensive
> it becomes.
> 
> If you look at your numbers, you may find the "much more expensive"
> mainframe wasn't so expensive after all.
> 
> Even if the perception that the mainframe is too expensive turns out to
> be true after reviewing all of the cost factors, there are ways to
> reduce many of the cost factors and keep the mainframe infrastructure
> cost effective.
> 
> We've seen IBM give us ridiculously high MIP estimates for new mainframe
> projects as Norris had mentioned, and CEC based software contracts have
> caused unnecessarily high cpu upgrade costs, but we still feel that our
> mainframe environment (with proper financial care and feeding) continues
> to provide significant contribution to IT value at our company.
> 
> Maybe someday alternative non-mainframe computing will be best for all
> our work but if we can wait a little longer those solutions will only be
> better (cheaper?) next year...
> 
> Mp Welch
> Sprint
> 214-215-7284
> 

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

Delete Conformation

[Howard Rifkind]

I have a user who turned off the conformation delete notification in ISPF 
option 3.4.
 
How can I get it turned back of for him?
 
Thanks.


-
 Start your day with Yahoo! - make it your home page 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Robin Murray]

...and hands up all those who have converted a large, many faceted 
application off the mainframe only to see your TCO go up. I know of a 
company (not naming names) who just put their mainframe-to-server 
conversion on hold when it was revealed that the next stage of their 
conversion would be many millions of bucks.

Some things make sense for the mainframe, some things make sense for the 
servers. Creating an MXG PDB is perfect for a server - it's a pretty 
straight forward, self contained process.


Robin Murray
Tel: (902) 453-7300 x4177
Cell: (902) 430-0637





Ron and Jenny Hawkins <[EMAIL PROTECTED]>
Sent by: IBM Mainframe Discussion List 
07/13/2005 05:13 PM
Please respond to IBM Mainframe Discussion List
 
To: IBM-MAIN@BAMA.UA.EDU
cc: 
Subject:Re: Another - Another One Bites the Dust


Hands up all of you that have successfully migrated your SAS/MXG
applications from MVS to Windows and saved money. 

Hands up those of you that believe it is now costing more?

The MXG PDB is a classic example of an application that can be 
successfully
moved from mainframe to a windows or Unix and provide a better TCO along
with improved performance, function and productivity. 

In fact, if I was asked to develop an MXG PDB from scratch for a site I
wouldn't even consider using MVS. A reasonable server class desktop, with 
XP
Professional and some FC connections to SAN storage would be a better and
cheaper way to go in almost all cases.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Welch, Mp P [ITS]
> Sent: Thursday, 14 July 2005 3:48 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Another - Another One Bites the Dust
> 
> We've seen that many of our midrange projects end up costing much more
> than the mainframe solution they replaced.
> 
> The problem we've seen is that its usually too late to bring the
> application back after it migrates regardless of how much more expensive
> it becomes.
> 
> If you look at your numbers, you may find the "much more expensive"
> mainframe wasn't so expensive after all.
> 
> Even if the perception that the mainframe is too expensive turns out to
> be true after reviewing all of the cost factors, there are ways to
> reduce many of the cost factors and keep the mainframe infrastructure
> cost effective.
> 
> We've seen IBM give us ridiculously high MIP estimates for new mainframe
> projects as Norris had mentioned, and CEC based software contracts have
> caused unnecessarily high cpu upgrade costs, but we still feel that our
> mainframe environment (with proper financial care and feeding) continues
> to provide significant contribution to IT value at our company.
> 
> Maybe someday alternative non-mainframe computing will be best for all
> our work but if we can wait a little longer those solutions will only be
> better (cheaper?) next year...
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Delete Conformation

[La, Ann]

Have the user to to 3.4 and make sure the following has been selected:

Initial View . . . 1  1. Volume   Enter "/" to select option
  2. Space/  Confirm Data Set Delete
  3. Attrib   /  Confirm Member Delete  
  4. Total/  Include Additional Qualifiers  
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Howard Rifkind
Sent: Wednesday, July 13, 2005 3:22 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Delete Conformation


I have a user who turned off the conformation delete notification in ISPF 
option 3.4.
 
How can I get it turned back of for him?
 
Thanks.


-
 Start your day with Yahoo! - make it your home page 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Delete Conformation

[Howard Rifkind]

Thanks Ann, boy do look stupid.

"La, Ann" <[EMAIL PROTECTED]> wrote:Have the user to to 3.4 and make sure the 
following has been selected:

Initial View . . . 1 1. Volume Enter "/" to select option 
2. Space / Confirm Data Set Delete 
3. Attrib / Confirm Member Delete 
4. Total / Include Additional Qualifiers 
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Howard Rifkind
Sent: Wednesday, July 13, 2005 3:22 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Delete Conformation


I have a user who turned off the conformation delete notification in ISPF 
option 3.4.

How can I get it turned back of for him?

Thanks.


-
Start your day with Yahoo! - make it your home page 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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



-
 Start your day with Yahoo! - make it your home page 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Robin Murray]

If they are indeed doing a better job than what a mainframe can do 
regarding the number of support staff, disaster recovery, ease of 
maintenance and debuggability, then I would indeed concede the point. Have 
you investigated these areas? Or are they just running unix because "it's 
cheaper than a mainframe"?

Robin Murray
Tel: (902) 453-7300 x4177
Cell: (902) 430-0637





Ron and Jenny Hawkins <[EMAIL PROTECTED]>
Sent by: IBM Mainframe Discussion List 
07/13/2005 05:03 PM
Please respond to IBM Mainframe Discussion List
 
To: IBM-MAIN@BAMA.UA.EDU
cc: 
Subject:Re: Another - Another One Bites the Dust


> 
> > The day that it becomes commonplace for, say, three unix servers
> > to be able to support the entire IT production environment
> > for a large company, and do so reliably, I'll concede the point.
> 

Hmm, how about most of the largest Telcos in Asia, the largest airlines in
Asia, and a 270TB Credit Card Authorisation company, to name a few. 

What do the core applications in NASDAQ run on?

Most of the Unix sites I work in running large, partitioned Servers from
IBM, SUN and HP seem to be much, much larger than many of the sites
discussed on this list - and I'm talking transaction volume and customers,
not just TB.

And of course the very high availability applications aren't on MVS at all 
-
they are running on Stratus and Tandem (HP), right?

Then there is technology like Engenera and VMware, or simple bladeservers 
at
the low end that make many single application, clustered servers a low 
cost
reality. One customer has 240 servers running on Bladeservers in a pair of
19" cabinets connected to storage using iSCSI. MVS with all its WLM
automated knob twirling would not be able to give the same combined level 
of
RAS or TCO for these 240 applications. And these are servers, so even if
there is just an average of 5 concurrent users per application we are
talking 1200 users.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Hal Merritt]

Looked at that solution a few years ago. Of course, the root problem is
SAS trying to put itself out of business.  

Even so, the difficulty in automating and scheduling the process added a
lot of human intervention. Human beans ain't cheap. 

For a scenario where MXG was used for research and ad hoc, then, yes,
hands down a winner.

But for situations where MXG actually generated and distributed reports
to a number of people, I am not so sure. 

My $0.02, and there have been a few trivial technology advances in the
last decade or so ;-) 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ron and Jenny Hawkins
Sent: Wednesday, July 13, 2005 3:13 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Another - Another One Bites the Dust

Hands up all of you that have successfully migrated your SAS/MXG
applications from MVS to Windows and saved money. 

Hands up those of you that believe it is now costing more?

The MXG PDB is a classic example of an application that can be
successfully
moved from mainframe to a windows or Unix and provide a better TCO along
with improved performance, function and productivity. 

In fact, if I was asked to develop an MXG PDB from scratch for a site I
wouldn't even consider using MVS. A reasonable server class desktop,
with XP
Professional and some FC connections to SAN storage would be a better
and
cheaper way to go in almost all cases.

Ron

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: CSRCTABL pointed by ECVTCTBL

[Mark Zelden]

On Wed, 13 Jul 2005 12:50:37 -0700, Ray Mullins <[EMAIL PROTECTED]> wrote:

>A little word of warning...
>
>Mark, I ass/u/me that your change is for IPLINFO.

It was.

> You're using I as the
>loop control variable - which Shane is using for his outer loop in his
>ECVTCTBL REXX.
>
>So, if you do something stupid like I did, and paste the code below into
>Shane's REXX, you'll wind up with a wonderful, almost IEFBR15-like, effect.
>
>(Shane's using J for his loop variable.)
>

I noticed that and was going to change my code snip to match the J that
he was using, but I just used cut/paste also (from my IPLINFO version).
Sorry it caused you a little grief.

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

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

Re: DB2 and flashcopy2

[Ron and Jenny Hawkins]

Hal,

What about work in progress?

This is why we have logs, journals and WADS that track work in progress. Of
course the logs have to be part of the same consistency group as the
Database, but what you get is a copy of your application that can be backed
up, restored, and used for restart. Having IO consistency means you have
database consistency.

Restarting from those Shadowimages will be just the same as restarting after
a power failure, or starting up on a remote copy maintained with synch or
asynch remote copy. The DB will start, and the logs will be use to apply
updates or roll back uncommitted work.

I have 5TB of Oracle Database in Taiwan where I use Hardware consistency
Groups to spin off a backup and a reporting version of the database every
day. Oracle runs against these two copies daily, and it has been running
without a hitch for over 18 months. Oracle handles in-flight data pretty
much the same way as DB2, where the logs are used to externalise committed
data.

Remember that DB2 doc is only going to talk about how to do it with IBM
storage - that doesn't make it the only way, or the best way. IBM isn't
going to write a redbook on hardware copies across multiple controllers and
databases when the first paragraph says "start with two or more HDS Storage
Controllers..."

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Hal Merritt
> Sent: Thursday, 14 July 2005 3:49 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: DB2 and flashcopy2
> 
> What about the work in progress in DB2 buffers that is not yet committed
> (flushed) to DASD? The I/O might be consistent, but how would the data?
> 
> I would follow the suggestions in the DB2 doc rather than the hardware.
> 
> Also, there is ample discussion in many recovery Redbooks that discuss
> the 'Point of Consistency' concepts and issues.
> 
> Only the Lone Ranger has Silver Bullets.
> 
> My US$0.02
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Welch, Mp P [ITS]]

True.

Software costs have clearly been demonstrated to be an inhibitor to
mainframe growth.

I don't know why SAS continues to have a pricing structure for the size
of a mainframe machine instead of the business value of using the
application.

Value based pricing (not VWLC) for the mainframe, consistent with
similar business value received using non-mainframes, would solve many
mainframe dilemmas.

Metagroup says, High software prices of Z/OS and dependent utility
software will slow zSeries annual growth.

Mp Welch
Sprint
214-215-7284 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ron and Jenny Hawkins
Sent: Wednesday, July 13, 2005 3:13 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Another - Another One Bites the Dust

Hands up all of you that have successfully migrated your SAS/MXG
applications from MVS to Windows and saved money. 

Hands up those of you that believe it is now costing more?

The MXG PDB is a classic example of an application that can be
successfully moved from mainframe to a windows or Unix and provide a
better TCO along with improved performance, function and productivity. 

In fact, if I was asked to develop an MXG PDB from scratch for a site I
wouldn't even consider using MVS. A reasonable server class desktop,
with XP Professional and some FC connections to SAN storage would be a
better and cheaper way to go in almost all cases.

Ron

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On 
> Behalf Of Welch, Mp P [ITS]
> Sent: Thursday, 14 July 2005 3:48 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Another - Another One Bites the Dust
> 
> We've seen that many of our midrange projects end up costing much more

> than the mainframe solution they replaced.
> 
> The problem we've seen is that its usually too late to bring the 
> application back after it migrates regardless of how much more 
> expensive it becomes.
> 
> If you look at your numbers, you may find the "much more expensive"
> mainframe wasn't so expensive after all.
> 
> Even if the perception that the mainframe is too expensive turns out 
> to be true after reviewing all of the cost factors, there are ways to 
> reduce many of the cost factors and keep the mainframe infrastructure 
> cost effective.
> 
> We've seen IBM give us ridiculously high MIP estimates for new 
> mainframe projects as Norris had mentioned, and CEC based software 
> contracts have caused unnecessarily high cpu upgrade costs, but we 
> still feel that our mainframe environment (with proper financial care 
> and feeding) continues to provide significant contribution to IT value
at our company.
> 
> Maybe someday alternative non-mainframe computing will be best for all

> our work but if we can wait a little longer those solutions will only 
> be better (cheaper?) next year...
> 
> Mp Welch
> Sprint
> 214-215-7284
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions, 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: Another - Another One Bites the Dust

[Steve Comstock]

Robin Murray wrote:
...and hands up all those who have converted a large, many faceted 
application off the mainframe only to see your TCO go up. I know of a 
company (not naming names) 


C'mon, Robin. It's time to _start_ naming names -
and providing dates, locations, and contacts
when possible. Time to take the gloves off, eh?

Kind regards,

-Steve Comstock



who just put their mainframe-to-server
conversion on hold when it was revealed that the next stage of their 
conversion would be many millions of bucks.


Some things make sense for the mainframe, some things make sense for the 
servers. Creating an MXG PDB is perfect for a server - it's a pretty 
straight forward, self contained process.



Robin Murray
Tel: (902) 453-7300 x4177
Cell: (902) 430-0637





Ron and Jenny Hawkins <[EMAIL PROTECTED]>
Sent by: IBM Mainframe Discussion List 
07/13/2005 05:13 PM
Please respond to IBM Mainframe Discussion List
 
To: IBM-MAIN@BAMA.UA.EDU
cc: 
Subject:Re: Another - Another One Bites the Dust



Hands up all of you that have successfully migrated your SAS/MXG
applications from MVS to Windows and saved money. 


Hands up those of you that believe it is now costing more?

The MXG PDB is a classic example of an application that can be 
successfully

moved from mainframe to a windows or Unix and provide a better TCO along
with improved performance, function and productivity. 


In fact, if I was asked to develop an MXG PDB from scratch for a site I
wouldn't even consider using MVS. A reasonable server class desktop, with 
XP

Professional and some FC connections to SAN storage would be a better and
cheaper way to go in almost all cases.

Ron


--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: IBM VSAM Statistics are often Bogus

[Ed Finnell]

 
In a message dated 7/13/2005 3:41:56 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

the  conditions at the 1.4 and 1.5 levels (1G0 and 1H0) and reported on
validity  in the opposite way. Good is bad; bad is good. A philosophical and
ethical  conundrum if ever there was one. The 1.6 (1J0) level is  OK,
however.



"Holy spaghetti Batman, who's testing these  things?"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: IBM VSAM Statistics are often Bogus

[Martin Kline]

> "Holy spaghetti Batman, who's testing these  things?"

Probably went to the lowest bidder.


CONFIDENTIALITY NOTICE:  This electronic transmission (including any
accompanying attachments) is intended solely for its authorized
recipient(s), and may contain confidential and/or legally privileged
information.  If you are not an intended recipient, or responsible for
delivering some or all of this transmission to an intended recipient, be
aware that any review, copying, printing, distribution, use or disclosure of
the contents of this message is strictly prohibited.  If you have received
this electronic message in error, please contact us immediately by
electronic mail at [EMAIL PROTECTED] or notify us
immediately by telephone at 1-800-345-2021 or 816-531-5575 and destroy the
original and all copies of this transmission (including any attachments).
Thank you.

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

Re: Another - Another One Bites the Dust

[Ron and Jenny Hawkins]

There is an insurance company in Melbourne with a rather famous DB2
Nightmare that was finally moved off to a UNIX server (where it finally
performed) and hidden in a locked cupboard. The initials NM may bring back
memories for some... 

There have been quite a few successful migrations from MVS to Solaris and
HP-UX here in Asia. In SE Asia some large Telcos, an Airline and a Power
Company spring to mind.

I know a few companies that have put new MF consolidation on hold because
their next upgrade was going to cost many millions of bucks in software
licensing. There are countless stories on both sides of the fence.



> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Robin Murray
> Sent: Thursday, 14 July 2005 4:23 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Another - Another One Bites the Dust
> 
> ...and hands up all those who have converted a large, many faceted
> application off the mainframe only to see your TCO go up. I know of a
> company (not naming names) who just put their mainframe-to-server
> conversion on hold when it was revealed that the next stage of their
> conversion would be many millions of bucks.
> 
> Some things make sense for the mainframe, some things make sense for the
> servers. Creating an MXG PDB is perfect for a server - it's a pretty
> straight forward, self contained process.
> 
> 
> Robin Murray
> Tel: (902) 453-7300 x4177
> Cell: (902) 430-0637
> 
> 
> 
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Craddock, Chris]

> [snip]
> My original point was you can't compare a single-purpose 
> box's reliability with that of a mainframe and get a fair
> comparison.

You can compare anything you like to anything else. Fairness
is not (at least last I looked) considered to be a qualifier
in choosing one solution over another. 

> This is a very narrow point, regardless of what the user 
> sees and platform costs and whatnot. You're looking at a 
> wider picture here.

That's pretty much the point. Yes, the latest and greatest
mainframe technology is phenomenally reliable. No question
of that. And if you configure it the right way, you can get
very high business availability from a relatively small set
of moving parts. That's very cool. A towering achievement in
fact. But there are similarly effective solutions that cost
considerably less whichever way you slice it. Fairness to 
one or the other is irrelevant.

Unfortunately, in a lot of ways its like Porsche's success in
making a silk purse out of the old 911 sow's ear. For you non
car nuts, the Porsche has its engine hanging out over the back
axle, which causes it to have a high polar moment of inertia,
which means that left to its own devices and Newton's laws,
its going to have an evil tendency to want to disappear backwards
off the road. Ask me how I know...

Porsche has tamed that tendency by applying a staggering amount
of engineering effort - coincidentally over about the same time
as the IBM System/360 has evolved into what we see now. So now 
Porsche has a rear engined sports car that handles wonderfully,
but as anyone who has lusted after one knows, its an awfully
expensive way of getting from A to B. Just like the mainframe.

CC

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

Re: Another - Another One Bites the Dust

[Ron and Jenny Hawkins]

Hal,

C'mon Hal. You really think that sites that have right sized MXG don't use
automation to run BUILDPDB? You can't truly think that Windows and Unix
doesn't have any automation tools or ISV software. You don't even have to
FTP the SMF dataset nowadays - you just read it directly through FTP.

And as for report distribution, I'm not sure what particular superiority MVS
has over Unix and Windows? Procedures can print to a printer, or a file that
can be emailed later. 

Ron


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Hal Merritt
> Sent: Thursday, 14 July 2005 4:30 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Another - Another One Bites the Dust
> 
> Looked at that solution a few years ago. Of course, the root problem is
> SAS trying to put itself out of business.
> 
> Even so, the difficulty in automating and scheduling the process added a
> lot of human intervention. Human beans ain't cheap.
> 
> For a scenario where MXG was used for research and ad hoc, then, yes,
> hands down a winner.
> 
> But for situations where MXG actually generated and distributed reports
> to a number of people, I am not so sure.
> 
> My $0.02, and there have been a few trivial technology advances in the
> last decade or so ;-)
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Ron and Jenny Hawkins
> Sent: Wednesday, July 13, 2005 3:13 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Another - Another One Bites the Dust
> 
> Hands up all of you that have successfully migrated your SAS/MXG
> applications from MVS to Windows and saved money.
> 
> Hands up those of you that believe it is now costing more?
> 
> The MXG PDB is a classic example of an application that can be
> successfully
> moved from mainframe to a windows or Unix and provide a better TCO along
> with improved performance, function and productivity.
> 
> In fact, if I was asked to develop an MXG PDB from scratch for a site I
> wouldn't even consider using MVS. A reasonable server class desktop,
> with XP
> Professional and some FC connections to SAN storage would be a better
> and
> cheaper way to go in almost all cases.
> 
> Ron
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> 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: Another - Another One Bites the Dust

[Ted MacNEIL]

...
Metagroup says, High software prices of Z/OS and dependent utility
software will slow zSeries annual growth
...
Where have you (and they) been?
Everything new is old again.

There have been people (myself included) trumpetting this since IBM
introduced tier-based pricing in 1984-1985.

Conversion may have accelerated, lately; the issue is NOT brand new!

The argument is not total cost.
Rather, it's mostly cost per seat.
All costs! Not just the ones MetaGroup (Gartner, et. al.) decide to include.

Frankly, I don't trust those people any further than I could throw a tantrum!

-teD

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

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

Re: IBM VSAM Statistics are often Bogus

[Ted MacNEIL]

...
"Holy spaghetti Batman, who's testing these  things?"
...
Unfortunately, we are!
-teD

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

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

Re: CSRCTABL pointed by ECVTCTBL

[Ray Mullins]

Not a problem, not your fault, etc..  As I said, I was stupid and didn't
deskcheck.

(I need to d/l your new IPLINFO now.)

Later,
Ray

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Mark Zelden
Sent: Wednesday July 13 2005 13:31
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: CSRCTABL pointed by ECVTCTBL

On Wed, 13 Jul 2005 12:50:37 -0700, Ray Mullins <[EMAIL PROTECTED]> wrote:

>A little word of warning...
>
>Mark, I ass/u/me that your change is for IPLINFO.

It was.

> You're using I as the
>loop control variable - which Shane is using for his outer loop in his 
>ECVTCTBL REXX.
>
>So, if you do something stupid like I did, and paste the code below 
>into Shane's REXX, you'll wind up with a wonderful, almost IEFBR15-like,
effect.
>
>(Shane's using J for his loop variable.)
>

I noticed that and was going to change my code snip to match the J that he
was using, but I just used cut/paste also (from my IPLINFO version).
Sorry it caused you a little grief.

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

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Ron and Jenny Hawkins]

They have less support staff total than the Australian Bank I worked for had
System Programmers.

DR works with TrueCopy the same way MVS does, and server-less backup is way
beyond anything us MVS guys can dream of.

No need for Hyperswap and its associated performance penalty, because RAID-1
is built into the Logical Volume Manager (something like DFP)if you want
that sort of redundancy (some do).

Systems are usually up for months, and I find that the Solaris, HP-UX and
AIX vendor support can read dumps just as well as the MVS guys. 

I will concede that the equivalent of IO Config changes can be a PITA
compared to dynamic HCD, and that Fault Tolerance is not as good as Hot
Pluggable FRU. However in many cases this is managed using failover within
the clustering support, not unlike we do today with Parallel Sysplex.

We are talking TCO here. 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Robin Murray
> Sent: Thursday, 14 July 2005 4:29 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Another - Another One Bites the Dust
> 
> If they are indeed doing a better job than what a mainframe can do
> regarding the number of support staff, disaster recovery, ease of
> maintenance and debuggability, then I would indeed concede the point. Have
> you investigated these areas? Or are they just running unix because "it's
> cheaper than a mainframe"?
> 
> Robin Murray
> Tel: (902) 453-7300 x4177
> Cell: (902) 430-0637

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Mike Liberatore]

FTPing report files that must put a hurtin on the Network and that data 
is it really secure on that open systems


Ron and Jenny Hawkins wrote:


They have less support staff total than the Australian Bank I worked for had
System Programmers.

DR works with TrueCopy the same way MVS does, and server-less backup is way
beyond anything us MVS guys can dream of.

No need for Hyperswap and its associated performance penalty, because RAID-1
is built into the Logical Volume Manager (something like DFP)if you want
that sort of redundancy (some do).

Systems are usually up for months, and I find that the Solaris, HP-UX and
AIX vendor support can read dumps just as well as the MVS guys. 


I will concede that the equivalent of IO Config changes can be a PITA
compared to dynamic HCD, and that Fault Tolerance is not as good as Hot
Pluggable FRU. However in many cases this is managed using failover within
the clustering support, not unlike we do today with Parallel Sysplex.

We are talking TCO here. 

 


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Robin Murray
Sent: Thursday, 14 July 2005 4:29 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Another - Another One Bites the Dust

If they are indeed doing a better job than what a mainframe can do
regarding the number of support staff, disaster recovery, ease of
maintenance and debuggability, then I would indeed concede the point. Have
you investigated these areas? Or are they just running unix because "it's
cheaper than a mainframe"?

Robin Murray
Tel: (902) 453-7300 x4177
Cell: (902) 430-0637
   



--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Assembler: alignment of machine instructions

[Arthur T.]

On Wed, 13 Jul 2005 23:13:45 +0200, in comp.lang.asm370 
(Message-ID:<[EMAIL PROTECTED]>) 
"Michel Castelein" 
<[EMAIL PROTECTED]> wrote:


So, I'm wondering why the expansion of the SAVE macro 
begins with a DS 0H.


That's redundant, isn't it?


 Most macros start with an optional label.  Rather 
than tying the label to the first generated machine 
instruction, it's convenient to tie it to a DS 0H.  That 
allows you to easily add extra code at the beginning and to 
have multiple expansions (depending on parms specified) 
without having multiple label handling.


 In open code, people often coded
LABEL EQU   *
but, if there was an odd-length constant prior to it, it 
would not be halfword aligned, so people started using the 
DS 0H technique, instead.  (Also, IIRC, the TEST 
instruction has more information if you code as DS 0H.) 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Assembler: alignment of machine instructions

[Edward E. Jaffe]

Arthur T. wrote:

 Most macros start with an optional label.  Rather than tying the 
label to the first generated machine instruction, it's convenient to 
tie it to a DS 0H.  That allows you to easily add extra code at the 
beginning and to have multiple expansions (depending on parms 
specified) without having multiple label handling.


 In open code, people often coded
LABEL EQU   *
but, if there was an odd-length constant prior to it, it would not be 
halfword aligned, so people started using the DS 0H technique, 
instead.  (Also, IIRC, the TEST instruction has more information if 
you code as DS 0H.)



Of course, with modern HLASM it's preferable to code 'DC 0H' rather than 
the 'DS 0H' as required by older assembler implementations.


--
-
| 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: CSRCTABL pointed by ECVTCTBL

[Schiradin,Roland HG-Dir itb-db/dc]

Nobody report a bug for my assembler prog !!! Hehe

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Im Auftrag von Ray 
Mullins
Gesendet: Mittwoch, 13. Juli 2005 23:31
An: IBM-MAIN@BAMA.UA.EDU
Betreff: Re: CSRCTABL pointed by ECVTCTBL


Not a problem, not your fault, etc..  As I said, I was stupid and didn't 
deskcheck.

(I need to d/l your new IPLINFO now.)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Another - Another One Bites the Dust

[Craddock, Chris]

> Metagroup says, High software prices of Z/OS and dependent utility
> software will slow zSeries annual growth.

Oh, so it WILL slow growth eh? When? Any day soon? 

What a band of temporarly challenged genii. High software prices
have been retarding growth for decades. Customers have been fleeced
blind ever since the marketing vampires figured out that hitching 
prices to "MIPS" was as close as they could get to robbery without
facing jail 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: Another - Another One Bites the Dust

[Edward E. Jaffe]

Craddock, Chris wrote:


Metagroup says, High software prices of Z/OS and dependent utility
software will slow zSeries annual growth.
   



Oh, so it WILL slow growth eh? When? Any day soon? 


What a band of temporarly challenged genii. High software prices
have been retarding growth for decades. Customers have been fleeced
blind ever since the marketing vampires figured out that hitching 
prices to "MIPS" was as close as they could get to robbery without

facing jail time. 
 



Since the introduction of zSeries, IBM has seen *substantial* growth 
both in terms of raw mainframe capacity shipped and, more importantly, 
in terms of world-wide market share in the large server (i.e., >$250K) 
marketplace, gaining three full points in 2002 alone! (Source: IDC 
Quarterly Tracker). While Sun, HP and others took *major* dives after 
Y2K, IBM stayed healthy, introduced a new server line with $1B of R&D 
investment, and capitalized on the resulting opportunities that 
presented themselves.


This can't be ignored.

--
-
| 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: UNIX Terminology

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/12/2005
   at 07:44 AM, willie bunter <[EMAIL PROTECTED]> said:

>Are they availble on the INTERNET?

They're real beasts[1]. Try http://www.ora.com for an introduction.

[1] Look at their cover art.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Highly used programs: any better replacements out there? IDCAMS, IEFBR14

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/12/2005
   at 10:34 AM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>I find that when I go to ISPF 3.4 and type 'D' before a few dozen
>data set names, my terminal is unavailable for an uncomfortably long
>time during processing.

That ties into the issue of allowing multiple sessions for the same
userid. A restructuring of TSO[1] to support multiple legacy (not
Unix) address spaces could solve your problem.

[1] Including VTIOC.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: ABCs of System Programming Volume 9 UNIX System Services

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
07/13/2005
   at 07:51 AM, "McKown, John" <[EMAIL PROTECTED]> said:

>Hum, one could argue that z/VM is not an operating system. It is a
>hypervisor. 

No. CP is a hypervisor. Z/VM is an operating system of which CP is but
one component.

>You cannot run "applications" on z/VM directly.

Both CMS and GCS are part of z/VM. You can run applications on either
directly.

>Note that CMS is not z/VM.

Neither is CP ;-)

Both CMS and GCS are part of z/VM. Further, since the CP/67 days CMS
has been "first among equals", to the extent that two of the common
slang names for VM have been CP/CMS[1] and VM/CMS. All of the VM
maintenance procedures are designed around CMS.

[1] That name was also applied to CP/67.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: CSRCTABL pointed by ECVTCTBL

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/12/2005
   at 05:45 PM, "Edward E. Jaffe" <[EMAIL PROTECTED]> said:

>FYI. This test is incomplete/erroneous. The valid characters for
>modern  3270 devices are x'00' and x'40' through x'FE' inclusive.
>x'01' through  x'3F' and x'FF' will cause PROGxxx failures.

That's true for text, and for 12-bit and 14-bit addresses modes only.
Don't do the translation for, e.g., buffer orders, 16-bit addresses.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: CSRCTABL pointed by ECVTCTBL

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/13/2005
   at 07:21 AM, "Edward E. Jaffe" <[EMAIL PROTECTED]> said:

>No. From the very beginning, x'00' was defined as the "null"
>character.  An input field containing trailing nulls can be shifted
>right with  insert. Trailing blanks cannot be shifted.

Unless you have Text Assist.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Has "VSAM" become synonymous with KSDS?

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/12/2005
   at 05:36 PM, Binyamin Dissen <[EMAIL PROTECTED]> said:

>You never heard of block addressing?

You've never heard of variable-length records?

>You can do that in BDAM.

No. BDAM doesn't have the string concept.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Highly used programs: any better replacements out there? IDCAMS, IEFBR14

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/11/2005
   at 04:26 PM, Richard Peurifoy <[EMAIL PROTECTED]> said:

>Many people use this to create/delete datasets. 

Or, at least, so they believe. At least it's a less expensive
placeholder than IEHPROGM.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Highly used programs: any better replacements out there? IDCAMS, IEFBR14

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 07/11/2005
   at 04:51 PM, Steve Grimes <[EMAIL PROTECTED]> said:

>Wouldn't XR  R15,R15 have been more efficient?

No. Yes. On what processor?

Even in the S/360 days the answer would depend on the box. Likewise SR
versus SLR vs LA.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Highly used programs: any better replacements out there? IDCAMS, IEFBR14

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 07/12/2005
   at 07:27 AM, Martin Kline <[EMAIL PROTECTED]> said:

>Why hasn't IBM come out with a JCL option that says, "There is no
>program, just set return code zero?"  It could avoid all the setup
>for calling IEFBR14 - LOAD, DELETE, RB setup, save area, recovery,
>etc.

If it ain't broke don't fix it? That would introduce new potentiality
for errors and would increase the overhead for everything other than
IEFBR14. How expensive is one ATTACH and how much are you willing to
pay to get rid of it?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: IDCAMS 'ALLOCATE' command

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/12/2005
   at 09:42 AM, Rolf Ernst <[EMAIL PROTECTED]> said:

>SVC 99 uses only JES or compatible component.

Only if you are allocating a subsystem, e.g., SYSOUT, data set.
Otherwise JES is not involved.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: IDCAMS 'ALLOCATE' command

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/12/2005
   at 07:30 AM, Steve Comstock <[EMAIL PROTECTED]> said:

>OK, how about SVC 99 interfaces, the REXX BPXWDYN service, and the
>related Assembler callable services? Do all of them use TMP under the
>covers?

No. 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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