Re: Meet Cobol's hard core fans

[Ed Jaffe]

On 8/21/2014 7:08 PM, Shane Ginnane wrote:

 Some 23 of the world's top 25 retailers, 92 of the top 100 banks,
 and the 10 largest insurers all entrust core operations to Cobol
 programs running on IBM mainframes, says Deon Newman, vice
 president, IBM System z. Since 2010, around 50 to 75 customers
 have left the mainframe fold, IBM says, while some 270 of IBM's
 3,500 mainframe customers have come aboard as new clients since
 then, Newman says.

Hmmm. Note the careful wording - "System z". How many of those leaving 
the platform were "legacy" (say z/OS) customers ?. How many of the new 
clients were non-zLinux ?. What's the delta ?.


IIRC, when Greg Lotko referenced these same statistics during his 
keynote address at SHARE in Boston, he mentioned that approximately 40% 
of those "new" customers were z/OS.


Having said that, my understanding is that this count of "new" customers 
includes customers that completely reversed previously confirmed, 
in-progress business plans to migrate off the mainframe. IMHO, it is 
completely fair to count them as "new" since their moribund 9672s 
running just a few hard-to-kill apps under OS/390 V2R4 have now been 
replaced with zEC12s running z/OS 2.1 and a renewed business focus to 
move work onto the platform.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Fw: PLPA entry (was PLPA enty)

[Jim Mulder]

 I forgot to mention that you can reduce the risks of using 
SETPROG LNKST,UPDATE 
by specifying the DELAY=nnn parameter.  This causes
the processing to wait for nnn seconds after doing the update before
freeing control blocks for now unused LNKLSTs.  This allows time for 
operations against old LNKLSTs to complete before control blocks that
they may have been using get freed.

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

> From: Jim Mulder/Poughkeepsie/IBM
> To: IBM Mainframe Discussion List 
> Date: 08/22/2014 12:32 AM
> Subject: Re: PLPA entry (was PLPA enty)
> 
> 
> > >On Tue, 19 Aug 2014 08:28:22 -0400, Peter Relson wrote:
> > >
> > >>The only thing that is truly safe is to let new address spaces and 
jobs
> > >>use the new lnklst while old ones continue to use the old one.
> > >
> > >This has always been my approach - protect the long running address 
spaces.
> > >Of course, on a sysprog sandpit it can be a matter of "full steam 
> > ahead, and damn the users". The users in that case being (only) "us".

> > From: Brian Westerman 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 08/22/2014 12:15 AM
> > Subject: Re: PLPA entry (was PLPA enty)
> > Sent by: IBM Mainframe Discussion List 
> > 
> > I think I have to disagree.  I can't see where there is any evidence
> > that altering the LINKLIST while things are running would not 
> > "work".  If that were the case, I think there would be a lot of 
> > angry people opening problems with IBM support, and I would be one 
> > of the first on that list of people.
> > 
> > Not using the features is not an option, that's why we asked for 
> > them in the first place.  I know that IBM doesn't always provide 
> > what we ask for, but in this case it was done and it has never been 
> > unsuccessful for me.  I install and upgrade new systems for clients 
> > many times per year and I have yet to have this process fail or to 
> > experience a problem with this method.
> > 
> > I "could" just be lucky, but with the frequency that I use these 
> > commands and the number of systems I use them on, I would think that
> > I would have experienced a problem by now.:)

>   I have to disagree with your disagreement.  When these failures occur
> on IBM test systems, people tend to send me the dumps.  And I have
> seen the failures on several occasions.
> 
>   I am not telling you not to use it, as long as you are in an
> environment where you can understand and accept the risks.
> But it was not possible to design it in a way which was free
> from risks. 
> 
> Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OS message on HMC

[Lizette Koehler]

This is a very simple issue.

The TASK - GTF has a datasets called SYS1.TRACE with either DISP=(,CATLG) or
DISP=OLD

Another task needs it.

Issue the MVS Command D GRS,Cand see what else needs the data set.

Next, contact your system programmer in your shop for assistance.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Chandramohan, Harish - CW
> Sent: Thursday, August 21, 2014 9:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: OS message on HMC
> 
> Please guide me further to resolve the below message.
> 
> ISGECM1 Job 'GTF ' on system 'SYS2' is holding 'SYS1.TRACE'; other
jobs
> are waiting to use it.
> 
> Regards
> Harish C
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PLPA entry (was PLPA enty)

[Jim Mulder]

> >On Tue, 19 Aug 2014 08:28:22 -0400, Peter Relson wrote:
> >
> >>The only thing that is truly safe is to let new address spaces and 
jobs
> >>use the new lnklst while old ones continue to use the old one.
> >
> >This has always been my approach - protect the long running address 
spaces.
> >Of course, on a sysprog sandpit it can be a matter of "full steam 
> ahead, and damn the users". The users in that case being (only) "us".

> From: Brian Westerman 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/22/2014 12:15 AM
> Subject: Re: PLPA entry (was PLPA enty)
> Sent by: IBM Mainframe Discussion List 
> 
> I think I have to disagree.  I can't see where there is any evidence
> that altering the LINKLIST while things are running would not 
> "work".  If that were the case, I think there would be a lot of 
> angry people opening problems with IBM support, and I would be one 
> of the first on that list of people.
> 
> Not using the features is not an option, that's why we asked for 
> them in the first place.  I know that IBM doesn't always provide 
> what we ask for, but in this case it was done and it has never been 
> unsuccessful for me.  I install and upgrade new systems for clients 
> many times per year and I have yet to have this process fail or to 
> experience a problem with this method.
> 
> I "could" just be lucky, but with the frequency that I use these 
> commands and the number of systems I use them on, I would think that
> I would have experienced a problem by now.:)

  I have to disagree with your disagreement.  When these failures occur
on IBM test systems, people tend to send me the dumps.  And I have
seen the failures on several occasions.

  I am not telling you not to use it, as long as you are in an
environment where you can understand and accept the risks.
But it was not possible to design it in a way which was free
from risks. 

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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

OS message on HMC

[Chandramohan, Harish - CW]

Please guide me further to resolve the below message.

ISGECM1 Job 'GTF ' on system 'SYS2' is holding 'SYS1.TRACE'; other jobs 
are waiting to use it.

Regards
Harish C

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PLPA entry (was PLPA enty)

[Brian Westerman]

I think I have to disagree.  I can't see where there is any evidence that 
altering the LINKLIST while things are running would not "work".  If that were 
the case, I think there would be a lot of angry people opening problems with 
IBM support, and I would be one of the first on that list of people.

Not using the features is not an option, that's why we asked for them in the 
first place.  I know that IBM doesn't always provide what we ask for, but in 
this case it was done and it has never been unsuccessful for me.  I install and 
upgrade new systems for clients many times per year and I have yet to have this 
process fail or to experience a problem with this method.

I "could" just be lucky, but with the frequency that I use these commands and 
the number of systems I use them on, I would think that I would have 
experienced a problem by now.:)

Brian

On Tue, 19 Aug 2014 08:25:18 -0500, Shane Ginnane  wrote:

>On Tue, 19 Aug 2014 08:28:22 -0400, Peter Relson wrote:
>
>>The only thing that is truly safe is to let new address spaces and jobs
>>use the new lnklst while old ones continue to use the old one.
>
>This has always been my approach - protect the long running address spaces.
>Of course, on a sysprog sandpit it can be a matter of "full steam ahead, and 
>damn the users". The users in that case being (only) "us".
>
>Shane ...
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Meet Cobol's hard core fans

[Shane Ginnane]

>> Some 23 of the world's top 25 retailers, 92 of the top 100 banks,
>> and the 10 largest insurers all entrust core operations to Cobol
>> programs running on IBM mainframes, says Deon Newman, vice
>> president, IBM System z. Since 2010, around 50 to 75 customers
>> have left the mainframe fold, IBM says, while some 270 of IBM's
>> 3,500 mainframe customers have come aboard as new clients since
>> then, Newman says.
>>
...
>Since these statistics show a trend that goes counter to the common perception,

Hmmm. Note the careful wording - "System z".
How many of those leaving the platform were "legacy" (say z/OS) customers ?.
How many of the new clients were non-zLinux ?. What's the delta ?.

In this part of the world I see no evidence of increased prospects.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Meet Cobol's hard core fans

[Joel C. Ewing]

On 08/21/2014 03:19 PM, Paul Gilmartin wrote:
> On Thu, 21 Aug 2014 13:16:33 -0500, Ed Gould wrote:
>
>> http://www.computerworld.com/s/article/9250527/
>> Meet_Cobol_s_hard_core_fans?source=CTWNLE_nlt_shark_2014-08-21
>>
> 
> http://www.computerworld.com/s/article/9250527/Meet_Cobol_s_hard_core_fans?source=CTWNLE_nlt_shark_2014-08-21
>
>> Computerworld - With the long-anticipated Cobol skills shortage
>> starting to bite, many businesses have been steadily migrating
>> applications off the mainframe. Blue Cross Blue Shield of South
>> Carolina has been doubling down.
> Some 23 of the world's top 25 retailers, 92 of the top 100 banks,
> and the 10 largest insurers all entrust core operations to Cobol
> programs running on IBM mainframes, says Deon Newman, vice
> president, IBM System z. Since 2010, around 50 to 75 customers
> have left the mainframe fold, IBM says, while some 270 of IBM's
> 3,500 mainframe customers have come aboard as new clients since
> then, Newman says.
>
> I'm somewhat surprised to see an IBM employee publicly disclosing
> such business statistics.
>
> -- gil

Since these statistics show a trend that goes counter to the common perception, 
it makes perfect business sense for IBM to make them public, assuming they wish 
the mainframe to continue to be a viable platform.  

I'm sure one of the arguments used by those who have a financial self-interest 
in moving workloads off mainframes is that those other platforms must be the 
only viable long-term strategy since everyone is moving workloads from, not to, 
mainframes and everyone else can't be wrong.  If more customers are moving to 
mainframes than leaving, that destroys that argument.

As for the coming critical shortage of COBOL programmers: I don't know how 
colleges train people in IT these days, but in the old days students were 
taught basic programming concepts and algorithms and exposed to many different 
programming languages in order to appreciate that no single programming 
language is optimal for all tasks.  Once you understood programming concepts 
and were functionally literate in several languages, learning a new programming 
language was not that difficult:  just read a language reference manual and an 
introductory text, learn how to map constructs and algorithms in known 
programming languages into the new language, learn what is unique about the 
language, and study existing programs.  In a few days it was possible to write 
simple programs in the new language and certainly in at most a few months be 
competent enough to understand and potentiallly maintain programs in the 
language.  

Unless the new generation of programmers is much dumber than we were, I think 
the alarms about the future lack of COBOL programmers is overblown.  Acquiring 
a new language skill is a better understood process and simpler than teaching 
complex application designs unique to one installation.   It would certainly be 
better if younger programmers were brought on board and introduced to COBOL 
applications while some of the retiring COBOL programmers are still around, but 
that overlap is desireable just for passing on knowledge about installation 
programming conventions, complex application designs and inter-application 
relationships. If some IT-management types believe that this overlap 
requirement will just magically vanish or be significantly reduced if they 
migrate off COBOL to any of the existing alternatives or if they migrate to a 
different platform, they are in for a unpleasant surprise.

 
-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Meet Cobol's hard core fans

[John McKown]

Hum, perhaps by using GNU COBOL to compile existing COBOL source into C?
Then convert C to C# and Bob's your uncle! Instant, easy perfect
conversion! Now, about that resort property in the Sahara forest.
 On Aug 21, 2014 4:48 PM, "Tony Harminc"  wrote:

> On 21 August 2014 16:48, Greg Shirey  wrote:
> > As for the other 90% of businesses running mainframes today, Vecchio
> thinks the Cobol brain drain will be the
> > catalyst for more extensive migrations off the platform, through
> rewrites, moves to packaged applications or
> > recompiling and re-hosting Cobol on distributed computing platforms
>
> Not entirely clear to me how the COBOL brain drain is addressed by
> recompiling and re-hosting Cobol on distributed computing platforms.
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Meet Cobol's hard core fans

[Sam Siegel]

On Thu, Aug 21, 2014 at 2:57 PM, Mark Post  wrote:

> >>> On 8/21/2014 at 05:47 PM, Tony Harminc  wrote:
> > Not entirely clear to me how the COBOL brain drain is addressed by
> > recompiling and re-hosting Cobol on distributed computing platforms.
>
> It's magic, I guess.  Suddenly someone other than a long-time COBOL
> developer will be able to maintain it.
>
>
The eclipse based editor magically allows the distributed coder to
visualize COBOL and HLASM as Java and .NET.  Additionally when the same
coder enters updates in Java and .NET the same editor magically does an
error free translation to COBOL and HLASM.

The editor supports OS COBOL through Enterprise COBOL 5.x as well as all
known and unknown versions of HLASM and is predecessors.

The differences between VSE and z/OS are similarly handled.

The debugger has similar capabilities.

We can thank DARPA and other government agency for funding the development
work required to get the editor and debugger working.

Now if I can just get my DWIM macro working.

;-)

Sam


>
> Mark Post
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Meet Cobol's hard core fans

[Ted MacNEIL]

Over 30. I got my first 'business' PC in 1981, and was told, then, that was the 
first step in the demise of the mainframe.

-
-teD
-
  Original Message  
From: Greg Shirey
Sent: Thursday, August 21, 2014 16:48
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Meet Cobol's hard core fans

But I'm not surprised to see that Gartner is still predicting mass migrations 
off the mainframe in 3 to 5 years: 

For these mainframe-centric businesses, the Cobol application suite that runs 
the heart of the business isn't going anywhere. "But they still need to deal 
with the declining Cobol workforce . . . to keep these systems viable for the 
next decade or two," says Dale Vecchio, research vice president at Gartner Inc. 

As for the other 90% of businesses running mainframes today, Vecchio thinks the 
Cobol brain drain will be the catalyst for more extensive migrations off the 
platform, through rewrites, moves to packaged applications or recompiling and 
re-hosting Cobol on distributed computing platforms. After years of foot 
dragging, the looming Cobol brain drain will force many organizations into 
making a decision -- one way or the other -- within the next three to five 
years. "Increasingly, I see this transition happening," Vecchio says. "Waiting 
isn't going to make this any cheaper, and it isn't going to reduce the risk." 


They've been predicting that for close to 20 years now, I think.

Greg Shirey
Ben E. Keith Company

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, August 21, 2014 3:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Meet Cobol's hard core fans


I'm somewhat surprised to see an IBM employee publicly disclosing such business 
statistics.

-- gil


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Meet Cobol's hard core fans

[Mark Post]

>>> On 8/21/2014 at 04:19 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote: 
> I'm somewhat surprised to see an IBM employee publicly disclosing
> such business statistics.

IBM executives get away with a lot of !@#$ like that.  Pre-announcing stuff, 
etc.  IBM executive presentations are a gold mine of such disclosures.


Mark Post

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Meet Cobol's hard core fans

[Mark Post]

>>> On 8/21/2014 at 05:47 PM, Tony Harminc  wrote: 
> Not entirely clear to me how the COBOL brain drain is addressed by
> recompiling and re-hosting Cobol on distributed computing platforms.

It's magic, I guess.  Suddenly someone other than a long-time COBOL developer 
will be able to maintain it.


Mark Post

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Meet Cobol's hard core fans

[Tony Harminc]

On 21 August 2014 16:48, Greg Shirey  wrote:
> As for the other 90% of businesses running mainframes today, Vecchio thinks 
> the Cobol brain drain will be the
> catalyst for more extensive migrations off the platform, through rewrites, 
> moves to packaged applications or
> recompiling and re-hosting Cobol on distributed computing platforms

Not entirely clear to me how the COBOL brain drain is addressed by
recompiling and re-hosting Cobol on distributed computing platforms.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Meet Cobol's hard core fans

[Anne & Lynn Wheeler]

wgshi...@benekeith.com (Greg Shirey) writes:
> For these mainframe-centric businesses, the Cobol application suite
> that runs the heart of the business isn't going anywhere. "But they
> still need to deal with the declining Cobol workforce . . . to keep
> these systems viable for the next decade or two," says Dale Vecchio,
> research vice president at Gartner Inc.
>
> As for the other 90% of businesses running mainframes today, Vecchio
> thinks the Cobol brain drain will be the catalyst for more extensive
> migrations off the platform, through rewrites, moves to packaged
> applications or recompiling and re-hosting Cobol on distributed
> computing platforms.  After years of foot dragging, the looming Cobol
> brain drain will force many organizations into making a decision --
> one way or the other -- within the next three to five
> years. "Increasingly, I see this transition happening," Vecchio
> says. "Waiting isn't going to make this any cheaper, and it isn't
> going to reduce the risk."

there was enormous migration off mainframes in late 80s and early 90s
that resulted in predicting mainframe use would disappear altogether.

there was some very high value overnight batch cobol that had enormous
amount of institutional knowledge that had grown up over a period of
decades and wasn't easy to understand and/or translate to other
environments. during the 90s there were billions spent on failed efforts
to translate some of these applications to other environments. Since
then there has been somewhat hiatus ... for many of these, the cost of
not having functional operational environment was enormously larger than
the significant cost differential between mainframes and other
technologies. 

however, there has been slow erosion, with some becoming obsolete and/or
the cost of adapting to changing environment exceeds starting over from
scratch. In some cases, the decades of institutional knowledge becoming
less and less applicable is walled off with minimum change and new
innovation and adaptation occuring elsewhere.

as I've mentioned before in the late 80s, a senior disk engineer got a
talk scheduled at annual, worldwide, internal communication group
conference ... supposedly on 3174 performance, but opened the talk with
the statement that the communication group was going to be responsible
for the demise of the disk division. The communcation group had
strangelhold on mainframe datacenters with its strategic ownership of
everything that crossed the datacenter walls ... was attempting to
preserve its dumb terminal paradigm and fiercely fighting off
client/server and distributed computing. The disk division was starting
to see data fleeing datacenters to more distributed computing friendly
platforms with drop in disk sales.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Meet Cobol's hard core fans

[Greg Shirey]

But I'm not surprised to see that Gartner is still predicting mass migrations 
off the mainframe in 3 to 5 years:   

For these mainframe-centric businesses, the Cobol application suite that runs 
the heart of the business isn't going anywhere. "But they still need to deal 
with the declining Cobol workforce . . . to keep these systems viable for the 
next decade or two," says Dale Vecchio, research vice president at Gartner Inc. 

As for the other 90% of businesses running mainframes today, Vecchio thinks the 
Cobol brain drain will be the catalyst for more extensive migrations off the 
platform, through rewrites, moves to packaged applications or recompiling and 
re-hosting Cobol on distributed computing platforms.  After years of foot 
dragging, the looming Cobol brain drain will force many organizations into 
making a decision -- one way or the other -- within the next three to five 
years. "Increasingly, I see this transition happening," Vecchio says. "Waiting 
isn't going to make this any cheaper, and it isn't going to reduce the risk." 


They've been predicting that for close to 20 years now, I think.

Greg Shirey
Ben E. Keith Company

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, August 21, 2014 3:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Meet Cobol's hard core fans


I'm somewhat surprised to see an IBM employee publicly disclosing such business 
statistics.

-- gil


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Meet Cobol's hard core fans

[Paul Gilmartin]

On Thu, 21 Aug 2014 13:16:33 -0500, Ed Gould wrote:

>http://www.computerworld.com/s/article/9250527/
>Meet_Cobol_s_hard_core_fans?source=CTWNLE_nlt_shark_2014-08-21
> 

http://www.computerworld.com/s/article/9250527/Meet_Cobol_s_hard_core_fans?source=CTWNLE_nlt_shark_2014-08-21

>Computerworld - With the long-anticipated Cobol skills shortage
>starting to bite, many businesses have been steadily migrating
>applications off the mainframe. Blue Cross Blue Shield of South
>Carolina has been doubling down.

Some 23 of the world's top 25 retailers, 92 of the top 100 banks,
and the 10 largest insurers all entrust core operations to Cobol
programs running on IBM mainframes, says Deon Newman, vice
president, IBM System z. Since 2010, around 50 to 75 customers
have left the mainframe fold, IBM says, while some 270 of IBM's
3,500 mainframe customers have come aboard as new clients since
then, Newman says.

I'm somewhat surprised to see an IBM employee publicly disclosing
such business statistics.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Hard Capping an LPAR

[Al Sherkow Digest]

You might find some other ideas on  list. Vendors 
are not allowed on the list, so customers can talk more freely to one another. 

This is the typical approach to attempt to get an unruly vendor to negotiate. 
Some vendors will be very resistant. You may find that someone else has been 
successful with the particular vendors, and that is good information to have. 

Al Sherkow, I/S Management Strategies, Ltd.
Consulting Expertise on WLC, & LCS Software
Seminars on IBM SW Pricing
+1 414 332-3062

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Meet Cobol's hard core fans

[Ed Gould]

http://www.computerworld.com/s/article/9250527/ 
Meet_Cobol_s_hard_core_fans?source=CTWNLE_nlt_shark_2014-08-21


Computerworld - With the long-anticipated Cobol skills shortage  
starting to bite, many businesses have been steadily migrating  
applications off the mainframe. Blue Cross Blue Shield of South  
Carolina has been doubling down.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PLI and CICS Symblic Map addressability

[John Gilmore]

For in general

declare 1 struc based(strucp),
  2 . . .
  2 . . . ;

the statement

allocate struc ;

sets struc's default pointer, here strucp.  If you want to set another
pointer p then you write

allocate struc set(p) ;

If you wish to use struc only as a template, to map storage, call it block, then

strucp = addr(block) ;

permits the storage beginning at the address of block to be mapped as
an instance of struc.

Note that these statements do NOT in general initialize storage,
though the allocate statement can do so if the elements of struc have
the initial attribute.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DF/SORT question (challenge?)

[Shmuel Metz (Seymour J.)]

In <0944307717662460.wa.paulgboulderaim@listserv.ua.edu>, on
08/20/2014
   at 12:13 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>Strange DSN syntax,

Have you checked the TRAILER3 keyword of OUTFIL in the DF/SORT
documentation?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question: Possible to send email, with an attachment from the Mainframe?

[Shmuel Metz (Seymour J.)]

In
,
on 08/20/2014
   at 12:34 PM, Leonard Sasso  said:

>We are able to send email from our mainframe (z/OS 1.13).  Is it
>possible  to send an email with an attachment, from our mainframe?

Yes, and I believe that there are a couple of programs on the CBT tape
that do that, in addition to various 3rd party program products.
Depending on what you are trying to do, you might not even need those.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DF/SORT question (challenge?)

[Sri h Kolusu]

>>>Here's my question. If (can) sort insert records into its output on a 
break in key?
If so, why not sort the input file and, on each key break, generate an 
IEBUPDTE add control card and the write the record that belong to that 
card until the next key break. Do this for each key break and the 
resulting output file would be an IEUPDTE input stream that would then be 
fed into an IEBUPDTE job step that allocates a new PDS(e) and populates 
the members.

Chuck,

DFSORT is quite capable of generating the IEBUPDTE cards on key break. My 
sample JCL is doing a similar thing but generating the DFSORT OUTFIL 
control cards based on the key break.  If you want I can show you how to 
generate the IEBUPDTE sysin cards or for that matter any IBM utility 
control cards using DFSORT.  Send me an email and we can discuss it 
offline.

Thanks,
Kolusu
DFSORT Development

IBM Mainframe Discussion List  wrote on 
08/21/2014 09:28:51 AM:

> From: "Hardee, Chuck" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/21/2014 09:29 AM
> Subject: Re: DF/SORT question (challenge?)
> Sent by: IBM Mainframe Discussion List 
> 
> Okay, let me say up front, I know nothing about the abilities of 
> SORT other than simple sort this file on these keys and give me the 
> output in this file. Okay, we're good?
> 
> Here's my question. If (can) sort insert records into its output on 
> a break in key?
> If so, why not sort the input file and, on each key break, generate 
> an IEBUPDTE add control card and the write the record that belong to
> that card until the next key break. Do this for each key break and 
> the resulting output file would be an IEUPDTE input stream that 
> would then be fed into an IEBUPDTE job step that allocates a new PDS
> (e) and populates the members.
> 
> No need to dynamically create a dataset/member for every key break, 
> just a single PS type output file, in key sequence, with control 
> cards as needed.
> 
> Admittedly the control cards needed may be a bit more than a simple 
> add/insert (don't recall what terminology IEBUPDTE uses, haven't 
> used it in a while), and then there's the termination signal for 
> each member, but if the idea has merit, well, it's worth a try.
> 
> Of course, all bets are off if the OP needs a unique PS type file 
> for each key versus a member in a PDS(e) for each key.
> 
> Thanks for entertaining this idea.
> 
> Chuck
> 
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration
> CCG Information Technology
> 
> Thermo Fisher Scientific
> 300 Industry Drive | Pittsburgh, PA 15275
> Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 
490-9230
> chuck.har...@thermofisher.com | www.thermofisher.com
> 
> WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or 
> copying of this e-mail or the information herein by anyone other 
> than the intended recipient, or an employee or agent of a system 
> responsible for delivering the message to the intended recipient, is
> prohibited. If you are not the intended recipient, please inform the
> sender and delete all copies.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ] On Behalf Of TonyIcloud-OPERA
> Sent: Thursday, August 21, 2014 12:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: DF/SORT question (challenge?)
> 
> Before I tried the solution cited below (TYVM BTW), I set up a test 
> manually with some interesting results.  The input file is not sorted, 
and 
> I'm only doing SORT FIELDS=COPY.  All I want to do is to break up the 
file 
> into a bunch of little files.
> 
> Test #1. Read my input file, 229,762 records, lrecl=200/27800 FB , 310 
DD 
> statements, 310 OUTFIL INCLUDE statements.  RC=0, 310 members created, 
all 
> the data checks out.
> 
> Test #2. Read the same input file, 321 DD statements, 321 OUTFIL INCLUDE 
 
> statements, abends:
> 
> 10.09.26 JOB08830 IEC036I 
002-B4,IGC0005E,IDSXSB7A,AA,VS09610,4BB9,SHRE16, 
> 452
>   452 IDSX00S.IDSXSB7.SYSE.FIDX03.PDSE
> 
> ICE185A 0 AN S002 ABEND WAS ISSUED BY DFSORT, ANOTHER PROGRAM OR AN EXIT 
 
> (PHASE C 3)
> Quickref provides:
> B4 - Unable to create a system buffer required for PDSE processing.
> 
> I retried with regions of 16M, 32M, 0M, same result.  Not sure if our 
> local storage police exit chokes off my attempt at 0M.
> 
> 
> Interestingly, even though the abend occurred the output PDSE was 
> populated with all 321 members however the last 8 members contain 0 
> records.  Looks like DF/SORT was tripped up at the 313 mark by some 
system 
> limitation. I'm going to consult with my sysprogs before we go to IBM 
for 
> help.
> 
> P.S. My old successful attempt at writing 1,000 members occurred at a 
> different company, a much smaller shop, oddly enough.
> 
> 
> 
> 
> 
> 
> On Wed, 20 Aug 2014 12:01:00 -0500, Sri h Kolusu  
> wrote:
> 
> > Tony,
> >
> > It is quite easy to split the group of records into multiple members. 
> > Here
> > is a sample JCL which will give you the

Tool to analyze corrupted HFS

[mf db]

Hi

Is there a tool to analyze a corrupted hfs dataset ?

Recently one of our hfs was corrupted then a restore helped. The error
message was mvs internal error message. Code 157.

I believe copytree can only verify a path but I am lookinh to analyze hfs
dsn.

Z/os 1.13

Peter

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DF/SORT question (challenge?)

[Sri h Kolusu]

Tony,

ODMAXBF specifies the maximum buffer space DFSORT can use for each OUTFIL 
data set. Since you are creating so many OUTFIL files, it is a good idea 
to lower the buffer space for each OUTFIL.  Check this link which explains 
about ODMAXBF parameter in detail (search for ODMAXBF on that page)

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ice1ca60/3.14

Thanks
Kolusu
DFSORT Development
IBM Corporation



From:   TonyIcloud-OPERA 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   08/21/2014 09:43 AM
Subject:Re: DF/SORT question (challenge?)
Sent by:IBM Mainframe Discussion List 



Geez, I really should read:
1. the sample provided.
2. the book

RC=0

Now I need to find out more about ODMAXBF.  I feel like the guy who bought 
 
the toaster and didn't plug it in.






On Thu, 21 Aug 2014 11:35:25 -0500, Sri h Kolusu  
wrote:

> Tony,
>
> Did you have the override of ODMAXBF?  In my sample JCL I have coded it 
> as
> ODMAXBF=100K overriding the default value of 2M. Can you rerun the job
> with the ODMAXBF parm?
>
> Thanks,
> Kolusu
> DFSORT Development
> IBM Corporation
>
> IBM Mainframe Discussion List  wrote on
> 08/21/2014 09:18:40 AM:
>
>> From: TonyIcloud-OPERA 
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Date: 08/21/2014 09:25 AM
>> Subject: Re: DF/SORT question (challenge?)
>> Sent by: IBM Mainframe Discussion List 
>>
>> Before I tried the solution cited below (TYVM BTW), I set up a test
>> manually with some interesting results.  The input file is not sorted,
> and
>> I'm only doing SORT FIELDS=COPY.  All I want to do is to break up the
> file
>> into a bunch of little files.
>>
>> Test #1. Read my input file, 229,762 records, lrecl=200/27800 FB , 310
> DD
>> statements, 310 OUTFIL INCLUDE statements.  RC=0, 310 members created,
> all
>> the data checks out.
>>
>> Test #2. Read the same input file, 321 DD statements, 321 OUTFIL 
INCLUDE
>
>> statements, abends:
>>
>> 10.09.26 JOB08830 IEC036I
> 002-B4,IGC0005E,IDSXSB7A,AA,VS09610,4BB9,SHRE16,
>> 452
>>   452 IDSX00S.IDSXSB7.SYSE.FIDX03.PDSE
>>
>> ICE185A 0 AN S002 ABEND WAS ISSUED BY DFSORT, ANOTHER PROGRAM OR AN 
EXIT
>
>> (PHASE C 3)
>> Quickref provides:
>> B4 - Unable to create a system buffer required for PDSE processing.
>>
>> I retried with regions of 16M, 32M, 0M, same result.  Not sure if our
>> local storage police exit chokes off my attempt at 0M.
>>
>>
>> Interestingly, even though the abend occurred the output PDSE was
>> populated with all 321 members however the last 8 members contain 0
>> records.  Looks like DF/SORT was tripped up at the 313 mark by some
> system
>> limitation. I'm going to consult with my sysprogs before we go to IBM
> for
>> help.
>>
>> P.S. My old successful attempt at writing 1,000 members occurred at a
>> different company, a much smaller shop, oddly enough.
>>
>>
>>
>>
>>
>>
>> On Wed, 20 Aug 2014 12:01:00 -0500, Sri h Kolusu 
>> wrote:
>>
>> > Tony,
>> >
>> > It is quite easy to split the group of records into multiple members.
>> > Here
>> > is a sample JCL which will give you the desired results of splitting
> the
>> > first 999 groups of records into a PDSE each containing the group of
>> > records. I also assumed your Input is already sorted on the field you
>> > want
>> > to split. I assumed that the split field is 44 bytes in length. If it
> is
>> > different then you can change it in ALL the places referred by
> KEYBEGIN.
>> >
>> > This job creates a dynamic JCL which will then be submitted via
> INTRDR.
>> > Take a look at the output from Step0200 and then if everything looks
> ok
>> > then change the statement
>> > //SORTOUT  DD SYSOUT=*  to  //SORTOUT  DD SYSOUT=(*,INTRDR),RECFM=FB
>> > If you have more than 999 groups of records we will copy the rest of
> the
>> > records into another file which will then be used as input file to
>> > further
>> > split. I will show you how to build the dynamic JCL's based on that. 
I
>> > chose the split to be 999 groups as the maximum number of DD
> statements
>> > per job step is 3273, based on the number of single DD statements
> allowed
>> > for a TIOT (task input output table) control block size of 64K. This
>> > limit
>> > can be different depending on the installation defined TIOT size. The
>> > IBM-supplied default TIOT size is 32K.
>> >
>> >
> //*
>> > //*  BUILD DYNAMIC OUTFIL CARDS AND DDNAMES FOR EACH GROUP OF RECORDS
> *
>> >
> //*
>> > //STEP0100 EXEC PGM=SORT
>> > //SYSOUT   DD SYSOUT=*
>> > //SORTIN   DD DISP=SHR,DSN=Your Input FB 100 Byte file
>> > //*
>> > //OFCARDS  DD DSN=&&C,DISP=(,PASS),SPACE=(CYL,(20,20),RLSE)
>> > //DDNAMES  DD DSN=&&D,DISP=(,PASS),SPACE=(CYL,(20,20),RLSE)
>> > //SORTOUT  DD DUMMY
>> > //SYSINDD *
>> >   OPTION COPY,NULLOUT=RC4
>> >   OUTREC IFTHEN=(WHEN=GROUP,KEYBEGIN=(1,44),PUSH=(101:ID=4))
>> >  OUTFIL FNAMES=OFCARDS,REMOVECC,NODETAIL,BUILD=(80X),
>> >   INCLUDE=(101

Re: DF/SORT question (challenge?)

[TonyIcloud-OPERA]

Geez, I really should read:
1. the sample provided.
2. the book

RC=0

Now I need to find out more about ODMAXBF.  I feel like the guy who bought  
the toaster and didn't plug it in.







On Thu, 21 Aug 2014 11:35:25 -0500, Sri h Kolusu   
wrote:



Tony,

Did you have the override of ODMAXBF?  In my sample JCL I have coded it  
as

ODMAXBF=100K overriding the default value of 2M. Can you rerun the job
with the ODMAXBF parm?

Thanks,
Kolusu
DFSORT Development
IBM Corporation

IBM Mainframe Discussion List  wrote on
08/21/2014 09:18:40 AM:


From: TonyIcloud-OPERA 
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 08/21/2014 09:25 AM
Subject: Re: DF/SORT question (challenge?)
Sent by: IBM Mainframe Discussion List 

Before I tried the solution cited below (TYVM BTW), I set up a test
manually with some interesting results.  The input file is not sorted,

and

I'm only doing SORT FIELDS=COPY.  All I want to do is to break up the

file

into a bunch of little files.

Test #1. Read my input file, 229,762 records, lrecl=200/27800 FB , 310

DD

statements, 310 OUTFIL INCLUDE statements.  RC=0, 310 members created,

all

the data checks out.

Test #2. Read the same input file, 321 DD statements, 321 OUTFIL INCLUDE



statements, abends:

10.09.26 JOB08830 IEC036I

002-B4,IGC0005E,IDSXSB7A,AA,VS09610,4BB9,SHRE16,

452
  452 IDSX00S.IDSXSB7.SYSE.FIDX03.PDSE

ICE185A 0 AN S002 ABEND WAS ISSUED BY DFSORT, ANOTHER PROGRAM OR AN EXIT



(PHASE C 3)
Quickref provides:
B4 - Unable to create a system buffer required for PDSE processing.

I retried with regions of 16M, 32M, 0M, same result.  Not sure if our
local storage police exit chokes off my attempt at 0M.


Interestingly, even though the abend occurred the output PDSE was
populated with all 321 members however the last 8 members contain 0
records.  Looks like DF/SORT was tripped up at the 313 mark by some

system

limitation. I'm going to consult with my sysprogs before we go to IBM

for

help.

P.S. My old successful attempt at writing 1,000 members occurred at a
different company, a much smaller shop, oddly enough.






On Wed, 20 Aug 2014 12:01:00 -0500, Sri h Kolusu 
wrote:

> Tony,
>
> It is quite easy to split the group of records into multiple members.
> Here
> is a sample JCL which will give you the desired results of splitting

the

> first 999 groups of records into a PDSE each containing the group of
> records. I also assumed your Input is already sorted on the field you
> want
> to split. I assumed that the split field is 44 bytes in length. If it

is

> different then you can change it in ALL the places referred by

KEYBEGIN.

>
> This job creates a dynamic JCL which will then be submitted via

INTRDR.

> Take a look at the output from Step0200 and then if everything looks

ok

> then change the statement
> //SORTOUT  DD SYSOUT=*  to  //SORTOUT  DD SYSOUT=(*,INTRDR),RECFM=FB
> If you have more than 999 groups of records we will copy the rest of

the

> records into another file which will then be used as input file to
> further
> split. I will show you how to build the dynamic JCL's based on that. I
> chose the split to be 999 groups as the maximum number of DD

statements

> per job step is 3273, based on the number of single DD statements

allowed

> for a TIOT (task input output table) control block size of 64K. This
> limit
> can be different depending on the installation defined TIOT size. The
> IBM-supplied default TIOT size is 32K.
>
>

//*

> //*  BUILD DYNAMIC OUTFIL CARDS AND DDNAMES FOR EACH GROUP OF RECORDS

*

>

//*

> //STEP0100 EXEC PGM=SORT
> //SYSOUT   DD SYSOUT=*
> //SORTIN   DD DISP=SHR,DSN=Your Input FB 100 Byte file
> //*
> //OFCARDS  DD DSN=&&C,DISP=(,PASS),SPACE=(CYL,(20,20),RLSE)
> //DDNAMES  DD DSN=&&D,DISP=(,PASS),SPACE=(CYL,(20,20),RLSE)
> //SORTOUT  DD DUMMY
> //SYSINDD *
>   OPTION COPY,NULLOUT=RC4
>   OUTREC IFTHEN=(WHEN=GROUP,KEYBEGIN=(1,44),PUSH=(101:ID=4))
>  OUTFIL FNAMES=OFCARDS,REMOVECC,NODETAIL,BUILD=(80X),
>   INCLUDE=(101,4,ZD,LT,1000),
>   SECTIONS=(101,4,
>   TRAILER3=(3:'OUTFIL FNAMES=OUTF',101,4,',BUILD=(1,100),',
>C'INCLUDE=(101,4,ZD,EQ,',101,4,')')),
>   TRAILER1=(3:'OUTFIL FNAMES=NGRP',101,4,',SAVE')
>  OUTFIL FNAMES=DDNAMES,REMOVECC,NODETAIL,BUILD=(80X),
>   INCLUDE=(101,4,ZD,LT,1000),
>   SECTIONS=(101,4,
>   TRAILER3=('//OUTF',101,4,' DD ',
> 'DISP=SHR,DSN=Your.Split.PDSE(OUTF',101,4,')')),
>   TRAILER1=('//NGRP',101,4,' DD ',
> 'DSN=HLQ.TONYCLD.NGRP',101,4,','/,
> '//',15:'DISP=(NEW,CATLG,DELETE),',/,
> '//',15:'SPACE=(CYL,(100,40),RLSE)',/,
> '//*')
> //*
>

//*

> //*  SUBMIT THE SPLIT JOB TO INTRDR WITH THE ABOVE OUTPUT *
>

//*

> //STEP0200 EXEC  PGM=SORT,COND=(4,EQ,STE

Re: PLI and CICS Symblic Map addressability

[Terry Sambrooks]

Hi 

Sorry to have raised this and thanks in anticipation but my issue is resolve
via a combination of ALLOCATE with SET.

Kind Regards - Terry
 
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Sheffield
S17 3LA
UK
 
Reg : 3767263
 
Outgoing e-mails have been scanned, but it is the recipients responsibility
to ensure their anti-virus software is up to date.
 
 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DF/SORT question (challenge?)

[TonyIcloud-OPERA]

Chuck, not only will I entertain the idea, I'll try it.
I always have had the option of creating PS datasets but over the years  
I've gotten spoiled for writing to a PDSE because the JCL is simpler.  I  
also became spoiled for getting a quick record count for each member by  
3.5ing the MSL.




On Thu, 21 Aug 2014 11:28:51 -0500, Hardee, Chuck  
 wrote:


Okay, let me say up front, I know nothing about the abilities of SORT  
other than simple sort this file on these keys and give me the output in  
this file. Okay, we're good?


Here's my question. If (can) sort insert records into its output on a  
break in key?
If so, why not sort the input file and, on each key break, generate an  
IEBUPDTE add control card and the write the record that belong to that  
card until the next key break. Do this for each key break and the  
resulting output file would be an IEUPDTE input stream that would then  
be fed into an IEBUPDTE job step that allocates a new PDS(e) and  
populates the members.


No need to dynamically create a dataset/member for every key break, just  
a single PS type output file, in key sequence, with control cards as  
needed.


Admittedly the control cards needed may be a bit more than a simple  
add/insert (don't recall what terminology IEBUPDTE uses, haven't used it  
in a while), and then there's the termination signal for each member,  
but if the idea has merit, well, it's worth a try.


Of course, all bets are off if the OP needs a unique PS type file for  
each key versus a member in a PDS(e) for each key.


Thanks for entertaining this idea.

Chuck

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
CCG Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412)  
490-9230

chuck.har...@thermofisher.com | www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying  
of this e-mail or the information herein by anyone other than the  
intended recipient, or an employee or agent of a system responsible for  
delivering the message to the intended recipient, is prohibited. If you  
are not the intended recipient, please inform the sender and delete all  
copies.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On  
Behalf Of TonyIcloud-OPERA

Sent: Thursday, August 21, 2014 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DF/SORT question (challenge?)

Before I tried the solution cited below (TYVM BTW), I set up a test
manually with some interesting results.  The input file is not sorted,  
and
I'm only doing SORT FIELDS=COPY.  All I want to do is to break up the  
file

into a bunch of little files.

Test #1. Read my input file, 229,762 records, lrecl=200/27800 FB , 310 DD
statements, 310 OUTFIL INCLUDE statements.  RC=0, 310 members created,  
all

the data checks out.

Test #2. Read the same input file, 321 DD statements, 321 OUTFIL INCLUDE
statements, abends:

10.09.26 JOB08830 IEC036I  
002-B4,IGC0005E,IDSXSB7A,AA,VS09610,4BB9,SHRE16,

452
  452 IDSX00S.IDSXSB7.SYSE.FIDX03.PDSE

ICE185A 0 AN S002 ABEND WAS ISSUED BY DFSORT, ANOTHER PROGRAM OR AN EXIT
(PHASE C 3)
Quickref provides:
B4 - Unable to create a system buffer required for PDSE processing.

I retried with regions of 16M, 32M, 0M, same result.  Not sure if our
local storage police exit chokes off my attempt at 0M.


Interestingly, even though the abend occurred the output PDSE was
populated with all 321 members however the last 8 members contain 0
records.  Looks like DF/SORT was tripped up at the 313 mark by some  
system

limitation. I'm going to consult with my sysprogs before we go to IBM for
help.

P.S. My old successful attempt at writing 1,000 members occurred at a
different company, a much smaller shop, oddly enough.






On Wed, 20 Aug 2014 12:01:00 -0500, Sri h Kolusu 
wrote:


Tony,

It is quite easy to split the group of records into multiple members.
Here
is a sample JCL which will give you the desired results of splitting the
first 999 groups of records into a PDSE each containing the group of
records. I also assumed your Input is already sorted on the field you
want
to split. I assumed that the split field is 44 bytes in length. If it is
different then you can change it in ALL the places referred by KEYBEGIN.

This job creates a dynamic JCL which will then be submitted via INTRDR.
Take a look at the output from Step0200 and then if everything looks ok
then change the statement
//SORTOUT  DD SYSOUT=*  to  //SORTOUT  DD SYSOUT=(*,INTRDR),RECFM=FB
If you have more than 999 groups of records we will copy the rest of the
records into another file which will then be used as input file to
further
split. I will show you how to build the dynamic JCL's based on that. I
chose the split to be 999 groups as the maximum number of DD statements
per job step is 3273, based on the number of single DD statements  
allowed

for a

Re: DF/SORT question (challenge?)

[Sri h Kolusu]

Tony,

Did you have the override of ODMAXBF?  In my sample JCL I have coded it as 
ODMAXBF=100K overriding the default value of 2M. Can you rerun the job 
with the ODMAXBF parm? 

Thanks,
Kolusu
DFSORT Development
IBM Corporation

IBM Mainframe Discussion List  wrote on 
08/21/2014 09:18:40 AM:

> From: TonyIcloud-OPERA 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/21/2014 09:25 AM
> Subject: Re: DF/SORT question (challenge?)
> Sent by: IBM Mainframe Discussion List 
> 
> Before I tried the solution cited below (TYVM BTW), I set up a test 
> manually with some interesting results.  The input file is not sorted, 
and 
> I'm only doing SORT FIELDS=COPY.  All I want to do is to break up the 
file 
> into a bunch of little files.
> 
> Test #1. Read my input file, 229,762 records, lrecl=200/27800 FB , 310 
DD 
> statements, 310 OUTFIL INCLUDE statements.  RC=0, 310 members created, 
all 
> the data checks out.
> 
> Test #2. Read the same input file, 321 DD statements, 321 OUTFIL INCLUDE 
 
> statements, abends:
> 
> 10.09.26 JOB08830 IEC036I 
002-B4,IGC0005E,IDSXSB7A,AA,VS09610,4BB9,SHRE16, 
> 452
>   452 IDSX00S.IDSXSB7.SYSE.FIDX03.PDSE
> 
> ICE185A 0 AN S002 ABEND WAS ISSUED BY DFSORT, ANOTHER PROGRAM OR AN EXIT 
 
> (PHASE C 3)
> Quickref provides:
> B4 - Unable to create a system buffer required for PDSE processing.
> 
> I retried with regions of 16M, 32M, 0M, same result.  Not sure if our 
> local storage police exit chokes off my attempt at 0M.
> 
> 
> Interestingly, even though the abend occurred the output PDSE was 
> populated with all 321 members however the last 8 members contain 0 
> records.  Looks like DF/SORT was tripped up at the 313 mark by some 
system 
> limitation. I'm going to consult with my sysprogs before we go to IBM 
for 
> help.
> 
> P.S. My old successful attempt at writing 1,000 members occurred at a 
> different company, a much smaller shop, oddly enough.
> 
> 
> 
> 
> 
> 
> On Wed, 20 Aug 2014 12:01:00 -0500, Sri h Kolusu  
> wrote:
> 
> > Tony,
> >
> > It is quite easy to split the group of records into multiple members. 
> > Here
> > is a sample JCL which will give you the desired results of splitting 
the
> > first 999 groups of records into a PDSE each containing the group of
> > records. I also assumed your Input is already sorted on the field you 
> > want
> > to split. I assumed that the split field is 44 bytes in length. If it 
is
> > different then you can change it in ALL the places referred by 
KEYBEGIN.
> >
> > This job creates a dynamic JCL which will then be submitted via 
INTRDR.
> > Take a look at the output from Step0200 and then if everything looks 
ok
> > then change the statement
> > //SORTOUT  DD SYSOUT=*  to  //SORTOUT  DD SYSOUT=(*,INTRDR),RECFM=FB
> > If you have more than 999 groups of records we will copy the rest of 
the
> > records into another file which will then be used as input file to 
> > further
> > split. I will show you how to build the dynamic JCL's based on that. I
> > chose the split to be 999 groups as the maximum number of DD 
statements
> > per job step is 3273, based on the number of single DD statements 
allowed
> > for a TIOT (task input output table) control block size of 64K. This 
> > limit
> > can be different depending on the installation defined TIOT size. The
> > IBM-supplied default TIOT size is 32K.
> >
> > 
//*
> > //*  BUILD DYNAMIC OUTFIL CARDS AND DDNAMES FOR EACH GROUP OF RECORDS 
*
> > 
//*
> > //STEP0100 EXEC PGM=SORT
> > //SYSOUT   DD SYSOUT=*
> > //SORTIN   DD DISP=SHR,DSN=Your Input FB 100 Byte file
> > //*
> > //OFCARDS  DD DSN=&&C,DISP=(,PASS),SPACE=(CYL,(20,20),RLSE)
> > //DDNAMES  DD DSN=&&D,DISP=(,PASS),SPACE=(CYL,(20,20),RLSE)
> > //SORTOUT  DD DUMMY
> > //SYSINDD *
> >   OPTION COPY,NULLOUT=RC4
> >   OUTREC IFTHEN=(WHEN=GROUP,KEYBEGIN=(1,44),PUSH=(101:ID=4))
> >  OUTFIL FNAMES=OFCARDS,REMOVECC,NODETAIL,BUILD=(80X),
> >   INCLUDE=(101,4,ZD,LT,1000),
> >   SECTIONS=(101,4,
> >   TRAILER3=(3:'OUTFIL FNAMES=OUTF',101,4,',BUILD=(1,100),',
> >C'INCLUDE=(101,4,ZD,EQ,',101,4,')')),
> >   TRAILER1=(3:'OUTFIL FNAMES=NGRP',101,4,',SAVE')
> >  OUTFIL FNAMES=DDNAMES,REMOVECC,NODETAIL,BUILD=(80X),
> >   INCLUDE=(101,4,ZD,LT,1000),
> >   SECTIONS=(101,4,
> >   TRAILER3=('//OUTF',101,4,' DD ',
> > 'DISP=SHR,DSN=Your.Split.PDSE(OUTF',101,4,')')),
> >   TRAILER1=('//NGRP',101,4,' DD ',
> > 'DSN=HLQ.TONYCLD.NGRP',101,4,','/,
> > '//',15:'DISP=(NEW,CATLG,DELETE),',/,
> > '//',15:'SPACE=(CYL,(100,40),RLSE)',/,
> > '//*')
> > //*
> > 
//*
> > //*  SUBMIT THE SPLIT JOB TO INTRDR WITH THE ABOVE OUTPUT *
> > 
//*
> > //STEP0200 EXEC  PGM=SORT,COND=(4,EQ,STEP0100)
> > //SYSOUT   DD SYSOUT=*
> > //

Re: SMF records for SYSOUT file

[Barry Merrill]

The TYPE 26 Record contains several timestamps, including the
Start and End of "SYSOUT Processing" for the JOB, and the
Purge time, and it has the SYSTEM on which of the JES events
 SYSREAD SYSCVRT SYSEXEC SYSOUTP and SYSJPUR.

Barry






-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Donald J.
Sent: Thursday, August 21, 2014 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF records for SYSOUT file

The problem was that the file was not showing up yet in the JES3 queue.  A 
display of the printer showed nothing queued, yet user said a transaction had 
been queued to the printer 10 minutes ago.  5 minutes later the file is queued 
to JES3 and VPS immediately printed it after 1 millisecond. Not a VPS issue.

--
  Donald J.
  dona...@4email.net

> >What type of setting are you referring to?
> 
> Some possible settings, YMMV:
   vps parameters listed
> All of the very best for you.
> 
> Groete / Greetings
> Elardus Engelbrecht
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
http://www.fastmail.fm - A no graphics, no pop-ups email service

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DF/SORT question (challenge?)

[Hardee, Chuck]

Okay, let me say up front, I know nothing about the abilities of SORT other 
than simple sort this file on these keys and give me the output in this file. 
Okay, we're good?

Here's my question. If (can) sort insert records into its output on a break in 
key?
If so, why not sort the input file and, on each key break, generate an IEBUPDTE 
add control card and the write the record that belong to that card until the 
next key break. Do this for each key break and the resulting output file would 
be an IEUPDTE input stream that would then be fed into an IEBUPDTE job step 
that allocates a new PDS(e) and populates the members.

No need to dynamically create a dataset/member for every key break, just a 
single PS type output file, in key sequence, with control cards as needed.

Admittedly the control cards needed may be a bit more than a simple add/insert 
(don't recall what terminology IEBUPDTE uses, haven't used it in a while), and 
then there's the termination signal for each member, but if the idea has merit, 
well, it's worth a try.

Of course, all bets are off if the OP needs a unique PS type file for each key 
versus a member in a PDS(e) for each key.

Thanks for entertaining this idea.

Chuck

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
CCG Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
chuck.har...@thermofisher.com | www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of TonyIcloud-OPERA
Sent: Thursday, August 21, 2014 12:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DF/SORT question (challenge?)

Before I tried the solution cited below (TYVM BTW), I set up a test  
manually with some interesting results.  The input file is not sorted, and  
I'm only doing SORT FIELDS=COPY.  All I want to do is to break up the file  
into a bunch of little files.

Test #1. Read my input file, 229,762 records, lrecl=200/27800 FB , 310 DD  
statements, 310 OUTFIL INCLUDE statements.  RC=0, 310 members created, all  
the data checks out.

Test #2. Read the same input file, 321 DD statements, 321 OUTFIL INCLUDE  
statements, abends:

10.09.26 JOB08830 IEC036I 002-B4,IGC0005E,IDSXSB7A,AA,VS09610,4BB9,SHRE16,  
452
  452 IDSX00S.IDSXSB7.SYSE.FIDX03.PDSE

ICE185A 0 AN S002 ABEND WAS ISSUED BY DFSORT, ANOTHER PROGRAM OR AN EXIT  
(PHASE C 3)
Quickref provides:
B4 - Unable to create a system buffer required for PDSE processing.

I retried with regions of 16M, 32M, 0M, same result.  Not sure if our  
local storage police exit chokes off my attempt at 0M.


Interestingly, even though the abend occurred the output PDSE was  
populated with all 321 members however the last 8 members contain 0  
records.  Looks like DF/SORT was tripped up at the 313 mark by some system  
limitation. I'm going to consult with my sysprogs before we go to IBM for  
help.

P.S. My old successful attempt at writing 1,000 members occurred at a  
different company, a much smaller shop, oddly enough.






On Wed, 20 Aug 2014 12:01:00 -0500, Sri h Kolusu   
wrote:

> Tony,
>
> It is quite easy to split the group of records into multiple members.  
> Here
> is a sample JCL which will give you the desired results of splitting the
> first 999 groups of records into a PDSE each containing the group of
> records. I also assumed your Input is already sorted on the field you  
> want
> to split. I assumed that the split field is 44 bytes in length. If it is
> different then you can change it in ALL the places referred by KEYBEGIN.
>
> This job creates a dynamic JCL which will then be submitted via INTRDR.
> Take a look at the output from Step0200 and then if everything looks ok
> then change the statement
> //SORTOUT  DD SYSOUT=*  to  //SORTOUT  DD SYSOUT=(*,INTRDR),RECFM=FB
> If you have more than 999 groups of records we will copy the rest of the
> records into another file which will then be used as input file to  
> further
> split. I will show you how to build the dynamic JCL's based on that. I
> chose the split to be 999 groups as the maximum number of DD statements
> per job step is 3273, based on the number of single DD statements allowed
> for a TIOT (task input output table) control block size of 64K. This  
> limit
> can be different depending on the installation defined TIOT size. The
> IBM-supplied default TIOT size is 32K.
>
> //*
> //*  BUILD DYNAMIC OUTFIL CARDS AND DDNAMES FOR EACH GROUP OF RECORDS 

Test post, only

[Peter Hunkeler]

I'm sorry to disturb you. I'm invesgating some forum formatting issues.
  This line is prefixed with 10 blanks.
 This line is prefixed with 5 blanks. And this part is prefixed by 
10 blanks.

Last line begins on position1.

--
Peter Hunkeler





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DF/SORT question (challenge?)

[TonyIcloud-OPERA]

Before I tried the solution cited below (TYVM BTW), I set up a test  
manually with some interesting results.  The input file is not sorted, and  
I'm only doing SORT FIELDS=COPY.  All I want to do is to break up the file  
into a bunch of little files.


Test #1. Read my input file, 229,762 records, lrecl=200/27800 FB , 310 DD  
statements, 310 OUTFIL INCLUDE statements.  RC=0, 310 members created, all  
the data checks out.


Test #2. Read the same input file, 321 DD statements, 321 OUTFIL INCLUDE  
statements, abends:


10.09.26 JOB08830 IEC036I 002-B4,IGC0005E,IDSXSB7A,AA,VS09610,4BB9,SHRE16,  
452

 452 IDSX00S.IDSXSB7.SYSE.FIDX03.PDSE

ICE185A 0 AN S002 ABEND WAS ISSUED BY DFSORT, ANOTHER PROGRAM OR AN EXIT  
(PHASE C 3)

Quickref provides:
B4 - Unable to create a system buffer required for PDSE processing.

I retried with regions of 16M, 32M, 0M, same result.  Not sure if our  
local storage police exit chokes off my attempt at 0M.



Interestingly, even though the abend occurred the output PDSE was  
populated with all 321 members however the last 8 members contain 0  
records.  Looks like DF/SORT was tripped up at the 313 mark by some system  
limitation. I'm going to consult with my sysprogs before we go to IBM for  
help.


P.S. My old successful attempt at writing 1,000 members occurred at a  
different company, a much smaller shop, oddly enough.







On Wed, 20 Aug 2014 12:01:00 -0500, Sri h Kolusu   
wrote:



Tony,

It is quite easy to split the group of records into multiple members.  
Here

is a sample JCL which will give you the desired results of splitting the
first 999 groups of records into a PDSE each containing the group of
records. I also assumed your Input is already sorted on the field you  
want

to split. I assumed that the split field is 44 bytes in length. If it is
different then you can change it in ALL the places referred by KEYBEGIN.

This job creates a dynamic JCL which will then be submitted via INTRDR.
Take a look at the output from Step0200 and then if everything looks ok
then change the statement
//SORTOUT  DD SYSOUT=*  to  //SORTOUT  DD SYSOUT=(*,INTRDR),RECFM=FB
If you have more than 999 groups of records we will copy the rest of the
records into another file which will then be used as input file to  
further

split. I will show you how to build the dynamic JCL's based on that. I
chose the split to be 999 groups as the maximum number of DD statements
per job step is 3273, based on the number of single DD statements allowed
for a TIOT (task input output table) control block size of 64K. This  
limit

can be different depending on the installation defined TIOT size. The
IBM-supplied default TIOT size is 32K.

//*
//*  BUILD DYNAMIC OUTFIL CARDS AND DDNAMES FOR EACH GROUP OF RECORDS *
//*
//STEP0100 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD DISP=SHR,DSN=Your Input FB 100 Byte file
//*
//OFCARDS  DD DSN=&&C,DISP=(,PASS),SPACE=(CYL,(20,20),RLSE)
//DDNAMES  DD DSN=&&D,DISP=(,PASS),SPACE=(CYL,(20,20),RLSE)
//SORTOUT  DD DUMMY
//SYSINDD *
  OPTION COPY,NULLOUT=RC4
  OUTREC IFTHEN=(WHEN=GROUP,KEYBEGIN=(1,44),PUSH=(101:ID=4))
 OUTFIL FNAMES=OFCARDS,REMOVECC,NODETAIL,BUILD=(80X),
  INCLUDE=(101,4,ZD,LT,1000),
  SECTIONS=(101,4,
  TRAILER3=(3:'OUTFIL FNAMES=OUTF',101,4,',BUILD=(1,100),',
   C'INCLUDE=(101,4,ZD,EQ,',101,4,')')),
  TRAILER1=(3:'OUTFIL FNAMES=NGRP',101,4,',SAVE')
 OUTFIL FNAMES=DDNAMES,REMOVECC,NODETAIL,BUILD=(80X),
  INCLUDE=(101,4,ZD,LT,1000),
  SECTIONS=(101,4,
  TRAILER3=('//OUTF',101,4,' DD ',
'DISP=SHR,DSN=Your.Split.PDSE(OUTF',101,4,')')),
  TRAILER1=('//NGRP',101,4,' DD ',
'DSN=HLQ.TONYCLD.NGRP',101,4,','/,
'//',15:'DISP=(NEW,CATLG,DELETE),',/,
'//',15:'SPACE=(CYL,(100,40),RLSE)',/,
'//*')
//*
//*
//*  SUBMIT THE SPLIT JOB TO INTRDR WITH THE ABOVE OUTPUT *
//*
//STEP0200 EXEC  PGM=SORT,COND=(4,EQ,STEP0100)
//SYSOUT   DD SYSOUT=*
//SYSINDD *
   OPTION COPY
//*SORTOUT  DD SYSOUT=(*,INTRDR),RECFM=FB
//SORTOUT  DD SYSOUT=*
//SORTIN   DD DATA,DLM=$$
//SPLTTONY JOB (DA26,001,098,J69),'TONY',
// CLASS=A,
// MSGCLASS=H,
// MSGLEVEL=(1,1),
// TIME=(,15),
// NOTIFY=USERID
//*
//SPLTSTEP EXEC PGM=SORT,REGION=0M
//SYSOUT   DD SYSOUT=*
//SORTIN   DD DISP=SHR,DSN=Your Input FB 100 Byte file
$$
// DD DSN=&D,DISP=(OLD,PASS)
// DD DATA,DLM=$$
//SYSINDD *
  OPTION COPY,ODMAXBF=100K
  OUTREC IFTHEN=(WHEN=GROUP,KEYBEGIN=(1,44),PUSH=(101:ID=4))
$$
// DD DSN=&C,DISP=(OLD,PASS)
//*
Further if you have any questions please let me know

Thanks,
Kolusu
DFSORT Development
IBM Corporation

IBM Mainframe Discussion List  wrote on
08/20

Re: SMF records for SYSOUT file

[Donald J.]

The problem was that the file was not showing up yet
in the JES3 queue.  A display of the printer showed
nothing queued, yet user said a transaction had been
queued to the printer 10 minutes ago.  5 minutes later 
the file is queued to JES3 and VPS immediately 
printed it after 1 millisecond. Not a VPS issue.

-- 
  Donald J.
  dona...@4email.net

> >What type of setting are you referring to?
> 
> Some possible settings, YMMV:
   vps parameters listed
> All of the very best for you.
> 
> Groete / Greetings
> Elardus Engelbrecht
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

-- 
http://www.fastmail.fm - A no graphics, no pop-ups email service

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

PLI and CICS Symblic Map addressability

[Terry Sambrooks]

Hi 

I am not sure whether this is a CICS issues, a PLI Issue or just general
ignorance on my part.

I have written a suite of programs in COBOL for use with a CICS Command
Level class and am now attempting to convert them so that I have a PLI
version of the programs.

Focusing on one of the programs I find that it compiles with COND CODE 0004
and the W-level message states:

"IBM1085I W  46.0BMSMAPBR may be uninitialized when used."

Initially I ignored this and ran the transaction which promptly abended AEYD
indicating that an attempted was being made to use inaccessible storage. I
have attempted to Google for a resolution, and looked in both the PLI and
CICS manuals but am not making much headway. The symbolic map shows that
M100MNUI is BASED on BMSMAPBR. I had assumed that BMSMAPBR would be
populated at the point of use, but this looks like an incorrect assumption.

I would appreciate guidance on what may need to be done to ensure that
BMSMAPBR pointed to the correct storage location.

Kind Regards - Terry
 
Director
KMS-IT Limited
228 Abbeydale Road South
Dore
Sheffield
S17 3LA
UK
 
Reg : 3767263
 
Outgoing e-mails have been scanned, but it is the recipients responsibility
to ensure their anti-virus software is up to date.
 
 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way to tell in code if in Supervisor State?

[Ed Jaffe]

On 8/20/2014 6:47 AM, Charles Mills wrote:

Ah! Interesting. Thanks. Never used it before. SYNCH = "CALL with MODESET
and Return as you were."


Usually SYNCH is used to call a problem state routine from a supervisor 
state routine (that's how we use it), but it can be a convenient way to 
restore state the other way as well. BAKR/PR can do something similar at 
much less CPU cost.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DF/SORT question (challenge?)

[John McKown]

On Thu, Aug 21, 2014 at 9:37 AM, Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net> wrote:

> In , on 08/20/2014
>at 09:34 AM, TonyIcloud-OPERA  said:
>
> >I have a dataset that contains records with a field, by which I need
> >to create a separate dataset that would contain all occurrences of
> >that field.
>
> ITYM a separate file for each value in that field. If I were doing
> this, I'd sort on the field and have an output exit that allocated and
> opened the dataset for each value, closed and freed it on a control
> break and told the sort not to create any output.
>

You could even do that in, *gasp*, COBOL with an OUTPUT PROCEDURE IS phrase.


>
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>


-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DF/SORT question (challenge?)

[Shmuel Metz (Seymour J.)]

In , on 08/20/2014
   at 09:34 AM, TonyIcloud-OPERA  said:

>I have a dataset that contains records with a field, by which I need
>to create a separate dataset that would contain all occurrences of
>that field.

ITYM a separate file for each value in that field. If I were doing
this, I'd sort on the field and have an output exit that allocated and
opened the dataset for each value, closed and freed it on a control
break and told the sort not to create any output.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Possible method to "post" large files, for example and such

[Shmuel Metz (Seymour J.)]

In
,
on 08/20/2014
   at 09:18 AM, John McKown  said:

>Especially if the answer includes complicated code. I really don't 
>much like posting much code in email because many (most?) email 
>clients canl reformat the code in such as way as to make it nearly 
>useless.

Is that true even if you indent the code? Does it help if you use
format-flowed and have hard line ends in the quoted code?

>But if, for whatever reason, I decide that the only way to really 
>answer a question is with a complete program, I plan to use
>the "gist" capability on http://github.com,

I'd much prefer having it in the message.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way to tell in code if in Supervisor State?

[Shmuel Metz (Seymour J.)]

In <04dd01cfbc7d$5ba33430$12e99c90$@mcn.org>, on 08/20/2014
   at 03:47 PM, Charles Mills  said:

>What would be the performance difference?

The SVC path length for the SVC 12 (SYNCH) and SVC 3 (EXIT), in
addition to the path length of the SVC routines themselves. The EPSW
and associated housekeeping should be a lot faster, but if it's
infrequent then I'd go for whichever is most convenient.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RD&T Features

[Thomas Conley]

On 8/21/2014 8:05 AM, Mike Hammock wrote:



Date:Thu, 21 Aug 2014 11:00:07 -0400
From:Mike Hammock
Subject: Re: RD&T features

The licenses that are licensed by number of users (either named or
floating) always come in 3-processor mode, but the RVU licenses, as
implied above, come with a variable number of enabled processors, from 1
upward.  The latest version of zPDT enforces the "N+1" cores to enabled
processor restriction that has just been a recommendation in the past.
For most workloads, one processor (running  on at least two cores) will
provide very good performance for one or multiple users.  We have
systems with 15 - 20 typical developers who are very happy on a system
with a single enabled processor.

Mike Hammock
ITC



Mike makes a good point.  I've been concentrating on the Single User 
RD&T license for Personal Use.  The RVU licenses for RD&T are listed at 
17K for annual and 37K for perpetual.  Those are out of my price range 
and way overkill for me.  I'll be more clear going forward.


Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question: Possible to send email, with an attachment from the Mainframe?

[Paul Gilmartin]

On Wed, 20 Aug 2014 20:14:55 -0400, Thomas Kern wrote:
>
>I have used XMITIP to send PDFs from a z/VM system. The PDFs that I
>created to be send out were created as ASCII data then they were
>transmitted at S/MIME attachments of pure "DATA" to Windows recipients.
>The PDFS have been "compressed and encrypted" in a PDF fashion but it is
>all ASCII data.
> 
I'm astonished and curious.  XMITIP is available for both z/OS and z/VM?
I'm more familiar with VM SMTP than z/OS -- we haven't the latter
operational.

I believe the SMTP VM/task accepts EBCDIC files in the spool as either
plain text or NETDATA format; decodes the NETDATA, and translates
EBCDIC to ASCII for network transmission.  Does it treat apparent
binary attachments specially, suppressing EBCDIC<->ASCII conversion?
Is the code page pair constant within SMTP (037<->819?), regardless
of locale of the host system?  What about the LF/NL nightmare.  I
know CMS Pipelines translates 0x25<->0x0A; z/OS iconv 0x15<->0x0a.
The SMTP server will add a network line separator, ASCII 
after each record (someone said FB 80).  And this all gets undone
at the other end!?  You said ASCII data.  Does this mean no code
points above 0x7F?

I'm curious.  Will someone volunteer to send me a brief PDF attachment,
via XMITIP, to my address above?  (LISTSERV would discard it.)

When I email to my VM account, the MIME headers may
say character set is ISO8859-1, but the document has obviously been
translated to EBCDIC.  Shouldn't the MIME headers be adjsted to
reflect this translation, e.g. to IBM-1047?

Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RD&T Features

[Thomas Conley]

On 8/21/2014 8:23 AM, Rouse, Willie wrote:

Slightly OT Does the base offering have the Rexx compiler?


Respectfully,
Willie C. Rouse
Senior Mainframe Consultant
Prince George's County, Maryland
Office of Information Technology
9201 Basil Court/ Room B8
Largo, MD 20774
Voice: 301-883-7189
Fax: 301-883-3790



Willie,

Yes.

Regards,
Tom Conley

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Hard Capping an LPAR

[Herring, Bobby]

I am not sure, either. We were hoping they would negotiate if we limited them 
to the single severely crippled LPAR.

I'd like to name then here but that might complicate things later.
We've had good luck with every other vendor except these two.
Both are single use products that don't grow with MIPS upgrades. But, the cost 
does.

Hello to you, too! It's been quite a while since our conference calls.

Bobby

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Martin Packer
Sent: Thursday, August 21, 2014 4:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Hard Capping an LPAR

Not sure that addresses the licence cost issue. BTW hello Bobby!

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator, Worldwide Banking Center of 
Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   "Vernooij, CP (SPLXM) - KLM" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   21/08/2014 07:37
Subject:Re: Hard Capping an LPAR
Sent by:IBM Mainframe Discussion List 



If you need to cap a single application, put it in a Resource Group and give 
that a cap.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Herring, Bobby
Sent: Thursday, August 21, 2014 05:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hard Capping an LPAR

Thank you, that's what I needed to know.

We are trying to limit two problem ISV's that are MIPS based charging. We need 
to do a major CPU upgrade and these two products are making it too painful. One 
can't be gotten rid of easily. The other can be replaced with some pain but is 
doable.

If we can isolate them to the hard capped, very limited use LPAR, then maybe we 
can negotiate with them.

Thanks, Bobby



From: IBM Mainframe Discussion List  on behalf of Al 
Sherkow Digest 
Sent: Wednesday, August 20, 2014 8:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Hard Capping an LPAR

Putting a hard cap on an LPAR limits the LPAR's use of the CPU; it does not 
limit a single application.

Yes you specify that on the HMC. 5% of 2000 is 100.

Al Sherkow, I/S Management Strategies, Ltd.
Consulting Expertise on IBM Workload License Charges (WLC), LCS Software and 
Seminars on IBM Mainframe Software Pricing
+1 414 332-3062
[http://infonet.txfb-ins.com//images//email-signature-image.jpg]


WWW.TXFB-INS.COM

Texas Farm Bureau Insurance received the highest numerical score among auto 
insurance providers in Texas in the proprietary J.D. Power 2012-2014 U.S. Auto 
Insurance Studies SM (Central Region in 2012). 2014 Study based on 44,661 total 
responses measuring 8 providers in Texas and measures opinions of consumers 
with their auto insurance provider. Proprietary study results are based on 
experiences and perceptions of consumers surveyed March-April 2014. Your 
experiences may vary. Visit jdpower.com. © 2014 Texas Farm Bureau Insurance 
Companies.

CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is 
covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 
2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to you in 
error, do not read it. If you are not the intended recipient, you are hereby 
notified that any retention, dissemination, distribution, or copying of this 
communication is strictly prohibited. Please reply to the sender that you have 
received the message in error, then delete it. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Possible method to "post" large files, for example and such

[John McKown]

On Thu, Aug 21, 2014 at 8:34 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 21 Aug 2014 07:35:18 -0500, Shane Ginnane wrote:
>
> >On Thu, 21 Aug 2014 06:51:20 -0500, John McKown wrote:
> >
> >>Perhaps I am out-of-date. What I was trying to do by using github was to
> >>reduce the number of copies of things "flying around on the Internet" and
> >>thus to decrease bandwidth on the backbone networks. And to not "shove"
> >>large, possibly unwanted,  files to everybody here.
> >
> >Sounds good. We've all got private accounts, and can pull it out of the
> work-space in need.
> >
> Moving work product out through the security perimiter may be a
> policy violation in some organizations.
>
> -- gil
>
>
If that is the case, then wouldn't doing a cut and paste from an email be a
just as much a violation as downloading a file from a web site? Just
asking.  We have web site policies here too. As is reasonable. I just don't
understand why I can browse "guns and ammo" sites but not "game" sites.
OTOH, I know how to totally bypass all the restrictions (don't tell the LAN
people). But I don't because it just not my style.

-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Possible method to "post" large files, for example and such

[Paul Gilmartin]

On Thu, 21 Aug 2014 07:35:18 -0500, Shane Ginnane wrote:

>On Thu, 21 Aug 2014 06:51:20 -0500, John McKown wrote:
>
>>Perhaps I am out-of-date. What I was trying to do by using github was to
>>reduce the number of copies of things "flying around on the Internet" and
>>thus to decrease bandwidth on the backbone networks. And to not "shove"
>>large, possibly unwanted,  files to everybody here.
>
>Sounds good. We've all got private accounts, and can pull it out of the 
>work-space in need.
> 
Moving work product out through the security perimiter may be a
policy violation in some organizations.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Possible method to "post" large files, for example and such

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Jantje.
> 
> [ snip ]
> 
> My company (and I guess many others) blocks access to all such file-sharing 
> services, unfortunately.
> 
> Maybe you could consider using attachments to the posts?

I believe the listserv is configured to discard attachments before relaying 
posts.

-jc-

**
Information contained in this e-mail message and in any attachments thereto is 
confidential. If you are not the intended recipient, please destroy this 
message, delete any copies held on your systems, notify the sender immediately, 
and refrain from using or disclosing all or any part of its content to any 
other person.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF records for SYSOUT file

[Elardus Engelbrecht]

Donald J. wrote:

>> WAD. You can reduce the delay via a setting. If you're still having delay 
>> problems, check your JES3 performance.
>What type of setting are you referring to?

Some possible settings, YMMV:

INTERVAL=(MMSS,HHMM) INTERVAL FOR CERTAIN VPS FUNCTIONS
MRDINTVL=MMSS MISSING RESPONSE INTERVAL
MAXPRTS=(,???), MAXIMUM NUMBER OF PRINTERS DEFINED AND BUSY
TCPMRD=??,   MISSING TCPIP RESPONSE
TCPDISC=(N,Y,000?),  WAIT ? SEC BEFORE NEXT CONNECTION
RETRIES=?,  REQUEUE INTERNAL REROUTE 
REQROUTE=Y,  REQUEUE INTERNAL REROUTE

Above settings is about delays, missing response from TCP/IP and printers. You 
should look at other settings about sizing of work pieces, performance 
settings, etc.

We have customized over the years those and other settings (for VPS, JES2 (not 
JES3), TCP/IP, etc) for total of over 2-25000 printers countrywide.

>This problem only occurs at a few random times, and not on all files, so I 
>would not think it is a direct result of one parameter setting value.

I agree with you.

Perhaps, you should check how 'random' does this problem occur and with what 
output. Check also from where are the print work coming and how many concurrent 
printers are active and working?

>It appears application level tracing would be required to diagnose the issue.

It is a good idea, perhaps you should ask LRS for help.

About SMF, you can have VPS write its own SMF records, but AFAIK these are VPS 
own type, not type 6. It seemed to me you should go to LRS too about this.

All of the very best for you.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMP/E needed: ++HFSUPD

[Kurt Quackenbush]

++ HFS (MCKL001J)  /* $java_home/lib/security/java.security.sklm */
DISTLIB (AAJVHFS)
SYSLIB  (SAJV17K)
PARM (PATHMODE(0,6,4,4))
LINK ('../lib/security/java.security.sklm')
SHSCRIPT (MCKL001S,POST)
TEXT .

The shellscript MCKL001S in my case handles the pre-copy backup of
the affected files, ...


While I don't know exactly the content of your shell script, I'm 
confused how it makes a copy of the target file "pre-copy" as you say 
since the specification on the SHSCRIPT operand says "POST".  This means 
SMP/E invokes the shell script only after the copy operation, not 
before.  You can of course specify both PRE and POST on SHSCRIPT, thus 
telling SMP/E to invoke the shell script both before the copy and after.


Kurt Quackenbush -- IBM, SMP/E Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DF/SORT question (challenge?)

[Shane Ginnane]

On Thu, 21 Aug 2014 07:35:05 -0500, Paul Gilmartin wrote:

>Limit on number of open files?  OP said "hundreds or thousands".

Rebuke accepted - maybe I can (now) see a need for a sort.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Possible method to "post" large files, for example and such

[David Crayford]

On 21/08/2014 8:35 PM, Shane Ginnane wrote:

On Thu, 21 Aug 2014 06:51:20 -0500, John McKown wrote:


Perhaps I am out-of-date. What I was trying to do by using github was to
reduce the number of copies of things "flying around on the Internet" and
thus to decrease bandwidth on the backbone networks. And to not "shove"
large, possibly unwanted,  files to everybody here.

Sounds good. We've all got private accounts, and can pull it out of the 
work-space in need.


Sounds very good indeed!

If you've got curl installed it's really very easy to download from 
github using it's API.




Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DF/SORT question (challenge?)

[John McKown]

On Thu, Aug 21, 2014 at 7:35 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 20 Aug 2014 19:21:00 -0500, Shane Ginnane wrote:
>
> >awk '{print > "hlq."$1".file"}' dfsort.input
> >
> >Even OMVS should be able to achieve that. Can't see any reason for a sort.
> >
> Limit on number of open files?  OP said "hundreds or thousands".
>
> -- gil
>
>
Good point. Our OMVS MAXFILEPROC is "limited" to 64000. So "hundreds" might
not be a problem. But "thousands" could be since that is a system-wide
limit for all users.


-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DF/SORT question (challenge?)

[Paul Gilmartin]

On Wed, 20 Aug 2014 19:21:00 -0500, Shane Ginnane wrote:

>awk '{print > "hlq."$1".file"}' dfsort.input
>
>Even OMVS should be able to achieve that. Can't see any reason for a sort.
> 
Limit on number of open files?  OP said "hundreds or thousands".

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Possible method to "post" large files, for example and such

[Shane Ginnane]

On Thu, 21 Aug 2014 06:51:20 -0500, John McKown wrote:

>Perhaps I am out-of-date. What I was trying to do by using github was to
>reduce the number of copies of things "flying around on the Internet" and
>thus to decrease bandwidth on the backbone networks. And to not "shove"
>large, possibly unwanted,  files to everybody here.

Sounds good. We've all got private accounts, and can pull it out of the 
work-space in need.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF records for SYSOUT file

[Donald J.]

> WAD. You can reduce the delay via a setting. If you're still having delay
> problems, check your JES3 performance. 

What type of setting are you referring to?
This problem only occurs at a few random times, 
and not on all files, so I would not think it is
a direct result of one parameter setting value.

It appears application level tracing would be
required to diagnose the issue.

-- 
  Donald J.
  dona...@4email.net

On Thu, Aug 21, 2014, at 02:39 AM, Elardus Engelbrecht wrote:
> Barry Merrill wrote:
> 
> >There is no separate SMF record written when data is sent to the JES SPOOL.
> 
> Indeed.
> 
> >And Type 6 records are be written by JES2 or by some SYSOUT processing 
> >packages; some packages that manage spooled output for viewing and/or 
> >printing write their own SMF User SMF records.
> 
> True. VPS can do that too if you wish.
> 
> 
> Donald J. wrote:
> 
> >A user is complaining about a 15 minute delay in her print process showing 
> >up in the JES3 queue and beginning to print on the VPS printer.  The VPS 
> >print time matches the SMF 6 record time.
> 
> WAD. You can reduce the delay via a setting. If you're still having delay
> problems, check your JES3 performance. 
> 
> Note: I'm familiar with VPS from LRS.
> 
> Groete / Greetings
> Elardus Engelbrecht
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

-- 
http://www.fastmail.fm - IMAP accessible web-mail

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RD&T Features

[Rouse, Willie]

Slightly OT Does the base offering have the Rexx compiler?


Respectfully,
Willie C. Rouse
Senior Mainframe Consultant
Prince George's County, Maryland
Office of Information Technology
9201 Basil Court/ Room B8
Largo, MD 20774
Voice: 301-883-7189
Fax: 301-883-3790

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Hammock
Sent: Thursday, August 21, 2014 8:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RD&T Features

Date:Wed, 20 Aug 2014 11:00:07 -0400
From:Thomas Conley 
Subject: Re: RD&T features

On 8/20/2014 6:06 AM, Mainframe Newbie wrote:
> Thank you, Thomas for the crisp answer.
>
> On a similar note, do we know if RD&T works on 1 Core / 1 RVU license?
>
>

AFAIK, RD&T is only sold with a 3-CPU license (I'm in the US, so in another 
country, YMMV).  That's what I have with my RD&T.  I believe IBM did this in 
the US because the 1-CPU licenses they had been offering did not provide the 
best user experience.

Regards,
Tom Conley


Date:Thu, 21 Aug 2014 11:00:07 -0400
From:Mike Hammock
Subject: Re: RD&T features

The licenses that are licensed by number of users (either named or floating) 
always come in 3-processor mode, but the RVU licenses, as implied above, come 
with a variable number of enabled processors, from 1 upward.  The latest 
version of zPDT enforces the "N+1" cores to enabled processor restriction that 
has just been a recommendation in the past.
For most workloads, one processor (running  on at least two cores) will provide 
very good performance for one or multiple users.  We have systems with 15 - 20 
typical developers who are very happy on a system with a single enabled 
processor.

Mike Hammock
ITC


 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: How to reduce batch job's negative impact on the online transaction response time

[Shane Ginnane]

On Thu, 21 Aug 2014 09:16:25 +0800, ibmmain wrote:

 
>  There are more than 10 batch jobs runing during the daytime.How to use WLM 
> to assign 5% CPU to 
> these jobs? 

As mentioned elsewhere, resources classes can do this. May adversely impact the 
batch - especially if the run concurrently.
Note this is only treating the symptom, not the real problem, which is 
inappropriate goals.
   
> If the CPU was used by the batch jobs,the CICS online tran couldn't got the 
> CPU immediately when the tran need more
> CPU even the tran with CPU CRITICAL. how to solve this problem. 

If the CICS trans are over-achieving, they will become donors. 

Are all the AORs in the same service class ?
Are the trans all running on the QR TCB ?
What are the PIs ?.
Are the batch updates running in an (unclassified ?) DB2 enclave ?
...
All sorts of potential influences.

This can't be solved by plucking feathers out of the air.

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RD&T Features

[Mike Hammock]

Date:Wed, 20 Aug 2014 11:00:07 -0400
From:Thomas Conley 
Subject: Re: RD&T features

On 8/20/2014 6:06 AM, Mainframe Newbie wrote:

Thank you, Thomas for the crisp answer.

On a similar note, do we know if RD&T works on 1 Core / 1 RVU license?




AFAIK, RD&T is only sold with a 3-CPU license (I'm in the US, so in
another country, YMMV).  That's what I have with my RD&T.  I believe IBM
did this in the US because the 1-CPU licenses they had been offering did
not provide the best user experience.

Regards,
Tom Conley


Date:Thu, 21 Aug 2014 11:00:07 -0400
From:Mike Hammock
Subject: Re: RD&T features

The licenses that are licensed by number of users (either named or floating) 
always come in 3-processor mode, but the RVU licenses, as implied above, 
come with a variable number of enabled processors, from 1 upward.  The 
latest version of zPDT enforces the "N+1" cores to enabled processor 
restriction that has just been a recommendation in the past.
For most workloads, one processor (running  on at least two cores) will 
provide very good performance for one or multiple users.  We have systems 
with 15 - 20 typical developers who are very happy on a system with a single 
enabled processor.


Mike Hammock
ITC




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way to tell in code if in Supervisor State?

[Peter Relson]

SYNCH is the right method if you are attempting to decrease authority from 
supervisor state to problem state (such as your program is running in 
supervisor state and now needs an exit to get control in problem state 
which is the ESTAE case). It is not an efficient method otherwise.  I'll 
point out also that SYNCH the only proper method to use if you are 
decreasing state authority. While the architecture allows for 
authority-decreasing PC's, z/OS really does not support them and if not 
done properly can easily cause system integrity problems (and I'm not 
going to go into what might entail "properly" because you really shouldn't 
be doing this). I doubt that this limitation is well documented (if at 
all).

The simplest approach is to use BAKR ... PR if all that you want to do is 
to save and then restore the PSW state state.

EPSW will have let you determine whether you are or are not in supervisor 
state.
Since you seem to be able to switch if you want to, you must be authorized 
enough to do so.

So save your current state via BAKR before you switch, us MODESET to 
switch, and restore it by PR.

Note that if you are changing only the PSW key with MODESET the BAKR/PR 
approach is bad because even though the PR will restore the key it will 
not restore the PKM.
For example (but do not do this)
 BAKR
 MODESET KEY=ZERO
 PR

For a normal application, the PKM will have started at x'00C0', will be 
x'8040' after the MODESET and will still be x'8040' after the PR, thus 
leaving the key 8 application with the ability to SPKA to key 0.

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Possible method to "post" large files, for example and such

[John McKown]

On Thu, Aug 21, 2014 at 5:34 AM, Jantje.  wrote:

> On Wed, 20 Aug 2014 09:18:29 -0500, John McKown <
> john.archie.mck...@gmail.com> wrote:
>
> >In the future, I plan to try to answer such questions as completely as
> >possible.
>
> Great. But from what I have read so far on the list, you are already doing
> this. Thanks for that.
>

Thanks for the kind words. My time left may be short because my company is
discontinuing use of z/OS "hard" by no later than Dec 2015. And their plan
will work. Because the part of the business which is serviced by the z/OS
system is being terminated. All current clients have been informed that
their contracts are non-renewable. The new platform of choice is "cloud
based". And that seems to say that the Windows/Linux/AIX/Solaris people's
time is limited too. I know that the company has long stated that "we want
to be out of the IT business". Of course, they'll still need somebody local
for desktop and IP support issues. But they may outsource that to a local
support company like Geeks-R-Us. I'm sure that they will _love_ that.
Children should not be allowed to play with blasting caps.



>
> >answer a question is with a complete program, I plan to use the "gist"
> >capability on http://github.com, rather than clutter up the list,
>
> My company (and I guess many others) blocks access to all such
> file-sharing services, unfortunately.
>

Educate your management? Maybe get them a "clue stick" for Christmas?
. I guess they don't allow access to the CBTTape either? My
condolences!


>
> Maybe you could consider using attachments to the posts?
>

Perhaps I am out-of-date. What I was trying to do by using github was to
reduce the number of copies of things "flying around on the Internet" and
thus to decrease bandwidth on the backbone networks. And to not "shove"
large, possibly unwanted,  files to everybody here.



>
> Cheers,
>
> Jantje.
>
>
-- 
There is nothing more pleasant than traveling and meeting new people!
Genghis Khan

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Best way to tell in code if in Supervisor State?

[Donald Likens]

I wished I asked the list a long time ago on how to do this. I used the 
TESTAUTH macro for a long time to determine the mode entered. However this 
invokes an SVC and to avoid the overhead I now use my own macros that sets a 
flag in memory as well as mod so all I need to do is check the flag.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Strange LRSN value in DB2 Log Records

[Arie Kremer]

Many Thanks Wayne,

We send them the corresponding request. But I really think this is not the
issue. STCK to LRSN Delta is usually defined as no more than a number of
seconds, and we are dealing with years...Moreover, as well as I understand
some (described below) inputs, this is not a clock at all. I compared the
different between some DB2 events (INSERT operation to a table with
TIMESTAMP column setting to CURREMT_TIMESTAMP) and between LRSN in these
events. The different in the column was 2.8 seconds when in LRSN - 1.5
second...


On Wed, Aug 20, 2014 at 9:24 PM, Wayne Driscoll  wrote:

> You will want to check in the BSDS of the DB2 data sharing group (using
> offline utility DSNJU004) to determine if there is a STCK to LRSN Delta
> defined for the data sharing group.  This delta is required when a DB2
> subsystem is converted to data sharing with a (then) current log RBA that
> was greater then the high order 6 bytes of the STCK value.   If this value
> is non-zero, it will need to be subtracted from the LRSN value prior to
> converting it to a timestamp field.
> ==
> Wayne Driscoll
> OMEGAMON DB2 L3 Support/Development
> wdrisco(at)us(dot)ibm(dot)com
> All opinions are mine, and do not represent
> IBM Corporation.
> ==
>
> IBM Mainframe Discussion List  wrote on
> 08/18/2014 09:34:06 AM:
>
> > From: Arie Kremer 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 08/18/2014 09:34 AM
> > Subject: [IBM-MAIN] Strange LRSN value in DB2 Log Records
> > Sent by: IBM Mainframe Discussion List 
> >
> > We use IFI to analyze DB2 logs. "lrh_time" field in the log record header
> > is assumed to contain LRSN in SYSPLEX environment, when LRSN is usually
> > derived from the Coupling Facility clock, i.e. may be be used as a clock.
> > In most cases, this works perfect.
> > We have a customer that their Coupling Facility clock and the clock of
> > other processors are different (5 hours). In their DB2 environment, we
> get
> > LRSN that being converting to the timestamp means the year 2038, and
> seems
> > as not a clock. The values are acceding, and seems as the problem is only
> > when interpreting LRSN as a timestamp.
> > Does somebody know what does it mean? What is this LRSN means and how to
> > convert it to the real time?
> >
> > Many thanks
> > Arie Kremer
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Possible method to "post" large files, for example and such

[Jantje.]

On Wed, 20 Aug 2014 09:18:29 -0500, John McKown  
wrote:

>In the future, I plan to try to answer such questions as completely as
>possible. 

Great. But from what I have read so far on the list, you are already doing 
this. Thanks for that.

>answer a question is with a complete program, I plan to use the "gist"
>capability on http://github.com, rather than clutter up the list, 

My company (and I guess many others) blocks access to all such file-sharing 
services, unfortunately. 

Maybe you could consider using attachments to the posts?

Cheers,

Jantje.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Hard Capping an LPAR

[Vernooij, CP (SPLXM) - KLM]

This way one can keep the single application under control, without impacting 
other applications in the LPAR.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Martin Packer
Sent: Thursday, August 21, 2014 11:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hard Capping an LPAR

Not sure that addresses the licence cost issue. BTW hello Bobby!

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator, Worldwide Banking Center of 
Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   "Vernooij, CP (SPLXM) - KLM" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   21/08/2014 07:37
Subject:Re: Hard Capping an LPAR
Sent by:IBM Mainframe Discussion List 



If you need to cap a single application, put it in a Resource Group and give 
that a cap.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Herring, Bobby
Sent: Thursday, August 21, 2014 05:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hard Capping an LPAR

Thank you, that's what I needed to know.

We are trying to limit two problem ISV's that are MIPS based charging. We need 
to do a major CPU upgrade and these two products are making it too painful. One 
can't be gotten rid of easily. The other can be replaced with some pain but is 
doable.

If we can isolate them to the hard capped, very limited use LPAR, then maybe we 
can negotiate with them.

Thanks, Bobby



From: IBM Mainframe Discussion List  on behalf of Al 
Sherkow Digest 
Sent: Wednesday, August 20, 2014 8:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Hard Capping an LPAR

Putting a hard cap on an LPAR limits the LPAR's use of the CPU; it does not 
limit a single application.

Yes you specify that on the HMC. 5% of 2000 is 100.

Al Sherkow, I/S Management Strategies, Ltd.
Consulting Expertise on IBM Workload License Charges (WLC), LCS Software and 
Seminars on IBM Mainframe Software Pricing
+1 414 332-3062

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email 
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN [
http://infonet.txfb-ins.com//images//email-signature-image.jpg]
 WWW.TXFB-INS.COM<
http://www.txfb-ins.com>

Texas Farm Bureau Insurance received the highest numerical score among 
auto insurance providers in Texas in the proprietary J.D. Power 2012-2014 
U.S. Auto Insurance Studies SM (Central Region in 2012). 2014 Study based 
on 44,661 total responses measuring 8 providers in Texas and measures 
opinions of consumers with their auto insurance provider. Proprietary 
study results are based on experiences and perceptions of consumers 
surveyed March-April 2014. Your experiences may vary. Visit jdpower.com. (c) 
2014 Texas Farm Bureau Insurance Companies.

CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) 
is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 
2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to 
you in error, do not read it. If you are not the intended recipient, you 
are hereby notified that any retention, dissemination, distribution, or 
copying of this communication is strictly prohibited. Please reply to the 
sender that you have received the message in error, then delete it. Thank 
you.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email 
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain 
confidential and privileged material intended for the addressee only. If 
you are not the addressee, you are notified that no part of the e-mail or 
any attachment may be disclosed, copied or distributed, and that any other 
action related to this e-mail or attachment is strictly prohibited, and 
may be unlawful. If you have received this e-mail by error, please notify 
the sender immediately by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission 
of this e-mail or any attachments, nor responsible for any delay in 
receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered 
number 33014286

 


--

Re: DF/SORT question (challenge?)

[Martin Packer]

Is this whole limiting number of DD's thing a (lack of) XTIOT thing?

By the way I've thought for some time DFSORT needs a "BUCKET" ICETOOL 
operator like this. But perhaps as a sample it'd be good. How about it Sri 
Hari?

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Sri h Kolusu 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   21/08/2014 00:06
Subject:Re: DF/SORT question (challenge?)
Sent by:IBM Mainframe Discussion List 



>> Try adding close=free to the DD statement

Ed,

When using DFSORT applications, FREE=CLOSE cannot be used on any DD 
statements except DFSPARM. 

Thanks,
Kolusu

IBM Mainframe Discussion List  wrote on 
08/20/2014 03:24:55 PM:

> From: Ed Gould 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/20/2014 03:28 PM
> Subject: Re: DF/SORT question (challenge?)
> Sent by: IBM Mainframe Discussion List 
> 
> On Aug 20, 2014, at 12:54 PM, TonyIcloud-OPERA wrote:
> 
> > I once allocated a PDSE, and using DF/SORT, wrote 1,000 members to 
> > it in one pass of data.  I was tempted to try 10K output members 
> > but my beverage wager was already won.  When I get a bit of time, 
> > since I already have devised a technique to generate N number of DD 
> > statements and OUTFIL statements I'll try 10,000.  I don't recall 
> > the maximum number of DD cards??
> >
> Try adding close=free to the DD statement
> 
> Ed
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Hard Capping an LPAR

[Martin Packer]

Not sure that addresses the licence cost issue. BTW hello Bobby!

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   "Vernooij, CP (SPLXM) - KLM" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   21/08/2014 07:37
Subject:Re: Hard Capping an LPAR
Sent by:IBM Mainframe Discussion List 



If you need to cap a single application, put it in a Resource Group and 
give that a cap.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Herring, Bobby
Sent: Thursday, August 21, 2014 05:55
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hard Capping an LPAR

Thank you, that's what I needed to know.

We are trying to limit two problem ISV's that are MIPS based charging. We 
need to do a major CPU upgrade and these two products are making it too 
painful. One can't be gotten rid of easily. The other can be replaced with 
some pain but is doable.

If we can isolate them to the hard capped, very limited use LPAR, then 
maybe we can negotiate with them.

Thanks, Bobby



From: IBM Mainframe Discussion List  on behalf 
of Al Sherkow Digest 
Sent: Wednesday, August 20, 2014 8:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Hard Capping an LPAR

Putting a hard cap on an LPAR limits the LPAR's use of the CPU; it does 
not limit a single application.

Yes you specify that on the HMC. 5% of 2000 is 100.

Al Sherkow, I/S Management Strategies, Ltd.
Consulting Expertise on IBM Workload License Charges (WLC), LCS Software 
and Seminars on IBM Mainframe Software Pricing
+1 414 332-3062

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email 
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN [
http://infonet.txfb-ins.com//images//email-signature-image.jpg]
 WWW.TXFB-INS.COM<
http://www.txfb-ins.com>

Texas Farm Bureau Insurance received the highest numerical score among 
auto insurance providers in Texas in the proprietary J.D. Power 2012-2014 
U.S. Auto Insurance Studies SM (Central Region in 2012). 2014 Study based 
on 44,661 total responses measuring 8 providers in Texas and measures 
opinions of consumers with their auto insurance provider. Proprietary 
study results are based on experiences and perceptions of consumers 
surveyed March-April 2014. Your experiences may vary. Visit jdpower.com. © 
2014 Texas Farm Bureau Insurance Companies.

CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) 
is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 
2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to 
you in error, do not read it. If you are not the intended recipient, you 
are hereby notified that any retention, dissemination, distribution, or 
copying of this communication is strictly prohibited. Please reply to the 
sender that you have received the message in error, then delete it. Thank 
you.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email 
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain 
confidential and privileged material intended for the addressee only. If 
you are not the addressee, you are notified that no part of the e-mail or 
any attachment may be disclosed, copied or distributed, and that any other 
action related to this e-mail or attachment is strictly prohibited, and 
may be unlawful. If you have received this e-mail by error, please notify 
the sender immediately by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission 
of this e-mail or any attachments, nor responsible for any delay in 
receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered 
number 33014286

 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-

Re: Hard Capping an LPAR

[Elardus Engelbrecht]

Herring, Bobby wrote:

>Thank you, that's what I needed to know. 
 
Excellent!

>We are trying to limit two problem ISV's that are MIPS based charging. We need 
>to do a major CPU upgrade and these two products are making it too painful. 
>One can't be gotten rid of easily. The other can be replaced with some pain 
>but is doable. 
 
I have also been in pain in this similar situation. We moved those expensive 
ISV software, which were hijacking our CPU upgrade to raise their fees, to a 
very small, slow LPAR. Then we used RACF to keep them on their place until we 
stopped them finally and showed them the door.

>If we can isolate them to the hard capped, very limited use LPAR, then maybe 
>we can negotiate with them. 
 
Good luck with that one. I don't think any negotiation will help, they will try 
to sell you a more expensive replacement.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF records for SYSOUT file

[Elardus Engelbrecht]

Barry Merrill wrote:

>There is no separate SMF record written when data is sent to the JES SPOOL.

Indeed.

>And Type 6 records are be written by JES2 or by some SYSOUT processing 
>packages; some packages that manage spooled output for viewing and/or printing 
>write their own SMF User SMF records.

True. VPS can do that too if you wish.


Donald J. wrote:

>A user is complaining about a 15 minute delay in her print process showing up 
>in the JES3 queue and beginning to print on the VPS printer.  The VPS print 
>time matches the SMF 6 record time.

WAD. You can reduce the delay via a setting. If you're still having delay 
problems, check your JES3 performance. 

Note: I'm familiar with VPS from LRS.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TPUT fullscr NOT working getting abend 66D

[Micheal Butz]

I sysudump as I allocated it to my TSO session

Sent from my iPhone

> On Aug 21, 2014, at 2:57 AM, Anthony Thompson  
> wrote:
> 
> A reason code 8, if that is to be believed, indicates an 0C4 while validating 
> user pointers, or a pointer was set to zero. 
> 
> Set a SLIP trap to capture a dump for your 66D abend and diagnose the problem.
> 
> Ant.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of MichealButz
> Sent: Thursday, 21 August 2014 1:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: TPUT fullscr NOT working getting abend 66D
> 
> Hi,
> 
> 
> 
> All of the sudden my TPUT in fullscr mode stopped working instead it is 
> displaying it in line mode followed by a 66D abend at one point I saw a 
> reason code 8
> 
> 
> 
> I ran it under tso test with no problems checked the return codes TPUT 
> STFSMODE STTMPMD STLINENO all were good and the buffer area and it all looked 
> good 
> 
> 
> 
> Any help would be appreciated
> 
> Thanks
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN