Re: Sub Capacity Reporting for non IBM Vendors

2009-09-14 Thread R.S.

Edward Jaffe pisze:

R.S. wrote:
It is also worth to mention that IBM is the only company which is not 
try to catch the customer. I read several horror stories on this 
forum, on ISVcosts list, from own experience - almost any other 
company presents license agreements that HAVE to be negotiated. Only 
IBM's license agreemenst are let's say FAIR. No excessive costs of 
upgrade, SS, etc.

BTW: I didn't say 'CA' g


You're statements that: IBM is the only company which is not try to 
'catch' the customer and Only IBM's license agreemenst are let's say 
FAIR [SIC]--which I will paraphrase, since you are a non-native English 
speaker, to mean: IBM is the only honest mainframe software company 
are highly insulting and patently false.


You might have read so-called horror stories. And, you might have your 
own anecdotal negative experiences. But, I know for an ABSOLUTE FACT you 
are NOT a customer of Phoenix Software International. Your assertions, 
therefore, should not and cannot apply to us or any other software 
providers with whom you do not do business. (I suspect there are 
*dozens* of them--some who freely contribute their time and expertise to 
this list!)


Your statements are unfair, inaccurate, subjective opinion presented as 
fact, and ought to be recanted...


I recant.
I shouldn't say that IBM is the only honest company. That should be the 
only honest company *I know* . This statement does not preclude other 
companies.


Obviously I didn't mean PSI, because I had nothing to do with this 
company. However *every* ISV's license agreement I met needed 
negotiation. Not only for the price, but first of all terms and 
conditions. Sometimes it was small change, but sometimes not.


Last but not least: ISV *technical* employees usually are not 
responsible for marketing model of the company they work for.

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

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


Re: Sub Capacity Reporting for non IBM Vendors

2009-09-14 Thread Binyamin Dissen
On Mon, 14 Sep 2009 08:50:02 +0200 R.S. r.skoru...@bremultibank.com.pl
wrote:

:I recant.
:I shouldn't say that IBM is the only honest company. That should be the 
:only honest company *I know* . This statement does not preclude other 
:companies.

:Obviously I didn't mean PSI, because I had nothing to do with this 
:company. However *every* ISV's license agreement I met needed 
:negotiation. Not only for the price, but first of all terms and 
:conditions. Sometimes it was small change, but sometimes not.

Let me understand this correctly. You accept all IBM boilerplate agreements
with zero negotiation???

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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


Re: Sub Capacity Reporting for non IBM Vendors

2009-09-14 Thread R.S.

Binyamin Dissen pisze:

On Mon, 14 Sep 2009 08:50:02 +0200 R.S. r.skoru...@bremultibank.com.pl
wrote:

:I recant.
:I shouldn't say that IBM is the only honest company. That should be the 
:only honest company *I know* . This statement does not preclude other 
:companies.


:Obviously I didn't mean PSI, because I had nothing to do with this 
:company. However *every* ISV's license agreement I met needed 
:negotiation. Not only for the price, but first of all terms and 
:conditions. Sometimes it was small change, but sometimes not.


Let me understand this correctly. You accept all IBM boilerplate agreements
with zero negotiation???


No.
I don't have to look for gotchas. I negotiate prices, but usually not 
TsCs.


--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 
2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec 
podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym 
BRE Banku SA bd w caoci opacone.

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


Re: Sub Capacity Reporting for non IBM Vendors

2009-09-14 Thread Binyamin Dissen
On Mon, 14 Sep 2009 10:24:20 +0200 R.S. r.skoru...@bremultibank.com.pl
wrote:

:Binyamin Dissen pisze:
: On Mon, 14 Sep 2009 08:50:02 +0200 R.S. r.skoru...@bremultibank.com.pl
: wrote:
 
: :I recant.
: :I shouldn't say that IBM is the only honest company. That should be the 
: :only honest company *I know* . This statement does not preclude other 
: :companies.
 
: :Obviously I didn't mean PSI, because I had nothing to do with this 
: :company. However *every* ISV's license agreement I met needed 
: :negotiation. Not only for the price, but first of all terms and 
: :conditions. Sometimes it was small change, but sometimes not.
 
: Let me understand this correctly. You accept all IBM boilerplate agreements
: with zero negotiation???

:No.
:I don't have to look for gotchas. I negotiate prices, but usually not 
:TsCs.

Please present some examples of a gotchas that are unique to ISVs.

--
Binyamin Dissen bdis...@dissensoftware.com
http://www.dissensoftware.com

Director, Dissen Software, Bar  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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


Re: PDSE HELP Required.

2009-09-14 Thread Greg Price
Rick Fochtman wrote:

 In case you forgot: regular load modules only contain a note list if 
 they are in OVERLAY format, which is both archaic and unnecessarily 
 complicated.

OVERLAY format does use a second entry in the NOTE list, but *all*
PDS load modules have at least one entry in the NOTE TTR list
to point to the first text block.

I have, no doubt, forgotten lots of other things, though...

Cheers,
Greg

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


Re: Sub Capacity Reporting for non IBM Vendors

2009-09-14 Thread Ted MacNEIL
I don't have to look for gotchas.
I negotiate prices, but usually not TsCs.

Boy! Are you naive!
TC are negotiable!

-
Too busy driving to stop for gas!

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


WLM initiators and IEF196I messages

2009-09-14 Thread Gil Peleg
Hi all,
A little something I noticed...

We have some code in IEFACTRT that issues WTO messages with route code 11
(don't ask..).

When a job is running under a JES-managed initiator, the messages are
displayed fine in the JESMSGLG.
When a job is running under a WLM-managed initiator, each message is echoed
again with IEF196I message.

I know that is what IEF196I is for.
I see IWM034I stating that the WLM-managed initiator was started with
parameters SUB=MSTR.

But isn't that behavior of WLM-managed initiators inconsistent with the
behavior of JES-managed initiators?
Shouldn't WLM-managed initiators be started under the JES subsystem like
JES-managed initiators?

Thanks,
Gil.

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


Re: Sub Capacity Reporting for non IBM Vendors

2009-09-14 Thread R.S.

Ted MacNEIL pisze:

I don't have to look for gotchas.
I negotiate prices, but usually not TsCs.


Boy! Are you naive!
TC are negotiable!


I'm not naive. I know that TsCs are negotiable, as everything in business.

It is strange: when I complained about IBM on the list, I was scolded. 
Now I said something positive and I'm again scolded.
What I wrote is my (non-sponsored) opinion, based on some (mine and 
others) experience.

It wasn't my goal to convince anyone of anything.
EOT
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 
2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec 
podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym 
BRE Banku SA będą w całości opłacone.

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


SV: SV: SV: CLIST/REXX Library Formats

2009-09-14 Thread Thomas Berg
:D


 -Ursprungligt meddelande-
 Från: IBM Mainframe Discussion List 
 [mailto:ibm-m...@bama.ua.edu] För Steve Comstock
 Skickat: den 11 september 2009 20:06
 Till: IBM-MAIN@bama.ua.edu
 Ämne: Re: SV: SV: CLIST/REXX Library Formats
 
 Thomas Berg wrote:
 [snip]
 
  This makes it somewhat unusable when You want/need to work fast.  
  Which I normally do.
 
 Yeah, that's the word on the street. At least from the ladies. :-)
 
 
 -- 
 
 Kind regards,
 
 -Steve Comstock
 The Trainer's Friend, Inc.
 
 303-393-8716
 http://www.trainersfriend.com
 
z/OS Application development made easier
  * Our classes include
 + How things work
 + Programming examples with realistic applications
 + Starter / skeleton code
 + Complete working programs
 + Useful utilities and subroutines
 + Tips and techniques
 
 == Ask about being added to our opt-in list:  ==
 ==   * Early announcement of new courses  ==
 ==   * Early announcement of new techincal papers ==
 ==   * Early announcement of new promotions   ==
 
 --
 For IBM-MAIN subscribe / signoff / archive access 
 instructions, send email to lists...@bama.ua.edu with the 
 message: GET IBM-MAIN INFO Search the archives at 
 http://bama.ua.edu/archives/ibm-main.html
 

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


SV: CLIST/REXX Library Formats

2009-09-14 Thread Thomas Berg
 -Ursprungligt meddelande-
 Från: IBM Mainframe Discussion List 
 [mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin
 Skickat: den 11 september 2009 23:26
 Till: IBM-MAIN@bama.ua.edu
 Ämne: Re: CLIST/REXX Library Formats
 
 On Fri, 11 Sep 2009 19:38:21 +0200, Thomas Berg wrote:
 
  -Ursprungligt meddelande-
  [mailto:ibm-m...@bama.ua.edu] För Paul Gilmartin
 

snip

 
 If You with data length mean actual, existing data, not 
 the LRECL 
 of the dataset; then Yes.
 
 I'm using VB 32756/32760 as a way to catch all needs.
 When I then have 1000 rows in an existing member (this is a 
 PDSE), it 
 take someting like 3 seconds to repeat a row.
 (Line command R.)
 Then length of the data in a row is max 80 bytes.
 
 Indeed, I failed to write what I meant, length in the DCB.
 Your observation supports my surmise that ISPF (like XEDIT) 
 pads all records to that length.
 
 This makes it somewhat unusable when You want/need to work 
 fast.  Which 
 I normally do.
 
 This ought to be a topic for a performance APAR.  You likely 
 would get no better than SUG.
 

SUG ?



Regards, 
Thomas Berg 
__ 
Thomas Berg   Specialist   IT-U   SWEDBANK 

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


Re: SRDF/A, DB2

2009-09-14 Thread Jim Marshall
We will soon be installing an EMC V-Max and SRDF/A in an DB2 environment
running on an Z/OS LPAR(s). Can anyone share what their best practices are
or Point me to where I can find any Documentation on this subject? Thanks in
advance!

You did not say if you were doing SRDF/A prior to the DB2 so just a few 
general words which you may already know. In general doing SRDF/A and with 
any database system, defining Consistency Groups is critical to keep all parts 
of the database in one logical piece. EMC has the documentation which may 
not exactly spell things out in those terms but is a good place to start. 

If you can be more specific, then it would help.  

jim 

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


Re: SRDF/A, DB2

2009-09-14 Thread Mike Liberatore
Do you still have to install Consistency Group Software?

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Terri E Shaffer
Sent: Sunday, September 13, 2009 1:31 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: SRDF/A, DB2

I think this is where I will tell you I will know in a month or two... We
are installing a V-max with GDDR in a star configuration   We have done
it 2 other times within our environment, this is the first V-MAX and the
newest EMC software  mainframe enabler V7...  And I wonder about the
previous posts about the field idosyncorcies.

Thanks

Ms. Terri E. Shaffer 
terri.e.shaf...@jpmchase.com
Engineer
J.P.Morgan Chase  Co.
GTI DCT ECS Core Services zSoftware Group / Emerging Technologies 
Office: # 614-213-3467
Cell: # 412-519-2592 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Mike Liberatore
Sent: Saturday, September 12, 2009 8:50 AM
To: IBM-MAIN@bama.ua.edu
Subject: SRDF/A, DB2

We will soon be installing an EMC V-Max and SRDF/A in an DB2 environment
running on an Z/OS LPAR(s). Can anyone share what their best practices are
or

Point me to where I can find any Documentation on this subject? Thanks in
advance!


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase  Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase 
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.

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

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


Wanted: SHARE Volume I proceedings

2009-09-14 Thread Bob Shannon
SHARE used to publish two volumes of Proceedings: Volume I was a book 
containing papers; Volume II was microfiche of everything else. I have started 
to convert the Volume I Proceedings to PDF. I have Volume I from SHARE 74 
(Anaheim, Winter 1990) and SHARE 77 (Chicago, Summer 1991). If you have any 
other Volume I Proceedings in a file cabinet or in a box in your attic and are 
willing to donate it (or them), please contact me offline. During conversion to 
PDF the pages are removed from the binding, so the publication will be trashed 
during the process. Eventually the PDFs will be made available on a 
publically-accessible website.

Bob Shannon

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


Re: Sub Capacity Reporting for non IBM Vendors

2009-09-14 Thread Kelman, Tom
Peter,

Yes, all SMF records are written by SMF.  However, it is system programs
or application programs that request SMF to write them.  I know of many
vendor programs that request the writing of various SMF records, and
type 89 is no exception.  Any program could set up the application
oriented part of the SMF record and then request the SMF system to write
it as a type 89.  I have run into problem situations where a vendor
program has requested the writing of an SMF record with an ID used by
some other area and there have been conflicts, so the program requesting
the particular SMF record does have to follow some standards.

I do know for a fact that IBM's CPCS and imaging software packages cause
type 89 records to be written.  I've had to process them through a
special program supplied by that area of IBM for the last 4 years.  That
program creates reports in csv file format that I then send into IBM so
they can determine the charges for our CPCS and imaging processing for
the next year.  Those charges are based on the number of items that are
processed in those systems. 

Tom Kelman
Enterprise Capacity Planner
Commerce Bank of Kansas City
(816) 760-7632
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
 Behalf Of Peter Relson
 Sent: Saturday, September 12, 2009 8:00 AM
 To: IBM-MAIN@bama.ua.edu
 Subject: Re: Sub Capacity Reporting for non IBM Vendors
 
 A vendor could write SMF Type 89 records that record something other
 than MSUs.  IBM actually does this with their Check Processing
Control
 System (CPCS) and imaging software.  Those products write Type 89
 records that record the number of items processed.
 
 It seems really unlikely that anyone would write their own SMF type 89
 records (especially IBM). But perhaps you know something I don't.  SMF
89
 records are not written by applications. They are written by SMF. Only
by
 SMF.  SMF 89 subtype 2 records (which is what is really being talked
about
 in the SCRT discussion) are written by SMF based on information
associated
 with the product registration service (IFAEDREG). SMF 89 subtype 1
records
 are written by SMF based on information provided by applications using
 IFAUSAGE.
 
 Peter Relson
 z/OS Core Technology Design
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html


*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*

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


Re: Sub Capacity Reporting for non IBM Vendors

2009-09-14 Thread Kelman, Tom
What is said here might be true for those products that are doing
sub-capacity pricing based on MSUs.  They just need to
register/deregister their product to write the MULC data.  However, as I
said in a previous post, I know that the IBM CPCS and imaging software
cause SMF89 records to be written so those products can be priced based
on the number of items processed by the products.  I don't think that
can be done by registering the product to write the MULC data.  I have
to process these records through a program to create reports to send to
IBM each year.  By the way, I also know that this was in place before
the present sub-capacity pricing process was in place for the subsystems
like CICS and DB2.  I started to process these records at a previous job
in 2000 or earlier.

Tom Kelman
Enterprise Capacity Planner
Commerce Bank of Kansas City
(816) 760-7632

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
 Behalf Of Edward Jaffe
 Sent: Saturday, September 12, 2009 3:50 PM
 To: IBM-MAIN@bama.ua.edu
 Subject: Re: Sub Capacity Reporting for non IBM Vendors
 
 Scott Barry wrote:
  CA Common Services (CAIRIM) is writing SMF 89 data today,
contributing
 to
  SMF 89 and MULC (SMF type 30) analysis and reporting for many of its
  software products.  This effort came about in the past year's time-
 frame,
  having been revealed (remember - CA does not announce futures!) at
CA
 World
  2007.  The product identification is delivered by CA as a PTF, if
  interested, to resolve the individual product names based on their
CA
 LMP
  key identification.
 
 
 I think what Peter is saying is that such records are most likely NOT
 being created by CAIRIM. That is, it's unlikely that any CA-written
code
 formats an SMF89 record and calls the SMFWTM service to write it to
SMF.
 It's far more likely that CAIRIM simply uses the IFAEDxxx services to
 register/deregister their products and/or IFAUSAGE to write MULC data.
 Those actions will indirectly cause SMF89s to be produced. That's what
 our products do. I suspect, that's what they do too... Correct me if
I'm
 wrong...
 
 --
 Edward E Jaffe
 Phoenix Software International, Inc
 5200 W Century Blvd, Suite 800
 Los Angeles, CA 90045
 310-338-0400 x318
 edja...@phoenixsoftware.com
 http://www.phoenixsoftware.com/
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html


*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*

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


T-Rex and Dino-Software

2009-09-14 Thread גדי בן אבי
Hi,

A few days ago I asked a question about a replacement for Dino Software’s T-Rex.

From the way my question was phrased, it could have been inferred that I was 
dissatisfied with T-Rex or Dino Software.

First I would like to apologize to the great people at Dino Software. I have 
always been satisfied with T-Rex, and your technical and administrative support.

T-Rex is a great product , performs well and does almost anything you would 
want to do with a catalog.

Dino Software’s support is always fast and to the point.

Gadi


לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, 
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.

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


(ssh Client) z/OS to OpenSSH (CopSSH sshd) on Win Y2K SP4

2009-09-14 Thread Marco Gianfranco Indaco
Hi to all.
I've a problem when I connect via ssh my USS session to CopSSH using pubkey
and after starting a VbScript to exceute a MsExcel macro.
When I start the vbscript that make a CreateObject(Excel.Application)
it gives a Permission denied but this doesn't happens if I
authenticate using password.
 I think that problem is about unix vs windows API permission but why only
one method works fine? Any suggest?

Many thanks in advance.

Regards.
-- 
Marco Indaco
MF Consultant
Loc   : Milan, Italy
Mob  : (+39) 335 7035564

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


Re: Wanted: SHARE Volume I proceedings

2009-09-14 Thread Anne Lynn Wheeler
bshan...@rocketsoftware.com (Bob Shannon) writes:
 SHARE used to publish two volumes of Proceedings: Volume I was a book
 containing papers; Volume II was microfiche of everything else. I have
 started to convert the Volume I Proceedings to PDF. I have Volume I
 from SHARE 74 (Anaheim, Winter 1990) and SHARE 77 (Chicago, Summer
 1991). If you have any other Volume I Proceedings in a file cabinet or
 in a box in your attic and are willing to donate it (or them), please
 contact me offline. During conversion to PDF the pages are removed
 from the binding, so the publication will be trashed during the
 process. Eventually the PDFs will be made available on a
 publically-accessible website.

the copyright law changed in '79 ... i have SHARE copyrighted document
(LSRAD report) from '79 (after the copyright law change) and have been
trying since last jan, to get share permission to put up scan on
publicly available site (bitsavers.org ... which has some number of
earlier SHARE documents as well as IBM manuals). under the old law
... the copyright would have expired.

post from earlier this year
http://www.garlic.com/~lynn/2009.html#47
http://www.garlic.com/~lynn/2009.html#70

-- 
40+yrs virtualization experience (since Jan68), online at home since Mar1970

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


Re: WLM initiators and IEF196I messages

2009-09-14 Thread David Andrews
On Mon, 2009-09-14 at 06:48 -0400, Gil Peleg wrote:
 We have some code in IEFACTRT that issues WTO messages with route code 11

Yes, we changed our ACTRT to issue messages with another route code so
to avoid those superfluous (IMO) IEF196I messages.

-- 
David Andrews
A. Duda and Sons, Inc.
david.andr...@duda.com

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


Re: [turnkey-mvs] turnkey mvs and cobol/jcl environment

2009-09-14 Thread Thompson, Steve
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Andreas F. Geissbuehler
Sent: Saturday, September 12, 2009 9:52 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [turnkey-mvs] turnkey mvs and cobol/jcl environment

SNIP
I second Jo on this and URGE YOU to continue with herc 
and MVS 3.8j, even Assembler 370, but forget COBOL. 

You need to master current, modern COBOL which you can
accomplish short-term by visiting Prof. Don Higgin's website
at www.z390.org. Don's Java-based zASM and zCOBOL at
www.zcobol.org are modern, state-of-the-art implementation
which I recomend you should evaluate and consider to use,
instead of, in addition to and/or in combination with TK3.

SNIP

Assuming he is running a M/S product, he can probably get one of the
COBOL books with a COBOL CD in it. Fujitsu's COBOL runs nicely on NT,
and W2K (with a few tweeks). I haven't tried it under XP.

The use of the FCOBOL under MVS3.8 or the equivalent under DOS (R34?),
will teach COBOL basics. 

The PC based compilers will take that source (at least the Fujitsu one
will) and produce working code under Winders.

So the question is, where did OS/2 and a M/F compatible COBOL go? Why do
people use Realia (do they still exist?) to do COBOL development on a PC
and then upload the source to a M/F? [Same for the Fujitsu system.]

It is because of IBM Marketing's view of the world. 

Regards,
Steve Thompson

-- Opinions expressed by this poster may not reflect those held by
poster's employer --

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


Re: T-Rex and Dino-Software

2009-09-14 Thread Mark Zelden
On Mon, 14 Sep 2009 16:00:16 +0300, #1490;#1491;#1497; amp;#1489;#1503; 
#1488;#1489;#1497; gad...@malam.com wrote:

Hi,

A few days ago I asked a question about a replacement for Dino Software’s
T-Rex.

From the way my question was phrased, it could have been inferred that I
was dissatisfied with T-Rex or Dino Software.


I didn't take it that way.  You only mentioned cost related to an upgrade:
http://bama.ua.edu/cgi-bin/wa?A2=ind0909L=ibm-mainD=1amp;O=DP=67544

First I would like to apologize to the great people at Dino Software.

remainder of apology snipped

I have to ask:   Did the vendor contact you and ask you to post this 
apology?   If so, I would consider that very wrong since you posted an
legitimate question based on your experience and didn't disparage the
vendor in any way that I can see.  If not, did someone else contact
you off line who mistook your post?   Please be honest.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

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


Re: Sub Capacity Reporting for non IBM Vendors

2009-09-14 Thread Ed Finnell
 
In a message dated 9/14/2009 1:51:24 A.M. Central Daylight Time,  
r.skoru...@bremultibank.com.pl writes:

company. However *every* ISV's license agreement I met needed  
negotiation. Not only for the price, but first of all terms and  
conditions. Sometimes it was small change, but sometimes  not.



IBM's billing systems used to be just the  pits. Dups, retreads, and drops 
were common practice. When they outsourced marketing to  third party it got 
really slovenly with third party contracts and more serial  numbers for 
services. The cash cows, confusion and pricing did a lot to drive  us away from 
IBM top to bottom.
 
Third party have been caveat emptor for  ages. John Anderson started the 
isvcosts list several years ago it's an  end-user only forum to note problems 
and concerns.
 
Seems like today management by magazine  and instant gratification 
supercede technical competence and engineering  synergy. 





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


Re: Sub Capacity Reporting for non IBM Vendors

2009-09-14 Thread Rick Fochtman
Let's face it: some vendors are very fair and accomodating while others 
have practices that can only be characterized as predatory. I've dealt 
with both kinds.


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


Re: Sub Capacity Reporting for non IBM Vendors

2009-09-14 Thread Rick Fochtman

--snip--
Let me understand this correctly. You accept all IBM boilerplate 
agreements with zero negotiation???

-unsnip
If so, I want whatever it is that he's smoking!  :-)

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


Re: Sub Capacity Reporting for non IBM Vendors

2009-09-14 Thread Kelman, Tom
That's all well and good.  However, I just did a D PROD,STATE on my
systems and several products - CPCS, the imaging software, CICS, DB2,
and MQ - are not in this list, but they are all producing SMF Type89
records.  The ones for CICS, DB2, and MQ are run though SCRT every month
to produce the reports for IBM sub-capacity pricing.  So it appears that
this is not necessarily required to get the SMF Type 89 records.

Tom Kelman
Enterprise Capacity Planner
Commerce Bank of Kansas City
(816) 760-7632

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
 Behalf Of Edward Jaffe
 Sent: Monday, September 14, 2009 10:39 AM
 To: IBM-MAIN@bama.ua.edu
 Subject: Re: Sub Capacity Reporting for non IBM Vendors
 
 Kelman, Tom wrote:
  What is said here might be true for those products that are doing
  sub-capacity pricing based on MSUs.  They just need to
  register/deregister their product to write the MULC data.  However,
as I
  said in a previous post, I know that the IBM CPCS and imaging
software
  cause SMF89 records to be written so those products can be priced
based
  on the number of items processed by the products.  I don't think
that
  can be done by registering the product to write the MULC data.
 
 1) SMF89.1 records contain resource usage information. See IFAUSAGE
 service.
 2) SMF89.2 records contain product usage information. See IFAEDREG and
 IFAEDDRG services.
 
 These services, and the IFAURP report program, are described in z/OS
MVS
 Product Management:
 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2r130/
 
 --
 Edward E Jaffe
 Phoenix Software International, Inc
 5200 W Century Blvd, Suite 800
 Los Angeles, CA 90045
 310-338-0400 x318
 edja...@phoenixsoftware.com
 http://www.phoenixsoftware.com/
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html


*
If you wish to communicate securely with Commerce Bank and its
affiliates, you must log into your account under Online Services at 
http://www.commercebank.com or use the Commerce Bank Secure
Email Message Center at https://securemail.commercebank.com

NOTICE: This electronic mail message and any attached files are
confidential. The information is exclusively for the use of the
individual or entity intended as the recipient. If you are not
the intended recipient, any use, copying, printing, reviewing,
retention, disclosure, distribution or forwarding of the message
or any attached file is not authorized and is strictly prohibited.
If you have received this electronic mail message in error, please
advise the sender by reply electronic mail immediately and
permanently delete the original transmission, any attachments
and any copies of this message from your computer system.
*

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


Re: T-Rex and Dino-Software

2009-09-14 Thread David Andrews
On Mon, 2009-09-14 at 10:02 -0400, Mark Zelden wrote:
 On Mon, 14 Sep 2009 16:00:16 +0300, #1490;#1491;#1497; amp;#1489;#1503; 
 #1488;#1489;#1497; gad...@malam.com wrote:
 From the way my question was phrased, it could have been inferred
 I didn't take it that way.

For what little it may be worth, I *did* infer some dissatisfaction and
was a bit surprised - seeing as the Dino people have always been helpful
here and I'd never heard anyone disparage their product.  Thanks to Gadi
for clarifying his comment.

-- 
David Andrews
A. Duda and Sons, Inc.
david.andr...@duda.com

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


Re: Use of RETAIN

2009-09-14 Thread Daniel McLaughlin
Here is a short version of the job...and it croaks trying to open up the tape 
in 
the second part of the second step. We thought maybe it was a DD name 
conflict and changed the scheme for a test, same results...opened with IBM 
and will do the same with FDR folks. This job will be all generated by REXX to 
be dynamic.

  
//TAPE1  DD DSN=PDR.TSTBKP.AIG002(+1),  
//  DISP=(NEW,CATLG,DELETE),
//  UNIT=(TAPE92,,DEFER),   
//  DCB=(IPOBAK.PATTERN.DSCB,BUFNO=10), 
//  LABEL=(1,SL,EXPDT=99000),   
//  VOL=(,RETAIN)   
//DISK2  DD UNIT=3390,DISP=SHR,VOL=SER=DBPK23   
//TAPE2  DD DSN=PDR.TSTBKP.DBPK23(+1),  
//  DISP=(NEW,CATLG,DELETE),
//  UNIT=(TAPE92,,DEFER),   
//  LABEL=(2,SL,EXPDT=99000),   
//  DCB=(IPOBAK.PATTERN.DSCB,BUFNO=10), 
//  VOL=(PRIVATE,RETAIN,REF=*.TAPE1)
//SYSIN  DD DSN=PROD.PARMLIB(DR100),DISP=SHR
//SYSPRINT DD SYSOUT=*  
//SYSPRIN1 DD SYSOUT=*  
//SYSDUMP  DD SYSOUT=*  
//ABRMAP   DD SYSOUT=*  
//* End of Step 
//DUMP2  EXEC PGM=FDR,REGION=8M 
//DISKA  DD UNIT=3390,DISP=SHR,VOL=SER=DB0034   
//TAPEA  DD DSN=PDR.TSTBKP.DB0034(+1),  
//  DISP=(NEW,CATLG,DELETE),
//  DCB=(IPOBAK.PATTERN.DSCB,BUFNO=10), 
//  UNIT=(TAPE92,,DEFER),   
//  LABEL=(3,SL,EXPDT=99000),   
//  VOL=(,RETAIN,,,REF=*.DUMP1.TAPE1)   
//DISKB  DD UNIT=3390,DISP=SHR,VOL=SER=DB0035   
//TAPEB  DD DSN=PDR.TSTBKP.DB0035(+1),  
//  DISP=(NEW,CATLG,DELETE),
//  UNIT=(TAPE92,,DEFER),   
//  LABEL=(4,SL,EXPDT=99000),   
//  DCB=(IPOBAK.PATTERN.DSCB,BUFNO=10), 
//  VOL=(,RETAIN,,,REF=*.DUMP1.TAPE1)   
//SYSIN  DD DSN=PROD.PARMLIB(DR100),DISP=SHR
//SYSPRINT DD SYSOUT=*  
//SYSPRIN1 DD SYSOUT=*  
//SYSDUMP  DD SYSOUT=*  
//ABRMAP   DD SYSOUT=*  
//NOTIFY EXEC PGM=WTOPGM,COND=((3,GT),EVEN),
// PARM='JOB DRAIG001  BACKUP FAILED ON MVS'
//NOTIFY EXEC PGM=WTOPGM,COND=(1,LT),   
// PARM='JOB DRAIG001  BACKUP SUCCESSFUL ON MVS'
//* 

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


Re: [turnkey-mvs] turnkey mvs and cobol/jcl environment - hit send too soon

2009-09-14 Thread Steve Comstock

Thompson, Steve wrote:

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Andreas F. Geissbuehler
Sent: Saturday, September 12, 2009 9:52 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [turnkey-mvs] turnkey mvs and cobol/jcl environment

SNIP
I second Jo on this and URGE YOU to continue with herc 
and MVS 3.8j, even Assembler 370, but forget COBOL. 


You need to master current, modern COBOL which you can
accomplish short-term by visiting Prof. Don Higgin's website
at www.z390.org. Don's Java-based zASM and zCOBOL at
www.zcobol.org are modern, state-of-the-art implementation
which I recomend you should evaluate and consider to use,
instead of, in addition to and/or in combination with TK3.

SNIP

Assuming he is running a M/S product, he can probably get one of the
COBOL books with a COBOL CD in it. Fujitsu's COBOL runs nicely on NT,
and W2K (with a few tweeks). I haven't tried it under XP.

The use of the FCOBOL under MVS3.8 or the equivalent under DOS (R34?),
will teach COBOL basics. 


The PC based compilers will take that source (at least the Fujitsu one
will) and produce working code under Winders.

So the question is, where did OS/2 and a M/F compatible COBOL go? Why do
people use Realia (do they still exist?) to do COBOL development on a PC
and then upload the source to a M/F? [Same for the Fujitsu system.]

It is because of IBM Marketing's view of the world. 


Regards,
Steve Thompson


Marketing, probably. The current COBOL developers have been
pushing the edge of modernity constantly. Now, COBOL can
handle Unicode, ASCII, XML, DB2 LOBs, and more. I regularly
create COBOL CGIs for z/OS, including one to implement an
AJAX application.

For those who care / need to, you can create OO COBOL
classes that can interoperate with Java classes.

And well-written COBOL code is clear and easy to read
and maintain. Pretty nifty language these days.



--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

== Ask about being added to our opt-in list:  ==
==   * Early announcement of new courses  ==
==   * Early announcement of new techincal papers ==
==   * Early announcement of new promotions   ==

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


Re: [turnkey-mvs] turnkey mvs and cobol/jcl environment - hit send too soon

2009-09-14 Thread Howard Brazee
On 14 Sep 2009 08:25:19 -0700, st...@trainersfriend.com (Steve
Comstock) wrote:

Marketing, probably. The current COBOL developers have been
pushing the edge of modernity constantly. 

Which current CoBOL developers?   The compiler writers at IBM?   The
majority of people who develop CoBOL programs in mainframe shops?

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


Re: Carrier Pigeon beats Internet Speed

2009-09-14 Thread Howard Brazee
On 11 Sep 2009 18:59:04 -0700, tom_moul...@1scom.net (Tom Moulder)
wrote:

I am working with a company that literally did this.  They shipped a 
very large disk array to the central computing center and placed it next 
to the production array; synchronously copied all the data; found a 
quiet point on a Sunday morning and split the link; uncabled the array; 
shipped it across country to the BC site (Business Continuity now, not 
Disaster Recovery); they are in the process of cabling it up; will turn 
it on next weekend and away with go with a recovery drill.

Heck, I find it more reliable to synchronize the files I need between
home and work using my iPod as a medium than using the on-line disk
storage I pay for.   My batch update takes seconds to my iPod and
always completes.   The on-line update takes 5-10 minutes if it
finishes at all.

Sneaker-net has had quite a bit of success over the years.

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


CEEPIPI incorrect recovery processing?

2009-09-14 Thread Gord Tomlin
Just looking for input as to whether this is working as designed 
before I report it as a defect...


If a program that uses CEEPIPI to call HLL subroutines abends while 
*not* in any of the HLL subroutines, LE recovery processes the abend and 
transforms a system abend into a LE user abend. Meanwhile, the 
associated dump is written to SYSUDUMP rather than CEEDUMP.


This situation can be recreated by using the samples ASMPIPI and 
HLLPIPI from the LE Programming Guide, and adding the abend of your 
choice (I used EX 0,*) after the label TSUB in ASMPIPI. Instead of 
seeing a ABENDS0C3 in ASMPIPI, you will see a ABENDU4036-2 associated 
with CEEPLPKA. The only sign of the original abend is in the system 
trace table. Needless to say, LE's recovery routines have not made a 
positive contribution to locating the original problem.


One of the requirements for a program that uses CEEPIPI to call 
LE-conforming HLL routines is that the calling routine *not* be a 
LE-conforming program, so it seems nonsensical on the surface that LE's 
recovery routines would try to interpret the abend.


The LE Programming Guide says:
- init_sub creates a LE environment and sets the environment dormant so 
that exceptions are percolated out of it.
- for call_sub, CEEPIPI activates the LE environment before the called 
routine is invoked, and after the called routine returns, the 
environment is dormant.


It appears to me that LE is doing an incomplete job of 
ignoring/percolating abends that occur while outside of the LE 
environment. Does anyone know anything to the contrary?


Thanks!
--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507, gord.tom...@actionsoftware.com

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


Re: Sub Capacity Reporting for non IBM Vendors

2009-09-14 Thread Ted MacNEIL
Let's face it: some vendors are very fair and accomodating while others 
have practices that can only be characterized as predatory. I've dealt 
with both kinds.

So have I.
As a Capacity Analyst, I have been more involved in costing, than I've ever 
wanted to be.
I knew this was going to happen as soon as IBM introduced tiered pricing in 
1984.

The issue from Roland's post was not whether there were good, bad, or 
indifferent.
Rather, it was his statement was IBM is good, and everybody else was bad.

I can, from direct experience, state (unequivically) that I know two ISV's that 
(imo) Data21 (ZIP/390), and VANGUARD, are excellent vendors, in support, 
marketting  cost, along with product capability.

I can name two that are horrible, in my opinion, suck.
But, with today's libel laws, I shall not publicly.
-
Too busy driving to stop for gas!

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


Re: [turnkey-mvs] turnkey mvs and cobol/jcl environment - hit send too soon

2009-09-14 Thread Steve Comstock

Howard Brazee wrote:

On 14 Sep 2009 08:25:19 -0700, st...@trainersfriend.com (Steve
Comstock) wrote:


Marketing, probably. The current COBOL developers have been
pushing the edge of modernity constantly. 


Which current CoBOL developers?   The compiler writers at IBM?   The
majority of people who develop CoBOL programs in mainframe shops?


The former, mostly.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

== Ask about being added to our opt-in list:  ==
==   * Early announcement of new courses  ==
==   * Early announcement of new techincal papers ==
==   * Early announcement of new promotions   ==

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


Re: [turnkey-mvs] turnkey mvs and cobol/jcl environment

2009-09-14 Thread Steve Comstock

Thompson, Steve wrote:

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Andreas F. Geissbuehler
Sent: Saturday, September 12, 2009 9:52 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [turnkey-mvs] turnkey mvs and cobol/jcl environment

SNIP
I second Jo on this and URGE YOU to continue with herc 
and MVS 3.8j, even Assembler 370, but forget COBOL. 


You need to master current, modern COBOL which you can
accomplish short-term by visiting Prof. Don Higgin's website
at www.z390.org. Don's Java-based zASM and zCOBOL at
www.zcobol.org are modern, state-of-the-art implementation
which I recomend you should evaluate and consider to use,
instead of, in addition to and/or in combination with TK3.

SNIP

Assuming he is running a M/S product, he can probably get one of the
COBOL books with a COBOL CD in it. Fujitsu's COBOL runs nicely on NT,
and W2K (with a few tweeks). I haven't tried it under XP.

The use of the FCOBOL under MVS3.8 or the equivalent under DOS (R34?),
will teach COBOL basics. 


The PC based compilers will take that source (at least the Fujitsu one
will) and produce working code under Winders.

So the question is, where did OS/2 and a M/F compatible COBOL go? Why do
people use Realia (do they still exist?) to do COBOL development on a PC
and then upload the source to a M/F? [Same for the Fujitsu system.]

It is because of IBM Marketing's view of the world. 


Regards,
Steve Thompson


Marketing, probably. The current COBOL developers have been
pushing the edge of modernity constantly. Now,

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

== Ask about being added to our opt-in list:  ==
==   * Early announcement of new courses  ==
==   * Early announcement of new techincal papers ==
==   * Early announcement of new promotions   ==

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


Re: Sub Capacity Reporting for non IBM Vendors

2009-09-14 Thread Edward Jaffe

Kelman, Tom wrote:

What is said here might be true for those products that are doing
sub-capacity pricing based on MSUs.  They just need to
register/deregister their product to write the MULC data.  However, as I
said in a previous post, I know that the IBM CPCS and imaging software
cause SMF89 records to be written so those products can be priced based
on the number of items processed by the products.  I don't think that
can be done by registering the product to write the MULC data.


1) SMF89.1 records contain resource usage information. See IFAUSAGE service.
2) SMF89.2 records contain product usage information. See IFAEDREG and 
IFAEDDRG services.


These services, and the IFAURP report program, are described in z/OS MVS 
Product Management: 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2r130/


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

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


Re: Use of RETAIN

2009-09-14 Thread Ed Finnell
 
In a message dated 9/14/2009 9:47:57 A.M. Central Daylight Time,  
daniel_mclaugh...@us.crawco.com writes:

and it croaks trying to open up the tape in 
the second part of  the second step. We thought maybe it was a DD name 
conflict and changed  the scheme for a test, same results...opened with IBM 
and will do the same  with FDR folks. This job will be all generated by 
REXX to 



Still miss Bruce Black(FDR). Anyway  croakers generally issue messages?
FDRABR keeps it's own catalog of backups  and you should only need to point 
to the drive(s) once and it handles the  rest.





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


Re: z/VM GDDM install

2009-09-14 Thread Alan Altmark
On Thu, 10 Sep 2009 09:45:35 +0200, J D Cassidy s...@jdcassidy.net wrote:

appreciate the advice, thank you. Bloody hard way to get a manual though...

Perhaps you weren't around when you had to fill out a paper form and send it
to the branch office?  :-)

By the time L-class books were eliminated, products like GDDM were in
maintenance mode.  That meant that there were no further issuance of
publications and so the status-quo has been maintained.

A PMR is how you Officially Complain to IBM about something, even if it is
to complain about having to open an PMR!  :-)  (Help, I'm caught in an
endless loop!)

Alan Altmark
IBM

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


Re: Sub Capacity Reporting for non IBM Vendors

2009-09-14 Thread Edward Jaffe

Kelman, Tom wrote:

That's all well and good.  However, I just did a D PROD,STATE on my
systems and several products - CPCS, the imaging software, CICS, DB2,
and MQ - are not in this list, but they are all producing SMF Type89
records.  The ones for CICS, DB2, and MQ are run though SCRT every month
to produce the reports for IBM sub-capacity pricing.  So it appears that
this is not necessarily required to get the SMF Type 89 records.
  


Right. The DISPLAY PROD command is for products that use IFAEDREG and 
IFAEDDRG. Products that use IFAUSAGE do not appear there. SMF 89.1 
records were being produced for IFAUSAGE long before the product 
registration concept was envisioned.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

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


Re: CEEPIPI incorrect recovery processing?

2009-09-14 Thread Don Poitras
If you change to SYSMDUMP and use the IPCS command IP VERBX LEDATA
'ALL', you may be able to get a traceback and PSW/regs at time of
ABEND.

Gord Tomlin wrote:
 
 Just looking for input as to whether this is working as designed
 before I report it as a defect...
 
 If a program that uses CEEPIPI to call HLL subroutines abends while
 *not* in any of the HLL subroutines, LE recovery processes the abend and
 transforms a system abend into a LE user abend. Meanwhile, the
 associated dump is written to SYSUDUMP rather than CEEDUMP.
 
 This situation can be recreated by using the samples ASMPIPI and
 HLLPIPI from the LE Programming Guide, and adding the abend of your
 choice (I used EX 0,*) after the label TSUB in ASMPIPI. Instead of
 seeing a ABENDS0C3 in ASMPIPI, you will see a ABENDU4036-2 associated
 with CEEPLPKA. The only sign of the original abend is in the system
 trace table. Needless to say, LE's recovery routines have not made a
 positive contribution to locating the original problem.
 
 One of the requirements for a program that uses CEEPIPI to call
 LE-conforming HLL routines is that the calling routine *not* be a
 LE-conforming program, so it seems nonsensical on the surface that LE's
 recovery routines would try to interpret the abend.
 
 The LE Programming Guide says:
 - init_sub creates a LE environment and sets the environment dormant so
 that exceptions are percolated out of it.
 - for call_sub, CEEPIPI activates the LE environment before the called
 routine is invoked, and after the called routine returns, the
 environment is dormant.
 
 It appears to me that LE is doing an incomplete job of
 ignoring/percolating abends that occur while outside of the LE
 environment. Does anyone know anything to the contrary?
 
 Thanks!
 --
 
 Regards, Gord Tomlin
 Action Software International
 (a division of Mazda Computer Corporation)
 Tel: (905) 470-7113, Fax: (905) 470-6507, gord.tom...@actionsoftware.com

-- 
Don Poitras - zSeries R  D  -  SAS Institute Inc. -  SAS Campus Drive 
mailto:sas...@sas.com   (919)531-5637  Fax:677- Cary, NC 27513

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


Re: Use of RETAIN

2009-09-14 Thread Joseph Butz
Hi Daniel,

On quick look, I don't see a problem.  Have you sent this problem to us at
Innovation?  We haven't seen it yet.  Please submit the job and output to
the support email for us to review at your convenience.

Thanks,

Joseph Butz 
jb...@fdrinnovation.com



-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Daniel McLaughlin
Sent: Monday, September 14, 2009 10:48 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Use of RETAIN

Here is a short version of the job...and it croaks trying to open up the
tape in 
the second part of the second step. We thought maybe it was a DD name 
conflict and changed the scheme for a test, same results...opened with IBM 
and will do the same with FDR folks. This job will be all generated by REXX
to 
be dynamic.

  
//TAPE1  DD DSN=PDR.TSTBKP.AIG002(+1),

//  DISP=(NEW,CATLG,DELETE),

//  UNIT=(TAPE92,,DEFER),

//  DCB=(IPOBAK.PATTERN.DSCB,BUFNO=10),

//  LABEL=(1,SL,EXPDT=99000),

//  VOL=(,RETAIN)

//DISK2  DD UNIT=3390,DISP=SHR,VOL=SER=DBPK23

//TAPE2  DD DSN=PDR.TSTBKP.DBPK23(+1),

//  DISP=(NEW,CATLG,DELETE),

//  UNIT=(TAPE92,,DEFER),

//  LABEL=(2,SL,EXPDT=99000),

//  DCB=(IPOBAK.PATTERN.DSCB,BUFNO=10),

//  VOL=(PRIVATE,RETAIN,REF=*.TAPE1)

//SYSIN  DD DSN=PROD.PARMLIB(DR100),DISP=SHR

//SYSPRINT DD SYSOUT=*

//SYSPRIN1 DD SYSOUT=*

//SYSDUMP  DD SYSOUT=*

//ABRMAP   DD SYSOUT=*

//* End of Step

//DUMP2  EXEC PGM=FDR,REGION=8M

//DISKA  DD UNIT=3390,DISP=SHR,VOL=SER=DB0034

//TAPEA  DD DSN=PDR.TSTBKP.DB0034(+1),

//  DISP=(NEW,CATLG,DELETE),

//  DCB=(IPOBAK.PATTERN.DSCB,BUFNO=10),

//  UNIT=(TAPE92,,DEFER),

//  LABEL=(3,SL,EXPDT=99000),

//  VOL=(,RETAIN,,,REF=*.DUMP1.TAPE1)

//DISKB  DD UNIT=3390,DISP=SHR,VOL=SER=DB0035

//TAPEB  DD DSN=PDR.TSTBKP.DB0035(+1),

//  DISP=(NEW,CATLG,DELETE),

//  UNIT=(TAPE92,,DEFER),

//  LABEL=(4,SL,EXPDT=99000),

//  DCB=(IPOBAK.PATTERN.DSCB,BUFNO=10),

//  VOL=(,RETAIN,,,REF=*.DUMP1.TAPE1)

//SYSIN  DD DSN=PROD.PARMLIB(DR100),DISP=SHR

//SYSPRINT DD SYSOUT=*

//SYSPRIN1 DD SYSOUT=*

//SYSDUMP  DD SYSOUT=*

//ABRMAP   DD SYSOUT=*

//NOTIFY EXEC PGM=WTOPGM,COND=((3,GT),EVEN),

// PARM='JOB DRAIG001  BACKUP FAILED ON MVS'

//NOTIFY EXEC PGM=WTOPGM,COND=(1,LT),

// PARM='JOB DRAIG001  BACKUP SUCCESSFUL ON MVS'

//*


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

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


Re: CEEPIPI incorrect recovery processing?

2009-09-14 Thread Gord Tomlin
Thanks Don, but my mission here is not how to get at the LE information 
in the dump, but rather to have LE's recovery routines entirely out of 
the way when an abend occurs outside of the LE environment.


The LE Programming Guide says that when control is returned to the 
caller of CEEPIPI, the environment is set dormant so that exceptions are 
percolated out of it. While it does not explicitly say whether it will 
alter the abend information before percolating it, to me it seems like 
common sense that it would not. However, it is.


I think this is a defect, but I just want to find out whether anyone 
knows of a good reason why this should be considered to be correct 
operation first.


Don Poitras wrote:

If you change to SYSMDUMP and use the IPCS command IP VERBX LEDATA
'ALL', you may be able to get a traceback and PSW/regs at time of
ABEND.

Gord Tomlin wrote:

Just looking for input as to whether this is working as designed
before I report it as a defect...

If a program that uses CEEPIPI to call HLL subroutines abends while
*not* in any of the HLL subroutines, LE recovery processes the abend and
transforms a system abend into a LE user abend. Meanwhile, the
associated dump is written to SYSUDUMP rather than CEEDUMP.

This situation can be recreated by using the samples ASMPIPI and
HLLPIPI from the LE Programming Guide, and adding the abend of your
choice (I used EX 0,*) after the label TSUB in ASMPIPI. Instead of
seeing a ABENDS0C3 in ASMPIPI, you will see a ABENDU4036-2 associated
with CEEPLPKA. The only sign of the original abend is in the system
trace table. Needless to say, LE's recovery routines have not made a
positive contribution to locating the original problem.

One of the requirements for a program that uses CEEPIPI to call
LE-conforming HLL routines is that the calling routine *not* be a
LE-conforming program, so it seems nonsensical on the surface that LE's
recovery routines would try to interpret the abend.

The LE Programming Guide says:
- init_sub creates a LE environment and sets the environment dormant so
that exceptions are percolated out of it.
- for call_sub, CEEPIPI activates the LE environment before the called
routine is invoked, and after the called routine returns, the
environment is dormant.

It appears to me that LE is doing an incomplete job of
ignoring/percolating abends that occur while outside of the LE
environment. Does anyone know anything to the contrary?

Thanks!
--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507, gord.tom...@actionsoftware.com




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


Hiperbatch, Smartbatch, Dynamic Cache Management

2009-09-14 Thread gsg
Wondering if Hiperbatch, smartbatch, Dynamic Cache Management are still 
valid for improving performance with todays processors, DASD, OS etc...  I 
don't think that we use any of these and are only now starting to look at 
SMB.  Any feed back would be appreciated. 

And yes we are having performance problems.  Actually, I think we are just 
maxing out our processor.

Thanks

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


Internal Reader Problem

2009-09-14 Thread Mark Yuhas
We have 3 LPARs in our sysplex all in the same MAS.  All running z/OS
1.7.  We have an anomaly we can't explain.
When a job is submitted on System A, it is converted on system B.  Due
to the scheduling environment, the job
executes and ABENDs on System A.  Designating SYSAFF=A resolved the
problem.
   
Even though both systems have the same PROC name.  The PROCs our
different on each system.  My conclusion,
albeit uninformed, is that when the job was submitted on system A, all
of the Conversion PCEs on System A were
active and so a Conversion PCE on system B performed the conversion.

Is there a way, besides an exit, to force a job without a SYSAFF
designation to be converted on the same system
that it was submitted on?  


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


Re: Internal Reader Problem

2009-09-14 Thread Mark Zelden
On Mon, 14 Sep 2009 13:21:24 -0700, Mark Yuhas mark.yu...@paccar.com wrote:

We have 3 LPARs in our sysplex all in the same MAS.  All running z/OS
1.7.  We have an anomaly we can't explain.
When a job is submitted on System A, it is converted on system B.  Due
to the scheduling environment, the job
executes and ABENDs on System A.  Designating SYSAFF=A resolved the
problem.
   
Even though both systems have the same PROC name.  The PROCs our
different on each system.  My conclusion,
albeit uninformed, is that when the job was submitted on system A, all
of the Conversion PCEs on System A were
active and so a Conversion PCE on system B performed the conversion.

Is there a way, besides an exit, to force a job without a SYSAFF
designation to be converted on the same system
that it was submitted on?  


You can update the INTRDR statement in the init deck or via operator
command.  If you share the init deck, you can use SYSNAME.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

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


Re: Internal Reader Problem

2009-09-14 Thread Paul Gilmartin
On Mon, 14 Sep 2009 13:21:24 -0700, Mark Yuhas wrote:
   
Even though both systems have the same PROC name.  The PROCs our
different on each system.  ...

Is there a way, besides an exit, to force a job without a SYSAFF
designation to be converted on the same system
that it was submitted on?  

Take a different approach:

o Put identically named PROCs in different libraries and use
  the JCLLIB statement to select among them.  That way, whichever
  behavior is desired is available on either system.

o Or, just use different names for different PROCs.

-- gil

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


Re: CEEPIPI incorrect recovery processing?

2009-09-14 Thread Steve Comstock

Gord Tomlin wrote:
Just looking for input as to whether this is working as designed 
before I report it as a defect...


If a program that uses CEEPIPI to call HLL subroutines abends while 
*not* in any of the HLL subroutines, LE recovery processes the abend and 
transforms a system abend into a LE user abend. Meanwhile, the 
associated dump is written to SYSUDUMP rather than CEEDUMP.


Let me understand a little better:

1. Your driver initializes an LE environment for running
   subroutines by calling CEEPIPI with a request code of
   3 (init_sub)

   So I assume, for the moment, your PIPI table is set
   up correctly.

   [BTW, is this new behavior for you? Was it working before
and now it acts differently? Or is this your first time
through the PIPI process?]


2. You call your subroutine by calling CEEPIPI with a
   request code of 4 (run_sub) and it presumably runs OK

3. You call one or more additional subroutines (or your
   first subroutine again)

   at some time during this process, between two calls
   of subroutines from your PIPI table, your driver
   abends and gets an LE UCC

Is that about right?






This situation can be recreated by using the samples ASMPIPI and 
HLLPIPI from the LE Programming Guide, and adding the abend of your 
choice (I used EX 0,*) after the label TSUB in ASMPIPI. Instead of 
seeing a ABENDS0C3 in ASMPIPI, you will see a ABENDU4036-2 associated 
with CEEPLPKA. The only sign of the original abend is in the system 
trace table. Needless to say, LE's recovery routines have not made a 
positive contribution to locating the original problem.


One of the requirements for a program that uses CEEPIPI to call 
LE-conforming HLL routines is that the calling routine *not* be a 
LE-conforming program, so it seems nonsensical on the surface that LE's 
recovery routines would try to interpret the abend.


The LE Programming Guide says:
- init_sub creates a LE environment and sets the environment dormant so 
that exceptions are percolated out of it.
- for call_sub, CEEPIPI activates the LE environment before the called 
routine is invoked, and after the called routine returns, the 
environment is dormant.


It appears to me that LE is doing an incomplete job of 
ignoring/percolating abends that occur while outside of the LE 
environment. Does anyone know anything to the contrary?


Thanks!



--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

== Ask about being added to our opt-in list:  ==
==   * Early announcement of new courses  ==
==   * Early announcement of new techincal papers ==
==   * Early announcement of new promotions   ==

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


Re: file integrity verified - do I care?

2009-09-14 Thread Shmuel Metz (Seymour J.)
In jhkka59q0bavje123mfp9mp5cgdnmhm...@4ax.com, on 09/11/2009
   at 07:37 AM, Howard Brazee howard.bra...@cusys.edu said:

So how do you use it?   What do you do differently when you get a 97 than
when you get a 00?

Depending on the application, I might put out a message saying to
reconstruct from logs.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Carrier Pigeon beats Internet Speed

2009-09-14 Thread Shmuel Metz (Seymour J.)
In a30a9f528e618748a8ef5199e80c4a1c69a...@wkpp1infmb03.cbsh.com, on
09/11/2009
   at 02:00 PM, Kelman, Tom thomas.kel...@commercebank.com said:

Subject: Carrier Pigeon beats Internet Speed

Using RFC 1149?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: $HASP050 JES2 RESOURCE SHORTAGE OF BUFX - 0% UTILIZATION REACHED

2009-09-14 Thread Shmuel Metz (Seymour J.)
In lkkka5lk61hs8pbmnvs4c43gc80bnff...@4ax.com, on 09/11/2009
   at 07:39 AM, Howard Brazee howard.bra...@cusys.edu said:

I also once wrote a check out using mills, when the calculation indicated
I should do so, and there were no instructions on how to round.   It may
be legal tender, but they couldn't handle it.

The intent isn't to make an extraneous payment; the intent is to forcibly
bring it to the attention of somebody in a position to get it fixed.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: CLIST/REXX Library Formats

2009-09-14 Thread Shmuel Metz (Seymour J.)
In 4aa9651c.4010...@ync.net, on 09/10/2009
   at 03:44 PM, Rick Fochtman rfocht...@ync.net said:

Which is more effieient for CLIST/REXX libraries? the choices are 
RECFM=FB, LRECL=255 or RECFM=FB,LRECL=80?

If you can't use RECFM=VB, then use the smallest LRECL that your code will
fit into. Matching LRECL to your ISPF display width makes editing easier,
which may be more important than efficiency.

If you need to have existing libraries in SYSEXEC or SYSPROC then keep
RECFM and LRECL consistent with what they will be concatenated into; it's
not efficient if it doesn't work ;-)
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: CLIST/REXX Library Formats

2009-09-14 Thread Shmuel Metz (Seymour J.)
In
32208482.1252616974481.javamail.r...@elwamui-cypress.atl.sa.earthlink.net,
on 09/10/2009
   at 05:09 PM, Lizette Koehler stars...@mindspring.com said:

I think the Lrecl80 came from the punch card days.  The people I worked
with back in 1980 preferred the 80 byte record because they came from
punch cards.

Well, I started with EAM cards and I prefer RECFM=VB, LRECL=255.

I do not recall when we were able to go from the 24x80 screen to
mod3/mod4/mod5. 

The 3278-5 and the 3290 have been around for about three decades.

With the advances of screen szie (162x??)

I don't recall anything with that size; the 3290 was a maximum of 160
across. Of course, you can always define custom screen sizes in your 3270
simulator, but then you can do substantially more than 162 across.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: CLIST/REXX Library Formats

2009-09-14 Thread Shmuel Metz (Seymour J.)
In 6134cdf9e3c17546be1c9d525bdeef95f07eebe...@hqmail.rocketsoftware.com,
on 09/10/2009
   at 06:04 PM, Bob Shannon bshan...@rocketsoftware.com said:

With VLF, it pretty much doesn't matter.

For SYSPROC; it does for SYSEXEC.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: CLIST/REXX Library Formats

2009-09-14 Thread Shmuel Metz (Seymour J.)
In dc74548a025aff4a85f46926802a9b2303723...@chsa1035.share.beluni.net,
on 09/11/2009
   at 08:24 AM, Hunkeler Peter (KIUP 4)
peter.hunke...@credit-suisse.com said:

Interesting that you can see 80 characters in the 72 
positions the ISPF editor has to display the data ;-)

It would have been had he made such a claim; he didn't. ISPF/PDF EDIT uses
only six columns for sequence numbers and does not display the change
level unless you shift into the sequence field.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: CLIST/REXX Library Formats

2009-09-14 Thread Shmuel Metz (Seymour J.)
In db9405830909102240xade49f9o9adc503905547...@mail.gmail.com, on
09/11/2009
   at 03:40 PM, Wayne Bickerdike wayn...@gmail.com said:

So many times have novices asked me why their REXX was failing and it was
sequence numbers in 73-80. Can still happen for VB 255

No; for RECFM=VB the sequence numbers are on the left. However, the RENUM
command used to be BAD for unnumbered RECFM=VB. Have they fixed it to
shift the data right 8 columns before plugging in sequence numbers?

It should be 133 anyway, makes coding for my 1403 line printer a cinch
:)

Why not 145 for the 1443 or 242 for the 3800?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Internal Reader Problem

2009-09-14 Thread Scott Rowe
I didn't think you could put it on the INTRDR statement, but I've been using 
$T INTRDR,SYSAFF=* in the init deck for decades, no need for a system symbol 
;-)

 Mark Zelden mark.zel...@zurichna.com 9/14/2009 4:36 PM 
On Mon, 14 Sep 2009 13:21:24 -0700, Mark Yuhas mark.yu...@paccar.com wrote:

You can update the INTRDR statement in the init deck or via operator
command.  If you share the init deck, you can use SYSNAME.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com 
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ 
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html 

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



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.


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


Re: CEEPIPI incorrect recovery processing?

2009-09-14 Thread Gord Tomlin

Hi Steve,

You're close! I'll go through your points in order:

1. Correct. CEEPIPI is called with request code 3 (init_sub). The PIPI 
table is set up correctly. For the demonstration case (IBM's sample to 
keep things simple) I took a working program and added an intentional 
ABENDS0C3.


For your supplementary questions, I decided to create this demonstration 
case when I saw LE presenting user abends for system abends that 
occurred outside of the LE environment. We are in the process of 
developing an application that is making use of CEEPIPI, and on the 
happy path everything works fine. As for the treatment of abends 
outside the LE environment, this is not changed behavior. However, that 
does not automatically mean it is correct behavior.


2. Correct. CEEPIPI is called with request 4 (call_sub), and the called 
subroutine runs OK.


3. Correct. The abend occurs between two calls to CEEPIPI.

Note, however, that it is not necessary to call any subroutines to get 
this situation. If the driver program abends after receiving control 
back from CEEPIPI after the init_sub call, the abend information will 
still be altered by LE's recovery routines.


Regards, Gord Tomlin

Steve Comstock wrote:

Gord Tomlin wrote:
Just looking for input as to whether this is working as designed 
before I report it as a defect...


If a program that uses CEEPIPI to call HLL subroutines abends while 
*not* in any of the HLL subroutines, LE recovery processes the abend 
and transforms a system abend into a LE user abend. Meanwhile, the 
associated dump is written to SYSUDUMP rather than CEEDUMP.


Let me understand a little better:

1. Your driver initializes an LE environment for running
   subroutines by calling CEEPIPI with a request code of
   3 (init_sub)

   So I assume, for the moment, your PIPI table is set
   up correctly.

   [BTW, is this new behavior for you? Was it working before
and now it acts differently? Or is this your first time
through the PIPI process?]


2. You call your subroutine by calling CEEPIPI with a
   request code of 4 (run_sub) and it presumably runs OK

3. You call one or more additional subroutines (or your
   first subroutine again)

   at some time during this process, between two calls
   of subroutines from your PIPI table, your driver
   abends and gets an LE UCC

Is that about right?






This situation can be recreated by using the samples ASMPIPI and 
HLLPIPI from the LE Programming Guide, and adding the abend of your 
choice (I used EX 0,*) after the label TSUB in ASMPIPI. Instead of 
seeing a ABENDS0C3 in ASMPIPI, you will see a ABENDU4036-2 associated 
with CEEPLPKA. The only sign of the original abend is in the system 
trace table. Needless to say, LE's recovery routines have not made a 
positive contribution to locating the original problem.


One of the requirements for a program that uses CEEPIPI to call 
LE-conforming HLL routines is that the calling routine *not* be a 
LE-conforming program, so it seems nonsensical on the surface that 
LE's recovery routines would try to interpret the abend.


The LE Programming Guide says:
- init_sub creates a LE environment and sets the environment dormant 
so that exceptions are percolated out of it.
- for call_sub, CEEPIPI activates the LE environment before the called 
routine is invoked, and after the called routine returns, the 
environment is dormant.


It appears to me that LE is doing an incomplete job of 
ignoring/percolating abends that occur while outside of the LE 
environment. Does anyone know anything to the contrary?


Thanks!





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


TCB Address

2009-09-14 Thread Digestani, Raul
Hello all.
I'm asking about how to obtain current TCB address in an assembly pgm. 
Any help will be appreciated; thanks in advance.
 

__

Raúl Daniel Digestani 

Bco. Santander Río S.A.
CC 011 - Desarrollo de Sistemas II 
Gral. Hornos 238 - Piso 3 - Buenos Aires
Tel. (54 11) 4137-4242 / 5030-4242

rdigest...@santanderrio.com.ar

 


*
Visite http://www.santanderrio.com.ar y tenga el Banco al alcance de su
mano.
*
NOTA DE CONFIDENCIALIDAD / CONFIDENTIALITY NOTE
Este mensaje (y sus anexos) es confidencial y puede contener
información (i) de propiedad exclusiva de Banco Santander Rio S.A.
sus afiliadas o subsidiarias; o (ii) amparada por el secreto
profesional. Si usted ha recibido este fax o e-mail por error, por
favor comuníquelo inmediatamente vía fax o e-mail y tenga la
amabilidad de destruirlo; no debera copiar el mensaje ni divulgar su
contenido a ninguna persona.
Muchas gracias.

This message (including attachments) is confidential. It may also
contain information that (i) is exclusively property of Banco Santander Rio 
S.A. or its affiliates or subsidiaries; or (ii) is
privileged or otherwise legally exempt from disclosure. If you have
received it by mistake please let us know by fax or e-mail
immediately and destroy or delete it from your files or system; you
should also not copy the message nor disclose its contents to anyone.
Thank you.
*


Re: TCB Address

2009-09-14 Thread Chuck Arney
The field PSATOLD in the PSA contains the address of the TCB of the
active task.

Chuck Arney
illustro Systems International, LLC
http://www.illustro.com
Internet-enable your applications with z/Ware V2
Voice: 214-800-8900 X#5562
--
This e-mail is private and may be confidential and is for the intended
recipient only. If misdirected, please notify us by telephone and
confirm that it has been deleted from your system and any copies
destroyed. If you are not the intended recipient you are strictly
prohibited from using, printing, copying, distributing or disseminating
this e-mail or any information contained in it.  
  
We use reasonable measures to virus scan all E-mails leaving illustro
but no warranty is given that this E-mail and any attachments are virus
free. You should ensure you have adequate measures in place for your own
virus checking.

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
 Behalf Of Digestani, Raul
 Sent: Monday, September 14, 2009 5:09 PM
 To: IBM-MAIN@bama.ua.edu
 Subject: TCB Address
 
 Hello all.
 I'm asking about how to obtain current TCB address in an assembly pgm.
 Any help will be appreciated; thanks in advance.
 

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


Re: TCB Address

2009-09-14 Thread William H. Blair
  how to obtain current TCB address in an assembly pgm.

USING PSA,0   PSA addressability
L R3,PSATOLD  - Current TCB
USING TCB,R3  TCB addressability
...
IHAPSA LIST=NOPSA DSECT
IKJTCB LIST=NOTCB DSECT

--
WB

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


Re: CEEPIPI incorrect recovery processing?

2009-09-14 Thread Steve Comstock

Gord Tomlin wrote:

Hi Steve,

You're close! I'll go through your points in order:

1. Correct. CEEPIPI is called with request code 3 (init_sub). The PIPI 
table is set up correctly. For the demonstration case (IBM's sample to 
keep things simple) I took a working program and added an intentional 
ABENDS0C3.


For your supplementary questions, I decided to create this demonstration 
case when I saw LE presenting user abends for system abends that 
occurred outside of the LE environment. We are in the process of 
developing an application that is making use of CEEPIPI, and on the 
happy path everything works fine. As for the treatment of abends 
outside the LE environment, this is not changed behavior. However, that 
does not automatically mean it is correct behavior.


2. Correct. CEEPIPI is called with request 4 (call_sub), and the called 
subroutine runs OK.


3. Correct. The abend occurs between two calls to CEEPIPI.

Note, however, that it is not necessary to call any subroutines to get 
this situation. If the driver program abends after receiving control 
back from CEEPIPI after the init_sub call, the abend information will 
still be altered by LE's recovery routines.


Regards, Gord Tomlin



Well, I was going to try the sample code but I'm having a devil
of a time cutting-and-pasting from the pdf to a source member.

Can you send me your source (offlist, if you wish) to same me
some time on this?

[I got the hllpipi done, just need the driver to test and
experiment with.]


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

== Ask about being added to our opt-in list:  ==
==   * Early announcement of new courses  ==
==   * Early announcement of new techincal papers ==
==   * Early announcement of new promotions   ==

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


Re: stop-x37 type of function in SMS

2009-09-14 Thread Neil Duffee
On 2009-09-11 at 16:14, concerning stop-x37 type of function in 
SMS, jam...gr...@efir...com wrote to IBM-Main:  

 While at SARE a couple weeks ago my manager was told by an IBM'er that
 SMS could handle space abends like a STOP-X37 product. 
 
 Has anyone heard this and if so how is it implemented? 

Jim: I've been using something similar for several years now.  Check 
out the concept 'Overflow Storage Group'  as well as 'Extend Storage 
Group'.

In short, I created a StorGrp (appropriately named SPILL) with empty 
volumes for overflow.  The volumes are Enabled but the StorGrp is 
Quiesced.  In your StorGrp ACS routine, append the SPILL group to all 
SET STORGRP= statements that you want protected.  (there might be 
reasons not to)  

The volumes in a Quiesced StorGrp are less preferred than volumes in 
a normal pool.  I also like to have a quiesced volume (or 3) in each 
pool which is preferred over the Quiesced StorGrp.  If datasets end 
up in the overflow pool on a regular basis, the primary pool likely 
needs more volumes.  Read SMS Volume selection for Data Set 
allocation in the Storage Admin Reference manual (mine's SC26-7402-
01) for a blow-by-blow description.  

Other aids, that I can think of, require the use of a DataClas; 
specifically the 'Space Constraint Relief', 'Dynamic Volume Count'  
and, potentially, the 'Extended Format/Addressing' attributes.  I'll 
let you investigate.

--  signature = 6 lines follows --
Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585 fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uottawa.ca/ ~nduffee
How *do* you plan for something like that? Guardian Bob, Reboot
For every action, there is an equal and opposite criticism.
Systems Programming: Guilty, until proven innocent John Norgauer 
2004

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


Re: CEEPIPI incorrect recovery processing?

2009-09-14 Thread Gord Tomlin
I agree, the cut-and-paste out of the PDF is painful. I've sent you 
ASMPIPI off list. You already have HLLPIPI.


Steve Comstock wrote:

Gord Tomlin wrote:

Hi Steve,

You're close! I'll go through your points in order:

1. Correct. CEEPIPI is called with request code 3 (init_sub). The PIPI 
table is set up correctly. For the demonstration case (IBM's sample to 
keep things simple) I took a working program and added an intentional 
ABENDS0C3.


For your supplementary questions, I decided to create this 
demonstration case when I saw LE presenting user abends for system 
abends that occurred outside of the LE environment. We are in the 
process of developing an application that is making use of CEEPIPI, 
and on the happy path everything works fine. As for the treatment of 
abends outside the LE environment, this is not changed behavior. 
However, that does not automatically mean it is correct behavior.


2. Correct. CEEPIPI is called with request 4 (call_sub), and the 
called subroutine runs OK.


3. Correct. The abend occurs between two calls to CEEPIPI.

Note, however, that it is not necessary to call any subroutines to get 
this situation. If the driver program abends after receiving control 
back from CEEPIPI after the init_sub call, the abend information will 
still be altered by LE's recovery routines.


Regards, Gord Tomlin



Well, I was going to try the sample code but I'm having a devil
of a time cutting-and-pasting from the pdf to a source member.

Can you send me your source (offlist, if you wish) to same me
some time on this?

[I got the hllpipi done, just need the driver to test and
experiment with.]




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


Re: CEEPIPI incorrect recovery processing?

2009-09-14 Thread Steve Comstock

Gord Tomlin wrote:

Hi Steve,

You're close! I'll go through your points in order:

1. Correct. CEEPIPI is called with request code 3 (init_sub). The PIPI 
table is set up correctly. For the demonstration case (IBM's sample to 
keep things simple) I took a working program and added an intentional 
ABENDS0C3.


For your supplementary questions, I decided to create this demonstration 
case when I saw LE presenting user abends for system abends that 
occurred outside of the LE environment. We are in the process of 
developing an application that is making use of CEEPIPI, and on the 
happy path everything works fine. As for the treatment of abends 
outside the LE environment, this is not changed behavior. However, that 
does not automatically mean it is correct behavior.


2. Correct. CEEPIPI is called with request 4 (call_sub), and the called 
subroutine runs OK.


3. Correct. The abend occurs between two calls to CEEPIPI.

Note, however, that it is not necessary to call any subroutines to get 
this situation. If the driver program abends after receiving control 
back from CEEPIPI after the init_sub call, the abend information will 
still be altered by LE's recovery routines.


Regards, Gord Tomlin

Steve Comstock wrote:

Gord Tomlin wrote:
Just looking for input as to whether this is working as designed 
before I report it as a defect...


If a program that uses CEEPIPI to call HLL subroutines abends while 
*not* in any of the HLL subroutines, LE recovery processes the abend 
and transforms a system abend into a LE user abend. Meanwhile, the 
associated dump is written to SYSUDUMP rather than CEEDUMP.


Let me understand a little better:

1. Your driver initializes an LE environment for running
   subroutines by calling CEEPIPI with a request code of
   3 (init_sub)

   So I assume, for the moment, your PIPI table is set
   up correctly.

   [BTW, is this new behavior for you? Was it working before
and now it acts differently? Or is this your first time
through the PIPI process?]


2. You call your subroutine by calling CEEPIPI with a
   request code of 4 (run_sub) and it presumably runs OK

3. You call one or more additional subroutines (or your
   first subroutine again)

   at some time during this process, between two calls
   of subroutines from your PIPI table, your driver
   abends and gets an LE UCC

Is that about right?






This situation can be recreated by using the samples ASMPIPI and 
HLLPIPI from the LE Programming Guide, and adding the abend of 
your choice (I used EX 0,*) after the label TSUB in ASMPIPI. Instead 
of seeing a ABENDS0C3 in ASMPIPI, you will see a ABENDU4036-2 
associated with CEEPLPKA. The only sign of the original abend is in 
the system trace table. Needless to say, LE's recovery routines have 
not made a positive contribution to locating the original problem.


One of the requirements for a program that uses CEEPIPI to call 
LE-conforming HLL routines is that the calling routine *not* be a 
LE-conforming program, so it seems nonsensical on the surface that 
LE's recovery routines would try to interpret the abend.


The LE Programming Guide says:
- init_sub creates a LE environment and sets the environment dormant 
so that exceptions are percolated out of it.
- for call_sub, CEEPIPI activates the LE environment before the 
called routine is invoked, and after the called routine returns, the 
environment is dormant.


It appears to me that LE is doing an incomplete job of 
ignoring/percolating abends that occur while outside of the LE 
environment. Does anyone know anything to the contrary?


Thanks!


OK, I recreated your sample. But I think you're not being
correct in your testing. You said to induce an ABEND after
the label TSUB; but this is the point where the termination
of the LE environment occurs. So you are introducing an
abend before turning off LE, if you will.

If you move your abend instruction to after the symbol
DONE you get a standard z/OS (MVS) ABEND.

I think the error is misunderstanding the environment is
dormant; it means, essentially, unused but available. If
an error occurs before you do a term request, you still
have an LE environment present.

If you will be doing multiple calls of one subroutine,
or of many subroutines consecutively, either do a
term after each call_sub and an init_sub before each
call; or, start with a init_sub_dp, then a start_seq,
then all the call_sub's you need, then an end_seq,
then a term.

And remember, if you will be doing multiple calls of
a routine, that routine should be RENT.

Hope this helps.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

  z/OS Application development made easier
* Our classes include
   + How things work
   + Programming examples with realistic applications
   + Starter / skeleton code
   + Complete working programs
   + Useful utilities and subroutines
   + Tips and techniques

== Ask about being 

Re: CEEPIPI incorrect recovery processing?

2009-09-14 Thread Gord Tomlin
Definitely, the key item is the meaning of dormant. Clearly, the 
environment exists until it is destroyed by the term call. The 
question is what should happen when the environment exists but is dormant.


IBM states in the description of init_sub that it sets the environment 
dormant so that exceptions are percolated out of it. The issue is 
whether it is correct for the LE recovery routines to alter the abend 
information for an abend that occurs while the environment is dormant. 
Since it is a documented that callers of CEEPIPI not be LE compliant, it 
is illogical for LE to alter the abend information for an abend that 
occurs in this non LE-compliant environment.


The idea of terminating the environment after every subroutine 
eliminates one of the main benefits of using CEEPIPI, that being the 
avoidance of the overhead of creating and destroying the LE environment 
around every subroutine call.


Steve Comstock wrote:

Gord Tomlin wrote:

Hi Steve,

You're close! I'll go through your points in order:

1. Correct. CEEPIPI is called with request code 3 (init_sub). The PIPI 
table is set up correctly. For the demonstration case (IBM's sample to 
keep things simple) I took a working program and added an intentional 
ABENDS0C3.


For your supplementary questions, I decided to create this 
demonstration case when I saw LE presenting user abends for system 
abends that occurred outside of the LE environment. We are in the 
process of developing an application that is making use of CEEPIPI, 
and on the happy path everything works fine. As for the treatment of 
abends outside the LE environment, this is not changed behavior. 
However, that does not automatically mean it is correct behavior.


2. Correct. CEEPIPI is called with request 4 (call_sub), and the 
called subroutine runs OK.


3. Correct. The abend occurs between two calls to CEEPIPI.

Note, however, that it is not necessary to call any subroutines to get 
this situation. If the driver program abends after receiving control 
back from CEEPIPI after the init_sub call, the abend information will 
still be altered by LE's recovery routines.


Regards, Gord Tomlin

Steve Comstock wrote:

Gord Tomlin wrote:
Just looking for input as to whether this is working as designed 
before I report it as a defect...


If a program that uses CEEPIPI to call HLL subroutines abends while 
*not* in any of the HLL subroutines, LE recovery processes the abend 
and transforms a system abend into a LE user abend. Meanwhile, the 
associated dump is written to SYSUDUMP rather than CEEDUMP.


Let me understand a little better:

1. Your driver initializes an LE environment for running
   subroutines by calling CEEPIPI with a request code of
   3 (init_sub)

   So I assume, for the moment, your PIPI table is set
   up correctly.

   [BTW, is this new behavior for you? Was it working before
and now it acts differently? Or is this your first time
through the PIPI process?]


2. You call your subroutine by calling CEEPIPI with a
   request code of 4 (run_sub) and it presumably runs OK

3. You call one or more additional subroutines (or your
   first subroutine again)

   at some time during this process, between two calls
   of subroutines from your PIPI table, your driver
   abends and gets an LE UCC

Is that about right?






This situation can be recreated by using the samples ASMPIPI and 
HLLPIPI from the LE Programming Guide, and adding the abend of 
your choice (I used EX 0,*) after the label TSUB in ASMPIPI. Instead 
of seeing a ABENDS0C3 in ASMPIPI, you will see a ABENDU4036-2 
associated with CEEPLPKA. The only sign of the original abend is in 
the system trace table. Needless to say, LE's recovery routines have 
not made a positive contribution to locating the original problem.


One of the requirements for a program that uses CEEPIPI to call 
LE-conforming HLL routines is that the calling routine *not* be a 
LE-conforming program, so it seems nonsensical on the surface that 
LE's recovery routines would try to interpret the abend.


The LE Programming Guide says:
- init_sub creates a LE environment and sets the environment 
dormant so that exceptions are percolated out of it.
- for call_sub, CEEPIPI activates the LE environment before the 
called routine is invoked, and after the called routine returns, the 
environment is dormant.


It appears to me that LE is doing an incomplete job of 
ignoring/percolating abends that occur while outside of the LE 
environment. Does anyone know anything to the contrary?


Thanks!


OK, I recreated your sample. But I think you're not being
correct in your testing. You said to induce an ABEND after
the label TSUB; but this is the point where the termination
of the LE environment occurs. So you are introducing an
abend before turning off LE, if you will.

If you move your abend instruction to after the symbol
DONE you get a standard z/OS (MVS) ABEND.

I think the error is misunderstanding the environment is
dormant; it 

Re: [turnkey-mvs] turnkey mvs and cobol/jcl environment

2009-09-14 Thread Clark Morris
On 14 Sep 2009 07:38:40 -0700, in bit.listserv.ibm-main you wrote:

Thompson, Steve wrote:
 -Original Message-
 From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
 Behalf Of Andreas F. Geissbuehler
 Sent: Saturday, September 12, 2009 9:52 AM
 To: IBM-MAIN@bama.ua.edu
 Subject: Re: [turnkey-mvs] turnkey mvs and cobol/jcl environment
 
 SNIP
 I second Jo on this and URGE YOU to continue with herc 
 and MVS 3.8j, even Assembler 370, but forget COBOL. 
 
 You need to master current, modern COBOL which you can
 accomplish short-term by visiting Prof. Don Higgin's website
 at www.z390.org. Don's Java-based zASM and zCOBOL at
 www.zcobol.org are modern, state-of-the-art implementation
 which I recomend you should evaluate and consider to use,
 instead of, in addition to and/or in combination with TK3.
 
 SNIP
 
 Assuming he is running a M/S product, he can probably get one of the
 COBOL books with a COBOL CD in it. Fujitsu's COBOL runs nicely on NT,
 and W2K (with a few tweeks). I haven't tried it under XP.
 
 The use of the FCOBOL under MVS3.8 or the equivalent under DOS (R34?),
 will teach COBOL basics. 
 
 The PC based compilers will take that source (at least the Fujitsu one
 will) and produce working code under Winders.
 
 So the question is, where did OS/2 and a M/F compatible COBOL go? Why do
 people use Realia (do they still exist?) to do COBOL development on a PC
 and then upload the source to a M/F? [Same for the Fujitsu system.]
 
 It is because of IBM Marketing's view of the world. 
 
 Regards,
 Steve Thompson

Marketing, probably. The current COBOL developers have been
pushing the edge of modernity constantly. Now,

So explain why in 2009 Enterprise COBOL STILL can not recognize binary
character, IEEE  binary floating point and decimal floating point (the
latter pushed by Mike Cowlishaw of REXX fame) despite SHARE
requirements and despite C/C++ being able to do so.  We have LE to
encourage inter-language communication yet COBOL doesn't recognize
some basic data types despite them finally making it into the standard
in 2002 (except for decimal floating point which is being discussed).
Then there is the mind numbing idea that COBOL will ignore IEEE binary
floating point and define the 2002 standard floating point types as
decimal floating point.   The whole situation arouses the vitriolic
instincts and inclinations toward bitter sarcasm in me.  If I weren't
semi-retired (collecting pensions but willing to take contracts), I
might pursue this more actively.  

Oh yes, I understand there are OO classes in CICS that C/C++ can use
but I doubt they are available to COBOL.  Talk about lack of strategy.

Clark Morris  

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


Re: Hiperbatch, Smartbatch, Dynamic Cache Management

2009-09-14 Thread John Baxter
For DCME, have a look at Ron Hawkins' recent post:

http://bama.ua.edu/cgi-bin/wa?A2=ind0909L=ibm-mainP=R37609I=1X=-

If you are batch-constrained, the old Red Book: System/390 MVS Parallel
Sysplex Batch Performance - SG24-2557-00 has many pointers still valid
in even non-sysplexed environments.

Our own experiences focus on job scheduling, and stringent reviews of
DB2 application and subsystem performance.

FWIW... John


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of gsg
Sent: Monday, September 14, 2009 2:08 PM
To: IBM-MAIN@bama.ua.edu
Subject: Hiperbatch, Smartbatch, Dynamic Cache Management

Wondering if Hiperbatch, smartbatch, Dynamic Cache Management are still 
valid for improving performance with todays processors, DASD, OS etc...
I 
don't think that we use any of these and are only now starting to look
at 
SMB.  Any feed back would be appreciated. 

And yes we are having performance problems.  Actually, I think we are
just 
maxing out our processor.

Thanks

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


The information transmitted is intended only for the addressee and may contain 
confidential, proprietary and/or privileged material. Any unauthorized review, 
distribution or other use of or the taking of any action in reliance upon this 
information is prohibited. If you receive this in error, please contact the 
sender and delete or destroy this message and any copies.

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