Re: To restore Purged STC output

[Lizette Koehler]

Once output is purged on a JES2 SPOOL there is no recovery.

If you have offloaded the output to a tool like JES2 Offloader, CA View,
$AVERS, XPTR, etc, then you can.

But if you did a direct command in JES2 like $P, then no.  It is gone

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of mf db
> Sent: Monday, February 10, 2014 10:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: To restore Purged STC output
> 
> Hello Group,
> 
> Is there a possibility of recovering a particular Purged STC back to spool
?
> 
> Z/os : 1.13
> 
> Peter
> 

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

Re: Default OMVS segment

[Lizette Koehler]

You should join the RACF Group and ask this question.  That group could be
more helpful.

Second, go to Robert Hansel's website.  He has many RACF Papers that may
help.
http://www.rshconsulting.com/racfres.htm


I would also review the following SHARE presentation as well
https://share.confex.com/share/121/webprogram/Session13846.html


And the z/OS V2.1 Migration Guide
http://publibz.boulder.ibm.com/epubs/pdf/e0z2m192.pdf
Section:  z/OS UNIX actions to perform before installing z/OS V2R1

Use the BPX.UNIQUE.USER profile instead of
BPX.DEFAULT.USER
Description
: Before z/OS V1R11, if the BPX.DEFAULT.USER profile in the
FACILITY class was defined, users who accessed z/OS UNIX services who did
not
have an OMVS user or group segment were assigned the default OMVS segments
for the length of the user session. All users of the default OMVS segments
shared
the same UID and GID. As of z/OS V1R11, if BPX.UNIQUE.USER has been
defined, users who access z/OS UNIX services who do not have an OMVS user or
group segment are automatically assigned an OMVS segment with a unique UID
and GID. The new OMVS segments are added to the user and group profiles in 
the RACF database. As of z/OS V2R1 BPX.DEFAULT.USER has been removed.


You may need IBM's assistance because of the shared downward leveled
systems, to make it work in your shop.  So if you are sharing with z/OS
V1.13 and V1.12, then you should be able to do what you need in z/OS V2.1
and  convert your lower level systems to use the same process.

I am not sure if z/OS V2.1 has some STCs that require an OMVS segment or
not.  The OSMPD may require a valid OMVS Segment. Check the V2.1
Communication Server manuals or the RACF manuals.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of venkat kulkarni
> Sent: Monday, February 10, 2014 11:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Default OMVS segment
> 
> Yes, z/OS V1.13 is planned to be the last release to support
> *BPX.DEFAULT.USER*.  IBM recommends that we either use the
> BPX.UNIQUE.USER support that was introduced in z/OS V1.11,  or assign
unique
> UIDs to users who need them and assign GIDs for their groups.
> 
> I found below link to enable BPX.UNIQUE.USER support
> 
>
http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r
12.ic
> ha700%2Fautosvc.htm
> 
> But as I mentioned, we  share the RACF database with downlevel systems, So
as
> per this link  we  can enable automatic assignment of unique IDs on our
current
> systems and enable default OMVS segment processing on our downlevel
systems.
> In this situation, the two methods can coexist.
> 
> 
> 
> 
> On Tue, Feb 11, 2014 at 11:39 AM, Paul Gilmartin
> wrote:
> 
> > On Tue, 11 Feb 2014 11:25:54 +0530, venkat kulkarni wrote:
> >
> > >Hello,
> > >   On  newly installed z/OS 2.1 system we
> > >experiencing
> > OMVS
> > >segment not defined issue
> > >
> > >$HASP373 EZAZSSI  STARTED
> > >ICH408I JOB(OSNMPD  ) STEP(OSNMPD  ) CL(PROCESS ) 807
> > >  OMVS SEGMENT NOT DEFINED
> > >
> > >etc...
> > >
> > >
> > >
> > >We already defined Steps for setting up default OMVS segments.
> > >
> > >
> > http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm
> > .zos.r12.icha700%2Fdefomvs.htm
> > >
> > Hmmm... You appear to be reading the 1.12 documentation attempting to
> > configure a 2.1 system.  I have heard mumblings that the default OMVS
> > system is deprecated; near end-of-life.
> >
> > In the corresponding 2.1 document:
> >
> >
> > http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.icha
> > 700/russ.htm
> >
> > ... I see no mention of a default OMVS segment.  Perhaps IBM finally
> > got rid of the wretched thing.
> >
> > -- gil
> >

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

UK -- Next GSE Large Systems Working Group - Call for Papers

[Mark Wilson]

All,

We are planning the next GSE LSWG meeting that will be held on the 2nd April 
2014.

The most likely venue is IBM Southbank, but that depends on the feedback we get.

The reason for the email is that I am looking for speakers for the day.

Looking for fairly technical sessions that are Large Systems focused.

Would anyone be interested in presenting?

If so, would you let me have a few words by way of an abstract please.

Kind Regards

Mark Wilson
GSE Large Systems Chairman

__

This message was delivered by EPA Hosted Exchange and has been certified 
virus-free.
For more information please visit http://www.epacloud.com/exchange 
__

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

Re: SMP/E SYSMOD SOURCEID(s)?

[Kathryn A. Pinto]

Skip has given most of the answers already.  But to summarize the processing of 
UCLIN on the SOURCEID subentry:

A SYSMOD can have multiple SOURCEIDs.  The ADD and DEL UCLIN operations can be 
used to act on one or more SOURCEID values and leave the existing values as is. 
 For example, if a SYSMOD has 2 SOURCEIDs (DATALINK1 and DATALINK2), 

I can ADD one or more SOURCEIDs like so:

UCLIN.
ADD SYSMOD(sysmodid) SOURCEID(DATALINK3, DATALINK4).
ENDUCL.

This will leave the SYSMOD with 4 SOURCEIDs - DATALINK1, DATALINK2, DATALINK3 
and DATALINK4.

I can delete one or more SOURCEIDs like so:

UCLIN.
DEL SYSMOD(sysmodid) SOURCEID(DATALINK2, DATALINK4).
ENDUCL.

This will leave the SYSMOD with 2 SOURCEIDs - DATALINK1 and DATALINK3.

I can also DELete all of the SOURCEIDs like so:

UCLIN.
DEL SYSMOD(sysmodid) SOURCEID().
ENDUCL.

The REP UCLIN command will completely replace any existing SOURCEID values with 
the values specified in the UCLIN command.  For example, if a SYSMOD has 3 
SOURCEID values - DATALINK, DATALINK2, DATALINK3 and I want to 
o Change the first from DATALINK to WOMBAT
o Leave the second unmodified, whatever it is
o Remove the third entirely?

I could REPlace them as follows:

UCLIN.
REP SYSMOD(sysmodid) SOURCEID(WOMBAT, DATALINK2).
ENDUCL.

This will leave the SYSMOD with 2 SOURCEID values - WOMBAT and DATALINK2.

I could also do as Skip suggested and delete them all, then add the require 
ones:

UCLIN.
DEL SYSMOD(sysmodid) SOURCEID().
ADD SYSMOD(sysmodid) SOURCEID(WOMBAT, DATALINK2).
ENDUCL.

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

Re: XCFAS holding OMVS and XCF CDSes

[Bill Neiman]

Gary,

 XCF dynamically allocates in-use couple data sets, which will result in a 
SYSTEMS scope ENQ for each one.  If XCFAS continues to hold an ENQ on a couple 
data set that is not in use by any system, you should probably consider 
pursuing this as a defect.  If you prefer, you can contact me offline with 
whatever additional details you can provide.

 You can get IXC388I if you try to issue an ACOUPLE command from a system 
that is not using the specified CDS type.  However, it should never be possible 
to receive IXC388I for the sysplex CDS.  You can't be in a sysplex, basic or 
otherwise, without having a sysplex CDS in use.
 
Bill Neiman
Parallel Sysplex development
IBM

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

Re: Implicit VVDS creation

[DASDBILL2]

DMS and another large DASD management product suite called SAMS were marketed 
by Sterling for many years before CA acquired Sterling in ca. 1999. 
Bill Fairchild 

- Original Message -

From: "Ed Finnell"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, February 10, 2014 5:00:14 PM 
Subject: Re: Implicit VVDS creation 

That makes more sense. We had their DASD Mgt Product DMS(?) and that was   
about the time they ran me off. 
  
  
In a message dated 2/10/2014 4:47:45 P.M. Central Standard Time,   
dasdbi...@comcast.net writes: 

If it  was called FastDASD, then it was either Software Corp. of America's 

-- 
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: Dumb SMPE question

[Nims,Alva John (Al)]

I think all you can do is "assume" that no matter what, you want to continue, 
so after the "unreceive", use the SMP/e command "RESETRC."  This will reset the 
return code so that other commands can be executed.

Al Nims
Systems Admin/Programmer 3
Information Technology
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, February 10, 2014 11:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dumb SMPE question

On Mon, 10 Feb 2014 19:51:39 -0800, Skip Robinson wrote:

>If no PTFs will APPLY in a particular effort, you're treated to a 
>special message and return code:
>
>GIM24801S ** NO SYSMODS SATISFIED THE OPERANDS SPECIFIED ON THE APPLY 
>COMMAND.
>GIM20501IAPPLY PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12.
>  
My question is, is there any way one can get a different message or a less 
serious return code if one "unreceive[s]" PTFs before the APPLY?  I don't 
believe so; thus, I see no point in attempting to "unreceive" PTFs to get a 
cleaner-looking APPLY.

-- 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: Default OMVS segment

[John Eells]

venkat kulkarni wrote:

Yes, z/OS V1.13 is planned to be the last release to support
*BPX.DEFAULT.USER*.  IBM recommends that we either use the BPX.UNIQUE.USER
support that was introduced in z/OS V1.11,
  or assign unique UIDs to users who need them and assign GIDs for their
groups.



Of course, if you are already using BPX.NEXT.USER, you can either 
continue using that, or choose to convert to BPX.UNIQUE.USER.  If you 
have implemented neither one, UNIQUE is the way to go.


One additional note is that NEXT requires the RACF DB to be at AIM stage 
2, while UNIQUE requires AIM stage 3.  (Both have been around a Long 
Time.)  There's a not-so-new health check for AIM stage 3, that was 
added for z/OS R12 with UA64936 and for z/OS R13 with UA64937 in April 
2012, and a related check to see whether UIDs will be automatically 
assigned.


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: file types

[Scott Ford]

John,


I didn't realize that there could be two SELECTS that can reference the same 
DDNAME.



I learned something new, well everyday I learn something. I will give this a 
try.




Regards,

Scott Ford

www.identityforge.com





From: John McKown
Sent: ‎Monday‎, ‎February‎ ‎10‎, ‎2014 ‎1‎:‎06‎ ‎PM
To: IBM Mainframe Discussion List





I did a quick test. The simplest way was to simply have two SELECT
sentences which reference the same DD.

 FILE-CONTROL.
 SELECT FB ASSIGN TO UT-S-INPUT
FILE STATUS IS FB-STATUS-1
.
 SELECT VB ASSIGN TO UT-S-INPUT
FILE STATUS IS VB-STATUS-1
.
...
 FILE SECTION.
 FD   FB
  RECORD CONTAINS 80 CHARACTERS
  RECORDING MODE IS F
  BLOCK CONTAINS 0 RECORDS
  LABEL RECORDS ARE OMITTED
  .
 01  FB-RECORD.
 05 CARD-IMAGE   PIC X(80).
 FD  VB
 RECORDING MODE IS V
 RECORD IS VARYING IN SIZE
FROM 1 TO 80 CHARACTERS
DEPENDING ON VB-LRECL
 BLOCK CONTAINS 0 RECORDS
 LABEL RECORDS ARE OMITTED
 .
 01  VB-RECORD.
 05 CARD-COLUMN  OCCURS 1 TO 80 TIMES
DEPENDING ON VB-LRECL
PIC X(1).
...
PROCEDURE DIVISION.
...
 OPEN INPUT FB
 IF FB-FILE-STATUS-1 IS NOT 00 THEN
 OPEN INPUT VB
 IF VB-FILE-STATUS-1 IS NOT 00 THEN
  DISPLAY 'CANNOT OPEN INPUT FILE.'
  MOVE 8 TO RETURN-CODE
  GOBACK
 END-IF
ENDIF
...
 IF FB-FILE-STATUS-1 IS ZERO THEN
 READ FB-RECORD
 MOVE FB-RECORD TO WS-RECORD
  ELSE
 READ VB-RECORD
 MOVE VB-RECORD (1:VB-LRECL) TO WS-RECORD
END-IF
... process data in WS-RECORD



On Mon, Feb 10, 2014 at 5:16 PM, Scott Ford  wrote:

> All:
>
>
> I have a Cobol program that can input either RECFM=FB or RECFM=VB and I am
> trying to make it easier for our customers to use.
>
> The input file can be either and whats the simplest way to tell the
> program that the input is FB OR VB. I was thinking PARM= …
>
>
> What do you guys/gals think ?
>
>
>
>
>
>
> Best Regards,
>
> Scott Ford
>
> www.identityforge.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Wasn't there something about a PASCAL programmer knowing the value of
everything and the Wirth of nothing?

Maranatha! <><
John McKown

--
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: Default OMVS segment

[Staller, Allan]

BPX.DEFAULT.USER is ignored in z/OS 2.1. This has widely been reported in IBM 
announcements
The Migration Guide and this forum.

Check the archives.

Your choices are: 
1) create the OMVS segment for this user manually.
2) Set up the BPX.UNIQUE.USER/BPX.NEXT.USER environment as described in the 
manuals.

HTH,




   On  newly installed z/OS 2.1 system we experiencing OMVS 
segment not defined issue

$HASP373 EZAZSSI  STARTED
ICH408I JOB(OSNMPD  ) STEP(OSNMPD  ) CL(PROCESS ) 807
  OMVS SEGMENT NOT DEFINED

etc...

We already defined Steps for setting up default OMVS segments.



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

DF/SORT, joinkeys or splice ?

[TonyICLOUD]

I'm trying to match-merge 2 input files based on a key.  I want to 
create an output file with a record for every key from input1 plus all 
records with a match key from input2.  I haven't found a specific 
example in the books so I'm asking for help.


What I have:

//input1 dd *
key1 blah
key2 blah
//input2 dd*
key1 data-x
key1 data-y
key1 data-z
key2 data-m
key2 data-n
key2 data-o

What I wish to have, an output record per key from input1 times each key 
value found from input2 :


key1 blah data-x
key1 blah data-y
key1 blah data-z
key2 blah data-m
key2 blah data-n
key2 blah data-o

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

Re: file types

[Andreas F. Geissbuehler]

IMHO defining two FD's wins the simplicity and clarity medal. However I used 
the subroutine method in the (distant!) past to change the DDNAME on the fly:
CLOSE FD-FILE-NAME.
MOVE IN-REGION TO DDNAME-SUFFIX.
CALL 'FDFIXUP' USING FD-FILE-NAME, DDNAME.
OPEN OUTPUT FD-FILE-NAME.
e.g. to write / output each region's report (-section) to its own DD-statement 
(RJE remote printing / routing, microfiche). I don't know but expect it to 
still work in the current COBOL releases.

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

Re: SMP/E SYSMOD SOURCEID(s)?

[Paul Gilmartin]

On Tue, 11 Feb 2014 06:38:33 -0600, Kathryn A. Pinto wrote:

>Skip has given most of the answers already.  But to summarize the processing 
>of UCLIN on the SOURCEID subentry:
> 
Thanks.

Should I have been able to infer all this clearly from the SMP/E Commands 
manual?  If
not, I'll submit an RCF.  Examples should serve only to clarify information 
presented in
the processing description, not to supply essential information.

Is this behavior characteristic of repeatable subentries of DB entries (such as 
the
CSECT subentry of the MOD entry in the Target zone)?  Is there an overall rule
that I missed?

Is there a limit to the number of SOURCEIDs that can be defined for  SYSMOD?

>A SYSMOD can have multiple SOURCEIDs.  The ADD and DEL UCLIN operations can be 
>used to act on one or more SOURCEID values and leave the existing values as 
>is.  For example, if a SYSMOD has 2 SOURCEIDs (DATALINK1 and DATALINK2), 
>
>I can ADD one or more SOURCEIDs like so:
>
>UCLIN.
>ADD SYSMOD(sysmodid) SOURCEID(DATALINK3, DATALINK4).
>ENDUCL.
>
>This will leave the SYSMOD with 4 SOURCEIDs - DATALINK1, DATALINK2, DATALINK3 
>and DATALINK4.
>
>I can delete one or more SOURCEIDs like so:
>
>UCLIN.
>DEL SYSMOD(sysmodid) SOURCEID(DATALINK2, DATALINK4).
>ENDUCL.
>
>This will leave the SYSMOD with 2 SOURCEIDs - DATALINK1 and DATALINK3.
>
>I can also DELete all of the SOURCEIDs like so:
>
>UCLIN.
>DEL SYSMOD(sysmodid) SOURCEID().
>ENDUCL.
>
>The REP UCLIN command will completely replace any existing SOURCEID values 
>with the values specified in the UCLIN command.  For example, if a SYSMOD has 
>3 SOURCEID values - DATALINK, DATALINK2, DATALINK3 and I want to 
>o Change the first from DATALINK to WOMBAT
>o Leave the second unmodified, whatever it is
>o Remove the third entirely?
>
>I could REPlace them as follows:
>
>UCLIN.
>REP SYSMOD(sysmodid) SOURCEID(WOMBAT, DATALINK2).
>ENDUCL.
>
>This will leave the SYSMOD with 2 SOURCEID values - WOMBAT and DATALINK2.
>
>I could also do as Skip suggested and delete them all, then add the require 
>ones:
>
>UCLIN.
>DEL SYSMOD(sysmodid) SOURCEID().
>ADD SYSMOD(sysmodid) SOURCEID(WOMBAT, DATALINK2).
>ENDUCL.

Thanks again,
gil

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

Re: XCFAS holding OMVS and XCF CDSes

[Gary Weinhold]

Thanks for the responses, Skip and Lizette,

I probably wasn't clear that I did issue SETXCF CPL,ACOUPLE=SYS2.DKLOMVS.CDS03,TYPE=OMVS 
and received "IXC388I SETXCF COUPLE,ACOUPLE REQUIRES TYPE OMVS TO BE ACTIVE ON THIS 
SYSTEM" and similarly for TYPE=XCF.

I suspect it's something to do with the Basicness of the sysplex (no coupling 
facility), so I guess updating the COUPLExx PARMLIB members and reIPLing is the 
only way to go.

Gary Weinhold
Data Kinetics, Ltd.


From:Skip Robinson  (snipped)

In any case, as long as TYPE= is correct for the couple data set(s) you're 
manipulating, you should have no problem.

From:   Lizette Koehler  (snipped)

I think the same process you used for the CFRM and LOGR can be used for
the others.  each one is a TYPE in the environment.  I would check the
manual, but I think you can create new files and switch them like the
CFRM.  Or you create new files, update parmlib and IPL.

-Original Message-


From: Gary Weinhold  (snipped)

I am trying to clean up a volume with several alternate couple datasets
on it.  For  CFRM and LOGR, I just used IXCL1DSU to allocate alternates
and SETXCF CPL,ACOUPLEd to them and that freed up the datasets so I
could delete them.  But the XCF and OMVS CDSes are a problem.  I can't
delete them because they're in use by XCFAS (shared enq).  SETXCF won't
do anything because "IXC388I SETXCF COUPLE,ACOUPLE requires type OMVS to
active on this system" and the same message for XCF.




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

Re: XCFAS holding OMVS and XCF CDSes

[Skip Robinson]

The problem is that you're using the wrong TYPE keywords. They should be 
TYPE=SYSPLEX and TYPE=BPXMCDS . 

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



From:   Gary Weinhold 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   02/11/2014 07:09 AM
Subject:Re: XCFAS holding OMVS and XCF CDSes
Sent by:IBM Mainframe Discussion List 



Thanks for the responses, Skip and Lizette,

I probably wasn't clear that I did issue SETXCF 
CPL,ACOUPLE=SYS2.DKLOMVS.CDS03,TYPE=OMVS and received "IXC388I SETXCF 
COUPLE,ACOUPLE REQUIRES TYPE OMVS TO BE ACTIVE ON THIS SYSTEM" and 
similarly for TYPE=XCF.

I suspect it's something to do with the Basicness of the sysplex (no 
coupling facility), so I guess updating the COUPLExx PARMLIB members and 
reIPLing is the only way to go.

Gary Weinhold
Data Kinetics, Ltd.


From:Skip Robinson  (snipped)

In any case, as long as TYPE= is correct for the couple data set(s) you're 
manipulating, you should have no problem.

From:   Lizette Koehler  (snipped)

I think the same process you used for the CFRM and LOGR can be used for
the others.  each one is a TYPE in the environment.  I would check the
manual, but I think you can create new files and switch them like the
CFRM.  Or you create new files, update parmlib and IPL.

-Original Message-

> From: Gary Weinhold  (snipped)
>
> I am trying to clean up a volume with several alternate couple datasets
> on it.  For  CFRM and LOGR, I just used IXCL1DSU to allocate alternates
> and SETXCF CPL,ACOUPLEd to them and that freed up the datasets so I
> could delete them.  But the XCF and OMVS CDSes are a problem.  I can't
> delete them because they're in use by XCFAS (shared enq).  SETXCF won't
> do anything because "IXC388I SETXCF COUPLE,ACOUPLE requires type OMVS to
> active on this system" and the same message for XCF.


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

Re: file types

[Farley, Peter x23353]

Still should work, but only for QSAM files.  To work on VSAM files would 
require reverse engineering the OCO FIB structure in the COBOL runtime to find 
the ACB.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andreas F. Geissbuehler
Sent: Tuesday, February 11, 2014 9:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: file types

IMHO defining two FD's wins the simplicity and clarity medal. However I used 
the subroutine method in the (distant!) past to change the DDNAME on the fly:
CLOSE FD-FILE-NAME.
MOVE IN-REGION TO DDNAME-SUFFIX.
CALL 'FDFIXUP' USING FD-FILE-NAME, DDNAME.
OPEN OUTPUT FD-FILE-NAME.
e.g. to write / output each region's report (-section) to its own DD-statement 
(RJE remote printing / routing, microfiche). I don't know but expect it to 
still work in the current COBOL releases.

--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: XCFAS holding OMVS and XCF CDSes

[Skip Robinson]

I should have amplified. For XCF, there is no such thing as an 'invalid' 
couple type. If the TYPE= specified is not in use in the sysplex, he does 
not assume a typo. He assumes that the type named is not (yet?) in use. 
For the types that are actually in use, issue D XCF,CPL. All in-use couple 
data sets are displayed along with the type associated with each. Your 
SETXCF commands must name (or default to) one of those types

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



From:   Skip Robinson 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   02/11/2014 07:14 AM
Subject:Re: XCFAS holding OMVS and XCF CDSes
Sent by:IBM Mainframe Discussion List 



The problem is that you're using the wrong TYPE keywords. They should be 
TYPE=SYSPLEX and TYPE=BPXMCDS . 

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



From:   Gary Weinhold 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   02/11/2014 07:09 AM
Subject:Re: XCFAS holding OMVS and XCF CDSes
Sent by:IBM Mainframe Discussion List 



Thanks for the responses, Skip and Lizette,

I probably wasn't clear that I did issue SETXCF 
CPL,ACOUPLE=SYS2.DKLOMVS.CDS03,TYPE=OMVS and received "IXC388I SETXCF 
COUPLE,ACOUPLE REQUIRES TYPE OMVS TO BE ACTIVE ON THIS SYSTEM" and 
similarly for TYPE=XCF.

I suspect it's something to do with the Basicness of the sysplex (no 
coupling facility), so I guess updating the COUPLExx PARMLIB members and 
reIPLing is the only way to go.

Gary Weinhold
Data Kinetics, Ltd.


From:Skip Robinson  (snipped)

In any case, as long as TYPE= is correct for the couple data set(s) you're 

manipulating, you should have no problem.

From:   Lizette Koehler  (snipped)

I think the same process you used for the CFRM and LOGR can be used for
the others.  each one is a TYPE in the environment.  I would check the
manual, but I think you can create new files and switch them like the
CFRM.  Or you create new files, update parmlib and IPL.

-Original Message-

> From: Gary Weinhold  (snipped)
>
> I am trying to clean up a volume with several alternate couple datasets
> on it.  For  CFRM and LOGR, I just used IXCL1DSU to allocate alternates
> and SETXCF CPL,ACOUPLEd to them and that freed up the datasets so I
> could delete them.  But the XCF and OMVS CDSes are a problem.  I can't
> delete them because they're in use by XCFAS (shared enq).  SETXCF won't
> do anything because "IXC388I SETXCF COUPLE,ACOUPLE requires type OMVS to
> active on this system" and the same message for XCF.


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

Re: DF/SORT, joinkeys or splice ?

[Sri h Kolusu]

Tony,

It is quite easy to get the matching records from both files. Here is a 
DFSORT JCL which will give you the desired results. I assumed that your 
inputs are already pre-sorted on the key to be matched. If they are not 
then you just need to remove SORTED,NOSEQCK parms from the control cards.

//STEP0100 EXEC PGM=SORT 
//SYSOUT   DD SYSOUT=* 
//INPUT1   DD * 
KEY1 DATA-X 
KEY1 DATA-Y 
KEY1 DATA-Z 
KEY2 DATA-M 
KEY2 DATA-N 
KEY2 DATA-O 
//INPUT2   DD * 
KEY1 BLAH 
KEY2 BLAH 
//SORTOUT  DD SYSOUT=* 
//SYSINDD * 
  OPTION COPY 
  JOINKEYS F1=INPUT1,FIELDS=(1,4,A),SORTED,NOSEQCK 
  JOINKEYS F2=INPUT2,FIELDS=(1,4,A),SORTED,NOSEQCK 
  REFORMAT FIELDS=(F2:1,12,F1:6,10) 
//*

Check this link which explains in detail about Joinkeys

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICE1CA60/4.0?

Further if you have any questions please let me know

Thanks,
Kolusu
DFSORT Development
IBM Corporation

IBM Mainframe Discussion List  wrote on 
02/11/2014 06:28:26 AM:

> From: TonyICLOUD 
> To: IBM-MAIN@listserv.ua.edu, 
> Date: 02/11/2014 06:29 AM
> Subject: DF/SORT, joinkeys or splice ?
> Sent by: IBM Mainframe Discussion List 
> 
> I'm trying to match-merge 2 input files based on a key.  I want to 
> create an output file with a record for every key from input1 plus all 
> records with a match key from input2.  I haven't found a specific 
> example in the books so I'm asking for help.
> 
> What I have:
> 
> //input1 dd *
> key1 blah
> key2 blah
> //input2 dd*
> key1 data-x
> key1 data-y
> key1 data-z
> key2 data-m
> key2 data-n
> key2 data-o
> 
> What I wish to have, an output record per key from input1 times each key 

> value found from input2 :
> 
> key1 blah data-x
> key1 blah data-y
> key1 blah data-z
> key2 blah data-m
> key2 blah data-n
> key2 blah data-o
> 
> --
> 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: To restore Purged STC output

[Ed Jaffe]

On 2/10/2014 9:01 PM, mf db wrote:

Is there a possibility of recovering a particular Purged STC back to spool ?


If you purged only a subset of output files from the STC, it is often 
possible to recover them with the right tools. If you purged the entire 
job, no recovery is possible...


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: To restore Purged STC output

[Lizette Koehler]

To Ed's point.

If the STC is still running and you only purged a small subset and you DO
NOT HAVE SPIN=CLOSE,FREE=UNALLOC

In SDSF issue the ST command.  Then prefix the name of your STC.

Issue a ? (question mark) next to the name.  If there is any output
available, you can see it there.

Otherwise - purged is gone.

In JES2 if there is any part of the job on SPOOL and it does not use
SPIN=CLOSE,FREE=UNALLOC, then all of the job is still on the spool and
visible from the ST function.  JES2 will only purge when all parts are
purged.  That is why when a job has a step like IEBGENR and the only sysout
you find in O function is the IEBGENER step, if you did an ST you may see
the entire job still left on JES2.



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ed Jaffe
> Sent: Tuesday, February 11, 2014 9:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: To restore Purged STC output
> 
> On 2/10/2014 9:01 PM, mf db wrote:
> > Is there a possibility of recovering a particular Purged STC back to
spool ?
> 
> If you purged only a subset of output files from the STC, it is often
possible to
> recover them with the right tools. If you purged the entire job, no
recovery is
> possible...
> 
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/

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

Re: To restore Purged STC output

[John McKown]

But, even in these cases, you cannot "restore" it back into the SPOOL as it
was before it was deleted. You may, at most, be able to retrieve the data
which was in it and place it in a different SPOOL data set or a DISK data
set or . But you can't make it to be part of the job's output again.


On Tue, Feb 11, 2014 at 10:32 AM, Lizette Koehler
wrote:

> To Ed's point.
>
> If the STC is still running and you only purged a small subset and you DO
> NOT HAVE SPIN=CLOSE,FREE=UNALLOC
>
> In SDSF issue the ST command.  Then prefix the name of your STC.
>
> Issue a ? (question mark) next to the name.  If there is any output
> available, you can see it there.
>
> Otherwise - purged is gone.
>
> In JES2 if there is any part of the job on SPOOL and it does not use
> SPIN=CLOSE,FREE=UNALLOC, then all of the job is still on the spool and
> visible from the ST function.  JES2 will only purge when all parts are
> purged.  That is why when a job has a step like IEBGENR and the only sysout
> you find in O function is the IEBGENER step, if you did an ST you may see
> the entire job still left on JES2.
>
>
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Ed Jaffe
> > Sent: Tuesday, February 11, 2014 9:24 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: To restore Purged STC output
> >
> > On 2/10/2014 9:01 PM, mf db wrote:
> > > Is there a possibility of recovering a particular Purged STC back to
> spool ?
> >
> > If you purged only a subset of output files from the STC, it is often
> possible to
> > recover them with the right tools. If you purged the entire job, no
> recovery is
> > possible...
> >
> > --
> > Edward E Jaffe
> > Phoenix Software International, Inc
> > 831 Parkview Drive North
> > El Segundo, CA 90245
> > http://www.phoenixsoftware.com/
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Wasn't there something about a PASCAL programmer knowing the value of
everything and the Wirth of nothing?

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: Error overriding concatenated DD in PROC where one is instream data

[Ray Mullins]

Hi everyone,

I played a bit with this over the past couple of days, with several 
combinations of DDs, and it all points to the DD that's used to tell 
allocation to leave the second DD as-is. It's incorrectly being processed 
with a generated temporary data set name instead of letting the instream be.


I'm going to APAR this. I would appreciate it, though, if someone who has 
access to a 2.1 system could run my example JCL (it's just using IEBGENER 
and an instream PROC) to see if it's fixed there.


Cheers,
Ray

On 2014-02-07 06:25, Pommier, Rex wrote:

Ray,

Just out of curiosity, would it work if you added a third DD card to the 
original SYSLPARM DD concatenation?  The JCL ref manual doesn't explicitly 
state the override needs something to override, but it might be worth a try.

Can you try something like:

//SYSLPARM DD DSN=&&tempds,DISP=(OLD,DELETE)
// DD *
some more binder parms overriding the first one
/*
// DD *
A comment line or do-nothing line (or possibly nothing at all)
/*

And then your override would have the second DD * to be overridden.

Or maybe the third DD could be DD DUMMY?

Rex


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ray Mullins
Sent: Thursday, February 06, 2014 4:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Error overriding concatenated DD in PROC where one is instream data

Hello, long time absent.

In z/OS 1.13, I'm playing with instream data in a PROC for the first time to
try to simplify some bind JCL and I've run into an error. It's an atypical
situation, I realize.

In the PROC I have

//* Following is a data set created with ISRSCAN from a concatenation
//SYSLPARM DD DSN=&&tempds,DISP=(OLD,DELETE)
// DD *
some more binder parms overriding the first one
//*

Because one of the program objects needs different stuff, I've coded

//DRVASTRT EXEC MMB,symbolics
//B.SYSLPARM DD
// DD
// DD *
different parms to override a couple in the first two DDs
//*

The job hits this step and gives me

IEF344I MMDB B DRVASTRT SYSLPARM+001 - ALLOCATION FAILED DUE TO DATA
FACILITY SYSTEM ERROR
IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET
SYS14037.T114830.RA000.MMDB.R0484370

It seems like conversion/interpretation has skipped the fact that I'm not
overriding the second DD in the concatenation and is generating a data set
name, instead of noting that it's a blank DD and just leaving the original
DD alone.

  From a logic standpoint, this makes sense, but I'm wondering if this is WAD
(thou shalt not override instream data) or maybe DD concatenation needs some
extra checks if the underlying DD is instream (or does not have a DSN). I am
curious as how this would be handled if the DD was a SUBSYS.

Yes, I could put the instream data in a PDS member, but for various reasons
that would complicate the underlying binder proc; let's just say we'd rather
not go there.

So, what's the consensus? WAD? APARable?

Cheers,
Ray




--
M. Ray Mullins
Roseville, CA, USA
http://www.catherdersoftware.com/

German is essentially a form of assembly language consisting entirely of far 
calls heavily accented with throaty guttural sounds. ---ilvi
French is essentially German with messed-up pronunciation and spelling.  
--Robert B Wilson
English is essentially French converted to 7-bit ASCII.  ---Christophe Pierret 
[for Alain LaBonté]

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

Re: XCFAS holding OMVS and XCF CDSes

[Jerry Whitteridge]

(Quick Reply with no research)

Does the fact he is trying to add an as yet unused set of datasets mean he 
should add the PCOUPLE first and then the ACOUPLE ?

Jerry Whitteridge
Lead Systems Programmer
Safeway Inc.
925 951 4184

If you feel in control
you just aren't going fast enough.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Skip Robinson
Sent: Tuesday, February 11, 2014 7:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XCFAS holding OMVS and XCF CDSes

I should have amplified. For XCF, there is no such thing as an 'invalid' 
couple type. If the TYPE= specified is not in use in the sysplex, he does 
not assume a typo. He assumes that the type named is not (yet?) in use. 
For the types that are actually in use, issue D XCF,CPL. All in-use couple 
data sets are displayed along with the type associated with each. Your 
SETXCF commands must name (or default to) one of those types

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



From:   Skip Robinson 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   02/11/2014 07:14 AM
Subject:Re: XCFAS holding OMVS and XCF CDSes
Sent by:IBM Mainframe Discussion List 



The problem is that you're using the wrong TYPE keywords. They should be 
TYPE=SYSPLEX and TYPE=BPXMCDS . 

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



From:   Gary Weinhold 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   02/11/2014 07:09 AM
Subject:Re: XCFAS holding OMVS and XCF CDSes
Sent by:IBM Mainframe Discussion List 



Thanks for the responses, Skip and Lizette,

I probably wasn't clear that I did issue SETXCF 
CPL,ACOUPLE=SYS2.DKLOMVS.CDS03,TYPE=OMVS and received "IXC388I SETXCF 
COUPLE,ACOUPLE REQUIRES TYPE OMVS TO BE ACTIVE ON THIS SYSTEM" and 
similarly for TYPE=XCF.

I suspect it's something to do with the Basicness of the sysplex (no 
coupling facility), so I guess updating the COUPLExx PARMLIB members and 
reIPLing is the only way to go.

Gary Weinhold
Data Kinetics, Ltd.


From:Skip Robinson  (snipped)

In any case, as long as TYPE= is correct for the couple data set(s) you're 

manipulating, you should have no problem.

From:   Lizette Koehler  (snipped)

I think the same process you used for the CFRM and LOGR can be used for
the others.  each one is a TYPE in the environment.  I would check the
manual, but I think you can create new files and switch them like the
CFRM.  Or you create new files, update parmlib and IPL.

-Original Message-

> From: Gary Weinhold  (snipped)
>
> I am trying to clean up a volume with several alternate couple datasets
> on it.  For  CFRM and LOGR, I just used IXCL1DSU to allocate alternates
> and SETXCF CPL,ACOUPLEd to them and that freed up the datasets so I
> could delete them.  But the XCF and OMVS CDSes are a problem.  I can't
> delete them because they're in use by XCFAS (shared enq).  SETXCF won't
> do anything because "IXC388I SETXCF COUPLE,ACOUPLE requires type OMVS to
> active on this system" and the same message for XCF.


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


"Email Firewall" made the following annotations.
--

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

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

Re: Large Multi-Volume Physical Sequential allocation question

[Cosby, Bob - OCFO]

Question 1: I see you got 3 extents. How many of the 7 volumes did that cover? 
Two (2) mod-9's; RLSE released all the other requested space.
From MVS File-Aid
C-HH  D A T A S E T   N A M E --- Org   
Trks   XofY STATVOLSER
02999 00 NFCPPARA.B5I.EHRI.HS00.SF50.XMLT PS   
59970   1  2 PRDC46
03860 00 NFCPPARA.B5I.EHRI.HS00.SF50.XMLT PS   
34275   1  1   PRDJ77

Question 2: what amount was allocated in the three extents?
94245tracks or 6283cylinders: see below

3.4 Data Set Information shows 6654 cylinders (cannot explain that)
Data Set Name . . . . : NFCPPARA.B5I.EHRI.HS00.SF50.XMLT

General Data   Current Allocation
 Management class . . : **None**Allocated cylinders : 6,654
 Storage class  . . . : **None**Allocated extents . : 3
  Volume serial . . . : PRDC46 +
  Device type . . . . : 3390
 Data class . . . . . : **None**
  Organization  . . . : PS Current Utilization
  Record format . . . : FB  Used cylinders  . . : 6,654
  Record length . . . : 200 Used extents  . . . : 3
  Block size  . . . . : 27800
  1st extent cylinders: 3998
  Secondary cylinders : 4369   Dates
  Data set name type  : LARGE   Creation date . . . : 2014/02/05
  SMS Compressible. . : NO  Referenced date . . : 2014/02/05
Expiration date . . : ***None***


Question 3: Any reason not to use an SMS pool? Yes; we are a Payroll Processing 
center that pays 660,000 Federal Employees utilizing Computer Associates
IDMS.  A lot of the code was written in the 1970's and 1980's; 
more importantly a lot of the batch processes that are used
Un-catalogs DSNs which my understanding in SMS un-catalogs does 
a delete which the programmer could not go back to a previous step where a  
DSN was un-cataloged re-catalog the DSN and start processing from that 
step.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, February 10, 2014 5:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large Multi-Volume Physical Sequential allocation question

I see you got 3 extents. How many of the 7 volumes did that cover?  The VOLUME 
SERIAL shows multiple volumes, but it is helpful to know how many were used.

next, what amount was allocated in the three extents?  I would suspect that for 
non sms the VOL= might need to include serial numbers it could go to.



Any reason not to use an SMS pool?

Lizette


-Original Message-
>From: "Cosby, Bob - OCFO" 
>Sent: Feb 10, 2014 2:42 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Large Multi-Volume Physical Sequential allocation question
>
>Lizette you are correct I found out from Tom this has been around since OS 360 
>must have missed that part of the class; at any rate we are starting to 
>allocate NON SMS DSNs that span multiple volsers.  We kept getting SB37 abend 
>until we used the UNIT=(3390,P) and VOL=(,,,7) parameters.
>
>Data Set Name . . . . : NFCPPARA.B5I.EHRI.HS00.SF50.XMLT
>
>General Data   Current Allocation
> Management class . . : **None**Allocated cylinders : 6,654
> Storage class  . . . : **None**Allocated extents . : 3
>  Volume serial . . . : PRDC46 +
>  Device type . . . . : 3390
> Data class . . . . . : **None**
>  Organization  . . . : PS Current Utilization
>  Record format . . . : FB  Used cylinders  . . : 6,654
>  Record length . . . : 200 Used extents  . . . : 3
>  Block size  . . . . : 27800
>  1st extent cylinders: 3998
>  Secondary cylinders : 4369   Dates
>  Data set name type  : LARGE   Creation date . . . : 2014/02/05
>  SMS Compressible. . : NO  Referenced date . . : 2014/02/05
>Expiration date . . :
>***None***
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>On Behalf Of Lizette Koehler
>Sent: Friday, February 07, 2014 7:52 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Large Multi-Volume Physical Sequential allocation question
>
>The P indicates
>
>Asks the system to allocate the same number of devices as requested in the 
>VOLUME volume-count or SER subparameter, whichever is higher. Thus, all 
>volumes for the data set are mounted in parallel.
>
>If you specify the P subparameter for system-managed DASD, the system
>ignores it. If you specify the P subparameter for system-managed tape
>libraries, the system honors it
>
>
>So according to the JCL Reference manual, the P will be ignored for DASD.
>Since you say NON-SMS I am not sure.
>
>However, you have only asked for 7 volumes.  What size is the volumes it is 
>getting allocated on?  3390-3,3390-27
>Is ther

Re: VTOCIX out of VIRs, how to reorg?

[Mike Schwab]

OK.  We just did a free vol.  VTOC shows only the VTOCIX, VVDS, and
SMALLLDS.  Listcat of the SMALLDS shows 1 record, records added and
deleted don't match.  IDCAMS PRINT of the SMALLDS shows one record,
1st byte 'Z' followed by 43 '9', Remainder is X'00' out to X'C7'.

Is this an end of file marker and the SMALLDS is empty?

On Fri, Jan 31, 2014 at 9:47 AM, Mike Schwab  wrote:
> SDSP=150KB
>
> On Wed, Jan 29, 2014 at 5:38 PM, Graham Harris  wrote:
>> What is your SDSP threshold value?  (i.e. the SDSP= value on a query setsys)
>>
>>
>> On 29 January 2014 21:30, Mike Schwab  wrote:
>>
>>> Yes.  They were all INDEX(0,1,074) VTOC(05,00,1500).
>>> When we get them empty we will re-init as INDEX(0,1,149) VTOC(10,00,1305).
>>> Yesterday this LPAR had 192,000 HSM log file records.
>>> 64,000-67,000 records in the SDSP on each volume.
>>> 21,000-24,000 files on the ML1 volumes, most 1 track, biggest 23 tracks..
>>>
>>>
>>> On Wed, Jan 29, 2014 at 1:53 PM, Staller, Allan 
>>> wrote:
>>> > 1) AFAIK there is no way to re-size the VTOCIX except  a BUILDIX
>>> OSVTOC/BUILDIX IXVTOC  sequence.
>>> >
>>> > Specifically an example (slightly modified from the manual
>>>  "GC35-0033-39 Device Support Facilities (ICKDSF) User's Guide and
>>> Reference"):
>>> >
>>> > //jobname JOB
>>> > //STEP1  EXEC PGM=ICKDSF,PARM='NOREPLYU'
>>> > //SYSPRINT DD SYSOUT=A
>>> > //DDCARD DD UNIT=(3390,,DEFER),VOL=(PRIVATE,SER=VL3390),
>>> > // DISP=OLD
>>> > //SYSIN DD *
>>> > BUILDIX DDNAME(DDCARD) OS PURGE
>>>  <- Deletes
>>> the existing index
>>> > /*
>>> > //STEP2 EXEC PGM=ICKDSF
>>> > //SYSPRINT DD SYSOUT=A
>>> > //VOLDD DD UNIT=(3390,,DEFER),VOL=(PRIVATE,SER=339003),  <
>>> Allocates a new index.
>>> > // DSN=SYS1.VTOCIX.V39003,DISP=(NEW,KEEP),
>>> > // SPACE=(TRK,10,,CONTIG)
>>> > //SYSIN DD *
>>> > BUILDIX DDNAME(VOLDD) IXVTOC
>>> > /*
>>> >
>>> > 2) The previously mentioned MAXVTOC/MAXVTOCIX sizes are in TABLE 57 on
>>> page 586 of manual  "GC35-0033-39 Device Support Facilities (ICKDSF) User's
>>> Guide and Reference"):
>>> > 3) I believe we have established that there is adequate space in the
>>> SDSP dataset(s) via "HI-A-RBA -1,592,647,680, HI-U-RBA -454,471,680,
>>> 455,270,400, 452,075,520, so under 33%"
>>> > 4) I believe we have established that there is adequate space on the
>>> volume(s) via " Volumes are 45-48% free."
>>> >
>>> >
>>> > Something seems to be missing from the scenario. *IF* MOBIUS is placing
>>> HLQ.pgmname.ddname.R#.Dyymmdd.Thhmmss into the SDSP dataset(s),
>>> > *WHY* would there be *ANY* issues w/the VTOCIX?
>>> >
>>> > Are the VTOCIX's on these 3 volumes the same size as the remaining
>>> volumes?
>>> >
>>> >
>>> > 
>>> > The VIR count was down to 3 on the 3 volumes, other LPAR ML1 volumes
>>> have 236-1538 VIRs.
>>> > Volumes are 45-48% free.
>>> > HI-A-RBA -1,592,647,680, HI-U-RBA -454,471,680, 455,270,400,
>>> 452,075,520, so under 33%.
>>> > 
>>> >
>>> > --
>>> > 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
>>>
>>
>> --
>> 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?



-- 
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: VTOCIX out of VIRs, how to reorg?

[Staller, Allan]

At this point:
1) delete the SMALLDS, it is empty.
2) re-init the volume with appropriate VTOC/VTOCIX
3) redefine the SMALLDS and prime it.
4) Add the volume back into HSM for use.

Al Staller | Z Systems Programmer | KBM Group | (Tel) 972 664-3565 | 
allan.stal...@kbmg.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Tuesday, February 11, 2014 12:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTOCIX out of VIRs, how to reorg?

OK.  We just did a free vol.  VTOC shows only the VTOCIX, VVDS, and SMALLLDS.  
Listcat of the SMALLDS shows 1 record, records added and deleted don't match.  
IDCAMS PRINT of the SMALLDS shows one record, 1st byte 'Z' followed by 43 '9', 
Remainder is X'00' out to X'C7'.

Is this an end of file marker and the SMALLDS is empty?

On Fri, Jan 31, 2014 at 9:47 AM, Mike Schwab  wrote:
> SDSP=150KB
>
> On Wed, Jan 29, 2014 at 5:38 PM, Graham Harris  wrote:
>> What is your SDSP threshold value?  (i.e. the SDSP= value on a query 
>> setsys)
>>
>>
>> On 29 January 2014 21:30, Mike Schwab  wrote:
>>
>>> Yes.  They were all INDEX(0,1,074) VTOC(05,00,1500).
>>> When we get them empty we will re-init as INDEX(0,1,149) VTOC(10,00,1305).
>>> Yesterday this LPAR had 192,000 HSM log file records.
>>> 64,000-67,000 records in the SDSP on each volume.
>>> 21,000-24,000 files on the ML1 volumes, most 1 track, biggest 23 tracks..
>>>
>>>
>>> On Wed, Jan 29, 2014 at 1:53 PM, Staller, Allan 
>>> 
>>> wrote:
>>> > 1) AFAIK there is no way to re-size the VTOCIX except  a BUILDIX
>>> OSVTOC/BUILDIX IXVTOC  sequence.
>>> >
>>> > Specifically an example (slightly modified from the manual
>>>  "GC35-0033-39 Device Support Facilities (ICKDSF) User's Guide and
>>> Reference"):
>>> >
>>> > //jobname JOB
>>> > //STEP1  EXEC PGM=ICKDSF,PARM='NOREPLYU'
>>> > //SYSPRINT DD SYSOUT=A
>>> > //DDCARD DD UNIT=(3390,,DEFER),VOL=(PRIVATE,SER=VL3390),
>>> > // DISP=OLD
>>> > //SYSIN DD *
>>> > BUILDIX DDNAME(DDCARD) OS PURGE
>>>  <- 
>>> Deletes the existing index
>>> > /*
>>> > //STEP2 EXEC PGM=ICKDSF
>>> > //SYSPRINT DD SYSOUT=A
>>> > //VOLDD DD UNIT=(3390,,DEFER),VOL=(PRIVATE,SER=339003),  <
>>> Allocates a new index.
>>> > // DSN=SYS1.VTOCIX.V39003,DISP=(NEW,KEEP),
>>> > // SPACE=(TRK,10,,CONTIG)
>>> > //SYSIN DD *
>>> > BUILDIX DDNAME(VOLDD) IXVTOC
>>> > /*
>>> >
>>> > 2) The previously mentioned MAXVTOC/MAXVTOCIX sizes are in TABLE 
>>> > 57 on
>>> page 586 of manual  "GC35-0033-39 Device Support Facilities (ICKDSF) 
>>> User's Guide and Reference"):
>>> > 3) I believe we have established that there is adequate space in 
>>> > the
>>> SDSP dataset(s) via "HI-A-RBA -1,592,647,680, HI-U-RBA -454,471,680, 
>>> 455,270,400, 452,075,520, so under 33%"
>>> > 4) I believe we have established that there is adequate space on 
>>> > the
>>> volume(s) via " Volumes are 45-48% free."
>>> >
>>> >
>>> > Something seems to be missing from the scenario. *IF* MOBIUS is 
>>> > placing
>>> HLQ.pgmname.ddname.R#.Dyymmdd.Thhmmss into the SDSP dataset(s),
>>> > *WHY* would there be *ANY* issues w/the VTOCIX?
>>> >
>>> > Are the VTOCIX's on these 3 volumes the same size as the remaining
>>> volumes?
>>> >
>>> >
>>> > 
>>> > The VIR count was down to 3 on the 3 volumes, other LPAR ML1 
>>> > volumes
>>> have 236-1538 VIRs.
>>> > Volumes are 45-48% free.
>>> > HI-A-RBA -1,592,647,680, HI-U-RBA -454,471,680, 455,270,400,
>>> 452,075,520, so under 33%.
>>> > 
>>> >
>>> > --
>>> >  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
>>>
>>
>> -
>> - 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?



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

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

Re: XCFAS holding OMVS and XCF CDSes

[Skip Robinson]

A new data set (of a type that is already in use) is always added this 
way:

1. Do PSWITCH
2. Add ACOUPLE
3. For a second new data set, repeat steps 1 and 2. 

You never add PCOUPLE. You promote from ACOUPLE to PCOUPLE via PSWITCH. 
.
.
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



From:   Jerry Whitteridge 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   02/11/2014 09:30 AM
Subject:Re: XCFAS holding OMVS and XCF CDSes
Sent by:IBM Mainframe Discussion List 



(Quick Reply with no research)

Does the fact he is trying to add an as yet unused set of datasets mean he 
should add the PCOUPLE first and then the ACOUPLE ?

Jerry Whitteridge
Lead Systems Programmer
Safeway Inc.
925 951 4184

If you feel in control
you just aren't going fast enough.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Skip Robinson
Sent: Tuesday, February 11, 2014 7:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XCFAS holding OMVS and XCF CDSes

I should have amplified. For XCF, there is no such thing as an 'invalid' 
couple type. If the TYPE= specified is not in use in the sysplex, he does 
not assume a typo. He assumes that the type named is not (yet?) in use. 
For the types that are actually in use, issue D XCF,CPL. All in-use couple 

data sets are displayed along with the type associated with each. Your 
SETXCF commands must name (or default to) one of those types

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



From:   Skip Robinson 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   02/11/2014 07:14 AM
Subject:Re: XCFAS holding OMVS and XCF CDSes
Sent by:IBM Mainframe Discussion List 



The problem is that you're using the wrong TYPE keywords. They should be 
TYPE=SYSPLEX and TYPE=BPXMCDS . 

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



From:   Gary Weinhold 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   02/11/2014 07:09 AM
Subject:Re: XCFAS holding OMVS and XCF CDSes
Sent by:IBM Mainframe Discussion List 



Thanks for the responses, Skip and Lizette,

I probably wasn't clear that I did issue SETXCF 
CPL,ACOUPLE=SYS2.DKLOMVS.CDS03,TYPE=OMVS and received "IXC388I SETXCF 
COUPLE,ACOUPLE REQUIRES TYPE OMVS TO BE ACTIVE ON THIS SYSTEM" and 
similarly for TYPE=XCF.

I suspect it's something to do with the Basicness of the sysplex (no 
coupling facility), so I guess updating the COUPLExx PARMLIB members and 
reIPLing is the only way to go.

Gary Weinhold
Data Kinetics, Ltd.


From:Skip Robinson  (snipped)

In any case, as long as TYPE= is correct for the couple data set(s) you're 


manipulating, you should have no problem.

From:   Lizette Koehler  (snipped)

I think the same process you used for the CFRM and LOGR can be used for
the others.  each one is a TYPE in the environment.  I would check the
manual, but I think you can create new files and switch them like the
CFRM.  Or you create new files, update parmlib and IPL.

-Original Message-

> From: Gary Weinhold  (snipped)
>
> I am trying to clean up a volume with several alternate couple datasets
> on it.  For  CFRM and LOGR, I just used IXCL1DSU to allocate alternates
> and SETXCF CPL,ACOUPLEd to them and that freed up the datasets so I
> could delete them.  But the XCF and OMVS CDSes are a problem.  I can't
> delete them because they're in use by XCFAS (shared enq).  SETXCF won't
> do anything because "IXC388I SETXCF COUPLE,ACOUPLE requires type OMVS to
> active on this system" and the same message for XCF.


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

Was: Implicit VVDS creation now: FDR & VVDS's

[Ed Gould]

I do not have access to the FDR manuals now.
I am trying to remember if FDR consolidates the SYS1.VVDS extents  
*AND* releases unused extents of the VVDS?


I would guess that it does but without manuals its hard to guess.
BTW FDR is one of the few companies I cannot say enough good things  
about, congratulations IMHO.


Ed

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

Re: To restore Purged STC output

[Ed Jaffe]

On 2/11/2014 8:38 AM, John McKown wrote:

But, even in these cases, you cannot "restore" it back into the SPOOL as it
was before it was deleted. You may, at most, be able to retrieve the data
which was in it and place it in a different SPOOL data set or a DISK data
set or . But you can't make it to be part of the job's output again.


(E)JES has, since MVS/ESA 4.2, allowed you to make a new copy on 
JES2/JES3 SPOOL of the "deleted" data with the original job name and 
jobid so the banner pages (if needed) will print as expected. Presumably 
other tools have implemented similar capabilities since that time...


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

IBMLINK SR problems?

[Jousma, David]

Anyone try to open a new ticket today on Service Request?   IE9 here on WIN7, 
and it fails.  Both for me, and a team mate after you fill out the ticket, and 
click on open, comes back with the form emptied out, and error messages saying 
to fill in subject, problem text, etc.  Form is messed up too, SEV1 is gone, 
etc.  I find it hard to believe it is a global thing since no one else has said 
anything, however just as hard to believe it is a local thing either.

_
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: IBMLINK SR problems?

[Wissink, Brad [ITSYS]]

Just entered a new SR ticket at 2:00 pm and everything was fine.   I use 
Firefox.

Brad Wissink 
Information Technology Services 
Iowa State University 
515-294-3088 
"If it ain't broke, you ain't trying" - Red Green

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, February 11, 2014 2:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBMLINK SR problems?

Anyone try to open a new ticket today on Service Request?   IE9 here on WIN7, 
and it fails.  Both for me, and a team mate after you fill out the ticket, and 
click on open, comes back with the form emptied out, and error messages saying 
to fill in subject, problem text, etc.  Form is messed up too, SEV1 is gone, 
etc.  I find it hard to believe it is a global thing since no one else has said 
anything, however just as hard to believe it is a local thing either.

_
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: IBMLINK SR problems?

[Harold Zbiegien]

tried to update a PMR, got the same problem, IE9, I deleted cache, retried, 
same problem

 


 From: "Wissink, Brad [ITSYS]" 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, February 11, 2014 3:41 PM
Subject: Re: IBMLINK SR problems?
  

Just entered a new SR ticket at 2:00 pm and everything was fine.   I use 
Firefox.

Brad Wissink 
Information Technology Services 
Iowa State University 
515-294-3088 
"If it ain't broke, you ain't trying" - Red Green

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, February 11, 2014 2:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBMLINK SR problems?

Anyone try to open a new ticket today on Service Request?   IE9 here on WIN7, 
and it fails.  Both for me, and a team mate after you fill out the ticket, and 
click on open, comes back with the form emptied out, and error messages saying 
to fill in subject, problem text, etc.  Form is messed up too, SEV1 is gone, 
etc.  I find it hard to believe it is a global thing since no one else has said 
anything, however just as hard to believe it is a local thing either.

_
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: IBMLINK SR problems?

[Jousma, David]

Whew.  Glad I am not alone.   There is a statement on their webpage to IE10 
users, with a work around, which I tried to no avail.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Harold Zbiegien
Sent: Tuesday, February 11, 2014 3:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBMLINK SR problems?

tried to update a PMR, got the same problem, IE9, I deleted cache, retried, 
same problem

 


 From: "Wissink, Brad [ITSYS]" 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, February 11, 2014 3:41 PM
Subject: Re: IBMLINK SR problems?
  

Just entered a new SR ticket at 2:00 pm and everything was fine.   I use 
Firefox.

Brad Wissink 
Information Technology Services 
Iowa State University 
515-294-3088 
"If it ain't broke, you ain't trying" - Red Green

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, February 11, 2014 2:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IBMLINK SR problems?

Anyone try to open a new ticket today on Service Request?   IE9 here on WIN7, 
and it fails.  Both for me, and a team mate after you fill out the ticket, and 
click on open, comes back with the form emptied out, and error messages saying 
to fill in subject, problem text, etc.  Form is messed up too, SEV1 is gone, 
etc.  I find it hard to believe it is a global thing since no one else has said 
anything, however just as hard to believe it is a local thing either.

_
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

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: VTOCIX out of VIRs, how to reorg?

[Mike Schwab]

Looks like a successful re-init with larger VTOCIX and SMALLDS.

On Tue, Feb 11, 2014 at 12:51 PM, Staller, Allan  wrote:
> At this point:
> 1) delete the SMALLDS, it is empty.
> 2) re-init the volume with appropriate VTOC/VTOCIX
> 3) redefine the SMALLDS and prime it.
> 4) Add the volume back into HSM for use.
>
> Al Staller | Z Systems Programmer | KBM Group | (Tel) 972 664-3565 | 
> allan.stal...@kbmg.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Mike Schwab
> Sent: Tuesday, February 11, 2014 12:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VTOCIX out of VIRs, how to reorg?
>
> OK.  We just did a free vol.  VTOC shows only the VTOCIX, VVDS, and SMALLLDS. 
>  Listcat of the SMALLDS shows 1 record, records added and deleted don't 
> match.  IDCAMS PRINT of the SMALLDS shows one record, 1st byte 'Z' followed 
> by 43 '9', Remainder is X'00' out to X'C7'.
>
> Is this an end of file marker and the SMALLDS is empty?
>
> On Fri, Jan 31, 2014 at 9:47 AM, Mike Schwab  wrote:
>> SDSP=150KB
>>
>> On Wed, Jan 29, 2014 at 5:38 PM, Graham Harris  wrote:
>>> What is your SDSP threshold value?  (i.e. the SDSP= value on a query
>>> setsys)
>>>
>>>
>>> On 29 January 2014 21:30, Mike Schwab  wrote:
>>>
 Yes.  They were all INDEX(0,1,074) VTOC(05,00,1500).
 When we get them empty we will re-init as INDEX(0,1,149) VTOC(10,00,1305).
 Yesterday this LPAR had 192,000 HSM log file records.
 64,000-67,000 records in the SDSP on each volume.
 21,000-24,000 files on the ML1 volumes, most 1 track, biggest 23 tracks..


 On Wed, Jan 29, 2014 at 1:53 PM, Staller, Allan
 
 wrote:
 > 1) AFAIK there is no way to re-size the VTOCIX except  a BUILDIX
 OSVTOC/BUILDIX IXVTOC  sequence.
 >
 > Specifically an example (slightly modified from the manual
  "GC35-0033-39 Device Support Facilities (ICKDSF) User's Guide and
 Reference"):
 >
 > //jobname JOB
 > //STEP1  EXEC PGM=ICKDSF,PARM='NOREPLYU'
 > //SYSPRINT DD SYSOUT=A
 > //DDCARD DD UNIT=(3390,,DEFER),VOL=(PRIVATE,SER=VL3390),
 > // DISP=OLD
 > //SYSIN DD *
 > BUILDIX DDNAME(DDCARD) OS PURGE
  <-
 Deletes the existing index
 > /*
 > //STEP2 EXEC PGM=ICKDSF
 > //SYSPRINT DD SYSOUT=A
 > //VOLDD DD UNIT=(3390,,DEFER),VOL=(PRIVATE,SER=339003),  <
 Allocates a new index.
 > // DSN=SYS1.VTOCIX.V39003,DISP=(NEW,KEEP),
 > // SPACE=(TRK,10,,CONTIG)
 > //SYSIN DD *
 > BUILDIX DDNAME(VOLDD) IXVTOC
 > /*
 >
 > 2) The previously mentioned MAXVTOC/MAXVTOCIX sizes are in TABLE
 > 57 on
 page 586 of manual  "GC35-0033-39 Device Support Facilities (ICKDSF)
 User's Guide and Reference"):
 > 3) I believe we have established that there is adequate space in
 > the
 SDSP dataset(s) via "HI-A-RBA -1,592,647,680, HI-U-RBA -454,471,680,
 455,270,400, 452,075,520, so under 33%"
 > 4) I believe we have established that there is adequate space on
 > the
 volume(s) via " Volumes are 45-48% free."
 >
 >
 > Something seems to be missing from the scenario. *IF* MOBIUS is
 > placing
 HLQ.pgmname.ddname.R#.Dyymmdd.Thhmmss into the SDSP dataset(s),
 > *WHY* would there be *ANY* issues w/the VTOCIX?
 >
 > Are the VTOCIX's on these 3 volumes the same size as the remaining
 volumes?
 >
 >
 > 
 > The VIR count was down to 3 on the 3 volumes, other LPAR ML1
 > volumes
 have 236-1538 VIRs.
 > Volumes are 45-48% free.
 > HI-A-RBA -1,592,647,680, HI-U-RBA -454,471,680, 455,270,400,
 452,075,520, so under 33%.
 > 
 >
 > --
 >  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

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

Re: Large Multi-Volume Physical Sequential allocation question

[R.S.]

W dniu 2014-02-11 19:18, Cosby, Bob - OCFO pisze:
  
Question 3: Any reason not to use an SMS pool? Yes; we are a Payroll Processing center that pays 660,000 Federal Employees utilizing Computer Associates

 IDMS.  A lot of the code was written in the 1970's and 1980's; 
more importantly a lot of the batch processes that are used
 Un-catalogs DSNs which my understanding in SMS un-catalogs 
does a delete which the programmer could not go back to a previous step where a 
 DSN was un-cataloged re-catalog the DSN and start processing from 
that step.


That's the root reason why you have p roblems with quite elementary 
things. I don't criticize you, but I criticize the shop. You missed at 
least 20 year of improvements. SMS is 30 years old, catalog much more. 
BTW: I use code (partially) written in 1970's, but it's under current 
mainenance, it works with z/OS 1.13, DB2 (younger than the code!), and 
other really current features.


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.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote.



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

Re: Large Multi-Volume Physical Sequential allocation question

[Cosby, Bob - OCFO]

I agree 100% but here is our problem:
"What's the difference between obsolete hardware and obsolete software?"
Obsolete hardware is in a museum - Obsolete software is in
production running your business.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, February 11, 2014 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large Multi-Volume Physical Sequential allocation question

W dniu 2014-02-11 19:18, Cosby, Bob - OCFO pisze:
>
> Question 3: Any reason not to use an SMS pool? Yes; we are a Payroll 
> Processing center that pays 660,000 Federal Employees utilizing Computer 
> Associates
>  IDMS.  A lot of the code was written in the 1970's and 
> 1980's; more importantly a lot of the batch processes that are used
>  Un-catalogs DSNs which my understanding in SMS un-catalogs 
> does a delete which the programmer could not go back to a previous step where 
> a  DSN was un-cataloged re-catalog the DSN and start processing 
> from that step.

That's the root reason why you have p roblems with quite elementary things. I 
don't criticize you, but I criticize the shop. You missed at least 20 year of 
improvements. SMS is 30 years old, catalog much more.
BTW: I use code (partially) written in 1970's, but it's under current 
mainenance, it works with z/OS 1.13, DB2 (younger than the code!), and other 
really current features.

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.2014 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.696.052 złote.


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




This electronic message contains information generated by the USDA solely for 
the intended recipients. Any unauthorized interception of this message or the 
use or disclosure of the information it contains may violate the law and 
subject the violator to civil or criminal penalties. If you believe you have 
received this message in error, please notify the sender and delete the email 
immediately.

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

Re: Large Multi-Volume Physical Sequential allocation question

[Ed Gould]

Bob,

20++ years ago I ran into something like this and I started to  
educate the people (small bytes at a time) on how things should be  
done and how these changes can be instrumental in cost savings to the  
business (it was a semi not for profit business which made it doubly  
difficult) and it took several years of standing on the mound and  
preaching to management and anyone who might be in the decision  
making process and gradually things started to roll we got rid of  
IDMS and a whole lot of "old" thinking ... it took time and someone  
to stand up to management to show them how backwater they were in.  
Eventually it sunk in and the wheels started to move (it took 10  
years) but they finally adapted DB2 and got rid of the dead bodies  
that kept the company frozen.


You should be out preaching not hiding behind other peoples decisions  
and rewriting the standards manual and other basics.

Ed

On Feb 11, 2014, at 4:27 PM, Cosby, Bob - OCFO wrote:


I agree 100% but here is our problem:
"What's the difference between obsolete hardware and obsolete  
software?"

Obsolete hardware is in a museum - Obsolete software is in
production running your business.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM- 
m...@listserv.ua.edu] On Behalf Of R.S.

Sent: Tuesday, February 11, 2014 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large Multi-Volume Physical Sequential allocation  
question


W dniu 2014-02-11 19:18, Cosby, Bob - OCFO pisze:


Question 3: Any reason not to use an SMS pool? Yes; we are a  
Payroll Processing center that pays 660,000 Federal Employees  
utilizing Computer Associates
 IDMS.  A lot of the code was written in the  
1970's and 1980's; more importantly a lot of the batch processes  
that are used
 Un-catalogs DSNs which my understanding in SMS un- 
catalogs does a delete which the programmer could not go back to a  
previous step where a  DSN was un-cataloged re-catalog  
the DSN and start processing from that step.


That's the root reason why you have p roblems with quite elementary  
things. I don't criticize you, but I criticize the shop. You missed  
at least 20 year of improvements. SMS is 30 years old, catalog much  
more.
BTW: I use code (partially) written in 1970's, but it's under  
current mainenance, it works with z/OS 1.13, DB2 (younger than the  
code!), and other really current features.


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.2014 r. kapitał  
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052  
złote.



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




This electronic message contains information generated by the USDA  
solely for the intended recipients. Any unauthorized interception  
of this message or the use or disclosure of the information it  
contains may violate the law and subject the violator to civil or  
criminal penalties. If you believe you have received this message  
in error, please notify the sender and delete the email immediately.


--
For IBM-MAIN su

Re: Implicit VVDS creation

[Shmuel Metz (Seymour J.)]

In <5873965579866770.wa.markmzelden@listserv.ua.edu>, on
02/10/2014
   at 08:41 AM, Mark Zelden  said:

>Yes, of course the VVDS existed.  Been there since ICF (MVS/SP 1.3
>?). 

DF/EF provided the ICF. Later on DFP came along and included DF/DS and
DF/EF. Neither was bundled with MVS/SP.
 
-- 
 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: Implicit VVDS creation

[Shmuel Metz (Seymour J.)]

In <6330372289028276.wa.markmzelden@listserv.ua.edu>, on
02/10/2014
   at 03:22 PM, Mark Zelden  said:

>Could have been.   That was a batch tool only that used GTF like
>trace data IIRC, and may have even read GTF input. 

I vaguely recall that CMF had a seek optimizer that used GTF data.
 
-- 
 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: To restore Purged STC output

[Shmuel Metz (Seymour J.)]

In
,
on 02/11/2014
   at 10:31 AM, mf db  said:

>Is there a possibility of recovering a particular Purged STC back to
>spool ?

Did you do an offload?
 
-- 
 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: SMP/E SYSMOD SOURCEID(s)?

[Paul Gilmartin]

On Tue, 11 Feb 2014 08:56:03 -0600, Paul Gilmartin wrote:

>On Tue, 11 Feb 2014 06:38:33 -0600, Kathryn A. Pinto wrote:
>
>>Skip has given most of the answers already.  But to summarize the processing 
>>of UCLIN on the SOURCEID subentry:
>> 
>Thanks.
>
>Should I have been able to infer all this clearly from the SMP/E Commands 
>manual?  If
>not, I'll submit an RCF.  Examples should serve only to clarify information 
>presented in
>the processing description, not to supply essential information.
 

>>I can also DELete all of the SOURCEIDs like so:
>>
>>UCLIN.
>>DEL SYSMOD(sysmodid) SOURCEID().
>>ENDUCL.
>>
The syntax diagram in:


http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.gim1000/gim1217.htm
 

SYSMOD entry other than deleted SYSMOD
SMP/E for z/OS Commands
SA23-2275-00 

... appears not to allow an empty SOURCEID() list.  This, at least, deserves an 
RCF.

Thanks,
gil

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

Re: Storage Obtain .....

[Jim Thomas]

Hello ... 

Given the below ... 

 BAKR  R0,R0
 MSTA  R0  
 MSTA  R12 
 MODESET MODE=SUP,
   KEY=ZERO   
 L R11,PSAAOLD-PSA 
 SETLOCK OBTAIN,   
   ASCB=(11),  
   TYPE=CML,   
   MODE=UNCOND 
 XRR4,R4 
 L R7,PSAAOLD-PSA
 STORAGE OBTAIN, 
   LENGTH=LCLDSCTL,  
   SP=244,   
   LOC=(31,31),  
   CAUB=CURRENT, 
   OWNER=HOME,   
   LINKAGE=BRANCH
 LRR11,R1
 LRR0,R1 
 XRR14,R14   
 XRR15,R15   
 L R1,=AL4(WORKAREA) 
 MVCL  R0,R14

Everything up to the STORAGE OBTAIN seems to work but w/trying to chain
backward / forward save area's (no I not really using the linkage stack),
I get a S0C4-4 ??... I understand the S0C4 because R1 is zeroes ... but ...
why ??. My LTR after the STORAGE OBTAIN does not catch a failure. 

The only reason I'm trying to use the linkage stack is because this is at
the very start of my program.

The trace table shows the SSRV for the OBTAIN .. but it's obviously
failing... 

Could anybody give me some direction / suggestions ??. 

Kind Regards.

Jim Thomas

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

Re: Storage Obtain .....

[Jim Mulder]

>  BAKR  R0,R0
>  MSTA  R0 
>  MSTA  R12 
>  MODESET MODE=SUP,
>KEY=ZERO 
>  L R11,PSAAOLD-PSA 
>  SETLOCK OBTAIN, 
>ASCB=(11), 
>TYPE=CML, 
>MODE=UNCOND 
>  XRR4,R4 
>  L R7,PSAAOLD-PSA
>  STORAGE OBTAIN, 
>LENGTH=LCLDSCTL, 
>SP=244, 
>LOC=(31,31), 
>CAUB=CURRENT, 
>OWNER=HOME, 
>LINKAGE=BRANCH 
>  LRR11,R1 
>  LRR0,R1 
>  XRR14,R14 
>  XRR15,R15 
>  L R1,=AL4(WORKAREA) 
>  MVCL  R0,R14 
> 
> Everything up to the STORAGE OBTAIN seems to work but w/trying to chain
> backward / forward save area's (no I not really using the linkage 
stack),
> I get a S0C4-4 ??... I understand the S0C4 because R1 is zeroes ... but 
...
> why ??. My LTR after the STORAGE OBTAIN does not catch a failure. 
> 
> The only reason I'm trying to use the linkage stack is because this is 
at
> the very start of my program.
> 
> The trace table shows the SSRV for the OBTAIN .. but it's obviously
> failing... 

  It's not failing.  If it was failing, with the default of COND=NO, 
you would have gotten an ABEND.  What is in the SSRV   78   trace entry?
What is LCLDSCTL, which you used as a length specification? 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

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

Re: Storage Obtain .....

[Charles Mills]

What is the MVCL trying to accomplish? Clear a number of bytes equal to the
address of WORKAREA? Might you want the length of the OBTAIN and the length
of the MVCL to be the same?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jim Thomas
Sent: Tuesday, February 11, 2014 3:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Storage Obtain .

Hello ... 

Given the below ... 

 BAKR  R0,R0
 MSTA  R0  
 MSTA  R12 
 MODESET MODE=SUP,
   KEY=ZERO   
 L R11,PSAAOLD-PSA 
 SETLOCK OBTAIN,   
   ASCB=(11),  
   TYPE=CML,   
   MODE=UNCOND 
 XRR4,R4 
 L R7,PSAAOLD-PSA
 STORAGE OBTAIN, 
   LENGTH=LCLDSCTL,  
   SP=244,   
   LOC=(31,31),  
   CAUB=CURRENT, 
   OWNER=HOME,   
   LINKAGE=BRANCH
 LRR11,R1
 LRR0,R1 
 XRR14,R14   
 XRR15,R15   
 L R1,=AL4(WORKAREA) 
 MVCL  R0,R14

Everything up to the STORAGE OBTAIN seems to work but w/trying to chain
backward / forward save area's (no I not really using the linkage stack), I
get a S0C4-4 ??... I understand the S0C4 because R1 is zeroes ... but ...
why ??. My LTR after the STORAGE OBTAIN does not catch a failure. 

The only reason I'm trying to use the linkage stack is because this is at
the very start of my program.

The trace table shows the SSRV for the OBTAIN .. but it's obviously
failing... 

Could anybody give me some direction / suggestions ??. 

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

Users of CSP and its successor migrating to COBOL 5.1

[Clark F Morris]

If your shop uses an IBM z series computer and it is looking to
upgrade to version 5.1 of Enterprise COBOL and it is using Cross
System Product (CSP) or its Visual Gen successor, migration may be a
problem.  CSP and possibly its successor forced an F zone on all
signed fields with positive values leaving the D zone for negative
fields.  The elimination of NUMPROC(MIG) means this behavior if still
existing can cause problems.

Other program generators may also have this CSP peculiarity.

Clark Morris 

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

Re: XCFAS holding OMVS and XCF CDSes

[nitz-...@gmx.net]

> You never add PCOUPLE. You promote from ACOUPLE to PCOUPLE via PSWITCH. 

You do if you activate a CDS for the first time. There is nothing preventing 
you from specifying both pcouple and acouple in the same command. 
Admittedly I have never tried to switch both primary and alternate to a new 
name in the same command when this CDS type was already active.

Barbara

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

The implications of IBM selling its chip manufacturing business

[Ed Gould]

http://www.itworld.com/hardware/404469/implications-ibm-selling-its- 
chip-manufacturing-business?source=ITWNLE_nlt_tonight_2014-02-11



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