Re: SMP/E 3.4 - IBM Order Server Performance

[Shane Ginnane]

Mmmm - might the whole service delivery organization.
I just ordered a single PTF (plus requisites) via SRD for delivery via 
INET. Shipped notification came in  in no time. Kicked off a batch ftp to 
pick it up - timed out.
3 times.

Went and pulled it via http, and (SMP) received it. Just the one PTF - no 
requisites.
Ordered it again just to make sure I had punched all the right radio 
buttons.

All round, a pretty poor experience compared to the past.

Shane ...

Jack wrote on 04/06/2007 11:17:40 PM:

> >I ordered a single APAR earlier this morning and the job "timed out". 
The
> >default is 120 minutes of waiting.
> 
> I have to agree with Brian and Mark that the Receive Order is a very 
nice 
> feature but certainly has loss its responsiveness. The last APAR (6 
> SYSMODs) that I ordered required more than 3 but less than 5 hours to 
> complete. This is a tad more than the 15 - 20 minutes from a couple of 
> month ago.. 

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

Multiple Copying Program

[Cartwright, Dave]

Can anyone suggest a program to use to copy multiple sequential files at
a single point in time?  I want to setup a test CA-7 environment and
most of its queues are flat files which may be GENER'ed.  For aesthetic
reasons I would like to snap them all simultaneously.  I think SyncSort
may offer multiple copies, but I think they are processed sequentially.
FTL from file 270 of the CBT tape copies sequentially.  What I want is
something analagous to the PARALLEL command in DfDss - I suppose I could
set up parallel dumps of all the queues then restore them, but I was
hoping someone has a multiple copy utility that will allow me to do it
in one step.

 

Thanks

Dave

 

 


*
This email is intended solely for the use of the individual to whom
it is addressed and may contain confidential and/or privileged 
material.  Any views or opinions presented are solely those of the 
author and do not necessarily represent those of AGCO.
If you are not the intended recipient, be advised that you have
received this email in error and that any use, dissemination, 
forwarding, printing or copying of this email is strictly prohibited.
 
Neither AGCO nor the sender accepts any responsibility for viruses and it is 
your
responsibility to scan and virus check the e-mail and its attachment(s) (if 
any).
*
AGCO Limited, a limited company, registered in England (registered no.509133) 
with its registered office at Abbey Park Stoneleigh, Kenilworth CV8 2TQ, 
England.


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

[Dave Cartwright]

Twit! Once again answering my own question.
DFSMSdss supports the COPY operand for logical and physical copies.
That'll do, although I would still be interested if anyone has an alternative.

Dave

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Interesting(?) observation - IOCP on a z9BC

[Roy Hewitt]

John

McKown, John wrote:


Bottom line: Why did the S/A IOCP allow me to create a 2086 IOCDS on a
2096 machine? 


I presume you are referring to the SYSTEM keword on the ID statement, It 
is probably ignored by SA iocp, as its only purpose is to allow machine 
type verification of limit/options, when doing what you originally did.. 
i.e run a batch IOCP specify the upgrade option. By default IOCP will 
enforce IOCP limits for the machine on which IOCP is running, the SYSTEM 
keyword, along with the CHECKCPC=NO option, allows you to say, "when 
creating this IOCP, enforce limits for machine ". (The HCD wrapper 
function calls this "Write IOCDS in preparation of upgrade".)


I can only assume that you didn't change the machine type in HCD prior 
to creating the upgrade IOCDS? My assummption is based on the fact that 
the copy of the IOCP deck on you PC had SYSTEM set to 2086, if so this 
might explain why the original upgrade IOCP failed... ie it was still 
creating a 2086 format IOCP.


As for doing a POR, you can continue to use machine type 2086, and as 
you've found out successfully ACTIVATE. You will only need to fix it if 
you need to define something in HCD that is only availaable on 2096 and 
not on 2084, eg OSA ICC..


You should also be able to create an IOCDS using either

1) the upgrade option (like you did earlier)

or

2) using the standard batch IOCP (ICPIOCP) program and NOT HCD front end 
batch. HCD does more validity checking, then calls ICPIOCP!. Just export 
the IOCP deck from HCD and run ICPIOCP (described in z9 IOCP Users guide)


You dont even need to create the IOCDS, remember the IOCDS is only ever 
used at POR time...so if PORs are hard to come by, then you can defer it 
until you really need to...


Regards

Roy

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

z/OS Documentation? Ouch!

[Paul [EMAIL PROTECTED]]

I lately submitted an RCF on a z/OS product concerning an
apparently incomplete description of its command syntax.
The reply contained the following sentence, apparently
from a developer addressed to a tech writer:

... I probably would not say anything about the
syntax rules that are followed because you may
give misleading information.

So, the programmer is supposed to guess?

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

1.7 and Internal Reader

[Daniel McLaughlin]

Has anyone else had their venerable internal reader proc go crazy under 1.7? 
Ours gets JCL errors and doesn't pull the job to submit. Must be some more 
holes that got close in this release. Here is what we use, which shows an 
override error on IEFPROC.IEFRDER.

//*--*  
//*---THIS JOB PROVIDES A MEANS TO START A JOB FROM A PDS
*  
//*--*  
//RDR PROC FILE=SYS1.PROD.ZOS17.PROCLIB,
// MEM= 
//* RUN THROUGH JCLPREP ON 05/27/2007 AT 08:53:14 
//* 
//RDR   EXEC PGM=IEBGENER   
//SYSPRINT  DD SYSOUT=A 
//SYSUT1DD DSN=&FILE(&MEM), 
// DISP=SHR 
//SYSUT2DD SYSOUT=(A,INTRDR)
//SYSIN DD DUMMY

As always, help is appreciated.

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

Re: Multiple Copying Program

[Staller, Allan]

Don't forget the "PARALLEL" operand... 


Twit! Once again answering my own question.
DFSMSdss supports the COPY operand for logical and physical copies.
That'll do, although I would still be interested if anyone has an
alternative.


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

[Bill Wilkie]

It must be you.

It must be you.

Bill



From: "Thompson, Steve" <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Double Postings
Date: Mon, 4 Jun 2007 16:42:43 -0400

Is it me [our system], or is anyone else getting two of every posting?

Regards,
Steve Thompson

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


_
PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows 
Live Hotmail. 
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507


--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: 1.7 and Internal Reader

[Rich Tabor]

Probably needs to be something like:

//SYSUT1 DD DDNAME=IEFRDER
//IEFRDER DD DSN=&FILE(&MEM),DISP=SHR

On 6/5/07, Daniel McLaughlin <[EMAIL PROTECTED]> wrote:

Has anyone else had their venerable internal reader proc go crazy under 1.7?
Ours gets JCL errors and doesn't pull the job to submit. Must be some more
holes that got close in this release. Here is what we use, which shows an
override error on IEFPROC.IEFRDER.

//*--*
//*---THIS JOB PROVIDES A MEANS TO START A JOB FROM A PDS
*
//*--*
//RDR PROC FILE=SYS1.PROD.ZOS17.PROCLIB,
// MEM=
//* RUN THROUGH JCLPREP ON 05/27/2007 AT 08:53:14
//*
//RDR   EXEC PGM=IEBGENER
//SYSPRINT  DD SYSOUT=A
//SYSUT1DD DSN=&FILE(&MEM),
// DISP=SHR
//SYSUT2DD SYSOUT=(A,INTRDR)
//SYSIN DD DUMMY

As always, help is appreciated.

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



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

[Chris Mason]

Paul

Try to find out which development lab is responsible for the product - if 
you don't already know - and write a letter to the lab director - as if I 
needed to tell you - indicating how ridiculous this response was.


I once got a response from a manager responsible for documentation having 
made some comment on an internal IBM forum about inadequate documentation 
telling me off and telling me how many commendations his people had had - 
from where? - over how wonderful their work was - as if that had anything to 
do with my complaint.


Also I once had a comment from a developer - because he was using my 
presentation - on a trip that should have been mine  - about 
how I was describing internal mechanisms about which I shouldn't have known 
but were, in fact, discovered by testing, possibly - because I sometimes had 
to do this - using trial and error.


Chris Mason

- Original Message - 
From: "Paul [EMAIL PROTECTED]" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, June 05, 2007 2:30 PM
Subject: z/OS Documentation? Ouch!



I lately submitted an RCF on a z/OS product concerning an
apparently incomplete description of its command syntax.
The reply contained the following sentence, apparently
from a developer addressed to a tech writer:

   ... I probably would not say anything about the
   syntax rules that are followed because you may
   give misleading information.

So, the programmer is supposed to guess?

-- 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: 1.7 and Internal Reader

[Peter X. DeFabritus]

We had a similar problem.  If I remember correctly, JES2 for z/OS 1.7 has 
changed its internal reader processing, in that when a data set contains ASA 
control characters in column 1, JES2 no longer skips over these characters 
when receiving the records in an internal reader, but treats them as part of 
the JCL.  This could be causing your JCL errors.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Converting from Control-M to Cybermation ESP

[Allen Thennes]

Hey Gadi, I have been working with ESP since 1994. I have also worked for 
the vendor (Cybermation) for 3 years and worked very closely with the 
conversion teams. They do an exceptional job in identify all the necessary 
pieces in making the conversion as seamless as possible. As always there 
are some minor issues but what I have experienced is that the issues are 
fixed immediately and life goes on. I cannot recall ever seeing a 
conversion that went bad for any reason even with other scheduling 
products (CA7, BMC, CA Scheduler).

I am still using ESP today and find the product to be very stable and 
reliable. The support is better than what I get from other vendors. Also 
the ESP Agent technology is the best.

Hope this helps, let me know if you  have any questions. 


Regards,

Allen Thennes
IT- Production Support
Walgreen Co.
(847) 788-4648




גדי בן  אבי <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
06/05/2007 01:35 AM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@BAMA.UA.EDU
cc

Subject
Converting from Control-M to Cybermation ESP






Hi,
 
We are looking into Converting from Control-M to Cybermation ESP. 
 
Has anyone done this?
 
How was it done? Is the conversion simple, complicated, mostly automated?
 
Was it successful?
 
TIA
 
Gadi

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: 1.7 and Internal Reader

[Chris Mason]

Daniel

Please also post the job log so we can see the error messages.

It takes me back many years but I'm sure your procedure is what I used to 
do.


In any case, this worked for you in releases before 1.7 didn't it?

Chris Mason

- Original Message - 
From: "Daniel McLaughlin" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, June 05, 2007 2:50 PM
Subject: 1.7 and Internal Reader


Has anyone else had their venerable internal reader proc go crazy under 
1.7?

Ours gets JCL errors and doesn't pull the job to submit. Must be some more
holes that got close in this release. Here is what we use, which shows an
override error on IEFPROC.IEFRDER.

//*--*
//*---THIS JOB PROVIDES A MEANS TO START A JOB FROM A PDS
*
//*--*
//RDR PROC FILE=SYS1.PROD.ZOS17.PROCLIB,
// MEM=
//* RUN THROUGH JCLPREP ON 05/27/2007 AT 08:53:14
//*
//RDR   EXEC PGM=IEBGENER
//SYSPRINT  DD SYSOUT=A
//SYSUT1DD DSN=&FILE(&MEM),
// DISP=SHR
//SYSUT2DD SYSOUT=(A,INTRDR)
//SYSIN DD DUMMY

As always, help is appreciated.


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

Re: Friday musings on the future of 3270 applications

[Mark Zelden]

Here we go again ...


>If "USS" was "official" you would expect a massive number of hits.

Wayne (nor anyone else who has ever weighed in on this topic) never
claimed it was "official".  Read his post...  the word official was never used.

>Of course I have no doubt that the developers among themselves use "USS"
>very freely as will any, for example, redbook authors or SHARE attendees,
>who come into contact with them.

Exactly... common usage and less keystrokes.  So what is the problem in
using it in a forum like this when everyone knows exactly what it means?
Are all the net jargon abbreviations"official".  Do we waste time debating it? 

All who object:  Feel free to spell out Unix System Services (I tend to
use "z/OS Unix" in my "formal" writings) in any posts you need to.  Otherwise,
unless you really don't know what the OP was talking about, there is no 
point in debating this over and over again.

--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group:  G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
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

Re: SMP/E 3.4 - IBM Order Server Performance

[Ed Finnell]

 
In a message dated 6/5/2007 2:15:15 A.M. Central Daylight Time,  
[EMAIL PROTECTED] writes:

Ordered  it again just to make sure I had punched all the right radio  
buttons.

All round, a pretty poor experience compared to the  past.



>>
My suspicion is that they failed to address the tn3270 queue when they  
dropped support. Also, they don't have anybody left in capacity planning that  
can 
tell the difference in uniform and gaussian distribution and certainly  nobody 
at the management level that does comparative analysis.hey! borrow a  
quarter.



** See what's free at http://www.aol.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: 1.7 and Internal Reader

[Daniel McLaughlin]

Thank you...I guess that should have been obvious..I'll give it a try.

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

Job Stream via FTP

[Ward, Mike S]

Hello all, I have a question. Can a jcl job stream be submitted via an
FTP session? If yes, how? And are there any gotcha's?


Thanks in advance.
==
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity
to whom they are addressed.If you have received this email in error please 
notify the system manager. This message
contains confidential information and is intended only for the individual 
named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the 
sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system. If you are not 
the intended recipient you are notified that
disclosing, copying, distributing or taking any action in reliance on the 
contents of this information 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: Job Stream via FTP

[Veilleux, Jon L]

Use this format after you issue the FTP command:

SITE FILETYPE=JES
PUT  'JCL.Dataset'  


Jon L. Veilleux
[EMAIL PROTECTED]
(860) 636-2683 


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ward, Mike S
Sent: Tuesday, June 05, 2007 9:31 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Job Stream via FTP



Hello all, I have a question. Can a jcl job stream be submitted via an
FTP session? If yes, how? And are there any gotcha's?

This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: 1.7 and Internal Reader

[Chris Mason]

Rich

This is still taking me back many years but I'm happy to say I appear - 
according to the "MVS System Commands" manual - to have remembered 
correctly.


The purpose of IEFRDER is to identify the, possibly and typically one of 
many, DD-statement to which any relevant parameters specified on a START 
command would apply.


The manual shows the following for the command syntax and the first part of 
the explanation of the "keyword" parameter.




S membername[.identifier]
  [,devicetype|,[/]devnum]
  [,volumeserial]
  [,parameters]
  [,JOBNAME=jobname]
  [,JOBACCT=acct_info]
  [,SUB=subsystemname]
  [,keyword=option[,keyword=option]...]

-

keyword=option

Any appropriate keyword parameter you specify to override the corresponding 
parameter in the cataloged procedure. The maximum length of each 
keyword=option is 66 characters. No individual value within this field may 
be longer than 44 characters in length. You can specify:


- JCL JOB statement keyword parameters, to modify the JOB statement for the 
started task


- JCL EXEC statement keyword parameters, to override EXEC statements in the 
procedure being started (if the target of the START command is a procedure)


- JCL DD statement keyword parameters, to modify the IEFRDER DD statement 
(if it exists)


- JCL symbol names, to provide values for use in the started task




In addition - just for interest - the last two selections for the name of 
the started task are the following:




The device number associated with the IEFRDER DD statement within the 
member.


The member name.



Chris Mason

- Original Message - 
From: "Rich Tabor" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, June 05, 2007 2:58 PM
Subject: Re: 1.7 and Internal Reader



Probably needs to be something like:

//SYSUT1 DD DDNAME=IEFRDER
//IEFRDER DD DSN=&FILE(&MEM),DISP=SHR

On 6/5/07, Daniel McLaughlin <[EMAIL PROTECTED]> wrote:
Has anyone else had their venerable internal reader proc go crazy under 
1.7?
Ours gets JCL errors and doesn't pull the job to submit. Must be some 
more

holes that got close in this release. Here is what we use, which shows an
override error on IEFPROC.IEFRDER.

//*--*
//*---THIS JOB PROVIDES A MEANS TO START A JOB FROM A PDS
*
//*--*
//RDR PROC FILE=SYS1.PROD.ZOS17.PROCLIB,
// MEM=
//* RUN THROUGH JCLPREP ON 05/27/2007 AT 08:53:14
//*
//RDR   EXEC PGM=IEBGENER
//SYSPRINT  DD SYSOUT=A
//SYSUT1DD DSN=&FILE(&MEM),
// DISP=SHR
//SYSUT2DD SYSOUT=(A,INTRDR)
//SYSIN DD DUMMY

As always, help is appreciated.


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

Re: Job Stream via FTP

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Ward, Mike S
> Sent: Tuesday, June 05, 2007 8:31 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Job Stream via FTP
> 
> 
> 
> 
> Hello all, I have a question. Can a jcl job stream be submitted via an
> FTP session? If yes, how? And are there any gotcha's?
> 
> 
> Thanks in advance.

Sure

ftp zos
userid
password
ascii
quote site filetype=jes
put my.jcl

This will submit the JCL in the file "my.jcl". The "secret" is the
FILETYPE=JES parameter. This allows you to PUT a job's JCL to the
INTRDR. It also allows you to GET the job's output (assuming a number of
things that are a bit too detailed to go into here).

Setting up the ftp server for job submission:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b461/2.11
.64


the SITE commands (including FILETYPE=JES)
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B960/5.63

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
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

z/OS 1.8 Bug OA20554

[Jousma, David]

All,

I reported a day or two ago about getting various S80A-10 abends in
batch on a newly upgraded 1.8 production system.  IBM has identified the
offender as UA26500 which was applied/accepted as part of our base
serverpack.  Evidently it freemains x'10' bytes less than it getmained
all below the line.  In our case it affected batch DB2 utilities(IBM,
BMC, Princeton) because they use a lot of tape.  The APAR is still open,
but IBM has provided us a APARFIX for us to use.  We are currently
verifying that this is the fix.  This has stopped our upgrade progress
in its tracks until proven out.

Here is a cut/paste of the APAR

  APAR Identifier .. OA20554  Last Changed  07/05/22
  ABENDA78-18 DUE TO FREEMAIN FROM IGG0201X+X'170' DURING CLOSE OF
  PS NON-VSAM TAPE DATASET.

  Symptom .. AB ABEND Status ... CLOSED  PER
  Severity ... 2  Date Closed . 07/05/22
  Component .. 5695DF102  Duplicate of 
  Reported Release . 180  Fixed Release  999
  Component Name BASE ACCESS MET  Special NoticePE
  Current Target Date ..07/07/17  Flags
  SCP ...
  Platform 

  Status Detail: TESTPACKAGING - Packaged solution is being tested.

  PE PTF List:UA26500

  PTF List:
  Release 180   : PTF not available yet
  Release 190   : PTF not available yet


  Parent APAR:OA15735
  Child APAR list:


  ERROR DESCRIPTION:
  ERROR DURING FREEMAIN SYS CODE = A78-18
   ABENDA78-18 on the  FREEMAIN at IGG0201X+X'170' during
   SVC CLOSEwith apar OA10292 applied on the system.


  LOCAL FIX:


  PROBLEM SUMMARY:
  
  * USERS AFFECTED: All in HDZ1180 and above using non-VSAM data *
  * set with QSAM.   *
  
  * PROBLEM DESCRIPTION: An abend80A-10 after applying UA26500   *
  *  occurs because there is no storage  *
  *  available.  *
  *  The reason there is no storage  *
  *  available is because IGG0201Z will  *
  *  freemain a storage area that is *
  *  actually shorter than the amount*
  *  of storage gotten for this storage  *
  *  area in module IGG0191Q.*
  



Dave Jousma
Principal Systems Programmer
[EMAIL PROTECTED]
616.653.8429




This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: Friday musings on the future of 3270 applications

[Wayne Driscoll]

Chris,
  
You missed my point on this.  1 - As Mark Z. stated, I am not claiming
that USS is an "official" designation for z/OS UNIX, I am stating rather
that it should be usable in those places where it's meaning is clear.  2
- Mr. Metz, has repeatedly harped on how USS is NOT z/OS UNIX, and never
shall be, yet, he is quite happy to refer to "z/OS" as Z/OS, and the use
of the TMP in Batch as "Batch TSO."  On the latter, he used the fact
that IBM doc uses that nomenclature (which I don't recall seeing, and
searches in Book Manager haven't found any yet either) as justification
for using the term.  If IBM doc is suitable for him in that case, it
should be in others.
Wayne Driscoll
Product Developer
JME Software LLC
NOTE: All opinions are strictly my own.
   

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Chris Mason
Sent: Tuesday, June 05, 2007 12:04 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Friday musings on the future of 3270 applications

Wayne

No

This issue has been aired before and the proof that USS is the IBM
abbreviation for Unformatted System Services and *not* UNIX System
Services is contained in a post of mine from approximately 6 months ago,
date and
time: 15 Dec 2006, 13:41.


Claiming that USS is *official* for UNIX System Services is something
"up with which I will not put!" 

Chris Mason

- Original Message -
From: "Wayne Driscoll" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Monday, June 04, 2007 10:35 PM
Subject: Re: Friday musings on the future of 3270 applications


> And I've seen IBM documentation refer to z/OS UNIX System Services as
> USS, so will you accept that?

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

[O'Brien, David W. (NIH/CIT) [C]]

You were right Mark, the original OP never did post back.



From: Mark Zelden [mailto:[EMAIL PROTECTED]
Sent: Mon 6/4/2007 2:51 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: SYSTERM to DSN



On Mon, 4 Jun 2007 13:41:27 -0400, O'Brien, David W. (NIH/CIT) [C]
<[EMAIL PROTECTED]> wrote:

>Rather than 'suspect', why don't we wait for Daniel to supply the requested
information.
>

Not a bad idea.  But...

1) It can make interesting discussion while we all try an figure it out.

2) Many times the OP doesn't post back.

--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group:  G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
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



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

[J R]

And, at the risk of once more violating O'Brien's Law, I suspect I was right 
that it was the asynchronous responses from the HSM address space that was 
the real problem.




From: "O'Brien, David W. (NIH/CIT) [C]" <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: SYSTERM to DSN
Date: Tue, 5 Jun 2007 09:49:51 -0400

You were right Mark, the original OP never did post back.



From: Mark Zelden [mailto:[EMAIL PROTECTED]
Sent: Mon 6/4/2007 2:51 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: SYSTERM to DSN



On Mon, 4 Jun 2007 13:41:27 -0400, O'Brien, David W. (NIH/CIT) [C]
<[EMAIL PROTECTED]> wrote:

>Rather than 'suspect', why don't we wait for Daniel to supply the 
requested

information.
>

Not a bad idea.  But...

1) It can make interesting discussion while we all try an figure it out.

2) Many times the OP doesn't post back.

--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group:  G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
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



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


_
Make every IM count. Download Messenger and join the i’m Initiative now. 
It’s free. http://im.live.com/messenger/im/home/?source=TAGHM_June07


--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Friday musings on the future of 3270 applications

[J R]

Binyamin Dissen:


:>>There was/is also something called TSSO



:>last time I used TSSO, TPUT output went to the console



TPUT went to the console? I would be surprised.

Perhaps you meant PUTLINE?


About twenty years ago, there was also something called ConsoleMaster, but I 
don't see it around anymore.  It provided true TSO without TCAM or VTAM.  It 
could also operate without JES.


You could LOGON at an MCS console and thereafter hotkey between TSO and MCS.

In this case, TPUT/TGET definitely went to the console.



From: Binyamin Dissen <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Friday musings on the future of 3270 applications
Date: Tue, 5 Jun 2007 00:07:32 +0300

On Mon, 4 Jun 2007 15:48:42 -0300 "Shmuel Metz (Seymour J.)"
<[EMAIL PROTECTED]> wrote:

:>In <[EMAIL PROTECTED]>, on 06/03/2007
:>   at 02:31 AM, "Robert A. Rosenberg" <[EMAIL PROTECTED]> said:

:>>There was/is also something called TSSO

:>>From BTL; I don't know who is maintaining it these days, but it still
:>exists.  It actually is TSO, but doesn't require TCAS or VTAM. The
:>last time I used TSSO, TPUT output went to the console; I don't know
:>whether it can drive a 3270 with EXCP these days.

TPUT went to the console? I would be surprised.

Perhaps you meant PUTLINE?

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel



_
Need a break? Find your escape route with Live Search Maps. 
http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01


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

[Paul Gilmartin]

On Tue, 5 Jun 2007 08:31:04 -0500, Ward, Mike S wrote:
>
>Hello all, I have a question. Can a jcl job stream be submitted via an
>FTP session? If yes, how? And are there any gotcha's?
>
Code pages are frequently a "gotcha".  I make it work best
with:

quote site sbdataconn=(IBM-1047,ISO8859-1)

YMMV.  If you have JES3, "quote site jesrecfm=..." and
"quote site jeslrecl=..." may be extremely useful.  On
JES2, they are just harmful absent using a certain
undocumented switch.

-- 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: Friday musings on the future of 3270 applications

[Chris Mason]

Mark

Indeed, "here we go again". The last outbreak - as I remember - was about 6 
months ago.


Indeed the word "official" wasn't used - but it was strongly implied.[1]

I would ask you to do me the honour of taking the trouble to read ***my*** 
post. I specifically said that I had no objection to the use of USS for UNIX 
System Services if the context was clear - on this occasion and 6 months ago 
. Just don't try to state - or imply - that it is "official". Probably the 
"outbreak" 6 months ago was prompted by a possible confusion between USS as 
used to mean UNIX System Services and USS in its original, and hence 
"official", guise as VTAM's Unformatted System Services very likely in 
connection with various flavours of the TELNET server.


Clear?

Chris Mason

[1] As far as I can reconstruct the context - which I was not following 
closely, the sequence is as follows:




CC > > > >There are some subtle to significant differences from "real 
TSO(tm)",


SM > > > The batch TMP jobs we've been running for decades aren't real TSO?

CC > > No of course they're not.

SM > I've seen IBM documentation refer to it as batch TSO.

WD And I've seen IBM documentation refer to z/OS UNIX System Services as 
USS, so will you accept that?




This last comment was fired off at a well-known defender of the initials USS 
as belonging to VTAM - as all regular observers of the list dynamics are 
well aware.


Thus the context is something described as "real" and - to cap it all - to 
which I now find a trademark symbol attached!


QED

- Original Message - 


From: "Mark Zelden" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, June 05, 2007 3:21 PM
Subject: Re: Friday musings on the future of 3270 applications



Here we go again ...



If "USS" was "official" you would expect a massive number of hits.


Wayne (nor anyone else who has ever weighed in on this topic) never
claimed it was "official".  Read his post...  the word official was never 
used.



Of course I have no doubt that the developers among themselves use "USS"
very freely as will any, for example, redbook authors or SHARE attendees,
who come into contact with them.


Exactly... common usage and less keystrokes.  So what is the problem in
using it in a forum like this when everyone knows exactly what it means?
Are all the net jargon abbreviations"official".  Do we waste time debating 
it?


All who object:  Feel free to spell out Unix System Services (I tend to
use "z/OS Unix" in my "formal" writings) in any posts you need to. 
Otherwise,

unless you really don't know what the OP was talking about, there is no
point in debating this over and over again.

--
Mark Zelden


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

[Paul Gilmartin]

On Tue, 5 Jun 2007 15:02:06 +0200, Chris Mason wrote:
>
>Try to find out which development lab is responsible for the product - if
>you don't already know - and write a letter to the lab director - as if I
>needed to tell you - indicating how ridiculous this response was.
>
Well, I chose to defer the skip-level and to appeal to the tech writer
to (appeal to the developer to) reconsider:

I was extremely disappointed by that, focusing on the
sentence:

... I probably would not say anything about the
syntax rules that are followed because you may
give misleading information.

It is the responsibility of a Command Reference to provide
a correct specification of the command syntax so that
programmers don't develop their own "misleading information".
Please go back to the developer; ask him to consult the
design document if necessary, and to determine what the
intended syntax of the command is and to produce suitable
input for the next edition of the Command Reference.  If
necessary, take the draft to your test group to validate
that the product actually conforms to the specification.

OK.  Perhaps I'm being unrealistic.  I suspect this product
was developed under extreme time pressure.  The developer
may have been given considerable freedom: "Use your judgment;
make it work."  It's now time to discover the decisions the
developer made and provide the documentation for the customer.
Ask the programmer what choices he made if he's available;
read the source code if necessary.  Document the syntax.



I didn't even say "ridiculous".  I'll leave it to the tech
writer to infer that.

-- 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: Job Stream via FTP

[Chris Mason]

Mike

Some lecture notes - about a decade or more old now:




When the transfer mode is set to JES using the following subcommand


SITE FILETYPE=JES


jobs may be submitted.


While the "file type" is set to JES, the PUT subcommand causes the data set
to be interpreted as a job by the JES subsystem.


The status of the job can be displayed using the DIR or LS subcommands. This
is necessary to obtain the job number for receiving the output.


Output can be received by using the GET subcommand specifying the job number
as


JOBn or Jn


followed, using a period, with the number of the spool file.


Alternatively, the MGET command, without operands, may be used to retrieve
all held output.


Returning to file, as opposed to JES, file transfer mode requires the
subcommand


SITE FILETYPE=SEQ



Since I was aware I had answered this question before it was actually 
easiest to use Google to find my previous post and "copy and paste" the text 
from there.


I think you'll find using the archives of the list quite helpful.

Chris Mason

- Original Message - 
From: "Ward, Mike S" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, June 05, 2007 3:31 PM
Subject: Job Stream via FTP





Hello all, I have a question. Can a jcl job stream be submitted via an
FTP session? If yes, how? And are there any gotcha's?


Thanks in advance.


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

[Ward, Mike S]

Thank you very much. I will do so in the future.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Chris Mason
Sent: Tuesday, June 05, 2007 9:15 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Job Stream via FTP

Mike

Some lecture notes - about a decade or more old now:



I think you'll find using the archives of the list quite helpful.

Chris Mason


==
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity
to whom they are addressed.If you have received this email in error please 
notify the system manager. This message
contains confidential information and is intended only for the individual 
named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the 
sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system. If you are not 
the intended recipient you are notified that
disclosing, copying, distributing or taking any action in reliance on the 
contents of this information 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: Friday musings on the future of 3270 applications

[Binyamin Dissen]

On Tue, 5 Jun 2007 09:50:48 -0400 J R <[EMAIL PROTECTED]> wrote:

:>Binyamin Dissen:

:>>:>>There was/is also something called TSSO

:>>:>last time I used TSSO, TPUT output went to the console

:>>TPUT went to the console? I would be surprised.

:>>Perhaps you meant PUTLINE?

:>About twenty years ago, there was also something called ConsoleMaster, but I 
:>don't see it around anymore.  It provided true TSO without TCAM or VTAM.  It 
:>could also operate without JES.

That isn't TSSO.

:>You could LOGON at an MCS console and thereafter hotkey between TSO and MCS.

:>In this case, TPUT/TGET definitely went to the console.

Did it allow all TSO commands to run, or did it supply a TSO/ISPF like view
where one could only run commands that they defined?

When I wrote OperAider (died when CA bought UCCEL who bought SKK and CA
stupidly chose to stick with Opera) it supported true line mode TSO on the
console and true full screen via VTAM. It died before I could code in the
support for full screen on a console (the full screen via VTAM was a proof of
concept).

-- 
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

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

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

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

Re: Job Stream via FTP

[Paul Gilmartin]

On Tue, 5 Jun 2007 16:15:18 +0200, Chris Mason wrote:
>
>SITE FILETYPE=JES
>
This appears to work from a Solaris client.  However, from
Windows XP:

ftp> site filetype=jes
Invalid command.

And, ironically, from a z/OS client:

EZA1701I >>> SITE filetype=jes
502 SITE command not implemented.

... I'll recommend "QUOTE SITE FILETYPE=JES"

-- 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: Friday musings on the future of 3270 applications

[J R]

That isn't TSSO.


I know.


Did it allow all TSO commands to run


Yes.  It supported all SVC93/SVC94 functionality, so it did not matter what 
commands the user was running.




From: Binyamin Dissen <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Friday musings on the future of 3270 applications
Date: Tue, 5 Jun 2007 17:26:20 +0300

On Tue, 5 Jun 2007 09:50:48 -0400 J R <[EMAIL PROTECTED]> wrote:

:>Binyamin Dissen:

:>>:>>There was/is also something called TSSO

:>>:>last time I used TSSO, TPUT output went to the console

:>>TPUT went to the console? I would be surprised.

:>>Perhaps you meant PUTLINE?

:>About twenty years ago, there was also something called ConsoleMaster, 
but I
:>don't see it around anymore.  It provided true TSO without TCAM or VTAM.  
It

:>could also operate without JES.

That isn't TSSO.

:>You could LOGON at an MCS console and thereafter hotkey between TSO and 
MCS.


:>In this case, TPUT/TGET definitely went to the console.

Did it allow all TSO commands to run, or did it supply a TSO/ISPF like view
where one could only run commands that they defined?

When I wrote OperAider (died when CA bought UCCEL who bought SKK and CA
stupidly chose to stick with Opera) it supported true line mode TSO on the
console and true full screen via VTAM. It died before I could code in the
support for full screen on a console (the full screen via VTAM was a proof 
of

concept).

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

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

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

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


_
Don’t miss your chance to WIN $10,000 and other great prizes from Microsoft 
Office Live http://clk.atdmt.com/MRT/go/aub0540003042mrt/direct/01/


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

Re: Friday musings on the future of 3270 applications

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of J R
> Sent: Tuesday, June 05, 2007 9:34 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Friday musings on the future of 3270 applications
> 
> 
> >That isn't TSSO.
> 
> I know.
> 
> >Did it allow all TSO commands to run
> 
> Yes.  It supported all SVC93/SVC94 functionality, so it did 
> not matter what 
> commands the user was running.
> 

Oh, man. Any chance of getting this to run as a UNIX command so that I
could use TSO ISPF from a UNIX shell instead of TSO? Yes, I'm really
quite weird .

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
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: IEBCOPY Unloaded dataset to PC and back again...not

[Paul Gilmartin]

On Mon, 4 Jun 2007 19:26:53 -0500, Ed Gould wrote:
>
>Err IBM used to have a FDP product that did just that. I am not sure
>if they still market it or not. It was not designed specifically for
>this it was an hmmm designed to take almost any format file and
>create an 80 byte image enveloped inside JCL and send it to the
>spool. It was then NJE'd to the receiving system and then
>reconstructed into the right format and sent to the utility of choice
>
TSO TRANSMIT comes tantalizingly close to doing the central part
of this in that it creates LRECL=80 images of many file formats.
However, those can't be safely enveloped inside JCL because there's
no guarantee that the TRANSMIT output won't have a "//" (or any
other digraph) in columns 1-2 that will act as an unintended
delimiter.

-- 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: z/OS 1.8 Bug OA20554

[Ed Gould]

On Jun 5, 2007, at 8:48 AM, Jousma, David wrote:


All,

I reported a day or two ago about getting various S80A-10 abends in
batch on a newly upgraded 1.8 production system.  IBM has  
identified the

offender as UA26500 which was applied/accepted as part of our base
serverpack.  Evidently it freemains x'10' bytes less than it getmained
all below the line.  In our case it affected batch DB2 utilities(IBM,
BMC, Princeton) because they use a lot of tape.  The APAR is still  
open,

but IBM has provided us a APARFIX for us to use.  We are currently
verifying that this is the fix.  This has stopped our upgrade progress
in its tracks until proven out.


David,

Just curious as its the first time I have ever seen component as

 BASE ACCESS MET


WHat was it?


Ed

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

Re: z/OS 1.8 Bug OA20554

[Jousma, David]

I believe it is Base Access Method Services 



Dave Jousma
Principal Systems Programmer
[EMAIL PROTECTED]
616.653.8429


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ed Gould
Sent: Tuesday, June 05, 2007 10:47 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: z/OS 1.8 Bug OA20554


David,

Just curious as its the first time I have ever seen component as

  BASE ACCESS MET


WHat was it?


Ed

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Friday musings on the future of 3270 applications

[J R]

Oh, man. Any chance of getting this to run as a UNIX command so that I
could use TSO ISPF from a UNIX shell instead of TSO?


I doubt it.  It ran in a TSO address space.

In any case, it doesn't seem to exist any more.



From: "McKown, John" <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Friday musings on the future of 3270 applications
Date: Tue, 5 Jun 2007 09:39:45 -0500

> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of J R
> Sent: Tuesday, June 05, 2007 9:34 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Friday musings on the future of 3270 applications
>
>
> >That isn't TSSO.
>
> I know.
>
> >Did it allow all TSO commands to run
>
> Yes.  It supported all SVC93/SVC94 functionality, so it did
> not matter what
> commands the user was running.
>

Oh, man. Any chance of getting this to run as a UNIX command so that I
could use TSO ISPF from a UNIX shell instead of TSO? Yes, I'm really
quite weird .

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
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


_
PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows 
Live Hotmail. 
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507


--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Friday musings on the future of 3270 applications

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of J R
> Sent: Tuesday, June 05, 2007 9:58 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Friday musings on the future of 3270 applications
> 
> 
> >Oh, man. Any chance of getting this to run as a UNIX command 
> so that I
> >could use TSO ISPF from a UNIX shell instead of TSO?
> 
> I doubt it.  It ran in a TSO address space.
> 
> In any case, it doesn't seem to exist any more.

Too bad. Another of my dreams crushed by cruel reality .

I can envision ISPF under UNIX (perhaps only via X) by having a UNIX
command which is APF authorized. This command sets up Subsystem SVC
Screening for the TSO I/O (SVC 93/94?) services, then ATTACHes the
actual TMP (IKJEFT01). The SVC screen would "translate" the normal
terminal I/O into X (or ncurses?) calls by intepreting the 3270 stuff
and translating them appropriately. But it is a "pipe dream" because I
realize that there is really no real reason to do this.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
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

IBM mainframe PSP web site

[Richard Pinion]

Has anyone noticed "strange results" when seaching the IBM PSP website?  I 
routinely check the site specifying a type of "Z/OS", catagory of "MVS 
operating system", my level of Z/OS, and selecting "extract files only".  In 
the 
last week or so I have been getting results that do not fit into my selection 
criteria.  As an example here are some results that I got when using the 
criteria above.

[1]   SA08: WebSphere Service Registry and Repository-Basic Governance 
Profile Sample   2007-06-05 
 
This is a business profile containing a sample configuration for WSRR 
that provides a business model, lifecycles and policies that are sufficient to 
support basic SOA governance. 
 
[ More items like this found in Systems Management ] 
 
[2]   Domino Web Access server crash when users access mail files; 
Truncated call stacks occur in Domino NSD   2007-06-04 
 
Since upgrading your Domino server to release 7.0.2 or 6.5.6, the 
server 
crashes randomly (daily or more frequently) when Domino Web Access users 
access their mail files. These crashes can be intermittent, and sometimes 
difficult to reproduce. 
 
[ More items like this found in Other Data & Information 
Management ] 
 
[3]   Generating DB2 sample data using DB2 Alphablox   2007-06-04 
 
A simple JSP for generating DB2 sample "sales" data using DB2 
Alphablox, 
which includes Date, Time, Timestamp, Integer, and Double data 
 
[ More items like this found in S/390 (Enterprise Servers, 
Mainframes) ] 
 
[4]   Temperature alerts / shutdown - IBM eServer xSeries 230 and IBM 
Netfinity 5100   2007-06-04 
 
Source RETAIN tip H172504 Symptom IBM xSeries 230 / IBM Netfinity 
5100 with a second processor installed experiences either of the following: 
Processor #2 over-temp in the system event log Shutdown NOTE: This tip 
applies to Europe, 
 
[ More items like this found in i5/OS, OS/400 ]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: INTIDS (was: zOS 1.8 and One Byte Console ID)

[Scott Fagen]

On Fri, 1 Jun 2007 07:29:25 +0200, Barbara Nitz <[EMAIL PROTECTED]> wrote:

-snip-
>I beg to differ with regard to the INTIDS and UNKNIDS attribute, though. Given
>that there is no way in hell to define it on a 1.6 system that runs mixed
with a
>1.8 system, it is wrong of console initialization code to 'ignore' an
attribute (and
>in fact use the absolute opposite -N instead of Y) that could not be defined
>before. 

This is how CONSOLxx has always worked.  If the console was previously defined
in the sysplex, any values specified in CONSOLxx that do not correspond to the
currently defined values are rejected with RC=3.

This doesn't mean that you can't turn INTIDS on and have it persist.  The way
the CONSOLE control block sharing code works (by building in the assumption on
the 'downlevel' systems that there are attributes that they don't know about but
need to propagate) is that attributes set on the 1.8 system will be 'remembered'
by the downlevel systems, even if the 1.8 system leaves the sysplex.

So, if you want to have INTIDS or UNKNIDS set, you need to take two actions:
1) Put it in the CONSOLxx member.  You can even put it in a member shared with
   1.6/7.  CONSOLE initialization will 'ignore' the new specifications on the
   downlevel systems without causing the console definition to be thrown out.

2) Either manually or via automation use the VARY CN command to 'activate'
   UNKNIDS and INTIDS on the consoles that you want it on.  Obviously, the
   function will only work when the console is activated on a 1.8 system,
but the
   attribute will stay with the console, even after all the 1.8 systems
leave the
   sysplex (with one caveat, if you cold start the sysplex and don't IPL any 1.8
   systems, you will have to re-establish UNKNIDS/INTIDS after 1.8 rejoins). 

>If you don't explicitly look out for that, and then take steps to correct the
>console code assumptions during initialization, you will have a rude awakening
>with regard to these two attributes. No 1.8 console will have it. And I don't
>think any installation will go and rename their consoles (UCBs and all)
when they >switch between pre-1.8 and 1.8 systems, just to get these
attributes defined
>for the first time.

I don't believe that your understanding of how the code works is correct. 
If you set INTIDS/UNKNIDS, it will 'stick' to the console for the life of
the sysplex, regardless of the presence/absence of a 1.8 system.

>Effectively, the way it works now, you either have to cold-start a complete
>sysplex to get the console attributes, or you have to go to lenghts to get the
>attributes assigned as intended. (And as I said, I wonder what will happen to
>those keywords when I re-IPL my 1.6 system that doesn't know about them.)

Incorrect.  See discussion above.

>
>Besides, once a 1.8 system is in the plex, the lower level systems don't have
>the cond=m consoles anymore, just as you said. What I am missing here is a
>message that announces that fact. A D C,MSTR just gives 'no consoles meet
>speicifed criteria'. I just hope that we have all definitions in place so
that won't
>cause problems when we rollout 1.8 in mixed sysplexes.

If you want to have consoles with MASTER authority, give them MASTER
authority.  VARY CN(..),AUTH=MASTER.  It would be helpful to update CONSOLxx
as well.  The capability to have more than one console with MASTER authority
has existed since MVS 4.1.  

>
>Thanks for listening.
>regards, Barbara

No problem.

Scott Fagen
z/OS Core Technology Design
IBM Poughkeepsie

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

[Chris Mason]

Paul

This is a specific instance of the general rule that, if an FTP client 
doesn't understand the command you wish to send to the FTP server, you 
should "quote" it, as it were.



From "IP User's Guide and Commands":




QUOte subcommand—Send an uninterpreted string of data

Purpose

Use the QUOte subcommand to send an uninterpreted string of data to the 
server port on the foreign host.


The QUOte subcommand bypasses the FTP interface of your local host. You can 
use the QUOte subcommand to send commands that the remote server 
understands, but that the local host does not understand.




But you're right, we should be maximally helpful in these posts.

I wondered about your experience with OS/2 since I was pretty sure that the 
exercise which backs up the lectures - tell 'em about it in the morning so 
they can do it in the afternoon - involved using a PC with OS/2.


So I checked.

Indeed it does but we were using an FTP client GUI program called FTPPM - PM 
for "presentation manager" I think. Very probably the program put "quote" 
before and command entered in the command field as a matter of course.


But then I read further and, because FTPPM didn't/doesn't allow the JES 
output to be retrieved, that had to be done with the basic FTP command. 
However, there's no mention of needing to use "quote" in order to use the 
"site filetype=jes" command. Why, I wonder, has the OS/2 FTP command 
regressed since approximately 1995?


Chris Mason

- Original Message - 
From: "Paul Gilmartin" <[EMAIL PROTECTED]>

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, June 05, 2007 4:32 PM
Subject: Re: Job Stream via FTP



On Tue, 5 Jun 2007 16:15:18 +0200, Chris Mason wrote:


SITE FILETYPE=JES


This appears to work from a Solaris client.  However, from
Windows XP:

   ftp> site filetype=jes
   Invalid command.

And, ironically, from a z/OS client:

   EZA1701I >>> SITE filetype=jes
   502 SITE command not implemented.

... I'll recommend "QUOTE SITE FILETYPE=JES"

-- 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: Friday musings on the future of 3270 applications

[Tom Marchant]

On Tue, 5 Jun 2007 10:58:07 -0400, J R wrote:

>>Oh, man. Any chance of getting this to run as a UNIX command so that I
>>could use TSO ISPF from a UNIX shell instead of TSO?
>
>I doubt it.  It ran in a TSO address space.
>
>In any case, it doesn't seem to exist any more.

If you're talking about Console-Master from Xenos (www.xenos.com), it ran as
a started task.  They don't seem to be marketing it any more.

-- 
Tom Marchant

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

[Edward Jaffe]

Chris Mason wrote:
[snip]
But then I read further and, because FTPPM didn't/doesn't allow the 
JES output to be retrieved, that had to be done with the basic FTP 
command. However, there's no mention of needing to use "quote" in 
order to use the "site filetype=jes" command. Why, I wonder, has the 
OS/2 FTP command regressed since approximately 1995?


The "vanilla" ftp command under OS/2 allowed the site command to be used 
without having to say "quote site ...".


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
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: Friday musings on the future of 3270 applications

[J R]

If you're talking about Console-Master from Xenos (www.xenos.com), it ran 
as

a started task.


Yes, that was the "recovery mode" where JES was not available.

In non-recovery mode, you walked up to a console, entered "LOGON" and got a 
genuine TSO address space.




From: Tom Marchant <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Friday musings on the future of 3270 applications
Date: Tue, 5 Jun 2007 10:27:52 -0500

On Tue, 5 Jun 2007 10:58:07 -0400, J R wrote:

>>Oh, man. Any chance of getting this to run as a UNIX command so that I
>>could use TSO ISPF from a UNIX shell instead of TSO?
>
>I doubt it.  It ran in a TSO address space.
>
>In any case, it doesn't seem to exist any more.

If you're talking about Console-Master from Xenos (www.xenos.com), it ran 
as

a started task.  They don't seem to be marketing it any more.

--
Tom Marchant

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


_
Play games, earn tickets, get cool prizes. Play now–it's FREE! 
http://club.live.com/home.aspx?icid=CLUB_hotmailtextlink1


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

[Sharon Lopez]

If I restore UA26500 back to the base of HDZ1180, do you think that I will
be ok?  I'm due to roll my first 1.8 into production on June 17th and I've
already restored 2 ptfs on my test system, and frankly, I'm thinking about
postponing my upgrade  because of all the information that I've received on
this list.   

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Jousma, David
Sent: Tuesday, June 05, 2007 9:49 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: z/OS 1.8 Bug OA20554

All,

I reported a day or two ago about getting various S80A-10 abends in
batch on a newly upgraded 1.8 production system.  IBM has identified the
offender as UA26500 which was applied/accepted as part of our base
serverpack.  Evidently it freemains x'10' bytes less than it getmained
all below the line.  In our case it affected batch DB2 utilities(IBM,
BMC, Princeton) because they use a lot of tape.  The APAR is still open,
but IBM has provided us a APARFIX for us to use.  We are currently
verifying that this is the fix.  This has stopped our upgrade progress
in its tracks until proven out.

Here is a cut/paste of the APAR

  APAR Identifier .. OA20554  Last Changed  07/05/22
  ABENDA78-18 DUE TO FREEMAIN FROM IGG0201X+X'170' DURING CLOSE OF
  PS NON-VSAM TAPE DATASET.

  Symptom .. AB ABEND Status ... CLOSED  PER
  Severity ... 2  Date Closed . 07/05/22
  Component .. 5695DF102  Duplicate of 
  Reported Release . 180  Fixed Release  999
  Component Name BASE ACCESS MET  Special NoticePE
  Current Target Date ..07/07/17  Flags
  SCP ...
  Platform 

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

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Darren Evans-Young
Sent: Monday, June 04, 2007 3:47 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Double Postings

That may be my fault. I've been trying to update the Listserv mailer and
the Windows server the old one is on decided it wanted to start acting
up. Actually, I think the NIC was dying a slow death. You shouldn't see
any more dupsI hope.

Darren - List Owner


Any idea when this might end? I'm still getting two of every posting.

Later,
Steve Thompson

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

[Darren Evans-Young]

On Tue, 5 Jun 2007, Thompson, Steve wrote:

>
>Any idea when this might end? I'm still getting two of every posting.
>
>Later,
>Steve Thompson

Yikes, you shouldnt still be getting doubles!
Email me ([EMAIL PROTECTED]), not the list, a double posting
complete with the headers (Received: tags).  I dont think
the dups are coming from me.

Darren

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

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Darren Evans-Young
> 
> On Tue, 5 Jun 2007, Thompson, Steve wrote:
> 
> >
> >Any idea when this might end? I'm still getting two of every posting.
> >
> >Later,
> >Steve Thompson
> 
> Yikes, you shouldnt still be getting doubles!
> Email me ([EMAIL PROTECTED]), not the list, a double posting 
> complete with the headers (Received: tags).  I dont think the 
> dups are coming from me.

FWIW, I've not seen any duplicates at all.

-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: z/OS 1.8 Bug OA20554

[Mark Zelden]

On Tue, 5 Jun 2007 11:49:23 -0400, Sharon Lopez <[EMAIL PROTECTED]> wrote:

>If I restore UA26500 back to the base of HDZ1180, do you think that I will
>be ok?  I'm due to roll my first 1.8 into production on June 17th and I've
>already restored 2 ptfs on my test system, and frankly, I'm thinking about
>postponing my upgrade  because of all the information that I've received on
>this list.
>

As always, you have to look at what the PTF was fixing to see if that
problem is worse than the PE.  In this case you have to go back in the
chain to OA10292 - which was a timing issue.

FWIW, I have 1.8 running on LPARs that run the utilities that David
was having problems with.   I don't have UA26500 applied because 
holddata kept me from doing so and (luckily) it wasn't applied and
accepted with my ServerPac like it was with David.  I have been
burned by that exact situation with this upgrade and I really hope
I can talk about this at SHARE with some of the IBM-ers.  

According to SMP/E - IGG0201B and IGG0201X are at base on my
system, so to answer your question specifically, I think you are 
okay in regards to this particular issue if you restore UA26500.
Of course, YMMV.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group:  G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
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

Re: DFSORT date processing

[Frank Yaeger]

On Jun 5, 4:18 am, Captain Paralytic wrote:
> I have a file which contains a timestamp in the format:
> MMDDHHMMSSMM
> starting at position 27.
>
> Is it possible to have DFSORT remove records which are more than a
> month old where a month is defined as 28 days?
>
> If it is possible, can someone suggest the correct invocation?

I believe these DFSORT control statements will do what you asked for:

  OPTION COPY
  OMIT COND=(27,8,CH,LT,DATE1-28)

You'll need z/OS DFSORT V1R5 PTF UK90007 or DFSORT R14 PTF UK90006 (April,
2006) in order to use DFSORT's relative date function.  If you don't have
the April, 2006 PTF, ask your System Programmer to install it (it's free).
For complete details on all of the new DFSORT and ICETOOL functions
available with the April, 2006 PTF, see:

www.ibm.com/servers/storage/support/software/sort/mvs/peug/

Frank Yaeger - DFSORT Development Team (IBM) - [EMAIL PROTECTED]
Specialties: PARSE, JFY, SQZ, ICETOOL, IFTHEN, OVERLAY, Symbols, Migration

 => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Converting from Control-M to Cybermation ESP

[Hal Merritt]

ESP is no longer Cybermation. It is now a CA product. 

We feel that ESP is a superb product. We also feel that CA is trying
very had to put itself out of business and to divest itself of us as a
customer. 

Just my personal opinion.   

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of ??? ?? ???
Sent: Tuesday, June 05, 2007 1:35 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Converting from Control-M to Cybermation ESP

Hi,
 
We are looking into Converting from Control-M to Cybermation ESP. 
 
Has anyone done this?
 
How was it done? Is the conversion simple, complicated, mostly
automated?
 
Was it successful?
 
TIA
 
Gadi
 
NOTICE: This electronic mail message and any files transmitted with it are 
intended exclusively
for the individual or entity to which it is addressed. The message, together 
with any attachment, may contain confidential and/or privileged
information. Any unauthorized review, use, printing, saving, copying, 
disclosure 
or distribution is strictly prohibited. If you have received this message in 
error, please immediately
advise the sender by reply email and delete all copies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: BPXBATCH and DSNAME ENQs

[Tony Harminc]

On Tue, 29 May 2007 10:50:23 -0500, Paul Gilmartin wrote:

>Ouch!  Dynamically creating job steps seems utterly contrary to the
>JCL paradigm.

Indeed. One of several cases where the z/OS UNIX implementation has
unnecessarily broken existing paradigms. The surprise factor is often high.

What happens ENQ-wise if you have two "classic" job steps where the ENQ is
expected to last until the second one, and the *OMVSEX step is inserted in
between? I imagine that won't have any surprises. I suppose this bahaviour
can be explained by saying that the inserted job step provides no user
interface to its JCL, and that therefore there is no possibility of
affecting dataset ENQs.

>3 //PAUSE1   EXEC  PGM=BPXBATCH,PARM='sh exec /bin/true '
>
>... shows 3 generated "*OMVSEX" steps.  Hmmm.  One to exec() sh,
>a second to exec() /bin/true.  What's the third one?  In fact, the
>minimal:
>
>3 //PAUSE1   EXEC  PGM=BPXBATCH,PARM='sh exit'
>
>Shows 2 "*OMVSEX" steps.  Why?  But:
>
>3 //PAUSE1   EXEC  PGM=BPXBATCH,PARM='pgm /bin/sh -c exit'
>
>shows only one.  Why should 'sh ...' take one more exec() than
>'pgm /bin/sh -c ...'?

Um, I think because it implicitly runs the shell (process 1) since you
didn't use the pgm option, then the first shell command is "sh" (process 2),
and then under that second shell you run "/bin/true" (process 3). 

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Interesting(?) observation - IOCP on a z9BC

[Dave Kopischke]

On Tue, 5 Jun 2007 11:28:42 +0100, Roy Hewitt wrote:

>You dont even need to create the IOCDS, remember the IOCDS is only ever
>used at POR time...so if PORs are hard to come by, then you can defer it
>until you really need to...
>

If you don't create and activate a new IOCDS with the IODF, I believe you'll 
get hardware/software mismatch messages at every IPL until you get them 
synched up. Depending on your environment, you might have trouble finding 
the matching IOCDS if you let it languish for a long time. I would suggest a 
policy of keeping them synched up to avoid subsequent problems.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Interesting(?) observation - IOCP on a z9BC

[Glen Gasior]

This is a bit OT, but will you be running as a uniprocessor on the z9BC ?

On 6/4/07, McKown, John <[EMAIL PROTECTED]> wrote:


We recently converted our 2086 (z890) to a 2096 (z9BC) via a "suicide
swap".


--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Interesting(?) observation - IOCP on a z9BC

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Glen Gasior
> Sent: Tuesday, June 05, 2007 12:54 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Interesting(?) observation - IOCP on a z9BC
> 
> 
> This is a bit OT, but will you be running as a uniprocessor 
> on the z9BC ?
> 

No - we have two engines enabled. I don't like uniprocessors,
personally.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
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: IEBCOPY Unloaded dataset to PC and back again...not

[Ed Gould]

On Jun 5, 2007, at 9:40 AM, Paul Gilmartin wrote:




TSO TRANSMIT comes tantalizingly close to doing the central part
of this in that it creates LRECL=80 images of many file formats.
However, those can't be safely enveloped inside JCL because there's
no guarantee that the TRANSMIT output won't have a "//" (or any
other digraph) in columns 1-2 that will act as an unintended
delimiter.




Gil,

We sort of got around this issue with various DLM='??' type operands.  
We did come up with an issue with that, IIRC and I got really exotic  
(for us) /*XMIT with a (my memory is fading) as to exacts. The  
"problem" with my solution was than somewhere along the line IBM  
either dropped it or changed it in a PTF and the job stream would no  
longer work. I got called in and had to slightly change the job  
stream yo get it to work. I got put through the wringer for not  
knowing about it and not letting people know about the change. I  
looked through quite a few JES PTFS just to find the change.  I  
pleaded guilty but showed the people who were complaining how much  
PTF cover letters I had to read through to find it and that sort of  
calmed them down.


Ed

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

Re: Z/os mainframe encryption

[Mark Jacobs]

Jim Savage wrote:
New to cryptography, I'm using IBM callable services CSNBENC and CSNBDEC 
to encrypt/decrypt fields in SMS files.  It seems I need to obtain a key 
identifier by calling CSNBKGN and also specify an initialization vector to 
encrypt.  Are these two calling parameters 'keys' for the encryption?  Are they 
stored somewhere (and retreivable for decryption) in the calling services 
software?  or do I store one or both of them on my own in a file secured by 
some means?  The IBM manuals seem to assume a level of knowledge I just 
don't have on this subject.  Help!


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

  
We create a key using the KGUP utility program. This key is then 
accessed by the ICSF CSFKRR api. The key is accessed via the keylabel 
you select in the key creation process.


After the ICSF CSFKRR service reads the key from the CKDS database it 
returns a token value which is used by the decrypt and encrypt routines.


Did this answer your questions?

--
Mark Jacobs
Technical Services
Time Customer Service - Tampa, FL
--
Victory in defeat, there is none higher. She didn't give up, Ben; 
she's still trying to lift that stone after it has crushed her.
She's a father going down to a dull office job while cancer is 
painfully eating away his insides, so as to bring home one more pay 
check for the kids. She's a twelve-year-old girl trying to mother her
baby brothers and sisters because Mama had to go to Heaven. She's a 
switchboard operator sticking to her job while smoke is choking her 
and the fire is cutting off her escape. She's all the unsung heroes

who couldn't quite cut it but never quit.*

Robert A. Heinlein - Stranger in a Strange Land 


*Referring to the Auguste Rodin sculpture, Caryatid Who Has Fallen under Her 
Stone

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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 do i install Linux on S/390 Machine

[R.S.]

Just curious: what policy ?

Why people sometimes provide a link to a presentation at share.org and 
everyone can download the presentation.

My guesses:
a) There is no such policy. Presenations are available to public.
b) There is a policy, but people often break it, *and* sahre web service 
does not enforce the policy in any mean (I doubt it).
c) There are two (or more) kinds of presentations: available to public 
and only for share members.

d) Others. I have no idea what.


--
Radoslaw Skorupka
Lodz, Poland



JackOfAllTrades wrote:
That would violate SHARE's policy. There are still plenty of redbooks 
and other presentations you can find by searching the web. Or get your 
company to join SHARE.



- Original Message - From: "Mohan" <[EMAIL PROTECTED]>
To: ; "Kenneth E Tomiak" 
<[EMAIL PROTECTED]>

Sent: Sunday, June 03, 2007 10:54 PM
Subject: Re: How do i install Linux on S/390 Machine


Hi,
Thank you for the help.

I do not have a share UID, could you please send me that offline.

Thanks




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

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

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci 
opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 
r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 
z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.

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

Z/os mainframe encryption

[Jim Savage]

New to cryptography, I'm using IBM callable services CSNBENC and CSNBDEC 
to encrypt/decrypt fields in SMS files.  It seems I need to obtain a key 
identifier by calling CSNBKGN and also specify an initialization vector to 
encrypt.  Are these two calling parameters 'keys' for the encryption?  Are they 
stored somewhere (and retreivable for decryption) in the calling services 
software?  or do I store one or both of them on my own in a file secured by 
some means?  The IBM manuals seem to assume a level of knowledge I just 
don't have on this subject.  Help!

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

CICS Abends at startup AKEA

[Lizette Koehler]

Sorry for posting here, but the CICS newsgroup keeps revoking me - something 
about bouncing. 

Anyway, we had a CICS region fail after 64 abends of the following.  If anyone 
could provide some guidance as to where to being that would be great.  The only 
SVC Dump is at the end when we cancelled CICS (At the 65+ abend message).  And 
there does not appear to be any AP0001 dumps due to supression.  And of course 
management wants to know what happened.  So based on this very limited info I 
have, can anyone make a guess?  Thanks very much.

Lizette


2007155 01:35:15.31 STC00302 0090  +DFHSI8434I CICSPH   Control returned 
from PLT programs during the
   third stage of initialization.   
 
2007155 01:35:15.38 STC00302 0090  +DFHSI1517  CICSPH   Control is being 
given to CICS.  
2007155 01:35:15.38 STC00302 0090  +DFHSO0101I CICSPH   Sockets domain 
initialization has ended. 
2007155 01:35:15.38 STC00302 0090  +DFHEJ0102  CICSPH   Enterprise Java 
domain initialization has ended. 
2007155 01:35:15.73 STC00302 0090  +DFHAP0001  CICSPH   An abend (code 
0C4/AKEA) has occurred at offset  
   X'' in module DFHLUP.
 
2007155 01:35:15.73 STC00302 0090  +DFHME0116 CICSPH 287
 
 287 0090   (Module:DFHMEME) CICS symptom string 
for message DFHAP0001 is
 287 0090   PIDS/5697E9300 LVLS/630 MS/DFHAP0001 
RIDS/DFHSRP PTFS/UK05570
 287 0090   AB/S00C4 AB/UAKEA RIDS/DFHLUP 
ADRS/  
2007155 01:35:15.73 STC00302 0090  +DFHDU0205  CICSPH   A SYSTEM DUMP FOR 
DUMPCODE: AP0001  , WAS
   SUPPRESSED BY THE DUMP TABLE OPTION FOR 
THIS DUMPCODE 
2007155 01:35:15.74 STC00302 0090  +DFHAP0001  CICSPH   An abend (code 
0C4/AKEA) has occurred at offset  
   X'' in module DFHLUP.
 
2007155 01:35:15.74 STC00302 0090  +DFHME0116 CICSPH 290
 
 290 0090   (Module:DFHMEME) CICS symptom string 
for message DFHAP0001 is
 290 0090   PIDS/5697E9300 LVLS/630 MS/DFHAP0001 
RIDS/DFHSRP PTFS/UK05570
 290 0090   AB/S00C4 AB/UAKEA RIDS/DFHLUP 
ADRS/  
2007155 01:35:15.74 STC00302 0090  +DFHDU0205  CICSPH   A SYSTEM DUMP FOR 
DUMPCODE: AP0001  , WAS
   SUPPRESSED BY THE DUMP TABLE OPTION FOR 
THIS DUMPCODE 
2007155 01:35:15.75 STC00302 0090  +DFHAP0001  CICSPH   An abend (code 
0C4/AKEA) has occurred at offset

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

USS pedantry (was Friday musings on the future of 3270 applications

[Patrick O'Keefe]

On Tue, 5 Jun 2007 08:21:35 -0500, Mark Zelden 
<[EMAIL PROTECTED]> wrote:

>...
>Exactly... common usage and less keystrokes.  So what is the 
>problem in using it in a forum like this when everyone knows exactly 
>what it means?  Are all the net jargon abbreviations"official".  Do we 
>waste time debating it?
>...
 
No, I'm not complaining about the  pedantry; I'm adding to it.

Obviously not all net jargon is "official", but IBM has (or used to have) a
list of oficial IBM abreviations and USS is (was) in it as Unformated 
System Services, not Unix System Services.

Whether or not "everyone knows exactly what it means", there is not
time when I hear USS and automatically think "Unix".  Not one!  30 
years of working with VTAM guarantee that.  And if Unix for z/OS is 
meant, I resent the mental stumble that causes.  (Yup.  I'm pretty
intolerent.) 

You find our pedantry irritating.  I (probably "we", but I can speak only
for myself) find your misuse of USS irritating.  So it's a draw.

Pat O'Keefe

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

[R.S.]

Jim Savage wrote:
New to cryptography, I'm using IBM callable services CSNBENC and CSNBDEC 
to encrypt/decrypt fields in SMS files.  It seems I need to obtain a key 
identifier by calling CSNBKGN and also specify an initialization vector to 
encrypt.  Are these two calling parameters 'keys' for the encryption?  Are they 
stored somewhere (and retreivable for decryption) in the calling services 
software?  or do I store one or both of them on my own in a file secured by 
some means?  The IBM manuals seem to assume a level of knowledge I just 
don't have on this subject.  Help!


The vestor is not stored anywhere. The key can be stored in CKDS 
dataset. Of course key value is encrypted using another key (master 
key). You can use such a key (this from CKDS) or simply provide your 
own, in clear form. The last option is less secure.


--
Radoslaw Skorupka
Lodz, Poland


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

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

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci 
opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 
r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 
z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.

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

Re: CICS Abends at startup AKEA

[Clark, Kevin]

L. 

A dump would be better than a guess, however DFHLUP is for LU services/
MRO. Perhaps you have a 24bit program trying accessing EDSA.

Do a CEMT I SYD 

RESULT - OVERTYPE TO MODIFY  
  Sydumpcode(SR0001)check the AP0001 also 
  Sysdumping( Nosysdump )
  Dumpscope( Local ) 
  Shutoption( Noshutdown )   
  Maximum( 003 ) 
  Current()  
  Action(  ) 
  Daeoption( Nodae ) 


Kevin

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

Re: CICS Abends at startup AKEA

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler
> 
> Sorry for posting here, but the CICS newsgroup keeps revoking 
> me - something about bouncing. 
> 
> Anyway, we had a CICS region fail after 64 abends of the 
> following.  If anyone could provide some guidance as to where 
> to being that would be great.  The only SVC Dump is at the 
> end when we cancelled CICS (At the 65+ abend message).  And 
> there does not appear to be any AP0001 dumps due to 
> supression.  And of course management wants to know what 
> happened.  So based on this very limited info I have, can 
> anyone make a guess?  Thanks very much.

Open a PMR with CICS Support and send them the dump you have.  They may
or may not be able to diagnose the problem with that dump.

Beyond that, about all you can do is research the symptom string and
messages/module names on IBMLink.

It appears that something corrupted a pointer somewhere and caused a
"wild branch" to the "twilight zone".

You might consider un-suppressing the AP0001 dumpcode, restart CICS and
hopefully capture a failure-time dump.

-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: USS pedantry (was Friday musings on the future of 3270 applications

[Greg Shirey]

While you're in an intolerant mood, rail at IBM for including these
checks in Health Checker:

USS_AUTOMOUNT_DELAY
USS_FILESYS_CONFIG
USS_MAXSOCKETS_MAXFILEPROC 

Regards,

Greg Shirey
Ben E. Keith Company 

-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Patrick O'Keefe
Sent: Tuesday, June 05, 2007 2:31 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: USS pedantry (was Friday musings on the future of 3270
applications

 

Whether or not "everyone knows exactly what it means", there is not
time when I hear USS and automatically think "Unix".  Not one!  30 
years of working with VTAM guarantee that.  And if Unix for z/OS is 
meant, I resent the mental stumble that causes.  (Yup.  I'm pretty
intolerent.) 

You find our pedantry irritating.  I (probably "we", but I can speak
only
for myself) find your misuse of USS irritating.  So it's a draw.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: USS pedantry (was Friday musings on the future of 3270 applications

[Mark Zelden]

>You find our pedantry irritating.  

Not usually.  But occasionally. :-)I'm sure I've been guilty now and
then of being a little pedantic myself.

> (probably "we", but I can speak only
>for myself) find your misuse of USS irritating.  So it's a draw.
>

For the record, I don't use USS for Unix System Services in my posts (only
when quoting someone else).  I usually write "z/OS Unix" as I said in my
last post - even when replying to a post that uses the unofficial abbreviation. 
But I do get tired of the whining about it and the endless threads. 
I think some people use it just to get a rise from those who don't like it.   

I sympathize with you that you think "VTAM" at first glance when you see
it in a post, but it's really not worth debating.   That was my point.  So this
will be my final word on the subject and the next time I will just ignore the
thread or temptation to reply like I usually do. 

Cheers,

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group:  G-ITO
mailto:[EMAIL PROTECTED]
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
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

Re: CICS Abends at startup AKEA

[Fletcher, Kevin]

Lizette,

You have someone stepping on your CICS area (well you already knew
that). what you need is a SVC dump. I know of at least a few places
where a dump can be suppress. 1. with in CICS (CEMT S DU...), Abendaid
FX (or other dump reading product), DAE, or maybe you have a forgotten
SLIP suppressing.

What you may have to do is maybe set a slip for the condition and use
the CICS verb of IPCS to read. IIRC if you get one at point of the
initial abend you should get a list of offending transactions.

Thanks,
 
Fletch  


-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Lizette Koehler
Sent: Tuesday, June 05, 2007 3:30 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: CICS Abends at startup AKEA


Sorry for posting here, but the CICS newsgroup keeps revoking me -
something about bouncing. 

Anyway, we had a CICS region fail after 64 abends of the following.  If
anyone could provide some guidance as to where to being that would be
great.  The only SVC Dump is at the end when we cancelled CICS (At the
65+ abend message).  And there does not appear to be any AP0001 dumps
due to supression.  And of course management wants to know what
happened.  So based on this very limited info I have, can anyone make a
guess?  Thanks very much.

Lizette


2007155 01:35:15.31 STC00302 0090  +DFHSI8434I CICSPH   Control
returned from PLT programs during the
   third stage of initialization.

2007155 01:35:15.38 STC00302 0090  +DFHSI1517  CICSPH   Control is
being given to CICS.  
2007155 01:35:15.38 STC00302 0090  +DFHSO0101I CICSPH   Sockets
domain initialization has ended. 
2007155 01:35:15.38 STC00302 0090  +DFHEJ0102  CICSPH   Enterprise
Java domain initialization has ended. 
2007155 01:35:15.73 STC00302 0090  +DFHAP0001  CICSPH   An abend
(code 0C4/AKEA) has occurred at offset  
   X'' in module DFHLUP.

2007155 01:35:15.73 STC00302 0090  +DFHME0116 CICSPH 287

 287 0090   (Module:DFHMEME) CICS symptom
string for message DFHAP0001 is
 287 0090   PIDS/5697E9300 LVLS/630
MS/DFHAP0001 RIDS/DFHSRP PTFS/UK05570
 287 0090   AB/S00C4 AB/UAKEA RIDS/DFHLUP
ADRS/  
2007155 01:35:15.73 STC00302 0090  +DFHDU0205  CICSPH   A SYSTEM
DUMP FOR DUMPCODE: AP0001  , WAS
   SUPPRESSED BY THE DUMP TABLE
OPTION FOR THIS DUMPCODE 
2007155 01:35:15.74 STC00302 0090  +DFHAP0001  CICSPH   An abend
(code 0C4/AKEA) has occurred at offset  
   X'' in module DFHLUP.

2007155 01:35:15.74 STC00302 0090  +DFHME0116 CICSPH 290

 290 0090   (Module:DFHMEME) CICS symptom
string for message DFHAP0001 is
 290 0090   PIDS/5697E9300 LVLS/630
MS/DFHAP0001 RIDS/DFHSRP PTFS/UK05570
 290 0090   AB/S00C4 AB/UAKEA RIDS/DFHLUP
ADRS/  
2007155 01:35:15.74 STC00302 0090  +DFHDU0205  CICSPH   A SYSTEM
DUMP FOR DUMPCODE: AP0001  , WAS
   SUPPRESSED BY THE DUMP TABLE
OPTION FOR THIS DUMPCODE 
2007155 01:35:15.75 STC00302 0090  +DFHAP0001  CICSPH   An abend
(code 0C4/AKEA) has occurred at offset

--
For IBM-MAIN subscribe / signoff / archive access instructions, 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: CICS Abends at startup AKEA

[Bill Wilkie]

L.

What he said PLUS check for AMODE/RMODE of any recent changes.

Bill



From: "Clark, Kevin" <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List 
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: CICS Abends at startup AKEA
Date: Tue, 5 Jun 2007 15:40:45 -0400

L.

A dump would be better than a guess, however DFHLUP is for LU services/
MRO. Perhaps you have a 24bit program trying accessing EDSA.

Do a CEMT I SYD

RESULT - OVERTYPE TO MODIFY
  Sydumpcode(SR0001)check the AP0001 also
  Sysdumping( Nosysdump )
  Dumpscope( Local )
  Shutoption( Noshutdown )
  Maximum( 003 )
  Current()
  Action(  )
  Daeoption( Nodae )


Kevin

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


_
PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows 
Live Hotmail. 
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507


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

Re: CICS Abends at startup AKEA

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler
> Sent: Tuesday, June 05, 2007 2:30 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: CICS Abends at startup AKEA
> 
> 
> Sorry for posting here, but the CICS newsgroup keeps revoking 
> me - something about bouncing. 
> 
> Anyway, we had a CICS region fail after 64 abends of the 
> following.  If anyone could provide some guidance as to where 
> to being that would be great.  The only SVC Dump is at the 
> end when we cancelled CICS (At the 65+ abend message).  And 
> there does not appear to be any AP0001 dumps due to 
> supression.  And of course management wants to know what 
> happened.  So based on this very limited info I have, can 
> anyone make a guess?  Thanks very much.
> 
> Lizette
> 



I doubt that there is sufficient information from what you have posted.
Have you considered setting a SLIP dump on that CICS region to get an
SVC dump on the S0C4 abend? Then use IPCS to look at that. My SWAG is
that you have a PLT program which is corrupting memory somehow.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
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: USS pedantry (was Friday musings on the future of 3270 applications

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Patrick O'Keefe
Sent: Tuesday, June 05, 2007 2:31 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: USS pedantry (was Friday musings on the future of 3270
applications

On Tue, 5 Jun 2007 08:21:35 -0500, Mark Zelden
<[EMAIL PROTECTED]> wrote:

>...
>Exactly... common usage and less keystrokes.  So what is the problem in

>using it in a forum like this when everyone knows exactly what it 
>means?  Are all the net jargon abbreviations"official".  Do we waste 
>time debating it?
>...
 
No, I'm not complaining about the  pedantry; I'm adding to it.

Obviously not all net jargon is "official", but IBM has (or used to
have) a list of oficial IBM abreviations and USS is (was) in it as
Unformated System Services, not Unix System Services.

Whether or not "everyone knows exactly what it means", there is not time
when I hear USS and automatically think "Unix".  Not one!  30 years of
working with VTAM guarantee that.  And if Unix for z/OS is meant, I
resent the mental stumble that causes.  (Yup.  I'm pretty
intolerent.) 


And in an ETR I had open with IBM, they [the TCP group] had to agree
that using USS for Unix System Services was causing confusion when we
also needed to discuss USS [VTAM] while discussing OMVS...

Also, I recall seeing a non-published memo (internal, but not "IBM
Confidential") where someone in support was pointing out the ambiguity
being caused by Unix System Services being referred to by USS (when it
is specifically part of VTAM) for routing of support issues

Regards,
Steve Thompson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: USS pedantry (was Friday musings on the future of 3270 applications

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Thompson, Steve
> 
> 
> 
> And in an ETR I had open with IBM, they [the TCP group] had 
> to agree that using USS for Unix System Services was causing 
> confusion when we also needed to discuss USS [VTAM] while 
> discussing OMVS...
> 
> Also, I recall seeing a non-published memo (internal, but not "IBM
> Confidential") where someone in support was pointing out the 
> ambiguity being caused by Unix System Services being referred 
> to by USS (when it is specifically part of VTAM) for routing 
> of support issues

Why not just create "our own" acronym?  How about  ZIX  (for "z/OS
UNIX")?

Alternatively, prefix USS with a V (VTAM Unformatted System Services) or
a Z (z/OS Unix System Servces).  Then we can CUSS and FUSS over VUSS and
ZUSS.  :)  (Or maybe it should be zUSS.)

-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: USS pedantry (was Friday musings on the future of 3270 applications

[R.S.]

Patrick O'Keefe wrote:
On Tue, 5 Jun 2007 08:21:35 -0500, Mark Zelden 
<[EMAIL PROTECTED]> wrote:



...
Exactly... common usage and less keystrokes.  So what is the 
problem in using it in a forum like this when everyone knows exactly 
what it means?  Are all the net jargon abbreviations"official".  Do we 
waste time debating it?

...
 
No, I'm not complaining about the  pedantry; I'm adding to it.


Obviously not all net jargon is "official", but IBM has (or used to have) a
list of oficial IBM abreviations and USS is (was) in it as Unformated 
System Services, not Unix System Services.


Whether or not "everyone knows exactly what it means", there is not
time when I hear USS and automatically think "Unix".  Not one!  30 
years of working with VTAM guarantee that.  And if Unix for z/OS is 
meant, I resent the mental stumble that causes.  (Yup.  I'm pretty
intolerent.) 


You find our pedantry irritating.  I (probably "we", but I can speak only
for myself) find your misuse of USS irritating.  So it's a draw.


Oh no, again!
Please, look at www.acronymfinder.com and find what USS can mean.
*25 results*. Not two, 25.
It is possible for acronym to have multiple meanings. So, it is not 
pedantry, it is wrong conviction, there the only one proper meaning.


Assuming, we talk English (I'm trying at least), all of the meanings can 
be abbreviated to the same acronym. Unformatted System Services in not 
worse or better than Unix System Services or Upload Speed Sense.
English dictionary, i.e. Merriam-Webster will tell you exactly what 
acronym is. The definition is clear. There is no clause it have to be 
approved by IBM or any other entity.
I don's see any reason why we should use IBM-approved acronyms. More: we 
use here (on IBM-MAIN) many other acronyms, like BTW, ITYM, FSVO, PFCSK, 
VBG to name a few. Some of them have multiple meanings, none of them is 
IBM-approved, but we still use them and *understand* them, don't we ?
We also use "semi-official" acronym SMS (should be DFSMS). Even IBM 
books are full of USS in Unix, not VTAM context.


What is *primary* meaning of USS acronym ? Well, it depends. For you and 
S.Metz it is always Unformatted System Services. For me and *any 
mainframe specialist I ever met personally* it is Unix System Services 
aka z/OS UNIX. Of course my experience in this area is limited and 
biased (VTAM is not my speciality). Maybe like yours.
For non-mainframe folks (yes there are a lot of them around us!) it is 
United States Ship, like USS Hornet or USS Pampanito.
BTW: the last meaning of USS seems to be "more official" than VTAM-one, 
since it is used by US Government and US Army... 


Again, please, don't tell us what USS is. We know it, we can check it in 
acronymfinder.com (or elsewhere), finally we can ask when in doubt.


--
Radoslaw Skorupka
Lodz, Poland


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

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

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci 
opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 
r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 
z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.

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

Re: CICS Abends at startup AKEA

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

Without a dump and IPCS we can all run our crystal balls only.
Most customer raise a PMR and deliver dumps to IBM support. 
Well in these days a comon way. 

Roland


-Original Message-
From: IBM Mainframe Discussion List 
[mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler
Sent: Tuesday, June 05, 2007 9:30 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: CICS Abends at startup AKEA


Sorry for posting here, but the CICS newsgroup keeps revoking 
me - something about bouncing. 

Anyway, we had a CICS region fail after 64 abends of the 
following.  If anyone could provide some guidance as to where 
to being that would be great.  The only SVC Dump is at the end 
when we cancelled CICS (At the 65+ abend message).  And there 
does not appear to be any AP0001 dumps due to supression.  And 
of course management wants to know what happened.  So based on 
this very limited info I have, can anyone make a guess?  Thanks 
very much.

Lizette


2007155 01:35:15.31 STC00302 0090  +DFHSI8434I CICSPH   
Control returned from PLT programs during the
   third stage of 
initialization.
2007155 01:35:15.38 STC00302 0090  +DFHSI1517  CICSPH   
Control is being given to CICS.  
2007155 01:35:15.38 STC00302 0090  +DFHSO0101I CICSPH   
Sockets domain initialization has ended. 
2007155 01:35:15.38 STC00302 0090  +DFHEJ0102  CICSPH   
Enterprise Java domain initialization has ended. 
2007155 01:35:15.73 STC00302 0090  +DFHAP0001  CICSPH   An 
abend (code 0C4/AKEA) has occurred at offset  
   X'' in module 
DFHLUP. 
2007155 01:35:15.73 STC00302 0090  +DFHME0116 CICSPH 287
 
 287 0090   (Module:DFHMEME) CICS 
symptom string for message DFHAP0001 is
 287 0090   PIDS/5697E9300 LVLS/630 
MS/DFHAP0001 RIDS/DFHSRP PTFS/UK05570
 287 0090   AB/S00C4 AB/UAKEA 
RIDS/DFHLUP ADRS/  
2007155 01:35:15.73 STC00302 0090  +DFHDU0205  CICSPH   A 
SYSTEM DUMP FOR DUMPCODE: AP0001  , WAS
   SUPPRESSED BY THE DUMP 
TABLE OPTION FOR THIS DUMPCODE 
2007155 01:35:15.74 STC00302 0090  +DFHAP0001  CICSPH   An 
abend (code 0C4/AKEA) has occurred at offset  
   X'' in module 
DFHLUP. 
2007155 01:35:15.74 STC00302 0090  +DFHME0116 CICSPH 290
 
 290 0090   (Module:DFHMEME) CICS 
symptom string for message DFHAP0001 is
 290 0090   PIDS/5697E9300 LVLS/630 
MS/DFHAP0001 RIDS/DFHSRP PTFS/UK05570
 290 0090   AB/S00C4 AB/UAKEA 
RIDS/DFHLUP ADRS/  
2007155 01:35:15.74 STC00302 0090  +DFHDU0205  CICSPH   A 
SYSTEM DUMP FOR DUMPCODE: AP0001  , WAS
   SUPPRESSED BY THE DUMP 
TABLE OPTION FOR THIS DUMPCODE 
2007155 01:35:15.75 STC00302 0090  +DFHAP0001  CICSPH   An 
abend (code 0C4/AKEA) has occurred at offset

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: USS pedantry (was Friday musings on the future of 3270 applications

[McKown, John]

I agree with R.S. . After all, we don't want to become like that
political body in France (sorry, don't remember the name) which attempts
to MANDATE how the French speaking world will use words. IIRC, the have
"outlawed" many "words" such as Le Hamburger in favor of some long
involved phrase which is "pure French". And if the acronym USS is
unclear from the context (I.e. If I'm talking a about a USS shell
script, most people should know that I'm talking UNIX and not VTAM),
then I would think that it would be up to the poster to make sure that
[s]he was clear by stating "z/OS UNIX System Services" (which I sometime
call z/UNIX) or "VTAM Unformatted System Services" (the later could be
VTAM USS because that is clear too). Actually, I usually just say UNIX
and assume that everybody here knows that I mean z/OS UNIX System
Services and not Linux or HP-UX or AIX or Solaris.

I will now bow out. I will also attempt to use my admitted small brain
to try to figure out what USS means in context. If it is unclear, I will
ask the poster.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
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

SHARE: JES2 Songbook

[Chase, John]

Who's the current "custodian"?  I have a small contribution to make.

TIA,

-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: BPXBATCH and DSNAME ENQs

[Paul Gilmartin]

On Tue, 5 Jun 2007 11:56:45 -0500, Tony Harminc wrote:
>
>>Ouch!  Dynamically creating job steps seems utterly contrary to the
>>JCL paradigm.
>
>Indeed. One of several cases where the z/OS UNIX implementation has
>unnecessarily broken existing paradigms. The surprise factor is often high.
>
"unnecessarily" indeed.  I would be overjoyed if exec() retained the
DDNAME allocations.  It would be immensely useful to be able to do
fork(), then in the child a bunch of DYNALLOCs then an exec(), or
especially an execmvs().  I recognize fork() is a horse of a different
color: it creates a new address space which had better not have any
SYSDSN ENQs in common with the parent address space.

>What happens ENQ-wise if you have two "classic" job steps where the ENQ is
>expected to last until the second one, and the *OMVSEX step is inserted in
>between? I imagine that won't have any surprises. I suppose this bahaviour
>can be explained by saying that the inserted job step provides no user
>interface to its JCL, and that therefore there is no possibility of
>affecting dataset ENQs.
>
I think we agree.  By experiment, the inserted job step is
autonomous; it shares no ENQs with the explicit job steps,
but it can suffer an ENQ conflict with a later step in the
same job, or with its parent BPXBATCH step itself.

Hmmm.  I get the ENQ conflict even if I use "//STDOUT DD SYSOUT..."
but no inserted job steps appear in the job log.

>>3 //PAUSE1   EXEC  PGM=BPXBATCH,PARM='sh exec /bin/true '
>>
>>... shows 3 generated "*OMVSEX" steps.  Hmmm.  One to exec() sh,
>>a second to exec() /bin/true.  What's the third one?  In fact, the
>>minimal:
>>
>>3 //PAUSE1   EXEC  PGM=BPXBATCH,PARM='sh exit'
>>
>>Shows 2 "*OMVSEX" steps.  Why?  But:
>>
>>3 //PAUSE1   EXEC  PGM=BPXBATCH,PARM='pgm /bin/sh -c exit'
>>
>>shows only one.  Why should 'sh ...' take one more exec() than
>>'pgm /bin/sh -c ...'?
>
>Um, I think because it implicitly runs the shell (process 1) since you
>didn't use the pgm option, then the first shell command is "sh" (process 2),
>and then under that second shell you run "/bin/true" (process 3).
>
There appears to be no implicit shell.  Unless the first argument
is either SH or PGM, I get:

   BPXM010I BPXBATCH FAILED BECAUSE THE PARAMETERS DID NOT
START WITH SH OR PGM.

I suspect the extra exec() is coming out of /etc/profile.  At
least that's sufficient excuse not to investigate further.

-- 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: IEBCOPY Unloaded dataset to PC and back again...not

[Kenneth E Tomiak]

On Mon, 4 Jun 2007 17:50:10 -0500, Paul Gilmartin 
<[EMAIL PROTECTED]> wrote:


>like).
>
>What client are you using, and what does it do with "quote stru r"?
>
>On Solaris 10, I readily get:
>
>[EMAIL PROTECTED]:331$ uname -a
>SunOS solaris 5.10 Generic_118855-36 i86pc i386 i86pc
>

What a large portion of the world might try first, the regular FTP command 
from a windows/xp DOS style command window. It handles quote and quote 
site, it does not like 'stru r'. My GUI ftp application has no hidden settings, 
all 
are viewable by looking at the properties of the site. I even went beyond the 
norm and tried fudging the DCB attributes of the file both before and after the 
ftp process to no avail. Using quote site rdw did get the record descriptior 
word passed, but the records did not go back in their original length. Thus 
giving the same error the OP showed, the first record is not 64 bytes. Have 
you tried to feed the uploaded file back through IEBCOPY to populate a new 
PDS? That is where we see the file is no good.

ftp> quote site stru r
200-Unrecognized parameter 'stru' on SITE command.
200-Unrecognized parameter 'r' on SITE command.
200 SITE command was accepted
ftp> site stru r
Invalid command.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: BPXBATCH and DSNAME ENQs

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin
> Sent: Tuesday, June 05, 2007 4:02 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: BPXBATCH and DSNAME ENQs
> 
> 



> "unnecessarily" indeed.  I would be overjoyed if exec() retained the
> DDNAME allocations.  It would be immensely useful to be able to do
> fork(), then in the child a bunch of DYNALLOCs then an exec(), or
> especially an execmvs().  I recognize fork() is a horse of a different
> color: it creates a new address space which had better not have any
> SYSDSN ENQs in common with the parent address space.
> 



> -- gil

Gil,

Are you sure the exec() FREEs the allocations? That sounds strange to
me. I know that fork() ends up in another address space (except where
_BPX_SHAREAS is honored) and so the program invoked via exec() ends up
without the original address space's allocations. I didn't realize that
exec() itself did any deallocation of allocated DDs. I may test that
tomorrow.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
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: IEBCOPY Unloaded dataset to PC and back again...not

[Jim Phoenix]

Kenneth E Tomiak wrote:
On Mon, 4 Jun 2007 17:50:10 -0500, Paul Gilmartin 
<[EMAIL PROTECTED]> wrote:



  

like).

What client are you using, and what does it do with "quote stru r"?

On Solaris 10, I readily get:

[EMAIL PROTECTED]:331$ uname -a
SunOS solaris 5.10 Generic_118855-36 i86pc i386 i86pc




What a large portion of the world might try first, the regular FTP command 
from a windows/xp DOS style command window. It handles quote and quote 
site, it does not like 'stru r'. My GUI ftp application has no hidden settings, all 
are viewable by looking at the properties of the site. I even went beyond the 
norm and tried fudging the DCB attributes of the file both before and after the 
ftp process to no avail. Using quote site rdw did get the record descriptior 
word passed, but the records did not go back in their original length. Thus 
giving the same error the OP showed, the first record is not 64 bytes. Have 
you tried to feed the uploaded file back through IEBCOPY to populate a new 
PDS? That is where we see the file is no good.


ftp> quote site stru r
200-Unrecognized parameter 'stru' on SITE command.
200-Unrecognized parameter 'r' on SITE command.
200 SITE command was accepted
ftp> site stru r
Invalid command.

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

  
STRU is not a valid SITE sub-command.  Rather it is a command in it's 
own right.  Use quote stru r, not quote site stru r.


--
| Jim Phoenix  | Voice:   (310) 338-0400 x316   |
| Senior Software Developer| Fax: (310) 338-0801|
| Phoenix Software International   | Alt fax: (310) 337-2685|
| 5200 W. Century Blvd., Suite 800 | [EMAIL PROTECTED] |
| Los Angeles, CA 90045| http://www.phoenixsoftware.com |

Opinions expressed by this individual are not necessarily those of the Company.

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

[no subject]

[George, William (DHS-ITSD)]

A peer of mine is caught in a bind. 

He entered a command in the COMMAND field of the logon screen. The
command was one he cut and pasted from and email sent to him explaining
what to enter there. Unfortunately, the quotes around the
dataset(member) were MS word type quotes (forward and backword quotes).
His attempt to logon errored and he tried to get back to the logon
screen to fix his problem. 

However, apparently those quotes are non-displayable characters for TSO
(or ISPF) and are stored no permanently in his profile.

He now continually gets a screen eraser error when ever the LOGON panel
attempts to display.

I'm assuming this is due to the COMMAND field having that
non-displayable character stored there. He is unable to clear this.

 

Anyone know of a means, via a non sysprog point of view, to clear the
COMMAND field on the logon panel so he may start fresh.

 

Bill


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

Re: SHARE: JES2 Songbook

[Frank I Rosenzweig]

Current custodian is Helen Seren ([EMAIL PROTECTED]). Contact her directly
for submission criteria.

FIR

On 6/5/07, Chase, John <[EMAIL PROTECTED]> wrote:


Who's the current "custodian"?  I have a small contribution to make.

TIA,

-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

TSO LOGON Issue (resend with subject)

[George, William (DHS-ITSD)]

 

A peer of mine is caught in a bind. 

He entered a command in the COMMAND field of the logon screen. The
command was one he cut and pasted from and email sent to him explaining
what to enter there. Unfortunately, the quotes around the
dataset(member) were MS word type quotes (forward and backword quotes).
His attempt to logon errored and he tried to get back to the logon
screen to fix his problem. 

However, apparently those quotes are non-displayable characters for TSO
(or ISPF) and are stored no permanently in his profile.

He now continually gets a screen eraser error when ever the LOGON panel
attempts to display.

I'm assuming this is due to the COMMAND field having that
non-displayable character stored there. He is unable to clear this.

 

Anyone know of a means, via a non sysprog point of view, to clear the
COMMAND field on the logon panel so he may start fresh.

 

Bill


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

Re: How do i install Linux on S/390 Machine

[Kenneth E Tomiak]

Just because GOOGLE can find it does not mean you can view it without your 
SHARE userid. And if you can, something is broken because you should need 
to sign in.

It is also under Washington DC #2814. The session sometimes was sponsored 
by two projects at the same time and so it has a 28xx and a 93xx number. 
And then it drifted into the Linux Project before Curt stopped presenting. If 
you are searching the SHARE proceedings you should focus on the title since 
the session number can change from conference to conference.

>On Mon, 4 Jun 2007 22:57:53 -0500, Mohan <[EMAIL PROTECTED]> 
wrote:

>Hi Ed,
>
>When i googled, below is the SHARE session number i got it that Jack was
>refereing to.
>
>9314 - Linux in an LPAR - Here's How It's Done, since i do not have access
>to SHARE I'm unable to look at it further.
>
>
>Thanks
>
>Mohan
>
>>
>>> That would violate SHARE's policy. There are still plenty of
>>> redbooks and other presentations you can find by searching the web.
>>> Or get your company to join SHARE.
>>>

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

[Schwarz, Barry A]

If you don't have some form of special, you cannot do it for another
user.

-Original Message-
From: George, William (DHS-ITSD) [mailto:snip] 
Sent: Tuesday, June 05, 2007 2:53 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: TSO LOGON Issue

Thanks Barry. I just tried it myself but received a RACF error.
I'll attempt to find someone that can issue this command. 

Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Schwarz, Barry A
Sent: Tuesday, June 05, 2007 2:48 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: 

Have someone with system special issue 
ALU user TSO(NOCOMMAND)

Possibly have the user logon through telnet or other non-3270 method and
issue the command himself.  Not sure how much authority a user has over
his own account.

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

[George, William (DHS-ITSD)]

Thanks Barry. I just tried it myself but received a RACF error.
I'll attempt to find someone that can issue this command. 

Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Schwarz, Barry A
Sent: Tuesday, June 05, 2007 2:48 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: 

Have someone with system special issue 
ALU user TSO(NOCOMMAND)

Possibly have the user logon through telnet or other non-3270 method and
issue the command himself.  Not sure how much authority a user has over
his own account.

-Original Message-
From: George, William (DHS-ITSD) [mailto:snip] 
Sent: Tuesday, June 05, 2007 2:23 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: 

A peer of mine is caught in a bind. 

He entered a command in the COMMAND field of the logon screen. The
command was one he cut and pasted from and email sent to him explaining
what to enter there. Unfortunately, the quotes around the
dataset(member) were MS word type quotes (forward and backword quotes).
His attempt to logon errored and he tried to get back to the logon
screen to fix his problem. 

However, apparently those quotes are non-displayable characters for TSO
(or ISPF) and are stored no permanently in his profile.

He now continually gets a screen eraser error when ever the LOGON panel
attempts to display.

I'm assuming this is due to the COMMAND field having that
non-displayable character stored there. He is unable to clear this.

 

Anyone know of a means, via a non sysprog point of view, to clear the
COMMAND field on the logon panel so he may start fresh.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Interesting(?) observation - IOCP on a z9BC

[Roy Hewitt]

Dave Kopischke wrote:

On Tue, 5 Jun 2007 11:28:42 +0100, Roy Hewitt wrote:


You dont even need to create the IOCDS, remember the IOCDS is only ever
used at POR time...so if PORs are hard to come by, then you can defer it
until you really need to...



If you don't create and activate a new IOCDS with the IODF, I believe you'll 
get hardware/software mismatch messages at every IPL until you get them 
synched up. Depending on your environment, you might have trouble finding 
the matching IOCDS if you let it languish for a long time. I would suggest a 
policy of keeping them synched up to avoid subsequent problems.


Dave,

I completely agree that it is a very good policy to always update an 
IOCDS when you update an IODF.. you never know when you will do that 
unexpected POR! But the IOCDS is only ever used at CPC POR time, and has 
nothing to do with the 'sync' issue with an ACTIVATE, neither has it 
anything to do with IPL processing. Both these events use information in 
the currently active hardware config loaded in HSA. This might have been 
loaded from an IOCDS at POR, but could also have come from a previous 
ACTIVATE..


If you do POR from an out of date IOCDS, then yes, you can end up in a 
mess as the automatic selection (if you are set up that way) of the IODF 
will probably choose a non-synced config, and then ACTIVATES become 
something of a 'struggle'..


Just to reiterate, my point was that there is no great rush to POR.. 
plus John should still be able write an IOCDS using one of the methods 
mentioned.


Regards

Roy

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: BPXBATCH and DSNAME ENQs

[Paul Gilmartin]

On Tue, 5 Jun 2007 16:15:51 -0500, McKown, John wrote:
>
>> "unnecessarily" indeed.  I would be overjoyed if exec() retained the
>> DDNAME allocations.  It would be immensely useful to be able to do
>> fork(), then in the child a bunch of DYNALLOCs then an exec(), or
>> especially an execmvs().
>
>Are you sure the exec() FREEs the allocations? That sounds strange to
>me. I know that fork() ends up in another address space (except where
>_BPX_SHAREAS is honored) and so the program invoked via exec() ends up
>without the original address space's allocations. I didn't realize that
>exec() itself did any deallocation of allocated DDs. I may test that
>tomorrow.
>
Ah, a gentle RTFM ("F" stands for "Friendly" -- I had to search
for it.)  In:

Title: z/OS V1R7.0 UNIX System Services Programming:
Assembler Callable Services Reference
Document Number: SA22-7803-08

2.30 exec (BPX1EXC, BPX4EXC) -- Run a program
 ...
   The exec service dynamically inserts into a job a new job step that has
   no allocations associated with it, with the exception of the MVS data
   sets that may be built into the STEPLIB environment for the new process
   image.

-- 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: z/OS Documentation? Ouch!

[Kenneth E Tomiak]

>From two recent projects I am involved in, I have sent in close to 50 
corrections in for three manuals. I have not received feedback on the 20 or so 
emails, but they have been trickling back in. An email does not get the same 
priority as a problem report. If you can code the command the way the 
manual describes it and it causes a situation, report it as problem.

>On Tue, 5 Jun 2007 09:11:03 -0500, Paul Gilmartin 
<[EMAIL PROTECTED]> wrote:


>>
>Well, I chose to defer the skip-level and to appeal to the tech writer
>to (appeal to the developer to) reconsider:
>
>I was extremely disappointed by that, focusing on the
>sentence:
>
>... I probably would not say anything about the
>syntax rules that are followed because you may
>give misleading information.
>
>It is the responsibility of a Command Reference to provide
>a correct specification of the command syntax so that
>programmers don't develop their own "misleading information".
>Please go back to the developer; ask him to consult the
>design document if necessary, and to determine what the
>intended syntax of the command is and to produce suitable
>input for the next edition of the Command Reference.  If
>necessary, take the draft to your test group to validate
>that the product actually conforms to the specification.
>

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

[no subject]

[Schwarz, Barry A]

Have someone with system special issue 
ALU user TSO(NOCOMMAND)

Possibly have the user logon through telnet or other non-3270 method and
issue the command himself.  Not sure how much authority a user has over
his own account.

-Original Message-
From: George, William (DHS-ITSD) [mailto:snip] 
Sent: Tuesday, June 05, 2007 2:23 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: 

A peer of mine is caught in a bind. 

He entered a command in the COMMAND field of the logon screen. The
command was one he cut and pasted from and email sent to him explaining
what to enter there. Unfortunately, the quotes around the
dataset(member) were MS word type quotes (forward and backword quotes).
His attempt to logon errored and he tried to get back to the logon
screen to fix his problem. 

However, apparently those quotes are non-displayable characters for TSO
(or ISPF) and are stored no permanently in his profile.

He now continually gets a screen eraser error when ever the LOGON panel
attempts to display.

I'm assuming this is due to the COMMAND field having that
non-displayable character stored there. He is unable to clear this.

 

Anyone know of a means, via a non sysprog point of view, to clear the
COMMAND field on the logon panel so he may start fresh.

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

[Paul Gilmartin]

On Tue, 5 Jun 2007 15:00:43 -0700, Neubert, Kevin (DIS) wrote:

>Just a guess...   Determine the variable in question then remove it via
>ISPEXEC VERASE.
>
>From a batch job?

>From a linemode TSO session?

Catch 22?

>-Original Message-
>Behalf Of George, William (DHS-ITSD)
>Sent: Tuesday, June 05, 2007 2:26 PM
>
>Anyone know of a means, via a non sysprog point of view, to clear the
>COMMAND field on the logon panel so he may start fresh.

-- 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: TSO LOGON Issue (resend with subject)

[George, William (DHS-ITSD)]

Kevin

It appears to be a RACF 'variable' of which I or the person in question
do not have auth to change. Looks like it is just a matter of finding
someone with RACF authority to fix this.

Thanks
Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Neubert, Kevin (DIS)
Sent: Tuesday, June 05, 2007 3:01 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: TSO LOGON Issue (resend with subject)

Just a guess...   Determine the variable in question then remove it via
ISPEXEC VERASE.

Regards,

Kevin

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of George, William (DHS-ITSD)
Sent: Tuesday, June 05, 2007 2:26 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: TSO LOGON Issue (resend with subject)

Anyone know of a means, via a non sysprog point of view, to clear the
COMMAND field on the logon panel so he may start fresh.

 

Bill


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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: 1.7 and Internal Reader

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 06/05/2007
   at 07:50 AM, Daniel McLaughlin <[EMAIL PROTECTED]>
said:

>Has anyone else had their venerable internal reader proc go crazy
>under 1.7?  Ours gets JCL errors and doesn't pull the job to submit.
>Must be some more  holes that got close in this release. Here is what
>we use, which shows an  override error on IEFPROC.IEFRDER.

My guess is that the difference is not the release but the contents of
the START command. Does the START fail when you specify only the proc
name, the FILE keyword and the MEM keyword?

>//SYSUT1DD DSN=&FILE(&MEM),
> // DISP=SHR

That's not the venerable command; See Rich's response.


In <[EMAIL PROTECTED]>, on
06/05/2007
   at 05:58 AM, Rich Tabor <[EMAIL PROTECTED]> said:

>Probably needs to be something like:

>//SYSUT1 DD DDNAME=IEFRDER
>//IEFRDER DD DSN=&FILE(&MEM),DISP=SHR

Yes, if he's using a DD override on the START command.
That's not a new requirement, either.

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

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

Re: EZtrieve query

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 06/04/2007
   at 02:44 PM, Howard Brazee <[EMAIL PROTECTED]> said:

>My provider shows bit.listserv.ibm-main which contains a copy of this
>listserve.

IBM-MAIN is gated to bit.listserv.ibm-main, but articles in
bit.listserv.ibm-main are not gated to IBM-MAIN. If you want people
reading the list to see it, you need to send it to the list.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

operator display command with response

[Harold Zbiegien]

Anyone know of any program that I could issue an operator display type command 
and receive back the response?

Something like a vtam programmed operator but for system commands.

Harold Zbiegien

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

HSM recall to tape

[Harold Zbiegien]

We are in the middle of implementing a virtual tape system. And one of the 
goals is to dismantle our current TMM (tape mount management) system which is a 
combination of SMS rules and HSM.

We want to recall all of our migrated files and write them to tape.  The HSM 
RECALL command will recall a file to disk, but not to tape.

Does any one have any tips or suggestions?

Harold Zbiegien

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: TSO LOGON Issue (resend with subject)

[Neubert, Kevin (DIS)]

Just a guess...   Determine the variable in question then remove it via
ISPEXEC VERASE.

Regards,

Kevin

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of George, William (DHS-ITSD)
Sent: Tuesday, June 05, 2007 2:26 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: TSO LOGON Issue (resend with subject)

Anyone know of a means, via a non sysprog point of view, to clear the
COMMAND field on the logon panel so he may start fresh.

 

Bill


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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: TSO LOGON Issue (resend with subject)

[Jim Harrison]

The logon screen is a VTAM display, not ISPF, so VERASE or anything 
TSO-wise won't work.  I think you need to contact your sysprogs.  I 
have no idea where that information is stored between logons and I 
doubt you or your friend will have authority to mess with it.



At 06:04 PM 6/5/2007, George, William (DHS-ITSD) said:

Kevin

It appears to be a RACF 'variable' of which I or the person in question
do not have auth to change. Looks like it is just a matter of finding
someone with RACF authority to fix this.

Thanks
Bill

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Neubert, Kevin (DIS)
Sent: Tuesday, June 05, 2007 3:01 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: TSO LOGON Issue (resend with subject)

Just a guess...   Determine the variable in question then remove it via
ISPEXEC VERASE.

Regards,

Kevin

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of George, William (DHS-ITSD)
Sent: Tuesday, June 05, 2007 2:26 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: TSO LOGON Issue (resend with subject)

Anyone know of a means, via a non sysprog point of view, to clear the
COMMAND field on the logon panel so he may start fresh.



Bill


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

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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: HSM recall to tape

[Paul Gilmartin]

On Tue, 5 Jun 2007 18:25:13 -0400, Harold Zbiegien wrote:
>
>We want to recall all of our migrated files and write them to tape.  The HSM 
>RECALL command will recall a file to disk, but not to tape.
>
>Does any one have any tips or suggestions?
>
Where are they now?  ML1?  If so, wait until ML2 moves them to tape
on its own accord.

-- 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: TSO LOGON Issue (resend with subject)

[Paul Gilmartin]

On Tue, 5 Jun 2007 18:29:12 -0400, Jim Harrison wrote:

>The logon screen is a VTAM display, not ISPF, so VERASE or anything
>TSO-wise won't work.  I think you need to contact your sysprogs.  I
>have no idea where that information is stored between logons and I
>doubt you or your friend will have authority to mess with it.
>
Eek!  A one-way trapdoor.  I was thinking that if it allows
the user to break it, it ought by symmetry to allow the user
to fix it.  My thought was (finally a use for ISPGUI!), start
an ISPGUI session, bypassing the logon panels, and change
the value from the RACF panels.  Alas, the variable seems
not to appear in those panels.  It should.

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