date:20050801

In a recent note, arun kumar said:

 Date: Mon, 1 Aug 2005 01:43:23 -0700
 
 I am looking  for an easy way of printing USS files
 from USS to a network printer, something similar to
 LPR command in TSO that helps printing of PS/PDS with
 ease without changing JES2/VTAM PARMS.
 
Isn't it ironic that the TSO lpr command prints to the UNIX
spool, and the UNIX lpr command prints to the TSO spool?

 Can you please suggest.
 
Perhaps someone else can help.  It may involve defining
a writer that transfers a sysout class to the UNIX spool.

 My other question, can REXX exec be executed in USS?
 If yes, how to execute it.
 
Yes.

o Start your EXEC with /* REXX ... */

o chmod it to set the executable mode bits.

o place it in a directory in your executable search PATH.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: Command Reject

2005-08-01 Thread Craig Kittendorf

Thanks Ed.  Its an IBM Magstar (3490). The software is SYNCGENR (SYNCSORT).

Craig

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Edward E. Jaffe
Sent: Monday, August 01, 2005 12:20 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Command Reject

Craig Kittendorf wrote:

Hi,

I read the message manual but still don't know.  What is the following
trying to tell me?

   IOS000I 0920,B1,CMD,C2,0200,,**,,JFIMERGE  592   
8040202704202010(B320)(4100C2FF)8E0F95944896
   IOS000I 0920,B1,CMD,C2,0200,,**,M00164,JFIMERGE  593 
8040202704202010(B320)(4100C2FF)8E0F95944896

The job appeared to work otherwise.  Should I be concerned?

These messages tell you that a x'C2' (MEDIUM SENSE) command was rejected 
by the device. MEDIUM SENSE is supported by 3590 tape devices but not by 
older tape devices e.g., 3490. Either the executing program erroneously 
issued the command to a 3490, the 3590 device is somehow improperly 
defined to the system, some (ISV?) software caused a 3490 device to be 
improperly recognized by system code (even if defined correctly), or the 
3590 device is erroneously rejecting the command.

It could be that the executing program handled the command rejection 
gracefully and moved on without problems. Nevertheless, I would not 
ignore these messages. Something is wrong.

-- 
 -
| Edward E. Jaffe||
| Mgr, Research  Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
 -

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

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

Re: HLASM FLAG(PAGE0) and IBM Macros

2005-08-01 Thread Walt Farrell


On 7/31/2005 11:50 AM, Edward E. Jaffe wrote:
Currently, FLAG(PAGE0) flags all explicit references in which the base 
register is zero -- including those cases in which the index register 
for an RX-type instruction is non-zero e.g., 'B 4(R14)'. Such coding is 
fairly common practice. (Many years ago instructions coded this way 
actually ran slower, but that hasn't been true for a long, long time.) 
Furthermore, many instructions in AR-mode programs *must* be 
deliberately coded in this manner. Whether optional or required, such 
instructions should *not* be flagged as PSA references!


I think you may have meant that it flags all -implicit- references in 
which the base register is zero.  As I understand it, one fix for the 
assembler complaining about 'B 4(R14)' is to explicitly code it as

'B 4(R14,0)'


Walt

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

AW: Printing from USS

2005-08-01 Thread Sun Biao

the USS lp command similar to lpr in TSO works in such form: 
lp [-cmsw] [-d dest] [-n number] [-o printer-option] [-t title] [file...]
The dest is a printer name which must be defined in a print tool, such as IBM 
Infoprint Server operating under USS, with it's IP-Address. There wouldn't be 
an easy way as in TSO to print from USS.
Sun

-Ursprüngliche Nachricht-
Von: arun kumar [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 1. August 2005 10:43
An: IBM-MAIN@BAMA.UA.EDU
Betreff: Printing from USS


Esteemed Listers

I am looking  for an easy way of printing USS files
from USS to a network printer, something similar to
LPR command in TSO that helps printing of PS/PDS with
ease without changing JES2/VTAM PARMS.

Can you please suggest.

My other question, can REXX exec be executed in USS?
If yes, how to execute it.

TIA...Arun




Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

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

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

Re: SMP/E API GIM52801T? GIM52801E? Whatever.

2005-08-01 Thread Kurt Quackenbush


snip

Is UCLIN processing actually involved here, or is M  C misleading me.


UCLIN is not involved... the doc for message GIM52801E is misleading. 
This results from reusing a message and missing the appropriate doc 
updates.  I'll ensure a future instance of the book is corrected.



Further, when I specify qparms.csi=PREFIX.GLOBAL.CSIXYZ; and
qparms.csilen=strlen(csi); the API (apparently; a quick look at the
source of GIMCSAMP shows no such logic) truncates the DSNAME to
PREFIX.GLOBAL.CSI and successfully processes that data set.

snip

.. no mention of truncating excess characters from the lowest-level
qualifier.  Is this WAD, or perhaps some leftover test code?


Quite simply I believe it is a bug.  Unless you feel strongly and 
require an APAR, I'll see what I can do to fix it in a future release of 
SMP/E.


Kurt Quackenbush -- IBM, SMP/E Development

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

Re: HLASM FLAG(PAGE0) and IBM Macros

2005-08-01 Thread Edward E. Jaffe


Walt Farrell wrote:


On 7/31/2005 11:50 AM, Edward E. Jaffe wrote:

Currently, FLAG(PAGE0) flags all explicit references in which the 
base register is zero -- including those cases in which the index 
register for an RX-type instruction is non-zero e.g., 'B 4(R14)'. 
Such coding is fairly common practice. (Many years ago instructions 
coded this way actually ran slower, but that hasn't been true for a 
long, long time.) Furthermore, many instructions in AR-mode programs 
*must* be deliberately coded in this manner. Whether optional or 
required, such instructions should *not* be flagged as PSA references!



I think you may have meant that it flags all -implicit- references in 
which the base register is zero.  As I understand it, one fix for the 
assembler complaining about 'B 4(R14)' is to explicitly code it as 'B 
4(R14,0)'



I meant explicit in the sense that 'L Rx,PSATOLD-PSA' will generate a 
warning whereas 'USING PSA,R0' followed by 'L Rx,PSATOLD' will not.


You're right that coding workarounds exist. However, that won't help if 
you're not prepared to make those changes. We have one product that 
generates literally tens of thousands of PAGE0 warnings for perfectly 
legitimate code. Nobody wants to change them all. So we compile that 
product without the benefit of FLAG(PAGE0). My HLASM enhancement 
suggestion would solve that.


--
.-.
| Edward E. Jaffe||
| Mgr, Research  Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
'-'

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

Re: Command Reject

2005-08-01 Thread Craig Kittendorf

I discovered the job was not using SYNCGENR!  Sorry for the mis-information.
I'm still investigating.

Thanks
   Craig

-Original Message-
From: Kittendorf, Craig 
Sent: Monday, August 01, 2005 8:41 AM
To: 'IBM Mainframe Discussion List'
Subject: RE: Command Reject

Thanks Ed.  Its an IBM Magstar (3490). The software is SYNCGENR (SYNCSORT).

Craig

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Edward E. Jaffe
Sent: Monday, August 01, 2005 12:20 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Command Reject

Craig Kittendorf wrote:

Hi,

I read the message manual but still don't know.  What is the following
trying to tell me?

   IOS000I 0920,B1,CMD,C2,0200,,**,,JFIMERGE  592   
8040202704202010(B320)(4100C2FF)8E0F95944896
   IOS000I 0920,B1,CMD,C2,0200,,**,M00164,JFIMERGE  593 
8040202704202010(B320)(4100C2FF)8E0F95944896

The job appeared to work otherwise.  Should I be concerned?

These messages tell you that a x'C2' (MEDIUM SENSE) command was rejected 
by the device. MEDIUM SENSE is supported by 3590 tape devices but not by 
older tape devices e.g., 3490. Either the executing program erroneously 
issued the command to a 3490, the 3590 device is somehow improperly 
defined to the system, some (ISV?) software caused a 3490 device to be 
improperly recognized by system code (even if defined correctly), or the 
3590 device is erroneously rejecting the command.

It could be that the executing program handled the command rejection 
gracefully and moved on without problems. Nevertheless, I would not 
ignore these messages. Something is wrong.

-- 
 -
| Edward E. Jaffe||
| Mgr, Research  Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
 -

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

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

Re: SMP/E API GIM52801T? GIM52801E? Whatever.

In a recent note, Kurt Quackenbush said:

 Date: Mon, 1 Aug 2005 09:15:48 -0400
 
 UCLIN is not involved... the doc for message GIM52801E is misleading.
 This results from reusing a message and missing the appropriate doc
 updates.  I'll ensure a future instance of the book is corrected.
 
Thanks.  Again, I'll state that GIM52801T is a better choice
to reuse than GIM52801E, and would involve a less drastic
doc update, with less IF GIMSMP THEN ... ELSE IF GIMAPI ...
logic in the text.  GIM52801E is clearly addressed to UCLIN
errors and is best left that way, while GIM52801T addresses
parameter errors and could more easily be generalized.

  .. no mention of truncating excess characters from the lowest-level
 
 Quite simply I believe it is a bug.  Unless you feel strongly and
 require an APAR, I'll see what I can do to fix it in a future release of
 SMP/E.
 
Thanks.  Would a PMR with a suggestion of FIN APAR increase or
decrease your paperwork?

Thanks again,
gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: How to set z/OS UNIX locale to en_US.UTF-8?

2005-08-01 Thread Bo Xie

There is not reply for this issue. :-(

Would you be so kind to recommend some references/bibliography
focusing on the topic locale and code page in z/OS UNIX? Thank you
very much for your time!

Best Regards,
Xie Bo

On 7/29/05, Bo Xie [EMAIL PROTECTED] wrote:
 Hello,
 
 I want to set z/OS V1R6 UNIX locale to en_US.UTF-8 and the following is log:
 --
 TSO OMVS
 $ locale -a  | grep en_US*
 en_US.ISO8859-1.lp64
 en_US.ISO8859-1.xplink
 en_US.UTF-8.lp64
 en_US.UTF-8.xplink
 $ echo $LC_ALL
 
 $ LC_ALL=C
 $ echo $LC_ALL
 C
 $ LC_ALL=en_US.UTF-8
 FSUMA912 Cannot set locale: The internationalization variable settings
 are invalid.
 $ LC_ALL=en_US.UTF-8.xplink
 CEE3204S The system detected a protection exception (System Completion 
 Code=0C4)
 .
  From entry point spcvar at compile unit offset +07DA at entry 
 offse
 t +07DA at address 0A3389D2.
   FSUM2331 The session has ended.  Press Enter to end OMVS.
 --- Now TSO OMVS again
 $ echo $LC_ALL
 
 $ LC_ALL=en_US.UTF-8.lp64
 CEE3204S The system detected a protection exception (System Completion 
 Code=0C4)
 .
  From entry point spcvar at compile unit offset +07DA at entry 
 offse
 t +07DA at address 0A3389D2.
   FSUM2331 The session has ended.  Press Enter to end OMVS.
 --
 Any suggestions are welcome and appreciated!
 
 Best Regards,
 Xie Bo


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

Re: How can I convert ER diagram into SQL QUERY

2005-08-01 Thread Galambos, Robert

There is a listserv (DB2-L) listserv that is run by IDUG (international DB2
User Group) that may be of help in answering your questions. (whether OS/Z
390 or LUW versions)


You can subscribe at www.idug.org

 


 
Robert Galambos 

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

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Srinivas_Pasumarthi
Sent: July 31, 2005 11:22 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: How can I convert ER diagram into SQL QUERY

Hi Jim,
Thanks a lot for the information.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Fenner, Jim
Sent: Monday, August 01, 2005 4:41 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: How can I convert ER diagram into SQL QUERY

Srinivas,
 (i) You must have database specialists who created these tables and
designed their foreign keys, indexes, partitioning etc in the first place.
See them for advice. If your organisation happens to possess a tool that
would, as you request, convert ER diagram into SQL QUERY, then they
presumably are the experts in using that tool 

(ii) If you are using DB2 on a mainframe, you should in any case (whatever
your job description) possess and absorb a copy of Craig Mullins DB2
Developer's Guide 5th Edition' published by SAMS . If not,
... 



DISCLAIMER:
This email (including any attachments) is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or
distribution or forwarding of any or all of the contents in this message is
STRICTLY PROHIBITED. If you are not the intended recipient, please contact
the sender by email and delete all copies; your cooperation in this regard
is appreciated.

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



The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it. 

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

Re: CKD commands and PDS writing




but could you in
fact re-write an EOF record with Write Data? Is not the data length
zero, and is not a zero-length CCW illegal?

It is illegal in a Format-0 (24-bit) CCW but not in Format-1 (31-bit).  
I am sure there is some reason for that but it escapes me right now.


But there is a workaround even in format-0.  Code a non-zero data length 
in the WRITE DATA, but set the SLI (suppress length indicator) bit.  The 
I/O does end with a Unit Exception, which indicates that a EOF was 
read.BTW, this works only if CKD conversion mode is set in the CCW 
chain, but this is normally true for I/Os issued via EXCP


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

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

Re: STK 9840 in 3590 compat mode




Guy's i have both 9840   3590 tape and i can tell you with absolute certinty 
that you can not put 9840 tape into 3590 drives and read them it is physicaly 
impossiable. but the hardware def for a 9840 is defined as a 3590.

Absolutely true. 

The IBM 3590 carts use the same essential mechanism as their 3480 and 
3490 ancestors.  There is a single reel in the cart, with a leader 
sticking out which the drive grabs and wraps around a takeup reel in the 
drive.


The STK carts use 2 internal reels with no external leader, much like an 
audio cartridge.   There is no internal reel in the drive. 

So the drives are software compatible, but the carts are totally 
incompatible and cannot be mounted in the other vendors drives.


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

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

Re: How to detect a missing link list library?

2005-08-01 Thread Knutson, Sam

Hi Mark,

I like your approach and did a little proof of concept here Friday.


I cobbled together an IEAVMXIT which we used to use but retired some time
ago.

  L CTXTPTR,0(R1)LOAD R10 WITH PARM ADDRESS
  USING CTXT,CTXTPTR ESTABLISH ADDRESSABILITY TO PARM LIST 
  L R2,CTXTRCP   locate route codes
  USING CTXTROUT,R2  @ RCP 
  DS0H 
   
 * 
 * IEA716I LIBRARY NOT LOCATED -   LNKLST   DATA SET IGNORED   
 * SYS3.FOO.LINKLIB
 * 
 * IGGN307I SYS005,SYS3.FOO.VOLSER.LINKLIB,DATA SET NOT FOUND ON VOLUME
 * 
 * 
 * These messages are issued as a rollable message during IPL/NIP  
 * we will change the descriptor code to bring them to the attention   
 * of an operator if one is watching.  
 * 
 * We also set CVTUSER to a non-zero value and automation will 
 * issue further alerts if the system gets up far enough to run
 * OPSMVS. 
 * 
   
  L R3,CTXTTXPJ locate the message attributes  
  USING CTXTATTR,R3 @ XPJ  
  CLC   CTXTTMSG(7),=C'IEA716I'  IEA716I?  
  BEERROR   Flag it!   
  CLC   CTXTTMSG(8),=C'IGGN307I' IGGN307I? 
  BEERROR   Flag it!   
  B EXIT01  Not on our shopping list leave it  
  DROP  R3  ## XPJ message attributes  
 ERRORL R3,CTXTDCP  locate descriptor codes
  USING CTXTDESC,R3 @ DCP  
  OICTXTRFB2,CTXTPBCA   force brodcast to active consoles  
  OICTXTRFB1,CTXTRCDC   allow change to descriptor codes   
  XCCTXTDESC,CTXTDESC   clear existing descriptor codes
  OICTXTDC1,CTXTDC01change descriptor code to 01   
  DROP  R3  ## DCP 
 * 
  OICTXTRFB1,CTXTRCRC   allow a route code change  
  XCCTXTROUT(2),CTXTROUT   clear existing route codes  
  OICTXTR001,CTXTR01Route code 1   
 * 
 *   OPS/MVS will inspect this later   
 *and alert on a non-zero CVTUSER  
  L R1,CVTPTR  
  USING CVT,R1  @ CVT  
  MVC   CVTUSER,=C'EROR'Remember bad things happened   
 *   OPS/MVS will inspect this later   
  DROP  R1  ## CVT 
  DROP  R2  ## RCP  


The results I just dropped on CVTUSER for the moment but will tidy this up
by creating a 
site specific anchor table and obtaining that and anchoring it in CVTUSER
RSN.
This can be tested easily enough in REXX as could the tidied up version and
I will get
The ASO team to make this Job #1 for OPSMVS before it starts bringing up the
normal system facilities.
I also need to save off the actual messages as I expect that will be more
useful than just a GO/NOGO flag.

/* REXX */  
NUMERIC DIGITS 16/* handle big addresses */ 
CVT  = C2d(Storage(10,4))/* point to CVT */ 
CVTUSER  = C2d(Storage(D2x(CVT + 204),4))/* get CVTUSER  */ 
If CVTUSER  '' then say 'Errors detected during IPL'  
 Else say 'No errors'   
exit  

Note: Need to add CONTROL M,UEXIT=N after checking the results so we don't
run the general WTO exit all the time when we don't need it to reduce
overhead.

So far I just tested this with a system that had no consoles it was the only
thing I had available to IPL Friday when I worked this up. IPLing using only
the HMC the messages are more visible but

Re: STK 9840 in 3590 compat mode

 
In a message dated 8/1/2005 9:30:08 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

So the  drives are software compatible, but the carts are totally 
incompatible and  cannot be mounted in the other vendors drives.




Yup, but you can order 3590 guts for a  9840. 

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

Re: Command Reject

 
In a message dated 8/1/2005 9:43:41 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Command  reject on D/T3480 Tape due to C2 command incorrectly
being issued to  a device that does not support that command.
The invalid ccw was  being issued from module IFG019RM which was
being called with an  invalid branch code from IFG0196T .




Does it mention what happens to the output? Buffer dropped,
data lost, short block written?

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

Re: STK 9840 in 3590 compat mode

2005-08-01 Thread BRUCE BODA

Yes, you can re-configure the drive but you will Void any STK Warranty or 
service contract you have on the re-configured equipment.

- Original Message -
From: Ed Finnell [EMAIL PROTECTED]
Date: Monday, August 1, 2005 10:42 am
Subject: Re: STK 9840 in 3590 compat mode

 In a message dated 8/1/2005 9:30:08 A.M. Central Standard Time,  
 [EMAIL PROTECTED] writes:

 So the  drives are software compatible, but the carts are totally 
 incompatible and  cannot be mounted in the other vendors drives.

 Yup, but you can order 3590 guts for a  9840. 

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

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

Re: STK 9840 in 3590 compat mode




Yup, but you can order 3590 guts for a  9840. 

I have never heard that and I can't find any evidence of that on the STK 
web site.  It would sound like a good move for STK to offer a 
3590-compatible drive.


BTW, the STK T9940 tape drive uses a single hub design similar to the 
3590, but again the STK web site says that the tapes are not compatible 
with 3590.


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

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

Re: STK 9840 in 3590 compat mode

 
In a message dated 8/1/2005 10:03:06 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Yes, you  can re-configure the drive but you will Void any STK Warranty or 
service  contract you have on the re-configured  equipment.





Yeah, pretty much etched in laminar once you pick a config. Like
I said to Bruce we actually considered it, but were afraid of
mixed vendor support. For a D/R seemed like a way to satisfy
STK and 3590 exchange requirements.  

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

What is D/T2064

2005-08-01 Thread Howard Rifkind

Hi,
 
Any know what device type 2064 happens to be?


-
Yahoo! Mail
 Stay connected, organized, and protected. Take the tour

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

Re: What is D/T2064

2005-08-01 Thread Hall, Ken (GTI)

Freeway CPU?

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
 Behalf Of Howard Rifkind
 Sent: Monday, August 01, 2005 11:49 AM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: [IBM-MAIN] What is D/T2064

 Hi,

 Any know what device type 2064 happens to be?

 -
 Yahoo! Mail
  Stay connected, organized, and protected. Take the tour

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

If you are not an intended recipient of this e-mail, please notify the sender, 
delete it and do not read, act upon, print, disclose, copy, retain or 
redistribute it. Click here for important additional terms relating to this 
e-mail. http://www.ml.com/email_terms/

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

Re: What is D/T2064

2005-08-01 Thread Chase, John

 -Original Message-
 From: IBM Mainframe Discussion List On Behalf Of Howard Rifkind
 
 Hi,
  
 Any know what device type 2064 happens to be?

z/Box (z9x0, I believe; 2066 would be z/8x0.  Might be the other way
around).

-jc-

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

Re: What is D/T2064

2005-08-01 Thread August Carideo

Our M/F is a 2064 - 104




   
  Howard Rifkind
   
  [EMAIL PROTECTED]To:   IBM-MAIN@BAMA.UA.EDU  

  OM  cc:  
   
  Sent by: IBM Subject:  What is D/T2064
   
  Mainframe 
   
  Discussion List   
   
  [EMAIL PROTECTED]

  .EDU 
   

   

   
  08/01/2005 11:48  
   
  AM
   
  Please respond to 
   
  IBM Mainframe 
   
  Discussion List   
   

   

   




Hi,

Any know what device type 2064 happens to be?


-
Yahoo! Mail
 Stay connected, organized, and protected. Take the tour

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

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

Re: What is D/T2064

z/890
-Original Message-
From: Howard Rifkind [EMAIL PROTECTED]
Date: Mon, 1 Aug 2005 08:48:44 
To:IBM-MAIN@BAMA.UA.EDU
Subject: What is D/T2064

Hi,
 
Any know what device type 2064 happens to be?


-
Yahoo! Mail
 Stay connected, organized, and protected. Take the tour

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

-teD

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

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

Re: What is D/T2064

2005-08-01 Thread August Carideo

but what does that have to do with D/T2064




   
  Howard Rifkind
   
  [EMAIL PROTECTED]To:   IBM-MAIN@BAMA.UA.EDU  

  OM  cc:  
   
  Sent by: IBM Subject:  What is D/T2064
   
  Mainframe 
   
  Discussion List   
   
  [EMAIL PROTECTED]

  .EDU 
   

   

   
  08/01/2005 11:48  
   
  AM
   
  Please respond to 
   
  IBM Mainframe 
   
  Discussion List   
   

   

   




Hi,

Any know what device type 2064 happens to be?


-
Yahoo! Mail
 Stay connected, organized, and protected. Take the tour

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

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

Re: What is D/T2064

2005-08-01 Thread Horne, Jim - James S

D/T2064 means Device Type 2064, which is a zSeries eserver 900,
colloquially know as a z900.  Just for clarification, the others are:
Machine model   Other name
2064z900
2066z800
2084z990
2086z890
2094z9

Hope this helps,

Jim Horne
Lowe's Companies, Inc.

 
 but what does that have to do with D/T2064
 
 Any know what device type 2064 happens to be?

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

Re: STK 9840 in 3590 compat mode




Yes, you can re-configure the drive but you will Void any STK Warranty or 
service contract you have on the re-configured equipment.

I'm confused.  To reconfigure a T9840 to handle 3590 carts would require 
a whole new internal drive mechanism.  Since this can apparently be 
obtained only from STK (assuming that they really offer it), then STK 
should warrant it. 

I guess it is concievable that some third party is offering to modify a 
T9840 to handle 3590 carts, but why would you want to do so?  Why not 
just buy 3590 drives?


IBM used to offer a 3590 drive that would work in STK's tape libraries.  
Are you perhaps thinking of that?


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

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

Re: What is D/T2064


That is the z900 processor.

Here is a handy link for a quick look of cpu types

http://www.tech-news.com/publib/

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

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

Some SMP Receive Help Needed.

2005-08-01 Thread Howard Rifkind

Hi again.
 
Below are the first couple of lines of two files which I believe are sysmods 
(ptf's) which I think should be receive into the global zone but I did an 
receive and they did't come down.  
 
What would be the corect statemts (jcl) to do this and are these files valid?  
 
I don't think these are the same sysmods (ptf's).
 
Thanks.
 

++ASSIGN SOURCEID(HIPER ) TO(UA09169). /*2005179*/

++ASSIGN SOURCEID(HIPER ) TO(UA12828). /*2005179*/

++ASSIGN SOURCEID(PRP ) TO(UQ89572). /*2005179*/

++ASSIGN SOURCEID(PUT0312) TO(UQ82236).

++ASSIGN SOURCEID(PUT0403) TO(UA09169).

++ASSIGN SOURCEID(PUT0403) TO(UQ85501).

++ASSIGN SOURCEID(PUT0407) TO(UQ89572).

++ASSIGN SOURCEID(PUT0408) TO(UA12828).

++ASSIGN SOURCEID(PUT0503) TO(UK00286).

++ASSIGN SOURCEID(RSU0403) TO(UQ82236).

++ASSIGN SOURCEID(RSU0404) TO(UA09169).

++ASSIGN SOURCEID(RSU0406) TO(UQ85501).

++ASSIGN SOURCEID(RSU0408) TO(UQ89572).

++ASSIGN SOURCEID(RSU0409) TO(UA12828).

++ASSIGN SOURCEID(SMCCOR) TO(UQ82236).

++ASSIGN SOURCEID(SMCCOR) TO(UA09169).

++ASSIGN SOURCEID(SMCCOR) TO(UQ89572).

++ASSIGN SOURCEID(SMCCOR) TO(UQ85501).

++ASSIGN SOURCEID(SMCCOR) TO(UK00286).

++ASSIGN SOURCEID(SMCCOR) TO(UA12828).

++ PTF (UQ82236) /*

//UQ82236 JOB 5655-82236,HAL00,MSGLEVEL=(1,1),CLASS=A */ .

***

++ASSIGN SOURCEID(PRP ) TO(UA06764). /*2005180*/

++ASSIGN SOURCEID(PUT0311) TO(UA06764).

++ASSIGN SOURCEID(RSU0312) TO(UA06764).

++ASSIGN SOURCEID(SMCCOR) TO(UA06764).

++ PTF (UA06764) /*

//UA06764 JOB 5695-06764,SCPX2,MSGLEVEL=(1,1),CLASS=A */ .

 



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

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

Re: Some SMP Receive Help Needed.

2005-08-01 Thread Pommier, Rex R.

What messages did you get when you tried to run the receive?  Normally
there is a report that SMP/E generates that shows all the sysmods it
looked at and a short explanation as to why certain PTFs didn't get
received.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Howard Rifkind
Sent: Monday, August 01, 2005 11:50 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Some SMP Receive Help Needed.


Hi again.
 
Below are the first couple of lines of two files which I believe are
sysmods (ptf's) which I think should be receive into the global zone but
I did an receive and they did't come down.  
 
What would be the corect statemts (jcl) to do this and are these files
valid?  
 
I don't think these are the same sysmods (ptf's).
 
Thanks.
 

++ASSIGN SOURCEID(HIPER ) TO(UA09169). /*2005179*/

++ASSIGN SOURCEID(HIPER ) TO(UA12828). /*2005179*/

++ASSIGN SOURCEID(PRP ) TO(UQ89572). /*2005179*/

++ASSIGN SOURCEID(PUT0312) TO(UQ82236).

++ASSIGN SOURCEID(PUT0403) TO(UA09169).

++ASSIGN SOURCEID(PUT0403) TO(UQ85501).

++ASSIGN SOURCEID(PUT0407) TO(UQ89572).

++ASSIGN SOURCEID(PUT0408) TO(UA12828).

++ASSIGN SOURCEID(PUT0503) TO(UK00286).

++ASSIGN SOURCEID(RSU0403) TO(UQ82236).

++ASSIGN SOURCEID(RSU0404) TO(UA09169).

++ASSIGN SOURCEID(RSU0406) TO(UQ85501).

++ASSIGN SOURCEID(RSU0408) TO(UQ89572).

++ASSIGN SOURCEID(RSU0409) TO(UA12828).

++ASSIGN SOURCEID(SMCCOR) TO(UQ82236).

++ASSIGN SOURCEID(SMCCOR) TO(UA09169).

++ASSIGN SOURCEID(SMCCOR) TO(UQ89572).

++ASSIGN SOURCEID(SMCCOR) TO(UQ85501).

++ASSIGN SOURCEID(SMCCOR) TO(UK00286).

++ASSIGN SOURCEID(SMCCOR) TO(UA12828).

++ PTF (UQ82236) /*

//UQ82236 JOB 5655-82236,HAL00,MSGLEVEL=(1,1),CLASS=A */ .

***

++ASSIGN SOURCEID(PRP ) TO(UA06764). /*2005180*/

++ASSIGN SOURCEID(PUT0311) TO(UA06764).

++ASSIGN SOURCEID(RSU0312) TO(UA06764).

++ASSIGN SOURCEID(SMCCOR) TO(UA06764).

++ PTF (UA06764) /*

//UA06764 JOB 5695-06764,SCPX2,MSGLEVEL=(1,1),CLASS=A */ .

 



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

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

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

Re: Some SMP Receive Help Needed.

In a message dated 8/1/2005 11:50:29 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:

What would be the corect statemts (jcl) to do this and are these files
valid?

SET BDY(GLOBAL).
RECEIVE.

You need a dd for SMPHOLD and SMPPTFIN.

From 3.2 SMP/E Users Guide:

1.4.3.1 Examples

Let's look at a few of these examples.
Receiving SYSMODs and HOLDDATA: In the course of maintaining your system,
you need to install service and process the related HOLDDATA. Assume IBM has
supplied you with a service tape (such as a CBPDO tape or an ESO tape), and
you
want to install it on your system. The first step is to receive the SYSMODs
and HOLDDATA that are contained on the tape. You can accomplish this by
specifying the following commands:

SET BDY(GLOBAL).

RECEIVE.

When you issue these commands, SMP/E receives all the SYSMODs and HOLDDATA
on the service tape into the global zone.
Receiving Only HOLDDATA: There may be times when you do not want to receive
the SYSMODs from a service tape, but you do want to receive the HOLDDATA.
Because the HOLDDATA provides information about SYSMODs requiring special
handling or that are in error, it is important for you to receive the HOLDDATA
into
SMP/E's storage repository as soon as possible. The following commands
process only the HOLDDATA:

SET BDY(GLOBAL).

RECEIVE HOLDDATA.

By issuing these commands, you direct SMP/E to receive only the HOLDDATA
from the service tape into the global zone.
Receiving Only SYSMODs: Assume you have previously received only the
HOLDDATA from a service tape and are now ready to install the SYSMODs. To
install
these SYSMODs (using the APPLY and ACCEPT commands), you must first receive
them. This can be done by specifying the following commands:

SET BDY(GLOBAL).

RECEIVE SYSMODS.

When you issue these commands, you direct SMP/E to receive only the SYSMODs
from the service tape into the global zone.
Receiving SYSMODs and HOLDDATA for a Specific Product: You may want to
receive SYSMODs and HOLDDATA for a particular product from the service tape.
You
can accomplish this task by specifying the following commands:

SET BDY(GLOBAL).

RECEIVE FORFMID(HOP0001).

By issuing these commands, you direct SMP/E to receive SYSMODs and HOLDDATA
for the product whose FMID is HOP0001 from the service tape into the global
zone.
For a more complete description of all the RECEIVE command operands and other
examples, see _The RECEIVE Command_
(http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/DOCNUM/SA22-7771/HDRCHPREC?SHELF=GIM2BK21ScrollTOP=HDRCHPREC#HD
RCHPREC) in _SMP/E Commands_
(http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/DOCNUM/SA22-7771/CCONTENTS?SHELF=GIM2BK21;)
.

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

Re: STK 9840 in 3590 compat mode

2005-08-01 Thread BRUCE BODA

OSU is in fact moving in that direction, we will be installing 3590-h drives 
into our STK 9311 using c12 drive frames, we are also installing jaquar drives 
using c20 drive frames.

Bruce

- Original Message -
From: Bruce Black [EMAIL PROTECTED]
Date: Monday, August 1, 2005 12:01 pm
Subject: Re: STK 9840 in 3590 compat mode

 Yes, you can re-configure the drive but you will Void any STK 
 Warranty or service contract you have on the re-configured equipment.

 I'm confused.  To reconfigure a T9840 to handle 3590 carts would 
 require 
 a whole new internal drive mechanism.  Since this can apparently 
 be 
 obtained only from STK (assuming that they really offer it), then 
 STK 
 should warrant it. 

 I guess it is concievable that some third party is offering to 
 modify a 
 T9840 to handle 3590 carts, but why would you want to do so?  Why 
 not 
 just buy 3590 drives?

 IBM used to offer a 3590 drive that would work in STK's tape 
 libraries.  
 Are you perhaps thinking of that?

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

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

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

Making smaller ptf packages

2005-08-01 Thread Thomas Lawrence

Due to our coming late to the table of zOS, we have an enormous load of
ptf's to bring us up to the present day, which I requested from ShopZ. When
they were received it was 4 compressed tapes! Is there a way to have IBM
break this up so we could apply them much easier?

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

Re: Making smaller ptf packages

2005-08-01 Thread Alan Schwartz

I suggest using APPLY FORFMID(whatever you want) and specify Compress(ALL) 
to reduce chances of dataset space abends between applies.  Also a backup 
of the target volume and zones between runs is handy.  Just be sure to 
keep good logs; you don't want to mix them up if you have to do a restore.

Alan Schwartz
Assurant Shared Business Services
Lead Systems Programmer
Phone:  651-361-4758
Fax:   651-361-5625



Thomas Lawrence [EMAIL PROTECTED] 
Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
08/01/2005 12:41 PM
Please respond to
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Making smaller ptf packages






Due to our coming late to the table of zOS, we have an enormous load of
ptf's to bring us up to the present day, which I requested from ShopZ. 
When
they were received it was 4 compressed tapes! Is there a way to have IBM
break this up so we could apply them much easier?




**
This e-mail message and all attachments transmitted with it may contain legally 
privileged and/or confidential information intended solely for the use of the 
addressee(s). If the reader of this message is not the intended recipient, you 
are hereby notified that any reading, dissemination, distribution, copying, 
forwarding or other use of this message or its attachments is strictly 
prohibited. If you have received this message in error, please notify the 
sender immediately and delete this message and all copies and backups thereof.

Thank you.
**

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

Re: Making smaller ptf packages

 
In a message dated 8/1/2005 12:55:03 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

I  suggest using APPLY FORFMID(whatever you want) and specify Compress(ALL)  
to reduce chances of dataset space abends between applies.  Also a  backup 
of the target volume and zones between runs is handy.  Just be  sure to 
keep good logs; you don't want to mix them up if you have to do a  restore.




I like the Service/PAC methodology of Waves(s). If you kept
your install libraries can probably APPLY the service in
the same order(WAVES) that your system was built. It does
it by groups of FMIDs.

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

OSA Card Display Command

I have been trying to find out how many OSA cards are installed on our
two production processors.
I have asked our service providers, to no avail.
I have tried to look at the IODF.
I have tried looking at the OPS Display command doc.

What is the easiest way to find out how many OSA cards are installed?
The type?
Are they defined under VIPA?
I have “look but don't touch access” to 'everything'.
What I don't have is a handle on the appropriate doc, so I can find this stuff!

Also, is a CMC supported (or even needed) in a TÇP/IP environment?
Again, a pointer to doc would be appreciated!

I gave been given the resonsibility to co-ordinate an SNA to TCP/IP migration 
(mainframe) migration.
This will save us a ton of $$ (US), with next to no effort (except for the 
above questions).

Any help/pointers/etc would be greatly appreciated.

Thanks.


-teD

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

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

Re: Another - Another One Bites the Dust

2005-08-01 Thread Clark Morris

On 8 Jul 2005 05:20:23 -0700, in bit.listserv.ibm-main you wrote:

For those that keep score or have an interest...

http://biz.yahoo.com/prnews/050707/sfth081.html?.v=17


Given the way many places actually use their mainframes, a move to
operating system du jour may not decrease reliability.  If the online
transactions crash periodically, does it matter to users of those
applications that the system stays up.  A move to a well written
package on even Windows may result in increased reliability so far as
the end user is concerned.  If the mainframe applications people in a
shop are still in the VS COBOL way of doing things and their companies
aren't providing an adequate test environment, that shop probably will
be helped by a move to platform i, p, x, Linux or other vendor if that
causes a revision in the way of doing business.  
Happy Weekend.


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

Re: OSA Card Display Command

2005-08-01 Thread BRUCE BODA

if you go to the HMC on the z800-z900 processor, logon as sysprog the operator 
account will not work, scroll till you see the OSA Adapt ICON.

Select the image you wish to display and double click on the OSA ICON.

That will display the OSA Adapters installed in your system, but please be 
careful to select only display options or you could inadvertinly chsnge your 
OSA setings and that would be very bad.

Bruce Boda OSU

- Original Message -
From: Ted MacNEIL [EMAIL PROTECTED]
Date: Sunday, July 31, 2005 8:00 pm
Subject: OSA Card Display Command

 I have been trying to find out how many OSA cards are installed on our
 two production processors.
 I have asked our service providers, to no avail.
 I have tried to look at the IODF.
 I have tried looking at the OPS Display command doc.
 
 What is the easiest way to find out how many OSA cards are installed?
 The type?
 Are they defined under VIPA?
 I have “look but don't touch access” to 'everything'.
 What I don't have is a handle on the appropriate doc, so I can 
 find this stuff!
 
 Also, is a CMC supported (or even needed) in a TÇP/IP environment?
 Again, a pointer to doc would be appreciated!
 
 I gave been given the resonsibility to co-ordinate an SNA to 
 TCP/IP migration (mainframe) migration.
 This will save us a ton of $$ (US), with next to no effort (except 
 for the above questions).
 
 Any help/pointers/etc would be greatly appreciated.
 
 Thanks.
 
 
 -teD
 
 In God we Trust!
 All others bring data!
 -- W. Edwards Deming
 
 ---
 ---
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html
 

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

Re: OSA Card Display Command

2005-08-01 Thread Jon Brock

If you have access to the HMC, you can tell from there.  I'm not sure if that's 
included in your look but don't touch access, although I doubt it.

Other than that, I think that any channel defined in the IODF as OSC, OSD, or 
OSE would be an OSA card.

Jon



snip
What is the easiest way to find out how many OSA cards are installed?
The type?
Are they defined under VIPA?
I have ?look but don't touch access? to 'everything'.
/snip

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

Re: OSA Card Display Command

...
Other than that, I think that any channel defined in the IODF as OSC, OSD, or 
OSE would be an OSA card.
...
I tried reading the IODF.
I must be reading it wrong.
It says that there are 16, at least that's my iterpretation.

I'm in Toronto.
The HMC is in Texas.
Not an option!

Isn't there a simple display command?

-teD

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

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

4039 error with SOC-7

2005-08-01 Thread Howard Brazee

Why would I get a 4039 Error with a data exception?

 USER COMPLETION CODE=4039 REASON CODE=   
TIME=10.20.19  SEQ=00394  CPU=  ASID=0077 
PSW AT TIME OF ERROR  078D1000   880550D6  ILC 2  INTC 0D 
  ACTIVE LOAD MODULE   ADDRESS=07F411E0  OFFSET=00113EF6  
  NAME=CEEPLPKA   
  DATA AT PSW  080550D0 - 00181610  0A0D58D0  D00498EC
  AR/GR 0: 80D1EC28/8400   1: /84000FC7   
2: /0817FFC8   3: /00060007   
4: /0817FFC8   5: /0718   
6: /07F3C888   7: /0010   
8: /87FD3B48   9: /08180717   
A: /0817FB5C   B: /08055000   
C: /07F3FD80   D: /081822B0   
E: /87FD3C88   F: /   
END OF SYMPTOM DUMP   


This job has been running fine, but it abended twice - on close but not
the same input records with SOC-7 and 4039.  Looking at the dump, I see
the SOC-7 easily, but I'm trying to figure out why the old program is
trying to process the header record as a data record.   (one abort was
with the 2nd header record, the other was with the 1st header record). 

Normally SOC-7 is a trivial problem, especially since I see the error
and know it isn't something like a table overflow into program memory.
But I'm puzzled by the 4039.Maybe I should have them run it with
SSRANGE checking, or do a tape to tape copy of the input file first.

At any rate, I'm poring through the code trying to find out why it is
processing the header record.

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

Re: 4039 error with SOC-7

 
In a message dated 8/1/2005 2:07:10 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Why  would I get a 4039 Error with a data exception?




Maybe the EOT reflector fell off? 

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

Re: 4039 error with SOC-7

2005-08-01 Thread Staller, Allan

U4039 is LE (or C??) for an abnormal condition not handled. 

snip
Why  would I get a 4039 Error with a data exception?
/snip

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

Re: OSA Card Display Command

2005-08-01 Thread Jerry Whitteridge

Issue a D M command without parms. One of the displays is a map of
chipds and types with descriptions. Each OSA chpid will be listed.

On Mon, 2005-08-01 at 00:00 +, Ted MacNEIL wrote:
 ...
 Other than that, I think that any channel defined in the IODF as OSC, OSD, or 
 OSE would be an OSA card.
 ...
 I tried reading the IODF.
 I must be reading it wrong.
 It says that there are 16, at least that's my iterpretation.
 
 I'm in Toronto.
 The HMC is in Texas.
 Not an option!
 
 Isn't there a simple display command?
 
 -teD
 
 In God we Trust!
 All others bring data!
  -- W. Edwards Deming
 
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
 Search the archives at http://bama.ua.edu/archives/ibm-main.html
 
-- 
Jerry Whitteridge
Safeway Inc.
PH: 925 951 4184
Fax:925 951 4204


MMS safeway.com made the following annotations.
--
Warning: 
All e-mail sent to this address will be received by the Safeway corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain information proprietary to Safeway and is 
intended only for the use of the intended recipient(s).  If the reader of this 
message is not the intended recipient(s), you are notified that you have 
received this message in error and that any review, dissemination, distribution 
or copying of this message is strictly prohibited.  If you have received this 
message in error, please notify the sender immediately. 
  
==

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

Re: OSA Card Display Command

2005-08-01 Thread Ilya Gersh

D M=CHP   will give you the list of all your defined chpids.

ilya Gersh
[EMAIL PROTECTED]
617-614-2140 
617-974-1345 c
617-630-7185 f


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted 
MacNEIL
Sent: Sunday, July 31, 2005 8:00 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: OSA Card Display Command

I have been trying to find out how many OSA cards are installed on our
two production processors.
I have asked our service providers, to no avail.
I have tried to look at the IODF.
I have tried looking at the OPS Display command doc.

What is the easiest way to find out how many OSA cards are installed?
The type?
Are they defined under VIPA?
I have look but don't touch access to 'everything'.
What I don't have is a handle on the appropriate doc, so I can find this stuff!

Also, is a CMC supported (or even needed) in a TÇP/IP environment?
Again, a pointer to doc would be appreciated!

I gave been given the resonsibility to co-ordinate an SNA to TCP/IP migration 
(mainframe) migration.
This will save us a ton of $$ (US), with next to no effort (except for the 
above questions).

Any help/pointers/etc would be greatly appreciated.

Thanks.


-teD

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

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


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

Re: OSA Card Display Command

2005-08-01 Thread Glenn Miller

Ted,

If you have access to IBM's ResourceLink ( URL:
http://app-06.www.ibm.com/servers/resourcelink )
and you have been granted access to the Machine Information area for
your/their account, you can
obtain information about the status of each processor, when it performs its
weekly ( in my case ) phone
home status update.  The following is the output from the 'System Status'
display from one of my z990
processors ( note: The Channel numbers are the number of each Channel type
installed, not just the
number defined ):


Date of call:  2005/07/29 12:18:38
System Name:  CPC1
Power Status:  Fully Redundant
Second SE:  Operating

Installed Storage:  24576 MB
Running CPs:  6
Running SAPs:  2
Running ICFs:  1
Physical PUs:  12
CPs in LICCC:  6
SAPs in LICCC:  2
ICFs in LICCC:  0
Linux only CPs: 1
zAAPs: 0

Capacity Backup: Not installed

Partitions: 8

Total Channels:  194
ESCON Channels: 120
Coupling Facilities: 12
Parallel Channels: 0
Open System Adapters:  8
Fiber Channels:  52
Other Channels: 2




HTH

Glenn Miller

---
This message (including any attachments) is confidential and may be
privileged. If you have received it by mistake please notify the sender by
return e-mail and delete this message from your system. Any unauthorised
use or dissemination of this message in whole or in part is strictly
prohibited. Please note that e-mails are susceptible to change.
ABN AMRO Bank N.V. (including its group companies) shall not be liable for
the improper or incomplete transmission of the information contained in
this communication nor for any delay in its receipt or damage to your
system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that
the integrity of this communication has been maintained nor that this
communication is free of viruses, interceptions or interference.
---

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

Reference for DCB coexistence with RMODE 31 programs?

Okay, I admit it, this is kind of an embarrassingly newbie-ish post for
someone who has been writing assembler for 36 years. My only excuse is
that having sold my old company lock, stock, and barrel, and now working
solo, I have no old reference code to fall back on.
 
I've got some assembler subroutines (non-reentrant) in which I rather
lazily embedded QSAM and BPAM macros. That of course limits the code to
RMODE=24. I would like to move the necessary control blocks to AMODE=24
STORAGE and let the code be RMODE ANY31. (The code currently runs AMODE
ANY with no problems.)
 
Question: is there any reference that provides a succinct statement of
the steps necessary? (If not, why not, but that's a different topic.)
Yes, I know each macro is separately documented in the two DFSMS
manuals, but I mean, is there any overview of the conversion steps
necessary.
 
If there isn't a manual, I would welcome this esteemed group's input. I
need to move the DCB to AMODE=24 STORAGE. I need to point each DCB to
its own DCBE, which can be above the line, and I need to move the
appropriate EODAD= and so forth operands to the DCBE. What else? I don't
need a tutorial on 24-bit adcons or anything, I'm very familiar with the
theoretical concepts and the usage of the macros in general, just what
else specifically do I need to do to get from RMODE 24 code to RMODE
ANY31? I'm familiar with DSECTs and copying model control blocks from
CSECTs to STORAGE areas. What are the gotchas? The code in question has
both DCB abend and SYNAD exits.
 
Thanks!

Charles Mills



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

Re: OSA Card Display Command

2005-08-01 Thread Alan C. Field

The suggestions to display the channel types are one way, but all our OSA 
cards have
two channels per physical card.

So we show 8 OSA type channels on each processor, and this equates to four 
physical
slots in the frame. 

Depending on what Ted is trying to figure out this may be relevant 
information. 

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

NOMAIL

2005-08-01 Thread Tito Kiffer

NOMAIL

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

Re: Another - Another One Bites the Dust

snips
 And another 100 to replace them for newer ones as new 
 technology comes out.
 Wow, they must be in the money, customers money that is.
more snips
 And have another 50 in reserve to replace they ones going 
 down every 5 minutes. g

Just ain't so folks... take a long hard look at the real numbers
and the results are not pretty. Fact 1. z/OS availability, as
experienced by most of our brethren, is nothing to write home about.
See all of the past threads about IPL frequency for verification. 

Its not that the system isn't capable of continuous operation (IT 
IS!!!) but evidently a wide majority of customers don't actually
trust it to be as reliable as it is.

Fact 2, there are many ways of skinning the high availability
cat and clustered systems made up of nothing more than networked
PCs and PC-like boxes are getting some seriously good numbers in
the real world. Yes Gertrude, you really can get better availability
from Windows than most z/OS customers get in the real world. Once
again, its not an intrinsic better/worse story. Its how you choose
to configure and run them.

I'd make some caustic remark about roses and coffee but I am 
sure you all get my drift. The world around us really has changed.

CC

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

Re: Reference for DCB coexistence with RMODE 31 programs?

Ray Mullins' good advice snipped
 
 One thing I'll mention, because I just saw it - BDAM and BDAM 
 load using BSAM don't work in RMODE 31.

Yeah, there are a couple of areas where functionality slipped
through the cracks. Its also true that you can't write to a
termfile in 31 bit mode even with mindless QSAM. I also suspect
problems in other places where I've run across things that make
you go eh? but I have never had time to delve into them.

Bottom line. Most I/O works fine in 31-bit mode if you get all
the right smoke and mirror vectors aligned. Some won't no matter
how clever you are at geometry. Betcha Bruce knows a lot of the
specific quirks.

CC

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

Re: Another - Another One Bites the Dust

Ok, replying to my own post, but this is just weird...

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
 Behalf Of Craddock, Chris
 Sent: Monday, July 11, 2005 11:17 AM
^^

this post just arrived, a mere 3 weeks late? WTF?

CC

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

Re: Another - Another One Bites the Dust

2005-08-01 Thread Jon Brock

 . . . and it shall continue to do so; what's more, it is getting more complex 
all the time.  At most shops that have mainframes, it is only one component -- 
and an increasingly minor one -- in the overall enterprise IT picture.  I trust 
my zSeries to do things that the smaller boxes can't do, but the small boxes 
can also do things the z/box can't.  That's not necessarily a bad thing, but it 
gets harder every day to keep track of everything that our shop does and how it 
all communicates.  Apparently, I'm a bear of little brain.

Jon


snip
The world around us really has changed.
/snip

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

Re: Another - Another One Bites the Dust

2005-08-01 Thread Desi de la Garza

IPL FREQUENCY. Not here!

Thanks,
 
Desi de la Garza
Systems Programmer
Bexar County Information Services
[EMAIL PROTECTED]
 

-Original Message-
From: Craddock, Chris [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 11, 2005 11:17 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Another - Another One Bites the Dust

snips
 And another 100 to replace them for newer ones as new 
 technology comes out.
 Wow, they must be in the money, customers money that is.
more snips
 And have another 50 in reserve to replace they ones going 
 down every 5 minutes. g

Just ain't so folks... take a long hard look at the real numbers
and the results are not pretty. Fact 1. z/OS availability, as
experienced by most of our brethren, is nothing to write home about.
See all of the past threads about IPL frequency for verification. 

Its not that the system isn't capable of continuous operation (IT 
IS!!!) but evidently a wide majority of customers don't actually
trust it to be as reliable as it is.

Fact 2, there are many ways of skinning the high availability
cat and clustered systems made up of nothing more than networked
PCs and PC-like boxes are getting some seriously good numbers in
the real world. Yes Gertrude, you really can get better availability
from Windows than most z/OS customers get in the real world. Once
again, its not an intrinsic better/worse story. Its how you choose
to configure and run them.

I'd make some caustic remark about roses and coffee but I am 
sure you all get my drift. The world around us really has changed.

CC

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

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

Re: STAE/ESTAE

Glad you enjoyed them mate.

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
 Behalf Of Rob Scott
 Sent: Tuesday, July 19, 2005 5:31 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: STAE/ESTAE
 
 
 Chris,
 
 Carbon-based recovery analysis routine
 
 And
 
 ..that offer a point and shoot shortcut to your next unplanned IPL
 
 Two good chortles in two days !

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

Re: Another - Another One Bites the Dust

2005-08-01 Thread Ed Gould


On Aug 1, 2005, at 3:41 PM, Craddock, Chris wrote:


Ok, replying to my own post, but this is just weird...


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Craddock, Chris
Sent: Monday, July 11, 2005 11:17 AM

^^

this post just arrived, a mere 3 weeks late? WTF?

CC



Clearly from one of you utterly reliable PC based systems, Chris:-)

Ed

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

IPL MESSAGES.

2005-08-01 Thread Rugel José

When  I  IPL  our S/390 (os 390 2.10),  the  initial message appears  at  
Alternate console  instead of  Primary (  as  I need ),
This  is the CONSOLE04  parmlib member.
 
 * Top of Data **
 INIT MPF(00) RLIM(20)   
 CONSOLE  DEVNUM(080) AUTH(MASTER) ROUTCODE(ALL) ALTERNATE(520)  
 UNIT(3279-2C) NAME(CONSOL01) AREA(NONE) RTME(2) 
 CONSOLE  DEVNUM(520) AUTH(SYS IO CONS) ALTERNATE(080) AREA(4)   
  ROUTCODE(ALL) DEL(R)   
 UNIT(3279-2C) NAME(CONSOL02)
 
Jose Rugel 


*
La informacion contenida en este e-mail es confidencial y solo puede ser 
utilizada 
por la persona o la Institucion a la cual esta dirigido. 
Cualquier retencion, difusion, distribucion o copia de este mensaje esta 
prohibida. 
La Institucion no asume responsabilidad sobre informacion, opiniones o 
criterios 
contenidos en este mail que no este relacionada con negocios oficiales de 
nuestra 
 Institucion.
Si Usted recibio este mensaje por error notifique al Administrador o a quien le 
envio 
inmediatamente, eliminelo sin ver su contenido o hacer copias. 
** Banco del Pacifico S.A.** 
**
(Las tildes han sido omitidas intencionalmente para evitar problemas de lectura)
**

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

Re: IPL MESSAGES.

2005-08-01 Thread Brian Peterson

This is selected in your IODF.  In HCD, display your NIP console list.
Here's what mine looks like:

¢¢ NIP Console List ¢
  Goto  Backup  Query  Help
-

Command === 

Select one or more consoles, then press Enter

Configuration ID . : PRODPLEX Merged Conf

  Order   Device
/ Number  Number  Device Type
_   1 01013270-X
_   2 01023270-X
_   3 01033270-X
_   4 01213270-X
_   5 01223270-X
_   6 01233270-X
*** Bottom of data **

Brian

On Mon, 1 Aug 2005 16:36:38 -0500, =?iso-8859-1?Q?Rugel_Jos=E9?=
[EMAIL PROTECTED] wrote:

When  I  IPL  our S/390 (os 390 2.10),  the  initial message appears  at
Alternate console  instead of  Primary (  as  I need ),
This  is the CONSOLE04  parmlib member.

 * Top of Data **
 INIT MPF(00) RLIM(20)
 CONSOLE  DEVNUM(080) AUTH(MASTER) ROUTCODE(ALL) ALTERNATE(520)
 UNIT(3279-2C) NAME(CONSOL01) AREA(NONE) RTME(2)
 CONSOLE  DEVNUM(520) AUTH(SYS IO CONS) ALTERNATE(080) AREA(4)
  ROUTCODE(ALL) DEL(R)
 UNIT(3279-2C) NAME(CONSOL02)

Jose Rugel



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

SMP/E Causer Report Information Question.

2005-08-01 Thread Howard Rifkind

Does the INCMPLT in the line below mean incomplete and if so does it really 
mean that sysmods like UQ67009 are missing?

Thanks

UQ75326 INCMPLT PTF HIP6140 PRE UQ67009 UQ67699 UQ68815 UQ

HOLDS *ACTION(UQ75326) *DOC(UQ75326)



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

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

Re: SMP/E Causer Report Information Question.

2005-08-01 Thread Imbriale, Donald (Exchange)

A good description of INCMPLT and the format of the report and meaning
of all the fields can be found in the SMP/E Commands manual.  I did a
search on the SMP/E bookshelf in BookManager with keyword INCMPLT.

Don Imbriale


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
Of Howard Rifkind
Sent: Monday, August 01, 2005 5:46 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: SMP/E Causer Report Information Question.

Does the INCMPLT in the line below mean incomplete and if so does it
really mean
that sysmods like UQ67009 are missing?

Thanks

UQ75326 INCMPLT PTF HIP6140 PRE UQ67009 UQ67699 UQ68815 UQ

HOLDS *ACTION(UQ75326) *DOC(UQ75326)





***
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***

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

Re: CKD commands and PDS writing

In [EMAIL PROTECTED], on 07/29/2005
   at 01:09 PM, Bill Fairchild [EMAIL PROTECTED] said:

Not true if the EOF record is already there.  You can rewrite the EOF 
record  into the same space on the track without using a formatting
write,  although  this does not usually accomplish anything useful. 

As I recall, DOS/360 supported an EOF with a non-zero key length. If
you had to deal with such an animal, a Write Key and Data CCW might be
useful for updating it. It's not something that I've ever done, ever
seen done or ever wanted to see done.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: CKD commands and PDS writing

In [EMAIL PROTECTED], on 07/29/2005
   at 03:01 PM, Charles Mills [EMAIL PROTECTED] said:

We agree that re-writing an EOF record would be an exercise in
futility and I'm sure no one is interested in hearing us debate, but
could you in fact re-write an EOF record with Write Data? Is not the
data length zero, and is not a zero-length CCW illegal?

The CCW would not be zero length if the key length was nonzero.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: How to detect a missing link list library?

In
[EMAIL PROTECTED],
on 07/29/2005
   at 07:23 AM, Peter Relson [EMAIL PROTECTED] said:

There was no change in this processing aside from, actually,
detecting some of the additional cases and issuing even more messages
(some of these messages might alert you that LLA will not function
properly, for example).

Do you leave enough information in storage for a program to identify
the missing libraries?  If not, how difficult would it be to retain
the data? How difficult would it be to provide a diagnostic utility or
command to display information on missing linklist libraries? This
looks like a good candidate for a requirement.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: ILR005E PLPA PAGE DATA SET FULL

In [EMAIL PROTECTED], on 07/28/2005
   at 09:59 AM, Bill Fairchild [EMAIL PROTECTED] said:

When PAV is involved, other considerations complicate matters.  Any 
number  of I/Os can theoretically be happening simultaneously within
the same  data set  from any number of exposures as long as all those
I/Os are read  only.  But  if only one of them wants to do a write,
then serialization is  necessary  within the control unit.

How did IBM handle that on the 2305 and the paging 3880 boxen?
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Other DASD Erase programs

In [EMAIL PROTECTED], on 07/28/2005
   at 12:12 PM, Walt Farrell [EMAIL PROTECTED] said:

Writing an EOF is different.  That replaces just one block on the
track,  leaving the rest of the data (in the subsequent blocks)
intact. 

No, it erases the remainder of the track, at least as far as normal
CCW's are concerned.

ZAP and other programs can read the rest of the data in that case, 

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

Re: Routine name/srb

In [EMAIL PROTECTED], on
07/28/2005
   at 05:14 AM, mary george [EMAIL PROTECTED] said:

I find the BPX1MP and BPX1MPI  services been called in my module. My
system does not seem to have any interaction with UNIX,its running on
ZOS.

Unix System Services is part of z/OS, and other components, e.g.,
TCP/IP, use it.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SMP sloppiness

In [EMAIL PROTECTED], on 07/28/2005
   at 12:51 AM, SArnett [EMAIL PROTECTED] said:

I disagree for three two reasons.  The first is that the IBM
maintenance  documentation stated that it could be done to the live
system, the  second is that the IBM maintenance documentation I was
provided with was  WRONG in how to apply the maintenance, and the
third reason is that  doing the oposite worked. 

If you will note, I said I had installed XA express.

And you trusted its documentation. MVS Express was a dog's breakfast,
and there was no reason to expect XA Express to be any better.

I assure your that there was nothing in the XA express or CBIPO 
documentation explaining the proper maintenance philosophy of an
MVS  system.

CBIPO documentation distinguished between the driver system and the
target system. BTDTGTTS.

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

Re: Third party Maintenance of z/OS R4 after March 2007

In [EMAIL PROTECTED], on 07/28/2005
   at 10:10 AM, R.S. [EMAIL PROTECTED] said:

It is possible to take money for that. Without access to source code
it  is quite impossible to fix something.

Nonsense; it's not only possible, but lots of people have done it.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: What happened to iSource?

In [EMAIL PROTECTED],
on 07/28/2005
   at 02:14 PM, Hylton Tom P [EMAIL PROTECTED] said:

Recently, the following instructions have prefaced all of the
announcements,

An increasing number of e-mail clients are using spam blockers that
can affect delivery and display of some e-mail messages.  To ensure
delivery and proper display of your IBM Announcement e-mail
newsletter, please add our e-mail address, [EMAIL PROTECTED], to
your address book and safe sender list..

That's not a request that your postmaster is likely to go along with.
It would help if IBM would identify the IP addresses that they will
use for the mailings.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: OSA Card Display Command

...

Depending on what Ted is trying to figure out this may be relevant 
information.
...

I thought I was clear. (8-{[}

1. How do I find out how many cards?
I know we are in a VIPA config, but do we have one, two or more pairs.

2. (This hasn't been answered, yet)
Does a CMC configuration work with TCP/IP?

I'm getting maybes, 'uh-huh', 'I don't know', and conflicting answers from our 
provider's people.
So, I have one more question:

3. Where do I look it up?

I'm not that strong on Network Implementations, so I'm trying to find my own 
answers.


-teD

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

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

Re: Another - Another One Bites the Dust

...
I trust my zSeries to do things that the smaller boxes can't do.
...

I sort of won an argument with our provider.
They just added one more engine to our production z/box.
Originally, they wanted to POR/IPL to do it.
I was the only one against it.
Finally, when they realised there wasn't a time-frame when all LPARs could be 
taken down, they were 'forced' to do it my way.
They weren't comfortable, but it worked (surprise! surprise! surprise).

z/Stuff isn't going to work in shops that don't believe in the dynamic 
capabilities of the technology.


-teD

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

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

Re: MIGRATION 31 to 64bit IEFUSI and MEMLIMIT

...

Window Services.

...

So, I wasn't having delerium as well as old-timers'?

-teD

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

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

Re: Reference for DCB coexistence with RMODE 31 programs?

 One thing I'll mention, because I just saw it - BDAM and BDAM
 load using BSAM don't work in RMODE 31.

Oh darn g

 you can't write to a termfile in 31 bit mode

Are you saying that if I do all my RMODE 31/24 homework correctly for a
QSAM output DCB, and my user runs it under TSO with ALLOC DA(*) then it
will fail? Please confirm my interpretation of what you say, because if
so, it is a project-killer for me. 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Craddock, Chris
Sent: Monday, August 01, 2005 1:31 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Reference for DCB coexistence with RMODE 31 programs?


Ray Mullins' good advice snipped
 
 One thing I'll mention, because I just saw it - BDAM and BDAM
 load using BSAM don't work in RMODE 31.

Yeah, there are a couple of areas where functionality slipped through
the cracks. Its also true that  you can't write to a termfile in 31 bit
mode even with mindless QSAM. I also suspect problems in 

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

Re: Routine name/srb

...
Unix System Services is part of z/OS, and other components, e.g.,
TCP/IP, use it.
...

The latest Red-book on 'WLM for the SYSPROG' (forgotten the original title, 
BTW), has many sprinklings of the term
'USS' in the section(s) on UNIX Systems Services.

If this is not an official TLA, why is an official IBM doc using it.

BTW, all the Canadian IBM'rs are using it.

And (to keep this on topic), I highly recommend the aforementioned red-book to 
any (and all)
SYSPROGs, regardless of their experience with WLM.
Chapter Two is great!
How the WLM works.

I've been working with WLM since 1998 (leading the project to implement and 
being the implementer),
take IBM's ( Cheryl's) WLM course,
presented (pre  post) WLM implementation to CMG Canada,
come up with a major requirement to do with dynamic PAV's, that IBM is/was 
working on,
and I learned a lot!
And, I haven't even finished it, yet.

This is on par with (or better than) 
the “ABC's”.
I'm surprised it came outside of them!


-teD

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

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

Re: SMP sloppiness

...
MVS Express was a dog's breakfast
...

In the States, maybe.

IBM Canada was bragging about Express for years, to the point
where Pokey came up with the idea
to import it into the US.

After they 'improved' it, nobody wanted to touch it.

Fortunately, IBM Canada was able to fend off the 'improvements' and we kept the 
original product.


-teD

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

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

Re: What happened to iSource?

...
please add our e-mail address, [EMAIL PROTECTED], to
your address book and safe sender list..

That's not a request that your postmaster is likely to go along with.
...

In my naivete, why not?

(Of course, I still laugh at the request to do something if you don't receive 
this)

-teD

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

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

Re: Reference for DCB coexistence with RMODE 31 programs?

 Are you saying that if I do all my RMODE 31/24 homework 
 correctly for a QSAM output DCB, and my user runs it under
 TSO with ALLOC DA(*) then it will fail?

Sad but true.

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

Re: Reference for DCB coexistence with RMODE 31 programs?

Well that's interesting. I just read the relevant passage in DFSMS
Macros: 

The support for areas above the line is not provided for the following
devices: TSO terminal ... For the above devices, issue macros other than
OPEN and CLOSE in 24-bit addressing mode.

In my blissful ignorance, I think* I have been issuing PUTs in 31-bit
mode and terminal output has been working just fine. (Terminal output is
not a key to what the program does but it is specifically documented
[our doc] as supported.) Hmm.

*Am I missing something? If a program is linked into a conventional PDS
with PGM=HEWL,PARM='AMODE=31,RMODE=24... and then executed with TSO Rexx
CALL 'xx..LOAD()' will it not execute in AMODE 31? 

I have (in my ignorance, as I said) had no problems with OPEN/PUT/CLOSE
to a terminal. I just tested it again just now. All code and macros are
in RMODE 24. DCBs specify MACRF=(PM) with no DCBE. Old-fashioned 24-bit
OPEN. Curious.

rant

What a piece of #%#! Whatever happened to OS/360's vaunted device
independence? Talk about three lousy choices:

- put all or most of your QSAM code and data below the line
- dual-path your code based on whether or not a device is a terminal
- disallow terminal output

\rant

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Craddock, Chris
Sent: Monday, August 01, 2005 4:03 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Reference for DCB coexistence with RMODE 31 programs?


 Are you saying that if I do all my RMODE 31/24 homework
 correctly for a QSAM output DCB, and my user runs it under
 TSO with ALLOC DA(*) then it will fail?

Sad but true.

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

Re: Reference for DCB coexistence with RMODE 31 programs?

In a recent note, Craddock, Chris said:

 Date: Mon, 1 Aug 2005 18:02:56 -0500
 
  Are you saying that if I do all my RMODE 31/24 homework
  correctly for a QSAM output DCB, and my user runs it under
  TSO with ALLOC DA(*) then it will fail?
 
 Sad but true.
 
Surely, this ain't rocket science; merely a lack of
determination on the part of the developer, right?

A while back, I posted a problem with LMPUT to a RECFM=U
dataset.  I believe some readers analyzed this before
IBM: it was a failure to account for an I/O buffer above
the line.  IBM's resolution is to copy the data below
the line.  That feels _sooo_ twentieth century.  Is it
still impossible to use I/O buffers above the line?

Rats!  I try to look at my APAR with the new IBMLink.
It puts me at:

http://www-306.ibm.com/ibmlink/link2/servicelink/

Error 404: File not found: {0}

And they've stolen the Back button so it doesn't
work!

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Device Independence (was: ... DCB coexistence ...)

In a recent note, Charles Mills said:

 Date: Mon, 1 Aug 2005 16:41:40 -0700
 
 rant
 What a piece of #%#! Whatever happened to OS/360's vaunted device
 independence?  ...
 \rant
 
Gone with the wind.  All too many programs check for device
type, F1 DSCB, etc and fail if it's something they're not
designed for.  The fallback position should be simply
OPEN; GET/PUT; ... CLOSE; and let the chips fall where they
may, not decline to process the data set.

Even members of this list have advocated such device
sensitivity in the name of Performance.

Try, e.g.

ALLOCATE DD(INPUT) PATH('...') ...
TRANSMIT INFILE(INPUT) ...

... fails.  Why?.  Yet it works if an empty legacy data set is
catenated before the HFS file.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Dilemma of a young Mainframe Systems Programmer

2005-08-01 Thread Francisco Medina

This is being posted on behalf of a close friend named Tyler. I know he
is lurking in close proximity. Tyler was a young naïve boy right out of
high school, working as a temporary Computer Operator for a large company
(a starting spot that many on the list hold near and dear to their hearts).
Over time, he moved up the ranks and transitioned into the Technical
Support and Systems Programming departments. All appeared grand to the
outsiders eye, but as time went on Tyler began to realize that his talents
and abilities were no longer appreciated by his company.

The first indications of things going awry were the condescending attitude
and omnipotent stance from the Corporate Sysprogs. Tyler was an up and
coming youngster with an endless amount of potential and a knack for
learning new tools, methodologies, and tricks in a quick amount of time
(probably sounds familiar to many on the list). Many loved his abilities
and used his enthusiasm and knowledge to their advantage, while a selected
few tried to tear his reputation to bits. The general consensus was that
the Sysprogs were territorial and fearful of Tylers ambition.
Unfortunately, upper management was reliant upon the wicked and did not
support those striving to attain a high level of knowledge.

After years of reading IBM-Main on a daily basis, Tyler came to the
conclusion that his company situation was a mere microcosm of the industry.
Innovation and creativity are on the decline and met with stiff opposition
these days. OCO (Object Code Only) is a prime example of squashing
innovation. This inhibits the System Programmers ability to see what is
happening under the covers and mimic/exploit these facilities in other
applications. Nowadays, the Systems Programmer has to make assumptions
about what is happening internally and we arent always right (some of us
can never admit it, but we are all wrong at least once in a while). Also,
over time the Systems Programmers job responsibilities in many shops have
been reduced to customization of IBM and 3rd party products, performance
monitoring, and fine-tuning Systems and Applications. There are probably
Sysprogs out there who dont understand a lick of Assembler, but are still
very successful and efficient at their jobs (okay, some of you here may
disagree to the definition of efficient. Lets not go over the definition
of is a la Mr. Clinton). Gone are the days of creating customized
applications, exits, etc. for the benefit of companies. It still exists,
but is nowhere near as rampant as in the past.

The ever-increasing complexity of the system is a driving force behind the
transformation of the Systems Programmer job to more drone-like work, but
what it really comes down to is financials. We are all aware of the recent
layoffs within IBM (in the States and Europe) and the expansion of
outsourcing to India. In order to utilize India to its fullest potential,
there had to be extreme standardization. It isnt realistic to have major
Systems Programming customization performed halfway around the world with
the barriers of locality, time difference, and language. IBM can utilize
India to further its grip on the mainframe and standardization. As IBM
further outsources to India, their cost goes down and thus sweeter deals
are made to companies from IBM to handle their Systems Programming
functions. The company saves face in the industry by proclaiming to
be outsourcing to IBM, even though they are indirectly outsourcing to
India. Both IBM and the companies save money, but there are significant
negatives to the above scenario. Once again, innovation and ingenuity is
lost and furthermore, America falls even further down on the Technological
brain spectrum.

So where does this leave Tyler in the big scheme of things? Tyler is a
young man (okay, truly a boy) in his mid-20s with a big future in front of
him. All the stories of System crashes, rebuilding JESs, or fancy ZAPs from
the old days excite him and he wishes he had been around in those days when
there wasnt such a clamp on things. Tyler recognizes the need for the
clamps (sometimes nooses) these days and complies with them, but that
doesnt prevent him from dreaming about living in the days of old. What is
the latest excitement in the life of Tyler in the computing world? The non-
event that was Y2K! Tyler gets just as much excitement from watching the
clock turn to midnight every night. So as Tyler looks down the road, he
sees about 40 years (make that 50 as the retirement age will be 75 by then)
of drone-work rewarded with being laid off. Yippee and not only that, but
the platform may not be around more than half that duration as we seem to
fail to see the need for a better user interface.

The times have changed and there is a significant need to dumb down
(yeah, I said it) the interface. This is entirely why Windows is such a
huge success. The interface is appealing and makes things ultra-simple
for the user. Most of us here could wing

Re: Reference for DCB coexistence with RMODE 31 programs?

Looking at Gil's note, I got to wondering whether perhaps the first
assertion (about areas [buffers?] above the line) in 

The support for areas above the line is not provided for the following
devices: TSO terminal ... For the above devices, issue macros other than
OPEN and CLOSE in 24-bit addressing mode.

is true but the second assertion (about macros in 24-bit mode) is false
(no longer true?).

I think a lot of the documentation problem with this issue is that the
xSAM 31-bit support was added to MVS gradually and the documentation was
written gradually at the same times and in many cases never revisited.
The world could desperately use a single, well-written, up-to-date
chapter called using 31-bit storage and addressing with non-VSAM access
methods.

I think I may try moving everything except the DCBs and exit stubs above
the line but keeping the buffers below the line and see if it still
works with terminal output. (I can live without terminal input.)

more rant

The documentation is really poor. I didn't find the chapter on buffers
(and, oh yes, exits) above the line because it is under non-VSAM macro
descriptions. It's not a macro description. It's a general essay on
QSAM  co. and 31-bit addressing. It belongs in Using Datasets.

\more rant.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Charles Mills
Sent: Monday, August 01, 2005 4:42 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Reference for DCB coexistence with RMODE 31 programs?


Well that's interesting. I just read the relevant passage in DFSMS
Macros: 

The support for areas above the line is not provided for the following
devices: TSO terminal ... For the above devices, issue macros other than
OPEN and CLOSE in 24-bit addressing mode.

In my blissful ignorance, I think* I have been issuing PUTs in 31-bit
mode and terminal output has been working just fine. (Terminal output is
not a key to what the program does but it is specifically documented
[our doc] as supported.) Hmm.

*Am I missing something? If a program is linked into a conventional PDS
with PGM=HEWL,PARM='AMODE=31,RMODE=24... and then executed with TSO Rexx
CALL 'xx..LOAD()' will it not execute in AMODE 31? 

I have (in my ignorance, as I said) had no problems with OPEN/PUT/CLOSE
to a terminal. I just tested it again just now. All code and macros are
in RMODE 24. DCBs specify MACRF=(PM) with no DCBE. Old-fashioned 24-bit
OPEN. Curious.

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

Re: Device Independence (was: ... DCB coexistence ...)

 Whatever happened to OS/360's vaunted device 
 independence?  ... 
 
 Gone with the wind.  All too many programs check for device type

I hear you and I agree, but it's really two different issues:

- Some developer decides to over-check device types. Stupid, but it
just affects that one program and its users.

- This issue affects every developer who wants to write a program that
exploits 31-bit storage (what a concept in 2005!) and still supports
terminal I/O.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Paul Gilmartin
Sent: Monday, August 01, 2005 5:14 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Device Independence (was: ... DCB coexistence ...)


In a recent note, Charles Mills said:

 Date: Mon, 1 Aug 2005 16:41:40 -0700
 
 rant
 What a piece of #%#! Whatever happened to OS/360's vaunted device 
 independence?  ... \rant
 
Gone with the wind.  All too many programs check for device type, F1
DSCB, etc and fail if it's something they're not designed for.  The
fallback position should be simply OPEN; GET/PUT; ... CLOSE; and let the
chips fall where they may, not decline to process the data set.

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

Re: Dilemma of a young Mainframe Systems Programmer

2005-08-01 Thread Robert Justice


rant mode on

well, speaking of 'friendly user-interfaces, he could learn to use vi on 
unix

where the 'friendly way of doing something simple like signing the
he 'double toothpicks' off is to do Shift, Capital ZZ or bang Q

berkley produced both lsd and unix (and that's not a coincidence)

Okay, I'm done now speaking on behalf of friendly interfaces

enough said .

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

Re: Dilemma of a young Mainframe Systems Programmer

2005-08-01 Thread Robert Justice

okay, one more, yes, he could learn to use windows 
where in order to shutdown the system, you must first 
hit the START button. 

(Note that if us mainframers did something like that we'd be crucified). 

I really am done this time speaking of behalf of friendly inerfaces. 

. 


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

Re: Another - Another One Bites the Dust

2005-08-01 Thread Steve Comstock


 Chris, relative to another of your posts, I just received
this today (1 August) but the send date is listed as
11 July!

Kind regards,

-Steve Comstock


Craddock, Chris wrote:

snips

And another 100 to replace them for newer ones as new 
technology comes out.

Wow, they must be in the money, customers money that is.


more snips

And have another 50 in reserve to replace they ones going 
down every 5 minutes. g



Just ain't so folks... take a long hard look at the real numbers
and the results are not pretty. Fact 1. z/OS availability, as
experienced by most of our brethren, is nothing to write home about.
See all of the past threads about IPL frequency for verification. 

Its not that the system isn't capable of continuous operation (IT 
IS!!!) but evidently a wide majority of customers don't actually

trust it to be as reliable as it is.

Fact 2, there are many ways of skinning the high availability
cat and clustered systems made up of nothing more than networked
PCs and PC-like boxes are getting some seriously good numbers in
the real world. Yes Gertrude, you really can get better availability
from Windows than most z/OS customers get in the real world. Once
again, its not an intrinsic better/worse story. Its how you choose
to configure and run them.

I'd make some caustic remark about roses and coffee but I am 
sure you all get my drift. The world around us really has changed.


CC

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



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

Re: ILR005E PLPA PAGE DATA SET FULL

2005-08-01 Thread Ron and Jenny Hawkins

Shmuel,

You really need to go back and read what I was responding to. Ted said that
if he had a dedicated, custom sized volume for PLPA and another volume for
Common, he would still allocate a one Cylinder PLPA on the dedicated volume
and overflow to Common on another volume.

I said this is silly and pigheaded. What do you think of this?

I would simply love you to explain the point of your comment While I am
discussing how to configure it on a real system with a real load. What did
you ever mean by that remark? I'm sorry if I need to recall all the inner
workings of a mainframe and operating system that hasn't existed for a
quarter century to figure this comment out, but what exactly are you trying
to say about systems I work on. Be precise now, because the devil is in the
detail.

Ron 

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

Re: Dilemma of a young Mainframe Systems Programmer

2005-08-01 Thread Dave Salt


From: Francisco Medina [EMAIL PROTECTED]


SNIP

The times have changed and there is a significant need to dumb down
(yeah, I said it) the interface. This is entirely why Windows is such a
huge success. The interface is appealing and makes things ultra-simple
for the user. Most of us here could wing it when signed on to Mainframe TSO
for the very first time by using the panel options, but the majority of
people cannot. However, many 7 year olds can figure out the Windows GUI
interface in about a half-hour after a little experimentation and guidance.
Just because our platform is normally relegated to larger corporations
processing mostly in batch, does not mean that we need to have a crappy
interface that turns people off as soon as they see it. The initial
reaction of the majority would be, that sucks like the DOS days, even
though you and I probably love DOS more than Windows (hey, we love the
command-line interpreter). With the advent of Windows and the continued
aging of the mainframe community, it becomes more and more of a necessity
to enhance the user interface. If we choose to ignore this essential aspect
of the operating system, it is truly doomed for failure in the future.


Francisco,

I agree with everything you stated. However, for the benefit of those who 
monitor the list and might not know differently, I must point out there are 
many tools available that SIGNIFICANTLY improve the standard mainframe 
interface.


I confess up-front I make my living by developing such a tool, so obviously 
my opinions are biased. However, it's my experience that few people are 
aware such tools exist, or have ever had the opportunity to see or use them.


People who are exposed to the standard mainframe interface eventually move 
on to become managers. If they didn't like the mainframe and perceive it as 
unproductive and unintuitive, you can be sure they'll have no fondness for 
keeping it. But solutions are available right now, today, that dramatically 
improve the mainframe interface and help prevent this scenario from 
happening.


Perhaps everyone is sitting back and waiting for IBM to provide a solution. 
ISPF was introduced more than 20 years ago, and the underlying interface has 
changed little in all that time. Yes there have been major improvements in 
features and utilities, and the architecture itself (IMHO) is first rate. 
But still, the interface itself leaves much to be desired. Fortunately, part 
of the architecture provided by IBM allows tools and utilities to be created 
that can complement and enhance the base architecture. Tools created by 
vendors and even certain individuals are available to anyone who cares to 
look.


As with most things in life, you get what you pay for. Some tools are free, 
but usually the better tools cost money. Perhaps it's the perceived expense 
of licensing tools that prevents most shops from exploring what's available. 
But this is a case of penny wise and pound foolish. Mainframe hardware and 
software often costs hundreds of thousands or even millions of dollars to 
buy and operate. It then costs millions more on an annual basis to employee 
the people who work on the platform (i.e. roughly one million dollars a year 
for every 10 employees). With such VAST amounts of money involved, you'd 
think most companies would do almost anything in their power to improve 
productivity.


If a software tool improves productivity by an average of 10% and is used by 
20 people, and if such a tool cost $5,000 per year to license, then the 
return on investment works out to roughly $195,000 a year. Even if the tool 
generated a paltry 1% improvement in productivity, it would still return 
roughly 4 times the initial investment each and every year. If more than 20 
people used it, the return grows even bigger. It doesn't take a rocket 
scientist to realize that even very small investments in productivity tools 
can reap huge dividends, and at the same time make everyones lives much 
easier. Despite this, few companies look at any interface software beyond 
what comes with the standard mainframe installation. Other companies 
languish and complain, while still others spend huge sums of money to 
convert to other platforms.


Those in a position to investigate and recommend ways to improve mainframe 
productivity and the user interface should take it upon themselves to do so. 
If they don't, they shouldn't be surprised when the mainframe platform 
eventually dissapears for good. As Francisco so aptly stated in his email:


With the advent of Windows and the continued aging of the mainframe 
community, it becomes more and more of a necessity to enhance the user 
interface. If we choose to ignore this essential aspect of the operating 
system, it is truly doomed for failure in the future.


I couldn't agree more. However, anyone who thinks the standard ISPF 
interface is the only mainframe interface available has absolutely NO idea 
what they're missing.


Dave Salt

Re: Device Independence (was: ... DCB coexistence ...)