AW: Re: AW: Re: IEFA111I at IPL Time for z/OS V2.3

[Peter Hunkeler]

>I've arranged to have the System Messages documentation updated.
Thanks, Scott, for having the doc updated. Saves me an RCF.


--
Peter Hunkeler



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

Re: curious: Popularity & use of C on z/OS.

[Wayne Bickerdike]

I was at IBM from 1978 and I certainly remember the spoof on the "COME
FROM" statement.

Some wag inside IBM wrote a fairly convincing treatise which was called
"Structured Programming IBM's answer to the GOTO statement".

At the time IBM were actively training us in Jackson Structured
programming. It was largely a local effort at Northern Road in Cosham. It
never made it to the guys at RESPOND.

On Thu, Jan 18, 2018 at 4:06 PM, Joel C. Ewing  wrote:

> One of the issues of ACM SIGPLAN Notices definitively resolved this
> issue by suggesting that the any need for the harmful semantics of GOTO
> statement could easily be eliminated by instead allowing a "COME FROM"
> statement.  I can't remember which year, but it was an April issue.  :)
> JC Ewing
>
> On 01/17/2018 06:25 PM, Wayne Bickerdike wrote:
> > The old goto chestnut drops again.
> >
> > *Considered harmful* is a part of a phrasal template
> >  used in the titles of
> at
> > least 65 critical essays in computer science
> >  and related
> disciplines.[1]
> >  Its use
> in
> > this context originated in 1968 with Edsger Dijkstra
> > 's letter "Go To
> Statement
> > Considered Harmful".'t the originator of "goto considered harmful".
> >
> > I thought Michael Jackson defused it well it the 1970s with his
> structured
> > programming book and methods. GOTO was absolutely necessary in many
> cases.
> >
> > I'll posit that most will agree and admit that some won't.
> >
> >
> >
> > On Wed, Jan 17, 2018 at 11:10 PM, David Crayford 
> > wrote:
> >
> >> On 17/01/2018 3:19 AM, Paul Gilmartin wrote:
> >>
> >>> On Tue, 16 Jan 2018 18:51:55 +, Seymour J Metz wrote:
> >>>
> >>> That's a common beginners' mistake. Try putting the label inside a do
>  block and see what happens. A proper goto would pop what needs to be
> popped
>  and no more. See .
> 
>  Yes.
> >>> There I also read:
> >>>  Continuation
> >>>  REXX allows implicit continuation; a statement is treated as
> >>> continued if it
> >>>  would otherwise be syntactically invalid.  ...
> >>> ???
> >>> Not in any Rexx I know.  Is this perhaps a peculiarity of OS/2 Rexx?
> >>>
> >>> And C has an improper GOTO.  It allows branching into a block.  It's
> >>> implementation
> >>> dependent whether initializations are performed then.  Ugh!
> >>>
> >> If you don't like those semantics don't use goto. My ROT is to only use
> >> goto for branching to error handlers or cleanup routines.
> >>
> >> If you look at the Linux kernel code including s390 you will see lots of
> >> goto statements used just for that purpose. It's amusing to read threads
> >> about what the maintainers think about this subject
> >> http://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-
> >> in-Linux-Kernel-Code/.
> >>
> >>
> >>
> >>> ___
> >>>
>  From: Jack J. Woehr
>  Sent: Sunday, January 14, 2018 3:40 PM
> 
>  On 1/14/2018 11:35 AM, Seymour J Metz wrote:
> 
> > REXX doesn't have a goto
> >
>  Sure it does: SIGNAL
> 
> >>> -- gil
> >>>
> >>>
> >
> >
>
> --
> Joel C. Ewing,Bentonville, AR   jcew...@acm.org
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Wayne V. Bickerdike

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

Re: 0C4 in IGGCSI00

[ITschak Mugzach]

Same abens on our v2.2 (zPDT).

ITschak

בתאריך 18 בינו׳ 2018 4:04 לפנה״צ,‏ "Walt Farrell" 
כתב:

> On Thu, 18 Jan 2018 11:38:28 +1100, Wayne Bickerdike 
> wrote:
>
> >Kirks example was *KIRK..FOO*.
> >
> >I don't even receive a message for that filter..
>
> Thanks, Wayne.
>
> Sorry, Kirk. I didn't read carefully enough.
>
> --
> Walt
>
> --
> 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

HCD CHIPD definition - SPAN

[Ravi Gaur]

Thanks in advance for addressing my question ...
I am defining a new partition on separate LCSS (most of our partition are on 
LCSS 1 and this new partition is on 1) and further defining a CHIPID of type 
OSC now the chipid's being defined should be in mode of  "SPAN" as it's 
spanning across LCSS for different partitions however every time it's changing 
to SHR mode for new LCSS any hints to figure it out why??...

Below is a message :

EsN
e Selected operation mode SPAN for channel path 1.45 of processor CYY2 is e
e adjusted to mode SHR to match current partition assignments.e
DsM

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

Re: Are Mainframes a Security Risk? | Enterprise Systems Media

[Edward Gould]

> On Jan 17, 2018, at 12:34 PM, Seymour J Metz  wrote:
> 
> Good hardware and good software don't ensure security, but they make it 
> easier. Note that I wrote "easier", not "easy". There is no substitute for 
> good management.
> 
> 
Seymour:

Some 20 years ago thew company I worked for hired a real newbie. His 
qualifications were “system administrator”. Since we dealt with the security 
people all the time, it took all of an hour to get an idea that he should not 
have update access to anything. I talked to my boss and he talked with the 
people that were running their department and we we got back was he had plenty 
of experience. 
I went to the auditors as they were semi friends of mine and explained what was 
going on and that they should at least look into it. The next day the guy was 
out on the street with no references.  I get a phone call thanking me for 
letting them know about the situation. From then on before they could hire 
anyone in there security department they had to have interviewed with one of 
the auditors.
I stepped on some toes but the people in the security department had been 
overruled. We were still friends, the boss hated my guts as he got passed over 
from then on for AVP.

ed

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

Re: [EXTERNAL] Are Mainframes a Security Risk? | Enterprise Systems Media

[Edward Gould]

> On Jan 17, 2018, at 1:48 AM, Sankaranarayanan, Vignesh 
>  wrote:
> 
> "... he was able to find an exposure in z/OS rather fast, the ability of 
> almost any user to edit the APF (authorized program
> facilities) and give yourself root access."
> 
> ROFLMAO
> 
> That someone examined a very poorly secured z/OS system proves nothing.
> 
> --
> Tom Marchant

Tom,

You are spot on. I went to such a session and they were plowing on through with 
their presentation. I asked if the system was properly RACF protected, he tried 
some double talk and I asked specifically if sys1.parmlib was protected and he 
started up with the double talk. I stood up and said if you do not have a 
properly protected system, then YES you can play the tricks they were going 
through, I then said if sys1.parmlib is NOT protected then you get what ever 
you are trying to sell here. Someone 3 or 4 rows away from me said something to 
the effect that your software isn’t doing the basics then you shouldn’t let 
anyone near the system. The speaker got up and said yes this system was 
protected by RACF. I then asked if all the needed RACF rules had been written 
and no one could update any APF library. He then tried a run around and said 
all the program had to do was issue the SVC to do operator commands. I 
suggested then the system wasn’t properly RACF protected. The guy up on stage 
called for a coffee break. The guy that was running the show came over to me 
and told me I was being disruptive and could I please leave.  I said sure as 
long as you promise to give an honest presentation. He said, OK, LEAVE now. I 
left and I think that a lot of people left after I did.

Ed


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

Re: Finding the names of hsm's BCDSs

[Ron hawkins]

Would obtaining the data set names from SDSF meet your requirement?

//DFHSMJOB MSGLEVEL=1  
//STARTING EXEC DFHSM,CMD=00   
XX 
XX*  DFHSM 1.3 -  START PROCEDURE* 
XX*  * 
XX* THE FOLLOWING START PROCEDURE COULD BE DUPLICATED, AND RENAMED   * 
XX* FOR ANOTHER CPU IN THE CASE WHERE A MULTI-HOST ENVIRONMENT WILL  * 
XX* BE USED. CHANGES WOULD BE REQUIRED FOR THE CMD= AND THE HOST=* 
XX* PARAMETERS, AND THE ARCLOGX AND ARCLOGY DATA SET NAMES.  * 
XX*  * 
XX 
XXDFHSM  PROC CMD=00, USE PARMLIB MEMBER ARCCMD00  
XXEMERG=NO,   ALLOW ALL DFHSM FUNCTIONS
XXLOGSW=NO,   DON'T SWITCH LOGS AT STARTUP 
XXSTARTUP=YES,STARTUP INFO PRINTED AT STARTUP  
XXUID=DFHSM,  DFHSM AUTHORIZED-USER ID 
XXSIZE=0M,REGION SIZE FOR DFHSM
XXDDD=50, MAX DYNAMICALLY ALLOCATED DATA SETS  
XXHOST=1Y PROC.UNIT ID AND LEVEL FUNCTIONS 
XXDFHSM  EXEC PGM=ARCCTL,DYNAMNBR=,REGION=,TIME=1440, 
XXPARM=('EMERG=','LOGSW=','CMD=','UID=',   
XX'STARTUP=','HOST=') 
IEFC653I SUBSTITUTION JCL - PGM=ARCCTL,DYNAMNBR=50,REGION=0M,TIME=1440,
'UID=DFHSM','STARTUP=YES','HOST=1Y')   
XXHSMPARM  DD DSN=SYS1.PARMLIB,DISP=SHR
XXMSYSOUT  DD SYSOUT=A 
XXMSYSIN   DD DUMMY
XXSYSPRINT DD SYSOUT=A,FREE=CLOSE  
XXSYSUDUMP DD SYSOUT=A 
XXMIGCAT   DD DSN=,DISP=SHR  
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.MCDS,DISP=SHR
XXJOURNAL  DD DSN=,DISP=MOD  
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.JRNL,DISP=MOD
XXARCLOGX  DD DSN=,DISP=MOD  
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.HSMLOGX1,DISP=MOD
XXARCLOGY  DD DSN=,DISP=MOD  
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.HSMLOGY1,DISP=MOD
XXARCPDOX  DD DSN=,DISP=SHR   
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.HSMPDOX,DISP=SHR 
XXARCPDOY  DD DSN=,DISP=SHR   
XX*  */
XX* REMOVE THE NEXT DD STATEMENT IF YOU DO NOT INTEND TO USE */
XX* BACKUP AND DUMP. */
XX*  */
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.HSMPDOY,DISP=SHR 
XXBAKCAT   DD DSN=,DISP=SHR  
XX*  */
XX* REMOVE THE NEXT DD STATEMENT IF YOU DO NOT   */
XX* INTEND TO USE TAPE VOLUMES FOR DAILY BACKUP VOLUMES, SPILL   */
XX* BACKUP VOLUMES, OR MIGRATION LEVEL 2 VOLUMES.*/
XX*  */
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.BCDS,DISP=SHR
XXOFFCAT   DD DSN=,DISP=SHR  
IEFC653I SUBSTITUTION JCL - DSN=DFHSM.OCDS,DISP=SHR

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Wednesday, January 17, 2018 6:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Finding the names of hsm's BCDSs

Similarly, I was going to suggest calling TSO to invoke HSEND WAIT.

But QUERY CDS doesn't reveal the names of the HSM CDS's, just space information 
about them. Neither does Q SETSYS, but it does show the names of the CDS backup 
datasets. Quite often the backup dataset names are the same as the CDS', 
suffixed with BACKUP or BKUP or something.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Graham Harris
Sent: Thursday, 18 January 2018 6:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Finding the names of hsm's BCDSs

Whilst you're waiting for IBM to deliver a proper API, you could trap the 
console output from a F DFHSM,Q CDS.
DFHSM may well not be called DFHSM of course, so that will add a little extra 
work, perhaps using an ISGQUERY on ARCENQG




On 17 January 2018 at 13:29, Manfred Lotz  wrote:

> On Wed, 17 

Re: curious: Popularity & use of C on z/OS.

[Joel C. Ewing]

One of the issues of ACM SIGPLAN Notices definitively resolved this
issue by suggesting that the any need for the harmful semantics of GOTO
statement could easily be eliminated by instead allowing a "COME FROM"
statement.  I can't remember which year, but it was an April issue.  :)
    JC Ewing

On 01/17/2018 06:25 PM, Wayne Bickerdike wrote:
> The old goto chestnut drops again.
>
> *Considered harmful* is a part of a phrasal template
>  used in the titles of at
> least 65 critical essays in computer science
>  and related disciplines.[1]
>  Its use in
> this context originated in 1968 with Edsger Dijkstra
> 's letter "Go To Statement
> Considered Harmful".'t the originator of "goto considered harmful".
>
> I thought Michael Jackson defused it well it the 1970s with his structured
> programming book and methods. GOTO was absolutely necessary in many cases.
>
> I'll posit that most will agree and admit that some won't.
>
>
>
> On Wed, Jan 17, 2018 at 11:10 PM, David Crayford 
> wrote:
>
>> On 17/01/2018 3:19 AM, Paul Gilmartin wrote:
>>
>>> On Tue, 16 Jan 2018 18:51:55 +, Seymour J Metz wrote:
>>>
>>> That's a common beginners' mistake. Try putting the label inside a do
 block and see what happens. A proper goto would pop what needs to be popped
 and no more. See .

 Yes.
>>> There I also read:
>>>  Continuation
>>>  REXX allows implicit continuation; a statement is treated as
>>> continued if it
>>>  would otherwise be syntactically invalid.  ...
>>> ???
>>> Not in any Rexx I know.  Is this perhaps a peculiarity of OS/2 Rexx?
>>>
>>> And C has an improper GOTO.  It allows branching into a block.  It's
>>> implementation
>>> dependent whether initializations are performed then.  Ugh!
>>>
>> If you don't like those semantics don't use goto. My ROT is to only use
>> goto for branching to error handlers or cleanup routines.
>>
>> If you look at the Linux kernel code including s390 you will see lots of
>> goto statements used just for that purpose. It's amusing to read threads
>> about what the maintainers think about this subject
>> http://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-
>> in-Linux-Kernel-Code/.
>>
>>
>>
>>> ___
>>>
 From: Jack J. Woehr
 Sent: Sunday, January 14, 2018 3:40 PM

 On 1/14/2018 11:35 AM, Seymour J Metz wrote:

> REXX doesn't have a goto
>
 Sure it does: SIGNAL

>>> -- gil
>>>
>>>
>
>

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: VSE timeline [was: RE: VSAM usage for ancient disk models]

[Edward Gould]

> On Jan 17, 2018, at 12:16 PM, Farley, Peter x23353 
>  wrote:
> 
> On this Wikipedia page, notes #44 and #45 lead to IBM z/VSE history pages 
> that may tell you what you want to know.
> 
> https://en.wikipedia.org/wiki/History_of_IBM_mainframe_operating_systems#DOS/VS
>  
> 
> 
> 1980's VSE history:   
> https://www-03.ibm.com/systems/z/os/zvse/about/history1980s.html 
> 
> 
> 1990's VSE history:   
> https://www-03.ibm.com/systems/z/os/zvse/about/history1990s.html 
> 
> 
> 2000's VSE History:   
> https://www-03.ibm.com/systems/z/os/zvse/about/history2000s.html 
> 
> 
> 2010's VSE History:   
> https://www-03.ibm.com/systems/z/os/zvse/about/history2010s.html 
> 
> 
> Each of the IBM pages has a link to the next decade's history page, so you 
> can start with the 1980's page and proceed to the others in sequence.
> 
> I didn't read all the IBM pages closely, but I didn't see VSE/AF jump out.  
> Was that actually a version?
> 
> ECPS:VSE was a hardware feature on the 43xx machines (I know for sure it was 
> on the 4361, not sure about other models).  IIRC it provided microcode 
> assists for VSE under VM.
> 
> HTH
> 
> Peter

Peter:

It was on a 4331 that we had for testing.
Ed


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

Re: VSE timeline [was: RE: VSAM usage for ancient disk models]

[Barry Merrill]

You said: 

"The 3370s had a manufacturing fault that caused HDA failures. 
A good friend was an IBM CE and he told me that it was caused 
by contaminated lubricant."

In about 1975, I recall Roger Buchanan, an IBM CE originally from Australia,
described an IBM Disk Error problem he had just recently resolved, and I
think it was with the first European delivery of 3330s.

Apparently the new drives had been stored in several warehouses worldwide,
including one in Germany, awaiting the GA for shipment, and when those
first shipments went out, one-half of all of the European-stored drives
failed, with no other failures reported from any other warehouse.

Fortunately, IBM kept meticulous records of exactly where the drives had
been stored, so it only took a few days of failures to determine that 
all of the failed drives had been stored on the perimeter of the room,
and there were no failures for the interior stored devices.
By then, all of the failed devices had been replaced from other warehouses.

It took somewhat longer to determine the actual cause.
The walls of the storage room had been painted in a silicon-based paint,
and that silicon had leeched (?) into the silicon substrate of those
devices near the silicon wall (platters or electronics??).

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



 


 



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Wayne Bickerdike
Sent: Wednesday, January 17, 2018 5:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VSE timeline [was: RE: VSAM usage for ancient disk models]

I remember the 3310. IBM called them "piccolo" drives because of the noise the 
actuators made.

We received a bunch of these as replacements for faulty 3370s. That was back in 
1981 when I was working at ICI Petrochemicals in the UK.

The 3370s had a manufacturing fault that caused HDA failures. A good friend was 
an IBM CE and he told me that it was caused by contaminated lubricant.

It only affected drives manufactured at the plant in Germany. US drives weren't 
affected.

That was my first foray into DOS/VSE and FBA architecture.

We were running on a 4331 box, it was tiny and we ran ADABAS and CICS with a 
bunch of batch programs that built a bill of materials reporting system.

Batch runs took 24 + hours and the particular technique we used to drive the 
totals up the hierarchy destroyed those 3370s. (Lots of VSAM inserts and CI/CA 
splits).

We optimised the solution by using ADABAS which did work better than VSAM at 
the time.

Pretty sure that VSE/AF was a release too.

On Thu, Jan 18, 2018 at 5:28 AM, Seymour J Metz  wrote:

> Thanks. I was really hoping for something that listed all of the 
> players, with dates.
>
> VSE/AF was an add-on DOS/VSE package, just as MVS/SE was an add-on, 
> but I don't recall anybody saying "I'm running OS/VS2 R3.7 with 
> MVS/SE" or "I'm running OS/VS2 R3.8 with MVS/SE" instead of the 
> shorter "I'm running MVS/SE" or "I'm running MVS/SE2". Likewise with VM/SE 
> and VM/BSE.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Farley, Peter x23353 
> Sent: Wednesday, January 17, 2018 1:16 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: VSE timeline [was: RE: VSAM usage for ancient disk models]
>
> On this Wikipedia page, notes #44 and #45 lead to IBM z/VSE history 
> pages that may tell you what you want to know.
>
> https://secure-web.cisco.com/1Hxni8z1xE6vDmveRBopjI3Vzv4qg9
> VQ9eZGrH7t2axlv2TXRuKnDcewtJL-hrpi8jwK3-GxrA-
> 2iIMOvZDRBBfUNxKH2YcS14FFnmmhJH8BilUDJ1_2fI_5ME-
> 1hcCiY4dtKk8BTHa4OU6MfD7om1snenBWocvMGhl9GvOLU0_SOumoC5h-SVpLXZF_fC_
> aZLNzcOoQkWOHCDg6EhiG_kuy613a7e10fUIKzh-OapHJjXeZgVzPmkE1JIrW3eqtWAaxH
> eHFBht9WMWu5HxrN0rT_G2I-jEIzGTcNKtmOQfe1k--Q0UIKlGX2P1YoZJPSn6SKoEFiqv
> 9AD qG0PB3IvtsFsaIpaeCFoMMwXzsHPbebyeNDS7pKAq0_bLLcvaHD8dg6P2PU_
> hyO9MaXHylVHJzPZYhoUg3Uqk6r93PuIyH8nr2wio5V00QSoeYBZEzu/
> https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHistory_of_IBM_
> mainframe_operating_systems#DOS/VS
>
> 1980's VSE history: https://secure-web.cisco.com/
> 1mhCrVwIL6XNHIiS5zTkFhpBby8bw8liiRCkscsxbarX123Dg5jOSVKmKsH7
> ad9EfIz7qIm2VVjm9Z7niqX7VrOYwox2dnKpLjSm1a4bqN28BrF0nUCxpLYq
> EgyI9sWzR8x15GQT8mhNnr7iBxhHfQHD3hNKOYFygabIef1J9hcGY0ePFJPB
> RCtLVtsFarc387G5z2gY2lEqN7e-2ZYPN7cE2fKe6SWiDdlMkdc6vKiZYN
> dLbLrWHW0yzZ8YEjssi7Ek0bjZJYXIpSG6BW49F2LPvg9d6OTqa5tfdhgYcB
> k7YHuD19oVd02c1GoZe_u-XB1Az7by4zHbAgG4hyQrDiY9-
> mDz0RVkx2NKR7y4eptT43nCdIeuq0Jm0_sf_7B4A7TWWAR3E2Wbb7VuUC9b9O7KKRy
> J1kve_TXVodmW6kovwAgZ_pDwmDDagNzWKgbKd/https%3A%2F%
> 

Re: PDSCLEAN issue

[Anthony Thompson]

Oops, typo... z/OS 1.8

Sorry, Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Thursday, 18 January 2018 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDSCLEAN issue

My understanding is that the problem with deleting PDSE's after they have been 
in linklist, even after being removed from the currently active linklist set, 
was fixed in z/OS 1. See OW57609.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Beesley, Paul
Sent: Thursday, 18 January 2018 12:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDSCLEAN issue

No, Allan is right. LNKLST can include PDSE datasets but they seem to be 
managed differently to those added after IPL. They can't be deleted even after 
going through the Linklist unallocate palaver, and it seems they can't be 
emptied effectively.

BTW, someone suggested DELETE PDSE(*) but that doesn't work for Linklist 
datasets as they are in use by LLA (although I haven't tried stopping LLA)

Regards and thanks
Paul

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Wednesday, January 17, 2018 1:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDSCLEAN issue

On Tue, 16 Jan 2018 16:25:40 +, Allan Staller wrote:

>The only restriction I am aware of is that the PDSE cannot be in the IPL time 
>LINKLIST.

I think you mean LPA. LNKLST can include PDSE data sets.

--
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN Atos, Atos Consulting, 
Worldline and Canopy The Open Cloud Company are trading names used by the Atos 
group. The following trading entities are registered in England and Wales: Atos 
IT Services UK Limited (registered number 01245534), Atos Consulting Limited 
(registered number 04312380), Atos Worldline UK Limited (registered number 
08514184) and Canopy The Open Cloud Company Limited (registration number 
08011902). The registered office for each is at 4 Triton Square, Regent’s 
Place, London, NW1 3HG.The VAT No. for each is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for 
the addressee, and may contain confidential or privileged information. If you 
receive this e-mail in error, you are not authorised to copy, disclose, use or 
retain it. Please notify the sender immediately and delete this email from your 
systems. As emails may be intercepted, amended or lost, they are not secure. 
Atos therefore can accept no liability for any errors or their content. 
Although Atos endeavours to maintain a virus-free network, we do not warrant 
that this transmission is virus-free and can accept no liability for any 
damages resulting from any virus transmitted. The risks are deemed to be 
accepted by everyone who communicates with Atos by email.

--
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: PDSCLEAN issue

[Anthony Thompson]

My understanding is that the problem with deleting PDSE's after they have been 
in linklist, even after being removed from the currently active linklist set, 
was fixed in z/OS 1. See OW57609.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Beesley, Paul
Sent: Thursday, 18 January 2018 12:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDSCLEAN issue

No, Allan is right. LNKLST can include PDSE datasets but they seem to be 
managed differently to those added after IPL. They can't be deleted even after 
going through the Linklist unallocate palaver, and it seems they can't be 
emptied effectively.

BTW, someone suggested DELETE PDSE(*) but that doesn't work for Linklist 
datasets as they are in use by LLA (although I haven't tried stopping LLA)

Regards and thanks
Paul

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Wednesday, January 17, 2018 1:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDSCLEAN issue

On Tue, 16 Jan 2018 16:25:40 +, Allan Staller wrote:

>The only restriction I am aware of is that the PDSE cannot be in the IPL time 
>LINKLIST.

I think you mean LPA. LNKLST can include PDSE data sets.

--
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN Atos, Atos Consulting, 
Worldline and Canopy The Open Cloud Company are trading names used by the Atos 
group. The following trading entities are registered in England and Wales: Atos 
IT Services UK Limited (registered number 01245534), Atos Consulting Limited 
(registered number 04312380), Atos Worldline UK Limited (registered number 
08514184) and Canopy The Open Cloud Company Limited (registration number 
08011902). The registered office for each is at 4 Triton Square, Regent’s 
Place, London, NW1 3HG.The VAT No. for each is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for 
the addressee, and may contain confidential or privileged information. If you 
receive this e-mail in error, you are not authorised to copy, disclose, use or 
retain it. Please notify the sender immediately and delete this email from your 
systems. As emails may be intercepted, amended or lost, they are not secure. 
Atos therefore can accept no liability for any errors or their content. 
Although Atos endeavours to maintain a virus-free network, we do not warrant 
that this transmission is virus-free and can accept no liability for any 
damages resulting from any virus transmitted. The risks are deemed to be 
accepted by everyone who communicates with Atos by email.

--
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: VSE timeline [was: RE: VSAM usage for ancient disk models]

[Wayne Bickerdike]

In 1987 I worked on a variant of the 4331. The 8890.

Sold by Nixdorf but manufactured by Hitachi in Israel. We ran DOS/VSE with
FBA drives made by Fujitsu but rebadged as Nixdorf.

It was replaced by an IBM 9370 with 9335 FBA drives. The 2.5 MIPS of this
box soon maxed out and we went back to a more conventional NAS box with
Hitachi DASD.



On Thu, Jan 18, 2018 at 11:15 AM, Michel Beaulieu 
wrote:

> I was an IBM systems engineer  in that time  1980-1983.
> If memory serves me well: there was ECPS:VSE to run VSE/SP v1 natively on
> 4331 and 4341
>
> with single level storage (somewhat like a s/38 back then).
> ECPS:VM was the microcode to provide VM assists to VM/SP v1.
> The base code was DOS/VSE ( kind of follow on release to DOS/VS r34).
> Adding VSE/Advanced Functions on top of DOS/VSE was the building blocks of
> VSE/SP v1.
> VSE/SP was the preferred  delivery packaging. With the Other Program
> Products included in SIPO tapes.
> --
> Later, IBM would do one extra level of integration and build  VM/SP
> Express and VSE/SP Express
>
> tailored to the client configuration, the installation could restore a
> running system using FCOPY or DDR.
>
>
> Michel Beaulieu
>
> |*|
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Farley, Peter x23353 
> Sent: January 17, 2018 1:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: VSE timeline [was: RE: VSAM usage for ancient disk models]
>
> On this Wikipedia page, notes #44 and #45 lead to IBM z/VSE history pages
> that may tell you what you want to know.
>
> https://en.wikipedia.org/wiki/History_of_IBM_mainframe_
> operating_systems#DOS/VS
>
> 1980's VSE history: https://www-03.ibm.com/systems/z/os/zvse/about/
> history1980s.html
>
> 1990's VSE history: https://www-03.ibm.com/systems/z/os/zvse/about/
> history1990s.html
>
> 2000's VSE History: https://www-03.ibm.com/systems/z/os/zvse/about/
> history2000s.html
> [https://www-03.ibm.com/systems/resources/systemz_v17_
> zvse_images_zvselogo4_123x50.jpg] systems/z/os/zvse/about/history2000s.html>
>
> IBM: z/VSE Operating System - History - 2000s systems/z/os/zvse/about/history2000s.html>
> www-03.ibm.com
> Information about IBM's VSE operating system. Page describes VSE history
> in the 2000s.
>
>
>
> 2010's VSE History: https://www-03.ibm.com/systems/z/os/zvse/about/
> history2010s.html
> IBM: z/VSE Operating System - History - 2010s systems/z/os/zvse/about/history2010s.html>
> www-03.ibm.com
> Information about IBM's VSE operating system. Page describes VSE history
> in the 2010s.
>
>
>
> Each of the IBM pages has a link to the next decade's history page, so you
> can start with the 1980's page and proceed to the others in sequence.
>
> I didn't read all the IBM pages closely, but I didn't see VSE/AF jump
> out.  Was that actually a version?
>
> ECPS:VSE was a hardware feature on the 43xx machines (I know for sure it
> was on the 4361, not sure about other models).  IIRC it provided microcode
> assists for VSE under VM.
>
> HTH
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: Wednesday, January 17, 2018 12:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VSAM usage for ancient disk models
>
> Of course I remember the 3310, although I never used one. But your post
> reminds me of a question.
>
> Does anybody have a VSE timeline from the original DOS/VSE and ECPS:VSE
> that includes all of the packages, e.g., VSE/AF? There's a wike article on
> VSE and I'd like to flesh that out, or, better, put someone up to doing so.
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Farley, Peter x23353 
> Sent: Wednesday, January 17, 2018 11:10 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: VSAM usage for ancient disk models
>
> The 3090 processor controllers ran VM/370 on 3370 (FBA) disks.  I was able
> to actually see one of these at a large NYC shop in the 1990's while
> touring it with a friend who was the VP of Operations there.  The 3270
> screen inside the 3090 box had the VM/370 screen logo.
>
> That made my day.  I was a VM/VSE guy at the time and really resented the
> way that MVS shops looked down on us, as if we were deprived, backwards
> children.
>
> And you are right, the 3375's were 3370 boxes that emulated CKD on
> physical FBA geometry.
>
> Anyone remember 3310's?  Smaller FBA brothers of the 3370 DASD, sold with
> 4331 low-end CPU's for VM/VSE usage.  There was a special VSE version
> created in the mid 1980's (SSX/VSE) with simplified and largely menu-driven
> system generation and maintenance intended for sale with those low-end 

Re: curious: Popularity & use of C on z/OS.

[Wayne Bickerdike]

The old goto chestnut drops again.

*Considered harmful* is a part of a phrasal template
 used in the titles of at
least 65 critical essays in computer science
 and related disciplines.[1]
 Its use in
this context originated in 1968 with Edsger Dijkstra
's letter "Go To Statement
Considered Harmful".'t the originator of "goto considered harmful".

I thought Michael Jackson defused it well it the 1970s with his structured
programming book and methods. GOTO was absolutely necessary in many cases.

I'll posit that most will agree and admit that some won't.



On Wed, Jan 17, 2018 at 11:10 PM, David Crayford 
wrote:

> On 17/01/2018 3:19 AM, Paul Gilmartin wrote:
>
>> On Tue, 16 Jan 2018 18:51:55 +, Seymour J Metz wrote:
>>
>> That's a common beginners' mistake. Try putting the label inside a do
>>> block and see what happens. A proper goto would pop what needs to be popped
>>> and no more. See .
>>>
>>> Yes.
>>
>> There I also read:
>>  Continuation
>>  REXX allows implicit continuation; a statement is treated as
>> continued if it
>>  would otherwise be syntactically invalid.  ...
>> ???
>> Not in any Rexx I know.  Is this perhaps a peculiarity of OS/2 Rexx?
>>
>> And C has an improper GOTO.  It allows branching into a block.  It's
>> implementation
>> dependent whether initializations are performed then.  Ugh!
>>
>
> If you don't like those semantics don't use goto. My ROT is to only use
> goto for branching to error handlers or cleanup routines.
>
> If you look at the Linux kernel code including s390 you will see lots of
> goto statements used just for that purpose. It's amusing to read threads
> about what the maintainers think about this subject
> http://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-
> in-Linux-Kernel-Code/.
>
>
>
>> ___
>>
>>> From: Jack J. Woehr
>>> Sent: Sunday, January 14, 2018 3:40 PM
>>>
>>> On 1/14/2018 11:35 AM, Seymour J Metz wrote:
>>>
 REXX doesn't have a goto

>>> Sure it does: SIGNAL
>>>
>> -- 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
>



-- 
Wayne V. Bickerdike

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

What about 3390-9 track???

[R.S.]

I just read some chapter of DFSMS Macro Instructions for Datasets, the 
current one.
And I found the manual claims a 3990-9 hac longer track size: it is 
56669 - not 56664.

Is it a typo or there is something I don't know???
(it is Appendix 1.5.4)

--
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.plsą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.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Re: 0C4 in IGGCSI00

[Walt Farrell]

On Wed, 17 Jan 2018 16:25:28 -0600, Kirk Wolf  wrote:

>If I pass an invalid filter key to IGGCSI00, I get an 0C4 in IGGCSI00.

Invalid in what way?

-- 
Walt

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

Re: VSE timeline [was: RE: VSAM usage for ancient disk models]

[Wayne Bickerdike]

I remember the 3310. IBM called them "piccolo" drives because of the noise
the actuators made.

We received a bunch of these as replacements for faulty 3370s. That was
back in 1981 when I was working at ICI Petrochemicals in the UK.

The 3370s had a manufacturing fault that caused HDA failures. A good friend
was an IBM CE and he told me that it was caused by contaminated lubricant.

It only affected drives manufactured at the plant in Germany. US drives
weren't affected.

That was my first foray into DOS/VSE and FBA architecture.

We were running on a 4331 box, it was tiny and we ran ADABAS and CICS with
a bunch of batch programs that built a bill of materials reporting system.

Batch runs took 24 + hours and the particular technique we used to drive
the totals up the hierarchy destroyed those 3370s. (Lots of VSAM inserts
and CI/CA splits).

We optimised the solution by using ADABAS which did work better than VSAM
at the time.

Pretty sure that VSE/AF was a release too.

On Thu, Jan 18, 2018 at 5:28 AM, Seymour J Metz  wrote:

> Thanks. I was really hoping for something that listed all of the players,
> with dates.
>
> VSE/AF was an add-on DOS/VSE package, just as MVS/SE was an add-on, but I
> don't recall anybody saying "I'm running OS/VS2 R3.7 with MVS/SE" or "I'm
> running OS/VS2 R3.8 with MVS/SE" instead of the shorter "I'm running
> MVS/SE" or "I'm running MVS/SE2". Likewise with VM/SE and VM/BSE.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Farley, Peter x23353 
> Sent: Wednesday, January 17, 2018 1:16 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: VSE timeline [was: RE: VSAM usage for ancient disk models]
>
> On this Wikipedia page, notes #44 and #45 lead to IBM z/VSE history pages
> that may tell you what you want to know.
>
> https://secure-web.cisco.com/1Hxni8z1xE6vDmveRBopjI3Vzv4qg9
> VQ9eZGrH7t2axlv2TXRuKnDcewtJL-hrpi8jwK3-GxrA-
> 2iIMOvZDRBBfUNxKH2YcS14FFnmmhJH8BilUDJ1_2fI_5ME-
> 1hcCiY4dtKk8BTHa4OU6MfD7om1snenBWocvMGhl9GvOLU0_SOumoC5h-SVpLXZF_fC_
> aZLNzcOoQkWOHCDg6EhiG_kuy613a7e10fUIKzh-OapHJjXeZgVzPmkE1JIrW3eqtWAaxH
> eHFBht9WMWu5HxrN0rT_G2I-jEIzGTcNKtmOQfe1k--Q0UIKlGX2P1YoZJPSn6SKoEFiqv9AD
> qG0PB3IvtsFsaIpaeCFoMMwXzsHPbebyeNDS7pKAq0_bLLcvaHD8dg6P2PU_
> hyO9MaXHylVHJzPZYhoUg3Uqk6r93PuIyH8nr2wio5V00QSoeYBZEzu/
> https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FHistory_of_IBM_
> mainframe_operating_systems#DOS/VS
>
> 1980's VSE history: https://secure-web.cisco.com/
> 1mhCrVwIL6XNHIiS5zTkFhpBby8bw8liiRCkscsxbarX123Dg5jOSVKmKsH7
> ad9EfIz7qIm2VVjm9Z7niqX7VrOYwox2dnKpLjSm1a4bqN28BrF0nUCxpLYq
> EgyI9sWzR8x15GQT8mhNnr7iBxhHfQHD3hNKOYFygabIef1J9hcGY0ePFJPB
> RCtLVtsFarc387G5z2gY2lEqN7e-2ZYPN7cE2fKe6SWiDdlMkdc6vKiZYN
> dLbLrWHW0yzZ8YEjssi7Ek0bjZJYXIpSG6BW49F2LPvg9d6OTqa5tfdhgYcB
> k7YHuD19oVd02c1GoZe_u-XB1Az7by4zHbAgG4hyQrDiY9-
> mDz0RVkx2NKR7y4eptT43nCdIeuq0Jm0_sf_7B4A7TWWAR3E2Wbb7VuUC9b9O7KKRy
> J1kve_TXVodmW6kovwAgZ_pDwmDDagNzWKgbKd/https%3A%2F%
> 2Fwww-03.ibm.com%2Fsystems%2Fz%2Fos%2Fzvse%2Fabout%2Fhistory1980s.html
>
> 1990's VSE history: https://secure-web.cisco.com/
> 1db5triiP9Ds00aTgPbxRFOmDUxC7BcMOtYsni3chH_xTYDM6Oh7-
> 470gMWwkxX0MAM_Z3kJtt_3TMfyV6LtgguCau43dVKqo5c15wNS4
> Phz8J5hGLYOCphPa6Yr6yBekoeDHRBqKyuLjryQPwQ7-LMXfAUj-
> IIph9kHUEeQtMM53xEVXtGRrZQCR4Z4bRcNTzPq3PJ1wJTD_
> jc0fbrg6zhbAs1sc5upKKbHaexk9SjlBDmUOMapCcAK9nc2WDoKgNac7IGwu
> nTJx6TuB9GVM5Tr-Uxgor1Q-TNGIxBowgGDj44QcnDLn6360t_
> upTuYGF6x4lGqh3it7M0umpzf5gNvL7XuzX5mJTF1UrF3mhT7Xv8HTiCcD6S
> nD4OdW0lMJjbccB91nrGhca_P-p8cxuB8Meuwfjd1MFNI9E3PhZWDyBx
> rIDst-2WlYNpXNl-pn/https%3A%2F%2Fwww-03.ibm.com%2Fsystems%
> 2Fz%2Fos%2Fzvse%2Fabout%2Fhistory1990s.html
>
> 2000's VSE History: https://secure-web.cisco.com/1YAJcM2hjsRtdB76Ykv4-
> xfcVxX9mZBM-miQiMaWZiMyZ5CwcfGZERmXiCP6s_bRp0VbwtNPwnK_
> gUaUXgvL5MWfDfO2Fc9kg9FdFAvDqjymGiE2jUwJSqstRmjZpfmhNHMkmIKG
> fG6ZOIiAvkZMpqJn4D0GCRpijfgGaJuMUgPYyl_C0-K-NtwR5KbO-
> N8z4adwawT6HykdeyvYnISd4Cu9p9jWhRKNSTQT25asdIhy205GoNcQabEg8
> lx04K9Db2vuNCB91OTLRWmkrY8Gvqr9sKYYpSsZnbvYkNfHj1Ae6kvKbEmjy
> fdFGiyaF4zBdS_RT7Q2FC_HUBRDCnCnZ7zL-zWqFJFJLlhrjV-
> lznxO0QO35QLDzewLgbPRAWnyc9c6cjha0fQSWkwOlQqt-B_
> xqfrKyP2v5VFaDncDLID5v49IBZzbP-chGTGQ9wkzU/https%3A%2F%
> 2Fwww-03.ibm.com%2Fsystems%2Fz%2Fos%2Fzvse%2Fabout%2Fhistory2000s.html
>
> 2010's VSE History: https://secure-web.cisco.com/1Exaa9ZQSTz7_
> WUzVgXvYovWsRd92i3gPMDwkcdr4IR4zKNZw8V5o5tQu1ZQrDQPf_
> cwB4nWBr-cCdZoQavq7_mmF5ll3-gHT8M7mZiJhzd-q5CNZIJgl1cyXJomO2RNjqTXKyIRsQ
> XYap2gbw5a5ml0Box3VuUH1-TAzNSYOdHC8LzPwjx9j8c-gsqnncH6C3pQ3_
> 4Q2zKDtrMjhzrtKsrw7kuLKHdDQ_FOUjXhM6fOZKPw5m8VQUT4Cq_5B-
> SAzxTyJP78bH4g4qiX1m0ViqOLzSMXtr4EYCBoOf93Y5y-
> YKUOmymTSOSv7MUUMiQajJAxZCJrifaQ6lGXNLGwH1MVguCKJX45unHgqFZa
> IoZNu3iohQCsZZc7RwdQtREdXZwF7qL-0FRqGxTGWHSHiw0XD65wCLSMX1YM8t
> aU7nnWVp_nE7dVqiSAtaeROMH6R/https%3A%2F%2Fwww-03.ibm.com%
> 

Re: 0C4 in IGGCSI00

[Wayne Bickerdike]

Our dev LPAR at IBM also works OK.

*** z/OS V2R2 - GA Code *

 Last Date   z/OS   CodeHOLDATA
 Changed Level  Level   DATE
 --  -  --- --
 2017/12/26  V2R2   PUT1709/RSU1711 2017/12/21

I guess that's no consolation Kirk :)

On Thu, Jan 18, 2018 at 10:30 AM, Wayne Bickerdike 
wrote:

> Don't see this problem on our system.
>
> z/os 2.2 RSU 1707
>
> On Thu, Jan 18, 2018 at 9:25 AM, Kirk Wolf  wrote:
>
>> If I pass an invalid filter key to IGGCSI00, I get an 0C4 in IGGCSI00.
>>
>> I don't see this on our normal z/OS V2R2 dev system; only on a zPDT
>> running
>> the ADCD Dec 2015 V2R2 build.   Both systems have LMOD IGGCSI00 at the
>> base
>> level HDZ2220.
>>
>> On the other V2R2 system I get back RC4/Reas122 (Invalid filter key),
>> which
>> is expected.
>>
>> Easily reproduced from either my code or the IBM REXX sample:
>>
>>
>> exec 'sys1.samplib(iggcsirx)'
>>
>>  ENTER FILTER KEY
>> *KIRK..FOO*
>>  IRX0250E System abend code 0C4, reason code 0004.
>>  IRX0255E Abend in host command IGGCSI00 or address environment routine
>> LINKPGM.
>>  IEA995I SYMPTOM DUMP OUTPUT
>>  SYSTEM COMPLETION CODE=0C4  REASON CODE=0004
>>   TIME=15.39.52  SEQ=00598  CPU=4000  ASID=0048
>>   PSW AT TIME OF ERROR  078C   84AA8420  ILC 4  INTC 04
>> NO ACTIVE MODULE FOUND - PRIMARY NOT EQUAL TO HOME
>> NAME=UNKNOWN
>> DATA AT PSW  04AA841A - 30005840  B7181824  5850B004
>> AR/GR 0: 001B/0004   1: /04AAA124
>>   2: /7F212000   3: /0080
>>   4: /7F243178   5: /0087DF98
>>   6: /7F2430C8   7: /7F243268
>>   8: /1F436000   9: /
>>   A: /04AAA100   B: /7F6C4000
>>   C: /D9C5E2E4   D: /7F243290
>>   E: /84AA8372   F: 0700/84AB49B8
>>   END OF SYMPTOM DUMP
>>  78 *-*  ADDRESS LINKPGM 'IGGCSI00  MODRSNRC  CSIFIELD  DWORK'
>> +++ RC(-196) +++
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
>
> --
> Wayne V. Bickerdike
>
>


-- 
Wayne V. Bickerdike

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

Re: 0C4 in IGGCSI00

[Wayne Bickerdike]

Don't see this problem on our system.

z/os 2.2 RSU 1707

On Thu, Jan 18, 2018 at 9:25 AM, Kirk Wolf  wrote:

> If I pass an invalid filter key to IGGCSI00, I get an 0C4 in IGGCSI00.
>
> I don't see this on our normal z/OS V2R2 dev system; only on a zPDT running
> the ADCD Dec 2015 V2R2 build.   Both systems have LMOD IGGCSI00 at the base
> level HDZ2220.
>
> On the other V2R2 system I get back RC4/Reas122 (Invalid filter key), which
> is expected.
>
> Easily reproduced from either my code or the IBM REXX sample:
>
>
> exec 'sys1.samplib(iggcsirx)'
>
>  ENTER FILTER KEY
> *KIRK..FOO*
>  IRX0250E System abend code 0C4, reason code 0004.
>  IRX0255E Abend in host command IGGCSI00 or address environment routine
> LINKPGM.
>  IEA995I SYMPTOM DUMP OUTPUT
>  SYSTEM COMPLETION CODE=0C4  REASON CODE=0004
>   TIME=15.39.52  SEQ=00598  CPU=4000  ASID=0048
>   PSW AT TIME OF ERROR  078C   84AA8420  ILC 4  INTC 04
> NO ACTIVE MODULE FOUND - PRIMARY NOT EQUAL TO HOME
> NAME=UNKNOWN
> DATA AT PSW  04AA841A - 30005840  B7181824  5850B004
> AR/GR 0: 001B/0004   1: /04AAA124
>   2: /7F212000   3: /0080
>   4: /7F243178   5: /0087DF98
>   6: /7F2430C8   7: /7F243268
>   8: /1F436000   9: /
>   A: /04AAA100   B: /7F6C4000
>   C: /D9C5E2E4   D: /7F243290
>   E: /84AA8372   F: 0700/84AB49B8
>   END OF SYMPTOM DUMP
>  78 *-*  ADDRESS LINKPGM 'IGGCSI00  MODRSNRC  CSIFIELD  DWORK'
> +++ RC(-196) +++
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Wayne V. Bickerdike

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

Re: PDSCLEAN issue

[Paul Gilmartin]

On Wed, 17 Jan 2018 16:20:28 -0600, Jeffrey Holst wrote:
>>
>As the manual DFSMS: Using Datasets notes:
>A PDSE member is not actually deleted while in use. Any program connected to
>the member when the delete occurs can continue to access the member until the
>data set is closed. This is called a deferred delete.
>
>In other words, as long as the dataset is open, the space occupied by the 
>member being deleted is not freed.
> 
Does BLDL RELEASE break the connection and allow the space to be freed
even before the data set is closed?  That's what I thought it said.

-- gil

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

0C4 in IGGCSI00

[Kirk Wolf]

If I pass an invalid filter key to IGGCSI00, I get an 0C4 in IGGCSI00.

I don't see this on our normal z/OS V2R2 dev system; only on a zPDT running
the ADCD Dec 2015 V2R2 build.   Both systems have LMOD IGGCSI00 at the base
level HDZ2220.

On the other V2R2 system I get back RC4/Reas122 (Invalid filter key), which
is expected.

Easily reproduced from either my code or the IBM REXX sample:


exec 'sys1.samplib(iggcsirx)'

 ENTER FILTER KEY
*KIRK..FOO*
 IRX0250E System abend code 0C4, reason code 0004.
 IRX0255E Abend in host command IGGCSI00 or address environment routine
LINKPGM.
 IEA995I SYMPTOM DUMP OUTPUT
 SYSTEM COMPLETION CODE=0C4  REASON CODE=0004
  TIME=15.39.52  SEQ=00598  CPU=4000  ASID=0048
  PSW AT TIME OF ERROR  078C   84AA8420  ILC 4  INTC 04
NO ACTIVE MODULE FOUND - PRIMARY NOT EQUAL TO HOME
NAME=UNKNOWN
DATA AT PSW  04AA841A - 30005840  B7181824  5850B004
AR/GR 0: 001B/0004   1: /04AAA124
  2: /7F212000   3: /0080
  4: /7F243178   5: /0087DF98
  6: /7F2430C8   7: /7F243268
  8: /1F436000   9: /
  A: /04AAA100   B: /7F6C4000
  C: /D9C5E2E4   D: /7F243290
  E: /84AA8372   F: 0700/84AB49B8
  END OF SYMPTOM DUMP
 78 *-*  ADDRESS LINKPGM 'IGGCSI00  MODRSNRC  CSIFIELD  DWORK'
+++ RC(-196) +++

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

Re: PDSCLEAN issue

[Jeffrey Holst]

On Tue, 16 Jan 2018 11:21:56 -0600, Paul Gilmartin  wrote:

>On Tue, 16 Jan 2018 16:08:49 +, Beesley, Paul wrote:
>
>>I have been using the PDSCLEAN program from the CBT tape file 693 for a while 
>> ...
>>...
>>The report says the PDSE has been cleared, and indeed there are 0 members, 
>>however an ISPF 3.4 display shows that the percentage used hasn’t gone down 
>>from the original 67% used. I tried the process on a copy of the PDSE and it 
>>worked fine … 0 members and 0% used. I can only assume it’s because LLA has 
>>hold of it or something.
>> 
>PDSE, in a form of work unit isolation, maintains a connection ("hold") on any 
>member
>for which BLDL (or DESERV?) has been done until it is released (by BLDL 
>RELEASE, IIRC).
>
>-- gil
>
As the manual DFSMS: Using Datasets notes:
A PDSE member is not actually deleted while in use. Any program connected to
the member when the delete occurs can continue to access the member until the
data set is closed. This is called a deferred delete.

In other words, as long as the dataset is open, the space occupied by the 
member being deleted is not freed.

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

Re: Finding the names of hsm's BCDSs

[Graham Harris]

Whilst you're waiting for IBM to deliver a proper API, you could trap the
console output from a F DFHSM,Q CDS.
DFHSM may well not be called DFHSM of course, so that will add a little
extra work, perhaps using an ISGQUERY on ARCENQG




On 17 January 2018 at 13:29, Manfred Lotz  wrote:

> On Wed, 17 Jan 2018 15:04:11 +0200
> ITschak Mugzach  wrote:
>
> > Can you tell about the languages you wish to use and if this code
> > runs on a server side or client (TSO, Batch).
> >
>
> Assembler. The program runs in TSO.
>
> --
> Manfred
>
>
> > ITschak
> >
> > On Wed, Jan 17, 2018 at 10:04 AM, Manfred Lotz 
> > wrote:
> >
> > > Hi there,
> > > I like to find out the DFSMShsm BCDS names programmatically.
> > >
> > > As I know the DD names, i.e. BAKCAT, and optionally BAKCAT2, BAKCAT3
> > > and BAKCAT4 I thought of using AR mode in order to get the TIOT of
> > > HSM.
> > >
> > > However, in order to get to the TIOT reliably I need SWAREQ which
> > > doesn't support AR mode.
> > >
> > > Is there a way to get access to another address space's TIOT?  Any
> > > ideas much appreciated.
> > >
> > > --
> > > Thanks a lot,
> > > Manfred Lotz
> > >
> > > --
> > > 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: [EXTERNAL] CBT Tape Version 495 has been cut

[Paul Gilmartin]

On Wed, 17 Jan 2018 14:11:02 -0600, John McKown wrote:

>On Wed, Jan 17, 2018 at 2:08 PM, R.S. wrote:
>>
>> Excuse me, what CBT stands for? Is it a name (acronym) of bank?
>>
>​Connecticut Bank and Trust.​
>
(More):  http://www.cbttape.org/cbtfaq.htm

-- gil

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

Re: [EXTERNAL] CBT Tape Version 495 has been cut

[Blake, Daniel J [CTR]]

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, January 17, 2018 3:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] CBT Tape Version 495 has been cut

W dniu 2018-01-17 o 17:33, Edward Finnell pisze:
>> Back in the olden days, we'd have to send Arnie a reel tape to get the 
>> updates.
>>
>>
>> http://www.cbtclub.org/fall-social-photos-2017.html
>>   
>> In a message dated 1/17/2018 6:11:36 AM Central Standard Time, 
>> lionel.d...@va.gov writes:
>>
>>   
>> Congratulations on another release. The site, and before that the tape, have 
>> been a great benefit to the mainframe community and your work is greatly 
>> appreciated.

> Excuse me, what CBT stands for? Is it a name (acronym) of bank?



-- 
Radoslaw Skorupka
Lodz, Poland

Yup, Connecticut Bank and Trust where Arnold Casinghino (SP?)  worked when he 
established it..  

Also could mean Cognitive Behavior Therapy 

;-D an





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

Re: [EXTERNAL] CBT Tape Version 495 has been cut

[John McKown]

On Wed, Jan 17, 2018 at 2:08 PM, R.S. 
wrote:

> W dniu 2018-01-17 o 17:33, Edward Finnell pisze:
>
>> Back in the olden days, we'd have to send Arnie a reel tape to get the
>> updates.
>>
>>
>> http://www.cbtclub.org/fall-social-photos-2017.html
>>   In a message dated 1/17/2018 6:11:36 AM Central Standard Time,
>> lionel.d...@va.gov writes:
>>
>>   Congratulations on another release. The site, and before that the tape,
>> have been a great benefit to the mainframe community and your work is
>> greatly appreciated.
>>
>
> Excuse me, what CBT stands for? Is it a name (acronym) of bank?
>

​Connecticut Bank and Trust.​



>
> --
> Radoslaw Skorupka
> Lodz, Poland
>

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

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: Please Read: Server Certificates Expiring - Soon!

[Cieri, Anthony]

Please pardon the interruption for a brief comment. 

In case it is not completely obvious, the Digicert acquisition of the  
Geotrust CA also affects Verisign certificates. We have already encountered 
this issue (last week) with another business partner that used a certificate 
signed by a Verisign CA. When they renewed their cert, it was now signed by a 
Digicent CA, thus requiring us to ADD a new CA certificate in order to maintain 
the sessions.

If you or a business partner are using Verisign certs, you might see 
this issue again..

Hth
Tony

 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: Tuesday, January 16, 2018 7:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Please Read: Server Certificates Expiring - Soon!

On 1/16/2018 4:21 PM, John Eells wrote:
> Tom Conley wrote:
>> On 1/16/2018 2:47 PM, John Eells wrote:
>>> Jousma, David wrote:
 WSC has published!
 http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH1
 0884
>>>
>>> Indeed, and you beat me to it!  Many thanks for Kurt Quackenbush for 
>>> writing it, and Riaz Ahmad for getting it formatted as a Flash and 
>>> getting it posted to the WSC's website.
>>>
>>
>> I've only had the problem since 1/11/18.  Good to know the alert is 
>> out
>> 5 days later, g...
>>
> 
> The storied West Point and Officer's Candidate School response to "Why 
> did you make that mistake?" is appropriate here: "No excuse, sir."
> 
> On behalf of IBM, I apologize to all for the late notification.
> 
> Going forward, we are trying hard to make sure we understand and 
> communicate all the impacts as rapidly as we can.  The team that 
> maintains the servers will probably replace the server certificates 
> that expire in May some time in April.  Thus far, we know of no 
> impacts before April, but that's not yet any guarantee there will be 
> none before that date.
> 

The moral of the story is to update your CA certs ASAP per the instructions in 
the Alert.  I followed the directions to reinstall the new CA cert and viola!  
RECEIVE ORDER began to work again, as if by magic!

Regards,
Tom Conley

--
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: [EXTERNAL] CBT Tape Version 495 has been cut

[R.S.]

W dniu 2018-01-17 o 17:33, Edward Finnell pisze:

Back in the olden days, we'd have to send Arnie a reel tape to get the updates.


http://www.cbtclub.org/fall-social-photos-2017.html
  
In a message dated 1/17/2018 6:11:36 AM Central Standard Time, lionel.d...@va.gov writes:


  
Congratulations on another release. The site, and before that the tape, have been a great benefit to the mainframe community and your work is greatly appreciated.


Excuse me, what CBT stands for? Is it a name (acronym) of bank?

--
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.plsą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.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Re: AW: Re: IEFA111I at IPL Time for z/OS V2.3

[Scott Ballentine]

That's correct - the IEFA111I message is intended to be information to help 
debug a job that didn't behave as expected.  It's issued when a job has 
MSGLEVEL=(,1) in effect.

I've arranged to have the System Messages documentation updated.

-Scott Ballentine (sbal...@us.ibm.com)
 z/OS Allocation, SMF, Scheduler Development

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

Re: Are Mainframes a Security Risk? | Enterprise Systems Media

[Seymour J Metz]

Good hardware and good software don't ensure security, but they make it easier. 
Note that I wrote "easier", not "easy". There is no substitute for good 
management.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Clark Morris 
Sent: Tuesday, January 16, 2018 4:44 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Are Mainframes a Security Risk? | Enterprise Systems Media

[Default] On 16 Jan 2018 10:06:05 -0800, in bit.listserv.ibm-main
sme...@gmu.edu (Seymour J Metz) wrote:

>The text blaming z/OS for inept security management is bad enough, but  I 
>found "In fact, it can be difficult to get a lot of documentation on how 
>mainframes work online" to be truly precious.


IBM documentation is voluminous but if a shop isn't staffed with
people who read and understand the necessary manuals, security will
stink.  It also isn't enough to have a secure operating system.  It
must be properly configured.  The applications have to be written with
security in mind.  The organization must make sure its employees
understand the need for security and follow good practices.  The
vulnerability can be in a web-server or improperly secured networks.
>From what little I have read here, I am still wondering if zIIP and
zAAp  processors present a security risk and if I understand it
correctly that zIIP and zAAP code runs under an SRB.  In addition the
devices that connect to the mainframe can be a security hole.

In short, my belief is that the organizations approach to security
probably matters more the operating system and hardware chosen.

Clark Morris

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

VSE timeline [was: RE: VSAM usage for ancient disk models]

[Farley, Peter x23353]

On this Wikipedia page, notes #44 and #45 lead to IBM z/VSE history pages that 
may tell you what you want to know.

https://en.wikipedia.org/wiki/History_of_IBM_mainframe_operating_systems#DOS/VS

1980's VSE history: 
https://www-03.ibm.com/systems/z/os/zvse/about/history1980s.html

1990's VSE history: 
https://www-03.ibm.com/systems/z/os/zvse/about/history1990s.html

2000's VSE History: 
https://www-03.ibm.com/systems/z/os/zvse/about/history2000s.html

2010's VSE History: 
https://www-03.ibm.com/systems/z/os/zvse/about/history2010s.html

Each of the IBM pages has a link to the next decade's history page, so you can 
start with the 1980's page and proceed to the others in sequence.

I didn't read all the IBM pages closely, but I didn't see VSE/AF jump out.  Was 
that actually a version?

ECPS:VSE was a hardware feature on the 43xx machines (I know for sure it was on 
the 4361, not sure about other models).  IIRC it provided microcode assists for 
VSE under VM.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Wednesday, January 17, 2018 12:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VSAM usage for ancient disk models

Of course I remember the 3310, although I never used one. But your post reminds 
me of a question.

Does anybody have a VSE timeline from the original DOS/VSE and ECPS:VSE that 
includes all of the packages, e.g., VSE/AF? There's a wike article on VSE and 
I'd like to flesh that out, or, better, put someone up to doing so.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Wednesday, January 17, 2018 11:10 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: VSAM usage for ancient disk models

The 3090 processor controllers ran VM/370 on 3370 (FBA) disks.  I was able to 
actually see one of these at a large NYC shop in the 1990's while touring it 
with a friend who was the VP of Operations there.  The 3270 screen inside the 
3090 box had the VM/370 screen logo.

That made my day.  I was a VM/VSE guy at the time and really resented the way 
that MVS shops looked down on us, as if we were deprived, backwards children.

And you are right, the 3375's were 3370 boxes that emulated CKD on physical FBA 
geometry.

Anyone remember 3310's?  Smaller FBA brothers of the 3370 DASD, sold with 4331 
low-end CPU's for VM/VSE usage.  There was a special VSE version created in the 
mid 1980's (SSX/VSE) with simplified and largely menu-driven system generation 
and maintenance intended for sale with those low-end 4331 systems.  The ISV I 
worked at then got to play with SSX/VSE to set up our product for menu-driven 
installation on one of those systems.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Wednesday, January 17, 2018 9:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VSAM usage for ancient disk models

Current (for us 2.1)  z/OS HCD still shows 3375 as a valid DASD device type.   
IIRC  3375 was emulated CKD on FBA 3370 HDA's.   I also think 3375s were used 
as the storage for the embedded 43X1's used as processor controllers on 3090s.

Dana
--

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: VSAM usage for ancient disk models

[Seymour J Metz]

MVS never supported the 3310 or 3370, but it supported the 3375 early on.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Edward Gould 
Sent: Tuesday, January 16, 2018 8:43 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: VSAM usage for ancient disk models

> On Jan 16, 2018, at 5:06 PM, Alan Young  wrote:
>
> Not sure how far you want to go back, but take a look at MVS/DFP V3R3 Device 
> Support Reference on 
> http://secure-web.cisco.com/1uUD1rtAnzS9A_dPmffUPXp3BIfGTsSozdC-ATOwDiAQ4oZvvcygg31UADKo0Hrh76gfTuJ8tUslGpTvXPZ5L-Er_2n7xVRi3kGTpOEnFHnLnoNt9Jq4d66uwNGRpTlAOz-BRCiYH9MwLeIHiAE5fLh2bLXWDV4GxDhNKBjj-AHbE2fvQNn5GNTY93V53AUUkkIK_aVPTbeVB_dlnuFUcVwG72qF-6adpXOosE8RdooMmIWpyGhbtuz3dNy1IkW3KzWLZO19dcrUDyroS8pJvQk7ANXXltSX6FRnaxXPBZ91aErv9dkwTBY5T8QoOq575OCFE0mfB2n-ixm65cUuXCijdWVi7k2wSRTz96zO4lSa4iuSmgUCNDOkajxgF2BYoarBInaIM9zE6-AlkwbelvLJQdTJfR4r0CFmSDi4Zs39MU3z4mrv-1WNMGUbbSpbx/http%3A%2F%2Fpublibz.boulder.ibm.com%2Fcgi-bin%2Fbookmgr_OS390%2Flibrary
>  
> 
>  . Section 4.9 - VSAM Usage of Space for Selected Devices has 2305-2, 3330, 
> 3340/3344, 3350, 3375, 3380, 3390 and 9345. The direct link to the section is 
> http://secure-web.cisco.com/1Hydq1L7JX6mHxkVG66pO4WD6sDBghraJsDKAkOFHKTxNR1P7tyCZ8FvsZjJ6sB1iRozTzTY9Bm1Q7oCUau2q7V-0ZtqdwwCHI_GduNzKKXEu80-UxwFG_mijI4LHlJmH92DJ8EcNUexX2B3PdRHX0txk-JOsUqFt1bR0Xd28mTUtMdM5m7WLo7ed8Clo-ttLQgscxHDqXqVv8P_68YAjKYOEIynBDJlrfGuu3Lv2LgJcENL12-SMzP5AMwASO397sOf6RsGiPn_cR1bYUCUE1uo-ArDtkfrfxZem-RUcDOQ1ULdEXA0p2IIeJuJCF15ZjThPXb68OX2lO9BA5hxqf1E-NdScWxYI3Vs0NqsyrPloFXaRyVCefXBmPdGxQVbYNmsaPfmQWHPRsiwEO66GXjMgbMro7Bby9fgmT_ysf6-VqdewaZjTT9AdFNbm65No/http%3A%2F%2Fpublibz.boulder.ibm.com%2Fcgi-bin%2Fbookmgr_OS390%2FBOOKS%2FIGG3H101%2F4.9%3FDT%3D19930625100219
>  
> 
>
> Alan

Alan:

I honestly cannot remember MVS *EVER* supporting 3375’s  DOS/VSE and VM AFAIK 
are the only OS’s. Can someone correct me please ?

Ed


--
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: VSAM usage for ancient disk models

[Seymour J Metz]

Of course I remember the 3310, although I never used one. But your post reminds 
me of a question.

Does anybody have a VSE timeline from the original DOS/VSE and ECPS:VSE that 
includes all of the packages, e.g., VSE/AF? There's a wike article on VSE and 
I'd like to flesh that out, or, better, put someone up to doing so.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Farley, Peter x23353 
Sent: Wednesday, January 17, 2018 11:10 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: VSAM usage for ancient disk models

The 3090 processor controllers ran VM/370 on 3370 (FBA) disks.  I was able to 
actually see one of these at a large NYC shop in the 1990's while touring it 
with a friend who was the VP of Operations there.  The 3270 screen inside the 
3090 box had the VM/370 screen logo.

That made my day.  I was a VM/VSE guy at the time and really resented the way 
that MVS shops looked down on us, as if we were deprived, backwards children.

And you are right, the 3375's were 3370 boxes that emulated CKD on physical FBA 
geometry.

Anyone remember 3310's?  Smaller FBA brothers of the 3370 DASD, sold with 4331 
low-end CPU's for VM/VSE usage.  There was a special VSE version created in the 
mid 1980's (SSX/VSE) with simplified and largely menu-driven system generation 
and maintenance intended for sale with those low-end 4331 systems.  The ISV I 
worked at then got to play with SSX/VSE to set up our product for menu-driven 
installation on one of those systems.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Wednesday, January 17, 2018 9:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VSAM usage for ancient disk models

Current (for us 2.1)  z/OS HCD still shows 3375 as a valid DASD device type.   
IIRC  3375 was emulated CKD on FBA 3370 HDA's.   I also think 3375s were used 
as the storage for the embedded 43X1's used as processor controllers on 3090s.

Dana
--


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

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

Re: [EXTERNAL] CBT Tape Version 495 has been cut

[Edward Finnell]

Back in the olden days, we'd have to send Arnie a reel tape to get the updates.


http://www.cbtclub.org/fall-social-photos-2017.html
 
In a message dated 1/17/2018 6:11:36 AM Central Standard Time, 
lionel.d...@va.gov writes:

 
Congratulations on another release. The site, and before that the tape, have 
been a great benefit to the mainframe community and your work is greatly 
appreciated.

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

Re: VSAM usage for ancient disk models

[Farley, Peter x23353]

The 3090 processor controllers ran VM/370 on 3370 (FBA) disks.  I was able to 
actually see one of these at a large NYC shop in the 1990's while touring it 
with a friend who was the VP of Operations there.  The 3270 screen inside the 
3090 box had the VM/370 screen logo.

That made my day.  I was a VM/VSE guy at the time and really resented the way 
that MVS shops looked down on us, as if we were deprived, backwards children.

And you are right, the 3375's were 3370 boxes that emulated CKD on physical FBA 
geometry.

Anyone remember 3310's?  Smaller FBA brothers of the 3370 DASD, sold with 4331 
low-end CPU's for VM/VSE usage.  There was a special VSE version created in the 
mid 1980's (SSX/VSE) with simplified and largely menu-driven system generation 
and maintenance intended for sale with those low-end 4331 systems.  The ISV I 
worked at then got to play with SSX/VSE to set up our product for menu-driven 
installation on one of those systems.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Wednesday, January 17, 2018 9:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VSAM usage for ancient disk models

Current (for us 2.1)  z/OS HCD still shows 3375 as a valid DASD device type.   
IIRC  3375 was emulated CKD on FBA 3370 HDA's.   I also think 3375s were used 
as the storage for the embedded 43X1's used as processor controllers on 3090s.

Dana
--


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: VSAM usage for ancient disk models

[Anne & Lynn Wheeler]

mitchd...@gmail.com (Dana Mitchell) writes:
> Current (for us 2.1) z/OS HCD still shows 3375 as a valid DASD device
> type.  IIRC 3375 was emulated CKD on FBA 3370 HDA's.  I also think
> 3375s were used as the storage for the embedded 43X1's used as
> processor controllers on 3090s.

re:
http://www.garlic.com/~lynn/2018.html#41 VSAM usage for ancient disk models

FEs had bootstrap service process ... starting with incrementally
scoping for dignoses for failed component. 3081 had circuits enclosed in
TCMs ... no longer capable of scoping. Went to "service processor" (with
3310 FBA disk) that could be scoped/diagnosed and then used to analyze
large number of probes embedded in TCMs.

Original move to 3090 was going to be 4331 running customized version of
VM370 Release 6 for service processor (with 3370 disk, instead of RYO
primitive customized operating system done from scratch) and all service
screens done in CMS IOS3270 ... this was upgraded to pair of (redundant)
4361s for "3092"
https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3090.html

In addition, the 3092 processor controller requires two IBM 3370 model
A2 direct access storage devices with string switches or equivalent. The
3092 requires access to a customer-supplied 3420 model 4, 6 or 8 tape
drive or equivalent.

... snip ...

trivia: I had wanted to show that REXX (before customer release,
originally just REX) wasn't just another pretty scripting language ...
I decided on demo'ing that I could redo IPCS (very large assembler
application) in less than 3months elapsed time working half time with
ten times the function and running ten times faster (some slight of hand
for REXX to run faster than assembler). I finished early so started
doing library of automated scripts that searched/analyzed for lots of
different kind of failure signatures. I had expected that it would be
released to customers ... but for some reason it wasn't, even tho it
became standard for internal datacenters and customer support PSRs. Some
old email from the 3092 group wanting to include it
http://www.garlic.com/~lynn/2010e.html#email861031
http://www.garlic.com/~lynn/2010e.html#email861223

Eventually I got approval for making presentations at SHARE and other
customer user group meetings on how I implemented it .. and within a few
months similar implementations started to appear. As an aside the
implementation included functions like formating storage segments using
maclib DSECTs and decompiling instruction sequences ... and this was in
the "OCO-wars" (object code only) ... transition to no longer shipping
source code. past posts
http://www.garlic.com/~lynn/submain.html#dumprx

other trivia: this is old "greencard" done in IOS3270 with q
conversion to html:
http://www.garlic.com/~lynn/gcard.html

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: VSAM usage for ancient disk models

[Dana Mitchell]

Current (for us 2.1)  z/OS HCD still shows 3375 as a valid DASD device type.   
IIRC  3375 was emulated CKD on FBA 3370 HDA's.   I also think 3375s were used 
as the storage for the embedded 43X1's used as processor controllers on 3090s.

Dana

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

Re: PDSCLEAN issue

[Beesley, Paul]

No, Allan is right. LNKLST can include PDSE datasets but they seem to be 
managed differently to those added after IPL. They can't be deleted even after 
going through the Linklist unallocate palaver, and it seems they can't be 
emptied effectively.

BTW, someone suggested DELETE PDSE(*) but that doesn't work for Linklist 
datasets as they are in use by LLA (although I haven't tried stopping LLA)

Regards and thanks
Paul

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Wednesday, January 17, 2018 1:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDSCLEAN issue

On Tue, 16 Jan 2018 16:25:40 +, Allan Staller wrote:

>The only restriction I am aware of is that the PDSE cannot be in the IPL time 
>LINKLIST.

I think you mean LPA. LNKLST can include PDSE data sets.

--
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading 
names used by the Atos group. The following trading entities are registered in 
England and Wales: Atos IT Services UK Limited (registered number 01245534), 
Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited 
(registered number 08514184) and Canopy The Open Cloud Company Limited 
(registration number 08011902). The registered office for each is at 4 Triton 
Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for 
the addressee, and may contain confidential or privileged information. If you 
receive this e-mail in error, you are not authorised to copy, disclose, use or 
retain it. Please notify the sender immediately and delete this email from your 
systems. As emails may be intercepted, amended or lost, they are not secure. 
Atos therefore can accept no liability for any errors or their content. 
Although Atos endeavours to maintain a virus-free network, we do not warrant 
that this transmission is virus-free and can accept no liability for any 
damages resulting from any virus transmitted. The risks are deemed to be 
accepted by everyone who communicates with Atos by email.

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

Re: VSAM Performance - CPU reduction

[Peter Vander Woude]

Arun,

In the IDCAMS listing, I see that the files are defined NONSPANNED.  With the 
records being variable length, you could have as few as 2 records per ci, since 
the max is around 11000.  if all the records are the minimum of 170, then you 
would have around 156 records per ci.

Have you looked at changing NONSPANNED to SPANNED?  That will allow variable 
length records to go across CI's, and might help in some small way, by 
decreasing the actual space that the files use up.  As such the # of records 
read in, as defined by the BUFND, will be higher.

for the skip sequential file, if you are doing a point and then read next, what 
is the average number of records that are being processed?  Having the BUFND so 
high, if it's only processing a few records in the data component, then you are 
reading in, and spending higher cpu time, just to throw away those records and 
read in the next set of ci's.  Anytime you reduce the BUFND, of course your 
EXCP's will go up, as VSAM I/O counts are the number of times it had to read a 
group of ci's, as opposed to sequential files, where each block counts as an 
I/O, no matter what BUFNO is set to.

Peter

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

Re: running os/vs cobol in CICS 5.3 with DB2

[Rob Schramm]

Tim,

I am looking for the QDM (quick and dirty method) to pull a shop into a
more supported OS.  There is no appetite for reworking code to accommodate
the new COBOL.  If we were actually able to run on something newer, there
might be path for a small section of apps to go thru actual conversion.

Rob

On Thu, Jan 11, 2018 at 7:14 AM Timothy Sipples  wrote:

> A couple quick comments from me:
>
> 1. IBM eliminated Single Version Charge (SVC) time limits. If, for example,
> you have an OS/VS COBOL application that's still lagging behind, you could
> keep a CICS Transaction Server 2.3 AOR running it until you can get it
> pulled forward, and surround that laggard AOR with CICS Transaction Server
> 5.3 (or better yet 5.4) regions for everything else you run. CICS TS 2.3,
> the last release that supported OS/VS COBOL applications, has reached End
> of Service, of course. So has OS/VS COBOL for that matter. However, CICS
> has long supported freely intermixing interoperating releases, unless
> exceptionally documented otherwise. And there shouldn't be any financial
> obstacle in doing that now.
>
> 2. It's nearly certain you're taking a longer path length through the OS/VS
> COBOL execution versus an optimized Enterprise COBOL Version 6 alternative
> reality. Try to make the trek if you can, as soon as you can. There's
> considerable reward in that, especially if this OS/VS COBOL code is either
> contributing to your monthly peak 4HRA utilization, or if it is elongating
> your batch execution time when your batch execution time is your peak
> demand driver.
>
> 3. If the problem is that you lost the source code, reasonable source
> recovery might be possible. (There are some previous discussions about
> that.)
>
>
> 
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM Z and LinuxONE, AP/GCG/MEA
> E-Mail: sipp...@sg.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 

Rob Schramm

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

Re: Finding the names of hsm's BCDSs

[Manfred Lotz]

On Wed, 17 Jan 2018 15:04:11 +0200
ITschak Mugzach  wrote:

> Can you tell about the languages you wish to use and if this code
> runs on a server side or client (TSO, Batch).
> 

Assembler. The program runs in TSO.

-- 
Manfred


> ITschak
> 
> On Wed, Jan 17, 2018 at 10:04 AM, Manfred Lotz 
> wrote:
> 
> > Hi there,
> > I like to find out the DFSMShsm BCDS names programmatically.
> >
> > As I know the DD names, i.e. BAKCAT, and optionally BAKCAT2, BAKCAT3
> > and BAKCAT4 I thought of using AR mode in order to get the TIOT of
> > HSM.
> >
> > However, in order to get to the TIOT reliably I need SWAREQ which
> > doesn't support AR mode.
> >
> > Is there a way to get access to another address space's TIOT?  Any
> > ideas much appreciated.
> >
> > --
> > Thanks a lot,
> > Manfred Lotz
> >
> > --
> > 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: PDSCLEAN issue

[Tom Marchant]

On Tue, 16 Jan 2018 16:25:40 +, Allan Staller wrote:

>The only restriction I am aware of is that the PDSE cannot be in the IPL time 
>LINKLIST.

I think you mean LPA. LNKLST can include PDSE data sets.

-- 
Tom Marchant

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

Re: Finding the names of hsm's BCDSs

[ITschak Mugzach]

Can you tell about the languages you wish to use and if this code runs on a
server side or client (TSO, Batch).

ITschak

On Wed, Jan 17, 2018 at 10:04 AM, Manfred Lotz  wrote:

> Hi there,
> I like to find out the DFSMShsm BCDS names programmatically.
>
> As I know the DD names, i.e. BAKCAT, and optionally BAKCAT2, BAKCAT3
> and BAKCAT4 I thought of using AR mode in order to get the TIOT of HSM.
>
> However, in order to get to the TIOT reliably I need SWAREQ which
> doesn't support AR mode.
>
> Is there a way to get access to another address space's TIOT?  Any
> ideas much appreciated.
>
> --
> Thanks a lot,
> Manfred Lotz
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: [EXTERNAL] CBT Tape Version 495 has been cut

[PINION, RICHARD W.]

I second that!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Wednesday, January 17, 2018 7:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] CBT Tape Version 495 has been cut

[External Email]

Congratulations on another release. The site, and before that the tape, have 
been a great benefit to the mainframe community and your work is greatly 
appreciated.

--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sam Golob
Sent: Tuesday, January 16, 2018 9:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] CBT Tape Version 495 has been cut

Hi Folks,

 The CBT Tape Version 495 has been cut (finally).  There have been over 60 
file changes made since the last version was cut last March.  I believe that 
this is the single biggest increment in changes between file versions.

 The tape was cut yesterday, and the website updates were made today.

 Please look at the Changes section in the "CBT page", to see all the 
changes.

 Please also note that my sbgo...@attglobal.net email address has gone away 
irrevocably, and I can not retrieve any messages sent to there.  Please use 
sbgo...@cbttape.org to contact me, or alternatively, sbgo...@att.net.

 Use the materials safely, and in good health and happiness. All the 
contributors hope they will make your working life easier.

 All the best of everything to all of you.

Sincerely, Sam

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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Re: Finding the names of hsm's BCDSs

[Manfred Lotz]

On Wed, 17 Jan 2018 12:01:22 +
Rob Scott  wrote:

> In the meantime, you could try and come up with a safer local
> solution based around using ISGQUERY for the SYSDSN major name
> enqueues for the HSM address space.
> 
> Depending on local naming standards you could probably spot the BCDS
> dataset names from the list returned by ISGQUERY.

I don't want to rely on naming standards as as possible solution could
be used on systems where I don't know the naming standards in advance.

-- 
Manfred

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

Re: [EXTERNAL] CBT Tape Version 495 has been cut

[Dyck, Lionel B. (TRA)]

Congratulations on another release. The site, and before that the tape, have 
been a great benefit to the mainframe community and your work is greatly 
appreciated.

--
Lionel B. Dyck <
Mainframe Systems Programmer - TRA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sam Golob
Sent: Tuesday, January 16, 2018 9:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] CBT Tape Version 495 has been cut

Hi Folks,

     The CBT Tape Version 495 has been cut (finally).  There have been over 60 
file changes made since the last version was cut last March.  I believe that 
this is the single biggest increment in changes between file versions.

     The tape was cut yesterday, and the website updates were made today.

     Please look at the Changes section in the "CBT page", to see all the 
changes.

     Please also note that my sbgo...@attglobal.net email address has gone away 
irrevocably, and I can not retrieve any messages sent to there.  Please use 
sbgo...@cbttape.org to contact me, or alternatively, sbgo...@att.net.

     Use the materials safely, and in good health and happiness. All the 
contributors hope they will make your working life easier.

     All the best of everything to all of you.

Sincerely, Sam

--
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: curious: Popularity & use of C on z/OS.

[David Crayford]

On 17/01/2018 3:19 AM, Paul Gilmartin wrote:

On Tue, 16 Jan 2018 18:51:55 +, Seymour J Metz wrote:


That's a common beginners' mistake. Try putting the label inside a do block and see 
what happens. A proper goto would pop what needs to be popped and no more. See 
.


Yes.

There I also read:
 Continuation
 REXX allows implicit continuation; a statement is treated as continued 
if it
 would otherwise be syntactically invalid.  ...
???
Not in any Rexx I know.  Is this perhaps a peculiarity of OS/2 Rexx?

And C has an improper GOTO.  It allows branching into a block.  It's 
implementation
dependent whether initializations are performed then.  Ugh!


If you don't like those semantics don't use goto. My ROT is to only use 
goto for branching to error handlers or cleanup routines.


If you look at the Linux kernel code including s390 you will see lots of 
goto statements used just for that purpose. It's amusing to read threads 
about what the maintainers think about this subject 
http://koblents.com/Ches/Links/Month-Mar-2013/20-Using-Goto-in-Linux-Kernel-Code/.




___

From: Jack J. Woehr
Sent: Sunday, January 14, 2018 3:40 PM

On 1/14/2018 11:35 AM, Seymour J Metz wrote:

REXX doesn't have a goto

Sure it does: SIGNAL

-- 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: Finding the names of hsm's BCDSs

[Rob Scott]

Writing SRBs to sniff private storage data in another address space is not for 
the faint-hearted.

It can be done, however it is very easy to do it incorrectly or in an unsafe 
manner.

AR-Mode access to the foreign address space (HSM) is a big no-no - you are 
breaking system integrity rules and besides it will only work if the address 
space is non-swappable or the storage is currently swapped in.

So - what is a sensible programmer to do?

First of all, ask IBM for a supported HSM Query API to return the information 
you require - a proper API not just some lame TSO TPUT thing that you have to 
screen-scrape.

I realise that any new API resolution will take a few years to hit the streets, 
however if no-one asks then there are no RFEs presented to the developers.

In the meantime, you could try and come up with a safer local solution based 
around using ISGQUERY for the SYSDSN major name enqueues for the HSM address 
space.

Depending on local naming standards you could probably spot the BCDS dataset 
names from the list returned by ISGQUERY.

Rob Scott
Rocket Software



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Manfred Lotz
Sent: Wednesday, January 17, 2018 8:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Finding the names of hsm's BCDSs

Hi there,
I like to find out the DFSMShsm BCDS names programmatically.

As I know the DD names, i.e. BAKCAT, and optionally BAKCAT2, BAKCAT3 and 
BAKCAT4 I thought of using AR mode in order to get the TIOT of HSM.

However, in order to get to the TIOT reliably I need SWAREQ which doesn't 
support AR mode.

Is there a way to get access to another address space's TIOT?  Any ideas much 
appreciated.

--
Thanks a lot,
Manfred Lotz

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

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: Finding the names of hsm's BCDSs

[Binyamin Dissen]

On Wed, 17 Jan 2018 09:04:18 +0100 Manfred Lotz  wrote:

:>I like to find out the DFSMShsm BCDS names programmatically. 

:>As I know the DD names, i.e. BAKCAT, and optionally BAKCAT2, BAKCAT3
:>and BAKCAT4 I thought of using AR mode in order to get the TIOT of HSM. 

:>However, in order to get to the TIOT reliably I need SWAREQ which
:>doesn't support AR mode. 

:>Is there a way to get access to another address space's TIOT?  Any
:>ideas much appreciated.

Standard way would be via SRB.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: Are Mainframes a Security Risk? | Enterprise Systems Media

[ITschak Mugzach]

sorry to interfere, but there are compliance tools to help you find the gap
between vendor requirements and reality. IBM, Vanguard, CA and of course us
has tools. We just automated the process of compliance checks and send the
results from many so called legacy systems to a single server, so the
process is completely human free. have a look at www.securiteam.co.il.

ITschak

On Tue, Jan 16, 2018 at 11:44 PM, Clark Morris 
wrote:

> [Default] On 16 Jan 2018 10:06:05 -0800, in bit.listserv.ibm-main
> sme...@gmu.edu (Seymour J Metz) wrote:
>
> >The text blaming z/OS for inept security management is bad enough, but  I
> found "In fact, it can be difficult to get a lot of documentation on how
> mainframes work online" to be truly precious.
>
>
> IBM documentation is voluminous but if a shop isn't staffed with
> people who read and understand the necessary manuals, security will
> stink.  It also isn't enough to have a secure operating system.  It
> must be properly configured.  The applications have to be written with
> security in mind.  The organization must make sure its employees
> understand the need for security and follow good practices.  The
> vulnerability can be in a web-server or improperly secured networks.
> From what little I have read here, I am still wondering if zIIP and
> zAAp  processors present a security risk and if I understand it
> correctly that zIIP and zAAP code runs under an SRB.  In addition the
> devices that connect to the mainframe can be a security hole.
>
> In short, my belief is that the organizations approach to security
> probably matters more the operating system and hardware chosen.
>
> Clark Morris
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Finding the names of hsm's BCDSs

[Manfred Lotz]

Hi there,
I like to find out the DFSMShsm BCDS names programmatically. 

As I know the DD names, i.e. BAKCAT, and optionally BAKCAT2, BAKCAT3
and BAKCAT4 I thought of using AR mode in order to get the TIOT of HSM. 

However, in order to get to the TIOT reliably I need SWAREQ which
doesn't support AR mode. 

Is there a way to get access to another address space's TIOT?  Any
ideas much appreciated.

-- 
Thanks a lot,
Manfred Lotz

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

Re: [EXTERNAL] Re: Please Read: Server Certificates Expiring - Soon!

[Sankaranarayanan, Vignesh]

Is there a way to subscribe to TechDocs?
Some of them are really fun to read.

A feed to https://www-03.ibm.com/support/techdocs/atsmastr.nsf/Web/TD-ByDate 
would be great! Can be made a part of the 'My Notifications' maybe..?

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: 16 January 2018 19:17
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Please Read: Server Certificates Expiring - Soon!

WSC has published!  
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10884

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Monday, January 15, 2018 8:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Please Read: Server Certificates Expiring - Soon!

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

Last week, one of the RECEIVE ORDER server certificates expired.  The other IBM 
servers you use for getting products and service, and those for the testcase, 
ecurep, and Blue Diamond servers will also expire over the next several months.

Normally, impending expiration is not be a big deal; IBM just gets new 
certificates ahead of the expiration dates, and you never notice.
However, as I understand it, DigiCert acquired GeoTrust.  All the IBM server 
certificates in question are GeoTrust certificates.  There is rather more to 
the story, but the net is that IBM will replace all its GeoTrust certificates 
with new ones from DigiCert.  This has already been done for one RECEIVE ORDER 
server, eccgw02.rochester.ibm.com.  The GeoTrust CA certificate will no longer 
work with this server.

To continue to use the servers as the certificates are replaced with new ones 
from DigiCert, you will need to get and install a new DigiCert Global Root CA 
certificate.

If you use the eccgw02.rochester.ibm.com RECEIVE order server, you can buy some 
time by using eccgw01.boulder.ibm.com instead until you get the new CA 
certificate.

Look for a WSC Flash later today (I hope) with more-detailed information and 
instructions.  We will update it as we learn more, but the next deadline is 
some time in April, when we are likely to replace additional server 
certificates.  As I understand it, they must all be done by August.

We believe the required action, to get and install a new DigiCert Global Root 
CA certificate, will not change.  My recommendation is that you start the 
process to do that soon so that you do not lose access to the IBM servers.

--
John Eells
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 **CAUTION EXTERNAL 
EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

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

MARKSANDSPENCER.COM

 Unless otherwise stated above:
Marks and Spencer plc
Registered Office:
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know 
and then delete it from your system; you should not copy, disclose, or 
distribute its contents to anyone nor act in reliance on this e-mail, as this 
is prohibited and may be unlawful.

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

Re: DFSORT for HTTP logs - RECFM and BLKSiZE?

[Peter Hunkeler]

>I do believe that I should be able to point DFSORT at any file (Unix or not) 
>where performing  the functions of DFSORT make sense, and not be required to 
>specify in JCL the physical attributes of LRECL, RECFM and most especially 
>BLKSIZE. These should all be derivable from the physical dataset at open time.



When accessing a z/OS UNIX file with JCL PATH allocation,  OPEN will setup 
everything to read the data from the file system and return it as if it was a 
data set record when READing thereafter.


The difficulty for this process is to invent RECFM, LRECL, and BLKSIZE, because 
all of this is unknown to a UNIX file. How would OPEN know whether all 
"records" in the file are of same length without reading the whole file, so it 
can set RECFM=F? How would OPEN know how long the longest record is without 
reading the whole file, so it can set LRECL?


DFSMS Using Data Set says the defaults are: RECFM=U, LRECL=80, BLKSIZE=80. So 
it is up to the program to setup the DCB as expected, or to specify all of this 
in JCL (or SVC99).


Just my $0.02


--
Peter Hunkeler

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