Re: Read a PDS (all members) like PS dataset

[Edward Gould]

Peter:

No sure if this is what you want but again try the CBTTAPE. There is a utility 
to unload a PDS to PS (with and without IEBUPDTE cards. It still works after 
20+ years and it still works on PDSE’s.

Ed

> On Jun 14, 2016, at 12:30 PM, Peter Ten Eyck  
> wrote:
> 
> Any suggestions on how to read though a PDS (all members) like PS dataset. 
> Example, read via a program the trough a PDS finding every called or linked 
> program statement without regard to PDS member name.
> 
> --
> 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

OT/IBM Refused to Layoff its people

[Edward Gould]

http://www.businessinsider.com/ibm-corporate-america-history-2016-6

The American corporation has been transformed by globalization and new 
technology. But equally powerful is the belief that on Wall Street and in 
boardrooms the sole responsibility of a corporation is to maximize profits for 
shareholders. Starting this week, Business Insider teams up with public radio's 
"Marketplace ." Our series, 
"The Price of Profits,"  tells 
the story of how this idea changed the US and our lives.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Who was the first?

[Edward Gould]

* Boffins decipher manual for 2,000-year-old Ancient Greek computer
 Antikythera Mechanism inscriptions suggest eclipse, weather
 prediction and... RTFM
 http://go.reg.cx/tdml/48a2/578aca7f/139c06f8/2msv 


(bet it didn’t have a manual number)

Ed


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

They are Catching up....

[Edward Gould]

http://www.theregister.co.uk/2016/06/15/datacore_drops_spc1_bombshell/

DataCore drops SPC-1 bombshell
Benchmark blows record to hell and gone

The Fort Lauderdale boys have struck again, with a record-breaking run of 5 
million IOPS, and maybe killed off every other SPC-1 benchmark contender's 
hopes for a year or more.

DataCore Software, head-quartered in Fort Lauderdale, Florida, has scored 
5,120,098.98 SPC-1 IOPS 
[PDF]
 with a simple 2-node Lenovo server set-up, taking the record from Huawei's 3 
million-plus scoring OceanStore 18800 v3 array, which needs multiple racks and 
costs $2.37m. The DataCore Parallel Server configuration costs $505,525.24, 
almost a fifth of Huawei's cost.

It is astonishing how SPC-1 results have rocketed in the past few years, as 
Huawei and Hitachi/HPE and Kaminario have sent results above the 1 million IOPS 
mark.

What seemed ground-breaking at first is now viewed as ordinary; a million SPC-1 
IOPS? Okay, move on. Five million, though, is more than the previous top two 
results combined and comes from just a pair of hybrid flash/disk servers, not a 
super-charged all-flash array.

DataCore's 2-node Parallel Server configuration used a pair of Lenovo X3650 M5 
servers, each with:

Two Intel Xeon 2.30 GHz E5-2699 V3 processors each with 18 cores
1,536 GB RAM
Mix of SSDs and HDDs internal & external
RAID Controllers and Avago SAS HBA
Qlogic 16 Gbps Fibre Channel HBAs (host connections)
Brocade Switch
UPS
That's a huge amount of RAM – 1.54TB – for caching.




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

Re: Sysplex Timer issue

[Kieron D Hinds]

Hi! Yes the CTNID is case sensitive. 

The best description today can be found in the Server Time Protocol 
Implementation Guide, SG24-7281:

The CTN ID has the format [STP Network ID] - [ETR Network ID] and is the 
basis for the establishment of the Coordinated Timing Network. The format 
of these fields is: 
CTN ID = " - xx" 
Where 
 is the STP Network ID and xx is the ETR Network ID:

> The STP network ID is case sensitive and is one to eight characters. The 
valid characters are A – Z, a – z, 0 – 9, -, and _.

> The ETR Network ID is a numeric value ranging between 0 and 31.



Kieron Hinds
z/OS Integration Test / System z Platform Evaluation Test
IBM Systems and Technology Group













From:   Nathan Astle 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   06/15/2016 09:28 AM
Subject:Re: Sysplex Timer issue
Sent by:IBM Mainframe Discussion List 



Hi,

It turned out that the CTN-ID value was coded in Upper case and what we
used to build the CF was in Lower case.

I am still trying to see if CTN-ID values are case sensitive.

Does anybody know if CTN-ID has such constraints ?

On Tue, Jun 14, 2016 at 2:40 AM, Kieron D Hinds  
wrote:

> Hi,
> It sounds like you have a situation where the CF you're attempting to 
IPL
> is running on a CPC with a different CTNID than the CTNID of the CPC[s]
> where other images are already active (z/OS and CFs).
> I'd have to compare the CTNID in the output of the IXL160E as well as 
the
> IEA386I from the D ETR of active system[s] in the sysplex to know for
> sure, but if it the case then you'll need to get the CTNIDs to match.
>
> Is this the first attempt to activate the CF - if so was STP configured 
on
> the CF CPC? Versus if it was after a configuration change made to an
> existing CF, do you expect the STP configuration or the CTNID to change?
>
> Changing CTNIDs *can* be disruptive so please check with your local or 
IBM
> hardware support if you don't understand this already.
>
>
> Kieron Hinds
> z/OS Integration Test / System z Platform Evaluation Test
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From:   Nathan Astle 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   06/13/2016 01:54 PM
> Subject:Sysplex Timer issue
> Sent by:IBM Mainframe Discussion List 
>
>
>
> Hi,
>
> We are receiving the error message on CF, while IPling .
>
> IXL160E CF REQUEST TIME ORDERING: REQUIRED AND NOT-ENABLED 194
>
> REASON: CTNID MISMATCH
>
>
> The ETR I displayed in the Console is different from the error message.
>
>
> Does it mean i have to correct that in the IOGEN ?
>
>
> Jake
>
> --
> 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






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

Re: CCSID

[Rick Troth]

Oh goody. A character sets question.


On 06/12/16 18:20, Scott Ford wrote:

I found the problem we are using an IBM TBL EZACICTR which doesnt support
CP 437, duh 


Bummer.

Today the role of Lynn Wheeler will be played by /moi/ as I give some 
interesting (to me) history related to this topic. (Salted with 
entertaining embellishment because my facts just aren't as detailed or 
interesting as his.)




I have a bigger question, if we wanted to support Unicode (yeah ugh), how
do I know what CCSIDS to support ?


The problem with Unicode is that it's not an 8-bit codepage. It's 32 
bits. It is the solution to all of our planet-wide problems because 
"there's room for everyone!".


I like UTF-8 where you get an 8-bit wide byte stream. (And there are no 
worries over endianness.) But that doesn't suite everyone. 8-bit bytes 
don't even work for program source code anymore! Eight bit bummer.




For example we go from EBCDIC on z/OS to ASCII and from ASCII to EBCDIC.
Do I some how have to tell the target what the sending CCSID is ?


Yes. (But I more often see the codepage numbers than some CCSID.)

Without better knowledge of your data and the environment, I can only 
recommend circling near "EBCDIC is CP1047" and "ASCII is ISO-8859-1". If 
your stuff is US and most of Western Europe, that works. (Not so helpful 
for the Russians or the Greeks or anyone East of them.)


The Story

We've enjoyed this hemmorrhiod for decades.

Dirty little secret: IBM was one of the backers of ASCII in the 1960s. 
The S/360 had an ASCII/EBCDIC switch. But too much momentum with 
Hollerith history. OS/360 and its siblings continued using EBCDIC. So 
the nifty A/E HW bit got re-purposed. Besides, we can fix everything in 
software, right? Ahh, those were the days. If only 16M were enough. 
Twenty-four bit addressing mode bummer.


In the late 1980s, Edwin Hart, then at Johns Hopkins Applied Physics and 
active with SHARE, spear-headed a customer effort to _distill common 
practice_ into consistency. The result was


*SHARE Report SSD No. 366*:
ASCII and EBCDIC Character Set and Code Issues in Systems Application 
Architecture,

The ASCII/EBCDIC Character Set Task Force.
Edited by Edwin Hart,
The Johns Hopkins University,
Applied Physics Laboratory,
Laurel, Maryland, USA;
published by Share Inc.,
111 East Wacker Drive, Chicago, Illinois, USA 60601;
*June 1989*

The effect was what some called "Codepage 37 version 2". Most mainframe 
sites were using either CP 37 or CP 500 (or subsets), neither of which 
mapped correctly to de-facto EBCDIC (for common translations to/from 
ASCII). CP 37 was the closer of the two. With minor code point 
re-assignment, a codepage floated to the surface which many of us 
rabidly skimmed off and ran with.


IBM took the SHARE report to heart. Mostly. They soon blessed us with CP 
1047, the standard on USS, even now. Codepage 1047 is closer to the 
legendary and mythical CP 37v2, but still off by two points. It switches 
/not/ and /hat/ (circumflex, shift 6 on your US PC keyboard). Makes a 
/mess/ of code and scripts which use either of those characters. 
Thirty-two bit bummer.


Interestingly, this unofficial _CP 37v2 persists_. At least one ISV of 
note (I won't say which, but Dave Rivers might chime in) continues using 
an official pair of translate tables that /work consistently/ between 
z/OS and Unix/Linux/Windows. And there was much rejoicing.


I can offer these ...

   http://www.casita.net/pub/aecs.h
   http://www.casita.net/pub/aecs.c


No warranties expressed or implied. In fact, I recommend /not/ using the 
C routines for anything more than reference. (Code-up something in 
assembler and let the hardware do the grunt work.)


Tagging text with one codepage or another is madness.
But assuming EBCDIC is always one thing and ASCII always an invariant 
other is paint cornering you.
Eventually we will get to Unicode, and the chief cause of problems is 
solutions.

Sixty-four bit bummer.

-- R; <><




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

Re: Cringely article about more IBM rumors

[Jack J. Woehr]

Paul Gilmartin wrote:

ITYM "teleported".  You don't know until you open the box.

-- gil


Heisenberg, Schrödinger and Ohm were in a car.

Heisenberg was driving and a policeman pulled him over.

"Do you know how fast you were going?" the policeman asked Heisenberg.

"No, but I know where I am," replied Heisenberg.

"You were doing 90!" the policeman said.

"Thanks, now I'm lost!" said Heisenberg.

The policeman gets suspicious and searches the trunk. "Do you fellows know you have 
a dead cat in here?"

"Now we do," replies Schrödinger.

So the policeman tries to arrest them, but Ohm resists.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Cringely article about more IBM rumors

[Paul Gilmartin]

On Wed, 15 Jun 2016 17:14:01 -0400, Tony Harminc wrote:

>On 15 June 2016 at 17:06, Jack J. Woehr wrote:
>
>> http://www.cringely.com/2016/06/15/mainframe-dead-long-live-mainframe/
>>>
>>> Goodbye Mainframe. Hello Quantum Computers. IBM is probably looking to
>> sell the mainframe division to raise cash for building them there critturs.
>
>So how many IBM lawyers would be transferred as part of the division, I
>wonder...?
>
ITYM "teleported".  You don't know until you open the box.

-- gil

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

Re: IBM plans for the future - an imaginary tale

[Anne & Lynn Wheeler]

johnmattson...@gmail.com (John Mattson) writes:
> IBM made mistakes back in the 1980's and 1990's from which they may never
> really recover.
> 1) Doing away with the THINK motto.  It seems about the time they did this
> is when many of them stopped thinking.
> 2) Stopped giving the systems almost free to colleges which stopped the
> flow of trained personnel.  MS and Apple learned from this mistake.
> 3) They almost eliminated VM for heavens sake, and now others have
> re-invented it and taken the market.  Someone clearly was NOT THINKing.
> 4) They invented the PC and did not see the potential in it.  It's like
> Edison inventing the light bulb, saying "That's nice" and walking away.
> Inexcusable.

IBM cut the 50s/60s 40% (or greater) education discount with the
23Jun1969 unbundling announcement in the wake of various legal
actions. past unbundling posts
http://manana.garlic.com/~lynn/submain.html#unbundle

in the early 80s, IBM tried to recover, creating ACIS (academic
computing) ... started out with $300M to give away to univ. MIT Project
Athena got $25M (Project Athena equally funded by $25M from DEC),
X-windows, kerberos, etc. CMU got $50M ... went into MACH, Camelot, some
number of others (lots of places would use MACH, including newer Apple
operating system).

ACIS also sponsors EARN & BITNET (where this mailing list originated)
http://manana.garlic.com/~lynn/subnetwork.html#bitnet

... using similar technology used by the internal network (larger than
arpanet/internet from just about the beginning until sometime mid-80s)
http://manana.garlic.com/~lynn/subnetwork.html#internalnet

originally developed by the IBM Cambridge Science Center ... also
responsible for virtual machines, inventing GML in 1969 (morphs
into SGML a decade later, after another decade morphs into HTML),
and some number of other things ... past posts
http://manana.garlic.com/~lynn/subtopic.html#545tech
and
http://manana.garlic.com/~lynn/submain.html#sgml

I've frequently pontificated that early uptake of IBM/PC was 3270
terminal emulation ... IBM/PC with 3270 terminal emulation was about the
same price as 3270 terminal ... a large corporation with tens of thousands
of 3270s already justified could switch order to IBM/PC with little or
no additional business justification effort ... and get single desk
footprint that did mainframe terminal and some local computing.
http://manana.garlic.com/~lynn/subnetwork.html#terminal

my brother was Apple regional marketing rep (largest physical region in
CONUS) and would periodic come to town and I would get invited to some
business dinners. I got to argue with MAC developers (before MAC was
even announced) that it needed terminal emulation (they responded that
it was for the kitchen table and would never be contaminated by business
uses). Silicon valley was different place back them ... at Hacker's
Conference, people could bring unnounced products and be played with by
others that worked for competitors.

However, communication group didn't track as personal computers become
more powerful.  I've periodically mentioned that senior disk engineer
got a talk scheduled at the annual, internal, world-wide, communication
group conference supposedly on 3174 performance ... but opened the talk
with the statement that the communication group was going to be
responsible for the demise of the disk division. The issue was that the
communication group had stranglehold on datacenters with corporate
strategic responsibility for everything that crossed datacenter walls
... and were strongly fighting off distributed computing and
client/server, trying to preserve their dumb terminal (emulation)
paradigm and install base. The disk division was seeing the effects of
data fleeing the datacenter (to more distributed computing friendly
platforms) with drop in disk sales. The disk division had come up with a
number of solutions to address the problem, but they were constantly
vetoed by the communication group.

A few short years later the company goes into the red and was being
re-organized into the 13 "baby blues" in preparation for breaking up the
company. The board then brings in a new CEO to resurrect the company and
reverse the breakup.

Starting in the early 80s, I had a project called HSDT ... some past
posts
http://manana.garlic.com/~lynn/subnetwork.html#hsdt

with T1 and faster speed links and we were working with director of NSF
to connect the NSF supercomputer centers. We were suppose to get $20M,
but then congress cuts the budget, some number of other things happen,
and then NSF releases a RFP (largely based on what we already had
running) but internal politics prevent us from bidding. The NSF director
tries to help by writting the company a letter (with support from other
agencies), copying the CEO, but that just makes the internal politics
worse (as well as the comments that what we already had running was at
least 5yrs ahead of all RFP responses). As regional networks connect
into the centers it 

Re: Cringely article about more IBM rumors

[Tony Harminc]

On 15 June 2016 at 17:06, Jack J. Woehr  wrote:

> http://www.cringely.com/2016/06/15/mainframe-dead-long-live-mainframe/
>>
>> Goodbye Mainframe. Hello Quantum Computers. IBM is probably looking to
> sell the mainframe division to raise cash for building them there critturs.


So how many IBM lawyers would be transferred as part of the division, I
wonder...?

Tony H.

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

Re: Where is format of Job ID documented?

[Charles Mills]

Thanks. Supports the idea of only three possible prefixes.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of J R
Sent: Wednesday, June 15, 2016 2:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where is format of Job ID documented?

$JBIDBLD in KnowledgeCenter. 

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

Re: Cringely article about more IBM rumors

[Jack J. Woehr]

Dana Mitchell wrote:

Interesting reading

http://www.cringely.com/2016/06/15/mainframe-dead-long-live-mainframe/

Goodbye Mainframe. Hello Quantum Computers. IBM is probably looking to sell the mainframe division to raise cash for 
building them there critturs.


--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Where is format of Job ID documented?

[Charles Mills]

I was specifically wondering what could appear in the first position or first 
three positions. Is J(OB), S(TC) and T(SU) the complete set? I thought I seemed 
to remember A-something for APPC transactions? No? Anything else?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Wednesday, June 15, 2016 1:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where is format of Job ID documented?

On Wed, Jun 15, 2016 at 3:38 PM, Charles Mills  wrote:

> Yeah, I know, JOBn or Tnnn.
>
> Is there a formal description somewhere? Where?
>
> Charles
>
> ​I don't know if it is "formal" or not, but here:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa600/iea3a6_Obtaining_a_job_identifier.htm


...

Issue an ENDREQ macro after writing a complete job to the internal reader.
The job identifier is returned in the RPLRBAR field of the request parameter 
list (RPL). See z/OS JES2 Commands 

 or z/OS JES3 Commands

for
details about the job identifier.
RPLRBAR is an 8-byte field. The first 3 bytes, xxx, are the characters JOB, TSU 
or STC. The remaining 5 bytes, n, represent the five digits of the job 

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

Re: Where is format of Job ID documented?

[J R]

$JBIDBLD in KnowledgeCenter. 

Sent from my iPhone

> On Jun 15, 2016, at 16:39, Charles Mills  wrote:
> 
> Yeah, I know, JOBn or Tnnn.
> 
> Is there a formal description somewhere? Where?
> 
> Charles 
> 
> --
> 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: Where is format of Job ID documented?

[Sri h Kolusu]

Charles,


Perhaps this earlier discussion might help? (The postings from Klaus  and 
it also has Barry Merri's routine too)

https://groups.google.com/d/msg/bit.listserv.ibm-main/AC6LGZ2Pc2M/0lx26TmgRboJ


Kolusu

IBM Mainframe Discussion List  wrote on 
06/15/2016 01:38:50 PM:

> From: Charles Mills 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/15/2016 01:39 PM
> Subject: Where is format of Job ID documented?
> Sent by: IBM Mainframe Discussion List 
> 
> Yeah, I know, JOBn or Tnnn.
> 
> Is there a formal description somewhere? Where?
> 
> Charles 
> 
> --
> 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: Where is format of Job ID documented?

[Charles Mills]

Thank you, Doctor.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Barry Merrill
Sent: Wednesday, June 15, 2016 1:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Where is format of Job ID documented?

NO, but MXG has discovered these possibilities:


/* THIS ROUTINE EXPECTS JCTJOBID AND JOB AS 8-BYTE CHARACTERS, */
 /* AND SUBSYS AS A 4-BYTE CHARACTER AS INPUT.  */

 /* JCTJOBID OF ONE LETTER AND 7 DIGITS EXIST, BUT THE MAXIMUM  */
 /* JESNR IS 99 BECAUSE THE 1ST WHEN SEVEN IS ALWAYS ZERO.  */

 /* IT CREATES THE 4-BYTE CHARACTER TYPETASK AND NUMERIC JESNR  */
 /* IT IS %INCLUDE-D AFTER JCTJOBID AND SUBSYS EXIST.   */

 TYPETASK='';
 JESNR=.;
 IF SUBSYS=''  THEN SUBSYS=''; /*EARLY ASIDS,TMNT */
 IF JCTJOBID=JOB OR (JCTJOBID LE ' ' AND SUBSYS='STC')
 OR (JCTJOBID EQ 'MSTR' AND SUBSYS='SMS') THEN DO;
   JESNR=.;
   TYPETASK='STC';
 END;
 ELSE DO;
   IF INPUT(SUBSTR(JCTJOBID,2,7),?? 7.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,2,7),?? 7.);
 TYPETASK=SUBSTR(JCTJOBID,1,1);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,3,6),?? 6.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,3,6),?? 6.);
 TYPETASK=SUBSTR(JCTJOBID,1,2);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,4,5),?? 5.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,4,5),?? 5.);
 TYPETASK=SUBSTR(JCTJOBID,1,3);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,5,4),?? 4.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,5,4),?? 4.);
 TYPETASK=SUBSTR(JCTJOBID,1,4);
   END;
   IF SUBSYS='TCP ' THEN TYPETASK='TCP ';
   ELSE IF SUBSYS='PSF ' THEN TYPETASK='PSF ';
   ELSE IF SUBSYS='VPS ' THEN TYPETASK='VPS ';
   ELSE IF TYPETASK=:'J' THEN DO;
 IF  SUBSYS='TSO ' THEN TYPETASK='TSU ';
 ELSE IF SUBSYS='JES2' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='JES3' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='OMVS' THEN TYPETASK='OMVS';
 ELSE   TYPETASK='JOB ';
   END;
   ELSE IF TYPETASK=:'O' OR SUBSYS='OMVS' THEN TYPETASK='OMVS';
   ELSE IF TYPETASK=:'G' THEN TYPETASK='JOBG';
   ELSE IF TYPETASK=:'S' THEN TYPETASK='STC ';
   ELSE IF TYPETASK=:'A' THEN TYPETASK=SUBSYS;/*ASCH-OR-OMVS:CH16.150*/
   ELSE IF TYPETASK=:'T' THEN TYPETASK='TSU ';
   ELSE IF TYPETASK=:'I' AND SUBSYS='STC' THEN TYPETASK='STC  ';
   ELSE DO;
 IF  SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='TSO ' THEN TYPETASK='TSU ';
 ELSE IF SUBSYS='JES2' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='JES3' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='OMVS' THEN TYPETASK='OMVS';
 ELSE DO;
   IF PRODUCT='' THEN PRODUCT='';;
   IF SUBTYPE=.  THEN SUBTYPE=.;
   IF PRODUCT='PERFMON ' AND SUBTYPE=3 THEN DO;
 TYPETASK='STC';
 SUBSYS='PERFMON';
   END;
 END;
   END;
   IF TYPETASK=' ' THEN DO;
 BADVJESN+1;
 IF BADVJESN LE 2 THEN
   PUT '*** WARNING - TYPETASK NOT DECODED: ' /  +10
   _N_= SYSTEM= ID= SUBTYPE= JOB=
   JCTJOBID= SUBSYS= TYPETASK= JESNR= ;
   END;
   
 END;
  /* END OF MEMBER VGETJESN - GET JESNR AND TYPETASK FROM JCTJOBID */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Wednesday, June 15, 2016 3:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Where is format of Job ID documented?

Yeah, I know, JOBn or Tnnn.

Is there a formal description somewhere? Where?

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

Re: Where is format of Job ID documented?

[John McKown]

On Wed, Jun 15, 2016 at 3:38 PM, Charles Mills  wrote:

> Yeah, I know, JOBn or Tnnn.
>
> Is there a formal description somewhere? Where?
>
> Charles
>
> ​I don't know if it is "formal" or not, but here:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa600/iea3a6_Obtaining_a_job_identifier.htm


...

Issue an ENDREQ macro after writing a complete job to the internal reader.
The job identifier is returned in the RPLRBAR field of the request
parameter list (RPL). See z/OS JES2 Commands

 or z/OS JES3 Commands

for
details about the job identifier.
RPLRBAR is an 8-byte field. The first 3 bytes, xxx, are the characters JOB,
TSU or STC. The remaining 5 bytes, n, represent the five digits of the
job number. See z/OS JES2 Initialization and Tuning Guide

 or z/OS JES3 Initialization and Tuning Guide

 for more information.
...
​
The format of job numbers being displayed as part of command responses or
messages can change depending on whether JES2 is set up to support greater
than 65K jobs. When job numbers are potentially greater than 99,999, the
format for job numbers is as follows: if the maximum allowed job number
(high value of the JOBDEF RANGE= statement) is above 99,999, the job number
format is J0nn. This format is used unless the job number range is
decreased below 100,000. Similarly, STCn becomes S0nn and TSUn
becomes T0nn.

​...​

​​


-- 
"Pessimism is a admirable quality in an engineer. Pessimistic people check
their work three times, because they're sure that something won't be right.
Optimistic people check once, trust in Solis-de to keep the ship safe, then
blow everyone up."
"I think you're mistaking the word optimistic for inept."
"They've got a similar ring to my ear."

>From "Star Nomad" by Lindsay Buroker:

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: Cringely article about more IBM rumors

[Edward Finnell]

Yeah we hashed that out when the Z6/Z10 rolled out, same fabrication,  
something like 62% instruction overlap but not a Power chip. As Dr. Webb says  
'siblings not twins'. The z6 rollout can be found here:
 
http://speleotrove.com/decimal/IBM-z6-mainframe-microprocessor-Webb.pdf 
 
 Search on IBM z13 CPU and find some of Harv Emery's (WSC)  SHARE  
presentations on the Z13. Billions of transistors, 12.5 miles of copper wire, 
on  15 
layers  22nm technology on SOI boards not much bigger than an index  card.
 
 
In a message dated 6/15/2016 3:21:26 P.M. Central Daylight Time,  
john.archie.mck...@gmail.com writes:

But one  glaring mistake. The z series does not have a Power
chip inside  it.



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

Re: Where is format of Job ID documented?

[Barry Merrill]

NO, but MXG has discovered these possibilities:


/* THIS ROUTINE EXPECTS JCTJOBID AND JOB AS 8-BYTE CHARACTERS, */
 /* AND SUBSYS AS A 4-BYTE CHARACTER AS INPUT.  */

 /* JCTJOBID OF ONE LETTER AND 7 DIGITS EXIST, BUT THE MAXIMUM  */
 /* JESNR IS 99 BECAUSE THE 1ST WHEN SEVEN IS ALWAYS ZERO.  */

 /* IT CREATES THE 4-BYTE CHARACTER TYPETASK AND NUMERIC JESNR  */
 /* IT IS %INCLUDE-D AFTER JCTJOBID AND SUBSYS EXIST.   */

 TYPETASK='';
 JESNR=.;
 IF SUBSYS=''  THEN SUBSYS=''; /*EARLY ASIDS,TMNT */
 IF JCTJOBID=JOB OR (JCTJOBID LE ' ' AND SUBSYS='STC')
 OR (JCTJOBID EQ 'MSTR' AND SUBSYS='SMS') THEN DO;
   JESNR=.;
   TYPETASK='STC';
 END;
 ELSE DO;
   IF INPUT(SUBSTR(JCTJOBID,2,7),?? 7.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,2,7),?? 7.);
 TYPETASK=SUBSTR(JCTJOBID,1,1);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,3,6),?? 6.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,3,6),?? 6.);
 TYPETASK=SUBSTR(JCTJOBID,1,2);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,4,5),?? 5.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,4,5),?? 5.);
 TYPETASK=SUBSTR(JCTJOBID,1,3);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,5,4),?? 4.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,5,4),?? 4.);
 TYPETASK=SUBSTR(JCTJOBID,1,4);
   END;
   IF SUBSYS='TCP ' THEN TYPETASK='TCP ';
   ELSE IF SUBSYS='PSF ' THEN TYPETASK='PSF ';
   ELSE IF SUBSYS='VPS ' THEN TYPETASK='VPS ';
   ELSE IF TYPETASK=:'J' THEN DO;
 IF  SUBSYS='TSO ' THEN TYPETASK='TSU ';
 ELSE IF SUBSYS='JES2' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='JES3' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='OMVS' THEN TYPETASK='OMVS';
 ELSE   TYPETASK='JOB ';
   END;
   ELSE IF TYPETASK=:'O' OR SUBSYS='OMVS' THEN TYPETASK='OMVS';
   ELSE IF TYPETASK=:'G' THEN TYPETASK='JOBG';
   ELSE IF TYPETASK=:'S' THEN TYPETASK='STC ';
   ELSE IF TYPETASK=:'A' THEN TYPETASK=SUBSYS;/*ASCH-OR-OMVS:CH16.150*/
   ELSE IF TYPETASK=:'T' THEN TYPETASK='TSU ';
   ELSE IF TYPETASK=:'I' AND SUBSYS='STC' THEN TYPETASK='STC  ';
   ELSE DO;
 IF  SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='TSO ' THEN TYPETASK='TSU ';
 ELSE IF SUBSYS='JES2' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='JES3' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='OMVS' THEN TYPETASK='OMVS';
 ELSE DO;
   IF PRODUCT='' THEN PRODUCT='';;
   IF SUBTYPE=.  THEN SUBTYPE=.;
   IF PRODUCT='PERFMON ' AND SUBTYPE=3 THEN DO;
 TYPETASK='STC';
 SUBSYS='PERFMON';
   END;
 END;
   END;
   IF TYPETASK=' ' THEN DO;
 BADVJESN+1;
 IF BADVJESN LE 2 THEN
   PUT '*** WARNING - TYPETASK NOT DECODED: ' /  +10
   _N_= SYSTEM= ID= SUBTYPE= JOB=
   JCTJOBID= SUBSYS= TYPETASK= JESNR= ;
   END;
   
 END;
  /* END OF MEMBER VGETJESN - GET JESNR AND TYPETASK FROM JCTJOBID */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Wednesday, June 15, 2016 3:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Where is format of Job ID documented?

Yeah, I know, JOBn or Tnnn.

Is there a formal description somewhere? Where?

Charles 

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

Where is format of Job ID documented?

[Charles Mills]

Yeah, I know, JOBn or Tnnn.

Is there a formal description somewhere? Where?

Charles 

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

Re: Cringely article about more IBM rumors

[John McKown]

Interesting. But one glaring mistake. The z series does not have a Power
chip inside it.

On Wed, Jun 15, 2016 at 3:17 PM, Dana Mitchell  wrote:

> Interesting reading
>
> http://www.cringely.com/2016/06/15/mainframe-dead-long-live-mainframe/
>
> Dana
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
"Pessimism is a admirable quality in an engineer. Pessimistic people check
their work three times, because they're sure that something won't be right.
Optimistic people check once, trust in Solis-de to keep the ship safe, then
blow everyone up."
"I think you're mistaking the word optimistic for inept."
"They've got a similar ring to my ear."

>From "Star Nomad" by Lindsay Buroker:

Maranatha! <><
John McKown

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

Cringely article about more IBM rumors

[Dana Mitchell]

Interesting reading

http://www.cringely.com/2016/06/15/mainframe-dead-long-live-mainframe/

Dana

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

Re: Read a PDS (all members) like PS dataset

[CM Poncelet]

Yes, I had overlooked that BLDL requires a member name.

My comments were based on the following, written some 25+ years ago:

PDSRENMB CSECT START CONTROL SECTION
3300
*   
3400
*** 
3500
** MACROS * 
3600
*   
3700
MACRO  
3800
   READREC   
3900
   GET  READ  RECORD
4000
MVC   INPUT(80),0(R1) MOVE FROM BUFFER TO INPUT AREA   
4100
MEND   
4200
*   
4300
MACRO  
4400
   WRITEREC   
4500
   PUT   REPORTS,OUTPUT  OUTPUT REPORT RECORD 
4600
MEND   
4700
*   
4800
*** END OF MACROS * 
4900
*** 
5000
*   
5100
**  
5200
*** INITIAL PROCESSING ***  
5300
**  
5400
*   
5500
NAMEOFT  EQU   NAME-*   
5600
TTROFT   EQU   TTR-*
5700
NEWNAMEOFT EQU N_NAME-* 
5800
KOFT EQU   K-*  
5900
COFT EQU   C-*  
6000
INPUTOFT EQU   INPUT-*  
6100
*   
6200
BEGINSTM   R14,R12,12(R13) SAVE REGISTERS 14->12 TO OFFSET 12   
6300
LRR11,R15 LOAD ENTRY POINT LOCATION INTO R11   
6400
USING PDSRENMB,R11DEFINE R11 AS BASE REGISTER  
6500
STR13,SAVEBLK+8   SAVEAREA BACKWARD POINTER
6600
LRR6,R13   
6700
LAR13,SAVEBLK  
6800
STR13,4(,R6)  SAVEAREA FORWARD POINTER 
6900
*   
7000
*** 
7100
 START OF PROGRAM CODE PROPER * 
7200
*** 
7300
*   
7400
OPEN  (SYSIN,(INPUT))  
7500
L R4,=F'64'   FOR COUNTING ¬> 64 CARDS 
7600
LAR9,0(,R11)  FOR INDEXING MEMBER NAMES + BASE 
7700
S R9,=F'14'
7800
LAR10,0(,R11) FOR INDEXING NEWNAMES + BASE 
7900
S R10,=F'8'
8000
*   
8100
* DO UNTIL THERE ARE NO MORE SYSIN RECORDS  
8200
*   
8300
NEXT READREC SYSIN  
8400
LAR5,0(,R11)  USE R5 AS PSEUDO BASE REG
8500
LAR6,1USE R6 AS INDEX INCREMENT
8600
*   
8700
*  'MEMBER=' = 7
8800
*  ',' = 1  
8900
*  'NEWNAME=' = 8   
9000
*   = 1 MIN 
9100
*   = 1 MIN
9200
* 

Re: Read a PDS (all members) like PS dataset

[Itschak Mugzach]

Pnina,

Consider zapping the dataset entry (fmt1dscb)  in the vtoc (or, if you are
a CA client and has DMS, use DMS utility described in SPL). If you need
instruction how to zap, please tell.

Best,
ITschak

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

On Wed, Jun 15, 2016 at 12:38 PM, פנינה קוניגסברג  wrote:

> Thanks for the amazingly rapid reply.
>
> A little bit more info : the original dcb was lrecl=80, blksize=27290,
> recfm=fb dsorg=po.
> The file as modified by IDCAMS is lrecl=125, blksize
> =27920,recfm=vba,dsorg=po
>
> Built 2 sequential  output files, each with the dcb paramaters of before &
> after
> When writing to the seq lrecl 80 file received IEB311I CONFLICTING DCB
> PARAMETERS
> when writing to the lrecl 125 received  IEB351I I/O ERROR ,XXX,
> ,138C,D,SYSUT1  ,READ  ,WRNG.LEN.RECORD,251700,BSAM
>
> BTW, there was one crucial member that I reconstructed using DITTO VOLUME
> BROWSE and copy/paste . but I don't see myself doing that for 150 members -
>
>
> .
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Clifford McNeill
> Sent: Wednesday, June 15, 2016 6:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Read a PDS (all members) like PS dataset
>
> You could try to open, write, and close the PDS with the original LRECL
> and BLKSIZE, IEBGENER will do fine.  Then you should be able to recover the
> previous members.  Of course, get a backup first.
>
> Cliff McNeill
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of ? ? 
> Sent: Wednesday, June 15, 2016 10:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Read a PDS (all members) like PS dataset
>
> Always interesting, I am dealing this week  with an error that I hoped
> would be solved by the different solutions presented here, but after trying
> some of the solutions presented herein have not recovered.
> Background: In preparation for a system cutover, executed IDCAMS LISTC
> with SYSPRINT to a PDS file containing very important cutover data.
> (thought that was an efficient method of documentation   :)   - the laugh
> is on me).
> The original file was a typical jcl type (80 lrecl) after running the
> LISTC and updating the results, the PDS members which existed prior to the
> LISTC job execution were unreadable - IO ERROR.   Since the disk was a
> 'sandbox' type disk, it wasn't backed up nor dumped.  I have been trying
> various recovery methods - many of them as advised on this discussion list
> to not avail. Any ideas ?  Would it be preferable for me to  specify the
> actions I already did to try to recover the file?
>
> .
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of CM Poncelet
> Sent: Wednesday, June 15, 2016 8:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Read a PDS (all members) like PS dataset
>
> Yes it works, although I used it with the STOW macro (afterwards) to
> modify/update PDS directories. Use the List/Execute forms of the DCB
> Macro/DSECT if it is to be modified (in getmained storage).
>
> The FIND macro can then be used to locate the start of each PDS member
> returned by the BLDL. From there, read each PDS member in turn (some
> Open/Read/Closes might be needed).
>
> BTW My correction: IEBUPDTE can write (but not read, AFAIK) a PS dataset
> to a PDS. But IEBCOPY can read a PDS and write it to a PS - and vice versa.
>
> Paul Gilmartin wrote:
>
> >On Wed, 15 Jun 2016 04:14:04 +0100, CM Poncelet wrote:
> >
> >
> >>I would suggest writing some assembler code that invokes the BLDL
> >>macro to read the PDS directory, ...
> >>
> >>
> >>
> >Does that work?
> >
> >-- 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
>
> --
> 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: Recover PDS (Was Read a PDS (all members) like PS dataset)

[Jesse 1 Robinson]

CBT PDS command (or ISV descendant StarTool) can handle this nicely. However, 
even IEBGENER can do it as well. Something like

//SYSUT2 DD DISP=OLD,DSN=marfed-up-PDS,LRECL=80,RECFM=FB,DSORG=PO,BLKSIZE=???
//SYSUT1 DD DUMMY LRECL=80,RECFM=FB 

You need to figure out the actual block size for SYSUT2, which is a physical 
attribute of the file, not a logical attribute. There are various ways to 
determine physical block size. If the DCB block size is lower than the physical 
block size, you get an I/O error trying to read it. If the DCB block size is 
larger but still a multiple of 80, I believe you can read it. 

The important point that you have not lost previous data as long as your LISTC 
SYSPRINT specified a member name. In other words, the data set must still be 
DSORG=PO. If it now says DSORG=PS, you're toast because the directory was 
overwritten and cannot be recreated. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, June 15, 2016 9:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Recover PDS (Was Read a PDS (all members) like PS 
dataset)

Changing the title to start a new thread



Go to the CBTTAPE.ORG and get the PDS utility.  It has a recovery process.

Or if you know the original attributes, use IEBGENER to write a new Member

//S1  EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN   DD DUMMY
//SYSUT1   DD *
  Dummy record
/*
//SYSUT2  DD DISP=OLD,DSN=broken.pds(@#$Dmy),LRECL=x,BLKSIZE=X,DSORG=PO,RECFM=FB

You really do need both the LRECL and BLKSIZE for this to be successful.

I have used this, but it is at your own risk.

If you have a backup of the file, I would go back to it an re apply changes

Even in a Sandbox, I use HSM to back up critical files.  It is better to be 
safe than sorry later.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of ? ?
> Sent: Wednesday, June 15, 2016 8:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Read a PDS (all members) like PS dataset
> 
> Always interesting, I am dealing this week  with an error that I hoped 
> would be solved by the different solutions presented here, but after 
> trying some of the solutions presented herein have not recovered.
> Background: In preparation for a system cutover, executed IDCAMS LISTC 
> with SYSPRINT to a PDS file containing very important cutover data. (thought 
> that
> was an efficient method of documentation   :)   - the laugh is on me).
> The original file was a typical jcl type (80 lrecl) after running the 
> LISTC and updating the results, the PDS members which existed prior to the 
> LISTC job
> execution were unreadable - IO ERROR.   Since the disk was a 'sandbox' type
> disk, it wasn't backed up nor dumped.  I have been trying various 
> recovery methods - many of them as advised on this discussion list to 
> not avail. Any ideas ?  Would it be preferable for me to  specify the 
> actions I already did to try to recover the file?

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

CE$TDLI vcon generated in C compile

[Mike]

Hello,

a colleague here switched a little sample C app from using CTDLI to
CEETDLI, but his LINK step is failing on a VCON generated by compiler. Any
clues as to why the CEETDLI ends up as CE$TDLI, and where that entry point
lives?

Neither  I or my colleague has been able to find any reference in doc
anywhere. the IMS-L folks never heard of it, so i'm posting here.

Here is the Binder output:

IEW2278I B352 INVOCATION PARAMETERS - MAP

IEW2322I 1220  1 INCLUDE RESLIB(DFSLI000)

IEW2322I 1220  2 INCLUDE SYSLIB(CEETDLI)

IEW2322I 1220  3ENTRY CEESTART

IEW2322I 1220  4NAME IMSCPGM(R)

IEW2456E 9207 SYMBOL CE$TDLI UNRESOLVED.  MEMBER COULD NOT BE INCLUDED FROM
THE DESIGNATED CALL LIBRARY.

Thanks,

Mike O'Donnell

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

Re: Read a PDS (all members) like PS dataset

[Paul Gilmartin]

On Wed, 15 Jun 2016 10:15:56 -0700, retired mainframer wrote:
>
>Create two new PDSes.  One with the original DCB attributes of the broken 
>dataset.  The second with the new DCB attributes of that dataset.
> 
Make backups; work with copies.
Will HBACKDS/HRESTORE RENAME deal with inconsistent member attributes?

>Run IEBCOPY to copy only the new member(s) produced by LISTC to the second 
>dataset.  (Use the SELECT control card.)  The DD cards for this job should not 
>specify DCB information for either PDS.
> 
>Run a second IEBCOPY to copy only the original members created before you ran 
>the first LISTC operation.  (Use the EXCLUDE command.)  On the DD statement 
>pointing to the broken dataset, specify LRECL=80, RECFM=FB, and BLKSIZE=32760. 
> (For disk datasets, a BLKSIZE greater than the longest block is not a 
>problem.)  IEBCOPY will reblock the records to match the BLKSIZE specified 
>when the output dataset was created.
>
JCL may insist that BLKSIZE be a multiple of LRECL.

Will IEBCOPY insist on using the DSCB attributes of SYSUT1, copying to SYSUT2?

Ugh!  DFSMS should *never* allow changing the attributes of an existing 
nonempty data set.
DFSMS should *almost*never* allow overwriting the directory when DSORG=PO.  (If 
the
programmer explicitly overrides to DSORG=PS, programmer's gun; programmer's 
foot.)

-- gil

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

Re: zLINUX gold image build

[Veerendra Haluvadandimath]

Thank you Mark. Appreciate it

Regards,
Kumar

On Tue, Jun 14, 2016 at 10:57 PM, Mark Post  wrote:

> >>> On 6/14/2016 at 08:23 AM, Carlos Bodra  wrote:
> > http://www.redbooks.ibm.com/abstracts/sg247492.html?Open
>
> That book is quite old, and only talks about Red Hat Enterprise Linux.
> There are newer versions which use newer versions of z/VM, RHEL, and SUSE
> Linux Enterprise Server.
>
> More to the point, the Cookbooks are really only appropriate system setups
> if you're planning on using the cloning methodology described in them,
> which is not what all people want.
>
> I would say the OP needs to understand how they will be deploying the gold
> images before deciding how to create them and what they will look like.
> Something like that would be better discussed on the Linux-390 mailing list
> hosted by Marist College.
>
>
> Mark Post
>
> --
> 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: Read a PDS (all members) like PS dataset

[retired mainframer]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, June 15, 2016 9:52 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Read a PDS (all members) like PS dataset
> 
> On Wed, 15 Jun 2016 15:39:01 +, פנינה קוניגסברג wrote:
> 
> >Always interesting, I am dealing this week  with an error that I hoped would 
> >be solved by
> the different solutions presented here, but after trying some of the 
> solutions presented
> herein have not recovered.
> >Background: In preparation for a system cutover, executed IDCAMS LISTC with
> SYSPRINT to a PDS file containing very important cutover data. (thought that 
> was an
> efficient method of documentation   :)   - the laugh is on me).
> >The original file was a typical jcl type (80 lrecl) after running the LISTC 
> >and updating the
> results, the PDS members which existed prior to the LISTC job execution were 
> unreadable -
> IO ERROR.   Since the disk was a 'sandbox' type disk, it wasn't backed up nor 
> dumped.  I
> have been trying various recovery methods - many of them as advised on this 
> discussion list
> to not avail. Any ideas ?  Would it be preferable for me to  specify the 
> actions I already did
> to try to recover the file?
> >
> If you allocate the PDS with the original RECFM=FB,LRECL=80,BLKSIZE=? you
> should be able to
> read the older members correctly and the member(s) created as IDCAMS SYSPRINT 
> will
> receive I/O
> errors.

Gil's recommendation is a better plan than trying to restore the DCB of the 
broken dataset back to its original condition.  There is no reason to run the 
risk of damaging the dataset further.

Create two new PDSes.  One with the original DCB attributes of the broken 
dataset.  The second with the new DCB attributes of that dataset.

Run IEBCOPY to copy only the new member(s) produced by LISTC to the second 
dataset.  (Use the SELECT control card.)  The DD cards for this job should not 
specify DCB information for either PDS.

Run a second IEBCOPY to copy only the original members created before you ran 
the first LISTC operation.  (Use the EXCLUDE command.)  On the DD statement 
pointing to the broken dataset, specify LRECL=80, RECFM=FB, and BLKSIZE=32760.  
(For disk datasets, a BLKSIZE greater than the longest block is not a problem.) 
 IEBCOPY will reblock the records to match the BLKSIZE specified when the 
output dataset was created.

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

Re: Read a PDS (all members) like PS dataset

[Paul Gilmartin]

On Wed, 15 Jun 2016 15:39:01 +, פנינה קוניגסברג wrote:

>Always interesting, I am dealing this week  with an error that I hoped would 
>be solved by the different solutions presented here, but after trying some of 
>the solutions presented herein have not recovered. 
>Background: In preparation for a system cutover, executed IDCAMS LISTC with 
>SYSPRINT to a PDS file containing very important cutover data. (thought that 
>was an efficient method of documentation   :)   - the laugh is on me).
>The original file was a typical jcl type (80 lrecl) after running the LISTC 
>and updating the results, the PDS members which existed prior to the LISTC job 
>execution were unreadable - IO ERROR.   Since the disk was a 'sandbox' type 
>disk, it wasn't backed up nor dumped.  I have been trying various recovery 
>methods - many of them as advised on this discussion list to not avail. Any 
>ideas ?  Would it be preferable for me to  specify the actions I already did 
>to try to recover the file? 
> 
If you allocate the PDS with the original RECFM=FB,LRECL=80,BLKSIZE=? you 
should be able to
read the older members correctly and the member(s) created as IDCAMS SYSPRINT 
will receive I/O
errors.

That's why I use UNIX files wnenever possible: none of this attributes 
mickeymouse.

DFSMS should *never* permit changing the attributes of an existing nonempty 
data set.
Bad design.

-- gil

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

Re: Read a PDS (all members) like PS dataset

[פנינה קוניגסברג]

Thanks for the amazingly rapid reply.

A little bit more info : the original dcb was lrecl=80, blksize=27290, recfm=fb 
dsorg=po. 
The file as modified by IDCAMS is lrecl=125, blksize =27920,recfm=vba,dsorg=po

Built 2 sequential  output files, each with the dcb paramaters of before & 
after   
When writing to the seq lrecl 80 file received IEB311I CONFLICTING DCB 
PARAMETERS 
when writing to the lrecl 125 received  IEB351I I/O ERROR ,XXX,
,138C,D,SYSUT1  ,READ  ,WRNG.LEN.RECORD,251700,BSAM

BTW, there was one crucial member that I reconstructed using DITTO VOLUME 
BROWSE and copy/paste . but I don't see myself doing that for 150 members - 


.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clifford McNeill
Sent: Wednesday, June 15, 2016 6:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Read a PDS (all members) like PS dataset

You could try to open, write, and close the PDS with the original LRECL and 
BLKSIZE, IEBGENER will do fine.  Then you should be able to recover the 
previous members.  Of course, get a backup first.

Cliff McNeill



From: IBM Mainframe Discussion List  on behalf of 
? ? 
Sent: Wednesday, June 15, 2016 10:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Read a PDS (all members) like PS dataset

Always interesting, I am dealing this week  with an error that I hoped would be 
solved by the different solutions presented here, but after trying some of the 
solutions presented herein have not recovered.
Background: In preparation for a system cutover, executed IDCAMS LISTC with 
SYSPRINT to a PDS file containing very important cutover data. (thought that 
was an efficient method of documentation   :)   - the laugh is on me).
The original file was a typical jcl type (80 lrecl) after running the LISTC and 
updating the results, the PDS members which existed prior to the LISTC job 
execution were unreadable - IO ERROR.   Since the disk was a 'sandbox' type 
disk, it wasn't backed up nor dumped.  I have been trying various recovery 
methods - many of them as advised on this discussion list to not avail. Any 
ideas ?  Would it be preferable for me to  specify the actions I already did to 
try to recover the file?

.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of CM Poncelet
Sent: Wednesday, June 15, 2016 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Read a PDS (all members) like PS dataset

Yes it works, although I used it with the STOW macro (afterwards) to 
modify/update PDS directories. Use the List/Execute forms of the DCB 
Macro/DSECT if it is to be modified (in getmained storage).

The FIND macro can then be used to locate the start of each PDS member returned 
by the BLDL. From there, read each PDS member in turn (some Open/Read/Closes 
might be needed).

BTW My correction: IEBUPDTE can write (but not read, AFAIK) a PS dataset to a 
PDS. But IEBCOPY can read a PDS and write it to a PS - and vice versa.

Paul Gilmartin wrote:

>On Wed, 15 Jun 2016 04:14:04 +0100, CM Poncelet wrote:
>
>
>>I would suggest writing some assembler code that invokes the BLDL 
>>macro to read the PDS directory, ...
>>
>>
>>
>Does that work?
>
>-- 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

--
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: Recover PDS (Was Read a PDS (all members) like PS dataset)

[Lizette Koehler]

Changing the title to start a new thread



Go to the CBTTAPE.ORG and get the PDS utility.  It has a recovery process.

Or if you know the original attributes, use IEBGENER to write a new Member

//S1  EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN   DD DUMMY
//SYSUT1   DD *
  Dummy record
/*
//SYSUT2  DD DISP=OLD,DSN=broken.pds(@#$Dmy),LRECL=x,BLKSIZE=X,DSORG=PO,RECFM=FB

You really do need both the LRECL and BLKSIZE for this to be successful.

I have used this, but it is at your own risk.

If you have a backup of the file, I would go back to it an re apply changes

Even in a Sandbox, I use HSM to back up critical files.  It is better to be safe
than sorry later.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of ? ?
> Sent: Wednesday, June 15, 2016 8:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Read a PDS (all members) like PS dataset
> 
> Always interesting, I am dealing this week  with an error that I hoped would
> be solved by the different solutions presented here, but after trying some of
> the solutions presented herein have not recovered.
> Background: In preparation for a system cutover, executed IDCAMS LISTC with
> SYSPRINT to a PDS file containing very important cutover data. (thought that
> was an efficient method of documentation   :)   - the laugh is on me).
> The original file was a typical jcl type (80 lrecl) after running the LISTC
> and updating the results, the PDS members which existed prior to the LISTC job
> execution were unreadable - IO ERROR.   Since the disk was a 'sandbox' type
> disk, it wasn't backed up nor dumped.  I have been trying various recovery
> methods - many of them as advised on this discussion list to not avail. Any
> ideas ?  Would it be preferable for me to  specify the actions I already did
> to try to recover the file?
> 
> .

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

Re: Read a PDS (all members) like PS dataset

[Clifford McNeill]

You could try to open, write, and close the PDS with the original LRECL and 
BLKSIZE, IEBGENER will do fine.  Then you should be able to recover the 
previous members.  Of course, get a backup first.

Cliff McNeill



From: IBM Mainframe Discussion List  on behalf of 
? ? 
Sent: Wednesday, June 15, 2016 10:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Read a PDS (all members) like PS dataset

Always interesting, I am dealing this week  with an error that I hoped would be 
solved by the different solutions presented here, but after trying some of the 
solutions presented herein have not recovered.
Background: In preparation for a system cutover, executed IDCAMS LISTC with 
SYSPRINT to a PDS file containing very important cutover data. (thought that 
was an efficient method of documentation   :)   - the laugh is on me).
The original file was a typical jcl type (80 lrecl) after running the LISTC and 
updating the results, the PDS members which existed prior to the LISTC job 
execution were unreadable - IO ERROR.   Since the disk was a 'sandbox' type 
disk, it wasn't backed up nor dumped.  I have been trying various recovery 
methods - many of them as advised on this discussion list to not avail. Any 
ideas ?  Would it be preferable for me to  specify the actions I already did to 
try to recover the file?

.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of CM Poncelet
Sent: Wednesday, June 15, 2016 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Read a PDS (all members) like PS dataset

Yes it works, although I used it with the STOW macro (afterwards) to 
modify/update PDS directories. Use the List/Execute forms of the DCB 
Macro/DSECT if it is to be modified (in getmained storage).

The FIND macro can then be used to locate the start of each PDS member returned 
by the BLDL. From there, read each PDS member in turn (some Open/Read/Closes 
might be needed).

BTW My correction: IEBUPDTE can write (but not read, AFAIK) a PS dataset to a 
PDS. But IEBCOPY can read a PDS and write it to a PS - and vice versa.

Paul Gilmartin wrote:

>On Wed, 15 Jun 2016 04:14:04 +0100, CM Poncelet wrote:
>
>
>>I would suggest writing some assembler code that invokes the BLDL
>>macro to read the PDS directory, ...
>>
>>
>>
>Does that work?
>
>-- 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

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

IBM plans for the future - an imaginary tale

[John Mattson]

IBM made mistakes back in the 1980's and 1990's from which they may never
really recover.
1) Doing away with the THINK motto.  It seems about the time they did this
is when many of them stopped thinking.
2) Stopped giving the systems almost free to colleges which stopped the
flow of trained personnel.  MS and Apple learned from this mistake.
3) They almost eliminated VM for heavens sake, and now others have
re-invented it and taken the market.  Someone clearly was NOT THINKing.
4) They invented the PC and did not see the potential in it.  It's like
Edison inventing the light bulb, saying "That's nice" and walking away.
Inexcusable.
Had they NOT done these things, cost would not be such a problem.  As
it is, lowering cost is about their only choice. Not a good place to be.

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

Re: Read a PDS (all members) like PS dataset

[פנינה קוניגסברג]

Always interesting, I am dealing this week  with an error that I hoped would be 
solved by the different solutions presented here, but after trying some of the 
solutions presented herein have not recovered. 
Background: In preparation for a system cutover, executed IDCAMS LISTC with 
SYSPRINT to a PDS file containing very important cutover data. (thought that 
was an efficient method of documentation   :)   - the laugh is on me).
The original file was a typical jcl type (80 lrecl) after running the LISTC and 
updating the results, the PDS members which existed prior to the LISTC job 
execution were unreadable - IO ERROR.   Since the disk was a 'sandbox' type 
disk, it wasn't backed up nor dumped.  I have been trying various recovery 
methods - many of them as advised on this discussion list to not avail. Any 
ideas ?  Would it be preferable for me to  specify the actions I already did to 
try to recover the file? 

.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of CM Poncelet
Sent: Wednesday, June 15, 2016 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Read a PDS (all members) like PS dataset

Yes it works, although I used it with the STOW macro (afterwards) to 
modify/update PDS directories. Use the List/Execute forms of the DCB 
Macro/DSECT if it is to be modified (in getmained storage).

The FIND macro can then be used to locate the start of each PDS member returned 
by the BLDL. From there, read each PDS member in turn (some Open/Read/Closes 
might be needed).

BTW My correction: IEBUPDTE can write (but not read, AFAIK) a PS dataset to a 
PDS. But IEBCOPY can read a PDS and write it to a PS - and vice versa.

Paul Gilmartin wrote:

>On Wed, 15 Jun 2016 04:14:04 +0100, CM Poncelet wrote:
>  
>
>>I would suggest writing some assembler code that invokes the BLDL 
>>macro to read the PDS directory, ...
>>
>>
>>
>Does that work?
>
>-- 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

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

Re: Read a PDS (all members) like PS dataset

[Tim Deller]

It sounds like you just want to scan a PDS. 
You can do that with a program that is part of ISPF.

//SCAN1 EXEC PGM=ISRSUPC,PARM='L SRCHCMP CKPACKL ANYC'
//OUTDD DD SYSOUT=*   
//NEWDD DD DISP=SHR,DSN=SOME.SOURCE.PDS 
 SRCHFOR 'RANGE'  
 SRCHFOR 'STRING3'
 SRCHFOR 'SOMETHING ELSE'

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

Re: Sysplex Timer issue

[Nathan Astle]

Hi,

It turned out that the CTN-ID value was coded in Upper case and what we
used to build the CF was in Lower case.

I am still trying to see if CTN-ID values are case sensitive.

Does anybody know if CTN-ID has such constraints ?

On Tue, Jun 14, 2016 at 2:40 AM, Kieron D Hinds  wrote:

> Hi,
> It sounds like you have a situation where the CF you're attempting to IPL
> is running on a CPC with a different CTNID than the CTNID of the CPC[s]
> where other images are already active (z/OS and CFs).
> I'd have to compare the CTNID in the output of the IXL160E as well as the
> IEA386I from the D ETR of active system[s] in the sysplex to know for
> sure, but if it the case then you'll need to get the CTNIDs to match.
>
> Is this the first attempt to activate the CF - if so was STP configured on
> the CF CPC? Versus if it was after a configuration change made to an
> existing CF, do you expect the STP configuration or the CTNID to change?
>
> Changing CTNIDs *can* be disruptive so please check with your local or IBM
> hardware support if you don't understand this already.
>
>
> Kieron Hinds
> z/OS Integration Test / System z Platform Evaluation Test
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From:   Nathan Astle 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   06/13/2016 01:54 PM
> Subject:Sysplex Timer issue
> Sent by:IBM Mainframe Discussion List 
>
>
>
> Hi,
>
> We are receiving the error message on CF, while IPling .
>
> IXL160E CF REQUEST TIME ORDERING: REQUIRED AND NOT-ENABLED 194
>
> REASON: CTNID MISMATCH
>
>
> The ETR I displayed in the Console is different from the error message.
>
>
> Does it mean i have to correct that in the IOGEN ?
>
>
> Jake
>
> --
> 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: Read a PDS (all members) like PS dataset

[Walt Farrell]

On Tue, 14 Jun 2016 23:18:37 -0500, Paul Gilmartin  wrote:

>On Wed, 15 Jun 2016 04:14:04 +0100, CM Poncelet wrote:
>>
>>I would suggest writing some assembler code that invokes the BLDL macro
>>to read the PDS directory, ...
>> 
>Does that work?

No, it doesn't. BLDL requires that you already know the member name.

-- 
Walt

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

Read a PDS (all members) like PS dataset

[Bill Woodger]

Perhaps SAS calls IEBPTPCH "under the covers"?

Don't "buy" SAS just to do this...

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

Re: Read a PDS (all members) like PS dataset

[Vernooij, CP (ITOPT1) - KLM]

If you have SAS, you can use PROC SOURCE to unload a PDS to a PS dataset with 
separators between members specifying the membername.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Ten Eyck
Sent: 14 June, 2016 19:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Read a PDS (all members) like PS dataset

Any suggestions on how to read though a PDS (all members) like PS dataset. 
Example, read via a program the trough a PDS finding every called or linked 
program statement without regard to PDS member name.

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




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