Re: 3DES encryption using ICSF callable services

[John Blythe Reid]

Rob, no the key does not exist in the CKDS but is received as part of a request 
from a client browser in this string:

123456

The key tag shows the 16 hexadecimal digits of a single length DES key that 
must be used to encrypt the response. The browser randomly generates the DES 
key and includes it in the request so that the server (z/OS in this case) can 
use it to encrypt the response.

Regards,
John.

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

Re: Fastest way to read OLDEST GDG entry

[Longabaugh, Robert E]

The Generation data set is in a deferred roll-in status when it is allocated.  
It becomes part of the rolled in generations during the deallocation phase.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, November 19, 2015 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fastest way to read OLDEST GDG entry

On Thu, 19 Nov 2015 15:59:37 +, J O Skip Robinson wrote:

>I haven't experimented with this, but going with NOSCRATCH is likely to 
>cause big problems with DASD GDGs. A data set residing on an 
>SMS-managed volume must be cataloged.

It has been a long time since I looked at this, but what I remember is that 
GDGs were a special case. For one thing, with SMS, a data set is cataloged at 
allocation time, not at step end like it was before.

One consequence of that is that is that a generation may be scratched as soon 
as the new one is allocated, rather than wait until the step ends successfully.

Consider a new GDG created with NEW,CATLG,DELETE. Before SMS, the old 
generation was scratched at the time the new one is cataloged at the end of the 
step, when the new one is cataloged.

As a result, the idea of a generation being rolled in and rolled out was 
created. The data set is cataloged, but is not cataloged as part of the GDG.

--
Tom Marchant

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

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

Re: AW: Re: Fastest way to read OLDEST GDG entry

[Paul Gilmartin]

On Wed, 18 Nov 2015 09:17:25 -0800, John Mattson wrote:
>...
>   A third possibility which is kludgy would be to create each new DS with
>a unique DATETIME in the DSN and then do the catalog list and search for
>the oldest date.  No roll-off, no problems with new GDGs coming in.
>
Alas, JCL has no facility for creating a new DS with a unique DATETIME
in the DSN.  GDGs provide this in JCL.

-- gil

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

Re: AW: Re: Fastest way to read OLDEST GDG entry

[Lizette Koehler]

Gil,
You can use the symbols for DATE and HOUR and so forth.  I think it is 
documented  z/OS 2.1.0>z/OS MVS>z/OS MVS Initialization and Tuning 
Reference>Overview>Sharing parmlib definitions>What are system symbols?>Dynamic 
system symbols

https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/dynpsm.htm


New symbol  Old symbol
 

 


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Thursday, November 19, 2015 10:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: AW: Re: Fastest way to read OLDEST GDG entry
> 
> On Wed, 18 Nov 2015 09:17:25 -0800, John Mattson wrote:
> >...
> >   A third possibility which is kludgy would be to create each new DS
> >with a unique DATETIME in the DSN and then do the catalog list and
> >search for the oldest date.  No roll-off, no problems with new GDGs coming 
> >in.
> >
> Alas, JCL has no facility for creating a new DS with a unique DATETIME in the 
> DSN.
> GDGs provide this in JCL.
> 
> -- gil
> 

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

Re: TSO RECEIVE under UNIX Rexx (was: REXX-question)

[Elardus Engelbrecht]

Paul Gilmartin wrote:

>RECEIVE is extraordinarily ill-suited to automation:
>o The user has no a priori control over which spool file will be RECEIVEd.
>o The user must be present to reply to a prompt.

That is very true. JES2 simply gives to you what it seemed to be the first. I 
could not find the reason/algorithm for how RECEIVE and JES2 decide what to 
present to the receiver. 

I recommend using FTP instead of XMIT/RECEIVE for another reason - Speed and no 
filling up of JES2 spool.

>TSO developers (are there any such?) would do well to learn from CMS.
>How about: RECEIVE [JOB(jobID[.dsid])] [REPLY('reply-string')]

Well, ask IBM [formally of course]! Perhaps they can review your suggestion.

Groete / Greetings
Elardus Engelbrecht

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

Re: AW: Re: Fastest way to read OLDEST GDG entry

[Paul Gilmartin]

On Thu, 19 Nov 2015 10:58:01 -0700, Lizette Koehler wrote:

>Gil,
>You can use the symbols for DATE and HOUR and so forth.  I think it is 
>documented  z/OS 2.1.0>z/OS MVS>z/OS MVS Initialization and Tuning 
>Reference>Overview>Sharing parmlib definitions>What are system 
>symbols?>Dynamic system symbols
>
>https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/dynpsm.htm
>
>
>New symbol Old symbol
>
>   
>
>   
> 
Hmmm...  I think that's new in 2.1.  I haven't tried it.

o If two jobs are submitted close in time, is there a possibility of DSN 
conflict?
  I believe GDG would eliminate this.

o IBM contributors have acknowledged here that there's a timing window:
  if  and  are referenced close to midnight (who'd ever
  schedule a job for midnight!?) a 23 hour 59 minute error might result if
  the date changes between the two references.

  Why doesn't IBM fix that?  Rexx does it right.  JCL developers should read
  the Rexx manual to see how.

-- gil

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

Re: TSO RECEIVE under UNIX Rexx (was: REXX-question)

[Paul Gilmartin]

On Thu, 19 Nov 2015 12:18:23 -0600, Elardus Engelbrecht wrote:
>
>>RECEIVE is extraordinarily ill-suited to automation:
>>o The user has no a priori control over which spool file will be RECEIVEd.
>>o The user must be present to reply to a prompt.
>
>That is very true. JES2 simply gives to you what it seemed to be the first. I 
>could not find the reason/algorithm for how RECEIVE and JES2 decide what to 
>present to the receiver. 
> 
Deep within the Rexx SDSF API, a program can cause SDSF to ALLOCATE
a DSID to a SYS00nnn DD name.  The programmer could use that in
RECEIVE INDD(SYS00nnn) (I think; I haven't tried it.), gaining control of
what to RECEIVE.

>I recommend using FTP instead of XMIT/RECEIVE for another reason - Speed and 
>no filling up of JES2 spool.
> 
I like a combination of sftp and pax.

-- gil

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

"tapehlq" parm in IGGCATxx

[Bonno, Tuco]

this is re: z/os 2.2  
can anybody throw some light on the USAGE of the "tapehlq" parm in IGGCATxx?
and please, nobody say "it specifies the hlq for a tape volume catalog" [and, 
btw, the default is SYS1]  -- i have made an effort here, consulted the 2.2 
init & tuna REFERENCE ,   even searched in ibm's "info center" as well as in 
their "knowledge center"  AND  even looked the 2.2 init and tuning GUIDE [when 
all else fails, read the intstructions]
 – got nothing.
the parameter does NOT exist in z/os 1.13 – so what's its purpose? the 
INTENTION behind it?   HOW do you use it?

TIA !!

/s/ tuco bonno;
graduate, College of Conflict Management, University of SouthEast Asia;
I partied on the Ho Chi Minh trail, "tiến lên!"

The South Carolina
Department of Administration
4430 Broad River Road, Columbia, SC 29210
896.0176



Note: Act 121 of 2014 (SC Restructuring Act of 2014) abolished the Budget and 
Control Board. Effective July 1, 2015, the Department of Administration has 
been established. Please update your contact information.


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

Re: (External):Re: Deleting all members of a pds

[J O Skip Robinson]

Can also be accomplished with PDS[85] command or StarTool product. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, November 19, 2015 3:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Deleting all members of a pds

I have installed the CBTTAPE.ORG utility PDSCLEAN for both PDS and PDSE 
datasets an it works very well.  File 693.

Lizette



-Original Message-
>From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
>Sent: Nov 19, 2015 3:51 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Deleting all members of a pds
>
>On 2015-11-19 14:54, Ed Finnell wrote:
>> File 182 on CBT tape contains PDS command. It's a great tool. Can 
>> delete or  delete by mask add space, copy, merge and fix. The 
>> commercial version is Startools from Serena. Has saved my bacon numerous 
>> times.
>>  
> STOW  DCB,,I
>
>I believe (or hope) PDS uses that nowadays, since its older technique, 
>basically zapping the directory, didn't work for PDSE.
>
>> In a message dated 11/19/2015 3:43:17 P.M. Central Standard Time, 
>> johnmattson...@gmail.com writes:
>> 
>> Someone  was asking about deleting all members of a pds.  I just 
>> noticed that  DFSort has a bunch of "samples" one of which includes 
>> how to use ICETOOL to  delete all members of a PDS.  Hope this helps.  
>> Lots of  other neat things in here  too.
>
>I hope it (and IDCAMS) uses STOW.  Deleting members one-by-one can be 
>expensive.
>But if so, first sort in reverse order.
>
>I'm not going to measure timings
>
>-- gil


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

Re: Deleting all members of a pds

[Paul Gilmartin]

On 2015-11-19 15:04, R.S. wrote:
> W dniu 2015-11-19 o 22:42, John Mattson pisze:
>> Someone was asking about deleting all members of a pds.  I just noticed
>> that DFSort has a bunch of "samples" one of which includes how to use
>> ICETOOL to delete all members of a PDS.  Hope this helps.  Lots of other
>> neat things in here too.
>> http://www-01.ibm.com/support/docview.wss?uid=isg3T794
> Smart DFSORT tricks! 
>
I looked at that.  It builds a list of IDCAMS commands to delete the members
one-by-one.  Now that there are better techniques, it becomes less smart.
Does it at least sort the list in descending order?  Does IDCAMS
DELETE DATA.SET.NAME(*)
use STOW ,,I?

> I was really proud to be one of the tricks authors!
> Recently I was placed in some redpaper about exploitation of large amount of 
> memory, again it was related to DFSORT.
> :-)
> 

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

Re: TSO RECEIVE under UNIX Rexx (was: REXX-question)

[J O Skip Robinson]

The OUTPUT command (at least here) shows only Held output. XMITted files must 
be in (non-held) Output. If I try to see my file via OUTPUT, I get

IKJ56339I NO HELD OUTPUT FOR JOB my-userid

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Itschak Mugzach
Sent: Thursday, November 19, 2015 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: TSO RECEIVE under UNIX Rexx (was: REXX-question)

How about TSO output command to list all waiting files?

ITschak

ITschak Mugzach
Z/OS, ISV Products and Application Security & Risk Assessments Professional

On Thu, Nov 19, 2015 at 8:33 PM, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 19 Nov 2015 12:18:23 -0600, Elardus Engelbrecht wrote:
> >
> >>RECEIVE is extraordinarily ill-suited to automation:
> >>o The user has no a priori control over which spool file will be
> RECEIVEd.
> >>o The user must be present to reply to a prompt.
> >
> >That is very true. JES2 simply gives to you what it seemed to be the
> first. I could not find the reason/algorithm for how RECEIVE and JES2 
> decide what to present to the receiver.
> >
> Deep within the Rexx SDSF API, a program can cause SDSF to ALLOCATE a 
> DSID to a SYS00nnn DD name.  The programmer could use that in RECEIVE 
> INDD(SYS00nnn) (I think; I haven't tried it.), gaining control of what 
> to RECEIVE.
>
> >I recommend using FTP instead of XMIT/RECEIVE for another reason - 
> >Speed
> and no filling up of JES2 spool.
> >
> I like a combination of sftp and pax.
>
> -- gil


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

Re: Earlier than a z9?

[Tony Thigpen]

Yes.

I have a customer running OS/390 on an MP2000. We expect them to be off 
by the end of the year. We spent many an hour trying to find a way to 
move them to a current platform before they decided to put more dollars 
into their off-platform conversion.


I have a customer running OS/390 on a z800.

We recently moved a customer running OS/390 2.10 to a z/10.

I had a customer decommission VM on an MP2000 less than one year ago.

I know of several VSE shops running Integrated Servers.

I know of several VSE shops running FSI Flex boxes.


Tony Thigpen

Phil Smith wrote on 11/19/2015 05:59 PM:

Is anyone running on real hardware that's older than a z9? Off-list replies 
would be fine-not trying to embarrass anyone, trying to figure out whether 
there's any real work taking place on such ancient iron. Connor, you don't need 
to reply :)



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




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

Re: Earlier than a z9?

[William Donzelli]

A 4300 system was recently decommissioned out West, and the system was
broken apart. I think the processor and DASD went to a collector. The
card handling equipment will be coming east to me - real S/360 era
stuff that still works.

It seems the 4300 line were perhaps IBM's best machines - they never
broke, apparently. Mine (4331) never had a service call in its 30 year
working career. Other collector have similar stories.

But no, I do not know of any IBM older than a Z still in working
service. I certainly would like to know, now that those boxes should
probably now be saved. The same applies to older tape, DASDs, and
communication boxes. And software, of course...

Yes, I know this is an IBM list, but the crown for elderly machines
still in service belongs to Control Data. There are still a few Cyber
180s in active duty, and even a 1700 going *past* its 50th year.

--
Will

On Thu, Nov 19, 2015 at 5:59 PM, Phil Smith  wrote:
> Is anyone running on real hardware that's older than a z9? Off-list replies 
> would be fine-not trying to embarrass anyone, trying to figure out whether 
> there's any real work taking place on such ancient iron. Connor, you don't 
> need to reply :)
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: SMPE apply excluding certain FMID's?

[CM Poncelet]

You could collect all the FMIDs you want to install (in/excluding e.g. 
Omegamon etc.) into a single SOURCEID - and then install these FMIDs via 
an "APPLY SOURCEID()". CP


Neubert, Kevin wrote:


Not elegant, but perhaps workable?

Build your list:

LIST FUNCTIONS SYSMOD.

Your list sans OMEGAMON:

APPLY CHECK FORFMID (<<>>).

See "Figure 3. Combining SYSMOD selection operands on the APPLY Command," in "Chapter 3. The 
APPLY command" of "SMP/E for z/OS Commands (SA23-2275)" for a nice visual on processing order 
if you need further selection operands like SOURCEID/EXSRCID, etc.

Regards,

Kevin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Thursday, November 19, 2015 4:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPE apply excluding certain FMID's?

All,  I don't think this can be done after RTFMing, but wanted to make sure no 
one has some trick up their sleeves.   Just received my z/OS 2.2 serverpac, and 
this time around, decided to include my Omegamon suite of products with it.   
The question I have, is while my group manages the SMPe maintenance for 
Omegamon, the individual components are cared for and fed by the groups that 
use them (ie. DB2 team looks at reviews OMEG DB2 hold data, etc).   So, I've 
created an FMIDset of the Omeg FMID's to use for applying maintenance so that 
passing the relevant hold data along to those groups is easier.But what I 
don't see is a way to run a SMPE apply for everything else EXCLUDING these 
FMID's in the OMEGAMON FMIDset.  Can that be done?   I know that I could go to 
the effort to move these FMID's into their own zones, but that would be a lot 
of work, and that's not how my serverpac came.

Just looking if anyone had any suggestions that I haven't thought about.

Dave

_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

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 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


 



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

Re: Earlier than a z9?

[Charles Mills]

Like us, Phil is a vendor. For a vendor, the relevant questions are not "do
any of these things exist somewhere and powered on?" but rather

- Are any of our customers running box X? (Should be a question that can be
answer by better means than this listserve.)
- Are there any customers (prospects if you will) running box X and
*conceivably* in the market for new mainframe software (as opposed to "we're
not spending another nickel on that thing" or hobbyists like Mr. Krukosky).

Not criticizing anyone here. (In fact I sent a detailed private note to Phil
with some of our specifics in this regard.) Just trying to shed my light on
the subject from a practical point of view.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tony Thigpen
Sent: Thursday, November 19, 2015 4:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Earlier than a z9?

Yes.

I have a customer running OS/390 on an MP2000. We expect them to be off by
the end of the year. We spent many an hour trying to find a way to move them
to a current platform before they decided to put more dollars into their
off-platform conversion.

I have a customer running OS/390 on a z800.

We recently moved a customer running OS/390 2.10 to a z/10.

I had a customer decommission VM on an MP2000 less than one year ago.

I know of several VSE shops running Integrated Servers.

I know of several VSE shops running FSI Flex boxes.

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

Re: Earlier than a z9?

[Charles Mills]

How about the Halon system? Do you have one of those?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Connor Krukosky
Sent: Thursday, November 19, 2015 3:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Earlier than a z9?

Doh, should have included these photos.
http://imgur.com/a/C6zsx
I'm sure you all will enjoy them. And yes he got those HUGE DASDs as-well,
can't wait to hear one of those spin up :) Ignore the photos of the guts of
the 4341, I was tasked with taking the section of power-supply off the main
CPU cabinet so it would fit on the lift gate of the truck and thus took some
photos to remember where everything went.
So I can't say I haven't been in the guts of a mainframe prior to the
z890 :P
Also I am actually going back to that place this Saturday to get the raised
floor because free raised floor is nice :)

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

Re: SMPE apply excluding certain FMID's?

[Neubert, Kevin]

Not elegant, but perhaps workable?

Build your list:

LIST FUNCTIONS SYSMOD.

Your list sans OMEGAMON:

APPLY CHECK FORFMID (<<>>).

See "Figure 3. Combining SYSMOD selection operands on the APPLY Command," in 
"Chapter 3. The APPLY command" of "SMP/E for z/OS Commands (SA23-2275)" for a 
nice visual on processing order if you need further selection operands like 
SOURCEID/EXSRCID, etc.

Regards,

Kevin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Thursday, November 19, 2015 4:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPE apply excluding certain FMID's?

All,  I don't think this can be done after RTFMing, but wanted to make sure no 
one has some trick up their sleeves.   Just received my z/OS 2.2 serverpac, and 
this time around, decided to include my Omegamon suite of products with it.   
The question I have, is while my group manages the SMPe maintenance for 
Omegamon, the individual components are cared for and fed by the groups that 
use them (ie. DB2 team looks at reviews OMEG DB2 hold data, etc).   So, I've 
created an FMIDset of the Omeg FMID's to use for applying maintenance so that 
passing the relevant hold data along to those groups is easier.But what I 
don't see is a way to run a SMPE apply for everything else EXCLUDING these 
FMID's in the OMEGAMON FMIDset.  Can that be done?   I know that I could go to 
the effort to move these FMID's into their own zones, but that would be a lot 
of work, and that's not how my serverpac came.

Just looking if anyone had any suggestions that I haven't thought about.

Dave

_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

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 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: ICSF callable service error SMP/e

[Shmuel Metz (Seymour J.)]

In <9286832208987587.wa.paulgboulderaim@listserv.ua.edu>, on
11/19/2015
   at 11:55 AM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>Why is it preferable to fail directly rather than to (attempt to)
>fall back to an equivalent alternative service?

Why are you peddling straw dummies? Your claim was that "unavailable"
and "unauthorized" were the same. Change your claim and I'll change my
response as appropriate.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

[J O Skip Robinson]

I can see the relevant fields only on O(utput) screen, not on ST(atus). There 
are actually two significant fields: Dest, which is the target userid, and 
Status, which shows 'USER'. I believe that 'USER' will prevent a JES2 defined 
destid from hijacking the output. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, November 19, 2015 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

On 2015-11-17 15:23, J O Skip Robinson wrote:
> An XMITted file sits in the JES output queue in a designated class (usually 
> B) with the recipient's userid as DEST.  ... 
> 
So administrators must be careful not to assign User IDs that might match 
plausible DESTs.

Can anyone tell me how to obtain DEST via the Rexx SDSF API?
AFAICT, DEST (or DESTN) is a field on the JDS panel but not on the ST panel, 
and address SDSF supports "isfact ST" but not "isfact JDS".

Thanks,
gil


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

GDG Copy in FIFO Order

[Jim Marshall]

I’ve had a need from an application for processing files in a GDG in FIFO 
order.  Way back when an application came to me with the requirement.   He was 
receiving “N” number of File Transfers over night and needed to process them 
the next day in FIFO order.  

 I took some existing code I found on the CBT Tape and customized for my 
customer's needs.   It has the ability to specify if you want 1-N of them or 
ALL.   Additionally I create a file which can be used to DELETE the GDG(s) 
processed.  I made it so it is completely explained, documented within the code 
and easy to read.  It is in Assembler which should not scare you.  

In general whenever I was given a requirement I always believed someone else 
already encountered it, solved the problem and all I needed to do was to find 
the solution.  The first place I would always look on the CBT Tape at 
WWW.CBTTAPE.ORG maintained by Sam Golob. He does a great job ensuring things 
are documented and easy to find.   There is literally hundreds of thousands of 
lines of code in the hundreds of files.  There is an index of them all which is 
easy to read. 

If anyone wants the code, send me an e-mail at my address.

Jim Marshall, USAF-Ret, US Govt-OPM-Ret 
marshall-ja...@comcast.net 

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

Re: SMPE apply excluding certain FMID's?

[Robert A. Rosenberg]

At 14:35 + on 11/19/2015, Jousma, David wrote about Re: SMPE 
apply excluding certain FMID's?:


Do you really want/need to segregate applying maintenance for the 
Omegamon suite, or during a maintenance cycle do you simply want to 
more easily identify the relevant HOLDs just for >Omegamon?  I don't 
necessarily have in mind a solution for you, but I'm curious what 
your real goal is.


The latter.


An APPLY CHECK listing your created Omagamon FMIDSET (or the FMIDs) 
will give you this info since only Omegamon SYSMODs will be selected.


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

Re: Earlier than a z9?

[Tony Thigpen]

I am involved as a vendor of software for the VSE market, and as a 
vendor of systems programming services and also outsourcing for z/OS, 
z/VM and z/VSE.


Some of our vendor products have to be coded to run on both Integrated 
Servers and FSI Flex boxes because we still have customers running VSE 
on those boxes. These customers purchased the one-time fee ESL licenses 
and can't upgrade without significant budget issues. Yet, they keep up 
to date on the maintenance of their vendor products. So, they are 
pro-active and install our updates while stuck running a non-supported 
VSE level.


So, the question is not just:
> Are there any customers (prospects if you will) running box X and
> *conceivably* in the market for new mainframe software (as opposed
> to "we're not spending another nickel on that thing"

But, also:
"Are any of my customers still running the old hardware and still paying 
maintenance fees."


If yes to either question, then the vendor has to worry about the 
instructions used by the code and either not use the newer instructions 
unless they multi-path the code.



Tony Thigpen

Charles Mills wrote on 11/19/2015 08:19 PM:

Like us, Phil is a vendor. For a vendor, the relevant questions are not "do
any of these things exist somewhere and powered on?" but rather

- Are any of our customers running box X? (Should be a question that can be
answer by better means than this listserve.)
- Are there any customers (prospects if you will) running box X and
*conceivably* in the market for new mainframe software (as opposed to "we're
not spending another nickel on that thing" or hobbyists like Mr. Krukosky).

Not criticizing anyone here. (In fact I sent a detailed private note to Phil
with some of our specifics in this regard.) Just trying to shed my light on
the subject from a practical point of view.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tony Thigpen
Sent: Thursday, November 19, 2015 4:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Earlier than a z9?

Yes.

I have a customer running OS/390 on an MP2000. We expect them to be off by
the end of the year. We spent many an hour trying to find a way to move them
to a current platform before they decided to put more dollars into their
off-platform conversion.

I have a customer running OS/390 on a z800.

We recently moved a customer running OS/390 2.10 to a z/10.

I had a customer decommission VM on an MP2000 less than one year ago.

I know of several VSE shops running Integrated Servers.

I know of several VSE shops running FSI Flex boxes.

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




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

Re: ICSF callable service error SMP/e

[Paul Gilmartin]

On Thu, 19 Nov 2015 11:18:36 -0500, Shmuel Metz (Seymour J.) wrote:

> on 11/18/2015 at 03:05 PM, Paul Gilmartin said:
>
>>Sophistry!
>
>PKB.
>
>>If the user is not authorized,
>
>There's more than one user.
>
???  How many users does a job have?

>>it's de facto unavailable and should be treated as such.
>
>BS.
> 
Why is it preferable to fail directly rather than to (attempt to) fall back
to an equivalent alternative service?

AFAIK, there's no option to request that ICSF be bypassed and GIMJVCLT be used 
instead.

-- gil

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

Re: TSO RECEIVE under UNIX Rexx (was: REXX-question)

[Itschak Mugzach]

How about TSO output command to list all waiting files?

ITschak

ITschak Mugzach
Z/OS, ISV Products and Application Security & Risk Assessments Professional

On Thu, Nov 19, 2015 at 8:33 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 19 Nov 2015 12:18:23 -0600, Elardus Engelbrecht wrote:
> >
> >>RECEIVE is extraordinarily ill-suited to automation:
> >>o The user has no a priori control over which spool file will be
> RECEIVEd.
> >>o The user must be present to reply to a prompt.
> >
> >That is very true. JES2 simply gives to you what it seemed to be the
> first. I could not find the reason/algorithm for how RECEIVE and JES2
> decide what to present to the receiver.
> >
> Deep within the Rexx SDSF API, a program can cause SDSF to ALLOCATE
> a DSID to a SYS00nnn DD name.  The programmer could use that in
> RECEIVE INDD(SYS00nnn) (I think; I haven't tried it.), gaining control of
> what to RECEIVE.
>
> >I recommend using FTP instead of XMIT/RECEIVE for another reason - Speed
> and no filling up of JES2 spool.
> >
> I like a combination of sftp and pax.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Deleting all members of a pds

[Lizette Koehler]

I have installed the CBTTAPE.ORG utility PDSCLEAN for both PDS and PDSE 
datasets an it works very well.  File 693.

Lizette



-Original Message-
>From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
>Sent: Nov 19, 2015 3:51 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Deleting all members of a pds
>
>On 2015-11-19 14:54, Ed Finnell wrote:
>> File 182 on CBT tape contains PDS command. It's a great tool. Can delete or 
>>  delete by mask add space, copy, merge and fix. The commercial version is  
>> Startools from Serena. Has saved my bacon numerous times.
>>  
> STOW  DCB,,I
>
>I believe (or hope) PDS uses that nowadays, since its older technique,
>basically zapping the directory, didn't work for PDSE.
>
>> In a message dated 11/19/2015 3:43:17 P.M. Central Standard Time,  
>> johnmattson...@gmail.com writes:
>> 
>> Someone  was asking about deleting all members of a pds.  I just noticed
>> that  DFSort has a bunch of "samples" one of which includes how to use
>> ICETOOL to  delete all members of a PDS.  Hope this helps.  Lots of  other
>> neat things in here  too.
>
>I hope it (and IDCAMS) uses STOW.  Deleting members one-by-one can be 
>expensive.
>But if so, first sort in reverse order.
>
>I'm not going to measure timings
>
>-- gil

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

Re: Earlier than a z9?

[Connor Krukosky]

Doh, should have included these photos.
http://imgur.com/a/C6zsx
I'm sure you all will enjoy them. And yes he got those HUGE DASDs 
as-well, can't wait to hear one of those spin up :)
Ignore the photos of the guts of the 4341, I was tasked with taking the 
section of power-supply off the main CPU cabinet so it would fit on the 
lift gate of the truck and thus took some photos to remember where 
everything went.
So I can't say I haven't been in the guts of a mainframe prior to the 
z890 :P
Also I am actually going back to that place this Saturday to get the 
raised floor because free raised floor is nice :)


-Connor K

On 11/19/2015 6:12 PM, Connor Krukosky wrote:

Heh I am going to reply because it doesn't pertain to my system.
Although its not running any longer I knew of an s/390 that ran up 
until a couple of months ago and before that the company was running a 
4341 (aka s/370) until 1999 when they upgraded to the s/390 because of 
Y2K (because IBM pushed them too even though they released Y2K patches 
for the software on the s/370 a month or two later...)
If IBM didn't push them to move to the s/390 they would have probably 
been running that s/370 up until a couple of months ago.

Both of those systems are now at a museum run by a friend of mine.
That s/370 will run again someday, the s/390 he's been playing with.

-Connor K

On 11/19/2015 5:59 PM, Phil Smith wrote:
Is anyone running on real hardware that's older than a z9? Off-list 
replies would be fine-not trying to embarrass anyone, trying to 
figure out whether there's any real work taking place on such ancient 
iron. Connor, you don't need to reply :)




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


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


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

Deleting all members of a pds

[John Mattson]

Someone was asking about deleting all members of a pds.  I just noticed
that DFSort has a bunch of "samples" one of which includes how to use
ICETOOL to delete all members of a PDS.  Hope this helps.  Lots of other
neat things in here too.
http://www-01.ibm.com/support/docview.wss?uid=isg3T794

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

Re: Deleting all members of a pds

[Ed Finnell]

File 182 on CBT tape contains PDS command. It's a great tool. Can delete or 
 delete by mask add space, copy, merge and fix. The commercial version is  
Startools from Serena. Has saved my bacon numerous times.
 
 
In a message dated 11/19/2015 3:43:17 P.M. Central Standard Time,  
johnmattson...@gmail.com writes:

Someone  was asking about deleting all members of a pds.  I just noticed
that  DFSort has a bunch of "samples" one of which includes how to use
ICETOOL to  delete all members of a PDS.  Hope this helps.  Lots of  other
neat things in here  too.


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

Re: Deleting all members of a pds

[Graham Harris]

In z/OS V1R12, DFSMS access method services (IDCAMS) adds a new wildcard
option to the DELETE command, which lets you delete all members of a PDS or
PDSE.

https://www-01.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.idak100/amspdse12.htm%23amspdse12


On 19 November 2015 at 21:42, John Mattson  wrote:

> Someone was asking about deleting all members of a pds.  I just noticed
> that DFSort has a bunch of "samples" one of which includes how to use
> ICETOOL to delete all members of a PDS.  Hope this helps.  Lots of other
> neat things in here too.
> http://www-01.ibm.com/support/docview.wss?uid=isg3T794
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Earlier than a z9?

[Phil Smith]

Is anyone running on real hardware that's older than a z9? Off-list replies 
would be fine-not trying to embarrass anyone, trying to figure out whether 
there's any real work taking place on such ancient iron. Connor, you don't need 
to reply :)



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

Re: Deleting all members of a pds

[Paul Gilmartin]

On 2015-11-19 14:54, Ed Finnell wrote:
> File 182 on CBT tape contains PDS command. It's a great tool. Can delete or 
>  delete by mask add space, copy, merge and fix. The commercial version is  
> Startools from Serena. Has saved my bacon numerous times.
>  
 STOW  DCB,,I

I believe (or hope) PDS uses that nowadays, since its older technique,
basically zapping the directory, didn't work for PDSE.

> In a message dated 11/19/2015 3:43:17 P.M. Central Standard Time,  
> johnmattson...@gmail.com writes:
> 
> Someone  was asking about deleting all members of a pds.  I just noticed
> that  DFSort has a bunch of "samples" one of which includes how to use
> ICETOOL to  delete all members of a PDS.  Hope this helps.  Lots of  other
> neat things in here  too.

I hope it (and IDCAMS) uses STOW.  Deleting members one-by-one can be expensive.
But if so, first sort in reverse order.

I'm not going to measure timings

-- gil

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

Re: Earlier than a z9?

[Connor Krukosky]

Heh I am going to reply because it doesn't pertain to my system.
Although its not running any longer I knew of an s/390 that ran up until 
a couple of months ago and before that the company was running a 4341 
(aka s/370) until 1999 when they upgraded to the s/390 because of Y2K 
(because IBM pushed them too even though they released Y2K patches for 
the software on the s/370 a month or two later...)
If IBM didn't push them to move to the s/390 they would have probably 
been running that s/370 up until a couple of months ago.

Both of those systems are now at a museum run by a friend of mine.
That s/370 will run again someday, the s/390 he's been playing with.

-Connor K

On 11/19/2015 5:59 PM, Phil Smith wrote:

Is anyone running on real hardware that's older than a z9? Off-list replies 
would be fine-not trying to embarrass anyone, trying to figure out whether 
there's any real work taking place on such ancient iron. Connor, you don't need 
to reply :)



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


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

Re: Deleting all members of a pds

[R.S.]

W dniu 2015-11-19 o 22:42, John Mattson pisze:

Someone was asking about deleting all members of a pds.  I just noticed
that DFSort has a bunch of "samples" one of which includes how to use
ICETOOL to delete all members of a PDS.  Hope this helps.  Lots of other
neat things in here too.
http://www-01.ibm.com/support/docview.wss?uid=isg3T794

Smart DFSORT tricks!
I was really proud to be one of the tricks authors!
Recently I was placed in some redpaper about exploitation of large 
amount of memory, again it was related to DFSORT.

:-)

--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

[Paul Gilmartin]

On 2015-11-17 15:23, J O Skip Robinson wrote:
> An XMITted file sits in the JES output queue in a designated class (usually 
> B) with the recipient's userid as DEST.  ... 
> 
So administrators must be careful not to assign User IDs that might
match plausible DESTs.

Can anyone tell me how to obtain DEST via the Rexx SDSF API?
AFAICT, DEST (or DESTN) is a field on the JDS panel but not on the
ST panel, and address SDSF supports "isfact ST" but not "isfact JDS".

Thanks,
gil

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

Re: (External):HMC and JAVA and Browser ...again/still

[R.S.]

I'm still recommending virtual machinee with customized downlevel 
browser, with downlevel Java, with necessary customization.
Used solely for HMC and other appliances connectivity (like Broceade 
FICON switches and directors).
It won't stop working suddelny just after another update. It is (yes!) 
safe as long as you use it solely for HMC connections.
You can have many versions of the virtual machine if you need. (you 
don't usually).


BTW: I have customized my Java on my real (read: constantly updated) 
machine enough to have full connectivity to use all the features of HMC.

So I use virtual machine mostly for FICON switches and other devices.

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2015-11-19 o 18:06, Bill Allen pisze:

I have the same problem with my HMC and JAVA. I followed the steps outlined in 
the SHARE doc and it did not work for me either. I did notice a missing MCL 
below from Resource Link for my machine. Could be part of the problem. My HMC 
is at 2.12.1 on a z12-BC. I'm going to schedule my CE to apply it and see if it 
helps.

MCL H49564.103 Bundle 43
Release date: 2015/06/24
MCL installation: NONDISRUPTIVE
MCL contents:
  This fix is needed to allow Java Applet based tasks to work with the new 
version of Java.
  Update to SE mirroring task to include some additional files to mirror.

Impact:
  Function - Applet Updates to coincidence with the new level of Java on the 
HMC/SE.
  Update to SE mirroring task to include some additional files to mirror.

Dependencies:
Coreq H49565.018
  





--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

Re: Fastest way to read OLDEST GDG entry

[Mike Schwab]

It remains cataloged.  It is just no longer part of the gdg.  Good
thing those thousand or two files were just a few tracks.

On Thu, Nov 19, 2015 at 9:59 AM, J O Skip Robinson
 wrote:
> I haven't experimented with this, but going with NOSCRATCH is likely to cause 
> big problems with DASD GDGs. A data set residing on an SMS-managed volume 
> must be cataloged. It cannot just sit there uncataloged. Irresistible force 
> meets unmovable object.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Tom Marchant
> Sent: Thursday, November 19, 2015 4:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Fastest way to read OLDEST GDG entry
>
> On Wed, 18 Nov 2015 23:09:44 -0500, Robert A. Rosenberg wrote:
>
>>At 08:32 -0600 on 11/18/2015, Tom Marchant wrote about Re: Fastest way
>>to read OLDEST GDG entry:
>>
>>>you might want to make sure the GDG is defined with NOSCRATCH before
>>>doing this.
>>
>>Note that NOSCRATCH will (I think) not only leave the V00 of a
>>V01->V00 replacement cataloged (as a normally named file with the V01
>>being in the GDG base) but also do the same as GDG generations roll off
>>due to the limit. Normally once it rolls you would want it deleted.
>
> Correct. And if you set the GDG to NOSRCATCH before replacing a data set, 
> then change the GDG back to SCRATCH, and if a new generation that would have 
> caused an old one to roll off is created during the interval, I suspect that 
> old generation would have to be scratched manually.
>
> --
> Tom Marchant
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: ICSF callable service error SMP/e

[R.S.]

W dniu 2015-11-19 o 01:02, Paul Gilmartin pisze:

On 2015-11-18 16:17, R.S. wrote:

W dniu 2015-11-18 o 22:05, Paul Gilmartin pisze:

Sophistry!  If the user is not authorized, it's de facto unavailable and
should be treated as such.

I dare to disagree.
The service is up and ready. It does not allow anyone to use it, but even 
unauthorised user will get response.


Still sophistry.  What SMP/E should be asking is, "Can this job use CSNBOWH?"
Now I understand your point. You are right. It is not a question about 
CSF service availability, it is question CAN *I* USE IT.




which is what SMP/E needs to know, not "Is CSNBOWH available to properly
authorized users, even if not to this job?"  If ICSF supports no such query,
then SMP/E should take the empirical approach: request the OWH of some standard
document (perhaps the null string) and if CSNBOWH does not return the proper
hash, consider it "unavailable".

If the intent is to avoid triggering security violation alerts, the design
fails: I suspect that what SMP/E is doing causes such alerts.


Of course the question is why to block CSFBOWH, what is the rationale behind?
  

Especially since with a little reverse engineering (most of the instructions
have been supplied in this forum over years) any user can use GIMJVCLT as an
alternative.  I suppose that also could be disabled.
Still, I see no reason to block use OWH function. It is publicly known, 
well documented algorithm, everyone can use its own implementation 
instead of CSF service. Of course ICSF version is faster and much less 
consuming CPU, so...



Regards
--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

SMPE apply excluding certain FMID's?

[Jousma, David]

All,  I don't think this can be done after RTFMing, but wanted to make sure no 
one has some trick up their sleeves.   Just received my z/OS 2.2 serverpac, and 
this time around, decided to include my Omegamon suite of products with it.   
The question I have, is while my group manages the SMPe maintenance for 
Omegamon, the individual components are cared for and fed by the groups that 
use them (ie. DB2 team looks at reviews OMEG DB2 hold data, etc).   So, I've 
created an FMIDset of the Omeg FMID's to use for applying maintenance so that 
passing the relevant hold data along to those groups is easier.But what I 
don't see is a way to run a SMPE apply for everything else EXCLUDING these 
FMID's in the OMEGAMON FMIDset.  Can that be done?   I know that I could go to 
the effort to move these FMID's into their own zones, but that would be a lot 
of work, and that's not how my serverpac came.

Just looking if anyone had any suggestions that I haven't thought about.

Dave

_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: REXX-question

[Elardus Engelbrecht]

Hardee, Chuck wrote:

>Try adding: queue "RESTORE" 
>Just before the queue of the "END" command. 

While I have NOT tested out that REXX program, I believe it should work. 

I think Leopold should also add TRACE A to his REXX program for better 
debugging.

Groete / Greetings
Elardus Engelbrecht

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

Re: Fastest way to read OLDEST GDG entry

[Tom Marchant]

On Wed, 18 Nov 2015 23:09:44 -0500, Robert A. Rosenberg wrote:

>At 08:32 -0600 on 11/18/2015, Tom Marchant wrote about Re: Fastest
>way to read OLDEST GDG entry:
>
>>you might want to make sure the GDG is defined with NOSCRATCH
>>before doing this.
>
>Note that NOSCRATCH will (I think) not only leave the V00 of a
>V01->V00 replacement cataloged (as a normally named file with the V01
>being in the GDG base) but also do the same as GDG generations roll
>off due to the limit. Normally once it rolls you would want it
>deleted.

Correct. And if you set the GDG to NOSRCATCH before replacing a data set, 
then change the GDG back to SCRATCH, and if a new generation that would 
have caused an old one to roll off is created during the interval, I suspect 
that old generation would have to be scratched manually.

-- 
Tom Marchant

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

REXX-question

[Leopold Strauss]

Hi, all

I simply wanted to automize the receiving of a lot of XMIT-files in 
zOS-unix-shell ( not TSO)


Last but not least my problem could be broken down to following 
terminal-input-problem with the RECEIVE-command:


rexx-script:

parse arg indsn outdsn

address tso "PROFILE PROMPT"
queue "DATASET('"outdsn"')"
queue "END"
address tso "RECEIVE INDATASET('"indsn"')"

Result:

MV21:/u/leoplds$ receive.sh 'LEOPLDS.TEST.XMIT' 'LEOPLDS.TEST.TEST'
INMR901I Dataset SYSC.DOCEXEC.V717.LOADLIB from CHR9255 on ESJES2
INMR154I The incoming data set is a 'PROGRAM LIBRARY'.
INMR906A Enter restore parameters or 'DELETE' or 'END' +
INMR908A The input file attributes are: DSORG=PARTITIONED, RECFM=U, 
BLKSIZE=32760, LRECL=32756, File size=X'0005C3EE'K bytes +
INMR909A You may enter DSNAME, SPACE, UNIT, VOL, OLD/NEW, or 
RESTORE/COPY/DELETE/END
INMR800I The RECEIVE command failed. The PUTGET service routine issued 
return code 16.


I googled a lot, read manuals, but I did not find any working sample, 
which I could use.


appreciating all hints and br

--
Mit freundlichen Gruessen / Kind Regards,
Leopold Strauss, Team DEV-zOS, T: +43-2236-27551-331

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

Re: REXX-question

[Hardee, Chuck]

Leopold,

This is purely a guess, but the last line of the prompt states: 

INMR909A You may enter DSNAME, SPACE, UNIT, VOL, OLD/NEW, or 
RESTORE/COPY/DELETE/END

You supplied a DATASET() parameter, but I don't see a RESTORE, COPY or DELETE 
prior to the END.
Try adding:

queue "RESTORE"

Just before the queue of the "END" command.

Chuck

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

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

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leopold Strauss
Sent: Thursday, November 19, 2015 6:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: REXX-question

Hi, all

I simply wanted to automize the receiving of a lot of XMIT-files in 
zOS-unix-shell ( not TSO)

Last but not least my problem could be broken down to following 
terminal-input-problem with the RECEIVE-command:

rexx-script:

parse arg indsn outdsn

address tso "PROFILE PROMPT"
queue "DATASET('"outdsn"')"
queue "END"
address tso "RECEIVE INDATASET('"indsn"')"

Result:

MV21:/u/leoplds$ receive.sh 'LEOPLDS.TEST.XMIT' 'LEOPLDS.TEST.TEST'
INMR901I Dataset SYSC.DOCEXEC.V717.LOADLIB from CHR9255 on ESJES2
INMR154I The incoming data set is a 'PROGRAM LIBRARY'.
INMR906A Enter restore parameters or 'DELETE' or 'END' +
INMR908A The input file attributes are: DSORG=PARTITIONED, RECFM=U, 
BLKSIZE=32760, LRECL=32756, File size=X'0005C3EE'K bytes +
INMR909A You may enter DSNAME, SPACE, UNIT, VOL, OLD/NEW, or 
RESTORE/COPY/DELETE/END
INMR800I The RECEIVE command failed. The PUTGET service routine issued 
return code 16.

I googled a lot, read manuals, but I did not find any working sample, 
which I could use.

appreciating all hints and br

-- 
Mit freundlichen Gruessen / Kind Regards,
Leopold Strauss, Team DEV-zOS, T: +43-2236-27551-331

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

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

Re: z/OS Internet library links dead

[Jon Butler]

Tom,

As at 0720 on 19 November the z/OSv2 link is not working for me.  Nothing at 
all, no 404, no nothing.

The other links work, and I love the new prototype.  Very easy to find what you 
need, and to grab the PDFs for local use.

Thanks.

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

Re: REXX-question

[Itschak Mugzach]

Push the TSO RECEIVE commands (ie. END, DA(), etc.) into the tso stack and
then call RECEIVE.

ITschak

ITschak Mugzach
Z/OS, ISV Products and Application Security & Risk Assessments Professional

On Thu, Nov 19, 2015 at 1:47 PM, Leopold Strauss <
leopold.stra...@isis-papyrus.com> wrote:

> Hi, all
>
> I simply wanted to automize the receiving of a lot of XMIT-files in
> zOS-unix-shell ( not TSO)
>
> Last but not least my problem could be broken down to following
> terminal-input-problem with the RECEIVE-command:
>
> rexx-script:
>
> parse arg indsn outdsn
>
> address tso "PROFILE PROMPT"
> queue "DATASET('"outdsn"')"
> queue "END"
> address tso "RECEIVE INDATASET('"indsn"')"
>
> Result:
>
> MV21:/u/leoplds$ receive.sh 'LEOPLDS.TEST.XMIT' 'LEOPLDS.TEST.TEST'
> INMR901I Dataset SYSC.DOCEXEC.V717.LOADLIB from CHR9255 on ESJES2
> INMR154I The incoming data set is a 'PROGRAM LIBRARY'.
> INMR906A Enter restore parameters or 'DELETE' or 'END' +
> INMR908A The input file attributes are: DSORG=PARTITIONED, RECFM=U,
> BLKSIZE=32760, LRECL=32756, File size=X'0005C3EE'K bytes +
> INMR909A You may enter DSNAME, SPACE, UNIT, VOL, OLD/NEW, or
> RESTORE/COPY/DELETE/END
> INMR800I The RECEIVE command failed. The PUTGET service routine issued
> return code 16.
>
> I googled a lot, read manuals, but I did not find any working sample,
> which I could use.
>
> appreciating all hints and br
>
> --
> Mit freundlichen Gruessen / Kind Regards,
> Leopold Strauss, Team DEV-zOS, T: +43-2236-27551-331
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Privately owned mainframes (Was Re: I just bought an IBM z890)

[Tony Thigpen]

For those interested in owning a real mainframe, we do have some 
MP3000s, some z890s, and some z9s that we would sell that are stored in 
Chattanooga.


The z boxes would make great heaters in the winter. Just put one in the 
basement and power it up. :-)


Tony Thigpen

Elardus Engelbrecht wrote on 11/09/2015 06:56 AM:

Mike Schwab wrote:


http://www.chipsetc.com/computer-memorabilia-collectors.html
Cray Y-MP C90 supercomputer listed on eBay in September 2000; it sold to a 
private individual for $45,000, down from the original list price of $35 
million.


Interesting, what is more interesting, here is a snippet from your link about 
NASA which reminds me of that hunting for vintage programmers so Voyager can 
still be tracked until 2020:


When the first shuttle roared into space that year, the 8086 played a critical 
role, at the heart of diagnostic equipment that made sure the shuttle's twin 
booster rockets were safe for blastoff.

Today, more than two decades later, booster testing still uses 8086 chips, 
which are increasingly scarce. NASA plans to create a $20 million automated 
checking system, with all new hardware and software. In the meantime, it is 
hoarding 8086's so that a failed one does not ground the nation's fleet of 
aging spaceships.


Oh, BTW, I sold my Commodore 64 to a collector. ;-)

Today, thanks to those collectors, you can get Commodore emulators so all your 
ancient games [remember Manic Miner and Jet Set Willy? 8-D ] can be played on 
your PC.

And you get MAME which emulates games on your PC like these: Burger Time 
(Midway), Zaxxon, Crazy Kong, Dig Dug, Elevator Action, Frogger, Kung Fu Master 
(only one I finished!), etc.

Groete / Greetings
Elardus Engelbrecht

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




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

Re: Earlier than a z9?

[William Donzelli]

> Those HUGE DASDs are 3380s, I believe, with the sideways belt
> drive.Yeah, they're a little louder than a laptop drive. But no
> worries; you don't really hear them over the background A/C noise.

I am still on the search for a 3380/3880 set.

> I don't know about 3380s, but earlier IBM DASD often required 3-phase
> power, even though the motors were themselves single-phase. Not
> impossible for a dedicated hobbyist, but a bit of a pain.

Most DASDs from the big platter era have phase rotation sensors, so
when running the thing off a single phase, the sensor needs to be
fooled or there will be a power check.

--
Will

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

Re: Privately owned mainframes (Was Re: I just bought an IBM z890)

[William Donzelli]

> For those interested in owning a real mainframe, we do have some MP3000s,
> some z890s, and some z9s that we would sell that are stored in Chattanooga.

Anything older?

> The z boxes would make great heaters in the winter. Just put one in the
> basement and power it up. :-)

Yes, that is the plan here. I hate oil heat - I would rather have
slightly more expensive but very much more fun electric heat from a
big number crunching box. I will even take the meager heat any
blinkenlights put out.

--
Will

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

Re: Earlier than a z9?

[Charles Mills]

I listed *two* potentially relevant test questions, the first of them more
or less the one you suggest. :-)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tony Thigpen
Sent: Thursday, November 19, 2015 5:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Earlier than a z9?

I am involved as a vendor of software for the VSE market, and as a vendor of
systems programming services and also outsourcing for z/OS, z/VM and z/VSE.

Some of our vendor products have to be coded to run on both Integrated
Servers and FSI Flex boxes because we still have customers running VSE on
those boxes. These customers purchased the one-time fee ESL licenses and
can't upgrade without significant budget issues. Yet, they keep up to date
on the maintenance of their vendor products. So, they are pro-active and
install our updates while stuck running a non-supported VSE level.

So, the question is not just:
 > Are there any customers (prospects if you will) running box X and  >
*conceivably* in the market for new mainframe software (as opposed  > to
"we're not spending another nickel on that thing"

But, also:
"Are any of my customers still running the old hardware and still paying
maintenance fees."

If yes to either question, then the vendor has to worry about the
instructions used by the code and either not use the newer instructions
unless they multi-path the code.


Tony Thigpen

Charles Mills wrote on 11/19/2015 08:19 PM:
> Like us, Phil is a vendor. For a vendor, the relevant questions are 
> not "do any of these things exist somewhere and powered on?" but 
> rather
>
> - Are any of our customers running box X? (Should be a question that 
> can be answer by better means than this listserve.)
> - Are there any customers (prospects if you will) running box X and
> *conceivably* in the market for new mainframe software (as opposed to 
> "we're not spending another nickel on that thing" or hobbyists like Mr.
Krukosky).

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

Re: Fastest way to read OLDEST GDG entry

[John McKown]

On Thu, Nov 19, 2015 at 9:59 AM, J O Skip Robinson  wrote:

> I haven't experimented with this, but going with NOSCRATCH is likely to
> cause big problems with DASD GDGs. A data set residing on an SMS-managed
> volume must be cataloged. It cannot just sit there uncataloged.
> Irresistible force meets unmovable object.
>

I just tested the following on z/OS 1.12. With SMS managed disk data sets,
if the GDS "rolls off" the GDG base and NOSCRATCH is in effect, then the
GDS simply becomes a non-GDS entry which "just happens" to look like a
member of a GDG. I.e. it is not concatenated in with DSN=GDG.BASE nor can
it be referenced via DSN=GDG.BASE(-n), but can be via GDG.BASE.GV00.​



> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
>
-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

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

Re: ICSF callable service error SMP/e

[Shmuel Metz (Seymour J.)]

In <2680722424903653.wa.paulgboulderaim@listserv.ua.edu>, on
11/18/2015
   at 03:05 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>Sophistry!

PKB.

>If the user is not authorized,

There's more than one user.

>it's de facto unavailable and should be treated as such.

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

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

Re: Earlier than a z9?

[Tony Harminc]

On 19 November 2015 at 18:19, Connor Krukosky  wrote:
> Doh, should have included these photos.
> http://imgur.com/a/C6zsx
> I'm sure you all will enjoy them. And yes he got those HUGE DASDs as-well,
> can't wait to hear one of those spin up :)

Those HUGE DASDs are 3380s, I believe, with the sideways belt
drive.Yeah, they're a little louder than a laptop drive. But no
worries; you don't really hear them over the background A/C noise.

I don't know about 3380s, but earlier IBM DASD often required 3-phase
power, even though the motors were themselves single-phase. Not
impossible for a dedicated hobbyist, but a bit of a pain.

Tony H.

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

Re: Earlier than a z9?

[Linda]

Hi Phil,

z800 a01

It might get replaced in the next year or so. 

Linda

Sent from my iPhone

> On Nov 19, 2015, at 2:59 PM, Phil Smith  wrote:
> 
> Is anyone running on real hardware that's older than a z9? Off-list replies 
> would be fine-not trying to embarrass anyone, trying to figure out whether 
> there's any real work taking place on such ancient iron. Connor, you don't 
> need to reply :)
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Deleting all members of a pds

[Elardus Engelbrecht]

Paul Gilmartin wrote:

>I looked at that.  It builds a list of IDCAMS commands to delete the members 
>one-by-one.  

Obsolete by now.

> Does IDCAMS DELETE DATA.SET.NAME(*)

Yes, it is documented "If you specify the entryname in the format of a 
partition data set, pdsname(*), the command deletes all the members in the 
partition data set."

>use STOW ,,I?

I wish I know, but there is that nasty magic word: 'OCO'. - One more reason for 
you to hate everything like JCL and MVS! ;-)

Groete / Greetings
Elardus Engelbrecht

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

AW: Re: REXX-question

[Peter Hunkeler]

I'm curious to understand whay you want to run this rexx as a shell script as 
oposed to a simple batch tso step.

I don't see the benefit, only drawbacks

--Peter Hunkeler

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

Re: Fastest way to read OLDEST GDG entry

[J O Skip Robinson]

I haven't experimented with this, but going with NOSCRATCH is likely to cause 
big problems with DASD GDGs. A data set residing on an SMS-managed volume must 
be cataloged. It cannot just sit there uncataloged. Irresistible force meets 
unmovable object. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, November 19, 2015 4:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Fastest way to read OLDEST GDG entry

On Wed, 18 Nov 2015 23:09:44 -0500, Robert A. Rosenberg wrote:

>At 08:32 -0600 on 11/18/2015, Tom Marchant wrote about Re: Fastest way 
>to read OLDEST GDG entry:
>
>>you might want to make sure the GDG is defined with NOSCRATCH before 
>>doing this.
>
>Note that NOSCRATCH will (I think) not only leave the V00 of a
>V01->V00 replacement cataloged (as a normally named file with the V01
>being in the GDG base) but also do the same as GDG generations roll off 
>due to the limit. Normally once it rolls you would want it deleted.

Correct. And if you set the GDG to NOSRCATCH before replacing a data set, then 
change the GDG back to SCRATCH, and if a new generation that would have caused 
an old one to roll off is created during the interval, I suspect that old 
generation would have to be scratched manually.

--
Tom Marchant


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

Re: SMPE apply excluding certain FMID's?

[Tom Marchant]

On Thu, 19 Nov 2015 12:14:38 +, Jousma, David wrote:

>what I don't see is a way to run a SMPE apply for everything else 
>EXCLUDING these FMID's in the OMEGAMON FMIDset.  Can that be done?

I think you are asking if you can:

Apply select(everything) exclude(omegamon).

AFAIK, you cannot.

I don't know if you can specify an fmidset in EXCLUDE. Lacking that you'd 
have to specify all of the Omegamon FMIDS. Have you tried:

Apply FORFMID(everything) exclude(om1 om2 om3 ...).

Or change your FMIDSET for everything.

-- 
Tom Marchant

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

Re: SMPE apply excluding certain FMID's?

[Jousma, David]

Thanks Tom.  I've experimented with anything yet.  Was just reading the manuals 
to see if want I wanted to do could be done.   I am trying to do exactly as you 
characterized it.


_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, November 19, 2015 8:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE apply excluding certain FMID's?

On Thu, 19 Nov 2015 12:14:38 +, Jousma, David wrote:

>what I don't see is a way to run a SMPE apply for everything else 
>EXCLUDING these FMID's in the OMEGAMON FMIDset.  Can that be done?

I think you are asking if you can:

Apply select(everything) exclude(omegamon).

AFAIK, you cannot.

I don't know if you can specify an fmidset in EXCLUDE. Lacking that you'd have 
to specify all of the Omegamon FMIDS. Have you tried:

Apply FORFMID(everything) exclude(om1 om2 om3 ...).

Or change your FMIDSET for everything.

--
Tom Marchant

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

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: 3DES encryption using ICSF callable services

[R.S.]

W dniu 2015-11-19 o 14:44, Todd Arnold pisze:

One of the fundamental design points for CCA is that keys are protected.  Once they are 
inside the CCA system, they are always encrypted if they are outside the physically 
secure HSM module.  Thus, most crypto functions in the CCA API ("verbs") only 
accept keys in encrypted form - wrapped with the appropriate CCA master key.  They are 
decrypted on the fly inside the HSM and used for the desired operation.  Thus, before you 
can use a key in the Encipher verb, you need to get the key into such a form - wrapped by 
the master key.  That's the purpose of the import operation in the sequence you posted.

With any cryptographic system today, the biggest exposure is protection of your keys.  
Hardly anyone actually "breaks" the crypto algorithms themselves - they find 
ways to get to the keys.


Actually ICSF provides both open and secure key encryption services.
Separate issue is whether the service is part of CCA or not.

--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

Re: 3DES encryption using ICSF callable services

[John Blythe Reid]

I've finally discovered how to do it ! With this verb I can encrypt the text 
using a clear single length DES key without the need to create/import a token:

/* Symmetric Key Encipher - CSNBSYE */
call csnbsye(return_code,   
 reason_code,   
 exit_data_length,  
 exit_data, 
 rule_array_count,  /* 1   */   
 rule_array,/* 'DES'   */   
 des_key_l, /* DES key length  */   
 des_key,   /* DES key */   
 key_parms_l,   /* ignored */   
 ' ',   /* key parms   */   
 block_size,/* 8   */   
 initialization_vector_l,   /* 8 */ 
 initialization_vector, /* binary zeros  */ 
 chain_data_length, /* 16*/ 
 chain_data,/* binary zeros  */ 
 text_length,   /* plain text length */ 
 clear_text,/* plaintext   */   
 cipher_text_length,/* ciphertext length */ 
 cipher_text);  /* ciphertext */

I've tested it and it works OK.

The DES key is only in the clear for a minimal amount of time. It is received 
encrypted using RSA. It is decrypted using a private key. It is then used to 
DES encrypt the response and immediately discarded. There are only a handful of 
instructions between its decryption and its being discarded. There is no 
intervening I/O.

Regards,
John.


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

Re: Fastest way to read OLDEST GDG entry

[Tom Marchant]

On Thu, 19 Nov 2015 15:59:37 +, J O Skip Robinson wrote:

>I haven't experimented with this, but going with NOSCRATCH is likely to 
>cause big problems with DASD GDGs. A data set residing on an SMS-managed 
>volume must be cataloged.

It has been a long time since I looked at this, but what I remember is 
that GDGs were a special case. For one thing, with SMS, a data set is 
cataloged at allocation time, not at step end like it was before.

One consequence of that is that is that a generation may be scratched 
as soon as the new one is allocated, rather than wait until the step 
ends successfully.

Consider a new GDG created with NEW,CATLG,DELETE. Before SMS, the 
old generation was scratched at the time the new one is cataloged at 
the end of the step, when the new one is cataloged.

As a result, the idea of a generation being rolled in and rolled out was 
created. The data set is cataloged, but is not cataloged as part of the 
GDG.

-- 
Tom Marchant

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

Re: (External):HMC and JAVA and Browser ...again/still

[Bill Allen]

I have the same problem with my HMC and JAVA. I followed the steps outlined in 
the SHARE doc and it did not work for me either. I did notice a missing MCL 
below from Resource Link for my machine. Could be part of the problem. My HMC 
is at 2.12.1 on a z12-BC. I'm going to schedule my CE to apply it and see if it 
helps.

MCL H49564.103 Bundle 43
Release date: 2015/06/24
MCL installation: NONDISRUPTIVE
MCL contents:
 This fix is needed to allow Java Applet based tasks to work with the new 
version of Java.
 Update to SE mirroring task to include some additional files to mirror. 

Impact:
 Function - Applet Updates to coincidence with the new level of Java on the 
HMC/SE.
 Update to SE mirroring task to include some additional files to mirror. 

Dependencies:
Coreq H49565.018


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

Re: SMPE apply excluding certain FMID's?

[Jousma, David]

Yep!

_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, November 19, 2015 8:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE apply excluding certain FMID's?

On Thu, 19 Nov 2015 13:24:07 +, Jousma, David wrote:

>Was just reading the manuals to see if want I wanted to do could be done.

APPLY CHECK is your friend.

--
Tom Marchant

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

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMPE apply excluding certain FMID's?

[Tom Marchant]

On Thu, 19 Nov 2015 13:24:07 +, Jousma, David wrote:

>Was just reading the manuals to see if want I wanted to do could be done.

APPLY CHECK is your friend.

-- 
Tom Marchant

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

Re: 3DES encryption using ICSF callable services

[Todd Arnold]

One of the fundamental design points for CCA is that keys are protected.  Once 
they are inside the CCA system, they are always encrypted if they are outside 
the physically secure HSM module.  Thus, most crypto functions in the CCA API 
("verbs") only accept keys in encrypted form - wrapped with the appropriate CCA 
master key.  They are decrypted on the fly inside the HSM and used for the 
desired operation.  Thus, before you can use a key in the Encipher verb, you 
need to get the key into such a form - wrapped by the master key.  That's the 
purpose of the import operation in the sequence you posted.

With any cryptographic system today, the biggest exposure is protection of your 
keys.  Hardly anyone actually "breaks" the crypto algorithms themselves - they 
find ways to get to the keys.

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

Re: JCL QUESTION :IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET

[Bob Dott]

John, I believe your issue may be that the IBM VTS is installed as SMS managed 
tape. Have you added the VTS to SMS, if not you may need to. If you do have it 
defined in SMS, verify the tape datasets are getting assigned the correct 
storage group. If they are falling into a storage group for disk, that would 
drive this error. The DFSMS OAM Planning, Installation and Storage 
Administration guide for tape libraries (SC23-6867-01) would be the best manual 
to refer to if you have not set the VTS up in SMS.

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

Re: SMPE apply excluding certain FMID's?

[Kurt Quackenbush]

...   So, I've created an
FMIDset of the Omeg FMID's to use for applying maintenance so that
passing the relevant hold data along to those groups is easier.
But what I don't see is a way to run a SMPE apply for everything else
EXCLUDING these FMID's in the OMEGAMON FMIDset.  Can that be done?


No, there is no simple mechanism to exclude one or more FMIDs from APPLY 
processing.


Do you really want/need to segregate applying maintenance for the 
Omegamon suite, or during a maintenance cycle do you simply want to more 
easily identify the relevant HOLDs just for Omegamon?  I don't 
necessarily have in mind a solution for you, but I'm curious what your 
real goal is.


Kurt Quackenbush -- IBM, SMP/E Development

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

Re: SMPE apply excluding certain FMID's?

[Jousma, David]

>Do you really want/need to segregate applying maintenance for the Omegamon 
>suite, or during a maintenance cycle do you simply want to more easily 
>identify the relevant HOLDs just for >Omegamon?  I don't necessarily have in 
>mind a solution for you, but I'm curious what your real goal is.

The latter.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Thursday, November 19, 2015 9:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE apply excluding certain FMID's?

> ...   So, I've created an
> FMIDset of the Omeg FMID's to use for applying maintenance so that 
> passing the relevant hold data along to those groups is easier.
> But what I don't see is a way to run a SMPE apply for everything else 
> EXCLUDING these FMID's in the OMEGAMON FMIDset.  Can that be done?

No, there is no simple mechanism to exclude one or more FMIDs from APPLY 
processing.

Do you really want/need to segregate applying maintenance for the Omegamon 
suite, or during a maintenance cycle do you simply want to more easily identify 
the relevant HOLDs just for Omegamon?  I don't necessarily have in mind a 
solution for you, but I'm curious what your real goal is.

Kurt Quackenbush -- IBM, SMP/E Development

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

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: REXX-question

[Paul Gilmartin]

On Thu, 19 Nov 2015 12:47:40 +0100, Leopold Strauss wrote:

>Hi, all
> 
(Waiting for Lizette to suggest fora TSO-REXX and, most relevant,  MVS-OE.)

>I simply wanted to automize the receiving of a lot of XMIT-files in
>zOS-unix-shell ( not TSO)
>
>Last but not least my problem could be broken down to following
>terminal-input-problem with the RECEIVE-command:
>
>rexx-script:
>
>parse arg indsn outdsn
>
>address tso "PROFILE PROMPT"
>queue "DATASET('"outdsn"')" 
>
... Ouch!  Now you're in trouble.  When you run Rexx under the z/OS UNIX shell,
"address TSO starts the TSO TMP in a separate address space and creates a
communication channel between the UNIX address space and the TSO address
space.  "queue" operates in the UNIX address space; RECEIVE in the TSO
address space where lines queued in the UNIX address space are inaccessible
to it.

This may be further complicated by the conflict between TGET and GETLINE
I don't much understand it.

You might try two EXECs; one in the UNIX address space whch does:

address TSO "exec '''your.sysexec.pds(RCVWRAP)'''" 

Where RCVWRAP is an EXEC which issues the "queue" and "receive"
commands in the TSO address space.

BTW, allocations performed in the UNIX address space (e.g. with BPXWDYN)
are not available in the TSO address space.

I haven't had much success with this scheme; RECEIVE is a bad design.

I hate MVS!

-- gil

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

Re: REXX-question

[Bill Godfrey]

On Thu, 19 Nov 2015 12:47:40 +0100, Leopold Strauss wrote:

>Hi, all
>
>I simply wanted to automize the receiving of a lot of XMIT-files in
>zOS-unix-shell ( not TSO)
>
>Last but not least my problem could be broken down to following
>terminal-input-problem with the RECEIVE-command:
>
>rexx-script:
>
>parse arg indsn outdsn
>
>address tso "PROFILE PROMPT"
>queue "DATASET('"outdsn"')"
>queue "END"
>address tso "RECEIVE INDATASET('"indsn"')"
>
>Result:
>
>MV21:/u/leoplds$ receive.sh 'LEOPLDS.TEST.XMIT' 'LEOPLDS.TEST.TEST'
>INMR901I Dataset SYSC.DOCEXEC.V717.LOADLIB from CHR9255 on ESJES2
>INMR154I The incoming data set is a 'PROGRAM LIBRARY'.
>INMR906A Enter restore parameters or 'DELETE' or 'END' +
>INMR908A The input file attributes are: DSORG=PARTITIONED, RECFM=U,
>BLKSIZE=32760, LRECL=32756, File size=X'0005C3EE'K bytes +
>INMR909A You may enter DSNAME, SPACE, UNIT, VOL, OLD/NEW, or
>RESTORE/COPY/DELETE/END
>INMR800I The RECEIVE command failed. The PUTGET service routine issued
>return code 16.
>
>I googled a lot, read manuals, but I did not find any working sample,
>which I could use.
>
>appreciating all hints and br
>
>--
>Mit freundlichen Gruessen / Kind Regards,
>Leopold Strauss, Team DEV-zOS, T: +43-2236-27551-331
>

Try adding this anywhere before the RECEIVE command:

x = prompt('on')

Bill

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

TSO RECEIVE under UNIX Rexx (was: REXX-question)

[Paul Gilmartin]

(With a belated admonition to the OP to select a meaningful subject.
My experience is that any subject containing the word "question"
is suspect.  Don't say, "I have a question."  Simply ask your question.)

On Thu, 19 Nov 2015 16:48:23 +0100, Peter Hunkeler wrote:

>I'm curious to understand whay you want to run this rexx as a shell script as 
>oposed to a simple batch tso step.
>
>I don't see the benefit, only drawbacks
> 
It can be a matter of familiarity; the same trait that impels users with other
backgrounds to invoke UNIX services with BPXBATCH in cases where there
is no visible benefit, only drawbacks.

RECEIVE is extraordinarily ill-suited to automation:
o The user has no a priori control over which spool file will be RECEIVEd.
o The user must be present to reply to a prompt.

VM/CMS does somewhat better:
o CMS has the RDRLIST utility, similar to SDSF.
o Within RDRLIST, the user can issue a line command:
  RECEIVE / (options)  # "/" denotes the spool ID of the current line.
o Or, from the command line (like READY prompt):
  RECEIVE spoolID (options)
  Options may include:
  - target file ID
  - REPLACE/NOREPLACE, etc
  (Much like what must be supplied to PROMPT from TSO RECEIVE.)

TSO developers (are there any such?) would do well to learn from CMS.
How about:
  RECEIVE [JOB(jobID[.dsid])] [REPLY('reply-string')]

-- gil

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