Re: Two silly questions about USS or OMVS on Z/OS

2006-01-19 Thread Pohlen (Mailinglist)
Sorry Paul, but every system I have seen in Germany it works quite opposite
to yours as you can see below. Maybe it has something to do with the German
translation table in TCPIP or pcom. What will we learn from that? z/OS is
not multi-cultural :-))

# ps -ef ! grep 
   POHLI   16842875  65657  - 08:57:39 ttyp  0:00 grep 
# ps -ef | grep 
Usage: ps Ý-Aacdefjlmr¨ Ý-G idlist¨ Ý-g grouplist¨ Ý-n name¨ Ý-o format¨ ...
 Ý-p proclist¨ Ý-s idlist¨ Ý-t termlist¨ Ý-u!-U uidlist¨

Have a nice weekend

Franz Josef Pohlen

- Original Message - 
From: Paul Gilmartin [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Wednesday, January 18, 2006 8:30 PM
Subject: Re: [IBM-MAIN] Two silly questions about USS or OMVS on Z/OS


 In a recent note, Pohlen Mailinglist said:

  Date: Wed, 18 Jan 2006 16:34:06 +0100
 
  in omvs you use the exclamation mark instead of the pipe symbol. I know
that
  this is a difference to normal unix systems, therefore I have mentioned
it.
 
 Ahem.  I tried before I posted:

 [EMAIL PROTECTED]:128$ uname -a
 OS/390 MVS3 15.00 03 9672

 [EMAIL PROTECTED]:129$ ps -ef ! grep xxx
 Usage: ps [-Aacdefjlmr] [-G idlist] [-g grouplist] [-n name] [-o
format] ... [-p proclist] [-s idlist] [-t termlist] [-u|-U uidlist]

 [EMAIL PROTECTED]:130$ ps -ef | grep xxx
 SPPG824   33555246  - 12:27:12 ttyp  0:00 grep xxx

 -- gil
 -- 
 StorageTek
 INFORMATION made POWERFUL

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



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


Re: REXX Problem

2006-01-19 Thread Hunkeler Peter (KRDO 4)
Note the double ampersand which I understand are also required.
I believe that is wrong; one or the other, but not both. Also,
shouldn't the last command be
 ADDRESS ISREDIT SCAN = (oldscan)

I may well be wrong with the exact syntax. I became curious and
was quickly STFM (S=searching) and left the exact syntax as an 
exercise for the interested reader :-) (In fact, I just didn't 
have the time to try myself before posting, which I usually do).


Peter Hunkeler
CREDIT SUISSE

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: z/OS IPL Consoles

2006-01-19 Thread Walter Marguccio
--- Laine, Rogers [EMAIL PROTECTED] wrote:

 We are currently running z/OS 1.4 with two LPARS that are using
 3174-1L  3274-1L controllers that have 3270 terminals 
 attached for IPL'ing our two systems.
 What can we do to upgrade this old hardware to something a 
 little more current?

2074 is the newer version of the old 3x74 control units. It is
ESCON-attached, and can be shared amongs the LPARs. A LOT better.

 We also will be moving to 1.7 within the next 6-8 months. Can  this
help?

More than the OS, it's the CPC which can provide further functionality.
You didn't mention which CPC you have. If you have, or plan to get a
CPC which support OSC channel type (OSA ICC, or whatever the name is),
then you can even get rid of the above mentioned 2074. The
functionality of the latter is moved onto this special OSA card. No
more external boxes to handle your consoles.

HTH.

Walter Marguccio

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: z/OS IPL Consoles

2006-01-19 Thread Edward E. Jaffe

Walter Marguccio wrote:

... If you have, or plan to get a
CPC which support OSC channel type (OSA ICC, or whatever the name is),
then you can even get rid of the above mentioned 2074. The
functionality of the latter is moved onto this special OSA card. No
more external boxes to handle your consoles.
  


Unless you desire a solution that includes SSL security, coax support, 
or multi-user/single-console functionality.


--
-
| 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: Two silly questions about USS or OMVS on Z/OS

2006-01-19 Thread Hunkeler Peter (KRDO 4)
z/OS UNIX is of course multi-cultural! 

The shell and (most) of the utilities are written in C. 
C needs the LE runtime environment. The LE runtime 
enviroment is by default set to the C locale, which 
means that text is interpreted with code page IBM-1047. 
Therefore shell and utilities are expecting text to be 
encoded in code page IBM-1047.

So the user needs to make sure he/she is sending text data
encoded with the code page the shell and utilities expect.

In Germany and Austria, people used to work with their 3270
emulators set to code page 273 which is now replaced by 1141
to accomodate for the Euro symbol.

The vertical bar in code page 1047 (which is what shell and
utilites expect when running in the default locale) is at 
code point x'4F'. If you look at code page 1141, you'll see
that this is the explamation point.

Tell the shell, that you are actually sending text encoded 
with 1141 instead of 1047 and the shell will understand 
you vertical bar.

You can play with this. Simply add the following to your
.profile (NOTE that some lines may get split when posted
to IBM-MAIN)


if test -z $CHLOCALE  tty -s
then
  # ***
  # *** This part needs to be in code page IBM-1047 ***
  # ***

  until test $LOCALE_TO_SET -ge 1test $LOCALE_TO_SET -le 3
  do
echo
read LOCALE_TO_SET?Enter the locale: 1=IBM-1148 (CH) 2=IBM-1047 3=IBM-1141 
(DE) (default is 1):
if test -z $LOCALE_TO_SET
then
  LOCALE_TO_SET=1
fi
  done

  if test $LOCALE_TO_SET -eq 1
  then
export MYCODEPAGE=IBM-1148
export MYLOCALE=CH
  elif test $LOCALE_TO_SET -eq 2
  then
export MYCODEPAGE=IBM-1047
export MYLOCALE=CH
  elif test $LOCALE_TO_SET -eq 3
  then
export MYCODEPAGE=IBM-1141
export MYLOCALE=DE
  else
echo ** Error: LOCALE not set ***
  fi

  unset LOCALE_TO_SET

  echo ' - - - - - - - - - - - - - - - - - - - - - - - - -'
  echo ' - Logon shell will now be invoked to reflect-'
  echo  - locale De_$MYLOCALE.$MYCODEPAGE-
  echo ' - - - - - - - - - - - - - - - - - - - - - - - - -'
# export ENV=$HOME/.shrc
  export LC_ALL=De_$MYLOCALE.$MYCODEPAGE
  export LANG=C
  export CHLOCALE=EXECUTED

  export STEPLIB=none
  exec sh -L
fi

# 
*
# *** Starting here all code needs to be able to execute in either code page 
IBM-1148, IBM-1141 or IBM-1047 ***
# 
*

echo ' - - - - - - - - - - - - - - - - - - - -  - - - -'
echo ' - Welcome to OMVS System with localized setup  -'
echo ' - - - - - - - - - - - - - - - - - - - -  - - - -'

if test $_BPX_TERMPATH = 'OMVS'
then
# In the above if stmt an unequal would be code page dependent, so equal is 
used instead
else
  chcp -a ISO8859-1 -e $MYCODEPAGE

  if test $MYCODEPAGE = IBM-1148   # Multilingual code page
  then
export DISPLAY=`who am i | awk -F'[()]' '{print ($2)}'`:0.0
  elif test $MYCODEPAGE = IBM-1141 # German/Austrian code page
  then
export DISPLAY=`who am i | awk -F'Ž()š' '„print ($2)'`:0.0
  else
export DISPLAY=`who am i ! awk -F'í()ù' '{print ($2)}'`:0.0
  fi



I'm not sure the above code page dependent statements survive 
cut'n'paste'n'post, but this is merely to illustrate the 
problems you encounter when trying to write multi-code-page 
scripts.


Either run the 3270 emulator in the same host code page the
shell is expecting by default, i.e. IBM-1047 or tell
the shell to expect your code page (see above).

Hope that helps

Regards

Peter Hunkeler
CREDIT SUISSE

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


SV: [Rexx on z/Os]Point to particular member of PDS

2006-01-19 Thread Thomas Berg
You can get a memberlist in a MVS (non-TSO) REXX by executing program IEHLIST. 
(Doing that myself.)

Thomas Berg

 -Ursprungligt meddelande-
 Från: IBM Mainframe Discussion List 
 [mailto:[EMAIL PROTECTED] För Marco Gianfranco Indaco
 Skickat: den 18 januari 2006 20:30
 Till: IBM-MAIN@BAMA.UA.EDU
 Ämne: Re: [Rexx on z/Os]Point to particular member of PDS
 
 
 Hi Mr Charles, many thanks again.
 I suppose that something near the assembler is de facto the 
 only way to do this. If your tool is too complex is, for me, 
 enough a good advice that will direct me on the right way.
 
 My actual idea, that can be wrong, is to reach two target:
 1) find a way to list pds members from mvs data areas
 2) control that after an update of Job Fail Control Block on 
 JFCBELNM the EXECIO will run correctly.
 
 Best regards.
 
 P.S.= I only need to read the member.
 
  -Original Message-
  From: IBM Mainframe Discussion List [mailto: 
 [EMAIL PROTECTED] On 
  Behalf Of Marco Gianfranco Indaco
  Sent: Wednesday, January 18, 2006 9:07 AM
  To: IBM-MAIN@BAMA.UA.EDU
  Subject: Re: [Rexx on z/Os]Point to particular member of PDS
 
 
  Hi Brendan, thanks for your reply but: neither LISTDS or 
 OUTTRAP are 
  internal function of Rexx(or MVS). LISTDS is a tso command
  OUTTRAP is an external function that run only in the TSO/E 
 address space.
  So I can't use them running out of TSO.
 
   --
 Marco Indaco
 MF Consultant
 Loc: Milan, Italy
 Mob (+39) 335 7035564
 
 --
 For IBM-MAIN subscribe / signoff / archive access 
 instructions, 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: Clear key encryption

2006-01-19 Thread Ulrich Boche

Timothy Sipples wrote:
It's worth pointing out that so-called clear key encryption is what 
every other standard server does with the keys.  Except on a mainframe you 
have key-protected memory (and accelerators), so it's a lot harder for 
another task to grab that key.  I'd prefer a different term for clear 
key on mainframes -- maybe privileged key -- but there it is.


Secure key is fairly exotic stuff, but mainframes offer it if you need 
it.  The private keys never appear in memory: they are tucked away inside 
the special tamper-proof cryptographic coprocessor cards.  That also means 
extra I/O out to those cards for crypto processing, so it's not something 
you want to do unless you really need it.


The comment downthread is quite astute, that DR planning must take into 
account private key preservation and recovery.  If you lose the key(s) 
you've lost the data.  Fortunately ICSF (the z/OS key management facility 
and crypto API set) has a multi-year track record of keeping those keys 
safe.  With a little bit of planning this stuff really works, even in a DR 
situation.


It not true that the mainframe is the only platform that can use secure 
keys (keys encrypted by a master key and only decrypted inside protected 
encryption hardware). The IBM 4758-2 cards for xSeries were functionally 
very similar to the PCICC cards and had the same FIPS 140-1 level 4 
certification. These cards were also available for pSeries and iSeries. 
Currently, though, I'm not aware of any announced follow-on products to 
these cards.


There are other vendors who sell external crypto boxes with protected keys.
--
Ulrich Boche

--
Ulrich Boche
SVA GmbH, Germany
IBM Premier Business Partner

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

2006-01-19 Thread Bruce Hewson
Hello Ed,

Date formats can not be assumed. And this was extract from IBM SIS site.

I read it as yy/mm/dd = 2002 August 26,

On Wed, 18 Jan 2006 17:17:38 -0600, Ed Gould [EMAIL PROTECTED] wrote:

On Jan 17, 2006, at 11:17 PM, Bruce Hewson wrote:

 Hello Victor,

 Have you checked your SMF TYPE 19 collection as per Shane and Sam's
 posts?

 Check out Info APAR:

   APAR Identifier .. II02887  Last Changed  02/08/26
   SMF SWITCH COMMAND DOES NOT COMPLETE IN A TIMELY MANNER OR
   IPL DOES NOT COMPLETE IN TIMELY MANNER - WAITING ON SHARED DASD

Bruce,

1926 ???!!! even MVS is not that old.

Ed



Regards
Bruce

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: IPCS Batch on ACTIVE ?

2006-01-19 Thread Robert Wright
Cwi Jeret wrote on 01/19/2006 02:45:58 AM:

 U want to submit an IPCS Batch Job on the TSO ACTIVE storage
 rather than on a DUMP DataSet, like I do on the Source entry on the
 IPCS Defaults panel of the Online Dialog .

 How do I have to change my following JOB ?

 //IPCS  EXEC PGM=IKJEFT01,REGION=4M
 //IPCSDDIR  DD DSN=User.IPCSDDIR,DISP=SHR
 //DUMP  DD DSN=SYS1.DUMP,DISP=SHR  How to change
 to ACTIVE ?
 //SYSPROC   DD DSN=SYS1.SBLSCLI0,DISP=SHR
 //SYSUDUMP  DD SYSOUT=V
 //SYSTSPRT  DD SYSOUT=V
 //SYSPRINT  DD SYSOUT=V
 //IPCSPRNT  DD SYSOUT=V
 //SYSTSIN   DD *
 PROFILE MSGID
 IPCS NOPARM
 DROPDUMP DDNAME(DUMP)
 SETDEF  DDNAME(DUMP)  PRINT NOTERMINAL  NOCONFIRM
 IPLDATA STATUS
 DROPDUMP DDNAME(DUMP)
 END
 //*
 //
You want to do the following:

1.  Remove the DUMP ddname from the JCL.

2.  Change all instances of DDNAME(DUMP) in the input stream to read
ACTIVE.

Bob Wright - MVS Service Aids

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


Re: Two silly questions about USS or OMVS on Z/OS

2006-01-19 Thread Johnny Luo
 Glad to give the feedback.I've checked the /etc/services and found
out that the port otelnetd is using is 1023.Then I invoke an ordinary
telnet session to it and uss shows up:)


--
Best Regards,
Johnny Luo

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: IPCS Batch on ACTIVE ?

2006-01-19 Thread Cwi Jeret
Thanks For Your Answer !

Cwi Jeret

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

2006-01-19 Thread Chase, John
 -Original Message-
 From: IBM Mainframe Discussion List On Behalf Of Craig Bakken
 
 We would like to develop some scenarios to help train our 
 operations staff in situations were the operators need to 
 diagnose a problem and take such actions as taking a 
 standalone dump, partitioning an ill system out of a sysplex 
 or identifying a task causing a problem (ie looping or 
 holding a lock).  Does anyone have some documented scenarios 
 and/or any program code that may cause problems that could be 
 used to train operators on a standalone system?

Well, here's a QD program that will just loop for a long time:

LOOPER  CSECT ,
LOOPER  RMODE ANYin case you're storage-constrained  :-)
USING *,15
STM   14,12,12(,3)   save caller's regs
  SR2,2zero outer loop counter
SR3,3zero inner loop counter
LOOPEQU   *
BCT   3,LOOP iterate inner
BCT   2,LOOP iterate outer
LM14,12,12(13)   restore caller's regs
SR15,15  set rc=0 
BR14 return to caller
END   LOOPER

-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: Operator Training Scenarios

2006-01-19 Thread Mark Jacobs
Here is a shorter one for really storage constrained systems :-)

LOOPER  CSECT
LOOPER  RMODE  ANY
LOOPER  AMODE  31
BR 15
END

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Chase, John
Sent: Thursday, January 19, 2006 7:53 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Operator Training Scenarios

 -Original Message-
 From: IBM Mainframe Discussion List On Behalf Of Craig Bakken
 
 We would like to develop some scenarios to help train our 
 operations staff in situations were the operators need to 
 diagnose a problem and take such actions as taking a 
 standalone dump, partitioning an ill system out of a sysplex 
 or identifying a task causing a problem (ie looping or 
 holding a lock).  Does anyone have some documented scenarios 
 and/or any program code that may cause problems that could be 
 used to train operators on a standalone system?

Well, here's a QD program that will just loop for a long time:

LOOPER  CSECT ,
LOOPER  RMODE ANYin case you're storage-constrained  :-)
USING *,15
STM   14,12,12(,3)   save caller's regs
  SR2,2zero outer loop counter
SR3,3zero inner loop counter
LOOPEQU   *
BCT   3,LOOP iterate inner
BCT   2,LOOP iterate outer
LM14,12,12(13)   restore caller's regs
SR15,15  set rc=0 
BR14 return to caller
END   LOOPER

-jc-

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

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


Re: REXX Problem

2006-01-19 Thread Joel Wolpert

Joel Wolpert
Director - Performance and Capacity Planning
Shared Data Center
Securities Industry Automation Corporation
2 Metrotech Center
New York, NY 11201
(212) 383-3323
[EMAIL PROTECTED]


- Original Message -
From: IBM Mainframe Discussion List [EMAIL PROTECTED]
Sent: 01/18/2006 06:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: REXX Problem

In [EMAIL PROTECTED], on 01/18/2006
   at 11:54 AM, Edward E. Jaffe [EMAIL PROTECTED] said:

Just out of curiosity, is there a performance impact either way?

There is a minor performance cost to putting the unnecessary ADDRESS
ISREDIT statement in front of the ADDRESS ISREDIT cmd statements.
There is some debate as to whether there is a performance difference
between

ADDRESS ISREDIT cmd

and

cmd

I regard the impact on readability and maintainability as more
important than the performance impact.
 
-- 
 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

-
This message and its attachments may contain  privileged and
confidential information.  If you are not the intended recipient(s),
you are prohibited from printing, forwarding, saving or copying this
email.  If you have received this e-mail in error, please immediately
notify the sender and delete this e-mail and its attachments from your
computer.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Does SMP/E APPLY REDO Replace or Merge?

2006-01-19 Thread John Eells

[EMAIL PROTECTED] wrote:


This is the sort of question that can only (I hope) arise in a development
and test environment, not in production.


I can arise whenever anyone does what you did; so it's possible 
in production, but we hope that packagers take steps to prevent 
that.  (When they don't, PEs and SUPs tend to follow.)




Suppose I build a PTF and APPLY it.  I have second thoughts, and rebuild
it with a considerably different set of elements from the original; RECEIVE;
and APPLY REDO.  Is the result the same as if the earlier version had never
existed and only the later were APPLYed, or is it some sort of merging of
the two different versions?


SMP/E won't remove the first PTF's parts before installing the 
second's.  Suppose PTF 1a has parts A, B, and C and PTF 1b has B, 
C, and D.  The result after this scenario will have A, B, C, and D.




Recent unpleasant experience suggests that it merges rather than replaces:
elements may appear with the RMID of the PTF, even though they are not
present in the later version, only the earlier.

How do I undo this mess?  I suspect I might as well delete the CSI and
rebuild.


No need to be that drastic.  Just build a PTF with the parts you 
want that supercedes the first PTF number.  Make sure it contains 
*all* the parts that were part of either version of that PTF. 
Following the example above, PTF 2 would have to contain A, B, C, 
and D; part A would be at the pre-PTF 1a level; and parts B, C, 
and D would be at the PTF 1b level.


(Before the second APPLY, you could have RESTOREd PTF 1a and then 
APPLYed PTF 1b to get almost the same result.  The difference is 
that had you done that, the parts would have PTF 1b's RMID rather 
than PTF 2's RMID.)




This surely provokes a wishlist item:  If I attempt APPLY REDO, and there
are elements in the target zone with the RMID of the PTF, but not in the
PTF itself, SMP/E should report an error and fail the APPLY.  MC should
suggest Programmer Action:  Perform RESTORE and only then retry the APPLY.


I'll leave that one to you and Kurt.  But I'll note that PTF 
packagers are a small subset of SMP/E users, so my uninformed 
opinion is that it's quite possible there are higher-priority 
things for them to do...




Related question:  Is there any query that will show me all elements in
a target zone having a given RMID?


I don't recall, but the SMP/E books should say.

--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]

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


Re: Find the DD/dataset allocations for a job

2006-01-19 Thread Gilbert Saint-Flour
[EMAIL PROTECTED] wrote:

 I am trying to find a way (without cross memory services) to find the
 datasets allocated to DD names in an address space other than my own.
 Specifically, I am looking for a way for when given the name of a CICS
 region, how do I find the name of the CSD allocated to the DFHCSD DD
 card?

ShowMVS retrieves data set allocations for the master address space, and 
you could look at the code to see how it does it, but it's using CMS.

-- 

 Gilbert Saint-Flour
 GSF Software
 http://gsf-soft.com/
 mailto:[EMAIL PROTECTED]

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


Re: Find the DD/dataset allocations for a job

2006-01-19 Thread Rob Scott
 I am trying to find a way (without cross memory services) to find the
 datasets allocated to DD names in an address space other than my own.
 Specifically, I am looking for a way for when given the name of a CICS
 region, how do I find the name of the CSD allocated to the DFHCSD DD
 card?

I am afraid you are not going to get very far without X-memory services.

Your only hope that I can think of (without X-memory) is to use the
GQSCAN service to retrieve the current list of enqueues for the ASID in
question and then rely on some sort of site-standard, unique major name
or something in the dataset name to give you a good guess as to what it
might be. In your example, scanning the dataset name for 'CSD' might be
good - but can also give you false positives or no results at all.



If using x-memory services, then you need to do something like :

Shoot an SRB into the ASID in question and then run the DSAB/TIOT
entries to find the DDNames and then translate the TIOEJFCB SVA (using
SWAREQ) to get the JFCB and from there you can get the dataset name. Of
course, all the normal caveats apply when snooping around inside another
address space uninvited

Rob Scott
Rocket Software
http://www.rs.com/portfolio/mxi/

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

2006-01-19 Thread Mark Zelden
On Thu, 19 Jan 2006 06:52:33 -0600, Chase, John [EMAIL PROTECTED] wrote:


Well, here's a QD program that will just loop for a long time:

LOOPER  CSECT ,
LOOPER  RMODE ANYin case you're storage-constrained  :-)
USING *,15
STM   14,12,12(,3)   save caller's regs
   SR2,2zero outer loop counter
SR3,3zero inner loop counter
LOOPEQU   *
BCT   3,LOOP iterate inner
BCT   2,LOOP iterate outer
LM14,12,12(13)   restore caller's regs
SR15,15  set rc=0
BR14 return to caller
END   LOOPER


How about IEFBR15?  ;-)

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

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


Re: Operator Training Scenarios

2006-01-19 Thread Chase, John
 -Original Message-
 From: IBM Mainframe Discussion List On Behalf Of Mark Zelden
 
 On Thu, 19 Jan 2006 06:52:33 -0600, Chase, John 
 [EMAIL PROTECTED] wrote:
 
 Well, here's a QD program that will just loop for a long time:
 
 LOOPER  CSECT ,
 LOOPER  RMODE ANYin case you're storage-constrained  :-)
 USING *,15
 STM   14,12,12(,3)   save caller's regs
SR2,2zero outer loop counter
 SR3,3zero inner loop counter
 LOOPEQU   *
 BCT   3,LOOP iterate inner
 BCT   2,LOOP iterate outer
 LM14,12,12(13)   restore caller's regs
 SR15,15  set rc=0
 BR14 return to caller
 END   LOOPER
 
 
 How about IEFBR15?  ;-)

Not self-correcting (won't eventually end).  :-)

Now all we need are a few estimates how long LOOPER would run on various
processors if not cancelled

-jc-

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


Re: How SMFDUMP works?

2006-01-19 Thread Ed Gould

On Jan 19, 2006, at 5:35 AM, Bruce Hewson wrote:


Hello Ed,

Date formats can not be assumed. And this was extract from IBM SIS  
site.


I read it as yy/mm/dd = 2002 August 26,


I know this but it was a lame attempt at humor.   There is always  
talk on here about the graying of us sysprogs.

Sorry.


Ed



On Wed, 18 Jan 2006 17:17:38 -0600, Ed Gould  
[EMAIL PROTECTED] wrote:



On Jan 17, 2006, at 11:17 PM, Bruce Hewson wrote:


Hello Victor,

Have you checked your SMF TYPE 19 collection as per Shane and Sam's
posts?

Check out Info APAR:

  APAR Identifier .. II02887  Last Changed  02/08/26
  SMF SWITCH COMMAND DOES NOT COMPLETE IN A TIMELY MANNER OR
  IPL DOES NOT COMPLETE IN TIMELY MANNER - WAITING ON SHARED DASD


Bruce,

1926 ???!!! even MVS is not that old.

Ed




Regards
Bruce

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Does SMP/E APPLY REDO Replace or Merge?

2006-01-19 Thread Kurt Quackenbush

snip

John is right on with his response regarding REDO processing (thanks John).


This surely provokes a wishlist item:  If I attempt APPLY REDO, and there
are elements in the target zone with the RMID of the PTF, but not in the
PTF itself, SMP/E should report an error and fail the APPLY.  MC should
suggest Programmer Action:  Perform RESTORE and only then retry the 
APPLY.


I'll leave that one to you and Kurt.  But I'll note that PTF packagers 
are a small subset of SMP/E users, so my uninformed opinion is that it's 
quite possible there are higher-priority things for them to do...


You could submit a requirement, but John is right that for the 
foreseeable future I believe we have many higher-priority items to keep 
us busy.



Related question:  Is there any query that will show me all elements in
a target zone having a given RMID?


No such query or filtering is provided by SMP/E.  You could of course 
use LIST. and FIND the RMID value in question... crude by effective. 
Or you could use the GIMAPI program interface to perform such a query.


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


DocuText on z/OS 1.7

2006-01-19 Thread Laine, Rogers
Can someone tell me if they are running Docutext release 5.8.2D on z/OS
1.7?
Vendor says they have not tested this release on 1.7.
Any help would be appreciated.
 
TIA,
Rogers 
 
 
 
 



Confidentiality Notice:

This E-Mail transmission (and/or the documents accompanying it)
may contain information belonging to the sender which is 
confidential, privileged and/or exempt from disclosure under 
applicable law.  The information is intended only for the use
of the individual(s) or entity named above.   If you are not
the intended recipient, you are hereby  notified that any
disclosure, copying, distribution or the taking of any action
in reliance on the contents of this information is strictly 
prohibited.  If you have received this E-Mail transmission 
in error, please immediately notify us by return E-Mail or 
telephone to arrange for return of its contents including any
documents.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Billing for SRB Time

2006-01-19 Thread Tom Schmidt
On Wed, 18 Jan 2006 16:12:50 -0600, Craddock, Chris wrote:
Let's be clear - there is no difference AT ALL between the engines.
Every engine on the die can execute any instruction defined in the
architecture.

zAAP engines are a slightly different specialization. They are not
visible in the normal scheme of things and they can't field (I/O)
interrupts.


Is this they can't because of the contents of control register 6, or
because of something else?


 I agree that a problem program should see no differences.

Nope. The only way a zAAP gets to do any work at all is that the z/OS
dispatcher knows a zAAP is there. The dispatcher recognizes JVM work
and, if a zAAP is available, automatically dispatches that work on the
zAAP. But getting it going on the zAAP isn't exactly free. That's
considered ok because JAVA work is typically going to crank for a
(relatively) long time.
...
On your question of whether you could run an SRB on a zAAP;

SRBs are intended to be for very short running work that is in and out
and gone. They have been perverted into more long running things (e.g.
DB2) over the years, but the overhead of getting dispatched on a zAAP
would tend to limit the value of running a normal SRB on a zAAP - unless
the system knew ahead of time that the SRB was going to run for a while
- which of course it doesn't.

In theory if the dispatcher was willing to do it there is no reason SRB
work could not be dispatched on a zAAP, but it would be subject to the
same limitations as the JVM. In practice, the current JVM couldn't run
in SRB mode without some major surgery and there would not be any good
reason to do that. So you won't see an SRB running on a zAAP any time
soon.


Why do you say that the overhead is greater to dispatch a zAAP than a non-
zAAP CPU?  (I'm curious.)

--
Tom Schmidt
Madison, WI
(We have some IFLs and some zAAPs  the they all work quite well.)

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

2006-01-19 Thread John Laubenheimer
On Wed, 11 Jan 2006 06:45:55 -0600, Chase, John [EMAIL PROTECTED] wrote:

 -Original Message-
 From: IBM Mainframe Discussion List On Behalf Of Gene Muszak

 Esteemed colleagues

 Does anyone know where the SHARE expo is after SEATTLE in March?

According to http://www.share.org/Events/future_conf.cfm:

SHARE User-Driven Training Event  Expo
August 13-18, 2006
Baltimore, Maryland

I see nothing has been published yet for 2007 and beyond

-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

The SHARE website has finally been updated to include the dates and
locations for the 2007 conferences.


Future Conferences

SHARE User-Driven Training Event  Expo (SHARE 106)
March 5-10, 2006
Seattle, Washington

SHARE User-Driven Training Event  Expo (SHARE 107)
August 13-18, 2006
Baltimore, Maryland

SHARE User-Driven Training Event  Expo (SHARE 108)
February 11-16, 2007
Tampa, Florida

SHARE User-Driven Training Event  Expo (SHARE 109)
August 12-17, 2007
San Diego, California


In particular, note SHARE 108, which is a bit earlier than is normally
scheduled.  SHARE 108 was originally scheduled for the week before Mardi
Gras in New Orleans.  After Katrina, the Board of Director concluded that
it may not be in SHARE's interest to stay in New Orleans at this time.
The dates still reflect the week before Mardi Gras timing, albeit in a
different location.  As I understand it, New Orleans will be re-evaluated
for a future conference location.  (And, this change of venue was why the
2007 conferences haven't been posted until now.)

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


Re: Operator Training Scenarios

2006-01-19 Thread Fletcher, Kevin
Is that ONE better than an IEFBR14? ;-)

Fletch 
 
 
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Zelden
Sent: Thursday, January 19, 2006 8:54 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Operator Training Scenarios


On Thu, 19 Jan 2006 06:52:33 -0600, Chase, John [EMAIL PROTECTED]
wrote:


Well, here's a QD program that will just loop for a long time:

LOOPER  CSECT ,
LOOPER  RMODE ANYin case you're storage-constrained  :-)
USING *,15
STM   14,12,12(,3)   save caller's regs
   SR2,2zero outer loop counter
SR3,3zero inner loop counter
LOOPEQU   *
BCT   3,LOOP iterate inner
BCT   2,LOOP iterate outer
LM14,12,12(13)   restore caller's regs
SR15,15  set rc=0
BR14 return to caller
END   LOOPER


How about IEFBR15?  ;-)

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

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

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


Re: Two silly questions about USS or OMVS on Z/OS

2006-01-19 Thread Hal Merritt
Could it be that z/os is *too* multi-cultural?  :-))

The command response in the text of your email was very hard to read, no doubt 
due to some translations (code page?) along the way. There were two characters 
that did not display correctly on my PC.  

I have to wonder if that is somehow connected???

Let's put the blame on Windows. ;-)

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of 
Pohlen (Mailinglist)
Sent: Thursday, January 19, 2006 2:07 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Two silly questions about USS or OMVS on Z/OS

Sorry Paul, but every system I have seen in Germany it works quite opposite
to yours as you can see below. Maybe it has something to do with the German
translation table in TCPIP or pcom. What will we learn from that? z/OS is
not multi-cultural :-))

# ps -ef ! grep 
   POHLI   16842875  65657  - 08:57:39 ttyp  0:00 grep 
# ps -ef | grep 
Usage: ps Ý-Aacdefjlmr¨ Ý-G idlist¨ Ý-g grouplist¨ Ý-n name¨ Ý-o format¨ ...
 Ý-p proclist¨ Ý-s idlist¨ Ý-t termlist¨ Ý-u!-U uidlist¨

Have a nice weekend

Franz Josef Pohlen

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Billing for SRB Time

2006-01-19 Thread Craddock, Chris
 zAAP engines are a slightly different specialization. They are not
 visible in the normal scheme of things and they can't field (I/O)
 interrupts.

 Is this they can't because of the contents of control register 6, or
 because of something else?

I am not really sure. At some level the I/O interrupt mask has to be
off, but the key question is where is that set? Don Deese said that the
personality of the cpu is set in the HSA by PR/SM as part of LPAR
dispatch. 

That has the ring of truth about it because among other things, it
wouldn't require the overt cooperation of the operating system. z/OS and
zVM are both more aware of their environment than zLinux - which
basically doesn't care what the engine is. 

 Why do you say that the overhead is greater to dispatch a zAAP than a
non-
 zAAP CPU?  (I'm curious.)

Well for one thing, when the dispatcher is running on a normal CPU it is
already running on the engine where the application code will be
dispatched. There is a separate (not externally documented) signaling
protocol to get work fired up on a zAAP. Even on its best day that is
going to entail more path length than an ordinary dispatch.

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


Another fine mess ...

2006-01-19 Thread Kirk Talman
I own a piece of Assembler batch code that reads a parm member of a system 
library managed by Endeavor. This piece of code runs many times a day on 
all (10) production plexes.

The FINE Endeavor folks have chosen to compress the library on each plex 
around 5 am each day.  The collisions do not, unfortunately, cause an 
abend.  The program reads the member and finds garbage, causing it to 
fail in its task, returning the wrong return code.

I am wondering if I attempt to validate the parm, and finding garbage, 
what are the conditions under which I can get the correct information?

If I wait say 10-20 seconds, do I have to close and reopen the file before 
reissuing the FIND macro for the member?  Are there any other gotchas 
lurking in the shadows?

All lpars appear to be zOS 1.4.


-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom it is
addressed.  The information may also constitute a legally privileged
confidential communication.  If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying, or
unauthorized use of this information, or the taking of any action in
reliance on the contents of this information is strictly prohibited.
If you have received this communication in error, please notify us
immediately by e-mail, and delete the original message.  Thank you

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


Re: Another fine mess ...

2006-01-19 Thread Edward E. Jaffe

Kirk Talman wrote:
I own a piece of Assembler batch code that reads a parm member of a system 
library managed by Endeavor. This piece of code runs many times a day on 
all (10) production plexes.


The FINE Endeavor folks have chosen to compress the library on each plex 
around 5 am each day.  The collisions do not, unfortunately, cause an 
abend.  The program reads the member and finds garbage, causing it to 
fail in its task, returning the wrong return code.


I am wondering if I attempt to validate the parm, and finding garbage, 
what are the conditions under which I can get the correct information?


If I wait say 10-20 seconds, do I have to close and reopen the file before 
reissuing the FIND macro for the member?  Are there any other gotchas 
lurking in the shadows?


All lpars appear to be zOS 1.4.
  


IMHO, unserialized use of a PDS that's being compressed is a big 
mistake! I suggest you a) compress the PDS with DISP=OLD (SYSDSN 
exclusive), b) use an alternate serialization mechanism of some kind, or 
c) convert the library to PDSE and stop compressing it altogether.


--
.-.
| 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: Another fine mess ...

2006-01-19 Thread Knutson, Sam
Use PDSE

Use DISP=OLD either on your job or the compress

Change your code to do the same enqueue used by IEBCOPY

Best Regards,

Sam Knutson, GEICO
Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office)  301.986.3574

Logic is a tweeting bird in a green meadow. - Mr. Spock 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Kirk Talman
Sent: Thursday, January 19, 2006 11:53 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Another fine mess ...

I own a piece of Assembler batch code that reads a parm member of a
system library managed by Endeavor. This piece of code runs many times a
day on all (10) production plexes.

The FINE Endeavor folks have chosen to compress the library on each plex
around 5 am each day.  The collisions do not, unfortunately, cause an
abend.  The program reads the member and finds garbage, causing it to
fail in its task, returning the wrong return code.

I am wondering if I attempt to validate the parm, and finding garbage,
what are the conditions under which I can get the correct information?

If I wait say 10-20 seconds, do I have to close and reopen the file
before reissuing the FIND macro for the member?  Are there any other
gotchas lurking in the shadows?

All lpars appear to be zOS 1.4.



This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

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


Re: Another fine mess ...

2006-01-19 Thread Mark Zelden
On Thu, 19 Jan 2006 11:52:51 -0500, Kirk Talman [EMAIL PROTECTED] wrote:

I own a piece of Assembler batch code that reads a parm member of a system
library managed by Endeavor. This piece of code runs many times a day on
all (10) production plexes.

The FINE Endeavor folks have chosen to compress the library on each plex
around 5 am each day.  The collisions do not, unfortunately, cause an
abend.  The program reads the member and finds garbage, causing it to
fail in its task, returning the wrong return code.

I am wondering if I attempt to validate the parm, and finding garbage,
what are the conditions under which I can get the correct information?

If I wait say 10-20 seconds, do I have to close and reopen the file before
reissuing the FIND macro for the member?  Are there any other gotchas
lurking in the shadows?

All lpars appear to be zOS 1.4.



Opt. #1 (best opt.)  Convert to PDSE and never worry about compress

Opt. #2, change JCL to DISP=OLD

We changed Endevor libs to PDSE years ago.  The Endeavor folks used
to schedule jobs to compress our Endevor controlled JES2 proclibs and
cause problems.  PDSE resolved that and later on we converted to
dynamic proclibs after z/OS 1.2.

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

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


Auto-FTP

2006-01-19 Thread Jeffrey Barnard
Does z/OS have a way to automatically FTP reports from JES to a 
destination host?


Thanks.

Regards,
Jeff
--
Jeffrey C Barnard
Barnard Software, Inc. http://www.bsiopti.com
Phone 407-323-4773 Fax 407-323-4775

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

2006-01-19 Thread Víctor de la Fuente
I'm not sure, but, yes I think so.

2006/1/18, Imbriale, Donald (Exchange) [EMAIL PROTECTED]:

 Are you using any SMF exits such as IEFU29?

 Don Imbriale

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf
 Of Víctor de la Fuente
 Sent: Wednesday, January 18, 2006 4:39 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: How SMFDUMP works?
 
 Hi!
 I readed quickly all your answers!Thanks to all!
 My problem with the CLOSE PENDING is the file is not going DUMP REQUIRED
 forever...until it wants! I mean we don't know when it is going to change
 its status. Sometimes we waited for 20 minutes or more! So we need to
 know why it's not changing, because we'll go out of buffers if, any funny
 day, the file wants to stay in CLOSE PENDING for hours!
 
 Talking about SMF type records, we currently are NOT writing Type 19, 69
 nor
 99. When I can, I'll send you our SMFPRM member.
 
 I don't know the solution for my problem yet, but, this way, I'm sure
 I'll
 be a SMF expert in a few days!!!


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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Does SMP/E APPLY REDO Replace or Merge?

2006-01-19 Thread Skip Robinson
A customer's perspective. We recently had a problem for which IBM gave us
an APAR test fix. A while later they rewrote the fix so that it hit a
different MOD within the same LMOD. In that case, APPLY CHECK failed
because the new fix attempted to SUP another sysmod but did not contain the
same elements. For that case, SMP/E detects an error and quits. (Goodness.)
The proper way out was to RESTORE the first fix, which removed all traces
of it from the target zone, then APPLY the new fix. The result was clean:
correct version of code, SMP/E happy with all relationships.

Although vendors are in the business of crafting PTFs, customers often
create usermods and therefore have to deal with the same issues. It's
valuable for everyone to understand the process. SMP/E almost always
provides a mechanism to correct problems like this. I can't remember the
last time we actually had to trash an entire CSI and start over.

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

IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 01/19/2006
06:52:21 AM:

 snip

 John is right on with his response regarding REDO processing (thanks
John).

  This surely provokes a wishlist item:  If I attempt APPLY REDO, and
there
  are elements in the target zone with the RMID of the PTF, but not in
the
  PTF itself, SMP/E should report an error and fail the APPLY.  MC
should
  suggest Programmer Action:  Perform RESTORE and only then retry the
  APPLY.
 
  I'll leave that one to you and Kurt.  But I'll note that PTF packagers
  are a small subset of SMP/E users, so my uninformed opinion is that
it's
  quite possible there are higher-priority things for them to do...

 You could submit a requirement, but John is right that for the
 foreseeable future I believe we have many higher-priority items to keep
 us busy.

  Related question:  Is there any query that will show me all elements
in
  a target zone having a given RMID?

 No such query or filtering is provided by SMP/E.  You could of course
 use LIST. and FIND the RMID value in question... crude by effective.
 Or you could use the GIMAPI program interface to perform such a query.

 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

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

2006-01-19 Thread Paul Gilmartin
In a recent note, Knutson, Sam said:

 Date: Thu, 19 Jan 2006 12:36:36 -0500
 
 Use PDSE
 
The second-best idea.  Unfortunately we can't always do it because
we share data sets beyond sysplex boundaries.  HFS/z/FS shared by
NFS might be even better.

 Use DISP=OLD either on your job or the compress
 
Not always practical for heavily used linklibs and parameter libraries.

 Change your code to do the same enqueue used by IEBCOPY
 
How do I find that?  A search for ENQUEUE in:

Title: z/OS V1R7.0 DFSMSdfp Utilities
Document Number: SC26-7414-03

... returns no hits.  Do the queue names and resource names involved
require APF?

-- 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: Auto-FTP

2006-01-19 Thread Charles Mills
Is there an automatically FTP reports from JES to a destination host
feature in z/OS? Not that I know of. Could you do this with a batch job and
your scheduler? Possibly. Consider also lpp and third party products.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Jeffrey Barnard
Sent: Thursday, January 19, 2006 10:00 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Auto-FTP


Does z/OS have a way to automatically FTP reports from JES to a 
destination host?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Billing for SRB Time

2006-01-19 Thread Tom Schmidt
On Thu, 19 Jan 2006 10:54:16 -0600, Craddock, Chris wrote:

 zAAP engines are a slightly different specialization. They are not
 visible in the normal scheme of things and they can't field (I/O)
 interrupts.

 Is this they can't because of the contents of control register 6, or
 because of something else?

I am not really sure. At some level the I/O interrupt mask has to be
off, but the key question is where is that set? Don Deese said that the
personality of the cpu is set in the HSA by PR/SM as part of LPAR
dispatch.

That has the ring of truth about it because among other things, it
wouldn't require the overt cooperation of the operating system. z/OS and
zVM are both more aware of their environment than zLinux - which
basically doesn't care what the engine is.


The I/O interrupt issue has me wondering though -- are folks claiming that
a zAAP cannot process paging I/O for itself?  Surely the JVM is not page-
fixed in storage, is it?  (I don't see obvious evidence of that on our
systems, but they ARE the size of small continents so that might be part of
the reason why, I suppose.)

I am expecting that the zAAP's control register 6 has a
sufficiently 'different' I/O interrupt subclass value to allow for paging
I/O and not for normal I/O, thus implementing the spirit of the zAAP
nicely.


 Why do you say that the overhead is greater to dispatch a zAAP than a
 non-zAAP CPU?  (I'm curious.)

Well for one thing, when the dispatcher is running on a normal CPU it is
already running on the engine where the application code will be
dispatched. There is a separate (not externally documented) signaling
protocol to get work fired up on a zAAP. Even on its best day that is
going to entail more path length than an ordinary dispatch.

At least one of the (mumble-multiple) zAAPs here is usually active with
mumble-multiple JVMs having available work at most any given point when the
sun is visible in the sky here.  Often it is more than one zAAP busy.  I
don't see the non-zAAP working as hard as the zAAPs a lot of the time
during the day.  Given that environment I don't see why the dispatcher
wouldn't dispatch an SRB... especially one involved in fielding page I/O,
for example.  (But I don't recall having seen one on a zAAP for certain
yet, either; I suppose I can go dig through some dumps.)

--
Tom Schmidt
Madison, WI

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

2006-01-19 Thread Paul Gilmartin
In a recent note unmask] said:

 Date: Thu, 19 Jan 2006 12:59:54 -0500

 Does z/OS have a way to automatically FTP reports from JES to a
 destination host?

Why must it be from JES?  How about:

o Step 1:  write the report to a temporary data set.

o Step 2:  FTP from the data set to the destination host.

o Step 3:  IEBGENER the data set to the spool.

-- 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 SMFDUMP works?

2006-01-19 Thread Knutson, Sam
The output from the MVS operator command 

D SMF,O 

will show this and most of the other pertinent SMF configuration information of 
interest except CISIZE I think.

Thanks, Sam

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of 
Víctor de la Fuente
Sent: Thursday, January 19, 2006 12:48 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: How SMFDUMP works?

I'm not sure, but, yes I think so.

2006/1/18, Imbriale, Donald (Exchange) [EMAIL PROTECTED]:

 Are you using any SMF exits such as IEFU29?

 Don Imbriale


This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

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


Re: Auto-FTP

2006-01-19 Thread Chuck Arney
Jeff is asking about a feature that is available with the VSE IP stack's FTP
offerings.  With them and the proper definitions, Auto-FTP support will
automatically FTP a report from the VSE/POWER queues to the desired location
anytime a spool entry pops up in a designated output class.  There is no
additional action required by the user to make the FTP occur.

Since he is the author of one of the VSE IP stacks, I suspect he is thinking
of a new opportunity.  And he may have found one since z/OS TCP/IP does not
offer this support as far as I am aware!

Chuck Arney
illustro Systems International, LLC
http://www.illustro.com
Access 3270 data from anywhere with z/XML-Host
Access 3270 apps from the web with z/Web-Host
Access CMS minidisks from OS/390 or VSE with CMSACCess
Voice: 972-296-6166

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
 Behalf Of Paul Gilmartin
 Sent: Thursday, January 19, 2006 12:46 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Auto-FTP
 
 In a recent note unmask] said:
 
  Date: Thu, 19 Jan 2006 12:59:54 -0500
 
  Does z/OS have a way to automatically FTP reports from JES to a
  destination host?
 
 Why must it be from JES?  How about:
 
 o Step 1:  write the report to a temporary data set.
 
 o Step 2:  FTP from the data set to the destination host.
 
 o Step 3:  IEBGENER the data set to the spool.
 

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

2006-01-19 Thread Kirk Talman
I thank you for your consideration.  But our operation may be compared to 
a large (40+kMips) octopus wherein the arms do not always work in sync.

Someone else owns the datasets and job.  At the moment they are consumed 
with bringing up two new plexes and at least one new Endeavor environment. 
 And they see others problems through their own eyes.

I agree IEBCOPY has no need to use an ENQUE - dataset allocation handles 
that.  And I remember working for a software vendor a decade ago that had 
a product that did ENQUEs in places where other products by other vendors 
(such as IBM) did not.  I think those products are not used now.

I would use an abend but that is politically incorrect when someone else 
is using (somewhat reluctantly and belatedly) one's code by edict.

What I was wondering is, does FIND support (SVC 18) save information about 
the directory (such as member last fetched and corresponding TTR) bewtwen 
accesses if the file remains open.  And is there anything I have not 
considered.

IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDUwrote on 01/19/2006 
12:52:56 PM:

In a recent note, Knutson, Sam said:

Use PDSE

The second-best idea.  Unfortunately we can't always do it because we 
share data sets beyond sysplex boundaries.  HFS/z/FS shared by NFS might 
be even better.

Use DISP=OLD either on your job or the compress

Not always practical for heavily used linklibs and parameter libraries.

Change your code to do the same enqueue used by IEBCOPY

How do I find that?  A search for ENQUEUE in:
Title: z/OS V1R7.0 DFSMSdfp Utilities Document Number: SC26-7414-03

... returns no hits.  Do the queue names and resource names involved 
require APF?

-- gil



-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom it is
addressed.  The information may also constitute a legally privileged
confidential communication.  If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying, or
unauthorized use of this information, or the taking of any action in
reliance on the contents of this information is strictly prohibited.
If you have received this communication in error, please notify us
immediately by e-mail, and delete the original message.  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: Does SMP/E APPLY REDO Replace or Merge?

2006-01-19 Thread Paul Gilmartin
On Thu, 19 Jan 2006 09:35:28 -0800, Skip Robinson [EMAIL PROTECTED] wrote:

 A customer's perspective. We recently had a problem for which IBM gave us
 an APAR test fix. A while later they rewrote the fix so that it hit a
 different MOD within the same LMOD. In that case, APPLY CHECK failed
 because the new fix attempted to SUP another sysmod but did not contain the
 same elements. For that case, SMP/E detects an error and quits. (Goodness.)
 The proper way out was to RESTORE the first fix, which removed all traces
 of it from the target zone, then APPLY the new fix. The result was clean:
 correct version of code, SMP/E happy with all relationships.

Thanks for pointing this out.  APARs IR44571 and IR46970 show that
IBM is sometimes willing to provide enhancements to protect the CSI
integrity against unwitting transgressions by providers (even
including IBM itself).  Maybe there's hope in this case.

Interesting.  We also discovered our problem when we received a
GIM32501E message.  (Hmmm.  MC says SUPERSEDE; the actual message
says SUPERCEDE.)  Feels like a SEV4 APAR to me.  I vote with MC.)
But in our case, the error was detected only the second time we
attempted to APPLY the reworked PTF; the CSI was already damaged.

I also tried John Eells's suggestion of a coverup PTF; not a new one
-- the original offender hadn't shipped yet, so I was free to
experiment with it.  By adding enough elements, I got the APPLY
REDO to work without the GIM32501E.  I then did the RESTORE and
again tried to APPLY the smaller version.  Once again, SMP/E
reported GIM32501E on some (but not all) of the MOD elements it
earlier reported.

This leaves me curious concerning the algorithm used to generate the
GIM32501E.  What condition in the CSI caused that particular message,
and was repaired for you (but not for us) when you RESTOREd the
original APAR fix.

 Although vendors are in the business of crafting PTFs, customers often
 create usermods and therefore have to deal with the same issues. It's
 valuable for everyone to understand the process. SMP/E almost always
 provides a mechanism to correct problems like this. I can't remember the
 last time we actually had to trash an entire CSI and start over.

Thanks for pointing out that the benefits of good validation by SMP/E
extend beyond ISVs.  If nothing else, by helping us to craft better
SYSMODs, IBM keeps their service center phones quieter.

-- 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: Another fine mess ...

2006-01-19 Thread Richard Pinion
Maybe you could remove the problem PDS from your JCL and add code to the ASM 
program to do a dynamic allocate of the PDS (maybe use another parmlib to hold 
the name of the PDS in case it changes in the future, thus no program changes). 
 If the dynamic allocate fails, issue the STIMER macro, wake up and try the 
dynamic allocate again.  Repeat 'x' times as necessary and if still 
unsuccessful give up.

 [EMAIL PROTECTED] 1/19/2006 2:12:15 PM 
I thank you for your consideration.  But our operation may be compared to 
a large (40+kMips) octopus wherein the arms do not always work in sync.

Someone else owns the datasets and job.  At the moment they are consumed 
with bringing up two new plexes and at least one new Endeavor environment. 
 And they see others problems through their own eyes.

I agree IEBCOPY has no need to use an ENQUE - dataset allocation handles 
that.  And I remember working for a software vendor a decade ago that had 
a product that did ENQUEs in places where other products by other vendors 
(such as IBM) did not.  I think those products are not used now.

I would use an abend but that is politically incorrect when someone else 
is using (somewhat reluctantly and belatedly) one's code by edict.

What I was wondering is, does FIND support (SVC 18) save information about 
the directory (such as member last fetched and corresponding TTR) bewtwen 
accesses if the file remains open.  And is there anything I have not 
considered.

IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDUwrote on 01/19/2006 
12:52:56 PM:

In a recent note, Knutson, Sam said:

Use PDSE

The second-best idea.  Unfortunately we can't always do it because we 
share data sets beyond sysplex boundaries.  HFS/z/FS shared by NFS might 
be even better.

Use DISP=OLD either on your job or the compress

Not always practical for heavily used linklibs and parameter libraries.

Change your code to do the same enqueue used by IEBCOPY

How do I find that?  A search for ENQUEUE in:
Title: z/OS V1R7.0 DFSMSdfp Utilities Document Number: SC26-7414-03

... returns no hits.  Do the queue names and resource names involved 
require APF?

-- gil



-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom it is
addressed.  The information may also constitute a legally privileged
confidential communication.  If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying, or
unauthorized use of this information, or the taking of any action in
reliance on the contents of this information is strictly prohibited.
If you have received this communication in error, please notify us
immediately by e-mail, and delete the original message.  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

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

2006-01-19 Thread McKown, John
 -Original Message-
 From: IBM Mainframe Discussion List 
 [mailto:[EMAIL PROTECTED] On Behalf Of Chuck Arney
 Sent: Thursday, January 19, 2006 1:03 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Auto-FTP
 
 
 Jeff is asking about a feature that is available with the VSE 
 IP stack's FTP
 offerings.  With them and the proper definitions, Auto-FTP 
 support will
 automatically FTP a report from the VSE/POWER queues to the 
 desired location
 anytime a spool entry pops up in a designated output class.  
 There is no
 additional action required by the user to make the FTP occur.
 
 Since he is the author of one of the VSE IP stacks, I suspect 
 he is thinking
 of a new opportunity.  And he may have found one since z/OS 
 TCP/IP does not
 offer this support as far as I am aware!
 
 Chuck Arney

z/OS does not come with such an animal. However, starting with z/OS 1.6,
there is a FTP Callable API. I would __think__ that using this
facility along with SAPI to retrieve JES sysouts, it would be
__relatively__ easy to implement an external writer type facility to
read JES outputs and ftp them somewhere. Or maybe even multiple
somewheres.

If security (encryption) is not an issue, I wouldn't even bother with
the above (personally). I would use the standard NPF (free with z/OS) to
send the data via the LPD protocol to an LPD server instead of an FTP
server. The LPD server would write the data to a file instead of a
printer. This should be fairly simple to do using a Linux/Intel system.

Now, neither of the two above are likely to be embraced by most
companies due to support issues. So a vendor who wrote such a product
__might__ have a market for it.

Although I know that our company wouldn't buy it (zSeries is moribund),
the thought of having an NJE type connection to submit jobs from IP
connected servers such as Linux or Windows with the return of the output
is very interesting.

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

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

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


POSIX run-time option vs TSO and Batch

2006-01-19 Thread Wendell Simmons
I have a C application that uses Unix Services and therefore has to run
with POSIX ON - logic has been added to the C program to display the
setting of the POSIX option.

This C application is invoked from a COBOL program that is linked with a
CEEUOPT module that has the POSIX option turned ON.  The COBOL program is
used in both a Batch and SPF environment.

When the COBOL program is executed in a Batch environment, everything works
OK and the C program displays that the POSIX option is ON.

When the same COBOL program is executed in the SPF environment with a
different driver module than Batch, the C program displays that the POSIX
option is OFF and I get the following message:

GSKSSL: Unable to create log mutex: EDC5167I Access to the UNIX System
Services version of the C RTL is denied

For the TSO execution, I placed a RPTOPTS(ON) in the COBOL program and it
shows that POSIX is ON but the C program says that it is OFF???

Any suggestions would be greatly appreciated since I've been struggling
with this problem for over a week.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: National ID card processing?

2006-01-19 Thread Joel C. Ewing
Why on earth do you persist in asking for specifics about an 
implementation that hasn't been authorized by, or even formally proposed 
to, Congress?


Unless funds are appropriated to study implementing such a system, it 
would be inappropriate for federal employees to spend working hours 
analyzing the requirements for implementation, given past reluctance of 
Congress to approve any National ID system.  With no specifics on what 
data would be included in such a system, or who would have access, or 
what its intended use would be, it is simply impossible to hold any 
rational discussion about implementation details.


Attempts to supply any implementation detail at this point for a 
hypothetical system with unknown requirements would be worthless 
speculation.  In the remote event that such a proposal were passed by 
Congress, implementation decisions ultimately depend on who the 
Executive Branch places in charge.


If implementation decisions were to be made by someone with a legitimate 
computer-science / computer-security expertise, one would expect a 
choice of hardware, operating system, and application implementation 
techniques appropriate to the sensitivity of the data, the volume of the 
data, and the access requirements involved.


If decisions were made by a FEMA qualified Bush appointee whose sole 
talent is ideological loyalty, then we shouldn't be surprised by an 
implementation on a network of MS Windows platforms, infested by spy 
ware and viruses, and with no regular backups or any provision for 
recovery from hardware failures.


as400 wrote:

As a part of data storage, are the ID cards going to be processed from
a system running either a VAX cluster, MVS, z/OS, Solaris, AIX...etc??

Thanks




--
Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED]

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


Re: National ID card processing?

2006-01-19 Thread Pommier, Rex R.
I know this has been mentioned before, but why is as400 so insistent
on finding out information on how government systems, both real and -
like below - possibilities?  What do his questions have to do with the
purpose of this list?

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Joel C. Ewing
Sent: Thursday, January 19, 2006 1:32 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: National ID card processing?


Why on earth do you persist in asking for specifics about an 
implementation that hasn't been authorized by, or even formally proposed

to, Congress?

Unless funds are appropriated to study implementing such a system, it 
would be inappropriate for federal employees to spend working hours 
analyzing the requirements for implementation, given past reluctance of 
Congress to approve any National ID system.  With no specifics on what 
data would be included in such a system, or who would have access, or 
what its intended use would be, it is simply impossible to hold any 
rational discussion about implementation details.

Attempts to supply any implementation detail at this point for a 
hypothetical system with unknown requirements would be worthless 
speculation.  In the remote event that such a proposal were passed by 
Congress, implementation decisions ultimately depend on who the 
Executive Branch places in charge.

If implementation decisions were to be made by someone with a legitimate

computer-science / computer-security expertise, one would expect a 
choice of hardware, operating system, and application implementation 
techniques appropriate to the sensitivity of the data, the volume of the

data, and the access requirements involved.

If decisions were made by a FEMA qualified Bush appointee whose sole 
talent is ideological loyalty, then we shouldn't be surprised by an 
implementation on a network of MS Windows platforms, infested by spy 
ware and viruses, and with no regular backups or any provision for 
recovery from hardware failures.

as400 wrote:
 As a part of data storage, are the ID cards going to be processed from

 a system running either a VAX cluster, MVS, z/OS, Solaris, AIX...etc??
 
 Thanks
 


-- 
Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED]

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

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


Re: National ID card processing?

2006-01-19 Thread Chase, John
 -Original Message-
 From: IBM Mainframe Discussion List On Behalf Of Joel C. Ewing
 
 Why on earth do you persist in asking for specifics about an 
 implementation that hasn't been authorized by, or even 
 formally proposed to, Congress?

There is a *de facto* National ID card known as the Social Security
card, which states on its face, Not for identification.

There is also the passport, but possession of a passport is far less
mandatory than possession of a Social Security card.  Indeed, some
holders of Social Security cards are not eligible to hold passports.

It's easy enough to impute ill intent based on the formulation of the
queries posted

-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: National ID card processing?

2006-01-19 Thread Hal Merritt
Have not seen the original posts, but the OP could be talking about an
ID system that *is* being developed and deployed nationwide under the US
DHD. 

The first generation of these ID's were mag stripe, but are to be
replaced by 'smart cards'. 

The system is a way to identify trained emergency responders across
local, state, and federal jurisdictions. For example, a responder
trained and certified in Texas can respond to an emergency in Louisiana.
Otherwise, Louisiana authorities have no way of knowing if the person is
properly trained or just somebody that thinks they can help. 

Part of the information is exactly what skills the person has to offer.
All professional and volunteer emergency responders nation wide are
supposed to have one eventually. 

Being an untrained, ill prepared, would be 'rescuer' is a leading cause
of death or injury in large emergencies. And a huge headache to local
authorities trying to cope with a massive disaster. 

HTH. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Joel C. Ewing
Sent: Thursday, January 19, 2006 1:32 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: National ID card processing?

Why on earth do you persist in asking for specifics about an 
implementation that hasn't been authorized by, or even formally proposed

to, Congress?

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: IPCS Standard Print Service

2006-01-19 Thread Robert Wright
Todd Burch wrote on 01/16/2006 03:09:36 PM:

 Here is perhaps the smallest verb exit I've ever written to demonstrate
the
 blank lines at the top of the IPCS print dataset.  There are three blank
 lines at the top.  How do I access these?  When I write a REXX routine
that
 call the NOTE command, these blank lines do not exist in the print
 dataset.

 Assemble, linkedit, place in a library in your available TSO load libs,
and
 issue verbx miniverb from IPCS option 6.

 snip

I ran the requested experiment and got basically what I expected in the
RECFM=VBA data set.  The following was cut and pasted from ISPF browse
afterward - after turning on its display of control characters:

 1COMPON=REAL STORAGE MANAGEMENT,C
 +
 0WHY DOES THIS SHOW UP ON LINE 4?

The first line of output from MINIVERB should appear on line 3, following
an underscored title line on line 1 and a blank line 2.

You've been using the term print dataset which is what I've been
addressing, but your script would cause MINIVERB output to be sent to the
terminal as a destination unless you added print noterm as options like I
did.  There I do see 3 blank lines preceding the first one produced by
MINIVERB.  That's a consequence of PRDMP compatibility as well as some TSO
terminal output stream considerations.

o  PRDMP started the output from all verbs on a new page, but it didn't get
around to supporting ADPLEJEC until its final years.  ADPLEJEC is the bit
that says eject.  Old PRDMP exits put out between 60 and 90 blank lines to
cause the current page to overflow as a means to get to the top of the next
page.

o  The TSO output stream has no sense of pagination since it originally was
written to continuous forms fed through hardcopy terminals like 2741s.

IPCS's terminal support tries to make sense of all this by limiting the
number of consecutive blank lines that it actually honors and, conversely,
by slipping in some (3) blank lines when something nonblank shows up in the
output stream.
So the 3 blank lines that you see in your terminal output are the
consequence of the VERBEXIT subcommand putting out one blank line with a
page eject indication before giving control to the exit.

Now for some good news since you don't seem fond of the blank lines.  There
is a NOTOC option on VERBEXIT that suppresses several inherited behaviors
related to invoking verb exits, and one of those behaviors is forcing a new
page.  If you change your invocation to verbx miniverb notoc, you'll have
your output start on the first line.  (If you say note 'hi' page, you'll
get the 3 blank lines before HI.)

Bob Wright - MVS Service Aids

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


Re: National ID card processing?

2006-01-19 Thread Imbriale, Donald (Exchange)
I agree.  Sounds like a troll or someone doing school assignments
looking for a quick answer.

Don Imbriale

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
Of Pommier, Rex R.
Sent: Thursday, January 19, 2006 2:36 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: National ID card processing?

I know this has been mentioned before, but why is as400 so insistent
on finding out information on how government systems, both real and -
like below - possibilities?  What do his questions have to do with the
purpose of this list?

Rex


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


Max Region and IEFUSI mystery

2006-01-19 Thread Martin, Mike
Hi all,

We have an IEFUSI that basically hard codes a region of 64M.

...
MVC   REGSIZA,REG64MB SET REGION SIZE ABOVE TO 64MB 
MVC   REGLIMA,REG64MB SET REGION LIMIT ABOVE TO 64MB

...
REG64MB  DCF'67108864' REGION SIZE OF 64MB
...
REGLIMA  DSF   REGION LIMIT ABOVE 16MB  
REGSIZA  DSF   REGION SIZE ABOVE 16MB   

But one of our monitors shows a few of our CICS regions have more than
64M!!

I issued a dump for one of these regions and I can see ELIM of 580
(90M?).   Where did that come from?!  Where should I look?  (To my
knowledge, we don't have any other exits involved)

Region Requested = 200 
IEFUSI/SMF Specification = SMFL :  201  SMFEL:  400
SMFR :  200  SMFER:  400
Actual Limit = LIMIT:   9FA000  ELIM :  580


FONT SIZE=1 FACE=ARIAL^
This email may contain confidential and privileged material for the sole use of 
the intended recipient. If you are not the intended recipient, please contact 
the sender and delete all copies. Any review or distribution by others is 
strictly prohibited. Personal emails are restricted by policy of the State 
Employees' Credit Union (SECU). Therefore SECU specifically disclaims any 
responsibility or liability for any personal information or opinions of the 
author expressed in this email.


/FONT


--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Billing for SRB Time

2006-01-19 Thread Ted MacNEIL
The I/O interrupt issue has me wondering though -- are folks claiming that
a zAAP cannot process paging I/O for itself?

A page IO is not necessarily required to be processed on the CP/LP that has the 
page-faulting task running on it.


-teD
Me? A skeptic? I trust you have proof!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: National ID card processing?

2006-01-19 Thread Ed Finnell
 
In a message dated 1/19/2006 2:01:53 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Perhaps  we should report him to Homeland Security as someone asking
sensitive  questions about our nation's technical  infrastructure?




Send him to Hindu Kush as forward observer.

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

2006-01-19 Thread Arturo Juarez
On Thu, 19 Jan 2006 12:59:54 -0500, Jeffrey Barnard [EMAIL PROTECTED] wrote:

Does z/OS have a way to automatically FTP reports from JES to a
destination host?

Thanks.

Regards,
Jeff


Hi Jeff,

Well FTP has a direct interface with JES2, you can submit a job and receive
the output of that particular job using FTP, but that has to be done manualy
or using a scheduler product. i recomend you to take a look on Chapter 4.
Transferring data using the File Transfer Protocol (FTP) from the z/OS
V1R4.0 CS: IP User’s Guide and Commands.

With the information there you can figure out all the possible combinations
that you can do to meet your requirement. Whitouth the scheduler the job
that you submit manually will perform an FTP connection, submit the job that
generates the report and get the output to a particular host.

Regards.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Does SMP/E APPLY REDO Replace or Merge?

2006-01-19 Thread Skip Robinson
The suggestion to create a new super-PTF that tries to straighten
everything out should work (in principle) mechanically, but as a vendor I
would studiously avoid that sort of kludge because it enshrines a
developer's experimental efforts in a sysmod. We all try various things
that don't work. No use turning a PTF into a trial-and-error blog. ;-)

On the other hand, if the earlier PTF(s) had actually been shipped to and
installed by customers, then a super-PTF would be need to get them kosher
again.

That 'super-seed' word, by the way, seems to go either way according to my
Random House Unabridged. Should be a gimme in a spelling bee...

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

IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 01/19/2006
11:21:48 AM:

 On Thu, 19 Jan 2006 09:35:28 -0800, Skip Robinson JO.Skip.
 [EMAIL PROTECTED] wrote:
 
snip

 Interesting.  We also discovered our problem when we received a
 GIM32501E message.  (Hmmm.  MC says SUPERSEDE; the actual message
 says SUPERCEDE.)  Feels like a SEV4 APAR to me.  I vote with MC.)
 But in our case, the error was detected only the second time we
 attempted to APPLY the reworked PTF; the CSI was already damaged.

 I also tried John Eells's suggestion of a coverup PTF; not a new one
 -- the original offender hadn't shipped yet, so I was free to
 experiment with it.  By adding enough elements, I got the APPLY
 REDO to work without the GIM32501E.  I then did the RESTORE and
 again tried to APPLY the smaller version.  Once again, SMP/E
 reported GIM32501E on some (but not all) of the MOD elements it
 earlier reported.

snip

 -- gil

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


Re: Does SMP/E APPLY REDO Replace or Merge?

2006-01-19 Thread Ed Finnell
 
In a message dated 1/19/2006 3:34:51 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

On the  other hand, if the earlier PTF(s) had actually been shipped to  and
installed by customers, then a super-PTF would be need to get them  kosher
again.




Yeah, yeah but isn't it packaging of the first part where just about every  
LKED starts with INCLUDE modname so you gets the merge 
regardless?

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

2006-01-19 Thread Ed Finnell
 
In a message dated 1/19/2006 1:25:45 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

Although  I know that our company wouldn't buy it (zSeries is moribund),
the thought  of having an NJE type connection to submit jobs from IP
connected servers  such as Linux or Windows with the return of the output
is very  interesting.




The folks at Lead Tools are pretty up to speed already. Their little ePrint  
server is Linux based and can slice and dice print just about anyway you need  
it.
 
_http://www.leadtools.com/_ (http://www.leadtools.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: Billing for SRB Time

2006-01-19 Thread Tom Schmidt
On Thu, 19 Jan 2006 00:00:00 GMT, Ted MacNEIL wrote:

The I/O interrupt issue has me wondering though -- are folks claiming that
a zAAP cannot process paging I/O for itself?

A page IO is not necessarily required to be processed on the CP/LP that
has the page-faulting task running on it.

Yes, I'm aware of that.  The question is: can it?

--
Tom Schmidt
Madison, WI

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

2006-01-19 Thread Ted MacNEIL
(zSeries is moribund)

BSBB!

I don't know where you stand, but I have senior management coming to me and 
trying to offload.
There has not been a single case where they could justify it.

The DINOMYTH is just that! A myth.

We have found that the cost per fanny is still lower in the M/F arena.

We have over a 100 servers that peak at 15% utilisation.

We have a few mainframe that reach lows of 95%.

I was on a problem call a couple of weeks ago.
The *NIX admin complained that he had never had a server run so 'hot'.
It was running at 26%.
Fortunately, I was on mute!


-teD
Me? A skeptic? I trust you have proof!

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

2006-01-19 Thread McKown, John
 -Original Message-
 From: IBM Mainframe Discussion List 
 [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL
 Sent: Wednesday, January 18, 2006 6:00 PM
 To: IBM-MAIN@BAMA.UA.EDU
 Subject: Re: Auto-FTP
 
 
 (zSeries is moribund)
 
 BSBB!
 
 I don't know where you stand, but I have senior management 
 coming to me and trying to offload.
 There has not been a single case where they could justify it.
 
 The DINOMYTH is just that! A myth.
 
 We have found that the cost per fanny is still lower in the M/F arena.
 
 We have over a 100 servers that peak at 15% utilisation.
 
 We have a few mainframe that reach lows of 95%.
 
 I was on a problem call a couple of weeks ago.
 The *NIX admin complained that he had never had a server run so 'hot'.
 It was running at 26%.
 Fortunately, I was on mute!
 
 
 -teD
 Me? A skeptic? I trust you have proof!

I agree. However the mantra here is Perception is Reality. Our
management perceives the zSeries as over priced, under powered (for the
price), obsolete technology that is not worth even attempting to
upgrade. We are 100% VSAM. We have an Oracle Enterprise license which
I was told means we could put Oracle on the z/OS system for no added
cost. The person in charge of the database group basically said Forget
it. Not going to do it. Go away. Of course, some may say that is good
because they dislike Oracle. But it is also bad because the same person
is adamantly anti-DB2. Actually, he only likes MS SQL Server because it
is from his favorite open system vendor.

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

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

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


Re: IPCS Standard Print Service

2006-01-19 Thread Todd Burch
Bob, thanks a bunch for taking the time to spell it out for me.   Yes, I was
saying print dataset while meaning terminal output.

OK, so the NOTOC option will fix it.  Fantastic!

Bob, if you ever get near Katy, Texas (Houston), I'll buy you lunch, or
dinner - your choice!  Same thing if I ever make it up to POK or wherever it
is that you call home.

Todd

- Original Message - 
From: Robert Wright [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Thursday, January 19, 2006 2:10 PM
Subject: Re: IPCS Standard Print Service



 I ran the requested experiment and got basically what I expected in the
 RECFM=VBA data set.  The following was cut and pasted from ISPF browse
 afterward - after turning on its display of control characters:

  1COMPON=REAL STORAGE MANAGEMENT,C
  +
  0WHY DOES THIS SHOW UP ON LINE 4?

 The first line of output from MINIVERB should appear on line 3, following
 an underscored title line on line 1 and a blank line 2.

 You've been using the term print dataset which is what I've been
 addressing, but your script would cause MINIVERB output to be sent to the
 terminal as a destination unless you added print noterm as options like
I
 did.  There I do see 3 blank lines preceding the first one produced by
 MINIVERB.  That's a consequence of PRDMP compatibility as well as some TSO
 terminal output stream considerations.

 o  PRDMP started the output from all verbs on a new page, but it didn't
get
 around to supporting ADPLEJEC until its final years.  ADPLEJEC is the bit
 that says eject.  Old PRDMP exits put out between 60 and 90 blank lines to
 cause the current page to overflow as a means to get to the top of the
next
 page.

 o  The TSO output stream has no sense of pagination since it originally
was
 written to continuous forms fed through hardcopy terminals like 2741s.

 IPCS's terminal support tries to make sense of all this by limiting the
 number of consecutive blank lines that it actually honors and, conversely,
 by slipping in some (3) blank lines when something nonblank shows up in
the
 output stream.
 So the 3 blank lines that you see in your terminal output are the
 consequence of the VERBEXIT subcommand putting out one blank line with a
 page eject indication before giving control to the exit.

 Now for some good news since you don't seem fond of the blank lines.
There
 is a NOTOC option on VERBEXIT that suppresses several inherited behaviors
 related to invoking verb exits, and one of those behaviors is forcing a
new
 page.  If you change your invocation to verbx miniverb notoc, you'll
have
 your output start on the first line.  (If you say note 'hi' page, you'll
 get the 3 blank lines before HI.)

 Bob Wright - MVS Service Aids

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


Re: Auto-FTP

2006-01-19 Thread Ted MacNEIL
Our management perceives the zSeries as over priced

I still get comments like that from my boss and my VP of IT Operations.
So, I optimise and I point out the TCO.

The problem with the mainframe price model is the up-front costs.
We KNOW what it costs.

The problem with the other platforms is the hidden costs.
We don't know what it truly costs.

If we did a true (forensic) audit of costs, we would see that the $/butt is 
smaller in the M/F arena!


-teD
Me? A skeptic? I trust you have proof!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Billing for SRB Time

2006-01-19 Thread Edward E. Jaffe

Tom Schmidt wrote:

Yes, I'm aware of that.  The question is: can it?
  


zAAPs look (essentially) just like any other processor to z/OS. They 
have PCCA/LCCA like any other processor and are differentiated from GCPs 
by testing the PCCAIFA flag.


Anyway, a quick look at PCCACRG6 for a zAAP would go a long way toward 
answering these kinds of questions empirically. In addition, I suspect 
you could look at the zAAP LCCAs to see some various other control 
registers of interest saved at various times...


--
-
| 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: Auto-FTP

2006-01-19 Thread Jeffrey Barnard

Ed Finnell wrote:
 
In a message dated 1/19/2006 1:25:45 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:


Although  I know that our company wouldn't buy it (zSeries is moribund),
the thought  of having an NJE type connection to submit jobs from IP
connected servers  such as Linux or Windows with the return of the output
is very  interesting.


Actually, we already an NJE/IP Bridge product that provides NJE over 
TCP/IP support for MVS, OS/390, z/OS JES2/JES3. Heck, NJE/IP Bridge will 
even turn any PC into an NJE node using TCP/IP to talk to z/OS, z/VM, 
Linux on zSeries or other PC's. And that is an option for this customer 
but they wanted to know about a facility for automatically FTPing the 
reports first.


Thanks for the feedback everyone. Sounds like a simple REXX EXEC could 
scan the JES queue for a specific class, generate JCL and submit the 
batch FTP job to process the entry.


Regards,
Jeff


--
Jeffrey C Barnard
Barnard Software, Inc. http://www.bsiopti.com
Phone 407-323-4773 Fax 407-323-4775

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

2006-01-19 Thread Shmuel Metz (Seymour J.)
In [EMAIL PROTECTED],
on 01/19/2006
   at 12:36 PM, Knutson, Sam [EMAIL PROTECTED] said:

Change your code to do the same enqueue used by IEBCOPY

What ENQ? AFAIK it doesn't issue one.
 
-- 
 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: Billing for SRB Time

2006-01-19 Thread Shmuel Metz (Seymour J.)
In
[EMAIL PROTECTED],
on 01/19/2006
   at 10:54 AM, Craddock, Chris [EMAIL PROTECTED] said:

There is a separate (not externally documented) signaling protocol to
get work fired up on a zAAP.

Are you sure it's not a normal shoulder tap?
 
-- 
 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: Billing for SRB Time

2006-01-19 Thread Shmuel Metz (Seymour J.)
In [EMAIL PROTECTED], on 01/19/2006
   at 12:40 PM, Tom Schmidt [EMAIL PROTECTED] said:

The I/O interrupt issue has me wondering though -- are folks claiming
that a zAAP cannot process paging I/O for itself?  Surely the JVM is
not page-fixed in storage, is it? 

Surely it does not need to do its own I/O. Presumably the zAAP is as
capable of issuing a shoulder tap as any other processor.
 
-- 
 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: Does DDNAME?? override SUBSYS??

2006-01-19 Thread Shmuel Metz (Seymour J.)
In [EMAIL PROTECTED], on 01/18/2006
   at 11:53 PM, Paul Gilmartin [EMAIL PROTECTED] said:

WTF SJF? 

Scheduler JCL Facility was introduced in MVS/SP 1.3 to support the
OUTPUT statement. It allowed adding new JCL statements and new
keywords on existing statements.

I have heard tales that the JCL C/I is FUBAR (Beyond Ability to 
Repair), and development is afraid to replace or significantly 
modify it. 

I'm not sure that I believe it. certainly the code in the old R/I was
cleaner than, e.g., the Initiator. Take IEFZGST1 and IEFZGST2 -
please!
 
-- 
 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: Does SMP/E APPLY REDO Replace or Merge?

2006-01-19 Thread Shmuel Metz (Seymour J.)
In [EMAIL PROTECTED], on 01/18/2006
   at 11:28 PM, Paul Gilmartin [EMAIL PROTECTED] said:

Suppose I build a PTF and APPLY it.  I have second thoughts, and
rebuild it with a considerably different set of elements from the
original; RECEIVE; and APPLY REDO.  Is the result the same as if the
earlier version had never existed and only the later were APPLYed, or
is it some sort of merging of the two different versions?

No. The result is instant seppukko.

Recent unpleasant experience suggests that it merges rather than
replaces:

It replaces what is in the new PTF. It does not RESTORE elements
affected by the old PTF.

How do I undo this mess?

A new PTF, listing the old one in SUP and containing the correct level
of every element replaced by either.

This surely provokes a wishlist item:  If I attempt APPLY REDO, and
there are elements in the target zone with the RMID of the PTF, but
not in the PTF itself, SMP/E should report an error and fail the
APPLY.

That sounds reasonable; have you submitted 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: IPCS Standard Print Service

2006-01-19 Thread Shmuel Metz (Seymour J.)
In
[EMAIL PROTECTED],
on 01/19/2006
   at 03:10 PM, Robert Wright [EMAIL PROTECTED] said:

o  The TSO output stream has no sense of pagination since it
originally was written to continuous forms fed through hardcopy
terminals like 2741s.

I never saw continuous forms on a 2741, only perforated.
 
-- 
 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: REXX Problem

2006-01-19 Thread Shmuel Metz (Seymour J.)
In [EMAIL PROTECTED],
on 01/19/2006
   at 02:58 AM, Rob Scott [EMAIL PROTECTED] said:

Earlier in this thread you criticized the practice of using address
env buffer each time as being inefficient.

Not that I recall; I criticized doing *both* and address env *and*
doing address  env buffer as inefficient.

I think you are nitpicking here

One man's nit is another man's ABEND.

perhaps I should have used address
statement execution instead of call

But the reference to PUSH/POP would still have been incorrect.

The PUSH/POP method is used to maintain the address environment
between executions of the address env buffer statement.

What PUSH/POP method and why do you need to maintain an environment
that doesn't change?

I can appreciate that some coding techniques appeal to some whilst
not to others - if this is just such a case then so be it and we can
each agree to stick with our own gods.

As long as I don't inherit it,  I don't mind how cluttered your code
gets.
 
-- 
 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: Another fine mess ...

2006-01-19 Thread Edward E. Jaffe

Shmuel Metz (Seymour J.) wrote:

In [EMAIL PROTECTED],
on 01/19/2006
   at 12:36 PM, Knutson, Sam [EMAIL PROTECTED] said:

  

Change your code to do the same enqueue used by IEBCOPY



What ENQ? AFAIK it doesn't issue one.
  


Probably meant the binder ...

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


IBM High Level Assembler for Linux on zSeries

2006-01-19 Thread John R. Ehrman
IBM recently announced the availability of HLASM for Linux on
zSeries, as PRPQ 5799-TCQ. It is fully compatible with HLASM
on the current MVS, CMS, and VSE operating systems, and can
generate the ELF object format as well as the traditional OBJ
and GOFF formats.

John Ehrman (ehrmanATvnet.ibm.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: TN3270 Question

2006-01-19 Thread Chris Mason
Pat,

You're right - in principle. CS IP developers are also right - but
unimaginative.

RFC 2355 asserts that there are two types of TN3270E server logic: One where
the SSCP-LU session is available and USS commands and messages can be
passed through and one where there is no access to the SSCP-LU session.

The SSCP-LU session is available where the TN3270E server logic is supported
on an SNA Type 2.1 or 2.0 node with SSCP-dependent PU and LUs. This is what
you call the outboard emulator.

I wonder what was in the mind of the RFC writer when he specified the
other type of TN3270E server logic which does not have access to the
SSCP-LU session, probably a server as a VTAM application but he doesn't say
so.

But, but, but a VTAM application can access SSCP-LU functions for session
termination through the TERMSESS macro. What it cannot do is define itself
to VTAM as being able to send USS commands to the SSCP and receive USS
messages.

RFC 2355 does not envisage the TN3270E server logic supporting a USS table
in the same way that VTAM does but the CS IP TN3270E server logic does this
for LOGON support.

Combining TERMSESS capability and USS table support, the same USS service
can be offered to a TN3270E client as TN3270E server logic with USS
passthrough capability does also for LOGOFF support. This would incidentally
necessarily include support for USS messages - including the famous USS
message 5.

Protocols are all about appearances. The CS IP TELNET server is not a Type
2.0 or 2.1 node with USS passthrough support but it can behave to the client
as if it was - and does so already for LOGON support. My proposal is that
the CS IP TELNET server should behave as if it was also for LOGOFF support.

Note the benefit of having potentially the same behaviour at the TN3270E
client whether the server has USS passthrough support (where the USS table
in VTAM is used) or the server is pretending to have USS passthrough support
(where the USS table in CS IP TN3270E server logic is used).

To my mind the point about not following the RFC is irrelevant since the CS
IP TN3270E server logic would be claiming USS passthrough capability as
defined in the RFC rather than the lack of USS capability. We can forget
about these poor implementations of TN3270E which can't play USS and the
TN3270E clients need never encounter such a poor server.

The RFC is actually wrong is specifying the two types so rigidly. It ought
to distinguish between TN3270E server implementations which can support USS
no matter how and those which cannot. (Perhaps I can send in a comment on
these lines.) The CS IP TN3270E server logic is currently behaving as the
former for LOGON support but behaving as the latter for LOGOFF support. This
is obviously not consistent although I appreciate the RFC only worries about
this capability issue in connection with LOGOFF support.

A minor point, having now read the RFC - again, is that the CS IP TN3270E
server logic does not follow the RFC in its implementation of the lack of
USS capability LOGOFF support since the sequence is that used by VTAM
non-SNA 3270 support rather than that defined by the RFC.

Finally I should mention 'ibmtest. Back in 1969 when I participated in the
UK On-line Diagnostics project the need was felt for a means to run basic
tests to exercise the teleprocessing devices. In those days that meant
1050s and 2740s and the like. Since a component of these devices was the
typewriter printer, there was a need to invoke test printouts. The project
was aimed at being able to enter the test mode without the knowledge of the
BTAM application program driving the device, then running the tests and
finally returning control to the multiple wait within the BTAM program.
When VTAM/SNA came along there was still one direct descendant of those
devices, namely the 3767. I have always taken account of the ibmtest USS
function when teaching USS but I've never seen too much of a use for it with
3270 devices. Perhaps it was created only to be a test facility for the
3767 - and maybe the 3770 series of SNA devices which could claim to be a
descendant of the dearly remembered 1050 system. Anyhow I'm not going to
insist on ibmtest support with TN3270E server logic.

Chris Mason

- Original Message - 
From: Patrick O'Keefe [EMAIL PROTECTED]
Newsgroups: bit.listserv.ibm-main
To: IBM-MAIN@BAMA.UA.EDU
Sent: Wednesday, 18 January, 2006 9:55 PM
Subject: Re: TN3270 Question


 On Mon, 16 Jan 2006 16:16:40 +0100, Chris Mason [EMAIL PROTECTED]
 wrote:

 ...
 Once you do find the SysRq key, you can enter logoff without the
 quotation
 marks* and VTAM, performing its SSCP role, will terminate the session
 between the application and the TELNET logical unit (LU) managed by the
 TELNET 3270 server. Ideally you could have the possibility to determine
 the
 degree of prejudice you apply to the session termination request by
 specifying  whether the application is to be asked politely, TYPE(COND) -
 COND for conditional, 

Re: Billing for SRB Time

2006-01-19 Thread Tom Schmidt
On Thu, 19 Jan 2006 18:06:09 -0500, Shmuel Metz (Seymour J.) wrote:

On 01/19/2006 at 12:40 PM, I said:

The I/O interrupt issue has me wondering though -- are folks claiming
that a zAAP cannot process paging I/O for itself?  Surely the JVM is
not page-fixed in storage, is it?

Surely it does not need to do its own I/O. Presumably the zAAP is as
capable of issuing a shoulder tap as any other processor.


The zAAP may not have a need to use the 360-MP shoulder tap technique to
start I/Os or to field I/O interrupts. (I haven't found an appropriate
dump yet - I have other things to do now.)  But I wouldn't actually
suspect it uses that antique technique since (a) zAAPs are limited to
processors using PR/SM and (b) Chris, whom I trust, said they don't use
it.  PR/SM definitely treats the zAAPs special so there may well be sneaky
hipervisor techniques used to signal the processors... especially if the
processors needing to be signalled are cross-book, for example.

I haven't even established whether zAAPs run enabled or disabled for I/O
interrupts yet... if they ran disabled for I/O they would, of course, run
a lot faster.  (I know that I work a lot faster when I'm disabled for
interrupts.)  Up until they needed to be fed more data; then... not so
much faster.  The JVMs that run on them certainly have huge working sets
so they maybe just suck it all into storage via the general CPs before
they duck under the zAAP cloak to do the 'deep computing' and then pop
back from Narnia with the answers to life, the universe  everything.  I'd
be surprised with that outcome but it is, after all, less weird than the
things that Orvyl did decades ago at Stanford.  (Yes, I know, Orvyl did
I/O, but it mostly did its own I/O and pretty much ignored the MVS I/O
until it was good  ready to give control back to MVS.)

Its on my list of things to learn (after I get done with more things to
learn about CICS file control which I'm waist-deep in this month 
next).

--
Tom Schmidt
Madison, WI
(All of the zAAP stuff seems like a shameful waste of creative programming
by Greg D.  Co. just to keep the ISVs from draining the customer base
dry.)

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

2006-01-19 Thread John S. Giltner, Jr.

McKown, John wrote:
 Begin Snip --

 End Snip --

 Actually, he only likes MS SQL Server because it
is from his favorite open system vendor.

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



Of couse its open, it allows any and all viruses/worms/trojans in.  How 
much more open do you want 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: Billing for SRB Time

2006-01-19 Thread Craddock, Chris
 The zAAP may not have a need to use the 360-MP shoulder tap
technique to
 start I/Os or to field I/O interrupts. (I haven't found an appropriate
 dump yet - I have other things to do now.)  But I wouldn't actually
 suspect it uses that antique technique since (a) zAAPs are limited to
 processors using PR/SM and (b) Chris, whom I trust, said they don't
use
 it.  PR/SM definitely treats the zAAPs special so there may well be
sneaky
 hipervisor techniques used to signal the processors... especially if
the
 processors needing to be signalled are cross-book, for example.

Thanks for the vote of confidence Tom, but I don't think that's really
what I said. I don't know exactly how dispatching is done on the zAAP.
From conversations with BCP folks and knowing a bit about the innards of
the OS, I can speculate how it might be done, but that's all. To the
best of my knowledge the actual workings are undisclosed. 

 I haven't even established whether zAAPs run enabled or disabled for
I/O
 interrupts yet... if they ran disabled for I/O they would, of course,
run
 a lot faster.

I have not actually looked at a zAAP to be sure, but I am almost certain
they do run disabled for interrupts. That isn't so odd, since most of
the engines in a multi-engine LPAR are actually disabled for interrupts
most of the time. 

Think CPENABLE. What's actually going on under the covers in that case
is that the OS disables interrupts via the control register, so the
state of the I/O interrupt mask in the PSW is irrelevant. The PSW mask
has to be and-ed with the control register, so no interrupts are
actually seen by that engine, even though it nominally appears to be
enabled for interrupts.

The system selectively enables more engines for fielding I/O interrupts
based on the number of interrupts handled via TPI. It's a throughput
versus responsiveness trade-off. 

Given the limitations of zAAPs there would be no reason to enable one
for I/O interrupts. 

 (All of the zAAP stuff seems like a shameful waste of creative
programming
 by Greg D.  Co. just to keep the ISVs from draining the customer base
 dry.)

Pretty much. Greg, Peter Relson and others burned a lot of cycles doing
it. My question at the time was... couldn't you just have implemented
separate accounting fields for JVM work? Apparently lawyers were
involved in making that decision, so this is what we get for allowing
lawyers to dictate system design. 

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: Auto-FTP

2006-01-19 Thread Ed Gould

On Jan 19, 2006, at 12:00 AM, Ted MacNEIL wrote:


(zSeries is moribund)


BSBB!



Well, if zSeries is then TSO is deader than a doornail:)

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


What does XL of XL C/C++ mean?

2006-01-19 Thread Bo Xie
Hi all,

As of z/OS V1R7, the z/OS C/C++ compiler has been rebranded to z/OS XL
C/C++. What does XL of XL C/C++ mean?

Thank you for your time!

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: Two silly questions about USS or OMVS on Z/OS

2006-01-19 Thread Hunkeler Peter (KRDO 4)
The command response in the text of your email was 
very hard to read, no doubt due to some translations 
(code page?) along the way. There were two characters 
that did not display correctly on my PC.  

I have to wonder if that is somehow connected???

It sure is! As I have tried to explain earlier, Josef is
running his emulator with a German code page (273 or 1141)
but his shell session is running in the default locale 
which means it is using code page 1047.

The error message is coded to send square brackets
and these are encoded in code page 1047, i.e. X'AD'
and x'BD'. If those characters are the displayed
in the emulator using code page 1141 they show up
as Ý and ¨.

Let's put the blame on Windows. ;-) 
While I usually agree, it is not involved this time ;-)


BTW, I'm talking about z/OS UNIX not about z/OS MVS. The
latter is much less multicultural. MVS commands expect
text to be encoded in code page 037, so does TSO. 
Fortunately both MVS commands and TSO are only using
characters that are code page invariant. (I never dealt
with a Kanji MVS, so I can't tell how this works.)

REXX is always expecting its code to be in code page 
037 (here we go again: German code page users need to 
use the exclamation point when REXX actually wants a 
verical bar.) This applies also to REXX scripts run 
from a shell session.

ISPF is somewhat customizable (Don't ask me details,
I never fully got it).

This list is not exhaustive.


Peter Hunkeler
CREDIT SUISSE

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

2006-01-19 Thread Vernooy, C.P. - SPLXM
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]...
 I thank you for your consideration.  But our operation may be compared to  a 
 large (40+kMips) octopus wherein the arms do not always work in sync.
 
 Someone else owns the datasets and job.  At the moment they are consumed  
 with bringing up two new plexes and at least one new Endeavor environment. 
  And they see others problems through their own eyes.
 
 I agree IEBCOPY has no need to use an ENQUE - dataset allocation handles  
 that.  And I remember working for a software vendor a decade ago that had 
 a product that did ENQUEs in places where other products by other vendors  
 (such as IBM) did not.  I think those products are not used now.
 
 I would use an abend but that is politically incorrect when someone else  is 
 using (somewhat reluctantly and belatedly) one's code by edict.
 
 What I was wondering is, does FIND support (SVC 18) save information about 
 the directory (such as member last fetched and corresponding TTR) bewtwen  
 accesses if the file remains open.  And is there anything I have not 
 considered.
 
 IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDUwrote on 01/19/2006  
 12:52:56 PM:
 
 In a recent note, Knutson, Sam said:
 
 Use PDSE
 
 The second-best idea.  Unfortunately we can't always do it because we 
 share data sets beyond sysplex boundaries.  HFS/z/FS shared by NFS might  be 
 even better.
 
 Use DISP=OLD either on your job or the compress
 
 Not always practical for heavily used linklibs and parameter libraries.
 
 Change your code to do the same enqueue used by IEBCOPY
 
 How do I find that?  A search for ENQUEUE in:
 Title: z/OS V1R7.0 DFSMSdfp Utilities Document Number: SC26-7414-03
 
 ... returns no hits.  Do the queue names and resource names involved 
 require APF?
 
 -- gil
 

Another possible solution is to eliminate (more or less) the compress. Make it 
10 times its current size and try to find a quiet moment to compress the 
dataset, e.g. in the weekend.

A next solution is to bring it under PDSMAN Space Reuse control. This gives you 
automatic compress like PDSE, without the PDSE restrictions.

To clear my confusion: Gil, are you rkuebbin?

Kees.


**
For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), 
its subsidiaries and/or its employees shall not be liable for the incorrect or 
incomplete transmission of this e-mail or any attachments, nor responsible for 
any delay in receipt.
**

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