360 model 20 restoration

[Phil Smith III]

https://ibms360.co.uk/?page_id=22

 

Apologies if this has been here already-if so, I missed it.


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

Re: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E

[Steve Smith]

I got attention processing mixed up with something else.  TSO shouldn't
normally kill the command on an attention.

S13E & S33E are "normal" in many cases (outside of TSO - I'm not sure
within TSO), as it's sometimes easier to just DETACH rather than coordinate
a "proper" subtask shutdown.  So that may or may not indicate a problem.

TSO supports multi-tasking as much as jobs or STCs do; commands are indeed
ATTACHed & DETACHed; and there are a few TSO/TMP tasks running all the time
(see above).

In any case, TSO's particular rules about authorized commands aren't
relevant here.

For the original problem, I don't know anything else.  You might try it
from a READY prompt if you haven't yet.

sas


On Mon, May 20, 2019 at 6:39 PM Mike Shaw  wrote:

> On 5/20/2019 3:37 PM, Seymour J Metz wrote:
> > No and no.
> >
> > TSO does not support concurrent execution of tasks. When an unauthorized
> task calls an authorized command, the TMP doesn't let the unauthorized task
> continue until the authorized task completes.
> > 
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
>

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

Re: How to Identify PROC name in SMF

[Clark Morris]

[Default] On 20 May 2019 17:27:51 -0700, in bit.listserv.ibm-main
charl...@mcn.org (Charles Mills) wrote:

>Most in smf 30. Not sure about proc name. I've used a decent cbt reporting. No 
>lpar per se but smfid is almost the same thing.Charles 
PROC name is not available in any SMF record that I am aware of.  I
Used JES2 EXIT 6 (Philips Lights mods on the CBT tape) and JES3
IATUX32 (I believe Westinghouse mods on the JES3 tape) to create PROC
usage records back in the 1980s.  With the introduction of JCLLIB and
nested procs, the SMF records needed would be more complex and have to
include 1 or more data set names as well as the potential of multiple
PROC names.  All I had to deal with was the JES2 or JES3 specified
concatenation and 1 level of PROC name.

Clark Morris   
> Original message From: Lizette Koehler 
> Date: 5/20/19  5:04 PM  (GMT-08:00) To: 
>IBM-MAIN@LISTSERV.UA.EDU Subject: How to Identify PROC name in SMF Is this 
>possible?If so, what SMF  record can I use to find the followingJOBNAME/PROC 
>Used/Date/Time/LPARNote:  No SAS /no MXGOnly IFASMFDP  or  DAF Thanks 
>Lizette--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: How to Identify PROC name in SMF

[Charles Mills]

Most in smf 30. Not sure about proc name. I've used a decent cbt reporting. No 
lpar per se but smfid is almost the same thing.Charles 
 Original message From: Lizette Koehler 
 Date: 5/20/19  5:04 PM  (GMT-08:00) To: 
IBM-MAIN@LISTSERV.UA.EDU Subject: How to Identify PROC name in SMF Is this 
possible?If so, what SMF  record can I use to find the followingJOBNAME/PROC 
Used/Date/Time/LPARNote:  No SAS /no MXGOnly IFASMFDP  or  DAF Thanks 
Lizette--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

How to Identify PROC name in SMF

[Lizette Koehler]

Is this possible?

If so, what SMF  record can I use to find the following

JOBNAME/PROC Used/Date/Time/LPAR


Note:  No SAS /no MXG

Only IFASMFDP  or  DAF

 
Thanks 

Lizette

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

Re: [EXTERNAL] Re: Comparing SMP/E to Git

[Joel C. Ewing]

What PTF stands for (Program Temporary Fix) is of course no longer
accurate -- as  long as you stay on the same product release level they
are neither "temporary" nor confined to "fixes".   Many small functional
enhancements are implemented using PTFs and such PTFs are also part of
some RSU and PUT level, so maintenance to a PUT or RSU level is more
than just fixes as well.   Sometimes major functional enhancements may
be added as sort of an intermediate release by installing a dependent
function FMID that does some combination of adding new elements or
taking over ownership and replacing some elements that were originally
owned by the primary product FMID;  other release changes may be
regarded as  significant enough for a new function FMID that completely
deletes and replaces the FMID(s) and all asoociated components of a
previous release.   IBM or a 3rd party vendor could also decide to just
parckage what would effectively be a new release as a massive PTF that
changes everything belonging to the product but continues using the same
FMID. 

SMP/E has some support for maintenance of Assembler source code and
other "text" elements, but support for source code maintenance is
admittedly pretty rudimentary -- either complete replacement or record
insertion/deletion based on embedded sequence numbers.  This has
historically not been a priority area  for SMP/E enchancements because
with rare exceptions (installation customizable exits, sample programs,
and text configuration files), most z/OS system and product code from
IBM has been Object-Code-Only for decades and is maintained by
installation sites at the object module level.

IBM obviously must use additional source code management tools
internally for co-ordinating and properly sequencing updates to the
source code behind the PTFs.  Some other readers of this list may know
what those tools are.

    Joel C. Ewing

On 5/20/19 11:20 AM, Sankaranarayanan, Vignesh wrote:
> Thanks for writing this up Joel!
> Is it fair to say that SMP/E is not strictly error-fix anymore, since there 
> are now INCremental releases from CA (for example), which allow for the 
> introduction of product feature(s)?
> If it's RSU1903 or PUT1903, sure, that's fixes, but with the growth of 
> Continuous Delivery, product development itself is being sped up due to 
> shortened release cycles (think MQ now does CD).
>
> On the other end, GitLab (a provider of Git) is now offering package 
> management.
>
> Are the 2 products/technologies converging?
> Hypothetically, if they are, is Git better than SMP/E, or vice versa?
> That is... is tomorrow's SMP/E going to be "Not Your Father's SMP/E", having 
> stood the test of time, and possibly better at version control / package mgmt 
> than Git?
>
> Again, I just want to hear folks' thoughts on this topic..
>
> – Vignesh
> Mainframe Infrastructure
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Joel C. Ewing
> Sent: 20 May 2019 16:10
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: Comparing SMP/E to Git
>
> My understanding of Git is fairly superficial, having only read about it and 
> not actually used it, but it would appear that the orientation of git is 
> primarily one of files/modules, tracking collections of those and the 
> assigning of versioning levels for the entire collection of files. 
> Distribution of a product involves selecting a version level from one of a 
> linear progression of versions and supplying all pieces of the product 
> corresponding to that version level.
>
> SMP/E on the other hand only deals with product versions at major version 
> levels in the form of supplying and new product FMID that supercedes the 
> FMIDs for earlier versions of the product.   SMP/E has as its primary focus 
> fixes (PTFs)  that resolve problems ( APARs) for specific FMID levels of a 
> product.   Installing a singe PTF could change just a single file/module of a 
> product, or it could change many, even all, files in the product.   SMP/E 
> manages the handling of interdependencies among PTFs, APARs, and FMIDs.   You 
> can choose to distribute a product at a specific maintenance level as defined 
> by the set of libraries known to SMP/E and the associated SMP/E databases 
> that define what FMIDs and combination of PTFs are installed.
>
> The SMP/E approach appears much more powerful in that it can support the Git 
> approach as a subset by permitting "level set" PTFs which change so much of a 
> product as to be effectively a new sub-version level that is required for all 
> future updates.   Some z/OS products, particularly some that are Unix-based, 
> follow that approach and tend to have massive-sized PTFs that resolve many 
> APARs.   The normal PTF approach where one PTF resolves one APAR or a 
> relatively small number of APARs and affects a relatively small number of 
> files has the advantage that it allows more precise control over how much you 
> choose to perturb a 

Re: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E

[Mike Shaw]

On 5/20/2019 3:37 PM, Seymour J Metz wrote:

No and no.

TSO does not support concurrent execution of tasks. When an unauthorized task 
calls an authorized command, the TMP doesn't let the unauthorized task continue 
until the authorized task completes.

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




True for the unauthorized/authorized case Shmuel mentions, but under 
TSO/E, the ISPF main task does attach multiple concurrent tasks, one per 
logical screen...three logical screens, three concurrent tasks:


1 IEAVAR00
2 . IEESB605
3 . . IKJEFT01, JOBSTEP
4 . . . IKJEFT02
5 . . . . IKJEFT09
6 . . . . . ISPF
7 . . . . . . ISPTASK (ISPLLIB)
8 . . . . . . ISPTASK (ISPLLIB)
9 . . . . . . ISPTASK (ISPLLIB)

Task list above courtesy of zXDC...

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

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

Re: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E

[Mike Stramba]

No, it's not a "good call".

I do have the INTERRUPT option enabled.

At least that's what the compiler listing says.

What code does the INTERRUPT option  generate ?


Mike

On 5/20/19, Steve Smith  wrote:
> Good call... the INTERRUPT option is the likely culprit (the O.P. can say
> for sure).  Now maybe someone could explain why such an option exists.
> Would you like an 'EOF' option to specify whether EOF should be detected?
>
> TSO is a very-multi-tasked environment.  Each command is ATTACHed as a
> subtask, and the default for attention is to mercilessly DETACH it (which
> is essentially CANCEL for a task).  Except for the exceptions, of course.
>
> sas
>
>
> On Mon, May 20, 2019 at 11:03 AM Joe Monk  wrote:
>
>> If youre trying to run under TSO, did you compile with the INTERRUPT
>> option?
>>
>> Joe
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: z/OS Container Extensions

[John McKown]

Thanks.

On Mon, May 20, 2019, 14:16 Mike Schwab  wrote:

> You can run z/Linux on Hercules or Z mainframe. Go to
> https://hub.docker.com/search?q==image=s390x .
> Select IBM Z as the hardware and there are 2001 images ready to download.
> Pick one with the combination of database and language support you want.
>
> On Mon, May 20, 2019 at 12:00 PM John McKown
>  wrote:
> >
> > On Mon, May 20, 2019 at 7:56 AM Anthony Giorgio <
> niteh...@linux.vnet.ibm.com>
> > wrote:
> >
> > > If you have specific questions about zCX, feel free to post them here.
> > > I'll do my best to answer them, or find someone else who can.
> > >
> > > As far as the technical setup of zCX, it's essentially a z/OS
> hypervisor
> > > (like z/VM) that is only configured to run Linux.  The Linux guest OS
> is
> > > running Docker, and is a turnkey appliance.  You only have to configure
> > > the appliance to run in your z/OS environment (network, DASD, CPUs,
> etc.)
> > >
> > > Once zCX is configured and the address space (or spaces!) is started,
> > > the Docker service will be available to you in the appliance.  You can
> > > use this service to pull containers from Docker registries.  A
> container
> > > is essentially a packaged application+OS+libraries, which rather neatly
> > > solves the "dependency hell" problem.  You can create your own
> > > containers or use commercially published ones, and these can be
> deployed
> > > to a "Docker registry" for use, either internally or externally.
> > > --
> > > Anthony Giorgio
> > > Advisory Software Engineer, z/OS Container Extensions
> > >
> > >
> > I know nothing about Docker at present. Would it be possible for me to
> use
> > a Linux/Intel system and the s390x cross-build tools to make a Docker
> > "image" which I could then deploy on z/OS?
> >
> > --
> > This is clearly another case of too many mad scientists, and not enough
> > hunchbacks.
> >
> >
> > Maranatha! <><
> > John McKown
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: [EXTERNAL] Comparing SMP/E to Git

[Anthony Giorgio]

Well said.  Git was primarily designed to address deficiencies in other 
source code management systems.  It has excellent support for branching 
and merging, which were a major pain point in Linux kernel development.

Git is simply not designed to handle package management duties.

On 5/20/19 3:45 PM, Seymour J Metz wrote:

Is a Pier Cub better than a rowboat? Neither can do what he other does.

If you're trying to deal with dependencies, SMP is better than anything else 
that I've seen. If you have independent developers updating the same source 
module, SMP is useless.

When the only tool in your toolkit is a pipe, everything looks like  filter.


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



--
Anthony Giorgio
z/OS Container Extensions

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

Re: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E

[Seymour J Metz]

I'd say that the first step is to run a trace and find out what your terminal 
simulator is actually sending when you click on ATTENTION. Ideally, it will be 
the aid for PA1, exactly one time, but life is full of surprises.

Does your ATTENTION key work as expected with other applications?


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


From: IBM Mainframe Discussion List  on behalf of 
Mike Stramba 
Sent: Monday, May 20, 2019 12:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E

I'm trying to compile and run the PL/I ON ATTENTION interrupt example
from the PLI prog guide ver 4 r4 (pg 542   / GI11-9145-03)

The code contains an ON ATTENTION handler with a simple message and prompt :
 and the main line is a simple endless loop.

The goal was just to write an extremely primitive counter-tester,
which the user can interrupt after X seconds to see what
counting-performance had been achieved.

When I run the program and then press my 3270 emulator attention key,
the program just ends instead of the attention handler gaining
control.

The console log shows a SLIP TRAP X33E and X13E were matched.

MVS system codes SA38-0665-30 says for 33E :
 "During processing of a DETACH macro that specified a STAE=YES
operand, the system found that the specified subtask had not completed
processing"

code 13E is :
 "The task that created a subtask issued a DETACH macro for that
subtask, specifying STAE=NO before the subtask ended.

I ASSume the "subtask" is my test program ??

And the "task" is  TSO ??

Or maybe not :/

How do I just get the ON ATTENTION handler to work ?

Mike

--
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: Comparing SMP/E to Git

[Seymour J Metz]

Comparing SMP to git is like comparing a hammer to a screwdriver; each is good 
at what it is designed for and terrible at what the other does well.

SMP is designed to manage dependencies, and does that well. It does not have 
good support for multiple updates of the same element, while merging updates is 
common in the open source world.


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


From: IBM Mainframe Discussion List  on behalf of 
Joel C. Ewing 
Sent: Monday, May 20, 2019 11:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Comparing SMP/E to Git

My understanding of Git is fairly superficial, having only read about it
and not actually used it, but it would appear that the orientation of
git is primarily one of files/modules, tracking collections of those and
the assigning of versioning levels for the entire collection of files.
Distribution of a product involves selecting a version level from one of
a linear progression of versions and supplying all pieces of the product
corresponding to that version level.

SMP/E on the other hand only deals with product versions at major
version levels in the form of supplying and new product FMID that
supercedes the FMIDs for earlier versions of the product.   SMP/E has as
its primary focus fixes (PTFs)  that resolve problems ( APARs) for
specific FMID levels of a product.   Installing a singe PTF could change
just a single file/module of a product, or it could change many, even
all, files in the product.   SMP/E manages the handling of
interdependencies among PTFs, APARs, and FMIDs.   You can choose to
distribute a product at a specific maintenance level as defined by the
set of libraries known to SMP/E and the associated SMP/E databases that
define what FMIDs and combination of PTFs are installed.

The SMP/E approach appears much more powerful in that it can support the
Git approach as a subset by permitting "level set" PTFs which change so
much of a product as to be effectively a new sub-version level that is
required for all future updates.   Some z/OS products, particularly some
that are Unix-based, follow that approach and tend to have massive-sized
PTFs that resolve many APARs.   The normal PTF approach where one PTF
resolves one APAR or a relatively small number of APARs and affects a
relatively small number of files has the advantage that it allows more
precise control over how much you choose to perturb a functioning system
just to resolve a specific critical issue that is causing problems at
your installation.  That approach is possible even with very complex
applications in z/OS because the large load modules of such applications
are typically comprised of many linked modules and SMP/E can perform
updates at the level of individual modules.   Although it is typical to
install many PTFs at a time during a regular planned maintenance, the
PTF approach allows a lot of flexibility if specific fixes are known to
create unresolved problems.  The approach of tracking known problems in
the form of documented Error Holds against a PTF can even allow an
informed choice of whether it makes sense to install a PTF that fixes a
serious problem even though it may introduce some other unresolved
problem that might not be an exposure at your installation.
Joel C. Ewing

On 5/20/19 8:28 AM, Sankaranarayanan, Vignesh wrote:
> ... in what ways are they similar, and what ways are they different?
> Is the world better off with SMP/E-like structure for code, or is z/OS etc. 
> better off with Git-like structure?
>
> - Vignesh
> Mainframe Infrastructure
>
> ...


--
Joel C. Ewing

--
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] Comparing SMP/E to Git

[Seymour J Metz]

Is a Pier Cub better than a rowboat? Neither can do what he other does.

If you're trying to deal with dependencies, SMP is better than anything else 
that I've seen. If you have independent developers updating the same source 
module, SMP is useless.

When the only tool in your toolkit is a pipe, everything looks like  filter.


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


From: IBM Mainframe Discussion List  on behalf of 
Pew, Curtis G 
Sent: Monday, May 20, 2019 12:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Comparing SMP/E to Git

On May 20, 2019, at 11:20 AM, Sankaranarayanan, Vignesh 
mailto:vignesh.v.sankaranaraya...@marks-and-spencer.com>>
 wrote:

On the other end, GitLab (a provider of Git) is now offering package management.

Are the 2 products/technologies converging?
Hypothetically, if they are, is Git better than SMP/E, or vice versa?
That is... is tomorrow's SMP/E going to be "Not Your Father's SMP/E", having 
stood the test of time, and possibly better at version control / package mgmt 
than Git?

Again, I just want to hear folks' thoughts on this topic..


>From what I’ve seen, the package management offered by GitLab and GitHub are 
>distinct products from their git support.

I would still say the use cases for git (version control during development) 
and a package manager like SMP/E or rpm or the Git* offerings (managing 
dependencies in deployed software) are different enough that viewing them as 
somehow competitive would be a mistake.


--
Pew, Curtis G
curtis@austin.utexas.edu






--
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: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E

[Seymour J Metz]

No and no. 

TSO does not support concurrent execution of tasks. When an unauthorized task 
calls an authorized command, the TMP doesn't let the unauthorized task continue 
until the authorized task completes.

The default for attention is to allow the terminal user to decide what to do, 
e.g., TEST.

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


From: IBM Mainframe Discussion List  on behalf of 
Steve Smith 
Sent: Monday, May 20, 2019 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E

Good call... the INTERRUPT option is the likely culprit (the O.P. can say
for sure).  Now maybe someone could explain why such an option exists.
Would you like an 'EOF' option to specify whether EOF should be detected?

TSO is a very-multi-tasked environment.  Each command is ATTACHed as a
subtask, and the default for attention is to mercilessly DETACH it (which
is essentially CANCEL for a task).  Except for the exceptions, of course.

sas


On Mon, May 20, 2019 at 11:03 AM Joe Monk  wrote:

> If youre trying to run under TSO, did you compile with the INTERRUPT
> option?
>
> Joe

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

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

Re: z/OS Container Extensions

[Mike Schwab]

You can run z/Linux on Hercules or Z mainframe. Go to
https://hub.docker.com/search?q==image=s390x .
Select IBM Z as the hardware and there are 2001 images ready to download.
Pick one with the combination of database and language support you want.

On Mon, May 20, 2019 at 12:00 PM John McKown
 wrote:
>
> On Mon, May 20, 2019 at 7:56 AM Anthony Giorgio 
> wrote:
>
> > If you have specific questions about zCX, feel free to post them here.
> > I'll do my best to answer them, or find someone else who can.
> >
> > As far as the technical setup of zCX, it's essentially a z/OS hypervisor
> > (like z/VM) that is only configured to run Linux.  The Linux guest OS is
> > running Docker, and is a turnkey appliance.  You only have to configure
> > the appliance to run in your z/OS environment (network, DASD, CPUs, etc.)
> >
> > Once zCX is configured and the address space (or spaces!) is started,
> > the Docker service will be available to you in the appliance.  You can
> > use this service to pull containers from Docker registries.  A container
> > is essentially a packaged application+OS+libraries, which rather neatly
> > solves the "dependency hell" problem.  You can create your own
> > containers or use commercially published ones, and these can be deployed
> > to a "Docker registry" for use, either internally or externally.
> > --
> > Anthony Giorgio
> > Advisory Software Engineer, z/OS Container Extensions
> >
> >
> I know nothing about Docker at present. Would it be possible for me to use
> a Linux/Intel system and the s390x cross-build tools to make a Docker
> "image" which I could then deploy on z/OS?
>
> --
> This is clearly another case of too many mad scientists, and not enough
> hunchbacks.
>
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E

[Steve Smith]

Good call... the INTERRUPT option is the likely culprit (the O.P. can say
for sure).  Now maybe someone could explain why such an option exists.
Would you like an 'EOF' option to specify whether EOF should be detected?

TSO is a very-multi-tasked environment.  Each command is ATTACHed as a
subtask, and the default for attention is to mercilessly DETACH it (which
is essentially CANCEL for a task).  Except for the exceptions, of course.

sas


On Mon, May 20, 2019 at 11:03 AM Joe Monk  wrote:

> If youre trying to run under TSO, did you compile with the INTERRUPT
> option?
>
> Joe

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

Re: FTPLOGGING not working

[Frank Swarbrick]

Our Systems group has resolved this issue.  (I don't know the cause or the 
resolution at the moment.)


From: IBM Mainframe Discussion List  on behalf of 
Frank Swarbrick 
Sent: Monday, May 20, 2019 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: FTPLOGGING not working

Some PTFs were applied to our production z/OS 2.3 environment this weekend, and 
since the FTP server was cycled the log messages are no longer being written to 
the console.

FTPLOGGING TRUE is still set in the SYSFTPD config file.

Any thoughts?

--
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: Vote for RFE 48916 to create LE STORAGE report when program abends

[Tom Conley]

On 5/20/2019 12:55 PM, Richards, Robert B. wrote:

Tom,

Can you provide a link?

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pinnacle
Sent: Sunday, May 19, 2019 10:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Vote for RFE 48916 to create LE STORAGE report when program abends

Fellow IBM-MAINiacs,

I submitted a SHARE requirement a long time ago for LE to generate the
STORAGE and OPTIONS reports when an LE program abends.  In the event of
storage abends like 878, 80A, etc, the STORAGE report should still be
produced by LE, since the report itself could be invaluable in debugging
a storage problem.  The title of the RFE was hacked and shortened,
making it unintelligible, so no votes have accumulated for it.  Please
look it up and vote for RFE 48916 if you're so inclined.

Regards,
Tom Conley



Bob,

WTW!

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=48916

Tom

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

Re: Restoring IBM System/360 Model 20s and a System/370 Model 125

[William Donzelli]

One of the model 20s is more or less a parts car, probably used to
keep the production one running. They intend to use it for the same
purpose.

The 125 seems only to be the processor, as there were no S/370 era
peripherals with the lot, other than a 3504 with the top shaved off,
apparently used as a desk.

The red model 20 system, as a whole, is indeed quite nice, even if
they have their work cut out for them. I would have pursued this had
it not been in Europe, and also being drained from doing a similar
rescue about five months ago of a lonely 148.

Will

On Mon, May 20, 2019 at 12:30 PM Timothy Sipples  wrote:
>
> Correction: This team bid on one System/360 Model 20 but ended up winning a
> pair of Model 20s and a System/370 Model 125. Amazing! The Model 125 was
> pre-XA but has virtual storage and either 96K or 128K of main memory. I've
> changed the subject line to reflect what they've discovered.
>
> They recovered the systems from what was apparently a real, functioning
> data center in the 1970s and perhaps later. So they also found lots of
> connected cables, tape drives, manuals, cards, etc.
>
> 
> Timothy Sipples
> IT Architect Executive, Industry Solutions, IBM Z & LinuxONE
> 
>
> 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

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

Re: z/OS Container Extensions

[John McKown]

On Mon, May 20, 2019 at 7:56 AM Anthony Giorgio 
wrote:

> If you have specific questions about zCX, feel free to post them here.
> I'll do my best to answer them, or find someone else who can.
>
> As far as the technical setup of zCX, it's essentially a z/OS hypervisor
> (like z/VM) that is only configured to run Linux.  The Linux guest OS is
> running Docker, and is a turnkey appliance.  You only have to configure
> the appliance to run in your z/OS environment (network, DASD, CPUs, etc.)
>
> Once zCX is configured and the address space (or spaces!) is started,
> the Docker service will be available to you in the appliance.  You can
> use this service to pull containers from Docker registries.  A container
> is essentially a packaged application+OS+libraries, which rather neatly
> solves the "dependency hell" problem.  You can create your own
> containers or use commercially published ones, and these can be deployed
> to a "Docker registry" for use, either internally or externally.
> --
> Anthony Giorgio
> Advisory Software Engineer, z/OS Container Extensions
>
>
I know nothing about Docker at present. Would it be possible for me to use
a Linux/Intel system and the s390x cross-build tools to make a Docker
"image" which I could then deploy on z/OS?

-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.


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: [EXTERNAL] Comparing SMP/E to Git

[Pew, Curtis G]

On May 20, 2019, at 11:20 AM, Sankaranarayanan, Vignesh 
mailto:vignesh.v.sankaranaraya...@marks-and-spencer.com>>
 wrote:

On the other end, GitLab (a provider of Git) is now offering package management.

Are the 2 products/technologies converging?
Hypothetically, if they are, is Git better than SMP/E, or vice versa?
That is... is tomorrow's SMP/E going to be "Not Your Father's SMP/E", having 
stood the test of time, and possibly better at version control / package mgmt 
than Git?

Again, I just want to hear folks' thoughts on this topic..


From what I’ve seen, the package management offered by GitLab and GitHub are 
distinct products from their git support.

I would still say the use cases for git (version control during development) 
and a package manager like SMP/E or rpm or the Git* offerings (managing 
dependencies in deployed software) are different enough that viewing them as 
somehow competitive would be a mistake.


--
Pew, Curtis G
curtis@austin.utexas.edu






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

Re: Vote for RFE 48916 to create LE STORAGE report when program abends

[Richards, Robert B.]

Tom,

Can you provide a link?

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pinnacle
Sent: Sunday, May 19, 2019 10:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Vote for RFE 48916 to create LE STORAGE report when program abends

Fellow IBM-MAINiacs,

I submitted a SHARE requirement a long time ago for LE to generate the 
STORAGE and OPTIONS reports when an LE program abends.  In the event of 
storage abends like 878, 80A, etc, the STORAGE report should still be 
produced by LE, since the report itself could be invaluable in debugging 
a storage problem.  The title of the RFE was hacked and shortened, 
making it unintelligible, so no votes have accumulated for it.  Please 
look it up and vote for RFE 48916 if you're so inclined.

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

FTPLOGGING not working

[Frank Swarbrick]

Some PTFs were applied to our production z/OS 2.3 environment this weekend, and 
since the FTP server was cycled the log messages are no longer being written to 
the console.

FTPLOGGING TRUE is still set in the SYSFTPD config file.

Any thoughts?

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

Restoring IBM System/360 Model 20s and a System/370 Model 125

[Timothy Sipples]

Correction: This team bid on one System/360 Model 20 but ended up winning a
pair of Model 20s and a System/370 Model 125. Amazing! The Model 125 was
pre-XA but has virtual storage and either 96K or 128K of main memory. I've
changed the subject line to reflect what they've discovered.

They recovered the systems from what was apparently a real, functioning
data center in the 1970s and perhaps later. So they also found lots of
connected cables, tape drives, manuals, cards, etc.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE


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

Re: Comparing SMP/E to Git

[Paul Gilmartin]

On Mon, 20 May 2019 13:28:58 +, Sankaranarayanan, Vignesh wrote:

>... in what ways are they similar, and what ways are they different?
>Is the world better off with SMP/E-like structure for code, or is z/OS etc. 
>better off with Git-like structure?
>
I never learned Git.  I've long seen similarities and differences between
"make" and SMP/E:

Both build targets from sources and update those targets when the sources
change (and both use the term "target").

SMP/E restricts names to 8 (or 7) characters, all uppercase.  Make suffers
no such archaic restriction.

The only language processer SMP/E supports is Assembler.  Make allows
the user to define rules for processing any language.  SMP/E should do
likewise.

Make infers element types from filename extensions.  SMP/E supplies
the element type in the element MCS.  I prefer to use filenames only
for identification, not to overload then with metadata as make does.

SMP/E determines service level from PRE and SUP operands of SYSMODs;
make relies on file timestamps.  SMP/E's more orderly practice avoids a
misbehavior when a target has been built later than the timestamp of a
higher-level source.

Make has a macro facility; SMP/E has none.  That could be valuable
for global specification of a DSN HLQ.  (Use of the SYSLMOD LLQ to
select a DDDEF is a small step in that direction.)

The make product description is entirely in the makefile; SMP/E uses
two sources, the UCLIN and the JCLIN.  JCLIN seems to me to be
transitional, allowing the user to import (mostly) existing JCL rather
than needing to re-specify a product to import it to SMP/E.

SMP/E's support of UNIX files is bizarre.  The user seems required
to use GIMDTS to transform UNIX files to FB80 PDS or instream
elements, unload the PDSes with IEBCOPY to RELFILES, and package
those.  Even as IEBCOPY is the natural tool for PDSes, "pax -xpax"
is the natural for UNIX files, and preserves all the peculiar z/OS
metadata.  SMP/E should adopt pax for transfer of UNIX files rather
than the current convoluted process.

(And everything that Joel said.)

-- gil

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

Re: [EXTERNAL] Re: Comparing SMP/E to Git

[Sankaranarayanan, Vignesh]

Thanks for writing this up Joel!
Is it fair to say that SMP/E is not strictly error-fix anymore, since there are 
now INCremental releases from CA (for example), which allow for the 
introduction of product feature(s)?
If it's RSU1903 or PUT1903, sure, that's fixes, but with the growth of 
Continuous Delivery, product development itself is being sped up due to 
shortened release cycles (think MQ now does CD).

On the other end, GitLab (a provider of Git) is now offering package management.

Are the 2 products/technologies converging?
Hypothetically, if they are, is Git better than SMP/E, or vice versa?
That is... is tomorrow's SMP/E going to be "Not Your Father's SMP/E", having 
stood the test of time, and possibly better at version control / package mgmt 
than Git?

Again, I just want to hear folks' thoughts on this topic..

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Joel C. Ewing
Sent: 20 May 2019 16:10
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Comparing SMP/E to Git

My understanding of Git is fairly superficial, having only read about it and 
not actually used it, but it would appear that the orientation of git is 
primarily one of files/modules, tracking collections of those and the assigning 
of versioning levels for the entire collection of files. Distribution of a 
product involves selecting a version level from one of a linear progression of 
versions and supplying all pieces of the product corresponding to that version 
level.

SMP/E on the other hand only deals with product versions at major version 
levels in the form of supplying and new product FMID that supercedes the FMIDs 
for earlier versions of the product.   SMP/E has as its primary focus fixes 
(PTFs)  that resolve problems ( APARs) for specific FMID levels of a product.   
Installing a singe PTF could change just a single file/module of a product, or 
it could change many, even all, files in the product.   SMP/E manages the 
handling of interdependencies among PTFs, APARs, and FMIDs.   You can choose to 
distribute a product at a specific maintenance level as defined by the set of 
libraries known to SMP/E and the associated SMP/E databases that define what 
FMIDs and combination of PTFs are installed.

The SMP/E approach appears much more powerful in that it can support the Git 
approach as a subset by permitting "level set" PTFs which change so much of a 
product as to be effectively a new sub-version level that is required for all 
future updates.   Some z/OS products, particularly some that are Unix-based, 
follow that approach and tend to have massive-sized PTFs that resolve many 
APARs.   The normal PTF approach where one PTF resolves one APAR or a 
relatively small number of APARs and affects a relatively small number of files 
has the advantage that it allows more precise control over how much you choose 
to perturb a functioning system just to resolve a specific critical issue that 
is causing problems at your installation.  That approach is possible even with 
very complex applications in z/OS because the large load modules of such 
applications are typically comprised of many linked modules and SMP/E can 
perform updates at the level of individual modules.   Although it is typical to 
install many PTFs at a time during a regular planned maintenance, the PTF 
approach allows a lot of flexibility if specific fixes are known to create 
unresolved problems.  The approach of tracking known problems in the form of 
documented Error Holds against a PTF can even allow an informed choice of 
whether it makes sense to install a PTF that fixes a serious problem even 
though it may introduce some other unresolved problem that might not be an 
exposure at your installation.
Joel C. Ewing

On 5/20/19 8:28 AM, Sankaranarayanan, Vignesh wrote:
> ... in what ways are they similar, and what ways are they different?
> Is the world better off with SMP/E-like structure for code, or is z/OS etc. 
> better off with Git-like structure?
>
> - Vignesh
> Mainframe Infrastructure
>
> ...


--
Joel C. Ewing

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

Re: Comparing SMP/E to Git

[Joel C. Ewing]

My understanding of Git is fairly superficial, having only read about it
and not actually used it, but it would appear that the orientation of
git is primarily one of files/modules, tracking collections of those and
the assigning of versioning levels for the entire collection of files. 
Distribution of a product involves selecting a version level from one of
a linear progression of versions and supplying all pieces of the product
corresponding to that version level.

SMP/E on the other hand only deals with product versions at major
version levels in the form of supplying and new product FMID that
supercedes the FMIDs for earlier versions of the product.   SMP/E has as
its primary focus fixes (PTFs)  that resolve problems ( APARs) for
specific FMID levels of a product.   Installing a singe PTF could change
just a single file/module of a product, or it could change many, even
all, files in the product.   SMP/E manages the handling of
interdependencies among PTFs, APARs, and FMIDs.   You can choose to
distribute a product at a specific maintenance level as defined by the
set of libraries known to SMP/E and the associated SMP/E databases that
define what FMIDs and combination of PTFs are installed.

The SMP/E approach appears much more powerful in that it can support the
Git approach as a subset by permitting "level set" PTFs which change so
much of a product as to be effectively a new sub-version level that is
required for all future updates.   Some z/OS products, particularly some
that are Unix-based, follow that approach and tend to have massive-sized
PTFs that resolve many APARs.   The normal PTF approach where one PTF
resolves one APAR or a relatively small number of APARs and affects a
relatively small number of files has the advantage that it allows more
precise control over how much you choose to perturb a functioning system
just to resolve a specific critical issue that is causing problems at
your installation.  That approach is possible even with very complex
applications in z/OS because the large load modules of such applications
are typically comprised of many linked modules and SMP/E can perform
updates at the level of individual modules.   Although it is typical to
install many PTFs at a time during a regular planned maintenance, the
PTF approach allows a lot of flexibility if specific fixes are known to
create unresolved problems.  The approach of tracking known problems in
the form of documented Error Holds against a PTF can even allow an
informed choice of whether it makes sense to install a PTF that fixes a
serious problem even though it may introduce some other unresolved
problem that might not be an exposure at your installation.
    Joel C. Ewing

On 5/20/19 8:28 AM, Sankaranarayanan, Vignesh wrote:
> ... in what ways are they similar, and what ways are they different?
> Is the world better off with SMP/E-like structure for code, or is z/OS etc. 
> better off with Git-like structure?
>
> - Vignesh
> Mainframe Infrastructure
>
> ...


-- 
Joel C. Ewing

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

Re: PL/I TSO Interrupt - Attention handling - SLIP trap X33E / X13E

[Joe Monk]

If youre trying to run under TSO, did you compile with the INTERRUPT option?

Joe

On Sun, May 19, 2019 at 11:37 PM Mike Stramba  wrote:

> I'm trying to compile and run the PL/I ON ATTENTION interrupt example
> from the PLI prog guide ver 4 r4 (pg 542   / GI11-9145-03)
>
> The code contains an ON ATTENTION handler with a simple message and prompt
> :
>  and the main line is a simple endless loop.
>
> The goal was just to write an extremely primitive counter-tester,
> which the user can interrupt after X seconds to see what
> counting-performance had been achieved.
>
> When I run the program and then press my 3270 emulator attention key,
> the program just ends instead of the attention handler gaining
> control.
>
> The console log shows a SLIP TRAP X33E and X13E were matched.
>
> MVS system codes SA38-0665-30 says for 33E :
>  "During processing of a DETACH macro that specified a STAE=YES
> operand, the system found that the specified subtask had not completed
> processing"
>
> code 13E is :
>  "The task that created a subtask issued a DETACH macro for that
> subtask, specifying STAE=NO before the subtask ended.
>
> I ASSume the "subtask" is my test program ??
>
> And the "task" is  TSO ??
>
> Or maybe not :/
>
> How do I just get the ON ATTENTION handler to work ?
>
> Mike
>
> --
> 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] Re: Comparing SMP/E to Git

[Sankaranarayanan, Vignesh]

What about the PRE/SUP/REQ etc. control statements in PTFs... isn't that maybe 
a basic SCM?
Don't know if it allows for line-level diff as in Git, but does even Endevor 
allow/do that, for example?

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Anthony Giorgio
Sent: 20 May 2019 15:20
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: Comparing SMP/E to Git

Git is designed as a source code management system, while SMP/E is a package 
manager.  Git is analogous to Subversion, CVS, and RCS, while SMP/E is similar 
to RPM.

On 5/20/19 9:49 AM, Sankaranarayanan, Vignesh wrote:
> Fine, didn't intend to say they were meant for the same thing, wanted to 
> start a convo about both..
>
> If you have a few minutes, can you expand on your statement.. ?
>
> – Vignesh
> Mainframe Infrastructure
>
> -Original Message-

--
Anthony Giorgio
Advisory Software Engineer
Twitter: @a_giorgio

--
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: [EXTERNAL] Re: Comparing SMP/E to Git

[Anthony Giorgio]

Git is designed as a source code management system, while SMP/E is a 
package manager.  Git is analogous to Subversion, CVS, and RCS, while 
SMP/E is similar to RPM.


On 5/20/19 9:49 AM, Sankaranarayanan, Vignesh wrote:

Fine, didn't intend to say they were meant for the same thing, wanted to start 
a convo about both..

If you have a few minutes, can you expand on your statement.. ?

– Vignesh
Mainframe Infrastructure

-Original Message-


--
Anthony Giorgio
Advisory Software Engineer
Twitter: @a_giorgio

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

Re: [EXTERNAL] Re: Comparing SMP/E to Git

[Sankaranarayanan, Vignesh]

Fine, didn't intend to say they were meant for the same thing, wanted to start 
a convo about both..

If you have a few minutes, can you expand on your statement.. ?

– Vignesh
Mainframe Infrastructure

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Smith
Sent: 20 May 2019 14:44
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Comparing SMP/E to Git

That's like comparing a airliner to a boarding ramp.

sas

On Mon, May 20, 2019 at 9:29 AM Sankaranarayanan, Vignesh < 
vignesh.v.sankaranaraya...@marks-and-spencer.com> wrote:

> ... in what ways are they similar, and what ways are they different?
> Is the world better off with SMP/E-like structure for code, or is z/OS
> etc. better off with Git-like structure?
>
> - Vignesh
> Mainframe Infrastructure
>

--
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: Comparing SMP/E to Git

[Steve Smith]

That's like comparing a airliner to a boarding ramp.

sas

On Mon, May 20, 2019 at 9:29 AM Sankaranarayanan, Vignesh <
vignesh.v.sankaranaraya...@marks-and-spencer.com> wrote:

> ... in what ways are they similar, and what ways are they different?
> Is the world better off with SMP/E-like structure for code, or is z/OS
> etc. better off with Git-like structure?
>
> - Vignesh
> Mainframe Infrastructure
>

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

Comparing SMP/E to Git

[Sankaranarayanan, Vignesh]

... in what ways are they similar, and what ways are they different?
Is the world better off with SMP/E-like structure for code, or is z/OS etc. 
better off with Git-like structure?

- Vignesh
Mainframe Infrastructure


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: z/OS Container Extensions

[Anthony Giorgio]

If you have specific questions about zCX, feel free to post them here. 
I'll do my best to answer them, or find someone else who can.


As far as the technical setup of zCX, it's essentially a z/OS hypervisor 
(like z/VM) that is only configured to run Linux.  The Linux guest OS is 
running Docker, and is a turnkey appliance.  You only have to configure 
the appliance to run in your z/OS environment (network, DASD, CPUs, etc.)


Once zCX is configured and the address space (or spaces!) is started, 
the Docker service will be available to you in the appliance.  You can 
use this service to pull containers from Docker registries.  A container 
is essentially a packaged application+OS+libraries, which rather neatly 
solves the "dependency hell" problem.  You can create your own 
containers or use commercially published ones, and these can be deployed 
to a "Docker registry" for use, either internally or externally.



On 5/16/19 3:25 PM, Tina M Tarquinio wrote:
> You can check out the details here -->
> https://www.ibm.com/support/z-content-solutions/container-extensions/
>
> There are some FAQs that cover what you ask below, and more!
>
> And if that doesnt cover it, we can get the team to meet with you
> directly!
>
>
> Tina M. Tarquinio
> Director, IBM z/OS  | @tinatarq | tina...@us.ibm.com
>

--
Anthony Giorgio
Advisory Software Engineer, z/OS Container Extensions

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

Re: Convert ZFS to Expanded format

[Allan Staller]

This will require unload/delete/allocate/reload of the original dataset. I 
presume you mean either Extended Addressability or Extended Format.
In either case, these are attributes of the DATACLAS which can only be modified 
at dataset allocation time.

HTH,


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gadi Ben-Avi
Sent: Sunday, May 19, 2019 3:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Convert ZFS to Expanded format

Hi,
Is there a way to convert a ZFS, or any other VSAM file, to expanded format?
We are running z/OS v2.3.

Thanks

Gadi


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

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

Re: DFDSS copy to pre-allocated dsn

[Elaine Beal]

Robert,

Thank you- duh, read the whole error message:(
I was looking at only the first xxx reason code.

Elaine

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

A VTF Mainframe (VTFM) question

[Giliad Wilf]

Hi All,
 
I've been assigned to evaluate VTF Mainframe (VTFM) at our shop and it is 
already installed and running.

Looking for things that have been set "under the hood" I can see its subsystem 
has four SSI routines:
No. 9, "Notify write-to-operator message".
No. 10, "Notify operator command".
No. 252, ???
No. 254, ???

Obviously, The last two are servicing some "private requests", not of the usual 
"well known" types.

Does anyone have an idea what are these two for?

Giliad

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

Re: how to determine dasd subsystem type from console?

[Ron Hawkins]

Martin,

Agree. It's about time z/OS provided for something other than just IBM 
controllers.

However, it would be somewhat redundant, as it is the RCD and RDC that document 
supported feature information for the OS, and not the emulated model.

If you are running Hitachi's MAR you can get the HTC specific model 
information, and more.

Ron


RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Martin Packer
Sent: Monday, 20 May 2019 19:08
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] how to determine dasd subsystem type from console?


“2107-900” I’ve always felt to be a little non-descriptive. It doesn’t really 
document the HDS model.

Cheers, Martin

Sent from my iPad

> On 20 May 2019, at 09:55, Ron Hawkins  wrote:
>
> Itschak,
>
>
>
> The information is in the NED, which you can display with DS QD,devn,RCD.
>
>
>
> Unfortunately, the model information the emulated IBM device, but the
vendor ID and serial number should get you halfway there.
>
>
>
>
> +4 (4)
>
>
>
> 6 Bytes
>
> Device Type, in EBCDIC.
>
>
> +10 (A)
>
>
>
> 3 Bytes
>
> Device Model, in EBCDIC.
>
>
> +13 (D)
>
>
>
> 3 Bytes
>
> Manufacturer, in EBCDIC.
>
>
> +16 (10)
>
>
>
> 2 Bytes
>
> Manufacturing location, in EBCDIC.
>
>
> +18 (12)
>
>
>
> 12 Bytes
>
> Serial number, in EBCDIC. This field is right justified, padded with
leading zeros in EBCDIC.
>
>
> So “C8E3C3 F7F5” is “HTC 75.”
>
>
>
>
> DS QD,D212,RCD
>
> IEE459I 00.45.35 DEVSERV QDASD 683
>
> UNIT VOLSER SCUTYPE DEVTYPE   CYL  SSID SCU-SERIAL DEV-SERIAL EF
>
> 0D212 PE2US1 2107900 2107900 10017  0624 XX75-65423 XX75-65423 *O
>
>  READ CONFIGURATION DATA
>
> DC010100F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32412
>
> D402F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400
>
> D000F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400
>
> F001F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400
>
>    
>
>    
>
>    
>
> 81852D001E00 0624045001970002 000CC0129269B6FE 00850800
>
>   1 DEVICE(S) MET THE SELECTION CRITERIA
>
>   0 DEVICE(S) FAILED EXTENDED FUNCTION CHECKING
>
>
>
> The information is also available on in the Type 74 subtype 1 and 5
records, and the RMFPP Cache Summary report.
>
>
>
>
>
> RON HAWKINS
>
> Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
>
> m+61 400029610| t: +1 4085625415 | f: +1 4087912585
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf
Of ITschak Mugzach
> Sent: Monday, 20 May 2019 04:35
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] how to determine dasd subsystem type from console?
>
>
>
> Is there a command to display the storage subsystem vendor & model?
>
>
>
> ITschak
>
>
>
> --
>
> 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
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,  send 
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
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: how to determine dasd subsystem type from console?

[ITschak Mugzach]

Thanks Ron.

On Mon, May 20, 2019 at 10:55 AM Ron Hawkins 
wrote:

> Itschak,
>
>
>
> The information is in the NED, which you can display with DS QD,devn,RCD.
>
>
>
> Unfortunately, the model information the emulated IBM device, but the
> vendor ID and serial number should get you halfway there.
>
>
>
>
> +4 (4)
>
>
>
> 6 Bytes
>
> Device Type, in EBCDIC.
>
>
> +10 (A)
>
>
>
> 3 Bytes
>
> Device Model, in EBCDIC.
>
>
> +13 (D)
>
>
>
> 3 Bytes
>
> Manufacturer, in EBCDIC.
>
>
> +16 (10)
>
>
>
> 2 Bytes
>
> Manufacturing location, in EBCDIC.
>
>
> +18 (12)
>
>
>
> 12 Bytes
>
> Serial number, in EBCDIC. This field is right justified, padded with
> leading zeros in EBCDIC.
>
>
> So “C8E3C3 F7F5” is “HTC 75.”
>
>
>
>
> DS QD,D212,RCD
>
> IEE459I 00.45.35 DEVSERV QDASD 683
>
>  UNIT VOLSER SCUTYPE DEVTYPE   CYL  SSID SCU-SERIAL DEV-SERIAL EF
>
> 0D212 PE2US1 2107900 2107900 10017  0624 XX75-65423 XX75-65423 *O
>
>   READ CONFIGURATION DATA
>
> DC010100F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32412
>
> D402F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400
>
> D000F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400
>
> F001F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400
>
>    
>
>    
>
>    
>
> 81852D001E00 0624045001970002 000CC0129269B6FE 00850800
>
>   1 DEVICE(S) MET THE SELECTION CRITERIA
>
>   0 DEVICE(S) FAILED EXTENDED FUNCTION CHECKING
>
>
>
> The information is also available on in the Type 74 subtype 1 and 5
> records, and the RMFPP Cache Summary report.
>
>
>
>
>
> RON HAWKINS
>
> Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
>
> m+61 400029610| t: +1 4085625415 | f: +1 4087912585
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of ITschak Mugzach
> Sent: Monday, 20 May 2019 04:35
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] how to determine dasd subsystem type from console?
>
>
>
> Is there a command to display the storage subsystem vendor & model?
>
>
>
> ITschak
>
>
>
> --
>
> 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
>
>
> --
> 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: how to determine dasd subsystem type from console?

[Martin Packer]

“2107-900” I’ve always felt to be a little non-descriptive. It doesn’t
really document the HDS model.

Cheers, Martin

Sent from my iPad

> On 20 May 2019, at 09:55, Ron Hawkins  wrote:
>
> Itschak,
>
>
>
> The information is in the NED, which you can display with DS QD,devn,RCD.
>
>
>
> Unfortunately, the model information the emulated IBM device, but the
vendor ID and serial number should get you halfway there.
>
>
>
>
> +4 (4)
>
>
>
> 6 Bytes
>
> Device Type, in EBCDIC.
>
>
> +10 (A)
>
>
>
> 3 Bytes
>
> Device Model, in EBCDIC.
>
>
> +13 (D)
>
>
>
> 3 Bytes
>
> Manufacturer, in EBCDIC.
>
>
> +16 (10)
>
>
>
> 2 Bytes
>
> Manufacturing location, in EBCDIC.
>
>
> +18 (12)
>
>
>
> 12 Bytes
>
> Serial number, in EBCDIC. This field is right justified, padded with
leading zeros in EBCDIC.
>
>
> So “C8E3C3 F7F5” is “HTC 75.”
>
>
>
>
> DS QD,D212,RCD
>
> IEE459I 00.45.35 DEVSERV QDASD 683
>
> UNIT VOLSER SCUTYPE DEVTYPE   CYL  SSID SCU-SERIAL DEV-SERIAL EF
>
> 0D212 PE2US1 2107900 2107900 10017  0624 XX75-65423 XX75-65423 *O
>
>  READ CONFIGURATION DATA
>
> DC010100F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32412
>
> D402F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400
>
> D000F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400
>
> F001F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400
>
>    
>
>    
>
>    
>
> 81852D001E00 0624045001970002 000CC0129269B6FE 00850800
>
>   1 DEVICE(S) MET THE SELECTION CRITERIA
>
>   0 DEVICE(S) FAILED EXTENDED FUNCTION CHECKING
>
>
>
> The information is also available on in the Type 74 subtype 1 and 5
records, and the RMFPP Cache Summary report.
>
>
>
>
>
> RON HAWKINS
>
> Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
>
> m+61 400029610| t: +1 4085625415 | f: +1 4087912585
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
Of ITschak Mugzach
> Sent: Monday, 20 May 2019 04:35
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] how to determine dasd subsystem type from console?
>
>
>
> Is there a command to display the storage subsystem vendor & model?
>
>
>
> ITschak
>
>
>
> --
>
> 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
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: how to determine dasd subsystem type from console?

[Ron Hawkins]

Itschak,

 

The information is in the NED, which you can display with DS QD,devn,RCD.

 

Unfortunately, the model information the emulated IBM device, but the vendor ID 
and serial number should get you halfway there.

 


+4 (4)

 

6 Bytes

Device Type, in EBCDIC. 


+10 (A)

 

3 Bytes

Device Model, in EBCDIC. 


+13 (D)

 

3 Bytes

Manufacturer, in EBCDIC. 


+16 (10)

 

2 Bytes

Manufacturing location, in EBCDIC.


+18 (12)

 

12 Bytes

Serial number, in EBCDIC. This field is right justified, padded with leading 
zeros in EBCDIC. 


So “C8E3C3 F7F5” is “HTC 75.”

 


DS QD,D212,RCD   

IEE459I 00.45.35 DEVSERV QDASD 683   

 UNIT VOLSER SCUTYPE DEVTYPE   CYL  SSID SCU-SERIAL DEV-SERIAL EF

0D212 PE2US1 2107900 2107900 10017  0624 XX75-65423 XX75-65423 *O

  READ CONFIGURATION DATA

DC010100F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32412  

D402F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400  

D000F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400  

F001F0F0F2F1 F0F7F9F0F0C8E3C3 F7F5F0F0F0F0F0F0 F0F6F5F4F2F32400  

     

     

     

81852D001E00 0624045001970002 000CC0129269B6FE 00850800  

  1 DEVICE(S) MET THE SELECTION CRITERIA 

  0 DEVICE(S) FAILED EXTENDED FUNCTION CHECKING  

 

The information is also available on in the Type 74 subtype 1 and 5 records, 
and the RMFPP Cache Summary report.

 

 

RON HAWKINS

Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)

m+61 400029610| t: +1 4085625415 | f: +1 4087912585

 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
ITschak Mugzach
Sent: Monday, 20 May 2019 04:35
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] how to determine dasd subsystem type from console?

 

Is there a command to display the storage subsystem vendor & model?

 

ITschak

 

--

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


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